Summer 2013

There isn’t exactly a summer over here, but it’s just simpler to call it that. So, the long awaited summer holidays are already here, and it can only go two ways:

  1. Do nonsense
  2. Do useful stuff

Now, number 2 is obviously the the preferred option, but it is kind of vague. So I made a plan, now I’m a man with a plan:

Badly drawn mind map

Badly drawn mind map

I classified the useful stuff that I can do into two broad categories: Self and Others.

Self is well, about myself. My mind, heart, body. Others has to do with, surprise, other people! And those people are my family and friends. The idea behind this plan is self-improvement, without disregarding the relationships I have with people and also my social life. Notice that there is a bit of an overlap between Heart (which has to do with Self), and Others. Which I feel is natural. This actually brings to mind a Chinese proverb along the lines of

“Train yourself, grow a family, rule the country, make world peace”*

You need to start working on yourself, before you can move on to bigger things.

I identified numerous activities I can do to achieve my goals, but since I have only ~90 days, I narrowed it down to these five:

  • Orbital (Mind: consolidating knowledge)
  • Design (Mind: acquiring new knowledge, exploration)
  • Basketball (Body: health and fitness)
  • Family dinners (Heart: kinship)
  • Orientation camps (Heart: friendship, social life)

For ease of remembering, I formulated the acronym DOFOB. It is meant to be pronounced like DAFUQ, but just with DOFOB. Anyway, 5 goals, 90 days; I think I can manage.

* That’s an absolutely horrible translation, but I hope you get the idea. Start from yourself, then slowly effect change in the bigger picture.

Some quick guidelines to Clean Code

I recently read Clean Code by Robert C. Martin, and here is a very summarized compilation of tips/principles that I understoo or found useful.

Naming

Names should convey correct meaning. (descriptive and correct)
Names should be pronounceable.
Names should be searchable.

Functions

Functions should be small, < 10 lines.
Functions should do one thing and do it well.
A function that takes 2 parameter is good. A function that takes 1 is better. A function that takes 0 is best.
Avoid flag arguments (i.e. Boolean values), it shows that a function does >1 thing.
Functions should not have side effects (i.e. do things other than stated in its name).

Comments

Avoid comments if possible, your code should be explanatory.
Good comments: explaining intent, clarification of obscure parts, amplification of seemingly unimportant parts, TODO, warnings.
Bad comments: redundant, misleading, journal.

Formatting

Small files are easier to understand than big files.
Newspaper metaphor: Headline -> Quick summary/Gist -> Details.
Use blank lines to separate different concepts.
Code that is related should be close together e.g. variable declarations in a loop.
Use white space between words to emphasize relation.
There are no laws for indentation, just set rules within the team and stick to them.

Objects and Data Structures

Objects hide data behind abstractions and expose functions that operate on the data.
Data Structures are containers for data and have no meaningful functions.
Avoid train wrecks (i.e. someThing().anotherThing().lastThing().orIsIt()).

Errors

Use exceptions instead of return codes, this enables separation of error checking and function logic.
Write try-catch statements first (in line with TDD).
Write Unit Tests.
Three laws of TDD:
1 – You may not write production code until you have written a failin test.
2 – You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
3 – You may not write more production code than is sufficient to pass the currently failing test.
Tests, like your production code, should be clean.
Single concept per test.

Classes

Classes should be small, just like functions.
Single Responsibility Principle (SRP), a class or module should have one, and only one, reason to change.
Classes should be open for change.

Good Designs (Rules by Kent Beck)

1 – Runs all the test
2 – Contains no duplication
3 – Expresses the intent of the programmer
4 – Minimizes the number of classs and methods

Successive Refinement

Quickview for YouTube

-UPDATE- My first user review on Chrome Web Store 😀

5-stars yay!

5-stars yay!

I released Quickview for Youtube on the Chrome Web Store last right, it was a really exciting 30 mins.

Beads of sweat trickling down my faces as I waited in anticipation for the zip file complete uploading, cursor hovering above the “Pubish now” button, as if I need to click it before it disappears suddenly. “Completed.” Within a split second I pressed my mouse left button as hard as I could and then it was live, on the Chrome Web Store. I would get millions of users and everyone would love what I did. But first let me see if it works. Bam. Reality strikes hard. I uploaded a wrong version. “Take it down, take it down” I told myself as I maneuvered what seemed like a labyrinth of links to finally reach the console where I could remove it. No way I was going to ship something that broken. Within minutes, things have turned out well.

Perhaps things weren’t that dramatic but it really was a unnerving experience publishing my first Chrome extension. But that night I did so, friends told me they are using it, liked it, and shared it with their friends. So I’m very happy they found it useful.

From a technical perspective, this extension is definitely not difficult. I had to learn bits about DOM, constantly refer to the jQuery API, check out Web Platform and the MDN; and I’m really glad there are so many great resources for anyone interested. I recently read a book called Clean Code by Robert C. Martin, and I wanted to apply some principles I learned, such as proper meaningful naming, and simple do one thing functions. It is not as DRY as I like it to be, so there’s lots of room for improvement.  While building Quickview, I had moments where I needed to decide which was the better way to do things. Here I learned something about trade-offs, such as clever-looking code v.s. maintainability.

I have a long way to go, but Quickview is definitely a small step, and hopefully in the right direction.

PS. Quickview is open-source.