Those are my two simple rules for prioritizing work. It’s up to you and your team to determine how you measure business value and risk.

Check out http://strfti.me and let me know if you find it useful!

It turns out that, out of the box, Sass updates the “compiled” stylesheets on every request unless you’re running in production mode. This is really handy in development when you’re making incremental edits in a .sass file and refreshing the browser to see the results, but it’s completely unnecessary when running tests since the .sass files aren’t changing while the tests are running, and chances are your functional tests aren’t dependent on any CSS files anyway.

To change this behavior in our test environment, we added the following to config/environments/test.rb:

Now Sass will only compile the stylesheets once (the first time one is needed), and our entire test suite is about 60% faster (YMMV).

If you’re bored, check it out.

We’re also looking for an experienced QA engineer to keep us honest and help us with automated acceptance/regression testing, among other things.

To get you psyched up about coming to work with us, I thought I’d share a little about our team, our culture, and how we get things done.

We have a couple of amazing designers on staff, Kate and Scott. We get to bring their works of art to life. Kate has lots of insight into usability and user testing, and Scott brings a wealth of knowledge about visualizations (and he paints astronauts, which is awesome).

We still support IE6. Yeah, that sucks, but a good chunk of our users (mostly patients) still use it. Lucky for us, Cris and Adam know all the tricks. Semantic markup, IE hacks, accessibility… we’ve got it all. Well, except mobile, but that can change.

We do all kinds of crazy, awesome things in our free time. You already know about Scott’s astro-art. I created Twackit to play around with the Twitter API. James created a really cool visualization of the MBTA system. Steve is a Solar System Ambassador for the NASA Jet Propulsion Lab and a school committee member. Jeff “Mav” Dwyer wrote a book about GWT (don’t worry, we won’t make you read it) and hands out Google Wave invites like they’re candy. Rich helped Dan Cederholm (yes, the Dan Cederholm) build Dribbble, and he barely beat me in the finals of our Darts Madness tournament. Joe, Kate and I helped get HealthDataRights.org off the ground. Joe, Steve, Cris, and I participated in last year’s Rails Rumble and launched The Quest for Life. I’m sure I’m forgetting someone or something, but that should give you an idea of how we roll.

Also, everyone loves Star Trek IV but me — that’s the one where they go back in time to save the humpback whales, which is stupid.

We have an in-house research team that sometimes makes me feel like I don’t know shit about shit. The stack of journal publications and presentations of their research can probably be blamed for most of the deforestation of the past 10 years. Our researchers help us figure out what data is interesting to patients and what’s interesting for research purposes, and they make sure we ask the right questions the right way (something about science and bias and blah blah, etc.).

Everyone has a MacBook Pro and an external monitor. We use VirtualBox to do IE testing. Some of us commute from out of town so we usually telecommute a couple days a week, but we stay in touch with IM and Campfire.

We use Git for version control. It’s pretty awesome. It’s super-easy to work on branches. We’re always creating remote branches to work on new features in isolation, and short-lived local branches for quick bug fixes.

We release in 2 week iterations. Fast enough to get stuff out, not so fast you lose track of what’s going on.

There’s still a lot of legacy stuff that uses ERB and regular CSS, but all our new stuff is Haml and Sass.

We have dartboard that gets a lot of use, a Nintendo Wii (with Rock Band, of course), and we’ve been known to watch an episode of Star Trek or a certain movie featuring The Dude after work while we sip White Russians (or Caucasians, if you prefer). Three desks double as a conference room table which doubles as a ping pong table, and lo the balls fly furiously.

It’s rare to find a job that’s challenging, fun, or makes a difference in people’s lives, but PatientsLikeMe offers all of that in one place. A really great perk of working at PatientsLikeMe is that we have an opportunity to improve the lives of real people — thousands of patients with life-changing conditions. They’re a very involved user-base, with no shortage of ideas and feedback.

Oh, and we have direct deposit! You gotta have direct deposit.

I leaned on MacPorts to install Git, Ruby, RubyGems, PostgreSQL, and some other stuff that my Rails work depends on.

Xcode and MacPorts

1. Install Xcode from OSX DVD.
2. Install MacPorts via http://www.macports.org/install.php

Git

1. sudo port install git-core +svn+bash_completion+doc

To configure Git, including some handy aliases, add the following to ~/.gitconfig:

[user]
email = {your@email.com}
name = {Your Name}
[core]
editor = mate -w
[color]
status = auto
diff = auto
branch = auto
[alias]
co = checkout
st = status
ci = commit
df = !git diff | mate
[push]
default = tracking

To enable bash_completion, add the following lines to the end of your .bash_profile or .profile:

if [ -f /opt/local/etc/bash_completion ]; then
. /opt/local/etc/bash_completion
fi

Ruby 1.8.7 and RubyGems

1. sudo port install ruby
2. sudo port install rb-rubygems

(Note that gems will be installed to /opt/local/lib/ruby/gems/1.8.)

Symlink /usr/local/bin/ruby to MacPorts install

1. sudo ln -s /opt/local/bin/ruby /usr/local/bin/ruby

ImageMagick and RMagick
http://rmagick.rubyforge.org/install-osx.html

1. sudo port install imagemagick +gs +q16
2. sudo gem install rmagick

PostgreSQL 8.3
http://shifteleven.com/articles/2008/03/21/installing-postgresql-on-leopard-using-macports

1. sudo port install postgresql83 postgresql83-server
2. sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
3. sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
4. sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb’

And so that pg server launches at system startup…

1. sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist

PostgreSQL Ruby adapter

1. sudo env ARCHFLAGS=”-arch i386″ gem install postgres — –with-pgsql-lib=/opt/local/lib/postgresql83 –with-pgsql-include=/opt/local/include/postgresql83

Sphinx

1. sudo port install sphinx +postgresql83

Common gems

1. sudo gem install rails fastercsv redgreen git_remote_branch capistrano capistrano-ext ruby-debug ruby-prof sqlite3-ruby

SSH key

1. ssh-keygen (Enter to select all defaults)
2. Add public key to GitHub account.

Git is awesome. If you’re using it, you know what I mean. If you’re not, don’t be afraid to give it a try! Git is the gateway to a new generation of code sharing on GitHub and convenient deployment to Heroku. It’s built around fast branching, so it’s really easy (and did I mention fast?) to create and throw away experimental branches.

I’m pretty new to Git. I used it a bit in the past (with GitHub) but hadn’t really gotten into it until the past month or so when we made the switch at PatientsLikeMe from Subversion. It took me a couple of weeks to really understand what was going on, feel comfortable, and settle into a rhythm and workflow. This post will probably be old news to Git veterans, but I think there are enough Git noobs still out there that some will find this interesting or valuable (let me know if you’re one of them!).

Here’s how I use Git day-to-day, whether for new feature development or fixing bugs:

A. Work in a local branch

1. git checkout -b dev-branch-name (to create and switch to a local branch, where “dev-branch-name” is something meaningful)
2. Do some awesome (more or less) work.
3. git status, git add, git commit -am “Something about what I did”

B. Integrate with the latest

1. git checkout master
2. git pull (gets the stuff my teammates have pushed)
3. git checkout dev-branch-name
4. git rebase master (integrates my work with my teammates’)
5. Run the test suite.

C. Merge with the rest of the team

1. git checkout master
2. git merge dev-branch-name
3. git push

It looks like a lot of steps and a lot to remember, but you can automate much of it if you’d like to save some keystrokes. I still like to go through the motions. You could use a simpler, more traditional (read: SVN) workflow, doing all of your work in master, but then you’re missing out on a lot of the benefit of Git.

To make git a bit more user-friendly, I set up most of the aliases suggested by Justin French, so I actually use “git co” for checkout and “git ci” for commit, and I have a git completion bash script set up so that I don’t have to type out full branch names.

Switching between master and various local branches can get a bit confusing. To keep myself on track, and to try to avoid working in the wrong branch, I set up a shell prompt that displays the current branch for the git-aware working directory that I’m in. Here’s the actual prompt I’m using:


function parse_git_branch
{
ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
echo ${ref#refs/heads/}
}
export PS1='\[\033[0;34m\]\A \[\033[00m\]\w \[\033[01;31m\]$(parse_git_branch)\[\033[00m\] $ '


I’ve also started using grb to make working with (read: tracking) remote branches easier. It’s easy to install and has good documentation to get you started. Then there’s GitX, a powerful tool to browse your repository and to see which code is on what branches. I don’t lean on GitX as much as I could, but it comes in handy.

There’s a lot about Git that I still need to learn, so please leave a comment with your tips and tricks.

There’s some basic content and reports are generated from the data you tweet to @twackit. I’ve gotten some good feedback, and a couple people are already using it for things I never thought of, which is really cool! I wanted to get something simple up and running and try to get people using it, then see what kinds of requirements shake out from real-world use cases.

Since this is a Rails-oriented blog, I thought I’d share a few technical details:

1. Twackit is running on Rails 2.3.2, the current stable version.
2. I’m using SQLite3 for development, but Heroku ignores your database.yml and uses Postgres, which is cool with me.
3. It’s hosted on Heroku, which was very easy to set up in part because…
4. I’m using Git for version control. The code is not open source (at least not yet), and I’m only using a local repo, so no GitHub.
5. I used Haml for the layout and views, except for a few partials that encapsulate HTML and Javascript for third-party stuff, like Google Analytics and UserVoice. I just pasted their code into ERB templates.
6. The reports use the Google Visualization API for things like the Annotated Time Line, which is really cool but not very useful until you have a lot of data. (So start adding data, everyone!)
7. The Annotated Time Line wants Javascript Date objects. Unfortunately, Rails implements Date#to_json to return a String representation of the date, so I ended up hacking it to build a String of the form “new Date(year, month, day)”. I’ll keep looking for a better way.
8. I used John Nunemaker‘s Twitter gem to call the Twitter search API and to get the user’s name and photo URL to make the report a little prettier.
9. Twackit searches for new tweets every hour or so. To support very basic background jobs, Heroku invokes a rake task named “cron” (which I think is a terrible choice because of the name collision, but at least it’s intuitive).
10. The cron rake task records some stats about each cron import, like how long it took, how many tweets were imported, and for how many distinct users. The task finishes in less than a second, since there isn’t much data coming in (yet!).

So please check Twackit out and let me know what you think. And of course, tell everyone about it!

http://tinyurl.com/api-create.php?url=http://www.myreallyreallylongurl.com/its-really-long

renders a response like:

http://tinyurl.com/8y94xz

I recently created a Ruby on Rails plugin called tinify_urls that encapsulates this kind of thing, supporting the TinyURL, SnipURL, and is.gd APIs. The plugin has been tested against Rails 2.1.

I’m looking forward to feedback so let me know if you have a chance to try it out. To install the plugin:

script/plugin install git://github.com/jeremyw/tinify_urls.git