Aptana takes over RadRails development March 11th, 2007
For those of you who've been alarmed by the apparent stalling of the RadRails project, there is hope. I don't usually post news items, but I haven't seen any English coverage of this at RubyCorner, and I know some of you have been worrying that your favourite Ruby and/or Rails IDE is abandonware.
Fear not! Aptana is taking over development of RadRails, after Kyle Shank recently announced that he and his business partner just don't have time for it right now.
For details, see Kyle Shank's announcement, which includes links to a CRN article on how the deal came together and a discussion forum at Aptana's site.
Saving Uploaded Images to the Database August 12th, 2006
Judging from the questions people ask on the #rubyonrails channel, it seems that it's still a common practice to store uploaded images in the database.
At first glance, it seems sensible. You're storing all the metadata about the image in the database; its filename, its accessibility, its dimensions, when was it uploaded. Why not put everything about the image (including the bits of the file itself) in one place?
The approach even makes sense when you start to think about backups. By storing the images in the database, you can rest assured that your database backups will include the images, and that the images and metadata will be consistent in those backups.
It's an idea that I've found attractive myself. But I discussed this with Rob, and he came up with some really solid arguments against it:
- The images consume storage space in the database. Some databases, such as Oracle, require preallocation of physical storage into table spaces, so you want to reduce unnecessary disk consumption.
- Connection hogging on the database. One of the most hotly contested resources in an RDBMS is availability of network connections. When your application has to retrieve images from the database, you tie up precious database connections for longer.
- The database has little or no value to add to images. With non-binary columns, your data pays for its space in the database with its usefulness in queries, joins and transforms. Binary columns don't pay for themselves in this way. If the image is going to be manipulated after the initial store, the manipulation will happen outside the database.
- The operating system's filesystem is highly optimised for caching and delivery of files. In addition, your application server (Rails) or application server proxy (Apache) may also offer caching benefits.
Once you've considered this, the only benefits of storing images in the database are that they're centrally accessible, covered by your database backups, and easy to code for. But these benefits are weak in the face of the arguments above.
As far as central accessibility is concerned, all modern operating systems support some kind of network filesystem. The central accessibility goal is reached simply by exporting the image store as a network filesystem like CIFS or NFS.
When it comes to backups, production servers should almost certainly have a backup regimen that includes more than just the database. Since you should already have at least some paths in your filesystem backed up regularly, it's almost no additional effort to include images in the filesystem backup regimen.
The last remaining benefit is ease of coding. And yes, I imagine that in some application frameworks, it requires more work to store images outside the database. However, put this aside for a moment, and look at everything else we've looked at so far. If an RDMS is a bad fit for image storage, why isn't your application framework making it easy for you to store your images outside the database?
For Ruby on Rails developers, there are at least two rock-solid APIs for attaching images (and other binary files) to your models in a way that's so transparent, you couldn't tell from the code that the images are not stored in the database. For Singles Everywhere (a free online singles / dating site I recently completed for a customer), I used the file_column plugin, which was a pleasure to work with. There's also techno weenie's Acts as attachment plugin.
I suppose there may be cases where it makes more sense to put the images in the database. But I recommend that your default preference be for external storage, and that you insist on strong motivation that outweighs the concerns outlined above.
The Baby in the Java Bath August 11th, 2006
A few years ago, a really bright developer persuaded me to take Java seriously. I did, and I fell in love.
Looking back, though, I see that I didn't fall in love with Java. I fell in love with object orientation, with design patterns, with agile development and with test-driven development.
As a procedural C and Perl programmer, I hadn't been exposed to these things. I hadn't recognized that I needed them. I certainly knew something was wrong. I just could never get to the end of a software project and feel I'd done a solid job, and that extending the software would be a pleasure.
In the Java world, these things are mandatory. You simply can't survive without them. So you can't work with enterprise Java very long before being exposed to them. And for that, I'm truly grateful, both to Rob, who encouraged me to explore Java, and to the Java community.
Nevertheless, the enterprise Java environment left me unfulfilled, and I now realize that we were never lovers, Java and I. I don't like its rigidity, and am horrified by the complexity of the platform environment mandated by that rigidity.
Last year, I got into Rails with a vengeance. My time in enterprise Java land stood me in great stead. I understood the MVC framework, felt comfortable with most of the patterns codified into Rails, and appreciated why Rails wanted certain things done certain ways.
As a software developer, it feels like I've found my one true love. Ruby is a phenomenally expressive language. Its writability is one thing, but its readability is outstanding. It's beautifully expressive, and manages to provide powerful flexibility without the need to pay for that power when doing simple things.
For me, here's the proof that I've found home. I was a licensed user of IntelliJ IDEA, and was convinced that I would never be able to live without an IDE again, because of its powerful support for refactoring and code analysis. This, after being a die-hard "Vi should be enough" C and Perl hacker.
The dynamism of Ruby is such that I believe the same level of IDE support isn't and simply never will be available for Ruby. But here's the kicker. It doesn't matter. I don't miss my IDE, because Ruby and Rails is so clean, so consistent, so elegant that I just don't need IDE assistance to be productive.
Having successfully deployed Singles Everywhere to an highly available, scalable cluster, I don't buy the FUD that Rails doesn't scale. It does, and a damn-site more elegantly than JBOSS, Tomcat and friends. The thing with Rails is, you don't pay for scalability until it's time to scale.
Singles Everywhere has some surprisingly complex background processing to deal with. When I set up the cron jobs to handle it, the last lingering glow of my infatuation with J2EE flickered out for good as I realized how ridiculous J2EE has become.
You develop a we application. You have some processes that need to run outside request scope. So you set up an application container, add Quartz, set up all sorts of contexts and... Hold on a minute. This is running on a Unix server! How did we get so far abstracted from the usefulness of the operating system that we lost access to the system scheduler? And why isn't it a simple job to fire up a process that runs in the context of the application from that scheduler?
At that point, Java finally went cold for me. I'm done. Thanks for the beautiful babies, but from now on, we'll bath where we don't have to assemble and excite the H2O molecules ourselves.