I was awoken, slowly, by what I thought was someone ringing our doorbell. Our doorbell is extremely quiet, and is hard to hear. Perhaps I was just dreaming. Then a sharp thumping was heard, and I knew someone was knocking on the door. The last time this happened, it was a police officer knocking on the door to inform me that our Honda Civic had been smashed into by a hit-and-run driver. This time, it was our next door neighbor knocking on the door to inform me that our Honda Odyssey van had been smashed into by a hit-and-run driver.

According to my neighbor, he heard the boom of the impact, a sound which failed completely to wake me, and ran out to see the carnage. A white Chevy Impala hit our van, driving it over the curb and into the alley adjacent to our house. In the process of doing so, the van was forced over two large decorative rocks, completely demolishing the right front wheel, in addition to the devastation to the driver's side rear door.

My neighbor told me that the driver of the car had gotten out and fled on foot, leaving behind an injured passenger. My neighbor then proceeded to explain that the driver was Hispanic, and that he felt it was a strong possibility that the car was stolen. I smiled and nodded, as I waited for the police, who were already on the scene, to speak to me.

Two ambulances arrived, and the passenger in the car was extricated. Several people from the fire department then spent some time banging on the hood of the car, presumably trying to open it. The noise roused Carina, who somehow came to the conclusion that I had been tricked into going outside and was then being assaulted by villains. She got up and joined us outside, and spoke to the police and our neighbor while I called our insurance company and opened a claim. According to Carina, the police apprehended the driver of the car running down High Street. I never learned whether he was Hispanic, nor whether the car was stolen. Neither of those details are particularly interesting to me.

Initial theories suggested that the driver was coming out of the apartment complex driveway opposite our house. This notion was quickly dispelled, though, due to the distance our van had been moved. It wasn't likely that the Impala could have gotten sufficient speed in the driveway to ram our van in that way. What I think happened was the Impala came too fast down our street, and lost control as it hit the speed bump in front of my neighbor's house. The car ricocheted off our van, spun around, and came to a stop a few yards away, ending perpendicular to the road.

The insurance adjustor will be calling me first thing this morning, so now all there is to do is sit and wait.

When I started working at OSU, our department had three physical facilities connected by a single virtual LAN. The network performance was acceptable, most of the time, because most stations had only 100 megabit ethernet cards, and our uplink was as much (if not less).

Last October we opened our new building, and phased out two of the previous buildings. This left us with two buildings on our VLAN. Our new building has all brand-new HP ProCurve switches providing gigabit ethernet to every port, 10 gig fiber between floors, and a gig uplink to the campus network. The new computers for our student labs all have gig ethernet cards. Unfortunately, the link connecting our two buildings was only 100 megabit.

Our new building is used by all our public computer labs, plus all the faculty and staff. The network appliance providing our storage was in the other building. So all of our connections were being funneled through the 100 megabit connection, leading to extremely long login times, and occasional bursts of network latency. Last week my boss and I finally moved the filer and remaining servers from the old building into the new building. One would think this would make things significantly better for our network performance, and it did, but there was yet one piece that was still a significant bottleneck.

Prior to the move, we had a single /22 network for all our hosts. After the move, we acquired an additional /24 network (discontiguous from our primary pool). Our plan was to move all the student lab computers to the new /24, freeing up a large swath of IP addresses in our primary space. The campus network admins provisioned the new network for us, and configured routing on our upstream router. All worked as it needed to, but in a rather inefficient way: the /24 hosts need to connect to our filer in the /22 network, which means packets need to travel to the upstream router, and then immediately back into our network. The switch that connects our building to the upstream router is basically handling twice us much traffic as it might need to, as it sends packets up to the router and then immediately receives those packets again. Indeed, it was showing 100% utilization for most of the day today. I can only assume it's been at 100% utilization since we moved the filer into our building (and likely even before that).

Our switches can do layer 3 routing, so it seems kind of silly to send all the traffic up a hop to a router, only to come right back. Configuring our core switch to do the routing wasn't hard at all. Getting this configuration deployed throughout our building proved slightly more complicated. My first attempt to do so knocked all the student lab machines offline. I thought I could finalize the configurations quickly enough as to not cause too many problems, but a swelling body of irate students outside my office door convinced me otherwise. My boss was not thrilled with my enthusiasm. I aborted my plans, and set about preparing for a more graceful cut-over.

Around 5:40 PM tonight we made the switch. I executed a few commands on each of the affected switches, and then updated a few routes on our primary servers. With the exception of one minor -- and easily corrected -- oversight, everything worked great. Within moments the switch connecting us to our upstream router was reporting less than 20% utilization. Now that we're not hammering our upstream connection all day every day we'll be able to detect and react to abnormal traffic spikes. And most important to our student population, they're not all trying to share a single gigabit connection to our storage appliance!

I donated blood last Thursday for the first time in a long time. I used to donate to the Red Cross every eight weeks -- literally every eight weeks. See, I have O Negative blood, which makes me the universal donor. The Red Cross loves me, and they would call me every six weeks in order to schedule my next donation just as soon as I was permitted to donate again. A few years ago I was sick on the day of my scheduled donation, so I couldn't give blood. I rescheduled my appointment, but was ill that day, too. I must've forgotten to reschedule, and then shortly after that I moved. The Red Cross lost track of me.

OSU sponsors blood donation events pretty regularly. I'd meant to participate sooner, but failed to do so for various reasons. I finally forced myself to clear some time and to get down to the Red Cross' portable donation center. I had to answer a bunch of questions, since it'd been so long since my last donation. It took longer to prepare the paperwork than it did for me to actually donate blood! But then, I've always been a fast bleeder, and the nurse tending to me expressed genuine surprise when he realized I was done so soon.

Now that the Red Cross as my updated contact information, I know that I'll be getting regular calls from them.

This afternoon I took an online Meyers-Briggs personality test. I've taken many of these tests before, and I always get the same result: INTJ. I suppose it's good that I'm consistent in my results, as it makes me better trust the results of each subsequent test. The detailed description of INTJ was very thorough -- much moreso than many of the summaries I've read from prior tests -- and very closely describes how I perceive myself.

Carina's personality result was pretty much what I expected it to be. We make a good compliment to one another. I'm glad we're married.

My In-Series plugin is being taken over by a new developer, and has a new home at http://remstate.com/projects/in-series/. If you use In-Series, you should update your bookmarks and download the latest version.

Il Filosofo has released a new version of WP-DB Backup, as well. This version updates for the new scheduling functionality in the forthcoming WordPress 2.1 release. If you're a WP-DB Backup user, please be sure to update your bookmarks in order to keep up with Il Filosofo, since I'm no longer working on this plugin.

So it's official: I'm leaving WordPress behind. I'm involved with the development of Habari, the next-generation blogging solution. One might wonder why we're re-inventing the wheel. Someone recently quipped that we're past the wheel, and are now working on the hovercar! Nonetheless, an explanation of what Habari offers should help explain why I'm involved.

Community

Community is the cornerstone of Habari development. It was community that brought the four of us together, and we're keeping community squarely in mind as we approach decisions and plan features. We recognize that only through collaboration will Habari succeed: each participant brings with him or her their own unique skills and passions. This diversity of talent and ability is an important aspect of Habari's community.

Another important aspect is that Habari is owned by the community. No one person has full authority over it. The people who use it and work on it are the ones who should -- and will -- make decisions about Habari development. Additionally, community members should be given the power to take charge of their areas of expertise. If someone is passionate about documentation, they ought not have to work through someone else's restrictions in order to make the docs successful.

Innovation

Habari is about innovation. There's a lot of great things being done with internet technologies, and we are very interested in integrating them into the way we blog. Things like OpenID, CoComment, and the Atom Publishing Protocol are all very useful innovations. We've been frustrated by the difficulty in integrating these -- and more -- into WordPress. Some of the roadblocks to integration into WordPress were technical, while others were clearly non-technical. We hope to remove both kinds of roadblocks and make Habari the most cutting-edge blogging system available.

One of the very first decisions when planning Habari was to make it a fully object oriented system, and leverage the powerful features of PHP objects. This has resulted in some wonderfully efficient code, and so far the system is remarkably fast. Object oriented programming allows us to streamline the development of user-created plugins; allows us to integrate a unified error handling system; and vastly simplifies the construction of our Application Programming Interface.

Another early goal of Habari was database independence. There exist enough database abstraction libraries that locking oneself into a single database really does seem a poor design decision these days. By using PHP version 5, we gain access to the PHP Data Objects (PDO), which is the PHP-native database independence solution. We currently have MySQL and SQLite working, and are eager to find contributors with PostgreSQL experience. Preliminary conversations suggest that Oracle support wouldn't be too hard, either, surprisingly enough. Another very real benefit to using PHP5 + PDO is that we gain the use of prepared statements for all database interactions. This drastically reduces the likelihood of a SQL injection attack against your blog. We're considering using stored procedures, too, as both a means to improve performance as well as to improve database independence.

Documentation

As much as we're striving to make a system that's friendly and intuitive, we recognize that not all people have the same background as we do; and as such what's intuitive to us might not be intuitive to a first-time blogger. Documentation is of paramount importance to the Habari project. End-user documentation and developer documentation will both be included in the download.

We plan to integrate links to the manual into the Habari administrative interface, so that you may get help about specific parts of each screen with a single click. The manual will be part of your Habari installation, so if you can get to your site you can read the manual. Users should be able to access the documentation without relying on our possibly flaky servers to store the manual they need.

Developers -- and would-be developers -- should also be provided with meaningful documentation. We're fully documenting (via PHPdoc) the source code to Habari, and plan to include thorough instructions as to how the system operates: initialization, request processing, theme and plugin dispatching, and more. This is a fundamental part of the Habari distribution, and not left to the kindness of volunteers after the fact. New methods will be documented when they're included in a new release, not after someone figures it out on behalf of everyone else.

Another important aspect of documentation is meaningful changelogs, listing real changes to the product since the last release. Distributors and integrators rely on changelogs to see what's happened. Developers rely on changelogs to be made aware of fundamental changes to systems they might be using or extending.

Experimentation

Habari is not afraid to experiment with new ideas. The Subversion repository ensures that nothing is ever truly deleted. If someone eagerly checks in a new idea that proves to be either poorly implemented, or maybe just not such a great idea after all, the revision control system makes it easy to correct the situation and move on. We hope to support developer branches for their own work outside of the core trunk.

With all these people having access to check in new code, it's a very real possibility that someone might try to intentionally foul things up. If someone were to flake out and try to actively harm the project by deleting files or polluting contents, the other project members could simply roll back to a previous version before the attack and keep going. If someone checks in something by mistake, or implements something broken outside of their area of expertise, it can be dealt with relatively easily.

Development Model

I met DrBacchus several years ago, and it's been fascinating to listen to him speak about the Apache development process. The meritocracy of the Apache Software Foundation is such that regular participation results in increased permission within the project. This is the model we've decided to adopt for Habari: frequent contributors are given access to submit new stuff directly, because they've proven themselves capable.

This is important for several reasons. First, we each have our own areas of interest and expertise, so by getting more people involved directly we speed up the development of all areas of the code. Second, more people are available to deal with problem situations. Third, the project as a whole doesn't slow down if a few of the developers are offline for extended periods of time. Finally, more developers improves our "bus factor": it takes more people getting hit by more buses to interrupt the project.

Spread the news

We've been working on Habari since October, 2006. I'm tickled that many of the suggestions on "What the new kid on the block needs to get right" had been discussed long before we ever announced the project. With the influx of interest and enthusiasm, there's been a lot of attention on the installation process. Hopefully we can dedicate as much energy to the upgrade process as well.

I'm thrilled with the response to Habari so far. Owen's posted some more info about Habari, as well as a collection of links to some other posts about it. The IRC channel is becoming surprisingly busy. I know eventually all the enthusiasm will taper off, and tough decisions will need to be made; but for right now the sky's the limit!

Needless to say, I'm very excited about Habari!