Facing off with Old Code

Ever faced a codebase that had it’s last commit some years ago?

Either you have a bug to fix or a new feature that was asked implement, you will open up that text-editor/IDE and face off with old code. Right off the bat, it looks pretty “wrong”, even if you yourself wrote it. The only exceptional pieces of “old code” are parts you never have to open, because 1) they’re working exactly the way people need it to work and 2) users don’t ask for anything more than that.

People write code without a clear glimpse of the future. Some people do try their best to future-proof certain parts of the code, but it’s still written with uncertainty.

A few years pass and new things need to happen. Developers roll up their sleeves and see new opportunities of abstraction, new processes to pull out and modularize.

The thing is, those who work on top of the old code have the advantage of looking backwards, they can write the “thing” that can solve what really needs solving. That’s why no matter how pretty some patches of code presently look, they will almost always look crude in the future.

No matter how bad it looks, nobody can really blame previous developers; unless they didn’t have a firm grasp of the framework the software was built upon in the first place, but that’s a totally different story.

Besides, in the near future, even our “shiny new code” will suffer the same fate.

Something about ‘hard work’ and painting with watercolor

Elain, my brother and I painted with water-color a few weeks back.

(Rightmost is mine, Top is my brothers’, Left and Bottom are Elains’)

Back in May, Nate, me, Ryan and Joaquin painted with water-color as well. Joaquin wanted to paint some version of Hulk, Ryan tried to do this picture of a guy under a tree, Nate decided to paint a colorful street scene, but it’s not yet finished though.

I wanted to do ‘Wanderer above the sea of fog’

It’s an oil painting during the 1800’s by the German Romantic artist Caspar David Friedrich. and the fact that we were painting with watercolor..

It was ambitious, too ambitious.

The thing with painting with watercolor is that you need more patience than usual, like say, painting with acrylic. Water doesn’t usually go your way, so it ends up looking like nothing you expected it to be.

Working Sincerely

Everyone sees that one great painting, but no one gets to see the thousand others crumpled up in the trash.

The Zuckerberg’s in this world are over-glorified. By the way it’s not the “media’s” fault at all, they just want to earn more cash by putting up hot stories of teen-stars or young famous entrepreneurs because those are ‘exciting stories’. The masses feel more excited to hear about ‘big moments’ rather than ‘boring stories’ like the one about your neighbor, who worked his way up for 10-20 years while doing his business on the side which eventually led to quitting his job for that business.

Actually, it’s as equally amazing.

A business that feeds his family, sends them to vacations, buys them a modest house, gets his children more opportunities in life like finishing college or allowing them to be free exploring the things that they want to do, all thanks to his dedication and commitment. In his own little way, even just a tiny bit, helped change the world for the better.

Either way, if you looked closely at both stories, most ‘overnight success stories’ didn’t actually happen overnight. Study the others, those ‘success stories’, but never compare yourself with them. Sincerely keep working enthusiastically on what you’re currently doing.

Working hard beats talent at any time.

That looks absolutely nothing like the Wanderer Above the Sea of Fog

I agree.

Maybe in time, I can at least do a more decent job with the ‘Wanderer above the sea of fog’ in watercolor, if it’s ever possible. But hey, I actually enjoyed trying to paint it.

Rails: Developing Email-related features with rspec, email-spec and letter_opener

After years of being a developer, (.NET and Grails, now I’m 3 months into Ruby-land), I always run into productivity problems when developing email-related features. Here’s why:

  1. Write/Fix the code
  2. Send the email to an inbox
  3. Open the inbox
  4. Find something wrong
  5. Repeat 1-4 until satisfied

Sounds easy, but it’s really tedious. Your inbox fills up with test emails. Your 'flow' gets broken. So recently, I’ve marked a new milestone in my development career: that doesn’t happen anymore. Instead, this happens:

  1. Write a test, expecting what I want to appear in an email.
  2. Write the code
  3. Run the test, find something wrong
  4. (Optional) Run the mailer in the rails console, email pops up as an HTML file in my browser
  5. Repeat 1-4 until satisfied.

No more inbox related stuff, and I can cycle quickly through the usual development loop.

rspec, email_spec and letter_opener are the keys to how I became productive. Combining these gems are one of the many ways to get productive in churning out email-related code, but so far this is my most favorite.


rspec needs no introduction — simply put, it’s a unit testing framework for ruby.

I don’t write unit tests for all of my code, since I know I’ll go crazy when I do and it’ll be counterproductive. I only write tests for my code when:

  1. It’s a piece of the system that’s really important and prone to errors.
  2. It’s a pain to replicate manually.

To cut it short, Unit tests helps me be confident that whatever I’m expecting to send in an email, is actually written there in that email.

email_spec are helpers for rspec to test emails. Taken right out of the README:

describe "Signup Email" do
  include EmailSpec::Helpers
  include EmailSpec::Matchers
  # include ActionController::UrlWriter - old rails
  include Rails.application.routes.url_helpers

  before(:all) do
     @email = UserMailer.create_signup("jojo@yahoo.com", "Jojo Binks")

  it "should be set to be delivered to the email passed in" do
    @email.should deliver_to("jojo@yahoo.com")

  it "should contain the user's message in the mail body" do
    @email.should have_body_text(/Jojo Binks/)

  it "should contain a link to the confirmation link" do
    @email.should have_body_text(/#{confirm_account_url}/)

  it "should have the correct subject" do
    @email.should have_subject(/Account confirmation/)



letter_opener sends the email in the browser as an HTML file instead of really sending it. This means you do not need to set up email delivery in your development environment. Helpful for styling emails, and for integration tests (Cukes)

Taken right out of the README:

First add the gem to your development environment and run the bundle command to install it.

gem "letter_opener", :group => :development

Then set the delivery method in config/environments/development.rb

config.action_mailer.delivery_method = :letter_opener

Now any email will pop up in your browser instead of being sent. The messages are stored in tmp/letter_opener


rspec + letter_opener = developing any email-related feature is no longer painful.

What are some good certifications for a junior developer?

Are there any skill-building programs or certifications out there that you could recommend to a developer at the very beginning of his (post-bootcamp) career? Something that could ideally be done in addition to a part-time or full-time job? Thank you

There are a lot of skill-building programs out there but you gotta ask yourself first on which ‘programming world’ you would like to be part of:

Certifications are really good if you really want to build a career into middle-management, in-house software development departments a.k.a. mega-corp widget factories; these types highly appreciate certificates. A big pharmaceutical company would love to see a Microsoft Certificate over a Github profile since they don’t care about the code, they just care about you passing a “industry standard test” so that you would fit X number of requirements and feel safe that they got the right person. Couple your certificate with a filled out LinkedIn profile; and they’ll highly consider you.

Building a good Github profile/portfolio website is the better route if you want to build your career around working for companies that sell software as their core product, or well-known shops (Fog Creek, Basecamp, ThoughtBot, PivotalLabs, etc.). These type of companies highly value code and work output, and they’d understand the value in your profile. Don’t get me wrong, a certificate would help in some way but if you can’t show them you can code or be comfortable with the command line, they’ll go for anyone else who has built something and deployed it.

If you’re going for the certifications route, it depends on what stack you’re going for:

For anything with Spring, go through springsource.com/training you’ll find some links there for certification classes.

For anything .NET or Windows, go through microsoft.com/learning for more info.

Don’t underestimate the amount of time and money spent on studying/getting a certification. If you already have a job, don’t take a certification unless you really plan on moving up some sort of mega-corp corporate ladder, deeply studying a certain ‘vertical’ or if you’re targeting another job that requires a certain certification.

If you want to get ‘better’ that has no ‘immediate’ strict commitments:

  • Find yourself a user-group of your stack
  • Work with a friend on a project you think is ‘cool’
  • Talk to your boss and ask to work on a part of the company system that interests you
  • Work on some open-source project.

Discussion on HackerNews

Development Workflow with Vagrant

Whenever any developer creates software within a certain level of complexity, it requires a certain environment required for the application. If you were building a certain Rails app that had Resque on it, you’ll need to install Redis on computer, if it’s using MySQL or a certain flavor of an SQL database, you’d also need to install it. If it has environment files or other 3rd party software needed to run (i.e. ImageMagick, etc.) you’ll also need to install those.

In the long run, your host computer becomes this chaotic hotbed of a development environment you build your apps in. This becomes a pain point for most of the time during application development.

Problems rise up whenever you need to get other developers on board with the project. So you’ll have to set up the same type of environment you’ve set up.

Another problem is fixing bugs found in Production/Staging environments. Deployed from development code and development data, you have no idea whats going to happen when your software is deployed into a Production/Staging environment.

There are many other edge cases we can think of that involves development environments.

"It works on my machine"

This tends to be a thing developers would say. tldr; Vagrant is a good tool for this painful part of the development workflow.


Where I work (AELOGICA) we use this basic Vagrantfile for developing applications privately in our own computers.

Whenever I do vagrant up this basic configuration for a vagrant VM makes my project folder accessible inside that VM. I could do bundle install inside the VM, run ansible playbooks/chef scripts to set the VM up as a development/staging/production environment.

Other developers or devops involved in the project can effectively get the same environment, without messing up their host computer by installing tons of software to recreate a certain environment. It’s knowledge transfer of a project at its finest.

Used in this context, Vagrant is a great tool for creating consistent and stable development environments. It helps lessen the ‘works on my machine’ theory, when solving problems with the code.

Everyone doesn’t need to necessarily do the same workflow for everyone, Vagrant is just a tool at the end of the day.

As Mitchell Hashimoto, creator of Vagrant, would say:

Of course, it isn’t necessary to follow each and every principle of the Tao of Vagrant to use Vagrant. Vagrant is a general purpose tool and can be molded into your environment as you see fit. But it is important to see and understand the larger vision behind Vagrant.

Talk about career…

I’ve always wanted to talk to students about the realities of the IT/Software Development industry, a talk that I would have loved to hear when I was a student. God gave me that chance through a friend of mine.

I gave a talk entitled “Career Paths: Story-based Career Planning” for a host of graduating students in Asia Pacific College.

Depending on the circumstances and unless I need to learn something specific — it’s ridiculous to seriously take career advice from someone who has yet to hit 30:

'Who here has no idea what they'll do after graduation?'

I asked.

Most of them laughed and raised their hands. That got them talking, that question got their attention.

I didn’t talk as someone with authority, but as someone who is also going through their own career path, someone who is also learning as they go.

I told my story, I told them to learn from it, because it’s the most helpful thing they could get from me unless they approach me personally and ask for specific advice.

They wanted a 45 minute talk, I gave a 25 minute one. One thing about giving talks is knowing the context. A bunch of students attending for requirements? In this context, short and sweet is better than long and tedious.

The talk ends up with a single point: Focusing on your ‘Career Plan' is noteworthy, but what's more important is the character needed in going through your 'Career Path’.

Some snippets:

  • Part of my talk was going back to what the word ‘career’ really meant:
  • Career originates from the latin word carrus (a wheeled vehicle)
  • The definition of career transformed throughout time, now it’s being used to describe one’s profession.
  • Career is also a verb: to move uncontrollably.
  • I also didn’t know what to do after graduation.
  • Plans are man-made based on ideal expectations, do not follow them to the letter, see them as a guidelines.
  • Paths are made naturally based on personal character. Exceptional Careers (Yukihiro Matsumoto, Steve Wozniak, Bill Gates, Steve Jobs, Martin Odersky, Jack Dorsey, Elon Musk, etc.) seemed more of a ‘path’, not a ‘plan’.
  • Character beats ability, but it doesn’t mean you’ll give up trying to be better at being more able. Work smart.
  • Be concerned in doing the things you love doing, you’ll get highly paid to do these things in the future.
  • Passion is great, on the other side we also need to be professional. Balance both. What if you don’t feel like doing what want to do anymore? Plan around the things you’re passionate about.
  • Applying for a job and going into an interview is the norm after graduation, but it will be the ‘exception’ after working for a couple of years. Work well, work well with others.
  • Take related tasks that no one wants to do, your value instantly increases.
  • Do things that are highly valuable for the company. Climb up the value chain, avoid being a ‘cost center’, attach yourself to ‘profit centers’.
  • Avoid ‘make work’: made-up work to make you look busy. Automate ‘make work’, and you’ll instantly be essential to the organization.
  • Age is not that important, if you’re working with right people.
  • 'You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.' - Steve Jobs
  • I placed my trust in God that everything would be alright.

Building a simple expense/income app for me and my wife #DevHusband

I’m working on a simple expense/income tracker that me and my wife can use. Excel sheets/templates and other finance apps are way too complicated, we both agreed that in the end accounting is as simple as taking down notes in a ledger — why not enter those entries just as easy as tweeting (categorize expense/income in hashtags, etc.)

It’s not as complex or innovative as other accounting systems and projects, but it’s working out for the both of us and we’re using it. It’s also a nice excuse of a project for me to flex out Ruby code.

Enabling Code Blocks on Tumblr via Google PrettyPrint

Grab the prettify.js and a prettify css style from the Google Code repository, stick them in your ‘head’ tag

<link rel="stylesheet" type="text/css" media="screen" href="https://google-code-prettify.googlecode.com/svn/trunk/styles/sunburst.css" />

<script type="text/javascript" src="http://cdnjs.cloudflare.com/ajax/libs/prettify/188.0.0/prettify.js"></script>

Grab jQuery and append prettyPrint on every pre element it can find on your blog, then call prettyPrint()

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

$(document).ready( function(){

There you have it!