IF PROGRAMMING LANGUAGES WERE DRUGS:

JavaScript = Methamphetamine:
Anyone can cook some up at home but only pros can make the good stuff without blowing everything up.
Under the influence it tries to do everything at once, in seemingly no specific order before running off and making plenty of promises - but you have no clue if it kept any until it returns.

C = Heroin:
It takes some prep before you can take a hit but when you do it's far more potent than expected. When prepped (compiled) correctly it will induce complete and utter ecstasy but any error or abuse may kill you, leave you on the floor, in a coma or wishing you were dead.

HTML = Paracetamol(Panado):
Some don't think it's a real drug and others do. Either way you should grow a pair and try something a little more hardcore.

--------------------------------------

I came up with these after I randomly explained asynchronous js to a junior as synchronous code on meth. These were just off the top of my head, please feel free to correct or expand on them :-)

JavaScript Motherfucking Asynchronous Bullshit.

I get it, for quite some stuff, async is very, very useful. But why on fucking earth do so goddamn many functions NEED this (and those callback functions) and can't do without?!

If there would be good and nicely understandable await documentation that actually fucking works, I'd be so happy.

I've currently got .then after .then after motherfucking then and its irritating me to no end as it, in this context, shouldn't even be necessary. This thing I'm writing doesn't give a fuck if something takes a few milliseconds before the rest of the program can continue!!

Fuck asynchronous programming in JavaScript for goddamn everything.

(I do love JavaScript!)

Lessons I've learnt so far on programming

-- Your best written code today can be your worst tomorrow (Focus more on optimisation than style).
-- Having zero knowledge of a language then watching video tutorials is like purchasing an arsenal before knowing what a gun is (Read the docs instead).
-- It's works on my machine! Yes, because you built on Lenovo G-force but never considered the testers running on Intel Pentium 0.001 (Always consider low end devices).
-- "Programming" is you telling a story and without adding "comments" you just wrote a whole novel having no punctuation marks (Always add comments, you will thank yourself later for it I promise).
-- In programming there is nothing like "done"! You only have "in progress" or "abandoned" (Deploy progressively).
-- If at this point you still don't know how to make an asynchronous call in your favourite language, then you are still a rookie! take that from me. (Asynchronous operation is a key feature in programming that every coder should know).
-- If it's more than two conditions use "Switch... case" else stick with "If... else" (Readability should never be under-rated).
-- Code editors can MAKE YOU and BREAK YOU. They have great impact on your coding style and delivery time (Choose editors wisely).
-- Always resist the temptation of writing the whole project from scratch unless needs be (Favor patching to re-creation).
-- Helper methods reduces code redundancy by a large chunk (Always have a class in your project with helper methods).
-- There is something called git (Always make backups).
-- If you don't feel the soothing joy that comes in fixing a bug then "programming" is a no-no (Coding is fun only when it works).
-- Get angry with the bugs not the testers they're only noble messengers (Bugs are your true enemy).
-- You would learn more than a lot reading the codes of others and I mean a lot! (Code review promotes optimisation and let's you know when you are writing macaroni).
-- If you can do it without a framework you have yourself a big fat plus (Frameworks make you entirely dependent).
-- Treat your code like your pet, stop taking care of it and it dies! (Codes are fragile and needs regular updates to stay relevant).

Programming is nothing but fun and I've learnt that a long time ago.

aaaaaghh fucking Handlers man. Android is so fucking full of shit, i wonder why am i still doing it. love is pain.

Why can't there be one mother fucking solution to all lazy ass asynchronous programming? handlers, threadpools, asynctask, executers, Broadcasts, intentService, coroutines, rxjava,.... i don't what new stuff are people snorting these days.

Ok , leave everything. A handler is class- no sorry, Handler, alongside some fucking Looper clss (and maybe some more stuff i don't know) other classes is a way of handling inter thread communication. Handlers can:

-send data to ui thread
-recieve data from ui thread
-send "messages" to ui thread
-recieve "messages" from ui thread.
- can be attached to ui thread
- can be attached to any child thread
- can be accessed anonymosly via any view
- can be present in multiple places, working together
- can kill night king with a dagger
- can do porn better than johnny sins
- can run for president of the whole fucking world
- do some more shits that i have yet to discover

And where do i find this? buried deep insides some medium articles or in some guy's horrible accent video.
Is background processing really this much of a toughnut to crack?
earlier i was all about using asynctask or foreground/background services, because these are the most easy to understand abstraction of a fairly difficult topic.
But as i see more projects, i see underlying apis like handlers, threadpools , executers , being directly used.
Why cant there be a fucking single abstraction, that could be "lightly tweaked" to handle every ugly case.

Lord. Please deliver us from the cycle of unfinished programming languages and code benches that are designed to create more work for us. We beseech thee in thy mercy to transmute all this asynchronous lead that is found in javascript into a purer form of threading that is sensible and can be willfully blocked or not so in a way that works and does not divide us through our ugly code. May also we be given the ability to purge from our midst all child molesters and string them up by barbed wire off a line of telephone poles across the entire continental usa and may there be a sudden increase in the number of ravens and buzzards to feed on them, being nice birdies that I miss seeing so much. May half their positively identified population be kept alive and delivered unto us that we might remove their scrotum with a hook-ed barb and something resembling a serrated metallic spork, amen.

and please fix fucking node js. i agree that its asynchronous methods suck ass for literally everything as there is no use for it that seems to work given its a shitty emulated single thread.

Guys cover your eyes I'm gonna say two bad words inside a paragraph

Fuck JavaScript and asynchronous programming - I'm not skilled enough for this so I have to insult it periodically until I'm skilled enough to know partially more than now what the fuck I'm doing (therefore the times I use bad words when referring to js and async programming will decrease - or maybe at the increase of knowledge, my usage of bad words will augment. Only time will tell).

A very long rant.. but I'm looking to share some experiences, maybe a different perspective.. huge changes at the company.

So my company is starting our microservices journey (we have a 359 retail websites at this moment)

First question was: What to build first?

The first thing we had to do was to decide what we wanted to build as our first microservice. We went looking for a microservice that can be used read only, consumers could easily implement without overhauling production software and is isolated from other processes.

We’ve ended up with building a catalog service as our first microservice. That catalog service provides consumers of the microservice information of our catalog and its most essential information about items in the catalog.

By starting with building the catalog service the team could focus on building the microservice without any time pressure. The initial functionalities of the catalog service were being created to replace existing functionality which were working fine.

Because we choose such an isolated functionality we were able to introduce the new catalog service into production step by step. Instead of replacing the search functionality of the webshops using a big-bang approach, we choose A/B split testing to measure our changes and gradually increase the load of the microservice.

Next step: Choosing a datastore

The search engine that was in production when we started this project was making user of Solr. Due to the use of Lucene it was performing very well as a search engine, but from engineering perspective it lacked some functionalities. It came short if you wanted to run it in a cluster environment, configuring it was hard and not user friendly and last but not least, development of Solr seemed to be grinded to a halt.

Elasticsearch started entering the scene as a competitor for Solr and brought interesting features. Still using Lucene, which we were happy with, it was build with clustering in mind and being provided out of the box. Managing Elasticsearch was easy since there are REST APIs for configuration and as a fallback there are YAML configurations available.

We decided to use Elasticsearch since it provides us the strengths and capabilities of Lucene with the added joy of easy configuration, clustering and a lively community driving the project.

Even bigger challenge? Which programming language will we use

The team responsible for developing this first microservice consists out of a group web developers. So when looking for a programming language for the microservice, we went searching for a language close to their hearts and expertise. At that time a typical web developer at least had knowledge of PHP and Javascript.

What we’ve noticed during researching various languages is that almost all actions done by the catalog service will boil down to the following paradigm:

- Execute a HTTP call to fetch some JSON

- Transform JSON to a desired output

- Respond with the transformed JSON

Actions that easily can be done in a parallel and asynchronous manner and mainly consists out of transforming JSON from the source to a desired output. The programming language used for the catalog service should hold strong qualifications for those kind of actions.

Another thing to notice is that some functionalities that will be built using the catalog service will result into a high level of concurrent requests. For example the type-ahead functionality will trigger several requests to the catalog service per usage of a user.

To us, PHP and .NET at that time weren’t sufficient enough to us for building the catalog service based on the requirements we’ve set. Eventually we’ve decided to use Node.js which is better suited for the things we are looking for as described earlier. Node.js provides a non-blocking I/O model and being event driven helps us developing a high performance microservice.

The leap to start programming Node.js is relatively small since it basically is Javascript. A language that is familiar for the developers around that time. While Node.js is displaying some new concepts it is relatively easy for a developer to start using it.

The beauty of microservices and the isolation it provides, is that you can choose the best tool for that particular microservice. Not all microservices will be developed using Node.js and Elasticsearch. All kinds of combinations might arise and this is what makes the microservices architecture so flexible.

Even when Node.js or Elasticsearch turns out to be a bad choice for the catalog service it is relatively easy to switch that choice for magic ‘X’ or component ‘Z’. By focussing on creating a solid API the components that are driving that API don’t matter that much. It should do what you ask of it and when it is lacking you just replace it.

Many more headaches to come later this year ;)

Spent three hours catching a async void..

Changed it to a Task and it worked.

So i have been coding in python and its my main language. Give me 2 reason why i should learn js(node).this question aroused coz i have to work with MS Bot framework and they just support c# & node js (python is still in prev) and their code has asynchronous programming in both *cries in corner also suggest me good resources to lesrn what async prog