Monthly Archives: August 2019

Cheat Sheet To Good Experiences

I wasn’t sure where an article like this belonged. Essentially, I wanted to document some of my philosophies (which is just a fancy way of saying that if I face a situation, these are the guiding principles that help me make decisions) that I think have helped me experience a lot more positivity within and from others wherever I’ve been (but mostly concerning places away from home). These are, of course, very personal and subjective. As with everything, I expect these to evolve over time and I myself might disagree with some of them at a later point in time. But then, reading my old thoughts and values, and documenting the new ones is exactly the point of this blog anyway.

Writing them down in no particular order.

Smile first

On an imaginary (and intuited) bell curve that covers all of humankind (and dogs), from the ones who wouldn’t smile no matter what you do, to the ones who’d smile without any reason, I find that most people fall around the region where they’ll smile if they get a smile, where smile is just a metaphor for acting kindly in some way. That is to say that most people are good at heart, just not very upfront about it. A small act of kindness from our end is enough to tap into that ocean of goodness that just lies below the hard top surface.

My point is, most people are super nice in some or the other form

The worst that happens here is that they don’t return the smile back, but giving away is usually in itself quite rewarding. Between a win and a jackpot, and I’m good with either.

Assume best of intentions; Try seeing things from a different perspective

Many things make sense only when we see them from another point of view. And thanks to the complexity of the world we live in, that’s not always possible. There are far too many factors that can influence the way a person thinks. Acknowledge that. Try to see if the case in question has a right/wrong solution or is it just a matter of difference in perspective. More often that not, latter is the case. For that reason, give the other person the benefit of doubt. Probably they had a good reason for acting in a certain way or saying what they said.

Don’t judge before understanding

One useful tool that I’ve developed over time is to resist the urge to judge someone or something before I have a complete understanding of the picture. Even if I somehow think I do, just knowing that a simple picture with zigzag lines is enough to confuse my mind, let alone complicated situations with hundreds and hundreds of variables, keeps me away from making very bold statements and trusting my thoughts too much.

Optical Illusion – Wikipedia

In this case, being a software developer helps too. Anyone who has done any software engineering knows that no matter how good they get, they can never make statements like my code doesn’t have any bugs. In fact, the more software one writes, the less likely one is to make a statement like that. The same is true, I feel, for other walks of life.

Don’t be scared of looking stupid, making mistakes

Things will go south from time to time, not work out as per plan and even leave lasting bruises. Ideal outcome is just one of the many possible outcomes. I think these setbacks matter much less than our attitude in dealing with them. Sure, there’s the momentary joy in seeing things work out well, but there’s learning in seeing things not work out well. And learning goes much further than momentary joy (and of course, difficult times make for great stories).

Think of all the people in high school that you were once too scared to look stupid in front of. Think of the number of extracurriculars you didn’t participate in, skills that you didn’t learn, questions you didn’t raise your hand to answer to, just so that you could save yourself the momentary embarrassment in case you mess it up. Think of how many people are still in touch with you, or care about you, or even think about you once in a month. On this Earth-sized stage, the only definition of sanity is the one you set for yourself.

Laugh at yourself

Nothing is more powerful than the power to laugh at yourself. All of us have enough mistakes under our belt to write fat comic books out of it. From accidentally making inappropriate remarks that make me cringe whenever I remember them, to less intense fun mistakes that were quite painful at the time, I’ve done it all. And I’m not going to keep a straight face if you tell me you haven’t.

Don’t take it too seriously

I think we often overestimate how important we are. We’re granted a very limited time slot on this Earth stage, so why spend it under a false illusion of self importance and delusional (sometimes pretentious) seriousness. I think of myself as a macro-nihilist, meaning that while I understand the importance of my everyday, micro activities, I keep my emotional extremes in check by not forgetting that in the long run, none of my epic successes or catastrophic failures really matter much.

Being open to new cultures

You can’t shake hands with a closed fist. Similarly, if you’re too proud of the fact that you were randomly born into a specific geographic location or culture or religion or speak a particular language, you’ll find it very difficult to accept the majority of the human race that just as randomly happened to be born in another location or culture or religion or speak a different language. For me, it is a matter of celebration of similarities and differences, of simulating my life in a new culture and environment. That arouses a genuine interest in knowing things, and most people are willing to talk for hours if you show an interest.

On the other hand, being too proud of accidental things, while does feel good to practice thanks to our evolutionary history of tribalism, doesn’t help much when we meet people and experience cultures which are very different from our own.

Being predictable

When I was little, there was this thing about being unpredictable that I thought made people cool and edgy. But as I grew up, I realized that I’m most comfortable around people who’re predictable. That doesn’t necessarily mean that I agree with them all the time, but just that they’re consistent in their behavior even with things, thoughts and ideas that I don’t agree with.


That’s what I try to adopt for myself. Just trying to be consistent with the way I am, having a more values driven approach towards decisions. It is like being a particularly shaped piece in a box full of puzzle pieces that’s constantly shaking. You can be weird, crazy, stupid, no problem. Eventually, you’ll end up with other pieces you are a perfect fit with.

In closing

I hope this article was interesting for you to read. I certainly did have fun writing it. I’m curious to read this piece again in about a year or so and see if there’s anything to add or remove. Thank you for reading. Ciao!

How To – 12 Column Grid Library From Scratch

As web developers we’ve used countless UI libraries that give us an interface for creating grids. Now things have become much easier thanks to Grid and Flexbox in CSS, but it is still nice to have everything arranged in nice consistent classes for production use. Recently, I set out on a mini-mission to find a grid library for our new design system. In my search, I had to go through many libraries, their features and their source code. Most of them were 90% fit for my use case, but then I’d find some flaw that’d put me off. This continued for a couple of hours, at the end of which I uttered the golden developer words “I know, I’ll just implement my own grid library”. The old folks here know what follows. They also know, irrespective of whether you know if this is a bad idea, the temptation to start working in an empty file without any dependencies is too real to just ignore.

Anyway, after spending some time baking my own grid library, and slowly realizing that in probably a week or so, I’ll end up with exactly the kind of code that I’d rejected earlier, given how similar everything was looking, I decided to go with something readybaked. But this little exercise of trying to make a grid library taught me a lot about how these libraries are implemented. I wish to share some of that excitement, the learnings with you in this article.

By the end of this article, I want you to have at least a basic understanding of how a grid library is written and be confident to dig into the source code in case you need to customize a library to fit your needs. Note that I’m using Flexbox. Bootstrap 3 used widths and floats, and Bootstrap 4 uses Flexbox. I believe you can also use CSS3 Grids. Use what feels natural to you.

What’s a grid system?

A grid means what you’d expect it to mean. It is a two dimensional cellular structure, like a cupboard or a chess board, and you can put/place stuff on/in it. In the context of web development and design, grids usually just define the vertical or columnar properties. The reason is that we do not want to design for horizontal scrolling, and assume that all navigation on a page will be based on vertical scrolling. As a result, whatever the screen width is, we take that as 100% and divide it into the number of columns that we prefer.

First step is to set the number of columns that we’d like the designs to use. 12 is commonly used because with 12, we can divide the page into 1, 2, 3, 4, 6 and 12 parts (notice that those are just divisors of 12). Then we set the gutter size. Gutter is the gap between two columns. Usually we set it to 1rem which, if we haven’t modified, should be 16px.

12 column grid with gutters (taken from MDN CSS Grid Layout)

After that, we set breakpoints. Breakpoints are points where our UI changes in response to a change in the screen size. For modern websites, we have to cater to a wide variety of browsers and screen sizes, and defining a set of screen sizes is our first step towards it. For example

  • 0-450px can be considered to be small mobiles
  • 450px-750px can be large mobiles
  • 750px-1000px can be tables
  • 1000px+ can be desktops

This is all very arbitrary, of course. we can set whatever sizes fit most of our users’ device types or just copy what Bootstrap or other popular libraries do (in general, when in doubt follow the standards).

Next is to actually implement designs that adhere to this grid system. Here we make an assumption that we have a UI hi-fi design mockup that was built using the same 12 column grid as base. For ease of implementation, we can define the CSS classes that we frequently use, which while not absolutely necessary, is helpful.

Basic CSS

While I mentioned that it isn’t absolutely necessary to have CSS classes that help us with grids, more often than not we’ll want to have some of them. The way we do it is we write classes for all the possible widths that a div might take on the screen, right from 1/12 to 12/12 (which is essentially 100% width).

.row {
  display: flex
}
.col-1 {
  flex-basis: 8.3333333% // (1/12)*100 
}
.col-2 {
  flex-basis: 16.666666% // (2/12)*100
}
// and so on

In this short snippet, a .row would be the wrapper class for one or more .col-X classes.

Styling our HTML

Consider the simple markup. This is a typical layout for a blog with a navigation section on the left, blog content in the center and a sidebar on the right with some widget.

<main class="row">
  <aside   id="navigation"></aside>
  <article id="content"></article>
  <aside   id="blog-roll"></aside>
</main> 

Now, if we want to split the page into three columns; left sidebar (25% or col-3 containing the “.navigation”), main content (50% or col-6 containing “.content”) and right sidebar (25% or col-3 containing “.blog-roll”), we just have need to add the relevant classes to our markup

<main class="row">
  <aside    id="navigation" class="col-3"></aside>
  <article  id="content"    class="col-6"></article>
  <aside    id="blog-roll"  class="col-3"></aside>
</main> 

It should give you a grid like the following.

Notice how they just stick with each other without any padding. The purple border is Firefox developer tools showing us the layout.

Gutters

If you ignore the basic styling and borders, you’ll notice that there’s still no spacing between the columns (or gutters) here. We need spacing because otherwise we’ll have to add internal padding to all the columns and we do not want content from one column sticking to the content from another. To have some of that, we define a gutter variable and add half gutter width padding on right and left side of our columns.

:root {
  --gutter-half-width: .5rem
}
.row {
  & > *[class^="col-"] {
    padding-left: var(--gutter-half-width
    padding-right: var(--gutter-half-width
  }
}

Note that --gutter-half-width is just a variable in CSS that we access with the var() function. & > *[class^="col-"] selects all direct descendants of row class which have the col-* class set. :root selects the document root.

We don’t want gutters on the extreme left and extreme right of our grid. We compensate for that with negative margins on the .row class.

.row {
  margin-left: calc(var(--gutter-half-width) * -1
  margin-right: calc(var(--gutter-half-width) * -1
}

If you were to re-run the CSS again, we’d have something like the following.

Nice and tidy

Mobile responsiveness

At this point, our grid system is ready. Ready for one screen size, that is. Let’s see what happens if we switch to mobile view?

Eww!

I mean, it kind of does what we asked it to do, but if those columns were in fact two sidebars and one main content section, and this being displayed on a 320px screen, your users would be pretty irate (or worse, your website becomes popular on r/CrappyDesign). You don’t want that, don’t you?

To fix that, we’ll use the breakpoints that we had discussed about earlier. Essentially, we want to have three columns on desktops (which we’ve already made), one on tablet and one on mobile phones in a row. We start off with writing the media queries for each of our breakpoint.

@media only screen and (max-width: 449px) {
  // classes for mobile view
}
@media only screen and (min-width: 450px) {
  // classes for tablet view
}
@media only screen and (min-width: 768px) {
  // classes for desktop view
}

Next, we write the column CSS classes for each media query (same code, but we’ll rename them a bit so that we can tell which class is for which viewport). Notice the col-[viewport-name]-[column-width] format. You’ll might recognize this from libraries like Bootstrap (for example, col-md-3 or col-xs-6).

@media only screen and (max-width: 449px) {
  .col-mobile-1 {
    flex-basis: 8.3333333%
  }
  .col-mobile-2 {
    flex-basis: 16.666666%
  }
  // col-mobile-3 to col-mobile-10
  .col-mobile-11 {
    flex-basis: 91.666666%
  }
  .col-mobile-12 {
    flex-basis: 100%
  }
}
@media only screen and (min-width: 450px) {
  .col-tablet-1 {
    flex-basis: 8.3333333%
  }
  .col-tablet-2 {
    flex-basis: 16.666666%
  }
  // col-tablet-3 to col-tablet-12
}
@media only screen and (min-width: 768px) {
  .col-desktop-1 {
    flex-basis: 8.3333333% 
  }
  .col-desktop-2 {
    flex-basis: 16.666666% 
  }
  // col-desktop-3 to col-desktop-12
}

Now, we can edit our HTML to use these new classes. For each viewport, we add a class which tells the browser how wide it needs to be on that viewport. For example, our article section is 50% in width (or 6 out of 12 columns) on desktop, while 100% on tablet and mobile (or 12 out of 12 columns).

<main class="row">
  <aside   class="col-desktop-3
                  col-tablet-12
                  col-mobile-12" id="navigation"></aside>
  <article class="col-desktop-6
                  col-tablet-12
                  col-mobile-12" id="content"></article>
  <aside   class="col-desktop-3
                  col-tablet-12
                  col-mobile-12" id="blog-roll"></aside>
</main> 

This will ensure our columns are 100% width on tablet and mobile screens. And because our classes are inside of media queries that only fire at the viewport width breakpoints, only the relevant class gets applied. As you can imagine, one can really fine tune how things look by selecting a higher number of breakpoints and designing for a more consistent UI across the spectrum of screen sizes.

Bonus – Hiding sections

Let’s say we decide that the blog-roll section isn’t super important on mobile screens, and should be removed. This is a common usecase; hiding specific blocks on specific viewports. And there’s a very easy way of doing this right in the grid system.

The little trick is to add hidden classes, just like our column classes, to our viewport media queries.

@media only screen and (max-width: 449px) {
  .col-mobile-hidden {
    display: none
  }
}
@media only screen and (min-width: 450px) {
  .col-tablet-hidden {
    display: none
  }
}
@media only screen and (min-width: 768px) {
  .col-desktop-hidden {
    display: none
  }
}

Now, to hide the blog-roll on mobile phones, we just add the hidden class to its classlist.

<main class="row">
  <aside class="col-desktop-3
                col-tablet-12
                col-mobile-hidden" id="blog-roll"></aside>
</main> 

Code

I’ve posted truncated snippets above. The whole thing would look something like the following.

  
:root {
  --gutter-half-width: .5rem
}
.row {
  & > *[class^="col-"] {
    padding-left: var(--gutter-half-width
    padding-right: var(--gutter-half-width
  }
  margin-left: calc(var(--gutter-half-width) * -1
  margin-right: calc(var(--gutter-half-width) * -1
}
@media only screen and (max-width: 449px) {
  .col-mobile-1 {
    flex-basis: 8.3333333%
  }
  // ...
  .col-mobile-12 {
    flex-basis: 100%
  }
  .col-mobile-hidden {
    display: none
  }
}
@media only screen and (min-width: 450px) {
  .col-tablet-1 {
    flex-basis: 8.3333333%
  }
  // ...
  .col-tablet-12 {
    flex-basis: 100%
  }
  .col-tablet-hidden {
    display: none
  }
}
@media only screen and (min-width: 450px) {
  .col-desktop-1 {
    flex-basis: 8.3333333% 
  }
  // ...
  .col-desktop-12 {
    flex-basis: 100%
  }
  .col-desktop-hidden {
    display: none
  }
}

Possible extensions

The flexbox standard defines various ways of arranging things inside the container both along the flex-direction axis (called the main axis) and the cross axis (the axis perpendicular to the main axis). If we were to extend this, we could define helper classes like .col-reverse (flex-direction: reverse) or .col-spread-out (justify-content: space-between) using these properties depending on our use cases.

In closing

The flexbox standard is pretty elaborate, and extremely well documented. There are also good libraries build around Flexbox that provide what we just build, and much more than that, out of the box. In production, one should try to stick to libraries and not reinvent the wheel.

Having said that, it is also important to understand the libraries that we use. Now we know what actually happens when we use that familiar col-md-6 class from Bootstrap, and if need be, we won’t shy away from editing the source code to make the library fit our needs!

Thank you for reading!

The Indian ‘No?’

One of the traits of Indians who speak the English language is using ‘no’ at the end of sentences which are questions. I do it from time to time. It is frequent for Yes/No questions where you say the entire sentence first as an assertion and at the end you put a ‘no?’ to tell the listener you’re actually asking if the statement you just made was true. For example, if you’d like to ask your friend Bob if he likes Green color, you’d say Do you like green color? I, on the other hand, would have to fight an (tiny) instinct and not say You like green color, no?

Not trying to imply we’re the only ones who do it, or that it is a super bad thing. And since it comes naturally to both the speaker and the listener, we understand each other just as well, and that is what matters in the end. But I was just wondering how do so many people make the same basic mistake.

While learning German, I notice that sometimes I try to literally translate sentences, words for words, when I’m not able to think fast enough. For example, Can you please help me? becomes Kannst du bitte helfen mir?, which is incorrect. Rule is, if there are two verbs in a sentence, the second verb is thrown at the very end. So the right way to say that is Kannst du mir bitte helfen?. But if you don’t practice, literal translation (from your native language) is what comes naturally.

I think this is what happens when we try to ask a Yes/No question as Indians. At least for me, my native languages are Hindi and Marathi. In both, an assertion for You like Mangoes would translate* to Tumhe aam pasand hai or Tula ambe avadtat. Now, Do you like Mangoes? just adds a ‘Na’ sound to the Hindi and Marathi version; Tumhe aam pasand hai na? and Tula ambe avadtat na? which, if you then reverse literal translate back to English, becomes You like Mangoes, no? (*using Hinglish and Marathlish here so that everyone can try pronouncing it).

Of course, you can say it differently in Hindi which would be similar to literal English translation, Kya tumhe aam pasand hai?, but it depends on how good your Hindi is, and the exact sentence. I honestly have no idea which one’s more correct.

So, to be honest, I’m waiting for a friend who got a little late, and decided to write this piece sitting in a park under a tree. It is kind of random, and I think I’ll find counter examples to this if I think a bit more on it. But yes, that’s it for this spontaneous article. Thank you for reading.

The Neighbor

I held the elevator open for an elderly lady entering the building. She thanked me, and saw the floor that was already active. Her apartment was on the same floor, she said. I exclaimed “Neighbors!”, to which she smiled and said, yes. On reaching the floor, we discovered that we live in flats directly opposite to each other. We got talking; what I did and where I was from. Turned out, she lived in New Delhi with her husband for 5 years! I told her about my internship there for a couple of months. She could even tell the neighborhood she was in, which was pretty close to where I lived.

Incidents like these make you realized that the world’s not that big of a place. This entire conversation took place in German (at least I tried to) which was kind of a big deal for me. New language skill put to good use!

Experiences With Macbook And MacOS – Part 2

In the part 1 of this post, I wrote about getting a new laptop from/for work. I also dug into the similarities and differences between my old Thinkpad T440 and my work computer, a Macbook Pro.

Now, after more than 6 months of using the Macbook as my primary computer, I switched back to my Thinkpad. In this article, I’ll get into what I missed from the Thinkpad (which was slightly different from what I thought I’d miss) and what the tipping point for the switch was. This is a personal account, and as such, is shaped by the way I perceive things. Probably it would have been very different if I’d used a Macbook from an early age and made my first shift to a GNU/Linux distro 6 months ago.

Control

You lose a lot of control from over your system when you run a proprietary operating system (and most software on it). That feels obvious when I write it that way, but we often forget or take things for granted when using a GNU based operating system that we realize only when we switch to something like MacOS. There are ways of customing MacOS, no doubt, but they aren’t nearly as powerful (or simple) as the ones available on most distros on Linux.

It is worth noting that control isn’t strictly needed, and is a preference. But if you do prefer to be able to tinker with the way your system looks, feels and works, then you’ll find that preference better respected on this side of the fence.

UI

No matter how hard I try, I just couldn’t get myself to like the gestures and animations in MacOS. My brain is kind of stuck in the old school menus of Windows XP/7 (and hence, xfce). Also, having spent a lot of time customizing my status bar in xfce, I couldn’t help but feel under-equipped trying to do the same on MacOS. Not a huge fan of the bubbly semi-transparent UI scheme either.

New learnings

Depending on how you see it, it can be regarded as both good and bad. Most things just work out of the box in MacOS. It is like buying a fully furnished house. That frees you from having to think about things like setting up Wifi, Bluetooth, screen brightness and so on. All keys on the keyboard do what they say they do, sound works out of the box, and even if you break something, you can always take it to someone to get it fixed (Not very sure if/how the last one works, but guessing there’s some kind of support available to Macbook customers).

While all this sounds perfect (and it is, if that’s what you need), most of what I have learnt about computers is through fixing stuff that I broke while tinkering with it. A couple of months of MacOS usage made me realize that I’m not learning even a fraction of what I’d have otherwise did if I was using a broken system, full of shortcomings. I’ll let a quote from Moxie Marlinspike’s The Worst to summarize my thoughts.

…no matter how much research they do, a partisan of the best might not ever know as much about motorcycles as the partisan of the worst who takes a series of hare-brained cross-country motorcycle trips on a bike that barely runs, and ends up learning a ton about how to fix their constantly breaking bike along the way. The partisan of the best will likely never know as much about sailing as the partisan of the worst who gets the shitty boat without a working engine that they can immediately afford, and has no choice but to learn how to enter tight spaces and maneuver under sail.

Speed disappointments

So, in exchange of all of that, I assumed, I’ll be using a system that’s super smooth and faster than anything I’d ever used. Nop. Not even that. It was just as fast as my old computer. I think newer CPUs and hardware in general are quite overrated for most people’s use cases. If you know even a tiny bit of what you’re doing (and aren’t part of that minority of computer users that actually needs powerful hardware), you can make a 5-10 year old computer work more or less the same way as any modern computer.

Community

While I moved away from my Thinkpad, and by extension, the *nix community, it didn’t move away from me. I was constantly reminded of how customizable my desktop could’ve been at r/unixporn, how over 10 year old laptops are still daily drivers of many at r/thinkpad, how easy getting your operating to do something for you used to be at StackOverflow and what good documentation should look like at ArchWiki. All in all, I missed the community.

Tipping point

While all of this was coming to my notice slowly, a major turning point was hearing Hakun Lie and Bruce Lawson at DevBreak two months ago. There, I got to know about web standards and where things are heading. It was fun to get reminded of the things that excited me about web in the first place. Then, Bruno walked me through a project of his that used some of the newer web apis. I was blown away, and honestly a little embarrassed to have forgotten the passion with with people talk about the web and engineering things on it. I just wanted to get back to my old world.

Final thoughts

So I got back on my Thinkpad running a fresh installation of Arch and i3, and writing this on the same. Trying to get the function keys working never gets old for me, and the joy of having found the solution on the internet, implementing it and getting it to work and in the process actually understanding what happens when you press a function key is something you learn by actually doing it. This, and countless such experiences are what make it so much fun to be in the GNU/Linux ecosystem.

Thank you for reading!