Nigel Babu

Blog

  • 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.

    A Sign of the Times by NazarethCollege

    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.

    Screenshot of Input

    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.

  • 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.

  • Lighting Talks at UDW

    Since the last Ubuntu Developer Week, we’ve been having a session dedicated to project lighting talks, if you have an interesting project that you’re working on, talk about it for 5 minutes. Show case your project and maybe ask for new contributors in this quick 5 minutes per project session! If you’re interested, please add your name and project name to the Lightning Talks page or come find me in #ubuntu-devel or #ubuntu-motu and let me know. I’ll add you to the list!

  • 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!

  • Git and Bash Love

    I’ve recently been working with git a lot, more specifically with branches. I love git’s branching and its fairly awesome. However, its also easy to forget which branch you’re currently working on (especially awful to find that the commits you did were to master :/). Sometime back I did some extensive searching to fix that situation and finally stumbled upon a neat way to fix it. I modified the PS1 variable to show the current branch! Here’s what I added to the .bashrc file in Ubuntu 🙂

    function parse_git_branch {     ref=$(git symbolic-ref HEAD 2> /dev/null) || return     echo "("${ref#refs/heads/}")" }  RED="[33[0;31m]" YELLOW="[33[0;33m]" GREEN="[33[0;32m]"  PS1="$PS1$RED$(date +{13371f13f0bf161e7595c2ac5df92e005bed3de1d132ef646d0a44f3a1a9ee62}H:{13371f13f0bf161e7595c2ac5df92e005bed3de1d132ef646d0a44f3a1a9ee62}M) w$YELLOW $(parse_git_branch)$GREEN$[33[0m] "