The following is what I came up with. It’s a ruby script that uses the delightful Hpricot gem to parse the xml. It takes one argument, the subversion username that you wish to retrieve the logs for. I hope that it’s useful for someone else! You can curl it from http://pastie.textmate.org/197763.txt if that makes it easier, too.

[ruby]
#!/usr/bin/ruby
require ‘rubygems’
require ‘hpricot’

username = ARGV[0]
if username.nil? || username == “”
puts “Please specify the username to cull log entries for.”
exit
end

puts “Requesting SVN log, this may take a bit.”

doc = IO.popen(“svn log –xml”) do |f|
Hpricot.XML(f)
end

entries = doc.search(“logentry”).find_all do |entry|
(entry/”author”).innerHTML == username
end

entries.each do |entry|
revision = entry.attributes["revision"]
author = (entry/”author”).innerHTML
date = (entry/”date”).innerHTML
msg = (entry/”msg”).innerHTML

puts “r#{revision} – #{author}”
puts “#{date}”
puts “#{msg}”
puts “-”*80
end
[/ruby]

To this CTO, knowing the details of his network and server infrastructure was like knowing the details of the local utility electricity grid – not required. Is this a bad thing, or proof that networking technologies have succeeded?

The question posed is this: do companies building Internet-oriented products, Web 2.0 service companies for instance, need network engineers to keep their systems running? Or does it make more sense to outsource these kinds of operations to a third party (for instance, hosting everything via a virtual server or other hosting provider)?

If the answer to this is yes, then imagine some of the logical extremes: fat pipes leased by organizations (of the OC ilk, for instance) to handle their customer traffic is no longer necessary for anyone other than the hosting providers. Datacenters would have these kinds of connections while the corporate offices would have lower-end connections (I can see a popular Web 2.0 provider where employees run off a local DSL connection, while their hosting provider has a full OC-12 to handle traffic).

Of course, larger organizations with an IT support staff wouldn’t fit in this category, and companies with a large number of on-site employees requiring Internet access would still be leasing high-capacity connections, but it’s an interesting question nonetheless, especially as so many companies are moving their software offerings to subscription-based models. What’s your take?

Every so often, I like to head out to a Starbucks (which costs a couple bucks for the TMobile service they provide, plus a Venti cup of whatever’s brewing) or a FreshCity (where it’s free), take my MacBook, and get some work done. I find it’s often good motivation when I pick up and move to some other place – different environs give me a nice motivational push. What’s your take? Do you think offering WiFi for free at Starbucks, Panera, FreshCity, McDonald’s, and other places would be harming or helpful?

Don’t Miss:
What Starbucks Can Learn From the Movie Palace
WiFi is the New Air Conditioning
Wi-Fi should be free
Wi-Fi: If Not Free, Then How?

A while back we decided we would like to build a new phone system for Draconis – something that could grow as our needs grow, and versatile enough that could keep up with us. Our first thought was to use the open source Asterisk PBX, and as a result, we began building a phone system around this remarkable project. I’m going to give an intro to what we decided to build, but getting Asterisk up and running (especially if you don’t know a whole lot about phone systems) can be incredibly time-consuming. But, at least for us, it was also very fun.

The hardware
We spent a lot of time researching what we should use for hardware. Luckily we weren’t particularly attached to any existing phones we had (all of which were the standard fare – phones you could buy from Staples that plug into any old telephone jack), so we investigated both VoIP phones (also called hardphones), and adapters for plain-old telephones (also called ATAs, or Analog Telephony Adapters). There’s a third option as well, which are plug-in PCI cards (called FXS, or Foreign-Exchange Station, cards) that allow plain-old phones to connect to existing phone wiring and then into a computer with Asterisk (kind of like a specialized modem).

Eventually, we decided to buy VoIP hardphones – individually, they’re more expensive than similarly featured analog phones, but the versatility they provided (not to mention the savings over buying ATAs or FXS cards) sealed the deal. We settled on the Grandstream BudgeTone (I believe that’s read as “Budget Tone”, rather than “Budge Tone”) 100′s, and have been very happy. They’re essentially miniature computers with their own IP addresses that plug right into your existing data network and sync up with the Asterisk PBX software. To configure them, you can log into their built-in web interface. Very cool.

As I mentioned, we also considered using an ATA. These are little boxes with an Ethernet plug on one end, and a phone (RJ-11) plug on the other, and allow a standard analog phone to hook up to VoIP service. These are essentially the same thing as the adapters you get from a VoIP provider (like Vonage). However, we decided not to go this route simply for cost: the price of an ATA ranged between $50-$100, plus the cost of the phone, and that became more expensive than just purchasing the BudgeTones.

The FXS adapter is similar to an ATA, but a bit more robust. These are what enterprises typically use with many different phones on the premises, and their costs certainly reflect that (typically $350+). An FXS card provides the dial-tone and related “services” that standard telephones need to operate, but scaled up for multiple phones (kind of like multiple ATA’s rolled into one, but these are cards that sit in the server running Asterisk). Again, cost was a big factor here, and the price plus the telephones themselves just made the system much too expensive. Digium, the sponsor of the Asterisk project, sells a number of these cards.
Having a VoIP hardphone on your desk is great – since they rely on IP addresses, you can pick them up and move them anywhere you like: just plug them back into your existing Ethernet network and you’re good to go. Another cool feature (though I doubt it’s usefulness in everyday situations) is that the BudgeTones have built-in syslog, which can send messages to your syslog server for debugging. Cool, but if your office has more than a handful of phones, the amount of messages could just get overwhelming.

The software
Finally, once the hardware was chosen (and this was no easy step), we installed the BudgeTones and began the process of getting Asterisk up and running. The first step, and since we had no experience setting up an Asterisk system before, was to start experimenting with some of the configuration software out there (FreePBX – formerly called the Asterisk Management Portal, and TrixBox – itself formerly known as Asterisk@Home). Unfortunately, we had quite a difficult time getting FreePBX up and running, and TrixBox was out of the question (it’s distributed along with a scaled-down version of Linux, so you have to reinstall your system and use it’s distribution in order to run the software). Well, we were using an old Sun Ultra 5 server we had kicking around, so reinstalling the system software was out of the question.

Once we got Asterisk itself installed, we then spent an enormous amount of time trying to find documentation. I have to say – I’m not pleased in the slightest with the Asterisk project’s documentation. They have a great system there, which looks like it has a ton of features, but I still have little to no idea how to use it all. Getting started with Asterisk is not for the faint of heart, and you’ll need to plan on spending at least a week before you’re able to get much of what you want it to do running properly.

Some of the resources I found most useful were the configuration files that came with FreePBX – you don’t have to use them, but there are some very helpful macros in there and example dialplans that helped me get started. Also, check out Voip-Info – there’s a lot of useful info there, though it can be daunting at first.

I think the best way to get up and running with Asterisk is to make sure you have no set deadline, and then to experiment. It’s not easy, but when you do get things running, it can be a lot of fun (especially playing with the included sounds in the asterisk-sounds project).

In the future, I’m going to put together examples of how we got our system running, so hopefully others won’t have as hard a time as we did in getting started. But in the end, we have a working phone system that I’m proud of, and I learned a great deal. And that’s what matters.

Powering the Laptop
A novel new power system was announced recently (and which is expected to be field-tested this October) that does away with the hand-crank system previously developed. The new system, developed by Squid Labs, uses a pull-string and a high-efficiency generator to create enough electricity to power the laptop 10 minutes for every 1 minute of generating that electricity. As this Technology Review article explains,

Typical generators work best at high revolutions per minute, requiring noisy gears to step up the speed. The developers have done away with gears by custom-designing a generator that runs most efficiently at lower RPMs, a move that also makes possible a smaller device.

I immediately see a benefit for IT-related applications, especially for the backup power sources found at many datacenters, and I wonder how well the technology would scale up. Consider the major cost savings that could be realized for datacenters that rely on diesel generators as backup power sources. As fuel costs rise, and the need for backup power systems remains critical, saving money by generating electricity for extended durations on the cheap could be huge. Higher-efficiency generators could save datacenters a lot of money.

Another interesting technology is a more efficient battery system for the laptop that should last up to four times longer than normal PC batteries. It uses custom battery chemistry and intelligent sensor systems to get the better durability. Sounds like great news for the road warriors out there.

Networking
I’m especially intrigued by the wireless mesh network the laptops create automatically, with auto-routing capabilities for Internet access. The WiFi runs 802.11b at a reduced speed (max rate being about 2Mbit/s to save on power), and allows any laptops within range to communicate with each other. Interestingly, if any laptop has an Internet access connection, than all laptops in the same mesh network can share that connection automatically. I can easily envision a secluded community of laptop users, where one individual has a dial-up connection or other similar access, and the entire community of users can gain access to their email and otherwise access the Internet.

There are some interesting parallels between these mesh networks and much of the citywide WiFi projects being announced. Tropos, one company that develops a networking device for cities, creates a similar kind of mesh network for its devices – spanning an entire city or region. The idea is that one or multiple Tropos nodes have access to an Internet connection, and all other nodes can route users through the network to those connections, thus minimizing the number of pipes needed to “unwire” an entire city to barest minimum (and cutting costs, at that).

Technology Benefits
Much of the technology that’s coming out of the OLPC project seems to have applicability to the IT world as well, and I’ll be following the project closely. Actively solving a problem such as this can have great repercussions in many other industries, much of which hadn’t been intended in the first place. I look forward to seeing the OLPC project released, and the many lessons we can learn from it.

Once an Internet application is invoked, a whole series of events takes place. This article will be a simple introduction to how a packet is created and the various devices it will travel through on the way to its destination. Having an understanding of just what happens between point A and point Z can be quite helpful in furthering your understanding of networking.

I think the article gives a good sense of how incredibly complex networking really is. At each layer from the physical to application there’s an incredible amount of work going on, just to simply view a webpage. Networking is a good example of how powerful layers of abstraction can be. Each stage builds upon the last, while still creating an simpler interface for the next. It creates a sort of stack, with each stage being simpler and easier to use. At the bottom you have the physical layer, which would require a good deal of knowledge of physics and electronics to begin to comprehend. Yet once you get to the top you’re dealing with something as simple as typing “www.google.com” into your browser and hitting go. Much of the technology we take for granted today works because of these kinds of abstractions.

The article also mentions the differences between networking and programming. I think for both network administrators and programmers it’s very useful to have at least a passing understanding of what’s happening at each stage, each layer of abstraction. Whether you’re fixing a network problem or debugging a web application, you never know if you might be working with an application error or a broken ethernet link.