I've been known to make resolutions before. Sometimes they pan out, and sometimes, in the case of 2012's cooking expedition, they're a bit mixed in their success. But that shouldn't stop me from trying! With that in mind, here's what I plan to be up to in 2013:
Learn something new, every day. Seriously. Sometimes, you might say, "you learn something new every day," but often times, a day (or weeks) might go by where you don't learn anything, or you don't retain what you've learned. I'm making an effort to be consciously aware of my learning, as well as seek out knowledge on a daily basis. Part of the idea is that awareness of learning will help spark knowledge retention. The only rule to this is that I can't seek out knowledge for the sole purpose of filling my daily knowledge quota. Hopefully this will also force me to be more engaging in seeking out knowledge for general purposes.
Focus on fitness, activity, and diet. These all go hand in hand. I want 2013 to be a seriously active year. In August of 2012, I got back into running as well as rock climbing. Since then, I've won a (really really small) 5k, I've become an intermediate climber, and I'm considering training for a triathlon. I also was given an inflatable kayak for Christmas, which promises to be an excellent workout. I don't want to turn back now! I'm going to need to learn how to eat better if I want to get more out of my body, and I'm probably going to need to learn how to sleep better too. Hopefully, 2013 will see me visiting Acadia National Park, climbing the best rock climbing routes in New England, and perhaps even completing my first triathlon. Maybe somewhere on the horizon is a marathon, who knows what the limits are.
Side goals include writing and performing more music, making new friends, and if I'm lucky, getting back into the swing of cooking, continuing where I left off in 2012. Hopefully my band The Colors Run will be putting an album together in the March-April timeframe, so that's one goal that's looking pretty realizable. Here's to an accomplished and fulfilling 2013!
I had been using Rails to run my site for a few years now. I love Rails. I use
it daily. I even wrote a blogging gem
for it, which has attracted a small to moderate number of users, largely due
to a mention on the Ruby5 podcast 2 years ago
during RailsConf. At the time, I thought it was really important that Rails
developers use Rails tools.
But I'm not a Rails developer: I'm a full-stack developer. I still love
Rails–I still use it daily–but I use JavaScript and a host of
other tools on a daily basis as well, and as much fun as it would be to port a
blogging gem to node.js... actually, I don't think I'd enjoy that at all.
Sure, it might be an interesting exercise, but there are much more interesting
things to use node for, and much more interesting things to do with my time.
So when Rails 3.1 came out, and my blog app broke, I couldn't bring myself to
invest time in upgrading it... I wasn't even sure if it made sense in the
Rails ecosystem anymore. And, as it turns out, there are much simpler systems
I can use.
Jekyll is such a system. Rather than running on top of Rails, it's a static
site generator that accepts blog posts written in markdown/textile. Which
suits me fine, because the blog aspect of my site was the only dynamic part of
it. Everything else was done through JavaScript and web services.
So for the time being, all of my old articles are missing. Soon, I hope to
import my old articles into Jekyll. I'm hoping though that the flexibility of
being able to edit articles in an offline editor will allow me to write more
often as well. We'll see how it goes.
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.
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.
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.)
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
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.
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.
Copper Tree had a 3 hour show scheduled for this Saturday at Sangria's Bar and Grill in Lowell. Unfortunately, Ravi and Damien won't be able to be there :( so I'm kind of in this awkward position of playing a solo show. Right now, I'm scrambling to figure out how this is all going to work. Knowing 3 hours of material is surprisingly the part I'm least concerned with. I'm more concerned about finding people who can come. Sangria's is a nice-looking bar and grill located in scenic Lowell, Massachusetts. They serve dinner until 10pm, so if you want to get some food, you should probably get there in the first hour. Because they serve alcohol too, it's 21+. If you could come, I would be ecstatic.
I hate eating by myself. Eating to me is such a social thing, I love to eat with other people. A while back, I tried to start a "Feed a Liam" campaign, but it never really got off the ground, maybe because it involved eating out, which doesn't work into a lot of peoples' budgets/diets. I'm also not a very experienced cook, either. Most of my home cooking involves some kind of prepared meal-in-a-bag deal, which isn't really particularly healthy or cost-effective. I hate cooking by myself too, because it's a lot of effort for little return.
I was thinking- I've got a lot of time on my hands (and not much money), I really should learn how to cook. I'd also like to resurrect the Feed a Liam campaign, though eating out isn't such a good idea. So here's what I think would be great.
Let's cook together. You pick the day, you pick the time, breakfast, lunch or dinner. We agree on the food, and I'll pay for at least 50% of it. I'm aiming for making meals that I can learn and remember and potentially cook by myself if necessary. My car situation at the moment is a little sketchy, so cooking/eating at my place is preferred, unless your place is within walking distance or you want to pick me up. Doesn't this sound like just the best thing ever?
If for every door that closes, another one opens, I'm currently standing out in the hallway in front of the Copper Tree door, still somewhat ajar, but slowly and silently closing. Yeah, in other words, Copper Tree is quietly ceasing to be. And I get the sense that all three remaining band members are implicitly ok with that. Any one of us could be propping the door open, but it seems that none of us want it badly enough, including me. And that shouldn't be taken for anything more than it is- the band ran its course, it was enjoyable, it's just not going to last. It may have been better if we had figured this out before we decided to pay for studio time, but at least now I have some recordings for songs like Silhouette and All These Lazy Angels that I know some friends have wanted. And we do have a few more shows in the works before we all go in our separate directions, so I'll keep you all updated with that.
In the meantime, I've been writing more material. Now that I'm not writing with Copper Tree in mind, I'm able to be more personal and more honest, less concerned with "can this work in a 3-piece piano rock band". I even posted a song the sound of music on youtube:
The next step is to find musicians that'll stretch me in a different direction. I met a girl at Castellana's who's kind of a jazz singer, but she's starting this Mars Volta-esque group, could be interesting. I'm curious what it'd be like in a band where other people are writing a lot. We'll see where things go.
So as a lot of you know, my dad died of lung cancer just over 10 years ago. Well, I'm going to bike across Maine in order to raise money for lung research. If you've ever driven through Maine, you know it's a gigantic state compared to Massachusetts, and it'll take three days of biking to get from one side to the other. Now I've done the Walk for Hunger, which is 20 miles long, and sometimes, there were blisters involved. This is going to be a lot more difficult.
I also need to raise a lot more money. I'm going to have to raise $500, so I'll be asking all of you to help me out in any way you can. I'll probably be talking to a lot of you in person, but the easiest way to help is right through the web, so I'm going to put this here. Please visit this site to pledge for me to bike across Maine. The money is going directly to the American Lung Association of Maine. If you have any questions about the whole thing, please let me know. Also, I've got a roadbike, but I don't have much else, so if you have supplies that you might think are beneficial, those would be much appreciated as well. Thanks in advance to those of you who will help make this happen.
if barack obama's speeches weren't pretty hot already, the guy from the black eyed peas set his post-New Hampshire primary speech to music, along with a whole bunch of other famous people. it's not connected in any way to obama's campaign, though i'm sure he's enjoying it now. i wonder if this will get radio play on clearchannel?
i'm not sure if the youtube video will stay up, but www.yeswecansong.com (currently redirecting to dipdive.com) has the full video.
I've been blogging on and off since the day I turned 22 (way back in 2001). When I started doing server-side programming in PHP in 2002, I made my own blog, but after a few months, the GDC (which was housing the website) lost everything on their servers, and i didn't have any backups. After that, I wanted to try something that integrated into LiveJournal so I wouldn't have to worry about a database crash. I tried writing a Flash wrapper around LiveJournal, but that sucked hard. So when I started carpeliam.com, I had a spot for a blog to go, but it didn't actually exist.
Until now. I came up with the cool idea of housing the blogs on my own personal database on carpeliam.com, but simultaneously publishing it to LiveJournal through the LiveJournal API. I plan to add more features soon, like when I finish writing a song, it'll get a blog entry automagically. And of course there is an RSS for the whole thing, which might end up going up on facebook too. We'll just have to see what happens.
So 2012 is here, and I've run out of excuses to be terrible at cooking. So I purchased a book or two (the 
