nickporter

The blog post links to this documentation page:

https://developers.google.com/nearby/connections/overview

The screenshot: https://camo.githubusercontent.com/600d273da01fdefca1c72c27c...

    sum = (values) ->
      values.reduce (result, x) -> result + x

We're looking for a software engineer to join our small team. Our stack is Angular, Node, Go, Spark and Python on AWS. We're looking for someone that can design, implement and deploy features that touch all areas of the stack (but mostly frontend).

Email at nick@42technologies.com if interested.

Some of the architecture patterns are actually quite relevant for web development, especially the earlier lessons on decoupling the game layer from the platform layer.

Also, IMO it's unlikely that these events are unrelated.

    1. Tor says they might get compromised.
    2. Guy's exit node gets compromised.

After that, you should have enough JS knowledge to start building a client-side app that consumes your API. I honestly prefer AngularJS, but React+Flux seems like a fine choice.

I also used it when our landing page was wordpress-based.

I'm not trying to bash Docker. In fact, I use it quite a bit, and I never use Heroku. I just think that compared to Heroku, it's much more of a low-level tool. With Heroku, you can just paste a few really simple commands and your webapp is now up.

Oh maybe there's one thing: If you have a massive text file in your project, it will try to index it and things start to get slow.

A couple of years later, my uncle got me a summer job where he worked. That was right after my first year of comspci. I would write bash scripts to automate manual business processes. That's when I first got paid, but it wasn't real software development.

After my second year of uni, I landed an internship at a startup. That's when I first got paid for writing real production code (python).

So, it took maybe 6 years total. However, I think coding is much more accessible nowadays. I'm sure it's possible to start making money in less than a year if you've got drive and passion.

I am 100% for making sync functions asynchronous if it's implementation might have to be async in the future.

In fact, I have done so many times for the exact example you have mentioned.

When you design an asynchronous function, you're telling your caller that he can go and do other stuff (e.g. process other requests) while you're fetching his result in the background. Async functions should never block. If making everything async was a good idea, then underscore would be async.

The author also mentions that it is node convention to use callbacks. Sure, that's true. But he's calling his callbacks the wrong way. Node convention is `callback(error, result)`, not `callback(result)`.

Oh and promises ftw.

Articles like this hurt JavaScript's credibility, and certainly doesn't help new JS/node devs.