I'm my best friend!

Today, I was painfully trying to reactivate a 8-month-old prototype feature (a change in the way a project interfaces to Crystal Reports). The problems were the same we have previously encountered -- but, at the time, I was not on the project, just giving some technical hints and support. The most helpful messages thread I found in the Business Objects forums is a 8-month-old reply from me to me on these problems.

So, I'm my best friend.

The bretzel saved my life

Luckily I wasn't eating a bretzel while reading this (the most interesting part is quoted and translated below) otherwise I would still be choking.

Nach Erhebungen des Browser-Fachdienstes WebSideStory wurde der Firefox Anfang Januar von 4,6 Prozent aller Internet-Nutzer eingesetzt. Bis Mitte des Jahres wird ein Anstieg auf rund zehn Prozent für möglich gehalten. Der Marktanteil des Internet Explorers ist bereits von 95,5 Prozent im Juni 2004 auf 90,6 Prozent zurückgegangen. In Deutschland dürften diese Zahlen jedoch krass anders aussehen: Die Log-Statistiken von SPIEGEL ONLINE (beruhend auf über 200 Millionen Seitenaufrufen im Monat) sehen die Mozilla-Browser inzwischen bei rund 27 Prozent Marktanteil, der Internet Explorer ist derweil auf knapp 65 Prozent abgesackt.

Courtesy of google language tools:
After collections of the Browser specialty service WebSideStory the Firefox at the beginning of was used January by 4,6 per cent of all InterNet users. To center of the yearly a rise is considered possible approximately ten per cent. The market share of the InterNet Explorers already decreased/went back from 95,5 per cent in June 2004 on 90,6 per cent. In Germany these numbers might look however glaringly differently: The log statistics of MIRROR ON-line ONE (being based on over 200 million side calls in the month) see the Mozilla Browser in the meantime with approximately 27 per cent market share, the InterNet Explorer are meanwhile on scarcely 65 per cent sagged.

If you don't know Der Spiegel, think Time or Newsweek. Wow! Is the web ignited?

Second System Syndrom

The buzz is starting again about richer web interfaces (think GMail, Google Suggest), slashdot amplifying it.
I've got my lot of thoughts to share about this because I'm currently incubating the Second System Syndrom as my current task is coming to an end. I've been busy designing and building a JSP taglib and some strutseries using JavaScript, JSON and XMLHttpRequest.

Shared Model
The model has to be shared between the client and the server. Or, to be more precise, the model has to be replicated: currently, I'm sending far more data through background HTTP requests that what I need (and because of the new UI opportunities offered by the taglib the forms tend to be more complex and hence contain more data).
I'm currently envisioning two ways of doing it:

• directly mapping the Java Beans to replication enabled JS Objects.
• using server-side Javascript (Mozilla Rhino) with native objects and proxy objects on the client-side.
  

I'm afraid of the second solution being overkill (and I've not even thought how to make it fit with Struts) but I've got the intuition that useful things can be achieved with such a design but I can't say which. Anybody?

Toward more RESTful web applications
It may seem counter-intuitive but, given (ideally taglib-enforced) guidelines, enhanced web UIs make the web more RESTful. My main arguments are :
better HTTP support (PUT, DELETE methods)
less cluttered URL-space: far less technical URLs (some things can be entirely done client-side and the others can all be crammed into a couple of endpoints -- not that I support such extremities), so far more URLs really represent business processes and business objects.

Concerning REST, the major impediment (in my ecosystem) is Struts (mantra: must, not, abandon, Struts). Concerning business objects, I certainly could benefit from embedding the hibernate IDs into my URLs but I didn't really thought about it yet.

Java 5 annotations **sigh!**

I haven't yet use them that I run into their limits. (I'm not saying they will not help in managing the complexity; just that I already envision impossible applications.)
I just checked the Jsr 175 and the com.sun.mirror package over and sadly apt doesn't give access to the AST of the java class being compiled. What I've got in mind while browsing this stuff was to check whether it would be feasible to implement annonations inference (à la Hindley-Milner).

Digest: Formula Engine Rewrite

Damien Katz talks about what he worked on at Iris (those who created Lotus Notes/Domino) and it's story is pretty interesting on the ins and out of delivering such a piece of software.
(Furthermore I like to know my enemy: Lotus Domino is a foe of mine since I started writing extensions for this product.).

Here are the quotes:

Being a UI guy isn't just producing UIs, it also requires negotiating with lots of people, at least at Iris it did, which was the part I liked the least about the work. That's probably why Notes historically has such a maligned UI, because the culture there made it difficult to produce anything decent.

Iris was a lot like most engineering organizations, most of the good work was done by handful of talented people, the others often produced barely functional crap that would need to be cleaned up someday. (shocked? read the follow-up!)

It sounds weird, but that was big part of the culture at Iris. Just get it done and do it right, do whatever it takes.

My favourite:
I made some very unconventional decisions, the kind that taken in isolation sound crazy, but when combined into a complete architecture make good sense.

So here was my brand new untuned engine, hot off the presses and keeping up with the old, and I was a proud papa. [...] I profiled the engine, found the hotspots and destroyed them. They say you'll always be surprised by what the profiler shows, and I remember that I was. [...] The measurable performance gain was 300% faster.

These guys were cocky (at least they eat their own dog food):
At Iris we always ran experimental code on the production mail servers.

This remind me of The Raymond Chen Camp as once coined by Joel Spolsky.
More often than not, the old engine had it wrong, it had some indefensible behavior that was clearly not what was intended and often the formulas that relied on these behaviors did so unintentionally. It's like two wrongs making a right, but regardless if the old engine was wrong or right, the new had to have the same broken behavior. In software we call that being "bugward compatible". It sucks, and I absolutely hated that I had to go in and purposely mess up my carefully crafted, elegant code but that's what I had to do. That's necessary for a truly stable and backwards compatible product.

I also spent many months during crunch time working on the Database Team fixing bugs and performance problems. These were some of the hardest bugs I had ever faced, frequently we had no reproducible scenario, just a memory and stack dump, sometimes not even that.

But ultimately IBM killed Iris. In late 2001 IBM folded Iris Associates and converted all the employees to IBM. All the energy the Iris building had was seeping out. Really it was more pushed out by the BS that IBM management kept trying to sell us, like that nothing important would change and you'd still be able to work unfettered. Yeah right, just ask anyone who still works there how much time they spend battling bureaucracy vs. writing code. But such is big corporate management, they don't even realize how much they're damaging things, they are essentially politicians not engineers. It's sad, but I'm grateful for the time I had at Iris anyway, if it was still there I'd go back in a second.


And the follow-up: http://damienkatz.net/2005/01/formula-engine-response.html

Last but not least the space vs time dilemma :
Many computation problems can be thought of as a time vs. space issue, and the new engine by design uses a lot more memory. My new engine would have never, ever worked back when this stuff was first written, close to 20 years ago now.

Javascript in wonderland

I found an application of the eval function (inspired from google suggest dissected): I plan to eval the return of my XmlHttpRequests. Thus the server side can directly manipulate the javascript objects (a mixture of different DOMs, the usual cross-browser patois) without much infrastructure.

This may prove useful in such an endeavour.

I like eating oysters, sushis and steak tartare but not that!

As I was trying to keep up with xml-dev I came across that:
The circus sideshow is the source of the word geek, “a performer who engaged in bizarre acts, such as biting the head off a live chicken.”

Javascript: the most ill-considered language

I tend to be a server guy but Google recently demoed that smart web ui are feasible (GMail, Google suggest). So I started to seriously study Ecmascript (btw, the spec is verbose and overcomplicated) to realize that it's quite an elegant dynamic language.

Key Features:

• Closures and anonymous functions.
• Prototype-based inheritance (and the ability to dynamically extend the ancestor). (Most of the direct applications are ruined by the DOM implementation offered by MSIE).
  
• Objects are maps from strings to objects/cardinal/undefined/null values. a.b is syntaxic sugar for a["b"].
• Builtin regex support (à la Perl 5).
• Variable arguments list (each function has a builtin variable (arguments), the named parameters are just syntaxic sugar around arguments)
• reflexivity/introspection: one can iterate through an object's members and one can dynamically generate code from strings (see the Function constructor) or evaluate strings (I don't know whether this is really useful beyond writing things like an ecmascript console).