[march 31, 2010]: Elsewhere, Ms. Mirza, while dealing with another motley crew, delivers a response that will look familiar to students of computer science working with threads on an operating systems assignment -- it's what happens when you let two threads write to the same chunk of memory in abandon: The date is the 15th for the reception of April. April, come she may, surely.
Tuesday, March 30, 2010
discombobulated? become a TV reporter
Monday, March 29, 2010
by any other name
petrified
- Incompetent individuals tend to overestimate their own level of skill.
- Incompetent individuals fail to recognize genuine skill in others.
- Incompetent individuals fail to recognize the extremity of their inadequacy.
- If they can be trained to substantially improve their own skill level, these individuals can recognize and acknowledge their own previous lack of skill.
Put another way, this is all about people who are so dumb that they don't know how dumb they are. This reminds me of the story from a guy about his daughter and her singing. As a toddler, she insisted on singing loudly and clearly with nary a clue about how out-of-tune she was and how terrible it was for the ears of her listeners. He described her as unconsciously incompetent. As her days in school went by, she finally began to realise just how much her singing sucked. She was now consciously incompetent. She then started taking lessons and became a good singer. She now knew that she sang well and her listeners were now far better off. She had become consciously competent. After years of practice and performance, she became an artist of sorts. She had finally become unconsciously competent (People like Charlie Parker and John Coltrane who churned out endless runs of complicated yet masterful notes were in the upper crust of this category). The Dunning-Kruger effect seems to describe all individuals, who, for reasons unknown to quantum physicists and zoologists, appear to be atavistically inclined: they are destined to achieve new nadirs in unconscious incompetence.
Thursday, March 25, 2010
do you understand?
if (!true != !false)
.
Wednesday, March 24, 2010
rubies from rediff
Jacqueline answers, I love Dev D and Devdas! Both types of cinema interest me a lot.
Monday, March 22, 2010
super power gets cycle-savvy
Saturday, March 20, 2010
the curious case of the dog
It happened when I was reading the Scribner hardback edition of Stephen King's Under the Dome (ISBN: 978-1-4391-4850-1). The material seemed familiar and the King flourishes abounded. I was prepared for reading what looked like a return to territory last explored in The Mist and The Tommyknockers. The trouble started in chapter 4 of the section called "the good of the town, the good of the people." I was now familiar with Julia Shumway and her 15-year old Corgi named Horace. Chapter 4 begins with her getting ready for a night walk with Horace when her cellphone rings. It's Colonel James Cox of the US Army. Page 122. The conversation is about to end when, on page 125, a strange thing happens. The dog's name changes to Hector. This transformation lasts till the end of the chapter on page 127. What started with Horace -- waiting by the door, more than ready for a nighttime expedition now that he was cleaned out and fed -- pricked up his ears and looked around at her becomes Hector continued waiting patiently by the door and At the door, Hector pricked up his ears.
[march 30, 2010]: "Are you sure you have an authentic copy?" asks Sarika. This prompts me to check Google Books. Lo! The version available there (relax, it's just a preview, you passengers of the Black Pearl) is a corrected one. Closer examination reveals that it's a Simon and Schuster illustrated edition; the ISBN's the same, but this is most likely a newer version. I guess that makes the Scribner first editions collector's items.
knock on would
Monday, March 08, 2010
the ex-wife wins
Saturday, March 06, 2010
axis2: the sequel reeks
I recently returned to the natatorium of web services with the most variations of alphabet soup, the most fertile bed of specifications, some unfortunate acronyms (it's the time to DISCO ... get yourself some ROPE ... and who can forget SOAP?) and enough layers around an old idea to make it look like an adorned overfed pachyderm. The tools seemed to have improved; or perhaps they had just grown to have stronger armour to withstand the onslaught of specifications and protocols. Axis, the most popular open-source toolkit for web services had made way for Axis2. Axis2, it turned out, had decided to try and beat the WS soup nazis at their own game. It came up with its own complex design (ADB, AARs) and its own alphabet soup (an object model called AXIOM).
Getting started was not a problem, but once you started using the beast, you began to see the cracks. A simple client needed 18 JARs and notched a footprint of several megabytes. You saw all the typos (When users sends SOAP messages) and poor grammar (User care able to set his own mime-boundary string using this property) in supporting articles and in the documentation (Substract?). You also saw how careless the documentation was at times (the supporting text files for the 1.5.1 distribution contain URLs for the 1.4 distribution). You were taken aback at how incomplete (why have two articles on configuration parameters, when you could have just added some more javadoc? Then there was lack of support for enums, which is unfortunate because you just lost a clean strong way to enforce some constraints on parameter values. It's also a bit silly since J2SE 1.5 is the JDK of choice and the support for enums represented one of the most useful things that came with that version. If you wanted to try using minOccurs
or maxOccurs
, you were out of luck again. It all started looking like a giant step back for WS-kind.
Let's not even get started on interoperability or support for Spring. There's a very limited view of the world as far that last thing is concerned and it's a gross violation of the larger view that the developers of Spring have adopted. It's time to look at something simpler and more useful. After all, getting an elephant to guard your house soon becomes an economic problem (there's also the pachydump to consider).
(a few hours later). Oh great! Despite tall claims, Axis2 has severe problems with basic inheritance.
(a few days later). I am of the opinion that the quality of logging in any project says a lot about the quality of the project itself. This makes Axis2 suck even more. Let's start with org.apache.axis2.context.AbstractContext
and scroll down to the method debugPropertySet(String key, Object value)
. The following block of code contains enough to send your lunch back up your throat:
log.debug("=================="); log.debug(" Property set on object " + identity); log.debug(" Key =" + key); if (valueText != null) { log.debug(" Value =" + valueText); } log.debug(" Value Class = " + className); log.debug(" Value Classloader = " + classloader); log.debug( "Call Stack = " + JavaUtils.callStackToString()); log.debug("==================");
What a great place to practise your minimal competence in ASCII art. The fun doesn't end here. Let us turn our attention to org.apache.axis2.util.JavaUtils
and specifically to the method callStackToString
.
/** * Get a string containing the stack of the current location. * Note This utility is useful in debug scenarios to dump out * the call stack. * * @return String */ public static String callStackToString() { return stackToString(new RuntimeException()); } /** * Get a string containing the stack of the specified exception * * @param e * @return */ public static String stackToString(Throwable e) { java.io.StringWriter sw = new java.io.StringWriter(); java.io.BufferedWriter bw = new java.io.BufferedWriter(sw); java.io.PrintWriter pw = new java.io.PrintWriter(bw); e.printStackTrace(pw); pw.close(); String text = sw.getBuffer().toString(); // Jump past the throwable text = text.substring(text.indexOf("at")); text = replace(text, "at ", "DEBUG_FRAME = "); return text; }
Turn up the logging for org.apache.axis2
to see what I mean. Your log file will start looking like Armageddon and none of the traces will offer any useful information. The lack of respect for both performance and the usefulness of information is, however, appalling.
[march 23, 2010]: I should have just seen if Hani Suleiman had anything to say about Axis2. Guess what? He already said his piece in 2006. It's all there in the bile. If only I had read this first: I agree about the documentation, the language, the quality of code (System.out.println calls instead of logging calls; a complete lack of logging in core code, which means that I have exactly no idea what's going on behind the scenes even with the Axis2 code in front of me). Heck! I agree about everything. I wonder how the ASF let such a sub-par project into its fold. I leave you with a sample log message (some details have been removed in the interests of privacy) from the morass of one of the numerous builders floating in the source tree: Build the OMElelment obfuscatedFieldNameBy the StaxSOAPModelBuilder