Check this out:
It’s the aurora australis, or southern lights, seen from above! It was taken May 29, 2010 from the International Space Station. Bad Astronomy talks about what causes aurorae in the blog post where I found the picture.
Seriously: The aurora. From space. How cool is that?
Whenever I visit a Dreamwidth journal and leave it open in a tab, I always find myself wondering why I was looking at the Debian GNU/Linux website. For possibly obvious reasons:
I can’t imagine how I keep mixing up a dark red 1½-turn counterclockwise spiral with a dark red 1½-turn clockwise spiral! 😀
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:
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.
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.
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.
The last days of the floppy diskette are approaching: Sony will stop selling them in Japan next year.
No word on how long they’ll continue selling them in the US…but when was the last time you saw a new computer with a floppy disk drive?
Hello chkdsk, my old friend
I’ve got to run you once again
Cause my Windows box is acting weird
And the disk drive must need something cleared
And the error that was printed on my screen
Made me scream
And put aside my work
For chkdsk
