Lingaa->Rajni->Balleilakka->Choirs : How mass movies lead to high music

So I watched Lingaa yesterday.

Because of which I was googling and youtubing for rajni's impact outside india; and was largely expecting to find videos from japan - which I did.

But what was really interesting is that I found at least 5 to 6 videos of one song from Rajni's last movie - Sivaji - being sung by school choirs across US.

The song's called Balleilakka, and here's the original:
https://www.youtube.com/watch?v=Tma8zoLEPJU

Here's a sampler of schools choirs singing it:

Best that I found: https://www.youtube.com/watch?v=XQWLqcNr9B8
Really fast: https://www.youtube.com/watch?v=Rvo1_vLGAGo
Pretty good, but smattering of indians :) : https://www.youtube.com/watch?v=dUhMQYW-xmk
Pretty good: https://www.youtube.com/watch?v=09C8s1QhgqE
Shitty accoustics, but points for the effort: https://www.youtube.com/watch?v=jSJYVAB8XQU


.. and I began to wonder: why this song alone? None of them actually mentioned the source of the song; they usually called it an indian song in tamil. I think one mentioned that its AR Rehman's song.

So they were actually using it because it was a complex song musically - it was a tongue twister even for natural speakers of the language and what was really obvious from listening to it when sung by a chorus is that it had many layers and voices to it. I dont obviously know the right musical terms here, but in programming terms, it was a mutlithreaded song - multiple concurrent voices had to be active to make it happen, and each voice was sure to get knotted up in the tongue twister lyrics; not to mention that the beat was really fast! No wonder the choruses are taking it up as a challenge.

Its amazing that I live in a time when composers like Rehman have enough commercial clout to put complex music into a movie meant for the masses. Even better: not only do the intended audiences love the song, so do people who are serious about music!

Idea: A screenreader that's a market place, not a queue

Had this idea while in a meeting at work today where ADA was being talked about; and how making a page ADA compliant required reordering the markup - sometimes entirely.

What if the screen reader didn't read sequentially - like a queue of people who talk to a teller - and instead read everything that's on a page at the same time - almost like a marketplace where everyone's talking at the same time?

I'm not blind, but I have to imagine that this is how blind people perceive the real world anyway - as a cacophony of sounds that they have to filter out noise from. This is not that different from fully able people sensing the world and filtering what's important.

If we had such a screen reader, the document markup could be the cue for how "loud" each element would be, child elements could be "muted" in favor of the parent and so forth.

Todo: check if screen readers already do this.

Fixed order graphs with Graphviz

Graphviz continues to amaze me. I did not know until recently that they had an awk-like language for graphs within the graphviz package, but even closer home - there's a tool to control the order of nodes!

This is the one thing I've battled with out-of-the-box Graphviz for a long time - any new edge is likely to throw your neat-looking graph off-kilter *just because* that's the most optimal graph layout.

Well, not if you use osage, packmode and sortv.

I dont exactly know why its called osage, but this layouting engine actually obeys the order of nodes that you can specify with the sortv attribute.

You have to set the appropriate packmode setting, of course, and the correct incantation is:

packmode=array_uX

where X=1 if you want one column of nodes, 2 if two and so forth.

Here's a sample graph for a taste of what it looks like in practice (from the man page for osage, see example section):

digraph test123 {
    pack=8
    subgraph cluster0 {
        packmode=array_u1
        x[sortv=5]
        y[sortv=4]
        x0[sortv=3]
        y0[sortv=2]
        x1[sortv=1]
       
        subgraph cluster1 {
            mn
        }
    }
    b[shape=box];
    c[label="hello\nworld",color=blue,fontsize=24,fontname="Palatino−Italic",fontcolor=red,style=filled];

    a->z
    x->z
    a->b->c;
    a->{x y};

    edge [style=dashed,color=red];
    b->x;
}


Once you do that, you issue something like this:

osage testosage.dot -Tpng -o testosage.png

... and you should see a column of components with x at the bottom and x1 at the top.

Also, use

pack=16

to space the nodes out a bit. Default is 8

I fixed some hardware!

This is a personal first. I took my wife's laptop apart and repaired it!

My wife has a Lenovo 670 that we bought in India. Its a low-end laptop that I chose for her because we were in the market due to my son spilling water over the good Toshiba that she originally had. "You use it mostly for browsing", I had reasoned, adding: "Besides, its a Lenovo, which used to be a Thinkpad, so these things are rugged; and more importantly it has the chicklet keyboard so we're covered on the water spillage scenario from now on".

While it indeed was rugged, it didnt endear itself to my wife because it was slow as hell. Still, she was not a fan of the Mac and was happy that it was the one Windows machine in the household.

Fast forward 2.5 years later and across the globe where we are now, the poor laptop had fallen for the umpteenth time from the side table (I think it was the son again - this time a well-placed kick in sleep) and the wife found that she could no longer charge the laptop. The connector could still be seen inside, but it was not in its slot and couldn't be paired with the charger.

"Husband, can you see if you can fix this?" she asked. I quickly googled the nearest Lenovo service center and left it open in a tab for her to see.

A few weeks later, she got around to calling the service center only to be told that they didn't service any models sold outside the US of A, thank you very much.

We considered shipping it off true desi style with some hapless acquaintance to be delivered to a service center in India that DID service such models, but thought it might be not worth all that hassle.

So my wife repeated her original question and went one step further and found a web page with instructions on how to do it.

Two or three weeks later, I got around to looking at it. The initial steps were all pretty standard - unscrew 13 screws, turn over, unscrew 8 other screws and so forth. The rest were decidedly not unless you've been assembling and disassembling laptops (or other electronics) all your life.

Here's the thing about electronics these days: They're giant 3-D puzzles that have been put together in a space the size of a football field and then squished into the final size that you get it in. There is apparently one and only one way to take the thing apart and almost everything requires you to take the whole thing apart. Must be nice to be in a market where your product has no serviceable parts or the act of servicing it will render it non-serviceable.

So I got around to removing the battery (of course), back cover, the hard disk, the connection to the wireless lan and the optic drive. I had skipped the memory hoping it would not be germane to my fixing the power supply connection. Going through the next steps. however, it looked like the only way I could get to the power supply was by removing the fan, the cpu heat sink and the cpu itself.

Now this is not new territory to me - I HAVE disassembled a laptop before - solely because of my cheapness. Back in the early 2000s, they sold an abomination of a laptop called eMachines - they had great specs and were cheap; except they killed themselves whenever you ran more than 3 applications because the cpu heated up past its allowed range due to the cheap heat sink they put in. One way to solve this was to open it up and clean out the sink yourself.

Anyhoo, because of that experience, I knew that taking the CPU out implies putting in new compound - something that I didnt have then nor had now (side note: I had taken a chance with the eMachines and put the hardened compound back as-is and it did work for a while :) ). So I did what everyone would do - tried taking either the bottom half of the laptop or the bevel surrounding the keyboard without touching the CPU or its sink.

After about 5 hours, I gave up. All natural light had gone by then and I really couldnt work with the incandescent lights and the Walmart tools that I had. So I gave up for the next few weeks.

Finally, I picked it back up today. Started at about 11 am and by 6 I had the bevel around the keyboard removed. Here's the kicker: Remember I told you that these things are 3D puzzles? Well, not only are they puzzles, they're also traps: manufacturers put in blue paint on screws and stickers on specific components that will tell them if we've actually looked inside. The thing that held me up for a good 4 hours? One screw that was hidden under a Lenovo sticker. After I found it at 3 hours and 57 mins counting, I realized that special gum those kindly folks at Lenovo used would not allow me to peel the sticker off. It had to be scratched out - leaving no doubt that whatever warranty this laptop could have been under has now been voided.

Once the bevel was removed, I could look at the connector. Sure enough everything was fine and all it needed was to be put back in place. To their credit, this Lenovo had taken all kinds of weird angles of the charger and worked well until recently. I dont know if there was a bit that did hold it in place, but it looked like all they had going to keep it there was a snug fit. So I made that a lil bit snugger with some quickfix glue and closed the whole thing up.

And by "closed the whole thing up" I mean "Spent the next 2 hours painstakingly following the instructions in reverse order, of which half an hour was spent looking - unsucessfully - for the one washer that got away and was now hidden in the beige savannah called my carpet, then reaching the last step only to realize that step 8 was reinstalling the keyboard (a link off to another page) that I'd missed so going back a few steps to take gajillion screws out again and popping the keyboard out and finally getting it all together with 2 screws outside"

As if on cue, the wife showed up and asked nonchalantly: "How's it going?". This must be how CEOs and VPs feel.

We fired it up and it hasn't exploded - yet.

My wife, of course, noted dryly that it seems somewhat slower - like my hardware machinations could have magically slowed down the electronic pathways inside Windows 7.

I was just happy that it worked :). We hi-fived. She said she's proud she married someone who knows how to fix things.

A better portable environment

For a long time I've tried to create a portable environment for myself, without much success.

A portable environment is a collection of all software that I need and use for development available as a set of files on a USB stick. I should be able to put it into any machine (Win, OSX or Linux) and do everything that I want to do.

PortableApps comes pretty close. Portable msysgit gives a uniform bash shell everywhere and as long as i'm miserly with the languages I want to work with, I should be OK. Maybe cheat a bit with an install of Sublime Text (zip install used via Wine on Linux) and I'm golden.

At least that's what I've settled for now.

But sometimes its not enough. You want a full environment. You want to not have to copy files or git rebase. So I tried VirtualBox. The idea was that the only install I'd need was Virtual Box on each machine that I want to use the environment on, and the VDI file would be on the stick. That way everything remains in one place.

Except the VDI files dont work right with OSX. Or at least didnt on Snow Leopard. I've not tried on Mavericks.

But in the meantime, I had an idea: How about a node-webkit based environment? As long as the stick has executables for all OSs, the app itself can be run. There are enough and more terminal emulators, editors and so forth in JS these days. What is still not in JS (versioning, file system, etc) could probably be filled in using emscripten.js maybe?

Its a thought for 2015 :)

Idea: Stable visualization of a codebase

I have been thinking lately about visualizations of a codebase - spurred on because of recently rediscovering Software Catography and its successor - Codemap. Coincidentally, I also wanted to create my personal website as a "visual representation of the web of connections that it is", which essentially boiled down to a stable visualization.

When I looked at the tools that are currently available to do this, it seems like they are overly complex. The closest was Gource, but it focuses on the people who worked on the code and doesnt generate a stable visualization.

So here's my idea:

• The visualization will be created from the commit history of the codebase.
• Once created, the visualization is not a snapshot, but can be enhanced over time to show changes. So the output format should contain the history of changes.
• The visualization is essentially a Treemap-ish diagram with time along the X-axis and size along the Y.
• Each object(file or directory) is drawn as it comes to life in the commit log and is represented as a rectangle.
• Position: The first object  that is created gets the position x=0 within its parent, the second gets x=1 and so forth. Once assigned, these positions are permanent even after the object is moved or removed.
• Dimensions: The width remains the same for all: files have a width of 1 unit and directories have a width equal to the sum of the widths of its contents. The height is equal to the size of the file.
• When an object is changed, its old size shows up as a faded outline within the newly sized rectangle - somewhat akin to the age rings of trees. Size reductions may show age rings outside the current rectangle.
• When an object is moved, its old position shows a faded outline and objects after it do not move to take up the position.
• Similarly when an object is deleted, its old position shows a faded outline.
• Keeping the visualization contained: This is where the Treemap concepts are helpful. The complete visualization's size will be calculated inside-out: the size of the deepest directory will control the % contribution of its parent and therefore transitively its grandparent, and so forth. This way, the visualization can be contained in a finite space. At its smallest size, each "rectangle" will be reduced to a line: the position still remains as described above, the width is reduced to 1 pixel and the length is still the size of the file. No rings are possible at this level of compaction.
• Controls: The visualization will have:
• Play: A way to see the evolution of the codebase a la Gource
• Zoom in and out
• Time Filter: A way to filter out older rectangles. This will essentially show the current state of the codebase, but since all positions are fixed, it will give an idea of how far the current state is from the original.
• Object Highlight: this will highlight a particular file or directory to "show where it is in the map"
• Object Trace: This will high light the path of the object throughout its evolution in the codebase.
• Commit Highlight: Highlight all files in a commit

The advantages I see with such a visualization is that it combines a stable spatial representation of the code along with its evolution over time. Using a treemap representation essentially keeps it bounded so that the view could be injected into current developer environments without taking up too much screen space.

Implementation notes:

• A quick way to implement this might be using html divs.