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.
Saturday, February 28, 2009
Sunday, January 18, 2009
In memoriam: Eric Chatonet
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.
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.
Saturday, January 3, 2009
Revolution newsletter articles
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...
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...
Wednesday, November 26, 2008
Future-proofing your Revolution scripts
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...
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...
Subscribe to:
Posts (Atom)