I sometimes forget to check the site so I setup an automatic twitter feed to send me reminders. Was very easy to do …

The toughest thing about Heavens Above is remembering to check it frequently. This got me thinking – “wouldn’t it be nice if I got a text message about 10 minutes prior to a pass?”. After thinking about it and looking around on the heavens above site, I concluded there wasn’t any api or service I could coax to do this, I decided to write a quick and dirty script. I also found an blog describing some work that Paul Mison had done at Hackday London a few years ago. (I rarely have unique ideas…). The gist is this, periodically, check for ISS passes over a particular location (Richardson, Texas in this case) and within about 15 minutes of the event, send an update to twitter listing time and starting location (sky direction). I then could follow this twitter account (with mobile updates on) and now I can get notifications about when to look up and wave to our brave ISS crew (I even saw the ISS through the glare of lights at a high school football game).

The script is written in ruby and is setup to run as a cron job on one of my servers. It uses specific latitude and longitude and time zone to pull visible passes for the ISS from heavens above. It grinds up the html using Hpricot and looks for any passes with a magnitude greater then -1.0 (our seeing is better than that in Richardson but I wanted to limit the number of tweets. To reduce the number of hits on Heavens Above, the script caches the information in a config file and only returns to heavens above when it has tweeted about an event. The specifics of lat/long and twitter account are stored in a config file so this can be used for other locations as well. I’ve posted the hack on github.

If you live in/around Richardson, you can follow the richardsontxiss twitter account and it will send you tweets when you can see the ISS. It doesn’t take weather into account, but we are more likely to have clear weather than not. The next passes aren’t until the 24th so be patient if you do follow this. They do have gaps in time where there are few passes but then there will be a storm of great opportunities within a few short days.

If you are wondering what your latitude and longitude is, there is a nifty hack you can use to get it from a google map. Center the map on your location and enter the following in the browser url line:

javascript:void(prompt('',gApplication.getMap().getCenter()));

This will prompt you with the coordinates of the currently centered location on the map. Cool.

So I played around with the settings and ended up with this config which (knock on wood) seems to work pretty well.

I started with the following versions:

1. Leopard 10.5.8
2. ZenTest 4.1.4
3. Growl 1.1.6
4. autotest-growl gem 0.1.6
5. autotest-fsevent 0.1.1
6. autotest-rails 4.1.0

I didn’t need to make any adjustments to the growl configuration (via System Preferences) as reported in some solutions.

I added the following to the ~/.autotest file

require 'autotest/growl'
require 'autotest/fsevent'
Autotest::Growl::show_modified_files = true
Autotest::Growl::remote_notification = false
Autotest.add_hook :initialize do |at|
%w{.git .svn .hg .DS_Store ._* log}.each {|exception|at.add_exception(exception)}
end


I added some appropriately named images to the suggested ~/.autotest-growl directory per the really good (don’t skip over them, lots to learn if you have used an older config) instructions.

I then renamed the growlnotify app in /usr/local/bin to /usr/local/bin/growlnotify.wrapper (make sure it is executable with chmod if needed) and added the following wrapper (taken from Craig P Jolicoeu’s suggestion) as /usr/local/bin/growlnotify


#!/bin/bash
exec /usr/local/bin/growlnotify.wrapped -w "$@" &


That was it, autotest (and other apps) growl everytime now. Pretty easy (after I tried three or four other things that didn’t work). It seems the networked approaches with -H and other configs didn’t really work for me. The simplified wrapper seems to be all that is needed.

The other reported issues about growl not working if configured near the dock didn’t seem to cause me any issues (dock is on the bottom, growl is lower left).

Now my little robot friend (autotest) keeps me honest without fail.

Hope this helps.

Showing up to a meeting late.

The thing I like about scrum is even though we meet daily, we end up with fewer planned meetings (lots of ad-hoc white board sessions but they are very focused and productive). The thing I don’t like about scrum is having to wait for 5 or 10 minutes for the team to assemble. Sure there are things you can try and do to stop this behavior. I hate the idea of a ‘late jar’ where you contribute $1/minute you are late (donated to charity or food for the sprint review, etc) because if you agreed to attend a meeting at a certain time, then get there on time. On high performing teams, this isn’t as much of an issue. In some of the dysfunctional teams I’ve worked on, this is chronic.

I suggest that if you have 10AM meeting, then at 9:58, head over to the meeting rather than wait until 10:05 to go. Sure, you’ll wait around for 30 seconds or so but at least your team won’t be waiting on you.

Should be low-hanging fruit but is never seems to get picked.

I can’t wait to go back to the Mac but at least I can be more productive while I’m slumming in Vista. The LONG delay on starting ruby processes (like tests, console, etc…) is sapping my will to live tho…

The info on rails and emacs on the web was pretty good but if someone wants my formula, I’ll be glad to post it.

Assuming you have a bunch of web applications and a few common infra components. All of the web applications would have had the same (more or less) build file so you could refactor most of it into a common_build.xml. Since we were using ant 1.5X we used the little XML include trick to declare and use a new element. This lets the XML parser do the work of inserting the xml fragment into our build scripts.

For example, a web application’s build script would start like this.


<?xml version="1.0"?>
<!DOCTYPE project [
<!ENTITY common SYSTEM "file:../../common_build.xml">
]>
<project name="defects" default="build" basedir=".">
&common;
<!-- other ant properties and targets go here... -->
...


The common build script looks like this (it is only an xml fragment).


<property file="local_build.properties" />
<property file="../local_build.properties" />
<property file="../../local_build.properties" />
<property file="build.properties" />
<property file="../../common_build.properties" />



<property name="log.template.file" value="template_log4j.properties" />



<path id="master.classpath">
<pathelement location="${target}" />
<fileset dir="${lib}">
<include name="*.jar" />
</fileset>
<fileset dir="${target}">
<include name="*.jar" />
</fileset>
</path>
...


If this were setup in a directory structure like the following, you could apply this include trick in each of the webapps build scripts.

The common_build.xml is located in the root of the project. The webapps (for example, app1) have a build script that includes it. The build script in the webapps directory simply knows how to build each app. The core and common components probably don’t include the common_build.xml because they do something significantly different.

This approach works very well for situations where you need to build more than two very similar components. It isn’t a perfect solution tho as the syntax is somewhat confusing and not very intention revealing.

I should note, that I didn’t invent this but I can’t remember where I saw this used first. It was likely on an Apache open source project. It is now mentioned on the Ant FAQ.

Also, since Ant 1.6, there is a new <include> task which is even more flexible since it lets you use ant properties in the file name. This approach is much better than the xml trick.

Reusing build script fragments is a great way to DRY up your configuration and ensure more consistency.

I started added audits for my model associations. This went well until I wanted to audit a has and belongs to many (HABTM) association which as you know, doesn’t have to have a backing model (it simply relies on a join table that is named a particular way). Sigh. On a few HABTM as sociations, I actually had a model but our smarted myself (and followed an older web recipe) and created the model without id’s.  These associations do not work with this plugin.

No way to get there from here exept to convert HABTM to has many through. Further evidence why HABTM is shortcut that only leads to pain later if you need to extend the associations (like adding audit trails).

Avoid HABTM and your life will be better…. just imagine having to convert 10 or more association tables to models on a production system that has 1000’s of parent objects. You see any fun in that? The superstitious would call how HABTM handles join objects as ‘magic’ which isn’t really very accurate. It is simply a conventional shortcut. My big problem with it is the lack of flexibility it gives you – it is one of those box-canyon paradigms that is hard to get out of.

Oh and another note, if you add acts_as_audited to your project late in the game, you may run into problems with migrations if any migrations load data. The reason is a fresh checkout will bring the audit code which will perform audits even on migrated data and since early migrations don’t have the audit table loaded yet (it is a later migration), you can’t migrate data. Sure you can just do a rake db:schema:load but that will leave you without some of your migration data.

An easy solution is to simply rename the acts as audited migration to be your first migration (mung the date in the file name). This tricks the migration to run first and all should be fine… Note, this even works if you have previously migrated and then do an update to get this new ‘old’ migration – the migration still runs even though it is out of sequence thanks to the schema_migrations table which keeps up with what migrations have been run.

Part of the benefit of working with rails projects is the speed with which you can refactor and scaffold your way into different configurations. This can sometimes get you into trouble if an experiment or plugin doesn’t work. The best solution I’ve found for this is to ALWAYS initialized your fresh rails project into a git repository. This is like having infinite idea or skill mulligan’s for your project – a great safety net that let’s you go fast without fear.

Ryan Bates’s excellent screen cast series had a nice review of using git with rails and one of the commenters (Pete Yandell) offered a script to simplify life. This script sets up a standard rails project into git with the proper ignores. I modified the original script slightly to avoid placing .gitignore files into the empty directories within the .git directory. This is a harmless change but it seems cleaner to me. Here is my version of it:


#!/bin/sh
cat < .gitignore
log/*.log
tmp/**/*
db/*.sqlite3
coverage
doc/app/*
EOF
find . -type d -empty -exec touch {}/.gitignore \;
git init
echo "TODO - provide project README" > README
git add .
git commit -a -m "Initial import."

(here’s the gist)

This script works great (on OS X anyway) for setting up a project in git. This allows me to extend the ‘prototype’ from hours to multiple days if I need to without losing control or risking breaking the whole thing with a laps of concentration. I can create branches for experimental ideas and quickly switch back and forth. As long as my migrations are current and especially if I’m using data generators like populator, I can switch between branches to show my client a few different ideas or behaviors within seconds.

It is so great to have a (revisable) history of what I’ve done on a project. I can also quickly stash an idea away to work on it later. No matter what I do on the prototype, I can always recover back to some previous spot without much fuss or concern.

This technique works so well because it is all self contained within your rails directory and because it is such a low-overhead and fast approach.

The approach works like this:

1. rails some_new_project
2. cd some_new_project
3. git-rails
4. work on project for minutes or weeks with frequent checkins
5. create branches, rebase, squash commits, what ever – repeat previous steps
6. if want to keep it, move it to a public repo, if not simply rm -rf the entire directory…

Rails and git are really two powerful tools that have greatly revolutionized my personal work flow. I get to move quickly and with the assurance that I can undo any bad ideas. Infinite idea mulligans. I also get to practice using git even if my client is stuck on subversion (or worse). I highly recommend ALWAYS setting up your rails projects this way.

What am I talking about? I’ll use the work I’m currently doing for my client to illustrate. We have a rails RDOC oriented README_FOR_APP page that has includes for things like change log, metrics, notes/todos and the like. These elements are built by our cruise control process (we simply added a few extra statements in the rake file that cruse fires off).
Ok so how hard is this to do?

The answer is it is very simple. Here is the blow by blow…

1. set you project up to run under cruise control.

2. By default, cruise wants to run your rake test task. So you need to create a new super task for cruise to run. In you project Rakefile, add a new build task to run your tests and then generate the documentation.

3. Edit your doc/README_FOR_APP with useful information. When you want to include some of the generated files like the changelog, you simply add :include:filename. As an example, here is the project readme file…

= Some Project - Prototype
You can visit the current prototype by going to our
demo [http://url.to.the.site/] site.

== Notes

:include:notes.txt

== Statistics

:include:stats.txt

(LOC = Lines of Code)

== CHANGELOG

:include:CHANGELOG

Pretty simple…

4. Modify cruise to use your new rake task.

5. Set up a symlink in project facing web server directory to point to your cruise directory. For example in ~dhainlin/public_html I did something like ln -s /var/cruise/cruisecontrolrb-1.2.1/projects/sample/work sample which created a directory called sample. This essentially creates a permalink for your project documentation.

6. Browse to your new docs and enjoy fresh, always current information.

Hope this is useful. If you have questions or problems, let me know.

Before I get into how this could be used, take a look at some examples in this sample gallery.

Ok, how does this help?

First thing to note is the above samples are all generated on the fly using the google chart api. If you look at the image url’s you’ll see that all of the chart parameters/colors/data/format etc… are provided on the url line to google. This is simple but you obviously don’t want to do this by hand. This is where you can get creative. Say you have a web based data source (say one that stores project story points by sprint), you could coax that web service to produce json or xml data to your static page which could run some embedded javascript to produce a url to the Google charts API. Not totally trivial but since there are no server side elements (other than your feed), you can do this with minimal infrastructure.

I experimented with a simple rails app that allowed us to record the story point progress and plans on a few sprints. One of the side effects is it could produce nice looking burn down charts by generating the necessary url to feed to google charts. I’ll try to post more about this later with some examples (sanitized).