….::: VOX POPULI :::….

Gov 2.0 is Open Source

Posted by Mark Headd under Open Government, Open Source

It’s interesting to reflect back on the not too distant past and think about how governments have used open source software.

For many state and local governments - as recently as a few years ago - the use of open source software was something of a foreign concept. Many a government IT worker made an impassioned and well reasoned plea to bosses and co-workers to consider using open source software to capitalize on a range of different benefits. (And yes, in case you’re wondering, when I was a state government IT worker I made many such pleas to bosses and co-workers.)

For a long time, those pleas usually went unheeded. How far we’ve now come.

Not only are more and more state and local governments starting to realize the benefits of using open source software, some of them are actually starting to become developers of open source solutions.

The notion of government-sponsored open source software development isn’t necessarily new - it’s how we got SE Linux for example. But it is still a relatively new concept for state and local governments. I can think of two government entities that are leading the charge.

First, the New York State Senate. Under CIO Andrew Hoppin, the New York legislature’s upper chamber has become a leader in the public sector for its use of open source software. Not only does the Senate use Drupal for its public website, they also contribute Drupal modules back to the community.

After becoming the first legislative body in the country to develop iPhone and iPad apps, they not only released the code for these apps on GitHub, they actually did a code walk through for developers at a recent event in Albany.

And now, the State of Washington has released the code for its own mobile apps on GitHub. They are actively encouraging people to submit ideas to help further develop the software and to identify bugs.

Both of these governments (and others who are out there doing the same thing) will realize more benefits by open sourcing the code for their apps than they would have had they kept the source code a secret. By making the code for their apps visible and reusable, they’ll attract more developer interest and help ensure that bugs or security issues get identified quickly.

Other governments will benefit as well - these two organizations are clearly ahead of the curve in developing mobile apps, and other governments will benefit from their experience and expertise. Since’s governments generally don’t compete directly with each other, this type of sharing makes perfect sense.

Improvements or enhancements to these open source applications will in turn provide benefits for the governments that created them - this is one of the driving dynamics of Gov 2.0.

I’m wondering if there are other state and local governments out there doing this same thing. Do you know of a government agency or entity with a GitHub repo or other open source code repository?

Leave a comment below with the details.

Make the Cloud Listen (and Understand)

Posted by Mark Headd under Development Tools, Open Source, Tropo, Tutorials

Yesterday I wrote a post about the changing cloud telephony landscape, and highlighted some key factors that will dictate which cloud telephony providers are around for the long haul and deliver the next innovations.

One of those factors - support for speech recognition - is a good differentiator for developers to use when choosing a cloud telephony platform.

Speech recognition is becoming increasingly important in our everyday lives. Smartphones and powerful handheld devices enable multimodality, and there are more and more restrictions placed on our use of phones while doing other tings (like driving).

Plus, I can’t think of a more deflating concept than a cloud telephony provider that allows developers to build sophisticated apps and mashups in the language of their choice but that chains users of those apps to a telephone keypad. No fun.

To give an example of how powerful speech recognition can be, and how easy it is to use with a cloud telephony provider that supports it, I worked up a small demo to illustrate the point. The sample code for this demo is on Github, and we’ll dive into it in more detail below.

This demo uses two PHP libraries that are designed to work with the Tropo platform (one of the only cloud telephony providers to support speech recognition):

• A set of PHP classes for working with the Tropo WebAPI.
• A PHP library for creating SRGS grammars in XML format.

If you’ve read any of my previous posts on build applications for the Tropo platform, you’ll see lots of similarities between this and previous sample apps. Here I continue my use of the insanely awesome Limonade Framework for PHP.

Let’s take the example of a company directory that allows callers to dial a single number, select a person or department at the company and then be transferred to the person they select.

With cloud telephony, there is no need to have such a system live on a machine in the server room - it can be hosted externally in the cloud, making it easier to manage and to scale. In addition, with the Tropo Platform, it doesn’t have to be the same tired old DTMF-based menu telling callers to press an extension number or to “dial by name…”.

Using the PHP WebAPI Library and Limonade, we can construct a simple, yet power script that looks like this:

This script is pretty self-explanatory, but there are some key points I want to emphasize. First, note the $options array that holds the reference to an external grammar file (more on that in a bit). Tropo seems to need for this reference to be an absolute one and not a relative reference to the file (not hard to do with PHP - you just need to be aware of it).

Also, the file reference needs to include a trailing parameter indicating that this is an XML grammar (;type=application/grammar-xml). This seems to be true even if the grammar file is served with the correct MIME type by whatever is serving it.

Now lets have a look at this grammar file.

This simplistic example demonstrates how to use the PHPGrammar library. Note the simple array structure that is being used to hold the details of employees for our fictitious company. This could very easily be replaced with a dip into a data source of pretty much any kind, like an LDAP directory or database holding employee details.

Also note in this example that we want to do something referred to as Semantic Interpretation. Our grammar file is a set of rules that will be applied to what the caller says - Semantic Interpretation (SI) dictates the value that is given to our application from the grammar when a successful match occurs.

In this example, we want the caller to be able to say the name of the person they want to be transfered to. We make the first name optional so they may either say the last name of the person or (optionally) the full name. Obviously this may need to be changed based on the size of the directory to render in a grammar file (e.g., multiple employees with the same last name).

Do note that the Tropo platform seems to require the “Script” sytax for returning SI values on a successful match as opposed to the “String Literal” syntax. (More on these alternatives here.)

Works on Tropo (Script syntax):
<item>foo<tag>out=”bar”;</tag></item>

Does not work on Tropo (String Literal syntax):
<item>foo<tag>bar</tag></item>

So, when a caller says the name of a person in our company directory we want to return the number for that person to our Tropo script so we can transfer the call to them. This can clearly be seen when we examine the Result object that is delivered by the Tropo platform.

Tropo’s Result object includes the full grammar engine output, and lots of very detailed information about the recognition. As you can see, the utterance that the speech recognition engine heard was the name of one of our faux employees. The value that was returned is the number of that person.

We use this value in the transfer_call() method of our Tropo script.


// Create a new instance of the Result object.
$result = new Result();

// Get the value of the selection the caller made.
$phone = $result->getValue();

// Create a new instance of the Tropo object and transfer the call.
$tropo = new Tropo();
$tropo->transfer('+1'.$phone);

// Write out the JSON for Tropo to consume.
$tropo->RenderJson();


Using the PHP WebAPI library, it takes just 5 lines of code (excluding comments) to get the value of the grammar result and transfer the call. How cool is that?!

Obviously there are lots of things that can be done to enhance this script, to make it more robust, but it illustrates the essential concepts of speech recognition in the cloud.

What’s more, because of all of the great functionality provided by the Tropo cloud platform we can really push the envelope on the tired old company directory:

• We could take an inbound call from a Skype user and transfer to a cell phone (or a SIP endpoint).
• We could let our caller select a department in our company and then ring several different numbers at once, transferring the call to the first one answered (sort of a “hunt group in the cloud”).
• We could use Tropo’s built in IM capabilities to send a screen pop to the person receiving the call.

The sky is the limit. Which I guess is the point of cloud telephony…

Upgrading to CouchDB 0.11

Posted by Mark Headd under CouchDB, Development Tools, Open Source

Just a few days ago, CouchDB version 0.11 was released - this new version is packed full of cool new features as outlined on the Couch.io blog. It’s also the first release without the Alpha or Beta label attached to it.

What’s more exciting, CouchDB version 0.11 is a feature-freeze release candidate for the upcoming version 1.0. So if you’ve played around with CouchDB and have an old instance laying around, now is the time to upgrade.

If you’ve read my previous series on using CouchDB to build cloud telephony applications with Voxeo’s Tropo platform, and you used my instructions for setting up CouchDB on Ubuntu 8.04, then upgrading to CouchDB version 0.11 will be a piece of cake. (Note - the mirror you download from may be different than below. Go to the download page to find the best one):

Before upgrading, make sure that any customizations you’ve made to the CouchDB configuration are in /usr/local/etc/couchdb/local.ini. The upgrade process will overwrite any changes you have made in default.ini.

$ sudo /usr/local/etc/init.d/couchdb stop

You should probably run make uninstall on the previous version of CouchDB before starting.
If you see leftover files in /user/local
$ find /usr/local -name \*couch* | wc -l

You should probably get rid of them:
$ find /usr/local -name \*couch* | xargs rm -rf

$ wget http://www.trieuvan.com/apache/couchdb/0.11.0/apache-couchdb-0.11.0.tar.gz
$ tar -zxvf apache-couchdb-0.11.0.tar.gz
$ cd apache-couchdb-0.11.0/
$ ./configure && make && sudo make install
$ sudo /usr/local/etc/init.d/couchdb start
$ curl -X GET http://127.0.0.1:5984

You should see:

{”couchdb”:”Welcome”,”version”:”0.11.0″}

Note - if you see an error that says {"error":"error","reason":"eacces"} when trying to create a database or insert documents, you may need to re run some commands listed in the previous install instructions:

$ sudo chown -R couchdb /usr/local/etc/couchdb
$ sudo chown -R couchdb /usr/local/var/lib/couchdb
$ sudo chown -R couchdb /usr/local/var/log/couchdb

I’m in the process of finishing up a project that will make use of the Open311 API deployed by the City of San Francisco and it shall be SQL-free - now that I have CouchDB 0.11 installed, I’m ready to finish up.

Stay tuned - this project is going to kill!

OpenGov APIs: Interfacing with Open Government

Posted by Mark Headd under Development Tools, Open Government, Open Source

There has been lots of good talk (and a good deal of action) lately around open government APIs at events like Transparency Camp, Where 2.0 and on the Twitters.

So, as a prelude to a talk I’ll be giving at eComm next month, I wanted to write a post surveying the landscape of recent government API developments, and also to describe evolving efforts to construct standards for government APIs.

A Rundown of Recent State and Local API Developments

At Transparency Camp in DC last weekend, Socrata - a firm that hosts open data sets for governments - open sourced their API for accessing and querying public data. The Socrata Open Data API (or SODA) is a specification for running queries against public data sets. Currently, Socrata hosts data sets for the City of Seattle and others - code samples for working with the SODA spec can be found on Github.

The Open311 API recently implemented by the City of San Francisco (and being implemented by others) got some well deserved attention at the recent Where 2.0 conference. Other cities are starting to take note, and some (like Edmonton and Boston) look set to be next in line.

One of the early adopters of government APIs - the NY Senate - recently announced a new release for their OpenLeg API, which includes some important new changes. Today the NY Senate remains one of the few (if not the only) state legislative body to adopt an API to open up access to legislative information and proceedings, but other will hopeful soon follow. (Certainly the work done in Albany by NY Senate CIO Andrew Hoppin and his team has opened the door for work on other government APIs.)

That’s a lot of good stuff in just the last few weeks - I’ve probably missed some stuff, but I’m sure there is more to come in the weeks and months ahead.

Towards API Standards

The work being done on the Open311 API, the OpenMuni Project, and certainly the move by Socrata to open source the SODA spec will have significant implications for the open government data movement.

Standards for open data and APIs will make it easier for developers to build things - an app that works for one municipality can work for others if both adhere to a common standard that the app can run against. But they’ll also make it easier for governments to open up their data - standards will offer governments assurance that the time and effort they expend to maintain and publish data or stand up APIs will provide the most return on investment.

The move towards open data and government API standards is an important one that may influence the long-term success of the open government movement.

What’s Next?

As these standards develop, and as more and more municipalities start to embrace open data, we’ll move closer to the idea of government as a platform.

More and more open data will be published by governments in this country and others. These newly opened data sets may be hosted on infrastructure maintained by governments, or by third parties like Socrata. Enterprising governments in different regions or states may decide to team up and jointly host data that is of interest or value to constituents served by multiple governments or jurisdictions.

The applications that allow citizens to communicate with governments and consume public services will increasingly be built outside of government. (By outside, I mean outside the control of government and the government procurement framework.) Governments will increasingly become the collectors and maintainers of data and information and will focus less on building applications that use such data (or contracting for such applications to be built).

The applications built to consume public data and communicate with government will increasingly be designed as multitenant applications, able to service constituents in multiple jurisdictions that adhere to common data or API standards. They will also be built using more open source components and Web 2.0 technologies.

And (hopefully) the ranks of civic coders will continue to swell, as technologists looking to “scratch their own itch” are empowered to make a difference far beyond their own wants or needs.

All hail the transformative power of standards!

Open311 Goes Big Time

Posted by Mark Headd under Open Government, Open Source, Standards

This was a big week for the Open311 initiative. Federal CIO Vivek Kundra joined Gov 2.0 rock star Mayor Gavin Newsom from the City of San Francisco to announce a national initiative to adopt a common standard for a 311 API.

The number of supporters for the initiative is growing, and I think it’s high time that developers started getting in on the act.

There isn’t a publicly available sandbox (that I am aware of) for developers to use to develop Open311 applications. The Open311 website, however, has some detailed information on the API standard as well as some sample XML responses that the API will provide.

Based on this information, I’ve started working on a set of PHP classes for interacting with the Open311 API. It’s still rough, and it will obviously undergo many changes as more information on the API is developed, and public test infrastructure is set up.

Still, its a start (and it was fun to write!) - I’m hopeful that others will help develop this set of classes. Hit me up at mheadd [at] voiceingov.org if interested.

Cloudvox: Cloud Telephony Applications Made Easy

Posted by Mark Headd under Development Tools, Open Source, Tutorials

A couple of months ago, I did a quick write up on a new cloud telephony company named Cloudvox. In the interim, I’ve been doing some playing around with their HTTP/JSON API for creating telephone applications, and I’ve been blown away by how simple and powerful a tool it is for building sophisticated cloud telephony applications.

This post will provide a quick overview of how the Cloudvox JSON API can be paired with PHP and the delightfully awesome Limonade Framework. If you’re not a PHP developer don’t despair - this example can easily be ported to other languages like Ruby (using Sinatra) or C# (using Kayak).

Cloudvox API Helper Classes

When writing apps for the Cloudvox JSON API, there are two things that we need to manage - the JSON that we will send to Cloudvox (using plain old HTTP) and the response Cloudvox sends back to our app (this will include any user input collected from the caller, and also things like a unique identifier for the call, caller ID and other information about the call).

To make managing both sides of our exchange with Cloudvox easier, I’ve created a set of PHP classes that can be used with any standard PHP IDE to make writing Cloudvox JSON and parsing Cloudvox responses simple and easy. You can download this class library from GitHub.

Using these classes is pretty straightforward:


< ?php
include('cloudvox-json-http-classes.php');
$speak = new Speak("Hello world!");
$hangup = new Hangup();
Output::renderJSON($speak, $hangup);
?>


Will render:

[{"name":"Speak","phrase":"Hello world!"},{"name":"Hangup"}]

Required properties are included in the constructor for each class - in most IDE’s this means that you can simply use Shift + Control + Space Bar when you create a new instance of the object to see what properties are required.

Optional properties on all classes are handled by using the PHP __set() method in the base class. This effectively let’s you overload the object and set properties which are not declared in the class definition. So for example, if we wanted to collect input from the caller (e.g., their zip code) we would use the GetDigits class, and overload it to add a URL to post the results to:


< ?php

// First argument passed into the constructor sets # of digits to collect.
// Second argument sets the timeout.
$getDigits = new GetDigits(1,5);

// Now we overload the object to add a URL to post the results to.
$getDigits->url = “http://somehost.com/myscript.php”;

?>


The problem with overloading in PHP is that you don’t get the benefit of having your IDE display overload options (it can’t because the properties that we wish to set are not declared in the class definition). There also isn’t any way to control what overloaded properties get set, so its possible to add things the Cloudvox won’t understand.

I’m not sure there is any way around this given the way that PHP has implemented overloading. I do plan to work on a set of Cloudvox classes using another language that handles overloading a bit better, like C#, but for now you should only overload to set the url and method properites for classes that can use them (see the Cloudvox docs for more details).

Sipping on some Limonade

If you know of the excellent Ruby Framework Sinatra but you want to code your project in PHP, fear not - check out the equally excellent PHP framework called Limonade. It’s the functional equivalent of Sinatra for PHP.

Using Limonade with our set of Cloudvox JSON classes makes building cloud telephony applications very simple. The biggest benefit is that you don’t have to split up the different steps in your application (i.e., collecting input, validating input, re prompting, etc.) into different PHP files (which can be kind of a pain) - all of your steps can be contained within a single file.

Limonade lets you set a URL “route” that Cloudvox can send HTTP requests to with results, and to get rendered JSON for another application step. For example:


< ?php

dispatch_get('/start', 'cloudvox_start');
function cloudvox_start() {

$speak = new Speak("Hello world!");
$hangup = new Hangup();
Output::renderJSON($speak, $hangup);

}

?>


This “Hello World” example - defined in a script named sample.php - could be accessed by hitting http://somehost.com/index.php?/start. To make things easier, we’ll use a little Apache magic to allow URL rewriting:

This will let us access the above URL by hitting http://somehost.com/index.php/start.

A simple demo app using the Cloudvox JSON helper classes and the Limonade Framework can be seen below. You can use this sample application with a new Cloudvox account to get started building cloud telephony applications.

This simple app demonstrates how powerful the Cloudvox JSON API is for creating cloud telephony apps. When coupled with an elegant framework like Limonade, sophisticated, cloud-based telephony applications are readily available to any developer that wants to build one.

The helper classes for the Cloudvox API are obviously a work in progress, so if anyone reading this has comments or suggestions feel free to let me know - mheadd [at] voiceingov.org.

XHP for VoiceXML

Posted by Mark Headd under Development Tools, Open Source

Facebook has been busy lately doing all sorts of interesting things to the PHP scripting language. Although most of the recent PR hype was centered around HipHop for PHP (a name that, quite frankly, makes me want to use it less), Facebook also released another very interesting and potentially useful extension for PHP - XHP. From the XHP wiki on Github:

XHP is a PHP extension which augments the syntax of the language such that XML document fragments become valid PHP expressions. This allows you to use PHP as a stricter templating engine and offers much more straightforward implementation of reusable components.

Not sure where I read it, but one commenter compared XHP to E4X in JavaScript. It’s a neat idea, and its actually not all that hard to start playing around with XHP (if you’re comfortable installing PHP extensions).

After thinking about XHP and playing around with it a bit, I started to think it might be useful as a way of generating not just HTML, but also other XML-based languages like VoiceXML.

The core XHP classes that are used for generating HTML are fairly easy to understand, once you get use to the syntax - extending these core classes to generate VoiceXML (or any other XML-based language) is not all that hard. But before we do that, let’s install XHP as a PHP extension and kick the tires a bit.

Installing XHP on Ubuntu

I’ve tried the following instructions on both Ubuntu 8.04 and 8.10, and I’m pretty sure they’ll work with just about any recent Ubuntu version.

Make sure you’ve got the basics for building PHP extensions:

$ sudo apt-get install build-essential
$ sudo apt-get install php5-dev

Get the XHP source code:

$ mkdir xhp
$ cd xhp
$ git clone git://github.com/facebook/xhp.git

Get the PHP source code

$ sudo apt-get source php5

Make a directory in the PHP source code for the XHP extension

$ mkdir php-5.X.X/ext/xhp
$ cp -r xhp/xhp/* php-5.X.X/ext/xhp/

Depending on your system, you may need to add some of the prerequisites for building this extension:

$ sudo apt-get install flex bison

I tried this approach on both Ubuntu 8.04 and 8.10 and in both cases only version 0.13.5 of re2c worked (earlier version obtained via apt-get did not cut the mustard). If you’re running a later version, you may be able to get this version of re2c from the standard repos.

For this example, I’ll just build it from source:

$ wget http://sourceforge.net/projects/re2c/files/re2c/0.13.5/re2c-0.13.5.tar.gz/download
$ tar -zxvf re2c-0.13.5.tar.gz
$ cd re2c-0.13.5/
$ ./configure
$ sudo make
$ sudo make install

Move to new XHP extension directory and get ‘er done.

$ cd php-5.X.X/ext/xhp
$ phpize
$ ./configure
$ sudo make
$ sudo make install

When you run make install, the new extension file is placed in a directory where Apache can load it - however, we need to modify the php.ini file so that Apache is aware of the extension. Open php.ini and add the following:

extension=xhp.so
extension_dir=directory_where_xhp.so_is_located

When setting this last option, use the directory where xhp.so was placed by make install. Now we just restart Apache:

$ sudo /etc/init.d/apache2 restart

Easy right? Unfortunately, things get a little less clear at this point. It turns out that to make XHP work properly, some PHP libraries need to be included in any of the XHP scripts we write. These files are located in the php-lib directory of the XHP source code.

To make things easier (especially when we start to write our own extension to XHP for VoiceXML, lets move these files to a convenient local directory that we can include in our scripts:

$ cp php-5.X.X/ext/xhp/php-lib/* my/local/directory/php-lib/

So now we can do some interesting stuff like this:

What’s especially interesting about XHP is that it enforces proper syntax at compile time, so if your markup isn’t syntactically correct an exception gets tossed.

Generating VoiceXML with XHP

The XHP libraries we just discussed implement the HTML spec out of the box. However, if you try and render tags that are not part of the HTML spec an exception will occur. I wanted to find out how hard it would be to extend the concepts behind XHP for other markup languages, like VoiceXML. Turns out, its not hard at all.

If you look at the init.php file that is included in the example above, you’ll see its in turn including a file called html.php, which defines all of the HTML elements that can be rendered by XHP, the attributes that each can have and also the parent-child relationship between elements.

Using this is a guide (the syntax is new but fairly easy to follow), I knocked out a quick class file for some basic VoiceXML elements - just to illustrate the concept:

This is admittedly rough, and it only covers a few basic VoiceXML elements, but it demonstrates that extending XHP to render VoiceXML is actually quite easy. To use this file, simple edit the init.php file mentioned previously and add an include statement:

< ?php
require_once 'core.php';
require_once 'html.php';
require_once 'vxml.php';
?>

Now we’re ready to use XHP to generate VoiceXML:

How cool is that?

I’m still toying around with XHP, but this little experiment clearly shows that it has use beyond just simply rendering HTML. I’d be interested in hearing from other developers - is this worth a full blown project to flush out a complete VoiceXML class library for XHP? What other markup languages would make good candidates for this same type of approach?

Post a comment here, a tweet to @mheadd or shoot a quick e-mail to mheadd [at] voiceingov.org with your thoughts or comments.

Relaxing on the Couch with Tropo and CouchDB

Posted by Mark Headd under CouchDB, Development Tools, Open Source, Tutorials

This is the continuation of a series that will describe how to build voice applications with the Tropo cloud telephony platform and CouchDB.

In the last post, I detailed how to get a CouchDB instance up and running on Ubuntu, and how to get an account started on Tropo so that you can start building cloud telephony applications. In this post, we’ll create our first CouchDB database and create a simple Tropo application that connects to our CouchDB instance. First, however, we need to tweak the default settings for CouchDB so that we can access our CouchDB instance from the an external environment.

Configuring CouchDB

Recall from the last post that the configuration files for CouchDB are located in /usr/local/etc/couchdb/. Open the local configuration file and take a look at the default settings:

$ sudo vim /usr/local/etc/couchdb/local.ini

In the [httpd] section, you’ll notice the setting for the default port that is used to connect to CouchDB - 5984. You’ll also note the bind_address setting. By default, CouchDB listens only on localhost – you can change this by altering the value of bind_address to a publicly resolvable IP address (you may need to uncomment this setting as well).

However, before proceeding please note that CouchDB does not yet have a built in security model, so anyone that can access the IP address in the configuration file can potentially access your CouchDB instance. We’ll need to take some steps to restrict access to our CouchDB instance – there are several ways of doing this.

First, if you know the IP address (or range of addresses) that will be accessing your CouchDB instances, you can simply use IPTables to restrict access to that IP:

$ iptables -A INPUT -p tcp -s 64.57.102.34 –dport 5984 -j ACCEPT

The above command would restrict access to your CouchDB instance to a single IP address.

Another method for securing a publicly exposed CouchDB instance is to use Apache password authentication. A good overview of this approach can be found here.

After you’ve modified the bind_address setting, restart CouchDB and test connectivity to it:

$ sudo /usr/local/etc/init.d/couchdb restart
$ curl http://your_new_couchdb_ip:5984

Creating our CouchDB Database

Once you have your CouchDB instance up and running, you can create a database in one of two ways. The first, and easiest, is simply to use the curl command. You create a database in CouchDB by using the HTTP PUT method:

$curl -X PUT http://your_new_couchdb_ip:5984/call_logs

You can also create a database (and do lots of management functions in CouchDB) by using the GUI (called Futon). Its located at http://your_new_couchdb_ip:5984/_utils

Building a Simple Auto Attendant Application with Tropo

Now that we have an initial database in our CouchDB instance, lets build a simple Tropo application that will populate it with records (or documents in CouchDB parlance):

This simple application is a basic auto attendant. It asks the caller for a 4-digit extension and then transfers them to a 10-digit PSTN number. At the end of the call, we write a very simple call log document to our new call_logs database using the HTTP POST method.

(One small side note – you can use either the POST or PUT methods to insert a document into a CouchDB database. However, using PUT assumes you want to assign a specific document ID to your document. When you use HTTP POST, CouchDB will automatically assign a document ID. For now, we’ll keep things simple and use POST.)

Much of the functionality in this simple app is just stubbed out for now - i.e., the getPhoneNumberByExtension() method - we’ll build more of this out in later posts.

Modify this file by adding your instance-specifc details to the constant declarations at the top. Do also note that the last two constants can remain blank for now.


define("COUCH_DB_DESIGN_DOCUMENT_NAME", "");
define("COUCH_DB_SHOW_FUNCTION_NAME", "");


We’ll talk about how to use design documents in the next post.

When you load this file up on Tropo and make a test call, you will see your call log document is inserted into the call_logs database. The structure of the document is pure JSON, which is supported quite nicely in PHP (and most every other language that can run on Tropo as well).

In the next post, we’ll examine CouchDB design documents in more detail and modify our simple demo application to get a list of extensions from another CouchDB database and parse the JSON data structure in the getPhoneNumberByExtension() method.

Until then, keep on relaxing….

Building Voice Applications with Tropo and CouchDB

Posted by Mark Headd under CouchDB, Development Tools, Open Source, Tutorials

The beginning of a new decade is usually the time when there is a lot of reflection on what has changed for the better (and the worse) over the past 10 years.

The end of 2009 saw its fair share of pundits talking about how far we’ve come since the year 2000, but for me the most dramatic change has been to the way that voice applications are developed and deployed. In the past 10 years (hell, in the past 10 months!) we’ve seen a dramatic shift toward cloud telephony with the launch of a number of new services that have fundamentally altered how voice applications can be built.

There has simply never been a more varied and powerful array of tools available for developers to build phone applications with than exists today. Some of the newest and most innovative platforms around for building cloud-based phone applications are listed below:

• Tropo
• Couldvox
• CallFire
• TringMe
• Twilio
• Ribbit

Over the same period of time there’s also been lots of changes to some of the foundational technologies supporting voice applications (and other kinds of web applications). The NoSQL movement is gaining steam, and there is an interesting collection of new document-oriented databases available for developers to use. One of my favorite is Apache CouchDB.

The thing I find really interesting about CouchDB is that it makes use of an HTTP-based API - pretty much any tool or technology that can communicate via HTTP can be used to interact with a CouchDB instance (hello command line…). In addition, that data structure of the documents stored in a CouchDB instance is JSON. In my mind, this makes CouchDB a very useful choice when building cloud applications, specifically cloud telephony applications.

Who wants to use one of those old relational databases to build a cutting edge cloud phone app? That’s so 2009.

This post and the next several that follow it will detail how to set up a CouchDB instance and to build a cloud telephony application with it using the Voxeo Tropo platform.

For those that don’t know, Tropo is one of the new cloud telephony platforms that lets developers author voice apps quickly and easily using one of several different languages. It’s open source, well documented and supported by Voxeo’s industry leading telephony infrastructure.

So, if you want to start the new decade of right by learning how to build powerful, scalable, full featured voice applications using Tropo and CouchDB, read on.

Getting Started with Tropo

Head on over to Tropo.com and set up a new account (if you don’t have one already). Take a little time to review the documentation for Tropo - I’d recommend running through a few of the sample apps if you have time. They’re fairly self explanatory and provide a solid overview of the different languages that can be used to write a Tropo app - I’ll be using PHP for the example application in this series of blog posts, but you can use any language that Tropo supports.

Deploying and testing an application on Tropo is a snap, and you can even deploy a PSTN number for your application (or you can use the Skype calling number automatically provisioned when you create a Tropo app). More on this in the next post.

Installing CouchDB

The next step in building our cloud telephony application for the new decade is getting CouchDB up and running. The steps listed below detail how to install CouchDB 0.9 on Ubuntu 8.04 (the long-term support version of Ubuntu). A few points before we get started…

This specific combination of Ubuntu and CouchDB is my own preference. I typically run Ubuntu 8.04 when I deploy a new virtual server, but you are free to run whatever version you like, or another Linux distro entirely - its up to you. Depending on the version of Ubuntu you are running, you may be able to get CouchDB 0.9 installed by simply doing sudo apt-get install couchdb.

Keep in mind, though, that the HTTP API for CouchDB can change dramatically between versions - I’ve noticed some significant changes when going from 0.8 to 0.9 - the discussion here will focus on version 0.9 (as does a lot of good documentation on CouchDB available on the web).

If you don’t want to install CouchDB yourself, you may be able to take advantage of one of the growing number of CouchDB hosting services like CloudAnt or Couch.io. Again, its up to you.

To install CouchDB 0.9 on Ubuntu 8.04, using the following steps.

Step 1. Determine what version of Ubuntu is running on your machine:

$ cat /etc/lsb-release

Step 2. Install Erlang - CouchDB 0.9 requires at least Erlang version 5.5.5. If you are running Ubuntu 8.10 or above, you can probably get the required Erlang version by simply doing sudo apt-get install erlang. (Note - The last step in this section may take a while, feel free to go grab a cup of Joe while the source compiles.)

$ sudo apt-get build-dep erlang
$ sudo apt-get install java-gcj-compat java-gcj-compat-dev
$ wget http://www.erlang.org/download/otp_src_R12B-5.tar.gz
$ tar -zxvf otp_src_R12B-5.tar.gz
$ cd otp_src_R12B-5/
$ ./configure && make && sudo make install

Step 3. Install CouchDB dependencies:

$ sudo apt-get install libmozjs-dev libicu-dev libcurl4-openssl-dev

Step 4. Download CouchDB 0.9 Source and install:

$ wget http://apache.mirrors.redwire.net/couchdb/0.9.0/apache-couchdb-0.9.0.tar.gz
$ tar -zxvf apache-couchdb-0.9.0.tar.gz
$ cd apache-couchdb-0.9.0/
$ ./configure && make && sudo make install

Step 5. Create a user for CouchDB (More on this in the CouchDB README.txt file):

$ sudo adduser – –system – –home /usr/local/var/lib/couchdb – –no-create-home – –shell /bin/bash – –group – –gecos “CouchDB Administrator” couchdb
$ sudo chown -R couchdb /usr/local/etc/couchdb
$ sudo chown -R couchdb /usr/local/var/lib/couchdb
$ sudo chown -R couchdb /usr/local/var/log/couchdb

Step 6. Start CouchDB

$ sudo /usr/local/etc/init.d/couchdb start

If you see an error that says:

“Apache CouchDB needs write permission on the PID file: /usr/local/var/run/couchdb.pid”

Do the following, then try starting CouchDB again:

$ sudo touch /usr/local/var/run/couchdb.pid
$ sudo chown couchdb:couchdb /usr/local/var/run/couchdb.pid

When CouchDB starts successfully, you will see a message that says:

* Starting database server couchdb     [ OK ]

Step 7. Test connectivity to CouchDB:

$ curl http://127.0.0.1:5984

You should see:

{”couchdb”:”Welcome”,”version”:”0.9.0″}

The configuration file for CouchDB is located at /usr/local/etc/couchdb/local.ini — in the next post, we’ll modify some of the config settings for our CouchDB instance so that we can access it via HTTP from the Tropo environment.

We’ll also set up our first CouchDB database, add some documents and start coding our new cloud telephony application using Tropo.

Stay tuned…

The Growth of Civic Apps

Posted by Mark Headd under Open Government, Open Source

A pretty good indicator of the growth in the number of “civic applications” can be seen in the creation of some new application directories.

City-Go-Round is a really nice site that pulls together dozens of applications that relate to travel and transit systems. It lets users enter a zip code so they can identify apps created specifically for their area (if any exist). I really like that this site focuses not only on the use of publicly released transit data, but also encourages users to advocate for more public transit data. You can view a list of agencies and sort by those that make their transit data public and those that don’t - it also lists contact information so that users can advocate with transit agency officials that don’t yet make their data public and get them to wise up.

Another site (still in the alpha stage) that lists applications specifically tailored to a particular geographic area is Appify. One of the brains behind this site is John Geraci (of DIYCity.org fame). While this app directory doesn’t look to be focused exclusively on civic applications, there are several prominent ones represented in the alpha release - theNextTrain, SubwayDelay and SeeClickFix among them.

The civic application ecosystem is healthy and growing, and I think we’ll start to see more application directories like these as more and more governments and transit agencies start to make their data public.