In the beginning, dhh taught us how to build a blog in 15 minutes. A few years ago, I was frustrated with the current toolset for creating a blog in Ruby on Rails, and so I decided to build a pluggable blogging system. That’s when I ran into some Rails 2 monkey-patching issues and never got off the ground. Rails 3, however, allows me to do some seriously cool stuff, and I’ve retooled my previous effort to create Governor. Named after everybody’s favorite governor, Rod Blagojevich.
Governor by itself is very bare: all it lets you do is post articles. Where it starts to get cool is when you start adding plugins. At the moment, there are 9 plugins to choose from, giving you the ability to add an ATOM feed, comments, tags, draft/published states, or even announce your article to twitter, as you post it. (That twitter plugin is built on top of a middle-tier governor_background plugin, which sends your post to twitter outside of your regular request cycle. It can sit on top of either delayed_job or resque.)
Governor will work with most authentication frameworks out of the box, including Devise, Authlogic, and Clearance. If you have different needs, just call rails generate governor:configure, and you can redefine how authentication and authorization will work for your app.
This is my first foray into framework development, so I’m learning a lot. (If you see any issues or anti-patterns, please let me know!) There are a few plugins and features I’d like to implement in the future: better URLs for articles, a better system for blog administration, better asset management, better forms markup, better i18n support, and testing add-ons that can be reused across plugins. But one of the nice things about a pluggable open-source is that, if this is a pain point for someone else, they can extend it. If you end up using this or building on top of this, or if you run up against an issue or would like a feature, please let me know.
governor on github
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.
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.
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.
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.
