Archive for January, 2011

Introducing Statim

01/24/2011

I just push Statim, a very simple static site generator that I’ve worked on the past couple days. It is written in shell as an attempt to limit run-time dependencies so that it can be used on pretty much any Unix server. I more or less wanted a simple site generator that I could trigger on a git hook to build a website where I was less concerned about looks, and just wanted a quick way to push up information.

Currently running statim does the following:

  1. Copies all files from the content directory to the destination directory of your choice
  2. Runs any files ending in “.md” or “.markdown” through the “markdown” command and relocates the resulting html
  3. For each subdirectory it creates links based on file names and camel-casing conventions (like a wiki)
    • There’s nothing super complicated or revolutionary here, its just a simple tool for me because none of the others did what I wanted.

Ruby Development Woes

01/08/2011

After getting back into the flow of things post vacation I decided it was about time to put something up on my blog. A few days ago one of the Debian ruby package maintainers quit with a post detailing what he found to be some current problems with the Ruby community. As someone who works mostly in Ruby I share some of his opinions, albeit for different reasons.

To me the biggest problem with the Ruby development community is also its greatest strength. In the Ruby ecosystem nearly everything is optimized for the developer. What do I mean by this? Let’s look at it from the example of a couple of of the conclusions reached in the above-mentioned post.

The core Ruby development community should mature

One of my favorite things about being a Ruby programmer is how fast it is to code, package and distribute a library. Seriously, look at the front page of rubygems.org:

gem update --system
gem build foo.gemspec
gem push foo-1.0.0.gem

Just run these commands and you have released your code and anyone else can easily search for and install it on their system.

However, I think this process is often too easy. It seems very frequent that versions of gems are pushed before they are completely finished resulting in quick second versions release immediately after the first. Even worse, since a developer can share their project so easily version are often pushed in a "good enough" state and never reach major releases. Rake &emdash; the standard for Ruby project build scripts; used in pretty much any Ruby project you'll come across &emdash; is still on version 0.8.7!? (That's not to say that Rake isn't stable software, I'm just pointing out how common it is for a Ruby developer to use libraries and tools that haven't even reached their first major release and not even think about it).

I'm guilty of this myself. Pretty much everything that I've pushed out to rubygems was nowhere near complete. I just pushed it out because it was the easiest way to share it with my friends/co-workers and it was "good enough" for our purposes.

In addition to this, it is very difficult to judge the quality of any library you will see on rubygems. Does this gem being version "0.1.0" mean that it is incomplete, or are they just judicious in their versioning? This isn't a problem unique to Ruby, but the easy of releasing Ruby packages certainly exacerbates the issue.

The Ruby community should acknowledge that RVM and Rubygems are not for everybody

RVM and Rubygems make my life much easier. I can search for gems to help me write applications I'm working on, isolate them from the rest of my system, and test against multiple versions or Ruby very easily. However, RVM and Rubygems do make somethings more complicated for an average user.

If I want to install an application written in Ruby, I shouldn't have to install compilers and package managements tools. I want to be able to install a Ruby application and not worry about which ruby/gemset RVM is currently pointed at. These tools are fantastic when you are developing and manageable when your used to them, but if you want to just use a Ruby application without understanding the whole standard development environment they can be a pain in the butt.

What's the point?

These problems aren't a huge deal, but it is frustrating to see people claim an argument has no validity because the environment works for them. The Ruby community seems to rush to defend everything that gains popularity without really thinking through the repercussions for people in different situations. It's this eagerness that drives me to Ruby development, but at time I think this eagerness that will send others rushing away.

Follow

Get every new post delivered to your Inbox.