DEV Community: Preston Pham

My 3 years using CAP Theorem in 3 minutes

Preston Pham — Fri, 05 Jul 2024 02:44:00 +0000

A simple and popular mention of the CAP Theorem in office work is:

It’s not possible to have Consistency, Availability, and Partition tolerance at the same time.

There are many other variants. I’m sure most engineers have heard at least one.

The more complex but rarely mentioned explanation of the CAP Theorem would be from its original author, in this keynote from July 2000: Brewer PODC Keynote.

The most complex and almost never discussed is CAP’s proof. For example, this nicely written paper: Brewer’s Conjecture And The Feasibility of Consistent, Available, Partition-Tolerance Web Services.

I think the Simple CAP is not suitable to convey its meaning accurately, at least not enough for software development work, especially when decisions need to be made.

💡 Dangerously, decisions that require mentioning CAP are often important ones.

On the other hand, the Complex CAP is too long and too technical. There are many details requiring an understanding of distributed system theory. In most cases outside research, we don’t actually need those. Needless to say, it is rarely used in offices.

I seek something in the middle for my own use and came up with what I call “Sweet CAP.” It is not a single sentence, but four. Here they are:

C in CAP is strong consistency.

With many servers, P is always needed so we simply choose C or A.

A is preferred in most cases not involving money, together with eventual consistency.

Simplicity first, you may not need to worry about CAP at a small scale.

Certainly, saying all four at the same time is weird. I choose to use each sentence when necessary. For example:

Jerry: Because of CAP, our service needs to shut down when we are doing this operation to maintain consistency.

Me: Wait a second, we only need to shut down if we need strong consistency. Is it this case?

I have used these in my work over the last three years in chats, talks, and design documents. My colleagues seem to be okay with it. Most don’t have a problem understanding the message I want to convey. Sometimes, it even ignites more enjoyable discussions.

That’s why it is Sweet CAP.

5 tips to secure your weekends

Preston Pham — Wed, 27 Mar 2024 13:18:01 +0000

After a successful release of a critical bug fix, I stood up from office desk to head home. Along the way, I couldn’t stop feeling so good about myself. There’s nothing quite like the feeling when people commend you as a Rockstar Engineer.

Well, it was Friday evening and I had indeed accomplished some good work after all. Besides, my luggage was already packed, awaiting a planned trip to the beach for the next two days!

The next day arrived, and I did make it to the beach. But my travel plan ended up in the gutter. My weekends free time disappeared like smoke.

I found myself switching between the hotel desk, absolutely ill-equipped for work, and my bed; investigating why my bug fix ironically transformed into a new bug itself.

“Stressful” and “annoying” were not enough to describe how I felt.

The event above happened about 5 years ago. Back then, I was the main engineer in charged with maintaining a critical ETL pipeline. Its result is the main inputs for a recommendation system generating huge sales in a top successful company product.

From an outsider’s point-of-view, you are looking at an inexperience engineer tasked with overseeing a mission-critical software. Disasters are bound to happen.

But I won’t talk about the technical solution in this post. I’m sure that it will be boring enough that you guys will close this browser tab before you even read half of it.

Instead, I want to share the lessons I learned looking back at that event. Those lessons are distilled into the 5 Tips below to help you steer clear of the sad outcome.

The Good Intention

Please allow me 5 sentences before presenting the Tips.

Readers coming from other professions may notice and wonder why we corporate engineers frequently have to work on weekends.

Believe me when I say the root cause is our unreasonably high responsibility and expectation of our work. My thoughts were usually “Just a little bit more and I can save the business” or “Just a little bit more and I can deliver this mission critical feature today”.

So if you see friends who are in the same situation, please support them. They didn’t mess up, they just had too much good intention.

Tip #1: Release Policy

This policy is simple:

Never release on Friday afternoon or any afternoon before your day off.
If you have to release in those forbidden times, always make sure roll-back is possible and convenient.

If your workplace doesn’t have similar policies, propose to your boss to make it available. If you cannot do that, keep this to yourself and use these following tricks to avoid violating it.

I cannot finish it in time to today without making sure everything works as expected, but I will definitely finish on the next monday.
I can try to release today but there is a huge risk of failure and we have no plan B.
Let me finish testing this code today so we can have a safe release on the next monday and be done with this feature.

We don’t deceive our colleagues or bosses. Please don’t do that. The point is to show valid reasons to delay the release. Usually, safety reasons are the most convincing.

But sooner or later, there will be times when it is inevitable to release on Friday afternoon. Such as when the business promotion campaign is scheduled on weekends.

In those cases, a roll-back mechanism is a must-have. And to have it, pay attention configurations before doing code change. The goal is to have a button or equivalents to revert the system back to the state before the release. Then make this button accessible when you are not at your office desk.

🧯 Design for Backward Compatibility so you can roll-back safely.

Having a colleague doing this for your also works. But please let him/her knows beforehand.

Tip #2: Don’t count weekends into estimates

It may sounds strange to many people to count 2 days from weekends into estimates. But once in a while, it is very tempting to do so.

After all, saying out loud to everyone in the meeting that you can finish the task on Monday feels more superior than on Wednesday. Doing so briefly transforms us into a Rockstar Developer with an additional benefit of good impression on the boss.

But hear me out, don’t ever do this. To see why, consider these scenarios:

Your kids want to go swimming pool with you, thrice a day.
Your flight is delayed.
Your dog eats weird things and you need the vet’s help to make sure the poor soul is ok.
Your girl friend calls asking to go to the amusement park together, immediately.

These are unexpected scenarios that can happen any day of the week, including those two precious weekends. Thus, we want to avoid putting ourselves in the situation of having to choose between these events and finishing the committed task.

💡 The consequence of breaking the task estimate is losing trust and ruining the project timeline.

Tip #3: Ignore non-urgent chats

Urgent Chats are about live issues and require immediate investigation.

We will only allow those messages to have our attention. I use these 3 steps:

Identify chat channels or threads that contains Urgent Chats.
Setup notification only for those channels. Make sure the notification can reach your phone timely. Additionally, allow it to get your immediate attention by setting a unique ringtone.
Open your work chat app if and only if you receive the notification. Ignore everything else.

While responding to chat messages promptly does give the impression of a diligent engineer, the drawbacks outweigh the benefits. You have disclosed that you are online. It now becomes harder to ignore subsequent messages. Especially when the other person is your boss.

This situation is best described by Oliver Burkeman in his best-seller Four Thousand Weeks: Time Management for Mortals, using email instead, as follow:

you’ll become known as someone who responds promptly to email, so more people will consider it worth their while to message you to begin with

Tip #4: Ignore non-critical alerts

Critical Alerts refer to ones that require immediate action. Such as a total failure of the company’s only payment system. Others should be counted as non-critical.

Similarly to Tip #3, we do 3 steps:

Setup an Alert Sink. A place to where all Critical Alerts will be sent. If your company is using chat apps like Slack, the Sink is a dedicated channel receiving those alerts.
Setup notification for Alert Sink. Make sure the notification can reach your phone timely. Additionally, allow it to get your attention by assigning a special ringtone for example.
Check work chat messages if and only if you receive the notification. Ignore everything else.

💡 If a message doesn’t require immediate action, then it’s only makes sense to address it later.

Tip #5: The weekends are for you

Seriously, there are only 7 days in a week, and our work already consumes 5. That is 70%, a tremendous imbalance.

If week days are money, we are effectively giving 7 out of 10 coins we have to the company and only 3 coins to our loved ones. Worse, this exchange repeats for decades.

Of course, work is necessary. What I’m trying to say is you really should give the little 30% remaining days to other important aspects in your life. Otherwise, the existing imbalance will only worsen.

Doing this may put you 2 days behind, but if that task at hand is not urgent, then it really doesn’t matter in the end.

Work is infinite and our effort is finite, none of us are going to reach the end of “work”. So to go far, I vote for producing consistent and quality work over the long term. It’s a sustainable approach that allows us engineers to stay sane and live our lives to the fullest.

This perspective does not belong only to myself. It is directly or indirectly suggested by distinguished individuals worldwide.

In the book Slow Productivity: The Lost Art of Accomplishment Without Burnout by Cal Newport, the author argues that Slow Productivity is a sustainable and meaningful approach for knowledge workers. It contains these principles:

Do fewer things.

Work at a natural pace.

Obsess over quality.

Or in How to Live on 24 Hours a Day by Arnold Bennett:

If a man makes two-thirds of his existence subservient to one-third, for which admittedly he has no absolutely feverish zest, how can he hope to live fully and completely? He cannot.

Rendering yourself more efficient — either by implementing various productivity techniques or by driving yourself harder — won’t generally result in the feeling of having “enough time,” because, all else being equal, the demands will increase to offset any benefits. Far from getting things done, you’ll be creating new things to do.

And finally, these wise words told by a legend:

Remember that careers and jobs are long-term things. Too many young people think they can optimize something and they find they’ve spent couple of years or more specializing something that may not have been the right thing and in the process, they burn out. Because they haven’t spent enough time building up friendships and having a life outside computing.

~ from an interview with Bjarne Stroustrup, the creator of C++.

Responsibility to our work is important, yes. But don’t forget that we are also responsible for our bodies and minds, our families, and our friends.

I hope that the tips above will help you secure your precious weekends successfully. In fact, I know you will succeed. I have tried and seen it.

If you have more tips, let us know in the comments. Let’s meet again on a future post.

Design Pattern: Facade

Preston Pham — Mon, 04 Mar 2024 15:03:46 +0000

The “Facade” concept focuses on decomposing a complex system into manageable sub-systems, each having its dedicated representative object also called “Facade”.

The pattern bears a resemblance to micro-service models often employed in large-scale web backend systems, where each micro-service's API serves as a representative.

Another usage is to let Facade plays the role of an interface with multiple implementations, symbolizing various sub-systems.

When to Use

Simplifying Complexity: create a straightforward interface, making it easier for external entities to interact with complex underlying code. The Facade should be designed to be versatile enough for most common requirements. However, direct access to the code behind the Facade is still possible in rare cases where it is truly necessary.
Managing Dependent Types: When various types are intricately dependent, rearranging them to go through the Facade can streamline dependencies. Instead of relying on N types, one can depend solely on the Facade.

Implementation

Structure

Sample Code

An example Facade interface can be written as follows in Go:

type StockManager struct {
    readyStocks []ReadyStock
    hotStocks []HotStock
}

func (s *StockManager) GetStock(item Item) int {
    stock1 := findReadyStockOfItem(item, readyStocks)
    stock2 := findHotStockOfItem(item, hotStocks)
    return stock1 + stock2
}

The remaining code for sub-systems is omitted. We can still understand the pattern without it.

Testing

Given that this pattern primarily focuses on structuring types, testing is typically not required.

Related Patterns

Singleton

Often, only one Facade is needed. So we can apply the Singleton pattern ensures this uniqueness.

Abstract Factory

Since each sub-system contains inter-related objects, the Abstract Factory pattern can assist in their initialization.

Pair Programming in enterprise

Preston Pham — Thu, 22 Feb 2024 10:10:14 +0000

In the vast landscape of software development methodologies, one timeless technique has stood the test of time — Pair Programming. Many teams avoid this technique due to unfamiliarity and the upfront cost required. Indeed, it’s hard to justify doubling the resource, going from 1 engineer doing 1 task to requiring 2 engineers to do 1 task, not just once, but every week continuously.

So, how did it go in a real workplace? Let me tell you my experience.

The Abyss of Team Dysfunction

I’m in a team of 6 engineers. My teammates are all very smart people and are each familiar with a system they frequently work on. After joining the team, I also get familiar with another system. As time goes by, we do more and more tasks that change our systems, and we don’t really care about the other ones.

Almost a year passed, and I realized that we have a challenge. A disconnection among teammates hindered effective collaboration, making it difficult for team members to back each other up. Project timelines have to extend more and more frequently due to the siloed approach where each member handles only their familiar system. The growing complexity, intensified by the constant influx of new features, led to stress, a lot of stress.

We used to have a culture of doing talks. A talk is basically a 30-minute to 1-hour meeting organized by a team member to share anything they want. Mostly, people share about technical problems and solutions at work, or even at their school in the past. I think we learned a lot from each other this way, but that is long gone now. We don’t have time to do talks anymore. Even worse, we can’t even onboard new members properly.

In short, the team cannot “scale” further, and it’s time to take action.

Our Beacon: Pair Programming

Although costly to start, research has shown that Pair Programming is a practical and beneficial solution in the long run. The study “On the Economic Feasibility of Pair Programming” shows an approximate 15% longer development time but highlights the subsequent benefits in terms of higher code quality, better design, and lower bug counts.

Additionally, Cal Newport’s exploration in his book “Deep Work: Rules for Focused Success in a Distracted World” emphasizes the unparalleled results that stem from intense focus, which he calls Deep Work. Pair Programming inherently fosters focus much like a deep work session.

Why is that so? Because it shields both programmers from distractions and procrastination. In my opinion, this is the key motivation.

Armed with research insights, our team decided to venture into the realm of Pair Programming. We scheduled Pair Programming sessions at least once a week. The pairing changes after each week, so each engineer has the chance to work with as many teammates as possible. Simultaneously, a dashboard was deployed to anonymously monitor the bug resolution time of team members, providing a tangible metric to track progress.

Emergence from the Depths

As the weeks unfolded, the dashboard unveiled a promising transformation. Bug resolution time gradually decreases, pointing towards the positive impact of Pair Programming on code quality and problem-solving efficiency. The collaborative sessions not only improved the technical aspects but also forged stronger relationships among team members.

The most surprising result is that it actually decreases our development time! This is because each engineer brings different skills and knowledge into the session. So when Tom doesn’t know where to find the logs, Jerry can jump in to help because he knows it. As a bonus, members began to confidently take on tasks of other systems, breaking down the silos that had plagued the team for so long.

After three months of Pair Programming, the results spoke for themselves. We are happy with the success and decided to continue the Pair Programming sessions until now.

In conclusion, our journey through the abyss of team dysfunction to the summit of collaborative success strengthens the result of research studies. Pair Programming, an age-old technique, proved to be the beacon guiding our team out of the abyss, offering a practical solution that not only improves code quality but also cultivates a positive and efficient working environment.

References

Design Pattern: Composite

Preston Pham — Mon, 19 Feb 2024 01:27:51 +0000

We can consider a single type or a composition of related types to be the same by:

Creating a new type, usually an interface, to represent them, called Component.
Allowing recursive structure, meaning Component can contain other child Components. Components within this structure are called Composite , while those without any children are called Leaf.

When to Use

When representing hierarchical systems.
When disregarding the difference between a single object and a composition of objects, treating them all as a Component.

Implementation

Structure

Let's take the example of a UI framework (something like React). UIComponent represents all types of components such as buttons, text, etc. We also have Popup, which is a more complex component, composed of a button and a text, making it a Composite.

Sample Code

Component interface:

type UIComponent interface {
  Render()
}

Some *Leaf * types:

type Text struct{}
func (t *Text) Render() {
  fmt.Print("hello")
}

type Button struct{}
func (b *Button) Render() {
  fmt.Print("button: ")
}

Composite:

type Popup struct {
  children []UIComponent
}

func (p *Popup) Render() {
  for _, c := range p.children {
    c.Render()
  }
}

Usage:

text := &Text{}
button := &Button{}
popup := &Popup{
  children: []UIComponent{button, text},
}
popup.Render()

// Output:
// button: hello

This pattern offers a way to treat individual objects and compositions uniformly, providing a unified way to work with both. Moreover, we can freely switch the types behind UIComponent interface without affecting the users.

Testing

This is a pure pattern for building a structure, so I think we can skip this part 😇

Related patterns

Chain Of Responsibility

If we add the parent UIComponent field to UIComponent interface, we can create a usable structure for the Chain Of Responsibility pattern. Check out the pattern's article for more details.

Iterator

Iterator can be used to iterate through each component in the Composite structure.

Visitor

Helps gather the logic of the components in one place instead of being scattered across Composites and Leaves.

Decorator

Often used in conjunction with Composite. Check out the Decorator Pattern for more details.

Unveiling the Fully Qualified Domain Name of the Internet

Preston Pham — Fri, 16 Feb 2024 15:06:03 +0000

Navigating through the expansive Internet can be like finding one’s way through a bustling city, complete with intricate addresses and postal codes. At the heart of this digital address system lies the Fully Qualified Domain Name (FQDN). Comprising the host name, first-level domain name, and top-level domain name, the FQDN establishes a hierarchical framework similar to physical addresses.

Structure of a FQDN

The structure of an FQDN follows a specific pattern:

<host_name>.<first_level_domain_name>.<top_level_domain_name>

This well-defined structure allows easy identification and classification of web resources, analogous to how physical addresses are organized.

The Intention

The intentional design of the FQDN structure aims to bring order and logic to web resource naming and organization. By hierarchically segmenting the domain names, the FQDN enables efficient management and smooth navigation of the digital landscape.

An Example: mail.google.com

Taking the example of “mail.google.com”, we can observe the FQDN’s components in action.

“mail” signifies the host name
“google” represents the first-level domain name
and “com” indicates the top-level domain

Design Pattern: Chain Of Responsibility

Preston Pham — Fri, 16 Feb 2024 15:05:48 +0000

A feature can have different logics depending on the usage context. We can hide these logics from the user (caller) by placing them behind an interface. In this way, the caller will not know, and does not need to know, which logic is being used. We call the interface Handler , and each specific logic is a Concrete Handler.

When to use

There is more than one object that can handle the task we need, and we don’t need to know in advance which object will do that.
When we want to call multiple objects without having to specify them explicitly. The objects can be combined to do a task that can be chosen at run-time.

Implementation

Code Structure

I will use an example of the logging feature. In this case, we can log a string to the console if the string is just normal information, or we will send an email if it is an error. In any case, from the client’s side, there is only the Logger interface.

Usually, we would leave the most general logic, which can be used in the most cases, at the end of the chain. We want the more specific logics to run first because they might end the chain early.

In programming and problem-solving, it’s common to prioritize more specific and potentially terminating conditions before general ones for efficiency. This approach optimizes the process by handling specific cases early, potentially avoids unnecessary processing.

Sample Code

First, we write the Logger interface:

type LogLevel string

const (
 Info LogLevel = "info"
 Error LogLevel = "error"
)

type Logger interface {
 Log(level LogLevel, text string)
}

func NewLogger() Logger {
 return &EmailLogger{
  next: &ConsoleLogger{},
 }
}

Next is a Concrete Handler ConsoleLogger. This logger will write to the console and pass on to the next logger.

type ConsoleLogger struct {
  next Logger
}

func (l *ConsoleLogger) Log(level LogLevel, text string) {
  fmt.Printf("%s | %s\n", level, text)
  if l.next != nil {
    l.next.Log(level, text)
  }
}

Second Concrete Handler EmailLogger will only be activated when the log level is Error.

type EmailLogger struct {
    next Logger
}

func (l *EmailLogger) Log(level LogLevel, text string) {
 if level == Error {
  fmt.Printf("%s | sent alert email to me", level)
 }
 if l.next != nil {
  l.next.Log(level, text)
 }
}

Usage:

logger := NewLogger()
logger.Log(Info, "hello world")
logger.Log(Error, "the world has already ended due to zombies!")

// Output:
// info | hello world
// error | sent alert email to contact@codenghiemtuc.vn
// error | the world has already ended due to zombies!

Testing

We can test each specific logger like this:

func TestConsoleLogger(t *testing.T) {
  logger := &ConsoleLogger{}
  expect := "haha"

  logger.Log(Info, expect)
  // check console output
}

Or we can just test a chain of logger:

func TestLoggerChain(t *testing.T) {
    logger := NewLogger()
    expect := "haha"
        logger.Log(Error, expect)
         // check console output
         // check email is sent
}

Related Patterns

Composite

The Composite pattern can be applied to create a hierarchical structure with a child Component pointing to a parent Component, forming a chain. In this way, the child can handle requests and forward them to the parent.

I reinvented the wheel at work and it didn’t go well

Preston Pham — Thu, 15 Feb 2024 05:59:55 +0000

Dave the Dev is so excited about his new task to build a new technology at work. It will be the coolest and shiniest thing ever created in my career, he thought. It’s hard but Dave managed to pull through and deliver. So what’s wrong then? Well, the tech doesn’t work as expected and Dave realizes later that a correct solution was already built. Oops.

You can forget about Dave now. That’s exactly what happened to me when I decided to “reinvent” a Distributed Lock.

Let’s see what this task is about. There are 2 requirements:

Mutual Exclusion : at any time, maximum 1 server can acquire the lock
Frequency : there must be approximately T seconds between 2 consecutive lock acquisitions

The lock is used to give access to a block of code that updates our database.

Coincidentally, by the time I received the task, I just finished reading “Redis in Action” by Dr. Josiah L Carlson. The book has a long section instructing how to implement Distributed Locking. I felt like a teenager who just bought his first motorbike and I could not think of anything else other than to be on the road.

By the way, the book is very good. I recommend fellow engineers to read.

Needless to say, I was determined to make it work. After reviewing my knowledge and some quick research, I chose to use Redis because not only it fits the solution that I learned from the book but it is also an available tool to use in my company.

It made sense.

Here is my plan, simplified.

I would setup Redis to store the lock and wrote all the necessary logic to ensure that only one server could acquire the lock. This satisfies Requirement 1. Readers can imagine the lock is stored as lock_key=a_unique _value.
I would also set the expire time of lock_key to be exactly T seconds. This satisfies Requirement 2. It actually not enough but at least, this is what I thought.
Additionally, some minor logic would need to be implemented to handle edge cases.

It seemed like a great plan, so I and the team spent about 2 weeks developing it into our existing backend. The due date came and I was eager to see the results. Little did I know what lies ahead…

Of course, the result was not what I had hoped for. Yes, only one server was able to acquire the lock, but the frequency was off, very off. My design could only satisfy Requirement 2 in my head, not in real life. It took a total of 3 long weeks to realize that the chosen approach was not delivering the desired outcome.

We thought of rolling back, fix it, and then re-release. But the change was already out there and rolling it back was not an option since other teams already released their changes based on ours. Even if we can rollback, we could not figure out a fix that won’t lead to other issues. It felt like our design is fundamentally wrong.

The frustration was real, and I felt like I had fallen into a deep hole, with no clear way out.

Just when I thought things couldn’t get any worse, it turned out that there was an existing solution that could have saved us all this trouble — ETCD. Had I explored this option earlier, we could have had a correct solution in just 1 week instead of the frustrating weeks we have endured. So the better way had been there all this time. Always.

ETCD works in this case because it has a built-in primitive called “compare and swap” to implement Distributed Lock. More details in this document Using etcd for distributed coordination. I plan to write about the usage of this soon, hope you will like it!

The project didn’t succeed. I also didn’t succeed technically. But I did grow up a little bit more in my career. Because this whole experience taught me a valuable lesson:

If I am about to reinvent the wheel, think again.

There are often existing solutions and technologies within reach that can save time, effort, and unnecessary complications. It’s important to take a step back, evaluate all available options, ask colleagues, and consider whether there’s already a suitable tool or system in place that can effectively address the problem at hand.

If above steps don’t work, give your self a second chance. Forget about the task for a while by using desperate measures like procrastination, take a walk, take a drink, hit the gym, talk to your dog, or cat,…

This lesson has now become a guiding principle for me in all future endeavors, and I hope that sharing this experience can help readers avoid similar pitfalls.

Simple Hash Map with Scala in 15 minutes

Preston Pham — Fri, 27 Dec 2019 08:04:22 +0000

Implementing a Hash Map is a good way to get familiar with a new language, let's see how it can be done quickly in Scala. This article assumes that you are familiar with the data structure. If not, Hacker Earth has a really nice article to get you started.

Now, for this implementation, there are a few things I want to achieve:

use chaining to resolve collisions
support 3 operations: add, remove, and get
immutability (all modifications return a new map instead of changing the existing one) (but why?)

With those requirements in mind, let's write a short outline:

case class Entry[K, V](key: K, value: V)

class HashMap[K, V] private (entries: Vector[Vector[Entry[K, V]]]) {

  def add(key: K, value: V): HashMap[K, V] = ???

  def remove(key: K): HashMap[K, V] = ???

  def get(key: K): Option[V] = ???
}

Class Entry represents a key-value pair
I use Vector to hold the keys. Each key contains another Vector that holds all the values. Hence we have Vector[Vector[Entry[K, V]]]
Since my hash map is immutable, add must return a new hash map. The original map is left untouched.
get returns an Option that contains the value of that key if it exists and None otherwise
??? means throw new NotImplementedException(), which is quite convenient for writing code outline

Method add is quite straight forward:

def add(key: K, value: V): HashMap[K, V] = {
  val idx = indexFor(key)

  // if the table is empty, initialize and then run 'add' again
  if(entries.isEmpty) init.add(key, value)
  // otherwise, if 'key' exists, replace its old value
  // if not, associate 'value' with 'key'
  else {
    val chain = entries(idx)
    chain.indexWhere(_.key == key) match {
      case -1 => // key not found
        val e = Entry(key, value)
        new HashMap(entries.updated(idx, e +: chain))
      case i =>
        val replaced = chain(i).copy(value = value)
        new HashMap(entries.updated(idx, chain.updated(i, replaced)))
    }
  }
}

private val initialCapacity = 16

private def init: HashMap[K, V] = {
  new HashMap(Vector.fill(initialCapacity)(Vector.empty))
}

/** Returns the index of this key in the internal entry vector. */
private def indexFor(key: K): Int = {
  key.hashCode() & entries.length
}

remove is a bit tricky to write since we cannot do an 'in-place' removal (ahem, immutability ...). So we have to use filter:

def remove(key: K): HashMap[K, V] = {
  val idx = indexFor(key)
  val updated = entries.updated(idx, entries(idx).filter(_.key != key))
  new HashMap(updated)
}

However, this is not the most efficient way because filter will go through the whole collection instead of stopping once the unwanted element is seen. A more efficient approach to this case is to not remove anything at all but just 'mark' the element as removed. But I will not implement that here 😅

And lastly, we need to write out get method:

def get(key: K): Option[V] = {
  val idx = indexFor(key)
  entries(idx).find(_.key == key).map(_.value)
}

Method find of Vector already returns an Option if there is no element match with key so we don't need to manually handle that. Utility methods like find is the reason why I love Scala so much. It allows me to leave work early.

And that's it! We have completed our Hash Map implementation that satisfied the requirements we made at the beginning. You can use it like this:

val map = new HashMap[Int, String](Vector.empty)
val web = map.add(1, "web") // 1 -> "web"
val dev = web.add(2, "dev") // 1 -> "web", 2 -> "dev"

Notes

Array can be used for faster indexed access. Here, I use Vector to keep everything immutable.
This implementation uses a constant capacity (and it shouldn't). In practice, you should add some logic in method add to increase the capacity when needed. This is important to maintain performance.

5 reasons to learn Scala in 2019

Preston Pham — Fri, 20 Dec 2019 04:35:04 +0000

If you are looking for a new programming language to learn this year, Scala is a good choice. Here are 5 reasons why:

Flexibility

If it is 10 years ago, I would never recommend Scala to anyone. Because a programming language can be very fast, elegant, and feature rich but is still not good to learn if nobody else is using it. However, that is not the case anymore because Scala has been growing quickly and is now used in many areas such as:

Web frontend with ScalaJS and ScalaJS React
Web server with Play, Lift, and Akka HTTP
Android app with Scala on Android
Data processing with Spark and Kafka

There is even an open-source chess server written in Scala.

Elegance

Having used C++, C#, Java, and Python, I can say that Scala has a very concise and expressive syntax.

For example, to print "hello world" on console:

println("hello world")

To declare a value (or variable in Java):

val i: Int = 6
val j = 9 // automatically inferred as `Int`

To declare a method:

def add(a: Int, b: Int) = a + b

To remove all odd numbers in a list:

val list = List(1, 2, 3)
list.filter(x => isEven(x)) // result: List(2)
// or more like English
list filter isEven // result: List(2)

You can omit punctuations to have a more English-like syntax for extra expressiveness, this is called infix notation.

Rich API

Scala built-in library comes with an extremely rich API. Filtering a list in the code snippet above is a very typical example.

List API also contains many other methods. For example, to loop through each item in a list:

list.foreach(println)

To sum a list of numbers:

list.sum // result: 6

It works as long as the list contains numbers (e.g. integers, doubles...)

Computing the intersection of 2 lists is also simple:

val l1 = List(1, 2, 3)
val l2 = List(2, 3, 4)
l1.intersect(l2) // result: List(2, 3)

Great community & libraries

Yes, indeed. Compared to NodeJS or Python, Scala has a much smaller community and far fewer libraries (not counting Java ones). But it is not really bad because:

Most of the time, we only use a few top libraries and those in Scala have high quality to make up for quantity
People are very active and willing to help each other. Especially Gitter channels like Spark with Scala and typelevel/cats

Java Interoperability

Simply said, Java methods can be called and Java classes can be extended in Scala code. This means you have access to all Java libraries out there.

Conclusion

I was once questioning why should I use a language that looks so complicated. But after I understand Scala and realize how my life becomes much more easier, I'm in love with it. If the 5 reasons above are interesting to you, make sure to check out a short tour of Scala.

It's my first post to DEV, if you have any question or feedback, please let me know :)