Wednesday, May 30, 2007
This summer, my boy Jacob and I are doing a little bit of light weight programming. I won't make him work 70 hours a week (he's got it so cushy!), in part because in this new web model, you can write some pretty cool applications without working 70 hours a week. The traditional idea of the Internet's Long Tail is that, since distribution of products is so much cheaper, you can provide a longer list of products that appeal to more niche markets. It also means that, since development is so much cheaper, smaller projects become practical. Practical in an economic sense, and practical from a skills sense. To wit:
Our summer project? I'm going escape from AOL mail. AOL mail uses IMAP, and doesn't support forwarding, which means it's currently impossible to read in Google Mail. More than that, when I forward the mail from my laptop client, it's not formatted right. Ick. I like Google Mail. I don't like AOL mail. And, I have had my AOL address for so long, that to move it would mean no end of grief. So, Jacob's using his new Python chops to read my e-mails from the IMAP mailbox and put them directly into my POP mailbox, which I read from Google Mail. I'm not sure that we can get the recipients right - but we're going to try.
I tried a couple of products like this on the Internet, didn't like any of them. So, Jacob's writing it for a customer base of 1. Now, that's a long, long tail.
Thursday, May 24, 2007
Well, Chuck, I want to introduce you to The Thomas Howe Company, the third company I have started. I am pleased to announce that my business partner and I have signed a lease on some space in Osterville, we've hired our first people, and most importantly, we've signed up our first four customers. In the coming weeks, we'll introduce ourselves to the world. Wish us luck.
Our mission is simple: we want to help our customers integrate real time communications with the business process. Why? Because it makes businesses faster, makes businesses more efficient and makes customers happier. How are we doing this? We take our own assets, including a yet-to-be-announced service and software components, along with our partner's assets and provide professional services to integrate them into our customer's infrastructures. Our customers? Enterprises of all sizes, especially in the healthcare and financial verticals. We long for the day that carriers will understand this new world of communications and offer it to their customers.... but I hope you'll forgive me if I seem dubious about that possibility.
To all of our friends, family, partners and well-wishers - thank you for all your support. We've appreciated it in the past, and we'll depend upon it in the future. If you are ever in Osterville, we'll buy the coffee.
Friday, May 18, 2007
It began back in 1981, when I was a freshman in high school. At the time, I had been programming in basic for a year or two, and I was learning C at my father's office at Raytheon. There were a few kids I grew up with who were geeks, and we really divided our group using two dimensions. The first was the platform, and I'm sorry to say that I was NOT one of the Apple guys. My mom bought this Tandy RadioShack Model I with 16k Extended Basic - so my lot was cast there. The other dimension was data. There were those of us who hung around the mainframe doing COBOL, and those of us who simply didn't. I didn't. My friend, Ed Kirwin pictured above on the right, next to my best friend Peter DiPippo, did. I remember giving him a good dose of grief about it, as I thought the real studs went into scientific programming. How hard could those data centered applications be? I still have the plaque from my father's desk that says "Forgive us our transducers, as we forgive those that transduce against us." Of course, Ed went on to have an excellent career at Oracle. And me? Well, I'm not willing to call this game over yet, Mr. Kirwin. I don't care if you are still the dungeon master.
I'm not alone in my data blindness. When I was the editor for the first draft of the ADSL Forum's Internet Access Specification, it was clear they were giving it to the young guy because the Internet was the least important specification they had. (Video on Demand was the killer app. Ooops.) The Web model in 1994 was straight-forward. You clicked on a web page, the page streams to your server. One little tiny click up, one massive file of 100k down. ADSL was perfect for that, right? Lots of downstream bandwidth, a little upstream bandwidth. (Never thought of P2P, Flickr or Torrents. Ooops.)
Of course, now we are in a very different place with data. We are now in the era of the collaborative web... the programmable web... the literate web. For the vast majority of Web 2.0 startups, the data is what is monetized, not the functionality. From the (now famous) What is Web 2.0? article from Tim O'Reilly :
The race is on to own certain classes of core data: location, identity, calendaring of public events, product identifiers and namespaces. In many cases, where there is significant cost to create the data, there may be an opportunity for an Intel Inside style play, with a single source for the data. In others, the winner will be the company that first reaches critical mass via user aggregation, and turns that aggregated data into a system service.
If you feel like you don't have a good handle on Web 2.0 data, here's the video you need to see. It's only five minutes, and you really ought to take a quick look. As for me, I need to get off to work, and install that PostGres package for the new gateway I'm designing. I hope Ed is doing OK.
Wednesday, May 16, 2007
So, for all of you who have been asking, I've been programming my little heart out. Which is why I'm not blogging so much, as I can't seem to get my head shifted out of programming mode, and into blogging mode. Many dear friends have accused me (no so wrongly, apparently) of being single threaded in my work habits. Hmmm. Guilty, as charged.
Which really sucks, as I want to tell you all about the visit I had to 30 boxes, and the microformats work I've been doing, and all that happy stuff - but I will. I swear I will.
Now, if I can just figure out how to get that static pointer to my Postgres connection over to this other module without making it too much like a cludge....
Thursday, May 10, 2007
Perusing a blog tonight, I caught a post that made my jaw drop. Apparently, somebody recently patented the linked list. Seriously. Click the link.
Now, come on. What brain-dead patent lady let this one through?!? Mary Steelman. If you're that brain dead woman, and you are reading this blog, I'd like you to look to your upper left. That guy's name is Donald Knuth, and I am sure you have never heard his name. I am also sure that you aren't a degreed software engineer, because every software engineer I ever met in school studied his books. There is no accredited institution in the United States granting a degree in Computer Science that doesn't have "The Art of Computer Programming" as a text book in some class, somewhere. Not one. Not a single one. Aren't linked lists in, like, the second chapter? When did he write those books? Wasn't JFK still alive? I hate to call you out by name, Mary, but let's get real here. Donald's not mentioned in the prior art, anywhere. How did you miss this one?
Let me give you a hint for the future: google. What I claim is:
1) A method for discovering information on the Internet entitled "searching" for it.
2) A method for using Google, a search engine that you can use to "search" for information on the Internet.
3) A method for determining information about prior art, by placing the term "linked list" into "google".
4) A method for not looking like a complete fool by reading the very first link it returns, and reading the very first paragraph entitled "History" (See Exhibit A).
Linked lists were developed in 1955-56 by Allen Newell, Cliff Shaw and Herbert Simon at RAND Corporation as the primary data structure for their Information Processing Language. IPL was used by the authors to develop several early artificial intelligence programs, including the Logic Theory Machine, the General Problem Solver, and a computer chess program. Reports on their work appeared in IRE Transactions on Information Theory in 1956, and several conference proceedings from 1957-1959, including Proceedings of the Western Joint Computer Conference in 1957 and 1958, and Information Processing (Proceedings of the first UNESCO International Conference on Information Processing) in 1959. The now-classic diagram consisting of blocks representing list nodes with arrows pointing to successive list nodes appears in "Programming the Logic Theory Machine" by Newell and Shaw in Proc. WJCC, February 1957. Newell and Simon were recognized with the ACM Turing Award in 1975 for having "made basic contributions to artificial intelligence, the psychology of human cognition, and list processing".
Aren't patents supposed to encourage innovation by protecting the investments that companies and people make to develop them? Software patents like this subvert this principal in the most egregious way. I, for one, am becoming polarized against patents, not because I believe that investments shouldn't be protected, but because patents are granted in such stupid and ignorant ways.
And, no no no no no. Voice Over IP was not invented by VocalTec in 1996.
R,S,T,L, N and E Copyright (c), Thomas Howe. All rights reserved.
Wednesday, May 09, 2007
In a completely parallel thought, I've been learning Ruby on the side. I absolutely love Ruby, and it's good for this old DSP programmer to dive so deep into a very different world. Ruby is the language of choice for cutting edge Web applications designers these days, and breaks so many ingrained rules of design that it makes my head spin. (Excellent.) Ruby is opinionated software, and quite proud it. By opinionated, we mean that Ruby language designers and implementers make decisions that optimize their own personal productivity at the cost of generalization. From a recent interview on O'Reilly Radar, Ruby on Rails creator David Hansson, explains:
But let's focus on just one of the keys: Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility—the notion that we should try to accommodate as many approaches as possible, that we shouldn't pass judgement on one form of development over another. Well, Rails does, and I believe that's why it works.
With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I've embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level.
Isn't this interesting for the telecom industry? What sorts of decisions have we made about passing judgement on communications methods, products and services? If we could break the rules, and make radical decisions about how telephones are integrated into other technologies and processes, what new gains could we make?
One beautiful thing about the long tail is that, due to the radical lowering of barriers to entry for new services and to the widening of delivery mechanism, it doesn't take as many subscribers before a new service makes economic sense. You could indeed have a service that only 20,000 subscribers would pay for, but that might be a million dollar a month business, which would more than pay for three geeks in a room. And in this world of a billion cell phones, there aren't 20,000 who would pay for it? Yes, there probably are. Get opinionated. Somebody will agree with you, somewhere, and they'll see and pay for that value.
Thursday, May 03, 2007
The second project is an internal project we'll announce sometime later on in the year. For this one, we are using a hosted messaging backplane from Amazon called Simple Queue Service. (In fact, we are using nearly all of the Amazon APIs in the hosted version of this project, including the elastic computing cloud, simple storage service and, of course, the Turks.) Simple Queue Service, or SQS for short, is a simple, but extraordinarily powerful idea. SQS allows software to send messages between applications in a reliable and scalable way, using Amazon's hosted service. Messages are created by message producers, stored in the queue, and read by message consumers. Many different message producers may add to the same queue, as many different consumers may read from it. Amazon guarantees that a message is read at least once, and will hold a message for at least fifteen days. In practice, messages tend to be consumed nearly instantaneously, but it's good to know you've can go get a cup of coffee and not worry too much about missing a message. Messages can hold any data and, when combined with Amazon's simple storage service, can hold any data of arbitrary size.
An example might help here. Imagine you are designing a billing system for a large telecom carrier. If you have a switch creating call detail records, you could store those CDRs as an XML records in a local database. You could also take that XML data, and put it into an SQS queue to be read by a far end billing system. The billing system would wait for the XML record, and when it arrives, record it, bill it, invoice it, whatever. The calls to SQS are very simple and straightforward, and the service itself is quite inexpensive. Today's alternative implementation would probably use a standard such as Radius, which is supported in the billing world, has no traction outside of ISP billing in the Web world. SQS is a simple and straightforward alternative.
The advantages are numerous. First, since many producers can add to the same queue, you could use SQS to aggregate information from several sources. So, to extend our example, you could aggregate CDR data from many switches into a single outbound stream. Since SQS carries data only, different manufacturers can submit their XML into the queue without any impact to the billing system that consumes the data. Let's keep with the CDR example, and imagine that one of your twenty switches uses a different XML format than the other nineteen. Pretty simple with SQS. Create a piece of software that reads all of the XML from the aggregated stream, looks for the messages that need to be translated, translates and puts them back on the aggregated queue. Worried about the bottleneck? Don't be, as you can have as many instances of translators as you wish, as SQS guarantees that a message is read at least once, and if you wish, only once. The same argument is made for redundancy. You can have as may consumers or producers as you wish. If one fails, your throughput does drop, but the rest of the system is unaffected. (By the way, this is where the elastic computing cloud just rocks. Throughput dropping? Take 60 seconds to spin up a hundred or so servers to take care of it until you catch up, then give the servers back. Since a server costs about ten cents an hour.... well, you do the math.) This also makes components that hang off the message stream safer to deploy in production environments, as you can fractionally deploy components without affecting the core system.
The downside? Messaging backplanes do introduce a bit of delay into the system, and are probably inappropriate for communication between components where real time operation and response times must be guaranteed. As I think about the heuristics of real time design for web services based communications infrastructures, my gut tells me that the logical place for components is where real time communication is critical, where bottlenecks would occur, or where linear scaling is critical. Those components would then be best implemented in an Web Services, or SOA, architecture with messaging backplanes as the scaling and communication backplane.
We've been talking about Amazon SQS, which is undeniably the only reasonable hosted choice we have today. In a platform environment, there's a number of good choices ranging from legacy offerings from Tibco, down to the open source ActiveMQ offering. But honestly, the Amazon web services suite is so easy and inexpensive to use, it would take a lot for me to deploy my own platform. I suppose if you're Verizon, you could match the Amazon platform. Maybe. Either way, I expect to see communications architectures move from the inherently fragile legacy telecom designs towards new, service oriented designs, all on the backs of messaging solutions.
Wednesday, May 02, 2007
I am super interested about today's story about the Digg revolt, not so much about the story itself, but about the management reaction. The short story : some users posted the security key for unlocking HD-DVD movies, and Digg deleted them before the AACS Licensing Authority sued them. Users revolt, Digg capitulates and (apparently) are now awaiting the summons. Perhaps if they made no attempt to delete the posts in the first place, they would have a better argument about the lack of responsibility. The fact that they restored the key might be seen as an action equal to that of the original posters. I'm no lawyer, but I wonder if Digg ever signed a confidentiality agreement with the AACS (I doubt it), and I wonder if you could possibly copyright a 16 digit hexadecimal number. If so, I wish to copyright the letters R, S, T, L, N and E. Anyways, it appears as though the Digg management recognized that without the users, they don' t have a service, so as far as this goes... the users have the power. Lesson learned.
A smart, smart man once told me that marrying the right woman was like living in a greenhouse, where you would grow faster than in any other environment. Marry the wrong one, and you live in a desert, and your very existence is threatened. I have only worked at small companies, and almost exclusively inside startups. I started at PictureTel when it was clearly a startup, and my exit was a statement of how large it had become. My thought early in my career was that I wished to start my own company one day, so by hanging around startups, I would learn how to do it. As I've grown older, I see a richer truth : I grow faster in small companies. They are my greenhouse. At a small company, you are challenged from every side, every minute, every day. If you see my e-mail address change to "Mitre" or "Raytheon", please come to my retirement party... or should I say wake... because it will be a sure sign that I have stopped growing.
It was good to see the management team at Digg grow just a little bit. Victor Frankl said that life didn't have meaning, instead it asked you what your meaning was. I believe that Digg, and the management, have a deeper understanding of what their meaning is. Good to see they are living in a greenhouse, too.
R,S,T,L,N and E are copyright(c) 2007, Thomas Howe. All rights reserved.