KyleDaigle.com

If you’re been using MacPorts (::shudder::), it is time to change your package management solution.  After being thoroughly bent over when installing a package on MacPorts, I decided it was time to correct the many months of wrong-doing and get my *nix life in order.

After doing a complete reformat (after taking a TimeMachine backup of course), I was looking for a better way to keep my libraries and executables from infecting my computer like a virus.  I know I’m a little late to the party, but enter: Homebrew.  Homebrew is a new take on package management that leaves everything feeling much tastier.  The first big differences are:

It keeps your filesystem clean

Instead of littering your directories with various and sundry libraries and executables, with four Ruby installs, seven different occurrences of Gems, and who knows how many symlinks, you can keep everything in a clean tidy directory:  /usr/local.  Of course, if you were smart and conscious, you could have done that in the first place.  But I’m not going to lie, I didn’t pay attention until it was too late.

Simple, Easy to Read & Write Packages

The actual package files aren’t hard to maintain, add, or update since they’re just little Ruby files.  Using a simple structure, you can build a package file for just about any library whether it needs compilation or not.  Then share your package with the world and we can all benefit.  The GitHub page for Homebrew shares bounties on packages people would like added if there is something in particular you are missing.

Did I mention dead simple?

Want to create a new package?

$ brew create http://foo.com/bar-1.0.tgz
Created /usr/local/Library/Formula/bar.rb

Need to edit an existing package file?

$ brew edit wget

And its all in Ruby which comes pre-installed on Macs.

Websites today always seem to be pushing out a ton of hot new features that are super topical: SMS, integration with Social Media sites, ability to login with one of nine other logins you own, ability to make you toast. As part of any product, new features are a good (and I’d argue) easy way to keep your product innovative. But I think focusing on new features to keep your product fresh will ultimately give your customers the wrong impression.

The hard way to innovate but keep your product “innovative” is to continuously go back through your features and evolve them.  Not rewrite them, not throw them out when they have only a modicum of success, but to evolve the feature from what there is now into what would make the feature easier & more useful for your consumers.  Yes, sounds like common sense.  It is.  There isn’t a big immediate win when evolving new features, but there is a great slow buildup that will eventually tip the scales.

I’ve been talking to customers, clients, and immersing myself into a feature at Geezeo to get a better understanding of how to make it better & more useful for the end-user.  The easy answer would be to throw it out and start over.  Or to try and draw attention away by creating a new feature that has more pizazz, more excitement, something more interesting.  Instead, I’ve completely immersed myself into the product.  Decided that if my finances can’t be solved by solely using the product than how can we expect customers to do that same (ie, eat our own dog food).  We’ve come up with some great evolutions of the product and are not just taking on new features.  There is a great slow burn going on, and its about to blow up.

We setup CruiseControl.rb quite some time ago in order to try and track our application better as we had more developers coming onto our team. We started with CruiseControl.rb, tried Integrity, then CiJoe, but it looks like we’re coming whole circle to CruiseControl.rb again. Taking my co-workers lead, I started to re-setup the application but found a few things from his original post no longer held true. So I wanted to give a quick demo on how to setup CruiseControl.rb with Github and Apache as a front.

First, grab the latest code by checking out their Git repository:

git clone git://github.com/thoughtworks/cruisecontrol.rb.git

Then, add your project to CruiseControl.rb:

./cruise add Project-Name -s git -b branch-name-here -r git@github.com:username/project-name.git

The next step I found out through a little bit of trial and error.

Edit your Virtual Hosts file to add the following:

<VirtualHost *:80>
  ServerName cruise.mydomain.com
  ServerAlias cruise.mydomain.com

  ServerSignature Off

  <Directory />
    Options FollowSymLinks
    AllowOverride None
  </Directory>

  DocumentRoot /where/you/put/cruisecontrol.rb/public

  <Directory /where/you/put/cruisecontrol.rb/public>
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
    AuthName “Secure Area”
    AuthType Basic
    AuthUserFile /where/you/put/.htpasswd
    require valid-user
  </Directory>

  RewriteEngine On

  # Deflate
  AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

</VirtualHost>

You will need to have Phusion Passenger installed to go this route, but this way you don’t have to worry about proxying to the Mongrel server in the “old” version. After you make any configuration updates, be sure to restart Apache so the builder gets updated as well:

sudo /etc/init.d/apache2 restart

In an upcoming post, I’ll describe how to install some plugins, specifically installing a plugin for Campfire (since that was quite the hassle)!