Forem: Noaa Barki

Let's Go! Why Golang is the way to go :)

Noaa Barki — Mon, 19 Dec 2022 10:08:34 +0000

Not so long ago, while I was working on creating an outline for my upcoming Golang workshop one of my teammates came and asked me "Noaa, what is so special about Golang?". His question got me thinking “Why do I like this language so much?”, and I realized that I’m not really sure and maybe I don’t really understand Golang. So I decided to go on a new journey - my journey after the meaning of Golang.

In this article, we are going to talk about How Golang was invented in the first place, what is so special about it, when you should use it and why for those use cases I believe that Golang language is the way to go 🙂

Big thank you and credits to Karolina Rusinowicz, and Jacek Olszak who wrote “Why Golang may be a good choice for your project”. I learned a lot and used your article as a resource.

What is Go?

Go was developed by Google in 2007.
It was first released as an open source in 2009.
Go was designed just for that: to run on multiple cores and it was built to support concurrency. Concurrency in Go is considered very cheap and easy.

How Go was born?

A long time ago, in the early 2000, Google was growing exponentially. 📈 They grew so fast that they started to have a lot of scaling problems. They simply had too much of everything! Lots of software and systems, millions of lines of code being developed by hundreds of programmers, and finally lots of hardware on which all this software was launched.

In addition to that, Google’s entire source code was stored in one monolithic repository and their build took a huge amount of time. It was so long that to perform such a build, Google created its own build system to compile the code on many machines in parallel.

But... despite all this and many other optimization efforts, the time needed to build certain systems reached several dozen minutes in 2007.

This became a problem for a lot of other companies besides Google... 🌍
At that time, multi-core processors became common and the infrastructure became much more scalable, dynamic, and had more capacity. Using cloud infrastructure with hundreds of servers with multiple processors to deploy applications became universal. However, back then code compilation (mainly in C++) lasted too long and coding with threads and memory sharing (in C++ and Java) to write concurrent code was considered too complicated. Programmers made a lot of mistakes, and the code was often not optimized. In most cases, a thread was left waiting—and gobbling up resources like RAM and CPUs.

To solve this problem, alternative models of concurrent programming were created. 💡
An asynchronous model used especially in Node.js is one of them. However, it wasn’t so Promising 🙃 it was still complex for programmers to use and even much more difficult to debug. Additionally, there were many approaches to C++ and Java programming (which were the top languages for multi-threading) but none emerged as best-in-class.

This resulted in the code being difficult to manage and in needlessly long compilation times.

Fed up with these pitfalls, Googlers Robert Griesemer, Rob Pike, and Ken Thompson, decided to create a new language. This language was supposed to increase the productivity of Google engineers and allow them to use the company’s huge hardware resources more effectively. Since the most widely used programming languages at Google were C++ (mainly for servers) and Java/Python (the rest of the code), this new language needed to be similar to them so that programmers could learn it easily.

And this is exactly what they did. They wrote the code, published it as an open-source named Golang and they lived happily ever after. 🌈

Why Go?

CONCURRENCY MADE EASY

Go introduced an alternative model of concurrent programming, ****one based mainly on CSP language. This new model introduced goroutines which communicate with each other using channels (you can think about them as mailboxes). goroutines had several advantages over threads and memory sharing, one of them was that they were easier to understand which made the code much more simple and safe.
FAST PROGRAMS

Programs written in Go are executed fast and use little RAM. One reason why is because when Go code is compiled, it creates an executable file. This is not bytecode or any other intermediary code, it’s a machine code. 😎 Another reason is because of Go’s goroutine. A goroutine is a lightweight thread managed by Go runtime and it consumes fewer resources than threads in Operating Systems.
FAST BUILD
Go’s compilation is very fast because Go was designed to enable its compiler to analyze dependencies quickly and avoid loading files repeatedly. Under the hood, Go, compiles the source code incrementally, creating an object file for every package. so when somebody uses a specific package, it loads the previously prepared file.

Local Setup

In order to compile Go source code, Go requires two .env variables exists, $GOPATH and $GOROOT → $GOPATH pointing to the directory where the Go source code exists, and $GOROOT points to Go’s installation directory.

💡 Go v1.11 does introduce the concept of modules that allows you to have your project code outside of your GOPATH.

After installing Go, you have to configure your workspace.

Workspaces

A Go workspace is a directory stored on your local machine for your Go code. Go doesn’t require a special name or location for the workspace however, by default, Go expects all code to be in a single workspace. The reason why is for the compiler to operate at optimal efficiency. The path to your workspace should be stored in $GOPATH.

Inside the workspace there must be 3 subdirectories named by convention:

$GOPATH/src - for the code.

$GOPATH/pkg - stores archived files of packages installed in programs. This essentially helps to save compilation time based on whether the packages being used have been modified.

bin - stores all the compiled binaries.

File structure

go.mod

The package.json file for Go.
Modules are the Golang support for dependency management. A module by definition is a collection of related packages with a go.mod file at its root. All the modules which are needed to be used in the project are maintained in go.mod file.

The go.mod file defines:

Module import path.
The version of go with which the module was created
Dependency requirements of the module for a successful build. It defines both projects’ dependencies requirements and also locks them to their correct version.

go.sum

The package-lock file for Go.

This file contains all the project’s dependencies(a.k.a dependencies checksums) and it is managed by the go tools.

Packages

A package is the entry point to access a Go code. All go code is organized into packages and it simply consists of several.go files. You might be surprised to know that packages are the most powerful part of the Go language! (see “Why Go?. Fast Build” section).

Common packages structure

/cmd

In general, this folder contains the main entry point files for the project, with the directory name matching the name for the binary. In our project, this folder contains the main commands entry points. Each directory name matches the name of the command.
**/pkg**

This is the place to put public libraries. Usually, this may include API clients or utilities which may be handy for other projects but don’t justify their own project. The important thing to remember is that other projects might import these libraries, so we need to think twice when we make changes.
/internal

The internal directory is the place to put your private packages. If you put your code in an internal directory no external project will be able to import that code. Any code that lives outside of internal parent directory won’t be able to import this code.

Go 1.4 introduces an ability to hide code using internal directories.

Common best practices

Go projects often keep the core types grouped at the top of a file.
Organize code by responsibility, not by type.
Package names are often single form, lowercase (not snake_case or camelCase).

How To Fine Structure Your Project

Noaa Barki — Wed, 14 Oct 2020 23:06:10 +0000

Before we begin I'd like to ask you a question- when you are about to go on a trip, how do you pack your suitcase? Do you separate the shirts from the pants? Do you use some sort of organizers for your clothes or you just fold everything into one big pile?

The reason I'm asking you this is because a few months ago, during a code review session, my teammates and I argued about how we should separate a certain logic between the files in the project. We argued about it for some time until Guy, one of teammates, stood up and asked me: "When you pack a suitcase for a trip, do you put your swimsuit along with your undergarments or inside a separate bag?" my answer was immediate - a separate bag of course - but just like in a Disney movie Guy's question took me 9 years back in time when my family and I had a family trip to Eilat and I had to share a suitcase with my older brother. Back then I wasn't as sophisticated as I am today with my dedicated organizers and I did not know how to keep the suitcase organized throughout the trip. I remember how quickly everything in the suitcase got messed up and how after two days(!!!) I found myself re-inventing new rules for the suitcase organization's sake.

How I backpack my suitcases since Eilat

Recently, I got to plan the file structures of several projects - one of them was our frontend project and the rest were our backend services. These golden opportunities gave me a chance to research and understand what is, in my opinion, the right way of organizing a project's file structure.

In this article, I'd like to share with you why I think that your project files structure is one of the most important parts of your projects and my personal guidelines on how to build a files structure that I believe can improve the efficiency of the code and eventually lead to a healthier and faster development cycle. 🧘🏼‍♀️

Why

The main reason I love planning files structures is that it's like putting my application under the microscope, it enforces me to know which parts of the code can be grouped and which parts can work as independent units, what is stateless, what are the data flows and last but not least, what is my domain. It is almost like running my application through an MRI scan 😅 and knowing the answers to these questions significantly affected my understanding of the project and the application.

I believe that establishing a proper file structure is just like embracing code style and design patterns - it can clarify the dependencies and responsibilities of each file and part of the code and make the code more clear and efficient. From my experience, an organized file structure enables quick entry for new developers to the project and an optimal environment for fast development and delivery speed.

How to Organize File structure

The 3 goals

When I think about the ultimate file structure I imagine a structure which consists these 3 main goals:

Easy to maintain

Easy to file and easy to find

The ultimate way to test how "good" your file structure is to check how long it takes(for newbies👶🏼 and seniors👴🏼) to find a particular file in the project - the less it takes the more efficient it is. Keep in mind that file structure becomes powerful when there's no need to remember anything, ideally, it just needs to make sense so that unconsciously we know where every file is or where it belongs.

Reflects the application

Correct file structure tells the story of the application

I believe that every application has a story to tell, what its domain is, which features it holds, what layers it contains and what are the interactions between them, use the files structure like it was the index of that story's book - try to specify the logical structure of the data and the relationships between the application's components. This can help to define the data flows more clearly and especially needed when collaborating with others. 🤝

Make the best sense for the team

The one that would make the best sense for the teams is the best solution.

Whether you are working in squads or teams, guild or chapters, conformant the file structure with your organization improves the scalability of the application, especially in smaller companies. One key reason for that is that as your company grows you want to expand and grow easily while continue to move fast and deliver, for that you need to maintain the application flexible and more adapted to organizational changes. For example, a company that works with squads might separate the application's project by features, on the other hand, a company with developers working on different technologies(front-end and back-end developers) organizing the projects by type which is easier to classify, back up, and migrate might be more suitable.

However, knowing what to aim for wasn't enough, I still needed some guidelines and standards so I decided to try analyzing what exactly guides me during the process of planning a file structure.

The 5c's - 5 key principles for a proper structure

For a few months, while working on the file structure of several projects, I tried to figure out what is actually the thought process I do to build the structure for a project. I wrote down all my thoughts and concerns, the questions I asked and the answers I got until I finally came out with these 5 key principles:

👓 Clear

Think about your files and folders' names, keep it short(less than 25 characters) unique and meaningful so that the next developer will intuitively understand what are the responsibilities of that file and what it contains. I recommend to think about the file's names as keywords, based on their folder names. For example, inside folder called services I would expect to see userService and not user. Moreover, if I read a file with the name userService I would ultimately guess it's inside services folder.
This will save you a lot of time when you need to modify your files or navigate in your file structure.

🐾 Consistent

Choose a naming convention and follow them consistently, this will automate your workflows and save you time by keeping your code organized and understandable.

Examples:
• Angular: {fileName}.{type:component|service|test…}.{format:ts|css…}
• Go: files and folders names should camleCase based on what they are or what they do and {fileName_test}.go for test files.
• React: UI components should be PascalCase and {ComponentName}.test for test files.
• Java/C#: each file name should consist of the case-sensitive name of the top-level class it contains, plus the .java extension.

🌼 This is the pattern that I use for most of the projects:

I like to think that I took the best from every technology 😊

💎 Concise

Avoid overlapping and don't let your structure get too deep, it makes it harder to write relative imports or move files between places but mostly takes out the grouping context from a grouped files. A rule of thumb that I personally use - when your structure's nesting exceeds 3 levels you are probably gone too deep buddy 😏

✔️ Correct

Group all files and place them in your structure as they exist.

Let's break this down:

(i) "…group all files" - it can be by feature or by type of layer(such as service, controller, component, or stand-alone-scripts)- feel free to choose whatever works the best for you but follow it on the entire project.

Personally, in most cases and especially in front-end projects, I prefer to group the files by feature so that every feature-folder is an independent unit like a lego brick. One key reason for that is that I believe that people work on features and not on types of files, when I close my eyes and imagine my application I think about its views and the features it holds. The second reason is that I was surprised to find out how to modularize the project by features encourage everyone on the team to think about modeling the entities, the layers, inverting dependencies, decoupling code, and define flows in the application. 😌

Here is an example of a React project where the items are
grouped by feature:

dashboard and marketplace folders are both features in the application and each one contains its required internal items such as components, services, routes, etc.

For further reading about folder-by-feature, I recommend reading Tim G. Thomas's article.

(ii) "…place them in your structure as they exist " -

Use your file structure to reflect the architectural relationship between the components(features, types, etc…).
When I'm about to place items in the project I try to find which feature or layer in the architecture this component belongs to, what its scope, is there any architecture restrictions from or of that item?

Let's take for example the following snippet from a simple backend Node.js project:

As you can see in this project the items are group by type and the code is separated into 3 architectural layers: services, stores, and controllers. To reflect the architecture-relationship between the layers, I placed someEntityModel inside its own parent - someEntity- store folder because someEntityStore is the only one who deals with someEntity 's logic, placing it outside of this folder might imply that another store can import it and I didn't want that. On the other hand, all the stores can import db.ts, therefore it should be placed in the store's folder as a sibling to all the stores.

Now, you probably think that making sure you placed a file in the right place can be sometimes very confusing. A rule of thumb that I personally use is to ask myself "Which files can import it?" if my answer is either parent of the file/sibling of the file/I placed it in a dedicated well organized shared folder everything is ok, my file structure is aligned, everything is in its right place and I can keep on rocking it 🤓🤟🏻

💼 Conformant to the company workflows

Develop a folder structure that makes the most sense for your project or team, the best folder structure is the one that mimics the way you think.

🌸 Summary

I started my journey in the beloved arms of .NET framework and Angular, over the years I switched to React, Java, Node.js even Go. If you ask me, you can't take the framework out of a developer, you can leverage it 😌 and maybe the lack of "strict structure" is what made me so passionate about finding guidelines and standards in the first place.

This research gave me a lot of knowledge about the importance of file structure, how to structure and develop applications but mainly it showed me that I shouldn't look for "The One", there isn't one structure to rule them all like there's no one way to backpack your suitcase.

My current daily bag

Finding the right file structure is like choosing and backpacking your bag, the one that would make the best sense is the best solution.

I hope my experience will inspire you to explore your projects and who knows maybe to find new ways of backpacking a suitcase 🙌🏻.

Special thanks to Guy Warburg and the rest of my teammates at datreeio.

Git Bisect — And Debugging Is Easy

Noaa Barki — Mon, 25 May 2020 23:31:22 +0000

Once upon a time, there was a young developer who worked on a small side project, after a few hours he created a working version and started to refactor the code to make it nice, tidy, and clean. He refactored the code for a couple of hours and kept working neatly in small and meaningful commits. When he was pleased with his work he ran the code again but oh no, something terrible happened… the code didn’t work.

We have all been there, for me it happened a week ago, I sat in my bed and stared at my IDE rat me out that it was I who wrote that buggy code, “I got only myself to git blame that’s for sure” I grinned with myself but after a second a light bulb popped with a new idea — 💡 what if I can use Git to traverse through all of my commits and hunt down my bug? fortunately, after a short search on Google I discovered that it is possible - using the simple git bisect command.

In this tutorial, we will explore the git bisect command. How it works, why, and how to use it so hopefully you will find it useful and powerful as I do!

🔮Debugging with Git

As you may know for git everything is about commits, a branch for that matter is nothing but a pointer to a single commit. This allowed git to traverse through the commits and provide a couple of debugging tools to help us debug our code: File Annotation(a.k.a ‘git blame’) and Binary Search.

If you’d like to learn more about how git works under the hood and stores its data check out my recent article and git documentation for further reading.

File Annotation — git blame

File annotation shows the last commit to modify each line of any file and done using the git blame command, this is often the most useful tool for tracking down a bug and know who is the one to blame. If you are not familiar with git’s file annotation I highly recommend you read about it form git documentation.

Binary Search — git bisect

A way to locate which commit introduced an issue using binary search through all the commits history of a particular branch. It’s done with the git bisect command which checks out each commit allowing you to run a test to see if the issue exists in this commit. When you’re hunting down a bug but you don’t know where to look for it and there were hundreds of commits since the last good commit you remember - the git bisect command is your answer.

📽 Simple Scenario

Let’s say you worked on a new branch…

🥳 You worked for some time until you finally reach a good point with a good working product.

😌 You are also a responsible developer who wishes to keep his tree clean so you probably added a few commits along the way and had the following commits history:

*-----*--*---271cb1c (current)

💎 You decided it’s time to start refactoring the code, make it nicer and clean, eventually you ended up with the following commits history:

*-----*--*---271cb1c-*-66e0075-*-...--*---9c07a95 (current)

😰 Unfortunately, your code isn’t working properly at the current commit, apparently somewhere along the way a part of the code got broken.

🧐 You know that it had definitely worked before the refactor — when you added commit 271cb1c — meaning there is a bug in the code between commit 271cb1c and 9c07a95, the only question is…. How do you find it?

👑 Enter git bisect.

🛠 How to use it

Inspired by Clint Eastwood I like to think about this part as the story of ‘The Good, the Bad and the Wizard’:

🧙🏼‍♂️ The Wizard

Run the git bisect start command to startup the git bisect wizard.

😈 The Bad

In git the binary search works by repeatedly dividing in half the commits that could contain the bug and narrowing down the possible commits to one, this makes the scope of the search essential. The way to define the git bisect wizard what is the searching scope is by running the git bisect bad command which tells git that the current commit is broken and contains a contagious bug.

😇 The Good

The bad commit is only one end of the scope now we need to tell git when the last known good commit was, we do that by running git bisect <good_commit> command, for example in our case, the good commit was commit 271cb1c so we’ll run the following command:

git bisect 271cb1c

After running this command git will start checkout commits using binary search and allow at each commit to build the app and check whether or not the bug exists, all left for you to do is to make sure you tell git the status of the last git bisect command with either git bisect bad or git bisect good so it will continue to narrow down the possible commits, repeat until it finds the commit where the bug was introduced.
Let’s assume we checked out on commit 66e0075 and that we found out that the bug occurred before it so we run:

git bisect bad

🙌🏻 Git is kind

Now git has all it needs to determine that the commit between commit 66e0075 and commit 271cb1cis the commit where the bug introduced. When git finally finds the commit with the bug it prints all the information it has about it to help you figure out what happened that may have introduced this bug, for instance:

$ git bisect bad
66e00756e887030abcbde19ac3e10a7c2942036a is the first bad commit
commit 66e00756e887030abcbde19ac3e10a7c2942036a
Author: Noaa Barki <noaa@datree.io>
Date:   Sun Apr 26 12:10:56 2020 +0300
fix: added client
base/client.go                              
base/client_test.go                          
1 files changed, ......
 create mode 100644 base/client_test.go

🧙🏼‍♂️The Wizard

Like every time-travel journey its important to go back to where it all began otherwise we might be checked out on a commit from the past and end up in a weird branch state. We go back to the present by running the simple git bisect reset command which shuts down the git bisect wizard and reset the HEAD to where we were before we started.

🤖 Automation

This is the part when git bisect really shines - one of git bisect subcommand is the git bisect run which accepts a command as an argument and allows to fully automate git bisect!

git bisect run <cmd>...

After running this command git automatically runs cmd on each checked-out commit and uses the return value of that call to decide if the commit is good or bad until it will find the first broken commit.

How to use it

First, you tell git the scope of the bisect by providing the bad and good commits:

$ git bisect start <bad_commit> <good_commit>

Then you git bisect run with your command and let git do all the work for you, for example:

$ git bisect start HEAD 991debbc8b9e05ddc217023a898109822a70dd60
$ git bisect run npm run test

The command can be any script that will exit 0 for “good commit” or non-0 “bad-commit”.

🌸 Summary

In this tutorial, you learned how to track down a bug using the git bisect command. Moreover, you learned how to automate it and by that reduce debugging time significantly. I hope you’ll try git bisect in the future when you’ll look for a nice solution for hunting down a bug.

Special thanks for my teammates at datreeio 🙏🏻