Category: Tech

Posted on
by

I love seeing it when spam software doesn’t quite work. Sometimes it’s just schadenfreude, and sometimes it’s interesting to see how the templates are structured.

Here’s one that showed up in a comment spam on Speed Force:

{Hi|Hello|Hey there|Thanks}, {very|really|truly|genuinely} {cool|nice|good|interesting} {post|article|stuff}. Such {insighful|entertaining} writing is rare these days. I’ll {surely|certainly} be looking in on {this|your} {blog|site} again {soon|in the nea

It’s cut off because they managed to plug it in as the commenter name instead of the comment itself (oops!)

I haven’t decided whether to call this “flattery spam,” or “kiss-ass spam,” but my general reaction when I see these (and I’ve seen a lot of them) is, “Nice try.”

Posted on
by

WordPress has been making a big deal out of their new default theme, Twenty-Ten, released with WordPress 3.0. Meanwhile, I’ve been watching this site get more and more cluttered, and I keep having to tweak the existing theme to be able to deal with new WordPress features like nested comments, custom menus, etc.

Last week I had to replace the theme’s comment form (fortunately with something simpler) because it didn’t interact quite right with WordPress 3.0.

What the heck. I haven’t changed the look since 2007, so I might as well give it a shot.

I’ve switched over to Twenty-Ten, using one of my own photos for the banner. It’s a view from Modjeska Grade Road, taken last January.

Modjeska Grade View

I’m not quite happy with it yet, but I’m not sure what I want to do next.

My main goals for the new layout are:

  • Move the last of the customizations out of the theme and into plugins (so that I can easily switch to another theme if I want to).
  • Keep the new page uncluttered and relatively fast-loading (which is why I haven’t added everything back to the sidebar).

I have had to make a couple of adjustments to the theme itself. Twenty-Ten insists on showing excerpts instead of complete posts for archives, categories and searches, so I had to go in and modify that. I also added a couple of bits to the stylesheet: alternating comment backgrounds, tweaks to the old Twitter digests, etc. Still, I’m making a point of keeping those changes minimal and grouped together.

I’m also trying out WP-Minify, which should make scripts and styles load a lot faster, or at least the ones hosted locally. Unfortunately there are still a lot of remote scripts for things like Google Analytics, the Share This buttons, and the Link Within thumbnails. Some of them might work. I’ll have to experiment.

So, things are in a bit of flux. Please let me know if you find something that doesn’t work, or miss something that used to be here, by doing one of the following:

  • Leave a comment on this post.
  • Use the contact form.
  • Email me at kelson – at – pobox – dot – com.

Thanks!

Posted on
by

Twitter writes that link length shouldn’t matter, but the zillions of URL shortening services out there show that, for now, it does.

But why?

There are two main reasons to shorten* a link:

  • There’s a technical limit, such as SMS message length or email line width.
  • You expect people to manually enter the URL.

Right now, with Twitter messages limited to 140 characters and links forced to share that space with the rest of the post, URL shorteners are critical. But they’re working on a plan to accept longer URLs, and specifically shorten them for SMS messages. The full link will be available on the Twitter website, desktop clients, and other platforms that don’t have that hard and fast limit.

That will cut down on the demand for shorteners, but they’ll still be useful.

For one thing, there are other microblogging platforms out there like StatusNet.

For another, there’s email.

IIRC, the first URL shorteners launched because email programs often break up really long lines, including really long URLs. In plain-text messages, that leaves links not just unclickable, but inconvenient even to copy and paste, because you have to copy each line separately and paste them together. This will continue to be an issue as long as people continue to put visible URLs in email.

And then there’s the human factor. It might not be easy to remember http://is.gd/cGE8V, but it certainly takes a lot less time to write it on a scrap of paper than http://blogs.discovermagazine.com/badastronomy/2010/06/07/hard-to-port-eject-goose-eject/.

Which of those URLs would you rather type on your keyboard? Or worse, on your mobile phone?

*In this case, I mean making it really short and cryptic. There are plenty of reasons to keep links readable and sort of short.

Posted on
by

Photo of a door with a sign that says This Is Not a Door.So, remember this photo of a door labeled “This is not a door?” Last year, someone else sent a picture of the same door to FAIL Blog. Then a week ago, someone submitted mine to Friends of Irony, where Katie spotted it a few days later.

Here’s where things get interesting.

On both sites, people were absolutely convinced that it was “obviously” photoshopped.

*headdesk*

No, it’s real. It’s in a small business complex at the corner of Newport Ave. and Irvine Blvd. in Tustin, California. You can go there and look if you want. And of course there are the two photos taken from different angles.

The obvious conclusion is that people don’t really know how to tell whether a photo has been manipulated. At least on FAIL Blog, some of the doubters had reasons, even though they amounted to not understanding perspective.

I was tempted to post a comment linking to this XKCD strip (My hobby: insisting that real-life objects are photoshopped), but settled for requesting a photo credit instead.

Posted on
by

I recently tried to retrofit a mobile layout onto an old table-based site using CSS. It was a fairly simple layout: A banner across the top, two columns, and a footer. I figured I’d use CSS to “unwrap” the table and make the sidebar and main content area into full-width sections instead of side-by-side columns.

In theory this should be simple: CSS handles tables by using the display property and assigning it table, table-row and table-cell for the <table>, <tr> and <td> elements. You can assign these properties to other elements and make them act as tables, or you can assign block or inline to these elements and make the table act like a series of paragraphs.

Initial testing worked perfectly in Firefox 3.6 and Opera 10.5x. Internet Explorer 8, as expected, ignored the changes entirely. Chrome, however, did something very strange, and Safari reacted the same way: The banner shrank, and the columns changed from a narrow sidebar to a 50/50 split…making it actually worse for small screens.

Clearly WebKit didn’t like something I was doing. Unfortunately, WebKit powers the exact platforms I was targeting: the iPhone and Android!

I dug around with the developer tools a bit to see if I could figure out what was going on. Was the browser not applying the property? Were the table cells inheriting the “original” property from somewhere else? Did I need to change properties on thead and tbody as well?

What I found was that WebKit did recognize the display:block I had added, but somehow the computed style was reverting to display:table-cell. This only applied to table and td, though. Table rows actually did what I told them to, which was why the result ended up looking bizarre.

If it hadn’t changed anything, I probably would have chalked it up to the capability just not being implemented yet. But since it worked on table rows, but not on cells, I decided to treat it as a bug in WebKit and went looking for the best way to report it. I ended up creating a WebKit Bugzilla account and reporting it as bug 38527.

Check out the testcase in Firefox 3.6 or Opera 10.5 to see what it should look like, then take a look in Chrome 4 or 5 or Safari 4.