Big Words Indeed
Putting Big Words to work at Julie & Trammel’s:
Putting Big Words to work at Julie & Trammel’s:
Export a Vox blog to MTIF (Movable Type Import Format), along with some CSS to style it.
Requires Python, httplib2, Feed Parser and Beautiful Soup.
A few months ago, I was helping a friend troubleshoot an odd iPhone-related visual error on Hunch. The right side of the buttons weren’t lining up vertically with the top or bottom of the rest of the button. Oddly, the problem only manifested itself when viewing the site at certain zoom levels (non-quantized, to be specific). Pinching in/out or zooming into specific parts of the page made the buttons render correctly.
We’d used a similar technique on Domainr, so were curious to see if there was a way to address it cleanly.
It appeared that WebKit for iPhone uses mipmaps to render minimized background images. This makes sense—it has fast texturemapping hardware, and OS X / Quartz has been using OpenGL to render 2D graphics for some time.
The combination of hardware texture filtering of mipmapped background images with (then) imprecise texture coordinates were causing the artifacts we’d been seeing (recent related changes in WebKit).
Domainr’s buttons are styled using a sliding-door technique with a single CSS sprite background image. By this time we were starting to test against Safari 4.0 and Firefox 3.5, which also demonstrated similar visual errors when using their full-page zoom features.
The solution ended up being simple:
Vertically align the left and right background images for the button in the sprite.
It’s a palliative fix, but works. We were able to keep the single sprite image, and not introduce iPhone-specific CSS or
hack WebKit. In the end, there were other benefits to the fix. Despite redundant image data, aligning the background slices eased the process of updating the sprite image for new button variations.
Two friends of mine, both engineers, in separate occasions in the past week:
@rk: “Software is a hypothesis.”
@nk: “The GPL dictated behavior, whereas the authors of the MIT license merely prescribed it, having faith it would succeed on its inherent benefits.”
Last night I had another conversation with my friend John, who’s a director of engineering at a big game compaony.
I was relating has been building an integration test suite for our web application. We put it together in about three days using open-source tools like Cucumber, RSpec, EmailSpec, WWW::Mechanize and assorted home-grown or adapted bits of Ruby and Python. It’s great—we’ve got full black box testing of our APIs, pages and email. It tests the entire stack from HTTP to email.
John really really liked the idea, and expressed (again) how it’d be great if the game industry had the same level of cooperation and diffusion of code & ideas.
Since part of the stack wasn’t written in Ruby, we couldn’t make assertions by hooking into lower-level parts of the code. We had to test entirely via external APIs.
This originally was a response to a message posted by Chris Messina to the OpenID mailing list.
Since the original conversation that spawned OpenID, I’ve observed the rise of real identity versus obscuring it behind a [nonsensical] username @ someservice.com.
The fact is, the OpenID non-pattern has overwhelmingly ignored in favor of standard email + password signup. Hearteningly, the user experience of registration has been largely normalized. There are observable and copyable best practices here, that require neither a spec nor educating the user.
Basically, OpenID—as it is now—is irrelevant.
There were major lessons learned, but they were social rather than technical. The original problem that OpenID was conceived to solve has been supplanted by services like Disqus, Intense Debate and TypePad Connect.
The non-problem that OpenID  was intended to solve was putting a user in charge of how (and if) their identity online was centralized.
I say non-problem because it was already solved. Most people overwhelmingly didn’t care, and the people who did—knew how to set up multiple email addresses or use different usernames/passwords.
If email was invented today, it’s not to hard to imagine that we’d grant permission for a service to send us email using a mechanism similar to OAuth. Communicating with someone (or thing) via their preferred channel is just another ACL.
So OpenID won—not because it was the solution, but because it helped us understand the fundamental interaction problems that previous auth systems failed to address.
We didn’t build a better horse, but we did make some good glue.
In a piece for Ars Technica, author Nate Anderson opines:
“Distributing the cash fairly would require knowing how much people actually listen to specific tracks, which means software embedded in players or on users’ machines. And how many consumers are going to be excited about this?”
This software already exists—last.fm’s Audioscrobbler application tracks and reports the listening habits of 5 million people. A small fraction of the population, but strong evidence that users will trade a certain level of privacy in exchange for entertainment value.
It was all Caterina’s idea.
Earlier this evening, I received an NDA from a potential client. They’re a big company, so it came with some understandably bulletproof language, and was signed by an exec in their legal department (via a pasted-in scan of their signature).
The instructions that accompanied the NDA said I should sign and print two copies, mail one, and fax or email a copy back to them.
We don’t have a fax machine, let alone a landline, so we typically just paste in our signatures, create a PDF and send it back. Unfortunately, it wasn’t that simple. Fortunately, Adobe’s silly PDF protection was felled quickly by the OS X Print command.
Fail because of PDF password protection.
Open original NDA in Preview.
Fail because of character-set mangling.
Open printed PDF in Preview.
Fail because of charset mangling.
Create new multipage document in Adobe Illustrator.