Lonely Lion

Simon Wistow asks whether or not we need a better open source queuing system. My answer is yes. I’ve built two one-off hackish queuing systems for $work in the past three years, both of which used database tables as queues, both of which were only accessible by a language-locked api, neither of which was accessible by any sort of neutral service. Both had very specific tasks, hold tasks in a queue for offline (read: outside of a web transaction) processing.

Both jobs could have been fulfilled by a nice message queue service, but it didn’t seem like the effort was worth the payoff. That said, now that I’ve built two of exactly the same thing, I’m 100% of the belief that I’d love to have a easy to install web service-y queue (that isn’t owned by Amazon).

So, why the need? It’s sort of like the evolution of CouchDB & friends I wrote about back in December, all web programmers eventually are expected to be programmers, then they start examining the tools the traditionalists have built, and they question, “why can’t this be better?” Relational databases might not be best for web apps (I’m still not convinced, but for the sake of argument, go for it.) Full featured queue services might not be best for web apps. If for no other reason than they introduce a complicated system into your ecosphere for what is actually a very simple problem. I like Simon’s pointing at memcache and saying, “make a queue that works like that.” That would be pretty cool. I’m voting +1.

That said, like a good American I’m making this vote without fully examining all the candidates. Maybe the existing queues are simple enough…educate me lazy-web.

I’m 30!

So, expect a lot more mature blogging now, instead of all this hot open source stuff I’ve been tossing out at you. Now that I’m an old man, I’m pretty sure I’ll be writing Java or C#, kicking back with my enterprise friends, chatting about the power of waterfall.

So long 20′s, I barely knew you.

Yikes.

Consistently behind the curve, I just only recently started reading Martin Fowler’s Bliki.

This morning’s article on GetterEradicators confused me. He’s defending the use of getter methods from those that think that getters violate OO encapsulation.

Huh? They do?

I operate at a pretty basic OO level, I admit to not being the world’s greatest object designer, but getters violate OO? That’s news to me. I’m glad MF is defending the use of getters, as I’m pretty fond of them.

He does point to a bad pattern that I’m relatively guilty of, objects that contain only data. I do this a lot. Then other objects manipulate them. I got into the habit of building SQLObject classes to encapsulate my data, and then building other objects with has-a relationships to those SQLObjects.

That habit came from my inability to figure out how to use SQLObject as a true Object, rather than a wrapper around a database. I’m still a little fuzzy on how you can treat a SQLObject object as a full blown object, complete with methods that manipulate self.whatever.

ActiveRecord objects let me throw in as many methods as I please, with access to self. It’s cut down on my data only objects pretty significantly, which is a good thing (according to MF).

I’m gearing up to do some more SQLObject based work, after a several month hiatus. I think I need to spend some time figuring out how (if it’s possible) to build SQLObject’s that include data manipulators as well as just data. Otherwise, I’ll fall back on my has-a pattern, which I’m not “against”, but feels less clean than having a single object that knows my data, how to manipulate it, and persists it in a database nicely.

Ian on getting hung up. What a great article. I’m kind of behind the curve on blog-reading, as I avoided it while I was on vacation, so I just now read that piece. I like it. Very much. Not so much because I don’t like Rails (I do like Rails, a lot) but because I don’t like the end-all-be-all of anything.

Change, said the little monk with the robe, is the only thing you can rely on. I’m happy to be learning new things (Rails) just like I’m going to be happy to learn Turbogears and Pylons this week. Just like I’ll be happy to learn fancy-new-thing-that-appears-in-Q306.

Keep on keepin’ on you terrific web makers. Rails represents a pretty significant change in the web landscape, both technically and in how to market an open source project. Learn from it, use it, but don’t let it (or anything) become an anchor. If you close yourself off to new things, you’ll miss out.