Google+ Pulls Bait-and-Switch With Account Transfer/Merge Tool

I'm a fairly frequent user of Google+ and even a fairly early adopter; my very first Gmail-based account was added to Google+ in July 2011, just after the service opened its doors to public beta. I created another Google+ account a few months later to try to segregate posts between users, before newer features like hashtags and "volume sliders" existed. And once Google+ was opened to Google Apps users, I took the opportunity to start posting from my (primary) Apps-based account. Confusing, but I had hope that eventually I would be able to merge my accounts as promised in October 2011.

It's safe to say that the earlier accounts have a decent number of followers (circlers) and still get passed around in shared circles today. Of course, I was quite excited about the Google+ account (actually, circle) transfer tool once it was finally announced in July 2012, and took advantage of it to merge the middle account to my current one. The important part to me was that it brought all those who had me circled — my "circlers" — from the old account to the current one. Reconnecting is fun!

That meant I had two accounts remaining: the very first one, and my current Apps one. No problem, I thought; I'd be able to merge the very early account to it as well, by using the transfer tool a second time, in six months — as widely reported by tech press and blogs (ahem), and as documented in Google's own help file for the process as recently as February 13, 2013, the date of this post (click these screenshots to enlarge):

"You won't be able to use this tool with these accounts again for 6 months."

My first transfer completed on July 21, 2012, and I waited until February 1, 2013, a bit more than six months, to try to merge the circlers from the other pre-Apps account. I went through the process, and saw this during the transfer process:

"You can transfer your connections to or from a Google Account only once every 6 months."

Well, great, it has been more than six months; let's do this! I got to the final screen of the process, and...

"...you won't be able to use this tool with these accounts again for 6 months..."
"The target account migrated already and cannot migrate again right now."

...uh, what? OK, I thought, let's give it some time... I waited a while, and tried it again on February 11. Still no go; still the same error message. What could possibly be wrong here?

I posted to Google+ asking for someone behind the Google+ Help account to investigate. The response was as follows; emphasis added by me:

"Apologies for the confusion - accounts that have participated in a migration previously are unable to migrate ever again. We'll take steps to ensure this is clearly communicated during circle migration, as we can see that some resources suggest that this restriction is lifted after 6 months."

Where "some resources" refers to the initial announcement of the transfer tool, press coverage of the announcement, documentation for the tool, and even the screens guiding the user through the tool itself. That is, everything ever posted that said a word about whether this tool could be used again. Those "some resources". There is nothing on the whole Web that I can find suggesting that the Google+ circle transfer tool is a one-shot deal... well, until the response above.

I followed-up to my original Google+ post explaining this as new information, which contradicted all public communication about the transfer tool. Was this an oversight when implementing the tool? A six-month lapse in judgment? Or a change in policy that conveniently wasn't mentioned until someone actually tried to use the transfer tool a second time? (I certainly hope not the last option.)

Two days later, I still haven't heard anything else from the usual suspects who tend to handle this sort of community relations. That's odd, because real bugs tend to get pretty quick response from some of the good folks in G+ management and development; they're usually quite a pleasure to interact with.

To say the least, I'm disappointed. I now have two Google+ accounts, one an orphan that will never re-connect itself to the place I actually post content and comment on others' posts. There's a lot of early adopters connected to that orphaned account, and while I may have them circled in my current account, I can't see their non-public posts in my primary account, as they don't have the "real me" circled.

I can still hope that I'll be able to update this post, to say that Google actually followed through on their original promise, rather than broke it permanently. Time will tell.

[Update 18-Feb: The plot thickens! In an not-quite-related post, one of the G+ developers said "[Todd] ran into issues with a second merge and we're working on fixing that." See, I told you I was hopeful...!]

How priorities have changed: Google Apps Standard is no more

As described in a Google Enterprise blog post yesterday:

When we launched the premium business version we kept our free, basic version as well. Both businesses and individuals signed up for this version, but time has shown that in practice, the experience isn't quite right for either group. Businesses quickly outgrow the basic version and want things like 24/7 customer support and larger inboxes. Similarly, consumers often have to wait to get new features while we make them business-ready.

With this in mind, we’ve decided to make things very straightforward. Starting today for all new customers:

• Individuals wishing to use Google’s web apps like Gmail and Google Drive should create a free personal Google Account, which provides a seamless experience across all of our web services on any device.
• For Businesses, instead of two versions, there will be one. Companies of all sizes will sign up for our premium version, Google Apps for Business, which includes 24/7 phone support for any issue, a 25GB inbox, and a 99.9% uptime guarantee with no scheduled downtime. Pricing is still $50 per user, per year.

This is unfortunate news. In 2009, I set up a Google Apps Standard account for an informal, not-for-profit advocacy group of eight people on a shoestring budget (getting lawyers to established 501(c)(3) tax exempt status was not even on the table), and Google Apps Standard fit the bill perfectly: easy in-domain collaboration using the standard Google applications suite.

Two and a half years ago, a different Google Enterprise Blog post said this:

We've heard some questions about why the link to Google Apps Standard Edition disappeared from the Enterprise Apps home page, so we wanted to share the answer. As we explored a few design changes to the page, the link to Standard Edition was inadvertently dropped, although the free version of Apps was, as always, available [...]

We have no intention of eliminating Standard Edition, and we apologize for any confusion.

My, how the mighty's priorities have changed. I used to recommend Google Apps to fledgling groups that promote social awareness or political causes, or to families who want easy control over the accounts in their domain name, but no more. It's a sad day for innovation and convenience.

Klout is Bullshit (and you're falling for it!)

DISCLAIMER:
The title of this post, and all following content — not including opinions of any third parties reproduced here — are solely my opinion, and any legal stance should be taken in that light. (I have to put this here; while I'd love to see Klout's proprietary scheme exposed in open court to fizzle and expire, I don't personally have venture capital funding to cover the legal costs of defending any potential libel suit.)

There are two kinds of fools: one says, "This is old, therefore it is good"; the other says, "This is new, therefore it is better."

— William Ralph Inge

So, yesterday, Klout was "trending" on Google+. While I did consider this fact to be a demonstration of recursive inanity, I felt it was time for someone to call out Klout publicly for peddling snake oil.

As part of this buzz yesterday, WIRED ran a shameless ass-kiss of an article masquerading as journalism, claiming that employers are using Klout scores to make hiring decisions, and businesses are treating customers better or worse based on their scores. This is tantamount to making Klout a credit bureau — something that is normally regulated by law in the US, mind you — and is a trend fad that should be nipped in the bud, sooner than immediately. So I pulled up Blogger and started this post.

For those who don't yet know, Klout is a strange startup claiming to track social media users and associate real people with their levels of interaction and "influence" on other people. It captures topics on which someone is "influential", and assigns a score up to 100 based on the amount that a person's content garners comments/responses, reshares, and other metrics that are in a cauldron of black magic.

Klout is also one of the biggest scams on the Internet right now.

Eevee dissects PHP to its ungodly entrails

This is making the rounds. I don't often reblog (hell, I don't often blog, and I need to fix that), but Eevee's article about the failings of PHP is so full of well-reasoned win that it should be required reading for anyone even contemplating the use of PHP in a production-grade project.

As expected, apologists on Reddit and Hacker News have run to the defense of a language that really has no defense in the modern world, basically parroting the same arguments that Eevee already preempted in the blog post. Anyway, the comparison of PHP to a set of bizarrely quirky tools is, in my mind, the best bit of all:

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

I have to say that I agree with pretty much everything in Eevee's post. There are perhaps a dozen minor factual inaccuracies in the work done to compile the post, but they are far outweighed by factual reality of the rest.

Now, there's plenty that I dislike about all languages, and even entire language families: static/dynamic typing, functional/procedural style all have their strengths and weaknesses. These are tools for a job, and the job sometimes has different shapes and sizes. So I can see myself using any of C, Java, Perl, Scala, Ruby, C++, Python, or even C# (in spite of my dislike of Microsoft products) or a Lisp descendant if needed. All of these languages contain aspects that I truly dislike and wish were fixed A Long Time Ago, but they all have solid enough foundations to be useful in different situations.

I have yet to come up with a cohesive argument that favors PHP with the exception of "it's easy to install to an Apache webserver and there's lots of off-the-shelf stuff written in it". Unless you don't have oodles of memory to spare and have seen the light in a modern, threaded Apache, in which case you have to go through weird incantations for FastCGI configuration. Or unless you don't want to run Apache, and have to go through other weird config incantations. Or unless an OS packaging system doesn't build a given data access module into the PHP binary. Or unless you are afraid of weird security holes (and often the same ones every time!) that seem to crop up in all that off-the-shelf software at a rate that rivals the Win32 API, leading to a desire to sandbox the PHP code from the rest of a server.

Screw it. I can't come up with any coherent reason in favor of using PHP today. My enthusiasm stops at "it's barely good enough to run legacy applications"... an argument that should never be used for new software development.


(p.s. Hosting companies, are you listening? It's time to tout other supported programming languages for your services as selling points. Encourage new programmers to try something else. Your servers and sysadmins will thank you.)

Scala Pitfalls: Trait Bloat

Those of you following the active development of the Scala programming language may have noticed interesting Subversion commits today (r25962-25964) claiming to reduce the size of scala-library.jar by about 1.5MB. That's no small amount for a library that was creeping up on 9MB as of Scala 2.9.x, yet zero functionality was lost. So I bet you're wondering: how was this possible, and why is it important?

Friends of mine know that I've been really picking up on Scala lately because, as a person who comes from a very heavy imperative/object-oriented programming background, I find it to be a good hybrid language that offers both clean OO and functional programming constructs. Try as I might, I doubt I'll ever bring myself to appreciate the Lisp-derived languages, so when weighing Scala vs., for instance, Clojure, I found the superior OO support in Scala to be the aspect that put it over the top.

Google Cr-48 Ubuntu Adventures, part 2: Kubuntu Oneiric

As I alluded to in my previous post about installing vanilla Ubuntu Oneiric onto the Google Cr-48, Canonical's new Unity desktop system has annoyed me to the point of exhaustion. Rather than wear grooves into my Cr-48's trackpad for all the pointer motion required to use window menus, I've trashed and reinstalled the system from scratch with Kubuntu, the derivative distribution of Ubuntu focused on using the K Desktop Environment as the primary desktop UI system.

To be fair, I considered the up-and-comer Lubuntu, which also values the simplicity principle like Chrome OS. However, I first wanted to try something I was fairly confident would be stable on this system, and have the network management support necessary to get 3G working. I may try Lubuntu from a "live USB stick" later; if so, I'll post about that too.

KDE is an old friend. I used to work on NetBSD, another Unix-like OS, which had the usual bland X11 GUI and its applications available. When KDE 2 was available for NetBSD in 2001, and I took the time to compile it and try it out, I immediately switched to it as my desktop UI for a 486-based PC and a Commodore Amiga. While slow and memory-hungry for the time — previous X11 applications were generally written in plain C, whereas KDE heavily uses C++ — it still proved speedy in comparison to other then-available OS's (...I'm giving Redmond the evil eye here).

Prior to KDE, most X Window System UIs were based on a loose collection of applications and a window manager. What K brought to the table was integration: the desktop system included a uniform widget library, background services to streamline communication between applications, tools to manipulate system menus automatically, and graphical system management applications. It was, in my opinion, the first "grown-up" GUI for modern Unix systems, promising to bring Unix within the reach of Microsoft Windows and Mac OS users. (CDE promised similar goals, but didn't really deliver on anything besides a uniform widget toolkit.)

It had its share of problems, though. KDE is based on the Qt widget library, which originally had its own software license that made it difficult to integrate with applications written to use the GNU license; this led a few developers to start working on a competitor, GNOME. KDE also fell victim to feature bloat, a concept that applications like Google Chrome, and entire environments like GNOME and Chrome/Chromium OS, have sought to reverse by simplifying the user interface, and removing optional settings. While I may have recommended KDE to a new Unix user in the mid-2000s because of its similarity to other operating system UIs at the time, the simplicity approach has a lot of appeal today.

Fast-forward to today, and I find myself writing this post from a KDE-based system once again: Kubuntu Oneiric, which as of this writing uses KDE 4.7.1. The traditional desktop metaphor is alive and well, though it certainly has more visual effects these days. And while I find it somewhat nostalgic to go through the system settings to tweak small things to the way I like them, I have to admit that it is still a settings-heavy system, love or hate it.

But I digress; it's time to move on to the real substance of this post.

Google Cr-48: Installing Ubuntu Oneiric, and 3G support

So those of you who have followed my Chrome OS/Chromium OS adventures may be disappointed to find out that not only have I stopped producing builds, I've abandoned the Chromium OS project — at least for now. I still believe in the principles behind CrOS, but as it hasn't been working on my hardware for months, I was forced to choose another option.

Because of persistent wireless issues ever since Chrome OS 0.12 was released, which could have been fixed long ago simply by updating the compat-wireless ath9k driver, I reflashed the BIOS — taking care to save a backup copy of the original, should I want to try Chrome OS again — and installed the upcoming Ubuntu Oneiric Ocelot (11.10 Beta 2), completely overwriting the disk (including the partition table).

If you choose to follow in these footsteps, be aware that this completely blows away Chrome OS; it doesn't run in a dual-boot or parallel configuration. It's possible to go back, but how to do so is not covered here; you will need to reflash the BIOS to the original, then use a Chrome OS recovery disk.

I should also be very clear that Ubuntu 11.10 is a pre-release OS and is bound to have bugs. So tread at your own risk. It's due out next month (actually, in a couple weeks), but as with any newly released software, expect something to break in unexpected ways.

Finally, before describing what I did, note that this isn't for the light-hearted. If you want to try this, I hope you've done at least one install of a Unix-like OS (Linux, BSD, etc.) in the past.