I’ve been doing a lot work with CouchDB lately for Socialytics, and which means writing map/reduce functions in JavaScript for building views.  I was beginning to have a healthy set of views, it made sense to have this code in version control and be able to load these views to a CouchDB instance via the command line.  Not finding anything like this on the interwebs, I decided to come with something on my own.

My first pass at it was a Ruby implementation, but was fragile since it found the map and reduce functions via regular expressions.  This past weekend I decided to give a go with a new implementation using Node.js.  Since I’m now using JavaScript, I no longer had to use regular expressions to sniff out the map/reduce functions – I can just load the scripts up as code.  Another additional benefit is that now the view code got parsed, so I find syntax errors before the are loaded to Couch.

Here’s the code.  The script expects a designs/ folder at the same level as the loader script, with a subfolder for each design document underneath.  A design folder should have a .js file for each view.  A view file looks like this:

design.view = {
    map: function(doc) {
        emit(doc.created_at, null);
    },
    reduce: '_count'
};

CouchDB document update handlers are supported as well by assigning a function to design.update.  Once your view files are ready, just run loader.js with the CouchDB database URL as the parameter:

node db/couchdb/loader.js http://localhost:5984/myDatabase

So what do you think?  Does something like this exist already?  Is there a better way to do this?

Recently, I’ve been working on an HTML5 project that needed to need to retrieve data from a different origin, and decided to look at using CORS.

CORS, or Cross-Origin Resource Sharing is a specification that allows web applications to make AJAX calls cross-origin without resorting to workarounds such as JSONP.

Searching around, I found an CORS extension for Sinatra, which happened to be the framework I was using. However, the extension didn’t properly implement the spec, nor did it support CORS preflighting (required for more complex AJAX requests). So I rolled my own, but as a Rack Middleware. Here’s an example of a Rackup that shows it in action (this example uses Rack::CORS in Sinatra app, but should be able to use it in any Rack compatible framework):

require 'sinatra'
require 'rack/cors'

use Rack::Cors do |config|
  config.allow do |allow|
    allow.origins '*'
    allow.resource '/file/list_all/', :headers => :any
    allow.resource '/file/at/*',
        :methods => [:get, :post, :put, :delete],
        :headers => :any,
        :max_age => 0
  end
end

get '/file/list_all/' do
  #...
end

get '/file/at/*' do
  #...
end

To get going with Rack::CORS, just install the rack-cors Gem. To check out the source, see the project on Github.

If you want to learn more about CORS, here are some good links I found along the way:

• The W3C Working Draft on CORS, for good night time reading.
• A good article about CORS that summarizes the CORS spec.
• You can check if your browsers support CORS here.  This site records all pass/fails so you’ll be able to see a list of CORS supported (and not supported) browsers.
• The Sinatra CORS Extension I found.

I’ve been juggling a few different web projects lately, and decided to setup different virtual hosts on my Mac so that I can easily work with them. Googling around gave me a lot of different answers, none of which seem to work completely. This is what finally worked for me (on Snow Leopard).

First, add a new local domain to your /etc/hosts file:

127.0.0.1       localhost devsite.local

Next, you’ll need to configure Apache with this new virtual host. Fortunately, the default Apache config has this partially setup. Open up /etc/apache2/httpd.conf and uncomment the following Include:

# Virtual hosts
#Include /private/etc/apache2/extra/httpd-vhosts.conf

Now, we need to add our virtual host to the httpd-vhosts.conf file referenced above. The file already had a couple of sample configuration in it, but I commented out those and added the following:

<VirtualHost *:80>
    DocumentRoot "/Library/WebServer/Documents"
    ServerName localhost
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/usr/docs/devsite.local"
    ServerName devsite.local
</VirtualHost>

This first entry will map localhost to its default document location (without it http://localhost won’t work correctly). The second entry maps my new domain.  Additionally, you’ll want to make sure files in your new docs directory have adequate access permissions.  I ended adding a new Directory section to httpd-vhosts.conf file:

<Directory "/usr/docs/devsite.local">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Now all you have to do is put your web files in /usr/docs/devsite.local. I originally had my new local domain map to <user dir>/Sites/devsite.local, but changed it because I would have to make sure Apache could access to all the directories leading up to those docs. So instead I just symlinked my http docs from my user directory into /usr/docs.

A few weeks ago, I started using the Patron Gem for Skribit and ran into an issue on our CentOS production servers which uses a very old version of libcurl.  I got it working by compiling a new version of libcurl and building the Gem against those binaries.  Since I didn’t want to overwrite the libcurl that CentOS provided, I installed the binaries in another location instead, and updated the LD_LIBRARY_PATH environment variable so Rails could properly load the Gem.

A couple of days ago, Paul brought to my attention that using LD_LIBRARY_PATH isn’t a good thing.  While I didn’t necessarily think it was a big deal, it did peak my curiosity on how I would get this work without it.  Here’s the command I finally used to get it to work:

The key part is the –with-ldflags option at the very end.  The -Wl,-R<path> option adds the given path to the list of paths the linker will use to find libraries at runtime.  Hopefully, someone will find this information useful, since I couldn’t find this information myself on the ‘nets anywhere.

Just recently done a 2 week stint working on Windows while Apple Geniuses were working on my MBP, I thought it would be a good time to blog on my own Skribit Suggestion and reflect on my switch to Mac 14 months ago.

Reasons for Switching

Prior to my MBP, I’ve was working on a personal HP laptop that was on it’s last leg.  My screen had started developing an assortment of 1 pixel vertical lines and the keyboard would randomly doouble typed keys.  I had a choice to make – I can either get another (and better) Windows laptop, or do the the switch.  Ultimately, I decided on switching.  Here were my reasons.

Apple made great looking laptops that looks good too

Apple really makes some really good looking laptops, but it’s easy to forget that they they’re functionally great laptops too.  When my wife first got her MacBook, I was amazed at how everything looked so crisp on it.  And speaking as someone that has broken a power connector on a laptop before, MagSafe is a must-have awesome feature.

A Unix based Operating System

When you do development, working on a Unix based environment with a real command line is a big advantage.  Cygwin can help bridge that gap on Windows, but it’s nothing like having a terminal that can size itself properly and not having to constantly translate Windows paths to Unix paths and vice versa.

Another benefit of having a Unix OS is that Open Source software plays much better on it than on Windows.  Most OSS is developed to target Unix first, Windows second.  When working on Elf Island on Windows, my workflow while working on the game (which is developed primarily using OSS), involved starting two different services from Windows System Tray, starting another service from the Windows Services, and finally running a few commands from Cygwin.  I can do the equivalent of all that from the command line on a Unix environment.

A Paid-For Software Friendly Ecosystem

For some reason, it seems that Mac users are willing to pay for software, and as a result there is a lot of reasonably price software for Macs.  Doing software development myself, I can appreciate and definitely want to support this line of thinking.  Sure, Windows has tons of commercial, paid-for software, but I can’t say I feel comfortable about downloading them for fear of excessive ads, poor installations practices, and/or spyware.

Experiencing Something New

Probably the biggest reason for doing the switch is that I’ve been using Windows for years.  It was time for a change - a change for changes’ sake.  Programmers are told that they should regularly learn new languages to keep their skills sharp and to explore new ways of doing things.  It should be the same with the software you use as well.  If you develop software, you owe it to yourself to see how the other side does it to gain some perspective.

Conclusions

So after a year of working fully on the Mac, here’s are some things I like and don’t like about my OS X:

Pros

• Windows Management. It took a while getting used to, but I have grown to prefer Command+Tab & Command+` to Windows Alt+Tab model.
• OS Degradation. With my prior laptop, Windows had greatly degraded by it’s first anniversary.  I haven’t experience that with my MBP yet.
• Great TrackPad. When programming, I try to stay on the keyboard as much as possible, but I find that transitioning between the trackpad and keyboard on my MBP the easiest of any laptop I’ve used before.

Cons

• Keyboard Shortcut Images. For some strange reason keyboard shortcuts are still displayed using icons () that in some cases are no longer shown on the keyboard.  Trying to remember what icon is what key can feel like akin to decipher hieroglyphics.
• Alt Key Menu Access. I miss how the Alt key in Windows gave you keyboard access to the application menu.  I often used that function keyboard shortcut.
• I Miss My Alt+Ctrl+Delete. I kind of feel that Windows does a better job of preventing errant applications from locking up the whole OS.  I attribute that to Window’s plentiful experience with crashes and lockups.  It seems that lockups on OS X are more catastrophic (requiring a hard reboot) than they should be.

A Google search seems to indicate that problems uploading files on WordPress installs is a pretty common occurrence.  Unfortunately, I had the hardest time finding the solution to my particular ailment.  Hopefully, this post will find those others who run into this problem in the future.

From the WP Admin pages, go to Settings > Miscellaneous.  Make sure the value for ‘Store uploads in this folder’ is where you want your files stored (in most cases, it should be wp-content/uploads).

In my case, this was pointing to a folder I was using for a WP install I was using to test the Thesis theme I’m using now.  Reverting it to the default fixed my problem.

Recently, I needed to create some static reporting pages for Skribit.  From a quick search, I got a lot of results that talk about Rails and static pages, but none did exactly what I needed:

1. To be able to generate pages with different paths from one URL
2. Pages to persist across Rails deployments

Not seeing any solutions that fit my needs, I set out to come up with my own.  Here is what I ended up with.

First, I needed to add a route for generating/displaying the reports:

From here, I could just use the standard caches_page :show declaration, but that would only generate the page I wanted if I used /report/2009/05/25 as the URL.  What if I wanted /report to generate the report for the current week?  Well, you can do something like this:

The magic is in the after_filter method cache_weekly_report.  We basically use the same mechanism Rails page caching uses to save our new report page.  Now, calling /report will generate a static report at /report/2009/05/25, or whatever the current day is.

The last thing to do is to make sure that the reports persist through new server deployments.  That can easily be done with a symlink in your capistrano script:

And that’s it!  What do you think?  I’d love to know if there are any simpler solutions to this.

When building software, it’s a good idea to identify the needs of 3 different kinds of audiences.

The first 2 kinds are obvious ones.  We know to listen to what our End Users ask for, but not necessarily build everything they ask.  And we want to balance what the Business wants with when they want it.

The last audience, the fellow Developer, is often forgotten.  This means writing clear and concise code.  This also means identifying the common maintenance points in your software and making it easy to work with.

And this also means factoring into the design the capabilities of the development team.  Just like it is unacceptable to write bad code, it should be just as unacceptable to over design software beyond the hiring practices of the company you work for.

It’s been a month now since I left my contract at AutoTrader.com.  For the most part, I’ve enjoyed my time there, but the thought of celebrating my two year anniversary there was a little frightening.  While I am very adaptable to the corporate life, it isn’t for me.  When FlickStation (the last startup I was a part of) desolved, the plan was to serve a year of corporate duty to get my bearings before heading back into the startup arena.  But some interesting work, interesting politics, and great co-workers kept me there longer than I expected.  But ultimately, I’m addicted to execution and delivery, both of which seem very hard to do well and often in large companies.

Also, for people with entrepreneurial aspirations, the corporate world has a way of slowly draining it from you, replacing it with contentedness.  And when you’re building your startup, those aspirations provides the fuel for you to push on.  I was worried that one day I wake up and find it all gone.

I’m now spending my time at Good Egg Studios, where we just now wrapped up our second week in private beta of Elf Island.  Working here has been like a breathe of fresh air.  The technology is familiar and not so familiar at the same time, and I’m working with some great people (including Startup Weekend alums Rob and Amro) and leadership with great character.  As an added bonus, my commute is a lot shorter now, and also I’m much closer to Skribit.

Oh, and did I mention I was working on a game!  A fscking game!

It’s a real refreshing change to be doing developing on Mac these days.  Currently, our Ant builds at work are less than optimal, taking ten’s of minutes to do a full build.  Fixing it is something we definitely want to do, but because of the complexity of the build and existing deadlines, right now isn’t the best time.  So instead of constantly checking on the progress of my build, I installed this Growl Ant build listener which will display a Growl notification when a build has completed.

The README for the listener got me started – the only thing that didn’t work for me is setting the build listener using the ANT_OPT environment variable.  It looks like the default install of Ant on Leopard uses that environment variable as arguments to pass to the Java VM.  So instead, I just used an alias:

alias ant='ant -listener net.slimeslurp.growl.GrowlListener'

Just add this line to your ~/.bash_login to use the build listener every time you build.