Experiences With Macbook And MacOS

Uncategorized

It has been quite some time since I had last used a computer that would connect to the Wifi and Bluetooth out of the box without having me to scream at my computer screen and rip some hair. But that changed when I got my work laptop. It is a Macbook Pro. I was very excited to unbox my first ever Apple product, even though I was never keen on buying one myself (or could afford one, for that matter).

The two devices

There were some surprises, both pleasant and otherwise. This post is going to be about those, about how I felt switching from GNU/Linux based distros to the MacOS, from a Thinkpad to Macbook. Note that one is a four year old second hand laptop, while the other is more recent and hence, not an entirely fair comparison for absolute things like specs. Also the Macbook costs about five times of what I paid for the Thinkpad. These are very personal experiences and hence, biased opinions. YMMV.

Similarities

Both are excellent machines running excellent operating systems. If you want to get some work done, you couldn’t go wrong with either (and mostly depends on how familiar you are with each). Both are faster than anything I have used in the past. Software support is good on either. Both feel very durable (I can only vouch for the Thinkpad, but I’ve seen people use Macbooks for years too). And finally, both are considered ‘work’ laptops marketed towards professionals.

Where The Macbook Shines

1. Display

Compare the resolutions

The display is easily the best part of using a Macbook on a daily basis. Text is crisp, colors pop out of the screen and the resolution is out of this world. For comparison, the 27in monitor that I have as a secondary display has fewer pixels. Working on it is a joy, especially as a frontend developer.

2. Build Quality & Bulk

I used to think my Thinkpad was sleek and light, but the Mac is on another level. I can casually hold it in one hand and walk. There’s no flex anywhere, and the whole thing feels very solid and well built.

3. Trackpad

It is nice to get gesture-support out of the box for once. I tried doing it for the Thinkpad on Xfce, but that attempt failed miserably. The trackpad on the Macbook is huge. It has two levels of clicking for added functionality (I use the dictionary/reference look-up often). It supports many phone-touchscreen-like functions like pinch-to-zoom and is very refined.

4. Battery Life

Again something that I had never experienced before, a super long battery life. I have all the battery optimizations disabled and never stop the dev servers and IDEs, but I still easily get through half the day without having to connect the charger.

5. Speakers

In terms of absolute quality, I don’t know where the speakers on the Macbook Pro stand. For me, they’re hands down the best laptop speakers I have ever experienced. Loud and clear.

What I Miss From The Thinkpad

1. Ruggedness

While the Macbook is premium and rich, if I had to pick a more durable laptop, I’d pick the Thinkpad. I’d never use the Macbook as carelessly as I do my Thinkpad, especially considering the economic consequences.

2. Keyboard

I tried to get used to the new keyboard, and I did. But whenever I go back and use my Thinkpad, I immediately realize why it is called the best in the business. Perfect click-iness, key travel and key shape. Typing is a joy on the Thinkpad.

3. I/O

Nothing new here, but it sucks to need a dongle just to be able to connect a USB drive or read an SD card (yes, I still use those regularly). HDMI for secondary display? Need a fancy cable for that. VGA? You from the past, bro?

All I’m trying to say is, I’d rather have too many options at the cost of elegance than too few at the cost of functionality.

4. Operating System

It is hard to make a non-biased pick, but I’d still choose Arch and Xfce over MacOS. Many little things from years of using Linux distros have spoilt me; OS updates made me happy, but not anymore with Mac. Constant bugging to reboot just to update the OS? Don’t remember that from Arch. Aur (Arch User Repository) had everything in terms of software that you’d (almost) ever need, and I miss that.

It is also just the customizability an OS offers. The community that surrounds the laptop and the operating system (Have you checked out ArchWiki yet?).

5. Repair Costs

Thankfully, I’ve never had to repair either of them (I’d not have to do that for the Macbook anyway since it is a company device), but I felt the need to add this point here for fairness. Thinkpad parts are available in abundance on the internet, and you can do most repair on your own if you know how to use a screwdriver. A quick search for Thinkpad T440’s motherboard on ebay pops up results in the 50$ – 150$ range depending on the configuration. An equivalent for Macbook goes around 600$ – 800$.

In closing

As you can tell, there’s no clear winner here, even for me personally. I genuinely think the hardware of Apple is top notch and now kind of understand why many developers use Macbooks.

On the other hand, my heart still lies in the simplistic plains of Xfce, the ease of everyday operations, confidence to open the back cover and do minor repairs and the joy of just understanding what’s on the system. Of course, as things progress, maybe the Mac ways will become second nature to me and I’ll have a better understanding of this new system, which is nice.

It will be interesting to see how my thoughts shape from here. Cheers and thanks for reading.

Doing More With Jekyll – CloudCannon And Netlify

Uncategorized

I’ve been using Jekyll for the past couple of years now. I started this blog on Ghost, but soon moved it to Blogger. Later, I discovered that I could simply use Github Pages for hosting my static site. For someone coming from shared PHP based hostings like 000webhost and what not, this was unreal. I moved to Github Pages and have been using Jekyll since then.

I always liked Jekyll for the simplicity, no-nonsense setup and complete control over what gets served to the visitors. Plus given the nice Github integration, no sysadmin and total control over the content, it is just perfect for personal blogging and simple static sites.

But what I recently learned was that the land of static sites isn’t all dry. There are some nice tools that one can use to enhance their experience with Jekyll. In this article, I’ll be talking about two such tools that I discovered recently and found interesting: CloudCannon CMS and Netlify’s Split Testing

CloudCannon

CloudCannon is an online CMS for Jekyll sites. If you have ever used a CMS like WordPress or Joomla, CloudCannon would feel right home. If not, think of it like having a Google Docs-like interface for editing your site (as opposed to writing HTML or Markdown). It is more limited than your traditional CMSs in the sense that you cannot install plugins or change the appearance of your site from the panel (you can, but then you’ll have to code that logic yourself into the app and use flags in the frontmatter to selectively display component). But again, since you’re using a static site generator, you probably don’t plan on having a lot of plugins anyway.

CloudCannon home

The interface is simple. You get a WYSIWYG editor, and a sidebar with all the frontmatter fields. Interestingly, you can name the frontmatter fields in a way that CloudCannon recognizes to get more from the CMS. For example, if your field name ends in _html, CloudCannon will make it a WYSIWYG field. Same goes for _time, _image and many others (find them in the docs).

Post content view with frontmatter variables in sidebar
Post source view

The advanced configuration options includes free SSL, CDN, hosting, backups and authentication. You might not need it (I use Cloudflare which gives free SSL and CDN, and Github for hosting and backups), but good to have. One complaint I had with CloudCannon was that if a site build failed, CloudCannon wouldn’t abort the deploy. It will deploy the failed build and your site would go offline until you revert. I just hope there’s a setting for that somewhere, but that it isn’t turned on by default is worrying enough. So for now, I’d rather just use CloudCannon for CMS and host my site someplace else.

CloudCannon is free for single user sites and syncs well with Github. It sits in a sweet spot between a bloated CMS and simplistic static site generator, and enhances your productivity as a content creator while letting you keep all the control over what gets served to your readers.

Netlify – Split Testing

Netlify is a static site hosting service. I like it because of the few but very useful tools they provide. You can host your Jekyll site on Netlify, and it supports Node and Ruby-based build tools (so you can use grunt/webpack for your SPA apps). For quickly hosting a nice website with some frontend framework (say a ReactJS app), Netlify is great (although I’ve seen it used in production as well).

Netlify provides a rich set of configuration options, including functions, forms and authentication mechanisms. What I really found interesting was their split-testing beta feature. So what is split or A/B testing, you might ask?

If you want to test two versions of your website and see which one do your users prefer (in terms of a goal that can be anything like time spent on your website or product sales), A/B testing can be a good way to do it statistically.

Netlify Split Testing

In a nutshell, you create different branches with different code and then use a nice slider to adjust the percentage of traffic that would go to each branch. This feature is still in beta, and the split test turns itself off whenever any branch is pushed (which, I was told, is a known bug). A cookie gets set on the client side which can tell you what variant it is, so you can bake some logic around that to get stats and such.

In closing

I was pretty excited to find these interesting tools built around our humble Jekyll. If you are a Jekyll user, I’d love to hear about your workflows. I’m planning to bake a little asset pipeline on my blog soon, so any tips for that are welcome!

Thank you for reading.

Javascript – The Good Parts

Uncategorized

This isn’t going to be a shameless ripoff of Douglas Crockford’s work in the book Javascript – The Good Parts, which used to be a highly recommended book in the Javascript community before ES6 took off. Rather, I’m going to write what are, according to me, the good parts of the Javascript programming language. I’m not keen on making this sound like an endorsement or otherwise. I am more interested in exploring the reasons that make Javascript such a popular language even if not the most loved. Why is it that the language you find at most programming bootcamps is Javascript? In this little post, let’s try to reason that.

The motivation for writing this post came from my company, which is launching a new course that will teach people with no programming experience full stack web development. The course will teach a student all they need to know to write a complete web application, in Javascript. That made me wonder, why teach (just) Javascript? Why not Python, or Ruby, or something even fancier? Following are some of my ideas.

Because ease of learning

Javascript is a high level language, and the learning curve is somewhat flat until you get to the last 20% or so of the language. You don’t need to know a lot of computer science and computer organization to pick something like Javascript or Python. On the contrary, the typical first languages that are taught in colleges (in India), C and C++, require you to understand memory, stacks and heaps, platform that you write code for and so on.

Also, given the event driven nature of the web, Javascript makes a lot of sense when you’re interacting with user actions (Javascript supports event-driven style of programming). It is easy to express intentions in Javascript, and given that it has been around for some time now, most problems that you’d face are already solved somewhere by someone.

Because community and support

Javascript has a huge user base, and I’m not talking about the end users. I’m talking about developers. Many people I know started their careers in software technology with Javascript. There’s good reason for that. One that there’s no shortage of resources on learning Javascript, debugging, utility libraries, UI libraries, testing and frontend frameworks. It is easy for people to pick something up and stay motivated when they have their questions answered easily with google searches, and they find people with whom they can relate the learning process.

Because jobs

It is easy to find jobs that require Javascript, which is something that definitely matters if you’re learning how to write code for getting employed (which many of us are). The salary might not be as high as for some other languages and frameworks, but it would in general be high enough. Also, it is always possible, and much easier, to move in between different tech roles than getting into one in the first place.

Because frontend and backend

If you’ve been programming for some time now, picking a new language isn’t at all difficult, and that’s part of what is expected of us programmers. But for someone who’s just starting out, being able to program an entire application in a single language is a huge plus, as compared to spending a lot more time learning their second language for backend specifically. You can always learn a new language later on specifically for backend or anything else, once you are a decent Javascript developer.

Because JSON

JSON, or Javascript Object Notation, is a format for representing data as key value pairs in a text document (Douglas Crockford, mentioned earlier, is the creator of JSON). As the name suggests, it is the same format that you’d use to represent an Object in Javascript. While JSON is not exclusive to Javascript (since it is a file format), it is well integrated into the Javascript-verse and accepted as the de-facto format of data exchange.

To make things simpler, many NoSQL databases use the same key-value representation which means all of your data, from the database, to backend and eventually the frontend, is in one format. It makes things easy to understand. It shouldn’t then be surprising that many of the bootcamps choose such a NoSQL database to go along with their full stack development course.

Because time-to-productive

If you’ve written code in Java or C++, you know that it takes an awful lot of time to go from a complete programming novice to someone whose software might be useful to others. Compare that with Javascript (or Python). You can start learning it today, and within a week, you’ll have your very own sign up forms and what not. In a couple of months, you’ll be pushing out code of the quality you find in production at most startups (if you’re not sure whether to be happy or sad at that line, be neither. You’ll discover one way or the other).

Because it works (..for now)

And because we do not have an alternative. Javascript is installed universally. You don’t have to ship it with your app. I think that’s a huge point in its favour, and enough reason to learn some Javascript even if one doesn’t plan on writing a lot of it. It is the language of the application layer of the internet. It is far from elegant. But remember this

There are only two kinds of languages: the ones people complain about and the ones nobody uses. – Bjarne Stroustrup

That quote is particularly appealing to me, and not just because I had a mini-crush on Stroustrup ever since I missed his talk back in 2015.

In closing

Javascript can be a very good language to start with. It makes all the more sense if you’re learning to get employed as a developer. I must say that the ecosystem is not the best at this point. There are new libraries and frameworks popping up and fading out every other day, and there are way too many best practices for anything to be seen as a standard. But if you do get started with Javascript, spend some time later in your career figuring out how computers and the internet work. Javascript isn’t going to force you to, but it comes in handy.

If you liked this post, check out 17 tips after a year in Javascript development for exactly what the link title says. Thank you for reading!

Mumbai To Berlin

Uncategorized

Not many nice things can be said about the lack of planning things out. But if I had to, one of them would be that it really makes up for some uncertainty in life. Not necessarily good or bad, but makes things interesting from time to time. One such interesting phase that I’m living through is my time in Berlin. Do you know when you’re living through something, knowing that it is going to be memorable when you look back at it from the future? I’m kind of in that moment.

The iconic Fernsehturm (TV tower) in Alexanderplatz

My humble workdesk in Delhi. Second day of work. Naively wishing I was home enjoying vacations.

I couldn’t help but draw parallels between my arrival here in Berlin and some two and a half years ago in New Delhi. It felt similar to me in many ways. An unknown place, a completely different set of people I was going to spend time with, interact with. Back then, I was scared because I didn’t know the people, I didn’t know what I was going to work on, and I didn’t know if I’d fit in. This time around, with some experience from the past, I was excited for the very same reasons. The ‘what is the worst that can happen?’ questioning philosophy kicks in and makes things interesting (and once you watch this amazing video on Optimistic Nihilism by Kurzesagt, that mindset only strengthens). It also keeps you relatively safe while giving you much wider set of options than what would normally be available. (is this a greedy approach?)

Being An Expat

(Note and 2023 edit: For various reasons, I am no longer particularly fond of the word “expat”. I exclusively refer to myself as an immigrant. I wouldn’t edit the text to reflect that, but this note should suffice to reflect my newer thoughts)

So I’m an expat now. What’s the big deal? I think the big deal is the added responsibilities that comes with moving out. You are your own boss, and while that sounds all sunshine and rainbows, it really isn’t. From making your own tea, washing your own cloths to deciding how much money needs to go for rent and if the bread you’re buying at the supermarket strikes the right balance between cost and nutrition. Trust me, you don’t want to jump straight into it without some training-wheel exercise first.

The next thing is the experience. Moving to Berlin is something new, something I’d never experienced before and probably never would have if I hadn’t put some work into it. Experiencing something new is beneficial in many ways, and when that something new is a culture altogether, it teaches you a lot. And culture is not all there is. There’s the work style, interacting with colleagues, making friends, commuting and many such things. Now, I’m getting to experience how little things work out in not one, but two countries. And then that will lead to a lot more parallel-drawings which eventually end up widening my horizon. I feel that’s a good thing.

I intend to do good work whilst I’m here, make a positive impact on the people around me and my company and in doing so, learn invaluable lessons in life, tech and else. I’ll keep this blog updated on more interesting experiences from Germany, but in case you have any specific questions, my email address is on the about page.

On People Living In Their Home Cities

Before closing this essay, I’d list down one important thought.

I had never understood people; friends, seniors and industry veterans alike, when they said they wish to live close to their hometown with their families and commute from home everyday. I mean, why would you have restrictions for yourself, right? Aren’t you excited to live in this shinny new city and make money?

I feel my thoughts have changed, and changed for the good. Now I think I can empathize with them. It is a very valid reason and goal and while I may or may not make such a decision, I’ll have huge respect for anyone who does. It must take a lot of courage to go that way.

In Closing

Berlin is a beautiful city. The people are amazing, you have all sorts of food options. The streets are great for casual walking, like they’ve stood there still in history. Occasional posters and banners remind you of the history of this place. The way history is preserved in the architecture here, yet staying on top of the globalization game, is commendable. And sometimes, I just pause and think, how on earth did I make it here!

A snowy evening in Friedrichshain

So here’s to my new journey. I hope, with the usual ups and downs, things work out well. I hope to learn more and share my learnings with you. Embedding the video mentioned above, if you’d like to give it a watch. Thank you for reading!

2018 Year Review

Uncategorized

2018 is almost gone and it is time to review some of the good and some improvable events from the past year. I’ll also list down some TODOs in the end, derived from the list of things that I could’ve improved upon.

In a brief

The year started on a remote village’s railway station in Odissa, during the 2017 Jagriti Yatra. On returning from the Yatra, I was headed for some adventures in LaughGuru, work related and otherwise. I enjoyed staying at my new house in Mumbai a lot. Life was very chill until I had to depart from LaughGuru around mid of this year. After that, I spent some time learning full stack development with Python, then started applying to companies. Around mid-October, I had found a new full time job. The next two months were spent preparing for it, learning some non-tech things and just spending some good time with friends and family.

Highlights

Some things went right; planned or otherwise, and I learned a lot from them. Here are some of them from the past year.

  • Visited various places in the Jagriti Yatra, spoke with many unique individuals and made friends.
  • Took over bigger responsibilities of the codebase (and the tech team) of LaughGuru. Learned how major features are planned and implemented.
  • Learned quite a lot of advanced CSS and some SASS, implemented designs that were way out of my league.
  • Learned functional programming. Concepts were learned from Haskell, but most of the actual implementation was in Javascript.
  • Made small contributions to Freedom of the Press (and some other) repositories. Got the DigitalOcean Hacktober tee.
  • Learned backed development with Python and Flask. Learned how ORMs are used, schemas designed, app structured and tested.
  • Landed a new job, interviewed with many companies and spoke with many interesting and smart people.
  • My algorithms, data structures and computer science game in general was leveled up, thanks to the interviews.
  • Learned how overflows and overflow exploits, function calls actually work under the hood among other interesting low level stuff (thanks, Hacking – The Art of Exploitation).
  • Read some 15-20 (hard, soft and audio) books, most non-tech. Many were classics like 1984, Sapiens, The Mythical Man Month, The Selfish Gene and Pragmatic Programmer.
  • Read Applied cryptography and Serious cryptography, got a hands on with Coursera’s Cryptography 1 course by Dan Boneh, wrote ELi5s on cryptography primitives.

Mistakes and Areas To Improve

There is always room for improvement (a lot of it in my case), and in the following points, I’ll list down my own observations and some by my friends on ways to self-improvement.

  • Didn’t keep in touch well with friends and relatives.
  • Wrote very little actual code, especially in the second half of the year. Didn’t learn a new language or technology either.
  • Didn’t contribute to the open source as much as I’d have liked.
  • Didn’t implement the cryptographic primitives that I had spent a lot of time learning.
  • Spent too much time browsing reddit/youtube that could’ve been used to read books/learn something worthwhile.
  • Had a private room but didn’t set up the ideal work station that I had always wished for.
  • Didn’t workout regularly and got marginally overweight.
  • Didn’t plan the post-LaughGuru time properly, and didn’t follow whatever little plan I had religiously.
  • Got a chance to speak at a tech conference, missed it.
  • Didn’t dressed up decently, or looked like a professional.

# TODO in 2019

  • Web engineering, security engineering and open source needs to take front seats again.
  • Make active efforts to keep in touch and maintain healthy relationships with friends and relatives, be a nice-r person to be around in general.
  • Participate in opensource communities and build real, useful projects.
  • Walk, exercise and meditate daily. Wake up early.
  • Practice and get good at public speaking.
  • Save money and travel during holidays.
  • Read 24 books.
  • Put into practice the software engineering best practices that I have learned in the past year.
  • Remind myself that consistency and regular practice to become better at something beats one time wonders and luck on any day, and it is fun to be disciplined and process, systems oriented.

See you next year!

I hope you had a great year as well. I also hope you have a wonderful new year, filled with interesting problems, learnings and experiences.

Thank you for reading!

Working For Startups

Uncategorized

I went through an interesting roller-coaster of understanding what the world of computers and the internet actually looked like in real life. Having no software engineer in my family or friends didn’t help either. The net effect was that I had no idea what actual software development looks like, or how different it would be from the online programming idealism that I was exposed to early on.

It was in the second half of my college that I really understood that most software engineering jobs are not the glorious stay-up-late-night-to-save-the-world kinds. The stay-up-late-night part might still be applicable, but for completely different (and often, less significant) reasons.

So you’re excited to do good work, and have lots of energy that you wish to put into something meaningful and worthwhile, what do you do? A couple of my friends and college acquaintances decided to start their own companies, and I found that very interesting. Some went for a masters degree in western countries, and that is also a great option. For me, I decided to go work for startups.

In this article, I’ll list some interesting aspects of working for startups which I’ve learnt in my little journey so far.

Flexibility

Flexibility is being able to bend rules to fit some edge case or just be more human. Yes, the office time is 9-5, but if it makes me more productive to work 11-7, why not? Maybe I’d like to work from home some days a week, or maybe I’ll want to work more hours this month and take a vacation in the next. Not hungry during the lunchtime? Feel free to eat your meal later when you feel like. Of course, with great flexibility comes greater need for discipline and care must be taken to not misuse the trust your employer has in you.

I personally like it when things are flexible, but you must remember that things work both ways. Your employer might also expect some degree of flexibility from you (so occasional work on the weekend, longer work hours when nearing a release etc). As in the case with you in the above paragraph, be mindful about keeping it a fair transaction for both the parties.

Culture and Bonding

The startup culture is usually very friendly and informal. In case of small startups, you know almost all the people working for the company by their first names. Small talks are common, storytelling is a good way of deepening the bonding and so is sharing your lunch. At the startups that I worked for in the past, the entire team had their lunch together (or went out to have lunch in the nearby restaurants). We celebrated together when it was someone’s birthday, had a town hall once a month where the entire team would come together and present updates on what they’ve been up to.

As a result of all of that, the atmosphere was most often very positive, and when that’s the case, one looks forward to waking up and going to the office every day. It is a win-win for everyone.

Impact and Work

The next important bit is the impact of your work. In any early-stage startup, you’re sure to find loads of opportunities to build interesting features, be responsible for major chunks of the codebase and be an integral part of the team in general. A small startup is unlikely to have funds to hire multiple people for similar roles. Hence, the job will require you to take ownership and be responsible for anything that has to do with your part of the codebase, which is an excellent stimulant to do good work.

You might also need to occasionally work outside the scope of your job (talk to users, brainstorm the exact requirements, give your input in other parts of the product/service etc). It will get intense at times (the realization that you are responsible for a particular part of the product can be intimidating in the beginning), and you’d have to remind yourself that it is all part of the experience, the adventure. Like Sigmund Freud said,

One day, in retrospect, the years of struggle will strike you as the most beautiful

I certainly remember the day when I and my manager had to work till 4 in the morning to get a prototype ready for demo due next day (technically, the same day), or the last few weeks at my previous workplace where we were pushing ourselves to deliver. I feel I’m naive enough to enjoy these experiences instead of loathing them. But if that’s really the case, I’m happy to stay this way for more such adventures, for I feel the reward outweighs whatever drawback these experiences might have had on me.

Salary and Perks

In India, tech startups pay quite decently, especially if you’re in a tech or product role. Many have no official vacation policy so you can negotiate a vacation at any time. Many aspects of the job are flexible (see flexibility above). If it is a small company, you can except fewer perks (maybe just an annual bonus). As the size of the startup goes on increasing, the perks and salary increases. Note that I’m not talking about huge multinationals here which are notorious for paying very little and overworking their employees.

While how much you should earn is very subjective, there are many websites (for example) which will give you a range if you provide them with your details (like your education, skills and city). If you’re unsure about what you should get paid, these websites can help.

But note that monetary compensation is only one of the many ways you get paid at a job. Your happiness, professional growth, the network you’re building and the value your current work has on your career in the long run are some of the other currencies that you can take into account.

Caveats

While this article might have pushed you in the direction of thinking that working at a startup is without its downsides, that’s not true. Like many things in life, it isn’t binary and definitely not a black-white choice. For example, large multinational corporations would offer you more job security than a typical early-stage startup (this is less true than it used to, as I keep hearing about ‘layoffs’ in large companies in the news, but still a point to consider).

Similarly, if your goal is to make a decent sum of money, but while living as chill a life as possible (for example, maybe your priorities are your social life, family, living in your home city, less workload and responsibilities etc), then the startup life might not be the best fit for you.

With regards to finance, it should be noted that a ‘startup’ is a company trying to make money through various means (like investor funding, sales of their product etc) and things don’t always work out as per plans. In fact, a quick web search revealed that around 75-90% of all startups fail. What this means is that salaries can get delayed, extra workload if new resources cannot be hired, low enthusiasm of the team because of the previous two and many such problems. When considering a company, look for their funding status to get an idea about how they stand financially (Crunchbase is a good place to research). Glassdoor reviews and a simple internet search can also yield a lot of information that would help you in making the right decision.

Having a short interview with the founders is a good way to get to know the long-term vision of the company and the direction things are heading. Similarly, interviewing with the manager of the team that you’ve applied to (although not always an option) is a good way to see if you’d enjoy working in their team.

In Closing

Finally, don’t take it too seriously. Remember to learn and have fun, make new friends and visit new places. One thing I can guarantee you is that almost everyone you meet will have some interesting experience and important lessons that you can use in your life. Cross-pollination of ideas from one context to another is important, and that happens not just in business meetings but over lunch and coffee breaks. I hope you found this article useful. If you wish to talk about your startup adventure, or you’re looking forward to your first, feel free to drop me an email.

Thank you for reading!

Xiaomi Pocophone F1 Review – MIUI And Stock Android

Uncategorized

I bought the Xiaomi Pocofone F1 earlier this month. My previous phone, the Galaxy S5, was already four years old, although still usable. But calls on the S5, as I mentioned in my Nokia 105 review, were buggy because of a faulty microphone/speaker/whatever issue. Apart from that one (which I could’ve just repaired), the phone was pretty okay.

Galaxy S5 and Xiaomi Pocophone F1 – about screen

I was running LineageOS 14 on my Galaxy S5 and very few apps so speed was not an issue in almost all cases. RAM management was pretty bad, but I wasn’t affected by it as much since I close my apps after use anyway. The camera had become quite crap after moving away from stock Samsung ROM, but that too wasn’t a big deal. The phone was 3G only, which was an issue. The bigger issue, however, was that it fixated on Edge most of the time. So I had stopped using mobile data (or relying on it) since at least a year.

And if you haven’t noticed, service providers don’t really care about 3G users anymore. Before Jio and the entire 4G revolution, the 3G speeds I used to get were easily more than 8-10 mbps. Now, 1-2 mpbs on a good day (which is probably because 3G is more of a fallback network these days than the flagship network it used to be). While not enough reasons to get a new phone, I still did as resisting didn’t make sense.

Front view – clean stock UI. Tempered glass on both for screen protection
Back view

The Poco F1 costed me around INR 19,800 in the Flipkart sale for the 6GB/128GB variant. I bought it after some extensive research (never trusted Xiaomi for some reason). But as it turned out, most of the Youtubers that I follow said good things about this phone. I checked XDA to make sure modding was easy and stock ROMS were available (learned this the hard way after I bought the S5). There were some issues like limited DRM support, sub-par stock camera app and screen bleed, but I could live with those.

Initial Impressions

I immediately noticed one thing. Moving from a feature phone (the Nokia ExpressMusic) to the Galaxy Note was a big jump. Everything was new with fancy options behind every menu. Moving from the Note to the S5 was like an update. Substantial but nothing fancy. I kind of knew what to expect: a slightly faster phone, a slightly better camera, slightly better battery life etc, which all turned out to be more or less true.

Moving from the S5 to Poco felt similar to that second upgrade, if not less than that. It was a step back in many aspects, like from Super AMOLED to IPS, IP67 to nothing and a comfortable one-hand-phone to a 6.2in phablet. But in most other cases, it was an improvement although not something that would make your jaw drop. Battery life is the biggest upgrade, from half a day to two full days. The camera is a decent upgrade (with all the fancy bokeh shots and slow-mo stuff). Theoretically, speed and memory management should’ve been a huge upgrade as well, but as I said, my S5 never felt slow thanks to the lean OS, so that was a minor improvement.

I can place cellular calls freely on this phone. No problem. Dual 4G support and hence I am able to use mobile data once again. The internal memory is more than what I’ll probably need (To be honest, my laptop has similar specs). Fingerprint scanner is very fast, and IR face unlock works in pitch dark. Cool stuff.

Software – MIUI

I must confess here that I had a prejudice against MIUI since the Redmi 1S days. It felt like the old TouchWiz, bloated and slow. That all changed when I used Poco. It was snappy (although still bloated), and the first thing that I did was uninstall all the sponsored apps that came with the phone. Soon, I started liking the skin. It was snappy, and full-screen gesture-based navigation was quick. The notch on the top meant I could no longer see the notifications without sliding down, but I got used to that real quick. Soon, the MIUI Android Pie Beta ROM was released and I updated to it manually. It was even better. GCam mod came to the Poco and many complaints about the camera quality vanished instantaneously. Night Node was included sometime later and it was magical.

The only problem I had with the MIUI skin, and this was kind of a deal breaker, were the ads. Everywhere. From file manager to browser, music player, themes. It is ugly, and feels dirty, to open a stock app and see ads. The unofficial Lineage OS for Poco was getting stable during this time, and I decided to give it a go.

Unlocking the Bootloader

While reading on XDA, I learned that Xiaomi allows for official bootloader unlocks, and doesn’t void the warranty of the phone even if you flash custom ROMs to it provided you can get it back to stock before taking it to the service center to claim warranty. I remember Samsung was similar at one point (although they didn’t make it official by saying it out loud, like Xiaomi). You know the instant respect++ you feel for someone after learning something nice about them? I felt that way about Xiaomi at that moment. Unlocking requires their official tool, 72 hours of waiting time and a few clicks. A few more steps to flask TWRP recovery and you’re put in charge of your ship.

LineageOS 16

I flashed the latest LineageOS and got back to stock Android. Honestly, it wasn’t a huge relief or improvement per se. I was kind of enjoying MIUI and it was fast enough. So getting to stock was just an assurance that I won’t see random ads popping up in the system apps, and that I’m running something that’s better for my privacy. I also installed AdAway for blocking ads in other apps and browser.

Overall Experience and Conclusion

Buying a new phone used to be like a mini festival when I was young. It isn’t so much these days. For me, the smartphone (and the modding associated with it) has reduced from a hobby to just another utility, like the refrigerator or scooter. I’m sure innovation still happens in the smartphone industry. It may just be that it isn’t relevant to what I do anymore. And while that sounds depressing, it has freed up a lot of my time that I can use to…umm…do important work **cough cough** memes **cough cough**.

I hope this phone stands the test of time, just like my Galaxy S5 did. If you’re thinking about getting this phone, I hope my review gave you some perspective (although you might want to follow the advice of the pros out there). That’s it for this one. Thank you for reading.

Let’s Talk About CSS

Uncategorized,

CSS can be deceptively complex. And to most programmers, rightly so. We programmers tend to find patterns that help us relate the new information to what already exists within us, draw parallels and think of real world analogies. That is one reason learning your second or third programming language is much faster than learning the first if they share some paradigms. But with CSS, many of us have a memorize-first approach. While it works, it is more fun (and easier to debug) if we understands a little bit of the under-the-hood stuff.

In this post, let’s try to demystify some of the aspects of CSS that we as engineers should’ve asked when we got started with CSS. Better late than never, right?

Understanding The Browser

Starting with something basic: When you request a webpage, and it is downloaded to your system (computer, mobile phone etc), it is in the form of HTML code (at the application layer, that is). The browser then parses the html, line by line, downloading any external resources that it finds with separate HTTP requests. The HTML that is parsed is structured as a DOM tree, which can be thought of like a family tree, but with HTML elements. DOM defines the structure of the page; what goes where and what information does each node have.

On the side, the browser (in that, the rendering engine) is also processing the CSS files. CSS files are processed, and then styles for each node (HTML element, that is) is calculated, and applied to that node. The end result is ‘painted’ and rendered to the client’s screen.

So as you can tell, it is pretty straightforward. What’s interesting is the process of calculating the styles to be applied to each node, and that’s what we’ll be talking about for the rest of this article.

CSS Parsing

There are a couple of challenges when deciding what style applies to a particular element.

  • The engine has to first parse the CSS and get all the values for each property.
  • Then the engine has to decide what set of properties get applied to each element depending upon the specificity of the selectors, inherited and default values (since each element may have multiple rules that seem to style it).
  • Then the selected styles are converted into pixel values (we may have used rems, ems, percentages or vh/vw in our CSS code) as that’s what browsers understand.

In particular, the CSS engine looks for the following when dealing with a style and deciding if it really applies to a given node.

!important

If a property has !important in the value, it is immediately selected for the final processing irrespective of the specificity and code order.

Specificity

To put it simply, specificity deals with how ‘specific’ is the selector (based on concrete rules). For example, if you have some list-items, each with a class selector and CSS background-color: red; and one of them also has an ID selector with the CSS background-color: green;, then which background-color do you think gets applied to that particular list-item? It is the style in the ID selector.

Similarly, if the ID selected list-item had an inline style, the inline style would take precedence. Formally the hierarchy is

Inline style > ID selector > Class selector > Element selector

Browsers maintain an internal tuple of the form (0,0,0,0) representing the counts of each selector hierarchy viz. (inline-style, ID, class, element). For the selector h1.heading#top-heading, the tuple will look like (0,1,1,1), that is, one for ID, one for class and the last for element selector.

Suppose you had another selector h1.heading#top-heading#blue-color. Now the tuple for this would look like (0,2,1,1) as there are two ID selectors. If the browser had to choose between the former and this, it would choose this one as it has a higher specificity.

Source Order

Now what happens if specificity of two selectors match? Simple, the last selector in the source code (even in case of multiple files) gets selected for application.

Cascade

Cascade (n): A process whereby something, typically information or knowledge, is successively passed on.

The term Cascading in Cascading Style Sheets says something about the priority scheme that’s used to determine what style gets applied to an element when multiple rules match. In simpler words, if body has font-family: Arial; specified and the h1 has font-family: Helvetica;, Helvetica gets applied to the h1. However, if font-family on h1 wasn’t explicitly declared, Arial would’ve been selected by inheritance. This is how inheritance works in CSS.

Not every property is inherited. And it doesn’t make a lot of sense to inherit everything either. For example, setting margin: 0 10px; on body doesn’t automatically apply it to every child of body which doesn’t have an explicitly declared margin property. The ones which don’t have an explicitly declared margin get a default margin of 0px. This is how default properties work in CSS.

The obvious followup question is, how to tell if something will be inherited or default value will be selected? Honestly, I’m not sure. I usually just ask myself if it makes sense to have this property inherited or defaulted. More often than not, that’s enough. In case you’d want to explicitly make a property to inherit or default a value, use inherit and initial keyword respectively.

In Closing

That’s it for this little primer. I hope you found it useful. For a nice illustrated guide on this, check out this article on Mozilla. Thank you for reading.

The Pragmatic Programmer Notable Quotes

Uncategorized,

I completed reading ‘The Pragmatic Programmer’, probably one of the most recommended pieces of literature on software engineering. I’ll try to put down some of the quotes and my interpretation of them in the following paragraphs. I’ll be coming back to this from time to time. Hope they help you in your next software project.

The Cat Ate My Source Code

The greatest of all weaknesses is the fear of appearing weak.

Take responsibility for the code that you write and the decisions that you make, and when things go south, present options to recover from the mess instead of pointing fingers.

Software Entropy

When disorder increases in software, programmers call it “software rot.”

Active efforts have to be made to keep the disorder low and go against the nature’s law (of ever-increasing entropy) to keep away from software rot.

Don’t Live with Broken Windows

Once there is a broken window in a building, there will be more broken windows. This is the broken windows theory. Similarly, once a piece of sloppy code enters a codebase, it will attract more sloppiness. Don’t be the one to introduce a broken window into your codebase and fix existing ones as soon as feasible.

Stone Soup and Boiled Frogs

The frog just doesn’t notice the change. Don’t be like the frog. Keep an eye on the big picture. Constantly review what’s happening around you, not just what you personally are doing.

If you throw a frog into boiling water, it will jump out at your face. But if you put the frog in cold water and boil it, it won’t notice and get cooked to death. Good software projects die just like that, slowly, without anyone noticing.

Good-Enough Software

But artists will tell you that all the hard work is ruined if you don’t know when to stop. If you add layer upon layer, detail over detail, the painting becomes lost in the paint. Don’t spoil a perfectly good program by overembellishment and over-refinement.

Know when to stop refining a piece of software. Make tradeoffs if they improve the overall quality of your software.

Your Knowledge Portfolio

  • Serious investors invest regularly—as a habit.
  • Diversification is the key to long-term success.
  • Smart investors balance their portfolios between conservative and high-risk, high-reward investments.
  • Investors try to buy low and sell high for maximum return.
  • Portfolios should be reviewed and rebalanced periodically.

Think about your knowledge portfolio as investors think about their investment portfolio.

Communicate!

It’s not just what you’ve got, but also how you package it. Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication.

Learn to communicate with different kinds of people, technical and non-technical alike.

The Evils of Duplication

DRY (Don’t Repeat Yourself) principle: EVERY PIECE OF KNOWLEDGE MUST HAVE A SINGLE, UNAMBIGUOUS, AUTHORITATIVE REPRESENTATION WITHIN A SYSTEM.

Documents are no exception. Don’t duplicate business logic in code AND documentation. There should be one true source of knowledge (model) and the others should simply be views of that source.

Orthogonality

In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others.

The code you write has to be as decoupled from the rest of the project as possible. It makes bugs easier to find. There should never be overlapping functionality or duplicate code (also a violation of the DRY principle).

The Basic Tools

Every craftsman starts his or her journey with a basic set of good-quality tools.

Selecting a good set of tools can greatly improve your productivity and skills.

Source Code Control

Always Use Source Code Control

Even on single person projects that’s never going to see the light of the sun.

Debugging

Embrace the fact that debugging is just problem solving, and attack it as such.

The best way to start fixing a bug is to make it reproducible. After all, if you can’t reproduce it, how will you know if it is ever fixed?

“select” Isn’t Broken

If you encounter a bug, always be suspicious of your own code. No, the compiler isn’t broken and nor is the CPU. It is your code, fix it.

Pragmatic Paranoia

You Can’t Write Perfect Software

But Pragmatic Programmers take this a step further. They don’t trust themselves, either.

When everybody actually is out to get you, paranoia is just good thinking.

We overestimate our capabilities often. Most people think they’re the best drivers out there. Pragmatic programmers understand that everyone, including themselves, make mistakes, and hence keep an eye out for bugs before they creep in.

Dead Programs Tell No Lies

When your code discovers that something that was supposed to be impossible just happened, your program is no longer viable. Anything it does from this point forward becomes suspect, so terminate it as soon as possible. A dead program normally does a lot less damage than a crippled one.

Assertive Programming

If It Can’t Happen, Use Assertions to Ensure That It Won’t

Turning off assertions when you deliver a program to production is like crossing a high wire without a net because you once made it across in practice. There’s dramatic value, but it’s hard to get life insurance.

Always use assertions to make sure things are working well, even in situations when you’re sure or things are ‘obviously simple’. Detect early and abort.

When to Use Exceptions

“Will this code still run if I remove all the exception handlers?” If the answer is “no,” then maybe exceptions are being used in nonexceptional circumstances.

Don’t use exception for normal code flow control. Exceptions need to be reserved for ‘exceptional’ situations.

Decoupling and the Law of Demeter

Organize your code into cells (modules) and limit the interaction between them. If one module then gets compromised and has to be replaced, the other modules should be able to carry on.

Metaprogramming

Configure, Don’t Integrate

Our goal is to think declaratively (specifying what is to be done, not how) and create highly dynamic and adaptable programs.

Program for the general case, and put the specifics somewhere else—outside the compiled code base.

Put Abstractions in Code, Details in Metadata

Because business policy and rules are more likely to change than any other aspect of the project, it makes sense to maintain them in a very flexible format.

It’s Just a View

The view is an interpretation of the model (perhaps a subset)—it doesn’t need to be graphical.

The controller is more of a coordination mechanism, and doesn’t have to be related to any sort of input device.

Understand what a view really is. Everything revolves around the models, and views are just different ways in which you can represent those models.

While You Are Coding

However, good, safe drivers are constantly reviewing the situation, checking for potential problems, and putting themselves into good positions in case the unexpected happens. The same is true of coding—it may be largely routine, but keeping your wits about you could well prevent a disaster.

Programming by Coincidence

Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place.

If you don’t have fundamentals or infrastructure correct, brilliant bells and whistles will be irrelevant.

Program consciously. Write code thinking of it as an autonomous task once you have the business requirements and architecture clear is a mistake. There has to be equal involvement during programming.

Refactoring

Rather than construction, software is more like gardening—it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost. You may move plantings relative to each other to take advantage of the interplay of light and shadow, wind and rain. Overgrown plants get split or pruned, and colors that clash may get moved to more aesthetically pleasing locations. You pull weeds, and you fertilize plantings that are in need of some extra help. You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed.

If it hurts now, but is going to hurt even more later, you might as well get it over with.

Code That’s Easy to Test

All software you write will be tested—if not by you and your team, then by the eventual users—so you might as well plan on testing

The Requirements Pit

Don’t Gather Requirements—Dig for Them

Work with a User to Think Like a User

The key to managing growth of requirements is to point out each new feature’s impact on the schedule to the project sponsors.

Ubiquitous Automation

Civilization advances by extending the number of important operations we can perform without thinking.

Automate as much as you can.

Ruthless Testing

Most developers hate testing. They tend to test gently, subconsciously knowing where the code will break and avoiding the weak spots. Pragmatic Programmers are different. We are driven to find our bugs now, so we don’t have to endure the shame of others finding our bugs later.

Test State Coverage, Not Code Coverage

It’s All Writing

One of the most important pieces of information that should appear in the source file is the author’s name—not necessarily who edited the file last, but the owner.

Pride and Prejudice

We want to see pride of ownership. “I wrote this, and I stand behind my work.” Your signature should come to be recognized as an indicator of quality. People should see your name on a piece of code and expect it to be solid, well written, tested, and documented. A really professional job. Written by a real professional. A Pragmatic Programmer.

Take pride in your work. Don’t just assume it will be a small cog in the big wheel and use that as an excuse to write sloppy code.

In Closing

That’s all. There’s a lot more in the book, the stories and the experiences. I highly recommend you give it a try if your day job involves writing computer code. Thanks for reading.

Testing Websites On Kindle Paperwhite

Uncategorized,

I bought an Amazon Kindle this week, a device for reading books. It does a magnificent job at improving your reading speed, giving meanings and Wikipedia lookups on the spot and in general making reading a much more convenient and peaceful experience (for a non-native reader, at least).

I was pleasantly surprised to find an experimental web browser in it. I wanted to know how experimental it is. This post is going to be about that.

Warning: Multiple images ahead. Might take a few seconds to load. Patience.

Browser Score

One way to check how good or modern a browser is, is by checking and comparing html5test.com. While not all the features are made equal (some might be more important than others depending on the situation), it definitely gives us a good ballpark figure to compare browsers. For example, Latest Firefox (62.0.3) scores 493 on that test, while lastest Chrome (69) scores 505. Let’s see how our Kindle browser performs in this test!

Hmm. Not bad. And given that it supports Javascript (which was a little surprising to me), I think it works pretty well for its ‘experimental’ tag. Not web 2.0 of course, but decently well.

Testing Websites

Benchmarks and synthetic tests do their job, but nothing beats real-world web browsing, right? I tried to spend some time surfing the web with the Kindle’s browser to see if it would work for casual browsing, or any browsing for that matter. Let’s see how some of the popular websites performed on the browser.

Google

Google was pretty functional, and I didn’t have much trouble searching and navigating through search results. It felt very similar to how surfing on Opera Mini felt (remember that browser?). Usable, I’d say.

Gmail

In all seriousness, I didn’t expect Gmail to work. But it does and gives you a nice mobile view where you can read (and even compose) emails. Not the most convenient way of doing it (and using a randomized twenty-six character password didn’t help either), but can be done nevertheless.

Amazon

Amazon.com was kind of disappointing. Given how their shopping site looks even on modern browsers, I had expected it to look more or less the same, but the website essentially disappeared on Kindle.

The item listing page was a little better, although not a lot.

Wikipedia

Wikipedia was more or less what you’d see on a full browser, at least for reading existing articles. I didn’t try the contributors section (I’m lazy that way).

Youtube

The mobile Youtube site opens up with large thumbnails. On clicking a video, the media file (video.3gp as can be seen in the address bar) opens and as expected, doesn’t play. So Youtube is pretty unusable on Kindle.

xkcd

I couldn’t tell a difference between this version and the one I usually open on Chrome or Firefox. Nearly perfect. Nice work, Randall!

This blog!

Okay, I know. Not a popular website. One of the primary design goals while making the template for this blog was accessibility. I was very pleased to see everything in place (except for a few flexbox dependent sections on the homepage which needs a fix). Well done me! (I’ll show myself out)

Conclusion

I think Kindle’s little browser serves its purpose and does it well. Text is sometimes hard to read given the gray and black display. In my opinion, the bigger problem was that of scroll and typing. E-ink displays are very slow at refreshing, which makes scrolling web pages a pain. Then the typing experience is not that great either. I’m not complaining, of course. That would be very stupid. Honestly, I’m quite impressed with this device. It is well built and makes reading very convenient.

I want to think that the browser is so bare because the engineers at Amazon didn’t want us to switch to surfing Youtube or Facebook while reading that book. So in that sense, it isn’t a bug, it is a feature. Anyway, I hope you enjoyed this little article. I had nothing better to do on a Saturday evening, so this was it. Thank you for reading.