April 29, 2009 @ 05:06 PM by nap · 2 comments
For the past few months I’ve been trying to roll out a 1 or 2-day micro-app every month. Because, why not — it’s fun and refreshing. In February there was tweetdreams, March was Mogo madness (in use at offrails.org), and in April we spent a few days tossing this together.
The this that I refer to in the previous paragraph is Rdoc.info, a simple web service that generates documentation for Ruby libraries that are hosted on GitHub. You can add a new project and it’ll clone the repo from the hub of Git, use YARD to generate rdocs, and then host them for you. So you can read them. Online. Because it loves you.
If you’re the project owner, it’s even better; just add the following simple post-commit hook to your project’s settings in GitHub http://rdoc.info/projects/update and it’ll automatically regenerate documentation for you whenever you push to the remote. So yeah, unlike a random Twitter vanity application, it’s like, actually useful and stuff.
I’ve shown this to a few friends and they’ve had some good suggestions for how to make it more useful. Jeff, in particular, had some really great ideas that we’ve been looking into (more on that later, hopefully). Anyway, I’ve doc’d feature ideas in the project’s GitHub Issues list, and although we plan to get to them sooner or later, I wanted to release it first as-is, in the spirit of “release early, release often”. If you want to help out, the project has been open-sourced in the usual place.
April 22, 2009 @ 09:56 AM by nap · 2 comments
Railsconf is less than two weeks away. I’m pretty excited because this year we’re doing a Rails Rumble panel with a bunch of swell people who developed some pretty amazing things within the compressed event timeframe (48 hours). Winners and other innovators from both the 2007 and 2008 events will be present. The session is called “Starting Up Fast: Lessons from the Rails Rumble” and the point of it is that these guys will be sharing the tips and tricks that let them build great stuff quick with Rails. Hopefully their advice will be applicable to your own startups and hobby projects, in “real life” as well as within the innovation competition atmosphere.
So this is where we need your help. What do you want to ask them about? Project scoping for early and frequent iterations? Essential dev tools and techniques? Finding dependable partners / cofounders? General work habit questions? Inspirational mantras? Anything goes. Please submit your questions via Google Moderator. The event will be recorded and made available afterwards, so you won’t have to be in attendance to get your answers.
April 17, 2009 @ 03:11 PM by nap · 4 comments
Apparently both Extlib and the Mash library, which the latest version of the Twitter gem relies on, both define Mash as a top-level class. This is lame.
It means that if you're building an app that uses the Twitter gem to poll their API, you can't use DataMapper (which relies on Extlib) for your ORM. This is but one example of an affected application, of course (retweet stack trace). Integrity's twitter notification support is another victim. Epic namespacing fail.
So whose fault is this? The Mash library? Extlib? Which came first? Which is more widely used? OMFG fight!
Seriously, who cares? If you're asking yourself these questions you're missing the point.
module Org
module Zerosum
module Util
class CollisionPrevention
def initialize
puts "gtfo"
end
end
end
end
end
Java users, and consumers of other modern programming languages, figured out why namespacing was important a long time ago. In fact, one of the few things I actually liked from the Java world was it's use of hierarchal domain names in packages to ensure class name uniqueness and prevent this sort of ugly namespace collision. It's simple and effective. And yet we don't see a strategy like this in use in Ruby gems all that often. It's not like Ruby doesn't provide us with a mechanism for it; Modules provide a really easy way to accomplish this. So why aren't we taking advantage of it in our libraries?
I don't mean to single out Extlib and Mash in my rant here -- I'm just picking on them because they happen to demonstrate an obvious problem that we've all run into on occasion. Hell, I'm guilty of it too. Anyway, the bottom line is, that if you intend your code to be sucked into someone else's application and reused, please do your best to prevent obvious namespace collisions. It's as easy as A::B::C (or Tld::Domain::Feature::Specification).
Thanks for listening! :)
April 06, 2009 @ 07:18 PM by nap · 1 comment
I’m a little late to the party on this one, but CouchDB sure is the new hotness. We’ve been tossing around an idea for a new project and it’s a great fit for so many reasons. Schema-less? Check. Distributed and fault-tolerant? Yup. Document revision-aware? and it speaks JSON natively via a RESTful API? Oh yes. It’s easy to see why so many people are getting excited about it.
If you’re used to working with relational databases, it definitely requires a bit of mental reprogramming to really grok Couch, particularly when it comes to working with views and designing document relationships without traditional joins, etc etc. It’s powerful stuff, and after working with it just a little bit, I’m pretty enthusiastic, but still feel like I’ve got a ton to learn.
Anyway, in terms of Ruby client interfaces… there are a surprisingly large number of options that’ll make your life easier. Candidates include ActiveCouch, CouchFu, and RelaxDB. There’s also a DataMapper adapter. My personal pick would have to be jchris’s CouchRest library though. The core of it is very simple, modeled around Couch’s own couch.js library. Plus, the ExtendedDocument model stuff gives you most of what you’d want from a traditional ORM through properties, callbacks, validation mixins (lifted from DataMapper), in-line views (think of them as finder/scopes on steroids), attachments, and so on.
Before diving in too deep I figured I’d port a simple project over to Couch in order to familiarize myself with it. So I created a branch of the Retweet project that uses CouchRest instead of DataMapper. Check it out if you want to see how the CouchRest::ExtendedDocument stuff works in a simple project — only one model in this case. It’s quite nice. There’s also a CouchDB branch of sinatra-template, if you wanna use that to bootstrap your own ideas.
Btw, if you’re on a Mac, and using MacPorts, make sure to port selfupdate to the latest and greatest and then port install couchdb-devel to fetch CouchDB 0.9.0. Anything older than that won’t work with CouchRest.
April 03, 2009 @ 12:59 AM by nap · 1 comment
So what do you think?
Btw, it’s true about the sci-fi gadgets — they’re made to order :). I’m also available to build web applications, of course. Probably a better investment.
And yes, the Nth Metal (consulting business) site needs a bit of a makeover. All in due time.
April 01, 2009 @ 03:57 PM by nap · 1 comment
“In brightest day, in blackest night, no feed shall escape my sight!”
Mogo is a small planet-style feed aggregator built on top of Sinatra, leveraging DataMapper and Paul Dix’s supa-fast Feedzirra library for the actual feed processing. It also teams up nicely with [the all-knowing, all-powerful] Sphinx, making feed search a breeze. There’s a working example of Mogo in action installed here.
Source is available on GitHub so feel free to fork away if you’re in need of such a thing. Patches and pull requests happily accepted.
