Code FTW

Code like you have anterograde amnesia

2015-09-09T17:28:00.000-07:00

There is this advice around about how we should write our code:

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

I wonder if it can be written as "always code as if you have anterograde amnesia" instead.

Anterograde amnesia the inability to form new memories after the moment that caused the amnesia. H.M. is the famous case that you should have encountered if you're into psychology. You can also watch movies like Memento. Or you know, from first-hand experience, that night when you drank so much you didn't remember what happened?

In programing, the moment the amnesia sets in should the moment just before we start writing the code. It does have some truth to it because just a a month later, we'll only remember very little.

What would you do? What would be different? It seems like the end result is the same, but while a violent psychopath doesn't give guidelines about what you should do, anterograde amnesia reminds you that you're going to forget everything and that you need to do something about it.

How should code be written so that you'll still be able to understand it later? You have to keep your code simple, easy to understand, and if something is abnormal, it has to be documented.

You'll keep your version control history clean, make sure your commit messages explain the change well, and that your commits are atomic. This will help tremendously when you're trying to find out the context about a line of code using git blame.

You'll also link to references whenever you can. Did you copy a code from blog or gist or elsewhere? Paste the URL so that other programmers can look at the original source and understand what it is about.

You'll use design patterns (when it makes sense), follow conventions, and as I wrote previously, it's pretty much just following programming best practices.

Steve McConnell summarize it best on Code Complete:

The bottom line is that programmers who compensate for inherent human limitations write code that's easier for themselves and others to understand and that has fewer errors.

One of those inherent human limitations is that we'll forget. It's a real thing that I'm sure you have experienced, unless… maybe if you have hyperthymesia… Well, enough psychology for today!

Learning the fundamentals

2015-01-06T10:59:00.001-08:00

I notice that some programmers jump straight away to the more advanced concepts while still lacking the fundamental knowledge. For example, not understanding the principles object-oriented design, but readily applying design patterns everywhere.

The trouble with this is that you don't know if the design pattern you're using is appropriate for the problem because you don't know the trade off involved with that pattern versus other patterns. And worse, some apply design patterns before even understanding what the problem is.

Even to do object-oriented design well, you need to understand the concepts of modularization, isolation, cohesion, coupling, etc. Those basic design principles apply not only to program design, but also pretty much all complex things, like mobile phones, nuclear power plants, rockets, etc.

When you jump to patterns immediately, it's like using a chainsaw before learning how to use a hand saw. A chainsaw is powerful and may get your work done sooner, but it is not for all situations and it is more dangerous. You need to understand the situation and learn when is a good time to use one instead of the other. If you are a beginner, it is recommended that you stick with a hand saw. Yes, it will be inefficient, but it's much better than losing limbs.

I think this tendency to jump to advanced concepts is because the programming community tends to be filled with experienced programmers. So they talk about advanced concepts because those are the interesting things to talk about.

This gives a distorted view of the world for beginners. They think those are the most important things. Just like you don't see racing drivers talk about how to change lane safely, you don't see experienced programmers talk about the basic stuff. They'll talk about NoSQL instead of relational database, actor model and software transactional memory instead of inconsistent read, deadlock and starvation. It's assumed that everyone knows about the basics.

But fundamentals are the most important thing, even for a super engineer like Elon Musk:

One bit of advice: it is important to view knowledge as sort of a semantic tree -- make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the leaves/details or there is nothing for them to hang on to.

So if you're new into programming or feel that you're missing the fundamentals, do brush up on those. I highly recommend that you start with Code Complete.

Don't make members of your team compete among themselves

2014-12-31T10:26:00.002-08:00

I couldn't believe myself when I read that Marissa Meyer, who I used to greatly admire (until today), implemented a competitive performance review system at Yahoo:

Mayer also favored a system of quarterly performance reviews, or Q.P.R.s, that required every Yahoo employee, on every team, be ranked from 1 to 5. The system was meant to encourage hard work and weed out underperformers, but it soon produced the exact opposite. Because only so many 4s and 5s could be allotted, talented people no longer wanted to work together; strategic goals were sacrificed, as employees did not want to change projects and leave themselves open to a lower score.

That is exactly the stack ranking used by Microsoft, which worked so badly they had to drop it:

At the center of the cultural problems was a management system called “stack ranking.” Every current and former Microsoft employee I interviewed—every one—cited stack ranking as the most destructive process inside of Microsoft, something that drove out untold numbers of employees. The system—also referred to as “the performance model,” “the bell curve,” or just “the employee review”—has, with certain variations over the years, worked like this: every unit was forced to declare a certain percentage of employees as top performers, then good performers, then average, then below average, then poor.

“If you were on a team of 10 people, you walked in the first day knowing that, no matter how good everyone was, two people were going to get a great review, seven were going to get mediocre reviews, and one was going to get a terrible review,” said a former software developer. “It leads to employees focusing on competing with each other rather than competing with other companies.”

And chapter 25 of Peopleware, the classic management book, is dedicated to it:

Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal.

Always use tmux on SSH with Bash completion

2014-06-02T11:46:00.000-07:00

Why use tmux on SSH? Because sometimes you get disconnected and if you're running something, that process would get killed. tmux also seems to come already installed with Ubuntu servers, so there's no need to do anything on the server.

Why make this into a command? Because unless it's easy to use, it's hard to turn it into a habit.

Here is how you can create a command to always start tmux on SSH. Just add the following to ~/.bashrc.

function tsh() {
local SESSION_NAME=$(whoami)
ssh $* -t 'tmux a -t '$SESSION_NAME' || tmux new-session -s '$SESSION_NAME' || /bin/bash --login'
}

It will always attach to existing tmux session with the same name as your local username or create it if not available. The reason for using the same session name as your local username is so that you don't end up in someone else's tmux session. Of course this is assuming that your username is unique. Otherwise, just modify the SESSION_NAME variable to make it unique for you. For example:

local SESSION_NAME=$(whoami)MyUniqueString

I'm also used to use Bash completion instead of typing my server's host information. For that to work, the info has to be added to ~/.ssh/config. For example:

Host example.com
HostName example.com
User foobar

You'd also need to have bash-completion package installed. Here's how:

# Ubuntu

sudo apt-get install bash-completion

# Mac with Homebrew

brew install bash-completion

Now we need to allow tsh to be auto-completed. Just add this line to .bashrc:

complete -F _ssh tsh

And there you go! All you need to do now is just type

tsh ex⇥

and you'd get:

tsh example.com

Credit to this post for the inspiration: https://coderwall.com/p/powgbg.

No more slow key repeat on Mac

2013-08-06T12:53:00.001-07:00

As someone coming from Ubuntu, Mac has a slow keyboard repeat rate that makes moving your cursor to somewhere else more time consuming. It's not a big problem in Vim and you can use Vi-mode in your terminal, but sometimes it's faster to just move the cursor like a caveman.

Well, that's until I discover the Key Repeat option in KeyRemap4MacBook:

Viewing image from Vim's NERD Tree on Mac

2013-07-11T20:00:00.000-07:00

While in our text editing glory, wanting to see an image in our project can break our flow since that means we get out of our editor and use other application to see the image.

That's not a problem if you are using NERD Tree on Mac. Follow these steps.

1. Navigate to the image on NERD Tree.

2. Press m and then q.

3. Press Command-W to close the preview.

Recipe: rename long filename in *nix

2012-05-02T03:22:00.000-07:00

Want to rename a file with long path?

mv /super/long/path/to/filex /super/long/path/to/file_x
mv /super/long/path/to/filex /super/long/path/to/filey

Why? Brace expansion to the rescue.

mv /super/long/path/to/file{,_}x
mv /super/long/path/to/file{x,y}

Recipe: rename file extension in a directory recursively in *nix

2012-04-18T08:15:00.001-07:00

Rename file extension in a directory recursively, for example, from *.rhtml to *.html.erb:

find . -name "*.rhtml" -exec rename 's/(.*)\.rhtml/$1\.html.erb/' {} \;

I've just learned more about find. It leveled up my Unix ninja skill quite tremendously.

A deeply felt but undefined goal in mind

2012-04-09T09:47:00.000-07:00

Whereas a conventional artist starts painting a canvas knowing what she wants to paint, and holds to her original intention until the work is finished, an original artist with equal technical training commences with a deeply felt but undefined goal in mind, keeps modifying the picture in response to the unexpected colors and shapes emerging on the canvas, and ends up with a finished work that is responsive to her inner feelings, knows what she likes and does not like, and pays attention to what is happening on the canvas, a good painting is bound to emerge. On the other hand, if she holds on to a preconceived notion of what the painting should look like, without responding to the possibilities suggested by the forms developing before her, the painting is likely to be trite. (Mihaly Csikszentmihalyi - Flow)

For problems with a lot of unknowns, sometimes it's good to just start writing the code. You'll then see the patterns of what are always the same and what are different. You can then extract the parts that are the same into methods or classes, essentially refactoring it.

This is to be contrasted with a problem where upfront design is almost a necessity for good design. I think database schema and model design are a good example. If you have a lot of unknowns in designing those, either your requirement spec is not detailed enough or you don't know what you're doing.

Capistrano: Host key verification failed

2011-12-03T16:58:00.001-08:00

If you ever encountered the error message below when deploying using Capistrano, here's a solution for you.

 ** [12.12.12.12 :: err] Host key verification failed.
 ** [12.12.12.12 :: err] fatal: The remote end hung up unexpectedly
 ** [12.12.12.12 :: err] fetch-pack from 'git@github.com:abc/xyz.git' failed.

This seems to mean that the RSA key fingerprint needs to be verified (I'm not 100% sure on this). My solution was to do git clone on the server and confirm the fingerprint prompt, but there is a better approach. You can also do ssh git@github.com and confirm the prompt.

Creating Rails project from a local checkout of Rails repository

2011-08-25T04:14:00.000-07:00

For my forgetful brain:

ruby /rails_repo/bin/rails new projectname --dev

Superstitious programming

2011-08-15T06:43:00.001-07:00

Some programmers tend to think that something causes a problem without examining it further and confirming it. Then they just "fix" it or work around it, blaming it on the suspected cause.

For example, you're using an external library and you found that things went haywire. There are possible causes to this. First, the library causes it. How likely is it? You can look at the number of users (in other word, popularity) of the library. The more users, the less likely that it is the library's problem. Of course there's a remote possibility of you discovering a rare bug. But more likely, perhaps you're just not using the library right.

Here's a way of thinking that is also applicable in real life. Always check your assumption. Ensure that when you think something is causing the other, that it really is the case. Remove or change the cause and see if the effect changes or disappears. Only when you have that correlation that you can confidently say, "Yes, that's really the cause."

Having a knowledge of the scientific method will help greatly when doing this, and as a bonus, also when navigating life generally.

"Assumptions that aren't based on well-established facts are the bane of all projects." (from The Pragmatic Programmer by Andrew Hunt and David Thomas)

"One of the biggest differences between hobbyists and professional programmers is the difference that grows out of superstition into understanding." (from Code Complete, Second Edition by Steve McConnell)

The promise of chef, fulfilled

2010-09-24T08:08:00.000-07:00

After using chef (a system configuration management) for more than a year, it is finally a working solution for me. The first time it ran from scratch without a hitch, it was quite a strange experience. Wait a second, everything works? It's magic!

It probably came about because it was run on Ubuntu Lucid, which is an LTS release and probably better supported by the cookbooks. Turned out the old cookbooks I was using were not up to task to deal with Lucid. So I might as well update it to the latest version and deal with many broken things, which required a lot of head scratching and whatever else needed scratching.

I still don't get the hang of the whole thing about the similar but different variables usage like node, params, and others (nor do I really care, it's not that important), but it works beautifully and that's good enough.

It's critical but please get it done as cheap as IMpossible

2010-03-20T21:13:00.005-07:00

A nice quote to ~~shove~~ show to people that want softwares to be cheaply done:

What always amazes me is the companies who consider such a piece of software to be "critical" to their company -- but then try to get it done as cheaply as possible. (Chances are that more money was spent on the bathroom facilities in your office than you want to spend developing this program... yet your business success/failure hinges on whether this program is done correctly. Does that sound insane or what? I mean you have 5 employees, and EACH of those employees will cost you MULTIPLE TIMES MORE in a single year than you want/expect to spend developing this critical application -- an application that once completed, could easily make your employees much more efficient & your firm more productive, OR which alternately could cause needless frustration and even reduce their efficiency and productivity.)

The answer is it doesn't work. Those who offer low price are just bidding for any jobs, even the impossible (a very hard and so far unsolved problem quoted for $300-$1000) or ridiculous ones (a clone of eBay for under $500). The old adage still stands, price is a good indicator of goods.

Now, how do you find the excellent companies or programmers? That's a different ball game. Maybe on the next article, maybe.

How people use Google Maps

2010-03-17T07:51:00.003-07:00

Watching people press the arrow buttons on Google Maps is painful, but that's the state of most Internet users. Watch around 15:30.

The funny thing is that the usability advices given in this video are not applied on the site itself.

Tomorrow would be better

2010-01-27T19:40:00.004-08:00

A quote from Sergey Brin taken from Seth Godin's The Dip:

We knew that Google was going to get better every single day as we worked on it, and we knew that sooner or later, everyone was going to try it. So our feeling was that the later you tried it, the better it was for us because we'd make a better impression with better technology. So we were never in a big hurry to get you to use it today. Tomorrow would be better.

Doesn't mean that you'll never ship it!

Auto reload Rails plugin

2010-01-15T03:12:00.003-08:00

One day we all need to quickly get that plugin to work our way. But plugin development can be painful with restarting the server all the time.

Here is how to reload Rails plugin on every request on Rails 2.3.

Add "config.reload_plugins = true" on config/environment.rb. It has to be there, you can't put it on config/environments/development.rb due to the Rails start up steps. You may add "if RAILS_ENV = 'development'" instead.
```
  # config/environment.rb
  config.reload_plugins = true
```

On the plugin's init.rb, add the following line:


  # init.rb
  ActiveSupport::Dependencies.explicitly_unloadable_constants = 'YourPluginModuleName'

That's all. Don't forget to remove it when you're done.

Defining milestones

2010-01-04T07:07:00.004-08:00

Apparently my brain can remember the gist quite well while forgetting the source. Before I forget again:

For picking the milestones there is only one relevant rule. Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Coding, for a counterexample, is "90 percent finished" for half of the total coding time. Debugging is "99 percent complete" most of the time. "Planning complete" is an event one can proclaim almost at will.

Concrete milestones on the other hand, are 100-percent events. "Specifications signed by architects and implementers," "source coding 100 percent complete, keypunched, entered into disk library", "debugged version passes all test cases". These concrete milestones demark the vague phases of planning, coding, debugging. (Fred Brooks - The Mythical Man-Month: Essays on Software Engineering)

Uploadify "406 Not Acceptable" error with Rails

2009-12-31T00:16:00.004-08:00

To some poor souls out there, if you encounter "406 Not Acceptable" error when uploading file with Uploadify on IE, Firefox, or Chrome on Windows, you may want to remove or replace the respond_to block, if you can.

From what I can figure out, those Windows browsers send text/* as the HTTP_ACCEPT header, while on Linux, it sends */*. I suspect this is caused by different behavior of Flash on different OS and the header from Windows is considered invalid by Rails.

Reading obscure texts

2009-12-28T19:32:00.003-08:00

I've just read Zed Shaw's The Master, The Expert, The Programmer. Talk about the obscure Go Rin No Sho (The Book of Five Rings) by Miyamoto Musashi, I'm thinking that maybe it's good to read those obscure texts like The Art of War or Zen koans. They're supposedly full of wisdom, but we don't understand them. We simply don't because we've lost the context (in the case of Go Rin No Sho and The Art of War) or it's intentionally created to be non rational like the Zen koans.

It may be able to train your creativity, flexing those neuron connections, making you think outside of your daily thoughts and peering deep into yourself. And since it's obscure, the answer you get is most likely something inside you which you probably have never known.

How to find character encoding of a text file

2009-07-01T23:42:00.008-07:00

Is it UTF8, ISO-8859-1, or UTF16-LE? How do you know which encoding a text file uses?

Unfortunately, it's not so easy to find out. Unicode has been around for more than 15 years and there is one program called Excel that still exports CSV files in its own fancy ISO-8859-1 (Latin-1) encoding that is bound to mess up pretty much anything if you have some characters not in the US keyboard. But of course you didn't know what encoding the CSV file is in, even after almost pulling your hairs off googling for answer.

So, why bother about encoding? It's because my program can't read it if it's not converted to UTF-8. After trying many text editors hoping that it has a feature to show the current encoding, it finally dawned on me that there is this thing called Firefox which seems to recognize a file's character encoding.

Here's how to do it. Open the file in Firefox by selecting File on the menu bar, the choose Open File… and choose the file you want to open. Once the file is opened, go to View on the menu bar, and then choose Character Encoding. The selected one should be the encoding of the text file.

Standalone autotest with Rspec 1.2.0

2009-04-18T05:35:00.013-07:00

If you're looking for how to do autotest with Rspec for standalone project, you might end up with this old article from 2007. But sadly, it doesn't work anymore with the latest Rspec (1.2.0).

After angrily scratching your head for why it doesn't work, you might dive into the source code and eventually solved the problem by writing some code. Then you found out that it's already supported by Rspec, no extra code required and you wondered why you didn't think of that. After all, if the problem seems common enough, somebody must have solved it. (Replace you with I)

And how do you do it? Let's dive in.

Install Rspec and ZenTest.


  gem install rspec
  gem install ZenTest

Set up Rspec.
Create spec folder at your project root and put your spec files inside.
Run autospec.
Type autospec at your project root and it's done. I thought it's autotest and ended up wasting time figuring out why it doesn't work.

That's basically all, but there is more.

Adding color and other spec options

Just create spec.opts file inside spec directory. Fill it with some options, for example:


--color
--reverse

You can see the list of options available by executing spec --help.

Scan spec files within subdirectories

For one, the default behavior only scans spec files inside spec directory non-recursively. So if you like to organize your spec better, you're out of luck. But here is how to do it. In .autotest file in your project root, add the following code:


module Autotest::RspecMod
  Autotest.add_hook :initialize do |autotest|
    # Map to all "*_spec.rb" files inside spec and its sub directory.
    regexp = %r%^lib/(.*)\.rb$%

    autotest.remove_mapping(regexp)
    autotest.add_mapping(regexp) do |filename, m|
      autotest.files_matching(%r%^spec/.*#{m[1]}_spec.rb$%)
    end
  end
end

Pop up notification on Ubuntu

If you're on Ubuntu, you can follow these steps to have pop up notification when the test is finished. First, make sure you have libnotify-bin by running:

sudo apt-get install libnotify-bin

Then add the code below in .autotest.


require 'autotest/redgreen'

module Autotest::GnomeNotify
  # Time notification will be displayed before disappearing automatically.
  EXPIRATION_IN_SECONDS = 3
  ERROR_ICON = 'gtk-dialog-error'
  PENDING_ICON = 'gtk-dialog-warning'
  SUCCESS_ICON = 'gtk-dialog-info'

  # Convenience method to send an error notification message
  #
  # [title]         Notification message title.
  # [message]       Core message for the notification.
  # [icon]          An icon filename or stock icon to display.
  # [urgency]       The urgency level (low, normal, critical).
  # [time]          The timeout in milliseconds at which to expire the notification.
  def self.notify(title, message, icon, urgency='low', time=(EXPIRATION_IN_SECONDS * 1000))
    `notify-send -i #{icon} -u #{urgency} -t #{time} '#{title}' '#{message}'`
  end

  Autotest.add_hook :ran_command do |autotest|
    results = [autotest.results].flatten.join("\n")
    output = results.slice(/(\d+)\s+examples?,\s*(\d+)\s+failures?(,\s*(\d+)\s+pending)?/)

    if output  =~ /[1-9]\d*\spending?/
      notify 'PENDING:', "#{output}", PENDING_ICON, 'normal', 5000
    elsif output =~ /0 failures/
      notify 'PASS:', "#{output}", SUCCESS_ICON
    else
      notify 'FAIL:', "#{output}", ERROR_ICON, 'critical', 10000
    end
  end
end

The Genius of SMRT

2009-03-29T21:02:00.006-07:00

Here is an example of why you need to think.

Long time ago, there used to be a drawing that showed how long it took to travel from one station to another by Singapore's MRT.

This is how it looks like:

And there is a newer version, which looks like this one below:

Using both maps, tell me how long do I need to go from Bukit Gombak to Woodlands? Now you know that the newer version simply serves no purpose whatsoever to help people other than the fact that the timing seems to be updated and more current.

That, is the genius of non thinking.

The original document is still available on here though I can't find it linked from anywhere in the site. And there is a fancier, overkill one from TransitLink.

Delicious screws it up, again

2009-03-25T20:19:00.004-07:00

So one mistake in the past is not enough.

Now the Delicious toolbar is as clean as toilet water, annoying, but still can live with it. And guess what, the Awesome Bar is screwed too.

And the worst thing is, I can't downgrade! It kept coming up with "Invalid file hash" error. Great!

I'm talking about the Firefox add-on, version 2.1.032.

Update: Managed to downgrade to 2.1.018 and it works perfectly.

Why bureaucracy

2009-03-06T05:01:00.004-08:00

... the purpose of bureaucracy is to compensate for incompetence and lack of discipline — a problem that largely goes away if you have the right people in the first place. (GOOD TO GREAT - Jim Collins)

I've never thought of it that way but it makes a lot of sense. Bureaucracy seemed to me like something that naturally evolves to manage people, especially many people. And now I know the why.