Whether you’re using TDD or whatever it’s called when you write tests after your code (DDT?), there is no silver bullet for creating good unit tests. What separates bad unit tests from useful ones you might ask? Good unit tests explore possibilities and decision points that aren’t easily reproducible while poorly written tests provide a false sense of security by testing happy paths and trivial scenarios.
You’ve just finished a feature and written some tests. A reviewer then looks over your code and accompanying tests and is pleased. The code is released that Friday around 5pm (natch 😉), resulting in…
Ahh, your NPM package is finally live. You’ve published your library to the NPM registry for your tens of adoring fans (or maybe just you) to consume. You’ve been careful to exclude extraneous dependencies from the build and fiddled with webpack for hours to create a truly optimized build. But what about versioning?
Typically a minor version upgrade, from v1.1.0 to 1.2.0 introduces a non-breaking change like a small feature. A major upgrade, from v1.2.0 to v2.0.0, is usually reserved for breaking changes or non backwards-compatible changes. That leaves bugs, which can be resolved with patch upgrades.
This all sounds…
But… it worked locally, I pitifully mumbled at my screen. For some reason, the NodeJS API I had recently deployed to production on AWS using ElasticBeanstalk was returning a 413 (Request Entity Too Large) when a user attempted to upload an attached file. Without the ability to upload, we basically didn’t have an app!
Luckily, or perhaps not so luckily, the internet is littered with articles suggesting solutions to this common issue. At the root cause is the nginx configuration on the EC2 instance having a limit for incoming requests that is lower than what you are attempting to send…
Around 6 months ago our team’s test coverage was pretty dismal, hovering somewhere around 0% for most of our front end applications… yeah, we know. The team had recently switched to using ReactJS, was rapidly expanding and fighting against tight deadlines. Testing was the first thing to go. I mean we have a QA team right?
Fast forward to now and our test coverage has skyrocketed to around 20% per application! Writing tests certainly isn’t free. There is a lot of overhead and initial work to get unit and end-to-end tests working. So why do it? …
Depending on who you ask, Typescript is either the savior or downfall of Javascript. Regardless of how you may feel, there is no denying its popularity and appeal for many developers. I’ve been able to successfully avoid writing Typescript until recently when my team decided to adopt it for a new project. The hope is that using TS will help us avoid the kinds of bugs that lend themselves to using JS: type errors, accessing properties on objects which may not exist and other pitfalls that come at the cost of a dynamically typed language. …
WFH is here to stay for a lot of us. Whether we wanted it or not. At best, the freedom to work from home can offer you more time with your family and friends, the ability to travel and increase your productivity. At worst it can leave you feeling alone, depressed and overworked.
Of course many tech companies paint WFH as a benefit: office space ain’t cheap and neither is wifi 😉. All those free fizzy waters and ping pong tables add up amigo.Work from home they say! Yeah, but what if you don’t really know how?
As a software…
The company I work for is an exciting period of growth. Our engineering team is likely to double before the year’s end and we recently did around 20 interviews for 2 open junior roles on our team. These roles, like most you will see nowadays, require Javascript and more specifically ReactJS.
Nearly all of the interviewees went to a bootcamp which taught React, Javascript and typically NodeJS and MongoDB. The MERN stack seemed to be a popular stack at bootcamps across the board. After doing around a dozen interviews, some patterns really started to emerge in the process.
HTML and CSS — what’s that?
Bootcamps have…
CODEX
Our team has been hard at work developing shared component and shared state libraries for our growing number of e-commerce sites. To centralize this shared logic we’ve published these libraries as npm packages. This was only half the game we soon found out.
In order for our team to use these packages in development we relied on npm-linking the local repos to our consuming front-end. npm link allows you to create a symlink from a package in your node modules to a local directory on your machine. You can read more about it here. …
Stop using 108 console logs in your NodeJS app to debug your API endpoints. I used to employ this same method of saturating my code with logs until a wiser developer showed our team how to pause execution using VSCode.
The problem with relying on tons of logging is that it quickly becomes confusing, especially when dealing with asynchronous logic. Now your console log in that promise is being called out of order or perhaps you logged a deeply nested object and your console only prints [object] . Aarrggghhh. You hammer the endpoint with more and more requests, add more…
Using a script to verify the changes in your release branches
It’s release day at Vincent’s company! In just a few minutes all the new code for their different applications will be released into the wild. His team is feeling confident about a particular feature and hoping things go smoothly. After the site goes live Vince immediately receives a Pager Duty alert. Ruh roh.
It appears an API is returning 500s when processing customer credit cards. A quick investigation into the issue reveals the root cause: a simple property name mismatch. …
Brian Jenney
full-stackish developer, late bloomer coder and power google user
