We here at Imulus have spread our wings a bit and decided to get into the Rails game. I have had a crush on Ruby for a long time, causing me to jump on the Rails bandwagon when version 1.0 was in beta. I fell off the wagon before Rails 2 came out, being consumed by development work that wasn’t on the web. When Rails 3 and then Rails 3.1 came out with great support for unobtrusive javascript as well as the asset pipeline, several of us started to get involved again.

We’ve been wanting to continue work on Support Details for some time now. Since it was in .NET sitting on top of a homegrown CMS that it really didn’t need to be coupled to, our frontend developers had trouble moving forward on it. As a lark, I decided to port over the site to Rails. The main functionality was done in a couple of hours and we managed to iron out most of the other main points in spare hours over the next few days. We decided to update some of our detection to be way more accurate, and that took a few more days, but we can now tell if you are on Windows 3.1 running NCSA Mosaic

We didn’t want to stop there though. We were very excited about using CoffeeScript and Sass in the new Rails 3.1 asset pipeline to create readable code that could generate our Javascript and CSS. Taylor and Casey jumped onto migrating the existing Javascript and CSS over to using CoffeeScript and Sass. After running through the asset pipeline which would combine and minify our Javascript and CSS we had significantly reduced our asset download size.

While that was a great first step, we wanted to go further and make Support Details even faster. We started by using Delayed Job to send e-mails on a background queue, rather than tying up the main web thread. Then we decided that we wanted to take advantage of a CDN and so we used the excellent Asset Sync gem to compile and deploy our assets to Amazon S3/Cloudfront when we pushed to Heroku. After all of these changes our initial page load time was cut by more that half.

But wait, there’s more. We’ve had many requests to localize Support Details for different languages. Thanks to the support of various friends of Imulus, we are pleased to offer Support Details in Japanese, Russian, Italian and Portuguese. We plan on adding more languages in the future, and if you want to help in translation please feel free to give us a holler and we can send you a list of phrases we need for the translation.

We have a lot more planned for Support Details, and we have some more great Rails applications in the pipeline which we should be releasing for your viewing pleasure in the near future.

For a few internal projects at the Imulus office, we’ve been collecting timesheet data from the tracking software we use, ClickTime. Lucky for us, they offer an API with full access to all of our data. Unfortunately, however, it’s a SOAP API.

SOAP can be a bear, so we’ve rolled some code to help alleviate the pain of working with it:
a Ruby wrapper and a JavaScript wrapper. Both are open source, and we hope they make your life easier. Below are some examples of how to use them.

Ruby

The Ruby wrapper (ruby-clicktime) comes in the form of a single file with one class, ClickTime.

Requirements

ruby-clicktime uses Savon, so be sure to install that first:

$ gem install savon

Usage

The ClickTime class has two methods:

ClickTime#actions will return a list of all actions available to the ClickTime SOAP API

clicktime.actions  # un_sync_all, get_sync_id, set_sync_id, ...

ClickTime#exec will execute an API call and return a hash of results

clicktime.exec :api_action, {params}

Example

First, create an instance of the ClickTime class:

require 'clicktime'

clicktime = ClickTime.new :key => 'api-key', :password => 'password'

The GetEmployeeList and GetClientList API methods, as defined in the ClickTime API docs:

<GetEmployeeList xmlns="http://clicktime.com/webservices/2.2/">
	<UserID>string</UserID>
	<ActiveOnly>boolean</ActiveOnly>
</GetEmployeeList>

<GetClientList xmlns="http://clicktime.com/webservices/2.2/">
	<UserID>string</UserID>
</GetClientList>

To execute these queries, you would call the following:

employees = clicktime.exec :get_employee_list,
    {"UserID" => 'your-user-id', "ActiveOnly" => 'true'}
clients = clicktime.exec :get_client_list, {"UserID" => 'your-user-id'}

Notice the action is passed as a snake_case symbol from the list of available actions. (clicktime.actions to list them)

JavaScript

The JavaScript wrapper is a CommonJS module, ready for use in your Node.js project via npm.

Installation

In your project:

$ npm install clicktime

And in your script:

var ClickTime = require('clicktime');

Example

First, create an instance of the ClickTime object:

var clicktime = new ClickTime({
  key: 'your-api-key',
  password: 'your-api-password'
});

The GetEmployeeList API method, as defined in the ClickTime API docs:

<GetEmployeeList xmlns="http://clicktime.com/webservices/2.2/">
  <UserID>string</UserID>
  <ActiveOnly>boolean</ActiveOnly>
</GetEmployeeList>

To execute this query you would call the following:

clicktime.exec('GetEmployeeList', {
    UserID: 'some-user-id',
    ActiveOnly: true
  }, function(response){ // your callback function
    console.log(response);
  }
);

Reference

Source code:
ruby-clicktime on GitHub
node-clicktime on GitHub

ClickTime SOAP API Documentation:
http://app.clicktime.com/documentation/webservices/2_2/WebServicesDocumentation_2_2.asp

After patiently waiting for their arrival, Taylor and I received our new SSDs yesterday. Rather than migrating our data over from our old disks and potentially cheapening the solid-state experience, we both opted to start with a fresh slate. (By all accounts, he’s a glutton for reformatting his system. It’s a hobby of his.)

I was reluctant, mostly in anticipation that I’ll want to start fresh again in a few months when OS X Lion is released. Having just started on this machine a few months ago, I’m also keenly aware of how long it takes to get a system up and running and configured to my tastes.

Out of both curiosity and to make it easier on myself in the future, I decided to keep track of my installation and configuration process.

In roughly the right order:

• Google Chrome

  Faster than Safari

• Sparrow

  Sexier than Mail.app

• Adium

  Smarter than iChat

• Twitter

  Better than the browser version

• Growl

  Alerts FTW

• Stacks

  Group task management finally makes sense (shameless plug)

• TextMate

  My editor of choice. (See also: http://wastm2released.com/)

• Transmit 4

  Gotta move stuff

• Adobe CS5 Web Premium

  (Wow, they’re really pushing 5.5)

• Alfred

  Because I only used QuickSilver to launch applications

• Clyppan

  Clipboard manager

• xScope

  Clutch for UI development

• Sequel Pro

  MySQL database management

• Base

  SQLite database management

• CoRD

  RDP client

• VirtualBox

  Virtualizer

• Windows 7

  I know, I know.

• Xcode 4

  It took 7 hours to download from the App Store

• Homebrew

  Package manager

• Git

  DVCS

• Mercurial

  DVCS (Yes, we use both.)

• RVM

  Ruby version and environment manager

• Ruby 1.9.2

  Upgraded from 1.8.7 that ships with OS X

• Rails 3.1.2

  Upgraded from 2.3.5 that ships with OS X

• Node.js

  Server-side JavaScript

• NPM

  Package manager for Node

• iStat Menus

  I like to keep an eye on my CPU and RAM

• SuperDuper!

  Drive cloning

• YouControlTunes

  iTunes controls in the menu bar

• Alarm Clock 2

  Waking up has never been more miserable

• Fliqlo

  A huge clock screensaver

We’re currently in the process of switching from Subversion to Mercurial, and while the process has gone well so far, we’ve run into one issue that required a bit of investigating. It turns out that Mercurial and Git don’t track empty folders. To a certain extent, this makes sense, but when it comes to working with a CMS that creates empty folders which will eventually be filled, this can be troubling. Furthermore, our static framework provides a starting point for organizing images which is made up of multiple empty folders. We need these to be tracked to make sure everyone uses the same structure.

The Solution

Luckily, it’s relatively easy to get around this limitation by adding dummy files to your empty directories. Once these dummy files are added to the repository, their “empty” parent folders will also be tracked.

Looking around, it seems that a lot of people advocate adding .hgignore files to empty folders since those are commonly used anyway, but personally, I think that may cause some headaches down the road; if we’re not actually ignoring any files, they’re unnecessary, and may cause confusion. In addition, once those folders actually contain some files, it’d be nice to remove the blank files to keep things tidy.

For this reason, I’d suggest having your team standardize on a dummy file naming convention, such as .hidden or maybe something a bit more unique like .imulus or .unicorns. That way, we can later recursively delete these files without fear of deleting something important, like .hgignore files.

Taking it a Step Further

Once we figured out how to track empty directories, it was only natural we figure out a way to automate the process of adding blank files. Luckily, Ernesto Méndez has written a Python script to do it for us, and setting it up to use is very simple.

Getting Started

While his site provides a decent rundown on how to use the script, I’d encourage you to take the extra step of copying it to /usr/local/bin and making it executable. Once you do this, you’ll be able to run the script from inside any folder.

To begin, fire up Terminal and copy the script to /usr/local/bin. If you’d like, you can remove the .py extension as I have. You’ll be asked to enter your password.

sudo cp hg-touch.py /usr/local/bin/hg-touch

Next, we need to ensure that it is executable:

sudo chmod u+rwx /usr/local/bin/hg-touch

And that’s it. Now we can run the script from inside any folder and recursively add .unicorn files to every empty directory. Let’s take a look at some examples:

Creating Dummy Files

The following example will create .unicorn files in any empty directory found in the static-framework directory:

hg-touch -p static-framework .unicorn

Removing Dummy Files

Once we’ve added some real files to those directories, we can run the command to remove all the dummy files.

hg-touch -r -p static-framework .unicorn

Be extra careful when using this command to make sure you are removing files you truly know are no longer needed. You will not be prompted to confirm.

Wrapping Up

Although we’ve decided that Mercurial is best suited for us over Git, this script can just as easily be used for tracking empty directories in a Git repository as well. In fact, I’ve used it this way a few times already. You could even rename the script to git-touch if you’d prefer.

Although I haven’t found any real issues with the script, it would be nice to expand upon it and add some features. One that comes to mind is the ability to define a standard dummy file name, yet maintaining the option of overriding it. Surely this would be a relatively simple fix, and the source code is available should you be up to the challenge.

For a long time here at Imulus we had trouble keeping track of internal company information. Client datasheets, software licenses, Imulus specific programming tips, bug tracking, email setup documentation, employee calendar links, etc. This problem was not something isolated to just us, every work environment I’ve been a part of has struggled with documenting and finding information. Generally the solution ends up being a massive repository of excel documents or a shared hard drive full of text files and snippets. Neither of these solutions are practical or scalable.

Our answer to this problem was an internal company wiki. Our goal was to have a central resource that was easy to update and easy to get information out of. It needed to be searchable, easy to edit, and secure. Being a .NET shop we decided to go with ScrewTurn a free open source wiki for .NET environments. A few other alternatives are: Wordpress plugins and hosted solutions such as pbwiki.

We’ve been using this solution since last August and it has been a huge time saver. Our project manager no longer gets flooded with requests for, “that spec requirement the client sent over,” and our programmer’s no longer have to use local text files to keep track of bugs in their code.