No, no, it was nothing like that. I just applied for Google AdSense a few days before my actual 18th birthday. That, of course, netted me a declined application, because I was obviously still too young to participate in AdSense—but I wasn't counting on it also killing my ability to reapply later. When I tried again to sign up for AdSense using my main Google Account, after I was old enough, I got nothing but errors.

When I emailed Google AdSense Support about the problem, they said I could just reapply, but would have to use a different email address—meaning a different Google Account—to do so. I eventually did so, after I created an alias or two at Gmail, but I never used the approved account. I wasn't sure if I even wanted to try ads on this site, and I also had a hang-up about the principle of having one service in an account separate from all the others.

I did try to change the login email address associated with my approved AdSense account. The only problem was, my account's login couldn't be changed, because it was associated with a Gmail account. I was less than pleased, but figured it was a problem I could solve later.

And so it was: Last week, just in time for February break at college, I discovered that my primary Google Account again had the ability to apply for AdSense. Maybe there's some kind of expiration on declined applications; I haven't read enough of Google's policies to figure that out. (Who has the time, especially as a full-time college student?) So I did it: I reapplied for AdSense on my primary account.

Google's systems noticed that an active AdSense account already claimed my Payee Name. But instead of telling me I couldn't complete my application, as I expected, it asked if I wanted to transfer the account. What did I say? Yes!, of course.

I filled out a short form, got a bit of data from my approved AdSense account, agreed to forfeit my $0.00 of unpaid earnings in the old AdSense account,¹ submitted, and waited. In less than an hour, I got confirmations addressed to both my old and new email addresses that my account had been transferred. I logged into AdSense using my main Google Account, and it worked.

Technically, what Google did was close my old account and open a new one associated with my primary Gmail address. That's why unpaid earnings below the payment threshold didn't transfer. If I had generated ad code using the old account, I would have had to replace it. Not having to deal with that made a simple process even easier.

Thanks, Google. Every so often, you do something that makes me really happy. This was one of those things.

This change affects my website in a small way: I'm testing AdSense ads in the places supported by LightWord, the WordPress theme I use, whose development I have kind of taken over.² Since enabling the new ads (which only show on single posts) several days ago, I've seen exactly zero clicks. It'll be an interesting experiment to see if that changes.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

1. Earnings below the payment threshold of US$10 are forfeit in transfers. Not that I ever used my old account, so it couldn't possibly have any earnings.
2. It's not like anyone has really seen my changes. I haven't gotten around to officially forking the code and releasing my own version under a different name. Doing that sounds like a summer project, maybe, depending on how busy I am, as it will involve updating the theme code to meet all of the current Theme Review guidelines.

Earlier this month, no doubt on or soon after February 6, 2012, I went to Ping.fm to find a green bar on top of the area where I usually clicked to log in and get on with posting things to my social networks. Seesmic, apparently, had other plans. They really wanted to make sure I heard about their new product, Seesmic Ping. They covered the login link with a green bar to make sure I'd notice it.

The offending green bar on Ping.fm's homepage

All right, fine, I went to have a look. I didn't feel like signing up for the new service, though. Instead, I dug up the blog post announcing Seesmic Ping, from February 6. Near the end, there was a very telling paragraph:¹

For Ping.fm users – With the release of Seesmic Ping, we’ll look to maintain Ping.fm for some time. In the meantime, we encourage you to sign up for a Seesmic Profile and give Seesmic Ping a ride through our mobile applications or the web.

I wasn't the only one made uneasy by those two sentences. "for some time" really doesn't mean "indefinitely", and sure sounds like Seesmic will eventually kill Ping.fm entirely.

Source images: Question mark, Axe, logo from Ping.fm website

I've had complaints over the years with Ping.fm, occasionally with performance. But most of them came from decisions made by Seesmic, explicitly or not, after they acquired Ping.fm. They were things like:

• No new API keys for applications
• Disabling API keys for applications like the Shorten2Ping WordPress plugin, instead of blocking the users who were spamming
• No new services for years
• Issues with existing services, like Jaiku (which Google later shut down completely about a month ago)²
• Broken post-by-email³

Despite all the issues following the Seesmic acquisition, Ping.fm has remained solidly usable. But Seesmic has now announced a successor to Ping.fm—and what's more, they intend to charge for it (emphasis mine):⁴

We’ll look to have more features and services when Seesmic Ping comes out of beta as a paid service.

No pricing came with the announcement, just a notice that the new service would eventually cost money. I know we've all been spoiled by free Web services, and the money has to come from somewhere, but somehow I have my doubts that Seesmic will take an approach that is consumer-friendly. HootSuite has a great pricing model: Features that consumers will use (a few profiles, with one user who can manage them) are free; business-level features (more profiles, multiple-user collaboration) cost money. I don't think Seesmic Ping will follow that structure; if I had to guess, everyone will have to pay for it.

I mean, really, Seesmic could have made the green bar push the entire page down, instead of floating it over the four tabs at the top. Look at what it covers:

With the green bar made partially transparent, we can see what it covers

It floated on top of the page for a reason, I'm sure. Putting it there made me click on it to make it go away (it didn't). Then I read it, and followed the link. No doubt I followed the expected sequence of actions precisely. And that irritates me, because the green bar should have just looked like this:

This is just as informative, but less annoying.
It probably failed the In-Your-Face Test.

I imagine that the reasoning went something like, "If it doesn't cover the login link, users will ignore it. No, displacing the login link by 40 pixels isn't enough; it has to actually be inaccessible. We will force users to read this bar on every single page." Oh yeah, it pops up on every single page view. Home, login, Dashboard, settings, you-name-it—green bar ALL the pages... for lack of a better X all the Y idea.

There was also an email newsletter sent out on February 15, announcing Seesmic Ping, which I read after going through the whole "green bar" thing. It too addressed the future of Ping.fm... sort of:⁵

Like many of you, we appreciate the passion that Ping.fm brings, and made sure to carry over its core value of the simplicity in posting. With the launch of Seesmic Ping, we continue to enhance this service with reliability and robustness, while offering key features such as scheduling and the ability to post to multiple Twitter accounts and Facebook pages.
Eventually, Seesmic Ping will be a paid service. While in beta, Seesmic Ping is free to access. If you have any feedback, please tell us what you think: feedback.seesmic.com.

The email announcement carefully avoided any mention of shutting down Ping.fm. The original blog post never changed, though, so the plans are certainly still in place.

TweetStats' bar chart showing how I posted my tweets, as of 02:25 EST February 25, 2012

This state of affairs is really disappointing, because I've used Ping.fm as a staple of my online life for, literally, years. According to TweetStats, I've posted from Ping.fm more than I have from Twitter.com. (twhirl is still on top because I used to have it open all the time back in high school.) I post from the Web, from a third-party app on my Android phone, via SMS, and I used to use email posting from my mother's cell phone back before I had my own. In short, I use Ping.fm a lot. It still is the best option I've found on the market for cross-posting to different social networks.

If When Ping.fm goes away, I'll probably end up switching to Hellotxt. Hellotxt has its own share of issues at the moment, including a lot of services that are disabled and a significant slowness to the site, but it's still the best alternative to Ping.fm. I can also just roll up my sleeves and build my own personal system, since all of the sites I use provide free API access, but I'd rather not take the time to do that. It would also load my (very) shared server and lack a lot of features like posting via SMS⁶ and scheduled posting.⁷ Could I implement them? Sure. Would I take the time? Questionable. Additional features also mean additional server load, and so on.

The point is, I have only one practical alternative—Hellotxt—because building my own is hard, time-consuming, and unlikely to happen any time soon. I dream that Seesmic will change plans and decide not to kill Ping.fm, but the reality is that it's almost certain to happen and the only question is when. Hopefully Hellotxt will have its issues worked out by then and will be ready to take over as king of the cross-posting niche. It would certainly serve Seesmic right if Ping never went anywhere, and that might be worth losing Ping.fm.

As for never using Seesmic, ever, well, let's just say I oppose the way they do things. I don't like it when a company buys another company, takes the ideas and technology from existing products, and then shuts down the old company's services. Google does that a lot, and those are the times when I come closest to hating Google. The difference is, Google almost always creates awesome things out of the remains of old companies and services. Seesmic hasn't really done anything but allow a useful product to stagnate, and now they're going to kill it at some unspecified future date, replacing it with something that can never be a true replacement. You can't replace a free service with a paid service; it doesn't work that way.

If Seesmic takes their pricing structure in the same direction as HootSuite, though, and they only charge for certain features, I might actually give Ping a try. I have a hard time imagining a situation that would make me actually like Seesmic as a company, though.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

1. The paragraph was riddled with links to Seesmic.com, which I didn't copy. There was no point.
2. Unlike other social networks that died, Jaiku had a dedicated following willing to preserve its contents, if not the functionality. Apparently, my "presences" are archived.
3. Added later on publish date (23:20 or so) when I discovered that Shorten2Ping had failed to post this article via Ping.fm. My server's emails are working. The problem is with Ping.fm. Grr.
4. Yes, I skipped copying another link to Seesmic.com. All occurrences of "Seesmic Ping" were linked except for one. I guess somebody missed it.
5. And just like in the blog post, every occurrence of the phrase "Seesmic Ping" was linked to Seesmic.com. Talk about carpet-bombing links.
6. If I'm not paying for Seesmic Ping, I'm certainly not shelling out for an SMS gateway to serve my one-user app.
7. Ping.fm only has scheduled posting because HootSuite supports Ping.fm. It's not native. Hellotxt has native scheduling, but I haven't tested it yet.

I'd love to think my export format ideas post had something to do with the end product released yesterday, but I seriously doubt it.

Sort of...

Let's just say, Google Takeout isn't behaving very well. The test archive I created yesterday won't download, and I've tried both Google Chrome 13 and Mozilla Firefox 3.6. The feature isn't there yet, but I'm sure Google engineers are working on it.

I'm still happy...as soon as they make it actually work.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

That one feature: Export.

Think about it. Google Docs lets one download all of one's documents, spreadsheets, and presentations in a ZIP archive. Gmail allows both IMAP and POP access to mail accounts, facilitating the complete backup of account data to a personal computer or server. Google Reader offers export of one's entire subscription list. Google Calendar offers export formats compatible with several desktop and Web competitors' products. Google Contacts can be downloaded and imported into Microsoft Outlook, Apple Address Book, and countless others.

I could go on.² Just about every Google service offers some way for users to get their data out.³ Google's Data Liberation Front initiative is a demonstration of their commitment. So why can't I export my Google Voice data?

The Case

When GrandCentral was shutting down, users had to download messages one at a time. There were also large holes in the data that could be recovered due to a glitch in the storage system that irrevocably lost dozens of my messages, and likely thousands more from other users. (Most annoyingly, pleas from users for the company to do something about the data loss fell on deaf ears.) The issue was never officially addressed or explained; all we former users can do is speculate as to why our messages were forever irretrievable.

Fast-forward to Google Voice. The export function is still limited to downloading individual voicemails and call recordings, one at a time, manually. There is no support for exporting the transcripts of these audio recordings. It is not possible to download SMS conversations (save for copy-and-paste to text files). Call logs can only be backed up by painstaking manual duplication into a spreadsheet or other suitable format.

Every Google Voice account is amassing even more data than GrandCentral accounts did, thanks to support for text messaging (a long-awaited improvement, even if it doesn't support SMS-to-email or⁴ shortcodes⁵). Billing logs for international long-distance are another piece of the corpus.

All of this information is potentially useful in the future. There is a reason that users have flocked to the service and its promises of one number forever, keeping messages forever, and so forth. It's unlikely that Google itself will enter the deadpool any time soon, but services have been cut before. If Google Voice doesn't meet all the right expectations of Google's higher-ups, it too could get the axe. All those messages that were supposed to be kept forever? Gone.

I like to use the now-defunct Twitter-like service Pownce as an example. When the decision was made to shut down the site, a new section appeared in users' settings. That section allowed them to request a backup of their account data for download. To this day I can still open up a backup file and peruse my activity on the site, though it is long dead.

Unfortunately, I can't believe that Google would have its engineers develop a similar export tool for a service about to be shut down. It didn't happen for GrandCentral, that's for sure. Other companies (*cough* Nambu *cough*) have a similar attitude: Users don't need copies of their data; just jerk the tablecloth off the table, and all the dishes with it. Besides, I can't forget the seemingly arrogant launch of Google Buzz, right into my face. In short, there are precedents for Google violating DBAD.⁶

The Solution

Solving this problem is relatively simple. If a complete and total export feature is developed and released well before Google Voice is threatened with a shut-down, there won't be any issue. The phone numbers assigned to Google Voice accounts (so-called Google numbers) can be ported out to another provider—that was a core policy right from the start—so there's no issue of losing that; I could port my Google number to a cell phone right now. All future issues would be handled by someone else. Google's problem is historical data and keeping their promise to users.

How should the Google Voice team go about accomplishing this feat? I've been mulling over different ideas for the past few months, and I think I've come up with a reasonable export format.

The Format

My hypothetical export file looks something like this:

Google_Voice_export_acctusername_2010-04-30T14:23:47.zip

A few notes:
1) Files in any of the directories (except /Greetings) can be divided into date-dependent subfolders, but it's simpler to not do so. It's only an issue if the number of files in a directory exceeds file system limitations.
2) Obviously the IDs would be much larger in a production setting with thousands or millions of users; mine are just for illustration purposes.
3) I don't know if Google's database maintains separate IDs for each data type or if it keeps a single ID counter for all records, but that's why I prefixed each file type with a letter code indicating what it is: cr = call recording, nt = note, sc = SMS conversation, ts = transcript, vm = voicemail.

The Parts

Files

Within each CSV file are rows with the following data fields:

• call_logs.csv: ID,Timestamp,HasNote,Number,Type,Name,StartTime,EndTime
• recordings.csv: ID,Timestamp,HasNote,Number,Name,Duration
• sms.csv: ID,Timestamp,HasNote,Number,Name
• voicemail.csv: ID,Timestamp,HasNote,Number,Name,Duration

All timestamps are in UTC. It is easiest for all IDs to be unique, across all item types, though again I don't know how Google stores the data. I assume that the ID namespace is shared among all Google Voice items. I've used that assumption as the basis for some of my archive structure decisions; because of it, I did not need to disambiguate between notes attached to the different item types.

The exported CSV files contain required, optional, and conditional fields. Required fields must be non-empty; optional fields may be empty and are filled in if appropriate information is available; and conditional fields are required based on the value of another field.

Field notes: The HasNote and Duration fields would be useful to have, but are not required as the values they contain can be determined using other methods—respectively, by checking for the corresponding nt<ID>.txt file in /Notes and by checking the duration of the corresponding audio file in /Recordings or /Voicemail. I've left them in because, in the long run, having them would make it easier and more efficient to write a program to read the archive.

call_logs.csv

Required fields: ID, a unique record identifier; Timestamp, the item timestamp used on the Google Voice website; HasNote, whether the item has an attached note (1 for yes, 0 for no); Number, the phone number of the other party; and Type, the type of call record (placed/missed/received)

Optional fields: Name, the name of the contact (if the phone number can be matched to a contact)

Conditional fields: StartTime & Endtime, start and end timestamps for calculating call duration (empty for missed calls, as there is no start or end time)

ID cross-references: note

Call log entries are cross-referenced by ID to note files in the Notes directory if HasNote is 1.

recordings.csv

Required fields: ID, a unique record identifier; Timestamp, the item timestamp used on the Google Voice website; HasNote, whether the item has an attached note (1 for yes, 0 for no); and Number, the phone number of the other party

Optional fields: Name, the name of the contact (if the phone number can be matched to a contact); and Duration, the audio file duration

Conditional fields: none

ID cross-references: audio, note, transcript

Call recording records are cross-referenced by ID with audio files in the Recordings directory, note files in the Notes directory (if HasNote is 1), and transcript files in the Transcripts directory.

sms.csv

Required fields: ID, a unique record identifier; Timestamp, the item timestamp used on the Google Voice website; HasNote, whether the item has an attached note (1 for yes, 0 for no); Number, the phone number of the other party

Optional fields: Name, the name of the contact (if the phone number can be matched to a contact)

Conditional fields: none

ID cross-references: conversation text, note

SMS records are cross-referenced by ID to text files containing the full conversation, formatted like instant messaging transcripts:

(2010-03-21T04:12:02) Me: what's up?
(2010-03-21T04:14:53) John Smith: not much, got a test tomorrow fml
(2010-03-21T04:17:19) Me: what subject?
(2010-03-21T04:18:17) John Smith: history ugh
(2010-03-21T04:20:02) Me: ugh indeed. good luck and try not to die
(2010-03-21T04:23:47) John Smith: thx. if u dont hear frm me tmrw its bcuz my brain asploded
…

Again, all timestamps are in UTC.

SMS records are also cross-referenced by ID to note files in the Notes directory if HasNote is 1.

voicemail.csv

Required fields: ID, a unique record identifier; Timestamp, the item timestamp used on the Google Voice website; HasNote, whether the item has an attached note (1 for yes, 0 for no); Number, the phone number of the other party

Optional fields: Name, the name of the contact (if the phone number can be matched to a contact); and Duration, the audio file duration

Conditional fields: none

ID cross-references: audio, note, transcript

Voicemails are cross-referenced to audio files in the Voicemail directory, note files in the Notes directory (if HasNote is 1), and transcript files in the Transcripts directory.

Folders

The folders should be pretty self-explanatory. /Greetings contains recorded greetings (the only files with "real" names, though I'm sure they too have IDs on Google's end), /Notes contains the text of notes added with the Google Voice website's "Add note" feature, /Recordings contains recorded calls, /SMS contains full transcripts of text-message conversations, and /Voicemail contains voicemails.

The Greetings folder doesn't have an associated CSV file because I think the files it contains should just be given the same name as the corresponding greeting in Google Voice's settings. None of the other items really have names, so they can all go by ID and be indexed in CSV files; but the user is likely to name each greeting descriptively and that name shouldn't be hidden behind an abstraction (read: obfuscation) layer in the exported backup file.

Alternate Ideas

I toyed with the idea of somehow including time zone information to help put timestamps in context, but there's no good way of doing it. Put a time zone at the account level and you lose changes. I doubt there's a user-preference history somewhere in Google's database. Try to put it on each record and you have a nightmare, since most of the time there's no indication that the user changed time zones. The user can figure out where he/she was on any given day and mentally adjust the UTC timestamps given if it's really that important.

Similarly, I thought about including preferences, caller groups, and so forth, but I don't know enough about the data structure to come up with an estimated export format.

It occurred to me that the exported CSV files could also contain a ContactID field, matching up with the corresponding Google Contacts entry. That way, external applications could hook up to the GData Contacts API and pull the contact's information to enhance the information display. For example, a third-party app could emulate the way Google Voice's website places the contact's photo next to each related entry. I left this out of the above spec because of the potential for inaccurate ContactID values; who knows what the user will change in her contacts between exporting the Google Voice data and trying to use a third-party app with it.

Speaking of third-party apps, that's why I've tried to keep my hypothetical format so machine-readable. What if Google or another developer wrote a Web app or cross-platform application that could import the archived data and present it in a graphical interface? It'd be a great way to access archived information while offline—of course, Google could also add offline support to the site, but it's always good to have alternatives. The possibilities are truly endless; my contact-photo example above could be done with the export format as-is, though it would take a little more API work.

The Goal

My objective is not to have Google implement my solution verbatim; I know there are glitches in my reasoning, holes in my contingencies, omissions in available fields, etc. I wrote this specification (for that's pretty much what it turned out to be) to prove that it's possible to come up with a reasonable way to export all the data currently trapped inside Google Voice accounts.

Like I said, I know this isn't perfect; it's just a starting point. If you think the way I designed some or all of this format was unreasonable, go ahead and tell me. The comment form is there for a reason: That's where you can say, "I think you're wrong; here's why."⁷

Anyway. If I can come up with a data export format that includes most of the information Google has tucked away in a database somewhere, the engineers who work on Google Voice can certainly come up with a format to include every last scrap of data. After all, I'm just an amateur.

Update (06/11): Navarr, in the comments, reminded me that I left out the billing logs, as well as the per-call cost data. Since it would just add another CSV file and a field in call_logs.csv, I'll declare it an omission trivial enough to not bother correcting.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

1. Unfortunately, GrandCentral was notorious among many of us users for "losing" messages from before November 2007, so I have no records of my first year-or-so using the service.
2. Google Page Creator, though discontinued, offers ZIP downloads of the entire site and a redirection facility to keep links from breaking. (I myself have used it, along with an excellent WordPress plugin, to migrate files I uploaded to Google Pages to bits.technobabbl.es, their new home.)
3. Blogger offers an export as well, but so far as I know it can only be imported into another Blogger site.
4. Update (06/11): Thanks to Nathan Brauer for correcting me about SMS-to-email. Sometimes it's dangerous to write blog posts too far in advance: things slip through during the proofing process.
5. It does support a few Google-controlled short numbers; I know of three: 46645, 466453, & 48368
6. DBAD was an essay on the English Wikipedia, formerly known as WP:DICK or WP:DBAD; in the months since I was last really involved in the Wikimedia culture, it was apparently moved to the Meta wiki. Surprised the hell out of me.
7. Obviously, if you're not reading this on the site, you'll need to take an extra step to get a comment form.

Update (2012-02-26): Apparently NET10 now sells SIMs for use with AT&T, T-Mobile, and unlocked GSM phones, if you're willing to pay for the $50/month Unlimited Talk/Text/Data plan. Thanks to Anna for her comment.

NET10 Wireless: No Bills. No Contracts. No Evil...?

Last summer I began using a prepaid cell phone (an LG 300G, the cheapest, most basic model available at my purchase location) from NET10 Wireless, supposedly the "high-usage division" of TracFone. NET10's rates are flat: 10¢ per minute (even if it's actually one second, like any other per-minute charge) and 5¢ per text message in or out.

The phone's been very handy for some important calls and the 5¢ text messaging rate sure beats major carriers' rates of 10¢–25¢ or more per message (on plans without a texting bundle), but I wonder how true the "No Evil" part of the company's motto really is.

Airtime Treadmill

All of NET10's airtime packages come with a fixed number of days after which users are required to reload, or face losing their accumulated minutes (and their number, though that's not a concern for me because of Google Voice). I don't use the phone that much, so I buy the relatively economical 300-minute package for $30+tax every time I need to re-up, making my effective "monthly bill" $15-and-change. The package gives me 60 days to use my 300 minutes, but—and here's the kicker—whether I use them or not, I am forced to renew every sixty days. My low usage means I've accumulated over 1,000 extra minutes since last June—minutes that I would lose if I fail to renew. In order to not waste the money I've spent before, I must continue to renew my service. I suppose I should be thankful they let me keep all my minutes as long as I continue to renew, eh? :-/

The issue here is, the $30 package is the most economical one I could find. Analysis of the other available packages shows that paying every two months is probably the cheapest maintenance option available. There's a $20 package of 200 minutes, but it only lasts for 30 days. Deal breaker. Similarly, there are packages that last much longer (4,000 minutes for $400, two years' service) but with low usage, paying in two-month increments is actually cheaper in the long run:

• 1 yr. = $200
• 60 days × 6 ≈ 1 yr. & $30 × 6 = $180
• $200 − $180 = $20; 5 days can't possibly equal $20
• Similarly: 2 yrs. = $400
• 60 days × 12 ≈ 2 yrs. & $30 × 12 = $360
• $400 − $360 = $40; 10 days can't possibly equal $40

So it is truly cheaper to pay every two months, or use one of the other packages not exceeding 600 minutes. (At the 1,000-minute level, the number of service days earned for each dollar spent goes down due to the extra $10 price increase: $30 = 60 days, $45 = 90 days, $60 = 120 days, $100 = 180 days.)

I wonder about NET10's stated motto: "No bills, no contracts, no evil". Perhaps there are no bills or monthly contracts, but if you're a low-usage customer you must continue to pay into the system even if you never use most of the airtime you're buying. It's a self-perpetuating cycle that draws people along and keeps them paying so they don't lose their previous airtime investments.

As annoying as the practice of placing an expiration date on minutes that users have paid for is, it's a practice that seems to be matched by most prepaid carriers. I spent about two hours researching all the different options at a Wal-Mart store in Colorado Springs and came to the conclusion that NET10's service was the least evil. Other carriers have no expiration but charge a daily access fee on days the phone is used. Others have ridiculous per-minute rates. So NET10 is not "no evil", but I think "less evil" would be pretty accurate.

SMS Attempt Charges

On New Year's Eve, just after the ball dropped on a rebroadcast segment from Times Square, I attempted to send out a New Year text message to Ping.fm for posting to Facebook, Twitter, and so on. Of course, because it was seconds after midnight (Central), the network was so congested that the message didn't go through. My phone displayed "Sending failed" after spending about thirty seconds trying to send out the text. I tried three more times, to no avail. (I gave up and borrowed a few minutes' access to a computer.)

It wasn't a big deal that the message failed. I knew that the network would be busy. But it was a very big deal that my account balance was still debited for the 5¢ texting charge each time. Failed messages apparently counted. (It should be noted that friends using Verizon were texting with no problems. NET10 uses AT&T's network, which often has coverage and service issues.)

I emailed NET10's customer support. After a few days' back-and-forth, they asked me to call their support center so something could be "verified" on my account. I posed my question to the operator. She informed me (through her thick foreign accent) that the software on NET10's phones takes care of managing charges, and that it is the attempt to send a message that results in a charge; the outcome is irrelevant.

The Post Office charges for returned letters, I suppose, so that's not really a violation of communications business practice. But for a company that claims "no evil", I find that policy disturbing. Blowing 20¢ on failed text messages isn't going to break the bank, but it is annoying in principle. I'll just consider whether or not the network is likely to be busy before sending a message, and refrain from doing so if failure is probable.

The real question is, do other "normal" carriers like Verizon do this? With their much higher rates, I would think conventional monthly-contract providers would have significant user backlash if they attempted such a thing. Does that make NET10 more evil than "less evil"?

Hardware Lock-in

NET10 freely admits that their SIM cards and phones are specific to them. I received the following after emailing support to inquire about the possibility of using an unlocked GSM phone (such as the Nexus One) with their service:

If your phone is not manufactured as a NET10, we will not be
able to activate it using NET10 Wireless Prepaid Services. Hence, the
NET10 Wireless service will not be compatible with an unlocked phone.

Furthermore, NET10 SIM cards only work in the phones they were activated
with. Therefore, the SIM cards should not be switched between phones as
this may result in permanently disabling them.

The above was followed by a paragraph encouraging me to check out the selection of available phones at NET10's website. I did so just on a whim, and my expectation of disappointment did not go unwarranted.

NET10's website catalog lists only 16 phones at present, most of which fall into the "basic" category. Two devices have slide-out keyboards and a special text-messaging rate of 3¢ per message, but at $79.99 they are also the most expensive phones on the list. And of course, a lower text messaging rate would just mean I'd use even less of my balance than I do now. (I don't care about a camera, so I won't analyze that, but many of NET10's phones do have cameras.)

I have seen forum threads about using devices like the iPhone with NET10, and I assume the company has also seen them and works to keep users from doing so. Why prevent use of smarter phones on NET10's service? It comes back to software. Phones not manufactured as NET10 devices do not have the software to deduct minutes from a user's account. People using non-NET10 devices with NET10 service get effectively unlimited usage of voice and text communication because the phone is not configured to manage the account balance.

My question then is, why not commission an Android application to enable smartphone compatibility with NET10 and capitalize on the market of users like myself who would want a smartphone without a data plan? I would certainly be happy to restrict my Internet usage to Wi-Fi–enabled areas; having the phone+SMS+Internet functionality on the same device would be awesome if I could do it without paying for an expensive monthly contract from Verizon, AT&T, or T-Mobile.

This doesn't make NET10 evil or not, but it does show that they have lower regard for customer choice than one might think. By operating a no-contract cellular service, they are promoting consumer choice, but they limit consumer choice when they restrict the devices that can be used on their network to a tiny subset of the handsets available on the market. Of course, they're not the only carrier to do this; most U.S. carriers have handsets that only work on their network, and have handsets that will not work on their network no matter how much you plead. But still, it's a limiting factor.

Call & Text Spam

While it's not specifically a NET10 problem, I question the company's willingness—or lack thereof—to help me solve the problems. I received frequent and disruptive nuisance calls to my NET10 number from an underhanded collection agency for four months after activating my NET10 phone, and I continue to receive occasional calls from a second. I've never given out my NET10 number to anyone except my mother, and I made her promise never to call or share it; all communications to me come through Google Voice, and direct calls to my cell phone are by definition not for me. The calls also began the morning after I activated my phone.

Aside from the fact that there was no way a collection agency could have gotten my number that quickly, I also have no creditors that could possibly be seeking collection of old debts. I'm not old enough for that. So I was being woken up at 06:00 MDT by calls from Pennsylvania (placed at 08:00 EDT) intended for someone who had thrown away their prepaid phone number long ago. That sucked.

It did occur to me that I could just answer one of the calls and say the person the agency was looking for no longer owned the number, but even that would have cost ten or twenty cents that didn't need to be used on scumbag sub-legal debt collection agencies. (I looked into the firm that called me all summer. My research indicated that they dredge up debts that have long passed any relevant statutes of limitations and attempt to collect on them for profit. Hence my usage of "sub-legal".)

More recently, I've begun to receive spam SMS from various numbers, some of which are so much longer than 10 digits (or 11; senders are usually presented with the digit '1' prepended for some reason) that I don't think they even exist. Only opened messages are charged for, but NET10 is so focused on making money from text messaging (a trait they unfortunately share with all other U.S. cellular carriers) that the software on my phone displays only the first five characters of incoming messages. That limitation makes determining spam extremely difficult. If I could see more of the message—maybe display "Do you have more than $" instead of just "Do yo", scrolled horizontally like the phone's software does for contents of Notes—I could effectively avoid being charged for spam, but in my cynicism I have come to believe that NET10 doesn't care about spam because it potentially makes them more money.

On multiple occasions I have investigated the possibilities for blocking calls from specific numbers (the collections calls are consistent), or filtering spam from my incoming text messages, to no avail. NET10 cannot block calls, but they would have changed my number for "convenience". No guarantees that the new number wouldn't have more nuisance calls than the old one, of course. And there are no provisions for blocking text messages. The kicker is that a "normal", non-NET10 LG 300G would have the ability to block calls by itself, but that feature was removed from the NET10-compatible software. Grr...

My experience is admittedly limited (as I've only ever gotten one number from NET10) but I've heard from friends and classmates that it's not uncommon for a number from any provider to have problems with calls and texts intended for previous owners. It's not specifically part of NET10's "bad"—rather a con universal to the telecommunications industry—but it was still annoying.

Final Thoughts

Despite the issues, I've been pretty happy with NET10 itself. Even if they charge for failed text messages, require renewals every few months, and refuse to help me block spam, they're still a pretty good deal. At some point, once I establish a steady income, I plan to use up the minutes on my current phone and end its service to switch to something a little better. For now it serves the purpose of keeping me connected on the go when I need to be, and $15 a month isn't bad for a U.S. carrier. I'd move to drop them much sooner if they were more expensive.

Of course, these are my experiences with one phone, a NET10-programmed LG 300G purchased in June 2009. Any of the problems I mentioned, especially those related to features of the software features, might not exist on other models or a later release of the 300G.

Update (06/07): Be sure to check out Speak No Evil's comment below. It has some words of warning that I think are important.

Minor edit at 15:20 to correct erroneous usage of ≅ to ≈

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

He calls for a RESTful design that among other things would globalize message identifiers (rather than changing them the instant a message is moved to a new folder), replace folders with labels (a la Gmail), require the server to handle email search indexes, and make conversations the basic unit of email (instead of individual messages). reMAP would also make handling MIME messages unnecessary; the client could simply call the server with a request for text or HTML message representations without having to deal with parsing the MIME format itself.

I personally am in agreement with his entire proposal. The experiences I've had with IMAP in the past have highlighted shortcomings in a standard that was drafted over 15 years ago. Email has changed a great deal since then, but IMAP has not been revised to accommodate the enhancements made by newer clients and services like Gmail.

If IMAP is to be improved, it's probably appropriate to just completely replace it with something new. If the new system can translate IMAP commands into the equivalent operations in its own protocol, that's even better, because then servers can be upgraded without worries of breaking compatibility with older clients or the need to run server applications for IMAP and reMAP side by side.

There's plenty of discussion going on at the original post and on Hacker News. If, however, you would like to say something here, please don't hesitate.

As a side note, I see that Gabor is using Blogger's FTP publishing option, which will be going away soon. I hope the link will still work when he has to move.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

If you've had much interaction with me regarding computers, no matter what the medium—Twitter, Facebook, email, dinner conversation, small talk during a gathering—I've probably mentioned a service called Dropbox. A few of you have already succumbed to my uncharacteristic marketing tone and signed up, but I thought I'd blog about it and perhaps get more people on board.

I'll start with the reasons I like the service, and then explain why, exactly, I'm doing this a little later.

The site bills itself as an online synchronization and backup solution. I use it mostly for the backup, but that will probably change in the future. After all, it was created by a couple guys who were tired of forgetting their flash drives. It's ironic to note that my current use of Dropbox is to back up my 8GB (soon to be 32GB) SanDisk Cruzer Micro, using a modification contributed by another user.

Dropbox is just plain fun to use, and it has a lot of cross-platform compatibility. It synchronizes files between computers running Windows, Mac OS, or Linux; keeps backup copies online (using Amazon's S³ service—not that I should get too technical); stores revisions when files are changed; and keeps deleted files in case of the inevitable "damn, I shouldn't have deleted that" moment.

The backups, revisions, and deleted files are accessible from any computer with an Internet connection. Files can be added, updated, deleted, and otherwise managed via the website, too, which is great for travel or forgotten files (presentations, school projects, whatever). There is also a mobile website for PDAs and a higher-end version optimized for Android- and iPhone OS–based devices, as well as an iPhone App (there's an app for that™) which of course also works on the iPod Touch.

When naughty Vista workstations have tried to corrupt irreplaceable recordings and other files, Dropbox has restored them (with a little direction from me). Last summer, I bent the connector on my flash drive pretty severely while working on a design project at a poorly arranged Emerson computer desk. It still works, and retracts; but after asking around a bit and hearing that the drive was now likely unreliable, I was motivated to upgrade from the old Dropbox U3 mod—which had trouble on all sorts of non-personal computers—to DropboxPortable—which has worked everywhere so far. (It still won't work at the local public libraries, though. But neither will anything else; they blanket–block EXEs.) If and when my drive decides to give up the ghost, I know Dropbox will be there to give me my drive back just as I had it, as soon as I replace the failed hardware.

I also back up my music collection in Dropbox, which is a great, perfectly legal way to make sure I don't lose any downloaded or ripped MP3s. As it turns out, it's also useful because the device I use as my MP3 player—a Roland Edirol R-09HR—happens to be very picky about file structure. If there's one bit out of place, I get an "Improper Song!" error and can't listen to that file. When this happens to a song that used to play, I've often been able to go back into the previous file versions for that MP3 and load a playable version onto my R-09HR. It's much easier than using a so-called "repair tool" on the file.

There's also the matter of deleted file recovery. I've used the deleted file recovery to reinstate everything from seldom-played music (deleted to free up space) and design research (I just messed up) to irreplaceable recordings from my R-09HR (corrupted by Vista).

The list of times Dropbox has come in handy and/or saved my bacon is endless. If it's saved me so many times in the space of one year, it can surely do you some good.

So do yourself and the great people at Dropbox ("the Dropboxers") a favor and give it a try. I'll bet you won't be disappointed.

Note: Signing up through the links in this post will net you an extra 250MB* of storage in addition to Dropbox's free 2GB plan. That extra storage will stay with you if you decide to upgrade your account. (Disclaimer: You'll also earn me an extra 250MB.*) I tried to work out something special with the Dropbox team via their now-defunct affiliate program, but they stopped the program just before I inquired, so I'm unfortunately rather limited in the benefits I can pass on. Too bad, really; I had in mind something rather spectacular.

* – Please note that you must install the Dropbox application on at least one computer before you or I will receive any additional storage.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

The beauty of using this open system is that if something doesn't work the way I want it to, I am free to simply change it; every plugin is editable from within WordPress' administrative back-end, and the core code is also hackable (though I don't like messing with it because upgrades will break changes). When I discovered that the Wibiya Toolbar (or Wibar) was showing on the mobile version of the website (which is generated by MobilePress, another good plugin), I simply looked in the source of Wibiya's plugin to see how the JavaScript for the toolbar was being inserted.

I found that instead of using the wp_enqueue_script() function as WordPress plugin developers are supposed to do, the Wibiya developers simply used echo to output a <script> tag. That explained why only the JavaScript for the Wibar was loading on the mobile site. Rewriting the plugin to use the official WordPress script-injection method solved the problem.

The original relevant code was:

add_action('get_footer', 'filter_footer');
add_action('admin_menu', 'wibiya_config_page');

function filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        echo '<script src="http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js" type="text/javascript"></script>';
    }
}

I rewrote it just a little bit. My changes were pretty trivial, really. I changed the function name to be namespaced (including the plugin name) just so it'd be less likely to conflict with another plugin. I also switched actions to enable wp_enqueue_script() to work (get_footer is called too late) and added a check—if( !is_admin() )—to keep the toolbar off of admin pages, preserving the original behavior of the function (and the sanity of anyone using the modifications).

In short, wp_enqueue_script() takes five parameters, three of which are optional. The first two are the $handle and the $src, which specify a name for the script and its source address. Then come $deps (dependencies; Wibiya has none, so set to false), $ver (version; also false because it's irrelevant), and $in_footer (set to true because the toolbar should be inserted above the </body> tag).

So with my changes, the code block above becomes:

if( !is_admin() ) {
    add_action('wp_print_scripts', 'wibiya_filter_footer');
}
add_action('admin_menu', 'wibiya_config_page');

function wibiya_filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        wp_enqueue_script( 'wibiyabar', 'http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js', false, false, true );
    }
}

Following some light testing, I submitted an idea to the Wibiya feedback forum, where my update is currently being reviewed by the company. Hopefully, the change will be included in a future version of the Wibiya WordPress plugin. After all, it changes nothing for Wibiya but works wonders for compatibility with other plugins.

I'll just bet that this won't be the last time I'll send a patch to a plugin developer. I enjoy reporting bugs and coming up with fixes too much to not do it.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

Obligatory Rant

Getting away from Blogger is really much harder than it should be. There should be a process to verify with Google that one is not a spammer trying to get free link juice etc. and have the 301 redirects with the Custom Domain feature specifically enabled for the blog one wishes to move. Hackery like what I came across, and what I used, shouldn't be necessary. Blogger should natively support moving away from its platform, even if it might require a little human intervention on Google's end.

It's really too bad that Google is so horrible with customer support. Their products are, generally, really great, but if you run into a problem it had better be something common that others have run into. Your only option, in most cases, is to post in a public support forum and cross your fingers. Fortunately the problems I've encountered have been few, though I am getting increasingly irritated with every issue.

The Premise

Way back in the day, Blogger used to offer 301 Moved Permanently redirects via its Custom Domain feature, even for domains not set to CNAME to ghs.google.com, but I guess spammers were abusing the feature because that ability went away. For a while now, it's been showing an interstitial page to visitors instead of redirecting, warning visitors and crawlers that the site is now redirecting to an untrusted domain. This passes no link juice, and is incredibly inconvenient and unsightly for everyone.

I did a lot of research beginning when I returned from my long summer. In between college applications, family trips, and so on, I performed search after search for methods of migrating away from Blogger to a self-hosted WordPress site. I found a plugin to restore the old Blogger post slugs (to make redirection easier), but every redirect method I came across was in some way outdated and/or broken—until I happened to find Digital Inspiration's method: A Classic Blogger template specially configured to issue canonical links tags, JavaScript redirects, and a big <h1> anchor link to the new site.

Digital Inspiration redirected all traffic to the old site to a special page on the new server, built to handle redirections. A PHP script was offered, but I didn't take that bit. I found a nifty WordPress plugin instead: Redirection by urbangiraffe.com. With two plugins (Redirection and Maintain Blogger Permalinks, mentioned below) and the Digital Inspiration template generator, I was ready to develop my method.

Introduction

Before you do this kind of thing, make sure you run a plugin like the one mentioned here to convert the slugs for posts imported from Blogger to the Blogger format, so they'll match up with the redirects. If you don't, any posts with "small words" ("and", "the", etc.) in the title and posts with lengthy titles will have issues once you switch to the new site.

Also note that you may need to set the number of posts to display on the home page to 1 on Blogger's end. I had a last-minute bug when I implemented this for real that I didn't catch on the test site because I only created one nonsense post. Imagine how frustrating it was to suddenly have seven copies of each <Blogger> section on the page. (Now that I think about it, that's probably why the DI generator kept the homepage stuff out of those sections. But you should change the setting anyway just to be safe.)

Finally, note that, contrary to what a lot of migration guides say, you don't have to set your permalink structure in WordPress to match Blogger's. If you don't want your post URLs to end in .html, they don't have to. Apache .htaccess rewrites and/or the Redirection plugin will be your friend(s). I chose to simply convert the .html into a / but you can pretty much do whatever you want. I've also found that WordPress is capable of redirecting links of the format http://domain.tld/post-slug-here/ to the fully-qualified permalink all by itself, so use that as the target if you want to use a permalink format that doesn't match up with Blogger's. Note: I haven't personally tested this, but given what I know of how WordPress handles things, it should work fine. Use at your own risk, etc. etc., don't blame me if it won't work, etc. etc. But you're welcome to ask for help, of course.

Development

I started with a redirect template generated using Digital Inspiration's generator and set up a Blogger handler in Redirection on the new WordPress site, modifying the newly generated Blogger template accordingly. (DI's generator defaults to /blogger/ which I didn't want; it might eventually conflict with something. I used a more action-oriented /handle-blogger, removing the trailing slash.) The redirect I used was: /handle-blogger\?q\=http\:\/\/voyagerfan5761\.blogspot\.com(\/.+) -> $1

I began developing this solution well before discovering the magic bullet at Digital Inspiration. One of my first steps after installing WordPress was to add mod_rewrite redirects in my .htaccess file so I'd be prepared for redirections from Blogger. Once the handler was in place, I transferred my Apache redirection rules to the Redirection plugin in WordPress:

• Posts: /([0-9]{4})/([0-9]{1,2})/([^/]+)\.html(\?.+)?$ -> /$1/$2/$3/$4
• Categories (labels): /search/label/(.+)(\?.+)?$ -> /category/$1/$2⁺
• Monthly archives: /(\d{4})_(\d{2})_\d{2}_archive\.html(\?.+)?$ -> /$1/$2/$3

⁺ – Still need to figure out how to transform this to lowercase and change %20s to hyphens.

Update (02/14): I discovered that query strings killed the redirects and led to 404s. I changed $ to (\?.+)?$ at the end of each regex as well as added extra corresponding backreferences ($4 for posts, $2 for categories/labels, and $3 for monthly archives) to fix it. All query strings are kept, even if they're meaningless on the new site, but otherwise it would be a pain to whitelist only the useful ones. I'll update again with blacklisted query parameters if I discover a Blogger query parameter that breaks something in WordPress.

Once I had all the handling pieces in place on the new site, I tested the Blogger template on a test blog. During my testing, I found room for improvement. For instance, I read in my research that a meta refresh tag, used with a delay of 0, is often treated as a 301 redirect by search engines. I added refresh tags to the template.

I also found that Blogger tries to thwart JavaScript calls to window.location.href by placing script tags on the line following the call and invalidating the entire block. I defeated that by placing a multi-line comment starter after the semicolon, wrapping the block in <![CDATA[...]]>, and creatively faking out Blogger. It still inserts the extra tags, but they don't harm anything because I used trickery to force Blogger to place them inside a comment block (where they're just ignored).

In case future changes to Blogger break the template—and I'm sure that Google will do something to break my setup eventually—I added a link to my new contact page for users to tell me if it's not redirecting.

The template does everything I need it to do. With the Redirection plugin, I didn't need to use the PHP script provided in the Digital Inspiration post. I should also get better results from the migration because of the extra work I put into my template; feel free to get a copy for yourself. If you use it, please leave the existing comment block at the top intact. Both the original authors at Digital Inspiration and myself will appreciate it. I also plan to share my improvements back to DI.

Conclusion

Satisfied with my testing and confident of the results, I implemented the template on my real old Blogger site a couple days ago, where it seems to have been chugging along nicely ever since. If it breaks, and I don't notice, I'm sure someone will take the time to use the contact link I added and let me know. The link might cause a few issues with search crawlers, but I think I'm OK with it. Misdirected link juice is better than broken functionality.

Of course, this is the technique that worked for me. Like all the others I found, I'm sure this one too will become oudated and/or broken with time. But for now, it seems to be the best method for escaping the clutches of Blogger.

Update (01/23): A reader pointed out in the comments that IE6 might not follow the redirect. If your site has a significant fraction of readers using IE6, keep that in mind. I won't worry about it for my site just because most of you use something more recent.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761

You know, there's a certain satisfaction to this. I've been wanting to ditch Blogger for years, ever since I discovered WordPress. And I finally did. I'll consider the completion of this migration to be the fulfillment of my unstated New Year's resolution.

Thanks to the generosity of one of my Twitter contacts, @Navarr, I now have a self-hosted (er, friend-hosted) WordPress blog. He offered to host my blog after seeing me complain a lot about things I couldn't do under Blogger. Eventually I bit the bullet and bought a domain name near the end of October. The full story is available (once I finish revising it—oh, hell, that'll never happen, so just read it now and keep checking back ) on the about page. Now there's something I couldn't do with Blogger: A static page! (Update (01/20): Blogger just launched Pages on Blogger In Draft. Little late, guys.)

As an advance warning to my feed subscribers who've become used to visiting this site at voyagerfan5761.blogspot.com, I'm announcing that all pages on that domain will begin redirecting to a new WordPress site I set up at technobabbl.es soon. In fact, I'll probably have that set up by the time this post is published. Feed and email subscriptions, which are run through FeedBurner, should be unaffected by all this reconfiguration; the most you might experience are some issues with duplicate items being fed or mailed to you when the switch is made. Since I switched the feed a few weeks ago, all of those humps should be done with.

The search for a redirection solution was pretty tedious. Because I want to leave Blogger's hosting behind, the Custom Domain feature wasn't an option. Since I need the DNS records for technobabbl.es to point to DreamHost instead of Google, Blogger wouldn't issue 301 Moved Permanently headers; instead, it would show interstitial "untrusted domain" warning pages (returning 200 OK, creating a horrible search engine situation) that don't redirect users and don't pass link juice on to the new site.

I'd just 301-redirect the whole site if I had any way of doing so. Since Blogger doesn't let me do that, I either have to start from scratch search engine– and backlink–wise or find a more creative solution. Thanks to Digital Inspiration for a great post on migrating and Blogger redirection template generator, and thanks to John Godley of UrbanGiraffe.com for the Redirection WordPress plugin.

It took me a while to find this combination, but my pre-implementation testing indicates that it should be pretty perfect. I've also extended the Digital Inspiration template to issue meta refresh redirects in addition to JavaScript, anchor link, and canonical link tags, which should make it even more search-engine friendly. I could have just used redirects in my Apache .htaccess file, but Redirection will log the redirects for me, so I can keep track of the traffic coming in from the old site. For a more complete explanation of what tools I used for the migration, watch for a new how-to post.

Even with the redirection, I would like to ask all of you to update your bookmarks, and anyone who's linked to me should please edit those links. Redirects are fine, but it's better to not make crawlers (and users) jump through those kinds of hoops. I'd like to try and keep the experience as clean as possible.

Speaking of cleanliness, there were other side-effects of importing everything from Blogger. First, my feed footer was included in every post. So that's something for which I should keep an eye out. I'll get rid of all those pesky footers eventually. I only have to get them out of 500 posts. Second, Blogger uses stupid formatting tags (lots of <span style="font-weight: bold;">...</span> and <span style="font-style: italic;">...</span>) instead of the semantically correct, shorter <strong> and <em>, and it uses more <span> tags to size the text up for headers instead of creating <h_> tags. More slow cleanup work for me to do. Just have to fix a few posts at a time. I also need to do something with my Picasa-hosted images; rumor has it that they'll disappear if I stay away from Blogger too long.

Now I'm going to stop rambling about all the work I have to do on the site. Thanks for reading, everyone. I hope you'll weather any transition turbulence and follow me to my new site, where I've been working on a few hefty new posts to make up for the distinct lack of blogging in the last year.

Originally published at Technobabbles
Content copyright © 2006-2012 by dgw / voyagerfan5761