Jon Maddox

Your Platform Must be Compelling

2011-09-05T00:00:00-07:00

To attract the attention of developers, your platform must be compelling. Wikipedia defines The World Wide Web as:

A system of interlinked hypertext documents accessed via the Internet.

The web provided a simple way for posting text and images whenever you wanted, available all the time, accessible by anyone in the world. Using a simple markup language, all a programmer had to do was write a little bit of markup, use a simple tool to upload it to a server, and her work was viewable by anyone in the world at any time of the day. There was no one telling her what she could or couldn’t post. Armed with a browser to decode these documents, users could consume and bounce between all of these documents. It was simple, valuable, and extremely accessible. Most importantly, it was extremely compelling.

But what makes a platform compelling? Programmers are finicky, but simple to please. Hitting a few key points may make all the difference in growing your developer community.

Low effort, high reward

Programmers are lazy. That’s usually what makes them good programmers. They’re willing to put in a little work if it means they don’t have to do a lot of work later. Something that lets a programmer jump right in, put in a little time, and end up with something great will have that person hooked.

Ruby on Rails nailed this.

Removed core decisions from the boostrapping process of starting a project
Provided a source tree for developers allowing them to bounce between projects without a learning curve
Provided well thought out support for tons of features every web app needs
Provided a drop dead simple plug-in system allowing common patterns in web apps to be reused with other projects, shared with other developers, and more importantly, not reinvented

These added up to an environment that removed wheel reinventing and allowed developers to add awesome features to their app with very little effort. Developers flocked to it.

Enable multiple points of value for free

There’s nothing a developer likes more than creating a project and getting things for free. Make getting extras easier for your developers and they’ll run to you.

iOS nailed this.

A very exciting hardware target (iPhone) allowing developers to create software they’d have with them anywhere they go
Provided development tools allowing ideas to go from inside a head to a desirable mobile device unprecedentedly fast
Trivially support 2 other device classes (iPod touch & iPad)
Deployable to the App Store with millions of users that actually pay for apps

iOS developers typically get all of these things at trivial costs. Say what you want about Android and its device numbers, but it barely hits these four points. That’s why it’s void of interesting, classy apps.

Make it accessible

How long does it take for me to access, learn, and integrate your thing? Programmers have short attention spans. When picking from a pool, the speed in which they can get their hands dirty is a major decision factor.

Twitter nailed this. At least in the beginning.

RESTful API
No API key needed
Basic Auth for authentication

After a single glance at the API documentation, a programmer could start playing with the API. What’s easier and cooler than getting your Twitter stream by doing a cURL GET? No need to sign up or get approved for an API key first. No obscure awkward authentication scheme for posting. Just 100% HTTP, something every modern programming language has support for. It was trivial to begin creating one of the over 1 million Twitter clients and integrations.

It all adds up to fun

All of these add up to something super fun to play with. Yes, play. Programming is a funny thing. It lies somewhere between career/hobby and eager programmers are always looking for something new to play with.

iLife Server

2011-03-22T00:00:00-07:00

The following is not a description of what I think Apple will ship or would ever ship. It is not what I think the general world of consumers wants or needs. This is a software platform I want. What I want for my house. What I want for my family. Are there holes in this idea? Of course there is, this is a blog post, not a 500 page spec.

Simply put, this is the dream setup I like to call iLife server. It’s a canonical meta store and server for your music, photos, and video (if buying DRM video is something you’re interested in). Not just your music, but your wife’s, children’s, or whoever else lives in your house (most likely anyone using the same credit card).

What?

iLife server lives on your always on computer. This is most likely a family iMac. It runs silently like any server software would, waiting for you to interact with it remotely. It stores all of the music, photos, and videos for the entire household. Maybe it has a local client you can use to do some management, but this typically isn’t the way you interact with the media that it stores. So how do you use it?

iTunes and iPhoto are now dumb clients. When you open iTunes on your laptop or Mac Pro, it connects to iLife server and looks exactly like what you’re used to seeing now. Except none of the media is actually local. You can play music all day, make playlists, buy music, import music, delete music, edit metadata. iTunes relays all of this over to iLife server. Most of these ideas work for iPhoto too but won’t be detailed here.

But what about when you leave the house, you might say. The idea of branded Home Sharing is dead. It’s just sharing. Because that’s the entire point of iLife server. Media accessibility. When you pop open your MacBook air at your coffee shop, all of your music is right there in iTunes. It streams right from iLife server at your house. Oh, and this works on your iPhone, iPad, and iPod touch too.

But what about syncing, you might say. It’s simple, you sync just like you did before. Except the media is fetched over the network. You might think this would be slow, but you would be surprised. Remember FireWire iPods? Mmm… That was some nice syncing. Those days are gone. Between USB 2 and insanely slow sustained transfers on solid state, these devices sync super slow. The bottle neck isn’t wifi anymore like it might have been 5 years ago.

But wouldn’t this get messy, you’re basically suggesting a single media library for multiple people, you might say. Have you seen your own iTunes and iPhoto libraries recently? I rest my case. But to preserve some identity, iLife server would be user spaced. You have an identity on iLife server.

When you open iTunes it connects to iLife server with your identity. Just think logging in to YouTube. When you make a new playlist, this is your playlist. It appears in your iTunes clients and only yours. Want to make it available to everyone? Set it to be global and it appears available to everyone.

Why?

90% of the computers that Apple sells are notebooks. Notebooks get closed, put away, and are basically never “on”. Meanwhile, they make incredible music sharing software with AirTunes, AirPlay, iTunes DJ, and iPhone Remote. When I want to listen to my music (it’s all on my Mac Pro) I flip open the Remote app and push music to my multiple Airport Expresses. Great. My wife uses a MacBook. When she wants to listen to her music, she gets to pull out her notebook, plug it in, open it, set it on the table, and flip open the Remote app. This isn’t even an option. She has not and never will do this. Having her media on an available server resolves this.

When I want to grab photos or music out of her library, I have to go downstairs and open her laptop. What?

Why do we even have individual iTunes and iPhoto libraries? If we were roommates this pattern is forgivable. But we’re not. There’s no reason for this level of personalization of media in a household. Personalization should be maintained with playlists, photo albums, etc. The “library” is nothing but a pool of media that everyone wants access to.

Will this ever happen?

I wouldn’t bet on it. But I’ve tortured myself wanting something like it for years now. For me, this solves the accessibility problems of libraries trapped on laptops, merges redundant libraries, and ubiquitous availability of my media. The scary part is that, even though it would be a massive undertaking, it’s definitely doable.

$5 for Xcode Isn't Wrong, It's Just Weird

2011-03-09T00:00:00-08:00

There’s a lot of talk on Twitter about Apple charging $5 for Xcode. People are either complaining about the price, or complaining about people complaining about the price. I think a lot of people are missing the point.

Xcode is a very large piece of software. I have no problem with Apple charging $499 for it. The problem is, Xcode isn’t just Xcode, its the canonical way to get a GCC toolchain in OS X. And now Apple has it on a store front as “Xcode”, the software that provides “everything developers need to create great applications for Mac, iPhone, and iPad.”

This means in order to build software like ImageMagick, anything distributed with MacPorts or Homebrew, or other OSS software packages you might use, you need Xcode. Where it gets weird is that none of these things actually NEED the software called Xcode. But you have to buy Xcode if you want to use them. This is not only confusing but also creates very weird scenarios. I’ll try to describe a few of them.

Software like Boom isn’t even developer oriented. A normal user now has to pay $5 to use it. Yes, normal people use this
Ruby developers that have spent years installing Xcode just to build their C backed gems now have to pay $5 for Xcode.
What about employees that work in other languages? Now, they not only have to expense $5 for tools but explain why. Manager: “Why? You don’t write iOS apps.”
How does the employee purchase Xcode? If buys and expenses an Xcode license, its not even property of their employer. It’s the employee’s, because of the way the Mac App Store works.

Having to pay $5 for an advertised piece of software that you’re not really even using is weird. Apple very well may be planning on shipping 10.7 with a toolchain to allow the building of just such software. That would definitely remove the weirdness.

Get Push Notifications From Campfire or Anything Else That Growls

2009-08-12T00:00:00-07:00

Use Case:

You’re away from your computer and something tragic/awesome happens in Campfire. Someone pings you, but you’re not there to get it. You come back to your desktop with 100 growl messages of people pinging you in Campfire, and you missed something tragic/awesome. Eff that. Thats what happens to you. Here’s what happens to me:

I’m on the couch, someone pings me in Campfire: “Maddox, we’re adding an instance because of load”. I immediately get that message pushed to my phone and can then open Ember on my iPhone to immediately drop into the campfire and find out what’s going on. That means at the airport, in bed, or at a bar. It’s a really amazing flow.

With Prowl you can get all your growl notifications pushed to your iPhone. It’s a simple plug-in that pushes every growl message you get, to your phone. But we don’t want every message sent to our phone. So here’s the quick lesson on my awesome strategy for keeping the noise down while getting the important things.

You need to purchase Prowl from the app store
You need sign up with the prowl service. Register here
Read installation instructions or just skip ahead
Download the plug-in
Install it
Now you have to set it up which is the TRICKY part
Go to the app that you want to Prowl, because you don’t want EVERY growl notification going to your phone. Just the apps that you choose.

Set the display style for the app to “Prowl”

Butttt the trick is, you dont want it to always use Prowl. That would be annoying. You want the app to use Growl while you’re using your computer, but Prowl when you’re away. So… you trick it out.

Go to the display options tab and configure Prowl
Add your username and password
Now, this is the most crucial step:
Set Prowl up to only work if your computer has been idle for a set amount of time
And tell it what growl style to use when you haven’t been idle.

And you’re all set up. So all day long as I work, Campfire (via the awesome Propane.app) will growl to my screen. But, the second I’m away from my computer for longer than 5 minutes, all the growl notifications from Campfire will be sent via push notification to my iPhone.

This is an amazing flow, especially when you know everyone is using it. It means you can page them remotely anytime you really really need them. It’s the future.

Nginx + SSL from Network Solutions

2009-02-03T00:00:00-08:00

These days you need an intermediate cert when using an SSL. Last time I set up a cert from Network Solutions, this intermediate cert was clearly named. This time around they issued quite a few certs and it made it confusing.

AddTrustExternalCARoot.crt
MY.DOMAIN.COM.crt
NetworkSolutions_CA.crt
UTNAddTrustServer_CA.crt

The two certs we care about here are MY.DOMAIN.COM.crt, my site’s ssl cert, and NetworkSolutions_CA.crt, Network Solution’s intermediate key.

Ok, now the tricky part. With old Apache, there was a specific directive for defining the intermediate cert. Nginx participates in no such thing. With Nginx we just need to cat our two certs together.

cat MY.DOMAIN.COM.crt NetworkSolutions_CA.crt > combined.crt

Now just add this to your conf with:

ssl_certificate /usr/local/nginx/certs/combined.crt;

Jeez People, Stop Fretting Over Installing RMagick

2008-06-06T00:00:00-07:00

Rmagick. It sucks, I know. We all hate it. But you have apps that depend on it and haven’t changed that yet. So you need it installed for development. And you hate installing it.

But really, its not that installing RMagick sucks, its installing ImageMagick that sucks. Its hard. But the only thing worse than hard, is stupid ass MacPorts. Which is ********.

So all I hear is people complain over and over about having to install it. Meanwhile there has been a script to install ImageMagick and RMagick on OS X forever, but people just don’t seem to know its there.

I tell people about it and they just ignore me and then complain about installing RMagick to me later on!! WTF?!

So, I’ve had it. When you format or get a new computer go here: ~~http://rubyforge.org/frs/?group_id=12&release_id=21634~~

~~Download rm_install~~

That old script isn’t maintained and never works. I’ve decided to post one myself on GitHub with the hope that people will not only use it, but make sure it never gets stale. Grab it here: http://www.github.com/maddox/magick-installer

Now, once its downloaded. Do this:

sudo ./magick-installer.sh

and let it run forever. Done. Pretty easy right? There. PLEASE USE IT. Its a fantastic script that works really well. Its not hard to install ImageMagick anymore! Dance!

Show Your GIT Branch Name In Your Prompt

2008-03-13T00:00:00-07:00

Typing git branch over and over to see what branch you are on sucks. Sure, you could argue that you should always KNOW what branch you’re currently working on. And if you did, you would obviously not be a git user.

Bouncing around branches can be pretty common, and I know I’ve messed some things up pretty bad not knowing what branch I was on.

So set up your shell to always put the name of the current branch into your prompt.

function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}

function proml {
  local        BLUE="\[\033[0;34m\]"
  local         RED="\[\033[0;31m\]"
  local   LIGHT_RED="\[\033[1;31m\]"
  local       GREEN="\[\033[0;32m\]"
  local LIGHT_GREEN="\[\033[1;32m\]"
  local       WHITE="\[\033[1;37m\]"
  local  LIGHT_GRAY="\[\033[0;37m\]"
  case $TERM in
    xterm*)
    TITLEBAR='\[\033]0;\u@\h:\w\007\]'
    ;;
    *)
    TITLEBAR=""
    ;;
  esac

PS1="${TITLEBAR}\
$BLUE[$RED\$(date +%H:%M)$BLUE]\
$BLUE[$RED\u@\h:\w$GREEN\$(parse_git_branch)$BLUE]\
$GREEN\$ "
PS2='> '
PS4='+ '
}
proml

Pastie Link

Put this at the top of your .bash_profile and you’ll be pimping your branch all over.

Thanks to @defunkt for this.

Cleanly Migrate Your Subversion Repository To a GIT Repository

2008-03-05T00:00:00-08:00

So you’re ready to ride the GIT train eh? But what about all those projects in your subversion repository? Sure you could just use git-svn but what you really want is to cleanly move that repository and all its history to a nice new GIT repository.

Luckily it’s not that hard. For this example I’m going to use my_blog as the application name you’re porting to a GIT repository. We’re basically going to just initialize a new GIT repository, point it at your SVN repository, and suck in your code and history while remapping the users to GIT users. We’ll then just clone THAT repository to have a clean GIT repository free of SVN clutter.

The first thing we need to do is create a users file that maps all your SVN users to your GIT users. Just make a file on your Desktop named ‘users.txt’. Map the users using this format:

jmaddox = Jon Maddox <jon@gmail.com>
bigpappa = Brian Biggs <bigpappa@gmail.com>

Simple. Now here are the commands you’ll run. I’ll explain them below.

mkdir my_blog_tmp
cd my_blog_tmp
git-svn init http://code.yoursite.net/my_blog/trunk/ --no-metadata
git config svn.authorsfile ~/Desktop/users.txt
git-svn fetch

The first two are self explanatory, we’re making a new directory for the temporary repository. The second command initializes the directory as a git-svn hybrid thing and points the origin at your SVN repository. The flag, --no-metadata, tells GIT to leave all the SVN details behind (not the commit log). The fourth command tells GIT to remap all the SVN users to GIT users when it sucks down the source and history. The last command actually does the fetching.

Ok, so now after a few LONG minutes, your source is all there. Do a git log to see that your users have been mapped. Sweet!

Now you just have one last step. You need to clone this repository. Why do we do this? When doing a normal git clone it will take everything we want from the temporary repository, while leaving behind all the SVN cruft that was there to support the git-svn stuff.

git clone my_blog_tmp my_blog

Boom! You’re done. Now you have a super clean GIT repository all ready to use.

Git It?

2008-03-04T00:00:00-08:00

While working today I think I heard GIT mentioned on every form of communication I use daily. It was mentioned in several IRC channels, on twitter a ton, in an email, over IM, and a couple of new posts in my feeds. It has become obvious that GIT has hit the early adopter phase.

I’m not going to sell GIT or even try to explain why it’s so great. There are tons of places online that already do that. I’m just going to share a couple stories.

Who Gives a Crap, I Gotta Get Work Done

This new source code management software that seems to be gaining a HUGE amount of steam first popped on my radar early last summer. I contemplated playing with it, but like most things, I skipped it. I figured as a single developer, it wouldn’t mean much to me. I code,commit, iterate. “What do i need with fancy branching?” I said. But @peterc replied with my answer. I just didn’t get it then.

Months went by as I used SVN like everyone else. I was just happy with versioned code, that’s about all that SVN did for me.

RubyConf 2007

As I was outside with the rest of the Ruby Smoking Crew, I got Chris Wanstrath, unofficial GIT ambassador, to try to sell me on it. He started with the normal branching pitch, and I stoppped him.

“I don’t branch”.

“Because you don’t use GIT”.

BOOM. It hit me. I don’t branch because branching with SVN sucks so much fucking arse that it’s just not worth it. CERTAINLY not for changes that take only a few hours. With SVN you hang out on trunk and make your thousands of commits. Forget if you want to try something wacky real fast, you’d have to branch it! And thats just a whole lot of work.

Fast Forward a Few Days.

I’m sitting in a cube at Yahoo!. I’d been given a task a few days earlier. I was working on it and hit a stopping point. I needed to make a huge sweeping change. BUT, two hours later, I had to demo it to a room full of Yahoo! people I had never even met. AND they expected it to work. I knew my changes were going to break the whole app for a little while.

Ok, so first off, this project was neither IN a repository, nor did I even have access to one. I’d only been there for like two days. So I could copy my source directory and file it away for the demo, or… I could finally throw GIT on my laptop and try it out! So I installed GIT, initialized my rep. Branched it…whoa what? Thats it. git checkout -b new_model? Thats it?! SICK.

I continued my work and when it came time for the demo I just used git checkout master and voila, I was back to my fully working copy. I finally ‘got’ GIT. At least the branching part. Not only is it easy to branch, you can branch locally. And by locally, I mean privately. So if you want to try something weird and crazy out, you don’t need to worry about making a new branch at the central repository, just branch it locally and go to town. If it worked out, merge it back into master. If it doesn’t, just dump it. Now, like most GIT users, I don’t even work directly on master.

Ok, thats my story. I guess the moral is, you’re never going to get why something is good for YOU until YOU use it. Everyone takes different things away from products, especially when you’re talking about productivity.

Spec Out Your Cookies with Rspec

2008-02-04T00:00:00-08:00

Here’s something that got me this weekend and I couldn’t find much info on it anywhere. So like my Internet taught me, I’m sharing.

links_controller.rb

cookies[:phone] = params[:phone]

links_controller_spec.rb

it "should save the phone number in a cookie" do
  @my_cookies = mock('cookies')
  @my_cookies.stub!(:[]=)
  controller.stub!(:cookies).and_return(@my_cookies)

  @my_cookies.should_receive(:[]=).with(:phone, '804-755-7555')

  do_post
end

Here I’m making the expectation that a cookie will be set with the key of ‘phone’ and a value of a passed in parameter.
My do_post method takes care of the post and passes in the parameter :phone => '804-755-7555'.

Put Your PHP on Port 3000 With Lighttpd

2008-02-01T00:00:00-08:00

While most of my work these days is in a Ruby and Rails environment, I still get my hands dirty with PHP every now and again.

When working with web projects I practically require the ability to use absolute links for static content. Because of this, I usually have to host a PHP project under Apache and create a virtual name, oh and make a fake host entry in my hosts file. Blegh.

This usually sucks even more when I throw in the fact that my project is under some kind of source control (which is usually always the case). So what is a frustrated developer to do?

Well, the only reason this is annoying is because I don’t have to deal with it in my script/server world of Rails development. So I solved my litle PHP problem by borrowing from what I learned with Rails.

Instead of developing PHP apps under Apache, I installed Lighttpd and fire off an instance whenever I need to do work on the app. Very simply I added a lighty config file under APP_ROOT_/config and when I want to work on my PHP app, I just start lighty. Booom. Now I have my app running at localhost:3000. Just like my Rails apps, so my fancy bookmark in my bookmark bar works for both my PHP and Rails projects. Now that DRY!

So, how do you get it going like this? First off, all of these instructions were done in OS X 10.5 Leopard, so be warned.

Roll Your PHP

You need to roll your own PHP in order to get support for php-cgi. Do this:

mkdir src
cd src
wget http://us.php.net/distributions/php-5.2.5.tar.gz
tar xfz php-5.2.5.tar.gz
cd php-5.2.5
./configure --enable-fastcgi --enable-discard-path
  --enable-force-redirect --with-zlib --with-xml
  --with-mysql=/usr/local/mysql
  --prefix=/usr/local/php5-fcgi
  --disable-cli --enable-memory-limit
  --with-layout=GNU --with-regex=php

make
sudo make install

Pretty basic. Download, configure, make, and install PHP.

Next, rename the php binary, use tab complete I think the XXX part is different per install(?)

sudo mv /usr/local/php-cgi/bin/php-cgi.XXX /usr/local/php-cgi/bin/php

Lighttpd

Ok, I’m not a big fan of MacPorts, but I was having so much trouble getting Lighttpd installed on Leopard, that I had macports do it for me. So, go install macports first and:

sudo port -d selfupdate
sudo port install lighttpd

All the Rest

Ok, now you need to fix a small little problem with MySql and your new PHP. The new PHP may not see your MySql stuff correctly, so do this:

sudo mkdir /usr/local/mysql/lib/mysql
sudo cp /usr/local/mysql/lib/libmysqlclient.15.dylib /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib

Set Up Your App

Ok, you’re all set up. Now you just need to add a lighttpd config file to your app. Create APP_ROOT/config/lighty.conf with this:

server.port = 3000

# server.errorlog    = CWD + "/log/lighttpd.error.log"
# accesslog.filename = CWD + "/log/lighttpd.access.log"

server.modules = ( "mod_rewrite",
                   "mod_access",
                   "mod_fastcgi",
                   "mod_userdir",
                   "mod_accesslog" )


# If no file is specified, what to look for?
index-file.names = ( "index.html", "index.php" )

# Run the server under the user-name "www" for security purposes
# To bind to port 80, the server must be called by root user, but we don't want
# the server to have free run of the box, so it runs as "www"


# Set up the appropriate MIME type mappings
mimetype.assign             = (
  ".pdf"          =>      "application/pdf",
  ".sig"          =>      "application/pgp-signature",
  ".spl"          =>      "application/futuresplash",
  ".class"        =>      "application/octet-stream",
  ".ps"           =>      "application/postscript",
  ".torrent"      =>      "application/x-bittorrent",
  ".dvi"          =>      "application/x-dvi",
  ".gz"           =>      "application/x-gzip",
  ".pac"          =>      "application/x-ns-proxy-autoconfig",
  ".swf"          =>      "application/x-shockwave-flash",
  ".tar.gz"       =>      "application/x-tgz",
  ".tgz"          =>      "application/x-tgz",
  ".tar"          =>      "application/x-tar",
  ".zip"          =>      "application/zip",
  ".mp3"          =>      "audio/mpeg",
  ".m3u"          =>      "audio/x-mpegurl",
  ".wma"          =>      "audio/x-ms-wma",
  ".wax"          =>      "audio/x-ms-wax",
  ".ogg"          =>      "application/ogg",
  ".wav"          =>      "audio/x-wav",
  ".gif"          =>      "image/gif",
  ".jpg"          =>      "image/jpeg",
  ".jpeg"         =>      "image/jpeg",
  ".png"          =>      "image/png",
  ".xbm"          =>      "image/x-xbitmap",
  ".xpm"          =>      "image/x-xpixmap",
  ".xwd"          =>      "image/x-xwindowdump",
  ".css"          =>      "text/css",
  ".html"         =>      "text/html",
  ".htm"          =>      "text/html",
  ".js"           =>      "text/javascript",
  ".asc"          =>      "text/plain",
  ".c"            =>      "text/plain",
  ".cpp"          =>      "text/plain",
  ".log"          =>      "text/plain",
  ".conf"         =>      "text/plain",
  ".text"         =>      "text/plain",
  ".txt"          =>      "text/plain",
  ".dtd"          =>      "text/xml",
  ".xml"          =>      "text/xml",
  ".mpeg"         =>      "video/mpeg",
  ".mpg"          =>      "video/mpeg",
  ".mov"          =>      "video/quicktime",
  ".qt"           =>      "video/quicktime",
  ".avi"          =>      "video/x-msvideo",
  ".asf"          =>      "video/x-ms-asf",
  ".asx"          =>      "video/x-ms-asf",
  ".wmv"          =>      "video/x-ms-wmv",
  ".bz2"          =>      "application/x-bzip",
  ".tbz"          =>      "application/x-bzip-compressed-tar",
  ".tar.bz2"      =>      "application/x-bzip-compressed-tar"
 )


server.document-root = CWD

fastcgi.server = ( ".php" => ("localhost" => (
                     "bin-path" => "/usr/local/php5-fcgi/bin/php", # path to php binary
                     "socket" => "/tmp/php.socket"
                 )))

Now at the root of your app run:

lighttpd -D -f config/lighty.conf

Boom

Now you’re deving with port 3000. Plus, your app isn’t constantly available and just sitting there. When you need to work on it, fire it up, work, and shut’r down.

BDD’n All Over The Place

2007-11-29T00:00:00-08:00

I’ve been working on quite a range of different projects recently, not all of which are Ruby/Rails.

One is in PHP and one is a cross platform widget that will work for the Yahoo Widgets engine as well as OS X’s Dashboard.

Of these two projects I’ve managed to work some BDD into both of them. I thought I’d spread the word on the packages I’m using. For javascript I’m using JSSpec and for PHP I’m using PHPSpec

Neither are documented very much, and both are less than 6 months old. They’re limited, but I’ve been able to get what I need out of them and its been nice to be able to keep the same dev style even if I have to deal with JS and PHP.

Here’s a couple pieces of syntax.

PHPSpec

<?php

class DescribePage extends PHPSpec_Context{

  public function before(){
    $this->p = new Page();
  }

  public function itShouldReturnAShortUrl(){
    $this->p->url = "http://www.apple.com/imac/features.html";
    $this->spec($this->p->short_url())->should->be('www.apple.com');
  }

 public function itShouldNotBelongToAQueryWhenCreated(){
   $this->spec($this->p->query)->should->beNull();
  }

}

?>

JSSpec

describe('Get Song From XML', {
  before_each : function() {
    podcast = new Podcast()
    podcast.xmlUrl = 'podcast_xml_fixture.xml';
  },
    'should parse song title from xml': function() {
      topTune.readFeed();
      song = podcast.parseTune();
      expect(song[0]['title'].strip()).should_be("Willoughby - Frankenstein");
  },
      'should parse song url from xml': function() {
        podcast.readFeed();
        song = podcast.parseSong();
        expect(song[0]['link'].strip()).should_be("http://www.domain.com/featured/willoughby_-_franken");
  },
      'should create song': function() {
        podcast.getSong();
        expect(podcast.song).should_not_be(null);
    }
})

Display Validation Errors For Your Ajaxified Form

2007-11-05T00:00:00-08:00

One of the sweet things Rails provides is practically free error notification on forms. With just a little bit of

<%= error_messages_for :post %>

validations on your model, and some logic in your controller, bam, instant error messaging. Very simple.

But what if your form is using AJAX to post? The page doesn’t re-render, so how is our buddy, error_messages_for, going to work? Well its not, we’re gonna have to use AJAX to display the errors. It turns out this isn’t too touch, but as usual we want to keep it DRY.

The Controller

class PostsController < ApplicationController
  def create
    @post = Post.new(params[:post])
    @post.save!

    # automatically renders create.rjs.erb

  rescue ActiveRecord::RecordInvalid

    @model = @kit_item
    render :template => 'shared/validation_error.rjs.erb'

  end
end

We will attempt to create the Post. If all goes well, then the create rjs action will fire and all is well. But if the record fails validation, we catch it, assign the current model to @model, and render shared/validaiton_error.rjs.erb. This is our generic AJAX action for rendering errors for Models.

The AJAX

Create shared/validation_error.rjs and use this little snippit, and thats pretty much it for this part.

page.replace_html "errors_for_#{@model.class.name.underscore}", "Oops! <ul>" + @model.errors.collect{|k,v| "<li>The #{k} #{v}</li>"}.to_s + "</ul>"
page.visual_effect :highlight, "errors_for_#{@model.class.name.underscore}", :startcolor => "'#ff0000'", :endcolor => "'#aca2b6'"

So, the errors just get collected and printed out to a div in the page. Let’s go add this fancy div.

The View

This part is pretty simple. You just need to open up your form partial, posts/_form.html.erb and add this little view helper to the form:

<%= error_div_for post %>

This does nothing but prints out a div with a specific ID to prepare for our RJS action, if it’s needed. So let’s go make the view helper.

module ApplicationHelper

  def error_div_for(model)
      %{<div id="errors_for_#{model.class.name.underscore}"></div>}
  end

end

Now we can just call this simple view helper and pass in any model and it will dynamically build a div with the appropriate ID inside.

And thats pretty much it. To go through it again, when the form is loaded, the error div will be placed in the page, waiting to be used. Once the form is submitted in the background, the controller’s create action will attempt to save it. If the record is invalid with validation errors, then the universal validation_errror RJS template will be fired off and replace all the errors from the failed validation, into the div we placed in the page. Oh and of course a little red flash action to make sure the user sees the errors.

Flush your DNS Cache in Leopard

2007-10-29T00:00:00-07:00

As a web dev, you may spend some time messing with DNS and overriding it. Though, it can get annoying when you can’t get things back to the way that mere mortals see things on the internet.

lookupd -flushcache was a big tool in my arsenal in Tiger. But Leopard put a rightful end to lookupd, but left us without our known way of flushing the cache.

For the last couple of weeks its been pretty annoying, but I’m here to bring you, the NEW way to flush dns cache for OS X users!!! Holy crap this is exciting.

So it’s as simple as this:

dscacheutil -flushcache

There you have it.

Start and Stop MySql in Mac Os X 10.5 Leopard

2007-10-27T00:00:00-07:00

Yay! Its finally here! The newest version of my favorite operating system. And it comes with 98% of my dev stack ALREADY installed! Yay! This is perfect.

Wait… ok, no MySql. Thats ok, I’ll just install it…Wait… why isn’t it running…why isn’t this stupid preference panel turning it on! ARGHHH!

Ok, that may have just happened to you, and you dramatically hit the Google looking for answers. So answers I give you.

If you want to start MySql in Leopard, you need to call the startup item directly from the command line:

sudo /Library/StartupItems/MySQLCOM/MySQLCOM start

And to stop it:

sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop

Not so bad. But long… So make an alias in your .bash_profile

alias start_mysql="/Library/StartupItems/MySQLCOM/MySQLCOM start"
alias stop_mysql="/Library/StartupItems/MySQLCOM/MySQLCOM stop"

Happier? Relaxed? Good.

Use Capistrano to disable_web On Your PHP Apps

2007-03-09T00:00:00-08:00

Just like using Capistrano to deploy my Rails apps made my PHP apps jealous, being able to disable the entire app with a single command did too.

Using a simple cap disable_web command allows my Rails apps to be completely disabled while I perform maintenance on the site without having to worry about users accessing it. Being able to suspend the site with a single command is wonderful, trust me.

Well I want to do this with my PHP apps too. Here’s how I did it.

First create a generic page that you want your users to see when your site is disabled and name it maintenance.html. Then throw it into your /config directory.

Cap Tasks

Next, write a disable_web task for Capistrano.

desc "This will disable the application and show a warning screen"
task :disable_web do
  run "cp #{current_path}/config/maintenance.html #{current_path}/maintenance.html"
end

This simple one liner will copy the maintenance.html file into the root of your application. Now lets write a task to re-enable the application.

desc "This will enable the application and remove the warning screen"
task :enable_web do
  run "rm #{current_path}/maintenance.html"
end

This will simply delete the maintenance file.

Ok, so, basically, when you run cap disable_web, Capistrano will move your maintenance file into the root of your app, and enable_web will delete it. So far this does nothing to disable your PHP application.

mod_rewrite Magic

The trick to this is using mod_rewrite to look for your maintenance file. If it’s at the root of your application, then all requests will be directed to it. Otherwise the application works as normal.

RewriteEngine On

# Check for maintenance file and redirect all requests
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*(\.html|\.php)$ /maintenance.html [L]

This will look for any requests of .html and .php files. All requests that fit that condition will pointed to the maintenance.html page if it exists at the root of the application.

Huzzah! You’ve now got a “we’re fixin’ stuff” page. And you can go from this:

To this:

Associated and Non Associated Resources

2007-01-25T00:00:00-08:00

Problem: Your site has resources that can exist alone as well as be associated to another resource. You want to stay DRY as well as keep your routing RESTful.

I just came across this problem while working on a project, and its solution is a bit easier than you’d think. Thanks to Ruby being so dynamic, Rails provides a really easy way to accomplish this. I’ll give my use case as an example.

So I’ve got a website I’m working on. It’s for a church. Part of the data model will include Events and Groups. Groups will have_many Events. Simple enough. Here’s the wrench, Events can exist on their own as well. So the “Church” can have Events, which would be an Event existing alone without an association to anything, and every Group in the church will have_many Events.

We also want to use RESTful routes so that we can have routes like: /events, /events/1, /groups/1/events, /groups/4/events/32

Ok, so lets get jammin’ on the solution.

Lets knock out the data model first. We want to keep this DRY, so we’ll use Single Table Inheritance to keep track of the Events. We’ll have Events and GroupEvents. GroupEvents will inherit from the parent Events:

Class GroupEvent < Event

This way Events.find(:all) will return regular Events as well as GroupEvents. We’ll add one extra attribute for GroupEvent, group_id, this allows a GroupEvent to belong_to a Group. Lets make our migrations:

Data Tables

class CreateGroups < ActiveRecord::Migration
  def self.up
    create_table :groups do |t|
      t.column :name, :string
      t.column :description, :text
    end
  end

  def self.down
    drop_table :groups
  end
end


class CreateEvents < ActiveRecord::Migration
  def self.up
    create_table :events do |t|
      t.column :type, :string
      t.column :title, :string
      t.column :description, :text
      t.column :date_on_, :datetime

      # extra attribute for GroupEvent
      t.column :group_id, :integer
    end
  end

  def self.down
    drop_table :events
  end
end

If you’re unfamiliar with STI, the type column is there to keep track of what type of object the row is. We also added the group_id attribute for the GroupEvent.

Ok, so our DB is set up. Lets get our association on… Start by creating a new model named GroupEvent:

Data Model

class GroupEvent < Event
  belongs_to :group
end

GroupEvent inherits from Event. Since Event inherits from ActiveRecord::Base, our GroupEvent class is still an ActiveRecord. Its just extended a bit. We also added a belongs_to association to Group. So Group will have_many GroupEvents, not Events. Next up, the Group model…

class Group < ActiveRecord::Base
  has_many :events, :class_name => 'GroupEvent', :foreign_key => 'group_id'
end

Here’s where we’re pulling a few Rails tricks. We’re using telling Group that it has many events, but GroupEvents, using group_id as a foreign key (remember when we added that?!). So now we’re able to use:

@group = Group.find(1)
@events = @group.events

Whoa, nice! We didn’t have to have a separate table just for GroupEvents, which means we dont have to manage 2 different models and their attributes if they get updated. We also don’t have to use syntax like @group.group_events which is a bit ugly if you ask me. Groups have events, lets obfuscate HOW it has them to the back, so in the implementation we’re just worried about events, not namespaced events, blegh.

OK! NICE! So far so good. What about the routes? I want http://mychurch.com/events and http://mychurch.com/groups/2/events, not http://mychurch.com/groups/3/group_events.

Lets dig into the routing…

map.resources :events

map.resources :groups do |group|
  group.resources :events, :controller => 'group_events', :name_prefix => 'group_'
end

First things first, we add a resource for Event. Next, since we want nice pretty nested routing, we nest GroupEvent into Group. Here’s some more configuration (EEP! yes yes, our requirements are outside of a convention, BUT NOT BY MUCH!). We want to define the route to use ‘events’ in the actual URI, but we don’t want to stomp all over our previously declared resource, events. Our generated named routes will clash, we can’t have 2 events_path methods. So we add a :name_prefix option. This basically appends ‘group_’ to every little route helper we have. So event_path in the Group context becomes, group_event_path. The tricky one is new_event_path turns to group_new_event_path, so its not AS pretty, but good enough :)

Next we know our @group.events are going to be very different from our @events, so we need a GroupEventController. In order to properly map this, we use the :controller option. Without it, the routing will use EventController (those darn conventions…), and that would just process our logic for normal Events, not our scoped Group events.

So there ya have it. Around 10 lines of code and we have our domain model nice and dry, and our routes very logical!

Test Your respond_to Block

2006-11-30T00:00:00-08:00

Getting RESTful and wondering how to test your respond_to block in your controller to make sure its returning the right format? Drop these into your test_helper.rb.

def assert_xml
  assert_match 'application/xml', @response.headers['Content-Type']
end

def assert_rss
  assert_match 'application/rss+xml', @response.headers['Content-Type']
end

Then in your functional tests, use them like this:

def test_return_xml
  get :index, :format => 'xml'
  assert_xml
end

def test_return_rss
  get :index, :format => 'rss'
  assert_rss
end

Yay!

Automated PHP Deployment With Capistrano

2006-08-16T00:00:00-07:00

Sure, I’d like to spend my days and nights writing Ruby and cap deploy ing it to success, but I have to face the facts.

I Still Have PHP Apps To Maintain.

I have no one to blame but myself. I wrote them. And I still work where they were written. There’s no escape. After using Capistrano more than one time, you’ll be completely spoiled.

But Capistrano is only for crazy Rails apps right? Nope. Its simply a platform for automation. It just so happens that deployment usually requires quite a bit of steps. Hmmm…lots of steps…automation… a match made in heaven. So sure, Capistrano was thought up with Rails in mind, but created openly so you’re able to use it any way you’d like.

Capistrano’s power is in its remoting features. You tell it what to do on that other server, and it does it. Beauty. So, if your PHP deployment process requires an svn export combined with a few other repetitive steps you have to do every time, Capistrano is here to help you too.

Without going into all the details of Capistrano (following the link will give you a nice overview), it uses a deploy script (recipe) to understand your deployment environment and required tasks.

Ok ok ok, Lets Get On With It

So, we have a PHP app that we need to deploy to server X. It needs to be sucked out of its repository, its version symlinked to a doc_root, and then a shared directory symlinked into the site. This is a pretty common deployment scenario, so lets go with this.

First, we need a Capistrano recipe. Currently, it can only be auto generated for a Rails app, so psst, here it is. Download this and create a directory at the root of your PHP app and name it config.

mkdir config
cd config
wget http://maddox.s3.amazonaws.com/sites/deploy.rb

Capistrano wants its recipe to be in the config directory, so do as it likes. Now lets open it up and make it work with us. Once again, a complete description of the Capistrano recipe file is bit out of scope for this little post, so please read up.

We’ll edit all the normal items

set :application, "php_app"
set :repository, "http://code.phpdevelopers.com/#{application}/trunk"

We only deploy to one server, so edit…

role :web, "phpsite.com"

Now you need to add the directory you want to deploy to. Add…

set :deploy_to, "/home/www/#{application}"

Capistrano defaults to checkout when pulling from subversion. I prefer an export, if you do too, then add…

set :checkout, "export"

Ok, so if you’re familiar with Capistrano, you know exactly what we did. If you’re not, the most important thing to know is that Capistrano is going to suck your code from the repository defined, do everything it’s told to do in /home/www/php_app on your deployment server, phpsite.com.

Set’r Up

Believe it or not, we’re half way done. Next, lets let Capistrano get the directory we just defined ready for its magic.

cap setup

If you look on your deployment server, you should see 2 directories that were just created.

drwxrwxr-x    2 user  group      4096 Aug 16 01:48 releases
drwxr-sr-x    4 user  group      4096 Aug 16 01:48 shared

WOW! We’re already saving time! releases is where your app will be sucked down to. Capistrano exports your PHP app into a directory named after the current date/time. Each version you deploy will be kept in this directory. Shared is where you can keep files like uploaded assets or images that aren’t kept in your repository, but need to be around every time you export from subversion. If your users upload files all day long, and you redeploy your PHP app from subversion, all your uploaded files will be gone. So we keep those in here.

Here’s the deployment rub. Every time you deploy, you have to go symlink these directories from your /shared directory, into your current version of your PHP app. And a small bit of math can calculate the complexity when you start adding 2,3, or 6 asset folders. Yuck.

That’s where Capistrano helps ya out.

Capistrano, Take Me Away

Ok, so our deploy directory is set up and ready to get our files. Now we need to tell Capistrano exactly what to do when we deploy. Get it? Recipe…

Define a new task called deploy

desc "This will deploy the app"
task :deploy do

end

Inside the block we’ll just tell Capistrano exactly what it needs to do in order to deploy our app.

desc "This will deploy the app"
task :deploy do
  run "svn --quiet #{checkout} #{repository} #{release_path}"
  run "ln -nfs #{release_path} #{current_path}"
  run "ln -nfs #{shared_path}/photos #{current_path}/photos"
end

Ok, lets walk through exactly what this does. First, Capistrano uses subversion to suck your app out of the repository and into the releases directory. That releases_path is just a nice convenient variable for /home/www/php_site/releases/200608162012. Next, it will create a current symlink to that version of your app in the releases directory. Then we told it to symlink the directory photos from shared into the current version of the application.

And since you’re hosting a PHP app with Apache (a 99% guess), there’s no need to restart any servers. You’re done. You’re new version will be deployed safely and linked. The IMPORTANT thing to note, is that your new doc_root for your site will be /home/www/php_app/current.

Deploy!

Now, all ya gotta do to redeploy your site is…

cap deploy

Capistrano will go on to do everything you told it to do, on your deployment server. When its done, your directory should look like this…

lrwxrwxrwx   1 user group   42 2006-08-16 01:32 current -> /home/www/php_site_/releases/200608162012
drwxrwxr-x   4 user group 4096 2006-08-16 01:31 releases
drwxr-xr-x   4 user group 4096 2006-06-24 02:08 shared

And there you have it. Automated PHP deployment, with one simple command. Peering inside the current directory, you’ll see where the photos directory has been symlinked into it.

The moral is, Capistrano isn’t just for Rails deployment. Its powerful remote execution can be exploited to do anything you want. While our Rails apps get a lot for free when it comes to recipes, creating your own isn’t complicated. Especially if its replacing repetitive tasks you’ve done over and over and over and over and over again.

You’ll see the payoff the minute you get this set up. Especially on a Friday night at 5:30p when you’re walking out the door. And its not just for Rails!