DEV Community: Sam Williams

The Ultimate Guide to Migrating to the Cloud with Serverless

Sam Williams — Wed, 07 Aug 2019 07:00:31 +0000

A step by step guide to migrating an existing software product to run serverlessly in the cloud

You’ve got an app that you run and you’ve heard loads about serverless and the benefits. You may have even tried deploying some things with serverless but you want to move you whole app to serverless.

How do you do that? What bits do you do first? Do you have to do it all at the same time?

This article will guide you through the steps you can take to migrate your app or service to the cloud with Serverless.

1. Simple APIs

When you start the process of migrating your service to, it’s best to start with the low hanging fruit. This will get you some experience working with serverless and AWS but still provide value to the application.

Simple APIs are endpoints that don’t need to access your databases to perform their actions. This could be an API for sending emails, hitting external APIs and combining the data or for running some logic on the input.

A secondary advantage to creating these APIs is that it reduces the load on the existing servers. We, at MissionLabs, have found that this removal of functionality and complexity has allowed us to reduce the code on our servers by over 50%. This has resulted in much more readable code and quicker bug fixes.

How to migrate

Luckily, migrating simple APIs to the cloud using serverless is really easy with AWS Lambda and API Gateway.

AWS Lambda is a cloud function service where you can run code functions and only pay for when the function is running. You can write your code in Ruby, Python, Node, Java, Go or .Net and through the AWS SDK you can easily access other AWS services (such as email, sms, kinesis, databases).

To create an API using AWS Lambda and API Gateway you need to write a function that executes the logic. Then you need to export the function as exports.handler .

exports.handler = async (event, context) => { 
    // your function code goes here 
}

To deploy your code with an API using serverless, we need to add this new function to our serverless.yml file under function declaration. You need to define the location of the code as well as the methods and path for the API endpoint.

functions:    
myFirstApi:
    handler: src/myFirstApi/index.handler        
        events:            
        - http:
              path: getFromMyAPI                  
              method: GET
              cors: true

This will deploy your function code to ${random-api-subdomain}.execute-api.${region}.amazonaws.com/${stage}/getFromMyApi. Here is an example of an endpoint.

https://ic5hwq6j0a.execute-api.eu-west-1.amazonaws.com/live/item

If you want to create a more readable API address then you can use Route 53 to forward traffic so that your endpoint could be something like:

https://api.completecoding.io/v1/item (not active)

2. Databases and Connected APIs

Now that you’ve migrated some of your APIs, you’re familiar with writing Lambda functions and deploying them with Serverless.

The next step is to migrate your databases over to serverless and create the rest of your APIs.

2.1 Databases

Databases are obviously a massive part of any software product, but creating, managing and scaling them can be a pain. Provisioning shards and syncing instances can be difficult at the best of times.

With Serverless you can use DynamoDB, where scaling and performance are managed by AWS, leaving you to work on the valuable parts of the product.

How to migrate

Creating DynamoDB tables in serverless is relatively simple. All we need to do is create a new Resource and provide the table details.

Resources:  
    OrderTable:
    Type: AWS::DynamoDB::Table
        Properties:
        TableName: order-table
            AttributeDefinitions:
            - AttributeName: userID
                  AttributeType: S
                - AttributeName: orderId
                  AttributeType: S
            KeySchema:
            - AttributeName: userId
                  KeyType: HASH
                - AttributeName: orderId
                  KeyType: HASH

Things can get a little more complex when it comes to auto-scaling and secondary indexes.

To get auto-scaling added to our table, we have two options. We can either set up PayPerReqest billing or provision auto-scaling on the table.

PayPerRequest is better if you have more irregular traffic that comes in spikes and troughs. To provision is you can remove these lines:

ProvisionedThroughput:
    ReadCapacityUnits: 5
    WriteCapacityUnits: 5

and replace them with this line:

BillingMode: PAY\_PER\_REQUEST

The other option is to add auto-scaling. This wasn’t a feature when Dynamo was first released so the configuration is more complex. To reduce the complexity we can use the serverless-dynamodb-autoscaling plugin. To install this plugin run npm install serverless-dynamodb-autoscaling and then add some custom fields to our serverless.yml file.

plugins:  
    - serverless-dynamodb-autoscaling
custom:  
    capacities:    
        - table: order-table # DynamoDB Resource      
          read:
              minimum: 5 # Minimum read capacity
              maximum: 1000 # Maximum read capacity        
              usage: 0.75 # Targeted usage percentage      
          write:        
              minimum: 40 # Minimum write capacity
              maximum: 200 # Maximum write capacity
              usage: 0.5 # Targeted usage percentage

You should use whichever of these methods is most applicable to how each of your tables is used. There is no reason you can’t have some tables on PayPerRequest and others using normal auto-scaling.

There is also the issue of migrating all your data from your existing tables to your new dynamo tables. Luckily this is a brilliant article about how to complete these kinds of migrations, whether from MongoDB, Cassandra, mySQL or RDBMS.

2.2 Connected APIs

Now that we have our databases created, we should be able to convert most of our remaining APIs over to serverless. These might be user lookups, logins, product lookups, order status updates or any other kind of request that read or write to one of your tables.

How to migrate

The process to create these functions will be exactly the same as the process that you did in step 1, but now we have databases to access.

To access your data in DynamoDB, you can use the AWS SDK and the DynamoDB document client. This interface has the functionality to perform all the rest methods as well as a few extras such as scan, query, batchGet and batchWrite.

Whilst these sound perfect for baking into your Lambda code, I would suggest creating your own class that uses these methods. This is because the format of the request made to the document client is often overly complicated. Here’s my example of a simplified method for getting from Dynamo.

get(ID, table) {
    if (!table)
        throw 'table needed';
    if (typeof ID !== 'string')
        throw `ID was not string and was ${ID} on table ${table}`;
    return new Promise((resolve, reject) => {
        let params = {
            TableName: table,
            Key: {
                ID: ID,
            },
        };
        documentClient.get(params, function (err, data) {
            if (err) {
                console.log(`There was an error fetching the data for ID ${ID} on table ${table}`, err);
                return reject(err);
            }
            return resolve(data.Item);
        });
    });
}

If you now need to do a lookup in any of your APIs you can just use

let user = await DB.get('123-f342-3ca', 'user-table')

You can do the same for write, update, delete, scan and query.

With these methods, you should be able to port almost all your APIs over to serverless. This can be a large piece of work but there are a lot of benefits, including autoscaling, only pay for what you use, redundancy, separation of concerns and many more.

3. Storage

Cloud storage was the first service that was ever provided by AWS — Amazon S3. This service allows you to host file in the cloud, define the access policies, and easily use those files in other AWS services.

Items stored in S3 are put into buckets, which are isolated containers used to group items (similar to folders on your machine). You can store whatever files you like in S3, from product images to invoices, from data in JSON format to whole websites.

How to migrate

There are two stages to migrating to serverless cloud storage: creating the buckets and deploying the resources.

To create a bucket in serverless, you are defining a new resource. One thing to remember is that the bucket name must be globally unique. This means you can’t have the same bucket name on two accounts, or in two regions.

resources:
  Resources:
    UploadBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: my-bucket-name-is-unique

When you run sls deploy now, you'll find that you've created a bucket on your account. Now you can manually upload files into this bucket using the UI, or use it as a location to put uploaded files, but we're also going to learn how to sync up local files to the bucket.

To automatically upload files to our new bucket, we’re going to be using the serverless-s3-sync plugin. This plugin allows us to upload all the content of a folder on our computer to an S3 bucket as part of the deployment process.

To start using the plugin, we need to install it using npm install --save serverless-s3-sync and then adding the plugin to our serverless file. With out autoscaling DynamoDB plugin we'll now have this:

plugins:  
    - serverless-dynamodb-autoscaling
    - serverless-s3-sync

To configure the upload we need to add another field to our custom section as well.

custom:
  s3Sync:
    - bucketName: my-bucket-name-is-unique # required 
      bucketPrefix: assets/ # optional 
      localDir: dist/assets # required

The bucketName needs to match the name of the bucket you created. The localDir is the folder that you want to upload to the bucket. You can also use bucketPrefix if you want to add a prefix onto the start of the files (put them in a folder within the bucket).

With this all set up, running sls deploy will now create a new bucket and upload the files you have in dist/assets.

4. Website Hosting

So far you will have had to make quite a few URL changes to your website for all the API changes that you’ve already implemented. Now wouldn’t it be cool if you could also host that website entirely serverlessly and deploy it with all of your APIs, databases and everything else.

How to migrate

We’re going to host and deploy our website in a very similar way to the way that we are hosting our asset storage in the last section: serverless-s3-sync.

There are a few extra bits that we need to take care of when we’re hosting a website. To start out though, we’re still uploading a folder (containing our static site) to an S3 bucket. We can add a new bucket (MyWebsiteBucket) and new S3Sync setup. We set a custom variable called siteName and then use that to define the bucket name.

resources:
  Resources:
    UploadBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: my-bucket-name-is-unique
    MyWebsiteBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.siteName}

custom:
  s3Sync:
    - bucketName: my-bucket-name-is-unique 
      bucketPrefix: assets/
      localDir: dist/assets
    - bucketName: ${self:custom.siteName}  
      localDir: myWebsiteFolder
  siteName: serverlessfullstack.com

But this time we need to add a few more things onto our S3 bucket configuration. We need to set the access control and tell S3 that this is a website we’re hosting in the bucket.

    MyWebsiteBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.siteName}
        WebsiteConfiguration:
          IndexDocument: index.html
        AccessControl: PublicRead

We also need to create a policy document for the bucket in our resources

    WebsiteS3BucketPolicy:
      Type: AWS::S3::BucketPolicy
      Properties:
        Bucket:
          Ref: MyWebsiteBucket
        PolicyDocument:
          Statement:
            - Sid: PublicReadGetObject
              Effect: Allow
              Principal: "\*"
              Action:
              - s3:GetObject
              Resource:
              Fn::Join: ["", [
                  "arn:aws:s3:::",
                  {"Ref": "StaticSite"},
                  "/\*"
                ]]

When we now run sls deploy we'll get our content of our website uploaded to S3 and all the correct permissions set on the bucket.

You’ll now be able to view your site at http://serverlessfullstack.com.s3-website-us-east-1.amazonaws.com/

This is nice but it would be better if we were hosting on our own url, so that’s what we’ll do now. We need to create a DNS record that points the requested domain to our s3 bucket.

In Route 53, make sure you’ve set up your hosted zone name and then we can add the DNS record to the resources.

    DnsRecord:
        Type: 'AWS::Route53::RecordSet'
        Properties:
            AliasTarget:
                DNSName: ${self:custom.aliasDNSName}
                HostedZoneId: ${self:custom.aliasHostedZoneId}
            HostedZoneName: ${self:custom.siteName}.
            Name:
                Ref: MyWebsiteBucket
            Type: 'A'

With this we also need to set a few extra custom fields of hostedZoneName, aliasHostedZoneId and aliasDNSName.

custom:
    s3Sync:
        - bucketName: ${self:custom.siteName}
          localDir: myWebsiteFolder
    siteName: serverlessfullstack.com
    hostedZoneName: ${self:custom.siteName}
    aliasHostedZoneId: Z3AQBSTGFYJSTF # us-east-1
    aliasDNSName: s3-website-us-east-1.amazonaws.com

If you’ve set this up in a region that isn’t us-east-1 then you can find your aliasHostedZoneId here.

With this all set up you should now be able to run sls deploy again. This will add the DNS record to your account and now you can visit serverlessfullstack.com and see the live page hosted from S3.

If you’ve followed along, the only differences between our code should be: custom.siteName and your assets bucket name and you should have your own serverlessly hosted app!

If you’ve found this article useful and want to start working with Serverless then check out my FREE course on creating and deploying a Serverless API. You’ll learn to:

Create a user and get credentials on AWS and set up Serverless
Create a Lambda and API Endpoint to handle the API requests
Deploy, Test and Update your API

Originally published at https://completecoding.io on August 7, 2019.

What you need to become a full-stack serverless developer

Sam Williams — Tue, 16 Jul 2019 21:14:10 +0000

The 4 areas of development you need to know to call yourself a full-stack developer

Becoming a full-stack developer is the goal of a lot of developers. Being able to create a complete software product, getting to understand how the whole system work and the very nice wage increase(Over £5,500**) are all reasons people want to level up their skills and become a full-stack developer.

The issue is that learning all of the skills you need can take a lot of time. We’ll cover the 4 areas of development that you need to know and discuss the best way that you can learn them.

Front End /Website Hosting

Whenever you build any sort of application, it needs to have a front end. This is what your users will see and how they interact with your product.

This is often the first serverless skill that developers do, often without realising it. This is often through GitHub pages or a hosting service.

Whilst these services are great for quick and simple project hosting, you will need something more robust for larger and more technical serverless web hosting.

What you’ll need to be able to do

To be able to host the files required for a front end application.
To be able to serve these files on a given URL at scale
Point a registered domain name at these files

How to do this with Serverless?

Host the files on Amazon S3 (file storage system)
Create a CloudFront distribution to serve the files at scale
Use Route 53 to register a domain name and point it at the Cloudfront Distribution

Why Serverless is the best way to do this

S3, CloudFront and Route 53 all scale so you don’t have to work out (guess) how many visitors your site will get
You don’t need to set up or maintain the servers
You don’t need to set up DNS, nameservers or anything else to get the site up on your URL. Route 53 handles all of this.

Create an API

Every app needs APIs so that the front end can interact with the back end (databases, storage, email, etc.) which is where most of the power of a full-stack app comes from.

What you’ll need to be able to do

To be able to create restful API endpoints
To be able to access your databases
To be able to access other services (Storage, SMS, email, other APIs)
Protect your endpoints with API keys

How to do this?

Use API Gateway to build the API endpoints
Create Lambda functions to execute your logic and access other services (database access, SMS, email, etc.)
Create API keys that provide access to your API endpoints

Why Serverless is the best way to do this

Each endpoint is an isolated function, so if one breaks it doesn’t crash the others
You have very easy access to the rest of the serverless services through the aws-sdk, reducing code and speeding up development
You can easily create, limit and remove API keys to make sure that the right people are able to invoke your API endpoints.

Databases

All full-stack services need a way to store data about users, products, and everything else. This might be in a relational or non-relational database but you need to store the data somewhere organised.

What you’ll need to be able to do

Create a scalable non-relational or relational database
Access this database

How to do this?

Create a DynamoDB (non-relational) or Aurora (relational) database
Access your tables within your API Lambdas using the built-in tools within the AWS SDK

Why Serverless is the best way to do this

Your tables automatically scale and have built-in redundancy, removing the need to manage and sync multiple copies of databases
You can easily access the databases with the AWS SDK without having to expose it to the outside world.

Deployment and Maintainance

Once you’ve designed and built all of your systems, you need to deploy them into a production environment, maintain and upgrade them.

What you’ll need to be able to do

Deploy all of the resources we’ve talked about so far
Provide version-controlled configuration for all of the resources
Maintain and update the software and hardware that your systems are running on

How to do this?

Create the resources using the Serverless framework

Why Serverless is the best way to do this

When you create your serverless.yml file, you define all of the resources that you need to get your application running
This serverless.yml file can be version controlled to track changes over time
You can deploy your whole architecture in minutes with a single command
All of the underlying software and hardware is maintained, updated and upgraded by your service provider (AWS) so you don’t need to worry about it

If you’ve liked this article and want to start learning how you can become a full-stack developer, I have a free 3 part video course on how to build and deploy your own serverless API.

** London Front end developer (£42,994) vs London Fullstack Developer (48,767)

Building an API with Lambdas and API Gateway

Sam Williams — Wed, 18 Jul 2018 20:39:01 +0000

Want to access your database, control your system or execute some code from another website? An API can do all of this for you and they’re surprisingly easy to set up.

An API is a url that you can perform GET, PUT, POST and DELETE requests on to control another service. If you make one yourself then you can build these APIs to do whatever you want behind the scenes. Common uses are providing database control, performing actions on third party APIs (API-ception) or controlling another service.

Why Use an API

You may ask why we need an API when we can access the database directly or run the code on the website. There are a few massive advantages to APIs over running the code in your website.

Hide Your Access Keys and Tokens

This is possibly the most important reason to use an API. If your are accessing a database then you’re going to need the database details as well as user and access token/key.

If you access the database from the website then you’re going to have all of these details in the source code of your site. This is really bad practice as anyone can look into the source control and steal your details. This doesn’t sound too bad but what if these are your AWS or Google Cloud Compute credentials? They could then use these to run whatever they want on your account, leaving you with a huge bill.

Running these processes from behind an API means no one can see any of the private details so can’t steal them to use in their own projects. If you store your website code in Github or another public source control then it also means that they aren’t visible there either.

Run the Code Elsewhere

What if you aren’t using any other services and aren’t using any secret keys? If you are running a large or complex bit of code or if you don’t want anyone else reading your code and working out how it works then you can still use an API.

Control Who Has Access

Providing an API also allows you to restrict who is able to access the database or run the code. You can do this by requiring an API key. This key is used to identify the user making the request and then allowing or rejecting the request.

This can be used to allow only a few people to access the service, or even to create a tier system. This is how a lot of paid APIs work, giving everyone free but limited access and then allowing you to pay for access to superior parts of the service or just higher rate of requests.

Building the API

Now that we know some reasons why we might want to create an API, lets do just that. We’re going to use API Gateway and AWS Lambdas because its simpler than running a server. Make sure you have an AWS account and are logged in.

Setting up API Gateway

We can start by opening the API Gateway service and clicking Get Started*. On the next page we need to make sure that we’ve selected the New API option and then give our API a name.

When creating our first API we should select *New API* and then we can give this API a name and description and click *Create API*.

Clicking Create API will get us into the configuration page for your API. The first thing we need to do is to add a resource onto the API. Using resources allows us to group similar API calls together using nested slashes. We are going to create an API that we can use to recommendations on what to watch. Therefore we can have /tv-shows and /movies as two base methods.

Click the Actions dropdown and select Create Resource. Name your resources, making sure that they are both in the “/” path.

We want users to be able to go to /movies/horror or /tv-shows/comedy and we can do this by adding path parameters. These are variables that we can access inside the API. To create one of theses we need to set the resource to {resourceName} as shown below. This can be done for tv-shows and movies.

Now that we can length and genre we can create methods for getting and adding data to a table. Select one of the {genre} resources and click Actions then Create Method. This will create a small grey box below the resource which we can click. We are going to start with a GET request so select that and click the tick button.

This is where we get to decide how to handle the request. We are going to use AWS Lambdas but we need to create them before we can finish setting up the methods.

Creating the Lambdas

We are able to respond to these API requests using Lambdas which is great as they only run when we need them to. They are also really easy to create so that’s what we’ll do now.

In the Lambda console click Create function and then we can name our first API function movieAPI, set it to run Node 8.10 and Create new role from template(s). Name our new role tableAPI and add Simple Microservice permissions as the only template.

All code can be found at https://github.com/SamWSoftware/Projects/tree/master/movieAPI

Click Create function and we are sent into the Lambda window. Scroll down to the Function code section and we’ll change the code. The first thing we’re going to do is to check what request method was used.

exports.handler = async (event) => {
    console.log(event);
    if (event.httpMethod === 'PUT'){
        let response = putMovie(event)
        return done(response);
    } else if (event.httpMethod === 'GET'){
        let response = getMovie(event);
        return done(response);
    }
};

We’re going to start by writing the getMovie function. This function will start by getting the genre from the path parameters. This is where using path parameters can make this process easy.

const getMovie = event => {
    let genre = event.pathParameters.genre;
    return;
}

With the genre that the user requested we are going to get a recommended movie for them. I copied these from 25 Top Films From Each Genre and added them to an object with the genre as the key. We can then get the film by getting the value of the genre requested.

const movies = {
    action: 'Desperado (1995)',
    fantasy: 'Inception (2010)',
    ...
    horror: 'Black Swan (2010)'
}

const getMovie = event => {
    let genre = event.pathParameters.genre;
    return movies[genre];
}

This means that the title of the movie is being passed into the done function. This function is used as API Gateway expects the data to come back in a very specific format. This function turns a string into that required format.

const done = response => {
    return {
        statusCode: '200',
        body: JSON.stringify(response),
        headers: {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Methods': '\*',
            'Access-Control-Allow-Origin': '\*'
        }
    }
}

We can do a very similar thing for a tv-showsAPI function, reusing most of the code, just changing the function names and the movie suggestions to tv show.

Connecting the Lambdas to API Gateway

Back in API Gateway we can add our new Lambdas to the methods we created earlier. We need to make sure that Use Lambda Proxy integration is selected and we are pointing at the correct Lambda. Clicking Save will ask you for permissions to access this Lambda which we can give the OK.

Do this for the GET methods on both resources and we can start to test. Selecting the methods should now show a method execution diagram. This sounds complicated but the only bit we need is the _TEST _section.

Clicking TEST will open a new section where we can try out the API. There are lots of things you can set here but the only one we care about is the Path {genre}. We need to set this to the genre we’re requesting. Entering western as the genre and hitting the Test button gets a response like this:

We got our API working! Now we need to make sure that other people can access it. There are two steps to this.

We enable CORS — Select the {genre} resource and then click Actions and Enable CORS. Leave everything as defaults and when asked click Yes, replace existing values.
Deploy our API — Click on Actions and Deploy API. Set the deployment stage to [New Stage] and then give your stage a name like production or_ public._

Once your API has deployed you should get a URL like this. This is the base of your API. You can add /movies/western to access your API.

https://{uniqueCode}.execute-api.eu-west-1.amazonaws.com/production

That’s all for this article but in the next one we’ll connect this API to Dynamo tables and let users vote on their favourite movies in each genre.

If you’ve liked this article, make sure to hit that like button and follow me for the next API article.

Become a Developer and Get Your First Job Fast

Sam Williams — Fri, 13 Jul 2018 18:48:56 +0000

Ever thought about becoming a software developer or looking for a change of career? This article will give you a solid plan to get you started in software development and get your first job!

But why be a developer?

If your considering becoming a developer and but aren’t sure whether it’s a good idea, here are a few things to think about:

There is a huge demand for developers — at the time of writing, Indeed had 37,739 job adverts for ‘developer’ in the UK and 145,640 in the US. Those numbers are only going to increase as the U.S. Bureau of Labor Statistics estimates a 17% rise between 2014 and 2024.
The work can be very varied and interesting — as a developer you can work on a huge range of projects from e-commerce websites to computer games, from mobile apps to artificial intelligence. Almost all of the skills are transferable between each of these areas and this means you aren’t locked into a single job.
The work can be flexible — As most of your work is reading and writing code, all you need is a computer. This means it can be done from anywhere, at any time. There is an increasing number of remote developers who work from home or whilst travelling the world.

How to become a Developer

Being a developer is a skill and there are two major factors in developing a skill: effective practice and support from senior developers. You need to maximise both of these to help you become the best developer you can. There are are three good ways to make sure that you’re on a fast track to starting your developer career:

Coding Bootcamps — These are great because they are designed to take you from little or no coding experience to job ready in 3 months. This means lots of effective practice and tones of help from the developers running the bootcamp. The issues you might have with bootcamps are that they are usually 3 months of full time study and they can cost from £3000 ($4000) to £15,000 ($20,000). That’s a lot of money to spend especially since you’re not earning for those 3 months.
Get a Mentor — This is the perfect situation, you start coding and have a developer act as your mentor and tutor. They could be a friend, family member or just a developer that wants to help you out. You won’t get as much help as with a bootcamp but having someone to turn to when you hit a roadblock is really useful. Also having someone checking in on you and making sure that you’re putting the time in can help keep you on track. This sounds great but getting a mentor can be hard. Not everyone knows someone who works as a developer and it’s a lot of extra work for the mentor. If you know a developer, they may say no to being your mentor and you need to respect that.

Having a mentor can be brilliant

Get a Job as a Developer — This may seem like a cheat as you need to be able to code before you can get a job but I’ll explain later how to get to this point without a mentor or bootcamp. When you do get your first job you’ll suddenly have a huge advantage — you’ll be getting paid to practice coding whilst working with senior developers. What more could you want? Working as a developer will also expose you to the side of development that you’ll not see whilst you study — the business side. This is a massive part of development as there’s no point in making a product that no-one wants and dealing with customers is a skill that takes time to learn.

Starting a Plan

As not everyone can afford to go to a bootcamp or knows someone who’ll mentor them, I’ll give you a plan for how to get your first developer job. This is almost exactly how I went from an engineer to a developer in just 4 months.

Finding Your Job

To create a great plan you need to have a target that you are going to hit. Our target is to get a developer job as quickly as possible. The sooner you get your first job, the sooner you get the boost of practising code every day, having the support of senior developers and the bonus of getting paid.

There are a lot of ways to get into development, from data science to AI to game development but the sector that is the easiest to get into is web development. If you’ve got your heart set on something else remember that starting in web development doesn’t mean you’re locked into it. You’ll learn a huge amount that you’ll be able to use to transfer across into your preferred field.

When I searched for Junior Web Developer the first job listing I saw was for a Junior Front End Web Developer. The requirements are:

We can look through a few similar job adverts and find the requirements that appear often. These will likely be:

Front end knowledge: HTML, CSS and JavaScript
Ability to create responsive websites
A portfolio demonstrating your experience and skills
Understanding of version control

Other bonus skills might be:

Javascript libraries: jQuery, AJAX, Bootstrap
Debugging knowledge

Creating the Plan

Now that we know what we need to learn to meet the requirements we can create a plan for how to learn what we need to meet the requirements. You should try to follow this plan step by step as its going to be easier to learn the later sections if you know the earlier ones.

HTML and CSS

These are the building blocks of most websites today. You need to develop a strong understanding of these if you want a chance at getting a job. Luckily there are hundreds of free and paid resources out there which can help you learn and master these skills.

Free Code Camp is a website that teaches you everything to do with website development and it’s incredible. It takes you step by step through mini-lessons and its where I learnt HTML, CSS and JavaScript!

We’ll be starting with the Responsive Web Design Certification and the Basic HTML and HTML5 and Basic CSS sections. These sections introduce you to HTML and CSS and by the end, you’ll be creating forms and styling HTML with cascading variables.

An image that you’ll create in Basic CSS: Cascading CSS variables

To improve our CSS we’ll complete the Applied Visual Design section up to Create a More Complex Shape Using CSS and HTML, and then do all of Responsive Web Design and CSS Flexbox. We’re skipping some of the challenges and sections for now as our aim is to learn what we need and those other sections are great but not needed for now.

Now that we’ve learnt to use HTML and CSS to build and style a web page, we’re going to get some effective practice by completing the Responsive Web Design Projects. These projects will use everything that you’ve learnt so far to build 5 websites.

Version Control

Version control is a system where you save files and you can look back over time and see what you changed at what point. It’ll probably be used as every software company you ever work at and knowing the basics is really important.

To learn how to install Git, create a GitHub account and work with Git there is a great tutorial post An Intro to Git and GitHub. You could learn this before the HTML and CSS design projects and start using version control for these projects.

Now that you know how to use version control, try to do all of your projects in a local editor (like VS Code) and upload it to codepen when you’re finished. Working in a local editor is how you’ll be doing it at a job so it helps build your experience.

There are a lot of ways to use Git but you want to be able to create a GitHub repository, link that to a local folder, commit work that you’ve done and push that up to GitHub. Once you can do this you’ll be able to work effectively as part of a development team.

JavaScript

JavaScript is the language that powers 94.8% of websites on the internet. That's a lot of sites! JavaScript allows you to covert a static website into a fully interactive one.

To learn JavaScript we can do the Javascript Algorithms And Data Structures Certification on FreeCodeCamp. Because JavaScript is such a big part of modern websites, we’re going to complete the whole of this certification. This may seem like a lot of work but when you work as a web developer you’ll probably spend most of your time writing JavaScript so it's important to be good at it.

Building Your Portfolio

To show off what you can do you need to have a portfolio to show to possible employers. Luckily you will already have 10 projects — 5 HTML and CSS and 5 JavaScript. Make sure that you’ve got these all in version control and uploaded to GitHub so that other people (future employers) can have a look and see how well you work.

You can now go back to the portfolio site that you built and update it with all of your new projects. You can then use your new JavaScript skills to add interaction to the page. This could be a popup description when a user hovers over one of your projects, a slideshow of images or even a mini-game.

The Job Search

If you’ve done everything in the plan so far then you should meet the requirements of a lot of the junior web developer jobs. Now it’s time to apply for some jobs.

To apply for most jobs you need a cv so we can make a web developer cv. This should highlight your strengths without bringing added attention to how long you’ve been coding or the fact that you haven’t got any commercial experience.

Here’s the CV that I used to get my second job.

Which jobs to apply for is also important. This may seem wrong but you should apply to jobs where you can meet 80% of the requirements. You can always point out that as a self-taught developer you will likely pick up the other requirements faster than most other people.

Of course, this doesn’t mean you sound apply to every job where you meet the requirements. Only apply to jobs where you think the job is interesting and you would take if you got the offer.

Using Recruiters

Recruiters can be a powerful tool for getting your first job. They know what the company wants, often have jobs that aren’t on job boards and they want you to get the job… that’s how they get paid.

To make sure that your cv gets into the hands of as many recruiters as possible we need to apply to jobs on a range of sites. Start with the large sites like indeed and total jobs but also try to find the smaller job sites too.

A lot of developers talk about how awful recruiters are but we need to make sure to utilise them. Whenever you speak to a recruiter make sure to be respectful and polite. If they ask you about jobs that are way above or below your desired job, thank them and decline but remind them of the type of job you are looking for.

My first two jobs came from recruiters asking about a job that wasn’t suited to me, but they had another job that was perfect. Don’t give them such a hard time.

Continued Improvement

You probably won’t get an interview and job offer in the first week of applying for jobs. You might not get an interview in the first month but this gives us time to improve.

Now that we’ve met the basic requirements we can start adding more nice to haves into our toolkit. Now is the time to add a new tool to your tool chest. Adding more skills to your belt will make employers more likely to want you and increase your chances to get an interview. Here are some skills to learn:

Learn a library

There are JavaScript libraries out there which can make your life much easier. The most famous library is jQuery which helps you with DOM manipulation, object and array functions and much more.

I would recommend learning to use jQuery because it’s a great introduction to using libraries in JavaScript. There are loads of courses and tutorials for learning jQuery but I still love the FreeCodeCamp lesson.

Completing the HTML and CSS Lessons

Go back to the HTML and CSS lessons from FreeCodeCamp and complete the rest of the lessons in Applied Visual Design, Applied Accessibility and CSS Grid.

Advance Your CSS (optional)

If you like the design and style side of front end development then there’s a cool Daily CSS course that gets you to make images with just CSS and HTML. These images could be a great thing to talk about in an interview.

Learn how JavaScript Works

Being able to use JavaScript is great but understanding how it works can help you become a much better developer. It allows you to write the best possible code as you know why and how that code fixes the problem.

To get this deeper understanding of JavaScript I highly recommend the You Don’t Know JS book series. The first two books are great for understanding the fundamentals of JavaScript. Understanding this gives you a great foundation on which you can become an even better developer. They can be accessed for FREE online or bought in hard copy.

Build Projects

Another way to improve your skills is to build projects. These can be anything but your aim is to get practice using the tools that you are less experienced with. Not great with arrays, create a shopping list app. A bit iffy on styling, try to make an exact copy of a real website.

These projects should be improving your skills so if it's too easy or too difficult, stop and start a project that is at a better level.

Sometimes when you build a project you might need to learn a completely new skill and learning as you go can be a great way for some people to learn.

Interviews

After having applied for a bunch of jobs and continued to improve your skills you will hopefully be asked in an interview. This is your time to shine. There are loads of articles about how to approach the interview process so I won’t go into too much detail but will highlight what this article says:

Know your CV
Know about the company
Practice your skills
Be early, polite and confident
Ask Questions
Follow up after the interview

If you follow all of this advice then you’ll have a good chance of getting an offer. Amazing! If you don’t get an offer then make sure to ask for feedback and use that to be better in your next interview.

Summary

If you want to become a developer you should be aiming to get a junior web developer job ASAP so that you get the experience and support from senior developers. To get this kind of job you need to: learn HTML, CSS and JavaScript and build a portfolio of small projects. Once you’ve done this you can start applying to jobs.

Prepare well for your interviews and continue to build new skill whilst you wait for that offer.

Thanks for following my guide to becoming a developer and getting your first job. If you enjoyed it then give it a like and follow me for more developer tips and tricks!

Amazon Lex — Hacking a Postcode Slot Type

Sam Williams — Sun, 03 Jun 2018 08:07:26 +0000

When you create an Amazon Lex chatbot you use slots to gather bits of information from the user. To ensure that the slots are capturing the right types of information, you have to give a Slot type to each of the slots.

Amazon provides a list of pre-made slot types that cover a lot of things such as numbers, names, cities and lots of other categories. This is great and I’ve found that about half of my slots can be set to an Amazon slot type.

If the slot type you need isn’t a default Amazon type then they let you build your own slot type. This is great as it theoretically allows for infinitely unique slot types that will match your user’s inputs perfectly.

Creating a custom slot type

There are 2 types of custom slot type you can create: Expanded Values and Slot values and Synonyms. Expanded values is where you provide some sample values and Amazon these as training data to learn to identify if the value is the correct slot type. Slot values and synonyms allows you to hard code slot values and then provide a list of synonyms that a use might say.

Dealing with UK Postcodes

Recently we created a bot that needed to ask for a user’s postcode. Amazon doesn’t have a Postcode slot type so we needed to create a custom one. For this we would have to use Expanded values as we couldn’t just list every UK postcode.

First Try

The first attempt at a postcode type involved populating the list of example values with about 8 postcodes. I would have expected Lex to have learnt from those example postcodes but this results in some strange things happening. Sometimes it rejects about 1/3 of genuine postcodes, other times it lets almost anything through.

The whole point in slot types is to make sure that if the user types a valid value it will go though and incorrect values will be blocked. This method wasn’t good enough.

Try 2

When creating the Expanded values slot type it lets you know that it uses the example values as training data. To improve the accuracy of the validator we should try adding more training data. This way it has more values to train and test against.

I downloaded a list of 999 real uk postcodes and wrote a script to build the slot type json file. I uploaded this to Lex and tested it out.

The fact that with 999 new postcodes it only took a few seconds to build implies that it isn’t running a machine learning training cycle. It must be using another method of matching the values.

When testing this out, it had some of the same problems as the first version. Whilst it did accept more real postcodes and reject the more insane values, it did still reject some real postcodes and accept some random values.

Try 3 — the hacking begins

So having tried to get it working properly using Amazon’s methods we resorted to working around the system. We knew that there are some great rejex functions for postcode validation so we decided to give this a go.

We needed to design a new slot type that allowed everything through so we could pass it through to our own validation Lambda to perform the rejex. We copied our first slot type and then started adding random values that were between 3 and 8 characters long and included numbers, upper and lowe case letters, and spaces.

We added a initialisation and validation Lambda that took the value of the postcode slot and ran it through the rejex. If it succeeded then we let Lex carry on, else we re-elicited the postcode slot.

This worked much better than either of the previous methods, filtering out all of the nonsense values but still sometimes blocking valid postcodes before they even got through to the rejex validation.

4th times the charm???

I moved onto another part of the project whilst one of my colleagues started researching how other people dealt with similar issues. We couldn’t be the only ones hitting this problem.

Luckily we weren’t. Although a lot of the questions were about US postcode, there were some useful bits of information. The most important one was to try out the Music and Musician slot types. People suggested that they let any value through.

With this nugget of knowledge we created a new test for music and musician to see if the rumours were true.

Music was pretty good, letting through all postcodes with XXX XXX format but blocking all XXXX XXX postcodes. Musician is where we struck gold. This slot type appears to let absolutely anything through. When I say anything I mean anything, whether it was cat, dog or the lyrics to fresh prince.

This slot type has allowed our rejex to deal with whatever values users give it. You can use a validation Lambda to catch it when they say it or just run some validation checks at the start of your fulfilment Lambda.

Summary

Using a few values to create a slot type wasn’t very good
Using hundreds was better but not great
Creating a slot type to capture anything was ok
Using the Musician slot type lets anything through

Using this knowledge we can now create rejex slots validation, or any type of validation you want.

If you think you’ll use this in one of your chatbots or simply enjoyed seeing people hacking their way around Amazon then give this a like and follow me for more chatbot tips and tricks.

AWS Lambda — The Top 3 Ways to Work

Sam Williams — Sun, 15 Apr 2018 09:04:40 +0000

AWS Lambdas are incredible! They’re functions that are hosted on Amazon Web Services that can be triggered in a load of ways.

One of the bests part is that you only pay for the time the lambda is running. Got something that only runs once an hour and only takes 2 seconds? You’ll only be charged for 48 seconds a day! That’s insane compared to running a 24/7 ec2 or your own private server.

Today we’ll create a lambda and then look at the three best ways to work with the code.

Creating a Lambda

Once you’ve got your AWS account set up there are a few ways to create a new lambda. For the first Lambda we’re going to be using the AWS Console.

AWS Console

The easiest way to create your first lambda is to create it in the AWS Console. You can find Lambda under Services which takes you to the Lambda console.

This is what you’ll see if this is your first Lambda. Click that Create a function button to start setting up your first function.

You’ll end up on the setup page where you configure some of the function. You can create a Lambda from Blueprints or Serverless Application Repos but for this we’ll Author from scratch.

Enter the name for your function (this must be unique to your user or sub-account), choose your Runtime (We’ll use Node.js 8.10), and select a role.

You’ll have to create a new role if you don’t already have one. Create one from template and you can leave Policy templates blank.

Writing Your Lambda Code

One of the big advantages with Lambdas is that you can choose how you write and edit them. There are three main ways to do so: in Lambda Console, in Cloud9, and on your local machine. I’m going to cover all three and discuss advantages and disadvantages to them.

Lambda Console

This is the screen you got sent to when you created the function. You’ll see that there is a lot of stuff going on. The bit that we care about fro now is the Function code section, about half way down

In here we have a basic editor. I believe it’s based on the Cloud 9 IDE and works pretty damn well for simple Lambdas. You can see below that the handler is an async function because I chose to use Node 8.10. If you prefer callbacks then Node 6.10 is the runtime for you.

The advantages

It’s a decent editor.
You can access it from any computer through your AWS console.

The Disadvantages

It doesn’t seem to be 100% stable. Sometimes it doesn’t let you save so you have to copy all of your work to local file, reload the page and copy your work back. I hope that this gets fixed soon!
It doesn’t have a terminal. This means that you can install packages using NPM using this method alone.

Cloud 9 Editor

Amazon recently bought out Cloud 9, an online development platform. It seems to run a very basic version of Ubuntu that is integrated with the rest of the AWS platform.

Search for Cloud 9 in the console, go to the page and select Create environment. From here you give your environment a name and go to the next step.

Here you get to choose what you want to run this environment on. The great thing is that t2.micro is Free-tier eligible so you can use this method without getting charged anything if you’re on the free tier. I’ve never needed anything more powerful than a t2.micro.

Continue on from here and you’ll end up in your new cloud 9 environment!

The cool thing about this is that you have access to all of your Lambdas from inside your environment. Click AWS Resources then under Remote Functions you’ll find all of your functions. Click on the Lambda you want to edit and then hit the download button above to import it into your environment.

Once that’s done, it’ll be just like you’re working on it locally.

Once you’re finished, just select the function you’ve been working on from the local list and hit the upload button. Within a few seconds it’ll be live with all your changes.

The Advantages

Again, this is all remote so you don’t need to worry about forgetting to commit your work or save it to a memory stick if you work on multiple machines.
Getting your functions and uploading them is super easy. This is by far the best bit about this method.
You now have an integrated terminal, allowing you to install npm packages and do everything else you want to do using the terminal.

The Disadvantages

It still has the same stability issues that the Lambda editor has. I’ve had multiple occasions where I’ve tried to save couldn’t, having to copy to local, refresh and recopy to Cloud 9. After a few times, I gave up and moved to local editing.

Local Editing

I’m going to do this one a bit differently, I’ll list the advantages and disadvantages then show you how to make it so much better.

The Advantages

Local editing is how most developers will work, we can use our favourite IDE, extensions and colour schemes.
It’s stable (as long as your computer is).

The Disadvantages

There’s no fancy button to get and upload your work to AWS.
Your work is local, so multiple users or just working on multiple devices is more complex.

Local Editing Tricks

Because the advantages for this method are so appealing (or the other methods’ disadvantages are so appalling) we’re going to utilise some basic workarounds. It should take about 15 minutes to set up everything we need!

AWS CLI

To upload our work to AWS we can use the AWS CLI. This allows us to upload a zip file to our AWS account that populates a given Lambda.

To do this we first need to setup AWS CLI. You can install it usingthis tutorialor by typing npm install -g aws-cli into your terminal. Now we need to set up a user for our CLI to log in as.

In IAM Management, click Add User, give the user a name and select Programmatic Access. This will allow us to act as the user remotely.

In the permissions screen, choose to Attach existing policies directly and select AdministatorAccess. This will let you do whatever you want through your CLI. You can set stricter policies on this user if you want, or this is for another person to access.

There’s another screen before you end up being show your access key. Copy your access key and open a terminal. Run the command aws configure which will ask you for 4 things.

AWS Access Key ID [None]: "Your Access Key ID" AWS Secret Access Key [None]: "Your Secret Access Key" Default region name [eu-west-1]: Default output format [json]:

The first two are found on the last page of the user creation and the next two can be left as default or changed to whatever you want.

Using the AWS CLI

Now that we’ve got the CLI set up, we can use it to make our lives so much easier. If you have a folder with a lambda function in then we can run a few simple commands to upload it.

cd MyLambdaFunction rm index.zip zip –X –r ./index.zip \* aws lambda update-function-code --function-name MyLambdaFunction --zip-file fileb://index.zip cd ..

AWS CLI Build Script

This is great but typing this all out every time you want to upload a new lambda version would become tiresome. So we’re going to use a build script.

For this exact script to work, you need to have a folder structure like this. Each lambda has a folder with the relevant files and a region.txt file.

This script not only runs the basic AWS CLI commands, but it also does extra checks, runs npm install and echos out details about the progress.

This may look like a complex script but it can be easy broken down. The first 32 lines are moving into the lambda folder, running npm install, and checking that AWS CLI is installed. Line 38 is zipping the folder, except from certain files, and line 42 is uploading the zip file.

Now all you need to do is to navigate to the main lambdas folder and run

./build.sh example-lambda

This script could be modified and expanded to include region specific uploading, batch uploading multiple lambdas or Git integration.

Git

Most people reading this will use git on a daily basis. There’s a reason for that — it makes life simpler.

Having a git repository for all of your lambdas is a great way to work with teams of developers or by yourself on multiple machines.

Summary

There are three common ways to edit Lambdas: in the Lambda console, in Cloud 9, and locally.

There are advantages and disadvantages to all three methods, but I think the best choice is to write function locally and deploy them using a deployment script.

If you found this useful then give it some claps and follow me for more AWS tutorials and developer articles!

NEXT → Say Hello to Your Own Amazon Lex Chat Bot

I Burnt Out — Forcing Myself to Work at 100% All the Time

Sam Williams — Sat, 07 Apr 2018 10:24:58 +0000

I’ve written about how I utilise my mornings to do things like Doubling my salary in 5 months, and I wanted to carry on that level of progress. After a month of trying to force it, I was frustrated, exhausted and bored.

What I was doing

I was getting up every morning at 6am with the aim to do 1.5 hours of work before starting my daily job. I would sit down and try to do anything that I classed as making progress.

Why This Failed

There are load of reasons that this failed but here are the main three:

1. I changed my routine

With starting a new job, my routine changed slightly but the biggest change came when I broke my phone. This meant that I no longer had access to Blinkist to listen to a book whilst I had breakfast. To fill the time I turned to Youtube.

Youtube has a lot of amazing content, but it also has an insane amount of crap. Unfortunately that crap often has a great title and a eye catching thumbnail. I ended up getting distracted, watching useless video after useless video and wasting a lot of my mornings.

Because I changed my routine, I often forgot to do my daily bullet journal and weekly reviews. This meant I had no real plan for how to use my 1.5 hours and wasn’t catching my wasted time in my weekly reviews.

2. I had no direction

When I was trying to get y first developer job, I had a very clear goal with defined milestones.

When I was trying to double my salary, I had a very clear goal with defined milestones.

Currently I had no goal and no milestones. With no goal to achieve, I wasn’t delaying any work by watching another Youtube video.

3. I was forcing it

The days that I managed to actually get some work done, I was trying really hard to do really well. I had willpowered my way off Youtube and needed to make up for the days I’d wasted.

I was doing things just so I could feel like I was accomplishing something, not because I wanted to or because it was beneficial.

The Result

After a month of this, I was tired and frustrated. Tired from using my willpower to get some work done and frustrated that the work was crap and that I’d made almost no progress.

What I Did to Turn Things Around

I Chilled out

I decided that forcing progress wasn’t working and I deserved some time off. I still woke up at 6am but I did what I wanted. Watch a few episodes of Brooklyn Nine Nine? Why not! Have a session on Rocket League, Skyrim, or any other game that took my fancy? Sounds Fun! Snooze the alarm until 8am? Sometimes.

Set New Goals

After about 2 weeks of more relaxed mornings, I felt ready to start some work again. This time I knew I had to have a goal, so I sat down and came up with a new main goal.

For me this is to complete the Fast AI Deep Learning course. AI and deep learning is something that has always interested me, it’s a great skill for a developer to have, and there is a possible project at my job where I could use it.

As well as my main goal, I decided that I want to become more consistent with my articles, so I’ve decided to write one article a week. This is deliberately low so it’s easier for me to achieve, keeping motivation levels high. If I write more, even better!

Having a goal means that I know what I’m going to be doing when I get up in the morning, and more importantly, I want to be doing that. This should help me close the Youtube tab and start making progress again.

Restart Journal-ling

This goes along well with setting a new goal. My journal used to be amazing to making sure I knew what I was working on that week and that day. It helped me track progress and see how I was using my time.

It often catches weeks where you spend too much time on one thing as well as keeping you more organised in general.

I got a new phone

This may seem silly but it means that I can listen to Blinkist again, stripping Youtube from my mornings, removing a massive distraction opportunity.

The Aim

These changes will hopefully reignite my passion for progress and reduce the willpower I was using to force myself into work.

I’ll have better organisation of my life and hope to grow personally and professionally.

If you liked this article, please mash that clap button and follow me for more articles on tech and productivity.

AI is Taking Peoples’ Jobs — Are Developers Next?

Sam Williams — Tue, 27 Mar 2018 13:10:40 +0000

I was recently asked to comment on whether there was any point becoming a developer because AI might be doing it very soon.

Here is the quote I was asked to comment on:

Developing websites especially ones with static content or just plain content management will no longer be a relevant skill in next few years.

Developing website will boil down to choosing a color palette, deciding your content and then just letting a website creating tool to do the rest for you. Most of it has been automated already. Even things like deploying scalable web services and APIs have become easier owing to cloud computing platforms provided by Amazon, Google, Microsoft and others.

I’ve also been reading more articles on AI and a few have rekindled my interest in the conversation. One of the best articles I’ve read asks should developers should care that their AI products could take away peoples’ jobs.

AI Taking Jobs

There is no doubt that AI is now doing things that used to be done by people. The most obvious is chatbots taking away customer service jobs, but there are loads of other examples: facial recognition passport gates, automatic logistics planning, even art.

Tech taking jobs is normal

Throughout history technology has been taking peoples’ jobs. The horse drawn plough took away the jobs of field diggers, these horse farriers lost their jobs because of tractors and recently production line workers have been loosing their jobs to robotic workers.

AI taking peoples’ jobs is just the next step in the continual process.

Will AI Take Developer Jobs

Yes, and it’s already started.

The quote talks about jobs writing HTML and CSS and I thing that a lot of them are already disappearing. Services like SquareSpace allow you to design and build a website without any coding. You can have it exactly as you like without ever having to employ a developer. This isn’t even AI, this is just well designed software.

AI has also been used in this field. There havebeen projectsto get AI to build a website from a PhotoShop design. It used image analysis and feature detection to build up a full website from mockups.

What about more technical jobs?

Technical jobs, like dynamic websites, creating software or data science, seem safe for now but they will definitely start seeing AI in the workplace more and more.

I don’t believe that AI will be taking jobs away, but giving developers an incredibly powerful tool to create better products. There are loads of places that I’d love to use AI in my work life, automating the boring processes.

I don’t think it’ll be long before we have template compilers that take simple commands and compile them into whatever language you want. This will be such a powerful tool as it could eliminate the need for generic boilerplate code, cut down the repetitive typing tasks and give the developers time to do what we do best — solve problems.

I expect there are loads of use cases in development that would make life so much better. If you can think of any great examples let me know in the comments.

One thing that AI is a very long from being competent at is the soft skills. Creating a relationship with your customers, effectively motivating and working with a team, and understanding human wants and needs are all skills that turn a good developer into a great one.

What about in 100 years?

In 100 years, I have no doubt that a lot of current developer jobs will become obsolete. AI will probably be able to create incredibly complex software from a description of it’s features. There may also be sentient AI which can figure out whatever it is you want and do it, no more need for unique software packages.

There will also be loads of new jobs to replace our current ones. No one 100 years ago would have thought that web designer, JavaScript developer or machine learning developer would have been jobs. In 100 years there are going to be new jobs we can’t even imagine.

You could be an alien designer — designing synthetic lifeforms to make distant planets habitable for humans, or a warpdrive operator.

So is it worth becoming a developer now?

Yes, if you want to become a developer I think it is a great career choice.

You may start learning to do things that can already be done by AI but soon you’ll be working on projects that AI is not yet able to do. Demand for developers is set to massively increase over the next decade and the number of areas you can work in is massive.

You’ll also be in an industry where progression is always happening. You can continually grow your skills, adopt AI to make your life easier and more productive, and learn about the bleeding edge of technology.

Thanks for reading this article! If you liked it, give it a clap. If you loved it, follow me to get more tech content every week.

How I Doubled my Salary in 5 Months and Got an Amazing Job

Sam Williams — Sun, 11 Mar 2018 19:46:52 +0000

It certainly wasn’t easy but I managed to go from a low paid junior dev to a well paid developer in 5 months and even had fun on the way. This is how I did it.

6 months ago I quit my job as a junior JavaScript developer and travelled around south east Asia for 5 months. Within a week of getting back to the UK, I had 3 job offers and had accepted an offer of almost double my previous salary.

The Aim

I was planning to travel around south east Asia for 3–6 months and I knew that I wanted get a better job when I returned. My junior JavaScript job had shown me three things:

I loved to code, not only as a hobby but as a job.
I enjoyed back end development work as it was removed from the css and visual design of front end development work.
I didn’t like Angular that much.

With this knowledge, I set about creating a target for where I wanted to be by the time I finished travelling and what I needed to learn to get to that point.

My target was to be a Mid level Full stack developer.

The Recon

To become the mid level full stack developer I wanted to be. To find out where I needed to improve, I looked for jobs that I would want to apply for and saw what they were requiring in a candidate and what they said was desirable.

Through this I found a list of things that most of the jobs required:

Strong understanding of JavaScript
At least one framework (usually React or Angular)
Ability to create a REST API (usually express)
Knowledge of one or more database (usually MongoDB or SQL)

Formulating the Plan

With this information, I knew that I needed to up my game in a few key areas:

I needed to finish reading You Don’t Know JS. This book series helped me really understand the basics of JavaScript, so I reasoned that it would be great for learning the more advanced stuff.
I needed to become very good at one front end framework. I looked into Angular, Vue and React and decided on React. I’d done a bit of React before and liked it, I wasn’t a fan of Angular, and Vue wasn’t requested in many job adverts.
Although I could just about create an express API from scratch, I wasn’t very confident and could only do the basics. I needed to up my game across the board with this, especially if I was wanting to have a job that prioritised back end work.
I could either stick with relational databases (postgreSQL) or learn a new DB. I decided that I would go for learning MongoDB as it was massively popular and added NoSQL databases to my CV.

I wasn’t sure how long I’d be travelling for so decided to plan my learning out like this:

Learn React (and Redux) whilst reading You Don’t Know JavaScript.
Get much better at express and learn MongoDB.
Make something with the skills I’d learnt.
Learn other things.

I did this for a very good reason. If I ended my travels after 3 months and had completed 1 but was still part way through 2, then I would still be able to apply for mid level developer jobs, they’d just be limited to mainly front end jobs.

If I did back end learning first, after 3 months I still wouldn’t be very confident with any front end framework and that would probably be a sticking point for every mid level job. I could try to apply for a back end only developer role but they all seemed to want much more experience than I had.

Learn React and Redux, and read You Don’t Know JS

I’d done a little bit of React before, using Youtube videos and normal web tutorials but this time I wanted to make sure that I was learning it properly. This led me to getting the React JS and Redux: Mastering Web App course from Udemy.

This course was brilliant, the little bit of experience I had with React helped a lot but I had no experience with Redux. By the end of this course, I felt like I could have built a pretty complex website and was confident with both the syntax and formats of React and the data control of Redux.

This course took my about 2 weeks to complete, but I was working on it for an hour or 2 once or twice a week. I was on holiday in Asia so this wasn’t my main priority.

As well as working on the course when I had my laptop, I read my way through the last few books in the You Don’t Know JS series. I stored the online github version on my phone and read it whilst I was resting between climbs.

Having got some real world experience, I understood a lot more than the last time I tried to read these books. Things like Promises are really hard to understand if you’ve never used them.

Get much better at express and learn MongoDB

Now I felt comfortable creating front ends it was time to work on my back end skills.

Again I decided to do a Udemy course. I found that because they’re complete packages, it progresses nicely and tends to cover the whole process. Of course you can learn all of the same stuff for free on Youtube or other online tutorials but they never seem to cover a whole topic quite as well.

The next question was which course to do. There are free ones and paid ones, short ones and long ones.

I decided to invest in myself and buy a course ($10 is a tiny investment for such a lot of information) and I managed to narrow it down to about 3 courses. They varied in length between 7 hours and 25.5 hours.

I was tempted by the 7 hour course, I could get it done in a week or two whilst still enjoying my holiday. The 25 hour course would obviously take much longer but seemed to cover more topics. By this point in the trip, I’d decided that I was going to be travelling for as long as by bank balance allowed so I went with the 25 hour course.

Node with React: Fullstack Web Development

I’ve actually done a full review of this course here and it’s a great course.

Having done the React and Redux course before, the React stuff was being repeated. So you don’t waste time, you can just skip videos you already know or put the video on 2x speed and “skim watch” for a refresher or to check for any bits of useful advice.

The back end stuff is where this course excels. It covers a huge range of topics including: oAuth, email handling, payments, API key handling, MongoDB, mongoose and advanced deployment.

The reason that this course is so long is that it covers so many topics in such great detail. This is good and bad, but I ended up watching most of the videos at 1.5x speed and pausing it when I needed to.

This course obviously took longer than the first, and I managed to finish it in about 1.5 months.

I started Writing

At some point, whilst staying in China, I decided to write an article about how awful trying to do development was in China. It got accepted into the Free Code Camp publication, and now has 1.6K reads and 791 claps. I was amazed that people read what I wrote and liked it.

The Stats for the first 30 days of my article. Can you work out when it got put on Free Code Camp?

I decided that I was going to try to write more articles about what I was doing and cool things I find. This also ended up giving me a great talking point when it came to interviews.

Writing a blog is also a great way to log your progress and allows you to see how you’ve progressed.

Make something with the skills I’d learnt

Now I had all the tools I needed, I wanted to create something with them. I was 3.5 months into my travels and expected that I would be able to travel for another 1–3 months. This meant that I might need to start thinking about jobs soon if I wanted to start ASAP when I got back.

To apply for jobs I needed to update my CV and portfolio. This gave me a great chance to use what I’d learnt to build a new portfolio using Node and React.

This is exactly what I did. This is the result. As I said before, I’m not a designer, but it works well. I even used a wordpress API to host blog posts on the page.

I knew that the design was awful so I posted it in a web design review subredit. I got lots of good advice, most of which revolved around spending the next few months researching and learning the basics of web design.

One bit of advice I did take was to utilise the bootstraps that existed. This resulted in a completely new website, using none of the skills I’d used before, but it does look less garish.

Applying for Jobs

The next place I visited was a remote climbing area in Laos. This meant that there was minimal access to power and no wifi. This lead me to leave my laptop in Bangkok for the 2 weeks I was in Laos.

When I got to the campsite in Laos, I found out that they have 4G! I bought a local sim card (£2 for 1.5GB and then 89p for each extra GB) and had decent internet access. By this point I knew that I had 2 weeks in Laos, then about 4 weeks in China again before heading home. Time to get applying for job.

Progress

Over the course of the next 1.5 months I applied to well over 50 jobs, had email and LinkedIn conversations with about 25 people and managed to secure 5 job interviews for the week after I got back. Most of my interactions were by email but if someone wanted to call directly then I tried my best to accommodate that (I was 8 hours ahead).

I think that having an actual conversation is a great way to improve the relationship between you and the other person, increasing the chances that they’ll invite you to interview or recommend you for a job.

If you don’t feel comfortable having a call or Skype with people then you can stick to emails, but I think you’re missing out on improving your chances.

Build More Things

One of the interviews asked me to prototype what I would do for a company with an awful website and minimal customer service. This was cool as it pushed me into learning about prototyping. I wrote a series of articles on how I prototyped and fleshed out the website. You can see the website here read my articles here.

The last thing I did on this was to create a chat bot for returning orders. I had to learn about the workings of chat bots and it took me about a week to get a decent working version. This was a massive factor in me getting the job.

Interviews

Now that I had these 5 interviews lined up, I had to convert them to job offers.

Preparation

I’ve written articles about preparing for a JavaScript interview and mastering the interview process. I made sure I ticked every box.

I knew all the points I was wanting to emphasise, how to answer the questions about my weaknesses and what each company did.

The Interviews

I’ve always been good at interviews, being naturally introverted I’ve had to teach myself to act more extrovert and engage with the people interviewing me. If you find yourself acting shy and reserved in interviews, I recommend find a book on emotional intelligence and ways to act more confident.

I had tech tests at 3/4 of the interviews (having done the other two online) and my preparation paid off. There were small slip ups but I talked through my thinking and finished all of the tasks well.

The Offers and Negotiating

From my first 3 interviews, I had 2 offers. After the fourth interview I knew that they weren’t the company for me so let them know I wouldn’t be considering an offer from them. If you are ever in a similar situation, try not to lead them on if you know you’re not going to accept an offer from them.

Now I had offers from two companies who were very keen to hire me. It was time to negotiate. I’ve never been great at negotiating or asking for more but I read a few articles and went for it.

You might think to yourself: “well, I don’t want to set high expectations, and the offer is already generous, so I ought to just take it.”

No. Negotiate.

Or maybe: “I don’t want to start off on the wrong foot and look greedy with my future employer.”

No. Negotiate.

“But this company is small and — “

No. Shut up. Negotiate.

From Ten Rules of Negotiating a Job Offer. I recommend reading it if you’re applying for jobs.

I definitely didn’t do this perfectly (or even that well) but I did do a few things that strengthened my hand. I had two equal offers but I had a preference for one company. I wrote myself a little script and (after some breathing exercises to calm myself) I called the director of my favoured company.

Hi Dave. I’m calling to give you an update on where I’m at. Thank you for giving me an offer, I’m glad you thought that I would be a a great fit in the company too.

I’ve had another really strong offer and I’ll be making my decision this weekend, letting you know by Monday at 12pm.

There is one thing that could really strengthen the offer. I’m going to be relocating to wherever I take a job and some assistance with the relocation costs would be amazing.

It didn’t quite end up going exactly like that but it helped a lot. It thanked them for the offer, told them a deadline for making the decision and asked for an improvement in the offer without just asking for a higher wage.

Summary

I found out what I needed to get the jobs I wanted. I used this to create a plan and then used paid online courses to speed up the learning process.

I applied to loads of jobs and got 5 interviews. I negotiated the offers from the two companies I liked the best.

I’ve been working at MissionLabs for 2 weeks now and I’m loving it!

Say Hello to Your Own Amazon Lex Chat Bot

Sam Williams — Fri, 02 Mar 2018 08:07:57 +0000

Build your own chat bot using Amazon Lex and teach it to say whatever you want.

This tutorial will guide you through the whole process of making a chat bot. We will start by setting up some simple responses and then use AWS Lambda for more complex responses.

Set Up

As all of this is built on Amazon Web Services you need to have an account. If you don’t have one, you can set one up here and clicking Create an AWS Account.

Once you have your account set up, we can set up the bot. Search for Lex or find it in the services drop down.

The AWS Services List

Once on the Lex page, click Get Started to get onto the bot setup page. Here is the option to use one of three sample bots or create a Custom Bot. We’ll be creating a completely custom bot so select that option.

You now get to name your bot and select an output voice. The voice will be used if you ever want to make a voice chat version of your bot. We will also set the session timeout to 5 min as default and select no for the COPPA (unless you intend to include non PG replies!).

With that all set up, you can click Create. You’ll be taken to a new dashboard like this and I’ll explain what everything means as we go along.

Intents

A chat bot is a set of responses that it gives to a certain message. These are stored in Intents which are like talking points.

Naming your Bot

We’ll keep our first intent simple, if someone asks what our bot is called we will reply with a name.

Create a new intent by clicking Create Intent or clicking the + next to Intents on the left. A menu will pop up and we want to choose Create intent again. We have to name the intent so call it something like WhatAreYouCalled.

This puts us through to the Intent screen. For now the important sections are Sample utterances and Response. The rest of the settings we will cover later.

Sample Utterances

Utterances are the phrases that you want this intent to reply to. For us those are phrases like “What is your name” and “What are you called”. Add each of the phrases to the sample utterances; I also added “what do you like to be called” and “what should I call you”.

The smart bit of Amazon Lex is that it uses Natural Language Understanding (NLU) to work out what the user is trying to say. If they say “What’s your name” instead of “What is your name”, Lex will still match the phrases. Pretty smart!

Response

No we need to reply to this message. Click the Add Message button in the response box. This creates a new message box for us to fill in.

In here you can type whatever you want to respond. You can enter multiple answers so the user can get a varied and more natural responses.

Now click Save Intent at the bottom of the page and you’ve created your first intent.

Building and Testing the Bot

To get your new chat bot working we first need to build it. This allows Lex to take your sample utterances and put it all together. Click the Build button in the top right of the page, it can take a minute or so to finish building so be patient.

When it’s finished you get a new area on the right called Test Bot (latest). This is where you can try chatting to you bot and testing it out. Try asking your new bot it’s name.

Adding More Intents

Being able to tell you its name is cool, but we want it to do more than that. You can add intents for load of things, just repeat the process you’ve done with different utterances and responses.

What does your bot say if the user says Hi or Hello. We’re going to expand on this later so make sure you get it working!

You can also have a go at making your bot answer these questions:

Who made you?

What is your favourite colour?

What’s it like being a robot?

What other questions can you think to get your bot to answer?

Quick Tip

When you are creating your utterances, type them in all lower case with no punctuation. The NLU program gets rid of the punctuation and capitals so using them can break the system.

Improving the Hello Intent

Having your bot just reply with Hi or Hello is pretty cool but it isn’t much of a conversation. We’re going to change that.

New Hello Intent

This is the design for the new intent

Customer — Hi

Bot — Hi there, what’s your name?

Customer — my name is Dave

Bot — Hi Dave, it’s nice to meet you. Is there anything I can help you with today?

Slots

In Lex, variables are stored in Slots. These contain a property name, slot type and a prompt.

There are a few different ways to create new slots and I’ll talk through them.

The first method is the most expected way. In the Slots section, type the a name for your variable, choose a slot type and write a prompt. In this example I’m calling my variable Name choosing AMAZON.GB_FIRST_NAME and saying Hi there, what’s your name? as the prompt.

The prompt is sent if the Required box is ticked and the intent doesn’t know the value for the variable. Clicking the settings cog opens up a new menu where you can set multiple prompt messages and list some replies.

The user can reply with just the answer to the question but what if they say something like My name is David? Lex needs to know which bit of the reply is the the variable and what is just filler words. You define the variable with curly brackets around the variable.

The last bit is to change the final response. You can include any of the variables in the final message using the same {variableName} syntax as in the prompt utterances.

With all of this updated it’s time to build again and try it out!

Other way to populate the Slots

So far, the user says a phrase which gets the bot to reply with a prompt for the slot value. This is great but there’s another way. What if a user say “Hi there, it’s Claire”?

This is just wrong. They’ve told you their name and then you ask them for their name. Luckily we can sort this out.

We can add a new utterance that includes the slot name. This is the same as writing a prompt utterance, including {SlotName} in the utterance.

This now fills the slot with their name from the first message. The slot is filled so the prompt never has to fire and the final message is sent.

Writing Your Own Intents

With what you’ve learnt so far you can create intents that create a very unique conversation with your users. You can have intents with multiple slots that create very custom messages.

Try creating an intent that works like this:

Thanks for following this tutorial, I hope you enjoyed it. If you did then please react and follow me for more bot tutorials and JavaScript content.

You can also check out some of my most popular articles here!

Shopping App from Scratch — Part 3

Sam Williams — Tue, 27 Feb 2018 19:22:47 +0000

I’d been asked to prototype a shopping site for a job interview. This is part 3 of the process. Read Part 1 and Part 2 if you haven’t already.

Having got a decent chunk of the website working and with 8 days until my interview, I decided to start working on the chat bot. I’d never done any work with bots so I was really excited.

It started with a lot of Googling and I found countless ways to create a chat bot. One of the tutorials was on Chatbot’s Life on Medium. This tutorial created a bot using claudia-bot-builder and deployed it on AWS.

I worked my way through the tutorial but when I got to deploying it to AWS using Claudia, I hit a problem. It didn’t recognise my AWS credentials. I search stackoverflow, AWS and countless forums but couldn’t sort it. I spent almost the whole morning trying to get it to work. If you’ve got experience with AWS or Claudia comment and let me know what I should have done!

The next tutorial I found didn’t use Claudia or AWS so I gave that a go and it worked. I had to start by using ngrok to tunnel the webhook requests through to a local port.

With this set up I needed to create the webhook routes in my bot API. This meant creating a get route for Facebook verification and a push route for receiving any messages.

Now I had to go through the process of setting up Facebook so that it worked with my new bot API. this involved creating a Facebook page for my group, adding an app to that page, adding messaging to that app and then adding my ngrok route to verified messaging routes.

I verified the route and saw the request go through. I also decided to get my app approved for bot messaging by submitting a request. This allows the bot to reply to other users, not just me.

The next step was to create a simple function that sends the same message back to the user. This was great as it allowed me to see how the process works and find any errors. Luckily there weren’t and it worked great.

Having a chat bot that imitates whatever you say is quite cool but completely useless. To give this bot a purpose you can connect it to API.ai. There are probably loads of different natural language processing (NLP) libraries and resources but this one is the one the tutorial suggests.

Once I’d signed up, I created an agent. An agent is like the logic of a bot, it contains all of the ‘request → response’ paths. To start I added a ‘small talk’ add on which meant the bot could have small talk with the user.

Small Talk

You can customise any of the responses and it had a list of inputs which will result in this response. The clever part comes with the fact that the phrase doesn’t have to match exactly. If a user types ‘what is your name’ instead of ‘what’s your name’, it’ll still match. This is the real strength of using a NLP service rather than hard coding all the responses yourself.

Creating something more customised

The available add-ons are great and it looks like you can do a lot with them but sometimes you just need to do something that they don’t offer. This is where custom intents come in.

Intents

These are the building blocks of any successful chat bot. They have a defined set of training phrases and then a given response phrase.

Simple text response

This could be as simple as “we will, we will” getting the response of “Rock you!”. This is most commonly used for simple support questions like “What is your customer support number?” or “What is the website address?”. Any question that can have an answer that doesn’t change.

Complex Requests

The simple text response intents are fun but they aren’t able to deal with the more complex and relevant questions such as “Where is my order” or “Can I return my order”. For these we need to use webhooks.

Fulfilment Options

When you enable a webhook call for an intent, the data is sent to the webhook URL that you created. This webhook gets all of the information contained within the intent and you can use this however you want, then return a custom message.

Chaining Intents

Asking a question and then giving an answer isn’t how a normal conversation goes, it’s a back and forth of a series of questions and answers.

DialogFlow allows you to add follow-up intents to any intents you’ve already made. Here is my follow up intents for my returnOrder intent.

Customer — Can I return my order

Bot — Of course, can I take your order number please (simple text response)

Customer — It’s 12345678

Bot — Thank you, I’ll just check that order (simple text response)

Bot — 2 pairs of Fred Perry B72 lace ups for Lucy Jones (webhook that hit the API to search the database for the order)

Bot — Is this the order you want to return?

Customer — Yes

Bot — OK, you will receive an email with a free post label (simple text response but also hits the webhook to send the email)

This is much more like what you expect from customer service, and it’s all completely automated in this bot.

Creating this really wasn’t very hard, I managed to do this having never worked with chat bots before. It takes a little while to get your head around how everything works (especially with the webhooks) but if you follow a tutorial and can use stackoverflow then you should be fine.

The webhook API was very simple: receive a request, if it has an action of return order then do a get request to main API and format the order in a readable way.

Creating a Shopping App from Scratch (Part 2)

Sam Williams — Wed, 07 Feb 2018 01:13:29 +0000

This is part 2 of a series on creating a shopping website from scratch for an upcoming interview. Click here to read part 1 to find out more!

Product Lists

I knew that this bit would end up taking a while. I had to create and populate a products model, create a get route for the API with searching capabilities, then create product list, product preview, product and filter criteria components.

The basic back end came together quickly and the front end list and preview components were done reasonable quickly too. I’d set it up so the URL was /products/:gender/:category which ended up regretting later on but it worked.

Filtering

This is where things started to slowly unwind. I created a filter component using multi-select drop downs, populated from the same store as the sub-header. The multi-selects worked well and I managed to get the values from them (with Google, console.log and trial-and-improvement).

I now had to work out how to turn that search query into a URL. This is where I realised that having a category as a parameter in the URL had a major problem — what if they were searching for more than one category? I had been trying to go with a /products/:gender/:category/:brand type of URL but that was not going to work now.

After some trial and error followed by a while of contemplative frustration, I decided to go with /products/:gender?filter-criteria. I could get the filter criteria and gender and pass them straight into the getProducts action… or not.

Converting Filtering into Queries

For some reason I had left the API functionality at getting all of the available products. Now I needed to take the filter from the front end and convert it into a query for MongoDB.

The problem with this is that the query comes in as a string and it needs to be compiled with $and and $or controls for multiple fields and multiple values for those fields respectively.

For example, requesting all women’s shoes in size 5 or 6 and in blue or white come as a string like this:

?gender=womens&stock=5&stock=6&colors=blue&colors=white

But the query to the mongo database needs to be in this format:

{
  $and: [
    { gender: "womens" },
    {  
      stock: [{ 
        $elemMatch: { 
          size: [5, 6],
          stock: { $gt: 0 } 
        }
      }]
    },
    { $or: [
      { colors: "blue" },
      { colors: "white" }
    ]}
  ]
}

By default, express parses the above query into this format:

{
    gender: "womens",
    stock: [5, 6],
    colors: ["blue", "white"]
}

There are 3 problems with this :

The stock parameter is actually an array of objects.
The colors parameter is an array of strings.
We need to have all three parameters in a product.

The stock objects look like this:

{ size: 4, stock: 13 },
{ size: 4, stock: 0 }

This means that we need to create an array of objects that have one of the sized requested and also have stock. To do this we use $elemMatch for an object with size in our size array and stock being greater than 0.

{  
  stock: [{ // create an array of elements
    $elemMatch: { // That match 
      size: [5, 6], // size of 5 or 6
      stock: { $gt: 0 } // and stock greater than 0
    }
  }]
}

To handle this, I created a handleStock function.

function handleStock(size) {
  return { 
    stock: { $elemMatch: { size: size, stock: { $gt: 0 } } } 
  };
}

The colors is slightly simpler. We need to find products that match blue or white. This was similarly handed by a handleColorsArray function

{ $or: [
  { colors: "blue" },
  { colors: "white" }
]}

function handleColorsArray(array) {
  return { $or: array.map(col => ({ colors: col })) };
}

The last issue is making sure the products contain all of the properties. To do this, if a query had more than one parameter I would pass it to convertToAnd(). This maps over every parameter. “stock” parameters are passed to handleStock. “colours” parameters are passed to handleColorsArray if they are a array. Everything else is just passed through as is.

Once each of the parameters has been mapped over, the array of queries is wrapped in an $and query.

function convertToAnd(query) {
  let q = Object.keys(query).map(param => {
    if (param === "stock") {
      return handleStock(query.stock);
    } else if (param === "colors" && typeof query.color !== "string") {
      return handleColorsArray(query.colors);
    } else {
      return { [param]: query[param] };
    }
  });
  return { $and: q };
}

Now if I did a call to the API with queries, it could process them and return the array of all of the matching products. Hooray!

Filter Criteria

Now with the API able to receive and processing the filtered queries, I had to allow the users to select and change them.

I created a FilterCriteria component that mapped over the filtering options and created a new Select dropdown for each. This Select uses MaterializeCSS multi-select dropdown boxes so that a user could select and unselect the options that they want. Because of MaterializeCSS these boxes worked well and looked great.

Now I had to get the resulting information from the form and somehow send this to the API. The solution I came up with was to make the search button a to the URL that corresponded to the queries.

I did this by mapping over the form and extracting all of the drop down values. I then mapped over these adding them to a query string. If a value had multiple selected options, I mapped each of them to another section of the query string.

FWith the completed query string, I generate the complete URL and push it into the history.

A few small hiccups

The way that I’d set things up, it currently worked like this:

Search for trainers by Fred Perry in size 5
Redirected to URL /products/womens?category=TRAINERS&brand=FRED%20PERRY&size=5

The problem with this is that TRAINERS doesn’t match trainers like in the database. The reason that it is TRAINERS in the URL is that I capitalised the strings as lower case looked really bad.

To try to fix this, I just converted all of the strings to lower case before processing them. This brought up two new problems.

The default values don’t equal themselves as the value from the select has been lower cased →(“category” === “Category”) is false. This means they are added to the query string as category=Category
The brands no longer match the database strings

After some over complicated attempts to capitalise certain parts I realised I could just change the original values in the database.

“red” became “Red”, “trainers” became “Trainers”. I think this also looks much better than block capitals.

This meant that I didn’t need to do any string manipulation and everything would work as it had done before.

Product Page

Now I had a fully filterable product list, I needed to send the customers somewhere when they clicked on a product.

This was a simple layout — image on the left — basic details on the right — full details below.

Basic wireframing

Building this component was simple to build and most of my time was spent styling it so that it looked good and worked well on desktop and on mobile.

I’ve still got some work to do with this page. The select boxes are being created before the product information has been received and aren’t updating their values with the correct information. The Add to Basket button currently doesn’t do anything as I need to create the user/basket update methods first.

Account Pages

The last UI thing I decided to tackle was building an account section. Again I borrowed the design from Asos, simple tabs on the right and information on the right. When on mobile, the menu was full screen width and opened a new page that had a back button.

Each of the options (Orders, Details, Addresses) have their own UI component. These components are either rendered to the right side of the menu when on desktop, or as a separate page when viewing on mobile.

These components are very simple, taking a prop of either auth (user) and rendering out the relevant data. Again these components currently don’t support updating the user information as I’ve decided to work on other parts of the prototype first.

Things to note

It may seem like I’m building lots of components without finishing some of them, even leaving some not working properly. You’d be right. I’m doing this for 3 reasons:

I only have 3 weeks to build it. Making 80% of it work will take 20% of the time. I’m just skipping the last 20% and saving myself a load of time.
This is a prototype. I’m not trying to make a perfect product, I want to show all of the ideas I have. As long as they work reasonably well and demonstrate the skills and ideas that I have, they’re meeting their requirements.
I’m actually on holiday. I’m doing this in the last few weeks of a 6 month road trip around South East Asia. I don’t want to be spending all day every day sat inside on a laptop when I could be outside climbing and having fum.

In the next section I’ll talk about creating a chat bot to accompany the website. I’ve never worked with chat bots before so come along for the ride!

If you liked this article, make sure to react and follow me to see the part 3!