Tuesday, April 28, 2009

Misguided documentation

Documentation is one thing in software development which no one wants to do and hence gets talked about too little or, gets talked about a lot and still no one wants to do it. Even if documentation exists its a pain to read or get at the information that you want mostly because of bad abstracts and introductions. With the proliferation of software methodologies each requiring its own type of documentation its a mess (just like the code :P..). Even in a single methodology there are approach documents, HLDs, LLDs, use-case documents etc. most of which are sometimes not very relevant but, since the the enterprise processes demand it they are still produced and maintained :O.

I had to pick up the implementation of a small (er. tiny actually) feature and was given 2 documents to start off. The first was an abridged requirement specification covering just the change that I was supposed to do and the other an impact analysis document. The requirements document was pretty straight forward (except for some vague clauses added just so that the business analysts can bargain later). The impact analysis document was quite another beast, over 20 pages long (excluding the fluff like cover sheet, intended audience, disclaimer etc.) it was a carefully copy-pasted creation that discussed the same approach that was to be implemented in about 7 use-cases. If you were looking for existing functionality, use-cases impacted, use-cases that should not be affected, alternate flows, expected areas of conflict with previous changes etc. this was not the document to read. All the document said was in such-n'-such a screen, a field should be added the corresponding back-end code should be invoked blah blah for every use-case. I see absolutely no point in maintaining a totally worthless project artifact like this. If a change requires just a specification and LLD why not leave it at that why go through all the hoopla of creating all other worthless documents?

Wednesday, April 22, 2009

Google introduces updateware

I don't understand google's maniacal need to update. Yes, I understand that quick updates are a good but, the last time I searched for googleupd* in my hard drive look at how many places it showed up
%PROGRAM_FILES%\Google\Common\Google Updater\GoogeUpdaterService.exe
And google is still not satisfied :O..there are 2 scheduled tasks as well
GoogleUpdateTaskMachine - to run at startup
GoogleUpdateTaskUserS-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXX-XXXX - to run when idle
If you thought google was satisfied with that you're wrong they have the one last trick up in the registry
After software, adware, nagware, annoyware, bloatware google has introduced updateware :/ ps. follow this excellent link on instruction to get rid of it all

Tuesday, April 21, 2009

Vim replace expressions

Today I discovered the the existence of evaluated expressions as replacements in vim. Consider the following snippet
String tStr = request.getParameter("frmAmt_D_DR");
if ( tStr != null && !"".equals(tStr.trim()) ) {
  xxxDDrAmt = Double.parseDouble(trStr);
In this I want to transform the Double.parseDouble line to
xxxDDrAmt = parseLocalizedDouble(request, "frmAmt_D_DR", locale);
The change had to be done in a lot of files and I was racking my brains trying to figure out a macro to do this. I even tried to match the entire snippet but, ran into trouble with both approaches especially because the if condition could include other conditions and there might also be more than one limits that had to be processed. Then I found some obscure comment somewhere in one of the my numerous entreaties to google that referred to evaluated expression in the replacement giving me my Eureka! moment :). Since all the variable names were always some contraction of the actual input parameter name all I needed to do was to device an expression that constructed the parameter name from the variable name. Its long and ugly but gets the job done :D
:g/Double\.parseDouble/s/\(\w\+Amt\w*\).*$/\= submatch(1) . " = parseLocalizedDouble(request, \"frm_" . toupper(strpart(submatch(1), 3, 1)) . "_" . toupper(strpart(submatch(1), 4, 2)) . (strlen(strpart(submatch(1), 9)) > 1 ? "_" . strpart(submatch(1), 9) : "") . "\", locale);"/
Running this,
xxxDDrAmt = Double.parseDouble(trStr);
xxxDDrAmt = parseLocalizedDouble(request, "frm_D_DR", locale);
xxxDDrAmtUSD = Double.parseDouble(trStr);
xxxDDrAmtUSD = parseLocalizedDouble(request, "frm_D_DR_USD", locale);
Here is an annotated version but don't try using this one vim expects the entire thing to be in a single line :|
:g/Double\.parseDouble/                       # global search for double parsing
s/\(\w\+Amt\w*\).*$                           # search for variable names containing Amt
/\= submatch(1)                               # submatch(1) gives the first group
  . " = parseLocalizedDouble(request, \"frm_" # . is the string concatenation operator
  . toupper(strpart(submatch(1), 3, 1)) . "_" # strpart is the substr equivalent in vim
  . toupper(strpart(submatch(1), 4, 2))
  . (strlen(strpart(submatch(1), 9)) > 1      # don't change Amts to _S :)
    ? "_" . strpart(submatch(1), 9) : "")     # vim even supports the ternary operator ^_^
  . "\", locale);"

Monday, April 20, 2009

Custom taglibs in Websphere

I spent the better part of an hour trying to figure out why
var v = "<mylib:my-tag attr="<%= request.getParameter("some_attr") %>" />";
wasn't compiling in WAS6 and was complaining that attribute value is not given for some_attr. But, this
<% String someAttr = request.getParameter("some_attr"); %>
var v = "<mylib:my-tag attr="<%= someAttr %>" />";
works just fine. Turns out if you need JSP evaluation inside you custom taglibs attribute you need to give inside single quotes instead of double quotes. Something about the twin double quotes trips up the WAS6 JSP compiler. Now, since I had to do this in a lot of places I simply opted for the simplest solution, use single quotes :)
var v = "<mylib:my-tag attr='<%= request.getParameter("some_attr") %>' />";
Works like a charm !!