My G+ Profile
« September 15, 2003 | Main | September 17, 2003 »
September 16, 2003
XML Database Based Blogging
One of the things I love about reading Jon Udell's blog is that Jon is a "cool stuff" magnet. Such is the case today where Jon reports on Kimbro Staken's new blog software, built on top of Sleepycat's Berkeley DB XML. In Kimbro's system, the XPATH query on the XML data just becomes part of the URL and thus is folded right into the GET. As Jon says: "I just love this idea of incorporating XPath into RESTian URLs." There's something elegant about it.
Every once in a while I make a change to my CSS that allows my posts to have more meaningful mark-up. For example, I created a class for quotes so that it would be easier to find them. Still, I think there's much more to do in this area to make my blog a more meaningful data repository for myself and others. Using an XML based data base as the heart of the content management system would provide the infrastructure for doing this (although making it reality would still require discipline).
The other part of this post that's very interesting to me is the link to Berkeley DB XML. I'd heard of it before, but never looked into it. If you've ever thought about building an application that's based on XML, you know how key an XML based DB is to the whole thing. Berkeley DB XML is an open source XML database built on top of Berkeley DB. (People who know the history of iMALL are chuckling right now.) I found a good little article on Berkeley DB XML that contains PERL code showing how it can be used. Summary: supports XPATH queries, but not updates---yet. Imagine being able to GET, POST, PUT, and DELETE to an XML database in a RESTian manner.
04:58 PM | Recommend This | Print This
Wisconsin Moves to Regulate VoIP
The Wisconsin Public Service Commission has informed VoIP provider 8x8 that its VoIP service is subject to the same rules as traditional telephone companies. Last month Vonage was told a similar story by Michigan. In this story from c|net News, Huw Rees, a spokesman for 8x8 claims that this ruling has ramifications beyond voice:
[The WPSC ruling] could potentially regulate e-mail because they don't distinguish between data communication and telephone communication. It seems to be a lot of confusion to how and whether or not to regulate these types of services.
The problem is that as services converge, its more and more difficult to separate out voice services from data services. Combine a Cisco 7200 with the right cards and software and you've got a voice switch. Buy some PRIs from the phone company and you can start offering phone service to your friends and neighbors. There are companies like PortaOne who will sell you the billing and self-service provisioning system and you're in business. Its cheaper than you think too: a few hundred thousand is all it takes to be your own phone company these days.
I think that PSCs around the country have to start regulating behavior instead of implementation. That is, don't try to figure out what's data and what voice. Don't try to regulate data packets. Just modify the rules so that they're consistent with voice service and forget about how its delivered. If we believe that there is some public interest in regulating voice, and I think there is (eg. 911 service, life line services, etc.) then let's provide for that. But all the rules now about CLECs and so on were made a decade ago when becoming a phone company required the cooperation of the RBOCs. At this point, its hard to imagine how they'd stop you.
02:35 PM | Recommend This | Print This
Extreme Programming
There's been a lot of buzz about Extreme Programming, or XP as its sometimes called. Proponents claim that its the answer to late projects and buggy code. They might be right. A recent Wired Magazine article called The New X-Men talks a bit about XP and highlights four programmers at HP's Seattle office. One of those developers is Kevin Yu, described a s 25-year old, prematurely jaded programmer:
Yu is among thousands of coders who've discovered extreme programming, a method of software development that emphasizes constant feedback. Traditional coding devotes a huge amount of time to up-front planning, then demands rigid adherence to that plan. XP is different. Programmers spend relatively little time planning and instead dive into the writing, making course corrections as needed and allowing better ideas to emerge after snippets of code are tested and assessed. The result is a speedy loop: plan, code, test, release, plan, code, test.
At the heart of XP are some simple concepts and principals. The Wired article, following the lead of an article on IBM developerWorks by Roy Miller called XP Distilled, defines twelve rules for XP:
- The Planning Game XP is based on the assumption that you can't know everything upfront and that you'll learn as you code. This XP encourages the creation of a rough plan and then frequent updates as you go along. This involves constant communication and frequent meetings with the customer.
- Small Releases Put a simple system into production quickly, then release new versions on a short cycle. Even so, each release should deliver real business value.
- System Metaphor This is XP's answer to architecture. The system metaphor provides a picture of all the pieces and how they interact.
- Simple design Simple designs lead to simple implementations. The implementation should pass all the tests with a minimum amount of code and no more.
- Testing Writing unit tests is part of writing the code in XP. In fact, the test is written before the code and serves as the specification. The customers write the acceptance tests. How is that possible? See my write-up of Ward Cunningham and Brian Ingeson's talk on the FIT Framework for one possible answer.
- Refactoring Refactoring is rewriting the code to simplify, add flexibility, or remove redundancy without changing the functionality. An XP team refactors relentlessly.
- Pair Programming Write all code with two programmers at one machine. Some might think this inefficient, but Martin Fowler says "When people say that pair programming reduces productivity, I answer, 'that would be true if the most time-consuming part of programming was typing."
- Collective Ownership Any person on the team can change code anywhere in the system at any time.
- Continuous Integration Rather than scheduling daily, weekly, or even monthly builds, XP proponents build the entire system several times throughout each day to make sure each piece works in concert.
- 40-Hour Week Burning the midnight oil kills performance. XP teams endeavor to work a fixed number of hours each week and to never work overtime two weeks in a row.
- Onsite Customer Developers aren't allowed to make business decisions, so having a real, live customer or user on the team, available full-time to answer questions speeds the process. I think this dovetails nicely with a well developed discipline of product management.
- Coding Standards Having a coding standard prevents the team from being distracted by silly arguments and supports the pair programming and collective code ownership principals.
Some are put off by the religious fervor that XP devotees have. I put that down to excitement at discovering something they like and that works for them. From my perspective, XP is about big-scale programming. I think it would be difficult to do in a start-up and maybe not as useful where typically one visionary is creating the pilot. I'm intrigued though. If I were managing a development team again, I'd probably give it a try.