Monthly Archives: March 2018

Phone Review – Nokia 105

30/03/2018UncategorizedelectronicsAbhishek Nagekar

But why a new phone?

Not many people buy a Nokia 105 for reviewing. I certainly didn’t. My Samsung phone had developed this weird syndrome that it would randomly decide not to let me hear the other person’s voice in a phone call. And while I was okay with something as minor as that, many of my friends and family members weren’t so much. I mean, it worked fine for 95% for the things, except for making a phone call, which I average at around 1-2 every day.

So after couple of months of this struggle, I decided that I had two options. Either fix the phone (which involved flashing stock rom, do some A-B testing and if it still doesn’t work, visit the service centre), which was a lot of work and may require money, or get a new phone just for calling, which was easy but definitely required money. After thinking for a bit, I went with this nice phone that I found on Amazon. The deal was in around INR 948, which felt decently cheap, so I bought it.

Review

In a nutshell: FM radio, a 3.5 mm headphone jack, torch, Micro USB connector for charging and a removable battery that lasts more than a week of normal usage.

I opened up the box and the phone instantly felt nice, something new, something interesting to look at, to start, to go through the menu. It was like the first time I went through an Android phone. Nowadays, everything is either Android and iOS, and there’s not much to look at in your colleague’s new phone. But this felt new. The phone doesn’t lag, and key-press to ready-for-operation time is negligible. They keypad is backlitted, and keys are soft to touch and takes some getting used to, not exactly my most preferred keyboard, but works fine for most things (which is just texting and dialing numbers, to be honest).

The display is QQVGA, which is quarter of a quarter of a VGA. For comparison, Apple Watch has 6.3 times more pixels on its screen than this phone. And just for the heck of it, Samsung’s current flagship phone, the Galaxy S9 has 222 times more pixels. Yes, two hundred and twenty two times. But here’s the thing, it more than works for most purposes. It has 4MB of RAM and 4MB of ROM. You can even play Snake on this thing. Isn’t that super cool?

It has a very dim torch too, but works fine and can be switched on from homescreen with a double click on the top arrow key. The features that set it apart from the many phones I’ve seen and tried in the recent times are the FM radio, 3.5 mm headphone jack and a week long battery life. In all honesty, I charged this phone last Sunday afternoon, and today is exactly a week since that. The battery indicator is still around 30-40%, and I’m certain it will last 2-3 more days. Isn’t that plain insane? The sizes of battery may have improved but so have the components that will drain it. And then suddenly you have a phone with a decent battery size (around 800mAh) but nothing to actually drain it and it feels like a phone from another planet. Thumbs up for that.

Conclusion

The phone is good, the quality is decent, most importantly, it just works. If you need a secondary phone that won’t die out in the middle of the day, this phone can take that spot. If you just want to get away from the habits of checking your social apps during commute, then you might consider using this as your primary phone and using that smart phone as an mp3 player cum ebook reader. It is a win win win; 1. You have a phone with amazing battery life. 2. You don’t get distracted and can finish reading that book without the urge of checking reddit/replying whatsapp. 3. Your smartphone’s battery life improves quite a bit without a SIM and data connection.

Thank you for reading

Book Review – The Mythical Man Month – Fred Brooks

27/03/2018UncategorizedbooksAbhishek Nagekar

Probably one of the highest recommended books in the software world, this isn’t your typical tutorial/guide/reference book on programming or software engineering. Rather, this book is a series of ideas, more or less independent, on large software projects.

I’ll have to admit that you should get some actual software development/management time under your belt before picking up this book, otherwise it is very difficult to make the right connections, which is very important given this is a book full of essays from the 70s software development era. Details might have gone outdated, and many other things won’t really work in today’s fast paced startups who live by the fail fast mantra. Nevertheless, the human aspect of software is very accurately depicted in the text. Why software projects are difficult to manage? Why does adding man power to an already late project only makes it ‘later’? Why is communication important? These are some of the interesting questions that the author addresses in the text with his opinions and experiences.

I won’t go into the content of the book, as I would never be able to do justice to it. If you’re looking for a short summary, refer the Wikipedia page for the book. Highly recommended if you’re a software developer and would like to read one of the rare kind of books in our field, a book on the human aspect of software engineering.

Myths About Frontend Engineering

23/03/2018UncategorizedAbhishek Nagekar

I’ve met a lot of young programmers in the recent past. When I say young, I don’t mean by age or accumulated experience, because that way even I am young. I mean the people who’re starting out in the world of software development, putting their first few footprints in this virgin new land. I’ve noticed this one thing in particular, discomfort about working on the frontend of a web/hybrid application, writing Javascript and CSS.

And if I am completely honest, even I was amongst those people just about a year ago. I consider myself an accidental frontend engineer and now, having worked in that trade for the past 6 months, I feel I’m in a position of debunking some of the myths that I believed in before starting out, and probably help those of you who try to stay away from frontend engineering due to some of these undue fears.

Myth #1: CSS is difficult

This is something that I hear most often. People hate CSS because they feel it is hard/illogical/browser-dependant/just-trial-and-error/not-really-programming and more. In fact, none of that is true in modern browsers. Now since IE has died, and we have build tools for most of the things, any project using a modern build tool like webpack is a joy to work with. We have auto prefixers, polyfills and things that minimize the need for writing browser specific CSS. You spend less time wrestling with your tools and more time solving the actual problem of designing the interface.

Then there are CSS preprocessors that add loops, variables and control statements to vanilla CSS to make it more programming-like and easy to write/maintain. I’ve not been a huge fan of these, but is definitely something I’d want to checkout. There’s also this new shift in style of writing CSS in Javascript itself and there are libraries like styled components that assist you with that. While the correctness of this approach is arguable, I feel writing CSS wrapped in JS has it’s own advantages, something you can explore as well.

Myth #2: Javascript is broken

Here’s the thing. It is very easy to mess things up with Javascript, or any other forgiving language. And JS is right there at the top in the list of languages that are extremely forgiving, making it very easy to shoot yourself in the foot if you’re not careful. And apart from all of that, bashing JS is the part time hobby of half of the Internet, and while there may have been reasons to do that in the past, the current language specification is pretty good and useful. With the new ES6 and upcoming ES7 standard additions to the language, it is very much possible to write good quality tight code that is maintainable for years.

As the language does not enforce tightness upon you, much of the responsibility of not messing up the codebase falls on your shoulders. There are tonnes of libraries that assist you with immutable data structures, code linting to avoid common coercion bugs, following functional programming paradigms to enforce side-effect free code etc. Once you’re comfortable with these good practices, writing clean and maintainable code in JS feels just as natural as writing it in any other language.

Myth #3: There’s no logic in frontend

Again, this is totally not true. Your typical frontend these days has a lot of business logic thanks to the onset of single page applications. You have persistent storage on the frontend in the form of LocalStorage, you have indexDB for a client side database, you have service workers for hijacking API requests and servicing them right on the client, webworkers for additional computational needs, websockets for real time event based bidirectional communication, databases like CouchDB on the backend mated with PouchDB on the frontend which have nice syncing capabilities.

In short, there’s more to do on the frontend than ever, and most of these things involve solving tough challenges, both from an infrastructure and programming perspective, and needless to say, this is apart from the beautiful application that people will use, structured and styled in HTML and CSS respectively, that is also part of the frontend.

Myth #4: There’s no computer science in frontend

I’ve spent more time in my current work place not making new features but optimizing the ones that were inefficiently implemented. Computation/memory resources are very precious on the end user devices, given that the application has to run on a wide range of devices, and you cannot just assume what runs smoothly in your desktop browser on your 10 Mbits connection will run just as smoothly on that three generations old phone running a 1 Mbit connection. This particular thought process has embedded a mindset within me that makes me write side effect free functions, save data that comes to the application locally, avoid iterations, think about efficient data structures and about reducing any IO that might cause my application to slow down. If I don’t, then my beautiful application goes crashing down in old mobile browsers.

You don’t need to know computer science per se, and while you can get away with not knowing where a graph should be used or what tail recursion is in most case, knowing it only helps. And it definitely helps in optimization, if your application is particularly heavy and has to run on mobile phones. I recently fixed a bug that required knowledge of JS event loop and call stack (thanks Philip Roberts!) and I would’ve had a hard time figuring it out had I lacked this particular piece of knowledge. The point is, there’s always scope to apply your core knowledge no matter what your profile is.

Myth #5: Libraries/Frameworks on the frontend go extinct fast

It feels bad when a framework that you spent a lot of time learning goes out of active development. While that is surely the case with many frameworks/libraries in the Javascript land (new libraries are literally getting written ever other hour), some of the popular ones like React and Angular stay supported for years. And while that still is less compared to Django in Python or Qt in C++, these JS libraries are also relatively easy to pick up and master, requiring fraction of the effort it would take the same engineer to get that kind of confidence in Django. Adaptability is a critical programmer quality, and learning a new framework once every two years is not that bad a deal given how dynamic the frontend web development scene is.

Myth #6: The support tools are not mature

I used to argue that there are no good debuggers available for the frontend, that the IDEs are not that great, that CSS debugging is just trial and error and JS debugging is just console.logs all over the place. I was obviously wrong. Our tech lead demonstrated the use of node’s debugger which can be integrated into VS Code and WebStorm, setting breakpoints and analysing application state at that point. Then there’s Chrome’s own developer tools which has this performance tab that you can use to check which part of the code is slowing down the application. Using these tools will probably take up an article of their own, but the point is, like with anything else, you have to look around for new things if you want to master the art, otherwise you don’t learn anything new.

In Closing

I am convinced that frontend development is nothing less than any other form of software development, with its own set of challenges and perks, and if you have any deeper interests like core computer science, cyber security, distributed computing etc, you can learn those things separately and apply them here. There’s always scope for that, like in other developer profiles. Plus, in all the above points, we never mentioned the perks of being a frontend developer. Yes, it is an extremely rewarding profile. Just last week, I was showing off our web application to my mom. She was quite impressed. I went over all the pages, the search design and many other little things that I’m proud of, on my phone. Sometime during this, I noticed that I’m not connected to the Internet, and the application never made me feel like I wasn’t, thanks to the amazing browser side technologies like indexDB and service workers that make progressive web apps possible. Now even I was impressed, haha. Also, explaining your work to someone not from the tech background is simple, and ‘I create beautiful websites’ is a nice description of the kind of work you do, no matter what the audience is.

I don’t think an article can change anyone’s mind regarding frontend engineering, but at the least, if you were unfriendly towards frontend development, I hope to have given you some content to start considering frontend engineering as one of the profiles that you might want to someday work as.

Thank you for reading.

Hum Developers Kab Banenge?

08/03/2018Uncategorizeddesi, lifeAbhishek Nagekar

I was sitting at my office desk as usual, besides the window enjoying the cool breeze of post 6 pm friday evening of a summer day, 7 floors in the sky, at our office. We’re now 2 regulars in the office, and while it does get a little boring at times, there are also times when I appreciate the silence, the sound of wind through the little window on my left, the occasional rattling of helicopters passing by. That desk and that window are really interesting, my gateway to a different world where I just sit 15 minutes at a stretch staring at a distant building, the lights on its terrace blinking harmoniously. The occasional helicopter, and the people inside of it. Where must they be heading? Are they appreciating the fact that they’re inside that bird that countless individuals like me adore from the ground. I don’t know.

And just like that, I get to think about my own self. My thoughts four and a half years ago, in the first year of my college. There was so much excitement of getting into computers formally, finally. Now I could actually read interesting stuff off the Internet all day long and call it studying, without raising my mum’s eyebrows. I had a friend with whom I could share my technical side, which wasn’t much then, to be honest. Programming was the new thing and we knew we needed to learn this wizardry. Why and how we never thought of. There wasn’t a lot of knowledge within, not even speaking of wisdom, startups were unheard of, and life’s goals were defined in terms of what to learn next and ‘let’s see if we can solve this interesting puzzle with code’. It just was this raw energy that we had then, a kind of purity towards learning, the way opposite magnetic poles attract; no stray intentions.

It always brings a smile on my face thinking of those days. That purity towards the thing that you love, not asking why or if it will help me figure things out in the ‘big picture’ or will it look good on my portfolio, just that desire to go do it, to learn that absurd thing that has been obsolete for half a decade; why, because why not. I clearly, very clearly remember the happiness I felt after learning enough C to write basic programs, enough Python to flaunt my first ‘full stack’ web application. I learnt much later what full stack was, and even later that it was a job title. It was nice being able to make those things. We did whatever we thought was cool at that moment, anything that would tickle our curiosity.

In the midst of all of this, there was always a question I remember asking myself and my friend: ‘Hum developers kab banenge?’ All we knew was that a ‘software developer’ gets paid to do the kind of things that we do as hobbies. We had seen in total one software developer by then. He was Asa Dotzler from Mozilla. He was a nice person, but then we saw him as God because he could write code, you know. We kept on asking the question, but then sometime later, we stopped. Life got busy, everyone dashed towards their personal goals, the bigger picture and all that adulthood stuff. Suddenly, all of us were identified as developers, got hired as software engineers and started working for a monthly paycheck.

We were there before we even knew we were, and things aren’t much different on this side of the fence. Only now, you have to work whether or not you feel like working, your hobbies come in secondary to your professional goals and your life starts to revolve around this weird hierarchy of going from bottom of this growth ladder towards the top, occasionally changing the ladder. I guess that was all part of the package that we never bothered to explore properly. Or perhaps all of this is the optional bit that we took because everyone else was taking it, and maybe, with some courage we can get rid of this extra weight slowing us down and be those balls of raw energy that we were in college, being the ‘developers’ that we always wanted to be. I don’t know which one it is, but I guess we’ll eventually find out.

Thank you for reading.