Command Recall on AIX

One of the most frustrating things about working with unix is the lack of a user interface, everything is command line. Try explaining stuff like awk, grep, vi and ls to new users and the complaints start to roll in. What tops the list has to be the lack of command recall using the arrow keys. We've all been conditioned that pressing up-arrow will bring back the previous command so we can make edits instead of typing the whole thing over again.

No more. Below is a short series of commands that can be added to a .profile that will enable the arrow keys to behave in unix like they do in DOS:

set -o emacs
alias __A='^P'
alias __B='^N'
alias __C='^F'
alias __D='^B' 

Note that ^P refers to the keysequence control-p while editing the file using vi, so actually typing in the characters probably won't work.

Debugging Dojo with Firebug

I've spent the last few weeks trying to integrate sametime dojo widgets into a portal theme and I used firebug extensively to debug my code. Dojo is difficult to debug because of the way it injects code using the requires function, everything shows up as an eval.

Firebug Extensions

I didn't know this, but there are quite a few firebug extensions out there, though none really for dojo. IBM has developed a dojo extension for use in their rational developer products, but since I use eclipse I was out of luck. Thankfully IBM has a history of participating in the open source community and appears to have contributed their code to the firebug community.

The code can be found at http://code.google.com/p/fbug/source/browse/#svn%2Fextensions%2Fdojofirebugextension

I downloaded from their SVN server and executed the build.xml, drag/dropped the resulting dojofirebugextension-1.0a6.xpi into firefox and now I have a nice dojo interface for firebug.

Thanks to Patricio Reyna Almandos and Fernando Gomez (IBM Argentina) for putting this together.

Vague Error Message with Sametime Proxy

More insight related to my work with the integration of sametime into a portal theme. If anyone runs into this error:

SystemOut.log:[3/7/11 12:41:01:852 EST] 00000022 STLoginServle W com.ibm.rtc.stproxy.servlet.STLoginServlet loginbyToken  CLFRX0055E: unable to retrieve login credentials

the message is a little misleading. Yes, it cannot retrieve the login credentials, but why exactly? The proxy will produce this error if it cannot find at least one of the following in the request:

• password
• LtpaToken
• LtpaToken2
• SametimeToken

 In my case I was using SSO through a Webseal reverse proxy and I failed to qualify my junction as an LTPA junction. Webseal wasn't sending the token causing the above error.

Race Condition with Sametime Proxy Server

I've spent the last few weeks integrating a web based sametime chat client into websphere portal and ran into a curious problem. It seemed that on occasion the buddy list would not populate, all I'd get is a dojo busy indicator, but if I refreshed the page everything would be fine.

Time to open up firebug.

I have to admit that dojo isn't the easiest javascript to debug, they've really stretched the capabilities of the language, but I finally tracked it down to a piece of code during the execution of:

ST_Client = new sametime.WebClient({}, "STClient");

At some point it tests if it should display the buddy list right away or add the task to a queue for later execution, and in this case it was adding to the queue. So who is supposed to deal with the queue, and why wasn't it being done? Turns out that there's some code executed in the login

stproxy.login.loginByPassword()

that iterates through the queue and displays the buddy list. I was running into a race condition because I was trying to log in to the samtime server before showing the buddy list, but in some cases the login was finishing before the call to create the WebClient was done.

The Fix?

Ensure that the code creates the WebClient before it tries to login. Go figure.