Github Longest Streak...60 days and counting!

I had wondered for a while what is that grid of boxes on Github profile and what is the use of it until I read 177 days of Github. Just about the same period, I read How To Stay Focused When You Get Bored Working Toward Your Goals and How to Stop Procrastinating on Your Goals by Using the “Seinfeld Strategy”.  In short, they are all about habits.

But if you look at the people who are consistently achieving their goals, you start to realize that it’s not the events or the results that make them different. It’s their commitment to the process. They fall in love with the daily practice, not the individual event.

In the blog post, he tells the story of a successful comedian who had written a joke every day for many years. He kept doing it. He didn't want to break the chain.

I was really motivated by those blogs and started a mission. I decide to write some code every day and push them to Github. Do it as a daily exercise. Keep doing it every day and don't break the chain.

I created a few projects to work on such as grunt-protractor-runner and WhatNext.  At that time, I also had to practice my skill for upcoming coding interview. I chose to solve some problems on Project Euler every day and pushed my solutions to Github. I have solved 38 problems. :D

These projects gives me enough amount of work to do every day. After I had done for a few weeks, I started to be afraid of breaking this chain. The deadline time for each day is at 2PM in my timezone. When I got it done for the day, I felt relieved haha. Some days I have to sleep late just to solve a problem on Project Euler because I cannot do it the day after.

And now I did it. Today is the 60th day!!

I have done it for 60 consecutive days and I hope I can do it more. Let's see how far I can go. :)

WhatNext: My first android application on Google Play

I just published my first Android application on Google Play.

The application name is WhatNext. It is a simple tool to help you do "single tasking". The idea comes the first time when I played nodejs, tried to wrap my brain around its single-threading and event-driven model. Then I started thinking about applying this idea to how I handle things before I found out that people outside technology circle calls it "single tasking". There are a couple articles about this concept as listed below

• single-tasking and productivity
• Why Single-Tasking Makes You Smarter
• Multitasking is Out, Single Tasking is In

I'm usually overwhelmed with a pile of long-standing tasks in my long todo list and my energy always get drained upfront and then I procrastinate.

I've been wanting to develop this idea into android application for a while but I procrastinated. :-/

Finally, I started developing it 2-3 weeks ago with an idea to keep it simple, focused and effective. I also want to keep iterating, gradually improving and release the application early and often. I try to ship it as soon as possible.

Another goal is to learn Android application development and its components which I think I'm really late to the area. The best way to learn new technology is learning by doing. Although I tried to ship the first version as soon as I can, my habits still keep me reading all the things upfront before coding the first line.

Now I understand why people often say that developing a good Android application is difficult and takes much time. After I have read Android documentation and guides and watched some I/O talks, I see that Android is quite big in term of platform. There are many components, concepts and design patterns. I just read about 15% of them. These patterns and concepts enable very much flexibility and extensibility and force some good practices and design but, on the other hand, it is difficult to get it right the first time for developers.

The project is really young and I open source here.  If you want to try the app, get it on Google Play. The application supports only >= 4.x by intention and only tested with my Galaxy Nexus.

Enjoy! :D

My first experience maintaining a project on Github

A month ago, I started playing AngularJS and tried setting up a working dev/testing build environment. To do E2E testing with Angular app, they recommend newly test framework called protractor. I jumped to it and it happened that there was no usable Grunt task to run protractor in the build process yet. So I spent a night creating a small grunt task for myself and published it to npm registry.

A couple days later, I got the first issue in Github which is "can't run". Haha. After I had eagerly investigated, I didn't know what is the problem and the issue still hasn't been resolved until now. :-/ 

A few days later, I got the first pull request to add new option to the task. I was quite surprised and excited. I eagerly worked with him and merged it quickly because I know how it feel when you want your pull request to be merged as soon as possible especially a npm module. 

I was more surprised that I got an issue or pull request almost every day after that. I felt really great and tried to clear these issues and merge these pull requests as fast as possible. 

The last surprise is that it has been downloaded for 1426 times in the last month! :D

A week with xmonad

Last weekend I read about xmonad at Liang Zan's blog and I think I have never used tiling window manager. I was using GNOME Shell and it freezes sometimes. So I give xmonad a try as well as xmobar and urxvt.

It took me more than a half day to set it up and get it working like I want and having the same functions as my previous gnome shell and its extensions.

After a week with xmonad, I get used to it and still find-tune some configs everyday for little edge cases and new hotkeys. I think the overall experience is great especially if you are keyboard-centric. Every window actions are at your fingertips. It's fast, customizable and simple.

Now, with xmonad, I can utilize my screen more effective. I haven't seen my wallpaper for a while. urxvt is also fast at startup, faster than gnome-terminal.

The documentation and information on the internet is acceptable. You might need to dig in haskell syntax sometimes when your config errors. However, if you are a linux user, you are fine.

Finally, here is my current screenshot. Nothing special and really minimalistic. :-)

First impression of Golang

I have been playing with Go for 2 weeks. Here are my first impressions.

Good things

• Concise and clearly expressed syntax - Its syntax smells like C and Python. It also has some small interesting improvements over typical C-family languages. 
• if with a short statement. It might be just a syntactic sugar but I think it makes the code more concise.
• I like the idea of having only for loop and C's while is a version of for. 
• Capitalization means it is exported. Very simple and good formatting in the same time.
• switch with break by default.  Yeah. It's arguable but break by default is my choice.
• goroutine and channels - After I have been busy with thread-safe and concurrent issues using Java and Obj-c for a while, synchronized block, locks, java.util.concurrent, GCD and dispatch_async(), etc. I think this is another simple and amazing abstraction to deal with synchronization and concurrency in addition to a single thread and event-loop in nodejs.
• Easily add methods to almost any types even function
• Interface are satisfied implicitly - This is a 'wow' for me.
• Toolchain included - testing, package management, formatting and documentation. This helps Go developers to have a uniform development flow.
• Only one style and consistency - go fmt forces some styles and convention such as tab indentation. You might be annoyed if your preferred style is different from what the Go team has chosen. While I'm writing this, I found a very good explanation on why this is a good idea.

Interesting but in question

• One place for packages - Go needs every packages to be under GOPATH and wants developer to avoid local/relative import. It provides a good structure for that. It needs to specify fully qualified name in code when import a package. For example, import "github.com/teerapap/mylib".  It seems to be a good idea but I wonder if the url changes. Do I have to changes every import lines in my code?
• No versioning on package management - As opposed to npm, go get just get the latest version. I'm not sure if it is a good idea. Some said that you have to snapshot your tree. Some said that you need to use versioned path /v2/mylib instead.
• Only static linking

Finally, I am very new to Go so I have no comments on speed/performance aspect and I am still not sure what Go fits but it is quite fun to explore the language.

My experience with unit testing in software development

I am not a fan of software engineering which is taught in school. Waterfall model, spiral model,  many blah blah phases ,diagrams and documents. I usually thought of those as useless works or not worth to do.  I thought that software development should be simple. Get requirement -> Draft design -> Go coding! ->  Debug -> Someone test it manually -> Debug -> Test again (until it's acceptable) -> OK, Finished

Documentation should exist only if it is essential and the source code is one of the documentation. This methodology works fine because I usually develop alone or in a small team and the software does not have many modules.

Unit testing is one of those which I thought it's not worth to do. I agree that's it's useful for regression test of the code but I thought I know what I've done with my code and know what are affected. 

Around two years ago, I and my colleagues started a new project. One of them wanted to try a kind of Agile development model (I don't know the name. I've said I'm not a fan of these models) and we tried.

He encouraged me to write the unit test for each class and a few acceptance tests for overall project behaviors. I did it because I wanted to give it a try too.

Then I know I was wrong about testing. I usually see some bugs because the tests fail. In addition, I feels great when all the tests go green. The tests guarantee that the software still work as it should. However, I see some disadvantages or difficulties in writing test.

VisualVM on ubuntu(lucid) failed to initialize the Profiler engine

I installed VisualVM on my lucid(amd64), luanch it and it shows an error.

Failed to initialize the Profiler engine: Problem with a required JFluid installation directory or file /usr/lib/jvm/java-6-openjdk/lib/visualvm/profiler3/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so Original message: File does not exist.

In sprite of this error, the visualvm still can run but profiler/sampler doesn't show up.
Someone have filed this bug here. To fix this problem, recompile the missing lib manually and move to the right place.
Here are the steps

1. Download visualvm source here (visualvm_1.2.2.orig.tar.gz at the right pane)
2. Extract it and cd to the build directory
   tar -xzvf visualvm_1.2.2.orig.tar.gz
   tar -xzvf netbeans-profiler-visualvm_release68.tar.gz
   cd lib.profiler/native/build
3. You will see build script ( buildnative-linux64.sh ) then edit it. 
1. Replace gcc32 with gcc
2. Change 2 BuildJDK lines to below. /usr/bin/jvm/default-java/ is my jdk path; yours may differ.
   BuildForJDK "/usr/lib/jvm/default-java" "jdk16"
4. Make directory for release
   mkdir -p ../../release/lib/deployed/jdk16/linux-amd64/
5. Run this build script. It will compile the source against jni headers in our jdk and output as libprofilerinterface.so
   ./buildnative-linux64.sh
6. Move libprofilerinterface.so to the right place in your jdk path
   sudo cp ../../release/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so /usr/lib/jvm/default-java/lib/visualvm/profiler3/lib/deployed/jdk16/linux-amd64/
7. Launch VisualVM again.