Override backspace as the back button

I have a common problem. I write a lot of web applications that run in a portal. When a user hits the back button it will take them to a different portlet or log them out of the portal completely. I can't prevent them from clicking the back button, but IE and Firefox both have the backspace key set up as a shortcut for the back button. This is annoying because the users will accidentally type it thinking that the cursor is in a text field. When it's not the back button is pressed and the user complains that they were randomly logged off.

To prevent this I use the javascript Shortcut.js and a small chunk of code.

shortcut.add("backspace", function() {
 // override backspace as the back button
},{ 'type':'keydown', 'disable_in_input':true, 'propagate':false });

That's all there is to it.

Tool tips thought

I don't know why it didn't occur to me before, but a tooltip does not have to be hidden when the link to hover loses focus. Especially if the tooltip should remain up for the user to interact with.

Instead ensure that the tooltip shows up where the mouse cursor is currently located, covering the underlying link, then hide it on mouse out of the tooltip instead of on mouseout of the initiating link.

clueTip zindex tip

OK, so the title isn't great, but that's what this is.

I had an issue where I'm using the clueTip jQuery plugin to show tooltips in my page. Everything was working great until I tried to show one inside of a dialog.

Even when I used the cluezIndex setting to show the tooltip and set the value to 3000 it wouldn't work.

$('a.toolTip').cluetip({cluezIndex: 3000, local: true, hidelocal: true, cursor: 'pointer', arrows: false, positionBy: 'mouse'});

After tracing through the code I found the problem. Once a tooltip is added to the page the cluezIndex value that it has stays the same, you can't change it with this setting.

For me, I made sure that all of my cluetip showings set the cluezIndex to 3000. Be sure to set the cluezIndex to a value that's higher than everything you want it to be above.

jQuery annoyances

Mostly I love jQuery, but there are few annoyances that I have struggled with.

Datepicker

• I have not been able to bind a date picker to elements that are dynamically added to the page after load. This causes a problem.
• The z-index did not allow the datepicker to show up on top of a dialog, I had to tweak the CSS to make that happen.
  

Dialog

• My element is stripped from the location on the page and moved into the dynamically generated dialog html element. this causes inherited CSS settings to be lost and the layout within a dialog must be specifically set.
• Building the same dialog multiple times puts multiple copies in the DOM instead of cleaning up itself.
• .remove() removes the dialog from the DOM by completely destroying the HTML, but it also destroys my HTML that was ripped from another location on my page.
• the maxHeight value is ignored when initially building a dialog, and I have to check the height and specifically fix it if it is too big.

Branching code for Development and test.

One of the biggest problems that's happened on projects that past few years was that web service changes that I was working on would break the UI that used it. This would cause testing to come to a halt until I could also add in the UI enhancements and redeployed it for test.

On the project that I'm working on now we're trying to implement some changes based on those problems.

First, we have set up a new web server to deploy a Development version of the web service to. This stems directly from the fact that new enhancements require changes to the web service and UI. The rules or additional features of the web service may break the UI until it is enhanced to take advantage of the new features. Having this new server now, I can break the web service and also use this development version to update the UI. When both are ready then they can be deployed for the tester.

Second, with multiple developers, sometimes one persons changes are ready to deploy for testing before the other persons. However, in an environment where everyone is using the main branch of the Source Code Repository (CVS for me) the code may not be in a deployable state due to one of the developers changes. In order to keep code synchronized with CVS, just in case my local hard drive dies, and have things in an easily deployable state, we are planning to branch each Story.

Timing is odd, it's something I was planning on doing, before I started implementing it I had the article The Story of the Branch Pattern sent to me. I'm doing basically the same thing.

Head is always deployable and the version that the Testers are testing. Defect fixes (unless they are very big) are done directly in Head so they can be redeployed quickly.

A new branch is created for each story. Development of the stories are done stand alone until they are ready to be tested, then they are merged in with Head and deployed for testing.

The only problem that I still have not figured out a way to work through is that this project has multiple developers. Each one is working on Web Service changes at the same time, and needs to have that web service deployed somewhere in order to make changes to the UI. We only have one development web server. Ultimately I think this could be fixed if I could figure out a way to get both the backend web server and the front end web server running on my local box. Each developer would then do everything locally until they are ready to merge. Until then I think the only solution is going to be to merge web service changes together outside of Head and deploy that merged version to the development web server.

Ultra Edit is coming for Linux and Mac

Ultra Edit (my favorite editor) is finally making a version that will run on Linux and Mac.  I think that this is a very telling step.   It may mean that software makers are finally feeling that Microsoft is losing it's grip on the OS.   

Even without some of the more popular pieces of software being available for Mac, and to a smaller extent Linux, people have been switching away from Windows.   

If Software Vendors update their applications to work on these other systems, I expect that even more people will be willing to make that leap.

Book Review: The Little Book of Ruby

SaphireSteel.com gave away the free book The Little Book of Ruby and I took advantage of it. Due to some things I was working on I had to restart the book several times. Now that I've finally finished it I thought I'd write up my thoughts.

The Little Book of Ruby does a decent job of explaining the very basics of Ruby. It does not delve into detail or give best practices on things, however, it's enough that a Ruby Beginner can read through the 85 page eBook and be able to figure out mostly what's happening in Ruby code that they look at.

It's a better start to Ruby than Why the Lucky Stiff's into. Why is an interesting character, but he gets too sidetracked, The Little Book of Ruby is a much better starting place.