Vithun's Blog

50 Years of Apple

2026-04-24T00:00:00+01:00

As Apple celebrated 50 years of existence this month, here are 5 things (amongst many more) that I have picked up and imbibed deeply in how I go about my work.

Look Forward, Not Back

Apple is famous for not celebrating the past too much (although 50 years is a valid exception!). Such celebrations are just are not worth the time. There is more of the future yet to be invented that there is no point to sit on the laurels of the past.

I’ve realised this is a useful personal mantra too. You can always get too attached to a project to the point where you think it’s your baby and you can’t let it go. Truth is, whether it was an absolute success or an absolute failure, it does not define you. Those are just a moment in time. Resetting to zero as soon as you can is always a super-power. It keeps you hungry for what’s next.

As I write this, I have just completed 5 years at Maersk. What I have done in 5 years is irrelevant, it’s now in the past. I reset to zero and start fresh again tomorrow.

Work Backwards to the Technology

Steve Jobs in 1997:

One of the things I’ve always found is that you’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it. And I’ve made this mistake probably more than anybody else in this room. And I got the scar tissue to prove it.

Such a simple and obvious idea. Equally hard to implement and scale across teams on a continuous basis because: on the one-hand you don’t want to get blind-sided and not allow room for new technological discoveries; and on the other hand, you always want to be able to tie something back to making life better for our users. I try my best to maintain the balance, and when I have a bias it’s towards the user experience.

Innovation Does Not Happen Overnight

From Daring Fireball:

This is how the designers and engineers at Apple roll: They roll.

They take something small, simple, and painstakingly well considered. They ruthlessly cut features to derive the absolute minimum core product they can start with. They polish those features to a shiny intensity. At an anticipated media event, Apple reveals this core product as its Next Big Thing, and explains — no, wait, it simply shows — how painstakingly thoughtful and well designed this core product is. The company releases the product for sale.

Then everyone goes back to Cupertino and rolls. As in, they start with a few tightly packed snowballs and then roll them in more snow to pick up mass until they’ve got a snowman. That’s how Apple builds its platforms. It’s a slow and steady process of continuous iterative improvement—so slow, in fact, that the process is easy to overlook if you’re observing it in real time. Only in hindsight is it obvious just how remarkable Apple’s platform development process is.

There’s a lot of hype and buzz created in the name of innovation and showing shiny, new things. They start off great, but soon the makers lose interest and go pursue the next shiny thing. Apple doesn’t typically work that way. They never seem to be in a hurry to show something that everyone else is doing. They take time and do it their own way. And once they bring that take to the market, pretty often you can trust them to keep iterating on it. And gradually it grows from strength and strength into perfection in a few years time. Being patient and focused for those few years is the key!

Every time we build something, I tell myself the same: Not worth celebrating yet, there’s a lot more to be done. Time to put the heads down again.

The Work is Your Brand

Mobile phones in the 90s used to look like this:

By © Raimond Spekking / CC BY-SA 4.0, via Wikimedia Commons

Soltys0, CC BY-SA 2.5, via Wikimedia Commons

Here’s how the iPhone looked when it launched:

Rafael Fernandez, CC BY-SA 4.0, via Wikimedia Commons

Notice the difference. There is no word “Apple” front and center on the iPhone. All the focus instead is on the user experience. But everyone knows it is built by Apple.

When you build something insanely great, the product you build becomes the brand. It’s a handy reminder everyday in a world where I have sometimes seen feature announcements where the list of credits is longer than the description of the feature itself!

Team First and a Long Term View on People

And finally to the builders who make it all happen!

Lone geniuses can only go so far. Insanely great work can happen only when you have a bunch of people gelling together such that they force each other to punch above their weight. And to recruit such people and create that team culture, you need to invest deliberately and it takes time, sometimes longer than you expect. But once it starts bearing fruit, the magic unfolds. I have experienced this first-hand multiple times.

Nobody explains this as well as Steve Jobs himself.

180 Degrees

2023-09-13T00:00:00+01:00

Photo by Justin Luebke on Unsplash

Make Something Wonderful puts together many of Steve Jobs’s notes and messages in his own words. One thing that stayed with me was an email exchange between him and Andy Grove, in which over the course of a mail thread Steve Jobs ends up completely changing his mind.

Below is the relevant part of the mail thread with most other text redacted. Click through this link and search for 180 degrees in the content to read the relevant thread in whole.

From: Steve Jobs
To: Andy Grove
Subject: Re[2]: Pixar-3D graphics
Date: October 1, 1995, 3:50 p.m.

Andy,

[redacted]

Therefore, I have changed my position 180 degrees - [redacted].
Thanks for the clearer perspective.

Steve

As strong-minded as Steve Jobs, his strength is also demonstrated in the openness and humility to change his mind 180 degrees when faced with a reasoning to do so. Many good leaders exhibit this quality…

A few years ago, in a previous job, I had the good fortune of participating in one of the orientation days Aman Bhutani used to run for the engineering organisation he led. Aman used to have a list of principles he used to talk about. While many of those stayed with me, the one relevant to this post is “Strong opinions, loosely held”. While investing in the team culture, Aman encouraged us to have strong opinions and be vocal about it.

Strong Opinions: Being meek about one’s ideas or opinions means those ideas would be discarded at the earliest challenge, whether it’s from a louder colleague, or a boss, or one with a fancier title. And that’s not a great way to foster the growth of ideas, especially when they are freshly-formed or brittle. To build a culture brimming with more ideas, and an environment where these ideas get strengthened by sharing widely and being challenged openly, it becomes imperative to encourage having these strong opinions.

Loosely Held: As strong as the opinions are, holding onto them dearly (especially based on the ego that it originated from you) invariably ends up creating friction that comes in the way of collaboration and progress. This is where good leaders (“lead” as in “lead the way forward”; nothing to do with job titles) are open to changing their mind 180 degrees. This is because they do not attach the idea to themselves or any person, but they think of it as a hypothesis that is bound to change if evidence suggests otherwise. Being able to change one’s mind (or disagree and commit) helps get onto the same page with one’s collaborators and move ahead with the sort of cohesion that can’t be created otherwise.

Teams/organisations where this principle is not effectively practiced can run into one of two problems:

People can’t get along, and any friction stays open coming in the way of collaboration. While this isn’t great for the organisation, the symptoms are at least clear for a leader to recognise this and step in sooner to address the issue.
People try to avoid conversations on such hard topics, and try to stay diplomatic. Compromise solutions are found where possible to keep everyone happy (usually not a great idea: the best way to split a five-dollar bill is not by tearing it into two and giving each party one piece). These symptoms don’t show up as early as the previous one, and can lead to late and sudden discovery of problems after a prolonged period of everything appearing hunky dory.

So, practice having strong opinions but hold them loosely. Encourage this in the people around you. Be comfortable changing your views 180 degrees. Try your best to be right. But celebrate being wrong, because it’s a step towards being right. Ultimately, this all boils down to a scientific way of thinking. As Adam Grant says in his book Think Again:

I’ve noticed a great paradox in great scientists and superforecasters: the reason they are so comfortable being wrong is that they’re terrified of being wrong. What sets them apart is the time horizon. They’re determined to reach the correct answer in the long run, and they know that means they have to be open to stumbling, backtracking, and rerouting in the short run. They shun rose-colored glasses in favor of a sturdy mirror.

Playing the Long Game

2022-11-09T00:00:00+00:00

Photo by michael weir on Unsplash

I love sport analogies. Taking a mental model from a particular sport and applying it to different areas of life is always an interesting mental exercise. This post describes one that I keep coming back to.

I was once in a heated situation at work and responding to someone when another colleague told me something profound. He said: “Do you know you don’t have to react to everything?”. This stayed with me for a while. It sounded familiar to something I had heard about a decade before that experience. I was in my teens and playing Cricket in the nets, and batting against the leather ball for the first time. I kept edging a lot of deliveries. The coach came up to me and said something along the lines of: “Do you know you don’t have to hit every ball?”.

As Cricket itself has evolved into different formats, I keep thinking about this analogy. Test Cricket, which is considered to be the purest form, is played over the longest timespan. As a batsman, success in no other format beats what one achieves in Test Cricket. But success here is hard-earned. One has to be prepared to let a lot of deliveries go, and be very choosy about which deliveries to score off of. This is in stark contrast to T20 Cricket, which has a way shorter timespan, where the norm is more and more to look to maximise each delivery while placing a smaller premium on one’s wicket. So “letting a delivery go” is out of fashion here.

What the above tells me is that the longer the game one is in, the more they have got to be able to let something go. And not just let it go, but take it off their mind and start from blank for the next thing coming their way. Reacting to everything is something one does when having a shorter-term mindset.

A thing to note is that taking any model to the extreme is usually counter-productive. Just like leaving every delivery in Test Cricket and never scoring much becomes pointless after a while (and gets one dropped from the team), so is never reacting to anything. The trick is always choosing just the right things to react to and let most of the other things alone. Easier said than done, of course.

Related resource: The Infinite Game

Building Resilience within Constraints

2022-08-12T00:00:00+01:00

The constraints that life has placed at different phases have helped build a certain resilience that make me not take the eventual absence of constraints for granted. Instead I’m in a more balanced state to deal with the positive changes, while mindful that both success and failure are never permanent.

As Rudyard Kipling says:

If you can meet success and failure and treat them both as impostors, then you are a balanced man, my son.

Money

I grew up in the middle class Bangalore of the 90’s. In my formative years, there were phases where my parents could just about make ends meet. I remember in my early college days, my daily allowance would exactly afford me my bus charge to college and back. With my college being close to a commercial hub, I’d longingly look at the shops, wishing that one day I could buy all the gadgets, clothes, and food I wanted to.

About a decade and a half later, as I visited the same place, I could now afford to buy any of those. But I no longer wanted to buy everything anymore. I had learnt to live my life within limits.

Job

I worked at a company for close to 7 years in my late 20’s and early 30’s. The company sponsored my visa to live in the UK. Like any job, it had its ups and downs. During the days with downs, I wanted to quit and join another company. But I had to grin and bare as the hassle with shifting visa sponsorship was too high. I’d longingly look at job advertisements wishing that one day I could apply and go work wherever I wanted to.

A few years later, when I got granted permanent residence in the UK, I no longer depended on the company for my visa. I could afford to join any other company I wanted. But by then I had learnt to work through hard times. I no longer wanted to leave simply because of some hard days. I ended up staying on for a while after.

Title

Working my way into my career, I used to think that my lack of seniority and title comes in the way of sometimes taking opinionated decisions and pushing through with them. I used to think that one day I would have the title where I could simply tell people what to do and they’d listen.

And then when I got the titles and the power that comes with it, I no longer wanted to indiscriminately use it with people. I would rely more on influencing through building trust, relationships, rationale and narratives, the way I had learnt to over all the years without such titles.

Know the Bigger Picture

2022-04-13T00:00:00+01:00

The automatic rising arm at the entrance of my gym’s parking lot has been broken for the last few weeks. Everyday when I get in, I see the bit that is left of the arm (can I call it the shoulder?) still doing its job dutifully.

It was a good reminder that we can sometimes focus too much on doing our part of the job well and lose sight of whether the things around it are functioning as well.

We might think: “Hey, I’ve been tilting up to let the car through and reverting back down when it’s done and that is exactly what I was supposed to do”. But we forget that the actual job to be done was controlling the cars getting through, and that job is no longer being done.

Related thought: Start with Why

My Approach as an Interviewer

2021-05-22T00:00:00+01:00

I have conducted many interviews over the last few years. I have also been on the other side recently interviewing for a new role. Both these perspectives have helped shape two simple guiding principles I follow for when I’m interviewing a candidate for a role.

Principle 1: Create a positive value add for the team hiring the role
Principle 2: Facilitate the candidate landing their next role

Principle 1: Create a positive value add for the team hiring the role

This principle might sound obvious. But to do it well, it is necessary to understand the gaps in the team. While this is easier when I’m interviewing for my immediate team, it needs some due diligence when stepping in to interview candidates for other/wider teams. In those instances, in addition to the job description, I try to dig into a bit more detail with the hiring manager about the sort of work that the person joining the team would be doing. This is especially important when some job descriptions list so many things as ideal that it is really hard to find a candidate who checks all the boxes. Having a priority stack in mind of what are actually required, and what are nice-to-haves helps focus on key areas.

(Ideally the job description itself clearly distinguishes this, but I still run into many that don’t. That’s a whole different topic though, and I can refer the reader to check this article out.)

Principle 2: Facilitate the candidate landing their next role

This principle keeps me in the mindset of looking for reasons to hire rather than looking for reasons not to. When the candidate demonstrates enough skills/qualities that I’m convinced will add value to the team, the decision is simple: I recommend we hire them. But where this principle really makes a difference is when I’m convinced that the candidate is not a good fit. Rather than ending with a plain rejection, I make sure to write specific feedback. When doing so, I ask myself if the candidate was interviewing elsewhere in the near future, what are the small list of specific things they can work on which will increase their odds of success. They might not end up working for my company in this instance, but I feel I owe it to the time they have put in to help them along their journey.

The Kuchcha House

2021-01-17T00:00:00+00:00

It was a summer afternoon. This meant it was the season of mangoes. Every year, around this time, we would have a plastic tub at home that seemed to always be filled with mangoes. This year was no different.

I was around 6 or 7 years at the time. It was summer vacations at school, so I was mostly at home. I finished my lunch and took two mangoes from the tub. I had to have lunch first. The grownups used to say: “Have a jackfruit on an empty stomach, and have a mango on a full one”. If the grownups said it, they were probably right.

I ate my mangoes fully, except for the skin and the seeds of course. They were ripe and sweet, and I remember thinking that nothing else comes close to how happy it made me feel. I then went and threw the mango skin and seeds out of our rear balcony.

Our house was a two-storey building. We lived on the first floor. We had a balcony on the back which faced an empty “site” – a plot of land allotted to build a house. Houses had already been built on either sides of this site. Whoever owned this site probably had no plans of building a house there yet. So it was in a pretty unkempt state housing a lot of weeds that wanted to grow there, the main one being parthenium. Us, as well as people from the houses on either sides of the site used to throw out garbage and food waste into the site.

I used to imagine this site as a “peninsula”. In school I had learnt that a peninsula is covered on three sides by water and one side by land. I equated this site being covered on three sides by houses (one of it our own) and one side by the road in front of it to being a peninsula. Our schooling then was limited to what we saw in text books. This was before computers and internet became commonplace. So to think beyond what we saw in a text book, one’s imagination was the only way. You can see why I imagined the site as a peninsula – I couldn’t really go see an actual peninsula.

One morning a few days later, when I went to throw some waste away, I was pleasantly surprised by something else that had cropped up in the site pretty much overnight. This was another thing I had learnt in school, and only seen in the text books – a hut. I had learnt that there were two types of houses: pucca houses and kuchcha houses. Pucca houses were built strongly in a way that would withstand the weather and other challenges well. Kuchcha houses, on the other hand, could not withstand these well as they were built of weak materials like straws, hay, and other materials like a dried old coconut tree’s leaves. I knew we lived in a pucca house, but I had never seen a kuchcha house. Until that day.

I stood staring there in amazement. It looked like a family of four – a couple and two kids – were living inside. One kid was very young, probably less than two years old. The other one was around my age. I wondered if he went to school like me. His mother seemed to dress in a manner that was similar to the maid who used to come clean our home everyday. Our maid used to bring her kid with her who used to just sit in a corner while the mother finished the chores. I wondered if this kid in the site behind also just tagged along with his mother on her everyday work. I was envious of him, because I had to get ready and go to school on time. He appeared to be free.

I came back inside excitedly and told everyone that there is a kuchcha house behind our house. I opened my textbook and saw the picture in it. This hut looked so similar. I couldn’t wait to go to school and share this news with my friends. However, to my astonishment, I did not get the reaction I expected from the grownups. They didn’t seem to share my excitement. They went to the rear balcony. Folks living on the either sides of the site had also come out. They were enquiring the family who had moved into the hut – “Who are you?”, “Where are you from?”, “Why have you built this hut here?”. The tone of questioning didn’t seem friendly or enthusiastic.

I headed to school and shared the story of the magical kuchcha house that had been built overnight with my friends. I pointed to the picture in our textbook and told them it looked exactly like in the picture. I promised I’d show it to them if they visited my place.

On getting home in the evening, I rushed to the balcony. The hut wasn’t there anymore. I was confused and disappointed. I asked folks at home about it. They told me the hut wasn’t supposed to be there. That the people in the hut did not own the site. Folks of all the houses around the site had opposed to them being there and had forced them to move out. The grownups told me it was for the good of everyone. They told me that the folks in the kuchcha house would have littered the site if they had been allowed to stay for long. If the grownups said it, they were probably right.

Slowly, I washed my face and had my dinner. I followed it up with two mangoes. I then went and threw the mango skin and seeds out into the site behind.

If All You Have Is A Hammer…

2020-12-18T00:00:00+00:00

Over the last few years in my work, I have come across situations where a particular technology has been sold as a silver bullet. This is usually by people who have seen those technologies succeed for them under a certain context, who then push for adopting the same in wider contexts.

I have seen this tendency result in a push for using an event-driven way (and use Kafka) in cases where a traditional request-response mechanism would have been simpler. I have seen folks building an in-house framework for isomorphic rendering and evangelise its adoption when common sense suggests to pick a rendering approach based on specific needs. And most recently, I have had to contend with folks pushing to use React to construct email content.

A good consequence of going through this experience repeatedly means now I am able to clearly articulate a thought process to counter such silver bullet tool/technology prescriptions. It starts with two questions:

Does using the recommended tool/technology drastically simplify solving the problem at hand?
Do the people on the team have the skill in (or the appetite to learn) this new tool/technology?

If the answer to the first question is “No”, then there is not enough of a reason to adopt something new. And this becomes especially true if the answer to the second question is also a “No”.
If the answer to the first question is “Yes”, then it is worth pushing for it a bit even if the answer to the second question is “No”. But ultimately the success of adopting the new approach will be dependent on how well the team buys in.
Needless to say, two “Yes”-es is the ideal situation to use something new.

Let me now walk through applying this thought process for the “use React to construct email content” argument. The people recommending to use React were developers who had used it successfully to build interactive web components (and some folks who had not really used React but had drank the kool-aid).

The first question now became: “Does using React make generating HTML content for email simpler?”. My first answer is “No”. Let me elaborate…

The main difference between the general web (where React shines) and email is that the latter does not really have the concept of JavaScript executing on the client-side. React is a JavaScript library for building user interfaces (and it especially shines for its declarative nature of building interactive UI on the client). Putting these two statements together logically leads to the observation that using React is not really a first-pick for constructing email content.

But I still wanted to entertain the counter-point. I tried to think what could make the answer to “Does using React make generating HTML content for email simpler?” a “Yes”. And one situation where that can happen is if a team is already super-comfortable using React and have already built a library of components in a way that those components can be reused as is within email (Note: this is a huge leap of faith because building for email is in some cases trickier/hackier than building for the browsers). And this brought me to the second question…

“Are people in the team already familiar with React?”. The answer was a “No”. The team was mostly made of folks who were very familiar building email content using HTML (via a templating language) and CSS for years. It made no sense to suddenly make all of them learn JavaScript (and React specifically) just because some developers who built web components using the same felt we ought to give it a try.

As the answers to both questions were a “No” for our context, the decision became obvious.

I think with respect to learning a new technology, people can go through these phases in order:

Reluctance to use the technology as they don’t know it
Appetite to experiment with the technology
Familiarity with the technology and a tendency to advocate for its use anywhere and everywhere
Wisdom about the technology – knowledge when to use it, and more importantly when NOT to

When someone advocates for a technology, try to figure out if they are in 3 or 4. If they are in 3, beware and take what they say with a pinch of salt.

Working Backwards to the Technology

Context We See People In

2020-09-13T00:00:00+01:00

If you have ten shirts and uniformly spread out wearing them, you would repeat a shirt every two weeks (assuming a 5-day working week).

If you have a recurring meeting with someone everyday, they would come across the variation and probably not spend too much attention on one single shirt. At the other end, if you are meeting them once every two weeks at regular intervals, they might think you only have one shirt you always wear.

In most cases, our randomness in shirt selection probably addresses this, but that’s not the point of this post. The point is extending this thought to beyond fashion: one thing to ask yourself when pigeonholing someone is if you always see them in the same context. Maybe you’d encounter a different picture if you occasionally saw them on a Thursday rather than a Monday.

Better Define Work-Life Boundary While Using Things

2020-07-16T00:00:00+01:00

Working from home became the norm this year. While many people expected a drop in work productivity, the inverse turned out to be a dark horse. In the beginning, I easily kept sliding back to work even after my typical work hours. Got a Slack ping from someone in the US my night time (I’m based in UK), no problem – my work laptop is one room away. Unsurprisingly, soon all boundaries between work and home were blurred.

I knew this behavior wouldn’t be sustainable for the long run. I had to design a way to make that boundary more clearly defined again. I removed all work-related apps from my phone. I didn’t really need to have Slack or work email in my hand/pocket anymore. If I badly needed to check on something, I was never going to be far from my work laptop anyway. And I tried to be disciplined about not returning to open my work laptop at crazy hours.

This worked well. But there was one problem. I use Things as my GTD system of choice. Up until now, I had one Things account and I’d capture all work tasks under a separate Area of Responsibility in Things. As I kept using Things this way, I realized this system still did not have the boundary between work and life that I was trying to achieve. Having work-related tasks visible in my Inbox, for example, would again trigger the urge sometimes to go action on it immediately on my work laptop. I had to break clean. The solution was simple: I created a separate Things account.

That’s where the story should have ended. But it’s not that simple. Ideas can come anywhere, and Things was my trusted system to capture those. Now, if late at night, I suddenly got an idea about work I couldn’t put it in Things because my personal devices only had my personal Things account. I didn’t want to go and open my work laptop again. I wanted a fire-and-forget way of sending a quick idea/task to my work Things account without really having to go and open my work Things.

And I did exactly that using Things’ Mail to Things feature and a nifty shortcut in iOS.

First, I enabled Mail to Things. The instructions are documented here. This provides an auto-generated email address which I copied over.

I then set up a workflow in Shortcuts. If you do not have Shortcuts installed, get it here (it can make your life simpler in various ways beyond what this blog post covers!). When the workflow is run, it prompts me to enter some text representing the task/idea I want to capture. It then sends this over as an email to my Mail to Things address. I can then immediately take my mind off it knowing I’ll find it safe in my work Things Inbox the next morning.

By checking the box to show this workflow in the iOS Widget, I can now trigger this directly from the widget screen making the whole process of capturing a task almost absent of any cognitive load, which is exactly how it should be.

Docker and Kubernetes Learning Resources

2020-04-27T00:00:00+01:00

In 2018, I was new to Docker. In 2019, I was new to Kubernetes. Over the last year, I have been working a lot with both.

While I believe the best way to learn any new technology is to use it continuously, there are usually some resources that help start off with a technology simpler than otherwise. In this post, I list the ones which made Docker and Kubernetes easy for me.

Docker – From the Beginning

This series of blog posts from Chris Noring was completely accessible to me as a newbie, and helped me start with a good foundation.

Kubernetes Basics

As I was looking for something similarly accessible like the above, this series by Daniel Sanche fit the bill.

Kubernetes – From the Beginning

Note: I have not gone through this series because by the time it was published, I was already comfortable with Kubernetes. I list this here simply because it is from the same author as the Docker series above, and so I expect this to be a beginner-friendly resource.

Visual Studio Code Kubernetes Extension

If you are not a VS Code user, I would recommend you still install it just for this. And within VS Code, install the Kubernetes extension. This extension gives you a clickable way to explore all the Kubernetes concepts within your cluster.

If you click on the Kubernetes icon on the sidebar, you will have your clusters listed. Once you choose a cluster, you will get a tree structure that you can click to expand/collapse and explore.

You can then click on any of the leaf items, pods for example, and it’ll open up its YAML definition which you can study.

You can also right-click on these items, and get a context-menu to launch further actions like following logs.

All of these are, of course, possible by using the kubectl command-line. But I found mastering those commands not easy to begin with. Using the VS Code extension’s GUI, and visually organizing the concepts in my mind first helped me later when I started using the command-line more.

Kubernetes – Up and Running

A few days into working with Kubernetes, I got a copy of Kubernetes Up & Running by Kelsey Hightower. Reading through it, and connecting the concepts to my everyday usage helped solidify the learnings.

Gamifying Continuous Integration

2016-11-21T00:00:00+00:00

Originally posted on Expedia’s Tech Blog.

For the last couple of years we’ve been moving applications from our data centers into the cloud. One of the advantages of moving to the cloud was that we could host our applications in different geographical regions bringing them closer to the user. Also each team working on an application gets the chance to easily have their app hosted on multiple environments (test/stress/integration/production). Having multiple versions of an application running at the same time across multiple regions and environments brought its own challenge of visibility. It was not straight-forward to know what’s running where and when.

To solve this problem we started collecting data (based on events) about everything that happens in terms of our applications getting built, deployed, and deleted. This helped power dashboards that improved the visibility over what’s hosted where. Over months of collecting data, we started realising more usages for this data. One of the other characteristics of our team is that we are a very diverse group of engineers all over the world using a range of technologies. We’re always interested in ways to help spread and share great ways of working. With that in mind, one of the usages of this data we’re trying is a little game we created called Primer Go — “Primer” for the internal name we have for our CI/CD system, and “Go” inspired by Pokemon Go (it was over coffee talking about Pokemon Go which lead to a couple of us to think that we should create a game of some sort around our CI/CD).

Primer Go is a monthly league. The scores get reset at the beginning of the month, and at the end of each month we have the application at the top of the league being declared a winner. The participants in the league are the huge number (over two thousand on last count) of different applications we have running. There are some minimum criteria that an application has to meet to be eligible to be on the league in a month; for example: they should have at least 3 new versions released to production. Each eligible application is scored (on a scale from 1 to 100) in multiple categories, and then the average across all categories is taken. As of this writing, there are 4 scoring categories:

Repository Information

Within the company, we encourage having an open-source model of working. This means that any team can contribute to any project by just building the new feature they want and opening a pull request. For this to be effective, it is important that everyone make their repository more accessible. This means having high quality and up-to-date README file, contribution guidelines and notes about testing. We have a category in Primer Go that scores applications based on the above information being present, and on how recently they were updated.

Small Changes

We encourage people to have a higher number of smaller pull requests, rather than one (or very few) huge pull request. This helps build stuff incrementally, makes it easier to isolate and roll back specific issues, and is also easier to review (increasing the chances of the code review being of a higher quality). This category within the game awards points based on the number of pull requests merged into the application in the month. The number of active developers on that application in the month is also taken into consideration to ensure that team sizes don’t heavily influence the scoring in this category.

Release Frequency

How frequently we are able to get new changes out for our users in a main factor that determines how well we are doing Continuous Delivery, and our game has a category to measure just that. We check how many new versions of the application were released to production in the month, and then divide that by the total number of versions (pull requests) merged into the code base. Teams that are closer to 100% in this category are the ones that are releasing each change in isolation into production before further changes are merged on top of it.

Release Speed

This category measures how long it takes from the moment a change is merged into the main branch to the moment that change is released into production. The faster this is, the greater the score. This category makes people think more about their build pipelines (parallelising effectively), testing architecture, and the CI/CD infrastructure itself.

Every month, the league helps us:

Recognise applications that are doing well. This also means that teams thus identified have a platform to share their best practices across the company.
Recognise areas of improvement for each application.
Have some fun :smile:

We’re constantly tuning and updating the criteria based on feedback from the community and data we’re seeing in the wild. Development metrics are great informers but if you rely on them exclusively or too heavily it is easy to accidentally encourage the wrong behaviors. So far we’ve found this sort of friendly competition is a great way promote how we want to work across a large audience.

Grails Multi-Tenant Plugin & Spring Security Filter

2011-12-05T00:00:00+00:00

We had a long-standing issue in our Grails project, where the “remember me” functionality was not working as we expected it to. It was behaving very inconsistently. Sometimes the user would be remembered, and sometimes not.

Our application uses the spring-security plugin for authentication, and I initially wondered that there might be a bug in the “remember me” functionality of the plugin. On further investigation, I noticed that the problem was not actually in the spring-security plugin.

Our application also uses the multi-tenant-core plugin, which resolves the tenant based on the request. The problem was that sometimes the multi-tenant-core plugin was not resolving the tenant (returning 0 instead) when called within the authentication code of the spring-security plugin. Therefore, spring-security was not finding a user by the respective username within the tenant represented by 0 (as such a tenant did not exist).

The reason this was happening was because the multi-tenant-core plugin has a filter which calculates the current tenant and spring-security has its own set of filters. The application was behaving as expected when multi-tenant-core’s filter executed before spring-security’s remember me filter, and erroneously otherwise. To fix this problem, we had to make sure that the multi-tenant-core plugin’s filter would always execute before the spring-security filters.

Adding a line to our application’s BootStrap.groovy did the trick:

import org.codehaus.groovy.grails.plugins.springsecurity.SecurityFilterPosition
import org.codehaus.groovy.grails.plugins.springsecurity.SpringSecurityUtils

class BootStrap {
    def init = { servletContext ->
        ...
        // To make sure it executes before all authentication filters
    SpringSecurityUtils.clientRegisterFilter('multiTenantFilter', SecurityFilterPosition.PRE_AUTH_FILTER.getOrder() - 1)
        
        ...
    }
    ...
}

Hibernate & MySQL Spatial Index

2011-11-30T00:00:00+00:00

While working on a Grails application which required spatial queries, I came across a problem. I had to make use of the MBRContains function in MySQL. Since I was using Grails which in turn uses Hibernate, the HQL query I would write had to support these spatial functions.

I used an extension of Hibernate Spatial dialect for the application’s data source dialect which I have explained in the previous post.

A few days after writing the code to perform some complex queries (which included spatial clauses in it), we noticed that the site’s performance was getting slower. While investigating, I found that for some reason, the MBRContainsfunction was not making use of the spatial index we had added on a column. This was a bit strange.

I then obtained the SQL query that was being generated from the HQL query. We had the following as part of the where clause in HQL query:

... and mbrcontains(GeomFromText(:boundary), location) = true ...

As expected, this was generating an SQL query in this form:

... and MBRContains(GeomFromText(?), location) = 1 ...

When I tested the above generated SQL query using EXPLAIN, I found that the spatial index was not being used by the query. A quick search on Google showed me that I was not the only one with this problem. The problem here was the “= 1” being generated in the SQL query because of the “= true” in the HQL query. This, for some reason, was preventing the spatial index from being used. If I removed the “= true” in HQL query, it was resulting in some Unexpected AST node exception in Hibernate.

I couldn’t find a proper solution for the problem anywhere on the net, and ironically XKCD published this cartoon on the very same day. We finally decided to rewrite the whole complex query in plain SQL to overcome this problem.

About a week later, when it was time to start rewriting the query, I still felt a bit lazy about it. If only there was a simple way to solve the above problem, it would prevent me from having to sit for the next 2 to 3 days and rewrite a pretty complex query and test it thoroughly. And then I realised there was actually a way. It was quite simple actually, and sometimes it is the simpler things we tend to miss.

All I did was register a new function with a tiny bit of hack in the MySQLDialect of our application:

registerFunction("mbr_contains", new SQLFunctionTemplate(Hibernate.BOOLEAN, "MBRContains(?1, ?2) and 1"));

And then I used this function in the HQL query. The query now became something like this:

... and mbr_contains(GeomFromText(:${boundaryVariable}), location) = 1 ...

which is valid HQL, and also generates SQL which makes use of the spatial index:

... and MBRContains(GeomFromText(?), location) and 1 = 1 ...

Combining MySQL Full-Text & Spatial Search In Grails

2011-11-02T00:00:00+00:00

In the Grails project I’m currently working on, we were required to have a search functionality which would take into account, among other things, location data (spatial query) and keywords (full-text query). For this we required our Hibernate queries to support the relevant features. This would be possible by using an appropriate MySQLDialect. For spatial queries, we could use this dialect: org.hibernatespatial.mysql.MySQLSpatialDialect. However, we also wanted Hibernate to support full-text queries. So I extended this dialect and wrote a custom dialect for our application. In this case, our custom dialect looked something like this:

package org.philevents;

import org.hibernate.Hibernate;
import org.hibernate.dialect.function.SQLFunctionTemplate;

public class MySQLDialect extends org.hibernatespatial.mysql.MySQLSpatialDialect {
    public MySQLDialect() {
        super();
        registerFunction("match_against",
            new SQLFunctionTemplate(Hibernate.BOOLEAN, "match ?1 against (?2 in boolean mode)") );
    }
}

We now have a match_against function available in Hibernate. This takes two arguments (represented by ?1 and ?2) and performs the full-text search using MySQL’s match...against.

Next, we have to make sure that our Grails application uses the above dialect class. This is done by configuring the dialect of the dataSource in /grails-app/conf/DataSource.groovy. Since I was using different data sources for different environments, my configuration looked something like this:

environments {
    development {
        dataSource {
            ...
            username = "..."
            password = "..."
            dialect = org.philevents.MySQLDialect
        }
    }
    test {
        dataSource {
            ...
            username = "..."
            password = "..."
            dialect = org.philevents.MySQLDialect
        }
    }
    production {
        dataSource {
            ...
            username = "..."
            password = "..."
            dialect = org.philevents.MySQLDialect
        }
    }
}

Now a full-text query can be executed by something like this: Let us assume we have a Book domain class which has a field called abstract. We now have to search this field based on some given keywords. This is done by:

def results = Book.executeQuery("from Book b where match_against((abstract), ?) <> 0", [keywords])

Spatial queries can be executed by the features provided by the HibernateSpatialDialect class, and are available in our application as our custom dialect is a subset of it. Details of how we used spatial queries in our application will be provided in a future post.

Grails Image Crop Using Jcrop

2011-05-31T00:00:00+01:00

You might have seen many websites nowadays have a profile picture. And when you upload a profile picture, you are usually prompted to crop the picture (sometimes with certain forced resolution), and it is this cropped picture that is used from then onwards. I was required to implement a similar functionality in the Grails project I’m working on. I decided to use Jcrop for the JavaScript side of the cropping mechanism as it was based on jQuery and we were already using jQuery in our application. Here, I illustrate how I did the job.

I first downloaded Jcrop from here. The downloaded zip file contains, among other things, two folders: /css and /js. I copied the contents of these two folders into /web-app/css and /web-app/js/jcrop directories (respectively) of my grails application.

Now I have the required tools for cropping. I had previously saved the image uploaded by a user (see here to read about file uploads in grails). In my gsp (view), I first render this image and give it an id.

<img id="picture" src="${resource(file: imageSource)}" />

I then added the following within a script tag in the same gsp to initialize Jcrop:

$(function() {
    $('#picture').Jcrop({
        aspectRatio: 1,
        setSelect: [0, 0, 100, 100],
        minSize: [100, 100],
        onSelect: updateCoords,
        onChange: updateCoords
    });
});

Since I use Jcrop (and in turn jQuery), the required javascript and css files should be included. So, I added the following lines within the head section of the gsp:

<link rel="stylesheet" href="${resource(dir:'css',file:'jquery.Jcrop.css')}" />
<g:javascript plugin="jquery" />
<g:javascript src="jcrop/jquery.Jcrop.min.js" />

Now if you look back at the script to initialize Jcrop, you can see that I have mentioned updateCoords as the method to be called on selecting or changing the cropper element. So we should now provide the updateCoords method. I added this within a script tag in the head section of my gsp:

function updateCoords(c) {
    $('#x1').val(c.x);
    $('#y1').val(c.y);
    $('#x2').val(c.x2);
    $('#y2').val(c.y2);
}

x1, y1, x2 and y2 above are ids of hidden fields that will save the co-ordinates of the crop layout. This is how I have included them in my gsp within a form:

<g:form action="savePicture">
    <g:hiddenField name="x1" value="0" />
    <g:hiddenField name="y1" value="0" />
    <g:hiddenField name="x2" value="100" />
    <g:hiddenField name="y2" value="100" />
    <g:submitButton name="Crop and Save" />
</g:form>

Now, when the user adjusts the cropper and presses the submit button, the co-ordinates of this cropped layout will be available to the controller method. Using this we can crop the image in our controller (using various ways) and save it. This is one way to do it:

def savePicture = {
    def x1 = params.x1 as Integer
    def y1 = params.y1 as Integer
    def x2 = params.x2 as Integer
    def y2 = params.y2 as Integer
    File tempPicture = new File("/path/to/original/file")
    BufferedImage image = ImageIO.read(tempPicture)
    BufferedImage croppedImage = image.getSubimage(x1, y1, x2 - x1, y2 - y1)
    File profilePicture = new File("/path/to/new/cropped/file")
    ImageIO.write(croppedImage, "jpg", profilePicture);
    FileUtils.deleteQuietly(tempPicture)
}

Note: The fully qualified names of classes used above are java.io.File, java.awt.image.BufferedImage, javax.imageio.ImageIO and org.apache.commons.io.FileUtils.

Custom Password Encoder For Grails Spring-Security Plugin

2011-05-31T00:00:00+01:00

The spring-security (core and others) plugin is very handy for incorporating user (and role) based functionalities for a grails application. The plugin comes with a lot of features out-of-the-box. And more often than not, some of the basic features can be used as is. However, there are occasions when a little bit of customization might be required.

In my current project, I was required to use a custom password encryption algorithm. The spring-security plugin uses the SHA-256 algorithm by default. This can be changed to use other standard algorithms (MD2, MD5 etc.) by adding the following lines (if, for example, MD5 encoding is required) in /grails-app/conf/Config.groovy:

grails.plugins.springsecurity.password.algorithm = "MD5"

But what I wanted was to use a custom algorithm of our own, not the standard ones. Fortunately, this is again, very easy. Because of Spring’s dependency injection, we can easily create our own password encoder and inject it. I have outlined how I did this below.

I first created a PasswordEncoder class which implemented Spring’s PasswordEncoder interface. I then overrode the methods of the interface according to our requirements.

class PasswordEncoder implements org.springframework.security.authentication.encoding.PasswordEncoder {

    @Override
    String encodePassword(String password, salt = null) {
        def encodedPassword
        /* TODO Encode the password using a custom algorithm */
        return encodedPassword
    }

    @Override
    public boolean isPasswordValid(String encodedPassword, 
        String rawPassword, salt = null) {
        return (encodedPassword == encodePassword(rawPassword, salt))
    }
}

Once this is done, I just injected the PasswordEncoder as a bean in the application context. In grails, this can be done by declaring the bean in /grails-app/conf/spring/resources.groovy:

beans = {
    passwordEncoder(packagename.PasswordEncoder)
}

And that’s it! The plugin will now use this custom password encoder for encryption.

My Eureka Moment in Software Engineering

2011-02-14T00:00:00+00:00

Originally posted on the Graduate Developer Community Blog.

My name is Vithun Kumar Gajendra. I am originally from India, and completed a Master’s course in UK under a student visa. Before coming to UK, I worked as a Software Engineer for about 15 months, and I was very much in the thick of action. This work experience would also go on to help me to understand the stuff I studied in the Master’s course even better. My experience here was like a typical recent graduate who enjoyed doing quick programming tasks at college level. I used to solve problems very quickly (I used to be the quickest in my batch at office!), and would go on accomplishing a lot of things within these 15 months. I worked on problems and mini-projects in fields ranging across Shell scripts, CSS, JSP, Servlets, Oracle PL-SQL, SOAP Web Services, a bit of Spring etc. I had a good time working as part of a team making use of tools like CVS, Bugzilla etc. I also got introduced to how tools like Eclipse, Maven, Ant, Hudson etc. were being used in a development environment (I had no idea about the existence of some of these tools before!). In short, this was a period where I was a really good jack of all trades, but unfortunately the master of none. I now look back at that time, and feel that my speed was actually a curse. I did not have the patience to stop and look in detail at some of the things I had done and understand them in depth. I just thought I could do anything and did not worry about how I did it.

I then came over to the UK to do my Master’s course. I did an MSc in Advanced Web Engineering in the University of Essex. It was here that I had my first “eureka” moment. I had this module called “Software Design and Architecture”. In this module, I was formally introduced to the concept of “coupling” in software engineering. And I suddenly realised that I had never thought about writing code in a clean way before. All that I focussed on before was to write code that would get the job done. Now I suddenly realised that there was a good (“artistic” if you might) way to write code. I suddenly realised what a fool I had been! And all of a sudden, I began realising the role of concepts like refactoring and design patterns. (I had been part of a “refactoring” team in my previous work experience without having this knowledge). And now, I turned wise. I realised there is always much more to learn (and apply).

Once I completed my Master’s, I had to wait a few months. I could not find a job as I was still under student visa. And I wouldn’t get my work visa until I got my degree results. So it was in this period that I decided to have a look at Spring. You might ask: Why Spring? I had been introduced to Spring at Mformation. I was required to rewrite existing DAOs using Spring templates and thereby eliminate boilerplate code. I just followed the instructions of my team lead: “Rewrite the code using Spring methods. Declare something in some XMLs and it would work.” It did work, and I did not care at that time how it worked. For some reason, after my Master’s, I thought I’ll have a look at how this worked. And then another eureka moment struck me. Spring was not something that just helped in simplifying DAOs. It was LOTS more than that. I began studying it in detail from the basics(Dependency Injection, Aspect Oriented Programming). The more I read about it, the more I started getting excited.

By this time, I got an internship offer. They required someone with HTML and MySQL skills, and although I wanted to work with Java, I tried to keep myself occupied until I got my work visa. But my interview here went rather well, which in turn made them think about my position as being somewhat permanent and not just an intern. However I joined on a temporary contract (as I still had just a student visa). I was given an in-house problem (of reasonable complexity) to solve. I came up with a concept, which I thought would work. I wrote a proposal, and my manager suggested me to implement it using PHP. I requested him if I could do it in Java, and after a bit of reluctance (because PHP was used mainly for development within the company) he agreed. I now got the platform to use my Spring knowledge (gained mainly by reading and doing small examples). I developed a proof-of-concept within 7 days. Through this course, I made use of Spring, Hibernate, Maven and Eclipse. I created a well-structured and organized code-base. My manager was impressed with the solution and the speed at which I implemented it. He considered it an “elegant” solution to the problem. And this time I was satisfied that my speed had not come at the cost of learning. I understood more about Spring and my interest in Spring has increased even more. I informed the management that I did not intend to take up a permanent position (because they were looking for someone who would do more with PHP, and I did not want to give up Java and Spring, and I also wanted to relocate to London). So towards the end of my tenure, I had to explain the application I had created to a colleague who had a good understanding of Java, but no knowledge of Spring/Hibernate. Within the next couple of days, I managed to impress her with what all Spring had to offer. She was also able to easily pick up the code I had written (and the best practices I had followed). She also decided to use my proof-of-concept as the base and extend it to completely satisfy the requirements. I left the place with a very good feeling and a sense of accomplishment, and with good relationships forged.

Vithun's Blog

50 Years of Apple

Look Forward, Not Back

Work Backwards to the Technology

Innovation Does Not Happen Overnight

The Work is Your Brand

Team First and a Long Term View on People

180 Degrees

Playing the Long Game

Building Resilience within Constraints

Money

Job

Title

Know the Bigger Picture

My Approach as an Interviewer

Principle 1: Create a positive value add for the team hiring the role

Principle 2: Facilitate the candidate landing their next role

The Kuchcha House

If All You Have Is A Hammer…

Related Thought

Another Related Thought

Context We See People In

Better Define Work-Life Boundary While Using Things

Docker and Kubernetes Learning Resources

Docker – From the Beginning

Kubernetes Basics

Kubernetes – From the Beginning

Visual Studio Code Kubernetes Extension

Kubernetes – Up and Running

Gamifying Continuous Integration

Repository Information

Small Changes

Release Frequency

Release Speed

Grails Multi-Tenant Plugin & Spring Security Filter

Hibernate & MySQL Spatial Index

Combining MySQL Full-Text & Spatial Search In Grails

Grails Image Crop Using Jcrop

Custom Password Encoder For Grails Spring-Security Plugin

My Eureka Moment in Software Engineering