some code I've been writing lately

Update: Plogger has been renamed Blugg, so as not to be confused with the open source PHP photo gallery. I'll most likely be rewriting Blugg as a Ruby Gem instead of a Rails plugin, but this change probably won't take place for a few weeks. Stay tuned!

Short version: I wrote a pluggable blogging system in Rails called Plogger.

Long version: So, I've been working on updating my website lately, and I looked around to see what's currently going on with Rails blogging systems. When I first started getting into Rails, Typo was the only system out there. But I wanted to develop a Rails site myself, and Typo doesn't really make that easy. Neither does Mephisto.

For this version of my site (published about 2 years ago), I wrote my own system, which has served me pretty well. 2 years later, I was hoping that Rails' options for blogging systems might have improved. Full-scale applications like Typo and Mephisto are still popular approaches, though I read a lot about people who have used them who decide to switch to Wordpress (because as much as we want to use Ruby/Rails software, we don't want to worry about our blog).

I also looked at Bloggity, Bloget, and Enki, but they were either too opinionated for me, or did not concentrate on the feature set that I was most interested in (for example, allow guests to comment).

Seeing as how I'm on break right now, I decided to write my own blog plugin. I wanted to write a minimal system that did just what I wanted, but make it pluggable so that people who want additional features can easily add them. Enter Plogger, and the first few plugins I've written for it. We'll see what happens.

new year's!

it's that time of year, again... time to take stock and make plans. here are a few.

• graduate
• make school the highest priority
• make joy the other highest priority
• take care of myself
• communicate
• stay organized, both physically and mentally
• eat well, stay in shape
• ride a century
• live by a budget
• expand my culinary skills
• make some open-source contributions

There are probably more out there, we'll see what happens.

the good news and the bad news

the good news is, i'm back at WPI, finishing my undergrad.

the bad news is, i can't pass for an undergrad anymore, i look too old.

I think the Democrats are right

I think the Democrats are right when it comes to spending on a philosophical level at the moment, and that's not just because I'm a Democrat myself. Who doesn't truly sympathize with the Republican cause of limited government and giving power to the people? The problem is, the entrepreneurs that Republicans would have save us aren't getting any funding, because capital is dried up, because the banks aren't lending. Surely there must be somebody who has capital? Sure- the federal govt. Ok, so we're borrowing from our children, but aren't we always? Didn't our parents get us in this mess? And if this works, and the economy improves, then won't they be in a better chance to shoulder the load? As obviously, we can't at the moment.

Not that I agree with all of the spending that some House Dems wanted. But Republicans need to realize that the Republican ideals aren't going to save them right now, that they don't have the votes even if they did, and there's no valor in saying "I told you so". The federal government is the only body that can do something about this, so let's try to get something constructive done for a change.

End rant.

the spirit of giving, open source style

So as many in my current little niche of a business community know, Ruby on Rails and Merb have decided to combine forces and become some sort of Ruby super framework. I had just come home from Christmas shopping to find my RSS feed full of blogs from some of the players involved, so I jumped on to IRC to try to get a feel from the community.

The results were mixed: some of the prevailing thoughts was "What's in it for Merb?", "I thought Rails embodied all of the aspects of a framework that we wanted to get away from.", and "Why not combine them into a new framework instead of merging Merb into Rails?"

Well, there's a ton that Merb, or the Merb community, will get out of this: for one, access to a wider community of plugin developers and framework contributors. Being able to pitch a project to a client and not have to say that we'd like to use a 1.x framework that is still going through growing pains. Validation that Merb took the right approach and has added some fresh insight and serious benefits into the medium-sized MVC Ruby web app field. Rails will no longer embody the aspects of a framework we don't like: no code is still faster than no code, there will be a public API. Promises have been made about dropping alias_method_chain. It's a Good Thing.

That's not to say that this couldn't be messed up: there are a million ways this could go wrong. When it comes down to it, what really matters are the people involved. If you've got good people working together, you'll do a lot better. Get the wrong people spearheading a project, and the best project can become a nightmare.

The key people heading up Merb and Rails said all of the things you'd expect them to say. They're the public face of their respective frameworks, after all. However, it's some of the developers of each framework that actually made me feel better about this. They said the things I needed to hear.Carl mentioned his initial fears (similar to mine) and how they were assuaged, and Pratik (on IRC) did mention that Rails 3.x would be a lot less bloated than current Rails. Pratik has in my mind often been playing defense when it comes to Rails, so it was heartening to hear him be open and forthcoming on the aspects that would be improved.

While I'm not naive enough to think that they'll be able to deliver on every promise, I'm cautiously optimistic, and I'm thinking things just might work out after all.


Meanwhile, I've been busy writing a lot of open source material. The mantra of OSS has always been that you have the power to make it what you want, and while I've always believed that, I've always been content to want what other people make. But when I bit the bullet and fixed a bug in an OSS library that I was using, I kind of caught the fever and started doing this all over the place. The result is a dozen open source projects on GitHub, roughly half of which are forks of other projects, contributing little additions here or there. When I have time, I'll go into more detail on these projects over at http://carpeliam.github.com.

Well, tomorrow is Christmas, and I have gifts to wrap, so I hope everybody gets what they were hoping for this year, whether that be a merge of your two favorite web frameworks or some nice open source software.

hallelujah, audio works in Ubuntu Intrepid

I recently installed Ubuntu, first to work on Merb projects, then to work on creating a virtual machine for carpeliam.com. Now, I just plain like it.

But the difference between me now and me when I first tried Debian in college is I had a lot more time back then to fool with things if/when they didn't work. And for many people, unfortunately, Linux is still not something you can install and have it just work.

But after I convinced myself that a lack of good tunes was hurting my productivity, I spent hours on Google, in #alsa and in #pulseaudio trying to figure out how to get audio to work in my Ubuntu Intrepid desktop. (#ubuntu has for the most part been useless to anyone asking a question that couldn't be answered by Google in 5 minutes.)

The first problem comes from the fact that there seem to be several places where you can set the default soundcard, not the first of which is Alsa's ~/.asoundrc. First, this seems to be completely independent of Gnome's "Multimedia Systems Selector" in System>Preferences, which isn't even visible by default (you need to enable it in the menu, but why would you, it doesn't seem to affect anything). But I won't cover either of those, because they both seemed irrelevant.

PulseAudio seemed to be the default, seemingly oblivious to the fact that nothing was pointing to it and asking it to play.

$ aplay /usr/share/sounds/question.wav
Playing WAVE '/usr/share/sounds/question.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
ALSA lib pcm_pulse.c:629:(pulse_prepare) PulseAudio: Unable to create stream: Invalid argument

The first thing I tried to do was to get sound working without PulseAudio, but that wasn't working for me either. Apparently this is where things differ between me and the rest of the Ubuntu community- a lot of people leave PulseAudio, and things just "work". If anybody can tell me why what works for everybody else doesn't work for me, I'm really curious. But here's what I tried:

$ aplay -Dhw:0 /usr/share/sounds/question.wav
Playing WAVE '/usr/share/sounds/question.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
aplay: set_params:954: Sample format non available

A few minutes in #alsa came back with a result: use plughw:0 instead of hw:0. (Didn't catch the reasoning behind this, something about "HDA codecs", somebody please enlighten me.)

At this point, my Google Radar is going off: if this is the right solution, why doesn't Google mention it? Oh well, pushing forward--PulseAudio is still the default, and still giving me problems.

Two options: either uninstall PulseAudio, or try to figure it out. The guy in #alsa tells me to ask someone in either #ubuntu or #pulseaudio; given my constant lack of success getting questions answered in #ubuntu, I went to #pulseaudio.

Commence hours of debugging with somebody who is probably a code committer with pulseaudio. (The guy in #alsa probably was too, it's definitely helpful when you go to the source.) Long story short: plughw is apparently the way to go.

All I needed to do to get pulseaudio to work for me is to create the following (in ~/.pulse/default.pa):

#!/usr/bin/pulseaudio -nF

.include /etc/pulse/default.pa

load-module module-alsa-sink device=plughw:M44 rate=44100 sink_name=delta44
set-default-sink delta44

This includes the system-level default config so nothing gets overwritten, and then loads a module that specifies my sound device using plughw. M44 is my device's name, but plughw:0 could also work just as well, or insert-your-device-name-here. Name the sink whatever makes sense to you, just as long as the sink_name you give in line #5 matches the value in line #6.

I'm still kind of curious why I need to use plughw instead of hw--my gut tells me I'm somehow cheating the system--but now that sound works, I don't really care too much.

happy birthday to me

If you can read this, it means that carpeliam.com is successfully running on a virtual machine, running on top of JeOS, nginx front-end proxy server, thin Ruby web app server, Rails, and what have you.

I also borked my windows installation while repartitioning my hard drive, so i'll be reinstalling XPx64 sometime next week. Yet another birthday present I'm giving myself. Woo.

on the road again

It's good to have pet projects and hobbies. Music has unfortunately been in a lull as far as collaboration is concerned, and will probably stay that way until I have a good way to cart my crazy large keyboard around.

In the meantime, I've been getting a bit more serious about my bike. The trek really got me thinking about biking as a means of transportation, as a workout, as an activity, and as something just plain fun. The problem with bikes is that they're a money sink. I thought I was saving money when I got a pair of bike shoes for 65% off, and a bike jersey for around 50% off. And then I buy the pedals/cleats, and the multi-tool, and the odometer, and all of the sudden... Bikes might be the most efficient means of transportation, but recently, it's been the most efficient way of thinning out my wallet.

I had my first ride in my new cleats today. Cleats really help with efficiency, but the flip side is that it can be kind of hard to get your shoe out of the pedal when you need to. For beginners (which is me), you're supposed to practice releasing your foot from the pedals at a fair distance away from where you actually want to stop. This was working fine today, until 5 miles into my 10 mile 8 mile ride, my chain decided to derail at the bottom of a hill. No time to prepare to release, I was kind of stuck, and really lucky that I was able to get my feet out and avoided falling into the road (which almost happened). I'll have to take a look at the chain/gears... I'm not at the point where I can actually service my bike (though I did manage to put the new pedals on), but I want to learn. At some point, not this season but within the next 2 or 3 years, I want to do a century (100 miles). At that point, the Trek Across Maine might be nothing. (Here's hoping.)

I'm thinking like a rubyist

I've been feeling the urge to blog about some of the code stuff I've been working on. So, after taking a little while to install a code highlighter on my carpeliam.com blog, I'm ready to get started.

On HungryWorcester.com, we're trying hard to integrate mobile capabilities into the website. This starts with serving a version of the site to phones that doesn't include a ton of graphics, css, or javascript. Thanks to the popular mobile_fu plug-in, this is possible. But inevitably, because I'm doing most of my development on a desktop machine and not a mobile phone, I forget to make equivalent views for the mobile site. Because I'm viewing the site through firefox, I rarely ever detect a problem, until somebody else says "Hey, is page x supposed to work on the mobile site?"

Of course, like every other coder out there, I'm diligently using TDD. (You are using TDD, aren't you?) But writing tests for the mobile site is a pain, and I haven't been doing it.

I figured it was time to find a way, and so I set out to do some mobile testing.

Unit testing in Ruby is pretty similar to most other languages: you've got your setup, your test method that starts with the word "test", and your teardown. I wanted to take certain tests that were already running and run them again in the context of a mobile session. First, I had to figure out a way to emulate a mobile session. That's easy.

def set_mobile
  @request.env['HTTP_USER_AGENT'] = 'nokia' # or any other random phone
end

Calling this method at the beginning of my test will run the rest of the test within a mobile context, like this:

def test_mobile_should_allow_signup
  set_mobile
  test_should_allow_signup
end

But I don't want to write this block for every single mobile test, that would take forever. And then I wouldn't have time to blog about it afterwards. I knew that in Java/JUnit, you can wrap your tests in a test suite, and use annotations to describe which tests should be run under which contexts. But Ruby doesn't have annotations, as far as I know.

I guess that's because it's not the Ruby Way. So I thought about it: what is the Ruby way? doesn't Ruby have some really great metaprogramming options? Turns out, it does. In Ruby, it's easy to add methods at runtime. How easy? This easy:

def self.add_methods_to_mobile_tests args
  args.each do | method_name |
    define_method "test_mobile_#{method_name}" do
      set_mobile
      eval("test_#{method_name}")
    end
  end
end

I just add that method to my test_helper, and then call it like this from my test:

require File.dirname(__FILE__) + '/../test_helper'
class UsersControllerTest < ActionController::TestCase
  add_methods_to_mobile_tests %w( should_allow_signup should_require_login_on_signup )
  #... a bunch of tests
end

This way, it's as easy to test functionality in a mobile browser as adding the test name to an array. I probably could find a way to refer to these methods as actual methods instead of strings, which would make it a little bit less error-prone, but this is good enough for me. All in all, it makes the tests more robust, it cuts down on the amount of coding I have to do, and makes us all happier people.

...aaaannnnnnd we're back!

carpeliam.com has finished moving across the internet to a new host, and the result is a better, faster, stronger website. It looks like it finally finished propagating itself across the internet (I think I was the only one who couldn't see it for a while), so I guess it's safe to announce its return.

carpeliam.com is currently built on top of the ever so lovely and talented Ruby on Rails platform. It's fantastic. But there's another, leaner, faster fish in the sea of Ruby web frameworks called Merb, and I'll be redesigning the website to use this framework in the near future. Don't expect anything too soon, as it's going to be redesigned both front and back, inside and out - a brand new face to go with its brand new shiny interior. But when it's live, oh baby. Well, hopefully it doesn't suck.