I created LanceDarkly, a VS Code extension to help make it easy to manage LaunchDarkly toggles without leaving the editor. What are LaunchDarkly toggles? It’s a service which enables a way of remotely managing the visibility of app features. Toggles are especially handy for trunk-based development and continuous deployment practices by enabling engineers to build features without the end-user seeing it. When that feature is ready, the toggle can be switched on to make the feature visible for all. LaunchDarkly toggles have many other options including splitting traffic to provide a way to split test.
There is an issue with unit testing VS Code extensions. The vscode dependency - which is needed to utilise the editor’s features - will error when running unit tests. Essentially it is a third party dependency which is out of your control, so the best thing to do is to mock the API. I will be using Jest and will explain how to use its mocking features to handle the VS Code dependency.
This won’t be a deep dive into unit testing React components but I will present some options for mocking external services. This is seen as good practice at the unit test level, as we don’t want these tests dependant on an external API which will slow the feedback down and make the test fragile. Mocking is typically used quite loosely and there are plenty of nuances when we throw spies and stubs in the mix. However, they do have a particular meaning and they are all placed under the generic term of Test Double as described by Martin Fowler.
In the previous article I talked about security concerns around storing tokens in localStorage. I thought it would be worth exploring how to use HttpOnly cookies when making requests from a React client-side app. This will include making changes to the Apollo Graphql Server to manage cookies from the client. In this post I will go through the changes needed to enable storing JWTs in HttpOnly cookies from sending headers.
This is the continuation of JWT for authentication using Apollo Graphql server and will show an example of how to send JWTs for each request from the client to the GraphQL server, and how to handle updated tokens when a user returns for a new session in the client.
This tutorial will focus on the key features needed to send and receive tokens, meaning there is no complete example output to try at the end. The aim is to help you integrate authentication into your own app.
This post will cover managing complex state at a feature level rather than the entire site. React hooks have enabled developers to have cleaner functional components which help to rationalise our component logic with ease.
Take useState hook, it’s one line of code that can be used to manage the state of a component rather than having to create a class component with the addition of boiler code. This is great because we are keeping simple things clear!
However, there are features that are inherently complex as they could have many nested child components and need to alter the state.
What options are there to manage this complexity in React?
Typically ‘speed of delivery’ is a key measure for an Agile software engineering team. However, sometimes you notice a pattern of weeks ending with high or low points, and this affects the predictability of your delivery. So how can you make delivery more consistent?
This post will focus more on pace of delivery and around team processes, rather than tooling to reduce overheads, like automation. The reason you want to achieve predictable delivery, is so that your team can confidently estimate what can be done in a sprint. This can also help product and business estimate how long a feature could take to deliver.
This post will be covering two topics, installing Bcrypt NodeJS as a dependency and prevent linking node_modules from host machine to your docker container.
Using Bcrypt package to encrypt passwords comes with a minor challenge: when installed it needs to be compiled to the operating system (OS) architecture using node-gyp, python 2.x. These prerequisite dependencies are needed to build the app on a dev machine, which needs to be documented. However, docker solves the need to communicate this in your “get started” documentation. Unfortunately this will create a problem of slow feedback loop during development.
For most of my published open source projects I’ve added a simple continuous integration (CI) pipeline using Travis CI. This time around I wanted a way to deploy a project after successful integration and try a new pipeline. Azure DevOps caught my attention. The goal here is to build, test and deploy my VS Code extension Git Mob to the marketplace.
I’ll provide bite size instructions to help you build a CI and continuous delivery (CD) pipeline for your VS Code extension on Azure DevOps platform. Following these steps I estimate it will take 15-25mins to get it all working.
This post is to help developers who are new to Azure DevOps releases and deploying a VS Code extension. Azure pipelines come with lots of great options but it can be difficult to know what to do to achieve your goal. The goal in this case is to deploy my VS Code extension, Git Mob to the marketplace.
I’ll provide bite size instructions to help you build a release for your VS Code extension using Azure DevOps platform. This will take about 5-10mins.