Forem: Jonathan Fielding

Typesafe application configuration in TypeScript

Jonathan Fielding — Sat, 24 Jan 2026 08:05:07 +0000

If you've ever had a deployment succeed but then the service acts weird, there's a decent chance config was the culprit.

Config bugs are painful because:

they often pass code review ("it's just config")
deployments can look healthy until the broken path is hit
secrets make debugging harder (you can't safely log everything)
and TypeScript can give a false sense of safety because config is often a quiet loophole where any creeps back in

In this post:

why typesafe config matters (and what goes wrong without it)
why validating config at startup is a big deal
how zodified-config solves both using Zod
copy/paste examples you can drop into your app

Why typesafe configuration matters (and what can go wrong without it)

A common pattern in Node.js apps is using a config library like node-config:

import config from "config";

const port = config.get("port");

The issue is that config.get() is often effectively untyped inside your app. In many setups it returns any (or unknown), which means TypeScript can't catch mistakes.

For example, you expect port to be a number:

import config from "config";

const port: number = config.get("port");

This compile but if your config value is "3000" (a string), you may run into runtime problems when you do:

app.listen(port);

Even worse are subtle bugs:

import config from "config";

const enableMetrics = config.get("metrics.enabled");

if (enableMetrics) {
  startMetricsServer();
}

If metrics.enabled is the string "false", it's truthy, and suddenly metrics are enabled in production when they shouldn't be.

That's how config issues turn into scattered, confusing “ghost bugs”.

Why validating configuration at startup is a big deal

Types help you use config safely. Validation helps you ensure the config is actually valid before the app starts serving traffic.

Without startup validation you often get this pattern:

app boots “fine”
first request hits a codepath that needs config
runtime explosion
sometimes the service crashes entirely

A rule I like:

If the app can't run correctly without a config setting, fail fast before you start serving traffic.

This is especially useful in Kubernetes: new pods should only become “ready” if their config is valid.

Practical wins of startup validation

Prevent broken deployments

Missing values (DB URLs, API keys, queue names) should crash immediately, not halfway through a request.
Faster feedback loops

Misconfiguration becomes obvious in startup logs (and CI/CD), rather than waiting for a user to trigger it.
Clear error messages

Schema validation can tell you exactly what's wrong:
- which key is missing
- which key has the wrong type
- which nested value failed validation

Introducing zodified-config

Once you want typesafe config and startup validation, you end up wanting the same workflow everywhere:

define a schema (runtime contract)
validate config once, on boot
access config with types and autocomplete across your app

That's what zodified-config is for.

It lets you:

define your config schema using Zod
keep using the familiar node-config file structure (config/default.json, etc.)
validate at startup (fail fast)
get TypeScript types for config access everywhere

It's built as a wrapper around node-config, so you keep existing behaviour just with Zod-backed validation and type safety.

How to use zodified-config (step-by-step)

1) Install

If you're using CommonJS:

npm i zodified-config

If you're using ESM:

npm i zodified-config-esm

2) Define your schema

// src/schema.ts
import z from "zod";

export const configSchema = z.object({
  value: z.string(),
});

export type Config = z.infer<typeof configSchema>;

This schema is the runtime contract, and z.infer gives you compile-time types from that same source.

3) Define your configuration files

Because this wraps node-config, you use the same structure:

// config/default.json
{
  "value": "hello world"
}

4) Validate at startup (fail fast)

Declare your validated config type using TypeScript module augmentation, then validate on boot:

// src/index.ts
import config from "zodified-config";
import { configSchema } from "./schema";
import type { Config } from "./schema";

declare module "zodified-config" {
  interface ValidatedConfig extends Config {}
}

config.validate(configSchema);

If config is invalid, validation throws at startup, exactly when you want to find out.

(You can wrap it in a try/catch if you want to customise the error output.)

5) Access values with type safety

Now anywhere in your app:

// src/other.ts
import config from "zodified-config";

const value = config.get("value");
// value is typed as string

console.log(value);

This is where it starts to feel really good:

autocomplete for config keys
compile-time safety for config usage
fewer “stringly-typed” surprises

A more realistic example

Here's what this looks like for a typical service:

// src/schema.ts
import z from "zod";

export const configSchema = z.object({
  env: z.enum(["development", "test", "production"]),
  port: z.number(),
  database: z.object({
    url: z.string().url(),
    poolSize: z.number().int().positive(),
  }),
  features: z.object({
    metrics: z.boolean(),
  }),
});

export type Config = z.infer<typeof configSchema>;

After validating at startup, access becomes boring (in the best way):

import config from "zodified-config";

const port = config.get("port"); // number
const dbUrl = config.get("database.url"); // string
const metricsEnabled = config.get("features.metrics"); // boolean

If someone breaks config in an environment:

the app fails immediately
you get a clear validation error
you don't ship a “looks healthy but is doomed” deployment

Conclusion

TypeScript gives you a lot of safety but configuration is often the escape hatch where untyped values creep back in and quietly undermine it.

Defining a schema for config:

makes config access typesafe
improves editor autocomplete and catches key mistakes earlier

Validating config at startup:

prevents broken deployments
makes issues obvious in logs and CI/CD
reduces “works on my machine” surprises
gives you confidence changing config over time

Tools like zodified-config keep your code and config in sync and it's one of those small changes that makes a big difference to reliability.

If you try it, I'd love to hear how it goes.

5 Habits of Great Software Engineers

Jonathan Fielding — Sun, 16 May 2021 20:08:02 +0000

I first started my journey as a software engineer back in 2008 when I joined ADP, building software for building merchants. This was my first experience working at a tech company, and as someone new to the industry, I couldn’t tell the difference between what were the good habits I should be picking up from my colleagues and what were their bad habits.

Since that first role, I have worked at 7 different companies across a variety of different industries, which as a result, gave me the opportunity to work with some incredible engineers that I have been able to pick up some good habits from.

Today I want to share with you some of those habits, focusing on the five habits which I believe all developers could benefit from having.

1. Admit when you don’t know something

Photo by Jon Tyson on Unsplash

The first habit it is important to instil in yourself is to admit when you don’t know something and accept that you can never know everything.

To give you some perspective on this, if we take a look at Wikipedia, we will find it lists over 700 programming languages alone, and when we consider that each will have its own frameworks and languages, it is clear that no one could be knowledgeable about everything.

Instead of pretending you know all the answers, you should instead admit when you are unsure and feedback to the team that you will need to take the time to learn and research about the area your exploring. Besides allowing you to get help when you need it, being known for admitting when you don’t know something can instil trust within your team that when you say you know something, you actually do.

2. Learn from your team’s mistakes instead of assigning blame

Photo by Sarah Kilian on Unsplash

As software engineers, we are often building complex systems and solving complex problems on a daily basis. Inevitably sometimes we will make mistakes; however, the focus shouldn’t be on blaming the individual who made the mistake, but instead on identifying what we can learn as a team from the mistake to prevent it from happening again.

The way in which I do this in my teams is that for mistakes that result in an incident that affects our users, we will write a post mortem. In this post mortem, we will document what happened, what was the cause, what was the impact and what the actions are to prevent this from happening again.

In other cases where the mistake doesn’t impact our users, we will normally talk about it as part of our team retrospectives, where we can safely talk about what has gone wrong and the learning we can take from it.

This approach means we spend our time focusing on team growth rather than assigning blame to whoever made the mistake. As a team, we get to share the learnings and as a whole, the whole team has much better morale.

3. Put your user’s needs above your own

Photo by Taras Shypka on Unsplash

As software engineers, we often need to make decisions about what technologies we use. The choices we make every day have an impact on both our experience as developers and the experience of our users using our products. This means we should always consider the user cost of the decisions we make.

Let’s take the example of delivering a new feature for our users. As part of the research into developing the feature, we find a library that will enable us to deliver the feature faster. At first glance, this is a win for both the user who will benefit from the feature being ready sooner and the developer who is building it. To validate this, it is important to consider the cost of using the library, this could result in a couple of scenarios:

Perhaps it is a 1KB library that will have a negligible impact on the user’s experience of the application.
Alternatively, maybe it is a 1MB library that will negatively impact the performance of the application.

If it is the first option, then choosing the library might have a net benefit to both the user and the engineer, however, if the latter is true then only the developer sees the benefit of using the library. In this example, I would always prioritise putting the user first to ensure they have a great experience even if it means it will take me a bit longer to deliver the feature.

4. Have strong opinions, but hold them weakly

Photo by Steve Johnson on Unsplash

In your lifetime, you might have come across the phrase, “Strong Opinions, Weakly Held”. The phrase originated from a post written back in 2008 by Paul Saffo regarding how he approaches writing long-term technology forecasts, wherein in the face of uncertainty, it’s important to form an opinion on something even if that opinion is later proven incorrect. The post itself can be found on Paul Saffo’s blog.

While it originated in technology forecasting, it has quickly been applied as a framework for thinking.

If we apply this to software engineering, you might propose a solution you believe to be correct for the problem at hand. Further down the road, you might then find your original solution will not work; however, with the additional information you learnt, you then can get to the correct solution to solve your user’s problem.

5. Listen first, speak later

Photo by Brett Jordan on Unsplash

There is a common misconception that software engineers are shut-ins that don’t like to communicate with others. The reality of being a successful software engineering is quite the opposite; we work in multi-functional teams bringing together people from different disciplines, and we work together to build great products for our users.

When working in this way, communication between everyone in the team is incredibly important so that everyone has a good understanding of what the team is trying to achieve. This communication must be 2 way, with an emphasis on listening first to all the opinions in the team and then giving your input.

This becomes even more important as you grow into a more senior engineer, where your words will carry more weight, making it difficult to not sway the conversation. Listen to your colleagues, they will have great ideas that as a team you can build on to build great products.

Conclusion

It goes without saying that there is much more to being a great software engineer than the five habits I have written about here. Software engineering is a broad complex field and what works at one company might not work at another.

These habits came from my own experiences and I would love to hear about your own experiences, what habits do you think make a great software engineer?

Starting a tech meet-up during a global pandemic

Jonathan Fielding — Sun, 16 May 2021 20:04:05 +0000

My 2020 started like most peoples; I was going to work on the weekdays and enjoying my weekends with my family. Sometimes I would attend tech meetups after work. I even managed to host a couple in my workplace, first London Web Performance, and then on the last week before we entered lockdown, we hosted a JS Monthly London International Women’s Day event.

Then came lockdown, and with it came a sudden break in tech events, with conferences and meetups all being cancelled.

Shortly into this, I got talking to Natalie, an associate engineer I work with at RVU, and we came up with the idea of starting a meetup ourselves, we then found our another colleague Ricardo had similar ideas, so we combined forces.

Figuring out what we wanted to create a meetup about

Having had the idea we wanted to create a meetup we decided to put a session in so we could ideate what we wanted our meetup to focus on.

These discussions focused on two things, the topics that we wanted to cover and the audience we wanted to reach. When it came to topics we wanted to be fairly web-focused, with a focus on product development in particular. When it came to the audience we wanted to appeal to a broad spectrum, from associate engineer right through to lead.

In our discussions, we decided that as we were all product engineers the meetup should focus loosely on product engineering, with talks around the area of building great products.

Naming our meetup

Having decided to start our meetup, the first priority was to give it a name. We created a slack channel called #an-unnamed-meetup and started to throw name ideas back and forth.

After some thinking, we came up with a wide variety of names, and then we shared them in a poll with the rest of the RVU engineering team, the choices being:

Product Engineering People
Programmed in Pencil
Build Right, Scale Fast
Core Red
London Product Engineering
Product Engineering Monthly
Ventures in Engineering
Shipping Code

With a total of 13 votes, we settled on the name Programmed in Pencil which we had come up with based on our company belief that “Everything is written in pencil”.

Creating the website

Having named our meetup, the next step was to register the domain name and create a website.

For the website, I cheekily forked a website I built for a conference called Web Progressions back in 2016. The primary reason for this was the site was open-source, and this would save me time as it already had everything I needed from a template point of view. It also was already set up in a way that Jekyll could compile the Sass when deployed to GitHub pages.

After spending some time skinning the template to have a unique look and feel to this meetup, I then sent a screenshot across to my colleague Rob Newport who is a designer in my team. He then did an amazing job of tweaking the design to the lovely site design you see today, and then we paired on implementing the changes.

We then pushed the page up to GitHub, the cloud team at RVU kindly bought the domain name and then we pointed it at the site.

Finding Speakers

So we had a name, a potential date to run our meetup and a website ready to go, we now needed to find some people who would like to speak at the meetup.

Early on in discussing the meetup, we agreed that it was essential to ensure that the speaker lineup wasn’t just those from RVU. This wasn’t to be a marketing event for our business but instead to be an event that would help share knowledge and be an opportunity for us to give back to the tech community.

That said, for our first speaker, we actually were fortunate enough that one of our colleagues had already recently prepared a talk for a conference which unfortunately been postponed due to Coronavirus. He, therefore, was happy to give the talk at our meetup.

Fortunately having been attending meetups for a good number of years and spoke at them myself I have made many friends in the tech community so for the other two talks I reached out to my friends Jo Franchetti and Katie Fenn, both of which were happy to talk.

Promoting the meetup

With everything in place, the next step was to promote the meetup.

As a self-confessed Twitter addict, this was the primary place I promoted the event. I regularly tweeted about it to my followers to encourage them to attend. I also reached out to other meetups, JS Monthly London and Frontend London and asked them to also tweet out to their followers.

Besides Twitter, I also promoted the event on various slack groups I am in focused on engineering including FEL slack and Codebar.

The night of the event

When it came to the night, we were all ready; we had agreed among, Natalie, Ricardo and I, who would introduce each speaker.

At the beginning of the event, I introduced the event along with myself and my co-hosts Ricardo and Natalie. Then for each speaker, a different host would introduce them. The talks were all really good, and I was really proud to have been part of organising this great event.

After the event, we regrouped and discussed what went well, and we summarised it into the following:

What went well

Amazing talks with live demos that worked well
We had about 40 people attend
Zoom webinars worked well for both registrations and people joining the meetup

What didn’t go so well:

One of the speakers had connection problems which lead to us having to do some quick shuffling of the order of the talks
We were awful at keeping on time, with this being remote some people dialled in for specific talks however by being

While there is little we can do regarding connection issues of speakers or attendees, we did think about how we could resolve the second issue. What we came up with was tweaking the format to better take into account keeping on time. We inserted “Interviews” in between each of the talks, which would be an opportunity for us and the audience to ask questions.

This served a dual purpose where it provided buffer time in between each talk, if a talk ran short we could ask more questions, and if it ran longer, we would simply have less time for questions.

In Summary

Running Programmed in Pencil with my work colleagues has been a great experience and allowed me to finally live my dream of running my own tech event.

Would I recommend others give it a try, definitely, I think diversity of thought is incredibly important so I would love to see more remote tech meet-ups to pop up all with their own focus to give people lots of different places to learn about things in different ways.

A few people have asked why I haven’t yet spoken at Programmed in Pencil myself, to be honest, I wanted to provide a stage for others to share their knowledge, I always felt that if I were to talk it would be if we were short of a speaker one month, but I wouldn’t be aiming to speak at the event.

Our next meetup is on the evening of Wednesday 26th May, and we welcome those from all over the world to join us. Register at www.programmedinpencil.com.

Getting past my insecurities by talking at tech events

Jonathan Fielding — Fri, 05 Mar 2021 13:08:40 +0000

As a person, I am very insecure. I struggle to introduce myself to people I haven’t spoken to before and this something that has often left me feeling isolated when attending tech events.

When at a tech event if I don't already know someone at the event I can struggle to start a conversation with people at the event. This results in the majority of people I have spoken to at events are those who I have either seen speak (so I can ask a question to start a conversation), those that introduce themselves or I have been introduced too.

Speaking at Halfstack London 2019

I think part of this stems back to being bullied in high school, so much so that I changed schools at the beginning of year 9. This was a terrible experience and it was during this time I changed from being someone who would express his emotions to someone who kept them to myself. since then I have had to relearn how to not keep these feelings bottled up inside and to express myself better. This hasn’t really helped with my inner confidence at all, while outwardly I may come across as a confident person, I still have these deep down insecurities which leave me often feeling worried unnecessarily about things.

Where there is one place I am confident however is in my coding, since I was 9 years old learning BASIC on an Acorn I have loved to code and I have been confident in speaking to others about it.

After changing school at the beginning of Year 9 I found a book in my new school's library about HTML and I then launched my first website, which as I was 13 was aptly named Jonathan’s World. Ever since I have loved the web, I even attempted running a web hosting company when I was 15, then by the time I was 17 I realised there was no money in it unless you can do it on a huge scale so I got out of the hosting game.

With this confidence in talking about technology, I have tried to get past the awkwardness of attending an event by starting to talk at them. The theory being that if I was speaking people would approach me rather than me having to approach them.

Since I started speaking at events I have given over 20 different talks at conferences and meetups across London. I reuse those talks as well so the number of talks I have actually given is probably close to 50 by now. What I found is that this gave me the opportunity to share with others what I know and to also build my own confidence.

This also validated my hypothesis, and usually, after I have given a talk people will start a conversation with me instead of the other way round. With this, I have been able to start real conversations and make new friends which in turn has meant I have been introduced to many new amazing people I wouldn’t have otherwise met.

As a developer there are many different places we can talk about what we do, there are online forums, sites like Reddit, Twitter and even through GitHub but nothing quite compares to the interactions you get and the knowledge that is shared at a meetup or a conference. The bringing together of like minds is amazing, and it gives you an amazing opportunity to share problems you might have faced, learn from one another and talk about the cool web things you are passionate about. I love to attend meetups like London Web Standards, London Web and Front-end London and if you find yourself at one of these events and you see me there, I would love it if you introduced yourself, and I myself will be looking to try being more confident in my ability to introduce myself as well.

If your running an event like a meetup or a conference and you want someone to come and talk, I am always looking for places to talk so just get in touch, I am very easy to get hold of either through this site or on Twitter.

From talking to other people in the development community, I know there are others who went through bullying and/or are in the situation of feeling awkward and out of place when going to development events and as a community, we have a duty to try and ensure everyone is included. So next time you see someone at a meetup or conference who you think might be feeling to insecure to introduce themselves, maybe you should introduce yourself to them, start a conversation because by being at the same event you clearly already have one thing in common, that you share an interest in whatever the talk is about. I think it's up to the development community to make sure everyone feels welcome and valued because without the people that make up the community, there is no community.

Working with variables and conditionals in Go Lang

Jonathan Fielding — Fri, 05 Mar 2021 12:48:44 +0000

I recently started to learn Go Lang, and as part of this I have been learning about variables and how they differ to variables in other languages I have worked with such as JavaScript and PHP.

Getting to grips with variables

In Go, variables are explicitly declared and when you compile your application, Go will infer the type of the initialized variables and use this to check the type-correctness of your code.

To define a variable in Go Lang we use var followed by the name of the variable, equals, and the value we want to assign to the variable. We can update our ‘Hello World’ application from earlier to use variables for each of the words.

The first step is to create a new file, in this case, I used using-variables.go. We can then take the original code from our hello world application and create 2 variables, one for each of the words. We then update our fmt.Println to instead join the strings, adding a space in between.

package main

import "fmt"

func main() {
    var hello = "hello"
    var world = "world"

    fmt.Println(hello + " " + world)
}

We can then run this example:

go run 02-using-variables.go

This will result in the words hello world being logged to the console. While this is a fairly contrived example, is shows us how we can easily update code which previously hard coded to now be customisable.

Introducing conditional logic to our application

The next thing we are going to learn about is how we can introduce conditional logic to our hello world application. In this case I want to allow the user to have the option to provide a name and instead of saying hello to the world we will say hello to that individual person instead 😀.

The first step is to create our new file for the new version of the application. I have called my file conditional-logic.go and as a starting point I copied and pasted the code from our previous application.

We now need to allow our application to get user input. To do this we need to import the os package which will make the arguments available to us as an Array. To access this Array we use os.Args, the first item of which will be the path to our application and the rest of the values will be the arguments we passed to it.

We only want to set the name when an argument has been passed, to do this we can use an if statement. In this if statement we want to check that the length of the arguments, excluding the application path is equal to one, we do this with the following.

if len(os.Args[1:]) == 1 {
    name = os.Args[1]
}

If we incorporate this into our completed code it will look as follows:


package main

import (
  "fmt"
  "os"
)

func main() {
  var hello = "hello"
  var name = "world"

  if len(os.Args[1:]) == 1 {
    name = os.Args[1]
  }

  fmt.Println(hello + " " + name)
}

To run our application we can simply run the command:

go run conditional-logic.go

This will still output hello world however if we now pass a name as an additional argument:

go run conditional-logic.go jonathan

The output will now be hello jonathan, this is exactly what we wanted to achieve 🤗.

Wrapping up

Thank you for taking the time to read about using variables in Go Lang, it was good to start playing with variables and conditionals and I can definitely see similarities to how I would write the same thing in JavaScript.

Writing your first `Hello World` in GoLang

Jonathan Fielding — Wed, 03 Mar 2021 22:51:23 +0000

Recently I was given the feedback that I needed to broaden my skillset when it comes to the technologies I use to enable me to progress further in my career as an Engineer.

As a more ‘frontend focused’ full-stack engineer, the backend languages I have had experience with so far are those more commonly picked up by frontend engineers, that being PHP early on in my career and then later moving to Node.js.

I decided to pick Go Lang as a technology RVU already uses as the programming language to learn. The benefit is that I would immediately have use for it in the workplace, giving me a chance to apply what I have been learning.

With all this in mind, I will try to document my learning here to help others who are trying to learn Go Lang as well.

Installing Go Lang

Before we can get started with Go Lang, we first need to set up our development environment. As a Mac user, I will document how to do this on Mac using the command line (Terminal) however, Windows instructions can be found at https://golangdocs.com/install-go-windows.

Install Homebrew

The first step is to install homebrew if you do not already have it installed. Homebrew is a package manager for macOS that allows you to install different command-line tools and programming languages onto your computer.

Installing homebrew is fairly straight forward; we simply run the following command:

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

We will then be asked for our password, and the install script will then do all the hard work for us. If you get stuck, the documentation can be found at https://brew.sh.

Configure your system paths

Having installed homebrew we now need to configure some system paths.

The system paths will need to be added to your systems shell configs. The file you will need to edit will differ based on the Shell your command-line interface is using. To find out what Shell we are using, we can run echo $SHELL in our CLI; this will tell us the path to the Shell we are currently using.

If the output is /bin/zsh or similar, you are using zsh and will need to edit the .zshrc file located in your users’ home directory.

If the output is /bin/bash or similar, you are using bash and will need to edit the .bashrc file located in your users’ home directory.

You will need to copy and paste the following paths to your Shell config file.

# Go development
export GOPATH=”${HOME}/.go”
export GOROOT=”$(brew — prefix golang)/libexec”
export PATH=”$PATH:${GOPATH}/bin:${GOROOT}/bin”
test -d “${GOPATH}” || mkdir “${GOPATH}”
test -d “${GOPATH}/src/github.com” || mkdir -p “${GOPATH}/src/github.com”

Install Go Lang using homebrew

Finally, we can install Go Lang, to do this we simply run the following command:

brew install go

This will automatically install Go for us on your computer, once this is done we are ready to setup our text editor and then write our first app 😀

Configuring Visual Studio Code

As a heavy user of Microsoft’s Visual Studio Code (aka VS Code), the next step before writing any code is to install some plugins to add Go Lang support. If you are not a VS Code user, please feel free to skip this step.

As this is my first day using Go Lang I don’t have any life-changing suggestions for extensions right now however the official plugin for VS Code by the Go Team at Google seems pretty good. It can be found at https://marketplace.visualstudio.com/items?itemName=golang.Go.

Writing your first `hello world`

Having set up my environment I can finally write my first code in Go Lang, as is customary in the tech space this will be a hello world application that simply logs ‘hello world’ to the console.

To start with we need to create a file for our hello world application, we will call it hello-world.go. We will open this in our text editor and then write out code, for our ‘hello world’ application, the code looks like below.

package main

import "fmt"

func main() {
    fmt.Println("hello world")
}

As you can see we imported the Go Lang library fmt and then used that to simply log to the console using fmt.Println("hello world").

We can run our code by running the following in our CLI from the folder that we are using.

go run hello-world.go

What’s next?

Today I managed to get my environment setup and write my first application😁. It was super fun getting this all setup and hopefully, this can be helpful to others trying to learn Go Lang for the first time.

5 Less Known JavaScript Features That You Should Know About

Jonathan Fielding — Wed, 03 Mar 2021 20:14:51 +0000

JavaScript is an ever-evolving programming language, with yearly EcmaScript versions debuting new features every year. That makes it difficult to keep up with all the changes that are being made to the language so I thought I would write a short post of 5 features that you could use to improve your own code.

1. JavaScript string padding

The first JavaScript feature I wanted to talk about is the result of an incident that happened back in 2016 in the JavaScript ecosystem.

The incident involved a JavaScript package called left-pad which was published to NPM. The purpose of the package was to pad a string with extra characters, and while simple in nature the package was a dependency of thousands of JavaScript projects worldwide.

The incident happened when it was removed from NPM and as it was depended on by many packages it caused a domino effect breaking software builds all over the world.

While NPM fixed the issue, it became evident to the folk at TC39 that a lot of people were preferring to use a library to pad strings than write the code themselves thus as part of ES2017 they introduced .padStart() and .padEnd().

To add 0’s to the beginning of a string we would use .padStart(), passing the target length for the string and the string to pad the current string with. In the below example I am padding the string "1" so that it has a length of "4".

let str = "1";
str = str.padStart(4,0);
console.log(str) // output is 0001

Alternatively, we might want to pad the end of our string and for this, we can use .padEnd().

Similar to the example above, we pass both the target length for the string and the string to pad the current string with to .padEnd(). In the below example I am padding the string “1” so that it has a length of “4”. This time however it will add the padding to the end.

let str = "1";
str = str.padEnd(4,0);
console.log(str) // result is 1000

2. Spread operator

The Spread operator isn’t the newest and shiniest of JavaScript features, arriving back in 2015 as part of the ES2015 specification however some of its use cases are often overlooked.

The first use case of the spread operator is to add the items from one array to another array. In the example below I have an array with 3 fruit however I want a second array which has the fourth fruit so I use the spread operator to copy the original fruit, and add the fourth fruit.

const arr1 = ["Apple", "Orange", "Pear"]
const arr2 = [...arr1, "Banana"]
console.log(arr2) // ["Apple", "Orange", "Pear", "Banana"]

We can do a similar thing with objects, however with the added benefit that we can override values in the original object.

const personA = {
  name: "Jonathan",
  age: 21,
}
const personB = {
  ...personA,
  name: 'Charlie'
}
console.log(personB) // {name: "Charlie", age: 21}

3. Rest parameter

Following on from the Spread operator, we have the Rest parameter, which is kind of like its opposite. The rest syntax collects multiple elements and “condenses” them into a single element.

A good use case for the rest parameter is to group the remaining elements of an array when it is being destructured. In the below example we have some fruits which we destructure so the apple is on its own, with the remaining fruit are left in a fruits array.

const [apple, ...fruits] = ["apple", "orange", "pear"];
console.log(apple); // output is "apple"
console.log(fruits); // output is ["orange", "pear"]

4. Array.prototype.includes

The next feature I want to talk about is Array.prototype.includes, this feature allows you to find if an array contains an item.

Prior to Array.prototype.includes, this would have been achieved by looping through the array and setting a variable to true if the item is found, see below:

const fruits = ["Dragonfruit", "Kiwi", "Mango", "Pear", "Starfruit"];
let found = false;
fruits.forEach(function(fruit) {
  if (fruit === 'Kiwi') {
    found = true;
  }
});
console.log(found); // Outputs `true`

Now, with Array.prototype.includes, we can reduce this significantly to the following.

const fruits = ["Dragonfruit", "Kiwi", "Mango", "Pear", "Starfruit"];
const found = fruits.includes("Kiwi");
console.log(found); // Outputs `true`

Note: as developers, we don’t need to worry about how this search is now implemented so the browsers have the opportunity to optimise this behaviour themselves.

5. Optional Chaining

The fifth and final feature I want to talk about is Optional Chaining.

Optional Chaining allows us to attempt to retrieve data nested deeply within an object without having to handle the situation where the data might not exist.

Lets take a look at the below example, in this we are defining Jonathan with some meta data.

const jonathan = {
  name: "Jonathan",
  meta: {
    age: 21
  }
}
const age = jonathan.meta.age;
const gender = jonathan.other.gender; // Will throw error
console.log(age);
console.log(gender);

If we run this code it results in an error as the other section of the object does not exist.

With optional chaining we can prevent this error by saying, don’t go further in the objects tree if a property does not exist. I updated the code below with optional chaining.

const jonathan = {
  name: "Jonathan",
  meta: {
    age: 21
  }
}
const age = jonathan?.meta?.age;
const gender = Jonathan?.other?.gender;
console.log(age); // outputs 21
console.log(gender); // outputs "undefined"

If we run this now, there will no longer be an error and the gender will simply be undefined which we can handle separately.

Wrapping up

JavaScript is rapidly advancing faster than it has ever before, with yearly updates the language keeping it fresh it's very easy to forget about all the cool things we can do with features that are even just a couple of years old.

In my own experience, writing this post actually led to me learning more about each of the features I talked about. Helping me to reinforce my own knowledge along the way.
Thank you for taking the time to read, if you want to read similar posts please follow me on Medium.

5 Tech Talks That Changed How I Approached Software Engineering

Jonathan Fielding — Tue, 02 Mar 2021 22:24:53 +0000

The first conference I attended as a web developer was the first jQuery UK conference back in 2012. After this, I was hooked and would regularly find myself attending conferences to help me to learn and grow.

I really love to hear from all the amazing speakers that conferences I have attended offer and learn about how they solve software engineering problems. This in turn has had an impact on my own approach to software engineering.

With it being a year since I was last able to attend an event in person I thought I would write a post about my favourite talks I have seen over the years, all of which I feel remain very relevant to this day.

5. "Getting more from Git" by Alice Bartlett

First up, I want to mention an awesome talk by Alice Bartlett on how to use Git more effectively.

Git is a tool we use every day as developers and the way in which we use it can have a huge impact on how our teams interact with our code. If we use it well it can streamline the way in which teams work, if we use it badly the history doesn't tell us anything and we are effectively using it as a shared file system.

In this talk, Alice Bartlett takes us through Git in more detail than we are normally used to and share her learnings of using it over the years.

4. "From Milliseconds to Millions" by Harry Roberts

Web performance is really important, and in this talk by Harry Roberts, he talks about how milliseconds in load time can impact both your users and your business significantly.

The thing that I really liked about the way in which Harry presented this talk is that it really helps the audience understand the benefits of investing in web performance.

3. "Bet you didn’t think your browser could do that" by Monica Dinculescu

In this talk, Monica helps us to reconsider the preconceptions we have of what can be achieved when building a static website.

As part of this, she demonstrates how browsers and technology have been evolving so there is a lot more you can build without resorting to building a serverside application.

2. "Building an interactive IoTshirt with MQTT" by Jo Franchetti

I love playing with the Internet of Things and home automation so while this talk didn't impact my day job it did play on my heartstrings of what I code in my spare time.

While demonstrating how to build her IoT t-shirt she does an awesome job of also demonstrating some cool tech along the way. This is probably what resulted in me going back to playing with JavaScript powering my Lego robots.

1. "You should use [insert library/framework], it’s the bestestest!" by Paul Lewis

Finally, we have this talk from Paul Lewis that I saw at ffconf all those years ago that busts myths around JavaScript Frameworks. It is by far my favourite talk I have ever seen.

It's worth noting that while some of the tooling he uses looks a bit different now, it still all remains very relevant. I recommend this talk to any engineer I manage as the talk to watch to make them think more about the tech decisions they make.

Wrapping Up

I picked these 5 talks as I found that they are still as relevant today as they were when I saw them. I hope you enjoyed them as much as I did.

As a final part, I want to thank all the amazing speakers I have seen speak at meetups and conferences over the years. Your teachings have really helped me grow as an engineer and I appreciate all the time you all put into writing the talks you gave.

If you are interested in reading more of my writing please follow me here on dev.to and on Twitter at http://twitter.com/jonthanfielding

Forem: Jonathan Fielding

Typesafe application configuration in TypeScript

Why typesafe configuration matters (and what can go wrong without it)

Why validating configuration at startup is a big deal

Practical wins of startup validation

Introducing zodified-config

How to use zodified-config (step-by-step)

1) Install

2) Define your schema

3) Define your configuration files

4) Validate at startup (fail fast)

5) Access values with type safety

A more realistic example

Conclusion

5 Habits of Great Software Engineers

1. Admit when you don’t know something

2. Learn from your team’s mistakes instead of assigning blame

3. Put your user’s needs above your own

4. Have strong opinions, but hold them weakly

5. Listen first, speak later

Conclusion

Starting a tech meet-up during a global pandemic

Figuring out what we wanted to create a meetup about

Naming our meetup

Creating the website

Finding Speakers

Promoting the meetup

The night of the event

In Summary

Getting past my insecurities by talking at tech events

Working with variables and conditionals in Go Lang

Getting to grips with variables

Introducing conditional logic to our application

Wrapping up

Writing your first `Hello World` in GoLang

Installing Go Lang

Install Homebrew

Configure your system paths

Install Go Lang using homebrew

Configuring Visual Studio Code

Writing your first hello world

What’s next?

5 Less Known JavaScript Features That You Should Know About

1. JavaScript string padding

2. Spread operator

3. Rest parameter

4. Array.prototype.includes

5. Optional Chaining

Wrapping up

5 Tech Talks That Changed How I Approached Software Engineering

5. "Getting more from Git" by Alice Bartlett

4. "From Milliseconds to Millions" by Harry Roberts

3. "Bet you didn’t think your browser could do that" by Monica Dinculescu

2. "Building an interactive IoTshirt with MQTT" by Jo Franchetti

1. "You should use [insert library/framework], it’s the bestestest!" by Paul Lewis

Wrapping Up

Writing your first `hello world`