Tag Archives: programming

What Writing A Web Development Tutorial Taught Me

Uncategorized,

I recently wrote a tutorial on getting started with web development. It was a frontend only (meaning covering only HTML, CSS and JavaScript), 5 day tutorial that covered very basic web development topics and concepts like HTML elements, CSS selectors and JavaScript language semantics. Along with learning the basics of frontend web development, the course takers built their very first website which was a simple, one page portfolio site listing their interests and some pictures.

I’d not go into the technicalities of the course itself, as that’s off topic. What I’d like to do in the little post is list down some things I learned while I was writing the course, about writing the course and also about writing your thoughts down in general.

  1. If you’d like to test your understanding, try explaining it
  2. Many obviously true beliefs that you hold probably aren’t true
  3. Explaining is an art
  4. The role of an editor
  5. Writing requires a lot more focus than programming
  6. Having a continuous thought train for a multipart article is exponentially more difficult than writing a one off article
  7. Have a plan or outline
  8. Know your audience’s technnical competence

So, without further ado, let’s get started.

If you’d like to test your understanding, try explaining it

“The person who says he knows what he thinks but cannot express it usually does not know what he thinks.”
— Mortimer Adler

The above quote from this interesting blog post about Feynman Technique on Farnam Street captures the gist of this learning. We’re good at convincing ourselves that we understand something when in reality we might not. It is similar to when we speak a language natively and are confident in our knowledge, but then when a language-learner asks us a simple question, we don’t have an explanation but rather know it ‘intuitively’.

As an example, when I was writing the chapter on JavaScript, I was tempted to write that arrow functions have replaced the ‘function()’ functions. I asked myself why I thought that was the case, and I didn’t have an answer. I had just ‘believed’ that to be the case.

Upon researching, I learned the differences in their workings and their use cases, and I came out of that a bit wiser than before. That was just one instance where I wrote something, then asked myself why I thought that was the case, and learned that that was in fact not the case.

The bottom line here is, if you want to learn something well or test your understanding, try explaining it. Interestingly, that’s just me rediscovering the Feynman technique.

Many obviously true beliefs that you hold probably aren’t true

This is an extension of the previous point. But with a different takeaway. Since we’ve now established that many of our beliefs are wrong, it is wise to not be too confident in them and always practice humility when it comes to your knowledge, and consequently, your opinions and worldview. In other words, while it is great to put in time and energy to learn something properly and have opinions about it, it is also important to be ready to accept that you could be wrong and change.

This point is best illustrated by the “Strong Opinions, Weakly Held” philosophy, best outlined by a little paragraphy from this post.

A couple years ago, I was talking the Institute’s Bob Johansen about wisdom, and he explained that – to deal with an uncertain future and still move forward – they advise people to have “strong opinions, which are weakly held.” They’ve been giving this advice for years, and I understand that it was first developed by Instituite Director Paul Saffo. Bob explained that weak opinions are problematic because people aren’t inspired to develop the best arguments possible for them, or to put forth the energy required to test them. Bob explained that it was just as important, however, to not be too attached to what you believe because, otherwise, it undermines your ability to “see” and “hear” evidence that clashes with your opinions. This is what psychologists sometimes call the problem of “confirmation bias.”

While you’re at it, I recommend reading this article by Jeff Atwood where I first read it. There’s also this nice TED talk along the same lines.

Explaining is an art

It is not easy to explain why linear-gradient works the way it does. It is hard to explain parameters of a function to someone who has never written any code, and you cannot use words like parameters, arguments or function call before explaining them. In short, writing a beginners programming course is some work (who would’ve thought?!). Now I look back at all those books, articles and tutorials that taught me the basics of everything I’ve learned and realize how great it was to have had all of that top quality learning material for free on the internet.

My personal experience is that we don’t notice when something is very well written or explained, especially with technical writing and documentation. It feels very natural and in-flow. But try to remember the last badly written article that you read. It was exhausting, you had to re-read through paragraphs to make sense of the text and you probably didn’t even finish it. That’s why, the next time you read through something and don’t notice anything wrong, take a moment to appreciate the effort that might’ve gone into making it come across the way it does.

The role of an editor

I learned what an editor does while writing this course. I would typically submit a day’s work as a document, fairly confident that I had done a good job only to find out the next day that the document has 200 new comments and edits. How was that even possible? I’m not a good writer, accepted, but those many edits? I would genuinely fear submitting my work for editing, just like my younger self would fear exams for all the bad grades I could get.

But in this case, the editor is really there to make the text readable, check if the sentences flow naturally and there’s no discontinuation of thoughts (and of course, spelling and grammatical shortcomings in the text). All in all, after the edit the content doesn’t look anything like the initial draft I sent for editing. If you ever get the chance to get your work reviewed by an editor, don’t miss it. You’ll learn a lot.

Writing, for me, requires a lot more focus than programming

I realized how much more focus writing content needed as compared to programming. I could just not do it in the office. Every 15 minutes I’d lose my train of thoughts due to some or the other distraction. I believe this could be just because I’m not used to the idea of writing content in the office, or writing professionally in general. I would end up taking work from home days to make sure I’m making progress. I had not expected this to happen, especially after having been an amaeteur blogger for a while now. But there I was, trying to think of the next sentence while repeatedly reading the paragraphs above.

Having a continuous thought train for a multipart article is a lot more difficult than writing a one off article

So I feel quite comfortable writing something like this very post. It is not as long, and one can write the whole thing in a couple of sittings. Then there are also not a lot of different ways of presenting here. Just text followed by headings followed by more text. That’s quite a lot easier than writing a multi-day course with each day three or four times as long as a typical blog post with many screenshots, git commits, code snippets and, of course, text. It is important to keep track of all your resources, and any mistake you find later on means all the screenshots and git commits from that point on needs to be updated, which is quite a hassle.

Have a plan or outline

To avoid finding technical faults / discontinuities in the text much later in the course writing, having a plan or an outline about the content is very important. Each chapter, and every topic in the chapter should be outlined before even starting with the actual writing. Ideally, even the outline should be reviewed by someone who knows about how learning works (yes, that’s an expertise), and the final outcome should be communicated well in advance. You want to avoid making the course too difficult (and have people drop out after getting stuck) and too easy (and have people drop out after getting bored).

Know your audience’s technnical competence

When you’re writing a beginner course in software development, you have to explain every bit of technicality. From creation of a file with special extension to what a git commit is. Any assumption you make regarding the ability of the user to understand the course’s substance can backfire resulting in many course takers abandoning the course mid way or flooding the communication channels with their questions. To avoid this, it is important to know the technical competence of your target audience. You cannot cater to a wide range of expertise, and no matter what you write, many people are going to be left out. But that’s okay.

In closing

I’m glad I found this opportunity to do some professional writing. I learned some important aspects of writing, and I tried to share my experiences with you through this post. I hope you find something useful out of this. As always, 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.

On The Importance Of Iterations In (Product) Development

Uncategorized

In LaughGuru, we received designs from the UI designers on Zeplin, a nice tool that bridges the gap between designers and developers. While I wouldn’t know about designers, it definitely made my life (as a developer) easy. My previous experience with frontend was with designers who gave me Photoshop PSDs and that was it. A Photoshop noob was expected to extract layers among other things and think about mobile responsiveness and all of that. I’ll leave you here saying it didn’t end well. But I digress.

Recently, I read the all-time classic ‘The Mythical Man Month’. It had an interesting line that I even wrote in my nice quotes file. It goes like this: “Plan to throw one away; you will, anyhow.”. It says something about planning to throw away the initial iteration of any product that you’re developing, because even if you don’t, you’ll throw it regardless. While that isn’t very agile and might not apply in its entirety to most of the software development happening today (to be fair, it was initially written in 1975), it had an interesting idea about how the first version of the product needs major reforms (or rewrite) to end up as something usable and/or beautiful. You can’t avoid that. You can only prepare for that.

Coming back to why I mentioned LaughGuru because I just remembered that. The first version that we received from the designers wasn’t very impressive. It lacked colors and looked bland to my ‘taste’, whatever it was at that time. But my manager had something else on his mind. He seemed to focus on the data flow and UX parts of things rather than the colors, unlike me. We went ahead and implemented it anyway, but since there was no design-design, most of the focus was on functionality, routing and data flow. It became the beta of our product’s latest iteration.

Later, we received newer designs which had colors. We discussed and later implemented them. This time, I could fully focus on the designs part as functionality was already done and tested. We did decently well and a couple of iterations later the end result was nothing short of beautiful. I used to tell my manager Look! it has started to look even better now, and he usually replied, unimpressed and with the typical attitude of a badass that he was, Yes, that’s kinda the idea. Of course, separation of concerns works. I was proud, and an important lesson got reinforced within me. The first iteration is usually ugly and sometimes embarrassingly silly. But it tells nothing about the practicality or viability of the underlying idea. It tells even less about if the idea will ever be successful. So why abandon it or feel dejected if the initial iteration draws negative feedback. Instead, learn from the criticisms and stick to the larger goal of why you started it in the first place.

I was recently working on my portfolio site because, to be honest, having this blog as a site to represent me and the kind of work that I do doesn’t really work with anyone expect developers and engineers, and that isn’t a very nice (read: accessible) thing to say about a website or yourself. I wanted something fancy and shiny, so I made that. Following are some don’t dos in any software project. I tried to focus on too many at once (content, UX, UI). I tried to get everything straight in one iteration, or roughly a day. I had no plan for the development, or any vision about what the end result should look like. I had little idea about what audience I’m targeting. The end result was something I wasn’t very proud, but I still asked my friends for feedback.

While the feedback was in general useful, a friend who was particularly into UX and UIs decided to guide me a bit (I’m sure he must’ve had taken a deep breath on seeing my work). He completed a course on product design on Udacity which mentioned that UI designing is never complete. You will always find ways to improve, and at a point, you’ll have to stop yourself once the design requirements are settled. But the room for improvements is always there. Another useful lesson. We went on to make small changes in the page, and with each little change, such as making a heading bold or adding some padding below an element, the page looked better than it looked previously. Within a day or two, the page was something that I’d proudly associate with myself.

So to close this one, let’s review the lessons we learnt:

  • Your product’s first iteration is going to look like shit unless you decide to launch it too late. Don’t get saddened by its lack of ‘perfection’, for you’ll have plenty of time to do it down the line. Focus on the basics like why you started it all and what purpose it is supposed to serve.
  • Separation of concerns is important. It is easy to get overwhelmed by the things to do, so have a plan and don’t put too many things on your plate at once.
  • It takes time to create anything worthwhile. You cannot get something right in the first iteration itself. It is against the laws of nature. Evolution required some four billion years to create the beautiful individual that you are. Don’t rush it beyond what is possible and practical.
  • In UI development, things are never done to a 100%. You try to improve as much as possible through iterations, meeting business requirements and personal standards and then going well beyond that. At a point, you call it a day and move on to the next challenge.

I hope you enjoyed this little article. Thank you for reading.

Advice From An Old Programmer – Zed Shaw

Uncategorized,

The first article on my site is about me starting with Python. That was four years ago and around that time I had read this book called ‘Learn Python The Hard Way’. I really, really liked it. It was amongst one of those earlier pieces of memories that I’d probably never forget for my entire life, similar to the kind of impact reading The Hacker Manifesto and Sir Eric Raymond’s ‘How To Become A Hacker’ had on me.

I decided to give the Python 3 edition of Learn Python The Hard Way a read. The last section of the book is titled ‘Advice from an old programmer’ and in that, Zed Shaw shares with us some of his zoomed-out thoughts on programming and the career one makes out of it. Although it is very subjective and very blunt, just like the rest of the book (and I really like the rawness in his writing), for me personally it refreshed the old memories associated with the book.

I had read this exact chapter in the previous edition, but this time it made so much more sense. And not just this chapter, but in the entire book, the subtle pieces of well targeted humor and strong opinions held by the author were something of a delight to read even if you didn’t believe in the exact same thing.

I’m copy pasting the section of that book that I think I’ll come back to read re-read again and again. I think many of you will appreciate it as well.

Advice From An Old Programmer

You’ve finished this book and have decided to continue with programming. Maybe it will be a career for you, or maybe it will be a hobby. You’ll need some advice to make sure you continue on the right path and get the most enjoyment out of your newly chosen activity.

I’ve been programming for a very long time. So long that it’s incredibly boring to me. At the time that I wrote this book, I knew about 20 programming languages and could learn new ones in about a day to a week depending on how weird they were. Eventually, though, this just became boring and couldn’t hold my interest anymore. This doesn’t mean I think programming is boring, or that you will think it’s boring, only that I find it uninteresting at this point in my journey.

What I discovered after this journey of learning is that it’s not the languages that matter but what you do
with them. Actually, I always knew that, but I’d get distracted by the languages and forget it periodically.
Now I never forget it, and neither should you.

Which programming language you learn and use doesn’t matter. Do not get sucked into the religion
surrounding programming languages as that will only blind you to their true purpose of being your tool
for doing interesting things.

Programming as an intellectual activity is the only art form that allows you to create interactive art. You
can create projects that other people can play with, and you can talk to them indirectly. No other art form
is quite this interactive. Movies flow to the audience in one direction. Paintings do not move. Code goes
both ways.

Programming as a profession is only moderately interesting. It can be a good job, but you could make
about the same money and be happier running a fast food joint. You’re much better off using code as
your secret weapon in another profession.

People who can code in the world of technology companies are a dime a dozen and get no respect.
People who can code in biology, medicine, government, sociology, physics, history, and mathematics
are respected and can do amazing things to advance those disciplines.

Of course, all of this advice is pointless. If you liked learning to write software with this book, you should try
to use it to improve your life any way you can. Go out and explore this weird, wonderful, new intellectual
pursuit that barely anyone in the last 50 years has been able to explore. Might as well enjoy it while you
can.

Finally, I’ll say that learning to create software changes you and makes you different. Not better or
worse, just different. You may find that people treat you harshly because you can create software, maybe
using words like “nerd.” Maybe you’ll find that because you can dissect their logic they hate arguing
with you. You may even find that simply knowing how a computer works makes you annoying and weird
to them.

To this I have just one piece of advice: they can go to hell. The world needs more weird people who know
how things work and who love to figure it all out. When they treat you like this, just remember that this is
your journey, not theirs. Being different is not a crime, and people who tell you it is are just jealous that
you’ve picked up a skill they never in their wildest dreams could acquire.
You can code.

They cannot. That is pretty damn cool.

Beautiful, isn’t it? Thank you for reading!

A Programmer Or A Problem Solver?

Uncategorized,

Normally when we think of programming, we think of problem solving. Similarly, if someone works in the field of computers and say they love problem solving, we immediately assume that they work with some computer code. Programming is almost synonymous with problem solving, in that it involves breaking down complex looking problems into simple mini problems that can be easily taken care of. Where they might differ, in my opinion, is finding the right problems to solve.

The inspiration for this post came from a recent blog post that I read (embarrassed to admit I’m not able to find that post found it!) about the mistakes developers make. One of the mistakes was confusing between the love for problem solving and programming. That was a little “ahaa!” moment for me. It gave me a moment to reflect on my own likes and interests. What is it that excites me? Is it the idea of building the next big thing? Maybe. Is it spending countless hours writing code that does what has been done a million times before, just so that you can fall in love with your code all over again? Yes, that’s sounds about right.

I liked to call myself a problem solver, but I’m not even close to being one. I didn’t feel like there was a distinction. But there definitely is, now that I’ve met some people in my field who are ‘problem solvers’ first. I don’t have Github projects that reflect a problem solver. What you’d rather find are spot on examples of reinventing the wheel (a dozen chat/social network networks), attempts to write the most beautiful code that I can (regardless of whether it works or not), over-engineering to say the least, projects made entirely for trying out new languages, new frameworks, new IDEs, literally. I’m somewhat embarrassed to admit that the current project I’m working on is a chat backend as well.

You get the pattern. It isn’t hard to understand that I love programming. I love writing code regardless of the problem in hand. I see people building things that are changing the world, the way we live, the way we communicate, the way we travel and I appreciate them all. We need people like that. They are on the frontiers of the information age that programmers like me and many of you are riding on. It is here we start to see the difference between someone who is a programmer first and someone who is a problem solver first. I believe it is a matter of preference, experience, and the level and kind of exposure one has in the budding years in tech.

I had a couple of “tech friends” right from my junior college some 4 years ago, people with whom I could discuss programming and tech in general. Most of my collaborated projects were with these people, and we always worked on something because we enjoyed it, purely out of our “passion” for computers. We spoke about new languages, technological advancements and people in tech in our free time. We never thought any of this would help us get a good job or any project would appear on our CVs. That is one reason why technologies and frameworks are scattered all over my blog, instead of quality projects that people actually use in one particular technology that I could’ve been good at.

So that’s what I’ve learnt recently, and wished to share here. I (or anyone) won’t know which way is the right way to go, or if there is one, and it doesn’t really matter much as long as you enjoy what you’re doing and make a decent sum of money doing it. I admire people who are passionate about programming as well as problem solving, and the world would really be incomplete without either one. Thank you for reading.

Experiences With Android

Uncategorized

I began learning Android this semester for my final year project. Android and Java were technologies I never thought I would learn by myself. I always felt they were overcomplicated and for me that translated to boring. I was, of course, wrong as things started to become clear.

My friend Kunal really inspired me to take on Android. He guided me with basics of Java that I covered by reading the first 12 chapters of the book “Java The Complete Reference”. After that Kunal even went ahead to give me a hands on session on the basics of Android.

Now to be honest, I can write basic Android applications, but anything above that would require extensive Googling. Partly because once I knew I won’t need to learn anymore to complete the project, I stopped. But inspite of all that, there were a few great experiences that I wanted to share here about my short journey with Java and Android.

The most amazing thing I learned was that Java is a great language to learn object oriented programming concepts. Interface, abstract class, method overloading and overriding were just words for me before diving head first into Android. I understood the meaning, and I could even write you the classic sample Animal<->Dog,Cat example to demonstrate all of those, but I never actually saw their potential application in any of my projects. Get started with Android and in a day you’ll realize what those terms actually look like in practice and suddenly it all starts to make sense.

Another thing that I noticed in the Android ecosystem is that Android is far more stable than most of the other technologies that I deal with, or have dealt with. I remember my time with Angular 2. Issues used to pop up and the only thing that showed up when you Google your problems was a Github issue created 3 days ago with 17 comments saying “Same problem here”. It was horrible, and it intensifies when you’re using it to build something professionally for a third party, and not just a random side project. Android felt much more like C++, predictable, readily available resources on Q&A sites like StackOverflow, and a standardized way of doing things.

Lastly, a subjective realization. Android is a powerful tool in any developer’s toolkit. It is the midway between web and system, with the ease and straightforwardness of the web and the power and reach of system. It is fascinating to a naive code guy like me to grasp what all is possible in Android. The APIs make just about everything accessible to the developer, and I’m not even going to get started on the reach of Android. Look, imagine this. It’s like knowing how to hack Raspberry Pi with your kick-ass Python, but in this case, every damn person you know has a Pi, carries one around, and it is connected to the Internet all the time. Now that is the kind of power we’re talking about here.

In closing, if you’re like me who just does something for the sake of that momentary joy of learning something new, give Android a try. Apart from all the good stuff that I’ve mentioned above, it is just a great feeling to try something new, right? Thank you for reading.

_Generic in C And Generic LinkedList Implementation

Uncategorized,

Tada! Finally a non-Javascript post for those of you who stopped visiting my blog because of my sick Js addiction. So my lost friend Aditya is back, and while talking to him, I got to read a piece of code that he wrote when we were in third semester, last year. The aim was to build a generic container to store different datatypes, in C. So yes, literally storing [21, “abhishek”, 3.142, ‘z’] in a single dynamically allocated linkedlist. That was pretty bold for us then.

For making that happen, he made use of the _Generic macro that C11 introducted for generic type selection. For those unfamiliar with it, I’ll begin with explaining the basics of the macro. For those of you interested in the linkedlist code, scroll down to the bottom of this article. You can always check out the C11 draft [section 6.5.1.1 Generic selection pg #96] (the standard costs around $60 but is essentially the same thing).

The _Generic macro follows the format _Generic(controlling-expression, association-list) where controlling-expression is the expression whose type is to be detected, and association-list is the dictionary of type-expression pairs where type can be any object type and the expression can be any expression, constant or a pointer to any function, pretty much anything that can be evaluated.

To put it simply, compare it to the switch statement for type detection. For example,

#include <stdio.h>
int main() {
  char *teststring = "my char array" // target object
  char *type = _Generic(
    teststring,
    int: "int",
    int*: "int *",
    char: "char",
    char*: "char *",
    float: "float",
    default: "default"
  
  printf("%s", type
  return 0
}

$ gcc main.c
$ ./a.out
char *

The _Generic macro can be wrapped around in a nice looking function call, say detect_type(). Compare this to a (pseudo) switch statement which evaluates the case that matches the switch params

// Pseudocode may resemble Javascript. Reader discretion advised
var someobj = "text here" // target object
var type // to store the typename
type_switch(someobj) {
  case int:
    type = "int"
  case int*:
    type = "int*"
  case char:
    type = "char"
  case char*:
    type = "char*"
  default:
    type = "default"
}
print(type)

So that is it. A compile time type identification in C with a simple macro. We can do pretty amazing stuff with it using pointers to functions. For example, a generic print function, that can take in any type of argument and print it. I have added cases for integers, characters and string, but others can be added just as easily.

That was neat, wasn’t it. Now back to Aditya. He used the same macro to create a dynamically allocated linkedlist. I am pasting the gist here so that you can read his beautiful code.

File linkedlist.c

File linkedlist.h

File main.c

To compile it, run ~$ gcc main.c linkedlist.c -o linkedlist on any machine with GCC installed (I’ve tested it on version >4.9). Run it with ~$ ./linkedlist and you should see the different elements that we’ve added printed on the standard out. You may also pack the linkedlist into a statically linked library, by running.

~$ gcc -c linkedlist.c -o linkedlist.o
~$ ar rcs linkedlist.a linkedlist.o
~$ gcc main.c linkedlist.a

Interesting, isn’t it? Want to thank him, or have any comments or improvements? Drop them into the comment box. Thank you for reading.

External Links

Vim Cheatsheet

Uncategorized

Started using vi, although the only reason is it being light weight [I am taking a leap of faith, hoping that it will increase my speed after some practice, as most vi gurus say]. Let me first admit it. Vi feels awful in the beginning. It is really intimidating, and I am having a hard time to remember the commands and stuff. Hence I started writing the commands I learn from google and stackoverflow in a file. Thought to post it here, for everyone.

I will keep the list updated as I learn more and more commands and tricks. It serves me as a reference, and hopefully will do the same for some of you.

Open file

vim file.js

Swtich to insert mode

i

Switch to append mode

a

Switch to command mode

[ESC]

Save file

:w

Save and exit

:wq

Exit [if no changes were made]

:q

Exit, discarding changes

:q!

Moving through text

h - left
j - down
k - up
l - right

Undo last operation

u

Copy current line

yy

Cut current line

dd

Paste last copied line

p

Select text

[CTRL] + v
h,j,k,l ;for moving and selecting

Selecting multiple lines

[SHIFT] + v
j,k ;selecting lines

Search through text

:s/pattern

Search and replace

:s/pattern/replacementString

Working with multiple files

vim file1.c file2.c file2.c

Next file

:n

Previous file

:prev

Go to particular file

:b file3.c

Working with multiple files [tabs]

vim file1.c file2.c file3.c -p

Move to next tab

gt

Move to previous tab

gT

List all open files [or buffers]

:ls

Commenting multiple lines

[CTRL] + v ;to enter visual mode


[ESC]

Uncommenting multiple lines

[CTRL] + v ;to enter visual mode
jjjl ;selecting multiple rows and columns
d

Auto-indenting

=

Move to the start of the file

gg

Move to the end of the file

G

Auto indent entire file

gg=G

Indenting a block [starting from a paranthesis]

=%

Indenting selected lines


jj ;move down through required lines
>

Starting a shell

:shell

Executing bash without shell

:command ;eg. :pwd

Love For Graphical User Interface

Uncategorized

I considered myself a ‘programmer’. One who can make stuff happen, put it on paper, my thoughts and use it as a framework to create working stuff in the digital world. As any programmer, I learnt to write command line programs first. What are command line programs, you’d ask. Well, a Command Line Interface (CLI) is an interface which reacts to not visual, but textual inputs from the keyboard. You never need a mouse to work with a command line, of course, if you’re skilled with that particular type.

Command lines were the only way people worked with computers in the past. It was a time when the other name for people who worked with computers was programmers and hackers. No one else had the time or skill to learn and master the complicated systems. But like everything, it changed. Back in 1973, we had the first computer system that ran a GUI, or Graphical User Interface. As it sounds, yes everything was now controlled by pointing device, better known to us as a mouse. This was the onset of computers for the non programmers. Now, everyone could learn how to make computers do stuff with few ‘clicks’. We never actually looked back since.

But same was not true for people who program the computer. Programmers still and will always prefer the command line interface for most simple tasks. There are actually some tough reasons for this statement. Mainly, although the task to master CLI tools is not easy, once you do it, it feels much more comfortable than to use the every changing GUI. Not to mention the low resources that are required to run these utilities, and consistency over different platforms or operating systems. As an example, I can write a CLI tool in Python and C++ to run on Windows and Linux, and you won’t be able to spot the difference between the four instances. Can I do the same with GUIs? No, at least not right now.

For the above few reasons, I never gave a thought to learning GUI programming, in any language. You don’t want to do something that is of no use to you, right? Maybe.

After been coding for sometime now, I gave a thought to why some people who are not very good programmers, succeed more than people who are great programmers. It was a thing that deserved a thought. After reading several success and failure stories on Medium and Quora, I was convinced that there is no lack of skill in any field on this planet. Take anything for example, like I thought about C++. The language I am getting better at everyday, people have been learning it from the past 30 years. Who am I challenging? It struck me that mastering some form of art (yes, programming is as much an art for me as astronomy) and creating something that people use, are not necessarily same sets. Though there is a large area of intersection, you can’t be sure that just being good at something will make you successful, whatever that word means here. It was good time for me to stop thinking about how good of a shot I am at programming, and start focusing on what the world actually needs that I can provide or produce, if at all I can.

That was the time I realized, CLIs are great, but if you want everyone to use your thing, you need to give them something they will love. You need to help them in a way that they are able to use the help. How did I expect everyone to love the CLI just because I think it is cool and looks all black and white (well, that’s what I think is cool).

Not everyone is a nerd. Not everyone has to be one. The world is so diverse. It is really satisfying to see an artist painting, a drummer performing and an athlete giving his best. It is this diversity, in us, the animals and the plants as well that makes our home, the Earth. We, geeks and nerds are no different. We love making stuff that work to our command. But we, like every other human present, also has the morale duty to help others with the stuff that excites us. Just as a painter sells his paintings, not only because he wants to earn from it, but also because he wants his art to spread, so that somewhere in a living room of some house, the hosts always get asked, ‘where did you get this masterpiece from?’.

There is a very different joy in seeing your creation being used. It is something different than doing what you love. Yes, it really is different. It brings the best out of you, a kind of motivation. I wanted to make something like that. I wanted to write GUIs. I took up learning it about a month ago, and I am kind of comfortable with Qt.

There are a lot of frameworks for writing GUIs, as anybody using a computer today can imagine. Plus, many high level languages provide APIs to write graphical applications within the language libraries, Java for instance. Still, having done some programming in C++, I had two basic options open in front of me, GTK+ and Qt. I choose Qt after reading some articles on Stackoverflow from users with similar dilemma. Qt is cool, lots of possibilities and support. Code is quite portable, and an important thing, I am enjoying it, which matters a lot, right?

If you wonder where am I right now with it, I am writing a GUI wrapper for the GNU’s dd utility which should make it simple for someone who’s just started using GNU/Linux to burn ISOs to disks, without the hassle of setting up a more than required complex tool or destroying the data trying to use dd from the command line by messing up the ‘if’ and ‘of’, for example.

Neat, huh? Haha. I will put it up once I finish it, but the important thing is, I could do it. The best part about being a programmer is, adapting is too easy. At least when beginning. And that is mandatory, given the ever changing world of Information Technology.

I’ll conclude this long post here. If you made it till here, then a big thank you. I feel it is hard to read what I write, because I tend to write my feeling, and mostly they don’t look the same on paper. Nevertheless, do tell me what you think about this article. Liked it, hated it, anything.

What programming isn’t

Uncategorized
There were days when I used to search the web for ‘best programming languages‘ and ‘most popular programming languages‘ in my free time. I was not able to decide myself what language to learn and invest my time upon, such that it would pay me back everything I put into it. This was really a hard task, given the fact that I have interest in a wide range of stuff related to computers, from algorithms to designing beautiful forms with CSS.
Given that I had no guidance from the people around me, since I had no one in my family from the technical field, and the college professors were not of much help either. Now that justifies my amateur-ish googling habits.
Leaving that aside, I have lately been asked a lot of times by my fellow mates, what is the ‘best language‘ to start with and what are the current ‘hot languages‘ in the market. To start with, there is no language that is ‘best’ in every sense. If there was, why would anyone bother creating additional languages in the first place, right? Languages are written and implemented with certain goals in mind, which it should satisfies better than what was present before creating that language, that’s the whole point about it. So stop searching for the best language and start looking for your own needs.
Secondly, I don’t think anybody should care about the ‘hot languages’ in the market, except for the tech magazines’ journalists. Why? Because if you haven’t heard of it yet, then you probably don’t actually need it yet. It is much better to know a single language as a whole, than to learn 5 languages just for the sake of them being ‘hot’.
If you are new to programming, then most probably you are taught programming using some or the other language (most probably C++ or Python). What most fail to teach is that programming is not equal to learning a language. Programming is the mindset that you develop when you are solving problem for a wide range of sub-problems by writing a common solution to all. Most of the times it means looking for a pattern in the chaos of that problem. You don’t need to know a language for finding this pattern, do you? You have to realize this thing at the earliest.
Programming language that you choose is the tool you choose for the task you have in hand. Now, depending upon the task, some tool might be better than the others, and help you in doing the task quicker. You can think of an analogy here, like if you want to cut tree trunks, you can use saw blade or maybe even a kitchen knife. But the saw will get the job done much faster. However, any sane human won’t cut vegetables using a saw. The same goes for programming languages. Different tasks demand different languages, and each has its own pros and cons. But the languages won’t help a bit if you cannot figure out the problem itself in the first place.
I had start to program in C, jumped to Python because ‘Google used it’. Then I came to PHP because I read somewhere that PHP gets you a job quickly. I started with JS and Node.js later due to their growing popularity. I did a lot of mistakes when I started it all. I wish I knew it then, that instead of wasting my time on learning the syntax of languages to do the exact same thing I did with the previous language, I could have been much better off learning some interesting algorithms that would’ve helped me in solving some tough hackathon problems.
So is the knowledge of language implementations not useful? Of course, I don’t mean that. A language is very useful once you know how to use it. You don’t have to know everything from a language. Just enough to get the problem solved. Nothing more. For example, you might have probably heard of C++. If you have ever tried to learn C++, you might have realized that it is a really large language. Originally designed for low level embedded programming and as a ‘C with Classes’, C++ has evolved to be a language that can be used in almost every domain. The ‘Standard Template Library’ is large enough for you to not miss anything in most of the cases, and even if you do, there is boost at your rescue. So do you think you most know all of the above to call yourself a C++ programmer? No. Many great programmers who use this language use just a subset of it and they are fine with it. I personally don’t use the object oriented facilities of the language much, but it doesn’t matter as long as it does what you want it to do. So don’t aim to know an entire language unless you want to get into compiler development or it’s standardization committee. Focus on the thing you are working on, and not the language you are using.
Have the enthusiasm to solve problems. Take pride in building things from the scratch, all by yourself. The love for programming comes in automatically. But most important of all, learn how to program and not how to write syntax of a particular language.
Thank you for reading.