Building a proof of concept? Try Twitter

The journey from idea to mature software typically follows three very high level stages:

Proof of Concept > Evolve > Mature and maintain

Each stage will involve the usual development concerns (analysis, specification, design, implementation, integration, stage & tests) with all the corresponding artefacts (stories, acceptance criteria, points, etc.) involving sprints, scrums and whatever other rituals in your culture. The concerns at each stage can also be broken down further. For example, design will typically involve content, logical and presentational aspects. Presentational aspects will require thinking about user experience and be part of a holistic information architecture.

Some idea thrives on a certain component, such as user experience or underlying content. Some thrives on feature or functionalities. Many ideas in one way or another require some form of social acceptance, and this is often key to social or commercial success of the software. Social acceptance is in many ways the golden goal. Many projects invests heavily, at the proof of concept stage, to better understand the potential of social acceptance by creating an alpha or beta version of a software. While the creation of an alpha or beta version complete with its own front-end clients and API can definitely strengthen the case for success at the proof of concept stage, there can perhaps be another way to focus more on social acceptance of the idea socially. Twitter presents itself as a low cost platform for such a use case. It has most of the components required for a bootstrapped proof of concept software:

• Storage: Twitter stores tweets



• Input/Output: Input via 'What's happening?', API. Output to public/follower's Timelines



• Events: Tweets, mentions, re-tweets



• Messaging: Again, via tweets, DM (direct messaging) between users

Processing units are external to Twitter though. The processing units are the users. Users can be biological or software bots. Software bots are easily scripted using available Twitter libraries. Theoretically, we can even run both an asynchronous message queue (via the following-follower mechanism) or a distributed worker farm (via DM-ing) on Twitter.

So, here we have a medium to build a proof of concept, by building a Twitter bot tapping on Twitter's API. The fun part stems from the social aspects. Our software bots can interact with biological users voluntarily or automatically. From these interactions, we learn more about the idea and gather proofs that the gist of the concept works or not.

Remember "The Network is the Computer"? Remember perhaps the Unix philosophy?

• Write programs that do one thing and do it well.


• Write programs to work together.


• Write programs to handle text streams, because that is a universal interface.

From a practical perspective, these mantras are not just useful in constructing good software, it helps in worldly efficiencies as well. Let's say I have an idea to start a food recommendation service. What I could do at the beginning is:

• Write the API


• Database


• PHP/RoR/Python/NameYourLanguage


• Web-server


• Message Queue


• Email


• Cron


• NoSQL


• Caching


• Design RESTful endpoints


• etc.


• Write the Web front-end


• PHP/RoR/Python/NameYourLanguage


• Front-end design


• CSS


• Cross-browser


• jQuery


• etc.


• Write the mobile app (Android or iPhone)


• Objective C / Java


• AppStore submission


• Mobile design


• iOS / Android quirks


• etc.

Or I can write a Twitter bot:

• Write the Twitter bot


• The food/restaurant recommendation algorithm


• The food/restaurant database (stored as Twitter lists?)


• How biological users use and react (analyse via Timeline?)

By going the route of the Twitter bot, I write no front-end (users interact with the bot via Twitter web, TweetDeck or whatever client they use which suits them), I don't worry about storage as most interactions are stored as tweets, I don't worrry about scalability. I focus on writing my recommendation bot that does recommendation well.

You may argue that the user experience is different and that may play a big part in the success of the idea. Probably and of course, the API, web front-end and mobile-app are all eventual concerns. But only IF your idea does well. And in most cases, ideas has to evolve, be tweaked and even changed before it comes to a point where its polished and scales. Would an early stage software project exploring and validating ideas need to expand the whole arsenal of technologies for that? Would it be efficient for a an early stage project to do so?

I will like to put forth this idea that Twitter bots/applications tapping on the API can be a useful tool for such early stage proof of concept and exploration. The artifacts created in the form of these software that lives cronned by the minute to Twitter could even live on as a great service to biological entities on Twitter even if the adventure is validated. It could even evolve into the core of the eventual sofware entity. It could serve as the missing piece between thinking and analysing an idea versus implementing a more involved software artifact of the idea. I am using one myself in the form of a Twitter bot by the name of @watweat, which does: food recommendations! I figure a couple of hours to create a proof of concept to renounce/validate the viability of an idea is pretty good ROI.

Cloudphp.net and reviews of PHP Development in the Cloud

The companion website to PHP Development in the Cloud is at cloudphp.net.

The website contains the source code of examples in the book and other related resources. There's also a list of PHP PaaS that might be useful if you're looking at migrating to these services.
Also, thanks to Jason, Rafael and Michelangelo for the great reviews:

"The book provides an excellent overview of what the cloud is and isn't, and then how PHP developers can leverage it in our applications."

Jason Austin

"Ivo and Vito did a very good job of bringing the topic into a PHP developer’s world in a very concise and objective manner, without leaving important platforms and concepts behind."

Rafael Dohms

"Let me say the book is a fun read. You can take it up to your bedroom as late-night read, read during lunch or even in the garden when the kids are playing about."

Michelangelo van Dam

Book: PHP Development in the Cloud

I like cloud computing for two reasons:

It's shared!

Personal space is vital and enjoyable for many of life's activities, but easily accessible public spaces/utility/services can be more efficient for many other activities (for example, we don't need to own a football field to play it, renting a pitch for 2 hours will be better). I think public clouds such as Amazon, Rackspace and others like it are analogous to accessible public utilities.

It's alive!

"The illusion that we are separate from one another is an optical delusion of our consciousness."

Albert Einstein

I have this romanticised (but strongly held) ideal that the cloud is alive through us, that all the artifacts of our existence within the cloud such as our data (tweets, profiles, documents, etc.), our APIs, software, platform and infrastructure collectively form part of a larger evolutionary process towards the Singularity.

Hence the book...

Along these lines, in the midst of some tinkering and experimentation with more immediately practicable applications of the cloud; I had a conversation with Ivo at the Claddagh Ring of Hendon and we'd decided to write this book together. We wanted to clarify where cloud computing will intersect with the internet & the WWW; and parts of it that makes having a different term to describe the cloud necessary. We do so from a PHP perspective because it is the language for the web that we like the most.

This book is available for purchase via Amazon.com as well as php|architect.

APC on techPortal

APC is one of the things that you should do if you care about the performance of your PHP application.

It is always beneficial if done properly. My latest article on techPortal entitled Understanding APC discusses some of the things that you should look out for.

If you're not sure what APC actually is, how it differs from other caches or how to start using it; check out the article!

The Gmagick, Amazon, Windows, techPortal, php|architect and Zend DevZone Hamper Blog

It's been a while since I last blogged so I am packing it all up with a tags-like title for a change.

Over the past few months, there had been several Gmagick releases that incorporate a few fixes and some new features. Check out the release notes on PECL for more info. A big thank you to all that had tried it out and had contributed fixes.

For Windows users, Gmagick is now available for Windows, grab the DLLs from Mikko's valokuva.

On the evangelism side of things, I wrote about using Gmagick along with Amazon's Elastic MapReduce cloud service to do color searching. This appears on techPortal. Yes, it is indeed quite long, according to Cal Evans. It showcases how Amazon's cloud allows developers to be flexible with the precision of both the pixel scope for color quantization and the proximity of colors to search within a 3D colorspace. This burrowing into Elastic MapReduce is part of some other cloud spotting that I had been enjoying while working on an upcoming book with Ivo Jansch.

That's not all!(Intercom speakers) There's an article on Gmagick in the October issue of php|architect as well. In this article, elephpant visits the museum. Curious? Check out the October issue!

For those that are interested in more Gmagick related documentation (besides the manual), Vikram wrote a nice and rather comprehensive tutorial on Zend Developer Zone.

That's about it now.

A quick look at the Tokyo Tyrant extension for PHP

Here's a quick, rough look at the speed of the Tokyo Tyrant extension for PHP released by Mikko 2 days ago. I am using it as an on-memory hash. Profiling done with xdebug on PHP 5.3.0:

Here's the collateral userspace costs of an alternative PHP implementation by Bertrand Mansion (dependent on the sockets extension to PHP):

The Gmagick Extension

I am excited to announce the release of the Gmagick PHP extension, which I ported from Imagick along with Mikko Koppanen, one of the Imagick author who got me to do the extension and guided me along the way.

The extension seeks to make the image processing capability of GraphicsMagick accessible from PHP. GraphicsMagick is forked from version 5.5.2 of ImageMagick and had since developed with important differences and improvements (for more details, see GraphicsMagick's website).

In terms of Gmagick and Imagick, we try to keep the method interface similar so existing Imagick users will find converting to Gmagick a breeze. One major difference however, is that most of the mutator methods in Gmagick are chainable.

We'll leave you to decide which extension is more suitable for your needs. A high level difference that we keep in mind when developing Gmagick is that Imagick's feature set is more extensive and powerful, whereas Gmagick should be simpler and more efficient (see benchmarks).