Obviously, I’m paraphrasing.
(If you watch the video, feel free to skip over the Q&A period, in which I ask a batshit crazy question and blame democracy for the inability of Python to feed more families.)
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.
Amazon is starting a limited beta of an online database they’re calling SimpleDB. It’s functionally very similar to CouchDB, in that it uses REST for queries and inserts, stores data in flat “schema-less” pages, and is generally geared towards web-app-like data. The NYTimes DBSlayer takes a half-fast approach by layering a JSON REST API on top of an existing relational database.
Although these three projects each take a different stab at the same problem, they all agree on one thing, “you should really put DB in your name…somewhere.”
Amazon SimpleDB solves the problem that a lot of EC2 explorers end up running into the minute they want to have persistent data across sessions. Because EC2 is a fresh slate on each reboot, typical databases aren’t really usable, unless you spend an awful lot of time figuring out how to off-load your data to Amazon S3 on a regular basis.
I wish I had some sort of pithy analysis of the recent leanings by web-visionaries away from SQL databases and towards these sort of REST db’s. The timeline in my head goes something like this:
Raw SQL begat ORMs begat full stack web frameworks begat wrapping a REST interface around an ORM begat “hey, let’s have our controllers talk to the REST interface, rather than the ORM” begat “hey, why do we need an ORM, or a traditional database? Let’s just make a REST accessible database!”
I guess that’s relatively pithy.
Really though, I’m not entirely sure what to make of this “trend.” I’ve yet to build even a trivial project using any of the three (Amazon is a closed beta, so I’m not sure if it’ll even be a possibility anytime soon). Maybe it’s time I take a crack at one of them.
Django and Rails are friends. At first Django is irritating and aggressive. Rails is up tight, but Django teaches him how to have a good time. Then they drink 40’s and pour some out “for their homies.”
Just a bit of technical correction though, no one pours their beer out for their homies in the sink. They do it on the ground. Because their homies are in the ground. So, unless your homies drowned in the sewer system, make sure you pour it out…on the ground. Peace. Also, Django is pronounced Django*.
Regardless, Django and Rails are friends! How great!
* Intentionally unhelpful.
Google jumped into the crowdening [sic] arena of ways-to-make-your-web-app-work-offline with Google Gears. I’m pretty excited about the whole concept. Just last night, me and Mrs. McAvoy were heard to exclaim, “I really like Google Docs, I wish it worked offline.”
Clearly, the Google bugging of my home has finally paid off for the Googineers. Glad the McAvoy’s could help you out guys. Good luck with your Gears.
I want to start messing with this offline stuff. Lots of fun ideas come to mind.
Edited to add: O’Reilly Radar explains the whole thing a lot better than me. We live in the future folks. This is really neat stuff.
Edited (again) to add: Holy cow! Dojo offline is now built on top of Gears! This is the greatest!
From what I’ve gathered, deployment was a big theme at this year’s Railsconf. There’s a handful of groups targeting different virtualization platforms for easy-instant Rails deployments. DHH started a mailing list for the discussion, kicking it off with a succinct explanation of the goals.
It’s a great idea. Virtualization allowed me to work around a lot of rules as $last_job, and has the potential for easy deployment and at $new_job. Given the ease of use of a variety of virtualization options out there in the world, the idea of deploying your Rails / Django / Whatever app to a pre-built container is a really good one. It’s not a trivial exercise to get a nice LAMP stack approved by a stodgy sysadmin infrastructure. It’s way easier to say, “let me drop this vmware instance into your great big awesome vmware machine.”
Good idea Railsconf attendees. Attention everyone else: begin stealing this idea immediately.
_why opened up the Hackety Blog, apparently shutting down his redhanded blog. So far, he’s taken a look at a handful of potential programming as education tools. I’m glad that talented programmers are evaluating education tools. We have a little boy due this August, so programming as education is on my mind.
In other news, Ian came up with a good first olpc-chicago project.
I’ve been pleasantly watching the releases of Apollo and Silverlight over the past few days, and just sort of thinking, “oh, nice, new things to play around with.” Then comes Mark Pilgrim with a dose of cranky, yet wildly accurate ranting.
Sounds good to me, I guess. Yet, at the same time, everytime M$ & Company say the words Ruby or Python, it gets that much easier to say the same words in front of a somewhat backwards potential tech customer and not get booted out the door. So, the tally so far: big companies reinventing the web –, big companies putting good words in press releases ++.
As an aside, please never trim your fingernails at your desk during work hours within earshot of me. It’s really goddamn gross.
So, Vista is languishing (no links provided, seriously you’ve heard this as well as I have). At the same time, Microsoft just released some really cool sounding stuff for dynamic language enthusiasts in the form of some sort of mysterious “Dynamic Language Runtime.” Jon Udell interviewed John Lam about it, as well as how it will integrate with Silverlight.
So, on the one hand, you’ve got the Microsoft that’s sort of doing big dumb things, and on the other hand, you’ve got some really bright types putting out neat stuff that has a lot of potential. Recent neat stuff by Microsoft list: Xbox 360, XNA game dev framework, Robot dev tools, Iron Python, RubyCLR, Silverlight. Nice work good part of Microsoft.
Hey Lazyweb, is there some clever pattern that addresses passing an ‘order by’ to a database and getting an alphabetically sorted list where “the” doesn’t factor into the sort?
Look at this gigantic list of bands. It’s annoying to have to remember that “The” screws everything up.
Do I create a field “name_without_the” and
select * from bands order by name_without_the? I’m assuming this is a common alpha-issue that’s been solved millions of times, but I can’t find a best-practice suggestion via two minutes of Googling.
Please suggest clever ways to do this without sorting in-memory or some junk like that. Let’s keep it in the database folks.