Programming and Prose

Introducing Statim

rhburrows — Tue, 25 Jan 2011 07:25:28 +0000

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:

Copies all files from the content directory to the destination directory of your choice
Runs any files ending in “.md” or “.markdown” through the “markdown” command and relocates the resulting html
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

rhburrows — Sun, 09 Jan 2011 07:17:41 +0000

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.

Monads and Channel 9

rhburrows — Mon, 20 Dec 2010 06:06:48 +0000

I spent a large part of my day yesterday watching various videos on Channel 9. There are a lot of videos on there, but after digging a while I can always find some that I’m interested in. I particularly enjoy the Going Deep Series.

The Going deep series has recently started showing a series of talks called Monadic Design Patterns for the Web (part 1, part 2). I’ve only recently begun to develop an intuition for monads (after reading lots of tutorials and haskell code), and I’ve found these lectures to make things very clear to me.

The real reason I’m making this post is Greg Meredith (who gives the above mentioned talks) has started a book called “Monadic Design Patterns” for the web and has started a Kickstarter project to raise money towards writing this book. I personally think this sounds like an interesting book, so if you think so also consider donating.

Emacs File Loading

rhburrows — Fri, 10 Dec 2010 04:30:42 +0000

I have a grown fairly large emacs configuration over the years and I am constantly tweaking it. I test out new packages and remove old ones that I haven’t been using. My original method for adding a new package to my emacs configuration was just to follow the install instructions verbatim from the README, but as I’ve been learning more about emacs and programming emacs lisp, I decided it was time to look into the different methods of including elisp code that were available.

I noticed that some packages use load, some use require, and others use autoload and wondered what the differences were and which ones I should be using…

`load` & `load-file`

load and load-file are the most basic methods of including an elisp file into your configuration. Each one simply reads the file and executes the code. This means that if the load expression is executed more than once the file contents will be executed more than once. There are times where this is useful, but I think that its safe to say that this is not something I desire for the normal case.

The difference between load and load-file comes from the way the file is located on the system. load will search through each directory in the list load-path and if it finds the file there it will load it, while load-file just looks directly at the path that you have specified.

`require`

require is a command that solves the problem of loading the same file more than once mentioned in the previous section. With require, emacs will search for the appropriate file only if it hasn’t yet been loaded and then execute it. To use this the file must use the provide function to define the feature that it includes. After this function has been executed (i.e. when the file has been loaded and the feature has been included), if require is called again emacs will not try to re-execute the file.

By default require expects that the feature will be provided by a file of the same name located within the load path. This can be overridden using an optional second parameter to require but I can’t really think of a reason I would want to do that very often.

`autoload`

autoload works a little differently than the other two functions, as it doesn’t load any file when it is called. Instead, its purpose is to delay the execution of the referenced file until the code within it is actually needed. You give autoload the name of a function and a file that contains that function and, when the function is called — if the file hasn’t yet been loaded — autoload will read and execute the lisp code from within the file. This is nice because it can greatly increase your startup time by not loading packages that you are not planning to use.

On the other side of the issue is each autoload call only binds one function to a file. This means if you have 5 functions contained in a file that you want to trigger that file’s autoloading, you must call autoload 5 separate times in your configuration.

`eval-after-load`

Another potential problem with autoload happens when you have some additional code you want to execute after the file has loaded (i.e. you want to change some of the keybindings defined within the file). If you were to set them at startup time, when one of the autoload functions is called the file will be read/evaluated and your bindings will be overridden back to the defaults.

Luckily, emacs has already thought of this problem and provides us with eval-after-load. This function allows us to define some additional code to evaluate after some specific code is loaded. In our previous scenario if we define our keybindings using eval-after-load to execute the definitions after the autoload, our code will be executed second and override the files keybindings back to the settings we want.

Applying this knowledge

After clearing up my understanding I have decided on a few things:

I want to remove pretty much all load and load-file calls from my configuration.
I want to switch all of my modules that I can to use require.
I want to use autoload only rare occasions when loading the file takes a lot of time/resources.

My first instinct was to move as much as possible to autoload but I realized that I don’t actually start emacs very frequently. I usually just leave it open and close and open buffers as necessary. For this reason I think I would find the sudden pause when loading a module that I am referencing for the first time more annoying than an increased startup time (YMMV).

Now that I’ve got a plan all that’s left is to actually do it.

Book Review: Land Of Lisp

rhburrows — Tue, 23 Nov 2010 22:22:41 +0000

Land of Lisp is a book written that teaches programming in Common Lisp through writing a series of games. It attempts to inspire the reader through fun example programs and is an overwhelming success.

This is one of the few programming books I have read where I found myself really wanting to finish off each sample so that I could play the resulting game. It does a great job of creating games that are fun and original enough to hold your attention.

Not only this, but the book actually goes into quite a bit of depth for each of the topics covered. During the course of building these games the reader writes a web server, a DSL for creating SVG, and an interface for adventure like games. Through these exercises many of the benefits of Common Lisp (and all lisps in general) are explored.

Does this have me wanting to rush out and use lisp for my next project, no. But, I will certainly consider it, and I had a lot of fun reading through this book and learning the language.

Book Review: Focus

rhburrows — Sat, 20 Nov 2010 05:00:52 +0000

I recently read through the free release of Focus by Leo Babauta. Its short, about 125 pages, and reads very quickly. I enjoyed the read and definitely got some ideas from it about both why and how to focus better.

The book’s main point seems to be that in this busy age of distraction focusing on a single subject at once can be very difficult. Despite this, focus is very important to productivity, and to enjoyment of your life. By consciously acknowledging the importance of focusing we can make steps towards improving our own attention to the topic at hand.

Most of the contents of this book didn’t strike me as new information, but seeing it all presented in one place helped me to realize how well everything plays together. Avoiding distractions and interruptions has always been important to me, but for some reason I previously only associated these ideas with work. After reading Focus I realize that these same problems can hurt enjoyment of other aspects of your life. I also found his view on goal setting in the chapter “Letting go of goals” to be an interesting alternative to ideas I’ve heard in the past.

I only read the free version of this book because I was just curious and the vast amount of stuff included with the premium one looks overwhelming; but assuming the premium one is of comparable quality to the free one I think it would be worth the money. I am definitely going to be evaluating whether or not it is something that I want to buy.

Book Review: Start Small, Stay Small

rhburrows — Tue, 16 Nov 2010 03:29:32 +0000

I just finished reading Start Small, Stay Small: A Developer’s Guide to Launching a Startup by Rob Walling and I thoroughly enjoyed it. It struck me as The Four Hour Work Week with most of the fluff/exaggeration stripped out and presented from a developer’s perspective. I generally rate business books by how much they inspire me to start working, and by that rubric this one’s a winner.

Start Small, Stay Small does an excellent job of explaining what is necessary to run a software business to a developer who may think that creating the product is all that needs to be done. The book’s short length and the avoidance of unnecessary filler makes the information (at least feel) much more actionable than advice I have read in other books.

Business books in the software world seem to be mostly focused around the venture capital driven, make it huge types of companies but this book presents an alternative plan; one that is more realistic for the average developer. The options of bootstrapping a company and then growing it larger, or just creating a small, self-sustaining business and going on to found another are presented along with reasons why each one should be chosen. Even if your goal is to build a gigantic company, the information on marketing in this book could prove invaluable.

In short, I found this book to be exactly what it advertised; a blueprint to getting a startup off the ground for a developer.

Scripting with ruby

rhburrows — Sat, 13 Nov 2010 21:30:06 +0000

Earlier I wrote about using Unix command line tools to manage text when the job at hand calls for a quick fix instead of a program that you plan to keep around. When the script that I’m writing is a longer one I will often reach for ruby, but ruby can also be quite useful for quick scripts. Specifically, the ruby executable provides several command line flags that are helpful when writing these quick scripts.

-e

-e is the first flag we’ll need for using ruby as our command line swiss army knife. If you call ruby with -e it will evaluate the string following it with the ruby interpreter. Example:

ruby -e 'puts "Hello, world!"'

Got it? Good, now lets move on to more interesting options.

-n, -p, and -i

The -n flag causes ruby to loop over each line of the input. For example if you want to capitalize all of the lines in a file (to stdout) you could do the following:

ruby -n -e 'puts $_.upcase' < original-file.txt > upcased-file.txt

Printing out something is so common that ruby provides another flag that will print out the value of $_ after each step. With -p the following example becomes:

ruby -p -e '$_.upcase!' < original-file.txt > upcased-file.txt

Notice that we are now using the destructive version of upcase (namely upcase!) so that the value of $_ is redefined before it is printed out. It turns out that taking a file, performing some operation on each line, printing the changed line and then putting in a new file is so common that ruby gives us yet another flag to help with this occasion. We can shorten our simple example even further with -i:

ruby -p -i -e '$_.upcase!' file.txt

The -i flag tells ruby to operate on the passed file in-place. This means rather than redirect the file into ruby and the output out of ruby, it will open the file itself and overwrite it with the modified lines. Obviously this isn’t quite the same result as the earlier examples in that the original file is no longer maintained. If you don’t want to lose the original (or you aren’t confident that your script is going to work as expected) you can pass -i a backup extension to make a copy of the original file.

You’ll notice this is similar to the -i flag of sed. I find myself using ruby with -i now whenever I might reach for sed because the -i flag of sed seems to work differently in Linux than in the BSD tools. With ruby I don’t have to worry about the cross-platform stuff as much.

Other Resources

Dave Thomas (of the Pragmatic Programmers) put together a list of handy one liners for ruby. This is old but still quite useful:

http://www.fepus.net/ruby1line.txt

And, as always, the man page has a lot of great information.

Call For Help

rhburrows — Sat, 13 Nov 2010 04:01:25 +0000

What is the best way to edit a wordpress.com blog within emacs? I tried to use weblogger from the ELPA but I had some trouble with accidentally overwriting my posts. I heard something about using org-mode to post to WordPress (this sounds good) but I was wondering if there are any other options, and which ones are commonly preferred.

Testing mobile sites with Cucumber

rhburrows — Thu, 04 Nov 2010 16:16:37 +0000

Recently I was working on a site that had been originally built with Rails 2 and was later migrated to Rails 3. As part of the migration the cucumber integration tests were switched from using Webrat to drive the UI to using Capybara. Unfortunately this broke a handful of tests for the mobile version of the UI.

Take One

The site decides whether or not to show the user the mobile version of the site based on the user agent. The problem is that Capybara won’t let you set custom headers (such as the user agent) the Webrat will. After a quick search of the internet I can across This site. In short the blog post details a way to open up the current RackTest driver (the default driver that cucumber uses) and adds a way to put in arbitrary headers.

I added the code in the blog post to my project and indeed it fixed my tests (with a little reorganizing). Something about it struck me as wrong. Even the blog post I got the technique from calls the class a “Hack.” I wanted to find a cleaner way…

Introducing capybara-iphone

My “cleaner” solution was to write a new Capybara driver that pretends to be an IPhone and to have the mobile specific tests run with that. It is a very simple project that extends the Capybara::Driver::RackTest code and adds an additional user agent header to identify itself as an IPhone. Now all you have to do is set up the capybara-iphone gem in your project and tag the tests that you want to run the a mobile browser with ‘@iphone’.

The Future

One could imagine an incarnation of capybara-iphone that adds support for handling that IPhone specific javascript calls, and lets you do other things that better test your application’s IPhone interface. At the moment, however, I don’t have plans to do any of these, but the project sounds fun enough that with a little push I might start working on it.

More information on using capybara-iphone can be found in the Readme on Github.