Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "chain learning"
-
This is a rant.
I'd rather say go fuck yourself. I mean whatever the fuck you mean by block chain programming? Found a word and start adding random words to it and start learning it? I mean who the fuck wants to program AI in HTML? (Seen somewhere else)10 -
The perks of learning iptables through practice:
Suddenly losing Internet connection on le entire computer and then realizing that you added a DROP EVERYTHING on the input chain through a referenced chain 😅3 -
Okay, story time.
Back during 2016, I decided to do a little experiment to test the viability of multithreading in a JavaScript server stack, and I'm not talking about the Node.js way of queuing I/O on background threads, or about WebWorkers that box and convert your arguments to JSON and back during a simple call across two JS contexts.
I'm talking about JavaScript code running concurrently on all cores. I'm talking about replacing the god-awful single-threaded event loop of ECMAScript – the biggest bottleneck in software history – with an honest-to-god, lock-free thread-pool scheduler that executes JS code in parallel, on all cores.
I'm talking about concurrent access to shared mutable state – a big, rightfully-hated mess when done badly – in JavaScript.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
Every time I showed my work to a JavaScript developer, I'd get negative feedback. Like, unjustified hatred and immediate denial, or outright rejection of the entire concept. Some were even adamantly trying to discourage me from this project.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
http://nexusjs.com/architecture/
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
The average JavaScript developer doesn't want a multithreaded server platform for JavaScript because it means a change of the status quo.
And this is exactly why I started this project. I wanted a highly performant JavaScript platform for servers that's more suitable for real-time applications like transcoding, video streaming, and machine learning.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
How about utilising logical CPUs to the fullest extent, and allowing them to execute JavaScript? Something that isn't even possible with the current model implemented by Node?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
Good JavaScript programming practices miraculously coincide with the best practices of thread-safety.
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18 -
I've caught the efficiency bug.
I recently started a minimum wage job to get my life back in order after a failed 2 year project (post mortem: next time bring more cash for a longer runway)
I've noticed this thing I do at every job, where I see inefficiency and I think "how can I use technology to automate myself out of this job?"
My first ever application was in C++ for college (a BASIC interpreter) and it's been so long I've since forgotten the language.
But after a while every language starts to look like every other language, and you start to wonder if maybe the reason you never seriously went anywhere as a programmer was because you never really were cut out for it.
Code monkey, sure. Programmer? Dunno, maybe I just suffer from imposter syndrome.
So a few years back I worked at a retail chain. Nothing as big as walmart, but they have well over 10k store locations. They had two IBM handscanners per store, old grungy ugly things, and one of these machines would inevitably be broken, lost or in need of upgrade/replacement about once a year, per location. District manager, who I hit it off with, and made a point of building report with, told me they were paying something like $1500 a piece.
After a programming dry spell, I picked up 'coding' with MIT app inventor. Built a 'mostly complete' inventory management app over the course of a month, and waited for the right time.
The day of a big store audit, (and the day before a multi-regional meeting), I made sure I was in-store at the same time as my district manager, so he could 'stumble upon' me working, scanning in and pricing items into the app.
Naturally he asked about it, and I had the numbers, the print outs, and the app itself to show him. He seemed impressed by what amounted to a code monkeys 'non-code' solution for a problem they had.
Long story short, he does what I expected, runs it by the other regionals and middle executives at the meeting, and six months later they had invested in a full blown in house app, cutting IBM out of the mix I presume.
From what I understand they now use the app throughout the entire store chain.
So if you work at IBM, sorry, that contract you lost for handscanners at 10k+ stores? Yeah that was my fault (and MIT app inventor).
They say software is 'eating the world' but it really goes to show, for a lot of 'almost coders' and 'code monkeys' half our problem is dealing with setup and platform boilerplate. I think in the future that a lot of jobs are either going to be created or destroyed thanks to better 'low code' solutions, and it seems to be a big potential future market.
In the mean while I've realized, while working on side projects, that maybe I can do this after all, and taken up Kotlin. I want to do a couple of apps for efficiency and store tracking at my current employer to see if I'm capable and not just an mit app-inventor codemonkey after all.
I'm hoping, by demonstrating what I can do, I can use that as a springboard into an internal programming position at my current gig (which seems to be a company thats moving towards a more tech oriented approach to efficiency and management). Also watching money walk out the door due to inefficiency kinda pisses me off, and the thought of fixing those issues sounds really interesting. At the end of the day I just like learning new technologies, and maybe this is all just an excuse to pick up something new after spending so long on less serious work.
I still have a ways to go, but the prospect of working on B2B, and being able to offer technological solutions to common and recurring business needs excites the hell out of me..as cringy and over-repeated as that may sound.5 -
When you have to learn a new language so you can learn a framework so you can learn to integrate with an app you about to learn how to make.1
-
This week I reached a major milestone in a Machine Learning/Music Analysis project that I've been working on for a long time!!
I'm really proud to launch 'The Harmonic Algorithm' as an open source project! It represents the evolution of something that's grown with me through two thesis' (initially in music analysis and later in creative computation) and has been a vessel for my passion in both Music and Computation/Machine Learning for a number of years.
For more info, detailed usage examples (with video clips) and installation instructions for anyone inclined to try it out, have a look at the GitHub repo for the project:
https://github.com/OscarSouth/...
"The Harmonic Algorithm, written in Haskell and R, generates musical domain specific data inside user defined constraints then filters it down and deterministically ranks it using a tailored Markov Chain model trained on ingested musical data. This presents a unique tool in the hands of the composer or performer which can be used as a writing aid, analysis device, for instrumental study or even in live performance."1 -
I fucking hate chained methods. Ok, not all of them. Query things like array.where.first... that stuff is ok.
Specially if it's part of the std lib of a lang, which would be probably written by a very competent coder and under scrutiny.
But if you're not that person, chances are you'll produce VASTLY inferior code.
I'm talking about things like:
expect(n).to.be(x).and.not(y)
And the reason I don't like it is because it's all fine and dandy at first.
But once you get to the corner cases, jesus christ, prepare to read some docpages.
You end up reading their entire fucking docs (which are suboptimal sometimes) trying to figure if this fucking dsl can do what you need.
Then you give up and ask in a github issue. And the dev first condescends you and then tells you that the beautiful eden of code he created doesn't let you do what you want.
The corner cases usually involve nesting or some very specific condition, albeit reasonable.
This kind of design is usually present in testing or validation js libraries. And I hate all of those for it.
If you want a modern js testing lib that doesn't suck ass, check avajs. It's as simple as testing should be.
No magic globals, no chaining, zero config. Fuck globals forced by libs.
But my favorite thing about it that is I can put a breakpoint wherever the fuck I want and the debugger stops right fucking there.
Code is basically lines of statements, that's it, and by overusing chaining, by encouraging the grouping of dozens of statements into one, you are preventing me from controlling these statements on MY code.
As an end dev, I only expect complexity increases to come from the problems themselves rather than from needlessly "beautified" apis.
When people create their own shitty dsl, an image comes to my mind of an incoherent rambling man that likes poetry a lot and creates his own martial art, which looks pretty but will get your ass kicked against the most basic styles of fighting.
I fucking hate esoteric code.
Even if I had to execute a list of functions, I'd rather send them in an array instead of being able to chain them because:
a) tree shaking would spare from all the functions i didn't import
b) that's what fucking arrays are for, to contain several things.
This bad style of coding is a result of how low the barrier to code in higher level langs are.
As a language or library gets easier to use you might think that's a positive thing. But at the same time it breeds laziness.
Js has such a low learning curve that it attacts the wrong kind of devs, the lazy, the uninspired, the medium.com reader, the "i just care about my paycheck" ones.
Someone might think that by bashing bad js devs I'm trying to elevate myself.
That'd be extremely stupid. That's like beating a retarded blind man in a game and then saying "look, I'm way better than this retarded blind man".
I'm not on a risky point of view, just take a stroll down npmjs.com. That place is a landfill. Not really npm's fault, in fact their search algorithm is good.
It's just the community.
Every lang has a ratio of competence. Of competent to incompetent devs.
You have the lang devs and most intelligent lib devs at the top. At the bottom you have the bottom.
Well js has a horrible ratio. I wouldn't be shocked to find out that most js devs still consider using import or await the future.
You could say that js improved a lot, that it was way worse beforr. But I hate chaining now, and i hated back then!
On top of this, you have these blog web companies, sucking the "js tutorial" business tit dry, pumping out the most obscenely unprofessional and bar lowering tutorials you can imagine, further capping the average intelligence of most js devs.
And abusing SEO while they're at it, littering the entire web with copy paste content.2 -
Here comes lots of random pieces of advice...
Ain't no shortcuts.
Be prepared, becoming a good programmer (there are lots of shitty programmers, not so many good ones) takes lots of pain, frustration, and failure. It's going to suck for awhile. There will be false starts. At some point you will question whether you are cut out for it or not. Embrace the struggle -- if you aren't failing, you aren't learning.
Remember that in 2021 being a programmer is just as much (maybe even moreso) about picking up new things on the fly as it is about your crystalized knowledge. I don't want someone who has all the core features of some language memorized, I want someone who can learn new things quickly. Everything is open book all the time. I have to look up pretty basic stuff all the time, it's just that it takes me like twelve seconds to look it up and digest it.
Build, build, build, build, build. At least while you are learning, you should always be working on a project. Don't worry about how big the project is, small is fine.
Remember that programming is a tool, not the end goal in and of itself. Nobody gives a shit how good a carpenter is at using some specialized saw, they care about what the carpenter can build with that specialized saw.
Plan your build. This is a VERY important part of the process that newer devs/programmers like to skip. You are always free to change the plan, but you should have a plan going on. Don't store your plan in your head. If you plan exists only in your head you are doing it wrong. Write that shit down! If you create a solid development process, the cognitive overhead for any project goes way down.
Don't fall into the trap of comparing yourself to others, especially to the experts you are learning from. They are good because they have done the thing that you are struggling with at least a thousand times.
Don't fall into the trap of comparing yourself today to yourself yesterday. This will make it seem like you haven't learned anything and aren't on the move. Compare yourself to yourself last week, last month, last year.
Have experienced programmers review your code. Don't be afraid to ask, most of us really really enjoy this (if it makes you feel any better about the "inconvenience", it will take a mid-level waaaaay less time to review your code that it took for you to write it, and a senior dev even less time than that). You will hate it, it will suck having someone seem like they are just ripping your code apart, but it will make you so much better so much faster than just relying on your own internal knowledge.
When you start to be able to put the pieces together, stay humble. I've seen countless devs with a year of experience start to get a big head and talk like they know shit. Don't keep your mouth closed, but as a newer dev if you are talking noise instead of asking questions there is no way I will think you are ready to have the Jr./Associate/Whatever removed from your title.
Don't ever. Ever. Ever. Criticize someone else's preferred tools. Tooling is so far down the list of what makes a good programmer. This is another thing newer devs have a tendency to do, thinking that their tool chain is the only way to do it. Definitely recommend to people alternatives to check out. A senior dev using Notepad++, a terminal window, and a compiler from 1977 is probably better than you are with the newest shiniest IDE.
Don't be a dick about terminology/vocabulary. Different words mean different things to different people in different organizations. If what you call GNU/Linux somebody else just calls Linux, let it go man! You understand what they mean, and if you don't it's your job to figure out what they mean, not tell them the right way to say it.
One analogy I like to make is that becoming a programmer is a lot like becoming a chef. You don't become a chef by following recipes (i.e. just following tutorials and walk-throughs). You become a chef by learning about different ingredients, learning about different cooking techniques, learning about different styles of cuisine, and (this is the important part), learning how to put together ingredients, techniques, and cuisines in ways that no one has ever showed you about before. -
Want an app to sell to investors?
All aboard the hype train.
Block chain.... Check
Machine learning...... Check
Pwa..... Check2 -
I did not think that making a serverless Discord bot would be such a learning experience. The code itself was easy. The hard part was the infrastructure, because I decided to automate it all with Terraform and deploy it on AWS.
Before this project, I had no idea how API Gateways worked. Now I still have very little idea how they work but I managed to build one anyway. Eventually. And then I had to figure out how to automate the deployment of a lambda layer and function that would both still be managed in the Terraform state, with any code changes triggering a rebuild and update for the resource.
And then I had to untangle a dependency mess because API Gateways have some weird issues where two resources that have no explicit dependencies on each other will throw an error if they don't deploy in the right order.
And then I went the wrong way with Github actions trying to conditionally chain multiple workflows together before I realized I could just put multiple jobs with conditions in a single workflow.
And now after all that work over the course of 2 days, I have a bot that does this:2 -
Dell Summer Internship Experience
Firstly,to be a part of this process it is important to clear the exam conducted by college and according to me it wasn't something which can't be easily achieved so to prepare of this exam stick to basics of all subjects which have been taught so far till semester majorily data structures,data base,Java,C, operating system were asked.Basics of all following subjects should be clear which also going to help during internship.I myself prepared for the test from geeksforgeek.I tried to gain as much as basic knowledge of subjects I can.And after selecting from test you have you go through hackathon on that personally I think one should be prepared with latest demanding skills.Mostly all the hackathon topics were in and around Machine Learning,Block chain,Web development,Databases.So typically should be aware of all these technologies and how this can be used to enhance in project.During hackathon days it is important to be interactive,it is good to clear doubts or explain your idea and how innovative you project is and how different it can be and further keep in mind how your project can be industrial utilized.Try to make your project more in aspect of how industry going to adapt this or how this problem's solution is perfect in every terms for a company.And majorily at last it comes down to how to present your project infront of your panel.I think keep that session as much as interactive you can,try to answer their queries,and most importantly know your part of the project very well on theoretical as well as on code level. At last you have to go through a HR interview in which firstly you have to be prepare with a nice resume in which you to include all your achievement's,projects and most importantly keep it short and simple and include only those things which you are completely aware of.For interview first try to know and learn about company, it's goals,in what field it is presently working and during interview there is nothing to worry about you just have to talk like you are talking with a normal person,express all your views ,try to speak out. Confidence is one important thing for this interview.So this was conclusion of my experience from hackathon hiring process from Dell.5 -
is being a tech/dev person, a dead end job?
i have been thinking about this for sometime. as a dev, we can progress into senior dev, then tech lead, then staff engineer probably. but that is that. for a tech person :
1. their salary levels are defined. for eg, a junior may earn $10k pm , and the highest tech guy (say staff engineer) will earn $100k pm, but everyone's salary will be spread over this range only, in different slots.
2. some companies give stocks and bonuses , but most of the time that too is fixed to say 30% of the annual salary at max.
3. its a low risk job as a min of x number of tech folks are always required for their tech product to work properly. plus these folks are majorly with similar skills, so 2 react guys can be reduced to 1 but not because of incompetency .
4. even if people are incompetent, our domain is friendly and more like a community learning stuff. we share our knowledge in public domain and try to make things easy to learn for other folks inside and outside the office. this is probably a bad thing too
compare this to businesses , management and sales they have different:
1. thier career progression : saleman > sales team manager> branch manager > multiple branch manager(director) > multiple zones/state manager (president) > multiple countries/ company manager (cxo)
2. their salaries are comission based. they get a commission in the number of sales they get, later theybget comission in the sales of their team> their branch > their zone and finally in company's total revenue. this leads to very meagre number in salaries, but a very major and mostly consistent and handsome number in commission. that is why their salaries ranges from $2k pm to $2-$3millions per month.
3. in sales/management , their is a always a room for optimisation . if a guy is selling less products, than another guy, he could be fired and leads could be given to other/new person. managers can optimise the cost/expenses chain and help company generate wider profits. overall everyone is running for (a) to get an incentive and (b) to dodge their boss's axe.
4. this makes it a cut-throat and a network-first domain. people are arrogant and selfish, and have their own special tricks and tactics to ensure their value.
as a manager , you don't go around sharing the stories on how you got apple to partner with foxconn for every iphone manufacturing, you just enjoy the big fat bonus check and awe of inspiration that your junior interns make.
this sound a little bad , but on the contrary , this involves being a people person and a social animal. i remember one example from the office web series, where different sales people would have different strategies for getting a business: Michael would go wild, Stanley would connect with people of his race, and Phyllis would dress up like a client's wife.
in real life too, i have seen people using various social cues to get business. the guy from whom we bought our car, he was so friendly with my dad, i once thought that they are some long lost brothers.
this makes me wonder : are sales/mgmt people being better at being entrepreneur and human beings than we devs?
in terms of ethics, i don't think that people who are defining their life around comissions and cut throat races to be friendly or supportive beings. but at the same time, they would be connecting with people and their real problems, so they might become more helpful than their friends/relatives and other "good people" ?
Additionally, the skills of sales/mgmt translate directly to entrepreneurship, so every good salesman/manager is a billionaire in making. whereas we devs are just being peas in a pod , debating on next big npm package and trying to manage taxes on our already meagre , "consistent" income :/
mann i want some people skills like these guys10 -
Dell Summer Internship Experience
Firstly,to be a part of this process it is important to clear the exam conducted by college and according to me it wasn't something which can't be easily achieved so to prepare of this exam stick to basics of all subjects which have been taught so far till semester majorily data structures,data base,Java,C, operating system were asked.Basics of all following subjects should be clear which also going to help during internship.
I myself prepared for the test from geeksforgeek.I tried to gain as much as basic knowledge of subjects I can.And after selecting from test you have you go through hackathon on that personally I think one should be prepared with latest demanding skills.Mostly all the hackathon topics were in and around Machine Learning,Block chain,Web development,Databases.So typically should be aware of all these technologies and how this can be used to enhance in project.
During hackathon days it is important to be interactive,it is good to clear doubts or explain your idea and how innovative you project is and how different it can be and further keep in mind how your project can be industrial utilized.Try to make your project more in aspect of how industry going to adapt this or how this problem's solution is perfect in every terms for a company.And majorily at last it comes down to how to present your project infront of your panel.
I think keep that session as much as interactive you can,try to answer their queries,and most importantly know your part of the project very well on theoretical as well as on code level. At last you have to go through a HR interview in which firstly you have to be prepare with a nice resume in which you to include all your achievement's,projects and most importantly keep it short and simple and include only those things which you are completely aware of.For interview first try to know and learn about company, it's goals,in what field it is presently working and during interview there is nothing to worry about you just have to talk like you are talking with a normal person,express all your views ,try to speak out.
Confidence is one important thing for this interview.So this was conclusion of my experience from hackathon hiring process from Dell.2 -
Need advice about switching to contracting.
TL;DR;
So I had 2 years of exp as an android dev, then I had a 1.5 year gap from doing android and now for the past 6 months Ive been doing android again fulltime. Im thinking of switching to contracting due to my debts and boring project and life crushing slow corporate processes in my current fulltime job, so I need tips and advices as to where should I start looking for new contracting gigs and in general what should I pay attention to. If it helps, I am based in EU, but am open to any EU/US gigs.
Now the full story:
Initially when I joined my current fulltime job after a break I had zero confidence, lowered my and employers expectations, joined as a junior but quickly picked up the latest standards and crushed it. Im doing better than half devs in my scrum team right now and would consider myself to be a mid level right now.
Asked for a 50% bump, manager kinda okayed it but the HQ overseas is taking a very long time to give me the actual bump. I have been waiting for 10 weeks already (lots of people in the decision chain were on and off vacations due to summer, also I guess manager sent this request to HQ too late, go figure). Anyways its becoming unnaceptable and I feel like its time for a change.
Now since I have mortgage and bills to pay, even with the bump that I requested that would leave me with like maximum 700-800 bucks a month after all expenses. I have debts of around 20k and paying them back at this rate would take 3 years at least and sounds like a not viable plan at all.
Also it does not help that the project Im working on is full of legacy and Im not learning anything new here. Corporate life seems to be very slow, lots of red tape kills creativity and so on. I remember in startups I was cooking features left and right each sprint, in here deploying a simple popup feature sometimes takes weeks due to incompetence in the chain. I miss the times where I worked in startups, did my job learned nre skills and after 6 months could jump on another exciting gig. Im not growing here anymore.
So because my ADD brain seems to be suited much better for working in startups, and also I need to make more money quick and I dont see a future in current company, I am thinking of going back to contracting. All I need right now is to build a few side apps, get them reviewed by seniors and fill my knowledge gaps. Then I plan of starting interviewing as a mid level or even a senior for that matter, since I worked with actual seniors and to be honest I dont think getting up to their level would be rocket science.
Only difference between mid and senior devs that I see atleast in my current company is that seniors are taking on responsibility more often, and they also take care of our tools, such as CD/CI, pipeline scripts, linters and etc. Usually seniors are the ones who do the research/investigations and then come up with actual tasks/stories for mids/juniors. Also seniors introduce new dependencies and update our stack, solve some performance issues and address bottlenecks and technical debt. I dont think its rocket science, also Ive been the sole dev responsible for apps in the past and always did decent work. Turns out all I needed was to test myself in an environment full of other devs, thats it. My only bottleneck was the imposter syndrome because I was a self taught dev who worked most of my career alone.
Anyways I posted here asking for some tips and advices on how to begin my search for new contract opportunities. I am living in EU, can you give me some decent sites where I could just start applying? Also I would appreciate any other tips opinions and feedback. Thanks!3