Posts
-
5 Steps Towards Better Engineering.
I just realized that I haven’t posted anything to my blog since my dad’s passing, and this post has been in my draft since about 2 days after Tim Dodd’s interview was uploaded onto Youtube. It’s still worth a read.
I “recently” (retroactively applied) watched an interview of Elon Musk by Tim Dodd, the Everyday Astronaut, and in it he listed 5 steps every project must follow to be successful. I couldn’t agree more with him, and at the risk of coming across as an Elon fanboy, I wanted to share them here:
-
Immortal
Thatha
Aug 12, 2012 Tears flow through my heart when I try to remember all our moments together, only to be wiped away with the comfort of knowing that you now live through me. You molded me every step of the way, into the man that I am today. To the man who taught me everything I needed to know about life, language, and mathematics… Cheers! And thanks for everything!
I received the news of my grandfather’s passing while I was in the crowd watching Justice end their live set at Outside Lands. I vividly remember the text and call from my aunt in India, and not knowing what to feel as I made my way out through the crowds in Golden Gate Park. I walked back home that night, all the way to my apartment in Hayes Valley, and went to bed to sleep off all that I got to sample at WineLands that day. It took me a mere 2 days then to process my grief and pen my feelings in a short Facebook Note afterwards.
As an atheist, I don’t have the luxury of comfort that many get from a belief in the afterlife. But, it was easy for me to come to terms with my grandfather’s mortality.
Although he was no longer with us, I knew that the idea of him would still live within us, and it would continue to leave an imprint on the world through our actions – the actions of those who have been touched by his kind, curious, and perfectly flawed soul.
Growing up, I had spent enough time with my grandfather to get to know his true essence. Yes, he was flawed. Yes, my grandmother, my parents, my uncles, my aunt, my sister and myself have each complained about him from time to time. Some of us even hold grudges towards him still to this day. But if you had spent just a little time with him, you would know that he always meant well.
Was he perfect? Far from it. Even the gods aren’t. He was only human – a mere mortal. And so are we, flawed mortals navigating an imperfect world.
I have come across many versions of the “three deaths”, but the one that struck me the most went something like the following:
Every man dies three deaths. Once when his biological self dies. Yet again, when the last person he knows dies. And lastly, his real death occurs when his name is uttered for the last time.
I found comfort in the knowledge that he was still alive and well in our collective memories.
Then this year, after enduring through his cancer diagnosis for over two years, my dad passed away on April 7th. And, I couldn’t find peace in the same thought that had given me calm during my grandfather’s demise.
-
Corona-Oh-Nah-Nah!
This post will either go down in my blog history as one of the stupidest dumbest paranoid analysis of the numbers behind COVID-19 fatality rates, or (hopefully) end up as a thoughtful neutral analysis of the facts as they stand currently. With the recent coronavirus pandemic, there have been a lot of comparisons made in the media with the flu, and a lot of discussions had about the severity of this virus. Especially about its mortality rate. Since, I’m currently funemployed and got nothing better to do while in quarantine, I felt the need to chime in on the topic as well :)
-
Elevator System Design
I came across an interesting System Design interview question.
I have a building with 50 floors. I would like to have 4 elevators to serve the people of this building. How would you go about designing for this?
On the surface, this looks like a very simple arrays/lists/counts based algorithm problem. But I very quickly realized this wasn’t a question on manipulating lists and such, but actually a question about Inteface design and separation of concerns between various components in a system. Of course, I most likely bombed when it came to answering this question, because the design I came up with was embarrassingly lacking in terms of clean separation of concerns.
But, for an interview that spans 45-mins to 1-hour, I hope the purpose of the question isn’t to judge whether the candidate can come up with the cleanest most optimum solution, but instead, rather assess how they think about componentizing different aspects of functionality vs. optimizing for performance vs. readability vs. upgradability, etc. Is the code monolithic (too vertically integrated)? Are components spread out too thin (too separated with having to follow multiple classes to understand a simple action)? Is it a balanced approach? Is there even such thing as a balanced approach? :)
Anyway, after the interview was over, I wondered what kind of a system I would actually be happy about committing to a source repo if I was actually tasked to come up with it at work. And thus, I began going down a rabbit hole of designing the components of a building elevator system with details all the way down to the button, light, and motor controls :/
Hold up! Let’s follow the KISS principle and Keep It Stupid Simple. (I know that it’s actually “keep it simple, stupid!” but in the spirit of self love and self respect I would like to… you get the point.)
The basic principle followed at every level of the design was to ensure that the design allows for testability, abstraction, encapsulation, and separation of concerns.
The design I’ve come up with – BTW, feel free to dissect and criticize as you wish – is as follows. A Building has floors and zero or more elevator shafts. The shafts each contain one elevator and are responsible for moving them up and down the floors. There is a central controller that orchestrates which elevator shaft should service a call at any floor. And each elevator is responsible for the actions riders take within one such as selecting the desired floor, opening the door, etc.
Let’s define the interfaces…
-
Sync-o de Mayo!
I know it’s not May 5th yet. But, I don’t have enough Star Wars geek cred to pull off a “May the fourth be with you!” related pun. So, please bear with me.
Previously, I mentioned how the two magical words, “Operational Transforms,” a.k.a. “OT”, were the solution to all of my real-time syncing woes. So, what is OT? Before answering that, let’s first take a look at the problem we face with syncing.
Consider the scenario where two people, A and B, are simultaneously editing a simple document containing the text “hello!” initially.
- The initial state of the document contains the text “hello!” at Version 0.
- Person A makes an edit replacing the ‘h’ with a capital ‘H’ so that the document now says “Hello!” at their Version 1.
- Person B makes an edit inserting the text “ world” before the ‘!’ to make it say “hello world!” at their Version 1.
Now each person has arrived at a different state of the document, and we want to be able to merge their changes together to converge the divergent states back to a version of the document that contains both edits and says “Hello world!”
There is nothing new about this. We deal with this almost everyday in today’s workplace whether you are a developer merging changes in Git, or a product manager merging different versions of a Powerpoint slideshow, or a lawyer merging suggestions in a contract using Track Changes, or simply keeping your Dropbox / Google Drive in sync with your local folder. And regardless of what scenario you are dealing with, the solution is pretty much the same.
Diff, Sync, Merge.
You diff your version of the document, as well as the version that you want to sync with, against a common ancestor version from history to determine what exactly changed, and then determine how to merge both your changes. Finally, you sync the merged document back to the repository.
The Problem with Diff/Sync/Merge
Diff Sync Merge (aka Diff Merge) is a solid and proven way to perform merges, but it comes with one huge caveat. It needs multiple versions of the entire model to be retrieved/synced for performing sync and merge operations. Whether it was just a single character that was replaced, or the entire document, you still need access to the entire document to perform the diffs. This works well for use cases where you only have to sync relatively rarely.
But, if you want to build a real-time collaborative application a la Google Docs, the latency involved in pushing/retrieving entire document models back and forth on each individual edit would make it unusable. We need to rethink syncing and merging. We need a way to sync changes without syncing entire documents.
OT to the Rescue!
The basic premise behind operation transform is quite simple, and can be explained with the following diamond.
subscribe via RSS