Stay tuned here for more entirely personal posts.  If you’re looking for technical / professional goodness, you might want to look at my other blog.

Whenever I have the time, I’ll have to move this blog to something else. In the meantime, Google is remove a feature that has been with Blogger since the beginning. They claim that keeping this particular feature is holding them back. I can’t help but think that they’re just lazy or perhaps being evil.

What feature is this you ask? It’s called SFTP. Basically, it uses a secure connection to upload my blog to my server. When I post, Google renders all of the pages and uploads static copies of them to my server. Why is this important? Two reasons.

First, when someone uses my blog, my server sends them a file. That’s it. No ifs, ands, or buts. This is great because, when I get tons of traffic, my site stays up. The more work my server has to do, the less likely my page is to stay up. This doesn’t matter so much for Google, as they can plausibly claim that whatever they will put together can take a hurricane-force storm of traffic. Still, when it does go down (and Google has outages more frequently than most realize), I will have absolutely no introspection as to why. When someone can’t get to my blog, I’ll have no way to figure out what’s going on. This leads me to the next issue.

Second, this feature was the only way to effectively integrate Blogger into another website. Almost any blog worth reading is part of a larger website. I might have code posted if I’m a programmer. I might have web tools if I’m a business. I might have special access for clients / investors / employees. As of this switch, these sites are dead in the water. The only way to integrate the blog into your site either involves rickety forwarding setups, or doing your best to make Google’s site LOOK like it’s part of yours, without it actually being so.

That’s primarily why I used Blogger. Not only did I use it for that reason, I cannot automatically migrate to their new setup without breaking things–precisely because I used it this way.

People have had stuff running this way for literally a decade. Tons of small businesses and consultants (and big businesses for that matter) were just given eight weeks to track down a consultant and pay them to basically re-engineer their entire site. Bad show Google. Bad show.

So, this is probably the last post here until I figure this out. I doubt I have too many readers of this particular blog, but it’ll be sad to see it go. All of the content will still be here (ironically, another useful property of SFTP that will never people possible with Blogger again).

Good night, and good luck.

If you’re one of my technical readers, feel free to head over and read some of my new posts.

On Thursday, a distributed denial-of-service attack disrupted three major US social network sites.

No solid evidence has been released as to why this may have happened or if the above two things are related. That means it’s time for a conspiracy theory!

Maybe this wasn’t automated, but it’s an insidious idea. What if this was automated retribution for attacking the botnets’ C&C; infrastructure? Think of it as a bold new stride in mutually-assured-destruction between the security community and cyber-criminals.

Would security professionals (or the people at ISPs that work with them) be less likely to help cooperatively police the internet if they were going to be implicated in the next major disruption of public services? I bet so. Even if the professionals resist the coercion, it’s hard to imagine that their bosses are immune, and there’s no motivation like a disappearing paycheck.

I can only imagine Gary Oldman being cast as the disgruntled Latvian cyber-criminal. Bruce Willis plays the FBI agent? Or maybe Harrison Ford if this becomes the next Clancy novel. Don Cheadle as Barack Obama? The mind reels at the Hollywood possibilities.

If this is related, I just hope that it doesn’t become more fodder for legitimizing government control over the Internet “because it needs it”. Government law enforcement support might be helpful, but not invasive manipulation.

If you have a technical bent, read this whole article. It’s about a guy building electronic brains, and it’s fascinating. If you just want the salty-sweet juxtaposition, just read the first question on the third page here.

Here’s an example. Clearly, this is horribly wrong. Sun refuses to fix a bug because people have worked around it, thus it must be maintained–to the detriment of all programmers to follow. This gradual growth of cruft is one thing that has driven people away from Java.

Why is this important to me? Well, it’s mostly important because I think that it prevents good comparisons of technologies. It sends the wrong message when people move to Rails because Java is riddled with unnecessary complexity and buggy libraries. While it is some compliment that it says that Ruby is easy to use compared to Java, it doesn’t emphasize what makes Ruby such a different way of doing things.

Real improvements like reduction in code through expressiveness, flexible extension of types, the block syntax, et cetera get lost in the shuffle. What’s worse, it doesn’t send the message that Ruby can be used to solve industrial problems. The eternal mantra of the Ruby naysayers–that it doesn’t scale–is at least partially reinforced when people flock to it for simple projects.

For those who have built scalable applications on top of Ruby, this is laughable. Yet the point remains that dynamic languages in general and Ruby in particular have a great deal of value to deliver to real, serious software development. Even though it’s fun to play with, it’s not just a toy.

Similarly, when people legitimately work on projects like JRuby that work gets ignored by people who just don’t want to deal with the cruft. While that’s a great reason to avoid a class-library, it’s a horrible way to allocate our resources as an industry. In a world where languages live or die by their “standard libraries”, this just makes people’s lives harder and guarantees that we spend more energy to move the same distance.

I can only hope that Oracle’s recent acquisition of Sun might change this attitude and position Java as a more useful technology. It’s a shame to see all of the hard work people have put into the JVM be squandered because some people are afraid to break an API. If anything, this could have been turned into an opportunity for Java to offer versioned APIs, but instead it was met with duplication of functionality and degradation of the clarity of their class library.

I feel that this puts work on Rails 3 in an important light. The Merb project was about a lot of things, but one of its most important aspects was that the people behind it continued the march towards a better product. The Rails core team did a great thing by welcoming the best of Merb into Rails. It’s letting us build a better future, and it’s showing that we can maintain compatibility and still move forward.

We just need to always be mindful that the day that we stop improving Rails is the day that someone starts writing its replacement. More than anything, we need to insist that there is no excuse for not fixing a bug.

By the time TCP (and indeed the whole IP stack) has made it to my desktop, it had been on a long journey. MacOSX’s network has a storied pedigree that goes back deep into the iterations of the original BSD Unix. There is, as they say, heavy voodoo.

Today I hit a corner case that only made sense after some pretty serious debugging. I’m sharing it here with the hopes that it may save you the headache.

The backbone of the Internet is designed to just have these routes disappear for a while. You get a few ICMP messages back if you’re very lucky. Otherwise, your packets might just disappear.

One of the nice features of TCP is that it’s incredibly resilient to network links just disappearing. This is no problem for it. In fact, if you’re not sending any traffic, you may not even notice that you’re down. Failures being invisible is a nice feature when you’re not doing anything.

That said, there are protocols that really want to know when they’re down. XMPP is one of them. For protocols like XMPP, there is a pretty standard procedure of having some sort of “keep-alive” data that you occasionally send. Since XMPP data streams are just XML documents, most XMPP implementations just send a few whitespace bytes in between stanzas when idle.

Today, I was debugging an XMPP connection over a 3G modem. This manifests itself under a ppp0 link in MacOSX. While I wasn’t thinking about it, I walked around with my laptop. One spot caused the phone connection to lose signal and it failed. When I noticed, I reconnected the modem. This provoked some very interesting behavior (or rather lack of behavior) from the BSD IP stack.

Normally, when some fundamental aspect of network changes, there is some device that will interrupt your connection. For example, if my XMPP server had lost power, when it recovered the keepalive packets would have triggered a TCP reset, which breaks the connection. Similarly, if I remove an IP address from a Linux machine, connections on that IP are interrupted. It just so happens that in this case, the IP stack did NOT break the connections.

In fact, it just silently ate any data that the connections attempted to send. So the keepalives completely failed to kill the dead connection. It took almost fifteen minutes until some sort of behavior that caused the IP stack to notice that the connection should be killed.

It took a while to track down what was happening, but apparently the connections were maintained (so says netstat) and the sent packets just disappeared without any sort of sending error! Very weird behavior triggered by an odd corner case. I’ve also discovered that this appears to also happen when you close your laptop and go to another wireless access point. This is ugly for my use-case, as I want the agent on the laptop to reconnect when it has a new address. If anyone has a good way to detect this in a portable way (i.e. not plugging into Apple’s NetKit watchers), please let me know.

While I find this mildly annoying, I have to admit that I can’t fault TCP. If the packets are just disappearing, the best behavior is to just resend and keep waiting for the connection to come back up for a reasonably long time out. This is exactly what happened. Instead, I hope that Apple will eventually do what Linux does and push an error into the socket when it tries to send from an address that isn’t valid for that machine anymore.