DEV Community: ayelishaamoah

Re-learning the basics

ayelishaamoah — Wed, 19 May 2021 16:53:47 +0000

As a developer, it can be easy to focus too much on the job at hand without taking the time to reflect on what we've learnt, so I wanted to give myself the chance to get back to basics and solidify what I've learnt and will see if there are any gaps in my knowledge that I can fill.

To do this I decided to work through some of the challenges set out on Frontend Masters. The first challenge I attempted was the Single price grid component.

The challenge

Users should be able to:

View the optimal layout for the component depending on their device's screen size
See a hover state on desktop devices for the Sign-Up call-to-action

My process

I started by setting up my project that involved creating a dedicated repository for all of the challenges, each challenge will have a README and be fully self-contained. I began by creating a bare-bones project with Create React App (CRA) that included TypeScript support. Then I added Storybook for the component library and Styled Components (A popular CSS-in-JS library) for the component styling.

Built with

Semantic HTML5 markup
Flexbox
Responsive markup
React
Styled Components
TypeScript

What I built

This is what I was trying to build

This is what I actually built

Thoughts

I chose to do this as a time-boxed exercise so that meant I couldn't spend as long as I would have liked to fine-tune the styling.

I think that my fonts are a bit off, specifically the font weight and spacing but if this was a real-life task, I'd hope to have a more comprehensive design document that includes font weights and line heights. I think you might get this level of detail with the paid tier of Frontend Masters and would make it easier to create a pixel-perfect component.

However, being able to spot those nuances and recreate them with CSS is an area for improvement - you might not always have the luxury of having a fully fleshed out design specification or design system.

I think I also should have used the same text content to make it possible to compare a like-for-like design.

What I learned/ refreshed

During this project, I refreshed my knowledge on the following areas of Frontend Development and learnt a couple of CSS tricks that I hadn't used before.

[Recap] Responsive design and how to use media queries to build responsive layouts
[Recap] Responsive font sizes - I tried using both em and rem and have decided that rem is more predictable
[Recap] Semantic HTML elements
[Recap] css transitions
[New] css filters


transition: filter 0.5s ease-in-out;

&:hover {

filter:  brightness(90%);

}

[Recap] Setting up Storybook
[Recap] SASS - mainly used the parent selector (&) example above
[Recap] Basic TypeScript for React Functional Components
[New] Styled Components (example below). I have recently used emotion (which is built on Styled Components) and wanted to compare the differences.


export const ButtonStyle = styled.button`

background-color: ${(props: ButtonStyleProps) => props.variant === 'primary' && theme.colours.secondaryOne};

`

}

N.B I think I will need to spend a bit more time using Styled Components before comparing as I'm not sure if the way I am using props is the most efficient approach - this seems much cleaner in Emotion if you have a few styles that need to change based on the same property that is passed into the component.

I would also like to explore theming with Styled Components - this is easy with Emotion and I would like to see if it's as straightforward with Styled Components

Continued development/ next steps

Deploy the component library so that I can add a publicly accessible link to these posts
Rebuild the component using CSS grid (or think about using grid in an upcoming project)
Read more about accessibility and see if there are any updates needed to bring the component in line with accessibility standards
Think about how small the 'atoms' should be when designing components

Useful resources

Storybook - I have enjoyed working with Storybook as you can create smaller components in isolation and then bring them together

Here is a link to the repository, if anyone has any feedback on how to improve the component that would be hugely appreciated.

Any feedback on the article itself would also help me out for posts I write in the future.

Test Driving FizzBuzz

ayelishaamoah — Wed, 05 Jun 2019 23:05:05 +0000

What is TDD?

Test Driven Development is a development approach that involves writing your test first and then writing the simplest code that allows you to pass that test, allowing tests to guide your application code. This process is repeated as many times as it is required.

Unit testing

Unit tests should test a single unit of code - generally a method/ function and should only be concerned with the output of that unit. We can use tools such as mocks, stubs and testing frameworks to make unit testing easier.

Generally unit testing consists of four parts:

setup - the system under test (usually a class, object, or method) is set up e.g account = Account.new
exercise - the system under test is executed account.deposit(1000)
verify - check the result against the expectationexpect(account.show_balance).to eq 1000
teardown - reset the system under test (usually handled by the language framework)

TDD process

A common approach to TDD is the Red-Green-Refactor lifecycle:

Red - write a failing test
Green - write the simplest code to pass the test
Refactor - clean up the code that was written

TDD in swift

As I'm beginning my journey with swift I am interested in gaining exposure to the XCTest framework. In order to do this I will attempt to TDD a basic FizzBuzz app. This involves starting a project in XCode.

Fizzbuzz is a programming Kata that can be used to learn TDD and is a great way to explore TDD in a new language.

Process

Create a file for the tests
Write the first test e.g

    func testIsDivisibleByThree() {
        let brain = Brain()
        let result = brain.isDivisibleByThree(number: 3)
        XCTAssertEqual(result, true)
    }

XCode will throw some errors that you will want to resolve step-by-step.

Import the app into your test file by placing@testable import FizzBuzzat the top of file underimport XCTest
Write the simplest code to pass the tests

class Brain {
    func isDivisibleByThree(number: Int) -> Bool {
        return true
    }
}

Run the tests using ⌘ + U

This process is repeated for each piece of functionality with refactors when code starts becoming repetitive.

Here is a great article on Medium Getting Started with TDD in Swift that I followed in order to build FizzBuzz in Swift.

Effective Debugging

ayelishaamoah — Sat, 25 May 2019 21:27:48 +0000

What is a bug?

A bug is an error or fault with a program that causes an unexpected or incorrect result. There can be many causes of bugs with some including issues with the code itself e.g typos, syntax errors and undefined variables or issues with unexpected behaviour which means that the code is running fun but the expected result is not being produced - unit tests are good at catching these types of errors e.g the below will show whether your program is producing unexpected results:

fizzbuzz
  prints Fizz if the number is 3 (FAILED - 1)

Failures:

  1) FizzBuzz prints Fizz if the number is 3
     Failure/Error: expect(fizzbuzz(3)).to eq 'Fizz'

       expected: "Fizz"
            got: 3

1 example, 1 failure

An important point to mention is that no matter your testing methodology, if you come across an error that does not have a test case already written, you should write a test case that reproduces the bug, this will help keep you focused on fixing that bug and highlight if that bug happens again.

What does a good debugging process look like?

1. Tighten the loop

The first step is to find where the error is originating from.

  2) RandomHappyEmoji::new returns a :D emoji as a string
     Failure/Error: super(HAPPY_EMOJI.sample)

     NameError:
       uninitialized constant HAPPY_EMOJI
     # ./lib/random_happy_emoji.rb:10:in `initialize'
     # ./spec/units/random_happy_emoji_spec.rb:11:in `new'
     # ./spec/units/random_happy_emoji_spec.rb:11:in `block (3 levels) in <top (required)>'

By reading the stack trace in the error message you can find the file and line number.

# ./lib/random_happy_emoji.rb:10:in `initialize'

The line above highlights file and line the error message is originating from. Error message contains a lot useful information to help point you in the right direction - although arguably some languages are more helpful than others.

2. Get visibility on the error

The next step would be to read the code where the error is located and see whether you can you follow what is happening in your code. Are there any tools that will help you see what your code is outputting at each step?
Ruby has the p command which can be used to return a value on a specific line, variable or method call.
JavaScript has console.log() and the debugger in your chrome dev tools

3. Make a change and run a test

Only make a change to the code when you have a clear idea of what is going on. Check if your test has made a change to the error message - if not you can undo that change.

One thing that I can't stress enough is making sure you read your error messages, on numerous occasions I have sat there scratching my head before noticing that the console is shouting something like 'unexpected token ; on line 5'. If you notice this happening it is probably time for a break.

Learning by translation

ayelishaamoah — Sat, 25 May 2019 18:27:00 +0000

Due to the rate of change a software engineer is faced with, being able to pick up new languages and technologies is crucial. One of the focuses at Makers Academy is being able to feel confident in saying "I can make anything", to me this means being able to feel comfortable working on unfamiliar technologies so that you aren't restricted to working on the same tech stacks throughout your career.

In week 5 of Makers Academy we discussed the concept of Learning by translation which involves taking a problem that you have previously tackled and trying to solve that problem using an unfamiliar language.

By focusing on programming concepts and patterns that transfer directly into another language can help to quickly get exposure to a new language.

Once you have an idea of the problem you want to solve, make a note of the concepts that you need to understand in order to solve that problem. For example one of the steps involves writing a for loop:

Ruby code

for variable in expression do
  some repeatable statement
end

for i in 0..5
   puts "Number: #{i}"
end

JavaScript code


for (variable; condition; increment) {
  repeatable statement
};

var i;

for (i = 0; i < 5; i++) {
 console.log("Number: " + i);
}

FizzBuzz is a good starter challenge to become familiar with a new language as it is a simple problem that uses core programming concepts such as loops and can be used to learn a new testing framework.

Although this is a useful approach to get a quick overview of some of the common functionality of a language that you know you'll need but it won't necessarily help you in the conventions of the language e.g Ruby convention suggests naming variables in snake_case for methods and variables but JavaScript convention prefers camelCase.

Long term growth

ayelishaamoah — Fri, 24 May 2019 11:45:57 +0000

As a Makers Academy student you are expected to be able to be in control of your own learning, this means that you have to leave any expectations of hand holding at the door. You are provided with broad goals that are meant to help you progress at Makers and beyond:

I am equipped for long term growth
I can make anything
I help my teams succeed

I've spent a bit of time thinking about what it means to be equipped for long term growth and I think that this involves being able to diagnose your own learning needs and making sure that you are using your time effectively - this is especially important at Makers where the amount you need to learn drastically exceeds the time you have during the course. The coaches explain pretty early on that we are in charge of what content we decide to use to help us reach our learning goals - this is both empowering and slightly terrifying.

Each week we have set learning objectives that we need to cover and are provided with resources that we can go through, there are also optional workshops throughout the week which go over some of the core concepts we are expected to understand.

Weekly Process

I usually start the week by having a look at the learning objectives and plan to attend any workshops that are scheduled as I find these more useful than reading through docs. Any topics that are not covered will be added to my to do list for the week.

Daily Process

I'll usually set myself 2-3 daily goals which should be measurable e.g:

I will take 6 breaks throughout the day
I will spend an hour at the end of the day consolidating notes taken during the day or making notes related to a learning objective You should be able to easily answer yes or no to whether the goal has been met - goals should be ambigious e.g I will start a project as you won't have a clear idea of what that actually means

I usually use work cycles to plan my day which works nicely with the Pomodoro as you can have short bursts of uninterrupted periods of work followed by short breaks.

This is something that has helped me plan and track and measure my daily learning as well as manage my own wellbeing - my initial approach of trying to force my way through a problem wasn't getting me very far and working for long periods of time meant I would burn out by the end of the day.