Image placeholder services are useful tools for web app developers. They serve the singular purpose of marking the location of a future image within a design or layout. Spaces that will eventually be filled with production images can be worked around while the artists or photographers prepare the images behind the scenes. From the perspective of rapid application development, an image placeholder service is a standard part of the developer’s toolkit.
Unfortunately, their ubiquity has led to a flooding of the market with too many free services to be counted on two hands. My personal favorites are Placehold.it, which provides simple gray images along with the image’s dimensions in text at the middle of each image, and Placekitten, which shows images of kittens in any size. Kittens are adorable in virtually any context, even for the cold souls in the world who don’t like cats—cold souls like mine.
I set out to build an image placeholder service mostly as an academic exercise. Our work at Ashe Avenue is generally revenue-focused and on a rapid schedule. Any opportunity we have to build tools on the side, either for fun or just because, we jump at. I had always assumed building an image placeholder service would be straightforward, but I wanted to know what the intricacies of it would be, and I had questions about how to make it perform: Should I generate the images on-the-fly or beforehand? Should I cache the results? How many different types of images did I really even need? And most importantly, what images should I use?
I made the obvious choice: pictures of Vanilla Ice and early-90s Mustangs! It was so absurd that I knew it’d get noticed, but in doing so the core purpose (serving simple images) wouldn’t be tampered with or avoided. Developer John McKinney and I had a brainstorming session one day to decide what we should name the service and into my mind popped NiceNiceJPG. I’ll admit that there was doubt in my mind for a moment or two that the domain name wouldn’t be available, but in hindsight I may have been worried for no reason. It’s a ridiculous name but still pretty obvious. Luckily, it was available and we registered it.
NiceNiceJPG takes just a few parameters, depending on the image you want returned: a width and height if you want to be explicit, or just a single number that represents a square’s width and height.
Examples:
http://www.nicenicejpg.com/600/300 : returns a 600x300 image of Vanilla Ice
http://www.nicenicejpg.com/450 : returns a 450x450 image of Vanilla Ice
The app itself is built in Rails 3, and since there’s no UGC or dynamic content, there’s no database. There are nine basic images uses ranging from very small portrait to very large landscape. Images are cut dynamically using RMagick according to the size requested and returned as binary with the "image/jpeg" content type.
The plan from the beginning had been to make the code open source, so we released the code on the same day we launched NiceNiceJPG.com. By open sourcing the code, we’ve not only enabled users to make changes to the code, add new images, or add caching to the mix, but we’ve also strengthened our own ability to build non-revenue tools that serve greater purposes than simply making money. The code is available to be used, forked, and extended on GitHub.
Comments are closed.