It’s just too many clicks to leave the ol’ feed reader to see an article and save it to del.icio.us. I’m not into that kind of commitment. I am, however, into Greasemonkey so I headed to userscripts.org and discovered two fairly poor attempts to do what I wanted. The first one just took me to the del.icio.us/post page which is a different kind of bad solution. The second one displayed a nice box in the page for editing the info before saving away to del.icio.us but it appeared halfway off of my screen and I didn’t have the patience to figure out why. Here are those two:

• http://userscripts.org/scripts/show/11233
• http://userscripts.org/scripts/show/7957

Mine has many virtues. First off it actually works and on any browser window size larger than 422 pixels. Secondly it is visually a bit more disruptive than the small Google-styled “window” that one displays but not so obnoxious as to take you off the page entirely. And finally, it automatically pulls the title, link and selected text from the article. Fully featured! As a bonus you get the timeless, classic and beautiful feel of my favorite color, #eee.

Because of the way del.icio.us’ API works, it’ll ask you for your username and password the first time through but after that should behave nicely.

http://svn.rcrowley.org/svn/greasemonkey/readelicious.user.js or http://userscripts.org/scripts/show/22494

Just like the career of the average software engineer, Curvr has now grown up just a bit and started reusing other people’s code.

Dopplr integration in curvrmail

Geotagging is awesome but a bit of a pain to automate with any kind of accuracy. I’m making a compromise here by automatically tagging things using my location according to Dopplr. I had this working with my original PHP curvrmail script but have since switched to using Flickr::Upload::Dopplr just to practice some Perl.

AutoManual image rotation

Since my N73 isn’t friendly enough to rotate pictures for me, I’ve added a way to specify rotation in the email you send to Curvr. Prefixing with “L ” or “l ” will rotate 90 degrees counterclockwise and prefixing with “R ” or “r ” will rotate 90 degrees clockwise. Note in both cases that it is a letter followed by a space followed by the normal title/tags syntax.

It is a bit awkward to think about in terms of left and right, since I could either be talking about the direction you rotated the camera or the direction the photo should be rotated (which itself could be rather ambiguous, so we’ll say that it is relative to the top). So here’s the official word: the rotate syntax wants to know which direction you rotated the camera to take the picture.

curvrconf for getting API tokens

Getting tokens for the Flickr and Dopplr API, while not something you need to do often, is quite a drag. Enter curvrconf, the copy-and-paste simple way to get your tokens out. All it needs is to be setup with the same API key as curvrmail and it’ll guide you through grabbing tokens. For the Flickr API, setup your key for web-based auth and give it a garbage URL to return to (I use http://localhost:81/).

As usual, the API key is up to you. I accidentally committed my keys/secrets/tokens to Subversion but have expired all of them so don’t even bother trying to steal my accounts.

Anti-blue C code

The main curvr program has for a long time introduced some strange blue artifacts into my photos. I figured this was due to some underflow or overflow issues with my color maps. I finally took the time to do some serious experimentation and it turns out that if I just favor a stronger red channel in these edge cases, the artifacts seem to go away. Strange and beautiful indeed. I can’t fully explain the phenomenon but believe it’s somehow related to my using the red channel as my indicator of color value (as many photographers do when converting to black & white).

So there it is, curvr-0.2.

Er, here it is: http://svn.rcrowley.org/svn/curvr/tags/curvr-0.2

A bit ranty, proceed.

The designers of iCal did it wrong. I applaud them for including timezone support at all because of the can-of-worms I envision it being. Dates are scary in the parsing sense. For the uninitiated, here’s about how iCal works now:

You can enable timezone support (rightfully off by default as it adds clutter that 90% will never click) in Preferences and then have an editable timezone option for every event on your calendar. This part will be strange in text but I’ll try: changing the timezone on a single event will cause that event’s block of time (in week view or day view) to shift up or down by the offset between your home timezone and the event timezone. Easy-to-follow example: an event in St. Louis (Central Time) at 10:00 am appears at 8:00 am on my calendar because I’m in Pacific Time.

The right way is to allow setting entire days to a certain timezone. Perhaps this setting would be inferred from a multi-day event on your calendar or (bonus!) a feed imported from Dopplr? Tying a timezone to a multi-day event would be sweet as it could be expanded to start and stop at certain times of day, thereby satisfying even the craziest of travellers. Assuming this default would eliminate my need to micromanage my calendar.

Benefits? I could say (to my computer, with mouse clicks), “I will be in the Central timezone from February 1st until February 9th, please show those day’s events accordingly.” If an event is scheduled on a day that I’m slated to be in the Central timezone, it should always be shown as if it is in the Central timezone. Displaying everything in the current timezone just makes me do extra math.

The tradeoff in design here is day-to-day consistency versus the rate at which I can consume information from my calendar. I can understand why Apple’s designers made the decision they did but respectfully disagree. It is much easier to casually remember where I’ll be at any given time (in the macro sense) but much more difficult to remember that I must constantly do timezone math when looking ahead on my calendar.

The echosphere is making quite a stink about Microsoft’s proposed X-UA-Compatible header to explicitly match HTML pages to rendering engines. There are two possible outcomes, assuming Microsoft goes ahead and implements this HTTP disaster. More likely is that we will be roughly where we are now, with special cases to make IE do what we want and other browsers just working reasonably correctly by themselves. Less likely is that the Redmond dream will be realized and every browser will become a time capsule of rendering engines ready to happily consume whatever 1997 garbage you can throw at it. Oh yeah, if you add the header to all of those ancient pages.

For maximum effect, X-UA-Compatible requires the support of the other browser vendors, otherwise it is just another Microsoft hack with a pretty mask on (read: no regular expressions). (Aside: The ideal solution to problems like the old broken box model would have been to fix it immediately instead of six years later. I can’t help but think that X-UA-Compatible would never have been proposed had that bug not persisted for so long.) In this best-case scenario the cynic in me still sees ignorant developers either omitting this header or setting it only for IE, leaving other browsers to do … something. If the header is set for all of the major vendors (and we’ll just assume that those major vendors will still be the only major vendors down the road) then I must admit, browser bloat is the biggest concern we have. I for one don’t want my Firefox to get any bigger. Just imagine the new and exciting memory leaks!

In the (I think) more likely case of Microsoft pushing ahead with this feature alone then developers have the slight advantage of being able to code to one version of IE instead of several, in addition to Firefox/Webkit/Opera. This may prove to be useful in fixing those sites that IE7 broke. But seriously, why haven’t those already been fixed?

Ultimately, it all comes down to what browsers do if that header isn’t sent or they aren’t paying attention to it at all. It sounds like Microsoft is content to leave everything its IE7 state forever unless told otherwise but I doubt anyone else will be keene on the idea. Microsoft is a much bigger fan of backwards-compatibility than Apple (think Classic Mode) or Mozilla (each new version of Firefox breaks all of my extensions) so I expect to see these others defaulting to their cutting-edge browser unless told to retard themselves. This most-important point of the whole feature is summed up best by Jeremy Keith, “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.” I’m a desktop software developer by day and wish I could say to Windows, “Make this app work just like an out-of-the-box Windows XP installation.” I can’t because having such a ridiculous level of backwards-compatibility ultimately makes software too big and unwieldy — it hurts you in the long run. I hope, when framed in the desktop version that the insanity here shows through.

My final thought on the matter is that the best thing Microsoft can do for the future is to push IE7 out to everyone. Like pulling off band-aids, it’s best to do these things fast and deal with the consequences all together. Fixing the IE box model should not take seven years. Get it over with and move forward without the hacks.

Elsewhere:

• A List Apart: Articles: From Switches to Targets: A Standardista’s Journey
• QuirksBlog: The versioning switch is not a browser detect
• Adactio: Journal—Broken
• A List Apart: Articles: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8

Ever wanted Wordpress to display small screenshots of pages you’re linking to like the del.icio.us homepage? Neither have I but a friend wanted it and I wanted to build a Wordpress plugin, so here it is.

wp-screenshots takes the URL of a del.icio.us RSS feed as input and gives back a <ul> containing thumbnails from the unofficial Snap API.

Installation is as easy as running svn co http://svn.rcrowley.org/svn/wp-screenshots/ ./ in your wp-content/plugins/ directory. You can then use the PHP function screenshots() anywhere in your templates. As a bonus, if you setup wp-screenshots.php to run as a cronjob, it’ll understand what’s up and just hit the proper image URLs to make sure Snap’s cache is primed for your page views.

http://svn.rcrowley.org/svn/wp-screenshots/

Manifest (verb): To embed XML describing libraries which are expected to be available at runtime, done in the course of developing software using Microsoft Visual Studio.

The wisdom of the collective T-Rex (#xulrunner on irc.mozilla.org) says that statically linking against the Microsoft C Runtime (msvcr80.dll and friends) is the way to go. However I’ve run into a case where I cannot do this (deciding whether this is due to technical limitations or lack of competence is for readers to help me decide).

The image processing component of the Flickr Uploadr links against GraphicsMagick and Exiv2, libraries that do image processing and EXIF/IPTC metadata processing, respectively. Without them, it doesn’t fly. Problem is, they both link the C Runtime themselves by using std::string and such. Both of these libraries will build fine given the /MT flag, which instructs them to statically link the C Runtime. When they themselves are statically linked into the XPCOM component later, all hell breaks loose. It seems that the static linker can’t resolve the duplicate definitions caused by overzealous static linking.

The solution, as it stands, is simply to include the C Runtime and its manifest in the distribution. Placing the following files in Uploadr’s components/ directory has allowed life to go on for the moment.

• msvcr80.dll
• msvcp80.dll
• msvcm80.dll
• Microsoft.VC80.CRT.manifest

Lastly, make sure your XPCOM project in Visual Studio is set to embed its manifest from Project Properties » Manifest Tool » Input and Output » Embed Manifest.

A more optimal solution might be to combine the Visual Studio projects for GraphicsMagick (and therefore libjpeg, etc), Exiv2 and the XPCOM component into one large tree that Visual Studio might be able to better manage. Has anyone out there done such a thing with Microsoft’s static linker (even if not with XULRunner)?

This post is about two things. Most proudly it is about me finally taking the time to setup all of the necessary gears and levers for my phone to post processed photos through to Flickr. Bonus-ly, it is about rolling what seems like your own email server from a few config files and Yahoo! Mail (or GMail, if your twisted brain is so inclined).

First, the fun stuff. I posted in November about curvr, my automated and assumption-filled command-line Photoshop. Refresher course here: http://rcrowley.org/2007/11/08/introducing-curvr/. The day after I wrote curvr I started to experience what can only be described as “crunch time” on Flickr Uploadr, so a quick shell script called curvall was born so I could at least use curvr after Bluetoothing photos from my phone.

Almost two months later and this is just silly. A different kind of crunch time, if you will. From a distance the solution isn’t nearly as ugly as the syntax of .procmailrc but I won’t be mean. I setup an MX record for my domain to send mail to the box in my apartment. From there, postfix rejects the riff-raff and passes the good stuff on to procmail which either works photos over with curvr or forwards to Yahoo! Mail for my consumption.

Postfix, there’s more to life than UNIX accounts

We need to teach postfix what email addresses to accept.

/etc/postfix/virtual:

r@rcrowley.org rcrowley@localhost
SPECIAL_CURVRMAIL_ADDRESS@rcrowley.org rcrowley@localhost

/etc/postfix/main.cf (available in SVN):

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = banzai
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = banzai, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

# Nasty homegrown config
virtual_alias_domains = rcrowley.org
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail

It really is important not to put the same domain in mydestination and virtual_alias_domains. Fecal matter and oscillating device and all that. Then run these commands:

$ sudo postmap /etc/postfix/virtual
$ sudo postfix reload

Procmail, your syntactic colon is full of shit

If photo, Flickr it. If not, throw it out into the cold.

~/.procmailrc (also available in SVN):

:0 bfW
* ^TO_<SECRET_CURVRMAIL_ADDRESS>@rcrowley.org
| /home/rcrowley/bin/curvrmail

:0 E :
! <normal_forwarding_destination>@yahoo.com

Now, Stephen R. van den Berg willing, email to your special address will be sent through curvr and onto Flickr (assuming you updated the curvrmail script with your secret Flickr email address) and all of your normal email will be forwarded somewhere else.

Yahoo-oooo!

I admit it, I like Yahoo! Mail. So I have my .procmailrc forwarding to Yahoo! Mail. Over at Yahoo! Mail I have a default mailbox setup as the-first-letter-of-my-first-name@rcrowley.org so that I can also send mail as my better email address.

Anyway, it’s all in SVN: http://svn.rcrowley.org/svn/curvr/

I’m interested to know how similar this all is to Aaron’s filtr workflow.

Before I forget, some rather scattered mental notes from last week in Ireland.

1. Airbus’ 330 is the nicest plane I’ve ever been on.
2. The Irish are much less savagely capitalistic than Americans. Case in point, everything was closed on December 26th for St. Steven’s Day. Me, I’ve never heard of it.
3. The food is amazing. Stews, gravies, lamb and all came with the typical “Irish flag” plate of carrots, multiple varieties of potatoes and green beans or broccoli.
4. Ford Motor Company, for all its shortcomings, is doing surprisingly well in Ireland. Nearly every delivery van, all of the police cars (Garda!) and a healthy portion of the citizen cars were Fords.
5. Continuing the automotive train of thought, Ford, Mazda, Toyota and Honda all had almost completely different product lines than in the US. I can understand skipping out on the big trucks but they all make some reasonable cars that I can’t understand reinventing for Ireland/UK drivers.
6. The roads are laid out terribly. They use a white line for both the center divider and lane dividers. Sometimes they’re all a single dotted line, meaning you need God, the Pope, Jesus, your navigator and your mother all working together to stay in the right place.
7. The speed limit on barely-wide-enough-to-fit-2-cars roads is 100 km/hr. WTF?
8. Irish cigarettes bear warnings that do not mess around. The best one: “Smoking kills.” I know, pics-or-it-didn’t-happen — coming soon to a Flickr near you.
9. The Irish accent is substantially different than the English accent. (Of course I can’t provide an example in text.)
10. Roundabouts are far more efficient than stoplights.
11. It is odd and comforting at the same time to see whole families together in the pub.
12. You can always find live music in Temple Bar, Dublin.

Time to take a deep breath. Flickr Uploadr 3.0 is out for all and two minor revisions later is looking pretty good. There are still issues to be resolved but I won’t spend any time here whining about desktop software or how hard it is.

Instead, a couple of lessons I definitely learned the hard way from this release.

• Desktop software, despite my best efforts, just can’t be deployed as rapidly as a website can. I’m still trying to find the sweet spot between pushing fixes as soon as they’re fixes and not bothering users with a constant stream of incremental updates.
• Some bugs are not as bad as they seem. And specifically not as bad as the one you might introduce hurrying out a fix. The transparency the Flickr Forum gives us in diagnosing bugs and communicating workarounds is invaluable here. Keeping members in the loop is just about as important as fixing the bugs.
• Other people’s computers are more different than your’s than you can possibly imagine (or replicate with 6 computers). Statically link like your life depends on it! (But that’s only half the battle.) Diagnosing problems when you can’t just fire up cmd.exe or Terminal is a daunting task.

The next challenge will be turning the GPL’ed Uploadr into something moldable and bendable for other developers to play with. In the meantime, check out the new Flickr Uploadr and its source code at http://flickr.com/tools/uploadr/.

Photo from Cal.

The average XULRunner developer gets to choose at the beginning of any project whether to work with the 1.8 or 1.9 series. 1.8 gets you stability and heartache; 1.9 gets you trunk-y goodness and a sweet thread library. I’m of course simplifying things.

Until yesterday the prospect of localizing XULRunner itself had not even crossed my mind. An error to be sure but one that was actually easily corrected. We at Flickr chose to work with the 1.9 branch to take advantage of the newly enjoyable thread library. Working with these nightly builds was great as I was able to watch bugs die each time I pulled a new nightly.

The trouble began when I started putting together final builds yesterday. Things like the Mozilla upgrade system, file picker dialog and standard OK/Cancel buttons were not localized because nightly builds come only in English. Bummer. LXR came to my rescue, though. I was able to pull together my own localizations of XULRunner by scraping pieces from the Firefox 2 codebase.

I am not sure what the lesson here is but with ample planning and testing, apps built on XULRunner trunk can be localized just like any other. It would be awesome if, in the future, trunk builds included the entire localization tree, which would allow my build process to just pick out the appropriate JAR file for each language (which is essentially what I do now). Look to the Flickr Uploadr source (more on that soon) for an example of how all this works.