My little framework need a upgrade, to Spring perhaps, so that it can be more easily configurable and flexible. But as always, time is not on my side to upgrade it in time to hand in some work. Shall I just make do with what I have now? I think I'll just do that.
Upgrading yourself constantly is necessary to keep your mind fresh and challenged, so that it does not forget the methods with which it learns new things. And frankly, I always get a boost of motivation and confidence during an upgrade. Opportunities to upgrade oneself doesn't just present itself at your feet. One have to seek them out, grab them and then make sure it is made full use of. The headache comes when more than one such opportunities have come and there is only room for one.
21 October 2005
10 October 2005
pointers
A very powerful feature in C and C++. I have sometimes missed the days which I have hours and hours of headache and fun figuring out how to use or read those *******... hahahaaa... *smiles*
But pointers can be misused. Pointing to memory addresses outside of your array can allow your program to access data that you did not initialise. If you know the address of sensitive data, who knows what you can do to them.
Pointing to data outside of your jurisdiction is a no-no. Similarly, pointing fingers at someone else can be hurting as well. No prizes for guessing correctly at which end of the pointing I was at, but it just reminds me of this:
One have to trust others to do the work one is unable to do. This trust is tested when something fails. If the responsibility is unison, the trust is strengthened. Thus with trust, the work fulfilled.
But pointers can be misused. Pointing to memory addresses outside of your array can allow your program to access data that you did not initialise. If you know the address of sensitive data, who knows what you can do to them.
Pointing to data outside of your jurisdiction is a no-no. Similarly, pointing fingers at someone else can be hurting as well. No prizes for guessing correctly at which end of the pointing I was at, but it just reminds me of this:
One have to trust others to do the work one is unable to do. This trust is tested when something fails. If the responsibility is unison, the trust is strengthened. Thus with trust, the work fulfilled.
2 October 2005
e=mc^2
Einstein. An article in today's papers reminded me of the strong relationship between believing in simpler methods to visualising a truth.
E=mc^2. The formula for Kinetic Energy is KE=0.5m(v^2). I don't know which came first, but I suspect the KE's is earlier. If indeed so, I'm just pleasantly surprised by the similarity between the two formulae. Einstein did not prove that the mc^2 formula is indeed true when published, but merely derived the formula from a parallel observed from everyday lives. This is the make-up of a ingenious mind.
Unified Theory. I religiously believe that Einstein is right, when he attempts (alas, in vain) for a simpler but unified one theory for everything, including mass, time and space. His theory for general relativity has put us one big step forward in that direction. His belief is that this theory has to be simpler than anything that is present, but not too simple. An paradox? Not quite. The achievemet of the former requires of the mind to see past the obvious and derive simplicity from it while the latter requires the mind to merely accept the obvious even if there is anything to be derived from it.
I may seem not be making any sense here, but it is clear in my mind I'm not babbling nonsense.
E=mc^2. The formula for Kinetic Energy is KE=0.5m(v^2). I don't know which came first, but I suspect the KE's is earlier. If indeed so, I'm just pleasantly surprised by the similarity between the two formulae. Einstein did not prove that the mc^2 formula is indeed true when published, but merely derived the formula from a parallel observed from everyday lives. This is the make-up of a ingenious mind.
Unified Theory. I religiously believe that Einstein is right, when he attempts (alas, in vain) for a simpler but unified one theory for everything, including mass, time and space. His theory for general relativity has put us one big step forward in that direction. His belief is that this theory has to be simpler than anything that is present, but not too simple. An paradox? Not quite. The achievemet of the former requires of the mind to see past the obvious and derive simplicity from it while the latter requires the mind to merely accept the obvious even if there is anything to be derived from it.
I may seem not be making any sense here, but it is clear in my mind I'm not babbling nonsense.
log_category=blog (part 2)
The software is about to go-live, thus it's about time to close the logger's handler. The most painful part of the problem has been solved in part 1. Part 2 just requires some time to fix.
Part 2 requires the logging to be "cleaned" up so that the appropriate logs get channelled to the correct log files. There is still some confusion to the logging mechanism, but at least the logs appear, just perhaps to all the log files.
logHandler.close();
Part 2 requires the logging to be "cleaned" up so that the appropriate logs get channelled to the correct log files. There is still some confusion to the logging mechanism, but at least the logs appear, just perhaps to all the log files.
logHandler.close();
24 September 2005
tragic and marvellous; music and software (part 2)
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.
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.
Subscribe to:
Posts (Atom)
