In these times of Agile development, super tight deadlines, and personal multitasking responsibilities that would make the latest Cray Supercomputer weep, every little tool that helps manage your workload is a blessing. Even more so if implementing and using said tool is simple and intuitive.

If you are more than just a casual user of MacOS X, then most likely you have heard of Growl. If you haven't, it is a highly configurable, unobtrusive notification system that gives application developers access to a simple API that they can tie into, instantly enabling notification functionality. For instance, there are add-ons for Firefox and Thunderbird that inform you when your download is finished or you have new email, plugins for iTunes that easily display current track info when the song changes, and even a plugin that updates you what is going on with your character and friends in Second Life.

You may think "This is all well and good, but how does it help me at work?" Well, there is a little known extra that is included with the Growl package (in the Extras folder of all places) called growlnotify. It is a fairly simple and straight forward command line interface for sending Growl notifications. After installing and configuring Growl in your System Preferences, then building and installing growlnotify, open a terminal and try the following:

growlnotify -t "Hello from Growl" -m "Nice to meet you"

If everything is set up correctly, you should see something like this:

(the style and position will depend on how you set your preferences, but you get the idea)

So how is this useful? Well, I was looking for a quick and simple way to get notified whenever a developer made a commit to the Subversion server. Setting up SVN to email me would be a bulky task, and either checking the web interface, GUI front ends, or using the SVN command line tools would have to be an interactive step on my part.

That's when I remembered growlnotify. After a read through of the man page, a quick and dirty shell script, and a little help from my old friend cron, I had pretty much what I needed:

---

#!/bin/bash

localrep=`dirname $BASH_SOURCE`
URL=`svn info $localrep 2>/dev/null | sed -ne 's#^URL: ##p'`
there=`svn info $URL 2>/dev/null | sed -ne 's#^Last Changed Rev: ##p'`
here=`svn info $localrep 2>/dev/null | sed -ne 's#^Revision: ##p'`
blame=`svn info $URL 2>/dev/null | sed -ne 's#^Last Changed Author: ##p'`

if [ $there -gt $here ] ; then
growlnotify -t "SVN Commit by $blame" -m "Local: $here - Remote: $there"
fi


---

Elated with the success of my elegantly simple solution, I started thinking up other uses for my new found favorite tool. After a few neat but overall useless and unproductive ideas, it dawned on me.

Builds!

So now that Growl has informed me that there is new code waiting, it's time to update my local source tree, build, and deploy for testing. Depending on what part of the project I'm working on, this process could take anywhere from 5 to 20+ minutes and include a any number of steps and scripts. Sure, I could just keep switching back and forth to the terminal to check if the build is done, but why? I can just end all of my build scripts with one simple line:

---


growlnotify -t "Build is done" -m "Get to testing"


---

And with that one line,  I no longer have to babysit a terminal of scrolling text. Now I'm free to spend that time reading the relevant design documents, check the bug tracker, catching up on the progress of other developers, *cough*check Slashdot*cough*, et cetera. When the computer is done doing it's thing, it will inform me without any intervention on my part.

Conclusion

Growl and growlnotify are not huge software packages of paradigm shifting, buzzword bingo winning, manager wowing life changers. They are a pair of simple tools to make your development life just a little bit easier, and are easy to grok with a simple one time read through of the man page. These two examples are just quick and easy ways for you to start working with notifications, there are many more possible ways to utilize these tools in your workflow.

Happy hacking!

3 Comments

FlexMonkey is a new tool to perform automated testing on your Flex applications. With it, you can record a set of interactions, save those commands into a TestCase class, add the TestCase to your TestSuite, and include it as part of a FlexUnit testing workflow.

Unit Testing and Test Driven Development is an encouraged agile method for reducing bugs. Up until now though, Unit Testing has been restricted to testing everything but the User Interface. Sure, we can easily test our functions, utility classes, etc. but the real challenge for the Flash/Flex community has been how to test actual interactivity. I believe that FlexMonkey is on its way to solving this. FlexMonkey incorporates the popular FlexUnit testing framework. Here are some good tutorials to learn more about FlexUnit: Adobe Flex Cookbook

The big question to ask yourself is if you're ready to change your work flow and start writing tests first. Those who practice and advocate TDD (FYI, I'm still learning) will tell you that it changes the way you approach writing code. By writing tests first, it forces you to determine necessary functionality upfront. Cleaner code leads to less bugs. The other huge benefit is that functionality is constantly being tested. If a new feature breaks existing functionality, you will be notified immediately rather than it going undetected until a user finds it.

Steps to set up FlexMonkey.
There are really very few steps to get FlexMonkey up and running.

1. Download the latest swc, at the time of writing this its in version .5:
   http://code.google.com/p/flexmonkey/
2. Copy the FlexMonkeyUI.swc into your projects lib directory.
3. Write your first TestCase class. I'm calling mine BaseTestCase and storing it in a test package.
4. Add your compiler arguments. These are going to be unique to your system. You'll need to know where your Flex sdk folder is located in order to include the automation swcs. You'll also need to point to your FlexMonkeyUI.swc. The reason for these absolute references is because FlexMonkey does a Mixin to reference the BaseTestCase.-includes tests.BaseTestCase -include-libraries "/Applications/Adobe Flex Builder 3/sdks/3.2.0/frameworks/libs/automation_agent.swc" "/Applications/Adobe Flex Builder 3/sdks/3.2.0/frameworks/libs/automation.swc" "/Users/seth/Flex/tutorials/projects/flexMonkey/libs/FlexMonkeyUI.swc"
5. Write your first test and run!

Click here to see an example (right-click on the example to download the code):

http://9mmedia.com/examples/flexmonkey/

To make FlexMonkey run, click the FlexUnit Runner tab -> Run.

There are circumstances where you'll need to use these properties in your classes:

• automationName: I've used this when there has been a scope conflict - two components with the same id. Even though they live in different classes, the automation only recognizes them by their name. To fix it, I've added their uid to their id name.
• showInAutomationHierarchy: This has also helped with scope conflicts in a ViewStack.

Even though FlexMonkey is only at version .5, I'm already finding it to be a useful tool. When manually testing begins to feel like Groundhog day, its time to automate and make FlexMonkey work.

12 Comments