Sarath Chandra Pandurangi's Blog

When you are developing a customer front web application, you should take every measure to hide technical details from the user. This is especially true for JEE applications. Not only because the user is pissed off looking at a huge stack trace but also it reveals a lot. Look at the following figure This famous shopping site has been developed to show stack trace on the web page. The developer cleverly hid the trace when the page loads up. But leaves a link that uses DHTML to show the hidden div. That kinda defeats the whole purpose. If the user sees this link, he is less likely NOT to click it. If you really want to have a handle on this. Print out a unique token (a timestamp, md5 hash or something - get creative here), and correspondingly log it in your appserver along with stack trace. Have the user (customer or your pain-in-the-neck-QA guy) email you that token. Now you can grep that log for it. Now, you know, I have less confidence in that site this day forward.

Jyothsna and I love biking. Yesterday we *surprise* visited Annapolis. It was sudden, so, I dint know where to start. So we stopped at the visitor centre. Found out US Navy Academy was a place worth going to. And there was a college football game that had just begun. We had a more naturalistic view on spending the evening. So we started walking to the Market space, to the dock. At the end of the dock, We were surprised to find Free Wheelin' . They rent out bikes for free. Really. Its not a 16 speed mountain bike of your childhood dreams but, a simple one speed cruiser enough to have fun. All they needed was our Photo Ids and a Credit Card. (They make a copy of these and shred it when we return). They even gave us a Annapolis Transit pass each, in case we had a flat tire or just were to far to bike back. I did a similar thing in SFO two years back. A friend and I rented a couple of bikes and biked the Golden Gate. But that wasn't free. We rented from Bikeshare.com. They cha...

Reading this post , I feel the urge to burst out. This kind of tweaking is not really *adminy* . A true Admin would rather kill the terminal he sudo-ed in, to be even sure. Enabling your user to become a sudo-er is a privilege. Like in the movie, Spider-man - Great power comes with great responsibility. The extra prompt for password might be a little annoying for frequenters. But completely overriding it is appalling at best, if not awful abuse of the said privilege. For all the interns who joined as admins, a friendly advice - security defaults have a place in unix. They are set after a lot of research in usage (especially by admins before you). So leave them alone, as much as you can. Security is not for ease of use. The harder a password the better, so read that post with admonition. For the new *nix users - If you just want to do this, Dont bother installing *nix. Go with an easy mac or better yet, stick with Windoze ME (I am rude, am I not?). Well that feels happy now. I h...

I LIVE google voice. I dont know if it is down, but I got this. Time : Saturday, September 05 2009 11:08 AM EST Calling the Phone # seems to work fine.

Textareas allow new lines to enter. These are represented by \n (1) or \r\n (2) characters. But when you save to DB you have a limit to certain length of chars. There is no maxlength attribute in HTML that will stop you from entering data. This is generally acomplished by Javascript. You do a onkeyup hook and stop event or trim after textarea.value.length > maxlength. There are many other solutions out there.. But.. Here is the problem that most of those solutions overlook, How do you deal with the count on \n and \r\n representations. Lets first see how it matters. If the text entered has new lines, the length is calculated differently in Firefox and IE. When you enter a Text like 01234 567890 You expect the textarea.value.length to be 11. (10 chars + new line).On the backend, however, java would recieve it as 12 chars (10 chars + \r\n) (this is irrespective of FF or IE). So you are effectively saving 12 chars to DB. Worse yet, IE seems to figure textarea.value.length as 12 (...

In iBatis, a parameter is escaped, autoquoted and replaced automatically. So a #stringParam# will be auto autoquoted and then replaced. Its also escaped, meaning symbols like ' and % are escaped. This causes a problem when you have to do wildcard searches. With a like operator. Say, You have to look up employees by first name. The SQL would look like select * from emp where first_name = 'sarath' and the iBatis Query would be simply <select id="getEmpByFName"> select * from emp where first_name = #value# </select> On the same lines, A wildcard search of firstname would be (in SQL) select * from emp where first_name like '%sar%' But, if you just make an iBatis select like: <select id="getEmpByFName"> select * from emp where first_name like #value# </select> and make it concatinate with "%" before passing it to queryForList(), You will see nothing in results. This is because iBatis will escape % too. ...