Feb 27, 2008

GNU Apps On Windows?

There's a story circulating that Microsoft is going to provide a GNU compatible tool chain for Windows. This would in theory allow pretty much any *nix application to run on Windows with very little or no change.

I seriously doubt there's any truth in this mostly because it would create a horrible rift with their third party developers who'd they'd be throwing to the wolfs, but you never know, anythings possible. There is no technical reason it can't be done. Hell, from Microsoft's perspective, I'd think it would actually be easy. After all both MinGW and Cygwin already provide this functionality. In fact all they'd really have to do is provide a standard re-distributable C library and compiler.

Even though I think it's a bogus rumor I really do hope Microsoft does this. I've always thought it was the one thing they could do that would guarantee them another 25 years of market dominance. In fact it's the only thing I can think of that could buy them enough time to switch away from the "Software As A Product" business model.

They just better hope other people are more forgiving than I am. While I really want this to be true, it makes it easier for software I write to run on Windows, I have no personal interest in ever doing business with them again. Any vendor who doesn't always try and do the right thing for their customers is not some one I want to give money to.

After a decade of bullying everyone in the sandbox it's a bit hard to accept they really want to share there toys now and even worse for them I've come to realize most of the alternatives are significantly better.

Feb 24, 2008

Marketing Open Source

Zed Shaw gives a talk about Mongrel where he touches heavily on how to market an Open Source project. It's worth watching if these things interest you at all, at the very least you'll learn what yak shaving is.

http://www.infoq.com/presentations/zed-shaw-mongrel-loc-economics

Feb 23, 2008

Patch Bombing and Change Stashing

I ran across the term 'patch bombing' today, which could be defined as; "multiple application logic changes all rolled into a single source code commit", it's the opposite of an 'atomic change'

I found the term relevant to a background thought I've been pickling over lately....

It's not uncommon for me to be in the middle of adding a new feature when I run across a bit of crufty code that needs to be refactored. Which poses the problem; How do I do the refactoring with out mixing the change sets?

In the past I'd just make both changes and write one fat commit message explaining everything but I always thought this approach smelled bad. Then, Jay Fields blogged about 'using patch as subversion's stash' and turned me on to 'the power of git-stash'.

It turns out that Bazaar, which I'm using for my current project, doesn't directly support this operation either but Jay's patch-stashing approach works just as well for bzr as it does for svn.

Feb 22, 2008

Method Not Allowed

Quite a bit of my old code just redirects when an action gets a request with an unsupported method, for example; 'get' requests to 'destroy' actions. While my old approach prevented anything bad from happening it always seemed wrong. It also made maintaining my tests a tiny bit more complicated because each seemed to have a different location they redirected to.

So I decided to clean up the code in my current project today. The obvious choice was to render an error template and return the proper status code.


# file: app/controllers/parts_controller.rb
def destroy
unless request.delete?
render :layout => false, :template => "errors/405", :status => 405
return
end
begin
Part.find(params[:id]).destroy
flash.now[:success] = "The part has been successfully deleted."
rescue
flash[:failure] = "Unable to delete part."
end
end
This also simplified my tests.

# file: test/functional/parts_controller_test.rb
def test_destroy_get
get :destroy
assert_response 405
assert_template("errors/405")
end

Feb 10, 2008

The Application Appliance

This post is the continuation of a thread that started with: Opportunities

The hardware it's self would not be remarkable in anyway and since I'm really only interested in the software stack the logical choice is to resell some other vendors machines preconfigured to meet my needs.

At this point I'm not exactly sure who's machines I'll use but I'd prefer it to be a vendor that sees Ubuntu (or maybe Debian) as a first class target. My short list at the moment really only contains System76 so if anyone has any other suggestions I'd love to hear from you?

The software on the other hand is much more interesting. The software will be delivered through a private apt repository as customized packages and include specifically configured base tools such as Apache, Postgres and Ruby as well as management tools for deployment, monitoring, replication and backup.

Now obviously there's nothing special about this approach, in fact that's kind of the point. I don't want to have to re-think the simple standard parts I want to focus on the newer more unique parts. The management tools, replication and fail over to cloud services, etc...

More later....

Feb 2, 2008

My Opinionated Application Stack

This post is the continuation of a thread that started with: Opportunities

Recently I've been thinking a lot about different ways to minimize duplication of work. Many of my projects have similar requirements, how best can I reuse the effort from one to the next?

I've also been puzzling over another problem; How do I provide businesses with reliable application when they don't have the necessary I.T. support to manage it and they don't have a reliable enough internet connection to go the "software as a service" route?

It turns out that both questions may have the same answer. An application appliance! A low cost plug and play application server that's configured with a well defined software stack and the ability to backup to a remote service that is able to double as a warm standby in a pinch.

In future posts I'll explain in more detail.

Opportunities

A driving belief of mine is that there's an enormous long tail associated with the custom business software market. It exists because software development is difficult and in the past only the deepest pockets have typically tried to tackle the problem but I think this has already began to change! Things like agile test driven development methodologies, the use of free software, and opinionated design are going to make it a reality.

I'd like to share my recipe for this but you'll need to keep in mind I'm focusing on the really (really) small business that just doesn't register on the radar of more established custom software providers.

It's really simple and goes something like this...

Stick to the small projects that can be completed quickly. Every business has itches that need to be scratched. Keep the customer involved, which should be easy if you're focusing on a real itches and provide a turn key (nearly) zero administration solution.

Which gets me to what I wanted to talk about, my opinionated application stack

Feb 1, 2008

My Apache Setup

I've been using Apache2 with mod_fcgid for quite a while because it's good enough. I use it primarily because it's really simple to administer and I'm hosting internal business applications with very little load on them. Here's my setup...

Installation is really straight forward

$> sudo apt-get install apache2 libapache2-mod-fcgid
$> a2enmod fcgid


default config
# serve everything from /var/www/ and use /var/www/default as the document root

ServerAdmin webmaster@hostname

# setup logs
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
LogLevel warn\

# limit the amount of info about server
ServerSignature Off

# default permissions to all files
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>p;

# setup document root and permissions
DocumentRoot /var/www/default
<Directory /var/www/default>
Options +FollowSymLinks +MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

# define environment for fcgid processes
DefaultInitEnv PATH "/opt/ruby/bin"
DefaultInitEnv RAILS_ENV "production"


per application config
# run the app from /var/www/appname and serve it aliased as http://hostname/appname

Alias /appname "/var/www/appname/current/public"
<Directory /var/www/appname/current/public/>

Options -Indexes +MultiViews +FollowSymLinks +ExecCGI
AllowOverride None
Order deny,allow
Allow from all

RewriteEngine On

# provide support for cap deploy:web:disable
RewriteCond /var/www/appname/current/public/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /appname/system/maintenance.html [L]

# standard rails rewrite with support for alias directory
RewriteBase /appname
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

# define error documents
ErrorDocument 500 500.html
</Directory>