Monday, June 23, 2014

Kiss-ass Principle

The steps to resolve a bug/error report can be broken down into 6 simple steps.
  1. Clarify the problem
  2. Implement temporary solution (if applicable)
  3. Find root cause of the problem
  4. Implement permanent solution
  5. Verify solution with user
  6. Implement preventive solution/action --make sure this problem doesn't repeat again
  7. Send out summary of lesson learned
A reckless programmer will only do at least 2 of the steps above and no more.
I don't like reckless programmers.

However when it comes to responding the bug/error report back to the user directly, I have a helpful format what I call 'Kiss-ass Principle'.
It is designed to make the user feel respected. And happy.
A happy user will support you in more ways than you can imagine.

Kiss-ass Principle can be plainly broken to roughly 7 steps.
  1. Acknowledge the user problem feedback and clarify -- "Thanks Sam, what/how/where/when you see that error?"
  2. Let them know when you are looking into this problem -- "OK, I am doing this shit currently but will look into this in 5 mins time" or "Ok, investigating now".
  3. Let them know you found the source of the problem -- "Ah I see the problem now. It is because of la la la la"
  4. Tell them when it will be fixed -- "This bug will be fixed in the next server update"
  5. Tell them it is fixed and request the user verify -- "OK, updated the server with the fix, can you try again"
  6. Reassure the user the problem is seriously taken care of -- "This is a shitty problem but it is fixed and should be fine from now on"
  7. Say sorry if you have to.

Saturday, February 01, 2014

Book review: Groovy 2 Cookbook

(Disclaimer: I got a copy of Groovy 2 Cookbook from Packt for review)

A good cookbook will help you learn something quickly, or guide you to solve a problem in simpler way. On both count this book has done a good job.

I find the 'Using Groovy Language features' chapter easy to follow and will be helpful for newbies to learn Groovy. However I think they missed out focused topics on Collections.

The chapter on Meta-programming and DSL is particularly helpful. I have learned new tricks on applying DSL in my day to day work.

The chapter on concurrent programming is decent but could be better with simpler examples. This is the chapter where it reads like a overview of what gpars can do for you but if you don't have a good grasp of concurrent programming with groovy then the examples can be confusing. I wouldn't recommend newcomers to learn gpars from this book and instead learn from the online doc directly.

Maybe it is the nature of Groovy where the language is already quite easy to read and understand -- this book can be seen as struggling to compete with the very concise and clear online documentation.

As somebody who has been programming with Groovy for many years, I would recommend this book to Java programmer who would like to get a good grip of Groovy language quickly. Otherwise this book offers little to seasoned Groovy programmers.

Thursday, November 07, 2013

Instant Handlebar.js book review

(Got a chance to review this book last week, and here is it)

Easy and very fast read
Good for developers who are looking to learn better JS template solution.
Also good for more in-depth information after reading various tutorial online.
The actual Handlebar.js is pretty good too so this short book is more like a introduction to the power of Handlebar.js before you dig into the official doc.

Monday, July 15, 2013

One thing you need to do to stop being sucky

Stop waiting for permission.

You don't need the company budget to get the X gadget that will increase productivity by Y-fold.

You don't need your boss to 'okay' to do that awesome thing.

You don't need to make your colleagues happy -- ship it or fuck off.

You don't have to be nice. It's optional. Get shits done.

You don't need permission from God to set out to change the world. Ask for blessing and forgiveness.
God loves you anyway.

You don't need permission.

Thursday, June 06, 2013

When sending e-mail

  1. If it's too long, break it down into list
  2. If it's a long instruction, break it down into steps
  3. Number your list 
  4. Keep it very short -- let's leave essay to schools
  5. At the end of e-mail, suggest/recommend/tell the reader what to do next
Now go send e-mail like a boss.

Sunday, June 02, 2013

Why we need the visionaries to save us (the nerds)

I met many young aspiring startup founders this weekends at AngelHack SG. I was impressed. I was also disturbed by the lack of visionary thinking among them.
Programmer nerds are by default, clever people. You need a certain level of intelligence to code shit. And you need visionaries. 

Need. It's not optional.

You can code the damn thing -- the algorithm, the SQL data mapping, CSS framework, angular-shit, and what not. You make it pretty and fast. And you proved that it works.

You, the awesome programmer is going to impress the judges and some of them will fall off their chairs.


No no. It is different when you are hacking in events like AngelHack. Unless you can complete the whole damn thing -- the best bang for bucks is the slides! But better make sure you can code the damn thing okay.

After 24 or 48 hours labor, you have to present to a panel of angels and investors that need to understand what you got for them.
You window of opportunity is very small. 
I mean, how long does it take you to pee? Well you got less time than that.

But I digress, the point is not about pitching in the shortest time possible. 
It is about making them see the value of your stuff.

Show is better than tell.

You got to show what you got -- not tell.
But if you only have the server running and you are showing them the logs flying everywhere, you get an F.

F for fail.

I know you are an awesome programmer, but if you don't have the chops to deliver your idea out to the world, you need a vision guy to do it for you.

The vision guy will sell your idea.
This vision guy will do the slides for you.
For you!

If you can't find any then maybe it's about time you learn how to be a visionary.

Start here.

Friday, April 12, 2013

Simplest solution to redirect Tomcat port 8080 to port 80

sudo iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

(Tested to work fine on Ubuntu 12.04, 12.10)