This morning, we had a ticket regarding the publish times of posts in a site that was using Radiant CMS. The clue we had was that the publish time and the created_at time were different – which meant that somewhere, the published_at is being set and saved in the db without UTC. I searched the code for a good hour or so for terms like “published_at”, “publish!”, “timezone”, “TimeZone”, “local”, “utc”, etc. to no avail. I still couldn’t find where it is happening. We already had a debugger right before saving it and here are the results:

(rdb:2) page.created_at
nil
(rdb:2) page.published_at
nil
(rdb:2) page.save
true
(rdb:2) page.created_at
Thu, 23 Aug 2012 10:30:36 EST +10:00
(rdb:2) page.published_at
Thu, 23 Aug 2012 10:30:36 EST +10:00
(rdb:2) page.reload
#
(rdb:2) page.created_at
Thu, 23 Aug 2012 10:30:36 EST +10:00
(rdb:2) page.published_at
Thu, 23 Aug 2012 18:30:36 EST +10:00

As you can see, right after saving, the published_at is the same as created_at, but after reloading, we see it change! I checked the db structure and I didn’t see anything different. At that point, thoughts on Radiant bugs flew into my brain.

“Maybe this is a Radiant bug?” “No it couldn’t be – I searched already and no one seemed to point it out.” “It has to be – it’s not in our code!” “No, if it was a bug, somebody surely would have fixed it”

Needless to say, I trusted Radiant too much to even check. Finally, I did relent and tried opening the Radiant gem. And there it was. Right before saving, Radiant used Time.now when saving published_at. From this StackOverflow answer it is mentioned that Time.now used the machine’s OS no matter what you set in Rail’s config.time_zone. This was the flaw! And it WAS in Radiant and not in our code. Having fixed it, I checked Radiant’s github again and saw that it was fixed at some point. We were just using an older version – it probably was fixed without people knowing about it.

So there you have it. Don’t trust your tools too much and always consider EVERY option.

Here at Aelogica, we love open source. All of us have, one way or another, created an open source project or contributed to it. Contributing to open source is very fulfilling – people contribute to each other’s work and it is a great way to learn new things. I’ll talk about this in detail in a little while so hold on to your seats. Most of my points may have already been said before but hopefully, if you haven’t contributed or created any open source projects yet, this post might make you think about doing so.

Creating an Open Source Project There are a lot of posts (and even books) about creating/maintaining open source projects so I’ll only state what I think and have experienced about it. FIrst, being forked (for the non-technical, basically someone copies your code to modify or use for his own purposes) in Github gives me the feeling of importance and that my work was valued. It gives you that sense of accomplishment comparable to seeing people use a phrase or word you just invented (or a fad you started – not that I have started any fads). Most of us have created open source projects and I’ll use this opportunity to showcase some of them:

• minizip - a ruby wrapper for zip (UNIX/OSX)/7zip(WIN)
• pivotal-angel - a supplement for the pivotal-tracker gem
• Compass Twitter Bootstrap Plugin
• Vimercises - Vim exercises for beginners
• IJGMaps - jQuery wrapper for Google maps v3
• RadLib - collection of lua utility functions
• Nakor - gem for generating Corona game templates
• Corona Game Template
• Cocos2D Patterns
• Storey - manage multiple schemas in multi-tenant rails apps
• navi - database-backed navigation

Contributing

For me, contributing to open source is very fulfilling. It gives me almost the same feeling as creating an open source project that was forked. You don’t have to be a really bad ass programmer just to contribute. Contributing can come in many forms: creating issues (bugs that you encountered and don’t know how to fix), participating in a discussion on how to move forward with a project (some individuals that have a huge amount of followers usually consult with their users through a mailing list – asking for suggestions on how to tackle a problem), and even correcting spelling/grammar mistakes that might lead to confusion. Pointing out bugs (don’t forget to also show how to reproduce it!) helps developers greatly since most of the time, they don’t have the means to QA everything their apps/tools do. That means it is up to the community to help with spotting (and fixing, if possible) the bugs that appear.

Interacting with our Heroes

I am easily starstruck by my own heroes and idols. I’m pretty sure a lot of people are too and that’s also a great motivation to working with their projects. A couple of my heroes are Aslak Hellesøy (creator of Cucumber) and Chris Eppstein (creator of Compass and core team member of SASS). I pretty much use their creations everyday so when the time came when I wanted to give something back, I helped out as much as I could. They are also VERY active in their respective mailing lists – almost replying to each of the emails there – making sure that the community is active and that newcomers feel welcome.

Back when Aslak requested people to come into the cucumber chat room to help out with merging all the Cucumber Textmate Bundle forks into one (and making it officially under cucumber’s repo), the best I could do was to join in and look at the logs to see which ones were good or not. I knew NOTHING about Textmate bundles, and the only reason I was there was because I USED Textmate (before) and I loved Cucumber. Even if Aslak and the others did the coding and stuff, they made me feel like I was still of help even by just checking the commits of each one.

Another time I helped my hero was when Aslak requested someone to create a script to mass message all the forkers of the Cucumber Textmate Bundle. I did that script during my free time and that knowing he used it (he even helped me test it!) made my day. It’s like helping Spiderman or Batman by throwing a rock at an enemy he’s fighting with – you know they can beat that guy up even without your rock, but you also know that somehow, you made their fight much easier.

Contributing: Learning New Things

Contributing to open source also makes you learn things – things that you would otherwise not care about given other circumstances. Case in point: I suggested to YADR (this is the current dotfile package most of us use now) that vimrc.afters should be in /vim/after, not in root – to minimize the files in root and so everything will be in your yadr folder. To be honest, I was expecting them to actually fix it, since I knew nothing about customizing Vim. The reply: “Please do implement and pull request :)” made me stop in my tracks. It was very polite of Yan (the owner) to say “if you really like it, do it”. Having no experience whatsoever with Vim plugins (I relied on other people/plugins to customize my Vim), I didn’t know if I should just leave it until someone else does it (someone actually agreed with my suggestion).

Instead, I thought of it as a challenge so off I went and experimented – besides, it was just a simple path fix, what could go wrong? Sure enough, that simple fix took me longer than expected. I perused the Vim help files and looked at the definitions for filereadable, expand, and the filename expansions for Vim. It was indeed a challenge (for me) so in the end, I had to concede and assume that the file was in ~/.yadr/vim/after instead of ~/. My original solution was to direct relatively so even if yadr was installed elsewhere it would have been okay. In any case, I still learned something new in the process of contributing, so in the end, it was still a good experience (not to mention it was merged to master a few minutes after the push!).

I hope that a lot more people will start their own projects and contribute to projects they love and use. It just makes the (software) world a better place to live code in.

In one of our Tuesday lunches, we discussed what our favorite tools were. We discussed the pros and cons of each and we mostly agreed with everything. This was so that we were all at the same page when coding and so everything is consistent. As a side note to this, we also planned to create a style guide for everyone so we all followed the same coding conventions, code style, etc. as much as possible.

We based most of our stuff from existing guides, and added some examples and changed some based on our preferences and own opinions. Our primary source was Github’s own style guide here: https://github.com/styleguide/

Some were also taken from existing blog posts (and rightfully credited – if you are the author and have issues, don’t hesitate to send us an email!). We think that this might help other people as well, so without further ado:

The Aelogica Style Guide

Buddy and I were discussing how to develop our Vim skills and it led to us thinking about a game much like http://vim-adventures.com/. We discussed about creating a game where given a task in Vim, you’ll compete with other players on how fast you can finish the task.

We thought about creating a server and making people log in etc, but that’s kinda hard to set up since we’ll have to deal with security, server load, etc. So I made a quick prototype of our idea and modified it a bit.

Enter Vimercises.

These are a set of exercises that will test your knowledge of Vim. It is designed for beginners and intermediate Vim users such as ourselves(Ramon is our resident Vim expert having used it for a couple of years I think). Anyway, most of these tasks are based on our every day experiences while pairing.

Hopefully this gets to help people and make them better Vim users. Next up: a post on how the project page was setup using Jekyll, HAML, SASS, Compass and some thoughts on Vimercises version 2 – going social!

Not trying to start editor wars here, but changing from TextMate to Vim was one of the best things that have happened to me. Recently, I was investigating a bug involving something about a ruby script that’s 1000 lines long. I didn’t have access to the original file so I had to create a 1000 line ruby script.

My first try was to create a ruby script that will print out 1000 lines using puts. This was easy, with File.open, although I still had to format etc and took me about five minutes.

Enter Vim.

I had to rewrite the code by not using puts and using a real, non-cpu extensive ruby line that will just check if text exists in a browser. Instead of writing a ruby script again, I remembered about Vim’s power. To cut the long story short, all I did was yank the line I wanted to execute 1000 times(can’t do a loop since the bug was supposed to have happened because the script was 1000 lines long) and then just typed:

1000p

which basically just pastes the line 1000 times. Trying to think about that in TextMate without any plugin, I would have had to do an exponential copy-paste, where I duplicate the line, copy the two lines, duplicated the 4 lines, etc.

It would have took me more or less 5-10 minutes also, along with just writing it in ruby which would take about 1-3 minutes. Vim did it for me with just 5 key presses which roughly translates to 1-2 seconds.

Sweet stuff is sweet.