• I'm still alive, and on FriendFeed and Twitter

    Wow, it seems like I haven't posted anything this year. Don't worry, you aren't rid of me yet. I'm still alive and posting updates to FriendFeed and (less often) to Twitter.

    If you belong to what I imagine must be now the microscopic population of loyal readers of my blog, please do hook up with me on FriendFeed or Twitter. I'll follow you back if you're a reader!

  • Dragging tab to a new window coming to Firefox

    Completely by accident, I discovered that you can now drag a tab out from its current window to a new window in a recent Firefox nightly. A short video 24-second better explains what I'm talking about:

    This tab tearing capability is a pretty neat feature - I know you can already do this in Safari, Opera and Galeon. It's really well done in Safari, which I think is what Firefox is emulating. Nice to see Firefox follow suit!

    If you can't wait for Firefox 3.1, try it out in a recent Firefox nighty build (remember to use a new profile unless you are willing to risk corrupting your daily profile).

  • Optimize Firefox's memory usage by tweaking session preferences

    I'm a heavy tabbed browsing user - I have around 30 tabs open in my day-to-day Firefox profile all the time. Since the day Firefox 3 was released, I've noticed Firefox progressively getting slower with this particular Firefox profile (I use a different profile for web development). When it got to the point where changing tabs took a noticeable pause of 1-2 seconds, I tweaked some of Firefox's session store and history preferences and now things are blazing fast again.

    Here's what you can do:

    1. Go to about:config in Firefox.
    2. Type in "session" in the "Filter" box.
    3. Edit browser.sessionhistory.max_entries - this is the number of pages stored in the history of your browsing session. Basically these are pages that can be reached using your Back and Forward buttons. The default is 50 - I reduced it to 20.
    4. Edit browser.sessionhistory.max_total_viewers - this is the number of pages that are stored in RAM so that they aren't re-processed by Firefox's rendering engine. This is what allows you to go Back to a page in Firefox and have it load almost instantaneously. The number of pages stored actually depends on the amount of RAM on your machine (see this). I reduced this to 4 (I have 2GB RAM).
    5. Edit browser.sessionstore.max_tabs_undo - the number of tabs you can restore after closing them (you can do this with Ctrl/Cmd-Shift-T). The default of 10 is more than I really need, so I reduced it to 3 tabs.
    6. Edit browser.sessionstore.interval - Firefox saves your session after every 10 seconds by default. I changed this to a more conservative 30000 milliseconds.

    You can read more about these preferences and more at the MozillaZine Knowledge Base. If you've any tips on how to improve Firefox's performance, be sure to share!

  • Sass with Rails - avoiding disappearing stylesheets in production

    A few days ago I noticed that some of the pages on the Hotels app on wego.com were completely unstyled. They turned out looking rather Jakob Nielsen-istic:

    Wego.com Hotels - no CSS


    But we were attached to our ugly shade of green to leave those pages in their naked glory. Preliminary CSI work told me that some cached stylesheets generated by Rails were empty files. Why is this is happening?

    stylesheet_link_tag and the :cache option

    Was I overriding the stylesheets generated by Rails in different pages? Because we have a lot of cobranded sites and country sites on wego.com, I use the :cache option when using stylesheet_link_tag very often.

    For example, the main wego.com site's layout template has a stylesheet_link_tag like this (in reality there are a whole lot more stylesheets):

    <%= stylesheet_link_tag 'yui/reset-fonts', 'search',  :cache => 'cache/search/listings' %>

    When I need to make a new page for a cobranded site, I'll create a new layout template with this:

    <%= stylesheet_link_tag 'yui/reset-fonts', 'search', "sites/#{current_site}/cobrand", :cache => "cache/#{current_site}/search/listings" %>

    Oftentimes I'd copy and paste (boo and hiss all you want!) the stylesheet_link_tag from one layout template to another and forget to update the cache path (the :cache => '/path/to/stylesheet' part). Two different stylesheet sets being cached to the same path is naturally a very stupid thing to do. So this wasn't it, but it's good to point this out because I have made this mistake at least 2 times!

    Don't check in generated CSS files by accident

    Next, since I was using Sass, I was by now pretty sure that was it. First things first: did I check in a generated CSS file into source control (we use Git)? It's another amateur mistake, but unsurprisingly, I've done this a couple of times. I think I'd wasted about an hour hunting down the reason for a style change that just wouldn't show up. Yeah, I could have just added *.css to .gitignore, but I'm still using a mix of pure CSS and Sass templates.

    The problem

    In the end, I found this blog post by Ari Lerner on the CitrusByte blog about similar woes with Sass in production that set me on the path to a solution. It seems that when Rails encounters stylesheet_link_tag calls, it starts to pull together all the stylesheets and sometimes Sass is unable to generate the CSS files fast enough. Rails then throws an exception about not being able to find the CSS files and outputs an empty CSS file to the cache path.

    The solution

    The solution? Generate all the CSS files from Sass templates prior to restarting Rails when deploying. I added a rake task for updating all the Sass stylesheets:

    namespace :sass do
      desc 'Updates stylesheets if necessary from their Sass templates.'
      task :update => :environment do
        Sass::Plugin.update_stylesheets
      end
    end

    Then, I created a mirror of this as a Capistrano task:

    namespace :sass do
      desc 'Updates the stylesheets generated by Sass'
      task :update, :roles => :app do
        invoke_command "cd #{latest_release}; RAILS_ENV=#{rails_env} rake sass:update"
      end
    
      # Generate all the stylesheets manually (from their Sass templates) before each restart.
      before 'deploy:restart', 'sass:update'
    end

    Now, whenever I do a cap deploy, the stylesheets are generated before the Rails processes are restarted, ensuring that Rails' stylesheet_link_tag helper is always able to find the pure CSS files when trying to merge them together and caching them to a single file.

  • Reveal currently open files in Mac OS X

    Something I noticed completely by accident today when I clicked on the titlebar of QuickTime Player today with the Cmd key held down. The "titlebar" is this thing here - I'm not sure that's the right name for it:


    Anyway, if you hold down the Cmd key (aka the Apple key), a menu pops up that shows the folder hierarchy of where the currently opened QuickTime movie is in your filesystem:


    This works in all Mac apps that display the filename of the currently open/focused file in the titlebar.

    It's useful for me since my NADD means I try to close as many unused windows as possible to adhere to my Cmd-Tab diet - now I can close Finder windows after opening files and be sure that I can get back to them quickly. What about QuickSilver? Yup, I do use (and love) QuickSilver but I don't let it catalog every single file!

    Another nice thing about this is that I can easily reveal files in Finder in my favorite text editor (TextMate) without needing to use the project drawer:


subscribe via RSS