All posts by Patrick

Enjoying My Mornings With a Double Edge Razor

After more than a decade of shaving with your typical cartridge-based safety razor, I figured there had to be something better. Getting a close shave with one often means horrible razor burn and ingrown hairs: not a good way to start my day. So after asking my barber for some advice, I was pointed in the direction of the classic straight razor or the double edge razor that was popular in my grandparents’ generation.

Wade & Butcher Medium Size Hollow Ground Merkur Hefty Classic Safety Razor

Continue reading Enjoying My Mornings With a Double Edge Razor

My next project: ActiveMob

For my last semester at Carnegie Mellon Silicon Valley I’m working through an entrepreneurship course with several past team mates. In 12 weeks (of which we have about 9 remaining), we’ll be designing, implementing and seeking user feedback for a software product of our choosing.

Our team has chosen to develop a route tracking Android application for runners and cyclists with a twist (eventually for other various outdoor sports). There are many of them available at the moment, some of which are open source (usually a good sign that the market is saturated), but we hope to add a social element that we have yet to see executed properly. We’ve named our app ActiveMob and set up a website to which we’ll be posting updates and eventually launching the application. So far we’ve been developing at full speed and I’ve been amazed at how quickly we’ve been able to pull something usable together. As we collect user feedback we hope to focus our idea into something marketable and potentially profitable.

I Heart roboguice

Since I was introduced to it by @ahsteele, I’ve been in love with the simplicity that roboguice provides for Android development. It introduces the inversion of control principle to your app and much of the Android SDK. With a bit of configuration, you can remove the explicit calls to get resource objects, shared preferences, etc. and instead simply inject them with the use of simple decorators.

For instance, let’s say you needed access to a shared preferences instance. Traditionally, one would need to request a shared preferences object from a context and store it as a member in onCreate or request it every time it’s needed using one of the methods below:

class SomeActivity extends Activity
   SharedPreferences prefs = null; // class member
   protected void onCreate (Bundle savedInstanceState){
      // Method 1:
      prefs = getSharedPreferences("some_key", MODE_PRIVATE);
      // Method 2:
      prefs = PreferenceManager.getDefaultSharedPreferences(this);

But with roboguice configured, this class simplifies to:

class SomeActivity extends RoboActivity
   @Inject SharedPreferences prefs; // equivalent to method 2 above
   protected void onCreate (Bundle savedInstanceState){
      // nothing to do here!

This can be done outside of an activity class and will use the application context capture the proper SharedPreferences object.

Resources can also be injected, avoiding the need to use findResourceById and cast the resulting object like this:

      // inside method
      Button b = (Button)findViewById(;

Instead, you can just use the @InjectView decorator:

   // class member
   @InjectView( Button b;

You can find some additional examples on the Google Project site. I’ve ended up using roboguice on all of my recent Android projects and haven’t looked back; it makes Android code more succinct and I have discovered that I am a big fan of Inversion of Control in my own code.

Twitter as a Software Engineering Tool: Follow-up


At the beginning of the GeoCam Memo & Track projects, which I took part in with several of my classmates, we chose to experiment with the use of Twitter as a means of sharing daily status in lieu of a daily tag up. We were working remotely on the project part time in the evenings and on weekends so planning a time when all of us would be available on a daily basis was difficult. This was exacerbated by the fact that we spanned multiple time zones and had varying amounts of demand from our full-time jobs. Our assumption was that tweeting our daily status with a unique hash tag would provide us a quick and easy place to look to see the day’s progress and happenings.


Twitter ended up nearly unused for coordination as the semester progressed. Our assumed need for a daily tag-up analog proved unnecessary after only a couple of days. We found that as remote students, we had been trained to work in a very coordinated manner already, using tools like Skype and Google Talk to informally plan, share status and coordinate. Twitter seemed redundant and only a couple of team members continued using it to post status for a couple of trailing weeks. It ended up being used primarily to provide occasional status updates to our customer and other potential contributors.

Coordination aside, we did get a good deal of use out of Twitter as a continuous integration tool. Our Jenkins CI instance was configured to post to twitter when a build or test failed. This proved a much cleaner yet still efficient mean of reporting CI status to the entire team than email. Having a public-facing CI report kept us a bit more aware of our build as well. It was harder to ignore them when we knew that our customer and anyone else could instantly see when we checked in bad code.


Based on our experience, I think Twitter could be a great coordination tool if used on the right team with the right process. For us, it was simply a matter of it not providing any additional value to our process. Our use of rotating pairs with pair programming required much more coordination than Twitter could have provided. I would actually go so far as to say that we’re likely an edge case. I would encourage other teams in different situations to give it a try (assuming, of course, that you don’t mind your status being public or you have a Twitter clone inside of your company). It was a great way to track status during the short couple of weeks that we were using it as intended and I will likely try it again with teams in the future.


PJWiki (Patrick’s Java Wiki … creative, I know) is a desktop wiki with a server-less storage system that saves in plain text using the file system. I am working on it as an open source version of an application, PWiki (sans J), that I developed for my current employer.

PWiki was developed in C# using WinForms as a quick and dirty Wiki solution to use in an environment that frowned upon open source software and provided terrible wiki’s via corporate. The data contained within the wiki would be FOUO and so would need to be protected in much the same way as files on our intranet. Additionally, the data would need to be stored in a human readable format and the application built for our Windows-only development environment. These limitations led me to develop the application using a text-file-based back end in which all data was stored in a shared file system location. It’s been in heavy use for nearly 2 years now and the choice to use plain text for storage in a common file system location has come in handy on multiple occasions including the ability to write simple scripts to parse the contents for information used by other tools. Needless to say, I was proud of the result a bit disappointed with its limitations. I had developed the bulk of it on my own time but resorted to developing fixes on company time. To avoid legal issues, I decided to just turn over ownership to the company and start developing a more open version of it using a more portable language. Not that C# isn’t portable (Mono anyone?) but I saw it as an opportunity to improve my Java development skills and am particularly fond of how portable the Java VM is.

Enter PJWiki. It’s being developed using Swing (NetBeans aided, lame I know) and at this point I have the majority of the wiki parsing engine developed. Next steps are to smooth out the UI and work on getting an efficient search and printing implementation in place, two of the most used features in PWiki. Development is currently on hold as I finish up my last two months of school work, but I hope to get right back at it shortly and start working on making it usable.

Twitter as a Software Engineering Process Tool

It was recently suggested by my practicum teammate, @samdkarp, that in lieu of formal daily “stand-up” meetings to support our agile software process we use Twitter to share our daily status. For a remote, part-time team with a variety of schedules we thought that this might be a good approach, allowing us to share status at our convenience. So far it has been a great way to coordinate; we’ve committed to at least daily updates so that we can have impromptu pairing sessions as team members are available. Including the hash tag #geocamsu has allowed us to capture our updates and display them as a feed on our Google Sites landing page. Our goal being to use it as a means of keeping our stakeholders’ confidence up by keeping them in the loop.

Our use of HudsonJenkins CI should provide even more opportunity to incorporate Twitter into our process. We plan to create a test status account on twitter, driven by the Jenkins Twitter plugin. As we push our commits to GitHub, our Jenkins CI server will pull, run the test suite and tweet any changes in success status. Being able to include this status with our individual daily status has made Twitter our one-stop status dashboard.

Assuming that we continue to update as frequently as we plan to, Twitter should prove to be a great way for our remote team to get the benefit of a status meeting without the need for a dedicated daily time.

C2DM Prototype

As part of my current practicum project at CM-SV, I was asked to put together a prototype that demonstrates the capabilities of Google’s Cloud To Device Messaging (C2DM) service, or push notifications. What follows was the result:

c2dmprototype consists of two applications: a relatively vanilla Django server application (the Cloud part of C2DM) and an Android 2.2 application (the device part of C2DM). The demo aims to demonstrate the basic pieces of a “push to talk” application by allowing a user to send audio messages to devices by pushing them instead of requiring the battery-limited phone to poll the server. I’ll cover the purpose of the two applications below. Continue reading C2DM Prototype

The Carnegie Mellon Practicum Has Arrived!

When I got accepted into the SE masters program at CM-SV, my most anticipated and nerve-wracking course was the always-off-in-the-distance practicum. The idea of working a legitimate software project with several of my classmates caused my mind to wander, chasing all of the possibilities while the concept of working potentially full-time simultaneously on two projects had me terrified. Well, the time has finally come as the practicum kicked off one week ago, today. The nerves are all but gone and the excitement is in full swing as I learn more about the project I’ve been placed on with several of my former teammates and one that, after only a week, is already hitting it off with the group as though we’ve worked together for months.

We’re working with several NASA Ames researchers that are working on the GeoCam project being sponsored by Google. Their goal is to provide a suite of tools to disaster first responders that utilize recent advances in mobile technologies to make search efforts more efficient and effective. As the first part of the GeoCam name hints, the projects focus on incorporating the capture of geolocation data into disaster response protocols.

The most mature of the tools and the inspiration for the project name is GeoCam Photo, an image capturing application that attaches geolocation data and allows users to label and classify images before synchronizing them with a central server. This data can be useful in coordinating, documenting and analyzing the actions of disaster response team members in the field. The application consists of a client and server component, written using the Android SDK and the Django framework respectively.

Our project (or projects), which are still being brainstormed, should provide similar functionality within the disaster response domain. We’re looking into options that range from providing more direct push-to-talk communication to a status monitor that would analyze movement using a phone’s accelerometer and compass and alert search team managers when they’re in potential imminent danger. We’ve set up a Google Sites landing for the project and intend to update it regularly as we further define the project.

Wikifiy Your Life

For the last 3.5 years, I’ve been doing brain dumps into a personal wiki throughout or at the end of each day and I think you should too. It has proven helpful to me in more ways than I could have foreseen and I can’t imagine getting by without one.


As an engineering student, I had a notebook with me at almost all times that I used to write down assignments, reminders and ideas. That hasn’t changed as I and all of my coworkers still carry one with us everywhere to this day. Taking the time to write something down makes the difference between it being a fleeting thought and a permanent idea or reminder.

While in school I had a lot to write down and often went through a composition notebook in less than the span of a semester. While I would keep the old books, I didn’t bring them with me and often found myself needing to dig through my closet for something I jotted down in an older book. In my Junior year, while contributing to Wikipedia, I wondered if I could create a Wikipedia of my own; a ‘permanent’ place to store my thoughts and ideas. A few days and a 50 dollar purchase later and I had my very own searchable instance of DokuWiki running on a remote host, reachable from anywhere in the world [with internet access]. I reference it on a daily basis.

Why a Wiki?

So why does a wiki instead of a blog?

  1. Brain Dump-able
    Regardless of your background, these days you likely suffer from information overload: things to do, people you’ve met, TV shows you’ve been recommended, books you’d like to read, places to see, and on, and on, and on… A wiki give you an easily modifiable place to put that information.
  2. Searchable
    Most wiki software provides a search box that will, in seconds, search the entire contents of your wiki. A personal wiki is about as close as you will get in your lifetime to having Google for your brain.
  3. Easily Accessible
    Whether you host your own server or pay for hosting, a Wiki can be made available from anywhere on the internet; with the recent popularity of smart phones, this means nearly anywhere you get cell reception!
  4. Sharable
    Most wiki software is built to be public and promote knowledge sharing. I lock mine down but have, on occasion, opened up pages on it to people I worked with. Give them an account and set the permissions and you can work collaboratively without additional costs.
  5. Private
    Note: I didn’t say secure. A wiki is only as secure as the software you use and your own security practices. You should never put private information onto a Wiki unless you know you can lock it down.

How to get started

  1. Host your wiki
    If you don’t already have a host, find a reliable one (I use Justhost) and find a compatible wiki application. If your host supports PHP, I would recommend DokuWiki or MediaWiki among many. Quite often you’ll just need to try several of them before you find the right one. Alternatively, you could use a free wiki host that lose you some control, but are easier on the wallet. Springpad, while not a wiki in the traditional sense, provides a comparable experience for free.
  2. Secure your wiki
    If you set up your own, it’s likely configured to share with everyone by default. If you’re OK with that, then be my guest. Otherwise, take a few moments to disable access by non-users and disable user sign-up.
  3. Define your process
    Your wiki will gather e-dust unless you take the time to build it. If you don’t have immediate access to it throughout the day, write your thoughts down in a notebook and transfer them at the end of the day. If you’re in front of your computer all day, create a ‘scratchpad’ wiki page and use it to write down anything you can. As your ideas become more concrete, create pages dedicated to them.
  4. Stick to it
    It’s easy to miss the benefit of a personal wiki in the initial weeks or days. Stick to it. You’ll eventually encounter the first time it saves your ass and will love it from that point on.

I hope this entry helps at least a couple of people get hold of their information overload. The structure is up to you and with search, it’s almost unimportant, but having a permanent place to write down your thoughts is one of the best things you can do for your sanity. Who knows, it may even help you remember that killer idea that will make you millions.

Ruby: Executing code only if file was called directly

I wanted a way to treat a Ruby file as both an importable library or a script. The best solution I could find was as follows:

if __FILE__ == $0
   #script / run as self code goes here

If the file is called directly a la ruby ./library.rb, the code within that if block will be executed. If included, __FILE__, the file that this code exists in will not match $0, the file being executed and the code in that block will not be executed.


PHRASE = "Hello World"
def get_phrase
if __FILE__ == $0
 puts "Executing library.rb"
 puts get_phrase
require "library.rb"
puts "Executing script.rb"
puts get_phrase

Running ruby script.rb will produce:

Executing script.rb
Hello World

Running ruby library.rb will produce:

Executing library.rb
Hello World

It seems trivial but I’ve utilized this several times while creating large collections of scripts.