Cijin

When reading about Race conditions in go, I came across runtime.gosched() which I glanced over but did not clearly understand. So went through the docs to understand what it does. This is what the docs says it does:

Gosched yields the processor, allowing other goroutines to run. It does not suspend the current goroutine, 
so execution resumes automatically.

When I read this, I did not clearly understand what it does, cause I did not understand what yield meant. This is the best definition that made sense in this context: To give over possession of, as in deference or defeat; surrender.

Cijin

Mutexes

A mutex is named after the concept of mutual exclusion. Which is what they do as well. They lock a block of code till execution is complete for another go routine to access it.

Example from Go In Action:

package main

import (

Cijin

Unbuffered Channels

Before I talk about unbuffered channels, let me recap what channels are and how they help make concurrency easier in Go. Channels synchronize go routines as they send and recieve resources they need between each other. When declaring channel we use the make keyword along with the type of data that we are going to share.

Unbuffered and Buffered channels behave differently and understanding both will help you decide which one is more suitable in a given scenario.

Unbuffered channel is channel with no capacity to hold any value before it's recieved.

Cijin

Buffered Channels

A buffered channel is a channel that can hold one or more values before they are recieved. There are also different conditions when send and recieve will block:

• Recieve will block if there is no value in the channel
• Send will block if there is no space in the buffer for the incoming value

Creating an unbuffered channel

var bufferedChan = make(chan int, capacity) // where capacity is the number of ints the channel can hold

Cijin

The idea came to me while I was petting my cat of all times and I remembered an interview question that I was asked once that I royally cocked up. That interview has had the greatest impact on how I think as a developer or person. Why? Let me give more context first.

The interview question was simple, it was a bracket matching question similar to what a linter would do. i.e. Given an input of string, check if an opening bracket is accompanied by a closing bracket and the order matters (I forgot about that "tiny" detail when I started to solve the problem 😁). Ex:

Input : {[( )])}

Cijin

I gave the term "over-engineered" a whole new meaning, when I set out to create the devblabber website.

1 Year ago:

The goal was to create a simple blog website and learn AdonisJs (v5) which was recently released. Overkill would be an understatement. Took me a couple of weeks to write the UI using React which was totally not neccessary. Then once I headed to the server side. Things got out of hand really quick, I set a postgres server with redis which was the easy part still unnecessary. The project started to get features like people being able to login and comment on blogs. So got sidetracked and looked at how facebook handled comments, likes and etc (I know, I know). This continued for a few more weeks till a couple of months later when I started work and the project just sat there and there was no blogsite.

Cijin

Cats: Teachers in furry clothing

Although I find all animals and plants as all the mentors you will need in life. Grit from knucle dragging seeds, persitance from ants, kindness from dogs, selflessness from trees, curiosity from seals... and more

I picked cats cause I have two and I get to observe them more than any of the above as I work remotely from home as a software engineer

These are some of the things my cats have taught me:

You are a child of god, no less than the sun and the stars. So treat yourself that way! Don't go chasing affection, attention

Cijin

Select

To be candid I never really understood what select statements did. I understood that they handled values returned from channels similar to a switch statement, minus the channels.

It wasn't until I went through the Select chapter of TDD with go, that I really understood what they did.

Understaanding select

What helped me understand was the the problem being solved in the chapter so I'll use snippets of those as my examples.

The question was the race to url using http.GET and return the faster one. Let's look at the initial approach

Cijin

The HandShake Problem

The Back Story

It's no ground breaking finding but an intersting one none the less. Was watching a movie based on a true story, one of my favorite things I took away from it was this; There was a challenging task in front of the kids in the movie, they had to do 12 months of learning in 8. So the teacher says, make life your problem, ask questions solve them, and ask questions of questions.

Now although the problem was aimed at teaching Maths, Science etc. I am a programmer so why not use the same ideology to improve coding skills. So here is one of them.

Cijin

The Why

TDD just works, it's simple to implement. Gives you confidence on the code you are writing. It can be a great form of documentation. Moreover on complex problems it can help you get started by breaking problem down.

Why now?

It's never to late start including tests. Regardless of the fact that you are scaling your operations, encountering a lot of bugs, lacking documentation, or starting a tight deadline feature, etc. From my humble experience, any time you save by not writing tests is offset by fixing bugs later on, most times more time that it would take to write the test. Plus, ain't nothing more scarier than pushing a change and wondering if something broke while your fixing a bug.