Woke up early for a last minute preparation for the SCBCD exam scheduled at 11am. Attempted the mock exam questions found in the study book. Realised that I'll fail the exam...
What a way to begin the day. It wasn't so difficult to decide on the route to take, though others may think it illogical; I'll give the exam a pass. After 3 days of trying to cram as much information as I can based on the syllabus, a sad but true realisation set in: If I really study enough and passes the exam, it means that my grey cells are mutating to become silicon chips.
Software design requires more lateral thinking than software development. Spatial visualisation helps too. Why? Because one needs to be open to alterative ideas to solving unique design problems, infusing the design with flexibility to handle currently unknown features. There are design patterns to follow, and there's nothing very rocket-science about it; but it's a fallacy to think that one can just look into a patterns dictionary and be able to find and correctly use a pattern for any particular design problem.
Good software design is akin to a well composed and orchestrated piece of music. Every components performs its intended role, every layer handling the tasks assigned well. As much as we won't expect the violin to play the part of the tuba, we should also be clear on where the responsibilities of different software parts start and end. A well-designed software should have as few grey-areas as possible at these boundaries.
These are unspoken rules that govern software design. Every software is different, just as every symphony is unique. It is then expected that each software presents itself with a different set of challenges aka problems. Although the problem-domain may be similar (harmony between different instrumental sections -to- integration between components) and the solution applied seems like a template, the resulting outcome is likely starkly different. If one can see the differences in the similar problems and solutions, the applied solution will likely result in a more positive outcome.
Mahler followed that evening. Tragic was the symphony. Enlightening.
Morning had been tragic. Evening became light. Thought-provoking.
Silicon is not grey. Grey is both. Stimulated.
Sparkled.
Sparks.
24 September 2005
21 September 2005
life without the net
Moving house is not mean feat, I'm just glad to have very capable parents.
Since moving into my new place almost 2 weeks, I'm without Internet access, cable TV and fix-telephone line. It won't be at least another 5 more days before I get any of those luxuries.
But somehow, I don't miss not having my broadband access. It negates the addiction to have to check my email every night before I sleep, and once every 4 hours during weekends.
Don't ask me where I'm posting from now... But I'll confess to something: in the midst of not missing Internet at home, I want my cable TV.
Since moving into my new place almost 2 weeks, I'm without Internet access, cable TV and fix-telephone line. It won't be at least another 5 more days before I get any of those luxuries.
But somehow, I don't miss not having my broadband access. It negates the addiction to have to check my email every night before I sleep, and once every 4 hours during weekends.
Don't ask me where I'm posting from now... But I'll confess to something: in the midst of not missing Internet at home, I want my cable TV.
a study of classical music and software (part 1)
A concert last week started me thinking (again) about the relationship between what makes a good piece of music and why am I such a mule for good software.
I have always held classical music composers in high regard, simply for their ingenuity and for their gift to the human race. I've always wondered about the "method" which I appreciate their music. I often marvelled at how the composer parallel-thread (they make multi-threading seemed simple) the sounds of so many instruments and have them work together so beautifully. And of course, harmony is not really rocket-science; there are known "methods" to harmonise different notes to produce different feel, and usage different keys to convey a different mood. In fact, one can learn all these from any modern music lessons. But it is the touch of genius that makes a piece of music special, different from others, magical. That said, more often than not, I listen to the composer as opposed to the performing artiste.
It seems to come naturally, maybe because of the lack of enough proper musical training?; I am able to hear differences in composition and orchestration style ignoring all the technicalities of harmonies etc. I can quite accurate identify Beethoven, Brahms, Tchaikovsky, Bach and Vivaldi works that are unknown to me. I'm sure I'm not alone as this is likely to come with time and experience. What attracts my attention is my ability to identify repeated patterns, and then such similar patterns in different contexts, from which I analyse in the subconscious and draw parallels.
What has all these got to do with software? To be continued...
PS. Many times I ask myself why I like to draw such difficult parallels. I have never gotten an answer to that question.
I have always held classical music composers in high regard, simply for their ingenuity and for their gift to the human race. I've always wondered about the "method" which I appreciate their music. I often marvelled at how the composer parallel-thread (they make multi-threading seemed simple) the sounds of so many instruments and have them work together so beautifully. And of course, harmony is not really rocket-science; there are known "methods" to harmonise different notes to produce different feel, and usage different keys to convey a different mood. In fact, one can learn all these from any modern music lessons. But it is the touch of genius that makes a piece of music special, different from others, magical. That said, more often than not, I listen to the composer as opposed to the performing artiste.
It seems to come naturally, maybe because of the lack of enough proper musical training?; I am able to hear differences in composition and orchestration style ignoring all the technicalities of harmonies etc. I can quite accurate identify Beethoven, Brahms, Tchaikovsky, Bach and Vivaldi works that are unknown to me. I'm sure I'm not alone as this is likely to come with time and experience. What attracts my attention is my ability to identify repeated patterns, and then such similar patterns in different contexts, from which I analyse in the subconscious and draw parallels.
What has all these got to do with software? To be continued...
PS. Many times I ask myself why I like to draw such difficult parallels. I have never gotten an answer to that question.
13 September 2005
being switched
To ensure that a software you help to architecture does not start to disintegrate upon entering a stage of testing is a massive effort. Maybe it's just me, my phobia, my paranoia. But being in the knowledge of inefficencies and insufficencies of the framework, and worse constantly finding more tells me that my fears are real. One comforting fact is that the frequency of discovering such items is decreasing.
As such items are getting more difficult to find (which is good), that basically implies that one have lesser to do (predicted). So it's natural to be reassigned to something else, say development of business components. It's a welcome change, a switch in the thinking process. But I must stress that it's a painful switch. Business component development requires a more top-down thinking process, making sure that all the if-else rules are done in the correct order and before any action is taken. Coming to the action, data must be retrieved or updated in the correct order (and remember to handle exceptions so that they can be rolled back as well). In fact, I don't miss business component development.
Framework component development is more focussed at a single task, and it have to do it well. It should not care whichever order it is placed in the entire process. It only needs a very clear and concise interface, preferably the same interface as other similar components, and I stress again, does its work well, very well. Designing for a clear and concise interface shared between different components is not an easy task. Expect constant changes, sometimes a complete overhaul. Maybe that's a sign of a poor design phase, but there's no alternatives, if it requires to be changed or upgraded, it just have to be done. Each component then have to be ensured that it can stand on its own 2 feet, and handle every possible scenario that can pass through it, and not fail unexpectedly. Almost every possible error have to be handled properly.
As such items are getting more difficult to find (which is good), that basically implies that one have lesser to do (predicted). So it's natural to be reassigned to something else, say development of business components. It's a welcome change, a switch in the thinking process. But I must stress that it's a painful switch. Business component development requires a more top-down thinking process, making sure that all the if-else rules are done in the correct order and before any action is taken. Coming to the action, data must be retrieved or updated in the correct order (and remember to handle exceptions so that they can be rolled back as well). In fact, I don't miss business component development.
Framework component development is more focussed at a single task, and it have to do it well. It should not care whichever order it is placed in the entire process. It only needs a very clear and concise interface, preferably the same interface as other similar components, and I stress again, does its work well, very well. Designing for a clear and concise interface shared between different components is not an easy task. Expect constant changes, sometimes a complete overhaul. Maybe that's a sign of a poor design phase, but there's no alternatives, if it requires to be changed or upgraded, it just have to be done. Each component then have to be ensured that it can stand on its own 2 feet, and handle every possible scenario that can pass through it, and not fail unexpectedly. Almost every possible error have to be handled properly.
7 September 2005
a webservice frustration
I had thought that ensuring inter-operability between .NET and Java, and compliant to WS-I is more than headache enough. Now I have got to ensure that the WSDL is readable by LoadRunner too. It is to note that every software implementation that parses WSDL has it's little habits and interpretations of the WSDL definitions and WS-I standards. Admittedly, there's still a long long way to go before all will agree to a single interpretation... ... *sigh*
Hence, I'll warn anyone reading again, webservices development is NOT for the non-technically-inclined, and certainly not for people who wants to keep there hands clean. Soap is certainly not provided.
Hence, I'll warn anyone reading again, webservices development is NOT for the non-technically-inclined, and certainly not for people who wants to keep there hands clean. Soap is certainly not provided.
2 September 2005
log_category=blog (part 1)
It always feel good to make any in-roads for a long-standing problem. Satisfaction derived from such breakthroughs are often greater than completely solving the problem itself.
The path to solving any problem is always painful, worse when there's a time constraint. I'm never quite as good in solving inter-personal problems than software related ones. Maybe this is due to my overly logical grey-matter.
I can really feel my grey-cells dying up there after all the hyper-threading performed today. All atrributed to java.util.logging, spring and ServletContextListener. Let part 2 continue another day for a mandatory rest period.
The path to solving any problem is always painful, worse when there's a time constraint. I'm never quite as good in solving inter-personal problems than software related ones. Maybe this is due to my overly logical grey-matter.
I can really feel my grey-cells dying up there after all the hyper-threading performed today. All atrributed to java.util.logging, spring and ServletContextListener. Let part 2 continue another day for a mandatory rest period.
Subscribe to:
Posts (Atom)
