finally{}

Traditionally, customer service was provided via phone, email or web. In the age of Twitters and Facebooks, those options seems so old age practice. Since youngsters spend so much time on the ubiquitous Twitter, they would eventually bring customer service to Twitter and other social media.

Here is how YATSY (a simple case management system for Google App Engine) is integrated with Twitter.

Isn’t that simple? Follow @yatsy; once yatsy follows back, send a direct message to yatsy to create a case. YATSY system will read this DM and create a case & will respond back.

Having Twitter Integration is a double edge sword. If you provide a fantastic customer service it will be known in the social media. On the other hand, if you do a lousy job, it will spread like a wild fire. Yet, if you monitor Twitter Streams, you’ll be able to improve your products and customer service too.

Now for the techies. How did I implement Twitter Integration? YATSY itself is written using web2py, a web-framework in Python. Twitter streams are parsed using python-twitter, a simple & efficient Python wrapper for Twitter API.

Steps Forward

• Use Google App Engine Cron to initiate twitter parsing & case creation (now one need to explicitly execute the function)
• Using the same Cron facility for auto-follow
• Use a message queue for IN/OUT messages (if you know a good message queue implementation in Python, please leave a comment)
• Integrate (case) notes with Twitter

If your hands are itching to test this, go ahead and follow yatsy & once yatsy follow you back, DM your case text.

If you are interested in checking out the code or want to do a code review, head to Google Code page

Non-functional features are as important as functional features in determining the success of an open-source application. Users should be able to download and try most of the functionality, without complicated installation steps. Equally important is the ease with which it can be deployed.

While striving to keep these boundary conditions for end-users, developers prefer a language (and framework) that enable them to transform their brilliant ideas into working code quickly.

With such a thought process, I searched for a framework to develop YATSY – an open source helpdesk application for small businesses. As the title says, I settled on web2py because of the following reasons:

It is on Python: If you didn’t know, Python can be learnt intuitively. In the recent years lots of Python-based frameworks have evolved improving developer’s productivity drastically. Python places minimal constraints on the developer; hence development is generally quick.

It adapts to Schema Changes: Schema changes are an inherent part of development; especially if you follow the open-source mantra of ‘release early; release often’. Web2py automatically changes db schema if it detects a change in the underlying model. You don’t need to drop and recreate schema or issue alter table commands. One less head-ache for developers.

Its a self-contained Framework: web2py is based on MVC pattern and it comes bundled with most of the components needed for web-development – authentication, authorization, form generation & validation,  internationalization, admin interface, ajax (jQuery) and so on.

Its well documented: Yes it is a pity that the official manual has to be bought but Massimo, the lead developer, seems to have a justification for it. I went ahead and bought the manual and I should it is fantastic – he explains each component of the stack pretty well.

It can be installed easily: It is based on Python,  but it is not a pre-requisite to run web2py. Download, Unzip, Execute are all that is needed to get started with web2py development – on any OS.

It can be hosted on AppEngine: This is a big plus for me. Google AppEngine is the only cloud hosting that I am aware of that provides a free hosting for Python based applications. So potential users of YATSY can try free GAE hosting before moving to paid hosting. Deploying web2py application to AppEngine is a one-click affair.

It can be hosted elsewhere too: Web2py provides the flexibility to host the developed application anywhere Python can be installed. This means that users are not tied to GAE. If they want to install in their own servers, it is no problem.

With web2py providing the basic blocks for non-functional requirements, I find it easy to develop YATSY. You can check out the code at Google code and try it at Google AppEngine.

An irony of being in software industry is that as I gain more experience, I go farther away from constructing software. I keep learning lots of abstract concepts, but don’t get to test them. Not to be out-dated, I write pieces of software myself to test these concepts and theories. Its like being in college continuously!

Of late, I’ve been reading a lot about cloud computing, SAAS, REST and web2.0. But I couldn’t find a way to test them. So I decided to develop an application, which I named YATSY – Yet Another Ticketing System – utilizing years of experience in customizing other helpdesk, support desk and service desk systems.

Only Google offered a free hosting (limited free hosting; with an option to upgrade) on the cloud. With its current offering Google AppEngine (GAE) supports only Python. And web2py, a python web-framework, makes it extremely easy to develop for GAE. Not only that – web2py claims to make it easy to build stand-alone applications for all the three platforms: Mac, Linux & Windows. Though web2py doesn’t have many contributed 3rd party plug-ins, I went ahead with web2py because of the above feature set.

One more negative about web2py is that it lacks a fine documentation. So it is little difficult for beginners. Yet discussions on their google group compensates for this lack.

With that said, web2py does make web-programming easy and hosting on GAE is even easier. Here is what I’ve been able to achieve.

You can see it hosted in Google AppEngine. The code is checked in Google Code.

Your comments are welcome.

Few books grab your attention on the first page and keep it that way until the last. It is surprising that a technical book written by a technical person would be such a one. As I read every page of ‘The mythical Man-Month‘ (MMM), I was thinking to myself, “Damn, I should’ve read this book in college; or at least when I started with my career”. The author, Frederick Brooks, is dealing about those invaluable lessons that I learnt hard way over these many years in this field.

Every problem that the author talks about is so relevant today. Fundamental to the book is the ‘fallacious and dangerous myth about interchangeability of men and months‘. Even today when I present effort estimates to stakeholders, the immediate question is, “So if we double the team size, we should half the time to build this application?”. Brooks derives his response from a restaurant menu in New Orleans – ‘Good cooking takes time!’. Some tasks can’t be hurried without spoiling the result.

Or take the problem of communication. Though every one talks the same business language (English), their interpretations vary. Often one hears, “Oh! you meant that? I thought it was something else!”. Despite plenty of modeling techniques, understanding between parties involved remains a paramount problem in running a software project. (This is compounded in offshore projects).

Those of us who have handled large systems with different functional owners for different modules would have dealt with the issue of ‘conceptual integrity‘. I have managed such projects and it is not only difficult to integrate these modules; such systems throw enormous amount of confusion to the end users.

Building prototypes and releasing alpha & beta software are a common practices today. Open Source Software Practice advocates ‘release often; release early’. Yet, I’ve witnessed large projects with multi man-year effort and high complexity being developed in isolation after gather user requirements. When the project is released after years of development, the ‘actual need and the user’s perception of that need’ changed; and the project is a colossal failure bringing frustration and humiliation to the technical team.

These are just few of the problems and solutions discussed by Brooks. As I said in the beginning of the article, all the issues discussed Brooks are surprisingly relevant today. If you are in software stream – as a developer or as a functional analyst or as a manager – you should read this book. It will avoid you going though the path of agony.

I’m continuing from my earlier posts on Time Tracking Tool and Authenticating in GAE. When I started with Time Tracking Tool, I had the idea of having a server which will act as a centralized data repository – laptop/desktop tool, mobile tool should send data to the server and data will be analyzed in the server.

To that end, I got the windows desktop client tool talking to a server application. The server is a Google AppEngine Application. Currently there is not much in the server side. Just plain data that is transferred from the client tool. I’ll continue to work on the components and improve on the features – especially dashboard, analytics and similar other features.

To start with download the windows client tool (mySecs_x.x.zip – as the general practice x.x denotes the version) and unzip the content to a directory. You can use the client tool as a standalone tool (without synchronizing data to the server). This is the default configuration. However if you are okay to synchronize then modify the config.xml accordingly.

As I said before, client tool works as a stand alone tool by default. If you’re okay to synchronize the data, then change this to 1. I use Google Authentication, hence you need to have a gmail account and provide these in the respective xml nodes.

(A note about data privacy: I don’t pass your email id  to the server. So I wouldn’t know about your email id. If you are particular about your email id, which you should be, then create another gmail id for this purpose.

Also, since code for the server is shared, you can download the GAE code and host it on your own).

This is a working version. I’m using it to capture details and synchronize with the GAE server. As I continue to find bugs, I’ll fix them. However if you find bugs, please report them in the Issue Log. (A user reported that it doesn’t work with x64. I don’t know how to fix it. I will search around to fix it).

Next steps? Incorporate with Google Charts to provide some neat analytics reports, so that it really becomes an useful tool.

I need a help though. I am really bad at web design. So if you can take some time of you to design a cool home page and a list page, it will be great. I will surely acknowledge you for your contribution. So if you want to help, please contact me.