StackOverflow DevDays

About 6 months ago I signed up for the StackOverflow DevDays in London, a one day event run by the team behind StackOverflow, which if you’e a programmer is a website you’ll probably know well. This includes Joel Spolsky and Jeff Atwood, the aim of the day is to talk about all things development. So no particular focus on a technology, more a focus on good code, how to write it and, the appreciation of it.

An example was the session given by Michael Sparks from the BBC about Python. Not a language I know anything about, but in 45 minutes he went line by line through around 30 lines of code which make up the spell checker in some Google apps. Hugely nerdy but informative, interesting and inspiring. Other technologies covered included Android, Nokia QT, jQuery, Yahoo Developer Tools and so on. The only common factor being people are doing cool things with the code.

And inspiration was really the order of the day, if you were slightly jaded about programming going into the (packed) auditorium then by the end of the day, if you weren’t re-inspired to do cool things then a change of career should probably be on the cards for you.

Unfortunately I had to duck out early due to some real world production issues to deal with, but if the event comes back in the future, you can be assured that I’ll be signed up.

October 28, 2009 by 0

Taking Notes Podcast Episode 100

Yesterday, Bruce and Julian were kind enough to invite Peter Presnell, Declan Lynch and myself to have a bit of a chat about XPages on the land mark 100th episode of the Taking Notes Podcast. The chat itself seemed to go OK, but even if you’re not interested, you should listen to the podcast for the first 4 minutes if nothing else. 

Rob Novak managed to organise the Lotus Community (like herding cats at the best of times) to record their own individual congratulations for Bruce and Julian. We get to enjoy the fruits of his work at the start of the podcast.

So go and take a listen. And here’s to another 100 episodes of a great Lotus tradition.

October 26, 2009 by 0

Catch and Cancel Return Key Press for Safari in XPages

The solution to one of the small but annoying bugs in IQJam had eluded me for quite a while, so this morning I resolved to have another go at it after a lazy weekend of feeling ill. And, lo and behold, I managed to fix it.

So a little bit of background to the problem, when you login to IQJam we provide a login button for you to press after filling in your username and password, but most people are used to just hitting return after finishing typing their password. Unfortunately, this is a case where Safari actually implements internet standards just a little too well. What browsers are meant to do (but none of them except Safari actually do) is submit the form that a text field is in when the user presses the return key.

Now in most development environments this is pretty easy to fix, you just add a

return false;

to the onSubmit action of the HTML form that the field is located in. But with XPages we don’t have access to the action, onSubmit or anything else to do with the form, as pretty much everything you click on in an XPage will want to interact with the server using code that has been generated for us rather than written by us.

In this case, I wanted to do my own AJAX post request to the server and deal with the entire interaction myself and stop anything else being submitted to the server. The problem was how? I spent ages trying to stop event bubbling to try and cancel the keypress event when the user presses return to no avail. However, I did learn, at least, that the keypress event fires before the form is submitted back to the server.

So my solution is to put this code in the keypress event of the password field:

if (thisEvent.keyCode == 13){

dojo.connect(

document.forms[0], 

‘onsubmit’, 

null, 

function(e) { 

e.preventDefault();

return false;

}

);

doLogin(“#{id:userName}”, “#{id:password}”)

}

Basically when the user presses the return key, using Dojo, I can re-write the form onsubmit method to prevent it posting back to the server, and instead run my own “doLogin” function.

It’s important to be aware that this will effectively break the XPage for all other actions unless I re-write the original onSubmit function back to what it was after I have finished, but here, I am going to be re-loading the page anyway so it’s not necessary.

Once again, we have more evidence that if you’re beginning to get into XPages, it’s worth spending as much time learning Dojo as it is to learn the XPages themselves.

October 19, 2009 by 1

Domino Designer is Free!

I can’t imagine why you’ve not seen this news, but just in case, with the release of Notes / Domino 8.5.1 next Monday, Domino Designer will now be free.

This is huge news for the platform, as it means that anyone can download and have a play with 8.5.1 which is the first really good version of Domino Designer on Eclipse. It means that you can have a play with XPages without having to worry about CALs. And I’d really recommend taking that look, whereas XPages in 8.5.0 were very much a “dot zero” release, with 8.5.1 we have a vastly improved dev environment and hugely increased performance and stability on the server side.

If you’re in any doubt about what you can achieve with XPages in a relatively short amount of time (i.e. less than it took us to develop the first version of IdeaJam), then have a look at http://IQJam.net, the first commercially available application developed specifically for Domino 8.5.1 using XPages.

October 6, 2009 by 0

IQJam Beta is live

As you may have seen, Bruce announced the beta release of IQJam overnight. We’ve been bashing on about IQJam for a couple of months now, so I thought I’d give a little background on what it is and where it came from.

The original genesis of the application came, as these things do, from several different places at once. Within two weeks, three of our IdeaJam customers spoke to us and said they were looking for ways of building up databases of solutions to problems. Of course, each of them had a slightly different take, one wanted to enhance their Help Desk, another is rolling out a new methodology and needs support in that process for people new to the way of working being introduced.

As is normal on this blog, I don’t really concentrate on the business side of things, more the technical as that’s my day job. It got us thinking anyway, and taking the experiences we had from rolling out IdeaJam and the characteristics of our existing customers into account we made several technical decisions up front.

Run on XPages, which in turn lead us to make the choice to only run on Domino 8.5.1. This was actually a very easy decision. I have been hugely surprised over the last year at how willing companies are to take their servers right up to the latest version of the Domino server. 8.5.1 will be coming out sometime soon (as we have learned from Ed’s blog) and our expectation is that most of the 8.5.0 servers will be quickly upgraded and that those people not wanting to go with a “.0” release will also follow on soon behind. In terms of the XPages side of things, the changes that we have been given in 8.5.1 make XPages so much faster, more stable and usable that I have really loved the last 4 months of coding even on the beta releases.

Just to give you an idea of the performance. The live IQJam server has an old Pentium 4 processor and a single hard drive. My impression is that with the release of 8.5.1, XPages will actually overtake classic HTTP in terms of performance.

Support “modern” browsers, that is – IE6 can take a back seat. This, I suspect will be our most controversial decision. Not amongst developers of course as we all know that IE6 needs to die, and die quickly. But it is still a corporate standard in many companies. What we have learned with IdeaJam, though, is that the companies most interested in “social software” also seem to be the companies that keep most up to date with their software, including web browsers. I can honestly say that I have not even looked at IQJam in IE6 and have no plans to. That being said, everything should work fine, there may be some UI discrepancies where we are using funky CSS etc, but life is too short to support IE6 so we have no plans to. At all. Was that definitive enough? 😉

Administer everything from the web. This was a relatively easy decision, one of the surprises about IdeaJam is the number of people that we host the application for on our server (witness the recent Lotus Knows IdeaJam event). In IdeaJam we have put as many administration function into the browser as possible, but for IQJam we wanted to make everything available for the hosted customer. So from the browser it is possible to control the look and feel of the application, messages that get displayed to the user, graphics, emails, and every single other configuration option.

Over the next few weeks and months, I plan to dig a little deeper into the XPages side of things, how we do certain things and why we did them that way. But for the moment, head on over to iqjam.net and have a dig around. You can log in with your existing IdeaJam user name and password, or register if you’ve not used IdeaJam before.

September 16, 2009 by 0

On synchronization in XPages

The biggest issue that we had with XPages in 8.5.0 was performance, every piece of code you wrote had to be optimised to get the best performance, something which us Notes developers have spent all too little time on in the past.

With 8.5.1 everything is faster from DDE onwards, but there are some code changes that we can take advantage of to make things even better. Most important of these is synchronization. For those of you who know Java this will be a familiar concept that has just been implemented into Server Side JavaScript (SSJS). But for the LotusScript developer, here is my quick attempt at explaining it…

If you have a commonly used piece of code, it will be called by multiple different areas of the system at the same time (or at least very close together) and return the same result. If you’re doing some expensive piece of work (such as a DbLookup) then all of the calls to that code will run and there will be an inevitable performance hit.

By adding the synchronize wrapper around the “expensive” code what will happen is that all of the calls to that code will queue up behind each other, so that code can only run once at a time. We can then cache the results of the code so that all of the queued up calls can just get that result from memory (the applicationScope for example) rather than having to go off and calculate it again and again. A very simple concept but one which saves a huge amount of processing time.

But what will our code look like? Well here is a sample function from the upcoming IQJam application that will be launching later this week.

function getControlPanelFieldString(fieldname){

synchronized(applicationScope){

if(isCacheInvalid(“controlpanel_” + fieldname, 600)){

var controlPanels = database.getView(“lookupControlPanel”);

var controlPanel = controlPanels.getFirstDocument();

applicationScope.put(“controlpanel_” + fieldname, controlPanel.getItemValueString(fieldname));

controlPanel = null;

controlPanels = null;

} 

}

  return applicationScope.get(“controlpanel_” + fieldname);

}

/**

A generic caching mechanism for each key will check to see if it is ‘n’ seconds

since it was last updated. Use for things that change relatively infrequently  

*/

function isCacheInvalid(key, cacheInterval){

var currentTime = new Date().getTime();

if (!applicationScope.containsKey(key + “_time”)){

applicationScope.put(key + “_time”, currentTime);

  return true;

}

var diffInSecs = Math.ceil((currentTime – applicationScope.get(key + “_time”)) / 1000);

if (diffInSecs < cacheInterval) {

return false;

} else {

applicationScope.put(key + “_time”, currentTime);

return true;

}

}

We store lots of tiny variables about the application in a “Control Panel” document and then read them as needed into the applicationScope. The nature of the variables is that they don’t change much so we can cache them for long periods of time (10 minutes in this case).

As with lots of XPages code, the idea for this came from the Discussion template (which is quite dramatically different under the covers in 8.5.1), so I’d highly recommend digging through the code in there to get an idea of what you can do with XPages. And of course we have to offer thanks to Thomas Gumz and the other XPages developers in IBM who write the code that the rest of us can then re-use for our own dastardly ends.

Disclaimer: Notes/Domino 8.5.1 is beta software and no features are guaranteed until release.

September 14, 2009 by 4

Sessions, sessions, sessions

When is a session not a session?

Most Domino web sites these days will be running some form of session authentication which stores a cookie on the user’s browser and a tiny piece of memory with details about the user on the server. This has always worked fine, and of course these sessions can time out (by default after 30 minutes).

But with the advent of XPages we now also have the sessionScope variable container which allows us to store information about a user’s session (whether they are authenticated or not). This offers us huge opportunities for performance improvements as it means we don’t need to keep on doing @DbLookups to get user specific information for every page load. But it does introduce some potential issues if the authentication session timeouts are different to the sessionScope timeouts.

Basically the server needs to be able to clear out sessionScope variables after an amount of time, otherwise the server would run out of memory very quickly indeed. But in a recent project we had users who would open a page and then come back to it 2 or 3 hours later and then wonder why everything had stopped working. This is because the default timeout for sessionScope variables is something around 30 minutes and our session timeouts were set to 2 hours.  So once the page had been left inactive for half an hour it effectively lost all of the background information that drove how it should act when the user pressed the save button for example.

The solution is very simple, but very important. In the application properties for your database (opened in Domino Designer these days remember), go to the XPages tab and make sure to set the Session timeout field to be more than the authentication Session Timeout (which you set in the server or website document). The rule of thumb that we have come to (in the absence of any official guidelines from IBM) is that if you have a 2 hour authentication timeout for your website, then set the XPages Session Timeout to 3 hours.

Generally the application timeout is less important for this sort of thing, but we took the opportunity to also set that to 3 hours in this case as I knew it wouldn’t be too large.

There are, of course, caveats here. If your server has memory issues then this is only going to exacerbate them as for each user (remember a user is just a visitor to the website, not necessarily someone who logs in) is going to take up some memory from the server for a minimum of 3 hours, but for us it solves more problems than it causes.

Of course, if you are not using the sessionScope to store any page sensitive data then you can just ignore all of this, but once you start using the sessionScope, it does become rather addictive, so I suspect you will get some benefit from setting this variable. Either way if you start to see completely bizarre errors, this may be a good first port of call.

Hopefully this article will save someone the pain of trying to debug seemingly un-reproducible errors in a dev environment where you don’t have the time to leave pages inactive for hours on end!

September 10, 2009 by 4

If you’re going to UKLUG…

…we’ve been waitlisting new registrations for about a week now, even though there is still a month to go. I suspect that the announcement of Bob Picciano as the keynote speaker was what pushed us over the top so early on this year.

This is great news for us, especially when conferences are suffering so much in the current economic strife. But what it does mean is that, if you’ve registered you have a certain amount of responsibility. If you do not turn up to the event then your wasted space could have been taken by someone else. Given the amazing agenda that we’ve got set up, we want as many people as possible to be able to attend.

If you can’t make it, that’s fine, but could we please ask you to log in to the site at http://uklug.info and click the profile link on the top right and then the “Cancel Registration” button. This will allow us to approve the next person on the wait list in your place.

September 10, 2009 by 0

Giant’s Causeway walking weekend

A group of fellow Loti types spent the weekend leeching off the hospitality of Steve McDonagh and walking the clifftops around the Giant’s Causeway in Northern Ireland.

A cracking time all round (and my legs have just about recovered). Full trip report here and my photos (not nearly as good as Eileen’s for which I shall blame the phone based camera) are here

September 7, 2009 by 0

LotusKnows IdeaJam is OPEN!

Ever since IamLUG a couple of weeks ago, we’ve been looking forward to the LotusKnows IdeaJam. For as long as I can remember the Lotus community has been asking for more marketing from Lotus generally, well this seems to be the chance we’ve been waiting for. If you have a great idea or simply want to go and comment and vote on other people’s thoughts then head on over to the site.

If you already have an IdeaJam username and password then you don’t need to register again, but it’s only a three day event so get in there quick and make the most of the opportunity.

August 19, 2009 by 0