Last week we explored using Postgres as a central communication nexus between several data sources. At the time, I made a fairly hand-wavy allusion to REST interfaces. Since I hadn’t really explored further, I had assumed PLV8 could use core node.js or other similar libraries to invoke HTTP APIs. Of course as a trusted language, PLV8 isn’t allowed to do that. It’s more of a language for easily manipulating JSON and JSONB objects within Postgres.
Programming is fun. I love programming! Ever since I changed my career from programming to database work, I’ve still occasionally dabbled in my former craft. As such, I believe I can say this with a fair amount of accuracy: programmers don’t understand databases. This isn’t something small, either; there’s a fundamental misunderstanding at play. Unless the coder happens to work primarily with graphics, bulk set-based transformations are not something they’ll generally work with.
I was fighting with packaging some software at work, trying to produce a workable RPM package to replace the manually installed kludge currently polluting one of our servers, and discovered the --spec-only option to the bdist_rpm action.
Now, this particular option only makes sense since a spec file must be generated for bdist_rpm to work anyway, but I never thought about it. What it provides is an awesome shortcut to doing packaging slightly more complicated than merely relying on what bdist_rpm produces.
A while ago, I decided to use Pylons to rebuild my site. I even went so far as to name the engine “BonePyl”, which just narrowly edged out “BonesAW” for “Bones’ Awesome Weblog”. While doing this, I’ve obviously had to orient myself with the API, which meant buying The Definitive Guide to Pylons and copious scouring of the web for secondary documentation on SQL Alchemy and FormEncode. It’s a lot to bite off, and I’m having trouble chewing, but considering my current site is a bunch of PHP I threw together back in 1999, I’m obviously in no hurry.
There’s a lot of debate in application development circles over various sundries such as column naming schemes and framework implementation details. Well, I’d like to clear all that up.
See, there are more application frameworks than grains of sand on the entire planet Earth, and each one of them has a different philosophy and API for creating database objects. Rails, Django, Turbogears, Zope, Zoop, Drupal, Catalyst, Nitro, Nuke… holy fucking Christ, stop it already!
