At Federated Media, any individual can buy ads on any of our 80+ sites. When they submit their creative, it’s very likely it’ll be animated. There’s probably no doubt that animated ads are more effective at attracting attention than their static counterparts, but that’s also what makes them so annoying.
To strike a balance—respecting our authors and their audiences above all else—we require that any animation lasts no longer than 15 seconds.
The only problem is, we had no way to enforce this. So Andre, who first built FM’s platform, would watch every banner ad for at least 15 seconds to make sure it stopped animating. A nefarious ad designer could have successfully gotten past the Andre-check by animating the banner for 12 seconds, pausing it for 20 seconds, and then repeating continuously. What usually happens though is that someone submits a banner with animation that lasts for about 2-3 seconds, pauses for 3, and then repeats continuously.
Whenever an ad like this was submitted, we’d have to email the person who submitted it, ask if they could resubmit an ad with animation that stops after 15 seconds, etc etc etc. It was a really manual process.
So earlier this week I set out to see if there was an easy way to probe a GIF file programmatically to determine whether or not it was configured to loop continuously. PHP doesn’t do this natively, and I couldn’t find anything on Google that even came close to analyzing a GIF’s animation metadata—in any language.
So, I decided to write my own.
With a hex editor in one hand and the GIF 89a standard in the other, I set about understanding the image format and the Netscape 2.0 Application Extension (below) that added the option to loop the animation continuously (or for a specific number of iterations):
byte 1 : 33 (hex 0x21) GIF Extension code
byte 2 : 255 (hex 0xFF) Application Extension Label
byte 3 : 11 (hex (0x0B) Length of Application Block
(eleven bytes of data to follow)
bytes 4 to 11 : "NETSCAPE"
bytes 12 to 14 : "2.0"
byte 15 : 3 (hex 0x03) Length of Data Sub-Block
(three bytes of data to follow)
byte 16 : 1 (hex 0x01)
bytes 17 to 18 : 0 to 65535, an unsigned integer in
lo-hi byte format. This indicate the
number of iterations the loop should
be executed.
bytes 19 : 0 (hex 0x00) a Data Sub-block Terminator.
In the end, I didn’t write a complete GIF parser, but opted for a simple regular expression probe of the GIF file. Bonus: figuring out how to convert little-endian unsigned ints from hexadecimal to decimal.
So far I’ve tested the code on some pretty long GIF animations, and it seems accurate. So if you need to find the duration of a GIF animation and/or the number of times it loops, here’s the code to do so in PHP—which should be pretty easily translated into just about any other language.
The WordPress importer for Blogger doesn’t use the already published post “slug”—which is necessary for maintaining the permalinks (aka the URLs) of imported posts. Instead the importer generates brand new permalinks based on the post titles, using rules that diverge notably from those used by Blogger:
Blogger truncates the title much sooner than WordPress (less than 40 characters in length)
Blogger excludes English article words (a, an, the)
Blogger drops characters with accents, instead of converting them to their closest ASCII equivalentUpdate: For the record, Blogger now transforms some accented characters into their ASCII equivalents, but it didn’t used to
So for example, a post title like:
Los viernes, música para tu iPod en iPod Noticias
gets transformed by Blogger into:
los-viernes-msica-para-tu-ipod-en-ipod
whereas WordPress produces:
los-viernes-musica-para-tu-ipod-en-ipod-noticias
How a title gets transformed into a permalink (aka “dirified”) is of little importance here. What is crucially important is that the permalink doesn’t change—an issue when moving from one blogging platform to another. The average blogger probably doesn’t care about this too much—but there are some people (myself included) who wouldn’t want all the existing links to our blog posts out there on the internet to break, especially when it comes to maintaining that precious PageRank™ (and findability).
When I moved from Blogger to WordPress 1.5 in 2005, I managed to maintain the permalinks the hard way (just shy of updating every one by hand). These days, the importer is so good, practically all you have to do is click a link and sit back. I wanted the same to be true for the permalinks.
Update: A number of people have sent me emails or left comments about troubles they’ve had with the Blogger Importer. Oftentimes it only seems to import a fraction of their blog posts and comments. In which case, they revert to Plan B: download an Atom-based export of their Blogger posts and comments, transform it into a WXR file (aka WordPress eXtended RSS), and then import it into WordPress using the WordPress importer. This solves the import problem, but tragically it leaves behind the crucial metadata necessary to update the WordPress permalinks to their Blogger equivalents. However, all is not lost. Since version 2.0, my plugin will now generate best-effort, Blogger-like permalinks if it can’t find the crucial Blogger permalink metadata.
Instructions
First, import your posts using the Blogger Importer or via a WXR file.
Upload the file maintain-blogger-permalinks.php to your plugins directory:
/path/to/wordpress/wp-content/plugins
Activate the plugin (don’t forget!)
Under Tools > Maintain Blogger Permalinks click the button that says “Maintain Blogger Permalinks”. And that’s all. This is a one-time-use-only plugin. All your permalinks have been reverted to their Blogger versions.
Deactivate and delete maintain-blogger-permalinks.php
If you haven’t already, go to Settings > Permalinks and select “Month and name”
Finally, install the Blogger 301 Redirect plugin and follow its instructions to redirect your old Blogger posts to their new WordPress locations.
It doesn’t take many tools to program. At least it doesn’t feel like it takes that many. Obviously a computer. A lot of people are using Macs nowadays. What better reason to start using Ubuntu on a PC.
At Federated Media I’m finally using source code control, in our case Subversion. I had been doing isolated CVS commits on my own code at O’Reilly, but now that I’m working on a codebase with three other people, I have to say it actually makes working together exciting.
So my work is all svn st, svn diff, svn up, and svn commit. I’m editing text in gedit. No IDE, plain old vanilla gedit seems good enough. I’ve tried Emacs, Bluefish, gPHPEdit, EditPlus under Wine. But always back to gedit after few days.
I find myself doing a fair amount of refactoring, across lots of files I’m not familar with (though getting moreso), and when I make a change I want to be fairly confident that I won’t break a dependency I didn’t know existed. Enter grep. Other than forgetting whether the search pattern or the file argument comes first, I’m pretty handy with grep. grep -r sometext * was my new best friend…
…until I discovered something really really annoying. Since I was using it across many directories resursively, not only would grep return the files I wanted it to, it also returned Subversion’s cached copies of the files in the hidden .svn directories. Yuck! What a mess, grep would return useful results, but I’d still have to pick through them skipping over the .svn/… results.
I googled every possible phrase I could think of that meant how do I prevent grep from returning subversion files, figuring this would be FAQ #1 for anyone writing code under Subversion. No dice. Finally after some extreme phrasal gymnastics, I found a session description for a presentation at an upcoming KDE conference in Ireland that closed with this tantalizing nugget:
Time to gather information the old-fashioned way: by asking a person. So last month I sent an email to the session presenter, David Faure, and he told me he uses wcgrep, a bash script from the Subversion sources (not installed by default) that’s worth its filesize in gold.
I dropped it into /usr/bin, and now I wcgrep sometext with wild abandon (as an added benefit, the -r recursive option and trailing asterisk are optional). And occasionally when I just want a list of files that contain some method name, I whip out wcgrep -l sometext. And that’s pretty much what I do all day.
Many thanks to David Faure for pointing me in the right direction and Ben Reser for writing wcgrep.
Apartment hunting in San Francisco can be daunting. The first burden to overcome is learning the neighborhoods. Luckily, San Francisco is a relatively small big city, with 800,000 inhabitants in an area roughly the shape of a square, 7 miles on each side. Here’s a pretty decent map that outlines the major neighborhoods.
However, for the hands-down most accuracy (albeit at the cost of being a little busy), check out the San Francisco Association of Realtors MLS Map. It’s big, so here’s just a taste:
SFGate’s neighborhood guide is a good starting point, but I soon turned to my SF-based friends, family, and co-workers for any information they would share. What I heard again and again in response to the question “Where would you live if you could live anywhere” was “the Mission,” due to its concentration of young people, taquerias, nightlife, and sun. It’s not an area frequented by tourists, so not an area I’d spent any time in before. Which I liked.
I discovered an invaluable “guide” book intended solely for residents, rather than tourists, the aptly named, Not For Tourists Guide to San Francisco, 2006, which I highly recommend for demystifying San Francisco’s neighborhoods, in particular the areas where stores and restaurants coalesce. But don’t take my word for it, you can actually view the entire book online via a series of PDFs, for free. They even say:
Feel free to view and print these pdfs. If you’ve printed more than 20 pages, perhaps consider buying an actual book.
Very cool. But I digress.
The second burden is the cost of living. Currently (circa 2006) the rent for a 1 bedroom apartment (1 bedroom usually means a bedroom, a living room, and a kitchen) starts at around $1400. A month. Most anywhere else in the country, that’s a respectable mortgage payment. On a 4 bedroom house. With a yard. And of course it only goes up from there.
The final challenge is just showing up. Since there isn’t a surplus of vacant rentals, a landlord can schedule a 1 hour long (or less) open house (sometimes with only a day or two’s notice) to show an apartment. If you can make it to the open house at the appointed hour, you show up. If not, well then that’s not the apartment for you. If you’re interested, they’ll provide a detailed rental application to fill out and fax back. It’s definitely worth filling out one of these for fun (they’re like personal history research projects) or at least compiling the phone numbers and addresses for current and previous landlords and employers.
Serious hunters will bring a checkbook with them, necessary for putting down a security deposit (as a measure of serious interest) as well as a recent credit report for each prospective renter (which can be got for free via annualcreditreport.com). With anywhere from 5 to 30 people stopping by in an hour’s timeframe, the pool of applicants (read: the competition) is too great for any landlord to want (read: need) to wait for any promised checks or applications.
In between open houses, fellow apartment hunters can be identified by the stack of ink-jet printouts of open house ads from Craigslist they’re carrying around. I felt a certain fraternity with these souls, knowing that I was doing exactly the same thing. Craigslist appears to have a corner on the rental classifieds market in San Francisco (and I presume many other cities). Aside from pounding the pavement, for many Craigslist is the first and last place to look for rentals.
Suffice it to say, for a dyed-in-the-wool maximizer like myself, this process has been a bit trying—and is compounded by the fact that I live an hour and a half away.
This is the 1st post in a series about finding an apartment in SF.
You’re blogging. WordPress, Movable Type, Blogger, it doesn’t matter. You’ve got like 15 to 20 tabs open in Firefox. As per usual.
You’ve just stumbled upon the best quote on some blog that’s like totally supportive of whatever you’re blogging about. So you copy the URL and flip back to your post, only to experience this unsettling cognitive race condition.
Since you’ve yet to copy the actual text of the quote into your post, you can’t use your blog’s “create a link” button (some popular examples to the right). But at the same time, you can’t go back and copy the text without losing the URL. Errr.
Have you heard the one about the farmer trying to get a wolf, a sheep, and a cabbage across the river?
So what happens?
As a workaround, you paste the URL into your post, flip back to the post you got the URL from, copy the text you meant to excerpt, flip back to your blog (trying to find the right tab), paste the text, cut the URL out of your post, select the copied text, click the “create a link” button, and finally paste the URL into the JavaScript popup where you’d originally intended.
All that for a link! Two words: usability nightmare.
Even if things had happened in the right order—select text, copy text, switch tabs, paste text, switch tabs, copy URL, switch tabs, select text, click “create a link” button, paste URL—copying a simple quote and its URL from a webpage still requires 10 tedious, error-prone, and redundant steps.
So what should happen?
I want to be able to copy a quote and its URL at the same time, without having to so much as think about it. To do so, I wrote my first Firefox extension, which I opted to name the somewhat homely, Copy as HTML Link.
I took Jeremy Gillick’s Copy Plain Text plugin and modified it (with permission) to build an HTML link out of whatever text is selected, containing both the text and its URL. The idea was so simple, I can’t believe I didn’t think of it earlier. I also looked at Jedrick Kostecki’s excellent imgTag extension for inspiration, which does the same for <img /> tags when you right click on an image.
So if you were to use Copy as HTML Link to copy the first line of this paragraph, and then you pasted that into your blog post or text editor, you’d get:
<a href="http://justinsomnia.org/2006/05/copy-as-html-link-for-firefox/">I want to be able to copy a quote and its URL at the same time</a>
How to use Copy as HTML Link
Here’s a visual explanation of how it works:
What was 10 steps becomes 4: Select text, right click and select Copy as HTML Link, switch tabs, paste link.
Bonus step 5: continue blogging, train of thought intact.
Update, v3.1: Added French, Dutch, Serbian, and Chinese (zh-CN) locales; prepped for upcoming clipboard changes in Firefox 16, fixed weird context menu indentation on Mac OS X.
Update, v3.0: Copy as HTML Link now works appropriately when pasting in HTML-aware contexts, like rich email clients and WYSIWYG blog post editors.
Update, v2.0: Copy as HTML Link can now copy the text and URL of any link when you right click on it, without the need to select the text (which can be strangely frustrating in some situations). It’s super handy for copying the title and permalink of blog posts.
Questions, comments, and suggestions are always welcome. If you’re interested in contributing to the code behind Copy as HTML Link, it’s hosted on GitHub.
you can’t use your blog’s “create a link” button (some popular examples to the right). But at the same time, you can’t go back and copy the text without losing the URL. Errr. 