Saturday, March 19, 2011

Announcing the Silpa Indic languages Dictionary client for Android




Some time last week aashiks came over with an idea that we should throw an android front end on top of the brilliant Silpa language computing framework.

Even though Android inherently supports unicode, rendering of Indian languages like Malayalam etc are not supported. So when it was time to write a english->malayalam/other indian language dictionary client for android there was only one way to do it. Render whatever we wanted to display server side and pass it on as an image on the phone.

The Silpa framework had disjoint support for what we wanted i.e
1. Look up meaning for a given word in a given language
2. Render text in a given language and throw back the text as an image

Making two seperate calls to do something sounded a bit tedious. So ashik decided to wrap them both into one Silpa module that returns back the image in response to a simple HTTP GET, while I decided it was finally time to dip my feet in the Android SDK.

Impressions: Android SDK is awesome, Eclipse is a bitch

Our first running version of the client did its job but in the most fugly way possible. Being the Android n00b that I was , did'nt have enough sense to realise that HTTP calls shouldnt be made from the main activity. This resulted in the whole app freezing until the server responded with something.

After some frantic googling I came over this brilliant article in android developer blog

http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html

The usecase specified there was exactly what we were looking for(with very very minor modifications). Couple of hours of copy-paste-type-type-type later, we had what we wanted.

During the course of development we also ran into some minor issues with the Silpa dictionary like no response if the word was capitalized, resulting image being cut slightly at the top etc etc. All these were fixed promptly by the Silpa overlords Vasudev Kamath and Santhosh Thottingal.

So finally a week after the idea was conceived by aashiks we have a beta quality client out. It supports meaning lookups for English->Malayalam and English->Hindi

The entire source for the app can be found at https://github.com/rajivnair/Silpa-Dictionary-Android-client

You can download the unsigned apk from https://github.com/downloads/rajivnair/Silpa-Dictionary-Android-client/Silpa%20Dictionary.apk

Feel free to fork and may the foss be with you all.





























Saturday, January 08, 2011

The Programmer-Non Programmer immiscibility - Part 1

I happened to watch "The Social Network" recently and liked it a lot. I think its the only movie in which hacking(the way stallman puts it) is shown somewhat realistically unlike Tony Stark with his transparent phones and personal AI assistants.

Even though most people who see the movie see it as a story of "betrayal" or "fallout between friends" T see a more common pattern in both of Mark Zuckerberg's conflicts as depicted in the movie i.e Programmer-Non Programmer friction.

Both of Mark's "adversaries" in the movie were not programmers. And I think in both cases the fact that they didnt actually write any code somehow lessened the "value" of their actual contribution(if any).

I wont try to take sides in whether Mark Zuckerberg screwed over his friends or was he just smart. Being a programmer myself I'm afraid my stand would be inherently biased.

The fact that programmers and non programmers don't mix that easily is something gets highlighted to me quite frequently at work these days. At work most of the "people in charge" are non-programmers or at least people who would answer "No" to "Are you a technical person?". Quite often we are faced with situations where decisions taken by the non-technical crowd fly in the face of basic software engineering.

I've also realized that in most situations highlighting the problem and offering a sensible sounding solution fixes it , while in some cases and they are met with "I don't want it that way".

But if you dig a little deeper you'll find that the difference is not between people "likes to program" and "doesn't like to program". What usually turns off the self-professed non-technical people is a "fear-of-the-unknown". Its a powerful driving force. Very seldom do people want to try something new.

An easy analogy would be a kid refusing to learn to multiply and choosing to repeatedly add to get his answers. The sad part is that he does get his answer. But what he doesn't realize is that the time he spent repeatedly adding could have been put to better uses.

The situation further complicates when the kid who doesn't know how to multiply is put in charge of a team in which people who know how to multiple are a minority. Its a very sensitive situation in which any attempt by the "multipliers" to explain multiplication is quickly seen as either an insult on the intellect of the non-multipliers or arrogance or both. What I've learned from experience is that aggressiveness from either side worsens the situation.

The formation of a team with the above mentioned composition is unavoidable in todays IT scenario, since your average IT crowd is filled with programmers and non-programmers. Hence this situation cannot be prevented, however it is my firm belief that it can be dealt with easily.

The key to dealing with the above situation is to encourage a culture of criticism and debate. When I say a culture of criticism I mean that the following sentences should come up in team meetings frequently.

1. You are wrong and heres why
2. Actually what you are suggesting isn't right either and heres why
3. I was wrong -> Personally I rate this sentence to be the most important but the most scarcely heard sentence in today's workplace.

Ideally no decisions that impact the day to day working of a software team like new processes or new tools or new design should be implemented without them passing through a meeting room with every member present where the above mentioned three sentences are spoken.

The fundamental difference in which programmers and non-programmers approach problems pr work in general lead into interesting questions like this one - http://stackoverflow.com/questions/811246/how-to-hide-thinking-at-work-so-that-the-non-programmers-dont-suspect-slacking/


My office has a window with a pretty neat view of the KL skyline. Sometimes when im thinking about stuff I like staring out of it. Once my team lead asked whether i was free since i seem to have time to stare out of the window. Wonder whether i should start implementing some of the suggestions that people give in the above mentioned link.

I'm naming this article as part one of a series because I've been writing this one for over a week and I have a slight feeling that I'll have more to add on to this in the future.