Released Technologies

SMS is the data protocol that connects most people in our world. Cheaper in many cases than voice, more reliable when there is iffy reception, accessible from the cheapest devices, they have proven to be a reliable resource in remote or post-disaster environments. However, obstacles do exist to easy use of SMS as a component in technology solutions. Hosting a scalable infrastructure to manage incoming and outgoing messages typically requires custom code and dedicated computers.

This framework evolved from our experiences building the infrastructure for Golden Shadow and surveying requirements for the Mekong Collaboration Program. We are also currently using the framework as part of our Directory to transmission of send position updates via SMS and query nearby friends from your cell phone.

This framework simplifies writing programs that use Twitter to interact with users. Using Twitter's services you can effectively create a worldwide SMS gateway with little effort - as long as the interaction with your application falls within the style dictated by Twitter. Using this framework makes writing the code a matter of programming your bot. You won't have to worry about plumbing tasks such as user enrollment. You need only focuson the messages you want to exchange with your users. Advanced solutions requiring SMS would probably 'graduate' from using Twitter as a core component, but using this bot framework allows for fast prototyping, deployment and design initiation. initiating the design process. 

We took the first cut of our Contacts Nearby SMS service to Laos and had tons of feedback after only a day of use. If we had waited to have a full-blown SMS service we wouldn't have learned as much as fast or as vividly.

Key requirements:

• Minimize the code needed to write a ‘bot' that can have conversations with users so that a developer only needs to write the bot logic.
• Interact with Twitter's API in a way that conforms to terms of service and minimizes the scalability impact of using the bot on the Twitter infrastructure
• Manage all the enrollment of ‘followers' needed for an user to have a private conversation with the bot

This project is builds on the .NET Framework 2.0 and requires a connection to the internet to interact with Twitter obviously, and a twitter user account to act as the bot itself.

Note: Twitter has become very popular. Understandably, the Twitter team keeps a close eye on the scalability impact of having ‘bots' using their API because bots touch the system more often than people using interactive applications. Twitter strictly enforces limits on the use of their API. You will need to contact them if you want to build bots that run continuously. You can sidestep this issue by running you bot logic less often - if your bots don't require active conversations with your users.

Fortunately, Twitter has been very generous and allowed an exception so a couple of our own proof-of-concept bots, targeting the humanitarian workforce, can run with less performance throttling. This is something that Twitter manages per bot account. It is not free if you use the InSTEDD framework to build your bot.

Developers:

• Source code, wiki and technical discussions at: http://code.google.com/p/twitterbots/
• Source is available under The MIT License.

This project evolved out of a simple need: how can we make our software more malleable and easier to change in the field?

In humanitarian and aid scenarios, it is common to suddenly realize that the requirements a piece of software was built to are exceeded by the situation. Adding new functionality and changing some behaviour may become critical in order to be able to deploy or integrate existing systems.

One big problem with this is that software tends to be very brittle- changing or fixing something puts at risk breaking other things. This can be made more predictable through good design and architecture practices, of course. A good design practice is to build software around automated tests (a practice called Test Driven Development - TDD). When doing TDD, a developer builds automated tests as an integral part of the development process - even before the actual code that would make those tests pass gets written. Later on functionality is added or changed, it is easy to re-run these tests and see what was broken in the process, and revise the requirements, tests, or the actual project code to accomodate the changes.

When changing the software it is important that these tests become easy to read and understand, especially if the developer is under pressure. The Moq project evolved out of efforts on how we can make tests easier to read - especially when building 'Mock' objects (objects that 'pretend' to behave like a larger, more complex part of the system, that can be abstracted for the needs of a particular test). Using mock objects helps to isolate tests on a target object from a larger, more complicated context, and helps your objects be less coupled, which improves the design of the overall system.

Specifically - Moq can be used by developers on the .NET platform to specify the behaviour of mock objects used in testing. It's called Moq because it is based on the LINQ technology available in .NET.

Developers:

• Source code, wiki and technical discussions at: http://code.google.com/p/moq/
• Source is available under New BSD License.

This project is a joint effort of InSTEDD, Clarius and Manas