I visited Leh, Laddakh in mid 2001 for trekking and seeing the place. Four of us completed our trek along Laddakh's Markha Valley in about eight days and decided to travel south to Srinagar in the Kashmir valley. Although Laddakh and Srinagar are both part of the state of Jammu and Kashmir they have dissimilar cultures and political atmosphere. The predominantly Buddhist Leh has been spared most of the violence that has plagued the state while the predominantly Muslim Kashmir valley has been at the heart of incidents.
We hired a taxi to ferry us to from Leh to Srinagar. The road connecting the two passes through several towns including Kargil that bore witness to a small scale war as recently as 1999. We started at noon from Leh. In spite of the modest distance (~475 Km/300 miles) ahead of us we were obliged to stop in Kargil at nightfall for various reasons. Traffic through the narrow Zoji-La pass was regulated so that vehicles driving North-South could only travel through from sunrise to noon. For the rest of the day the pass would be used by vehicles traveling in the opposite direction. Moreover nighttime civilian travel was not common, even discouraged.
In Kargil we checked into a hotel for the night. During dinner the manager came over and enquired if we had hired the cab in Leh. After we answered he told us to expect the driver to come up with an excuse to end the journey in Kargil and go no further. We would be offered an identical vehicle with a new driver to take us to our destination at no extra cost. It happened exactly as he predicted. Early next day our driver informed us that the car wouldn't start but we could continue our journey in another vehicle that had miraculously appeared out of nowhere in the predawn cold.
The incident was puzzling until we discovered the reason behind it. Our first cab driver was a Buddhist from Laddakh. He didn't dare to venture into Kashmir valley for fear of his life. His replacement was a Muslim from Srinagar who stayed away from Leh. The desire to survive had prompted them to come to an arrangement through which they could still work and split fares.
The rest of our journey was uneventful save for the hair raising transit through the narrow paths of Zoji-La. We reached Srinagar safely and settled into a house boat in Nagin Lake.
I haven't been to Kashmir since. I wonder if things have changed sufficiently for the cabbies to drop their arrangement.
Tuesday, October 16, 2007
Bank Notes
I recently had to deposit money into a friend's account. He has an account with State Bank of India, Trivandrum branch. For those of you not from around here, that branch is in a city in a different state. All I had to do was:
Armed with this information I visited the bank and presented my request. I was promptly informed that this particular branch would only let me make deposits if the target account belonged to this branch. So much for "core banking".
All was not lost yet. I recalled another branch located in St. Marks road and asked if visiting that one would help. Unfortunately, no. That particular branch was for "specialized personal banking" whereas I needed a "general branch". The nearest one was a good 10 Km away. I later found that "general branch" is a vaguely defined concept; the "advanced options" section of SBI's Branch Locator does not include it among the more than a dozen 'branch type' options listed.
With that I gave up on SBI. Fortunately my friend had an account with Indian Bank. IB was a little more forthcoming with information about their branches. I located the nearest one and went over. I found the printed pay-in slip a bit confusing in spite of instructions written in three languages. Luckily one of the employees hinted that what mattered was the inclusion of relevant information in the form; the "where" did not matter. So I filled up the form as best as I could and paid the money.
This episode left me with some questions.
- Locate the nearest SBI branch
- Make the deposit
Armed with this information I visited the bank and presented my request. I was promptly informed that this particular branch would only let me make deposits if the target account belonged to this branch. So much for "core banking".
All was not lost yet. I recalled another branch located in St. Marks road and asked if visiting that one would help. Unfortunately, no. That particular branch was for "specialized personal banking" whereas I needed a "general branch". The nearest one was a good 10 Km away. I later found that "general branch" is a vaguely defined concept; the "advanced options" section of SBI's Branch Locator does not include it among the more than a dozen 'branch type' options listed.
With that I gave up on SBI. Fortunately my friend had an account with Indian Bank. IB was a little more forthcoming with information about their branches. I located the nearest one and went over. I found the printed pay-in slip a bit confusing in spite of instructions written in three languages. Luckily one of the employees hinted that what mattered was the inclusion of relevant information in the form; the "where" did not matter. So I filled up the form as best as I could and paid the money.
This episode left me with some questions.
- What is "core banking"? Does it exclude paying in money to accounts established in other states/cities/branches, especially in this day and age when all banks are touting their internet facilities?
- Why does a national bank with vast outreach make depositing money to a non-local account so difficult? Particularly in cities like Bangalore where a significant percentage of inhabitants are from other states.
- Who designs the pay-in slips used in banks? I feel that at least some of them need to be redesigned to make them easier to use. Something akin to usability in software applied to banking.
Saturday, June 02, 2007
Django Testing Gotchas
I recently started using Django's newly introduced capability to make use of test fixtures. In order to do this all test classes that need fixtures have to be subclasses of Django's custom TestCase class rather than the customary unittest.TestCase. I had written about 17 or so test cases split across two test classes. One of these test classes used Django's fixtures.
Each Django test run (kicked off by running python manage.py test) involves the following steps:
After reading up more about the problem I figured that I could probably cut down on the time taken by "refactoring" my tests and moving unnecessary fixtures out to "initial fixtures" so that they would only be loaded once. Luckily this would work in my case as my app only used the data for reference; it did not modify any. I was therefore not constrained to load the data before each test.
I made the necessary changes and re-ran my test cases. The time taken to execute the test cases improved ever so slightly. It now took about ~140 seconds.
I was still unhappy with the results. Since I was not using any fixtures, I decided to substitute Django's TestCase with unittest.TestCase. And voilà! It was as I had engaged hyper drive. 24 tests now took a mere 0.2 seconds to run!
Naturally the question that came to my mind was that in the absence of fixtures, what on earth was taking up so much time? Django is known for its speed vis a vis Rails; I had come to expect the same kind of superior performance while running tests too. I don't have an answer right now. I hope to come up with one after I take a look at Django's innards.
Each Django test run (kicked off by running python manage.py test) involves the following steps:
- Create test database
- Create the necessary tables
- Load "initial fixtures" if any. These have to be located in a file named initial_data with suitable extension denoting fixture type (.xml, .json etc.)
- Load fixtures specified in each test case
- Execute any one test
- Remove fixtures loaded in step #4
- Repeat steps 4 through 6 until all tests have been executed.
After reading up more about the problem I figured that I could probably cut down on the time taken by "refactoring" my tests and moving unnecessary fixtures out to "initial fixtures" so that they would only be loaded once. Luckily this would work in my case as my app only used the data for reference; it did not modify any. I was therefore not constrained to load the data before each test.
I made the necessary changes and re-ran my test cases. The time taken to execute the test cases improved ever so slightly. It now took about ~140 seconds.
I was still unhappy with the results. Since I was not using any fixtures, I decided to substitute Django's TestCase with unittest.TestCase. And voilà! It was as I had engaged hyper drive. 24 tests now took a mere 0.2 seconds to run!
Naturally the question that came to my mind was that in the absence of fixtures, what on earth was taking up so much time? Django is known for its speed vis a vis Rails; I had come to expect the same kind of superior performance while running tests too. I don't have an answer right now. I hope to come up with one after I take a look at Django's innards.
Wednesday, February 14, 2007
Moving from Rails to Django: Replacing flash[:notice]
One of the most common practices I came across while learning Rails is the flash[:notice] mechanism used to send (error) messages to the template. Consequently it was also one of my first targets to migrate when I started moving a pet application from Rails to Django.
I came up with a simple (and all too obvious) way to send error messages to the template. I am sure that there are better ways to do this. If you know of any, please take a minute to share them.
First, the Rails snippet. Next, the equivalent in Django. The template in Rails ... ... and the template in Django. While testing in Django, flash can be treated just like any other context variable.
I came up with a simple (and all too obvious) way to send error messages to the template. I am sure that there are better ways to do this. If you know of any, please take a minute to share them.
First, the Rails snippet. Next, the equivalent in Django. The template in Rails ... ... and the template in Django. While testing in Django, flash can be treated just like any other context variable.
Request to Blogger
Please, please add a formatting tool/plug in/some other mechanism to highlight code syntax. It took me two frustrating hours of cutting and pasting to add code samples to this post. Even now, I am not completely happy with the results. And as automatically inserted line breaks (BR tags) and highlighter do not go together, I have to manually insert BR tags in all my posts :( Thankfully, I am not a prolific blogger ;) but even then it sucks.
I am not partial to any specific utility. In this case I followed the example set by other bloggers and used dp.SyntaxHighlighter. But I will (and so will most others, I suspect) gladly use your tool if you were to provide one.
C'mon guys, after all you are Google :)
I am not partial to any specific utility. In this case I followed the example set by other bloggers and used dp.SyntaxHighlighter. But I will (and so will most others, I suspect) gladly use your tool if you were to provide one.
C'mon guys, after all you are Google :)
Tuesday, February 13, 2007
Moving from Rails to Django: Migrating Tests
Context
I am in the process of migrating one of my small "pet" applications developed in Ruby on Rails to Python using Django. One of my first concerns was migrating tests, both unit (testing models) and functional (testing 'controllers' in Rails/'views' in Django) from one framework to the other. After looking around the documentation, asking questions and conducting some experiments I have some answers. Here is a listing of what I have found out so far.
Note
These examples will only work with the latest development version of Django.
Locating your tests
Rails
Usually located under the path [path_to_app]/test/functional/. There is usually one test source per controller, named as [controller_source_without_extension]_test.rb. For example if the source for a controller, say, 'Generator' is written in [path_to_app]/app/controllers/generator_controller.rb, then the corresponding test should be present in a file named generator_controller_test.rb
Django
The easiest way (see the official documentation) is to add all your tests to a file called tests.py and drop it in the application folder, at the same level as your models.py and views.py.
However I prefer to have a separate test source structure if I can help it. This has the added advantage of keeping I decided to adopt the convention used by Rails and came up with the following tree:
Fixtures
Fixtures are readily available in Rails. There are not quite there yet in Django and I am as righteously angry as the next ex-Rails user ;) But do not worry, they are on their way and will be available shortly. I am experimenting with a really dirty solution in the meantime. More on this in a subsequent post.
Writing Tests - setup
Rails
A typical setup() method in Rails looks like this: Django
The framework provides a test client to simulate browser calls. The best place to create a test client object would be the setup method.
Writing Tests - GET requests
Rails
My first objective was to test if a GET request to the controller/URL 'generator/index' was being handled properly. "Properly" in this case means three things:
Django
While the objectives remain the same, the steps vary. The key differences I noticed were:
Writing Tests - POST requests
Rails
A simple "happy path" POST request test looks like this in Rails: Here, in addition to checking the response I am also verifying that a particular session variable was set properly.
Django
Here again we find that there are no wrappers for session and that it is easy enough to add some. The session object itself is readily available and can be accessed using the test client.
Running Tests
Rails
The easiest way is to execute ./rake from the command line. There are separate tasks available (such as test:functional, for instance) in case you wish to run the functional tests only.
Django
The easiest way is to execute ./manage.py test from the command line. This will run the tests for all applications in the project. If you wish to test only one application, feed its name as an additional parameter.
Django Template Nuances
Django provides simple inheritance mechanism for templates. I personally like it :) What should be remembered is that using inheritance changes the testing process slightly. For instance, consider a view index that renders a template say, index.html. This template inherits from another, named base.html. A GET request test for the view would look like this: Note the difference from the earlier test. When template inheritance comes into play, response.template will resolve into a list of all the templates involved in the hierarchy, listed parent first. Corresponding to each template, there will be a separate context object at available at the same index in response.context (which will also resolve into a list)
I am in the process of migrating one of my small "pet" applications developed in Ruby on Rails to Python using Django. One of my first concerns was migrating tests, both unit (testing models) and functional (testing 'controllers' in Rails/'views' in Django) from one framework to the other. After looking around the documentation, asking questions and conducting some experiments I have some answers. Here is a listing of what I have found out so far.
Note
These examples will only work with the latest development version of Django.
Locating your tests
Rails
Usually located under the path [path_to_app]/test/functional/. There is usually one test source per controller, named as [controller_source_without_extension]_test.rb. For example if the source for a controller, say, 'Generator' is written in [path_to_app]/app/controllers/generator_controller.rb, then the corresponding test should be present in a file named generator_controller_test.rb
Django
The easiest way (see the official documentation) is to add all your tests to a file called tests.py and drop it in the application folder, at the same level as your models.py and views.py.
However I prefer to have a separate test source structure if I can help it. This has the added advantage of keeping I decided to adopt the convention used by Rails and came up with the following tree:
- [project]/[application]/test/functional/ for functional tests and
- [project]/[application]/test/unit/ for model tests.
Fixtures
Fixtures are readily available in Rails. There are not quite there yet in Django and I am as righteously angry as the next ex-Rails user ;) But do not worry, they are on their way and will be available shortly. I am experimenting with a really dirty solution in the meantime. More on this in a subsequent post.
Writing Tests - setup
Rails
A typical setup() method in Rails looks like this: Django
The framework provides a test client to simulate browser calls. The best place to create a test client object would be the setup method.
Writing Tests - GET requests
Rails
My first objective was to test if a GET request to the controller/URL 'generator/index' was being handled properly. "Properly" in this case means three things:
- Ensure that the response came back with an HTTP status of 200 OK;
- Ensure that the appropriate template was used; and
- Ensure that instance variables were present and had expected values.
Django
While the objectives remain the same, the steps vary. The key differences I noticed were:
- There are no built-in wrapper methods for GET/POST. It should be noted that it is easy to enough to code wrappers should one so wish.
- Likewise there are no equivalents for wrappers such as "assert_template" or "assert_response"
- Django uses a different philosophy when it comes to passing variables to templates. Instance variables are not directly passed to templates; rather they have to be explicitly passed using a context object or a call to locals()
Writing Tests - POST requests
Rails
A simple "happy path" POST request test looks like this in Rails: Here, in addition to checking the response I am also verifying that a particular session variable was set properly.
Django
Here again we find that there are no wrappers for session and that it is easy enough to add some. The session object itself is readily available and can be accessed using the test client.
Running Tests
Rails
The easiest way is to execute ./rake from the command line. There are separate tasks available (such as test:functional, for instance) in case you wish to run the functional tests only.
Django
The easiest way is to execute ./manage.py test from the command line. This will run the tests for all applications in the project. If you wish to test only one application, feed its name as an additional parameter.
Django Template Nuances
Django provides simple inheritance mechanism for templates. I personally like it :) What should be remembered is that using inheritance changes the testing process slightly. For instance, consider a view index that renders a template say, index.html. This template inherits from another, named base.html. A GET request test for the view would look like this: Note the difference from the earlier test. When template inheritance comes into play, response.template will resolve into a list of all the templates involved in the hierarchy, listed parent first. Corresponding to each template, there will be a separate context object at available at the same index in response.context (which will also resolve into a list)
Thursday, September 14, 2006
Advantages of working on Decent Code
I recently switched employers for the first time in my working career. After spending six and a half years with a huge (tens of thousands of employees) software services company I recently moved to a much smaller product company. After the initial few weeks getting acquainted, trained etcetera, I recently started hacking away at the code base. It came as a surprise to me that after three days spent adding enhancements to an existing (mostly Java) application I was no where near as stressed as I would have been in the past. I realised that this was mostly thanks to the decent code base that the application's developers had created in the first place. The code did nothing extraordinary; it was merely well structured, cleanly packaged and came with a good many automated tests. And boy, what a change it made. No need to spend days merely building the app; no more personal source code repositories (I have been forced to install CVS in my machine on several occasions in the past thanks to general ignorance about SCM tools).
The contrast with what I have been through while with my previous employer could not have been starker. I have worked in half a dozen 'legacy' applications for my previous employer and not once have I not been frustrated by poorly written code. Adding insult to injury were the indifferent "developers" who had created the monster in the first place.
The moral of the story is that good code goes a long way towards stress reduction and boosting employee happiness. Should I need to change jobs in the future, I will ask any potential employer to show me their existing code base. If the code sucks, I will politely bow out.
The contrast with what I have been through while with my previous employer could not have been starker. I have worked in half a dozen 'legacy' applications for my previous employer and not once have I not been frustrated by poorly written code. Adding insult to injury were the indifferent "developers" who had created the monster in the first place.
The moral of the story is that good code goes a long way towards stress reduction and boosting employee happiness. Should I need to change jobs in the future, I will ask any potential employer to show me their existing code base. If the code sucks, I will politely bow out.
Tuesday, July 18, 2006
Speechless
First they ban Blogs. If that wasn't bad enough, the bureaucrats - who get paid by taxes people like me pay at the rate of 33%, deducted at source - have the temerity to say "We would like those people to come forward who access these (the 12) radical websites and please explain to us what are they missing from their lives in the absence of these sites."
You f~!@#$% morons! Ever read the 'Objectives Resolution' of the Indian Constitution? The part where it says that "All people of India shall be guaranteed and secured social, economic and political justice; equality of status and opportunities before law; and fundamental freedoms - of talk, expression, belief, faith, worship, vocation, association and action - subject to law and public morality"?
What would you babus propose next? Filter search results like our neighbour? I agree with Ravi Mohan. It is time to think about leaving.
You f~!@#$% morons! Ever read the 'Objectives Resolution' of the Indian Constitution? The part where it says that "All people of India shall be guaranteed and secured social, economic and political justice; equality of status and opportunities before law; and fundamental freedoms - of talk, expression, belief, faith, worship, vocation, association and action - subject to law and public morality"?
What would you babus propose next? Filter search results like our neighbour? I agree with Ravi Mohan. It is time to think about leaving.
Wednesday, May 03, 2006
Presenting 'Blog Packager'
- Are you a would-be 'insightful blogger' who has the ideas but just cannot get the right words to express them?
- Are you a would-be 'hot blogger' craving the attention of a thousand raving fans?
- Are you a would-be 'celebrity blogger' who craves publicity but cannot merit even a hyperlink?
- Are you a would-be 'blogger-columnist' aspiring for a multi-thousand dollar contract from WashingtonPost.com but just cannot get noticed?
- Are you a would-be 'blogger-turned-author-turned-screenwriter-turned-director'**?
** Blog Packager will only take you as far as step 1, i.e. blogger. You will have to rely on a "book packager" and possibly a "screenplay packager" and a "directorial packager" to go any further.
So what is the deal?
Simple.
- You, the aspiring blogger, will approach me with your ideas and USD 250 (or Rs. 10,000) as retainer.
- I will hire jobless experts related to your field from wherever they can be found.
- The experts will then add flesh and sinews to your idea skeleton, in the process internalising (and thoroughly obfuscating) the ideas from all the bloggers they can find using Google.
- I will sign a contract with the first party interested in the blog and offer you a percentage of the contract money.
- In case you are too ugly to be photographed, we will supply you with photos to use in the blog.
- You can write about anything under the Sun. However, our market surveys indicate that narratives of the experiences of a non resident Indian teenager are in demand right now.
- If the venture flops, it is solely your fault.
- If the venture fails and nobody hears about it, you can try again by paying an additional retainer fee.
- If anybody alleges intellectual theft you alone will take the blame.
- My name, the company's name or the names of any staff members will not figure on any apologies that you might be required to make.
- Copy editing is forbidden. All materials we choose to show you (which is rare) will have to be used as-is.
********
In case you are wondering, this entry was sparked by an article in the New York Times on the recent 'Opal Mehta' fiasco. The following paragraph from the article caught my attention:
In a statement yesterday afternoon Michael Pietsch, senior vice president and publisher of Little, Brown, said the company would not publish the second book under its contract with Alloy Entertainment, the "book packager" that helped Ms. Viswanathan develop the concept for "Opal" and shape its first four chapters. Alloy, rather than Ms. Viswanathan, signed the contract, believed to be worth $500,000 for two books, with Little, Brown. (Italics added)
Saturday, April 22, 2006
Taking the Joel Test
Recently I had a chance to read Joel Splosky's article 'The Joel Test: 12 Steps to Better Code' After reading through the article I took a few minutes to evaluate a software services company that I am familiar with using the 12 questions that constitute the test. I have reproduced the questions and my answers below.
Do you use source control? - No. Most projects that use source control tools do not use them the proper way. Archiving and taking back-ups is NOT Version Control.
Can you make a build in one step? - No.
Do you make daily builds? - No. Build process starts several days (or hours) before delivery. It starts 'offshore' and continues 'on-site'.
Do you have a bug database? - Not in all projects. In fact only a minority of the projects use any kind of bug tracker.
Do you fix bugs before writing new code? - No!
Do you have an up-to-date schedule? - Not really.
Do you have a spec? - Yes.
Do programmers have quiet working conditions? - No!
Do you use the best tools money can buy? - No. (Tools?! *Buy* tools? Are you crazy?)
Do you have testers? - Yes.
Do new candidates write code during their interview? - No! (Code?! Are you crazy?)
Do you do hallway usability testing? - What's that???? Oh you want an answer? Well, the answer is No.
According to Joel, A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
This particular company rated 2. It would rate 3 if I grudgingly treat a partial 'Yes' as a full 'Yes' for Question #4 (Bug Database).
Try this for yourself. Be honest. Look long and hard at the results. If you are employed in the Indian software services industry, you have permission to weep.
Do you use source control? - No. Most projects that use source control tools do not use them the proper way. Archiving and taking back-ups is NOT Version Control.
Can you make a build in one step? - No.
Do you make daily builds? - No. Build process starts several days (or hours) before delivery. It starts 'offshore' and continues 'on-site'.
Do you have a bug database? - Not in all projects. In fact only a minority of the projects use any kind of bug tracker.
Do you fix bugs before writing new code? - No!
Do you have an up-to-date schedule? - Not really.
Do you have a spec? - Yes.
Do programmers have quiet working conditions? - No!
Do you use the best tools money can buy? - No. (Tools?! *Buy* tools? Are you crazy?)
Do you have testers? - Yes.
Do new candidates write code during their interview? - No! (Code?! Are you crazy?)
Do you do hallway usability testing? - What's that???? Oh you want an answer? Well, the answer is No.
According to Joel, A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
This particular company rated 2. It would rate 3 if I grudgingly treat a partial 'Yes' as a full 'Yes' for Question #4 (Bug Database).
Try this for yourself. Be honest. Look long and hard at the results. If you are employed in the Indian software services industry, you have permission to weep.
Monday, March 06, 2006
The Reverse Truck Factor
The speaker at a recent technology user group meeting introduced me to the concept of "Truck Factor" of software projects. The Truck Factor (TF) is defined as the number of people who would need to be hit by a Truck to seriously jeopardize the project. It is a measure of the number of people the project cannot do without; the higher the number the better. Interesting.
I quickly did a mental exercise to find out the TF for the projects that I have worked in. It dawned on me that not only was the TF very small, there was a Reverse Truck Factor (RTF) in play. I define RTF as the number of people who need to be hit by a truck (or several, just to be sure) for the project to stabilise and have anywhere near a decent chance of achieving what it is supposed to. The lower the RTF, the better are the chances of a project to succeed.
Unfortunately for me, the RTF has been consistently high in almost all the projects that I have worked in as part of the software "services" industry. With just one or two notable exceptions, Managers could always be counted while deriving the RTF.
I quickly did a mental exercise to find out the TF for the projects that I have worked in. It dawned on me that not only was the TF very small, there was a Reverse Truck Factor (RTF) in play. I define RTF as the number of people who need to be hit by a truck (or several, just to be sure) for the project to stabilise and have anywhere near a decent chance of achieving what it is supposed to. The lower the RTF, the better are the chances of a project to succeed.
Unfortunately for me, the RTF has been consistently high in almost all the projects that I have worked in as part of the software "services" industry. With just one or two notable exceptions, Managers could always be counted while deriving the RTF.
Saturday, October 01, 2005
Integration Theory of Learning Music (aka what Music Lessons did for me)
I attended my first ever Piano recital at the Alliance Francaise de Bangalore sometime early in May 2003. On that warm Bangalore evening the young and talented Ms. Berenice de Gama Rose gave her farewell recital to a small but appreciative audience. Ms. Rose was leaving her position as a teacher of (Piano) Music at the Bangalore School of music to take up her Masters in Business Administration elsewhere. The music that filled my ears on that day evoked several emotions and started a train of thought in my mind. Later I attempted to categorize what I felt and thought that day. Here is a summary.
A few weeks later I started Piano lessons in Bangalore and later when my work took me to Dallas found an exceptionally good teacher here (more on this in a later post). After more than a year of taking lessons and after a (very very simple, bordering on trivial) recital of my own, I reconsidered that evening in Bangalore. In the light of my own lessons, I now have a different look at things.
All music lessons start (or are supposed to) with the basics. As the student progresses on this track, the teacher introduces a fairly simple stand alone piece to work on. When I saw my first such (an arrangement of Placide Clappeau's 'O Holy Night') I could instantly *see* that I could do it - with a little bit of effort. This was a perception different from a *logical understanding* - i.e., perceiving that I could do a task as opposed to understanding that anyone can do it by putting in suitable effort. The focus is on the doing - rather than on the quantum of effort. This is made possible because the quantum of effort involved is *small*.
My recital came and went in December 2004, and early this year, I got my next advanced piece (an Arrangement one of J.S. Bach's Musettes). Here was a piece which was complex than my Christmas piece and yet I was confident that I could do it - in another month or so, after due practice. What is important is that if I had been told that I could do it when I started the lessons or earlier, I would have balked at it and possibly have had thoughts listed in observations #1 through #4.
A similar incident occurred earlier this month. I picked up 4A though 5B of Carl Fischer's 'Music Pathways - Repertoire' series of books. My teacher kindly agreed to play examples from each book so that I could hear first hand what they would sound like when played correctly. Boy! The pieces were beautiful. And I was astounded to realize that these were within my grasp - given adequate work of course.
This is the beauty of taking lessons, reading simple pieces of music and practicing with simple goals in mind. What lessons did for me was to help focus on the task at hand and prevent my mind from being overwhelmed by looking only at the finest, the masterpieces. And this realization I call my 'Integration theory of Learning Music'.
The theory states that if Joe aspiring-Pianist (or Manoj aspiring-Pianist, if you will) wants to be able to delight himself by playing Bach one day, he needs to start with the basics and take small steps at a time. And if Joe a-P does not have the will to stick to a schedule on his own, he should find a good teacher and pay him/her to force Joe to take those steps. For when you start at level 0 and are shown level 1, you know you can do it. And at the end of level 1, level 2 is only a few hours/days/weeks or practice away. And so on. The tiny dx(Lesson/Step/Quantum) when integrated over time will yield the quantity that makes playing Bach, Mozart and Beethoven possible.
- Awe. The skill with which the Performer played that beautiful Piano was outstanding - and it seemed all the more so to a worse-than-novice in music like me.
- A feeling that can be best described as "impossibility". While I *logically* understood that what I had witnessed was the natural consequence of the six plus hours(!) of practice put in by the performer each day for several years, to my mind it would always be impossible for *me* to ever do anything even remotely similar.
- Depression. Without much more explanation, let me just say that this usually follows points #1 and #2.
- "Giving up". After I recovered from #3, I gave up the whole line of thought and crawled back to my Dilbertain existence.
A few weeks later I started Piano lessons in Bangalore and later when my work took me to Dallas found an exceptionally good teacher here (more on this in a later post). After more than a year of taking lessons and after a (very very simple, bordering on trivial) recital of my own, I reconsidered that evening in Bangalore. In the light of my own lessons, I now have a different look at things.
All music lessons start (or are supposed to) with the basics. As the student progresses on this track, the teacher introduces a fairly simple stand alone piece to work on. When I saw my first such (an arrangement of Placide Clappeau's 'O Holy Night') I could instantly *see* that I could do it - with a little bit of effort. This was a perception different from a *logical understanding* - i.e., perceiving that I could do a task as opposed to understanding that anyone can do it by putting in suitable effort. The focus is on the doing - rather than on the quantum of effort. This is made possible because the quantum of effort involved is *small*.
My recital came and went in December 2004, and early this year, I got my next advanced piece (an Arrangement one of J.S. Bach's Musettes). Here was a piece which was complex than my Christmas piece and yet I was confident that I could do it - in another month or so, after due practice. What is important is that if I had been told that I could do it when I started the lessons or earlier, I would have balked at it and possibly have had thoughts listed in observations #1 through #4.
A similar incident occurred earlier this month. I picked up 4A though 5B of Carl Fischer's 'Music Pathways - Repertoire' series of books. My teacher kindly agreed to play examples from each book so that I could hear first hand what they would sound like when played correctly. Boy! The pieces were beautiful. And I was astounded to realize that these were within my grasp - given adequate work of course.
This is the beauty of taking lessons, reading simple pieces of music and practicing with simple goals in mind. What lessons did for me was to help focus on the task at hand and prevent my mind from being overwhelmed by looking only at the finest, the masterpieces. And this realization I call my 'Integration theory of Learning Music'.
The theory states that if Joe aspiring-Pianist (or Manoj aspiring-Pianist, if you will) wants to be able to delight himself by playing Bach one day, he needs to start with the basics and take small steps at a time. And if Joe a-P does not have the will to stick to a schedule on his own, he should find a good teacher and pay him/her to force Joe to take those steps. For when you start at level 0 and are shown level 1, you know you can do it. And at the end of level 1, level 2 is only a few hours/days/weeks or practice away. And so on. The tiny dx(Lesson/Step/Quantum) when integrated over time will yield the quantity that makes playing Bach, Mozart and Beethoven possible.
Monday, September 19, 2005
Where the Grid Bugs bite
The first ever role playing game I played on a computer was Diablo. Lacking a computer of my own, I would visit one of my friends and tactlessly invite myself to stay over at his house over the weekend. My friend (Bless his heart!) would let me play Diablo on his computer all night long to my heart's content. I never finished the game; as much fun as it was, I was not quite drawn to finish it.
Only a few months later it became next to impossible to play the more modern games on his computer. It appeared to me that every new game was designed to raise the bar on the memory and processing capacity requirements needed to play it while the basic game play and story lines remained the same (there are of course notable exceptions - the Ultima series of games immediately come to mind) I finally gave up on playing new games - Sierra's Arcanum was about the last game my once top-of-the-shelf laptop could handle.
And then Ravi drew my attention to something called Nethack. In this age of zillion-polygon graphics, Nethack's "ASCII art" screen was a highly contrasting oddity. I downloaded the game (all 2.0 MB of it!!) but never quite got around to playing it. A bad mistake. Almost as bad as picking up a cockatrice corpse with your bare hands. (If you haven't played Nethack don't worry - you will understand the last sentance when you do!)
Several months later, wailing in the in the confines of my Dilbertian prison (let us not go there), I chanced upon Nethack again. I realised that Eric Raymond was speaking from experience and wisdom accrued over years when he said opening the Nethack guidebook "Recently, you have begun to find yourself unfulfilled and distant in your daily occupation. Strange dreams of prospecting, stealing, crusading, and combat have haunted you in your sleep for many months, but you aren't sure of the reason".
In the wink of an eye I was transformed to Castcom, the lawful human Samurai, devoted servant of the mighty Sun Goddess Amaterasu Omikami, beginner in the ways of the Katana, on his quest to find the mighty Amulet of Yendor. Every day, every single trip that I made into the dungeons was a new adventure. And who cared if the Gnomes killed me the first few times? Or if I triggered a land mine and died? What was death by stoning indeed to a Samurai bound to Bushido? (For those uninitiated to the game, there is no "save game" option in Nethack. If you die, you die. You have to start all over from the beginning.) I could now see exactly why Nethack is considered THE best game ever by gamers and hackers.
I had heard of players taking years to complete the game - to "Ascend" in game parlance - only to go back in again, donning another costume, playing another character. I wondered if I would ever make it, and if so, how many attempts it would take me. Out of curiosity, after a dozen or more attempts, I came up with a way to count.
My character would be named Castcom - with a suffix indicating the number of times I had tried (and died) so far. As I remember Castcom1 died a very unheroic death. Castcoms 2 through 30 were "experimentals" as I learned more about the game and came to better understand the tricks of prospecting in dungeons. Castcoms 31 onward were serious adventurers - though I never stopped learning more about the game. While the key aspects remain the same, the dungeon levels are auto generated, as are the creatures that populate them. Thus there is little chance of any two game layouts - or experiences - being identical.
At the time of writing this I have two games going on. Castcom the 68 at home, and Castcom the 66 at, um, in Dilbert land. If you were wondering what happened to #67 - well, he bent to feel something on the ground while blind - only to realise that 1) the item on the ground was a cockatrice corpse and 2) he was not wearing any gloves. He would remember the lesson for the rest of his life. All 2 milliseconds of it. But I digress.
I could go on and on about the game for several pages - to the peril of Castcom68. The noble Samurai and his valiant dog just barely escaped being kicked to death by a mad warhorse and an oppurtunistic Gnome king a few minutes ago. A prayer to the Sun Goddes has just restored his health - small comfort considering the vicious creatures in the next room that he has managed to flee for a few minutes but must now confront before venturing any further. Now to open the door to the next room ...
Update on 08 March 2006: Castcom215 finally ascended - albeit thanks to liberal usage of spoilers. Rather shameful, considering that Castcom215-san was a Samurai and gave bushido scarce consideration when he used all those tips available on the internet. Will his kami ever find peace? Only time will tell.
Only a few months later it became next to impossible to play the more modern games on his computer. It appeared to me that every new game was designed to raise the bar on the memory and processing capacity requirements needed to play it while the basic game play and story lines remained the same (there are of course notable exceptions - the Ultima series of games immediately come to mind) I finally gave up on playing new games - Sierra's Arcanum was about the last game my once top-of-the-shelf laptop could handle.
And then Ravi drew my attention to something called Nethack. In this age of zillion-polygon graphics, Nethack's "ASCII art" screen was a highly contrasting oddity. I downloaded the game (all 2.0 MB of it!!) but never quite got around to playing it. A bad mistake. Almost as bad as picking up a cockatrice corpse with your bare hands. (If you haven't played Nethack don't worry - you will understand the last sentance when you do!)
Several months later, wailing in the in the confines of my Dilbertian prison (let us not go there), I chanced upon Nethack again. I realised that Eric Raymond was speaking from experience and wisdom accrued over years when he said opening the Nethack guidebook "Recently, you have begun to find yourself unfulfilled and distant in your daily occupation. Strange dreams of prospecting, stealing, crusading, and combat have haunted you in your sleep for many months, but you aren't sure of the reason".
In the wink of an eye I was transformed to Castcom, the lawful human Samurai, devoted servant of the mighty Sun Goddess Amaterasu Omikami, beginner in the ways of the Katana, on his quest to find the mighty Amulet of Yendor. Every day, every single trip that I made into the dungeons was a new adventure. And who cared if the Gnomes killed me the first few times? Or if I triggered a land mine and died? What was death by stoning indeed to a Samurai bound to Bushido? (For those uninitiated to the game, there is no "save game" option in Nethack. If you die, you die. You have to start all over from the beginning.) I could now see exactly why Nethack is considered THE best game ever by gamers and hackers.
I had heard of players taking years to complete the game - to "Ascend" in game parlance - only to go back in again, donning another costume, playing another character. I wondered if I would ever make it, and if so, how many attempts it would take me. Out of curiosity, after a dozen or more attempts, I came up with a way to count.
My character would be named Castcom - with a suffix indicating the number of times I had tried (and died) so far. As I remember Castcom1 died a very unheroic death. Castcoms 2 through 30 were "experimentals" as I learned more about the game and came to better understand the tricks of prospecting in dungeons. Castcoms 31 onward were serious adventurers - though I never stopped learning more about the game. While the key aspects remain the same, the dungeon levels are auto generated, as are the creatures that populate them. Thus there is little chance of any two game layouts - or experiences - being identical.
At the time of writing this I have two games going on. Castcom the 68 at home, and Castcom the 66 at, um, in Dilbert land. If you were wondering what happened to #67 - well, he bent to feel something on the ground while blind - only to realise that 1) the item on the ground was a cockatrice corpse and 2) he was not wearing any gloves. He would remember the lesson for the rest of his life. All 2 milliseconds of it. But I digress.
I could go on and on about the game for several pages - to the peril of Castcom68. The noble Samurai and his valiant dog just barely escaped being kicked to death by a mad warhorse and an oppurtunistic Gnome king a few minutes ago. A prayer to the Sun Goddes has just restored his health - small comfort considering the vicious creatures in the next room that he has managed to flee for a few minutes but must now confront before venturing any further. Now to open the door to the next room
Update on 08 March 2006: Castcom215 finally ascended - albeit thanks to liberal usage of spoilers. Rather shameful, considering that Castcom215-san was a Samurai and gave bushido
Subscribe to:
Posts (Atom)
Posts
