Posts About Development

Part 2: Making the Most of Async in Node.js: In Part 1 we discussed how to use p-limit and how to avoid some common pitfalls. Today we are going to go over capacity planning, and cover one last common pitfall - retry logic.

Part 1: Making the Most of Async in Node.js: In the previous article, I very briefly described a bunch of concepts in distributed computing, but before we get to the meat of this series, there’s an elephant in the room that I have so far ignored.

Background: Making the Most of Async in Node.js: If you’re trying to get a lot of unrelated tasks done in Node.js or similar languages, the normal way to write async code is often close enough to best case that most people don’t bother doing more than a little bit of tuning. But as the workload increases, and particularly if you are attempting to do any sort of offline (batch) processing in Node.js, the gap between simple and fast can reach into orders of magnitude and can be worth digging a lot deeper.

You Should Make Your Build Agents Bigger: Someone once told me that a lot of blog posts are about arguments the author already lost. This is one.

What if We Just Reused Code?: The software world is full of ways to avoid duplication of effort. We automate many tasks for our users, for each other, or for ourselves. Among ourselves, one solution we focus heavily upon is code reuse.

Promises in AngularJS: Last year, I gave a small presentation on Promises in AngularJS, with an interactive element. It’s a little bit dated, and a million people have now written about Promises, so I’ll leave the basics and the crash course to Kris Kowal, and jump right to the part I thought was interesting: my examples. Very few people put their examples on JSFiddle for the audience to experiment with, to see what breaks – or doesn’t – when you make alterations.

The Cobbler's Children Have No Shoes: Quality tools inspire quality applications

Rethinking Responsive Design: We know that these days a lot of our users are trying to access our websites from their phones. They may need some information, or they may just be bored and stuck somewhere that they don’t have a larger screen. We also know that a lot of the rest of our users are on tablets, or laptops. We also know that for some of us, how our designs look on projectors matters (which are limited in contrast in addition to real estate). We’ve been designing our little hearts out trying to make our websites “responsive”, and today a lot of the Web looks pretty good at 640 and 1024 pixels wide. It’s been a lot of work and everyone who has pulled it off deserves to be a little proud of themselves. I say “a little proud” because we’re completely dropping the ball in other areas of responsiveness.

See Also: During my absence, I did a bit of writing for my last employer, one is about running Jenkins entirely in Docker (including automated tests) and another one on Jasmine Matchers.

Branching Out: As a young developer, you probably got some good advice. Assuredly one of those pieces of advice was to keep challenging yourself. Branch out. Learn new programming languages. Use new libraries. Don’t let yourself get too comfortable about what you know.