DEV Community: Katie Raby

Studying for my Certified Solutions Architect Associate with AWS Cloud Quest

Katie Raby — Mon, 14 Nov 2022 12:47:56 +0000

Recently I discovered an amazing new gamified educational platform for learning all about AWS - Cloud Quest! ☁️ I'm currently on the journey of studying for for my AWS Certified Solutions Architect Associate (SAA) exam, using Cloud Quest to supplement my learning.

Learn-by-doing with Cloud Quest

Cloud Quest is a role-playing game which gives you 'real world' scenarios to solve using your cloud skills as you help citizens within a virtual city.

The game comprises of lab exercises, quizzes, and architecture challenges. Tasks for the citizens give you the opportunity to learn by doing. Presented with learning concepts and an architecture plan, you have to solve the problem using a real AWS console environment. There is a guided aspect to the lab, and then a 'DIY' section which gives you a challenge to complete without guidance using the skills you've learnt.

For completing the challenges, you earn reputation points, gems to upgrade buildings, buy clothes or vehicles. I currently ride around on an unicorn inflatable for the pool, and before that I was moving around the city via paper airplane. There is a super fun aspect to the game, with it's retro looking graphics and you might spot a random giraffe crossing the road too!

Solve problems in the city, and earn rewards upon completing the challenges.

What I love about Cloud Quest in my experience is the learn-by-doing aspect, and getting actual experience doing things in the AWS console. For example, one of my most recent tasks was building a mini REST API with Lambda Proxy Integration using API Gateway + Lambda. Building real solutions gives me confidence that I know the theoretical and practical knowledge required for my exam.

The Certified Cloud Practitioner track on Cloud Quest is completely free, so you can give the game a try without commitment, and anything additional to that you can get a subscription to AWS Skill Builders which also includes 150+ additional skillbuilder sessions, Jam, and all the Cloud Quest tracks (including the Solutions Architect track i'm currently working on!). Other tracks available on the game are security, machine learning, and serverless developer.

Quick exam revision with mini games

There are mini games within Cloud Quest which involve answering AWS quiz questions. These quizzes are great to solidify my knowledge for my Certified SAA exam. Between taking on the lab challenges for citizens, I make sure to go around the city and take part in the mini games as I go along, to revise my learnings so far.

One of these mini games is becoming friendly with Pets around the city. To befriend a pet, you have to prove yourself by answering the quiz questions. Certain animals need a specific number of questions answered before they're impressed.

Example multi-choice questions could be:

Choose 3 statements which are true of S3.
An EBS-backed EC2 instance needs to be ____ before changing instance type. stopped

Complete quiz questions to earn the trust of animals around the city, and gain Pet Friends after you've proved yourself!

You can also enter Drone Capture Mode to play a fun mini game, shooting down drones throughout the city to earn AWS service cards. Some of the drones will carry a challenge in which you can use these cards to fill in the correct services within an architecture diagram. Seeing architecture diagrams and understanding how all the pieces fit together is key here.

Drones float throughout the city! You can enter Drone Capture Mode to shoot the drones down, and earn rewards

With so much to do in the game, it's so hard to get bored. I never imagined having so much fun learning and the gamification and rewards system keeps you playing for longer. I'm learning a lot in-game, and anything i'm not sure about, there are links to relevant documentation so you can read all about it. The solutions architect path on Cloud Quest is a valuable resource in helping me feel prepared for my exam. I'm learning around the services and architecture, and gaining practical skills I need to feel confident with using AWS.

Pomodoro Pairing

Katie Raby — Thu, 19 May 2022 11:57:45 +0000

Recently I started using the pomodoro pairing technique at work for pairing/mobbing sessions. As a team, we wanted to try something different to keep our focus during longer sessions. Since some of us had already used the pomodoro technique before, it seemed well worth giving it a try. There are a range of benefits to using this technique, and it has positively transformed our pairing sessions.

What actually is the pomodoro technique?

No, it has nothing to do with tomatoes! Okay, maybe a little bit. The pomodoro timer was given its namesake in the 1980s when Francesco Cirillo, a university student, used a tomato timer to measure his 25-minute interval study sessions. These short sessions became known as a pomodoro. In the pomodoro technique, work is broken down into intervals, typically around 25-minutes. Each interval is separated by a short break.

The pomodoro steps

Decide on a task
Set the pomodoro timer (25 mins, adapt to suit)
Work on the task
When the timer finishes, take a short break (typically 5 mins)
Repeat steps 2-4 until you've done 3 or 4 pomodoros
Take a longer break

Pomodoro pairing

To start using the pomodoro pairing technique, take the above pomodoro steps and adapt them accordingly to fit your pairing or mobbing sessions.

A great tool to use is Cuckoo Timer, especially for remote teams. To get started with Cuckoo, create a shareable link which opens a new session for participants to join. In the sessions sidebar, there is an option to use the pomodoro technique, which displays the suggested work and break lengths to select from. Using a tool such as Cuckoo is a great way to ensure that everyone in the session each hears the alarm, and can hold each other accountable to the timer so that sessions don't run over.

Cuckoo interface, with a 'Use the Pomodoro Technique' option in the sessions sidebar.

After each pomodoro, choose a different driver to ensure that all participants in the pair or mob get the opportunity to regularly switch roles. Once the new driver is set up and ready to code, start the timer again for another pomodoro.

You may find yourselves drifting off too far from the task at hand during the session. If this happens, recognise it, and bring yourselves back to the task at hand. A good rule of thumb is, at the end of the current pomodoro, if you're still working through a thought process, let that play out until the end then consider that the end of the pomodoro. Don't forget to take your break!

Some of the benefits myself and the team have discovered working in this way are:

Making sure we take enough breaks - very easily forgotten throughout the day! ☕️
Having a healthy social break and time to yourself
Working for shorter time intervals keeps navigator(s) focused on the session at hand
Regular switching of pairing roles gives ample time in each role
Manageable work sessions allow other team members to drop in and out
Work (and commits) are broken down into manageable chunks

It's safe to say there are a lot of benefits to using this technique. The team loves it, as do I! I'm an advocate for this technique, and highly recommend you give it a try during your pairing sessions. Let me know your thoughts! 🗣

Additional resources

Pair programming explained (and other techniques you can employ)

Using testing-playground with React Testing Library

Katie Raby — Mon, 18 Apr 2022 18:00:33 +0000

React Testing Library is a popular testing utility tool for front-end testing.

Challenges can arise using React Testing Library, when trying to work out how to target an element.
A logical option may be to add a data-testid attribute to the element you want to target. Yet, there are a few downsides to this approach.

According to the React Testing Library guiding principles,

The more your tests resemble the way your software is used, the more confidence they can give you.
-- Kent C Dodds

We can often spend time testing implementation details. Using the data-testid attribute on an element is only testing that the element exists. Our focus when testing should be on the user, for example, what the user sees, or how the user interacts with it.

It can be a struggle to work out how to target elements without the use of data-testid...

Thankfully, we have the testing-playground!

The testing playground is a tool which gives you a visual representation of the DOM, and helps you discover the best queries to target elements.

How to access the playground from within your tests

There are two ways you can access the playground:

Logging the testing playground from within a test generates a link within your console when you run your tests, which you can open in the browser.

import { screen } from "@testing-library/react"

     it('test it block', () => {
       ...
       screen.logTestingPlaygroundURL();
       expect(...)
     })

Call the debug method screen.debug(), which prints out the DOM output. Copy and paste the DOM output into the testing playground directly.

Once the playground is open, you can navigate around it using the inspect-tool, much like the developer tools 'inspect'. When you inspect an element in the visual DOM, selecting it will display the suggested query to copy into your tests. The display gives you information about accessible and semantic ways to query your element. For example, buttons can be targeted using the accessible role of button.

The testing playground provides you with direct feedback when you make edits to the code. The playground displays improvements you can make to your code and queries, for example how to make your queries more specific by adding a name. Using the suggested queries is preferable to using the non-specific test-ids.

Another helpful use of the testing playground is to confirm what elements are visible in the DOM. You may be expecting to see a success message after a user clicks a button. If your test fails you can use the playground as a debugging tool to see what is visible to the user. Alternatively, you can use screen.debug() for the DOM output.

In summary, the testing playground is a great tool to use in conjunction with React Testing Library 🐸
Give it a go, and see how it can improve your testing skills.

Open Source: Tiny Contributions, Big Impact

Katie Raby — Mon, 27 Sep 2021 12:01:00 +0000

Open source software (OSS) is software that’s freely available to use, redistribute, and modify, typically shared via a public code repository hosting service. - Lyn Muldrow

The prospect of contributing to open source may feel daunting, or you may spend hours searching for a feature to build that perfectly fits your skill set. Sometimes by looking to make "big contributions" to a repo, or overthinking the process, you can rule yourself out and miss the opportunity to contribute at all.

Open source is for everyone, and even making tiny contributions can have a big impact.

TINY CONTRIBUTIONS

So what's the magic of making tiny contributions?
Making a small contribution to an open source project is a great way to introduce yourself to a new repository/project, learn something new, make a first contribution, or make a change in a technology you're not so familiar with. I can promise you, it's 100% worth it!

Some examples of meaningful tiny contributions to a project may be anything from fixing broken links or adding content to documentation, to fixing an alignment issue in CSS, or deleting unused code.

Note: creating a pull request (PR) to remove whitespace, or similar, may be considered a 'spam' contribution, so please try to target meaningful contributions only. A way you can do this is to work on already open issues that have need to be fixed. If unsure, please contact the maintainer of the project to be sure 🙂

BIG IMPACT

When you think of making a big impact contribution, your first thoughts might be fixing a critical bug, or implementing a major feature. However, your tiny changes can have a big impact not only on the project, but on your own personal development. For example, this could be making your first pull request to open source, or learning something new about the technology you're using.

Tiny contributions:

Build your confidence
Get you started on the journey of contributing to open source
Provide learning opportunities, which could be related to a certain technology, or using a new commit message convention
Get you involved in the open source community. During the process you may get to chat to maintainers and build relationships, or reflect on your contributions in a twitter post
Introduce you to setting up for contributing to a different codebase, and follow contributing guidelines
Allow you to make small contributions to your favourite repos
Fix small yet important issues - fixing that broken link may help any developer coming to read that documentation. Your contributions could have benefits for maintainers, the community and end-users to name a few!
Gives you the opportunity to work with new technologies you haven't used before and get exposure to new code, without committing to a large task.

From making a tiny contribution, this could give you the confidence, skills, community and experience to thrive and enjoy every contribution you make to open source - that's a huge impact! 🚀

⭐️ Get started today with making tiny contributions to open source and experience the big impact of your changes ⭐️

Planning to contribute to open source for the first time? find more information, with a step-by-step guide here.

Hacktoberfest is right around the corner! 🎃 Engaging in Hacktoberfest is a fantastic opportunity to find issues and get started in open source (and maybe even plant a tree 🌳). Special shout-out to @CockroachLabs for giving me the opportunity to make a tiny change, with big impact, being my first ever pull request to open source (Hacktoberfest 2020). 🥳

Go: Packages, Variables & Printing

Katie Raby — Fri, 19 Feb 2021 16:42:17 +0000

Now that you've installed Go (see previous in series), follow me on the journey to writing your first Go program.

Find some of the key pieces of information you need to get started, such as how a Go file is structured, how to declare variables, and how to print.

Packages 📦

A good place to start in any Go journey is looking at the anatomy of a Go file, and understanding how Go files structure themselves using things called packages. Every Go program is made up of packages, and the main ( 😉 ) and most important package, where programs start running is called package main.

Packages are declared at the top of the file, and then below that you have any imports, which can either be grouped or split out (example below showing a single import).

Package names provide context for their usage, and when referred to elsewhere and accessing contents of a package, the package name is the prefix. i.e. fmt.Println() to access the Println function inside the fmt package.

Within the main package, you need a main function, which is the entry point for execution. An example main.go file looks like:

// your package declaration
package main

// your import statements
import "fmt"

// main function - the entry point of execution 
func main() {
    fmt.Println("Hello, World.")
}

Note: it is best practice to only have one main package and method within a directory - as there should be only one entry point to a program.

The great thing i've found about Go is that so many handy packages are included by default in Go's standard library, such as Math and Testing. Find the full list of Go's standard library packages here.

Which packages are your favourite? Let me know in the comments below! ⬇️

helpful tip
When you are playing around with Go, creating the files from scratch each time (rather than letting the IDE fill this for you) will help you to get used to the structure of a Go file.

Variables 🐾

One of the first things you're probably wondering is how to declare a variable in Go.

The var statement declares either a single variable, or a list of variables, with the type at the end. If no type is provided, Go will infer the type of the initialised variable.

// declaring variable catYears as an integer
var catYears int

// initialising variable myCat to a string - type inferred
var myCat = "Hansel" 

// declares two variables, both of type boolean
var isCat, isDog bool

Variables can be written at package or function level. Inside a function, you can use the shorthand := syntax to declare and initialise a variable:

func main() { 
// variable catYears declared and initialised using shorthand
   catYears := 12
...

You can find all the different basic types in go here. More of these will be covered later in the series.

Printing / Formatting 🖨

To print or format in Go, you can use the "fmt" package (pronounced fumpt, used in the hello world example above).

Below are some of the most commonly used functions for printing and formatting.

Print - writes to standard output (stdout) can accept multiple arguments, spaces are added between arguments when neither are strings, returns number of bytes written and any error encountered (n int, e error).

fmt.Print(args…) (n int, e error)
fmt.Println(args…) (n int, e error) each print-out is on a new line

fmt.Print(1, true, 2)
// 1 true 2

fmt.Println("Hello")
fmt.Println("World")
// Hello
// World

Sprint - does the same as Print, but returns the resulting string instead of printing it to stdout. In terms of usage, you may be saving the formatted string to a variable for example.

fmt.Sprint(args…) string
fmt.Sprintln(args…) string

func main() {
  // resulting string is returned and saved into variable
  result := fmt.Sprint("Hello, World.")

  fmt.Print(result)
  // Hello, World.
...

Similarly to the above, there is also Fprint which prints the result to an external source, such as a file.

Formatting Strings

Printf(format string, args…) (n int, err error)
Sprintf(format string, args…) string

Both fmt.Printf and fmt.Sprintf can be used for string interpolation / formatting strings.

What is string interpolation?
"Evaluating a string literal containing one or more placeholders, yielding a result in which the placeholders are replaced with their corresponding values." (Wiki)

In short, you want a string to be dynamic and have values that could change, so, you put placeholders instead of static values.

In Go, these placeholders are also known as verbs. Both fmt.Printf and fmt.Sprintf expect a format string as their first argument - the format of the final string, including its verb placeholders.

An example of this in its basic form might look like:

var myName = "Katie"

// formatted string with %s as a placeholder for a string
fmt.Printf("My name is %s", myName)

Find more resources with examples and verbs for formatting below!

Running a Go program

A good place to wrap this intro up, is how you actually run your Go code.

$ go run filename.go

Don't forget that you can always use the Go Playground whenever you want to quickly try out a piece of code, or play around with something new!

Missed anything you think would be helpful to new Gophers? Comment below! 💬

Go: Installation, Setup & IDE

Katie Raby — Tue, 05 Jan 2021 19:54:38 +0000

A quick post on Go setup and installation for those following along on the Go journey with me.

My Setup

GoLand IDE (a JetBrains product), a cross-platform IDE built specifically for Go developers. I took the 'basic editing' GoLand tutorial and i'm really impressed with the features it offers, in terms of quick navigation and code completion. Normally for coding in JavaScript, I would use VS code - which i'm sure works well as a free tool for Go too, coupled with the Go extension.

Go Playground

If you don't want to install Go locally on your machine, you have the option to use the Go Playground, which runs your Go program in a sandbox environment, and is really handy if you just want to get started with minimal setup.

I'm currently working my way through the official Tour of Go which uses the Go playground alongside the information and tutorial. I am also using the playground if I just want to try something out quickly, without setting up local files etc.

Installing Go

To install Go, visit this link for the installation instructions.

Alternatively, you can use Homebrew:

brew install golang

Next: Verify Go has been installed, by checking your version in your terminal

go version
// go version go1.15.5 darwin/amd64

You're all set, and ready to 'Go'!

Introduction to My Golang Journey

Katie Raby — Thu, 31 Dec 2020 15:25:40 +0000

Unlike my other blog posts, this will form a series of blog posts focused on my personal learning journey whilst learning a new language - Go.

I'll be writing posts about Go basics as I learn or recap them, which will help me go over what I've learnt, give me accountability, and hopefully also help others following the same journey!

Why am I learning Go?

Since starting as a developer, I have mainly been working with the JavaScript stack and want to expand my skills to encompass other languages.
I love to learn and take on a challenge!
I'll be expanding my skills at work in 2021 to include Go. The back-end services are written in Go, and I want to be able to work across the full-stack.

What is my background?

Briefly, I started coding more seriously at the end of 2019, and graduated from my full-stack JavaScript coding bootcamp in May 2020. I started my role as a Junior Software Engineer in the July, and have continued to work and learn since!

What resources am I using so far?

A Tour of Go - the official Go learning tutorial
Frontend Masters "Go for JavaScript Developers" by Brenna Martenson
Notion for note-taking

Note: I am learning Go from the perspective of already being familiar with JavaScript.

The format of posts in this series will be free-flowing. Feel free to post any advice or resources in the comments below ⬇️

How I Changed Career from Marketing to Software Engineering

Katie Raby — Sun, 15 Nov 2020 10:54:45 +0000

Last year I was in an established marketing career, with no tech degree to speak of, and was convinced that making the switch to a new career in tech at this point in my life was near enough impossible.

Less than a year later, I started my career in tech as a Junior Software Engineer 💻 So here’s my story.

From dabbling in code for the very first time at the age of 12, and learning the basics in HTML and CSS, I found that there was an unmistakable pull and magical feeling about coding, a world where I could create anything I wanted.

Whilst at school, I never thought that a career in coding was even possible, nor had I thought of studying computer science an option. At many points in my life, I had tried to go back to coding ‘bits and bobs’, but had never fully committed myself to changing career.

After graduating from university in 2015 with a degree in International Business and French, I took an interest in marketing as a career as it would allow me to be creative and work across a broad range of disciplines. After a few jobs doing other things, such as a retail supervisor and recruitment consultant, I got a job working in marketing and communications for a global engineering consultancy, which marked the beginning of my career in marketing.

Once you’re fully embedded in a career, it can be difficult to make the change. You face all sorts of questions; how will I translate my previous experience into the tech world, or will my resume be impressive enough to land my first role. I had seen first hand working in a recruitment agency after university how challenging a career change can be, but I was determined. The focus for me ultimately became wanting to do a job that I would love and look forward to every day.

So what changed?

Over a year ago I attended a 2-day Django Girls workshop. Django Girls is a non-profit organisation created to inspire women from all backgrounds to get interested in technology, and interested I became! I learnt some Python and Django and created my first web application. I thoroughly enjoyed myself, and was curious to ask questions and learn more about each step of the process. The workshop re-sparked my love for code. At work, I took every opportunity to code when I could, by editing e-mail templates, and I developed a real thirst for solving problems and getting things to work.

I then began coding in the evenings after work, learning through online platforms such as FreeCodeCamp — where I started by working through the Responsive Web Design Certification. I also developed a love for coding pure CSS images, a digital expression of art through code! Coding in the evenings after work was difficult, but I developed a daily habit of coding via the #100DaysOfCode challenge, and would recommend it to anyone who wants to have fun, learn a lot, and hold themselves accountable to regular coding. I found out about this challenge at a local coding meet-up, and it felt fantastic to immerse myself amongst other coders.

It wasn’t long before I started looking into how I could get into coding full-time. One day, enough was enough. I was determined to make it happen. I took the plunge and handed in my notice at work. I was in a comfortable role, and something I could have continued doing for many years to come, but I wasn’t content with living inside of my comfort zone anymore when my true passions lay elsewhere. I knew how big a risk this was, leaving behind comfort and safety to pursue my dreams, and I had to at least give it a try.

I looked around at different options to start my career in tech, and settled on going to an in-person coding bootcamp, Northcoders, in Manchester, UK. During this time, I was active on LinkedIn, and whilst waiting for my course to start managed to secure myself some work at a digital agency working as a Junior Front End Web Developer. This was a fantastic experience, and solidified my decision to pursue a career in tech. It gave me the confidence that people believed in my skills, and that I could really make it into the industry.

What happened next?

I attended Northcoders bootcamp full-time, where I learnt everything from the ground-up on an intense course, finishing with building a group project, which for us was a full-stack mobile application geared towards helping people with their shopping during the pandemic. Though there are many different routes into the coding industry, a bootcamp worked really well for my learning style and gave me the skills to be able to build projects independently.

After bootcamp, I continued to learn and found ways to differentiate myself in the industry and build my brand, writing blog posts about things I had learnt and interacting with the developer community.

When it came to job searching, I had a portfolio of projects that I had built, and a CV showcasing my development experience and transferrable skills from my career in marketing, including project management, design and communication. Even though you may be looking to change career, don’t underestimate the value of skills you have developed thus far in your life or career. There is more to a career in development than just the coding!

What advice can I offer to you, looking to change career to development?

Having read my story, it’s important to remember that this is only my story — everyone has a different story! There are many different paths into development, whether this be a computer science degree, a bootcamp, self-taught, online degrees or courses, apprenticeships, part-time study and more.

Look into the different paths into development and find what works best for you and your situation.
Get involved in the tech community, whether this be through local meet-ups in your area, events such as Django Girls, or the developer community online via Twitter or Linkedin.
Find things which spark your passion for code. Take advantage of the free resources online, such as FreeCodeCamp, where you can try out a range of languages such as JavaScript or Python.
Always keep learning, and never give up on your dreams!

Stay up to date with my articles, and feel free to connect with me over on Twitter, or Github. ✨

Top Tips For Developers Starting Their First Role

Katie Raby — Sun, 25 Oct 2020 17:17:46 +0000

You’ve just landed your first Developer role. Congratulations! 🏆

What now? How do you prepare for your first week? What are some things you should think about when you start?

Here are some tips for developers starting out in their first role (and beyond!).

ASK QUESTIONS.
As a junior developer you can never ask too many questions! Your colleagues and workplace should be more than okay with answering all your questions — this is your chance to learn as much as you possibly can.
WRITE DOWN YOUR QUESTIONS.
You don’t want to forget questions as they arise, and someone may not always be available to answer them for you, so it can be a good idea to write down your questions and save them for an appropriate time.
On top of this, it’s good to write down your questions so that you can also write down the answer, and refer back to it when you need to.
BE HONEST ABOUT WHAT YOU DO AND DON’T KNOW.
Being honest about your experience is never going to work against you. It shows that you understand your areas for improvement and have something to work on, and on the flip side, it’s your time to shine if you know there are certain things you are better at.
DON’T BE AFRAID TO OFFER OPINIONS AND IDEAS.
No matter your level of experience, your opinions and ideas are really valuable.
TAKE NOTES.
Any notes which you may find useful, notes about the technology you’re using, notes about the team, notes about any research you’ve done, coding snippets to remember for the future!
GET A NOTEBOOK FOR ‘BUGS’.
Each time you come across a bug, make a note of what you found, how you found it, and how you went about fixing it, and how you fixed it. You can then have a collection of error messages and bugs which are able to refer back to, each time you come across something and don’t remember how you solved it the first time.
GET A NOTEBOOK FOR DAILY ACHIEVEMENTS.
Every day, starting from day one, make notes of your achievements each working day. This is great for those days you may be feeling low and need reminding of all the things you have achieved in your career so far, or when you just want to look back at how amazing you are, and also great to keep a record when it comes time for a promotion! You have a daily record of your achievements to hand.
WHEN YOU GET STUCK, DON’T SPEND TOO LONG BEFORE YOU ASK FOR HELP.
Try to figure out the solution on your own first, but don’t let yourself spend two days trying to solve something which you could have solved in ten minutes with a little help! There will be a learning curve at first, but don’t let yourself get bogged down.
PUSH YOURSELF OUT OF YOUR COMFORT ZONE WHENEVER YOU GET A CHANCE.
Try new things, and push the boundaries of your comfort zone, whenever you get the opportunity. Take the reins and lead your daily stand-up, or present a new technology idea to your CTO.
BE PATIENT WITH YOURSELF.
A Junior Developer or not, you are starting at a new company with new processes and a whole new codebase to get yourself acquainted with! Give yourself the time and patience you need to get to grips the life-changing transition you have just made into your new job, and understand that there are always things to learn at every level of your career.
UNDERSTAND THAT YOU WILL NEVER KNOW EVERYTHING.
Don’t feel deflated when you realise that you don’t know everything there is to know at work. No matter the skills you came in with, the possibilities and learning potential of programming is infinite — you will never know all the things, and neither will anyone in your company, and that is completely okay. Use this as something to drive you and excite you, that you have chosen a career in which you will be constantly learning and improving!
TREAT EVERY MOMENT AS A LEARNING OPPORTUNITY.
Even if there comes a problem you already know how to solve, there could be a new way of looking at the problem that you hadn’t already thought about, or new ways to approach it, and new things to discover.
IT’S OKAY TO STEP AWAY FROM A PROBLEM AND COME BACK TO IT.
Sometimes you just need to step away and come back to a problem later. Get yourself a hot drink and come back after a break. Looking at it with fresh eyes again could help you solve it, and if not, it’s okay to get help on the problem.
FIND A MENTOR.
Whether this be someone in or out of work, having a mentor who you can talk to about your coding experience, career progression, and general wellbeing can be invaluable.
FAMILIARISE YOURSELF WITH RELEVANT DOCUMENTATION.
Find out what technologies your team uses, and look into the relevant documentation associated to get a feel for things before diving in. You may also find that your team will have their own internal documentation, documenting things such as how to use their API or tools. Familiarise yourself with this on your first few days, so you know where to go when you need information.
FIND OUT ABOUT THE BIGGER PICTURE.
You’re working on one piece, or multiple pieces, of the wider puzzle. Find out how all the puzzle pieces fit together in the bigger picture of the product you’re working on. Find out about the industry you’re working in, and how the product you’re making fits into that industry picture.
DON’T FALL INTO THE TRAP OF WORKING ALL THE HOURS UNDER THE SUN.
You’re new to a job, you’re excited, and you want to prove yourself. You are tempted to continually work after hours, but please resist this temptation — it is a recipe for burnout. You will be learning a lot every day at work, and your brain needs time away and rest to process the things you’ve learnt throughout the day. Take rest when you need it, and arrive fresh for the next day to learn a whole lot more!
NEVER FORGET ABOUT THE END USER.
Always keep in mind WHO you are developing for, and WHO will be using your product, this will help to guide your development and ensure you are doing and noticing things with the end user in mind.
SPEND TIME REALLY UNDERSTANDING WHAT YOU ARE DEVELOPING.
You can quite easily feel like you want to dive headfirst into writing code as quickly as possible — but without really understanding the codebase and the product can be detrimental to you in the long-run, and can leave technical debt for the team. Ensure you spend time understanding what you’re developing and how things fit together, to be able to make more informed decisions about your code.
ENJOY YOURSELF.
Congratulations for reaching this amazing goal and securing your first role as a Junior Developer. You have worked so hard and you totally deserve it. Relish the feeling of landing an awesome job, and enjoy yourself!

Live Art - Showing Support for Artists Through Web Monetization

Katie Raby — Fri, 05 Jun 2020 21:04:23 +0000

What We Built

We built a "Live Art" web platform to help artists gain monetary support through live art sessions, with payments being sent from supporters using the coil browser extension to the logged-in artist. The payment pointer stored in the meta tags will be dynamic - changing depending on which artist is logged in, to eventually allow for multiple "art rooms" with multiple artists, giving supporters the ability to pick a room.

Submission Category:

This submission falls under the Creative Catalyst category: projects that use existing Web Monetization technology to explore the creation, distribution, and discoverability of content online.

We wanted to submit a project under the creative catalyst category to demonstrate the wide usage of Web Monetization, focused specifically on helping freelance/ad hoc creatives to monetize their passions through the web.

Demo

Find our hosted Live Art here at this link.

If you are an artist you will need a payment pointer to enable micro payments to be made to your web wallet. Uphold offer a good service for this and you can sign up here.

As a supporter you will need a coil account and the relevant extension for your web browser. Find more info about getting started here.

Once logged in and the site is monetized, the artist will be able to draw on the canvas with the supporter able to view in real-time.

The supporter will be sending payments via their Coil browser extension as below.

Link to Code

Back-end Repo

katieraby / live-art-backend

RUNNER UP in the DEV x Grant For The Web Hackathon 2020, 'Live Art'. Web monetization hackathon project. Created using nodeJS, Express, Mongoose and MongoDB. MIT Licensed.

Live Art Backend API

Backend RESTful API for Live Art, serving up endpoints relating to storing artist data, logging in, and fetching artist data Endpoints available:

GET /artist
POST /artist
POST /artist/:username

Getting Started & Installation

Prerequisites

To run this API on your machine, you will need Node.js and MongoDB installed on your machine.

To install Mongo, go to https://docs.mongodb.com/manual/installation/

To install Node, go to: https://nodejs.org/en/download/
The version required is a minimum of v. 13.8.0

Installation

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes.

Clone a copy of the repository on your machine using the below command:

git clone https://github.com/katieraby/live-art-backend.git

Install the required dependencies:

npm install

For testing, install the required dev dependencies:

npm i -D mocha chai supertest

How to create your dbConfig (required)

To connect to your live mongo database, ensure…

View on GitHub

Front-end Repo

katieraby / live-art

RUNNER UP in the DEV x Grant For The Web Hackathon 2020, 'Live Art'. Show support for artists and creatives by viewing their live art display in a monetized environment. Co-created with bainesface.

Live Art

A web application using web monetization and socket.io to enable supporters to view live art and make micro payments to the artist.

The hosted version of this project is available here.

If you are an artist you will need a payment pointer to enable micro payments to be made to your web wallet. Uphold offer a good service for this and you can sign up here

As a supporter you will need an coil account and the relevant extension for your web browser. All can be found here

Once logged in and the site is monetized, the artist will be able to draw on the canvas with the supporter able to view in real time.

The supporter will be sending payments via their Coil browser extension as below.

If you would like to view the backend API for this project please find the code here.

Prerequisites

…

View on GitHub

How We Built It

Technologies used:

We started off by creating our mini back-end, using Express, Mongoose and MongoDB, in which we would store the artist's data, including username, bio, payment pointer and password (hashed), to enable artists to have a regular account in which they could login as an artist to Live Art.

We then moved across to our front-end and decided to create our socket server within the front-end file structure, to separate concerns. For our front-end web application, we used React and integrated the Canvas API to act as our artist's whiteboard during a Live Art session.

To integrate web monetization into our application, we needed dynamic meta-tags, in which the monetization payment pointer changed according the artist logged in. We used the React plugin react-meta-tags to give us component-like access to the meta tags, where we were then able to grab the artist's payment pointer ID from the socket connection, store it in state, and reflect this change in our meta tags for monetization.

To finish, we added some styling to our application using CSS modules.

The Future of Live Art

At present our product, on the date of submission, is our minimum viable product and has a few bugs which need fixing!

Improvements we would also like to make following the submission deadline include:

Adding a live chat to allow users to interact with the artist
Allow supporters to login with Coil Authentication
Adding additional styling
Creating multiple art rooms, so multiple artists are able to draw at the same time, with supporters able to choose which artist to support.

Team Members

Sarah Baines - Github
Katie Raby - Github

Final Word

Thank you to the DEV team for putting on such awesome hackathons, to allow developers the opportunity to explore new technology they wouldn't otherwise be aware of!

How to: Pass the AWS Certified Cloud Practitioner Exam in 2020

Katie Raby — Fri, 15 May 2020 11:49:42 +0000

Introduction

From knowing very little about cloud computing in general, I passed my AWS Certified Cloud Practitioner (CCP) exam after 8 - 9 days of study.
Find out how I accomplished this below.

What is my background?
I'm relatively new to the tech industry, having started coding full-time at the end of last year through a full-stack coding bootcamp. As part of my final bootcamp project we used Firebase for Cloud Storage, and this piqued my curiosity for cloud services in general, so I was keen to delve into this more after my course.

Why AWS?
Amazon Web Services (AWS) is very widely used in the industry, and in Q4 of 2019 held the largest market share amongst cloud infrastructure providers (Source), so I thought I'd start there!

Who is this exam for?
Regardless of your current job or title, this foundational exam is suitable for anyone who has an interest in building overall knowledge and skills around the AWS Cloud. If you are currently working with AWS and have a base knowledge, you may be able to complete this exam in a shorter time span.

You can find details about the exam format and skills areas from Amazon.

Without re-inventing the wheel, find details about which resources I used below and how I managed my revision for the exam.

Play to your learning strengths

Play to your strengths in terms of how you learn best - I like to watch, write out my own notes and read them back for revision.

To prepare for the exam, I opened up a notebook on Gitbook and had pages for these areas: Cloud Computing - Overview, AWS Integrated Services, AWS Core Services, Technology Overview, AWS Global Infrastructure, Architecture, Security, Pricing and Support, and Q&A.

As I studied the different areas, I made notes on each of the pages that I would come back to later to read through.

Gaining an understanding

I started with going through this 6-hour video course: AWS Digital Training - AWS Cloud Practitioner Essentials (Second Edition). As this is an official Amazon course, it was a great place to start and really gave me a broad overview of the key areas for the exam. BONUS: you receive a certificate of completion after this course, so you get a real sense of achievement!

I then worked through ExamPro's 4-hour CCP Training Full Course 2020 - a fantastic resource, and thanks to FreeCodeCamp this is completely ad-free for the whole 4 hours. Alongside this, I was also making notes in my Gitbook and screenshotting the overview slides which were really helpful for last-minute revision.

Though the above two videos were crucial to my success, they didn't cover all of the services which might appear on the exam. The questions can be finicky, so be sure to read the Overview of Amazon Web Services Whitepaper - absolutely essential to read (even at 95 pages long).

Practical skills

I wanted to gain some practical skills alongside my theoretical knowledge, so I started by creating an AWS account and had a play around with the AWS Management Console.

The aforementioned ExamPro course helped a lot with this too - as there are "follow along" sections, and before I knew it, I had created a budget with an alert, launched EC2 instances, created an auto-scaling group, an elastic load balancer, and added items to an S3 bucket.

Practice, practice, practice!

My Dad, and I'm sure many others before him, said "Fail to prepare, prepare to fail", and that stuck with me throughout this preparation. Once you have worked through gaining a base knowledge, you still need to go into the details and get lots of exam practice in!

To revise for the exam I went ahead and purchased 6 practice exams and responses. There are detailed explanations for both correct and incorrect responses following each exam, and it also shows you which areas you need to brush up on. I completed all of the exams, ensuring I reached 73% + in each.

I also worked through this short set of Amazon official sample questions.

Throughout any of the practice exams whenever I got an answer wrong, or wasn't sure about the answer, I added this to the Q&A section of my Gitbook notes. That way I could come back to the questions I struggled with whilst revising and quickly refresh myself.

On the days leading up to the exam I read the Overview of Amazon Web Services Whitepaper again, and filled any gaps by searching for helpful Youtube videos, such as this one on the AWS Shared Responsibility Model.

Summary

Here's a summary of all the resources I used, which were free (with the exception of the practice exam set on Udemy):

Practice exams -
Amazon Official Sample Questions
6 AWS CCP Practice Exams - paid resource

Whitepapers & AWS Website -
Overview of Amazon Web Services
How AWS Pricing Works
AWS Support Plans Info

Videos & Training -
AWS Digital Training - AWS Cloud Practitioner Essentials (Second Edition)
Exam Pro's 4-hour CCP Course
Selected videos from this AWS Products and Services official playlist
AWS Shared Responsibility Model - unofficial

Please comment or get in touch with any further questions relating to my preparation for this course. I hope this answered 'How to pass the CCP exam in 2020'. Good luck for your exam!

The Benefits Of Test-Driven Development (TDD)

Katie Raby — Sun, 29 Mar 2020 17:58:42 +0000

The idea behind test driven development is that you let the tests 'drive' your development process. How does this work? Start by writing a test that fails, then develop the code to make that test pass, then refactor. This cycle is called red, green, refactor.

*a diagram to show the red, green, refactor TDD cycle*

RED: The red phase is the starting point of the cycle, where you define expectations for the piece of code being tested, and let the test fail. Write tests starting at the lowest level, e.g. when the function is passed an empty array, return an empty array. Why let the test fail? So that you know you have written a good test - a test shouldn't be able to pass without any logic.

GREEN: Implement the necessary logic to make your test pass - don't worry about it being the most optimised or efficient at this stage, the goal is to pass the test!

REFACTOR: During the refactor phase, consider how you could optimise your code, without adding any additional functionality.

So, now that you know about the process, what are the benefits of Test-Driven Development?

The foundations are in place before you build the house

With TDD you can dictate exactly what you expect your code to do from the ground up. TDD forces you to think about exactly what you expect from scenario to scenario, which makes you more likely to cover all the bases.

TDD helps you to develop the logic in your code

By starting tests with the simplest functionality first, you can use them to guide your logic as you build up functionality. This helps you to break a problem down into smaller, more manageable pieces, thus aiding the problem solving process.

Very high test-coverage

Test-coverage refers to the percentage of your code that is tested. A high test coverage means that you can trust your code works because you have a large set of tests, and TDD allows for this because you shouldn't have any code written which doesn't have the associated tests.

Improved quality of your code

As you are specifically writing code to pass the tests in place, and refactoring at the end of each test; you ensure your code is clean and optimised without any extra pieces of code that you won't need.

Prevents bugs early on in the development process

As you are adding to the functionality of your code as you go along, you ensure that each stage of the code is working as you progress. Much better than writing a large piece of code, and trying to test it afterwards only to find that it fails!

Easy to add functionality to your code

With a high test coverage, you are simply adding to a very tested piece of code. This is great because you know you can rely on the code you already have, and can write additional tests to add functionality bit by bit.

Your code can be understood easily

One great benefit of testing in general (and using descriptive test statements!), is the readability this provides for others. Developers, testers and non-technical colleagues working on or around the codebase can identify exactly what the piece of code does without any guesswork - great for when you are working on an older codebase and want to navigate around it easily.

Want to try it out for yourself? Get started with some resources below:

Uncle Bob's Three Rules of TDD
Three Rules of TDD - Youtube Video
Kata - the Only Way To Learn TDD