DEV Community: Ochuko

2025: The Year of Discomfort and Growth

Ochuko — Fri, 03 Jan 2025 17:17:26 +0000

2024 was comfortable... a little too comfortable. For the first time, I understand the saying, "Comfort is the killer of dreams." There was so much left unaccomplished as I settled into a rot of comfort mid-year. This rot would go on to follow me till the end of the year. I watched as my peers achieved incredible feats while I slipped quietly into the bed of comfort. Unfortunately, I didn't realise this until it was too late in the year, unable to find the zeal to break out of it.

The past year has taught me that one of the worst things you can do to your dreams is to be comfortable. It reminded me of when I interned at a large company; I had multiple conversations with top management staff, asking for career advice, and one thing they all told me was never to be comfortable. They had all explained how they let go of their dreams because they had settled for comfort, and somewhere along the way, I had forgotten about this.

Seeing the year fly by with many items on my to-do list left unchecked disappointed me. How did a year that started so strong turn out like this? Did I lose discipline? Did I burn out and never recover? That feeling of disappointment and regret is something I can never forget.

Another thing I realised was that my full-time job took up way more energy than I wanted it to. I love what I do, but it always feels like a chore, and when the day is over, I just want to rest and get "comfortable." After all, I spent the last 8 hours doing a "chore". Maybe comfort isn't the right word; perhaps I was just lazy. One thing I did know was that when the monthly cheque came in, I was good; I didn't seem to need or want more. I do my "chore" and get paid. Everybody wins.

Well, this year will be different! I will commit to discomfort, growth, and competence.

We may not notice this, but our jobs can become boring if care is not taken. In software engineering, creating APIs that all look the same... building dashboard UIs with all the same elements and components. I wasn't growing. There wasn't a challenge. I had grown accustomed to doing the same thing, the same way, over and over again. Thinking back on it, I quickly realised that I only felt alive when battling a challenge or building something I was passionate about.

That got me thinking: What if I could make my job a battlefield? 🤔 This is the first step I am taking towards growth this year. What if I could spend most of my day improving my skills and growing more competent? As David Hansson would put it: don't just make it work or make it fast; make it beautiful!

I will spend every moment of my job wondering how to make it beautiful. I spend most of my day doing this "chore", and what better way to grow my expertise and career? No more code that just works or features that just meet the criteria. It must be beautiful and reek of competence; it must be excellent.

The next step is defining S.M.A.R.T. goals for myself outside my work schedule. Everything broken down into timelines, with quarterly, monthly and weekly targets, as well as defining daily habits that can help me work towards them. Everything will be tracked and measured, and shortcomings will be recorded and reviewed at intervals.

No more going through the motions, hoping to make time to work on that side project or continue that course. I have to be meticulous and practice strict time blocking. I have to create a boundary between my full-time job and my personal time so I can change my mindset and lock in on what I need to achieve that day for myself. I have to be consistent and track my progress and growth with realistic and measurable targets.

2024 was an eye-opening year for me. I would never have thought being comfortable would be a bad thing. I guess in certain situations it isn't, but when it comes to your dreams and aspirations, it's one of the worst things you can do to yourself. I have learned from my experience and hope you can learn from it too.

I look forward to a year filled with discomfort and growth!

Happy New Year everyone 🎉🎆! I hope you have a fantastic year ahead!

Thank you so much if you made it this far; I appreciate the time you spent reading this 🥹. Please feel free to leave comments on some of the strategies you're using to achieve your goals this year, and let me know if you have any questions or suggestions for me. Thank you once again!

The Battle of the Units: PX vs REM vs EM (font-size)

Ochuko — Sun, 11 Sep 2022 17:33:36 +0000

In this article I'm going to go through a few CSS units for customizing the font-size of text when building webpages. There are a lot of other units such as pt, pc, ex, etc. I will be focusing on the 3 most popular units; px, em, and rem.

A lot of developers don't usually understand what the differences between these units are (I didn't either, until much later in my career); so I'm going to try to explain them as clearly as possible.

Let's jump right in! 🚀

PX (pixel)

Pixel is probably the most used unit in CSS and are very popular when it comes to setting the font-size of text on webpages. One pixel (1px) is defined as 1/96th of an inch in print media. On computer screens however, they are not usually related to actual measurements like centimeters and inches like you may think, they are just defined to be small but visible. What is considered visible is dependent on the device.

As we know, different devices have different number of pixels per inch on their screens, this is known as pixel density. If we used the number of physical pixels on the screen of a device to determine the size of content on that device, we would have a problem making things look the same across screens of all sizes. That's where device pixel ratio comes in. It's essentially just a way to calculate how much space a CSS pixel (1px) will take up on the device's screen that will enable it look the same size when compared to another device.

That might have been a lot to take in 😅, let me simplify a bit. Basically, different screens have different number of pixels (pixel density) and computers perform some calculations to ensure consistency in the size of content being displayed on screens, regardless of the pixel density.

I didn't do justice explaining this as this isn't the primary focus of this article but you can check out this video or this article for a more in-depth explanation.

Moving on...

Let's look at an example below.

A dash of HTML:



<div class="container">
  <div>
    <h1>This is a paragraph</h1>
    <p>
      Lorem ipsum, dolor sit amet consectetur adipisicing elit.
      Reprehenderit incidunt perferendis iure veritatis cupiditate delectus
      omnis at! Officiis praesentium officia, nemo veniam consequatur
      nostrum sunt aliquid ipsam, corporis quas quaerat. Lorem ipsum dolor
      sit amet consectetur adipisicing elit. Hic quam beatae voluptatibus
      amet possimus iure impedit assumenda distinctio aliquid debitis, autem
      vel ullam aut, quod corporis ratione atque ducimus dolorum.
    </p>
  </div>
</div>

A sprinkle of CSS:



* {
  font-family: Arial, Helvetica, sans-serif;
}

.container {
  width: 100%;
  height: 100vh;
  display: flex;
  justify-content: center;
  align-items: center;
}

.container div {
  max-width: 500px;
  padding: 5px 20px;
  border: 1px grey solid;
  border-radius: 10px;
}

p {
  font-size: 16px;
}

And voila!

The top box is how it looks when displayed on a larger screen like a laptop, and the bottom box is how it looks when displayed on a smaller screen, like a phone.

Notice how the text in both boxes are of the same in size, That's basically how the pixel works. It helps web content (not just text) look the same size across devices.

You can test it out for yourself on codepen here: https://codepen.io/pedoch/pen/vYjEOzO

EM (M)

The EM unit got its name from the uppercase letter 'M' (em) as most CSS units come from typography. The EM unit uses the current font-size of the parent element as its base. It can essentially be used to scale up or scale down the font-size of an element based on the font-size inherited from the parent.

Let's say we have a parent div that has a font-size of 16px. If we create a paragraph element in that div and give it a font-size of 1em the paragraph font-size will be 16px. However, if we give another paragraph the font-size of 2em that will translate to 32px. Let's take a look at the example below.

A splash of HTML:



<div class="div-one">
  <p class="one-em">1 em based on 10px</p>
  <p class="two-em">2 em based on 10px</p>
</div>
<div class="div-two">
  <p class="one-em">1 em based on 10px</p>
  <p class="two-em">2 em based on 10px</p>
</div>

A drizzle of CSS:



*{
  font-family: Arial, Helvetica, sans-serif;
}

.div-one {
  font-size: 15px;
}

.div-two {
  font-size: 20px;
}

.one-em {
  font-size: 1em;
}

.two-em {
  font-size: 2em;
}

And tada!

From the screenshot above we can see how EM can scale up the size of text and how they are affected by the current font-size inherited from their parent container.

You can test it out on codepen here: https://codepen.io/pedoch/pen/ZEoEZMe

Before you get all excited, I must warn you... it's not advisable to use EM especially within complex structured pages. If not used properly, we might run into scaling problems where elements might not be sized properly based on a complex inheritance of sizes in the DOM tree.

REM (Root EM)

Last but not least, REM. This works almost the same as EM, but the main difference is that REM only references the font-size of the root element on the page rather than the parent's font-size.

The root font-size is the default font-size specified either by the user in their browser settings or by you, the developer.

The default font-size of a web browser is usually 16px so therefore 1rem will be 16px and 2rem will be 32px. However, in a case where the root font-size is changed to 10px for example; 1rem will be 10px and 2rem will be 20px.

Let's look at an example to make things a bit clearer.

A pinch of HTML:



<div class="div-one">
  <!-- EM -->
  <p class="one-em">1 em based on container (40px)</p>
  <p class="two-em">2 em based on container (40px)</p>

  <!-- REM -->
  <p class="one-rem">1 rem based on root (16px)</p>
  <p class="two-rem">2 rem based on root (16px)</p>
</div>

A smidgen of CSS:



html {
  font-size: 16px;
}

* {
  font-family: Arial, Helvetica, sans-serif;
}

.div-one {
  font-size: 40px;
}

.one-em {
  font-size: 1em;
}

.two-em {
  font-size: 2em;
}

.one-rem {
  font-size: 1rem;
}

.two-rem {
  font-size: 2rem;
}

And boom!

As you can see, the paragraphs defined with REM units are completely undisturbed by the font-size declared in our container and are strictly rendered relative to the root font-size defined in the html element selector.

You can test it out on codepen here: https://codepen.io/pedoch/pen/qBYEWjg

The Verdict:

Now that you understand how each unit works, I'll tell you which unit wins this fierce battle for me and why.

As mentioned earlier, I would not recommend you use EM due to the possibility of having a complex hierarchy of nested elements. This can cause problems because EM is relative to the font-size it inherits from its parent, meaning text size can scale uncontrollably if not managed properly.

Bye bye EM👋🏽

Now PX and REM basically have the same effect on text; as we would get the same result if we used 32px and 2rem. This is because the default root font-size is 16px.

But REM has an advantage when accessibility comes into the picture.

When considering accessibility, we want users with limited vision to be able to read content on our websites comfortably. One way they can tweak the size of text on the screen is by using the browsers zoom functionality.

The zoom functionality (shown above) works perfectly fine for both PX and REM. However, there's another way this can also be done. This is when the user changes the default font size from the browser's settings. This method allows the text on the user's screen to appear larger or smaller by default based on how they configure it. This frees the users from having to manually zoom every page they visit. Let's see how REM and PX perform with this method.

The first paragraph is set to font-size: 16px; while the second is set to font-size: 1rem;. As you can see, they are both the same size.

At the moment, my browser font size setting is on medium. Let's see what happens when I change it to very large.

The result:

As you can see the text set with REM was scaled appropriately with the new default/base font size we specified in the browser settings.

This to me is why I would definitely recommend using REM when working with text content on your web pages.

I think we have a winner!!! 🎉🎉🎉

Note: REM does have its short comings when dealing with other use cases like padding. I will cover this in a different article.

If you made it this far, I want to say thank you very much.

I haven't written a lot of articles before and I know I have a lot more to learn so if you have contributions or think I didn't get something quite right, please leave a comment; as this will help me to continue to learn and grow.

Once again, thank you for your time and have a lovely day 👋🏽.

Setting up SSH keys for a new device - GitHub

Ochuko — Sat, 04 Sep 2021 19:13:31 +0000

I got a new laptop and had to go through the pain for setting up my entire dev environment from scratch. After hours of downloading and installing tools I was ready to go. I tried to pull one of my old repos from GitHub and I got the good ol' Permission denied (publickey). That really sucked, not gonna lie, completely forgot about GitHub's SSH keys. Which is why I decided to write this post today.

I remember the first day I ran into this problem, it took me forever to find a solution. I hope this would make it a little easier for someone out there to get up and running in no time.

STEP 1

We'd first start by setting up our own public/private key pair set. This can use either DSA or RSA. Which means basically any key we set up will work, most systems use ssh-keygen.

First, we'd want to enter the .ssh directory. Open the terminal and run this command:

cd ~/.ssh

Next, we need to generate our own personalised ssh key, by running this command:

ssh-keygen

Now that our key has been generated, we'll need to copy it.

Note: the text that shows up after the command has been run is not what we need.

To copy the key, we'll need to run a command that is specific to whatever OS (and in some cases terminal) is running on the system so pick the one that fits your need.

Windows (Cygwin/Git Bash):

cat id_rsa.pub | clip

Windows (PowerShell):

Get-Content id_rsa.pub | Set-Clipboard

OSX:

cat id_rsa.pub | pbcopy

Linux:

cat id_rsa.pub | xclip

STEP 2

Next, we head over to GitHub to add the key to our account.
When we get there, we log in (if you aren't already logged in). Once logged we're logged in we'll see the profile icon in the top right corner of the page, click on it. It will open a menu like this:

Go ahead and select the Settings option.

In settings there's a side menu on the left, select SSH and GPG keys.

Now we're in the SSH and GPG keys section, we can now add our new SSH key which we copied earlier.
Top right on the page you'll see a button that says New SSH Key, click on it.
We'll get a page like this:

In the Title field we'll give the SSH key a good description so we can know which device it belongs too. I normal use the make and year of the device, e.g. MacBook Pro 2020.

And in the Key field/textarea, that's where we paste the key we copied. Once we've done this, we can now hit the Add SSH Key button.

Once that is done, we'll see the key added to our list of keys:

STEP 3

We now need to configure our .gitconfig.
Open the terminal and run these commands.

To add our username to our git config we'll run:

git config --global user.name "example"

Replace "example" with your own username.

To add our email to our git config we'll run:

git config --global user.email example@example.com

Replace example@example.com with your own email.

Once this is done, restart the terminal and we should be good to go to.

I hope this was of help 😊.

PS: I know some of you use Personal Access Tokens, maybe I'll make a post for those too

My First Assessment Test and I Banged It

Ochuko — Tue, 13 Oct 2020 00:07:06 +0000

I finally gathered enough courage to click the link in my email. It had come about a week ago and I knew I was unprepared for it. It was a link to a HakerRank assessment test from Chili Piper. I had applied for a Front-End developer role. My data structure and algorithm skills were poor, yet I summoned the strength to put myself out there, I mean how bad could it be (unbelievably bad actually).

I read the instructions and saw there were just 2 questions to be done in 70 minutes, one React (Front-end), the other code (DSA). I said to myself "Of course I'll do the react question first!" since I had little or no experience in writing data structures and algorithms. To me the only data structure that existed was the Array.

I started the test and decided to go through the questions as one would do in a regular examination. The react question was quite straight forward. I was to complete a form that accepted name, email, phone number and blog URL. I was told to validate the fields using certain criteria and display "Form is Complete!" if all fields were valid and "Form is Incomplete!" if they weren't. Simple right? I decided to check out the DSA question, just to see if I may have been lucky enough to get an easy HakerRank question, of course I wasn't. The DSA question was titled "Airport Limousine" or something like that, bottom line, I had no idea what they asked me to do, so back to the react question, I guess. I'm quite experienced in React but I still felt the pressure, like I was drowning in the fear of failure or not being good enough.

Now this is the funny part. I managed to validate all fields successfully except the phone number field. I had about 30 minutes left, I thought to myself "I can definitely find a regex to validate this in 30 minutes". I was supposed to make sure that the phone number was 10 digits and that it didn't start with 0 or 1. I was able to complete the former. Here I was searching every possible site for a regex to check if the first digit of a phone number was 0 or 1, I had never seen 30 minutes fly so fast. I was so disappointed. I had come to the end of my very first assessment test ever and I failed to finish. My roommate walked up to me and asks what's up. I narrate my entire story to him and then he made a statement that'll change my life forever. He asked why I was trying use a regex to validate it when I could have just accessed the number like a string and used the indexing property to do the check. My heart dropped instantly. Basically, rather than looking for a regex is should have done something like:

var phoneNumber = 9237463281;

var phoneNumberString = phoneNumber.toString();

if(phoneNumberString [0] === 1 || phoneNumberString [0] === 0) 
    return false;

I wasted 30 valuable minutes looking for a complicated answer to a simple question. I guess that's what fear does to us, it blinds us from the most obvious answers to our problems. When we're afraid all we see is how hard the problem is, but not how easy the solution could be. I vowed that never would I allow fear to rule me again.