Today I begin decomposing our system into separate components. I felt that I will have to do it sometime, but I was reluctant to do it because I never did it before.
What I learned thinking about decomposition is this:
Never postpone things you have to do. Always remember - You have to do what you have to do.
Castle.Windsor is a IoC container (Inversion of Control), which helps build system from small components. I found it to be very simple, and easy to use.
Now, as I have moved all generic controls and helper stuff from UI to Core, and concrete stuff from Core to UI, ia have 50 tests not running.
Probably, most of them are ActiveRecord.InitializationExceptions, but anyway, unit tests again help me make good pace without worrying of damaging my system
The best part of unit testing is that it gives confidence that the code is yet again maintanable!
Sadly, but my code is falling apart just at the moment. The parts that worked before are not working for some mysterious reasons. And the worst thing is that i discover those bugs by sheer accident!
I mean - there's no testers in our team. And there's no way the bugs can be found when they bring up, except unit testing.
When i write a unit test, i feel a very strong feeling, that my code is secured from future bugs, which pop out unnoticably. It gives me confidence, and allows me to further refactor and expand the system
A few weeks ago i found a very peculiar Undo/Redo solution here .
The way it was written surprised me. It even took me 2 or 3 minutes to get the idea how the code works :).
All the magic is hidden inside a UndoRedo class. The idea is that instead of creating your variables directly, you wrap them with UndoRedo class like this:
readonly UndoRedo name = new UndoRedo(); public string Name { get { return name.Value; } set { name.Value = value; } }
This solution is very interesting, but, from my perspective, it asks too much from the programmer. To use this UndoRedo mechanism you would require to rewrite all your classes, which needs capabality of UndoRedo.
What is more, you could not make TextBox undoable, without overriding the TextBox class. And of course we know, that some classes in M$ field are for some mysterious reason sealed, so you can not inherit.
But overall, the solution is interesting, and it does work :)
Finally I start to embrace test-driven-development.
Whenether I fix a non-trivial defect, I first write a unit test to catch that error, and then fix the bug.
Even now, for example, I have to create a new command which creates a new contract for each student. Instead of writing immediatelly whole working code, I make a sketch of what my working code might look like, then I write unit test to test that my sketch code does not work.
Finally, (in a few minutes or hours) i implement the feature and the tests pass. Then I run all my tests (64 right now), and commit the code to svn.
EuroPython 2007 just finished. It was in Vilnius, Reval Hotel Lietuva.
Some comments about talks i attended: Seamless object persistence with ZODB - a talk by Mr. THEUNE, Christian, who presented an object oriented Zope database. It was an interesting to see it in action. I still wonder the performance of object databases. This aspect was not touched.
The point that Storm was built because they could not fix SQLAlchemy to work nice for them is not justified. In the end, the bug which was bothering Gustavo was actually fixed
So basically it means that Storm has no killer features against other Py ORM mappers
Storm reminds me of a .NET Entity Objects Framework Neo.
There was a very interesting talk about KSS, Ajax development with style.
They showed a simple wiki page which worked with no page reload at all, and all ajax stuff was done using KSS, not a single line of direct java script.
I could not grasp to the roots, but basically it's something in beetween about converting any code to a python , and to converting python to any other code.
For example, you write simple python code, and then translate it into C, which results in performance gains. The difference between PyPy and CPython is that PyPy is a much more sophisticated project, capable of optimizing code and jitting the resulting code.
Another example is you write a java script code (or schema code, or whatever), and then convert this code to python and then convert it to CLR bytecode and execute it in CLR environment.
The whole PyPy project is more a scientific research, than a concrete product.
I'm switching this blog language to English. It seems that blogging on software programming stuff is not that much popular. And I need to interact with the rest of 6 zillion population around the world.
So everybody please sharpen your teehts and start posting comments in English ;)
BTW, blog name will be changed too. Probably to "Code Ruins".
Though we do .Net development, i doubt programming skills in pythong are that much different than .Net skills.
The conference is from 9th July to 11th July. Following three days will be a sprint run (brainstorming code for one or another Python community project).
