I’ve had a letterpress for a couple years now; I absolutely love the thing, but rarely do I get the opportunity to put it to good use. Luckily, I’ve got four siblings, and [thusfar] they’ve all asked me to (or I’ve convinced them to let me) design and print their wedding invitations.
I've been playing with MongoDB a bit lately, and have been pretty impressed both with its simplicity and usefulness. There seem to be quite a few uses for a document-oriented DB, and, as the MongoDB team mentioned on their blog, logging is one of those things that MongoDB is perfectly suited for.
After a very long [unplanned] hiatus, I finally started doing a bit of daily design again (see this post for a bit of background).
It’s been good to get back into it a bit, so I thought I would share some of my latest creations. In case you can’t tell, I’ve been going with a band / music theme. As with the first time around, this forced creativity has been easy at times, and horribly difficult at others. What follows are the past three days in this experiment.
For a while now, I’ve used (and, for the most part, loved) OtherInbox. It’s a really handy service – just create a new email address for each site instead of giving out your main address for those sites to sell and then spam. But I’ve been using it since the beta, and have been increasingly annoyed by certain features that have been removed or withheld from the free account. For example, IMAP access is only available to pay accounts, as is the ability to read any message you received more than 30 days ago.
I’m not faulting OtherInbox for this – I get it, they need to make a profit. Heck, I would probably take the same approach they have. But, I finally decided there was a better solution for me. So goodbye OtherInbox, hello to the exact same functionality (and then some) via Gmail. Let me explain…
After over a year of promising it, I finally sat down last night to enable comments on this "blog" of mine. Turns out, the process was actually pretty easy and painless, and there was really no reason I shouldn't have done it earlier (except for the fact that I doubt anyone will actually care about commenting on this thing).
The Macheist 3 bundle is now available. 12 Mac apps (a combined value of over $550) for only $39! How can you pass that up? Plus, 25% of every sale goes to charity. So go ahead, purchase the bundle, there are some great apps in there.
I’ve had this ugly, default theme for far too long; unfortunately, laziness has gotten the better of me over the past year when it came to redesigning this blog. But, this past weekend, I decided to bite the bullet and do what I’ve been avoiding for a while. So, I’ve redesigned (to be more accurate, I’ve really just “un-designed”) my blog.
I know I'm not the only one that has, for years, longed for variables in CSS. It's been a much discussed and debated topic; in fact, someone has even gone to the trouble to write up a proposed spec. There have been plentyofsolutions, but, as a Rails developer, Rack Middleware seemed like the perfect place to hack together a quick solution for CSS variables.
Ryan Schwartz thinks I should actually use this blog of mine once in a while. Well, that makes one of us ;)
However, consider this a public service announcement for all those people who might have run into the problem I did with Rails and Passenger (modrails) compatibility.
An introduction before we begin: 99% of the time I use mongrel in development, because that’s what I use in production and that’s what has become my habit. However, for a new project I’m working on, we’ve discussed trying Passenger in production. So, more recently, I’ve been using passenger some in development for that project (I still, out of habit spin up script/server when starting work in the project).
As of a few days ago, this new project was running Rails 2.2.2 with Passenger 2.0.6 (when I remembered to got to http://go.local instead of http://localhost:3000). However, always wanting the apps I’m developing to stay up to date with the current version of Rails, I upgraded one to the latest, greatest Rails 2.3.1RC. A few Rails compatibility / deprecation issues, but everything was still working just fine — or so i thought. I didn’t notice anything strange because I was still developing with mongrel; I would still spin up script/server and hit http://localhost:3000. Late last night though, I remembered to use my passenger virtual host, and the following error pops up:
Ruby on Rails framework version 2.3.1 seems to be corrupted?! Please reinstall it?! Wha??
Anyway, it was a little frustrating as I tried a number of things to fix it, but the ultimate solution was simple: upgrade to Passenger 2.1.1, and voilá! Everything’s fixed.
This is something that’s been mulling around in my mind for a while now. Unfortunately, I’ve been too busy and distracted with other things to give it any more than a passing thought. However, this is me [finally] taking action.
With the desire to get to meet anybody around the area that’s doing similar work, I’m taking the initiative to officially begin the Wichita Ruby Users Group. That’s right, Wichita. As in Kansas. As in Wyatt Earp. As in the freaking Wizard of Oz (but with no association with either the musical “Oz!” or the hit HBO prison drama “Oz”).
I realize there are [currently] very few people who read this blog of mine, but if you’re in Kansas (or, heck, northern Oklahoma), get in touch with me. And hey, if you know anyone in the area, direct them my way. I’d really appreciate any help I can get on spreading the word on this thing. So, even if you don’t live anywhere near, twitter about it, call around, ping people, email them and just generally annoy everyone you know about this thing. Help me get the word out! If you can, try to convince your Ruby friends to move to Kansas so they can attend the meet-ups; I guarantee they will be the most entertaining programmer meet-ups around, even if it means I have to kick-off every meeting with a live performance by the philharmonic.
We’ll take anyone working with / dabbling in / thinking about / looking at / lusting after / crying over Ruby! If I get desperate enough, we may even start to accept some Django-ers (blasphemy!), although highly doubtful.
And maybe, just maybe, one day Wichita will be home to a beautiful, thriving Ruby community.
To get in touch with me, you can…
Email me: peburrows[at]gmail[dot]com
Call me: 501.278.6321
Twitter me: @peburrows
So I’ve started something new. In the spirit of feeding that growling hunger in my stomach for creativity, in the spirit of some day bleeding a shade of photoshop blue, I’ve starting forcing myself to do more design work — forcing myself to try and be more creative…on a daily basis.
If you haven’t seen ErrFree’sFacebox jQuery plugin, go check it out. It’s a great little lightbox mod that works with the excellent, lightweight jQuery javascript library. It’s based on the way Facebook often “pops-open” a new modal window on top of the currently loaded page. It’s a handy little way of doing things, and the first time I saw Chris Wanstrath’s Facebox plugin, I thought, “This could be perfect for a few different things I’ve got coming up.”
You guys aren’t gonna know what to do with yourselves if I keep up this trend of writing a blog post more often than once a month. If if makes you feel any better, I’m not sure I’ll manage either.
Anwyay, on to the substance.
So, like I mentioned in my last post, I’m working on a site for a photographer friend. Obviously, the main purpose of the site is to display pictures. That being the case, the obvious choice for a Rails app needing to upload files is Rick Olson’s wonderful attachment_fu plugin. For the site, I’m going to need quite a few different image sizes, and attachment_fu handles that wonderfully (If you’ll notice, we’re also using Amazon’s S3 storage service — there was some hacking done on the plugin for some tweaks to that as well; maybe another blog post coming soon?). Check it out:
So, there are a couple things to note here. First, we’re resizing the original image to fit within 800px x 800px; attachment_fu handles this just fine. Secondly, we’re also creating four different thumbnails.
At this point, those of you familiar with the attachment_fu plugin are thinking, “So what, I do this on every project.” Yes, yes you do. But here’s what you probably don’t do: compress your images on resize. And, if you do compress your images, your thumbnails probably aren’t very pretty — they probably have visible artifacts from the multiple-JPEG-compression.
“Multiple-JPEG-compression?” I hear you ask. Yes, multiple-JPEG-compression. Maybe it’s a phrase I’ve just made up, but “multiple-JPEG-compression” is not a good thing. JPEG is a lossy format, so every time you save a JPEG image with any kind of compression, you lose a bit of the quality. Eventually, you’ll start to notice. The issue with compressing images in attachment_fu is that 1) it doesn’t do it unless you change some code, and 2) if you changed your code, you’re probably compressing the original image and then creating compressed thumbnails from that compressed, resized original. And that, my friends, is what I would call multiple-JPEG-compression.
But first, let’s back up for a bit…
The reason I even started exploring this was only because of necessity. Originally I hadn’t even thought of compressing the images; I guess assumed anything that needed to be done on the resize would be taken care of by the attachment_fu plugin. And, for the most part it is. By default, it drops any color-profile that could be included with the image (this behavior can, of course, be over-written; just specify :keep_profile => true in the has_attachment options). This is a really good thing for a couple reasons: 1) color-profiles can really increase an image’s filesize 2) color-profiles aren’t really even taken into account by most browsers. But one thing the attachment_fu plugin doesn’t do by default is compress images. So, after checking out the RMagick documentation, I figured the solution would be an easy one; all I had to do was specify a quality in the Image#to_blob call, like so:
# in attachment_fu/lib/technoweenie/attachment_fu/processors/rmagick_processor.rb
def resize_image(img, size)
# # ...code not relevant to us right now...
# set
self.temp_path = write_to_temp_file(img.to_blob {self.quality = 75})
end
And that did exactly what it should: it compressed all my images on resize. But the issue I was having was the multiple-JPEG-compression; my thumbnails were turning out ugly, which is not acceptable for a photographer’s website. Here’s how they were turning out:
As you can see, this wasn’t gonna work. So, what could I do to fix it. Well, first I had to hunt down the root of the problem. After some digging, the issue was what I’ve mentioned before, the original was getting resized and compressed, and then the thumbnails were being resized and compressed from that initial resize and compress. Multiple-JPEG-compression. So, my first thought was “Oh, well I’ll just pass in the original, full-resolution image to the resize method so each thumbnail can be created from a fresh copy and will only be compressed once.”
Bad Idea. Ever heard anything about RMagick being a memory hog? Well, it’s never a good idea to feed RMagick’s addiction to hogged resources. And, having RMagick resize an image five time that could possibly be up to 5 megabytes in size is not a good idea. Duh, Phil.
So, what was the solution to the problem. After thinking about it for a bit, I arrived on the solution I moved forward with, and it appears to be working quite well. Here’s a run-through of the plan I formulated in my mind:
1) resize the original image, but without compression
2) send that resized, uncompressed image to the resize method for thumbnail creation
2b) make sure that the thumbnails are compressed (but maybe not as much as the original)
3) after all the thumbnails are created and compressed, compress the original image and save it as well
So, the next step was to figure out a way to implement my plan. Long story short, here are the re-written methods in the plugin (i’m not a fan of monkey-patching):
# in attachment_fu/lib/technoweenie/attachment_fu.rb
def after_process_attachment
if @saved_attachment
if respond_to?(:process_attachment_with_processing) &&
thumbnailable? &&
!attachment_options[:thumbnails].blank? &&
parent_id.nil?
temp_file = temp_path || create_temp_file
attachment_options[:thumbnails].each{|suffix, size|
create_or_update_thumbnail(temp_file, suffix, *size)
}
end
#############################
# now compress the original #
#############################
with_image do |temp_file|
resize_image_or_thumbnail!(temp_file, true)
end
save_to_storage
@temp_paths.clear
@saved_attachment = nil
callback :after_attachment_saved
end
end
#
#...
#
def resize_image_or_thumbnail!(img, compress=false)
if (!respond_to?(:parent_id) || parent_id.nil?) &&
attachment_options[:resize_to] # parent image
resize_image(img, attachment_options[:resize_to], compress)
elsif thumbnail_resize_options # thumbnail
# we want to always compress the thumbnails
resize_image(img, thumbnail_resize_options, true)
end
end
# in attachment_fu/lib/technoweenie/attachment_fu/processors/rmagick_processor.rb
# Performs the actual resizing operation for a thumbnail
def resize_image(img, size, compress=false)
size = size.first if size.is_a?(Array) && size.length == 1 && !size.first.is_a?(Fixnum)
if size.is_a?(Fixnum) || (size.is_a?(Array) && size.first.is_a?(Fixnum))
size = [size, size] if size.is_a?(Fixnum)
img.thumbnail!(*size)
else
img.change_geometry(size.to_s) {|cols, rows, image|
image.resize!(cols<1 ? 1 : cols, rows<1 ? 1 : rows)
}
end
if compress && !self.thumbnail
self.temp_path = write_to_temp_file(img.to_blob {self.quality = 75})
elsif self.thumbnail
self.temp_path = write_to_temp_file(img.to_blob {self.quality = 90})
else
self.temp_path = write_to_temp_file(img.to_blob)
end
end
This uses a compression level of 75 for the original full-size image and 90 for the thumbnails, compressing each image only a single time. And, after those changes, here’s the kind of thumbnails we get:
And now for a comparison:
Can you tell which is which? I sure can, and the difference in quality is well worth the time it took to figure out how to get things right.
So this evening (can we still call it evening at 4:30am?) I encountered a frustrating issue. I’m working on a rails site for a photographer friend, and it’s been coming along rather smoothly. However, tonight I ran into an annoyingly frustrating issue that turns out to have been caused some routes namespace gotchas.
My band ( the philharmonic ) has a new demo up on the site. Go check it out. Comment and tell me how much you hate it and how much you wish I would actually write something of substance in this blog...
.phil.
So Damon Clinkscales (a guy I work with) has put together this nifty little app called SnapTweet that integrates with Twitter and Flickr. Check it out, it’s pretty neat-o.
So posting to this thing has proven to be less frequent than I had hoped, but I’m here to say that [hopefully] it should become more of a routine. I’m going to make myself do it.
So there are a few things I’ve been meaning to document. Like I said in my first post, I did a custom Radiant CMS for vitalsource.com, although I didn’t do the design on that site, I just ported over the content to the new CMS. Anyway, I put together a few custom extensions for the site. They may be useful for one of your project, and if so, feel free to use them as you wish. I’d love to know if you find them useful and how you’ve implemented them on your site. Keep reading for an overview of the two handy extensions: Translator and RegexpURLs.
I've been doing quite a bit of work in Radiant lately at my job as I've moved the VitalSource homepage to the Radiant CMS. Coming from Sitellite, Radiant has been a breath of fresh air. Very clean, very extensible, very intuitively designed. The guys at Wiseheart Design deserve a beer (Foamee anyone?).
Since I got a chance to kick the tires of the Radiant car, I figured I would put the newfound knowledge and experience to some use and finally get this blog off the ground.
So, consider this the beginning of something big. I've got quite a few things I'd like to write about over the coming weeks (namely, some Radiant extensions that I wrote that I feel could be really useful to others).