Quartam - developing thoughts

Revolution, Snow Leopard and AppleEvent handlers

2009-10-25T22:18:00.000-07:00

As you know, Macs have always sported a rather different operating system - in fact, MacOSX is quite good at hiding its powerful UNIX underpinnings from the average user, while still offering its full power to the more advanced computer user. But tossing out the old brittle 'cooperative multi-tasking' MacOS Classic, and swapping in the modern, robust NeXtStep with a new coat of paint, required that the Apple developers came up with a whole compatibility layer, named Carbon.

And one of the things that Carbon brought with it, was the system of Apple Events - added in System 7.0, this new type of event allowed Mac applicatiosn to talk to one another. Later, these Apple Events formed the underpinning of AppleScript, the system-wide scripting mechanism that is widely used for automating processes (and in turn, underpins the Automator tasks that allow you to point-and-click automation workflows in MacOSX).

What exactly is an Apple Event? An AppleEvent has a generic Class and Id, as well as associated data - and our rev stacks can handle these events by implementing an 'appleEvent' handler in our (stack) script. Alright, but why should I care as revDeveloper? Because if you want to write a decent Mac application, you had better implement the 'core' events. These are apple events of class 'aevt' and have an id of 'oapp' (open application), 'odoc' (open document), 'pdoc' (print document) or 'quit' (exit application).

Now, the revEngine is kind enough to handle the 'oapp' and 'quit' events for us, translating them into built-in events for us to handle, So we can concentrate on 'odoc' and 'pdoc' - and in fact, we only need to bother with these if we have some sort of 'editor' application. Of course, the Quartam Reports Layout Builder is exactly such an application. So I implemented a simple handler in my stack:

on appleEvent pClass, pId
  if pClass is "aevt" and pId is "odoc" then
    -- get the associated data
    request appleEvent data
    put it into tFilePath
    -- now handle opening the file somewhere else
    OpenFile tFilePath
  else
    -- let the revEngine handle other events
    pass appleEvent
  end if
end appleEvent

However, with the release of Snow Leopard, the format of the associated data appears to have changed rather dramatically. In previous releases, we would get a file path that we could use directly in file processing. For instance, your 'OpenFile' handler could look something like this:

on OpenFile pFilePath
  put URL ("binfile:" & pFilePath into tBinaryData
  -- go ahead and parse the content of the file
end OpenFile

For Snow Leopard, the good engineers at Apple have decided to change the format and where a file path from an 'odoc' event used to look something like "/My Big Project/Layouts/My First Layout.qrl", it now looks something like "file://localhost/My%20Big%20Project/Layouts/My%20First%20Layout.qrl" - presumabl, they're paving the way for other protocls than "file://" in the future, but this change has left our apps in the dust. I'm sure they were kind enough to update the Cocoa framework to translate this automatically, but what about us who don't drink the Objective-C Kool-Aid?

Well, the '%20' substitute for the space character, clued me in that there was some sort of URL encoding going on. So after a bit of fiddling, I came up with the following workaround for this prickly problem:

on appleEvent pCLass, pId
  if pClass is "aevt" and pId is "odoc" then
    -- get the associated data
    request appleEvent data
    put NormalizedPath(it) into tFilePath
    -- now handle opening the file somewhere else
    OpenFile tFilePath
  else
    -- let the revEngine handle other events
    pass appleEvent
  end if
end appleEvent

function NormalizedPath pFilePath
  put pFilePath into tNormalizedPath
  -- workaround change in Snow Leopard
  if char 1 to 7 of pFilePath is "file://" then
    set the itemDelimiter to slash
    delete item 1 to 3 of pFilePath -- remove "file://localhost" from front
    repeat for each item pFilePart in pFilePath
      put slash & urlDecode(tFilePart) after tNormalizedPath
    end repeat
  end if
  return tNormalizedPath
end NormalizedPath

Splitting off the NormalizedPath function means I can reuse it for the 'pdoc' Apple Event, if I ever were to support that. Plus, I can now add that to my 'generic' library that I share among all my applications. Anyway, I hope this blog post is of help to some fellow revDeveloper baffled by this problem.

Repeat loops, dialog boxes and aborting

2009-10-19T22:19:00.000-07:00

It's one of those things that happen to all revolution developers at one point: you have written a repeat loop, inserted some 'answer' dialogs to figure out the problem, only to discover you're stuck and can't abort the loop because the dialog box is in the way. The only way out is killing the process, which has as downside that you've lost all changes to your stack ince the last Save.

After you've been bitten once, you'll probably adopt the habit of inserting an escape plan in your loops. At the same time, you ought to prevent problems in your shipping code with these escape routes, but more on that later - a first escape route may look something like this:


repeat forever 
  add 1 to theCounter 
  answer theCounter 
  -- next block allows escape 
  if the cantAbort of this stack is false and the shiftKey is down then 
    answer "Are you sure you want to exit the loop after running" && theCounter && "times?" with "Continue" or "Exit" 
    if it is "Exit" then exit repeat 
  end if 
end repeat

The cantAbort property of a stack determines whether or not you can abort in the first place (something which you really ought to turn on in standalones) and there's a checkbox on the stack inspector so it's quite convenient.

Another option is to move that block of code into a separate handler at the stack level


on CheckForAbort pCounter 
  if the cantAbort of this stack is false and the shiftKey is down then 
    answer "Are you sure you want to abort execution of" && pInfo && "?" with "Continue" or "Exit" 
    if it is "Exit" then exit to top 
  end if 
end CheckForAbort

and then add a call to that handler in your loop


repeat forever 
  add 1 to theCounter 
  answer theCounter 
  CheckForAbort "TightLoop-" & theCounter 
end repeat

The downside of the second approach is that any cleanup code that comes after the repeat won't be called. Of course you can also rely on try-throw-catch exception handling, but some people find this awkward.

So just for completion, here's how you'd allow escape with cleanup via exception handling; first change the CheckForAbort handler to


on CheckForAbort pInfo 
  if the cantAbort of this stack is false and the shiftKey is down then 
    answer "Are you sure you want to abort execution of" && pInfo && "?" with "Continue" or "Exit" 
    if it is "Exit" then throw "Aborting execution of" && pInfo 
  end if 
end CheckForAbort

and then modify the script with the loop so that it resembles the following


try 
  repeat forever 
    add 1 to theCounter 
    answer theCounter 
    CheckForAbort "TightLoop-" & theCounter 
  end repeat 
catch tError 
  answer error tError 
finally 
  -- do your cleanup here 
  --> it will be called whether or not something throws an error 
end try

Hopefully, this will be of use to you at one point or another. Make sure to check out these entries in the documentation for more information about aborting running scripts: cantAbort stack property, allowInterrupts global property, interrupt function and of course the try-throw-catch triade for exception handling. Use them wisely, and provide your users with a safer envronment to work in...

Quartam Reports Webinar

2009-10-04T08:00:00.000-07:00

As announced in the revUp 79 newsletter for revAfficionados, I'll be hosting a webinar on Quartam Reports, sponsored by the revSelect third-party extension program.

What can you expect to see?
- a few slides to explain how Quartam Reports can help you revDevelopers
- some examples of what you can achieve with Quartam Reports
- a brisk walkthrough creating a report for an example application
- time for questions and answers at the end

Click here to register and join us on October 6, 2009 at 7pm BST (8pm for most of Europe, 2pm Eastern for US viewers) - if you can't make it, you can always watch the recording a few days later. I'll post the download link once available.

RunRevLive'09 Slides and Example Code

2009-10-04T07:54:00.000-07:00

Just a month ago, RunRev held their successful RunRevLive'09 conference in Edinburgh.

As I've blogged before, I had the honour of presenting on three topics:
- 'Working with Java Classes'
- 'Desktop Databases with SQLite'
- 'Basic Reports & Output'

By popular demand, I've made the slides and example code for these sessions available in the Downloads section on the quartam.com website.

Presenting at RunRevLive'09

2009-08-08T01:32:00.000-07:00

Edinburgh is the hometown of Runtime Revolution Ltd, the guys behind Revolution - and the scene of this year's RunRevLive conference. After the huge success of last year's conference in Las Vegas, it has the makings of yet aother groundbreaking conference, focusing on the revWeb browser plug-in, the new product line-up (revMedia for free, revStudio and revEnterprise for extremely affordable prices) and the unveiling of revServer (the engine behind On-Rev).

When the crew asked me to present at this conference, I jumped at the chance to not just be there as one of the many attendees, but share my experiences with the rest of the community - as I have done for years on the use-revolution mailing list and the official forums. After submitting proposals, I got the green light for three presentations: 'Working with Java Classes', 'Desktop Databases with SQLite' and 'Basic Reports & Output.'

'Working with Java Classes' (Day Zero) delves into the various ways Revolution applications can interact with Java classes: a half-hour rollercoaster ride along shell commands, process comunication, socket communication, web services, message queues and externals.

'Desktop Databases with SQLite' (Day One) will take you on a trip through a straightforward desktop application where the data is stored in an SQLite database. By the end, you should have a pretty good idea how to quickly develop a database front-end with revStudio or revEnterprise.

'Basic Reports & Output' (Day One) will use the same desktop application to demonstrate various ways of reporting: generating HTML and RTF documents, using Excel as reporting vehicle in multiple ways, sending stuff to the printer using the built-in commands, and (obviously) how you ca make your life easier with Quartam Reports and Quartam PDF Library for Revolution.

I'm looking forward to seeing you all at the conference, both familiar and new faces - there are few things better than finally meeting someone you've only known through exchanging emails, or going for drinks with someone you only get to see via these get-togethers. Plenty of good stuff, and no jet-lag for me as it's only a hop accross the channel :-)

revMedia 4 - a Revolution on the Web

2009-07-22T12:33:00.000-07:00

First announced last year at the runrevlive'08 conference in Las Vegas, the RunRev team has unveiled the first public alpha of their revWeb browser plug-in - the easiest way to create RIAs (Rich Internet Applications) for use on Mac, Windows and Linux. [click here to read the press release]

And to top it off, the revMedia toolkit will be absolutely free. No longer do you have to cobble together an AJAX-based RIA using JavaScript in the browser and PHP or something else on the back-end; you can stop wondering why the Flash designer tool just doesn't think like you and me; gone are the days of pondering if Microsoft is going to cripple Silverlight on other platforms; and you don't even have to place bets on whether or not JavaFX is really such a splendid idea from server-focused Sun (the beleaguered company that is soon-to-be-gobbled-up-by-Oracle, if you're not keeping tabs on that platform).

This is it: start of with revMedia, and deploy to the web; move up to revStudio when you need to build desktop applications that are native for each platform and don't require a 50 MB runtime download; and move up again to revEnterprise when you need Oracle or SSL; and when you need easy hosting that uses the exact same language to create dynamic websites, On-Rev is your platform of choice.

To be frank, I've always expressed my dismay regarding browsers as a deployment platform for 'real' business applications. Maybe if XUL had taken off, building a feature-rich application running inside a browser would have made more sense. But including miles and miles of JavaScript to try and mimick a desktop app, that was clearly an impressive workaround, but still a hobbled experience.

So I'm glad to see that the Revolution has hit the web, and we'll see a renaissance of good ol' HyperCard: easy to program and easy to run. Keep up the good work, RunRev team!

Another Batch of New Items on my Bookshelf

2009-05-23T02:15:00.000-07:00

Packt Publishing Ltd is celebrating its 5th Anniversay - and I couldn't resist their special deal of 5 books for 75 euros. So my book collection got expanded with the following titles.

Service Oriented Architecture with Java was the first book that caught my eye. It gives a broad overview of why SOA (Service Oriented Architecture) is a good approach to developing new and combining existing applications. It also does a good job explaining the difference between tradition EAI (Enterprise Application Integration) and SOA, and why using an ESB (Enterprise Service Bus) is a good idea to assemble all the parts.
Having finished this book the dame day as it arrived, I have to say I liked the content, but was a little confused by some of the sentence constructs; it doesn't help when both the authors and the reviewer are non-native English speakers; I had it a little easier since I worked with developers from India in a not-too-distant past. Even though a technical book doesn't have to read like poetry, an editor should prevent from adding to the complexity of the material.

Service Oriented Java Business Integration was the logical next item, as JBI is one of those items I have a particular interest in. Even though this book is centered around Apache ServiceMix, I'm sure I'll be able to apply its principles to the alternative Glassfish OpenESB open-source project backed by Sun. Especially when I combine its contents with what I learned from the book Building SOA-Based Composite Applications Using NetBeans IDE 6 that I picked up last year.

Java EE 5 Development with NetBeans 6 continues the theme of my desire to learn more about Java EE development with NetBeans and Glassfish. Currently about a third into this book, I find it a good companion to the book Java EE 5 Development using GlassFish Application Server by the same author, which I also picked up last year - naturally, there is some overlap, but I have the memory of a goldfish and the author really does a good job of explaining things.

EJB 3 Developer Guide wraps up the enterprise-oriented book tour. Packed with practical examples, it gets straight to business. When I want a more architectural point-of-view, I can always refer back to the book EJB 3 in Action, published by Manning, which is three times the size but also contains more of the theory and differences between EJB 3 and older versions - and how the introduction of Java EE 5 really did simplify development a lot.

Swing Extreme Testing may seem like the odd-one-out, but what's the use of building an enterprise application back-end, if no one can see the contents? Having built a number of Swing-based front-ends, I can attest it takes time to get it "right" - and I'm sure I'm still doing things wrong. I sure wish someone would publish a book that explains best practices for Swing user interface development like Effective Java does for the Java language.
But I digress. While I've gradually converted to using JUnit for writing unit tests for the classes that make up the domain model, I still have to decide on a framework for testing the user interface. Once I've worked my way through this book, I'll be sure to check out FEST (Fixtures for Easy Software Testing) as the online articles I've read are quite favorable to this framework.

Ah, so much to read, so many experiments to conduct - and only so little time...

Vive la Revolution!

2009-04-16T11:53:00.000-07:00

It has been a busy month of April at the Runtime Revolution HQ - last week we witnessed the release of Revolution 3.5, with its data grid and behavior scripting, and this week they've announced the On-Rev web hosting initiative.

Since the unveiling of the RunRev web strategy at the runrevlive '08 conference, last year in Las Vegas, Rev-afficionados around the globe have been eagerly anticipating the day where they can do away with the mix-and-match (or should that be 'mismatch'?) of technologies needed to build modern, Internet-enabled applications.
With customers and end-users requesting applications that work on desktops and web-browsers alike, developers have been forced to use combinations of JavaScript, Flash, .NET, Java and a myriad of frameworks to deliver solutions where not all features might have been fully implemented accross the different client interfaces.

With the Revolution of the Future, developers will finally be able to build those same solutions with a comprehensive technology stack based on one language, and have it work as a desktop application or in a web browser, backed by business logic with database access on the server-side.
Java promised us this 15 years ago, and then kinda-sorta forgot about this promise. Granted, Java SE 6u10 finally fixed the Applets experience, and Java EE 5 definitely simplified server-side development; but in their panic to provide an alternative to Flash, they produced JavaFX with a new scripting language that doesn't even work like Java.

In short, I think the RunRev team has a winner on their hands - and I am definitely looking forward to putting these new Revolution technologies to good use.

Behavior on the Grid

2009-03-26T14:38:00.000-07:00

Today, the good people of Runtime Revolution Ltd. presented an impressive webinar, showcasing the brand new Data Grid control that is a salivating new feature of Revolution 3.5 - in fact, this new control has given us a lot more than what most people would want from a table control. You can setup everything from a straightforward table with multiple alignments, to a spectacular form with dynamically resizing rows containing arbitrary controls with judicious use of template groups.

This crown jewel was developed using the other new big technological addition to Revolution: behaviors. This allows you to write a script once and apply it to several other controls at once - and when you update the original behavior script, all those controls adopt the change in behavior automatically.
Of course, if you're used to object-oriented programming, this sounds like simple inheritance. The xCard paradigm, pioneered over 20 years ago by Apple's HyperCard is traditionally object-based but not fully object-oriented; there's a limited set of built-in controls and you can 'specialize' these by adding a script.
Another typical OO design pattern, Chain of Responsibility, was the basis of the xCard message path, which allows developers to place handlers for events, command and function calls in a central place - if you needed to know where the event originated, you could use 'the target' property to work your magic from there.

Strictly speaking this was enough to build something like the Data Grid in the past, but the new 'behavior' feature makes it a lot easier. The 'me' object points to the 'target' rather than the button that contains the 'behavior' script - so we no longer have to subject ourselves to 'long id' shenanigans to make sure we're modifiying the right controls.
Experiments with the new 'behavior' scripting methods have me pondering how I can adopt this for all my Revolution projects and which controls I can rebuild and put together in a single library for reuse - and perhaps for others to use. Ah, if only there was a function to conjure a Time-Turner so I could do everything I want to do but fail to find the time for...

The 15 Minute Fix

2009-02-28T10:39:00.000-08:00

Every once in a while, you hear the infamous words "That should only take 15 minutes to fix" - often spoken by someone who isn't a professional software developer. While it is true that a number of bugs can be rectified rather quickly - think: typo or simple inversion of logic - the change in the source code is only a tiny part of the process.

At my day-job, we have to pay extreme attention to the accurate workings of our software. As we cater to the healthcare indsutry, the lives of patients may well depend on our software. The physicians need acuurate data to apply the best treatment, so it is our duty that we correctly handle all the input coming into our laboratory informaton system, as well as the output we produce in the form of reports or data exchange with the general hospital system.

This means we follow a strict procedure for every modification to the source code: analysis -> analysis review -> code -> code review -> unit test -> integration test -> documentation + localisation -> final review. Exhaustive test plans are executed at every release to ensure that the software is reliable and that one change doesn't have a hidden impact on another part of the system. And that's something which simply can't be done in a quarter of an hour.

Even then, you can never be sure that your program will doexectly what it's supposed to do. There are many internal and external variables at play - and even if a computer is supposed to be a deterministic system, where the exact same actions should have the exact same result, errors do occur that are sometimes hard to figure out. Computer software is a composition of many layers - hardware, operating system, frameworks, libraries - most of which are outside of our control.

Yet we all rely on technology and the building blocks we have, to build new functionality, patch existing code and sometimes make radical changes. And we hope that the person who built that underlying layer, is at least as smart as we are, and caught all the mistakes before that layer came to us for further use. Looking at the giant software companies' bug lists may leave you in a bit of a shock when you see thousands upon thousands of entries, some lingering for a decade.

Is it all gloom and despair though? Definitely not - there are plenty of good practices we as developers can and should apply. Where I used to only care about producing the code for the features, I now take the time to write tests for my code, and run my libraries and applications through a battery of manual tests before releasing them into the wild. That sure prevents a lot of frustration for testers and myself, yet even with all that care, sme things are bound to pop up in the field.

A quick internal build for test purposes may only take 15 minutes - but a real solution, fully tested and vetted, that can't be done in such a timeframe.

In memoriam: Eric Chatonet

2009-01-18T07:48:00.000-08:00

Today, as I was catching up with emails on the use-revolution mailing list, when I came accross a post La communauté Revolution est en deuil that informed the members of how Eric Chatonet had passed away.

Like many others, this news has left me with a deep sadness - for we, the members of the Revolution community, have all lost in Eric an extraordinary man - intelligent, generous, always helpful and armed with a wonderful sense of humour. I fondly remember meeting him in person at the Revolution Conference in Malta in 2006, exchanging ideas and experiences, and smoking cigarettes with him, Malte Brill, and Tariel Gogoberidze on the balcony of the hotel.

My condoleances and thoughts are with his family. Having unexpectedly lost my father 4 years ago, I have an idea of how his son must be feeling right now. May he rest in peace, with a glass of wine and a cigarette, enjoying the afterlife to its fullest. He certainly earned it.

Revolution newsletter articles

2009-01-03T23:17:00.000-08:00

One of the best things about Revolution is its strong-knit community - whether it's on the mailing list or on the forums, when you post a question there's bound to come an answer from one of the many users that have faced a similar problem. And soon enough, the newbies come of age and start replying to questions as well. This way, the good advice keeps getting spread over an ever-growing group of users.

Another important resource is the Revolution newsletter, where both the company's engineers and a variety of writers from the uer community share their knowledge and their solutions for challenges encountered while developing their applications. I just concluded a series of articles on using the 'merge' function, which got good reader feedback.

The 'merge' function is one of those extremely helpful weapons in the Revolution armoury, which every developer should know about and use, as it has many applications and can save you a lot of time. It goes through a text, and evaluates expressions that you've put in between [[...]] double square brackets, and executes statements that you've put in between <?...?> processing instruction brackets; and when it's done, it hands you back the end result.

This makes it an ideal tool for assembling HTML pages, RTF documents, XML files and other text-based file formats. But you can also use it as a preprocessor for templates, ranging from SQL queries to VBScript or AppleScript. One particular combination is to use Microsoft Word as a reporting system in two ways: merging an RTF template into a document, and then merging the necessary script to automate Word and print the document for you.

Here are links to the individual articles:
- The Power of Merge (revUp | Issue 55 | August 18th, 2008)
- The Word of Merge - part 1 (revUp | Issue 61 | November 20th, 2008)
- The Word of Merge - part 2 (revUp | Issue 62 | December 22nd, 2008)

Enjoy the articles and Revolution! And if you still have to make a New Year's resolution, make it something along the lines of 'I want to learn' - as education is the only path that leads to prosperity...

Future-proofing your Revolution scripts

2008-11-26T12:03:00.000-08:00

While I'm still not giving out details on the new features or release date for Quartam PDF Library 1.1, I would like to share some insights that I gained as part of my efforts on producing this new version. Back in September, the team of Runtime Revolution shipped version 3.0 of its cross-platform development tool Revolution.

Overall, Revolution 3.0 is an impressive release, with a revamped script editor, gradients, nested arrays and much-improved out-of-the-box experience thanks to the Start Center and Resource Center. One of the items that was also introduced, but not mentioned in the press release, was the new 'byte' chunk type.

If you're wondering what it's good for or why you would want to use it instead of the good old 'character' chunk type, then allow me to explain the underlying reason for its introduction. Back in the HyperCard days, not much attention was given to languages that didn't fall neatly in the ASCII-domain, based on the English alphabet, where one character takes up a single byte and thus there are 256 possible characters (a number of which are control characters that can't even be displayed on screen).

Naturally, this isn't quite enough room for a couple of thousand Chinese or Japanese characters, and that's where Unicode comes into play. This is a set of standards that govern how this much larger number of characters can be stored and should be interpreted. The UTF-8 standard still relies on single bytes as its main storage system, but uses special bit-settings to determine if the next character is a single byte or more than one byte.

My other favorite cross-platform technology Java embraced Unicode from the very first day, which made perfect sense given its goal of "write once, run anywhere" global software. And to make this easier, if less memory-efficient for those circumstances where you only have to deal with the ASCII characters, it uses UTF-16 everywhere.

When Revolution 2.0 saw the daylight, it introduced support for Unicode text entry and manipulation. Rather than jumping on the UTF-16 bandwagon, the engineers decided to implement a more flexible system that would use plain-old ASCII for everyday operations, while allowing the developer to use UTF-16 only when necessary.

While the implementation could still use some love and care, Revolution's technology director Mark Waddingham has big plans for it and wants to evolve to a system that is far less painful than anything else out there, but as resource-efficient as the current implementation. Which means that in the future, Revolution developers will be able to use the 'character', 'word', 'item' and 'line' chunks without having to care about the underlying encoding - the engine will know what constitutes a word or a sentence in the language of that piece of text and will take care of collation and all the gruesome details of Unicode.

Traditionally, the one-byte-is-one-character paradigm of xCard meant that developers could use the 'character' keyword, along with the 'charToNum' and 'numToChar' functions, to manipulate data at the byte-level. But with this equivalence fading away at some point in the future, the new 'byte' chunk type is our saviour!

Quartam PDF Library reads PNG and JPEG image files as byte streams, extracting information about the image height and width, bit depth and other binary-encoded information. To ensure that this and other binary-reading code will keep working correctly in the future, I've decided to make the necessary changes in version 1.1 to use the 'byte' chunk type rather than the 'character' chunk type.

While this means that the next version will require developers have Revolution 3.0 or higher, I feel this is a fair trade-off. In my experience, the new Revolution version performs well with less problems and quirks than ever. And if I compare my glacial speed of development with their feature-packed release momentum, I'm sure they will be shipping their next version before I do ;-)

Just in case you'd like to know how I updated and thus future-proofed my code, here are some pointers:
- replace 'open file theFilePath for read' with 'open file theFilePath for binary read'
- replace 'open file theFilePath for write' with 'open file theFilePath for binary write'
- replace 'length(theBinaryVariable)' / 'the number of chars in theBinaryVariable' with 'the number of bytes in theBinaryVariable'
- replace 'char x to y of theBinaryVariable' with 'byte x to y of theBinaryVariable'
- replace 'charToNum(char x of theBinaryVariable)' with 'byteToNum(byte x of theBinaryVariable)'
- replace 'numToChar(theNumber)' with 'numToByte(theNumber)'

That's it - no other changes required! The modification was straightforward and consistent, and everything works just fine. I know that my code will continue to work in future versions, and I can enjoy the same linear speed that I have now with the 'character' chunk type once that part is overhauled for Unicode embracing.

If only all requested or necessary changes were so easy to implement...

An Apparition

2008-11-11T01:32:00.000-08:00

If you have been wondering why it's been so quiet here lately, the answer is simple: a lot of work piled up, there was release pressure and the band that I sing in had its first gig - which ate up a lot of hours and energy. But things are slowly getting back to normal, and I'll have two weeks off from the day-job very soon - time which I'm going to spend relaxing and catching up on items that languished while I was busy. This blog is one of those bits that deserve attention. So let me start by finishing a post that I started to write back in August: 'The Programmer Syndrome'

The Programmer Syndrome

2008-08-07T10:43:00.000-07:00

No, it's not as if all developers exhibit the same behaviours or nervous tics - but a lot of us tend to suffer from two less-than-stellar character traits: the "Not Invented Here" syndrome and its nefarious cousin "I've always done it this way". Not exactly what you're looking for in an industry where there's a continuing debate about code reuse.

Of course it is a lot more fun to claim you're at the forefront of technology and innovation, but half of the time we're just rehashing the same technology - message queues are about as old as UN*X and let's not even talk about the Network Computer brouha. And sometimes this running in circles makes us blind and turn us into snooty stubborn time-wasters. If you're wondering what triggered this post, well twice this week have I been confronted with this near-pathological behaviour.

The first occasion was reading one colleague's analysis for a new logging system to better track changes at the record level. Obviously an important feature that should be done right, and in this case the idea was to extend the logging features currently present in the application - thumbs up in the reuse department. What struck me as odd about it, was that he didn't want to adopt the auditing system that was added to the underlying database system in a not too distant past. What really irked me about it, was that he didn't even mention it and didn't bother to express a good reason as to why we shouldn't use the built-in mechanism.

The second occasion was when a colleague started to explain how they solved a certain asynchronous data processing problem at his previous job, in what we can euphemistically call a 1980's solution: have an external process poll the database every minute. And he insisted that this was the only robust way to do it, and it worked fast because they had hundreds of these batch processes running on an IBM RS-6000. As the problem unfolded, he had to add more and more checks and balances to counteract concurrent modifications by different processes. When I suggested that for this particular situation a message queue might be more appropriate, he dismissed it as costly and overcomplicated. I don't know about you, but message queues are generally built by very smart people who have thought through the different corner cases, and I'll happily follow their path.

Naturally, as we have creative minds (and no, it's not because we express ourselves through code rather than music or painting that we shouldn't be considered "creative") we seek challenges and aim for the sky when we decide not to fix the code but rewrite it - paraphrasing Captain Jack Sparrow: "a bigger boat, a better boat, that boat." And it is extremely important to deliver something that we feel proud of, which is what drives us to work insane hours and then some more, just to get it done by this impossible deadline with more features than were in the requirements.

But aren't we sometimes overdoing it by completely ripping something apart and replacing it with an alternative that lives up to our current standards? None of us were born with programming experience, we all had to learn through "Hello, world!" in a dozen programming languages, and if all is right, we're still learning new things every day. Yet with an ever-growing to do-list and much longer to research-list, I prefer not to duplicate efforts. Which is why open source libraries, with the right licensing policy, are a great blessing.

Steering back to the topic, I feel this interview with Joshua Bloch is a must-read. Joshua Bloch is the author of Effective Java, considered by many to be among the best books on how to use the Java programming language. Here's the single-best quote from that interview: "In order to stay sane, most developers have a can-do attitude, and some take it too far. They say to themselves, 'Yes, there's a library, but I can do better.' Maybe you can, but that doesn't mean you should."

Mind you, when I recently rebuilt a monitoring tool, I did scrap nearly 90% of the existing code and replaced it with new code that made as much use as possible of new features added in recent versions of Java. So please do not read the above as a mindless "holier-than-thou" rant about short-sighted colleagues. What I really hope, is that you remember to keep an open mind, learn about what's waiting for you to use in your applications - either in the core of your development libraries or in what's available from the outside world. And if you do roll your own, at least make a list of the arguments pro and contra.

Service-Orientation vs. Object-Orientation

2008-07-31T10:27:00.000-07:00

What better way to fill an hour-long lunch-break than by reading up on various websites? Some people like to play cards and others take a stroll around the village. Lots of people leave breadcrumbs in their keybpoard as they read their private emails, but my daily ritual includes trips to MacWorld, MacUser, OreillyNet, Java.Net, JavaWorld and JavaLobby.

Today I bumped into this fresh post by Masoud Kalali on JavaLobby: Service-Orientation vs. Object-Orientation: Understanding the Impedance Mismatch. Even if your language of choice is Revolution and therefore not object-oriented (even if it's object-based, but we'll leave that for some other time) you'll still want to head over to the site and read the article. After all, a smart programmer keeps his horizons broad so he knows which is the right tool for a particular job, right?

Object-oriented programming has long established itself as a solid software development paradigm, improving on procedural programming by offering encaspulation, inheritance and polymorphism. Service-oriented architecture may still be surrounded by a lot of buzzwords,(often referred to as the SOA ALphabet Soup) but has clearly shown the way to seamless interoperability, regardless of development platform or operating system.

Both OOP and SOA promote reuse. And as more and more business models, developed using an object-oriented language like Java, need to expose their logic as services, it naturally becomes important to do it correctly: rather than just exposing all individually available procedures and functions as web services, you should take a step back and think very hard about exactly what services you seek to offer the outside world.

The innards of your system may be as tightly- or loosely-coupled as you prefer, the truth is that there's a lot of methods in your classes that you're only going to use internally. Services are better defined in terms of business processes, anyway: your 'order entry' service would be wise to offer both a high-level 'do it all in one go' service where an entire order can be created using a single XML structure that includes master and detail information, and a fine-grained 'do just one thing at a time' API to create/read/update/delete one part at a time.

So setting up your services becomes a matter of defining the sensible parts of a workflow, starting with a small area of your application and expanding as it makes sense, based on the feedback of the users of your services - which can be colleagues in the IT-department or external partners. In such an approach, services unsurprisingly have a lot in common with 'task oriented' user interfaces, where the user is guided through the different steps of the process - not in the sometimes belittling way of wizards, but as part of a way to empower the user by concentrating on his or her job.

Information Technology in general and software development in particular are in so many ways still in their infancy. And as we're growing up, we're relearning things from the past, re-inventing how combining existing and sometimes considered-obsolete technologies delivers new value and makes our applications more powerful while easier to use. It feels great to take part in all this...

Message in a Bottle

2008-07-22T11:56:00.000-07:00

Most people who have spent some time with me, are convinced that I am musically stuck in the eighties: The Cure, Siouxsie and the Banshees, The Sisters of Mercy and all those happy-sounding bands. But don't let the title of this post lead you to believe I'm talking about The Police. No, I'm talking about enterprise integration in the form of message queues.

In my last post, I talked about how interesting it would be if we could combine the easy-to-master power of cross-platform desktop software development tool Revolution with the heavy-weight champion in cross-platform development: Java. Well, the first way we can make these two technologies work together and play into one another's strengths, is by means of message queues.

Back in the old days, most application integration consisted of exchanging files: application A exported data into a file, and then application B would import the data from that file, usually at the click of two buttons. Convenient, even if you had to copy them to and from floppy disks. In the multi-user time-sharing Unix world, pipes have traditionally played an important role in data exchange, as one application connected its output pipe to the other application's input pipe and vice versa, and just wrote data to one another.

And of course, in the golden age of internetworked computers, you're bound to have enjoyed the miracles of TCP/IP and other networking protocols, as you surfed the web, exchanged instant messages and legally downloaded the occasional file. All thanks to the wonderful world of sockets that connected an application on your computer with an application running on another computer somewhere out there.

Sockets are also often used to let two applications talk to one another while running on the same computer - does the word 'localhost' ring a bell? The common theme in this type of information interchange is that both sides agree on the data format and talk to one another directly in one form or another. Now while that's pretty easy to put together as long as the two parties can come to an agreement, it gets complicated as you have to talk to more and more applications.

Think about it: if two apps talk to one another, you have one connection to develop; when a third app joins the party, two extra connections need to be made; a fourth app means adding three more to the mix. The mathematical formula is n x (n - 1) connections to interconnect n applications. And that's not such a strange scenario: nowadays, our applications can't sit there in their ivory towers - our users expect them to talk to one another seamlessly.

So, would you like to write an ever increasing number of connectors? Or would you prefer an approach that takes care of the plumbing? Enter message queues: think of them like a mass-mailing system for applications - you post a message to the queue and it will make sure that your message reaches all the applications that have declared their interest in receiving all or just certain types of messages. In this method, all you have to agree on is the message format and where it will be posted.

I'm sure you'll agree nothing is easier than speaking the same language and delegating the actual delivery of messages? Add to this the promise of delivering your messages to the applications that are hooked into the system - in order and exactly once! That's certainly a much better deal than people losing the USB-stick, deleting the email or forgetting to import those data exchange files, right? And how about this: when you change the data in one client application, you broadcast it via the message queue and all other clients pick up the message and refresh accordingly? Sounds good to me...

But enough theory, how can we do this in practice? The good news is that most Message Queue vendors have signed on to the Java Messaging System standard: JMS. Even better news is that in these days of open-source software development, we can pick up a solid implementation for free: Apache ActiveMQ - yes, from the makers of the server that's running most of the worldwide web. And the best news (not just for Revolution developers), is the STOMP project: a combination of a bridge and a standard protocol, which allows any socket-wielding application to talk to just about all JMS-enabled Message Queues.

You guessed it: the first way of combining Java and Revolution is using sockets to talk to a JMS-enabled Message Queue. Armed with the STOMP-specs and earlier experiments with socket communication, I put together a STOMP library in a few hours yesterday morning. Now don't rush over to the quartam.com website just yet, as it needs more testing and tweaking before it's ready for general use. But I can tell you that sending and receiving messages works like a treat. Yet another reason to add Revolution to your developer toolbox if you haven't done so already.

So where does the bottle come into this story? Well, I happily drank the rest of the bottle of dry white wine that I opened yesterday evening, while typing this post. Or maybe I was just trying to lure you in with the title of one of the most famous songs by The Police. Then again, wouldn't it be nice if all the messages we carefully wrote as a child at the beach, shoved in a coke bottle and threw into the sea, actually made it to their destinations?

More Items on my Bookshelf

2008-06-30T11:54:00.001-07:00

As a follow-up on my previous post, I have a confession to make. When I looked through my recent additions in Delicious Library, I realized that I had accidentally skipped one of my recent purchases. So in an effort to rectify that, here are some more items that recently found themselves added to my collection.

The item that I forgot to mention, was TCP/IP Sockets in Java. One of the tasks at my day-job is the maintenance of a monitoring service for diagnostics machines - also known as sample or specimen analyzers. The communication between our Laboratory Information System and these machines is of the utmost importance to our customers, and the laboratory staff need to be alerted when the analyzers fail to send their data because of a stalled translator service.
The monitoring system is basically divided in two parts: the service daemon which monitors communication, and the dashboard user interface that displays the status. Both of these are written in Java, enabling monitoring on multiple operating systems - the ubiquitous Windows workstations, as well as Mac, Linux, Solaris and other Unix-derivatives. The data exchange between these parts relies on multi-threaded socket communication, and that's why I bought this book, as I'm sure I'll need it when I go about rewriting portions of the engine to make it more scalable and alleviate the limitations that the current version is bumping into.

Which brings me to the next item on my bookshelf: Java Concurrency in Practice. As computers gain multiple cores and both operating systems and CPUs get ever smarter about dividing up the workload among the available resources, not to mention the fact that users don't like waiting around twiddling their thumbs while data is getting processed, it becomes more and more important to learn how to write multi-threaded applications.
Now Java was built from the start with multi-threading in mind. Over the years, the APIs have been improved, and Java 5 and Java 6 added classes that make concurrent programming a lot easier, shielding developers form the low-level plumbing needed to make it happen. And there's a lot more planned in Java 7 to help sorting and other tasks make better use of the processing powers offered by multi-core environments. This book gives you a lot better insight about the tricky little details of concurrency, explaining how processors, in an effort to maximize throughput, may shuffle instructions around in memory to optimize performance. If you're using Java and want to make optimal use of concurrency, this is a must-read.

The last item that I want to mention this time around, is Effective Java (2nd edition). Considered by many as the bible of properly using Java, this book was revised and updated for Java 6, exploring new design patterns and language idioms, showing the reader how to make the most of features ranging from generics to enums to annotations to autoboxing to (you guessed it) concurrency utilities.
As I'm spending more and more time with Java, I'm looking for a deeper understanding of the technology and the language, hoping to make my code clearer, more correct, more robust, and (fingers crossed) more reusable. Don't worry, I'm still using Revolution as often as I can - it's the language that I jump back to whenever I get a chance. It makes things so much easier and with the upcoming browser plug-in, I can avoid the un-fun of Java applets, AJAX, Flash and Silverlight.

But it is equally important to look around, learn from the available technologies and then pick the best tool for the job. Revolution is a wonderful solution for desktop applications that both need to look good and connect to databases and the internet. But when it comes to building highly-scalable multi-threaded applications, there's no replacement for Java. Ah, if only we could marry these two cross-platform technologies. Or maybe we can? That will have to wait for another post, however.

New Items on my Bookshelf

2008-06-23T11:43:00.000-07:00

One of the defining characteristics of Information Technology, is that it is constantly shifting, and that you need to spend a lot of time just to keep up with the topics that you focus on. Not to mention the pet projects that you hope you'll eventually get around to but have already bought some books on for that magical moment when have time to actually read them.

And maybe I should wait to buy these books until I have that copious free time needed to properly digest their contents, but hey, what better motivation to move things along than a growing stack of books that you convince yourself have to be read before the end of the summer? A little pressure never hurt anyone, right?

On with the show - what did I recently add to my collection?

The Definitive ANTLR Reference - if you've ever dreamt of building domain-specific languages, ANTLR is the tool to get if you're not already knee-deep in LEX and YACC. Now why on earth would you need that? Well, if you're building business applications, this sort of embedded scripting languages can make a world of difference when it comes to customizing the workflow of your application.

Granted, if your focus is exclusively on MacOS X, you're better off making your application OSA-scriptable, so that your users can interact with your application via AppleScript. Or go one step further, and embed Automator actions. But if you're not that lucky, and you need cross-platform scripting, ANTLR and the visual grammar development environment ANTLRWorks will make your life a heck of a lot easier - producing code that is actually readable, rather than the undecipherable state machine mess that you get from YACC.

And now that we're talking about MacOS X (ooh, there was a smooth transition to the next book) - I just got my copy of Cocoa Programming for MacOS X by Aaron Hillegass. The just-released third edition was updated for MacOS X Tiger and Leopard, including coverage of XCode 3, Objective-C 2, Core Data, the garbage collector and Core Animation.

While I also have a copy of the Wrox-book Beginning MacOS X Programming, this will be the one that gets me going with Cocoa (that's my story and I'm sticking to it!) as the last Mac-specific development I did was using Think Pascal and the first 5 books of the original Inside Mac series, back in the day when Macs used Motorola 680x0 processors and we were happy to get System 7.

The last book I want to mention is The Art of SQL. Now I may live and breathe databases but you can never learn enough tricks of the trade. In this book, the author aims to teach people who are no longer novices how to write good SQL code from the start and most importantly, to have a view of SQL code that goes beyond individual SQL statements.

Remember the days when developers managed to fit entire accounting applications, including the data, onto a set of floppy disks or (gasp, we will never fill that up) 10 megabyte hard disks, running in 128 kilobyte RAM or less? With the way database sizes are exploding nowadays, you need to plan ahead and employ a different strategy - so I'm definitely looking forward to getting more in-depth than ever.

And just in case you're wondering: no, I don't always cuddle up on the sofa with a mug of hot cocoa and this type of book. Whenever I get a chance, I'll read books by Raymond E. Feist, Tad Williams, David Eddings, Margaret Weis and Tracy Hickmann. Hmm, another stereotypical geek trait: fantasy and science fiction. Ah well, when the shoe fits :-)

UI Design Essentials

2008-05-25T12:23:00.001-07:00

My design skills are limited to stick figures - and even then, people will react "Is that a MacBook the guy is holding?" - "No, that's a chihuahua peeking out of her purse..." Nevertheless, as a commercial software developer, I need to somehow be both a programmer and a designer, at the same time.

And when you cater to the Mac market, you're talking about the platform where applications have to bleed coolness - often with ground-breaking user interfaces, like Delicious Library or Apple's iApps. Following the platform's interface guidelines is only half the work: your job is to provide an elegant user interface that conveys information in an efficient manner, interacting in a compelling way at the same level as your target user.

Granted, I make database front-ends for a living. The boring kind of applications: accounting, order processing, and all that happy fun stuff that involves storing data in and loading it back from a database, and providing reports and statistics so that the end users can do their job. In my time, I have seen plenty of applications that were built from a developers' point of view. Which means it's logical, in a way, though not necessarily matching the user's line of thinking.

If you're lucky, the team that built the thing in the first place, took the time to read up on human-computer interaction, and tried to learn from the other applications out there. And if you're really lucky, they had someone on their team smart enough to say: "It's not enough to have menus and windows and buttons, but we should make sure that all elements in our application work consistently, as this will cut down on user training and support calls."

But I didn't mean to step onto the soapbox here - I just wanted to point you over to this entry on the Theocacao website - a blog for Mac developers, written by Scott Stevenson, who also maintains the Cocoa Dev Central learning center. You can fetch the slides of his UI Design Essentials talk as well as a movie recording. It may take a while to download the 532MB QuickTime HD file, but it is well worth it.

He talks about the history of developers and designers in software development, and although he can't make you a designer in as short a timeframe as an hour, he does make excellent points and offers practical advice. Specific topics touched include: the basics of iterative design and usability testing, the use of whitespace and partitioning, correct labels and prompts, as well as fonts and language design, covering inspector palettes and icons in the process.

He also ran through a real application that someone was brave enough to submit, pointing out design flaws that turn this functionally excellent application into something users can get to work by themselves, but could be so much better and easier to use by making a number of tweaks. In the wrap-up, he mentions a number of 'model citizens' that we should look at. Some of the best bits came up during the Q&A session at the end, which is only available in the video recording, unfortunately.

As you wait for the download to make its way to your computer, you may also want to chase down these books:

Designing Interfaces by Jenifer Tidwell (O'Reilly)
About Face 3 by Alan Cooper, Robert Reimann and David Cronin (Wiley)

While the latter is a very theoretical book which goes through great lengths to match up the implementation and mental models of developers and users respectively, the first book has great tips on how to improve the user interface of your desktop as well as web applications, filled with screenshots and explanations in a very readable format.

Of course, there are other resources out there, but I'm not going to add much more to this post - instead, I would like to encourage you to go out and look at applications that you use every day, and write down what you find annoying and what you like about the way it interacts with you as a user. And the n try to repeat what thery do right, and avoid what they do wrong.

While Quartam Reports works the way it does, as it was modeled after the Report Builder that shipped with Foxpro, it's not going to stay that way forever. I've already been prototyping a complete overhaul for a while now, and hope to make it a reality for version 2.0 - balancing between the "let's just get it over with" mindset of a developer who has to develop 189 of those pesky things, and the mindset of someone who is perhaps less-seasoned in the raw developing process, but has a good idea of the end-product and how it should turn mere facts into empowering information.

In the meantime, there's plenty to learn and consider and tweak, as usual... Not to mention plenty of code to toss and rewrite... It just never ends, does it?

Revolution Live '08 - redefining the web

2008-05-14T11:26:00.000-07:00

Now that I'm back home, caught up on sleep a bit and am starting the happy-fun return of my internal body clock to the Central European Time Zone, it seemed like a good opportunity to blog about the announcements at the Revolution Live Conference.

The great news for Revolution customers around the globe, is that their web offerings are shaping up really well: a PHP-style server module for creating web applications, plus a web browser plug-in - talk about a slam-dunk by the Runrev team!

This is the perfect answer to Adobe's trying to bring Flash to the desktop: anyone can now build Internet-enabled applications without having to struggle with ActionScript and tools that were meant for designers. Not that designers are illogical people - if they were clueless about putting two and two together, they wouldn't be able to pull off that AJAX stuff.

Boy, am I glad I won't have to continue struggling with that HTML+CSS+JavaScript batter mix either, if I want to build a Rich Internet Application... Let's check how Revolution stacks up against all these technologies that are trying to win the next round of browser wars:

AJAX is an interesting use of existing technologies, but in the end it's just another way to stretch what a browser can do. The fact of the matter is: the browser needs updating for it to ever become a true universal application platform.
Flash started life as a way to animate vector graphics, and whatever people may tell you, that's still what it is - they don't even have real buttons, it's all simulated. Thank you, please don't come again.
JavaFX is an interesting idea, but suffers from one major flaw: it is not Java. Which means that Java developers have to learn a whole new thing just to be with the times. If they really wanted it to become popular, they would have just provided a great applet builder, not this monstrosity.
Silverlight is Microsoft's attempt to beat Adobe in the browser plug-in wars. So far, it doesn't really seem to be getting very far. Maybe around version 3.0 we can consider it a major force, but I'm sure that you'll have to update your Silverlight apps every single time the Redmond team decides to replace essential parts.

Some people may think that Revolution is focusing entirely on the multimedia market with this strategy, but they couldn't be further from the truth: this is the single largest opportunity in the history of Revolution to make it big in the world of Enterprise applications!

Of course, there will be plenty of multimedia Flash-like stuff built using this browser plug-in, and it should attract a whole new crowd of Revolution developers. But looking at the biz app developers now, Revolution is by far the most secure technology of the bunch: short of obfuscating your Javascript, your AJAX apps are wide-open for anyone to take apart and try to take advantage of.

The Revolution community can now deploy applications for those customers who want to see a browser user interface, and we won't even have to learn a new language. Likewise, the server module will serve as an application server gateway like we haven't had before.

And I can assure you that existing and future Quartam tools will help you get to the bottom of things: use the server module and Quartam PDF Library to dynamically generate documents for your web applications; and once Quartam Reports hits version 2.0, you'll be able to leverage this report generation tool on the browser platform as well.

Good times...

Website make-over

2008-05-04T05:03:00.000-07:00

After about 4 years of a design that was clean but not very modern, I decided to sit down and give my site a complete make-over. I had a pretty good idea of what I wanted it to look like, and in my hubris estimated I could do it in a day or two.

The original website design was done using Claris Home Page, a dinosaur even in the day that I picked it in 2004 as my tool for table-based layouting. But for the rather simple site I had in mind, it was the logical choice, given that I had last designed a website back in 1994, in the days when HoTMetaL Pro was considered a major step forwards.

My mindset is that of a developer, not a designer. Which means that I'm pretty good at straightforward HTML, and I can work with XML and the gory details of XSL transformations. But for some reason, my brain comes to a grinding halt when it is confronted with CSS. So I generally let the designer "do his thang" and integrate it with my XSLT file or AJAX routine. Which I write in a programmer's text editor, not some fancy tool like Dreamweaver.

However, for my own website I was going to get it right - and of course, it resulted in a lot of expletives and crying and pleading with every deity that could remotely help - not that I really expected the ancient Roman goddess of wisdom, Minerva, to be any good at CSS, but hey, it would have been cool if she had swooped by and fixed the problems - and I was getting desparate at that point.

Until I decided to put away my programmer's hat, and dug out my copy of Freeway Pro, which I had recently upgraded to version 5 anyway. Created by Softpress, it is aimed at visual designers who like working with Quark XPress, drawing graphic elements and filling them with content.

A long long time ago, in a galaxy far away, I was active in various student associations, where I invariably ended up layouting the association's magazine using PageMaker or RagTime. So after a lot of experimenting, unlearning and documentation-consulting, in these past four (*) days, I managed to completely revamp the quartam.com website.

The result is CSS-based, and my website no longer looks like something designed in the 20th century. There's one more section to redo as far as layout goes, and I still have to wrap up those elusive tutorials that I started back in 2006 - I'll let you know when those eggs hatch. Right now, I have to get back to preparing for runrevlive.08 - where I will be presenting the session on Advanced Databases.

(*) Four days, whereas I had planned two days. Great - just great. If my boss reads this, I'm sure he'll have a field day - according to him, you need to multiply a developer's time estimate by 2 and then you may get a more realistic timeframe. Don't you just hate it when the manager is right? Then again, he worked his way up from the coding trenches - which means he has a much better idea about software development than, say, a former bank director pretending to be a CEO in IT...

Thinking of an opening line

2008-04-04T12:04:00.000-07:00

Starting a blog is like trying to convince a girl that there's more to you than a pair of glasses, some ruffled brown hair and a strange grin. What exactly are you supposed to say?

Let's start with explaining what I hope to do here. There are lots of corporate blogs that are either filled by the managers, or their secretary copywriters. The good new for you, is that I am neither a manager, nor a secretary.

During the day I am a software engineer at MIPS Belgium - a leading provider of laboratory information management systems. At the job, I use a mixture of Progress OpenEdge, Java and -to a lesser extent- C/C++.

After hours, I use Revolution - one of the best-kept secrets in software development, it allows anyone with the gift of reason to quickly create an application by dragging buttons and fields onto a card and adding scripts to them. In an easy to understand English-like syntax, not some mystifying combination of dot-notation and enforced object-orientation.

My plan for this blog is to talk about the technology that I work with - the tools that I build and sell to fellow developers, little bits of code that I write to test a feature or just to satisfy my curiosity, but also the books that I read and try to glean information out of that will help me in my daily occupations.

Don't expect multiple posts per day - given my hectic schedule, it is bound to be more or less a once-a-week affair. But then again, I may enjoy writing entries that I will do it more often. You'll just have to wait and see...