For the last few years I’ve been a pretty heavy user of Jest, I use it as my test runner across both my FE and BE stacks. While I’m a daily driver of the framework I was recently very surprised to discover a situation where one of my assumptions of how it runs, particularly the order of its
beforeEach method was totally incorrect.
Let’s start with an ordinary jest test describe:
Fairly standard. The
beforeAll will run first, followed by a
beforeEach prior to each test running, resulting with the output of:
top level before all
top level before each
1 day of planning and 4 days of coding.
Last year, while on the lookout for my next contract opportunity, I realised that I was a little out of practice with AWS. My last couple positions involved mostly web development with an aspect of infrastructure management, but nothing too in depth when it came to the AWS ecosystem or any of its moving parts. I took this time off as an opportunity to get myself back up to scratch, as well as practice some implementations that I’d theorised about but hadn’t had the chance to actualise them yet.
For the last few years I’ve been a part of several brand new and phase one projects. No matter the size of the team or business this project has begun with, mistakes are going to be made. Here I’m going to outline some of the most impactful decisions and their consequences I’ve come across. Follow all these steps closely to run a truly terrible project.
“Oh cool I got it working, let’s use it how it is.” — Dev who just finished configuring webpack for the first time.
Generally at the start of a new project, there is some time…
tldr: inside an s3 bucket with site hosting add a redirect.html file, a CloudFront distribution that loads the file and a route53 record set that adds an ‘Alias’ for the CloudFront distribution. Solution and code below.
Recently I re-launched a new design of my personal site, this also involved moving the domain from joshuatoth.com to jjt.dev. Having registered joshuatoth.com on AWS and jjt.dev on google domains.
Before the launch I had my jjt.dev redirecting to google domains via the ‘redirect’ domain control. Super simple
In August last year I had the opportunity to work on a greenfield project within the financial sector. The pitch to me was: An AWS native, Node.js, serverless, event-driven system to back up an IOT device capable of real time messaging and events. I was very intrigued.
The architecture of the project was more or less your expected serverless stack:
First of all, why did I try React Native? I’ve been toying with an app idea and wanted to give app development another shot. It’s been a few years since I last tried. Initially I built the api with Nodejs and a semi functional frontend with regular React. Looking at the trending ‘react’ google searches, React-Native is massive. Ok, let’s give it a shot.
Something that seems to come up a lot when using git on windows is wanting to use an SSH client to manage keys. When you want to use something like PuTTY its a fairly simple, but somewhat hidden process.
By default, git will look in your C:\Users\<username>\.ssh for an id_rsa key and load that.
To get git to load keys from an SSH client instead, you need to add an environment variable (GIT_SSH) pointing to the directory of the client you are using:
The next time you open a command line tool (cmd/powershell/mingw) git will use the SSH agent instead of loading the id_rsa key.
Git extensions has an annoying default setting of showing when a commit was authored, rather than when it was committed to the repository. You can change this by right clicking on a commit, going to the view menu and deselecting ‘Show Author Date’.
You can also deselect ‘relative date’ to show an exact date-time for the commit instead of something like: ‘4 Months ago’.
Breaking apart a monolith is something that takes a while… a long while. There are a few things that while not reducing code, can have a pretty large impact on the overall agility of your product development. Separating out your Front-end code from your monolith’s repository/project/deployment life-cycle is one of those methods. It’s often stateless when embedded into a monolith and one of the safer option to begin your journey. Here’s why.
Starting with deployments: When your front-end code is separated from your monolith it doesn’t need to follow the same deployment schedule anymore. …
For the last few years I’ve been on a journey of breaking down a monolith application. Quite often monolithic and legacy applications are subject to a painfully slow release cycle. It’s quite common for products to have a bi-annually or monthly release cycle, even with frequent daily releases there are still some glaring issues with a scheduled deployment cycle.
To set the scene: An application I’ve been working with for a couple of years has two sets of deployment cycles, running across two branches in a git repository: Beta and Live. Beta sits under a subdirectory for our…