According to Jackie Stewart, a three-time world champion F1 driver, having an understanding of how a car works made him a better pilot.
“You don’t have to be an engineer to be a racing driver, but you do have to have Mechanical Sympathy”
Martin Thompson (the designer of the LMAX Disruptor) applied the concept of mechanical sympathy to programming. In a nutshell, understanding the underlying hardware should make us a better developer when it comes to designing algorithms, data structures, etc.
In this post, we will dig into the processor and see how understanding some of its concepts can help us when it comes to optimizing solutions. …
A couple of months ago, I wrote a post about Go and CPU Caches: https://teivah.medium.com/go-and-cpu-caches-af5d32cc5592
Then, I wanted to extend the scope of this post. Following this idea, I had the chance to give a talk to GopherCon Turkey 2020. The topic is the following: Mechanical Sympathy in Go.
I tried to cover the following topics:
Here is the video of my talk:
The beginning of the talk was unfortunately ousted. Yet, you can find the slides here for the missing introduction:
With the rise of distributed architectures, consistent hashing became mainstream. But what is it exactly and how is it different from a standard hashing algorithm? What are the exact motivations behind it?
First, we will describe the main concepts. Then, we will dig into existing algorithms to understand the challenges associated with consistent hashing.
Hashing is the process to map data of arbitrary size to fixed-size values. Each existing algorithm has its own specification:
Hashing has many applications in computer science. For example, one of these applications is called checksum. To verify the integrity of a dataset it is possible to use a hashing algorithm. A server hashes a dataset and indicates the hash value to a client. Then, the client hashes its version of the dataset and compare the hash values. …
In ReactiveX, the two main concepts are the Observer and the Observable.
An Observable is a bounded or unbounded stream of data. An Observer subscribes to an Observable. Then, it reacts to whatever item the Observable emits. …
I wanted to let you know that I just released Algo Deck. It is a free & open-source collection of +200 algorithmic cards.
Each card is a synthesized way to describe a concept. For example:
Let’s take a look at the Go package in charge to provide synchronization primitives:
sync.Mutex is probably the most widely used primitive of the
sync package. It allows a mutual exclusion on a shared resource (no simultaneous access):
It must be pointed out that a
sync.Mutex cannot be copied (just like all the other primitives of
sync package). If a structure has a
sync field, it must be passed by pointer.
sync.RWMutex is a reader/writer mutex. It provides the same methods that we have just seen with
Unlock() (as both structures implement
sync.Locker interface). …
A small trick I wanted to share.
Sometimes, you need to make sure your Go tests are executed sequentially. I did not mention unit tests as one would argue that if unit tests cannot be executed in parallel, these are not unit tests.
Anyway, the first option is to run your tests using
go test -p 1.
The second option is the following:
In every test, we have to call
defer seq()(). The locking is the first statement executed whereas the unlocking is the last one. This option guarantees that
TestBar are executed sequentially regardless of the test option used.
This post is a summary of my 2-day experience at GopherCon UK 2019. I did not attend the first day (workshops only).
Disclaimer: In this post, I am expressing my opinions about some talks. Under no circumstances, I am making a value judgment on the speakers.
The conference started with a keynote from @JQiu25 who’s working at Google in the Go team.
She described the 3-step process when it comes to working with an external open-source library:
We are developing on two different Go projects using modules:
github.com/acme/foomodule that depends on the first one
Let’s say we made some changes to
github.com/acme/bar and we would like to test the impacts on
github.com/acme/foo before committing them.
Without Go modules, it was pretty straightforward as our changes were done in GOPATH so they were automatically reflected.
With Go modules, the trick is to replace our import by the physical location of the project:
/path/to/local/bar is the actual location of the
bar project containing the local changes.
We can also use the following command:
go mod edit -replace github.com/acme/bar=/path/to/local/bar