Yesterday, I ventured down to Google's campus for the celebration of the fifth anniversary of the launching of Google Code. It was a relatively eye-opening experience, as they pointed out a lot of things about their hosting system that I hadn't known previously. For example, while the site launched with four projects and two APIs, it's now hosting over 905 projects and 60 APIs. And that's just Google's stuff. End users have uploaded over 300,000 of their own projects to the site, and 26,000 of those were updated in the last month. 

Java is the most popular language used in Google Code projects, with PHP and Python both close behind. What is interesting here is that C++ and C# are dead even at 4% of the overall  projects. There are over 4000 Android applications in Google Code, and over 1000 Eclipse projects. The band, Radiohead, used the service to host its music so that fans could remix their songs, and the source code to the Apollo 11 guidance computer is hosted there as well.

But those are just numbers. What was really interesting to me was the way the Google folks took credit for simplifying online project hosting. And you know what, they're right: they did push open source hosting sites to simplify by offering a streamlined alternative.

How did Google streamline Google Code? For one thing, issue tracking was refined to the same simple interface you'd get when posting a comment to a Web site. Rather than ask bug submitters to post up huge amounts of information and click tons of radio buttons, as is the case in Bugzilla, the Google Code issue tracker submission window is nothing more than a title bar, and a big blank text box in which to describe the issue. 

Elsewhere, Google made it easy to host your project on their site, and took approval and compliance processes out of the system entirely. Sourceforge notably required a lot of hoop jumping back in 2005, and Google decided to ditch these requirements and just allow anyone to host projects there.

Google also took the controversial tactic of restricting license usage on Google Code. They whittled the choices down to the bare minimum, and as a result, over half of the code hosted there is either GPLv2 or GPLv3. A quarter of the projects are under the Apache License, and the rest are a mix of Eclipse, MIT, and a handful of others. As Google engineer, Ben Collins-Sussman put it, if you can't get what you want out of the licenses they chose, you're doing it wrong. He also said that many developers think of legal documents like code: if they compile, you're good to go. This is super wrong, and can get you in trouble. So Google has used Google Code to halt open source license proliferation and dilution.

For the fifth anniversary, Google implemented a Paxos algorithm in the backend of Google Code, so now updates will be instant and reliably replicated. 

As an Alex, I was most enthusiastically floored by this conversation between two Alexes. Or is that Alexii? Either way, their conversation was spurred by this excerpt from Steve Souders' "Even Faster Websites." Essentially, the gist of these sites is that CSS items are evaluated as a giant list, every time you put in a sub-div element. It's quite a realization, if you''re building sites with 1000's of CSS elements, like Facebook. Potentially, every <p> tag could be causing your viewers' browsers to check every one of those 1000's of elements. And it clutters up your DOM! Yikes! Go read up, because you may be dealing with CSS improperly. Or at least, from improper assumptions.

Boy, we were a tough crowd. The Windows Phone 7 leadership, marketing, project management folks plied us with food and beverage, but as a room full of tech journalists, were were naturally skeptical. Windows Phone 7, eh? Not Windows Mobile 7? The questions will remain until MIX in Las Vegas, 2 weeks from now, but here's what the Windows Phone 7 folks told us tonight...

• Windows Phone 7 development will be focused on Silverlight, but all of the .NET languages will work.
• XNA will be the games development platform, plus Games for Windows Live, or Xbox Live, or whatever you want to call it.
• There will be an App store
• The interface has been designed from the ground up for usability, rather than for consistency with the Windows brand.
• Devices will be coming from most manufacturers and all the carriers.
• The SDK will enable "cheap" development. They did not say free, though Charlie Kindel, who's heading up the whole project, said that his team understood that the other leading platforms offered free SDKs.
• Kindel and his team were molded in the image of the Xbox team: that is, a team beyond reproach, small, and given free reign within Microsoft.
• From my visual experience with the prototype/not-for-production device, the interface is super simplified, and well imagined.
• Realization? Well... Kindel had trouble getting his flashlight application to work... Only took 6 lines of code to write, though! 

Today, I attended the Enterprise Software Development Conference (DISCLOSURE: a conference run by SD Times parent company, BZMedia). This informative day of talks from the likes of Ken Pugh, David Intersimone, and Robert C. Martin lead me to one conclusion: there is some terrible code out there, and you, loyal readers, are the poor souls who are paid to clean it up. It is a difficult and thankless job, but that's why there are IDEs and static analysis tools. With enough time and effort, you can understand that 25 year old billing system, and you can make it work again.

In one session, an attendee told the story of his work with a large company that was having trouble with its billing system. To rectify the problem, they had been buying larger and larger Oracle licenses. It turned out that the code running their billing system never closed database connections. Ever. Four lines of code later, things were much better.

But as all of you reading this know by now, being an enterprise developer is rarely about writing perfectly clean, fresh code. All too often it's about connecting pipes, and in the very worst of times, forensics. 

Now, we know that when you're writing something anew, your team produces shining examples of modular, reusable, well commented code. But every company has bad code somewhere. Hidden in a dark office, running an ancient database on a machine that uses VHS tapes for backups.

And those are the tough problems that cause the most pain, yet they are terrifying to deal with on a code level. It's always a tough decision to start from scratch, and many times, you simply can't due to business constraints. Sometimes those problem applications are written in some arcane language none of your team understands. Other times, the source code was obviously written by people who hated white space and knew nothing about comments. You've all got your problem child applications.

ESDC's speakers offered a lot of advice, both on how to fix rotten code, and how to avoid the mistakes that lead to said bad code. David Intersimone, in particular, discussed strategies for dealing with nasty old code bases (He recommends a vigorous application of IDEs, refactoring, and analytics). There were many other topics discussed, including virtualization, and iPhones, but I got the sense from the attendees that this was the one topic with which they could all sympathize.

It is for this reason that I propose a new type of college course for anyone who wants a career in business programming: the "Fix it" course.

This class would require no in-lab time, no teacher. Just one big blob of horrible code, preferably in COBOL or some other more ancient dialect. The code would only run on a slow machine hidden in a basement somewhere, and accessible only through telnet. And it's broken. Students are then given one full semester to fix it. I think we can all agree this would be of great value to young programers, and prepare them well for the world ahead. Especially if the code contained no comments and no line breaks.

Ian Skerrett has the low down on how the whole logo process went down. Go vote right now!

It's hard to believe it has been 15 years since the Apache Web Server was first created. I'm sure we could all sit here and ruminate, quoting stories and telling tales of great excitement in the data center from years past. But instead, I'd just like to mention a simple truth that shows just why Apache is the Web server of choice for most of the Internet. Every time I have recently been privy to a troubleshooting session in an enterprise, there is one commonality when they're using Apache: they always rule it out as a point of failure immediately. If you're using a stable Apache, you can be almost positive that your problems have nothing to do with the actual server itself.

It's that stable. And has been for at least 10 years. That's not to say some of the mods that can be added to the server aren't glitchy from time to time. But when you get right down to it, the Apache Web Server is, generally, the most stable and reliable part of any Web stack. And that's why, after 15 years, it's still the only reasonable open source choice. New HTTPd servers come and go, and every time I see someone talk about LightHTTPd, or some other replacement for Apache, invariably, there is an email to Bugtraq a week later that renders the advantages moot due to some newfound security risk.

It says a lot that any security problem in Apache Web Server is immediate front page news. Mainly because they occur about as often as the Olympics. Anyone care to share an Apache story?

Today, I sat down with Yehuda Katz, Rails Framework Architect. Katz used to be the man behind Merb, but when Merb was merged into Rails last January, Katz became a core Rails contributor and architect. I sat him down to talk about the recent Rails 3.0 beta, and about the new life within the Ruby on Rails community.

How have things been on Rails since the merge with Merb?

It's been good. The interesting thing that's happened since that is a lot of other Ruby projects have done it. There's a tool called Webrat, which is a full stack testing tool; and abstraction around HTML Unit. Someone said I can make it better, they called it Capybara, and they pushed it into Rails.

Also, Micronaut. It's basically guys who said 'we can do rspec better.' This has started to happen in the Ruby community, and it makes me happy. I think there is too much in the open source world of people building software because you want to put your name back out there.

That's been a positive outcome. Also the Rails core team diversity has been very helpful. Rails core, before, was 37Signals and some people doing client work. Now we have people doing custom development around it. We have people working on problems we didn't have before. It's definitely caused us, both people who are new and veteran contributors, to question our assumptions. The conclusions have been almost 100% positive.

The community has gotten a lot healthier since the merge. Like rails was getting stagnant a lot of people who are coming back now who are coming to rails to first contribute. A big chunk of the time I spend every day on rails is cat herding. And trying to balance the need to be involved in the architecture of the thing, and getting things done by real people interested in doing things.

I hear things are being uncoupled, starting with Prototype.

Unobtrusive JavaScript. Rails is no longer coupled to Prototype. That was a community effort. DHH tweeted 'we're running behind,' and a community formed out of the aether. Less than a week later it's all done.

Basically what Rails did before, when you said 'link to remote,' like, I want a link that when you click if makes an AJAX request and when it comes back, put it in a div. In Rails on click, you would have to go through and find all those places where you used Prototype and remove that reference . People made shims they got out of sync. The way it works in Rails 3 it's straight HTML: a href = “actual url” and it uses the HTML 5 data tag. It supports custom attributes. We've created a library that says 'find any links and wire them up.' Anybody else in other libraries like Dojo who want this benefit just have to write JavaScript and not ruby.

Before having someone go and hack in the helpers and such required someone on both sides of the fence at all times.

What are the biggest changes for Rails 3.0?

The biggest thing is security. We went through the known remaining security vulnerabilties based on having spoken to Twitter and having them say 'your security tools are too manual right now.' [To prevent cross-site-scripting vulnerabilities] Almost every framework says if you use user content, just escape it. It's easy to forget to escape it. As an attacker, you have to find the places in Web applications where they forgot to escape. What we've essentially done is made Rails pessimistic by default. If you try to put in a string into HTML at any time, we automatically escape it. We went through all of Rails' internals and marked the form tags as safe, which means that for the vast majority of cases, users won't have to do a lot. But there will be cases where they were relying on content input by the user that was unsafe. But it's now almost impossible to have an accidental XSS attack.

We've also gone into cross-site request forgery (CSRF) protection. We were pretty rock solid before, but there were cases where we were blacklisting things which were not vectors for an attack. We made it less annoying to work with the systems. If there was a form you were submitting with JavaScript, you had to form a token even though that was not a possible vector. This makes it less likely for people to turn [CSRF protection] off.

Tthe second big thing is improving interoperability, mainly with other Ruby libraries. We've gone through Rails systematically, and found where we were coupling ourselves to ourselves and removed those. Rails controller view code is no longer coupled to the models, so you can use any views you want. We also added support other templating languages. We made it a lot easier to support other testing frameworks. TestUnit was standard, and others had to do a lot of work to strip out our support for TestUnit and add their own. Using rspec felt worse than using TestUnit. TestUnit itself is a plug-in now.

How has Jruby been involved in the Rails 3.0 push?

The biggest thing is to be in touch with them and make sure Rails 3 ran on JRuby. We made significant changes, and a lot of the things we added to Rails 3 were shaped a lot by JRuby and Charlie [Nutter, co-creator of JRuby]. Charlie wants to allow existing Hibernate models to work within Rails. That's not going to ship with Rails, but the way we built it, it's possible to swap in something for using Hibernate.

We didn't go in and say 'we're supporting some Java feature.' They have top notch Java integration. Because of the fact that we've made our layers agnostic, it's really easy to work with JRuby. We will see things, Hibernate being the first obvious example that will highlight this interoperability.

It sounds like there's a lot of new monitoring options in 3.0.

We've instrumented the entire framework. Ruby itself is intrinsically insturmentable. You can do something before and after to call the other method first. Then you have people trying to find the appropriate place to insert. For rails 3 we wanted ot make it really easy for New Relic [A new Rails company focused on monitoring] to exist. We rearchitected the logger to, instead of being hardcoded inside parts of Rails, to listen to instrumentation events and do the right thing. Things like, 'started SQL now.' Server did a request and it took this amount of time: that info is collected. If you want to say 'this should be considered model time,' you could do that yourself.

What's going on with Active Record versus DataMapper?

Active record got a big boost in Rails 3. There are a lot of reasons why people might have used DataMapper, before, and it is now in Rails. Active Record has a relational data model, so it is now a lot easier to chain together queries an compose queries. DataMapper is still a great library, with support for multiple databases. We wanted DataMapper to have the same mount of support as Active Record.

Another [area of improvement around DataMapper and Active Record] is that configuration for plug-ins looked different than configuration for top level things. In Rails 3, we just expose the ability for anyone to have just top level configuration. Finally, [we improved] instrumentation. Instead of the logger saying 'how much time is Active Record saving?' Active Record emits a SQL event and the logger listens for a SQL event, collects all the events, and puts them in the log. Anybody else who wants to put in a piece of Rails can do that now. DataMapper doesn't look different from using Active Record in the logs.

Finally initialization. On boot, plug-ins were initialized later. Active Record hooked in early, plug-ins like DataMapper could not. In Rails 3, Active Record is loaded similarly to how DataMapper is loaded. We also added an API for saying 'I would like to run this after that.' I want to run this block after or before this block. This makes it easier for frameworks that look at the built in code.

The default Rails experience is the same.

This sounds like it's mostly a housekeeping release.

I call it the Snow Leopard release. The routers way better; you can route based on sub-domains. Ruby has racks, like portlets were an abstraction, this is a simpler abstraction and Rails is now basically a rack framework. If you want to take a Sinatra application and put it inside a Rails route, it's really easy.

So, what's with Sinatra? It seems to be getting popular.

Sinatra is essentially a nicer wrapper around rack. You receive a request which is a hash and pathinfo, and you return an array of status code, the headers, and the body, and you have to do very specific things. That's not complicated; it's fairly easy, but most of the time you want to say when the user goes to this URL I want you to return this.

Sinatra makes that workflow really easy, especially if you have one big library you want to expose to the Internet. We've been looking at whether or not those abstractions will work in Rails. In general, it would require some work to get working. Our template API is very performant. But the way you set it up is--not horrible--but could be better. We're looking at ways to leverage the ideas of their templating system in Rails and maybe creating handlers. But in order to do that we have to solve some performance problems. We're looking at that for 3.1.

What do you think about other Web frameworks in other languages, like Django in Python?

We're trying to make it so that if people want to build something in other places, you shouldn't have to make a Rails specific version. Django wants people to write Django-specific things, not just Python. What's really cool about Ruby is that there isn't any divide. We pushed a lot of stuff back to rack, a lot to Ruby Gems; we prefer it to have things in a sharable form. People who work on minor frameworks write a disproportionate code. Making it easy to share template stuff with Sinatra, even though there's only 100 users--what good could that be? Well, if we are sharing, we have a much better ecosystem. The Python world has this wrong. Django feels that because they are a big framework, they don't have to share.

Do you even get to code anymore?

I do get to code. Half my time is working with people. Almost all the time I spend working with people is code reviews. It would be fairly difficult for the people who I work with who are not on Rails core to do stuff on their own, but a lot of people are getting pulled in. We have a few people contracted at Engine Yard who have worked their way into being members of the core team. The goal is not to make us [the core team] obsolete, but to make us a big group.ac

A week ago, I let ya'll know that the core PHP team had been brought to Facebook's main campus. That team were forced to sign NDA's, and taken to a very quiet, secluded meeting room where some cool new Facebook-backed open source project was described.

Well, I was able to put all the pieces together on this one, finally, and I now understand exactly what is up: Facebook has rewritten the PHP runtime from scratch. This coming Tuesday, they will make a big announcement around this project, and will make it available as open source software. I'm not really sure of any of the details of the project, but I do know that Facebook hired someone two years ago to do this, and I'm relatively sure this was a one-man project during that entire time.

So, why has Facebook rewritten the PHP runtime? Because PHP is obviously too slow for their tastes. A few years ago, I had a coffee meeting with some of the folks from Zend. When they asked what I had been hearing about PHP in the market from my sources, I hemmed and hawed, then told them that I had heard people complaining about how slow PHP was. Now, I don't personally consider PHP slow: it is simply not a language designed for the sorts of workloads that Java and .NET are.

But that still doesn't change the fact that PHP can be a tad pokey on the server. Well, when I said this to the Zend folks, their immediate reaction was similar to that of a gestapo officer looking for a spy: "What? Who said that? Tell us their name!"

Clearly, Zend does not think there is a problem. But Facebook did. Not enough of a problem to support more than one paycheck, but then, considering how many users they have, even a 1 percent performance gain would be a massive help.

This Tuesday, salvation should arrive. I would imagine this new project will push a lot of the weight in the PHP community into Facebook's corner of the world. It will be nice to see what they can do with all that interest, since Yahoo!, in the same position 6 years ago, largely squandered their opportunity to mold PHP into a more robust platform and language. 

UPDATE: After sifting through the comments here and elsewhere, I'm inclined to agree with the folks who are saying that Facebook will be introducing some sort of compiler for PHP. This sounds highly plausible, and fits into what I've heard. Obviously, I don't have absolute specifics. Thanks for the extra info, readers.

A friend in the valley clued me into a juicy bit of gossip that I have been unable to confirm or yet uncover. Perhaps y'all can help. I've heard that a whole gaggle of PHP core developers were invited to Facebook's offices today to discuss some grand new open-source project from Facebook. The company has already opened a number of projects, including Hive, a data-access layer for Hadoop.

But I'm as yet unable to uncover the actual nature of this new project. Considering the PHP developers being called to the scene, I'd imagine this has much more to do with the Facebook presentation layer than with its back end. We already know the back end is producing a ton of data, and that Facebook's biggest challenge is to make heads or tails of all that information. Hence their use and development of Hadoop-based solutions to the problem.

PHP is certainly the underpinnings of Facebook's presentation side. Does this mean we're about to see Facebook open its platform?

Over the weekend, a fairly large shift in the balance of power in rich Internet applications occured. As we all know by now, Adobe's Flash is the most popular browser plug-in and the most common way to play games in your browser. It's also the plug-in used to bring us video, audio and animations resplendent with silly characters and non-sensical music.

For some time now, the lack of a Flash player for the iPhone has been a big problem for mobile users. They've complained that the iPhone uses a full, real browser, but does not have access to whole swaths of the Web due to lack of Flash support. Certainly, Flash shouldn't be used as a front mend to data for this very reason: It may make data pretty, but it offers no text search or little accessibility support, and it confounds low-tech users who prefer Lynx to Firefox.

But this weekend, German developer Tobey Schneider may have shifted the balance of control on Flash away from Adobe. You see, Tobey has written a Flash runtime in JavaScript. The project is called "Gordon," and it looks to be in very early stages thus far. But I would imagine Mr. Schneider will have an awful lot of people interested in helping him flesh out this effort. Gordon relies on HTML 5 and the SVG standards, so this isn't going to take over for Flash anytime soon. But it may just help to remove the need for Adobe and Macromedia's love child once HTML 5 becomes widely adopted.

Frankly, having dealt with an obnoxious phone directory listed in Flash with no search function, and having been forced out of websites because I wasn't using a graphical browser, I can't wait.