I’ve been working on an application built on the Gatsby framework for a little over a year now, and have had an excellent time doing so. There have been a number of problems (mostly solvable), and a boatload of features and plugins that have saved more time than I can imagine. So in general, it was a good year, here are some of the ups and downs…
Some context; The application I manage is a reasonably sized, reasonably complex, multi product, multi locale, web application. With a full team of engineers, product managers and designers, all working together to build…
I take an approach of “how can this be easier/better” with my engineering, architecture and strategy work, this is the story of how we simplified and improved one of the most tedious parts of Back End (BE) to Front End (FE) relationships, whilst making the whole thing quicker, easier and in general, better. It comes down to one word: Contracts.
I like the above photo, a lot: it was a phenomenal feat of engineering; two teams drilling under the Channel Tunnel and meeting precisely in the middle. Thankfully software engineering is a little simpler than that.
However, when building Front…
Whilst writing part 1 of this series, I became aware that there wasn’t a huge amount of information or advice on how to utilise the overrides feature within eslint (outside of these docs). This is something I recommend utilising as it will allow you to understand when and why we should ignore certain lint rules, making it easier to fix problems as they arise with permanent solutions, rather than temporary ones.
Simply put; specific rules for specific files.
What you probably do now
Do these look familiar?
/* eslint-disable max-lines */// eslint-disable-next-line no-console
I bet they do, and it’s likely not a…
An age-old story, engineers complaining about reviewing code, having their code reviewed, how long it takes, how much time out of their day it takes. No matter what, it is a vital part of our jobs, and isn’t really going anywhere fast. With the introduction of better linting, better CI, and better tools, it’s getting easier than ever. Responding to this, I wanted to take the first steps into improving our process, with the ultimate goal of reaching opinion only code reviews whilst simultaneously reducing cognitive load for engineers.
Today we look at the first step into improving this process…
Do you live in a world where some developers, maybe even you, have specific things you’d like to enforce in a code review? Outside of the realms of the current ESLint rules, Prettier rules, or anything else that can’t be caught via CI? Well, hopefully, this will help you take that extra step forward to a world of overly specific, probably unnecessary linting rules.
A couple of notes before we start:
- You don’t need to know the absolute underlying fundamentals of javascript to do this, it might help, but it won’t hinder.
- AST and typescript aren’t super great friends yet…
One approach to using TypeScript with GraphQL is to generate a TypeScript type library based on a GraphQL schema, creating interfaces for all of the objects we might use in the code, which does work fine.
However, there is a safer way to do this, and that is by having unique types for every situation, rather than shared types that can be used everywhere. In this article, I’ll explain what’s wrong with this approach as well as a mechanism on how to improve it.
All of the code for this is available here: https://github.com/thomasparsons/graph-apollo-typing
The first approach for generating and using types
One mechanism that is in place…
Building a REST API using Node.js, deploying to Heroku and accessing it from a slash command within Slack.
The scene.
It’s the day before my wife’s birthday, and I realise, that whilst I have purchased her a gift from me, I haven’t purchased her one from our cats; a time-honoured tradition in our house for any gifting occasion.
I am a software engineer, and outside of my love for cats and my wife, I enjoy building applications of all sorts. So I figured I could probably knock some sort of tech together as a fun gift, and as we have a Slack…
I am a Senior Front-End Engineer at Perkbox, working within a large team of FE developers split over 5 projects. Alongside the day-to-day feature building and bug fixing, we are encouraged to try new techniques and practices to increase the quality of our work and our overall working practices.
Previously on this subject: Stateless and Stateful Components
This article assumes you already have at least a basic understanding of React, and ES6 syntax.
Before we were using TypeScript, we used variables such as const KRAMER = “kramer" and exported these from a shareable file, which works fine and multiple developers…
I am a Senior Front-End Engineer at Perkbox, working within a large team of FE developers split over 5 projects. Alongside the day-to-day feature building and bug fixing, we are encouraged to try new techniques and practices to increase the quality of our work and our overall working practices.
This article assumes you already have at least a basic understanding of React, and ES6 syntax.
About six months ago, we adopted Typescript within React Native as a new project was started, and then slowly, with lessons learned, those best practices were applied to our much larger library that had been…
