Starting a project from complete scratch is quite a daunting task to consider as a Junior Developer. So, when the Partners squad, made up of myself and Ste Jackson, were assigned the task of developing a brand-new application form for the Zuto website, it was hard to choose where to begin!

As you can imagine, the only way you can tackle a mammoth project like this is with careful planning and strategic organisation of both your workload and the many different components your code base will be made up of.

Thankfully, we came across Storybook: a Sandbox environment and open-source tool for UI development.

With this handy software, no longer did we have to monotonously check through every component’s functionality or see how they affected the main application. Now we had the tools to create and test our components as they would appear in the application before any real development work began.

Storybook was so integral to our process that it made me question how you could create a front-end development project without it. For that reason, I want to share 5 pros of using Storybook.

1. It’s an interactive playground for UI components

One of the main benefits of Storybook is that it allows you to create components that are interactive rather than static. You can live-edit your creations, play around with the display and view how they would render in different ways.

For example, when we created our Button component for the application form, we had to consider the many different states it would include. Thankfully, Storybook offers Addons which expand the environment and allow a user to customise tools to fit in with their needs.

With the Controls addon, we were able to interact with the Button component without the need to code - we could determine appropriate modifications such as the Button variant, size, subtext, icon and whether it was disabled. Take a look…

By selecting different options in the dropdown menus or by inputting our choice of text, we were able to render whatever style of Button we liked immediately onto the page, without affecting the larger application.

2. You can test in isolation

This brings me nicely to another benefit of using Storybook — the ability to test and develop your components separately to the application, meaning project dependencies will not affect the behavior of components.

We found it extremely useful having a platform like Storybook isolated from the rest of our application as we could safely play around with component design and functionality without worrying about any pages being disrupted. That being said, as much as the platform was separate, it was also incredibly easy to integrate within our React application when needed.

Not only that, Storybook works with most of the other front-end frameworks too!

3. Allows for rapid UI development

Using Storybook hugely cut down our development time. This was due to the speed in which you can create components and how easy the software is to set up.

We used Storybook to create our components in real-time, which was aided by hot module reloading; whenever we made a modification, the module was replaced without the whole page reloading. This instant gratification helped us a lot and made sure we could design each component perfectly before integrating it within the rest of our app.

Additionally, the process of building a new story within our project was super simple and once we’d implemented one, we could easily tackle the rest without any (many…) hiccups. If you want to read more about implementing stories, you can do so here: https://storybook.js.org/docs/react/get-started/setup

4. Add handy documentation for other developers

With each story you make, you have the option to integrate the Docs addon, which allows you to add high quality documentation to your components.

We chose to incorporate this as we wanted to add in-depth documentation so that any other developer could access Storybook and immediately understand each of the component's capabilities and usages.

For example, we set up a design for our Grid layout within Storybook, which wasn’t quite as self-explanatory as some of our other components. For this reason, having the Docs addon right alongside the Grid canvas gave us the ability to describe exactly what was going on and how our app form layout was structured.

We believe this will be a handy tool for other engineers at Zuto and will save vital time in understanding components before you are able to work with them.

5. Great UI for great UI

Finally, what more do you expect from a design tool created for building clean and pleasing user experiences, than an easy-to-use, aesthetically pleasing UI?

The organised and structured design of Storybook allows the user to focus on what matters most: building their components quickly and efficiently.

Storybook aids this process by separating your components accordingly, as well as organising the specified Addons you have implemented. It was due to this that we were able to showcase the atomic design principles that were vital to our approach of building the new app form.

With Storybook, we were able to easily demonstrate which components were classed as Atoms, Molecules and Organisms, and see clearly how they all interacted with one another. Not only did this help us during development, but it will make it easier for any future users to understand the thought processes behind our approach.

These many benefits that Storybook offer, including the rapid development process, the handy documentation for other developers and the clean UI, greatly improved our time and efficiency in building the new app form. As a developer, you’re always on the search for software and tools that will make your life easier, and Storybook offers exactly that! We hope to branch out this development tool into other areas at Zuto in the future. Follow this link if you would like to learn more about what Storybook has to offer: https://storybook.js.org/

Hello!

I'm Michael Horsley and I'm one of the software engineers at Zuto.

This is hopefully the first post in a series of ramblings around seeing if I can run a copy of Zuto APIs off a cluster of Raspberry Pi.

The posts will generally be split between a wordy bit explaining what I intended to do/why and then a step-by-step walking through of how it was done.

This one will be a bit more wordy, as it'll include an introduction about why I'm doing this and then setting up a Pi Cluster.

If you're here for tech, as I'm sure some are, skip ahead to section "Less talk more cluster"

I wonder if Zuto would run on a Raspberry Pi?

Why Raspberry Pi?

Well, mostly in an continuing effort to justify how much I spend on tech to myself and my partner (mostly the partner) I thought this would make great use of any Raspberry Pis I had already, as well as save some cost on hosting in AWS.

Could you have not just used the cloud?

Oh absolutely, and for anything that's even remotely important or has any service-level agreement requirements, I'd go cloud based every time.

Kubernetes in the cloud has progressed really well in the last couple of years. From AWS EKS or Googles Cloud Platform managing your cluster to orchestrators such as Rancher (https://rancher.com/) it all makes getting your docker images and containers up and running on the cloud has been made much simpler, because providers have abstracted a lot of the complicity/maintenance away from the user.

However I feel this often skips a lot of the learnings and appreciations that engineers gain from having to deal with the original pain of getting it all working without these helpful services.

Also as costs of cloud RAM and Cores reduce over time, engineers and companies seem to have less enthusiasm around optimising either memory and CPU usage, as it returns less value then releasing new features or focusing on code.

Working with a Pi cluster brings a very fixed amount of usable resources, bringing with it a challenge to see if you can squeeze everything out of the running applications and forcing you to constantly monitor the running pods.

Another bonus of a Pi cluster would be if I could get it all completely self contained within my home network, the idea of having a fully contained bubble sounds like fun, for both development and testing. However this might be difficult with some existing services that exist purely within the AWS realm.

This might even open up the ability to spin up dev environments for each of the engineering teams allowing them to work independently of the other teams without the extra cost would be caused in the cloud.

What are you hoping to gain?

Mostly a better understanding of data flow through Zutos APIs, I've been with Zuto a little over 3 months at time of writing and while I've built somewhat of an understanding of the applications I work with day-to-day, I've got no doubt I'm missing a lot of infrastructural knowledge.

By converting each application into the Pi cluster and then it's connecting applications, I'll have to understand what is going on and each flow throughout the system.

I may be able to optimise the applications to get everything running on the cluster. This will hopefully improve Zutos cost margins, as we scale these will only increase, so any benefit here will hopefully compound later down the line.

Why K3s

K3s is a lightweight version of Kubernetes, perfect for a Raspberry Pi Cluster and supports ARM. It comes bundled with fairly little but does include Ingress (that'll handle the API requests) and a Control plane (that'll control where our running applications sit in our cluster).

The other main option for Raspberry Pi is MicroK8s which boasts, among other things, high-availability.

I chose K3s over MicroK8s mostly because I struggled to get a basic .Net Core application running within the cluster, almost certainly something daft I've done but it was difficult to try and find any tutorial or guide that showed me how to piece together an Ingress or any other routing option into an usable setup.

If someone has a good tutorial or walk through I'd be happy to try it out, one joy of the Pi cluster is I can rebuild it fairly quickly now.

The Cluster

So I'm going to using a 3 node Cluster consisting of 1 Raspberry Pi 4 A (4GB model) and 2 Pi 4 B (8GB models) making it one primary and 2 secondary nodes. The primary node by default will act as the control plane while the 2 secondaries will run my applications, however you should be able to follow along with even a single Raspberry Pi (Ideally RPi 4B models, however 4A should work as well).

Less talk more cluster

For the following you'll need this;

• Raspberry Pi 4 with power supply
• SD Card and SD card USB Reader
• Desktop or Laptop to image the SD cards
• Raspberry Pi Imager (I've grabbed it from here https://www.raspberrypi.org/software/)
• SSH Keys generated on your machine (you will most likely already have these if you use GitHub, to check, go to your user directory and see if there's an .ssh folder, it might be hidden. If not, run ssh-keygen within command prompt and follow the instructions)
• [Optional] Lens for Kubernetes (https://k8slens.dev/) This is optional but will give you a nice GUI that'll display information about your cluster

In my commands to run, I'll either denote them as Desktop or Pi or Pi Primary, if you are following along, copy everything after the $

So if my command was Desktop $ ssh ubuntu@ubuntu this means, from my desktop machine I would run the command ssh ubuntu@ubuntu, hopefully that makes sense. This will hopefully make things easier later in the step-by-step when I switch between the primary/secondary nodes and my desktop for Helm.

The Pi and Pi Primary are for dealing with multiple Pi, if you're using only 1 Pi then skip the "Setting up our secondary Pi Node(s)" section.

Setting up a base Ubuntu Pi

1. Take the SD card and place it into your card reader and place that into your computer

2. Open up the Raspberry Pi Imager

3. Go to Ubuntu and then select Ubuntu Server 21.04 (RPi 3/4/400) 64-bit server OS for arm64 architectures

4. Then select your SD card

5. Click Write

   • This can take up to 10 minutes or so to write and then verify, depending on your USB port and Cards write speed
   • Once that is done it should have already safely ejected the mount, however if not, do this yourself before taking the reader out of your computer

[Optional Steps For Wifi]

If you would like your Pi to use Wifi on boot like I did, use the following, otherwise skip steps 6 - 10 if you have an Ethernet Cable connected to the Pi

6. Place the reader back into your PC to get the folder prompt back, we have some files we need to alter

7. Open up the drive disk view and select system-boot

8. Open the network-config file in a text editor

9. Remove the commented out lines under the ethernet section and replace it with something like my example

• just remember to be careful, this is yaml and it uses spaces, tabs will not work here and it's 2 spaces for indentation
• put your wifi name with " " surrounding it, just like your password
• An example is below;

version: 2
ethernets:
  eth0:
    dhcp4: true
    optional: true
wifis:
  wlan0:
    dhcp4: true
    optional: true
    access-points:
      "my-wireless-network-name":
        password: "my-network-password"

10. Safely eject the SD Card from your machine

[End of Optional Steps For Wifi]

11. Plug the SD card into your Pi and power it up

• Wait a couple of minutes and then open up a terminal, I personally use Git Bash (https://gitforwindows.org/), we are going to ssh into our PI now

12. You can ssh into your Pi either via its hostname like so or by it's IP

• Desktop $ ssh ubuntu@ubuntu

since the default host should be ubuntu or you should be able to get it via it's IP address, there's a few ways to find out the Pi IP address, I usually open up my wifi router's home page and look for it there. Hopefully ubuntu should work as a host name but that might depend on your routers settings

13. When prompted to add the key fingerprint type yes

• the default password is ubuntu unless you changed it within the user-data file previously

14. It should now ask us to reset the ubuntu user's password, follow the prompts to create a new password for this user, type what you want but remember it

• completing this step will kick us out of the ssh session

15. [Optional] If you have already set up ssh keys and would like to log into the Pi via them rather than a username/password, do the following from your machine

• Desktop $ ssh-copy-id ubuntu@ubuntu
• enter in the password you set in the previous step
• now when we ssh into the PI, we won't get asked for a password

16. ssh back into the PI

• Desktop $ ssh ubuntu@ubuntu

17. Run the following

• Pi $ sudo sed -i '1s/^/cgroup_enable=memory cgroup_memory=1 /' /boot/firmware/cmdline.txt
  • ? what does this command do? this allows resource management to restriction memory usage, when installing K3s, the service will not start if this part isn't configured correctly

18. Set the hostname of the pi, don't have this collide with any hostnames already defined on your network (so I use node1, node2, node3 etc).

• Pi $ sudo hostnamectl set-hostname node1

19. Then reboot

• Pi $ sudo reboot

20. Ssh back into the Pi once it's booted Desktop $ ssh ubuntu@node1 //or whatever you changed the host to

21. Run package updates, it's always good to keep it up to date for security updates

• Pi-Primary $ sudo apt -y update && sudo apt dist-upgrade
  • this takes a while
  • on the version that I am running, it will warn you that there's a new version of the kernel and it will need to restart some services, just hit Enter, you'll see two different screens that look something like this;
    

22. Finally reboot after that's done

• Pi $ sudo reboot

You now have base set up of the Raspberry Pi, however we don't yet have K3s on it. The previous steps are the same for all nodes within our cluster

Now it diverges slightly, on your Primary Pi node do the following

Setting up our primary Pi Node

1. Let's get K3s

• Pi-Primary $ curl -sfL https://get.k3s.io | sh -

2. Once that's done, run

• Pi-Primary $ sudo kubectl get nodes
  • this should return them as ready, if not, wait a few minutes and try again, failing that, double check the cgroup_enable and cgroup_memory to make sure they are correct

Setting up our secondary Pi Node(s)

Assuming you've repeated steps 1-22 for all the generic setting up of Ubuntu, we don't run the same curl command as our primary for all our secondaries, instead we install and connect our Pi(s) to the primary node by doing the following;

1. On the primary node run the following

• Pi-Primary $ sudo cat /var/lib/rancher/k3s/server/node-token
  • this will spit out a token, copy that for the next command

2. ssh into your secondary nodes and run the following, using the token generated from step 1

• Pi-Secondary $ export K3S_URL="https://node1:6443" && export K3S_TOKEN="<TokenCopied>" && curl -sfL https://get.k3s.io | sh -
  • Replacing the hostname node1 if you used something different
  • Replace '' with the token from step 1
  • Don't forget to copy the little - at the end, it's part of the command

3. After a few minutes you should be able to run Pi $ sudo kubectl get nodes on any of the Raspberry Pi to see the nodes as ready.

And there we go, we have a running cluster!

But we don't want to have to SSH into the Raspberry Pi everytime we want to deploy something or run any kubectl commands.

Running Kubectl commands without SSH'ing into the cluster everytime

For this we'll want to grab the Kube Config from the Primary Node, and then copy it to our main machine, this will allow us to run the kubectl commands outside of our cluster.

1. Create a new folder within your user directory on your main machine called .kube

• For example mine could then become C:\Users\michael.horsley\.kube

2. Within this directory create a new extentionless file called config

3. Open a terminal and SSH into the Primary Pi node

• Desktop $ ssh ubuntu@node1
  • my Primary Pi host is node1

4. Print the K3s kube config to the terminal

• Primary $ sudo cat /etc/rancher/k3s/k3s.yaml

5. Copy that from your terminal and then paste that into the config file we created in step 2

6. Open the config file and around line 5 there is a bit of text server: https://127.0.0.1:6443 change the 127.0.0.1 to your nodes hostname or IP address

• Mine would become https://node1:6443

7. Save that file and then re-open the terminal and try getting the cluster nodes

• Desktop $ kubectl get nodes

8. Now hopefully you'll be able to see all your nodes and we've done this outside of our cluster! No more needless SSH'ing back in to run commands. This'll become important for when we want to deploy applications into our cluster.

• If this step fails, try using the IP address instead of the hostname when updating the kube config file

9. [Optional step for Lens] Getting Lens set up with our cluster is now as easy as clicking to add a new Cluster and then selecting our config file. Lens should then connect and you'll be able to browse around the namespaces and contexts, we aren't running anything yet so it'll be a little empty.

Here's a link to a kubectl cheat sheet I will often refer back to since it's hard to remember all the commands (https://kubernetes.io/docs/reference/kubectl/cheatsheet/)

Next steps

My next steps are to start moving over the Api applications and their dependencies, I'll be doing this one at a time but first I'll need to figure out which ones to move.

Wrapping up

If you've made it this far then thank you, hopefully this post will at least have been interesting and do let me know how your cluster went or if you have any general feedback or advice for my posts or my Pi cluster! My twitter handle is @Mike_Horsley

Looking back, I still find it hard to believe how far I have come in such a short amount of time. From taking the leap into software development just five months ago and embarking on a 14-week intensive coding bootcamp at Northcoders, I kicked off 2021 with a bang and started my first job as a Junior Software Engineer. It still seems crazy that I managed to achieve something like this, especially during a global pandemic, and I am excited to see where this journey will take me going forward. For now, though, I wanted to share my experience and what I have learnt from starting my role as a Software Engineer at Zuto.

As I approached the end of my time at Northcoders, I was all set to embark on the gruelling journey into finding my first job. I put time and effort into my LinkedIn profile and mentally prepared myself for the endless amount of tech tests and inevitable rejections that were coming my way. However, just before I officially graduated, I was approached by Zuto, who had read about my coding experience on my tech blog and wanted to invite me to interview. It seemed too good to be true — an interview without all the stress and hassle of an application? But nevertheless, a couple of days later I was interviewing for the role whilst simultaneously finishing off my final Northcoders’ project. By the end of the week I was offered the job and I couldn’t believe it. I was so grateful that Zuto saw the potential in me and wanted to offer a soon-to-be coding bootcamp graduate a chance.

As much as I was excited to get my teeth into my first professional role, I was also trying to overcome the fear and anxiety that came with starting a new job in an industry that I had never worked in before. I couldn’t shake the fact that my only experience of coding had been at Northcoders, where I had been cooped up in my room doing the whole thing online. To think I would be removed from this bubble, working on something that would impact a real-life company, was very daunting and something that took me a while to digest. That familiar feeling of imposter syndrome was creeping up on me and I was already telling myself that I would be the most inexperienced person there — I didn’t have a computer science degree and was still relatively new to software development. What if I was out of my depth?

Thankfully, my first week at Zuto managed to alleviate these concerns and calm my nerves. The whole week was dedicated to introducing me to the company, allowing me to get to grips with what they did and how they did it. This was extremely useful as I was able to get a sense of the bigger picture of the environment I would be working in and understand the day-to-day rather than being chucked in at the deep end straight away. Furthermore, it gave me the opportunity to get to know some of the other new starters who I would be working with. This really helped us to establish some grounding before immediately starting to work as a team — I can imagine this being extremely useful in the long run as we progress in our careers at Zuto.

After the induction week, we were set our first team project. This was a really nice way to get the new starters introduced to the way in which the tech teams at Zuto work and how they approach a task. Myself and Phoebe, two Junior Engineers, were able to work with Michael, a Senior Engineer. We were both guided through the project and received a lot of handy pointers on best practices as well as the general ‘do’s and don’ts’ when working with a company’s code. Zuto use C# for their backend development, a language I had not worked with before, so it was quite a challenge to approach a project in a coding language I was not familiar with. It can still be a lot to keep up with, but I am lucky enough to be supported by a team that is willing to put time and energy into my development and learning. I was able to get started on some online courses whilst simultaneously learning on the job via paired and mob programming; it was really reassuring to hear that the company would mould my training to what methods of learning suit me best.

What most impressed me when starting at Zuto was the sense of community that exists within the company. From day one, I was made to feel welcomed and accepted into the workplace, and even whilst the majority of us are working from home, I still feel as though I am connected to my team and everyone is supporting one another.

When I had initially been searching for a job, what mattered most to me was finding a company that would recognise my potential as a coding bootcamp graduate and give me the support to grow within my first role. With Zuto, I have found exactly that.

So what have I learned from my experience?

1. Don’t be hard on yourself - It is perfectly valid to be nervous when starting a new job, regardless of the industry. The only person you must overcome when feeling like this is yourself!

2.Nobody expects you to know everything - It is your dedication and willingness to learn that matters most.

3. Ask questions - This is the only way you can learn!

I am excited to see what lies ahead in my career at Zuto and I can’t wait to learn more about the industry!

Hi there, and welcome to the blog.

As you can see, the blog focuses on technology at Zuto.

I thought that having the blog would give everyone the opportunity share their knowledge - without the pressure of talking in front of people. It also gives us something to look back on in the future to see how things have changed and developed.

I want to invite everyone to write a post on areas in technology which might interest them. You might have an opinion on tech stacks, or new developments within Zuto or the general technological world.

Squads can share their successes.

Zutonites can share their stories.

Maybe you are learning something new in your 10% time and want to share your progress; who knows, you may also start a conversation or inspire others' to also try learning something new.

Get in touch if you would like to contribute or want to discuss any ideas.

What is Password-less Authentication?

SSH Password-less Authentication is basically having the ability to log-on to another remote server without having to enter a password. This is particularly useful when you want to automate tasks/jobs such as zipping-up a directory by using a script, or even for remote command execution.

You should consider using SSH password-less authentication when you are dealing with a number of remote servers. By adding public keys to a file, you can eliminate the whole process of exposing a password elsewhere.

Using Password-less authentication now means we don’t have to put our passwords in continuous integration. Therefore meaning that we don’t need to share passwords between team members, thus making the password less accessible.

Why start using Password-less Authentication

In some cases, you may need to use Password-less Authentication for running commands on a remote server. Before having Password-less Authentication setup on the server, you probably would have used a password that was being stored / remembered somewhere. This is not very secure as the password could easily be found. However, once you have setup the Password-less Authentication, the key is less accessible, therefore making it a lot more secure.

Passwords Vs Keys

Passwords are strong right? Doing some research suggested that they can take seconds to crack if they do not contain any special characters, capital letters or numbers.

RSA Keys - It would take approximately 1.5 million years with a standard desktop machine to crack a 2048 bit key.

Passwords - It would take roughly 6 months with a standard desktop machine to crack a 10 character password containing special characters.

How to set it up

First of all, you will need the SSH keys for the server that you’re using.

• Log onto the box you want to connect to
• Navigate to ~/.ssh/
• Copy the public key into the authorized_keys file by running this command ssh-copy-id -i ~/.ssh/mykey user@host

If the SSH keys need to be regenerated, then you will need to follow these steps:

• Logon to the box that you want to connect from
• If it’s a different user, impersonate using
  sudo su - username
• In the home directory, run
  ssh-keygen -r rsa
• Don’t set a password
• It will generate the file at HomeDirectory/.ssh/id_rsa.pub
• You will need the public key to be added to the box you want to connect to
• You should now be able to ssh onto the box from the client machine, without the password.
  e.g. ssh username@hostname dir