interesting or uninteresting?

Blogging from Neuchatel, Switzerland doesn't feel any different. Hahahahaaaa, I mean should it?


Being in this new job does bring about certain challenges which I never thought would bother me. There are mostly about working with new people, being conscious about team and people dynamics and other stuff mostly concerning people matters. This brings me to the topic of what makes interesting work, and work interesting to me.

I have no doubt that technical challenges is the main factor for making any work interesting for me. But I also know for a fact that I'm also very much of a people person too. Let me rephrase: I am someone who is always concerned about how best to put forth my comments and ideas so that I'm understood and not misunderstood, and simultaneously being as sensitive as I can to how others are feeling about me, the situation and such. Such people-aspects of work, and life of course, has been an on-going effort and thus sometimes is relegated to the sub-conscious.

Thus, it is interesting to me that I'm putting in more effort to take a conscious note of the people dynamics around me than being worried about work challenges, or the lack of it.


Logically, blogging in an entirely different location should not matter that much. But again, it does feel good to being able to look out of the window and see a snow covered field just outside. A difference nonetheless.

a milestone

Things come, things go. Everything.
Partings. Reunions. Reflections.


It's been 4 years since I left school. I'm now leaving my first job for another. I've always talked about changing job due to the high stress level, lowly pay, lack of appreciation etc etc etc... the list goes on. But there must be something more to the complaints I have about the job that kept me going and going for these 4 years.

I don't want to go around pretending that everything is rosy and nice. If there'll be something that I felt should have been better, I'd like to make it known and heard. It also helps to relieve the bottled up stress. Friends who know me will understand that; I don't work well under stress.

Several have asked me if I have any plans or targets for the coming years. Frankly, I haven't been thinking too much about it. Given how I am, I know I will make the best of each and every situation to ensure that it helps me grow in the general direction that I wanted. And I think that is enough to see me through for at least a few more months.

think different

leadership

There was this discussion at work about what makes a good leader and what is good leadership recently. My first thought about this was this is an every-now-and-then discussion topic that surfaces, hundreds if not thousands of books published about it and uncountable articles written. I posted something similar like this in a blog shared among colleagues; this is improved upon the original.

If you ask me for my 2 cents worth, this is what I feel a great leader should be:

He may not be your friend in good times but is your best friend in bad times.
He is whom you will seek advice from when lost; and whom you will follow when instructed, and whom will inspire you to go further than instructed.
A great leader is not really your friend, but can be your friend, and is more than your friend: He is your leader.

What do you think?

never mind, as long as it works

I'm sure many of us would have encountered scenarios resulting in such a statement as above. A colleague was trying to figure out why his nested SQL select didn't work. Frankly, I'm also as clueless as he is. I suggested using table joins instead. It worked. Doesn't matter why it didn't work with nested select, as long as we've gotten something that worked. It didn't matter because the SQL statement is only for data analysis.

A more senior colleague was commenting that designers and developers tend to choose the easier way out when implementing new functionalities for the website. The mindset is as long as it eventually gets the new functionality working, who cares if one have to re-create a similar UI feature all over again in different pages. He is trying to have such a mindset changed, but admits that it's not going to be easy; I concur.


Actually, it doesn't matter in which context the "never mind, as long as it works" mindset appears in, it is a dangerous mindset. Dangerous to maintaining the quality of work one delivers. And it is something everyone is guilty of, myself inclusive.

Of course there are scenarios like the former, where lapsing into such laziness would not cause any further "harm". But situations like that latter involves a much more complex problem domain. In such cases, if the improvement towards the better method is certainly desireable and to be pursued, the question to ask is how much would one tolerate more bugs and design mistakes than if one were to stick to the current one-for-one implementation technique?

to upgrade?

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.

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.

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.

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();

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.

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.

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.

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.

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.

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.

elegant software design

An impression others often have of my insistence for. Upon further thought when this term was used on me again recently, I realised the usage of the word "elegant" is erroneous.

"Elegant" is used to describe an idea, plan or solution that is clever but simple, and therefore attractive (http://dictionary.cambridge.org/define.asp?key=25143&dict=CALD). Elegantly designed things takes effort. But the magnitude of elegance in the end-product is subjective. Different people hold differring views of what constitutes elegance and how much a particular factor affects elegance. Almost just as beauty is in the eye of the beholder.

However, software design is less of an art but more of a science. There are design patterns to help solve common problems; even if one is ignorant of patterns, an effective solution usually mimics an existing pattern. There are also general rules one should follow; the most common but most difficult to adhere to is the simplicity rule. (I'll write on SIMPLE software design in a separate posting.)

Given that there are rules which should be followed, this makes a good piece of software design to be described as proper more than elegant, which is the point that I want to get at. It is proper design that makes for easy usage, debugging and maintenance. In fact, this applies not just to software, just as a properly designed car makes for ease of handling, low maintenance and efficient motor transmission.

The catch is: it takes a certain amount of understanding to appreciate the proper-ness of a design in any domain-area. Only when proper-ness is attained can one perhaps debate over its elegance, beauty and all other things subjective.

a webservice chore

Creating a webservice has become a chore. In fact, it has never been exciting. There are just too many things to do and too many things that can go wrong. Starting with the WSDL, defining the service poses just too many posibility of making errors. Namespaces can go wrong; the WSDL can be WS-* non-compliant; even with WS-* compliance, Java can possibly generate difficult to use endpoints, or .NET not generating the expected proxy classes. This is certainly not recommended for the non-technically inclined. You create either a mess or an art, a painful piece of art.

Having adopted the development process of WSDL-to-Java, I start to wonder if the opposite way might have been easier. Just define the endpoints in my Java codes, and let the tool generate the (supposedly) WS-* compliant WSDL. Certainly I won't have as much control over the WSDL and XSD generated, but doing it this way will help to negate the need for designers to know the technical details of WSDL and XSD. Note that not all designers are technically inclined or trained, which I've always wonder why are they not so.

funny day

Funny day this is. Suddenly thought about how the world came about from millions of years ago to this day as I make my way from the train station to the office. Imagined that the ground beneath me is just plain dirt, not concrete. Or could just be just the ocean as land has not been formed. Do God really exist? Then I snapped myself out of it... back to reality.

Work at office is bordering on insanity. People questioning whether a public static final constant is initialised. The server not started, and the status right in my face and I don't see it. Recalling entire application configuration from memory. Generating those stubs when they refused to only yesterday, and I still don't know why it couldn't before. And to round up the day, evergreen war stories from the frontlines of user interaction.