Author: lekkim

Positive, competent, out-spoken, frank and customer focused architect and developer with a strong foundation in web, cloud and product development. I'm a strong advocate for API first and cloud based solutions and development. I have a knack for being able to communicate and present technically complicated matters in conference, customer and training settings. I've previously acted as team member and leader in a product organisation.

Lotusphere 2009: I have arrived

So I arrived last night at the Swan hotel after a long day of travel from Copenhagen, via Frankfurt to Orlando. I was in the hotel around 9.30 PM so that was nice. Even nicer since I, after a pizza and a beer, slept through the night so I’m hoping to have beat most of the 6 hour time difference. I remain to be proven right though… 🙂

Today (Saturday) is for relaxing if I manage to fix the last bug in a product and then BALD later. Maybe a little shopping with my Fiancee as well.

Lotusphere 2009: Showoff of what have I been doing these past two weeks?

The weeks leading up to Lotusphere is always crunch time but this year it has been worse than previous years. I have been head down with work almost non-stop the last 2 weeks. It has been rewarding though. I just finished the last beta of the next version of our sidebar plug-in for our group calendar product and if I may say so myself it kicks as…

If you want to see it in action stop by our booth on the showcase floor or watch this Flash movie (7mb) showing it off (it’s a bit heavy to load).

Now what was my Lotusphere presentation on again? 🙂

Lotusphere 2009: Bloggers program

As others (at least Mitch and John) I feel obligated to let everyone know that I have been selected to be part of the Lotusphere 2009 Bloggers program. Not sure that it changes anything though. Members of the Bloggers program will be sporting a “Blogger” sticker on their badge which makes for an interesting way to block being scanned in the showcase as I’ll be having a Speakers sticker, a Blogger sticker, a BDDay sticker and an Exhibitor sticker. Wow!

Besides all this blogging has been slow lately as I’m slowly surfacing after 8 days of non-stop work getting a cool sidebar plug-in product ready for Lotusphere. You should come see it at our booth in the showcase. Besides that I’m looking forward to hooking up with people.

I’m leaving for Florida in 3 days! Man I’m looking forward to it.

LotusScript.doc v2 – an update on the progress

Besides working way too much I have spent a good part of my Holidays working on LotusScript.doc version 2 and I’m happy to say that it is very close to completion. I have spent a great deal of time finalizing the logging framework and building the Notes/Java bridge to allow you to run LotusScript.doc from a Notes database instead of as a command line program. I also needed to weed out some issues in this regard which is why I have been blogging issues such as configuring the java.policy file and the maximum Java heap size.

To clarify…

LotusScript.doc v2 is out in a very, very limited prebeta 1 with one person besides me to try and weed out the most serious issues before releasing a beta. Again a beta, at least the first, will only go out to a select number of people to try and keep track of who has what release.

The goals for the functionality of LotusScript.doc v2 are very big but for starters I’m going for feature parity with LotusScript v1. Then once the new technology is out there I’m going to start enabling the new and advanced features.

Thank you for your patience.

LotusScript.doc v2 – required Java heap changes

Strong: Just to clarify – LotusScript.doc v2 isn’t out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

As you might know LotusScript.doc v2 is written in Java instead of LotusScript. This means that you have to make some minor changes to your Notes client to make it work. One of the settings you need to change is the size of the Java heap that is the amount of memory allocated to Java objects.

To change that you need to set the JavaMaxHeapSize notes.ini parameter as described in the Lotus Notes and Domino wiki. Although the wiki describes the setting as only being applicable to Domino servers it works just as fine for my test Notes client (8.0.2 Standard in this case). To change the setting add the following to your notes.ini (do check whether it is already set):

JavaMaxHeapSize=384MB

LotusScript.doc v2 – java.policy changes required

Strong: Just to clarify – LotusScript.doc v2 isn’t out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

LotusScript.doc v2 uses java.util.logging as its underlying logging framework. To spice things up a little it also uses some internal magic to ease troubleshooting and provide easy debugging. One of these tricks is to print out the XPath expression of the element being processed in the log. More on this another time.

In order to use java.util.logging and set custom Handlers and Formatters you need to tweek the java.policy a little bit. It’s quite easy as the only thing you have to add to your <Notes binary directory</jvm/lib/security/java.policy file is the following in the first “grant” section:

permission java.util.logging.LoggingPermission "control";

Here is a link to a default java.policy file and a changed java.policy file.

I’m trying to create script libraries using DXL – possible?

I have spent a little time this weekend trying to create Java script libraries (that is script libraries with Java code and not “JavaScript” libraries) from scratch using DXL. Exporting the DXL of a script library with a jar-file imported into it yields some base64 in a <javaarchive /> tag. The base64 data is however not decodable as it’s not valid base64. Base on prior experiences with this kind of stuff I tried decoding the bytes but without success.

The header in base64 is (or at leas to a multiple of 4 characters) is “UEsDBBQACAAIAKyEATkAAAAAAAAAAAAAAAAUAAAA”. I guess the beginning is probably a CDFILEHEADER struct (based on prior help) but I’m unable to decode it… 🙁

The struct should start with a DSIG struct (16 bit unsigned integer and a 32 bit unsigned integer) but I’m unable to get anything that makes sense. I end up with 20555 for the first WORD but that doesn’t “compute”. Bummer!

If you’ve done any work on this and is willing to share please drop me a comment. Thanks.