Well, the time has come to move the blog off of Google, and on to our new site at The Thomas Howe Company. Pat and I will be posting to our blog there, and we're just going to let this one mellow with age. (I'm going to imagine that, in this allegory, I'm George because I'm shorter than Pat. Pat can be Weezie.)
Monday, August 27, 2007
Well, the time has come to move the blog off of Google, and on to our new site at The Thomas Howe Company. Pat and I will be posting to our blog there, and we're just going to let this one mellow with age. (I'm going to imagine that, in this allegory, I'm George because I'm shorter than Pat. Pat can be Weezie.)
Wednesday, August 22, 2007
Tuesday, August 21, 2007
The reason why I advocate Ruby is straightforward : it's what the cutting edge Web developers use. When I coined the term WITA, I wanted to emphasize that this was a Web integrated architecture - not an IP integrated architecture. By integration, I mean integration of culture - the way that the community approaches, understands and tackles problems. In order for telephony to spiral into the much larger market of the Web, and therefore into the Enterprise, it needs to be introduced into the culture of Web development. Ruby is the prime ambassador for this, especially on the cutting edge of development.
This will, undoubtedly, cause major headaches for telecom engineers, who by-and-large have no experience with Ruby. (Maybe this is the Karmic payback, as the Ruby developers have no experience with phones). However, when the Web mindset is adopted and understood, then Ruby becomes a natural language for its implementation and development. In time, it may become the lingua franca of Web development; certainly Web development over time will become the definition of programming and architecture. The successful implementation of WITA applications will require the adoption of this mindset. Personally, I have pushed myself down the Ruby road primarily for culture - so that I can learn Web development in it's native tongue.
I feel there is no point where this is clearer to me than when I consider IMS. As an architecture, IMS is clearly the son of the companies that advocate it: big vendors making big equipment for big carriers with big budgets. It is a product of the culture of carrier based telecom development. The essential issue is that IMS, although making claims to enable the deployment of innovative services, makes the implementation of new applications nearly impossible because of culture. It is unreasonable to think that development of high value, niche applications is served by ever larger architectures. It is implausible to think that, with a ratio of nearly ten Web developers to one telecom developer, that the web developers will toss Ruby for P-SCSFs and HLRs. I recall a conversation with Henry Sinnreich a few years ago, where he said that he loved SBCs, as they hastened the demise of carriers because they were wasting their money purchasing them, instead of deploying pure SIP networks. I wonder if IMS has sent him into some sort of Nirvana.
Ruby is about culture. WITA is about deploying telephony architectures where that culture rules.
Monday, August 20, 2007
I love my hometown on Cape Cod, and (I can't believe I'm saying this) when I see things like this, I wish it could hold more people.
As I'll reveal soon, the mashup contest fad is coming to our neck of the woods too. Have you ever stopped to ask why there are mashup competitions, but not VoIP design competitions? Sure, on the trade show floor they have some "best of shows", but we all know how that game is played. You don't see designs done just for competition in telecom, but you do in the Web / Mashup world. As an example, the 2006 Mashup camp mashup I liked was the blinking Google pin. Some geek took a blinker pin from the Google booth at a trade show, attached it to the serial port of his laptop, used the Google Mail API to check for mail, then it blinks the "G" when new mail arrives. So geeky. But why compete with mashups?
The knee jerk answer is: because you can. Mashups are pretty simple to put together, but more so, you can do pretty creative and impressive things with them. Mashups are more about imagination than shear technological prowess. Designing even the simplest of VoIP devices (say a phone) requires an impressive amount of time and money, much more than the typical engineer can afford. (Never mind skill set.) More so, designing even the simplest of VoIP devices for a competition is more than most companies wish to spend in time and money. Therefore, the marketing kick or product risk doesn't make sense for traditional services, but not so for mashups.
The business answer is: because every Internet technology has a long tail. Amazon proves that products have a long tail. iTunes proves that music has a long tail. EBay proves that junk has a long tail. Mashups prove that Web services have long tails. Telco Mashups prove that telephony services have long tails. And that's stunning, because it means that we finally have an environment in which we can create new services. After all our efforts since the divestiture, it comes down to the simple fact that single greatest reason that new services often fail is not because people don't want them, but they were too expensive to develop and deploy for the masses. When they are inexpensive enough so that you can make one just for yourself, then people develop them just for themselves, or rather, just for mashup competitions. Just like iPTV, if you can make a video in your house that ten thousand people want to see, it makes complete sense to make it. NBC needs what, a million viewers to break even? If you have ten thousand people who will pay ten bucks a month for your find-me-based-on-my-facebook-whatever service, you and your two technicians will make a living. In the grand scheme, a good one too. Mashup competitions are, for me, prima facie evidence that Telephony has finally found its tail.
Wednesday, August 15, 2007
What's even better, though, is that these bloggers have readers, and at least some of those readers are just like me : telephony guys trying to create cool things that people will use. Each of these guys recognizes that telephony engineers have a new tool in the box : mashups. And hopefully, because of this sort of light weight programming model (I call it the anti-IMS), the wider world of engineers have a new tool in THEIR box : telephony. Telephony was once heavy weight, now it's light weight. Telephony used to be capital intensive, now it's pay-as-you-go. Telephony integration used to mean that enterprises would buy telephony equipment and integrate it, now enterprises can integrate with hosted, online solutions. Telephony mashups provide the right sort of light weight programming models that finally lower the barrier to integrating telephony with applications that will allow all engineers, not just us deep telephony geeks, to include telephony in the application.
Sure, there are a bunch of tools in our tool box, but for me, mashups are a keeper.
Rapid Apps on Rails:
A discussion about the impact of Ruby on Rails, Ajax and other tools that aid the developer in building new services rapidly and how combined with Amazon and Level services represent a new era in service deployments.
This is a discussion that looks at how the Enterprises are finally gaining the ability to provide services across a network and how it changes service models.
According to Cisco its working. Social networks are eating up the bandwidth and the Internet is again growing. What makes these services compelling and who is going to gain from these changes.
The New Age of Communication
We have talked about the concept of these new services now lets look at some of them and lets talk about why this is the perfect time to
offer services in the marketplace. Is the price of rollout so low that adoption can be small and niche, or do we all need massive viral adoption?
New Services with old lines
Single Number is thing of the past, now we have disposable numbers and with the ILECs having to watch the Cable companies expand into their space the time may be ripe for these kind of services. Best of all by extracting the person from the number the service is much more intriquing.
As you might notice, there's only five topics here. That's where you come in. Not only are we looking for audience participation during these five sessions, but we need to hear what you want hear at the show. Do you have an idea for a topic that's not here? What problem are you trying to solve? Something you really need to learn? Spit it here, and we'll talk about it there. Bring your two feet with you, participate, and let's make this worth more than our time.
Tuesday, August 14, 2007
If you haven't visited ProgrammableWeb (which is to say, you haven't written a mashup or web services based application), here's some places you ought to look at real quick:
- Let's say you want to see what APIs are out there to write your application with. Here's a list of all of them.
- Sure there are five hundred APIs, but which are the popular ones? Here's a great twist - mouse over the matrix, so you can drill down and see all the advertising mashups written using the Google AdWords API.
- What's a mashup? You can check out the two thousand, two hundred and twenty listed here.
- Do you think mashups are simply cool sites that have no business value? Check out the markets section of the site for another opinion. That's where we live, next to shopping and mapping.
THOMAS HOWE COMPANY NOW IN PARTNERSHIP WITH PROGRAMMABLEWEB
Award-winning consulting firm and application developer shares business communications solutions with ProgrammableWeb's online mashup community
W. BARNSTABLE, Mass., and SEATTLE - Aug. 14, 2007 - The Thomas Howe Company, a leading designer and developer of interactive voice and data solutions for businesses, has been named as a premium content partner for ProgrammableWeb, the leading web site for mashups, APIs (application programming interfaces) and the new "Web as Platform" approach to site development.
As a content partner, The Thomas Howe Company is providing expertise in the form of communications mashups, original articles and other materials that are posted in a new channel of ProgrammableWeb.com under the "Mobile/Telephony" section. The content will focus on telephony and mobile web services, APIs and mashups.
"Thomas Howe and team have an entrepreneur's knack for hunting down business-oriented APIs and an engineer's skill for putting them together," said John Musser, founder of ProgrammableWeb.
Howe was the first-place winner of the recent telephony mashup contest sponsored by O'Reilly Media and data-services provider StrikeIron. His entry, "After Hours Doctor's Office," transcribes office voicemails left by patients for doctors into text and then sends them via SMS to the doctor. A case study of this mashup is one of the items posted in the new section of ProgrammableWeb.
"At The Thomas Howe Company, we're interested in building real-time communications systems that help our clients save money while also increasing the quality of service for their customers," said Howe. "I hope that by sharing the information we have found useful, along with details of our own experiences, it will drive further creative thinking within the growing mashup community."
To view content from The Thomas Howe Company on ProgrammableWeb, visit www.programmableweb.com/telephony.
Friday, August 10, 2007
Wednesday, August 08, 2007
That said, my personal list of geek gods includes :
- Henning - One of the three writers of SIP, currently a Columbia Professor. (Just like Madonna, Sting and Bono, Mr. Schulzrinne needs only one name)
- Doug Tucker - CTO of Ubiquity, and in my opinion, the whole and complete package. He even took Kung Fu back in the day. Gotta love the dangerous geeks.
- Mark Reid - Editor of H.245, big shot at NMS and a perfect technical manager.
- Brough Turner - Long time CTO of NMS, long time leader, long time VON show dancer.
- Eric Burger - Interim CTO of BEA, founder of Snowshore and instantly credible in any room.
- Daniel Biage - CTO of Versatel Networks, old school engineering at it's finest. Go to Quebec to learn how to deeply care about what you do.
- Jeff Bernstein - Founder of 2Wire and PictureTel, really nice, really smart. Really nice, too. God is he smart.
- Dan Petrie - Independent Consultant and smart guy at PingTel, among the first to "get it"
- Ed Bassart - Founder of ShoreTel, been at it since the beginning, and deeply smart.
Tuesday, August 07, 2007
From their site :
Amazon Flexible Payments Service (Amazon FPS) is the first payments service designed from the ground up specifically for developers. The set of web services APIs allows the movement of money between any two entities, humans or computers. It is built on top of Amazon's reliable and scalable payment infrastructure.
Amazon FPS offers developers unmatched flexibility in how they can structure payment instructions, including standing instructions that can remain in place for multiple transactions. These instructions impose conditions and constraints on money movements and can be set by both senders and receivers of funds. For example, a sender might set a spending limit per week for a particular named recipient. Only that named recipient would be able to withdraw funds and only up to an amount per week equal to the spending limit. A piece of FPS functionality called the GateKeeper automatically enforces the constraints you set with payment instructions. When the sender or receiver is a computer system, payment instructions are set programmatically using APIs. FPS also provides a simple set of user interfaces that humans can use. From the users' point of view, they simply see terms of service and a request to accept those terms.
You can use the extensive feature set of Amazon FPS to conduct a wide variety of transactions under virtually any set of constraints. Key features include:
Send and receive money using credit card, bank account or Amazon Payments balance transfer as payment methods.
Create "Payment Instructions" to define conditions and constraints desired for a given transaction, and programmatically obtain payment authorizations or "tokens" that represent these Payment Instructions from customers.
Execute one-time, multiple, or recurring payments on behalf of customers.
Aggregate micro-transactions into a single larger transaction using Prepaid and Postpaid capabilities.
Build payment applications where you are neither the sender nor the recipient of funds. You can build marketplace applications that enable the movement of money between two third parties.
View account balances, transaction histories, and transaction details on the Amazon Payments web site.
Utilize the Amazon FPS sandbox to build and test applications without using real money or incurring any transaction charges.
Monday, August 06, 2007
Let's take a look at each of the three major parts of a Web Integrated Telephony Architecture (WITA) in depth. WITA contains three basic architecture blocks : a voice scripting front end, a Ruby on Rails back end, and a collection of web services to implement telephony applications. Today, I want to talk about the scripting front end.
The scripting front end provides the user interface for the user. User interfaces may be implemented through traditional web applications or desktop clients, but WITA applications typically use as a primary interface a voice scripting language such as VoiceXML. The VoiceXML script acts exactly as a web site, but instead of filling in forms, you use your voice to fill in forms to be posted to the web site. Instead of reading web pages produced by the site, the VoiceXML script will read the results back to you. VoiceXML scripts can be localized as web pages do, and can speak the native language of the caller. Different views into the application can be rendered to the user by either a voice menu choice (analogous to web site navigation) or through different dial in numbers or SIP addresses (analogous to using different URLs). In general, the scripting front end doesn't provide much in the way of call control, as the telephony features are implemented using the web services back end.
- Interfaces to the user through any telephony device, either from the PSTN to SIP. Can use natural language recognition, DTMF detection, or some combination of both.
- Interfaces to the Web server back end (typically implemented using Ruby on Rails). Fetches VoiceXML forms based on inbound dialing information. Presents data to user as provided by Web server back end. Collects data from user as a form and uses HTTP POST to save on server or to cause some action.
From a human to scripting standpoint, the scripting front end scales linearly with use. You need as many ports of inbound scripting as you have inbound callers. It is unimportant if each of the scripting ports come from a common source, as the scripts have no interaction with each other. Thus, you can use an arbitrarily large number of scripting engines (either hosted or platform) without any architectural impact to the application. Voice is not typically passed from the VoiceXML platform into the larger Internet, so quality of service issues are not typically important at this level. From a scripting to Web server standpoint, common and well known Internet scaling techniques of load balancing, server replication through DNS, etc, are fully available to the system engineer. No additional nor unique requirements are placed on the Web server farm in the WITA architecture.
In terms of business scaling, the WITA front end may be completely functional using a hosted provider (see below) at only a dime or so a minute of use. These hosted providers will be happy to scale with your application, or you can choose to deploy with a platform solution. Platform solutions typically make sense only for large or sensitive installations.
There are many hosted suppliers of voice scripting. My favorite happens to be Voxeo, because they have excellent service, they are well adopted by larger corporations in the US, they are price competitive and I happen to like those guys. There are a few other good choices as well, including BeVocal, TellMe and Angel.com.
For large corporations, there are a number of good options for platform solutions such as Convedia (now Radysis), Snowshore (now Cantata) and Voxeo (another reason I like them). In large measure, VoiceXML scripts are pretty portable, and only small code changes should be required when moving from hosted solutions to platform solutions.
Friday, August 03, 2007
As I've said in the past, instead of complaining, I'm committed to helping out at this year's VON show, and as part of that, I'm taking a pretty active role in the "Unconference" potion of VON. More about that later, but as part of that, Carl and I thought that a real cool thing to do was to show the audience, in real time, how much the new web technologies change the game for new services development. Sometimes, you just gotta see it. So, we're going to show you.
I'm planning a two hour session where we are going to develop, from scratch, an WITA (Web Integrated Telephony Architecture) service from scratch, in front of the audience. Three of us are going to work together on each of the major pieces : a scripting front end, a Ruby on Rails framework and a number of web services below us. As we work, we'll work out something were either the developer is explaining it as he goes, or another talks as he works. At the end, it will be an application that not only works, but can scale as high as you want it to - just like a web site.
The application? I like this one : my mother's memory is failing her. I'd like a reminder service that will call her cell phone with a voice message sometime in the future. For instance, you call a phone number, give your Mom's phone number, a voice message, and a time when you want it delivered. Maybe somebody will have another idea that's better, but that's what I got.
For you, if you don't really know how Telco mashups work, or what they look like, or why they are so revolutionary, come and join us. Grab a beer, kick off your shoes, and watch.
Wednesday, August 01, 2007
So, I'm not going to go into too much depth here about our conversation. Andrew promised me my own Ooma box to play with, and I'll give you an honest appraisal of it when it arrives. We couldn't talk long (as my cell phone kept dying), but I frankly didn't hear anything from Andrew that was earth shattering from a business perspective. I hope that Andrew's sudden "I have to go" response to "Tell me why your customer acquisition costs will be substantially less than Vonage's" was about schedule, and not about an uncomfortable question. We've planned to speak again after the box arrives, and I'll tell you how that goes.
No, what I want to mention is a good Ooma feature. According to Andrew, one Ooma feature is that when you are on the phone, if another call comes in, the other phones in the house ring. I love that feature - and I'll tell you why. It's a feature that doesn't require customer education, and doesn't require the customer to change his habits : the two killers of value added services. And, as Andrew rightly states, it works almost by surprise, which might be the best way that consumers learn about their product.
The second reason why I love that feature is because I'm getting excited to see some good engineering. What I mean is, I can't wait to see how they pulled that one off without causing serious head-aches for the installers. Near as I can tell, you need to drive each wired phone in the house independently to pull this off. If you had a multi-line wireless phone driving your house, it would be pretty easy, I suppose, but how many people have that? Typically, don't those Comcast installers cut the main line into the house, and then drive all the phones from their set top box? I don't think most houses have a system where all the wired phones go to the same place in the house, then are bridged together. Andrew told me these guys are the best in the business. I am truly excited to see how good their product is, and how innovative their solutions to problems like this will be.
Tuesday, July 31, 2007
Abramsky speculated that upcoming iPhone software updates would include new widgets, peer-to-peer applications (chat, picture messaging, social networking), location-based services, MMS support, home networking, and possibly some integration with Mac OS X Leopard.
"No word however on integration to Microsoft Exchange," he wrote. "It appears to us that Apple, classically, has more pleasant surprises in store for iPhone fans and investors."
After speaking with Joswiak, the analyst also made changes to his predictions for future iPhone models. Although he spoke of "higher resolution" iPhones earlier this month, Abramsky now says he expects Apple to differentiate its iPhone lineup not by features, but by price and memory capacity. The move, he explained, would be similar to how the company grew its iPod lineup, simplifying market positioning.
"This affirms our view of a lower priced ($349-399) iPhone [in the fourth calendar quarter of 2007 or first calendar quarter of 2008], with a higher priced version at higher capacity, to expand its market opportunity," the analyst wrote.
I personally find this fascinating, as Apple plans to differentiate the iPhone not by features, but by price and performance. If you recall, for most of era of competitive phone service, market success was found only through variations in price, as the basic service was essentially feature complete, and value added services had benefits which were only marginally valuable. Could it be that Apple has already caught on to what took telecom 100 years to understand?
Monday, July 30, 2007
- Voice XML: WITA uses VXML to handle inbound interactions with human beings, and most outbound voice messaging applications use VoiceXML to make those messages rich an interesting. The VXML scripts are delivered by a web services application, and post the inputs the collect to a web services application.
- Ruby on Rails : WITA uses Ruby on Rails to implement the web services application. It's responsible for putting the logic on top of the database, and for rendering views to the user in the form of VxML scripts, Web Services APIs and graphically intensive web pages.
- Telco Web Services : WITA uses telco web services to deliver telephony features such as outbound messaging, conference calling, click to dial and SMS messaging. These web services are called from the Ruby on Rails frame work, and provide the scaling and reliability components of the architecture.
Wednesday, July 25, 2007
Ok Thomas I'm prepared to step up and take that bet from you, easy money in my books.Now, since they've raised a bazillion dollars, there's no reason why they should EVER go out of business, so we'll need a better measure than the doors closing. That aside, I'm up for this bet, partly because I think it will be fun, but partly because I love dinner in New York. I'm betting that ease of use, ease of implementation and ease of uptake will spiral into the ground because it's simply not that valuable to the target customer. I say we pick a number of Ooma subscribers, and let's see if they go over that number. I'm not going to suggest that Ooma get a five million subscriber number, like the iPhone - or even a moderate number, like a million, that Vonage had. Can anyone think of a good metric? Outside of dinner, it's not that I'm hoping for Ooma's demise. In fact, I'd be tickled pink for them to succeed. My breath? Not holding it. I'm just hoping, just like many others, that this is the last effort at a business model that seems to fail nearly every time it's tried.
In 12 months from now I bet that Ooma will still be in business and am prepared to wager a dinner here in New York.
Reply post here to your blog to accept so we have this on public record.
It may be because of some of the consulting projects I've been involved with here at www.Cognation.net but I think Ooma have capture some very interesting aspects;
1/ Ease of use and design (so sorely lacking in a large number of basic projects I see) their ATA is 'the' best ata I've seen, nothing revolutionary but it's just well designed plain and simple.
....and whats dissapointing about this fact is that with all the brains in the voip industry no one else came up with this design until now.
2/ Ease of uptake (keeping original number is such a barrier to entry to skypein and similar - yes I'm looking at you Grand Central).
3/ Ease of implementation in their business model (peer to peer using existing ethernet/internet infrastructure with zero billing - how easy is that).
Like I said easy money and I look forward to accepting your bet.
I'll set up a page on the www.cognation.net website to track developments over the next 12 months.
To use voice in a compelling way, recognize that voice is a spice, not a main ingredient. Voice and other real time communications brings out the flavor in some other application, but it isn't the star. A compelling application starts with solving a real customer problem, and unless your customer happens to be a telco, carrying voice probably isn't the issue. The issue is something else. Take any vertical and check to see if I'm right. Here's a classic example: entertainment. American Idol had an innovative idea, which was to make a TV show where the people emotionally enroll in the outcome. If you think about it, it's just like sports: people watch because they care about their team. But how did they deeply involve the audience? They made them vote. How did they make it compelling and unique? They made them vote using text messages, which made the process unique and pandered to their core, young audience in one fell swoop. Brilliant. Compelling.
Why do we have such a voice services focus? My bet is that telephony has been so hard, for so long, that the people involved only know the telecom industry. We don't know the problems faced in other verticals because we've been so focused on the problems in ours. I bet you that if you spent just the smallest amount of time looking at transportation, or financial services or education, you'd find all sorts of places you could sprinkle basic communications into the mix to make it more delicious. Because we haven't done that, Jeff's food is bland and boring. He deserves better, you deserve better, and most importantly, customers deserve better.
As with many powerful tools, blogging services can be both used and abused. The ease of creating and updating webpages with Blogger has made it particularly prone to a form of behavior known as link spamming. Blogs engaged in this behavior are called spam blogs, and can be recognized by their irrelevant, repetitive, or nonsensical text, along with a large number of links, usually all pointing to a single site.
Shoot. You know you're in trouble when even a Google robot thinks that your posts are irrelevant, repetitive or nonsensical. Did I say that they were irrelevant, repetitive or nonsensical?
Monday, July 23, 2007
Is your business selling aspirin or penicillin?
Is it aspirin? Does your customer have a headache, and if he would just take your product/service, he'd get rid of it? Does your customer have achy muscles, and a few pills would put him at ease? Or is it penicillin? Does your customer have a life threatening illness? Is he more than uncomfortable, more than achy? Is he truly sick, and in trouble? Without your product, how in trouble is he? I'm sure it is obvious by now, you want to sell the anti-biotic, not the analgesic. If you avoid taking aspirin, you can get through the day. It's optional. If you avoid taking your penicillin, you might not have another day.
So, let's take that filter against today's whipping boy, Ooma. Is there any customer in the world to whom Ooma will be penicillin? (Not from where I sit.) And if so, would the medicine be generic? (Yup).
Ok - that's the easy part. Why is this so? I firmly believe that Ooma is aspirin because they have a horizontal product in an unregulated space, and it's really hard to differentiate the service to create any sort of brand loyalty. Outside of branding, horizontal products and services very, very rarely have points of competitive advantage other than price. In an unregulated space, businesses and consumers have choice. Although every business or home needs phones, they don't need Ooma phones. In phones, it's hard to make a brand. Apple is going to have the best shot of anybody, ever, of doing this, and the jury is still out.
Simply put, Ooma, and every company like it, sells aspirin, because it's an aspirin market. The basic issue with Ooma, and the cap on their success, isn't the team, or funding, or even their feature set. The basic issue is in the market they pursue.
Is your business selling aspirin or penicillin? Here's a hint - the first step is to find the market where the customers have a fever.
Friday, July 20, 2007
Thursday, July 19, 2007
Wednesday, July 18, 2007
Tuesday, July 17, 2007
It's not unique enough because the cost to establish a carrier is effectively zero, and the flip side of being able to offer the service to anyone is that all your competitors can too. Other than price, I have yet to see any land-line or VoIP carrier truly differentiate a service. These days, and IMHO, only GrandCentral, Iotum and the new iPhone actually make telephony services that are differentiated and valuable in a mass market. And none of those is a carrier, per se. If you were to measure brand loyalty for VoIP services, you would not need all the numbers on your keyboard, since it's practically zero. Number portability is the only sticking power of a telephone service these days, and that has nothing to do with brand.
I remember reading a book about entrepreneurship a long time ago, and I think the first or second rule was to methodically grow from a profitable base business. Exactly what was the profitable base business of SunRocket? Do a little test, and pick a handful of long term, substantial companies on your favorite stock market. Can you identify what their small, profitable base business was? I bet you can find it out. They nearly all have it. Is it all surprising when you see a company fail when it tried to make up with high volume what they couldn't make in margin? And unfortunately, this is the lot of VoIP carriers, and from where I sit, forever will be.
Friday, July 13, 2007
Adhearsion is a Ruby library that takes over Asterisk's internal processing of calls and puts them into the Ruby framework. You setup the dial plan of an Asterisk server to forward all calls to the Adhearsion server, either running locally or an a remote server. Once the call hits the Adhearsion server, you have the call in Ruby Land, and the world is your burrito. What can you do from there? Tons. You have at your disposal all of the Ruby integration with databases, UIs, web services calls, etc.
An example would be a hyper dial plan, that would connect calls, but also provide a gateway out to a Web Services function that would retrieve the latest weather report. Here's what it looks like :
#This is an example extensions.rb file which
# would handle how calls are processed by
# Asterisk. This is all completely valid Ruby
callee = User.find_by_extension extension
unless callee.busy? then dial callee
when 111 then exec :meetme
play weather_report('Dallas, Texas')
play %w(a-connect-charge-of 22
Now, here's a proof point. When I was at the Cluecon show, I told the crowd about the demonstration application I wrote to do a daily collection of body weight for Congestive Heart Failure cases. As I was describing it to the crowd, Jay - the author of Adhearsion - implemented the same application in Adhearsion as I was speaking. It didn't have the insane scale that my Amazon EC2 and Voxeo implementation did, but it was an amazingly complete implementation. Completely impressive stuff. Check it out.
Wednesday, July 11, 2007
What's a Chumby? It's a mashable toy. A chumby is a Wifi Enabled stuffed-animal, alarm clock, picture frame hybrid thing that you can put next to your bed (or on your desk, in your living room). It's always connected to the Internet, and displays whatever you would like it to from the Web - pictures, news, photos, weather, whatever. When you receive one, you set it up with a playlist of widgets from their web site, and off you go. Chumbys go for less than $200.00 and don't have any monthly fee. Now, I'm sure that at least three of my four kids will want one (they might not get one, but the want will be there), but why do I want one?
It's mashable. The chumby is open, and the fine Chumby folks make the hardware and software specs available to you. I would like to purchase one for each member of my extended family, then make a flickr channel with the family's pictures (from my four brothers and sisters, and their family) so that we could have a distributed family picture slideshow for everybody. How about taking the top 100 songs from each of our iTunes playlists and making the Howe Channel for music? How about using some client of our cell phones with a giant Google Maps where is the Howe Now?
The deeply amazing thing about lightweight programming models is how they radically expand the set of people who can create new services, and therefore the new services they create. I want all my engineering friends to have the Chumby mindset, so we can dream more and be disillusioned less.
Tuesday, July 10, 2007
I'm really happy I'm not running Nokia's handset division right now.
Xeni Jardin:Snip from Reuters:
Apple Inc. plans to launch a cheaper version of the iPhone inthe fourth quarter that could be based on the ultra-slim iPod Nano musicplayer, according to a JP Morgan report.Link
Kevin Chang, a JP Morgan analyst based in Taiwan, cited people in thesupply channel he did not name and an application with the U.S Patent andTrademark office for his report dated July 8.
Apple filed a patent application document dated July 5 that refers to amultifunctional handheld device with a circular touch pad control, similarto the Nano's scroll wheel.
Monday, July 09, 2007
I caught a link from mashup meister John Musser from Light Reading called Telco Web 2.0 Mashups. In it, Caroline Chappell speaks about the impact Web 2.0 technologies are having on IMS deployments in her new report. I think Caroline what has is mostly right from a technology standpoint, but misses on some critical cultural points. For instance, the mashup phenomenon has, at it's core, this idea of the perpetual beta. Without regard to how mashable the carriers make their offerings, it won't make them any more fleeter of foot. That said, I am in complete and violent agreement with Caroline, and I hope my industry has the good sense to listen to her advice.
Now, if I were to brag, I'd point my readers back to something I wrote nine months ago....
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.And when I read it, I remembered thinking : "Oh yes, that's part of the reason social networking is such an excellent idea. Since there's a bunch of information that exists between contacts, not simply IN the contact, there's real value in owning the data. " For instance, the service can tell you when a classmate joins the service, so that you can be connected.
Now, here's what I'm looking at. LinkedIn has something like 11 million users, and nearly all the fortune 500 is represented in that group by at least one leader. It's a big group, and it's a well known group, especially to business users. If there's a mass exodus to Facebook, doesn't it sort of suggest that the creation of these large databases of information isn't THAT hard to replicate? That the Web 2.0 promise of monetizing hard to replicate data using other people isn't as valuable as we thought? Now, if LinkedIn keeps going, and keeps going up in membership, we'll know just how valuable that data is. If not....
Friday, July 06, 2007
- I'm reading Garrett Smith's blog about the bad signs from SunRocket. SunRocket has shut down their affiliate program, and admits to owing commissions to their partners from March, and can't guarantee when they can pay. Ouch.
- I'm following Andy's blogs from France, as he prepares to tie the knot. I think that the South of France might just be the only place in the world prettier than Cape Cod in the summer.
- I'm waiting for my iPhone to arrive this afternoon, so by next Monday, my friends can stop asking me why I haven't mashed it up yet.
- I'm wondering how the h*ll Moshe got that close to Joanne from Rocketboom. I tell you, there's no justice in the world. Joanne might be the prettiest thing in the world other than my wife on Cape Cod in the summer.
- David Galbraith has me laughing and rolling on the floor with his iPhone meets the book of Job article.
- It may be the 114th year that the Cape Cod Baseball League has played, and it may be that 1 in 7 MLB players are alumni, and it may be that this all-free, all-volunteer league is the best and last place where the true game of baseball is played, but I'm just waiting for Sunday, where I'll get to sit at a Kettleers game and talk the night away with my kids. I think Jon should get his Canadian butt down here and join us. Bring the beer, Jon. It's summer on Cape Cod.
Thursday, July 05, 2007
There's a large number of providers today that you can sign up for to send text messages. I use Strike Iron's Global SMS Pro, because it's reliable, easy to setup and and simple to pay for. Sending text messages, however, is a much easier task than receiving them. Since text messages use the PSTN's SS7 network, it's a pain not only because of the equipment requirements, but the regulatory requirements. Signing up to receive text messages is a commitment and an investment, and typically costs over a thousand dollars to register your inbound number (called the short code) and a over a thousand dollars a month to maintain it, and that's before you start paying for traffic. Sending is typically much cheaper, since you only pay your ten cents or so a message to your provider.
This is where 411Sync's service comes in. 411Sync provides the developer with a free, and fairly easy, way of accepting inbound text messages. The 411Sync service provides a freely customizable way of enabling mobile search, but you can extend it to whatever your needs are. When you send a text message to the service, you specify a keyword (such as 'red_sox_score') and whatever parameters you desire (such as 'today'), and it will pass it to a standard Web CGI script that you specify when you create the keyword. Your program takes the parameter, calculates an answer, and passes it back as a formatted RSS or Atom message. 411Sync passes that answer back to the phone, with an ad attached. In our Red Sox example, if you sent a text message to 411Sync of red_sox_score today, it would respond with something like Red Sox 10, Yankees 0. You would register a program with red_sox_score, and it would be called with the parameter "today".
The business example? How about mobile workforce automation, with the target audience being a service technician. After you finish a job, you could send a message to your service like "wrico tom 5083649972 complete". Tom would be the technician's name, and the number would be the contact number of the job, and the keyword would tell the front office that the job is complete. The CGI script might record the time spent on the job for billing purposes, then as an answer, provide the address of the next job. In fact, for mobile status reporting, 411Sync is the best, and cheapest game in town. Check it out.
Tuesday, July 03, 2007
- Technically, I'd give them a B. They could be an A, and I think nothing hard is stopping them from getting there. Give me a more mature contact management solution, I'll give them a B+. Give me a good API, they earned that A.
- From a business standpoint, I give them an A-. The service is valuable, and over time, because of their social networking angle, hard to replicate. I don't see them charging money yet, but they could.
- From a buzz standpoint, a B+. I'm buzzed about them, and think they have great things in front of them. In the circles I travel, Jott isn't spoken of with awe and respect, but they should be. It's a great idea whose time is come.
Monday, July 02, 2007
Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.Ruby is an optimized language that allows programmers to write code, really really fast. Ruby on Rails is a framework for writing database backed web sites, really really fast. Using Ruby on Rails, you can literally make a database backed blogging web site in fifteen minutes, including complete access to your data model : create, read, update and delete (CRUD) with complete validation. Don't believe me? See for yourself. Using Ruby on Rails, you can create a web site that will allow you to browse Flickr sets in five minutes, using Ajax. Don't believe me? See for yourself. Is Ruby hard to learn? No, it's actually a joy. It's so easy, why don't you spin it up in your browser and take ten minutes to learn some.
I wanted to call your attention to Ruby and Ruby on Rails because it's fast become the standard implementation language for the Web 2.0 community. Companies such as Twitter and Basecamp, use Ruby to implement their sites, and we at the Thomas Howe Company use Ruby to create nearly all of our applications, and are using it for our new service. When I learned about Apple's iPhone development strategy, it was clear that they were telling us to use Ruby for the development.
There's downsides, as it runs pretty darn slow. In the great computer language shootout, Ruby comes in nearly in last place. How slow is slow? Ruby runs three times slower than Python, and about 60 times slower than C. However, there's some things to mention. First, it is getting faster all the time. I know I'll get slammed for being impertinent enough for saying so, but Web sites really don't have the same performance requirements of DSPs. And there's always EC2. Besides, as you grow past a hundred thousand subscribers, and you need five servers for your application, that's called a good problem to have.
Thursday, June 28, 2007
I was lucky enough to catch the end of Teltech's presentation at the Cluecon 2007 show in Chicago, and I heard about their new service called LiarCard. Essentially, Liarcard listens in on phone conversations, and detects if one of the parties is lying. Honestly. (Oh God, could this get bad, quick.) You arrange a call through Liarcard, and it records the conversation and then uses voice analysis to determine the probability of dishonesty during the call. You can even go back afterwards and tell which parts of the conversation were more dishonest than others.
Is it accurate? Well, according to them it is :
Essentially, if the quality of the voice is reasonably good and the operation and preparation is proper, the emotional analysis component will be almost 100% accurate. In this case, the technology will properly present how the tested subject is feeling in terms of emotional charge, cognitive conflicts and general stress ("Fight or Flight" syndrome). If the intention to deceive is genuine and this poses jeopardy on the tested subject, (assuming the tested party falls within the standard range of "sanity" or "normality"), then the Inaccuracy and Lie determination will also be accurate more than 90% of the time. (In the latest field research study conducted on 500 passengers in an airport, LVA -the security version of the technology- was able to render an overall accurate analysis in all 500 cases.)Ok - I'm not sure if this is the most amazing service I've seen, or the most disturbing, but I'm sure that Liarcard could read my emotional response. Hmmmm... I see they also have a site called LoveDetect... I wonder what THAT's about.
Anyways, I normally give out report cards for places like Liarcard, but I think I'll choose my words carefully this time. I'm sure you understand.