some code I've been writing lately

posted | comments

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.

the spirit of giving, open source style

posted | comments

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

posted | comments

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

posted | comments

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

posted | comments

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.)