Tech job interviews are notoriously difficult. You never know what questions they are going to ask you - are they going to ask about obscure language trivia, have you build some UI component while doing a screenshare, ask you some algorithm puzzles that have no relevance to the job day-to-day, or ask you to design an architecture for some theoretical problem?
Sometimes you have to load tons of data from a database, file, etc., so much so that your Node service crashes due to the dreaded "Out of Memory" error
Sometimes when developing a service that calls an external REST API or testing calling an endpoint from a front-end, you'll need to test what happens when that API returns different HTTP status codes. You can do this using tests, and mock/stub a 404, 500, etc. But often it's very helpful to see what happens when a specific response status is returned.
If you've ever worked with Express code, you've likely had to read through controllers (also sometimes referred to as "route handlers") that are doing way too much. So much so, that sometimes you can't even fit all the code for a method on the screen.
Getting up-to-speed on a new codebase - whether you're diving into an open source library or you just joined a new company and you're learning their code - is always a bit daunting...
Without a new Express version having been released in years, is it time to stop using it? On the surface, it looks like Express hasn't been maintained in a long time. It gets a couple minor version and patch version upgrades each year but version 5 (the next major version) has been in development for years and doesn't seem like it will ever be released at this point.
When writing code that's more generic, you may be wondering where in your project does it go? Could it be considered a utility? Or does it belong with your business/domain logic?
Because Node and the most popular web frameworks (like Express) don't provide much if any guidance on how to structure your REST API, many Node developers are often left floundering. Developers coming from Spring, Ruby on Rails, or Django benefit from those frameworks being so opinionated on structure/patterns, so don't usually have to struggle. But I've found that even those developers - because they've had their hand held by the frameworks - when they come to Node realize they didn't understand the underlying concepts
If you've worked on a few different Node applications you've probably seen a few different places you can put your tests. Or if you're new to writing tests you may be wondering what folder/directory to put them in. For example, do you put the test files alongside the JavaScript files? Or do you put them in their own test folder?
When you're writing tests, it's often the general setup like creating fake data and setting up stubs/mocks/fakes that can hold you back. Sometimes to the point where you end up skipping writing the tests altogether...
There are different layers where you can put request validation...
When you're writing code dealing with the request lifecycle, what is the difference between middleware and ontrollers? What code goes in each? They both touch the "request object" and do things with it, so it seems like there might be overlap or controllers might be redundant to have.
In this post I want to examine the claim that "you should only ever have one assertion per test".
Sometimes when working on adding or modifying unit tests within a test suite, you may not be sure what the best way to structure the tests within that suite is.
There are several different architectural patterns and solutions for handling asynchronous code. Queues, promises, worker threads, child processes, the cluster module, scaling horizontally with multiple containers, etc. Whether you're dealing with scaling up or computationally-heavy tasks, certain patterns/solutions will be the right choice over others.
Usually a task queue is used when you want to offload a longer running block of code and you don't need the results of that code in the rest of your code. But if we can skip waiting for asynchronous JavaScript code to finish, and keep the code "fast" that way, doesn't that accomplish the same thing? Why would you need a queue to begin with?
Something I see in many ExpressJS APIs is overuse / incorrect use of middleware. Sometimes to the extent that almost everything is middleware.
When it comes to executing several Promises concurrently and waiting for them all to finish before using their resolved values elsewhere in your code, Promise.all() is really useful. The problem is though, that if one of those Promises fails/rejects, all the function calls will still happen, but the return value you'll get will just be the value of the first rejected Promise.
You're chugging along writing tests, but then you run into a scenario where you need to test a side-effect. Maybe that's a call to a database, or a call to an external HTTP endpoint, or just making sure a function gets called.
The scenario: you're looking for a new job and have found a few potentially good options, but you have no idea what working there will actually be like...
If you've ever had to deal with setting up a Node.js project in which you had to install a bunch of things - like MySQL/Postgres, Redis, etc. - and then run some setup scripts just to be able to get the project running locally on your machine... then you've likely experienced the pain of losing half a day - at least - to solely just getting set up.
In order to test your endpoints/routes in Express/Koa/whatever you're using, you might currently be using a tool like Postman to send HTTP requests and make sure you're getting back the expected responses / the right code is being executed.
Have you ever used Node packages like knex, aws-cli, or mocha and wondered how they are able to be run from the command-line?
When you're working on an Express REST API, you may run into a situation where you need to make a call to fetch some data / do some things from your controller and then take that data and do some more things with it...and it just so happens you have another controller that returns that data you need / does those same things already. So naturally the question arises, should you make that controller to controller call?
_The scenario_: you want to make multiple requests at the same time, and wait for them all to finish before returning all the data.
When you’re starting up an Express project, it can be confusing to figure out all the modules you need... and this is no different when it comes to middleware.
You might have heard that you should separate your web logic (HTTP routes, middleware, and controllers) from your business logic (services).
You've written tests for your Express app, and you have most happy paths covered. But now you need to write a test for how your API handles an error. You want to test that your API returns a HTTP 500 status code, for example, if there is an internal server error.
You're creating the backend API for your new Node.js service and it's come time to setup Continuous Integration / CI so you can actually deploy the service.
Have you ever found yourself wanting to ditch using require for your Node imports, ditch writing code that made use of require() and instead used import?
When you're writing asynchronous code in JavaScript using async/await functions, it can be confusing to know how to handle returning an asynchronous value. Do you need to await the promise before you return? Or should you just return the promise?
As developers, we constantly hear that we should be writing tests... "All good developers know how to write tests, and they write them!"
Often when we're developing a piece of code, we need to take one starting value and apply several functions to it before we return that value. The problem with this is that it's difficult to read...
That's great that you can run the npm package you just installed (knex, in this case) from the command line, but what's usually left out is how you actually go about doing that.
A common scenario: as part of your npm start script, you need to have more than one command run.
Let's talk about writing unit tests for JavaScript / Node applications.
When you're working with Docker you'll typically have some sort of image library/registry, like Docker Hub, where built images are uploaded to. You might be wondering why you would download it if you could just create the image locally with docker build using the Dockerfile?
This is the second half of a better way to sell your skills as a developer than just "hire me!" or mass applying to jobs.
There are few things that bring developers more absolute agony than the job search. It's weird that even though software development skills are probably the most in-demand of all time, of any career, we still face such difficulties in searching and interviewing for new jobs.
A new scenario you might not have faced before: you have a long running task (like saving to a bunch of different databases, or processing video) that takes a while to process and it's currently causing your REST API response times to be way too slow for the end user.
Logging as much information as you need to be able to troubleshoot, understand what happened during a session, and even for analytics purposes is something all apps need to have in place before going to production. You've likely got some logging in place - things like errors and successful transactions (if you're looking at logs for analytics/metrics). But now you're wondering what else you should be logging so that you have everything you need should you face some issues in production.
When dealing with an array of async/await functions (which return Promises), it can be tricky to figure out how to execute them all in series (one-at-a-time) and how to call them in concurrently (not one-at-a-time, executed during overlapping time periods).
This is a follow-up to my post on the process for converting callbacks to Promises and to async/await functions
This is a follow-up to my last post, What is the difference between Controllers and Services in Node REST API's? In that post we covered the differences between the two, and what kind of logic goes where, but only briefly touched on why you might want to do this. You might still be wondering, "why is it a good idea to separate the two?". Why use services when controllers are already working?
If you've built out a REST API in Node (or other languages, for that matter), you've likely used the concept of "controllers" to help organize your application. Maybe you put your calls to your database or models there, called some other endpoints, and added some business logic to process the returns.
This is the next post in my ongoing series on knowing what to test in your Node applications by applying recipes to real-world scenarios. In the first one, we went over scenarios you should cover in your tests when calling a database from a Node service. And in the second one, we covered what scenarios to write tests for when your applications calls out to an external API.
"You should really use Promises or async/await here to make this more readable." How many times have you posted some code snippet when trying to get an answer to your question, and someone ends up pestering you about this?
Have you ever written a unit test expecting to catch an error with Chai, and gotten something like the following?
You might have heard that you should "always layer your app" and "never let logic leak into other layers" before. Those are statements made all over your favorite blogs, in "must read" programming books, and at tech meetups and conferences. But you might have wondered why exactly it's a problem!
This is the next post in my series on knowing what to test in your Node applications by applying recipes to real-world scenarios.
Do any GitHub or Google search for REST API structures using Node + Express and you'll find very few of them follow the same organization. What's even worse is, while there are lots of good tutorials out there, many of them have no structure at all. They just put everything into a 200-line server.js file and call it a day...
Have you ever been frustrated by having to always manually add '/api' to the beginning of each of your Express routes?
Have you ever tried finding an open source Node.js project that you could study to level up your skills, only to end up not finding one at all because you didn't know what actually makes a project a "good" one to study?
Have you ever been confused on how to structure your Express applications in a way that makes them testable? As with most things in the Node.js world, there are many ways of writing and structuring Express apps.
When you're writing unit tests for asynchronous functions in JavaScript, one test case you'll usually want to have is making sure the async function throws an error in case of an error scenario.
If you've ever gone through a JavaScript or Node unit testing tutorial, it can be difficult to find anything that shows you what you should be testing - what scenarios to cover, what to write tests for, etc.
Have you ever tried Test-Driven Development (TDD) thinking it would be the "holy grail" it's often made out to be, only to end up feeling like it was pointless?
Have you ever added logging to your custom Node modules, thinking you'll benefit from all that extra information, only to find that when you add the modules as dependencies, run npm install and npm start, your application logs start looking like the below?
Logging is one of those things that can sometimes be a black box for developers. Maybe you have a dedicated DevOps person who takes care of logging infrastructure for you, or maybe it's your first time working on this side of things.
The console module is usually the first tool Node.js developers reach for when handling logging in an application. It's easy to use, native to the platform, and easy to read. But then you might stumble upon a logging framework like Winston or Bunyan. The basic power of those tools might be attractive enough for you to consider switching. But should you? How do you know which one you should use? Should basic console.log’s be avoided entirely and not even used?
Unit testing is so critical to good software development, yet for beginners (and many experienced professionals as well) it's something that can feel alien and uncomfortable at first. It might be something you know you should be doing, but haven't had time to learn, or tried to and didn't get very far. It might also be something you've never even heard of before.
If you've spent any time in the Node or Front End JavaScript world, you know there are hundreds of thousands of modules to choose from.
../../../../../Having/to/write/code/like/this when you're requiring local modules is a sight for sore eyes. Fortunately there are easy solutions to fix this.
If you're coming to Node.js from a more synchronous language/environment such as Ruby on Rails or Java, the concept of asynchronous processing can be confusing. All the literature talks about Node being async, so it's easy to get the understanding that it's all asynchronous. But not every method in Node is async and this is important to be aware of.
If you're trying to loop over a list while using async/await in Node.js (or the browser, for that matter), reaching for the .forEach array function might seem like a natural choice. Let's say you go that route, fire up your tests or your application, and expect the synchronous-reading magic of async/await to do what it says and actually await the promise.
If you're one of the few remote developers on your team and you're new to the company or working with people you've never worked with before, you may have experienced the pain of relying on people who are unresponsive. This is easier to do when you are remote and they don't have a face to match the name or much of a relationship built up. Instead of familiar faces in the office, they (and you) are just names on a screen. And unlike being in the office you can't just walk over to their desk to get what you need.
Deciding that you're going to ask your manager if you can transition from your in-office software developer job to moving to a new city and working 100% remotely can be a big decision. There are likely tons of concerns you have about how to approach this. You've probably practiced your pitch hundreds of times, thought through all kinds of details and prepared for every scenario you could think of.
If you're a new or less-experienced developer that wants to eventually work remotely full-time, you may already be wondering how long you need to stay at your current on-site job (or future job if you're still looking for one) before you have the skills to go remote.
So you're looking for your first remote software developer job but all the job postings list requirements beyond your current knowledge.
There are several ways to make configurable components and services in Angular 2 / 4
In organizations that aren't fully remote, remote employees can sometimes be forgotten about, seen as black sheep or as separate from the group.
If you're using the npm module node-oracledb to connect to an Oracle database from Node, consider using this Promise-based and cursor-based wrapper/utility to return results from your queries and close connections
The recent obsession with capital "I" Innovation that has been rapidly gaining momentum the last couple of years has permeated across a majority of large, traditional companies with business models, technologies, and processes seemingly stuck in the past.
I turned my "on-premise" job into a remote one 6 months ago. Here are ten observations from the experience so far, with the goal that these assist others transitioning or thinking about transitioning to remote work.
This is the first in a series of projects that will be developed around the idea of applying "calm technology" to product design.
First time setup of Chrome Extensions can be painful if you've never done it before. Add to that setting them up for use with ES6 and you can end up spinning your wheels longer than writing code.
Although I've been working with compose for a bit now, I needed to review why it operates from right-to-left (also known as "right associative"). A review of mathematical theory will help answer this question.
Quick tip: for those developing AWS Lambda applications using Node.js, if you're uploading a zip package rather than editing inline, something you might get stuck on while trying to test your function is the below error
This project was an exercise to learn more about ThreeJS, Virtual Reality, and how the real, physical world can be used as inputs to a constructed, virtual world.
When first hearing about const in ES6, I was excited about the possibility of having immutability in native JavaScript.
As the Internet of Things reaches maturation and begins to become commonplace in our lives, the technology used to support IOT must be chosen well.
Recently at work I needed to use node-soap to interface with some old SOAP-based systems.
Had some fun over the weekend learning how to build skills using Amazon Alexa.
Project management software, and the project management practice in general, should include a Return on Investment feature.
This is the first post in a series I'll be doing about new ES6 features.
The last couple of days I've been playing around with authoring a Yeoman generator.
This past Wednesday was the inaugural meeting of the Hartford