you have to break a few eggs. I've got the breaking part covered.
posted
So 2012 is here, and I've run out of excuses to be terrible at cooking. So I purchased a book or two (the how to cook everything iPad app, and I'm looking at Cooking for Geeks) and went to town in the spices/baking aisles at Stop & Shop. Well, tonight, I made my first dinner, and it didn't turn out quite as well as I would have liked. This is probably not what omelettes are supposed to look like. Good news is, there's nowhere to go but up.
If you'd like to get together and cook with me sometime, let me know, as cooking is a lot more fun as a social thing, and I won't have to eat all of my mistakes by myself.
I got into Rails in the late summer of 2006. It was a pretty wild ride: Rails 2.0 was still over a year away, Github didn't exist, we were installing plugins (not gems) by finding them on technoweenie's SVN repository, and best practices/libraries hadn't really congealed yet. Everybody was more or less making their own way. This was somewhat restrictive, in the sense that we didn't have the same communication tools, documentation resources, and software libraries we have today; but also extremely productive, as it forced the community to come up with creative solutions that would build on top of each other and create a best of breed. This is standard in any evolutionary process, and Node.js proves to be no exception.
Node.js is in a similar state at the moment, where best practices, documentation resources, and best-of-breed software libraries are still congealing, and at an extremely rapid pace. The community has plenty of really creative and intelligent thinkers who are writing some great code. The Node.js revolution may have a leg or two up on the Rails revolution, however. For one, it can draw upon the wide array of JavaScript programmers who have a decade or more of experience. For another, I think the Node community has been able to learn from the Rails community (of which there will surely be some overlap) about coding practices, deployment practices, and what it means to develop for a niche web platform.
I've been playing with my own Node.js app for a few days, and I've learned a few things. Number 1, everything you heard about code reuse between the server and the client is true. Using browserify, I was able to expose some server-side CoffeeScript as client-side JavaScript without having to have to do too much. Very cool. Number 2, library development is going quickly, and a lot of it is being sponsored. Whereas Rails was presented as a full stack and Rack only came after other Ruby frameworks started to pop up, Node.js is pretty low-level, and is being added to from the ground up. Sencha Labs (perhaps best known for Sencha Touch) sponsored Tim Caswell and TJ Holowaychuk to create the connect middleware, and Holowaychuk is taking this further with Express, which is Node's equivalent of Sinatra. LearnBoost has sponsored Guillermo Rauch to create Socket.io socket transport layer, on top of which DNode and Juggernaut can build RPC and pubsub libraries. (Even these libraries, as well as Express, have formed as a base for otherlibraries to be built on top.)
Just as Rails was to me 5 years ago, Node.js is providing an exciting landscape.
but what am I doing with Node?
Well, I'm glad you asked. A friend of mine once taught me this Chess variation called Kriegspiel, where you can see your pieces but not those of your opponent's. Through trial and error, you have to build an understanding of where your opponent's pieces are, while they're trying to do the same regarding your pieces. It's a very challenging game, and I thought it'd be a great experiment for Node's asynchronous nature. Also, my friend has been living overseas for the past few years, so it's probably the only way we'd actually be able to play again. Enter Kriegspiel.js.
There are a few problems with the game right now... for one, you actually see both white and black pieces, and for another, it doesn't actually work. But most of the pieces behave properly, and most of the captures work appropriately. Check, mate, en passant, and castling rules haven't been implemented yet. But it's coming along. And maybe one day you'll be playing a game. Go ahead and try it out.
In a recent HTML5 class, I got to play around with some cool new technologies, including canvas, geolocation, html5 forms/markup, and others. Here's one little thing I created.
It uses processing.js to do the actual canvas drawing, local storage to manage the recording/playback, the new 'number' HTML5 input type, and some jQuery/math to glue it all together.
You can use the input to increase/decrease the number of bars attached to the cross, and you can use the mousewheel to make it grow or shrink.
because "Blogojevich" would be too tough to remember/spell.
posted
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.
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 themwhodecide 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.
recent OSS excursions and a quick take on the Rails/Merb merger
posted
So as many in my current little niche of a business community know, Ruby on Rails and Merb have decided to combineforces 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 MerbandRails 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.
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):
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.
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.)
So 2012 is here, and I've run out of excuses to be terrible at cooking. So I purchased a book or two (the how to cook everything iPad app, and I'm looking at Cooking for Geeks) and went to town in the spices/baking aisles at Stop & Shop. Well, tonight, I made my first dinner, and it didn't turn out quite as well as I would have liked. This is probably not what omelettes are supposed to look like. Good news is, there's nowhere to go but up.
