Stricter validation for Rails attachment_fu plugin

January 31st, 2008

I came across a little snag while using Rick Olson’s excellent attachment_fu plugin to resize images via ImageScience. The problem is that ImageScience version 1.1.3 gets very unhappy when asked to resize a file that isn’t an image. As mentioned here, if you pass ImageScience a simple ASCII text file, it will unceremoniously abort your Ruby process, dumping the cryptic message “terminate called after throwing an instance of ‘int’.”

I stumbled on this behavior in a unit test, but a user could get it by uploading a text file with an image extension (e.g. JPG). Right now attachment_fu does check that an uploaded file is of a certain MIME type, but it uses the MIME type reported by the CGI module to do so. Presumably CGI is only looking at the filename’s extension, so it’s quite easy to dupe.

I didn’t feel like having to switch back to RMagick for image processing (eyes bleeding installation, arcane configuration, memory leaks, etc), so I added a little stricter content type validation to attachment_fu. The patch uses the Unix file command to actually sniff the uploaded file’s starting bits and ensure it’s really one of the allowed content types. Couldn’t think of a good way to do this cross-platform, but if anyone has suggestions let me know.

The patch is here if you want it. To turn on strict validation, add the following to your has_attachment call:

:content_type_validation => true


more from the geek humor dept

January 25th, 2008

From Code Like a Pythonista: Idiomatic Python, an excellent introduction to python idiom:

from module import *

You’ve probably seen this “wild card” form of the import statement. You may even like it. Don’t use it.

To paraphrase a well-known exchange:

(Exterior Dagobah, jungle, swamp, and mist.)

LUKE: Is from module import * better than explicit imports?
YODA: No, not better. Quicker, easier, more seductive.
LUKE: But how will I know why explicit imports are better than the wild-card form?
YODA: Know you will when your code you try to read six months from now.

Oh dear.


new machine profiles at amazon ec2

December 22nd, 2007

We’re targeting amazon’s amazing ec2 service to host our alpha. Computing in the cloud is great for us — no installation/maintenance hassles, elastic expansibility as we need to scale, ability to create peripheral instances (such as staging) on the fly and turn them off when we’re done.

However, I was a bit worried about how the slim machine profile (1.7 G RAM, single processor) would fare for database and solr work. Fortunately, I just discovered that they’ve released new machine profiles with higher RAM, more processor cores, and more, faster storage. Rad. These folks know what’s up, and make it ever easier to run a startup.

Now I just need a solid memcached/web server machine profile (low CPU, high RAM, low storage) that shoots the gap between the small (0.10/hr) and the medium (0.40/hr). Something like 2 cores and 4-8 GB of RAM would be nice. Wonder how long it is before these specs themselves become configurable?


reading your code

November 14th, 2007

Reading code can be more difficult than writing it.   Coding Horror quoting Stan Kelley-Bootle’s book “The Devil’s Dp Dictionary”:

your program (n): a maze of non-sequiturs littered with clever-clever tricks and irrelevant comments. Compare MY PROGRAM.

my program (n): a gem of algorithmic precision, offering the most sublime balance between compact, efficient coding on the one hand, and fully commented legibility for posterity on the other. Compare YOUR PROGRAM.


solr rocks

November 14th, 2007

If you want to add search to your site, I highly recommend solr, a search server that builds on the lucene java information retrieval library. It does many powerful things out of the box–faceted search, highlighting, caching, etc–and the community around it is stellar. Plus it plays nice with ruby and python, giving you eval-ready output formats for both languages.

Over at the Rooftop Collective I’ve been hacking together some fun stuff on top it, adding local search and social search to the mix. After working w/ the code for a while, a couple things I really like about solr:

  • dynamic fields: This is sweet. You specify a wildcard pattern (say ‘*_f ‘), associate a type with it (say, float) and then can define a new field on the fly as you’re indexing a document (say, my_field_f). This is far more flexibility than I’ve ever seen a database provide, particularly at runtime. In practice, it lets you describe and search your data in ways that evolve as the application runs.
  • function queries: functional programming sneaks into Java.  You can create and compose arbitrary functions that run on your data set, mainly for sorting, but also for displaying calculations (like distance from a point).

Messing w/ solr also reminded me that I still don’t like hacking Java. Don’t like the verbosity. Don’t need the type safety–I can think clearly and write unit tests instead, thanks. Also, miss the built-in looping constructs from ruby. Also, miss the built-in fixtures from Rails. Don’t, however, miss the under-documented APIs from Ruby or Rails. Though it’s always fun to skim through random blog posts to figure out just what frob.foo() is really up to, why my computer spits fire when I call it, etc.


*feed* by m.t. anderson

November 11th, 2007

Very powerful, very well-written, very dark.I would have like a more hopeful ending. It took me a day to get over the feeling I closed the book with. While disintegration of humanity is memorable and powerful, it’s also irresponsible to leave it in shambles with no hope.

Feed made me think a lot about facebook. In some ways it’s different than Anderson imagined it–up until now, we’ve mainly been broadcasting to ourselves instead of the companies broadcasting to us. True, the structure of our messages is controlled, steering our thoughts toward easily consumable, re-displayable sound bites, but that’s a general trend in online culture (aside from blogs).

Now though, with last week’s launch of the facebook social ad program, facebook takes an eerie turn toward the structures in anderson’s book. You (supposedly) tell facebook the things you consume, the bands/brands (their merger, clever folks they are) you like, and then facebook crafts advertisements for both you and your friends that are specifically tailored to these preferences.

This is presented as a service. No, really. I mean, I get it–advertisements are a semi-necessary evil to support media services. I may need to use them to support the service I’m building too (sigh). But how creepy of facebook to pretend that we should like them, that we should be happy when they pin us to a demographic more accurately.

And the part about crafting advertisements for you based on what your friends bought? Creepy. I mean, is this the 50s? Are we all keeping up with the Jones, lusting after the goods our neighbors own? Sure, maybe it’ll work, but as the great stoop-side philosopher Arash Pessian once observed, “Does it make the sort of world you want to live in?”