Slumdog Millionaire - The Indian pysche gets offended

Slum dog millionaire has been globally extolled for its worth. In India, there have been mixed reactions. While we are beaming in all the attention Dan Boyle’s movie is providing, there have been accusations about the country being shown in bad light.

On one end of creative liberty, we accept Karan Johar making 3 hour movies where Gucci clad Amitabh dances with blonds and redheads. One can understand that Karan Johar is trying to woo the dollar bucks, but why isn’t he criticized for portraying India to be lavish when it clearly isn’t so. Creating positive vibes is good, but showing the not-so-lavish shouldn’t exactly be, offending? Well, may be the feel good emotions of such creations do help, however vicarious it might seem.

I am not trying to defend Slumdog behind the veil of reality, but simply as a product belonging to another end of creative expression. When compared to a run of the mill Bollywood money grosser, it clearly uses creative liberty in not portraying the affluent but rather celebrating the miserable and unfortunates (other end of the spectrum). I can’t help, but draw parallels with Gregory Roberts’ saga, Shantaram. So why is the movie offending to the Indian psyche? Is it because of the abused and homeless urchins? Is it for not-so-fair dusky toned heroine? Is it for the gaping religious and economic divide?

Let me guess.

I would like to call it a dichotomy. On one side of it, we always look at the brighter and greatly accentuated affluent (read Karan Johar movies), while on the other side we work to suppress the gloomy and miserable. It is like having an ugly-cyclops-like kid in your house you are afraid to let out of basement. Movies like Slum dog have been made by Indians too. Madhur Bhandarkar for instance. The only way to judge such movies is to treat them as pure creations just as we would openly do so to any other Bollywood movie.

Using MS Word for your resume? Hmmm..

Microsoft software on the desktop happens to throw up surprises every second week. Some are pleasant ones that that improve your productivity and leave you thanking Microsoft for the genius product. Some, as you might has guessed it, are not so pleasant and leave you clueless, angry and frustrated.

If one has been in the workplace for too long, (as i found out lately) one cannot get all the resume items in one go. So you write down your first project details, then think about what did you fiddle with and then update your resume. After 4 years of dabbling around i had a lot of ego-enhancing resume items to show-off. It took me around 2 weeks to finally get my resume into some shape. As you see, I ending up having a lot of resume modifications and my word based resume blotted to 200KB+. Impervious to the memory efficiency of Word, I also modified my resume summary to fit the job descriptions, every time I applied. A usual practice followed by the sensible job seekers to avoid one's resume being unknowingly modified by the ever eager consultancies.

So what did MS Word do?

It recorded all the changes that had gone into my resume from the time the document was created. No wonder the document a reflected 200KB size. With this heavy resume of mine, I applied to a job that I considered to be a 100% match for my skills. But, I got a blunt rejection from a company who were armed with a fake resume tracking tool that read back all the previous MS Word resume versions. Thanks to the recording function of MS Word, the company considered my resume to be a falsely modified resume just to suit their requirements. Nice tool and an even better MS Word.

Wonder why Word keeps all the records even if Undo function doesn't work after you save and close a Word document? I wasn't even aware of the fact that Microsoft keeps a track of all the changes that you ever make to a word document.

But a nice work around exists for such unpleasant behaviors. Copy your entire resume and paste it into a new word document you are about to apply with. When i did this, my resume size scaled down to 74KB from 200KB.

Hope this post helps some honest soul.

Concurrency Screw-ups

The above code will work perfectly, except when more than one task try to access the same port register. Since the port setting statement is not atomic, the 3 assembly steps could be pre-empted at anytime. Consider tasks A and B, both accessing PortA bits 0 and 1 respectively.

Task A code
1A. mov R0,PortA ; get PortA contents into R0
2A. OR R0,0x0001 ; Or the contents of R0 with bitmap
3A. mov PortA,R0 ; restore the modified PortA from R0

Task B code
1B. mov R0,PortA ; get PortA contents into R0
2B. OR R0,0x0002 ; Or the contents of R0 with bitmap
3B. mov PortA,R0 ; restore the modified PortA from R0

Lets say, Task A intends to set bit 0 of PortA, when after step 2A, gets pre-empted by Task B. Since Task B has no way to know that there exists another task accessing a shared resource as itself, it takes the snapshot of PortA register available to it and goes ahead with steps 1B to 2B. Once Task A cones around to complete its job of setting with steps 2A and 3A, it posseses an old snapshot of PortA. Task B will be in for a surprise as bit 1 is over-written to 0 by Task B. The result is Port A bit 1, if got set will only be so for few moments. The result can be as graver as your imagination can carry.

The solution
Any solution presented would need to involve a method that controls access to shared resources like ports. Task A could either flag the port register as used so as to tell Task B to be careful, or just force the 3 steps to be atomic. Below are the few easy get-aways:
- Disable interrupts globally and restore them once the steps have been completed.
- If restoring interrupts turnouts to be an overhead for a trivial task as port setting, some micros provide instructions which enforce CPU level atomicity for a given number of instructions.

Certain micros provide an architecture which overcomes this issue at the hardware level. There never is a single Port register that performs the setting as well as resetting functionality. Rather, 2 seperate I/O registers are dedicated for setting and resetting. Concurrency problem is again avoided here by allowing bits to change state only when 1 is written.

Reading Maintainence Code

My credentials for writing this article stems from the fact that for the past 1 year, i have read more code than pages in novels (exaggeration intended).

With software maintenance becoming the bread-winner for service based companies, a software maintenance engineer (call him so for the lack of pure jargon) many times finds himself staring at unknown code. Faced with similar situations, i follow the following steps:

1. Firstly get your hands on design documents
Documents do help. If you are totally new to the project, getting the top level idea is the first priority. Try to get hands on as much related documents as possible. More information is GOOD. The first place to independently search for such documents is a decently maintained repository. Search through the piles of DOCs, PPTs and PDFs and you will at times be pleasantly surprised to find that some cherubic soul would have done all the hard work for you. Look for documents with general ideas. Say no to specifics. A large maintenance project usually will have lots of literature dedicated to brilliant bug fixes and employee knowledge transfer docs. You are here to create such docs not read them!

2. Get a companion to help you through the introduction
Project induction training is for a Renaissance man. But your job requires you to zero-in on your module as soon as possible. If you are lucky, your new colleague could help you out on a specific module of interest. Ask as many questions as you can about your module. How is the module designed? Are the design documents reflecting the actual software or are they relics already? What is the complexity level of the module? Ask questions from your point of view. For example, you might be UNIX master, try to correlate the new system with your old experience. This will give you familiarity amongst the unknown. These steps will give you a nice platform to start-off.

3. Get the right code to travel through
In a large maintenance project you don’t need to spend time and energy reading a feature in the code which has been culled long ago. Always get the right code which means the latest release code. Keep reality at the nearest.

4. Check the directory structure
Every project will have a directory structure that reflects its modularity. Modules are divided into repository element or directories. The same structure could again be followed within a complex module. Armed with the general structure of the software, go through the various directories of the repository. Within the module's directory look through each of the file headers of source and headers files for the little more detailed picture. Some files will be deal with module's kernel, others with utility routines, wrappers, inter-module interfaces and some others with do job at all. Getting acquainted with such information will help you in traversing the code later. The modules are never standalone and hence share files with other modules. These shared elements may lie inside the module's directory or someplace else. Iterations of code browsing will later reveal these elements slowly. Patience. Period.

5. Get a good source code browser
A good source code browser goes a long way in quickly ramping you up. A code browser like Source Insight is a very effective tool designed to be saviour for the code challenged. Forget VI, adapt.

6. Observe the data elements / control flows of the code
Step 1 introduces you to important data structures. Look for such elements. These are the structures you will have to be careful about, once code editing begins. Control flows will introduce routines and data handling techniques. Look carefully at the routines as you parse the code. Generally one can figure out the top level and low level routines easily after a couple of iterations of the code. Also the information gained in step 4 will help. The God may lie in small things, but nobody understands the entire code overnight by looking into details. Avoid looking into of complex calculations, code tricks intially. Instead go through multiple iterations of the code by incrementally increasing the detail level each time.

7. Prepare a call stack if needed for each control flow scenario
This activity can be clubbed with step 6. Recognize a scenario when control within the software moves from point A to B. Traverse the flow and note down the routines that you encounter. Next time when you are thinking about when a particular function is call, the control flow will strike you first.

8. Make use of the real system to learn
If the trainer happens to walk you into the lab after the project training, your learning process is in for a break. Looking at the actual system can sometimes trigger the enthusiast in one. Getting hands on the target system can make the code study a lot easier. If the target has debugging features to work on, the process can turn out to be fun. Break points, single steps, stack tracing facilities can be used as effective learning tools.