Category: webdev

Nailing a localization bug
As I wrote in my last post, I’ve been working on Mozilla input. After the first 2 weeks of my work, I ended up finishing almost all of the easy bugs on the project. On Monday, I decided to tackle one of the more challenging bugg, bug 614535. The situation in Input is interesting because we often show LTR text in RTL localized pages. This bug was about problems with that.

My solution to the problem was to use the locale that’s associated with each ‘opinion’ and mark the text and the name of the locale itself with the correct direction. I had sat down thought about this earlier and also brainstormed with a friend. Our conclusion was to have a list in the settings that would be a list of locales that are Right to Left. I discussed this solution in #webdev, and Fred Wenzel told me there already is such a list (Doh! I should have checked). With the general agreement that my solution did make sense, I started to implement it.

The above picture is a screenshot of input searches before the fix. Some of the opinions have punctuations slightly messed up. And the locale, English (US), isn’t displayed properly. Fixing the opinions was easy, I created a new class with property ‘direction: ltr’ and applied that class if the locale of the message was not it the RTL_LANGUAGES array. Fixing the locale name was slightly more challenging because its an item in <ul> list. Simply adding a class to the <li> made the bullet point to also switch. This, may be technically correct (because that’s where you’d expect the bullet point in an LTR text), but it wasn’t an elegant or good-looking solution. I tried to put a span around the locale name, that didn’t work either. Eventually, with help from #webdev, I went with the Unicode left-to-right mark.
I still can’t say nailed it, my pull request is pending review.
2011-07-20
Pair Debugging with Byobu
Lately, I’ve been contributing to Mozilla Input. After writing a few small fixes, I started picking up the slightly not-small ones. My fixes ended up breaking tests. That’s when I ran into trouble. The Mozilla webdevs I’ve been working with use Mac and I use Ubuntu. With help from kumar and davedash, I tried debugging my setup to no avail. Long story short, we wanted to all be the same session and try to see the errors and use pdb.
Eventually, davedash gave me a user on an Ubuntu VPS where I set everything up. Since, the whole point of it was debugging this together, we debugged over byobu. Dave and I both logged into the same byobu session. It was just great for pair debugging. He waited while I setup everything and I watched how he was debugging. Perfect when your teammate is half a world away.
2011-07-12
Nerd-friendly blogging
I’ve been promising myself to write about my blog setup for a while now. As I explained earlier, I use Jekyll – ‘a simple, blog aware, static site generator’. Every time jekyll generates html, it gets dumped to the _site folder. I have my local nginx pointing to the _site folder, so every time I start write blog posts, I open a terminal, go to my blog’s root folder, and run jekyll --auto and hit my nginx install from the browser. This way, every time I save, I get to see what it looks like. I found this much faster than doing jekyll --auto --server and using the server with Jekyll. I version control the whole folder minus the _site folder with git and I’ve set up a bare repo on my server to which this will get pushed too.
Jekyll also runs on my server because I want to be able to blog from any machine from which I have SSH access to my server. I’ve set up the following commit hook on the bare git repo that regenerates the HTML files on every push.
```
GIT_REPO=$HOME/blog.git TMP_GIT_CLONE=/tmp/blog PUBLIC_WWW=$HOME/blog-www  git clone $GIT_REPO $TMP_GIT_CLONE jekyll --no-auto $TMP_GIT_CLONE $PUBLIC_WWW rm -Rf $TMP_GIT_CLONE exit 
```
Its a pretty rad setup. For comments, I’ve setup Disqus, which was quite easy. I set up askimet with them, so that the spam gets filtered, yet to get spammed though (knocks on wood). Overall, the setup has been quite nice and yes very nerd friendly. I can write in my text editor of choice and commit to git with complete rollback history if I want to. Not having an admin panel from which things can be changed is a great benefit!
2011-07-01
Hacking on Ubuntu Single Sign-On
As most of you, who’ve used community projects like Loco Team Portal and Summit know, we use login.launchpad.net as our open id provider. I believe the future is to use login.ubuntu.com. It is more consitent in terms of design, and is the exact same code as login.launchpad.net but with different configuration and theme.
We have bugs for both the projects to switch to login.ubuntu.com, but it isn’t really easy because login.ubuntu.com configuration is actually more stricter. We can’t login from it locally, i.e., it will not pass on my credentials back to my app if I’m running my app on 127.0.0.1. The ISD team suggested that I just run SSO locally and do my testing. After running Launchpad, what could be so hard right? Famous last words 😉
I fetched the source of SSO and started the bootstrap as the instructions said. It failed because some of the configs were in a private branch. With much hair-pulling, head-desking, and lots of help from David and Ricardo, I finally got it running last week. One of the main problems of doing this was the configuration for SSO are not stored in the ‘django way’ of things. It’s stored as .cfg files with some configglue magic. Configglue wasn’t originally open-sourced and thus the configs were private. The other problem was my inexperience with postgres 🙂
After configglue was open-sourced, the configs still sat in a private branch because nobody got around to fixing the bootstrap process, until last week. On Friday, Ricardo finally gave me the good news!. The bootstrap process is now fixed so that community members can actually run SSO without hair pulling. We can now easily work on doing the transition from login.launchpad.net to login.ubuntu.com
2011-06-19
Landing with tarmac
I heard about Tarmac a few weeks ago when Shane mentioned it in one of his intern diary blog posts. At that point I didn’t actually look into it much since I thought it was something that’s internal to Canonical. Last week, Michael Hall told me about Tarmac again and how they use it to land branches. This time though, I could grasp what it was since it sounded to provide a functionality Launchpad’s PQM. Every time Tarmac is run, it checks for approved branches that are ready to land. If it finds that they satisfy the conditions (optional) that are defined in its config, it lands them. (It can do more, please read the documentation for that).

I’m now running Tarmac for both Loco Team Portal project and the Summit project The really cool commitmessage plugin allowed me to define how each commit should look. I’ve formatted it in a way easy to figure out how did the review and who authored the change, and which bugs it fixed. If you want to see how it looks like, checkout the last few commits for summit. I did find a bug in tarmac documentation for which I now submitted a merge request 🙂
2011-06-11