PostgreSQL, the Poor Man's Oracle

Via HN. Good to hear that ARIN have successfully migrated their database from Oracle to PostgreSQL. Not sure if they are using the plain vanilla or commercialized version.

PostgreSQL is the most under-appreciated and unknown open-source database. While more features were added, they've lost the popularity game to MySQL for two main reasons. Lack of Windows support in the earlier version and availability from web hosting provider. I wish more people would add PostgreSQL into their technology stack consideration instead of just MySQL.

Be Helpful

"One day I was talking with one of our best engineers, an employee I’ll call John. Before the layoffs, he’d managed three engineers, but now he was a one-man department working very long hours. I told John I hoped to hire some help for him soon. His response surprised me. “There’s no rush—I’m happier now,” he said. It turned out that the engineers we’d laid off weren’t spectacular—they were merely adequate. John realized that he’d spent too much time riding herd on them and fixing their mistakes. “I’ve learned that I’d rather work by myself than with subpar performers,” he said. His words echo in my mind whenever I describe the most basic element of Netflix’s talent philosophy: The best thing you can do for employees—a perk better than foosball or free sushi—is hire only “A” players to work alongside them. Excellent colleagues trump everything else."
-- Patty McCord, How Netflix Reinvented HR, emphasis added
One of the best read this weekend. Excellent write up on Netflix's, (the company that provides on-demand Internet streaming media), human resource policies. So many gems from the slides on how they define their company culture but not all are applicable as different countries have different labour laws.

While you can't always get excellent employees, but at least find those with good attitude and nurture their aptitude. Everyone want to find a good employee but nobody want to train them up. As for employee, if you're falling behind, re-educate yourself to stay competitive or just move on to do something else.

Discussion at Slashdot has an opposite point of view.

Daily Working Routine

As a person who want to best use of his time, I am always curious about other people productivity hacks. Semih Yagcioglu recently wrote about his daily working routine which is something everyone can learn a few tricks from. Notable activities from his working style.

1. Break your day into morning, afternoon, and night routine. If possible try to slot in 10 to 15 minutes of exercises. Unfortunately I lost my Pedometer (walking steps counter) and now currently saving money to buy Fibit Force.

2. Similarly, I also work in a Timeboxing way or to be specify, using Pomodoro technique. Unfortunately, I do not prioritize my tasks to my liking and occasionally need to "fire fighting", where you caught up in many unexpected, urgent, and sometimes, not important tasks.

His Inbox Zero proach make senses. Any tasks or emails should be acted upon by replying it, delete it, or just delegate it. The 1-3-5 Rule can be handy in setting your daily goals. The Bullet Journal approach its something new for list-maker like me.

3. ZenPen is also something that's new to me. A cleaner version compare to Writer, the online writing tool I currently use.

In short, be aware and keep tracking of your to-do list and make adjustment accordingly. Don't dwell on the technique, focus on your tasks. In coming 2014, going to get myself a smart phone to complement my current pen-and-paper approach, let's see how this goes.

Decomposition Technique

Decomposition is one of the important skills for a programmer as we need to break any problems into smaller and manageable chunk. Bumped into this top-down approach on achieving that. Step as follows:
  1. Describe an overview of the problem in your head, with words.
  2. Try to write code that is the closest to those words
  3. For every unimplemented thing, repeat until done.
Pay attention to step 1 and 2. If you can conceptualize the problem and solution in your head and describe it in most layman term, surely the code produced will be easily understandable. As they said, good programmer are good writer or rather good communicator, they can convey their ideas across.

Similarly, another approach is to use reference pattern or application architecture. But this is at different scale, more of the overall architecture. Example is Command Query Responsibility Segregation (CQRS) which is an alternative model to CRUD model. Still reading and try to learn other approach than CRUD.

Teaching Subversion ?

After many years of using, encouraging, and observing developers using Subversion led me to a conclusion, it was never a technical issue but a people issue. Some lessons learned:

Management support
Unless the management, especially those without technical background, support the use of any source control to be the integral part of development process. Otherwise, you will be wasting your time and your breath.

Can anyone still practice software development without source control? Yes, you can. Short term project, especially those can be handled by single developer. Or one developer per module or folder approach where source code are shared through one centralized file server. Hence, you will encounter files in project that looks like this:
index.php
index_20131213.php
index_20131010.php

Yup, the developer is cooking his own source control. I cringes every time I see anyone does this. The saddest part is such practice is still so prevalent.

Company that don't value the importance of source control does not realize the benefit of safeguarding their intellectual property and other assorted gains in using it.

Use source control properly
Troy Hunt's 10 commandments lay down the rules on how to use it correctly. I will like to focus on two major difficulties I observed especially for those (me as well) who just starting to explore source control.

Write a meaningful and better commit message. You should explain the why and not really the how. Occasionally you will read empty commit, repeated (e.g. "latest update"), or just plain wrong commit message. These are useless and not helpful for anyone to review back any previous changes. Why so ? Because writing good commit message is hard, especially those whose mother tongue is not English. To solve this, set a standard log message format and encourage the developer to break each task into smaller chunk.

Commit early, often, and small / atomic. Break a large task into smaller sub-tasks. Unless the developer is stuck at something, there should be multiple commits per day. Also, this is to prevent those developers who like to commit everything in one shot.

In short, having the right tool and convention are not sufficient enough unless the developers are willing to use it correctly.

Programmer Productivity

"I would submit that the appearance of hard work is often an indication of failure. Software development often isn’t done well in a pressurised, interrupt driven, environment. It’s often not a good idea to work long hours. Sometimes the best way of solving a difficult problem is to stop thinking about it, go for a walk, or even better, get a good night’s sleep and let your subconscious solve it. One of my favourite books is A Mathematician’s Apology by G. H. Hardy, one of the leading British mathematicians of the 20th century. In it he describes his daily routine: four hours work in the morning followed by an afternoon of watching cricket. He says that it’s pointless and unproductive to do hard mental work for more than four hours a day."
-- Mike Hadlow, emphasis added
In other word, pretending to be busy is cheating and constant fire fighting indicating a repayment of technical debt. Long working hours? The lack of proper project management and client expectation.

Fuggit, just do it

"I'dropped out' of my life of making video games this summer, got rid of everything I own and set off on a journey across the US by bicycle. Every day I wake up in my tent and make a conscious decision to climb on the bike, with an awareness that something amazingly bad might happen, however something amazingly good might also happen. I so far have been fortunate for I have enjoyed lots of amazingly good moments, and have learned it is an acceptance of the prospect of very bad things that makes the trip more remarkable."
-- cmos, emphasis added
Share the same sentiment as well especially after I slipped on my motorcycle recently. We sometimes forget that we're not the exception and invisible. You should be always aware of the danger when riding a motorcycle.

Maybe in coming 2014 I should look into game or graphic development. Something that drew me into the field of development in my younger years. Is time to revisit the long lost love of mine.

Breaking into Programming

"From time to time, I run into people who are interested in breaking into programming. Last night at the company holiday party a guy (we’ll call him Sam) walked up and introduced himself, asking for advice on how to move from his current role over to development. Sam’s attitude impressed me – guys with a genuine desire to learn go places quickly. And on many occasions I’ve hired someone very green simply because I could sense a genuine interest in the craft and a hunger for knowledge. I’ll take attitude over aptitude."
-- Cory House, emphasis added
Same opinion here. Genuine interest and hunger for knowledge are the first two of out of four (more on that later) important qualities for newcomer in programming profession. Why so? Simply because all programming is generally maintenance programming, you will read more than writing code, especially by others, and you're going to hate what you've encounter. Unless you've genuine interest to sustain your motivation, otherwise it will be mundane, stressful, and soul-crushing.

Why all the negativity towards software maintenance? When you're taking over a legacy software project, you're going inherit all the unfortunate consequences that come with it. Undocumented business rules, inconsistency coding style, lack of or the abused of version control, no testing, no database referential integrity, big table (not the NoSQL storage but one table with > 50 columns), disgruntled stakeholders, and more are the typical encountered situations. *The most painful part is you're enduring all these due to the management or technical decisions made previously which you've no part of making and influenced.*

Which is why, as I observed, there exists a special group of developers or freelancers that focus on hacking the stuff up fast and move on to other projects and companies without doing any or minimum maintenance. These people know they're hacking stuff up and they know the happiest way is not to maintain it. Honestly, I don't blame them. Most stakeholders deserved what they're requesting for, something that is developed fast and cheap. Later, they will hire another bunch of people to maintain it. Off course, they will keep asking why is it so slow and expensive to churn out another feature. How can you move fast forward when you're paying technical debt? Nothing against this approach, fast and cheap works well for a startup which want to test the market with a Minimum Viable Product (MVP).

Back to the two other desirable developer traits. First, humility or as what what Edsger Dijkstra argued, accept your brain limitation, be a humble programmer. Let go of your ego, someone out there is worse or better than you, no need to be smug and insecure. Embrace and improve upon your incompetence, learn from them, let them inspired you. Find the gap and fill the void. Furthermore, can-do attitude doesn't means say yes to everything. Is okay to admit your cannot-do anything.

Second, empathy, the feeling of being in others' shoe. Keith Wesolowski recently stressed that "empathy is a core engineering value" which I believe, is something to be instilled into every developer. Understand your user pain, optimize and automate their works. Follow the coding convention, write proper documentation (the business rules or the whys), and be helpful to your fellow programmer.

In short, ask yourself, are you genuine passionate about software development, love learning, humble, and empathy person? If so, maybe this profession is right for you.

Learning and Earning Equally?

"You're always on one side or another of the learn vs. earn. Given the nature of equity and corporations, always know that owners reap the rewards and workers are transacting their time for money. But unless where you work is a co-op where profits are evenly distributed, you'll never extract the full amount of value that you create for the company. Always know whether at that moment you're learning or earning. If you're learning, then it's worth it. If you're not, you better be earning (e.g. being a founder, being a share holder). Otherwise you're just wasting time. "
-- Lessons from 2^5 that I wish I knew at 2^4, Garry Tan, emphasis added
How can you juggle equally between earning and learning? That is something I realized the hard way in my career life as a code monkey. As you age, time without interruption is a limited precious resource. There are always constant interruption from every part of your life.

What kind of adjustment I need to make for me to increase both my learning and earning? Note that earning more does not means gaining more money, but to save more through less spending.

Modernize Your Legacy PHP Application

How? Code base restructuring. As suggested by the video presentation below, these are the recommended 2 steps.

1. Consolidate classes for autoloading.
Just implement autoloading according to PSR-0 specification. Move php script around and remove all the require or include statement. Do make sure is one class per file.

Also, group all your helper functions into classes and call these global functions through static or instance method. Example of static method.
xxx_get() to XXX::get()
xxx_set() to XXX:set()

Some of you may argue this does not bring any sort of benefits except more typing. I do agree as occasionally we sometimes have a few orphaned global functions which hard to be grouped in any class. Surely we're not going to put these helper functions in a class called Miscellaneous or Common class.

2. Convert global to injected dependencies
Those dreadful global variables (those using global keyword) which sometimes accidentally which values may reassigned half way through your script.

Invalid UTF-8 Sequence in Subversion Again

I remembered I encountered this issue before few months back in March. But yet, I can't remember how to solve it. My previous solution to detect the culprit filename with invalid encoding was using strace but this post recommended a better, more accurate approach to detect it. The detection is straight forward, just convert the hexadecimal code to ASCII.

Let's look at my previous example
$ svn up

svn: Valid UTF-8 data
(hex: 49 50 )
followed by invalid UTF-8 sequence
(hex: a0 2d 56 69)

My issue last time I did not fully grok the error message. What the svn client tried to tell me is there is a filename in hexadecimal sequence of 49 50 a0 2d 56 69 that is causing the corruption.

Convert this hexadecimal sequence to ASCII and the full culprit filename known as shown below.
$ echo "\x49\x50\xa0\x2d\x56\x69" | xargs -0 printf
IP�-Vi

What you can do right now is find any file that contains this sequence of characters of IP�-Vi and remove it.
$ ls IP�-Vi*
$ rm -rf IP�-Vi*

Whoala ! There you have it.

Switch to Gnome 3.10

Regardless all negative experiences vented by numerous people on Gnome 3.x, I have the opposite and surprised experiences after switching to it from Unity Desktop. Everything seemed fall into place and far more stable and pleasant looking than the Unity. Commands to upgrade as follows:
$ sudo add-apt-repository ppa:gnome3-team/gnome3-next
$ sudo apt-get update
$ sudo apt-get install gnome-shell ubuntu-gnome-desktop

$ sudo add-apt-repository ppa:gnome3-team/gnome3-staging
$ sudo add-apt-repository ppa:gnome3-team/gnome3
$ sudo apt-get update && sudo apt-get dist-upgrade

$ sudo apt-get install gnome-weather gnome-music gnome-maps cheese gnome-documents

No More Excuses

"Many of them have skills but neglect to even attempt to put their skills to work. And when you ask them why, all they have for you is excuses. My race this, my gender that. We are living in an age when it is easier than ever before in human history to use your skills and ideas to positively impact your world."
-- Jon Doe
The quote above really resonate with me. As you age, time seems go faster and you've used up all your excuses of not doing something worthy with our life. How about those long lost dreams of doing something that change the world in the positive manner? Time to think hard on this matter and act on it. Get out of your comfort zone and take the first step. Reach for your next milestone. Make that decision.