Moving on!
This blog has officially moved to https://thekumar.github.io

★
Show & Tell
ojovivo

Product Placement
YOU ARE THE REASON
Aqua Utopia|海の底で記憶を紡ぐ
art blog(derogatory)

No title available

Kiana Khansmith
will byers stan first human second
TVSTRANGERTHINGS
Xuebing Du
h
Fai_Ryy

gracie abrams
he wasn't even looking at me and he found me
The Bowery Presents

Jar Jar Binks Fan Club
NASA

ellievsbear
seen from United Kingdom
seen from Germany
seen from United States
seen from Malaysia

seen from United States

seen from United States
seen from United States
seen from Mexico

seen from United Kingdom

seen from Germany
seen from United States
seen from United States

seen from United States
seen from Oman

seen from United States
seen from United Kingdom

seen from Malaysia

seen from Malaysia

seen from United States

seen from Russia
@vijayonstuff
Moving on!
This blog has officially moved to https://thekumar.github.io
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:
1. Question your requirements, or bluntly put, “make a requirement less dumb.”
Even smart people are dumb some of the time. So question every feature requirement that comes along your way. Especially, if it’s coming from a smart person.
Product managers and customers ask for many things, and a lot of it truly necessary. But, some of their asks may sound like necessary feature requests on the surface, but once you dig deeper, the reason for the ask might be moot or can be solved in a simpler way with less work or no work. Question whether requirements are actually necessary, or if they can be simplified and made better, or be eradicated.
2. Delete the part, delete the process.
This follows logically from #1, but is more of an active conscious effort to remove clutter that adds to unnecessary complexity. Every single additional feature you implement adds one more item that can and will fail, needs to be tested, requires additional maintenance, and increases complexity and adds to backwards compatibility headaches when developing new more important features.
So, cut down ruthlessly on what you deliver, and build only what is absolutely necessary. Spring clean your spring board.
3. Simplify, then optimize.
Do step #1 and #2 before you start to optimize features. If you’ve eradicated the part/feature completely, there is no need to optimize it at all. Think of it as 100% optimization at 0% cost.
4. Accelerate cycle time.
This is about iterative development, and to speed up spec, implementation, test, and evaluation time. If you’ve worked on Agile teams, you probably are already accustomed to fast iterations... but even then, it’s good to always think of a project as a bunch of small iterative MVPs that are built and validated quickly.
Yes, this may not always seem feasible, especially in long term large scale efforts. But, when SpaceX is launching, testing, failing, and iterating on giant Startships, you really have no excuses to claim you can’t practice this in your software project.
5. Automate.
Once you’ve figured out how to do something consistently at an acceptable standard, then automate it. Automation is the last step, but it’s critical.
A. It will improve quality of your outcomes by minimizing variance in operations and eradicate operator error; and
B. It frees you up to work on other cool and more fulfilling things.
No engineer wants to be repeating the same mundane manual process day after day, week after week, month after month... You do it manually once or twice to figure it out, but then as soon as you have it figured... AUTOMATE!
But, remember not to rush and do things out of order. We are struggling to get past #1 and #2 at my current work but are already automating things, and it is just soul sucking every time I have to do the monthly bill run, where a bunch of script automations have to be manually kicked off in sequence over a period of 5 days... Ahem! I have said too much.
Seriously though, #2 is probably the most important step. While the rest of my org is skipping to #5, I myself have made the blunder of optimizing performance for steps that shouldn’t exist in the first place, albeit while I’m fully aware of it. For instance, we have a manual workflow that involves exporting data as CSV which then gets validated by another team... and I have optimized memory utilization and implemented multipart uploads for this CSV generation step.
Am I proud of it? Uhhhh... Quick! Look here! Elon Musk!
https://www.youtube.com/watch?v=t705r8ICkRw&t=800s
I have linked directly to the part where he talks about the 5 step process, but the entire video (along with Part 2) is very informative and totally worth your time.
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.
Project Remix: What? Why? How?
It’s been a bit over 3 months since I started working on Mix.byCollab, my stab at building a real-time collaborative video editor.
I am working on this by myself and have nobody to report to or to hold me accountable. And Tax Day just surprised me with the realization that my runway might not last me as long as I thought it would... which is a bummer. I guess that’s my accountability.
So, to not lose motivation and to stay on track, I thought I might as well be transparent and blog about my progress on a regular basis (maybe a weekly blog post, but don’t quote me on it).
What?
Ever since working on ZDO, I have been wanting to create an HTML based online editor for videos that let people upload their shots and stitch them together a la iMovie, Final Cut, and Adobe Premiere. But, I never started on it, because from a UX perspective, I was taking an already complicated experience of a native app and making it shittier by pushing it online.
But then, I started working for Google Docs. And, two realities of the new web dawned upon me:
A highly complex application such as a word editor or spreadsheet can be fully written in client-side javascript, and perform at an acceptable level within your browser window; and
Even though Google’s suite of apps wasn’t providing the sleek (debatable) native experience of Microsoft Office, it was miles ahead of it in terms of usability and functionality. All because of its one killer feature: Real-time Collaboration.
If I can get the application to be as collaborative as Google Docs, then it would be worth any degradation in UX performance. And, with the advances being made in WebGL, Socket IO, Web Workers, and FFMPEG.js, it might as well be an app that runs inside the browser. You must have seen the screenshot from my previous posts about what it will look like. If not here it is again:
And yes, that’s the browser experience that I’m shooting for. And if HTML & Javascript aren’t up to par to handle videos, then I could still build a collaborative editor that runs across all the native platforms, but I’m taking a web first approach.
Why?
Mix.byCollab is a service that is coming soon!
Happy New Year!!!
My 2018 resolution is to launch the beta by Q2. Sign up to get notified!
Eject > Side B
This is my first blog post in over a year. I tried to blog a few times in between, but left those posts as drafts, because my nihilism took over :/
What’s the point?
So, I’m repurposing the title from a post I drafted last year after the presidential election to give an update on what's up.
TL,DR; I am not at Google anymore. I’m now working on my passion project that I’ve personally wanted to work on for over 4 years. Expect more posts on it with details, but here’s a sneak peek.
"Don't Die on this Mountain Today!"
When I signed up to climb Kilimanjaro, I simply took it for granted that I would summit it. And why not? I have always loved nature, and it has always been kind to me in return. I have hiked up almost all of the high points in Yosemite, and though they were not nearly as high as Kilimanjaro, they were steep and somewhat technically challenging hikes. And on top of that, I had to carry 30lb packs while climbing them.
Kilimanjaro on the other hand, though almost twice as high as Yosemite’s highest point (19,341′ vs. Clouds Rest at 9,990′), was just one long arduous climb up a steady incline. And we had guides and porters with us to help carry our gear (more on that whole colonial era concept in a follow-up post). And if not for anything else, all my long distance training for marathons had prepared me well for winning the mind over matter game needed to endure such long treks.
Of course, there were many times on this trail when my mind had to do just that, and remind my body what it’s really capable of. The route we took was the newly opened Northern-Circuit, which closely follows the well known Lemosho route and takes 8 days to summit and descend, giving us an extra day to acclimatize to the high altitude over the already long 7-day Lemosho route.
The first two days of hike getting through Forest Camp up to Shira 1 Camp were a breeze. But on the critical third day, when we were expected to actually start feeling the effects of altitude, I got hit with a contagious stomach bug that was making its round around our camp. I wasn’t the only one to get sick. In fact there were five of us in our climbing group, and all but one got sick on the mountain. I just happened to be the one with the unfortunate timing of getting hit on acclimatization day when we camped above 4000m for the first time.
The weirdest thing for me was how all of this didn’t seem like mind-blowing Sci-Fi stuff of the future. VR, AR, Light Field Immersion, and the points-based service economy... We’re already there.
2016: Time to Train
The last time I made a blog post, I was working on my Arduino project as part of my grand plan of building 12 vastly different things in the span of 12 months, each of which will force me to learn something new each month. And, just when it was beginning to progress forward, something big happened and my biggest project of the year took over... Moving to New York for a job at Google NYC. And along with it, my Arduino project got put on hold. Quite literally, in storage, along with most other tools I could use for creative purposes. Though the siege will soon be over when I move into my own apartment next month, I can’t wait to get all my stuff back.
All was not lost however, as I did get to work on a couple of software projects that were well beyond my area of expertise. I got to learn Machine Learning with Tensor Flow, and built a couple of domain-specific content recommendation systems using Hadoop MR. And on top of that, I definitely took advantage of my honeymoon period here at Google, and started learning as much random tech as possible while my actual responsibilities at work are still minimal.
Still, they don’t show the results that I had hoped for when I started on my grand goal of 12 in 12. So, lets focus on something that has a high chance of being on track this year...
Health!
My 12-month goal on the health front was to lose 20+lbs to get into my doctor-recommended BMI range. And, I may have gone a bit too crazy with it by signing up for a bit too much :) May be way too much... And now it’s time to train.
End of July, I’m running the first half of the SF Marathon! EZPZ!
A month later, I’m climbing Kilimanjaro the last week of August! Woot?
And today, I found out that I got selected in the drawing for the NYC Marathon this year in November!
TL;DR:
D3MO - Part 2
Continuing on with the D3 Clock-face we created in Part 1, Let’s create a simple SVG representation of a clock hand.
HTML
<svg width="120" height="20"> <path d="M 0 10 L 20 0 L 120 10 L 20 20 z"/> </svg>
Demo
Let’s turn it into a reusable symbol, and create the hour, minute, and second hands by reusing the symbol.
HTML
<svg width="300" height="300"> <defs> <symbol id="hand" > <path d="M 0 10 L 20 0 L 120 10 L 20 20 z"/> </symbol> </defs> <use id="secondHand" xlink:href="#hand" fill="#a00" transform="translate(150,150),rotate(-90),scale(1.5,0.75),translate(-20,-10)"/> <use id="minuteHand" xlink:href="#hand" fill="#666" transform="translate(150,150),rotate(30),translate(-20,-10)"/> <use id="hourHand" xlink:href="#hand" fill="#333" transform="translate(150,150),rotate(0),scale(.75,1.0),translate(-20,-10)"/> </svg>
Demo
Once the scale and translate transforms are done, the only thing we will need to worry about would be the rotation of the hands around that original 10,20 point in the symbol. So, let’s rewrite our SVG with nested groupings (or graphics contexts, or whatever G means) as follows:
HTML
<svg width="300" height="300"> <defs> <symbol id="hand" > <path d="M 0 10 L 20 0 L 120 10 L 20 20 z"/> </symbol> </defs> <g transform="translate(150,150)"> <g transform="rotate(0)"> <use id="secondHand" xlink:href="#hand" fill="#a00" transform="rotate(-90),scale(1.5,0.75),translate(-20,-10)"/> </g> </g> <g transform="translate(150,150)"> <g transform="rotate(120)"> <use id="minuteHand" xlink:href="#hand" fill="#666" transform="rotate(-90),translate(-20,-10)"/> </g> </g> <g transform="translate(150,150)"> <g transform="rotate(90)"> <use id="hourHand" xlink:href="#hand" fill="#333" transform="rotate(-90),scale(.75,1.0),translate(-20,-10)"/> </g> </g> </svg>
Demo
Delayed Start, but getting there! #infinity #arduino #visualizer #12in12
D3 Demo... D3MO? - part 1
My goal last week was to get a basic understanding of D3.js and to build a basic demo. A simple bar chart? a pie chart may be? But, the more I learned about it, I found out that it was way more powerful framework for data-binding & visualization, that to limit it to just charts felt like a crime :/ I didn’t want to build a simple chart anymore. I wanted to build a clock! Hopefully, these demos work on my blog :) (Also, this would be my first post with code. Entering new territory here on tumblr.)
Obviously D3 is a vast powerful framework, and I can't cover all of it in a week. So, instead of claiming I learnt D3 in a week, I will instead post code & demos to showcase how far I have progressed. In this first part of the series, I'm gonna try and walk you through building the Clock Face, and along the way, introduce you to some core concepts in D3
Start with the Basics!
Let's start by building a simple circle. Apparently, circular clocks have been all the rage with the kids since like... before the Grand Canyon was formed. Anyway, the simple way to draw a circle in HTML5 is to use SVG (Scalable Vector Graphics). I'm not gonna go into the details of SVG here, but here's the HTML that would give us a circle.
<svg width="100" height="100"> <g transform="translate(50,50)"> <circle r="45"/> </g> </svg>
And here's the D3 way of generating that. Let's provide a simple target DIV element inside which we will generate the SVG.
DOM
<div id="vis"/>
Script 1:
var dim = 300; var svg = d3.select("#vis") .append("svg") .attr("width",dim) .attr("height",dim); var circle = svg.append("g") .attr("transform","translate("+[dim/2,dim/2]+")") .append("circle") .attr("r", (dim/2) * .9);
Demo 1:
Pardon my French ;)
Burning Man Shelter: Cooling and Ventilation
I’ve been busy with life in general, and hadn’t found the time to make a blog post about Burning Man in a while. But, here is the follow up post about cooling your shelter on the playa, just in time for the man next year. )’(
(You can't tell, but that BM emoticon above has a sad face.)
Why Cool?
You are in the freakin’ desert! The Sun is shining on your yurt all day long heating it up (Radiative heating). The air outside is hot and dry as hell, and heating it up (Conductive heating). When you’re sleeping/hanging out inside your yurt, your body is heating it up (Generative heating). Somebody’s gotta cool it! It’s plain thermodynamics... ‘Nuff said!
Ways to Cool?
The simplest thing to do would be to buy a portable Air Conditioner / Cooler, and a portable generator to power it. But, if you are not a DIY’er, then you might as well skip the whole hexayurt building thingamajig and drive up in an RV and “camp” out on the playa in luxury.
No!!! This is Burning Man! And we get to hack life here on the playa! (Well, we each get to re-invent the wheel for ourselves, and in the process end up discovering a more efficient way to do things) So, in that spirit, let’s take a look at Evaporative Cooling.