I decided to switch to Arch Linux at the beginning of this year. After much customization work, the end result looks like this

.

The screenshots received much interest from my friends. I am going to show you how to build it. Long story short, use the same color theme for your applications.

OS: Arch Linux

Obviously only Linux or BSD gives you this much freedom to customize your desktop. I'm using Arch Linux. Other distros should yield the same result. The advantage of using Arch Linux is it gives you a blank slate to work on. If you use all-in-one distros like Ubuntu, you would have the extra work of stripping out the desktop environment.

Color theme: Solarized

There're some very good color themes available. Here're some very good ones.

• Solarized
• Zenburn
• IR_Black

Choose one which you like. I'm using Solarized. Not all color themes are created equally. Popular themes have more tooling support. For Solarized, it has been ported to vim, mutt, shell, and emacs. It makes it easier to apply the same color theme to other applications.

Font: Inconsolata

As with color themes, font is very much a personal preference. Choose a good monospaced font to use for all your apps. I'm using the Inconsolata font.

There are other good recommendations here

Window manager: XMonad

I'm using XMonad. I wanted a tiling windows manager as I wanted to maximise my screen estate. I chose XMonad because of the way it handles windows on multi monitors. Each screen shows an independent workspace. I have control over which application should appear on which screen. For example, I can show a movie on my second monitor while switching workspaces only on the laptop screen. The movie does not get affected. OS X, Windows, Gnome, KDE treats both screens as a single workspace. Nothing wrong with that. But I had to manually move apps from screen to screen and do a lot of Alt-Tab window cycling. With XMonad, I no longer need to do that. I just switch workspaces. XMonad allows you to configure apps to automatically go to designated workspaces. You get the added advantage of knowing exactly where which app is.

This repository is very well documented. My config is almost a carbon copy of it.

Status bar: Xmobar

Xmobar works well with my Window Manager(Xmonad). Configuring it is very easy. You should be able to achieve the same result with dzen2 too. Dzen has more features though. Xmobar is a plain text status bar. Here's my .xmobarrc. . THe gmail checker is a simple hand written ruby script. The colors used are picked from the solarized theme.

Termainal emulator: urxvt

I'm using urxvt as my terminal emulator. urxvt is highly customizable. I don't think the default terminal emulators that come with Gnome, KDE offer the same room for customizability as urxvt. It should not be a problem to install urxvt in your distro though. Just apply the color theme to your terminal. And it should merge nicely into the environment.

Here is my config for urxvt

Text editor: Emacs

Be it Vim or Emacs, you can easily apply a color theme for it. There's the Solarized theme for Vim as well. Just follow the instructions and install the appropriate color theme for your text editor. For emacs, you need to use the color theme package. There's a separate solarized color theme package. Install it and it'll merge perfectly with the status bar.

OS integration

To take it further, I made my wallpaper integrate into the status bar. I also used dark themes for Chrome and Firefox. Similarly for web apps like Gmail, I try to use a dark theme to merge in with the desktop. This makes the entire computing experience very pleasing to the eye.

 

I've left sold.sg. Starting in Jan 2012, I'll be on my own as an independent developer. I'm not alone though. I'll be collaborating with Zhenyi(andadinosaur.com) for the near future. Expect to see new projects coming in the coming months. =)

SmugFTP is my side project. It has been out in the wild since this January. So its more than half a year now. Why did I build it? The reason is I find uploading painful. I wanted to scratch my own itch.

 

I signed up for Smugmug after my wedding. My wedding photos were precious. My wife and I wanted to share it with our friends and family. We wanted to back our photos up. We chose Smugmug. Everything was good. Except the uploading. An upload usually take many hours. It's common to leave you computer running overnight to complete the upload. The thing is, uploads fail. When it fails, it stops. So you have to check it periodically. If it fails, restart it. I actually felt a sense of relief and accomplishement once the uploads are complete. I wasn't happy with the web uploaders. The default uploader doesn't work. I chose the Java one. It felt clunky. The engineer in me knew that there'e got to be a better way to do this. So I went to the Smugmug wiki to find uploaders that others have written. Unfortunately there's none that look good. Feeling disappointed, I went to the Smugmug user voice page. And there it was, a suggestion for FTP uploading. I wanted FTP. I voted. That was when I thought to myself, FTP is not too hard to build, why can't I build it?

 

And so I started building it. Smugmug had an API. After doing a little research, I knew FTP to Smugmug is possible. And not too hard too. The first beta release was out in a month. Immediately, there's interest from other users. Slowly, word spreaded and the project grew. It was until after 6 months or so that I felt that SmugFTP is finally stable. 

 

There're several things I learnt

 

1. Testing is very important. Try to make the tests as similar as the actual environment

 

2. Don't be ashamed to release a buggy product. SmugFTP was buggy for a good 6 months. It caused many users inconveniences. But they still forgave me. 

 

3. Be nice to your users. If you're nice, people reciprocate. I always apologised for failed uploads in the early days. And I went out of the way to fix the mess that the bugs created. All of them appreaciate it. And I had a fantastic relationship with some of my users as a result of that. 

 

4. Solve a real problem. If you're solving a painful problem, users will find you. They will stick with you, forgive you and spread word for you. I find too many people are building stuff that do not solve actual problems.

 

5. Development always take longer than you think. The production environment always have surprises for you. 

I'm one of those who have tried both Vim and Emacs. I've always wanted to write a post to share my experiences on these 2 venerable text editors. Right now, my primry editor is Emacs. Not to say Vim is not good, but for Emacs fits my setup better. I'm typing this article on Emacs if you're curious.

First a little history. I started with Vim first. Once I got through the steep learning curve, it felt fast. I was typing faster. Vim made me saw how inefficient I was earlier. From time to time, I will see articles or comments that mention Emacs. My curiosity grew. I started trying out Emacs. When I started learning it, I forced myself to use only emacs for a week. After that week, I was able to memorise most of the basic key strokes. So after about 2 years of using Emacs, I think its the right time to summarise my opinions.

Comparing the both of them is not fair. They have a different design philosophy. When we use Vim, the mindset is 'I want to type in the shortest time, and in as few keystrokes possible'. When we use Emacs, the mindset is 'I want to use Emacs for everything'.

Key Bindings

Vim keybindings are economical. But it can be cryptic. It is designed for the fingers. Emacs is designed for the brain. Key bindings can be executed through the minor modes which maps directly to an english phrase. Like 'comment-region', 'replace-string'. For Vim that would be "+gp'. As you can see, you are unable to guess just by reading what a Vim command can do.

Placement of key bindings

A good example of the difference in philosphy is the movement buttons. Vim places them in a line, right next to each other(GHJK). Emacs use C-n, C-p, C-f, C-b. It maps to next, previous, forward and back. Vim designs for the fingers. Emacs design for the brain. For emacs you won't have to memorise as much, but your fingers suffer from stretching.

Another good thing about emacs is there're other software that correlates their default key bindings with emacs. screen, tmux, zsh, etc has very similar keybindings to emacs. It shortend the learning curve considerably.

Window management

The killer feature that made Emacs my primary editor is the window management. Emacs allows me to have multiple frames. All the frames have access to the same buffers. This allows me to switch my buffers freely between the frames. That is very helpful if you use multi monitors. I cannot replicate the same behaviour with Vim. I'm stuck with the same buffers per Vim instance.

Otherwise, both editors are about equal when it comes to customizability and functions. For me, the above are the more obvious differences

Here's a simple way to add rvm to your zsh prompt. I think it should work for bash too. It'll only show when rvm is in use. And here's how it looks. [URL=http://img252.imageshack.us/i/rvmzshprompt.png/][IMG]http://img252.imageshack.us/img252/1047/rvmzshprompt.png[/IMG][/URL]

When you need to test for blank elements on Culerity, it is better to parse the html. Using Celerity helper methods such as $browser.button will return a Culerity::RemoteObjectProxy object. It does not tell you if it found an element or not. It is a limitation of Culerity. To work around it try this: You can use the above code in the step definitions.

While preparing for a presentation on Scala, I added some jokes on the functional languages. Here's the original version and the new editions Erlang You create a dozen clones of youself, pass the gun to one another in turn to shoot at each other's foot Python You have to align your foot 10 steps below the gun for it to work Ruby You pull the trigger to find popcorns popping out of the gun. Someone somewhere has just made all guns shoot popcorns. Haskell Close your eyes and picture a gun in your mind. Think about the foot being shot. Open your eyes. You found your foot shot. No sound. No smell. No one else even noticed. Scala You pull the trigger and you got shot. You stab your foot with the gun and you got shot.

Ruby facets has a lot of useful libraries. Sometimes you only want to load the ones that you need. Here's a little snippet that you can use Rails won't load facets as the 'lib' param is false. We then load the libraries manually through initializers. This helps when facets unwittingly clobbers some of the other gems you are using.

Here're the code to test the content of the pdfs. But first you need the pdf-reader gem. The feature file is above. Add the code above as a helper file. And lastly, the steps. Remember to add a @pdf tag to your feature files.

I was using thoughtbot's paperclip to attach files. I realised that paperclip only provide shoulda macros for test::unit. No cucumber macros? In the end, I got to write it. Its very simple. The feature is shown here: Define your steps: As celerity does not have an attach_file method, I got to write my own. You could see it's not hard at all. Remember to define the browser variable. Last, we have some hooks to clean up the test upload files. Remember to place an @upload tag in your scenario.