Jim Panttaja

Bob Zurek posted this annotated list of open source tools. Several that I am familiar with, but a few new ones as well: Open Source Tools For The Enterprise.

His comments on IM and the open source project Spark are interesting. He believes that IM will become more of the norm for communications – and Spark is a tool with very strong security, that should allow Enterprises to adopt IM for communication.

I have seen developers adopt IM as their primary interpersonal interface tool. The adoption in other pieces of the organization runs in to more resistance.

Yesterday felt like the first day of school. It was our first day in an “office” with our new company, RebelVox (www.RebelVox.com). We are still not in a real office, but the four of us are all in the same room (and not sitting at the same bench in South Park with our laptops out, or sitting at different tables at the Crossroads Cafe, interviewing people).

So we arrived with our laptops like other kids arrived with their lunch boxes or backpacks. We each claimed our desk (in this case, which couch or which stool). The good news is we already knew where we belonged for lunch – at the nerds table – and we know who the nerds are.

Yesterday the web site went up (at least a beginning one), the initial logo saw the light of day, we each received our phone number. You can check out the website and logo at www.RebelVox.com.

Today the highspeed network arrived – and perhaps later today, some

Now we have to get down to our lessons and our homework.

I came across this pointer in Guy Kawasaki’s blog to a great summary/taxonomy of data visualization tools and sites by Laura Fitton in Smashing Magazine. It includes references to Swivel and IBM’s ManyEyes which I wrote about in June.

Lot’s of pictures (examples).

I have been looking at database products, and found a couple of links (and a couple found me):

• EnterpriseDB offers an Oracle compatible product at a fraction of the Oracle cost. A colleague of ours, Bob Zurek is now their CTO.
• Not unrelated, EnterpriseDB is providing a Postgres Resource Center. Bob wrote about this in his blog.
• Encirq provides a very small footprint database for embedded environments. A former boss of mine at both Tandem and IBM, Steve Weick, is the VP and CTO. Steve has a great history with a variety of database products, including DB2, NonStop SQL, Informix and Cloudscape.

All are things I need to spend more time looking at.

Google has just released the ability to embed maps in a blog.

Here is an example of the trip we took in July and August.

The maps are easy to embed. Once you have created a map you like, click on ‘link to this page’. One of the options is a HTML to be copied in to your page. There are some Google Maps features that this won’t work with – in which case the text when you click on ‘link to this page’ is greyed out.

Last month, Scott Thurm wrote an article in the Wall Street Journal titled Now, It’s Business By Data, but Numbers Still Can’t Tell Future. The article discusses how a number of companies are managing by the numbers. But he points out, “Running a complex enterprise can’t be reduced to a spreadsheet, however.”

In the early 1970s I was working as a contractor for the Oakland Public Schools data processing department. I was writing (and fixing) Fortan and Cobol programs, supporting some old 1401 applications, and serving as a liaison with the statistics department. One September, enrollment took a dive. It was the first year that enrollment had decreased year over year. For a school district (as I recall Oakland was something like the fifth largest in the nation), declining enrollment is devastating to budgets. So they asked me to help them model (predict) what the next years enrollment would be. I spent a bunch of time using various curve fitting techniques to come up with the best estimate I could of the next years enrollment. The statistics department was thrilled – and prepared to take their numbers to the board.

The problem was – none of these techniques applied a year earlier would have predicted the decline that we saw. To me that proved that my methodology could not be trusted. The statisticians were happy to have an ‘answer’ and ignored my concerns.

That is not to say that I don’t like to look at the numbers. I love numbers. But I have learned to take them with a grain of salt.

Last Thursday, Skype had problems and was down for most of two days. There is an explanation on Skype’s website today.

There are a number of posts (look at the responses to the Skype blog) with various reactions to the blog – but I have to start by taking it at face value. Microsoft released their (monthly) patch release, and the rebooting that ensued – meant that all of the machines had to reconnect to Skype. That mass reconnection caused a failure in one of Skype’s algorithms.

At Sapias, we would see mini-versions of this when our network connectivity failed, or when there was a problem with one of our carriers. When connectivity was restored, there was a bunch of data (the size of the bunch directly proportional to the down time) that devices started to deliver to us – all at once. We would also see it every morning, as vehicles which had gone out of coverage the night before (with some drivers taking their vehicles home – out of cell range), came back in to coverage, and had some quantity of messages to deliver all at once.

Of course these things are better when they happen often (like our every morning load at Sapias). If they happen often, they aren’t unusual, and you know that you can react well to them. They are more troublesome when they are rare. Although some people are skeptical that the monthly Microsoft patch could cause this, I can imagine a case where that patch was unusual – and required some different level of restart. The key is that a company like Skype (and I aspire to having as many users as they have one day), has to figure out how to test for things that are very difficult to test for. Unless you have millions of internal users, or can simulate millions of users – with millions of machines, it is pretty hard to do.

It is another reminder that you can’t test quality in – you have to figure out in the architecture how to be bullet-proof. And regardless of how you test, there are always going to be cases that you didn’t anticipate. In this case, it sounds like Skype had algorithms to try to react to similar scenarios – but they failed. Perhaps another argument for not getting too fancy. Sometimes the fancy scheme is the one that fails.

So – time zones are simple. In the continental United States, there are four: Pacific Standard Time, Mountain Standard Time, Central Standard Time and Eastern Standard Time. Each an hour a part. The goal is to have all of us have a relatively normal ‘day’. With the sun rising at a reasonable hour, and the sun setting at a reasonable hour. Of course these don’t quite work. Boston (and especially the Cape) should really be in the next time zone over – but it is more convenient for them to be on the same time zone as the rest of the east coast. As a result – at the beginning of summer – the sun comes up about 4:00am.

But then – we got Daylight Saving Time. This meant that each spring, we set the clock forward an hour (spring forward), and then return the time in the fall (fall back). (This made the official sunrise on June 20th this year be a ‘reasonable’ 5:07am). The goal was to save energy – since much of our energy consumption is in the evening. If we made more of the evening be light outside – then we wouldn’t use as much electricity (See the Wikipedia entry for history – it ties the idea back to ancient Rome, to Ben Franklin, to a first failed experiment in the US during World War I, and then the beginning of adoption in World War II Time) See this page on the State of California’s web site, which references a study that showed that using Daylight Saving Time reduced the daily consumption of electricity is trimmed 1 percent.

So you now have Pacific Daylight Time, Mountain Daylight Time, Central Daylight Time and Eastern Daylight Time.

In the 1950s, the railroads didn’t use Daylight Saving Time. I grew up in Barstow, California. Barstow had the largest railroad switching yards west of Chicago. My baby sitter’s husband worked for the railroad. So in their house, the clocks all were set to Pacific Standard time all year. This added to a kindergartener’s confusion as I learned to tell time (and for you kids – this was when clocks had hands – none of this digital stuff).

But wait – there’s more. Arizona decided not to honor Daylight Saving Time. So Arizona stays on Mountain Standard Time through the suumer – which then matches Pacific Daylight Time.

Ah – but just when you understand that – and you are traveling on vacation through Arizona – you discover that the Navajo Nation (which is a large part of Arizona) does do Daylight Saving Time. And the National Monuments in Arizona (like Canyon de Chelly) run on Mountain Daylight Time.

I have gotten used to my cell phone/organizer (now an iPhone) handling time for me. It is set so that when I get off a plane in some random city, it syncs with the cell network, and shows the local time. On our recent trip, this has failed miserably. Nevada is PDT, Idaho is MDT, but at one point while in Nevada – I must have picked up an Idaho cell network – and phone shifted to MDT. And much of the time in Arizona I found my phone off by an hour (sometimes one direction, sometimes the other).

For many purposes on vacation – none of this matters. But knowing when things open and close (like the coffee shop, for example) can be quite crucial.

Managing systems that work across time zones – and had to work through Daylight Saving Time shifts is a challenge. Are there two 2:00AMs on a given day? Is 2:00AM before 1:30AM? Does the user want to see it in the vehicle’s time (at Sapias we tracked fleets of trucks), or the viewer’s time? As I was writing this – I was prepared to describe how Indiana has ny number of different ways of recognizing Daylight Saving Time (or not…) – but I discovered that a couple of years ago they fixed this. All of Indiana now honors Daylight Saving Time.

Mary and I always choose on the spring forward or fall back day – when we want to take advantage of – or lose – our hour. That works fine as long as we don’t have appointments on Sunday. And I need to make sure I am never in Arizona – and especially not in the Navajo Nation on either of those days – it would be too much to cope with.

Mary and I are sharing our calendars on Google Calendar, and now I learn that I can easily interact with Google Calendar via SMS (Brady Forrest post on OReilly Radar: SMS to GCal).

You can send an SMS to 48368: ‘next’ gets your next appointment, ‘day’ gets today’s appointments, ‘nday’ gets tomorrows appointments. ‘help’ gets a short description of these commands.

You can create events by sending an SMS to that same ‘address’. You can send phrases like “Family party Saturday at Sally’s at noon” – and it will figure out what you have in mind, and create the calendar event.

This approach is much easier than opening a web page, navigating to the right place, and picking menu choices. I now have a running SMS ‘session’ with 48368 (GVENT) – so it is easy to find on my phone.

Brady’s post includes a couple of other links for further information.

By the way, I have finished scanning through the electronic edition of iPhone the Missing Manual by David Pogue. I have the print version on order – but while traveling it was easy to zip through the online version on my Mac. There are a number of useful tidbits in here. There were answers to questions that I had asked (not that I asked David – but I asked the ether, and David came through) – and answers to questions that hadn’t occurred to me… If you have an iPhone in your life, you need this book.

Jesse Robbins at O’Reilly Radar has followed up on the outages at 365 Main. (I had written about this a couple of days ago: Hosted Data Centers and Outages). His post is a post mortem on the failure itself, and includes some commentary on the design approaches that 365 Main has taken.

The challenge in design and implementing architectures to deal with failure, is that often the complexity of the solution increases the likelihood of failure. One of the comments in my earlier post from Jeff Dao was that you should do a dry run of your solutions – simulate, or create a failure. But the more complex your solution, the more difficult it may be to simulate a failure – and in particular, the more difficult to simulate every failure scenario.

Having said that, in the case of 365 Main, it seems like they could have tested the three generators that failed to start up.