Forem: Hannah Cross

Tech Book Club Reading List 2020

Hannah Cross — Tue, 05 Jan 2021 12:42:16 +0000

Last year the dev team at NearSt started a "tech book club". We started meeting once a week to spend 30 to 45 minutes discussing a book, talk or podcast we thought was interesting and vaguely (or directly) relevant to our team's activities.

The below is an unordered list of the various resources we looked at in 2020. Some we liked, some we didn't. We definately didn't finish all the books either. However, they all provided great jumping off points for us to reflect on our team, roadmap, cultural attitudes and technical choices... and so forth.

We found this a particularly good activity since the start of the pandemic, bringing us together to exercise our minds and kick start team discussions whilst working remotely.

So, in case any of these spark your interest... here's our 2020 list!

How I deployed a Gatsby site to AWS S3

Hannah Cross — Wed, 22 Jan 2020 18:19:18 +0000

Choosing Gatsby.js

At work we are rethinking our front-end properties and the tools we use for them.

Our existing codebase is unnecessarily complex given our current needs so we looked to find a quick and efficient solution to throwing our primarily static pages out to the web.

Gatsby came out as a good option as it is fast, easy to configure and quick to edit and update. It has plenty of plugins which enable seemingly seamless integrations with AWS resources. The build time rendering is also good for speed and ease.

As part of a proof of concept exercise, I rebuilt part of our website using Gatsby.js, an AWS S3 bucket, AWS CloudFront and Serverless Framework.

Spoiler - IT WAS A SUPER FRIENDLY EXPERIENCE (with a few rough edges on the AWS side...)

Tools

AWS:

AWS CLI
AWS S3
AWS CloudFront

Gatsby:

gatsby-cli (I kicked off with a default starter)
gatsby-source-dynamodb

Serverless:

serverless
serverless-finch
serverless-cloudfront-invalidate

Building a Gatsby site

First off, I installed the Gatsby CLI:

yarn add gatsby-cli

Then to make my new gatsby project:

gatsby new name-of-your-site

which will create a directory with a default starter in it.

You can immediately get things running locally by

cd name-of-your-site and gatsby develop

You now have a gatsby site!

More detailed documentation lives here: Gatsby Docs

Connecting your Gatsby site to a database

Gatsby plugins are SO GOOD.

In just a few lines of config my Gatsby site was up and running with data from DynamoDB. (It is also just as easy to set things up with a SQL database too! Try gatsby-source-mysql)

yarn add gatsby-source-dynamodb

and in the gatsby-config.js

 plugins: [{
      resolve: "gatsby-source-dynamodb",
      options: {
        typeName: "NAME OF THIS CONNECTION",
        region: "REGION",
        params: {
          TableName: "TABLE NAME",
          // OTHER PARAMS HERE
        },
      },
    ]

Gatsby uses graphql so to access the data in a page, you can create a graphql query which will then be automagically be passed into your component as props. It would look something like this:


import React from "react";
import { graphql } from "gatsby";

const AnimalsPage = ({ data }) => {
  const animals = data.allAnimals.nodes;
  return (
    <div>
      <h1>All Animals</h1>

      <ol>
        {animals.map((animal, i) => {
          return (
            <li key={i}>
              <a href={`/${animal.id}`}>{animal.name}</a>
            </li>
          );
        })}
      </ol>
    </div>
  );
};


// this data is passed into the above component as props 
export const query = graphql`
  query MyQuery {
    allAnimals {
      nodes {
        name
        id
      }
    }
  }
`;

export default AnimalsPage;

To figure out your graphql query you can run gatsby develop and head to the GraphiQL interface at http://localhost:8000/__graphql

You can also add config to gatsby-node.js to fetch all your data and then generate pages based on a template for each data set. So if you have a database of animals each with the same data fields you can generate pages for each animal in the same layout.

Create a template under the templates folder and reference it in the gatsby-node.js file like this:

exports.createPages = async function({ actions, graphql }) {
  const { data } = await graphql(`
    query MyQuery {
      allAnimals {
        nodes {
          colour
          habitat
          country
          id
          diet 
          name
        }

      }
    }
  `);

  data.allAnimals.nodes.forEach(node => {
    const id = node.id;
    actions.createPage({
      path: `animal/${id}`,
      component: require.resolve(`./src/templates/page.js`),
      context: { node },
    });
  });
};

The data will be passed into the page template through context at build time. You can instantly generate a number of repeating pages with unique values and set the slug as well!

Finally once you have created your website, you just need to run

yarn build

and it will build your site locally, updating the public/* files.
These pages will be the files you will save in your S3 bucket!

Deploying your project to S3

Setup your AWS CLI and AWS profile

This post presumes you already have an AWS account but if you haven't configured a profile on your AWS CLI you can do so quickly provided you have your access details.

Run aws configure and then populate the below fields.

AWS Access Key ID: e.g. AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key: e.g.wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name: e.g. eu-west-1
Default output format: e.g. json

This will enable you to deploy to your AWS resources from your local environment without having to play around with AWS secrets and envs in your code.

You can check whether you have already set this up by running cat ~/.aws/credentials in your command line.

Create an S3 Bucket

Go to the AWS website and login.
Navigate to services/s3.
Create bucket
Choose a meaningful name for your bucket (you will use this in your serverless.yml later)
Choose a region close to your location
Hit create
Under the "Properties" tab, choose Static Website Hosting.
Set the Index and Error to index.html - this directs all traffic to your project which will handle the incoming HTTP requests.
Under "Permissions" turn off the block to make the S3 bucket public. (You can also look into setting IAM roles and restricting access with other configuration)
Save all this and you have your bucket!

Your serverless.yml

Add the plugins
yarn add serverless
yarn add serverless-finch
yarn add serverless-cloudfront-invalidate

As a side note: Check your repo for duplicate gitignore files and make sure to combine them.

You can now edit your serverless.yml file which will seem really long and full of comments but in the end you can get away with something as minimal as this:


service: service-name 

provider:
  name: aws

plugins:
  - serverless-finch
  - serverless-cloudfront-invalidate

custom:
  client:
    bucketName: bucket-name
    distributionFolder: public // the folder you want copied into S3

With this all set up you can run your build script

yarn build

and then run

sls client deploy

It should be quite quick and return an AWS URL where you can access your files. You will need this to set up your CloudFront Distribution.

N.B. By using serverless-finch and running sls client deploy you will not create a CloudFormation stack. It will just efficiently deploy your files to S3.

Set up CloudFront

By putting your S3 files behind CloudFront, your end users will have much faster access to these files. The files get cached in multiple locations and when your user navigates to the endpoint it will return the closest cached version of those files - nice!

You will need to login to the AWS console and setup a CloudFront property and get a DISTRIBUTION ID.

Services/CloudFront
Create Distribution
Choose "Web Distribution"
Add the S3 Bucket url to the Origin Name field (it should have popped up in your terminal when you ran sls client deploy)
Everything else can be default
Create Distribution!

The shorter CloudFront domain will take a few minutes to deploy but once deployed you will be able to access your files from both URLs (S3 and CloudFront)

Importantly this will add another step...Cache Invalidation
Each time you run your deploy command you will also want to invalidate the CloudFront cache so that your newer files will be stored instead.

Just add the following to your serverless.yml under custom

cloudfrontInvalidate:
    distributionId: "DISTRIBUTION ID"
    items: 
      - "/index.html"

Then you can run sls cloudfrontInvalidate and it will clear your cache!

And that's it!

So this was a really basic approach to deploying your gatsby site to AWS.

I found working with Gatsby.js so enjoyable. The documentation is friendly and there are plenty of articles and walkthroughs out there which help to clarify for various usecases. My favourite part of the process was being able to connect to a database with just a few lines of config and keep the data fetching out of the page creation. I could create 700+ pages with one template and the data fetching done in 20 lines in a config file. Then instead of generating each page on request, Gatsby builds all your files at build time meaning that you are only ever serving static html files to the end user. SPEEDY!

Deploying to AWS Resources is slightly more complex and I needed a hand with some of the config but that worked out fairly simple in the end too!

There are, of course, many other ways to do this however, hopefully this walkthrough provides a possible starting point for getting a personal project or a proof of concept up and running quickly!

Useful reading:

How learning to code is building my resilience, one mistake at a time

Hannah Cross — Sun, 10 Nov 2019 09:48:14 +0000

Dear new programmer,

I am so excited that you have also decided to join the world of programming! That said I know it can be tough to start with and things don't always go so smoothly. But don't give up!

Feeling like you have failed at something is not a great feeling. When you make a mistake that you believe you could have avoided or when you pick what turns out to be the wrong approach or solution, it can be so frustrating. It happens to many of us.

If you’re like me, these perfectly normal moments can really get you down. I have agonised over what I could have done better or that I should have been more prepared. At one point in my life, I felt that every mistake I made was a reflection of how bad I was as a person. However, I have since put a lot of focus on adhering to the advice of "learning from your mistakes" and do my best to extract some sort of knowledge or wisdom from each experience.

For me, this realisation and focus really came about when I changed career and started studying to be a web developer. One of the first lessons I was taught as a developer was how to fail. And break things. On a regular basis.

One thing I was constantly told at the start of my coding journey was that breaking things (or making mistakes) is integral to the whole process. Furthermore, this does not change throughout your career. Even the most senior and experienced developers make mistakes. It can be small like a typo in the spelling of a class or it could be huge like an expired certificate taking down an entire mobile phone network…!

The reality is that mistakes will happen, no matter what you do and where you are, but the point is to learn from them.

Failures, repeated failures, are finger posts on the road to achievement. One fails forward toward success.

C. S. Lewis

In order to build my resilience I needed to learn how to accept that making mistakes is natural and human without also feeling like my career, my life, or the world, was falling apart.

I started thinking about how to achieve this, and I realised I needed to find an environment where mistakes were understood and supported. I wanted to feel like I could try new things without fear or anxiety and learn from any mistakes or failures along the way.

This is one of the great things about my experience of the Tech community. The only way to advance is to try and fail. It’s the only way you learn and figure out how to improve. Furthermore, programming teams and projects are set up with frameworks and systems that allow for mistakes to happen – development environments, code reviews, user acceptance testing, test driven development, business driven development, stand ups, release cycles and more.

As a discipline it recognises that in order to improve and get better we need to be allowed to take risks which may end in failure. We need to try new things, test ideas, reaffirm our existing knowledge and yes, break things once in a while in order to succeed.

There is no innovation and creativity without failure. Period.

Brené Brown

The tough things

High Pressure to Deliver. If your resilience is low and you enter a world where you are regularly making mistakes and breaking things, it can get pretty stressful. Just like any high pressure job can feel.
Mistakes are relentless. In the first 9 months of working in my first developer job, my ability to pick myself up and move on was challenged. So many days had been spent agonising over a mistake I felt that I should have been able to identify sooner, or an error I should never have made in the first place. There were times when I let the feelings of failure or frustration get me down. It felt personal. It’s hard not to take these moments personally. I found it difficult. But I know I am not the only one who has felt this either.
Overwhelming number of resources and solutions and options. One of the biggest challenges for me was to identify which advice, solution or result in a google search was the most relevant or useful to my problem. Essentially, knowing what question to ask and figuring out if the answer is the one you need. This can feel like hacking through a jungle and it takes practice to slim down your research time for even the "simplest" of things.

The awesome things

I feel supported. Towards the end of last year, I had a seemingly endless run of tough days. Instead of telling me to ‘just get over it’ or ‘toughen up’ my boss and colleagues listened and offered advice and perspective. My learning definately sped up with this encouragement and support. This is even more true of my current job. The people you surround yourself with are so important in how well you learn and grow.
The online tech community has some great social media accounts. These social media accounts have been an amazing and surprising source of strength. There are so many instagram posts, medium articles, twitter accounts… all sharing the mistakes they made or the knowledge they gained or encouraging words to motivate their fellow developers.
I learn everyday. Every time I get stuck, break something or make a mistake, I take a breath and remind myself it's not just me and I will become a better developer because of this incident. I try not to judge myself too harshly, but instead accept that it happened and figure out why. With every bit of knowledge I gain, I inch closer to feeling more confident and more equipped to deal with the next challenge that comes my way.
I make things and people use them in the real world (sometimes) !!

Anyone who has never made a mistake has never tried anything new.
Albert Einstein

As you can see and do most likely know, the good outweighs the bad.
Of course, I still get upset and stressed but thanks to the help of my friends and colleagues, plus a healthy dose of perspective, now I am ready to pick myself up and try again. I feel ready to try and find the positive learning from the mistake instead of dwelling on what went wrong or what people are thinking about me as a result.

I will no doubt make a mess of something else. But I know it will be ok because with every tumble, a bit more knowledge gets logged in my brain. I will approach the problem differently next time and so keep moving forwards.

So, if you are feeling stressed, worried or frustrated with your progress or that you haven’t done enough. I know that you have. I also promise you that many other people have felt what you’re feeling. It won't be long before you are telling others who come after you the exact same thing.

Hannah xxx

Nevertheless, Hannah Cross Coded

Hannah Cross — Thu, 07 Mar 2019 11:23:53 +0000

I started to code in 2017 because...I wanted to build things and solve problems. I wanted to prove to myself that it wasn't "beyond me" or "too difficult"... and I did! I moved from a fundraising role in the cultural sector to a tech job within six months - anything is possible!

My favourite code editor is...VS code. I thought Atom was "the one" for a long time but in the past six months I have been completely converted by the integrated terminal, panda theme and debugging.

I hope for more women and young people to get involved with tech. I am currently volunteering for Code First Girls as I think everyone should have the opportunity to learn, even if it doesn't turn into a career. It's a really powerful life-skill. I also want to see the cultural and charitable sectors have more access to new technologies and IT infrastructures - this could transform the way some organisations work.