Seeding attachment_fu image data using rake

I've only recently discovered the practice of using rake tasks to seed junk data in my database to help, but thanks to the Populator and faker gems, it couldn't be simpler. It's lot less frustrating than messing with fixtures or migrations.

Working on a site where users upload a lot of images, getting a bunch of random image data loaded in is key. Sadly, Populator isn't well suited to fill in all the fields required by attachment_fu, and it would get really complicated when dealing with thumbnails. However, I found a good solution by going straight through the model itself.

Here's a snippet of code I recently wrote using Populator for user data, but generated each user's avatar by going through the attachment_fu model:

task :populate => :environment do
  require 'populator'
  require 'faker'
  require 'action_controller/test_process'

  [User, Prompt, Avatar].each(&:delete_all)

  User.populate 20 do |user|
    user.login            =   Faker::Name.first_name
    user.email            =   Faker::Internet.email
    #password is 'test'
    user.crypted_password =   "00742970dc9e6319f8019fd54864d3ea740f04b1"
    user.salt             =   "7e3041ebc2fc05a40c60028e2c4901a81035d3cd"
    user.activation_code  =   "8f24789ae988411ccf33ab0c30fe9106fab32e9a"
    user.activated_at     =   [nil, (2.months.ago)]
    user.created_at       =   2.months.ago..Time.now
    user.enabled          =   1
    user.about            =   Populator.sentences(2..5)

    #create user's avatar
    path_prefix = RAILS_ROOT + "/public/avatars/seed_images/"
    seed_images = Dir.entries(path_prefix)
    seed_images.delete_if { |x| x == "." || x == ".."}

    TEST_FILE = path_prefix + seed_images[rand(seed_images.length)]
    avatar = Avatar.create
    avatar.uploaded_data =
        ActionController::TestUploadedFile.new(TEST_FILE,'image/jpg')

    avatar.send :process_attachment
    avatar.user_id = user.id
    avatar.save
  end
end

Essentially, I'm randomly picking a file from my seed_images folder to be passed through attachmentfu. The trick to getting attachmentfu to work it's magic outside of the browser is to simulate a file upload using the ActionController::TestUploadedFile method, assign that to the uploaded_data attribute on the model and call the process attachment method.

This same method will work for testing the mode as well. Although, in your rake task, don't forget to require 'action_controller/test_process' or it won't work.

Happy image seeding.

Front-End Matters

Attention all web designers and developers. Have you read this? If you have, have you understood any of it? Do your eyes glaze over when someone starts talking about containing blocks, normal flow, floating, and positioned elements? I'm here today to tell you that you might want to take a harder look at that document, because it's the goddamned manual for making a web site look and behave like a web site.

And I'm telling you this because every day I'm more and more convinced that developers (in general) do not care for the front-end. When I say the front-end, I do mean the visual part of the web page, but not the design itself. Rather, the implementation of the design. I recently made it into the Stack Overflow beta test, and was eager to impart my CSS knowledge to frustrated developers. A lot of the questions asked were about the usual basics—problems with floats, centering things, box model basics, multi-column layouts, etc. Other questions were either rants about how frustrating CSS was, or requests about how to do things that are clearly outside of the capabilities of CSS. Reading these things, and thinking about every conversation I've ever had with frustrated developers about the technology, leaves me to believe that for your average web programmer person, the thought of having to make a site look how they want it (or how their designer has deemed it to be so) leaves them cold, bitter and scared inside.

And every developer reacts differently at the thought of having to execute a design. Some lash at designers for being such picky, anal-retentive bastards about every last pixel. Others huddle under the desk, and wait for some CSS Guru to appear, and make sense of this weird voodoo language. And some lash out at the technology itself, foaming at the mouth at the inadequacies of the CSS language, or the poor implementation in browsers. After all, how could laying out stylesheet possibly even approach the difficulty of programming things? Y'know, bytes and shit.

If you fit one of the above descriptions, then there's a good chance that you, as a developer, do not card for the front-end.

The <table> Problem

The point of this post is not to lecture programmers for being bad at layout. It's easy to see why it happened—over the past half decade or so, the web has become infinitely more complex on both the back and front ends. Google, web 2.0, AJAX, web apps, and multitudes of new frameworks and technologies have consumed all the attention and time of developers. Programmers have an incredible amount of things on their plate, and so layout is the first to get the axe — after all, that's what those designers are for.

Meanwhile, in the world of design, a similar revolution was happening. Table based designed was in its death throes, and a new technology was being crowned king. I'm sure a few developers poked their heads out from underneath their XMLRPC or SOAP business layer to see what all the commotion was. I can imagine their reaction:

"Table-less HTML you say? Divisions, you say? Semantics? Interesting. Let me know when it works with our legacy system. Now if you'll excuse me, I have to go 'normalize' something."

And with that, they disappeared back into their universe, and proceeded to extol the virtues of Web Forms, and how it made the browser pretend it was like the desktop. After all, what was wrong with tables? Developers spend all day with tables. They understand rows and columns. It was like designing with Excel. And table code itself is just messy enough that it felt right at home with the legacy intranet application they were maintaining.

Fast forward to today, and there's a lot of developers suddenly wondering, incredulously, why they're being forced to write their own user controls in HTML. Who are these design gurus, and what the hell did they do to System.Web.UI.Control? Isn't the whole point of an app framework to abstract design implementation? What? Box Model? You're crazy.

Fucking designers...

The Photoshop Problem

I don't want to get too down on developers, especially since they already have so much to worry about. Let talks about designers for a moment. More importantly, let's talk about designers and their relationship with Photoshop. Designers love Photoshop. If Photoshop had arms and legs, designers would take it out for a night on the town, get it drunk on cheap wine, and do things to it in the alley behind the 7-11. As you can imagine, this torrid love affair leads to a bit of baggage that anyone dealing with a designer needs to keep in mind.

If the problem with developers is that they think in terms of frameworks and APIs and controls, the problem with designers is that they think in layers. Everything is a fucking layer with designers. Or in the case of a typical design comp, it's about 165 layers. I have, on multiple occasions, had to explain to designer how laying out a site in CSS is not like dragging layers around in HTML (thank you very much, Dreamweaver). Designers also have this ultra-keen sixth sense about their designs that allows them to detect, at cursory glance and from 2 miles away, exactly all visual differences between the real site and their design, which was so beautiful when it was handed to you as a PSD. Instead of just telling them in fine detail exactly what they can do with their PSD, you try to calmly explain the limitations of CSS, cross browser implementation, the lack of proper alpha layer transparency in IE6, or, and god help you, the differences between font anti-aliasing and sub-pixel rendering across platforms. Now their eyes have glazed over, as their brains are vainly trying to figure out what any of this has to do with layers - or possibly gradients. Shiny things.

Fucking developers...

Meeting in the Middle

Which brings me back to this document. It is a beast; a nightmare of vague language and compounding rules. It reads like a cross between API documentation and the Vista EULA. It's a snooze, and nobody want's to bother with it (and I don't blame them). Yet these days, every time I do read it, two things happen:

1. I realize how fucking insane it must be to write a browser rendering engine, and begin to understand exactly why no two engines can agree on things completely.
2. I experience a moment where I gain sudden and instant understanding of what it is I spend so much of my time doing. I understand that there is an order and a sanity, and feel like such a fool for spending so much time on trial and error experiments when all the wisdom I needed was right here.

Sometimes this feeling passes, and is replaced by the standard confusion this document elicits. But sometimes I am able to hold on to what I glean, and feel not unlike some magician who's learned a new spell from an ancient tome.

I'm being dramatic, but my point is this: is it really okay to be either a web designer or developer and not have a deep meaningful understanding of how web pages are actually put together at the browser level? Is it okay to consider any part of your craft to be magic, or beyond your understanding?

For those with a computer science degree, the parallel example I run to in my mind is an image of a graphics programmer sitting in a job interview and saying, "I don't know about this OpenGL stuff. I make do with VGA."

For those trained in studio arts, I offer this: "I'm pretty good at tracing!"

Stop emailing your co-workers

Email is the single most frustrating way to communicate between co-workers. It is a giant dump pile of information that nobody reads. Have you ever written an email describing something in what you believe is the clearest way possible, only to receive a response thirty seconds later from the recipient stating he/she has no idea what you're talking about? Or just have it ignored, so you end up having to repeat yourself to them later in a meeting or over the phone?

It happens to me every single day.

Email is that nagging little demon that bounces up and down in the corner of our screen, immediately drawing our attention away from whatever important task we're already focused on. It must be read, replied to, and forwarded as quickly as possible lest we appear negligent in our jobs. Like some sort of sordid assembly line, we are forced to deal with every piece of mail that comes down the conveyor as quickly as possible -- which is why nobody ever seems to actually process the message. We respond quickly, often relying on our initial impression of the message, or even an emotional response which often boils down to: 'Why are you bothering me about this now when I have so much to do?!'

And by so much to do, I mean, I have so much to do because I spend all day writing emails!

Email, as it is used in the workplace is, at best an poor excuse for an IM client, or a basic message board -- a way to track threaded conversations. Beyond that it falls apart. In fact, a whole culture of products has grown up around email software just to make up for its shortcomings. And when using email to collaborate, it becomes a useless linear list of action items that lacks any sort of scoping, categorizing or tracking.

Of course, the shortcomings of email as a communication format is hardly news. You might be nodding sagely at this point and thinking you agree one hundred percent, but I'm willing to bet that as a web designer, you still rely on email for almost all collaboration with clients or co-workers. As web designers we should know better. Web 2.0 has brought us all sorts of new applications and collaboration tools to help us escape the hell of email communication.

So ask yourself, do you use email to do the following?

• Explain and/or document complicated technical concepts
• Manage project specifications
• Communicate schedules and deadlines
• Organize meetings
• Exchange files
• Keep track of public conversations
• Organize priorities or to-do lists

If you answered yes to more than one of those, stop what you're doing, and go investigate the world of project management software. If you can't find something to fit your needs, you might just want to think of a way to get all of the important information about a given project out of your inbox and into a space where everyone can access and modify it as they see fit. We call these wikis, and they're another product of this wonderful thing called the Web (which is not, by definition, email).

AJAX file uploads with jQuery and Rails

I've put together a little widget for uploading images to rails projects. It uses attachment_fu to handle the files, and jQuery to add all the interface goodness (and it will degrade correctly if javascript is turned off).

Quick warning: The widget still needs some work. Browser compatibility hasn't been fully tested (I know it doesn't work in IE6) and there is no validation messages, so it will only work with images under a megabyte.

Tutorial and source code for this widget coming soon.

Why jQuery?

While this shouldn't come as a surprise to any who has used it, I much prefer jQuery to Rails' built-in Prototype library, but getting Rails to play nice with jQuery can be an exercise in frustration. While there are plugins that allow jQuery to be used as a drop-in replacement, such as solution totally overlooks the point of choosing jQuery in the first place: writing javascript unobstrusively.

Rails very much fails at unobstrusive javascript, and it gets in the way of even trivial tasks. For example, the following code will not work without javascript:

<%= link_to "foo", bar_path(@bar), :method => "delete" %>

Because destroying a resource needs to be a POST operation, Rails uses javascript to build a form around the link, that submits when the link is clicked. There are ways to address this in Rails itself, but as far achieving this functionality unobtrusively, we have to abstract it out into a jQuery function:

 function destroy(element) {
    var f = document.createElement('form');
    f = $(f);
    f.attr("method", "POST");
    f.attr("action", element.attr('href'));
    element.parent().append(f);
    var m = document.createElement('input');
    m = $(m);
    m.attr("type", "hidden");
    m.attr("name", "_method");
    m.attr("value", "delete");
   f.append(m);
   var s = document.createElement('input');
   s = $(s);
   s.attr("type", "hidden");
   s.attr('name', 'authenticity_token');
   s.attr('value', AUTH_TOKEN);
   f.append(s);
   f.submit();
}

I really don't like having to hack around Rails, it totally defies the whole point of the convention-over-configuration mantra. But in this case, I totally side with jQuery. However, I can't help but feel that after spending a weekend messing around with this, using a framework that relies less on pre-fab might not be a bad idea.

RESTful routes in form_for defaulting to index (it’s Mongrel’s fault)

I hope this helps anyone out there googling for this problem. I've encountered it twice now. I was experiencing a lot of frustration with the standard issue Rails form_for code on an attachment_fu model. Code as follows:

%fieldset
  -form_for(:picture, :url => pictures_path, :html => {:multipart => true}) do |f|
    .field
      %label Upload Picture
      .picture-field
        =f.file_field :uploaded_data
        .field.button
          =submit_tag "Upload"

Apologies to all non-HAML people out there. Anyway, when I submit the form, it seems that Mongrel wasn't POSTing the request properly, and kept trying to perform a GET, which took me to the index action on the controller. After a few hours of pulling my hair out, I remembered this same thing happened to me last time I wrote a form for an attachment_fu model. After restarting Mongrel, everything seems hunky-dory.

Hope someone will find this knowledge useful.

Radiohead, Processing, and Tinkering

I've been in love with Processing since I first saw the work being done by Robert Hodgin over at Flight404. Now, Radiohead has jumped on the bandwagon, with their newest video for "House of Cards.". I've become increasingly fascinated by the whole field of data visualization, having to do with my evolving love affair of areas where art and technology intersect. Being able to present large and complex data structures in a wholly visual representation requires not only an understanding of the (often scientific) subject you're trying to represent, but skills in the visual arts as well. Often, it feels like a crossroads where the two hemispheres of the brain intersect, and for those of us who've never felt that we're totally within one hemisphere or the other, it's wonderful to see this sort of work being done (without necessarily wondering what the point of it all is). This same sort of obsession has always been present in Radiohead's work, either from the computerized voices in "Fitter, Happier", the low-poly meshes in the "Go To Sleep" video, or in this new video. They love to tinker with the raw technology, exploring it's power at the cultural level.

The video, much like their recent stem release of "Nude", calls on fans to remix and repurpose their work by providing both Processing source code and the raw CSV for download. In seems that since the release of In Rainbows, the band has been on a total interweb kick. They seem to be embracing the idea of cultural participation in their work. And rather than just trying to cash in on the pay-what-you-want buzz that surrounded the release of In Rainbows, they seem to earnestly trying to immerse themselves in the smaller creative pockets of the web, such those that surrounding Processing. I honestly can't imagine there's much mainstream interest in a few hundred megabytes of CSV files.

I hope we see more open media like Radiohead's releases. And I hope we get to keep tinkering with it in this strange intersection between technology and art. I like to tinker, it's fun. Now, if only I could take the time to learn Processing...

Is Dreamweaver useful anymore?

Dreamweaver is just one of those web design tools that's always been there. Most designers have used it, and I still get the impression many of them rely on it quite a lot. It's just one of the stops along the Abobe path of web design. First Photoshop, then Dreamweaver (or Flash!), then the Web. Being the code snob that I am, I honestly have not touched the program for quite a few years, and while I've always listed it as a skill on my resume, I realize that I don't really know the program that well. After spending the last couple of days poking around in it again, I really don't want to.

I remember I originally came to Dreamweaver in high school, when my friends and I would spend our time making up funny web pages and posting them to our FortuneCity accounts. It was fun, it was stupid, and I made everything using FrontPage 98. I had heard about this other program, Dreamweaver, and it supposedly blew FrontPage away (difficult, I know). I downloaded the demo, and fell in love, because Dreamweaver had great table layout features.

Guess what? Dreamweaver CS3 still has great table layout features. But I've moved on, and so has the rest of the web. In fact, I seriously question the need for a WYSIWYG design tool like Dreamweaver at all any more. It's not that such a tool isn't useful. It's that web design in general has become far too complex a topic to be able to make designing a web page feel like typing a Word document. The basic concept behind Dreamweaver is broken.

The Nice Stuff

But first, let's focus on Dreamweaver's strengths. It has a great text editor. No, really, I like the text editor. But TextMate is a better text editor, as is Coda. Stand alone text editors also have much smaller footprint. Dreamweaver is extremely slow and bulky if you're just editing source files. So really, the text editor isn't a compelling reason to use Dreamweaver.

Neither is the Browser Compatibility checker. Even if it is pretty cool.

I also recently discovered the built in source control. It's pretty basic, and is nothing compared to a real version control system, but it works well enough to keep you from overwriting co-worker's changes. I also appreciate how it gives you the option to split your workflow up between dev, test, and production. So the site-management features get a general thumbs up. But it's just not enough to justify the whole package, especially considering the Large, Glaring Problems.

The Large, Glaring Problems

The entire Design View is the biggest problem. Just forget about it. Completely. Pretend it doesn't exist, because you'll get absolutely nowhere using it. Why? Because it doesn't resemble a web browser. Or, at the very least, a web browser that anyone uses on the internet. It's a proprietary engine. It's not Gecko, it's not WebKit, nor Trident, nor Opera, nor iCab. It's a non-entity. If you use it, your page might look fine in Dreamweaver, but total crap in any other browser. Or vice versa. It is a completely unreliable representation of your page, and simply is not suitable for web design in the year 2008.

The second biggest problem is actually writing CSS layouts. Anyone who used MX 2004 or Dreamweaver 8 knows that it sucked at implementing CSS styles. CS3 is a lot better, and even includes handy templates for various types of multi-column, flexible/liquid layouts. But despite some good intentions on Adobe's part, actually writing and applying CSS using Dreamweaver's GUI it far more painful than just typing a CSS document. Creating stylesheets, writing selectors and attaching classes consists of clicking through a vast array of dialog boxes, drop downs, and menus. Granted, CS3 does let you view selectors in a tree format via the panel interface. You can click a selector, and then edit a grid of its properties.

Zero Abstraction

All of this is so much more effort than just typing out a CSS file, especially considering that the GUI still requires that you have a deep understanding of how CSS works. There is really no attempt to abstract the murky details of CSS design in that way you would expect WYSIWYG program to do so. There are half-assed attempts at it, such as the drop down box in the inspector panel that displays a list of all your class styles with the text formatting applied (similar to how a font-select box would operate). But it seems to treat all your classes as if they were text styles, not bothering to take into account any of the box styles associated with our classes, which makes the entire idea of visually selecting a class to be applied completely useless.

And forget about actually manipulating the Box Model in design view, similar to how tables are manipulated. You're pretty much limited to selecting the outline of the box, or the text inside of it. There are no handles to resize, no options to manipulate padding, margin, etc. via the mouse. You're stuck with hand-editing those value via the panel interface, or the god-awful style dialog. You could, of course, do what everyone does the first time they attempt a CSS layout in Dreamweaver: turn absolute positioning on for everything, and drag crap around on the page until everything is pixel perfect. If it looks right, why not? Because over the years, I've come to realize that this feature tends to lead people to the conclusion that layout in CSS is akin to layout in Photoshop, where everything is just "layers" that can be dragged, dropped, and stacked wherever they please. And when they tell me about this, I smile, and nod, and in the politest tone possible, proceed to explain to them how totally wrong that concept is.

The harsh truth here is, to get good at making web page, you have to just dig your heels in and learn what's going on under the Dreamweaver hood. I have yet to meet one person who uses Dreamweaver that hasn't had to spend a significant amount of time in Code View. And once your actually learn how all the HTML and CSS fits together, a tool like Dreamweaver doesn't offer a whole lot that can't be achieved by a lesser IDE like Coda, or a collection of free, easy to use, significantly more powerful Firefox extensions and a good text-editor by your side. You'll save money, and become a code snob like me.

Welcome to Things With Pixels

For the first time in it's life, Things With Pixels is now an active and fully developed website. It's been redesigned, and will probably continue to see design improvements into the future. I also plan on writing entries weekly, instead of semi-annually. Isn't that exciting?

For those who are curious, TWP has moved from Mephisto to Expression Engine Core, which has proven to be (fairly) enjoyable process. I really did like Mephisto, but lack of documentation and active development were serious dealbreakers. I spent this past weekend madly writing templates, and learning the EE tag and admin system, a process which I'll probably write more about soon.

Livin' on the Edge

I've also switched over from shared hosting at RailsPlayground to a VPS on Slicehost. What a difference! Slicehost isn't for everyone, but thanks to their excellent tutorials and community support, I was able to get my stack up and running pretty quickly. Their DIY approach to web hosting makes my inner sysadmin squeal with delight. It does kind of feel like living on the edge, though, knowing some stupid typo could bring down the whole show.