Babes in userland

The database service rolled out by Amazon last week will prove to be a clunker, despite all the praise it's received. It throws out three decades of experience with SQL and relational databases and demands developers learn more syntax to get less accomplished. It's just cover fire, and pretty intense cover fire at that, demanding a rewrite of the core of your Web application, the model layer.



I don't think Amazon is ill-intentioned, I just think the company made the mistake of thinking a system that works well for Amazon will be useful for the rest of us. The success of the ingenious S3 and EC2 platforms left the company with a surplus of hubris, and God bless them for launching a failure in a market Google and Microsoft don't even know exists. You don't build a market without some stumbles, and Amazon's success in assembling an Internet operating system is stellar so far.



People used to say Google was building an Internet Operating System, but as it turns out they were building Office for the Web. Which is fine. But Amazon is doing something much more empowering, and in the end I think they will have created more value outside their walls than Google ever did, even though they probably won't reap Google-scale profits.



Amazon's success is no small feat. Microsoft has been talking about Web services for years but in the end the two definitions most people heard were "a single sign-on system owned by Microsoft" and "a complicated message interchange system designed to sell copies of Windows Server." Google has crippled virtually every API they have launched. Apple and Yahoo have been focused on a Hollywood vision of the Net (both companies were run by studio chiefs for most of this decade) and are effectively out of this particular business entirely, by choice.



As it turns out, Amazon is not really in the business by choice either. It is in it by necessity. Yes, Amazon surely put some real work into turning S3 and EC2 from internal tools into public utilities. But it built those tools because it needed them -- reliable systems built on easy-to-grok open standards, capable of scaling quickly, just the sort of thing for a company as large and busy as Amazon. As it turns out, once you've built that sort of tool, you're more than halfway toward building something for the entire world.



Again: Amazon built some Web services because it needed them, then realized the rest of us would need them.



Amazon is a company that sells books and a bajillion other things over the Internet. That's what it does. Retail. It is not a software company, not even today, despite EC2 and S3, despite the fact that it has had kick-ass coders since its launched, despite what it may yet become.



Amazon is a user selling the software it made for itself.



This is important. This is new.



Microsoft and Google have always dog-fooded their own software, but that's the exception that proves the rule, which is this: Software companies make software to solve other peoples' problems.



And software companies never understand the problems they are solving as well as they understand the problem of making software.



So now their customers are taking matters into their own hands and building their own software.



This interests me personally because the same thing is happening to my industry, the news media. A reporter will never understand a beat as well as his sources and readers. A chump journalist at a tech magazine or business journal will never be able to write about software as well as Joel Spolsky or Philip Greenspun, who actually make software and actually run businesses. My only consolation is that most programmers -- and most people in any domain -- do not have half the writing talent of a Spolsky or Greenspun, a Graham or Shirky, a Yegge or Wall.



And so it is with software. Most software buyers are utterly lost at the sight of a command line, much less a compilation error.



But we're starting to see some cool users swimming against the tide. Call them babes in userland. An Amazon here. An Adrian Holovaty there. And, back in ancient Web history, a now-defunct online magazine launching the software that served you this page.



Then there are the chumps like me, learning scripting languages and server administration in my spare time, building a random collection of tools, and fervently hoping that Clary Shirky was right.

Reconsider the bonds in your 401k

Today I logged in to my 401k account, which I hadn't checked for about a year.



The returns are fine, but when I drilled down into my bond fund on a whim, I was horrified:





See that there "MBS Passthrough," where I have 34 percent of my bond money? Those are Mortgage Backed Securities. And CMBS? That means "Commercial Mortgage-Backed Securities." And CMO? "Collateralized Mortgage Obligations."



In total, nearly 60 percent of my bond money is exposed to the mortgage market. The CMBS and CMO categories are the most worrisome to me, because as I have written and blogged and read (and read and read and read), huge chunks of those markets have turned illiquid. In other words, it is hard to sell these securities, because it is hard to find buyers.



And it is hard to find buyers because people realize the ratings assigned to many bonds by Moody's, S&P and Finch were simply wrong -- there was far more risk hiding in certain types of debt security than was reflected in the ratings.



The short version: the bond market is broken.



And now the government is expected to intervene.



Do you want to be invested in a broken market where, when you go to sell your bonds, it may be impossible to find a buyer? Do you want to be in a market where the government is about to rewrite all the rules?



When you opted to put some of your 401k in bonds, did you do so to increase the risk and volatility in your portfolio, or did you have the opposite in mind?



For most people, the bond portion of the 401k is intended to provide lower risk and volatility than the stock market, along with diversification -- returns not correlated with the stock market. Heavy exposure to mortgage backed securities undermines these goals.



Your bond fund probably looks a lot like mine, since my bond fund is designed to mimmick the entire bond market.



Check your 401k and reevaluate your bond holdings and whether to reduce them.



I personally sold half my bonds, reducing bonds to 15 percent of my 401k.

Crappy Apple design, first in a series (no doubt)

I'm just not even going to say anything.

Best. Title. For a discussion thread. On a literary website. Ever.

Best. Email. Ever. (Until the next one.)

Crappy GMail design

Continuing the Weekend of Inane Web Design, GMail has decided email it sends itself must be spam.



Backstory: If you want to be able to send email using an alternate email address in GMail, GMail first sends an email to the alternate address with a link to verify you own the account.





I did this earlier today. My verification email would be coming straight to my GMail account, which receives all messages sent to the alternate address.



I kept waiting, and waiting, and the verification email never came. After about 10 minutes, I checked my spam folder. Guess what GMail thinks is spam? GMail's own administrative emails. Click for the larger version:





I went ahead and opened the message and clicked "Not Spam." That way, you know, they might eventually figure out their own email is not spam, though the miracle of Bayesian technology.

Crappy Linksys design

Let's say you're trying to join a WEP-encrypted wireless network (despite the security issues), and you need the password in hex format, since plain text passwords often fail to work.



So the dude who runs the network goes to look up the hex password, and sees the following when he connects to his Linksys router in his Web browser:





Oh, cool. The hex password is "6D68E02B33F2BCACC".



But, gee, why can't my MacBook connect to the wireless network? Why isn't the password working?



Because that wasn't really the password. The fool who designed the interface for my Linksys router made the hex password field way too short to show the password!



There are nine password characters hidden by the end of the password field. Here's what the password field would look like if it were designed properly:







The whole hex password is visible here.



This design flaw bit me at Thanksgiving, when our guest could not connect to the network even after I pulled up the hex password via our Linksys router interface. And I suspect it is behind some of the online wireless questions involving Linksys routers and Macs that no one can resolve.



Linksys' design is especially stupid because every single 128-bit (really 104-bit, but whatever) hex password ever used for any WEP connection is the same length: 26 characters. It's just the way the WEP standard works. And Linksys knows this, which is why the HTML form field for the hex password limits you to 26 characters:



Once you're aware of this issue, it is possible to see the nine hidden characters by carefully manipulating the mouse in the Linksys hex password field and scrolling to the right. But you shouldn't have to do this. The password field should be properly designed to begin with.