Experiences
Taking a look back, before GSoC14 began, I had confined myself to writing small utility scripts. It was something that would be used by me and me alone. I could change the API's as I wished. API Design? What the hell is that!? How things have changed in a matter of three months. I have learnt so much, too much to list in a single blog post, that I will just skim over my GSoC 2014 experiences. You can read my other blog posts tagged <gsoc> to take a look at what I actually did in the 3 months.
There is more than one way to do it, but there is only one CORRECT way
Many times in the past, I'd often be happy with the first solution that works. I would move on after I had a solution. During GSoC, I have learnt through experience that the while the first solution that clicks, could work, there is usually another(and better) way of solving the same problem. I had this experience in 3 of the 4 of my subprojects - namely : non-buildbot test framework, linenumbering(and a second linenumbering approach) and Checkers. I am really proud to say that I have submitted atleast 2 different approaches for each of them, and we have had the luxury to pick and choose solutions.
Writing code for a (standard) library package
As you are hopefully aware, IDLE is a Python standard library package. This has many implications, an important one being, changing existing code is a very difficult decision to make - you don't know how it is going to break someone else's setup. You also know it WILL break something. You have to work with what you have. This requires a lot of skill and an even greater understanding the codebase that you are working on. I feel I have picked up some of it - I feel I can now jump into any codebase and fix a bug or add a feature without creating some new 10 bugs in the process. GSoC has given me that confidence.
That test driven development is great
It was through GSoC that I learnt about Test Driven Development(TDD) and testing. I have used this methodology while working on the Linenumbering and 3rd party code checker subprojects. I feel it is a great philosophy. It forces you to think of the behavior, define that behavior, the desired API etc, all this before you write a single line of code. It has and will prevent me from jumping straight into coding - a recipe for disaster.
Successes
I feel I have met the expectation that I set before I started out. Two subprojects - non-buildbot test framework and unittest framework have been completed and committed to the python source tree. The third subproject - linenumbering is on the verge of being committed.Roadblocks
The fourth subproject, though fully functional, I have to admit is quite far from being a part of the IDLE source. I feel it is still some rounds of code review and improvements away from being "complete". This subproject is lagging behind other's in terms of completeness.
Looking forward...
With a heavy heart, and loads of memories,
Saimadhav Heblikar
No comments:
Post a Comment