I have started to use Mozilla Webrunner on my Mac: used in conjunction with Quicksilver, this is a neat way to start web sites as standalone sand-boxed applications. This does not replace tab browsing, of course, but is very useful for the applications you usually dock on your second monitor (or third one, if you are a real guru), like your continuous integration server dashboard or your web mail home page.
To have Quicksilver bootstrap Webrunner applications, simply store your profiles in a directory that you register as a custom catalog. And voila, you can launch your web applications with a few key strokes.
This is another way to reduce the latency between thinking about what the computer should do for you and have it actually do it. When you think at the zillions of cycles the computer wastes waiting for you, any tool, gadget or utility that helps minimizing this loss is to be lauded!
Sunday, September 30, 2007
Saturday, September 29, 2007
Agile In The Burbs?
In a recent post, my friend Alex commented on the complex art of managing employees in remote locations, which came at a time when I was thinking about the high toll of co-located teams.
My reflexion started a few weeks ago when I was reading a reader's letter in IEEE Spectrum's Forum. Commenting on a very complete coverage Spectrum just run on big cities and their challenges, the reader said:
My first reaction was: lucky man! Then my second thought was: why can not we all have such a life, a life where the distance to work does not put a toll on our lives and our environment?
So why do we rush to big cities? Because this is where the demand for IT workers is high: banks, public sector entities and private companies have a tendency to locate themselves downtown. Since they have a high need of software engineers, they act as a magnet for us geeks of all sorts.
But why do not we telecommute more? After all, this is a revolution that has been announced a long time ago and we now have the tools that would allow us to make it happen. Massively distributed open source communities have proven that this is a model that can work.
On the contrary, agile principles tell us that teams should be as co-located as possible, because of the millstone that distance puts on communication, whose efficiency is a major cause of success for software projects (and the lack thereof a major cause of failure). Industry luminaries and extensive discussions have made this point very clear.
Since housing madness only allows singles and dinkies to live downtown, the ones of us with a family are then forced to live in the burbs, far away from work and far away from the perfect commute the aforementioned reader says he experienced all his life.
Trying to accommodate the often conflicting requirements of agility, personal life and business is not a trivial task, but one that is certainly calling for a broader rethinking of the way our cities and workplaces are organized and located.
My reflexion started a few weeks ago when I was reading a reader's letter in IEEE Spectrum's Forum. Commenting on a very complete coverage Spectrum just run on big cities and their challenges, the reader said:
Why does modern society think that it’s entitled to expend all that energy, in whatever form, merely to transport people to their jobs? No one mentions the toll that a 4-hour-per-day commute takes on relationships. (...) What has always seemed more sensible to me is to live where you work. My commute is 10 minutes each way, on foot. And in my entire career as an engineer, the longest commute I’ve had was a half-hour drive.(Read the full letter "Megacommutes to megacities")
My first reaction was: lucky man! Then my second thought was: why can not we all have such a life, a life where the distance to work does not put a toll on our lives and our environment?
So why do we rush to big cities? Because this is where the demand for IT workers is high: banks, public sector entities and private companies have a tendency to locate themselves downtown. Since they have a high need of software engineers, they act as a magnet for us geeks of all sorts.
But why do not we telecommute more? After all, this is a revolution that has been announced a long time ago and we now have the tools that would allow us to make it happen. Massively distributed open source communities have proven that this is a model that can work.
On the contrary, agile principles tell us that teams should be as co-located as possible, because of the millstone that distance puts on communication, whose efficiency is a major cause of success for software projects (and the lack thereof a major cause of failure). Industry luminaries and extensive discussions have made this point very clear.
Since housing madness only allows singles and dinkies to live downtown, the ones of us with a family are then forced to live in the burbs, far away from work and far away from the perfect commute the aforementioned reader says he experienced all his life.
Trying to accommodate the often conflicting requirements of agility, personal life and business is not a trivial task, but one that is certainly calling for a broader rethinking of the way our cities and workplaces are organized and located.
Saturday, September 22, 2007
Code Literature
Open source projects documentation is a touchy subject.
I know it first hand from my own experience with NxBRE: writing and maintaining the 55+ pages PDF guide is not only a significant effort, but one of a very different nature than the effort of developing the product itself.
The wiki-based knowledge base is a good alternative: less formal, built from users questions and easy to maintain, it is definitively a viable approach for documenting small scale projects like mine.
This is also something learned on the field, as I have to work a lot with open source solutions. A pristine and up to date documentation is still an exception, at least for non-company backed projects. After hours of trial and error, fighting with an on-line documentation that was sometimes outdated (many examples would simply not work) and sometimes too advanced (showing features available in snapshot builds only), I came to consider recommending a paid-for solution, just for the sake of having someone to blame if the documentation was bad.
But that would have been too easy to surrender that way! Instead, I reverted to the more courageous tactics of the open source addict:
I know it first hand from my own experience with NxBRE: writing and maintaining the 55+ pages PDF guide is not only a significant effort, but one of a very different nature than the effort of developing the product itself.
The wiki-based knowledge base is a good alternative: less formal, built from users questions and easy to maintain, it is definitively a viable approach for documenting small scale projects like mine.
This is also something learned on the field, as I have to work a lot with open source solutions. A pristine and up to date documentation is still an exception, at least for non-company backed projects. After hours of trial and error, fighting with an on-line documentation that was sometimes outdated (many examples would simply not work) and sometimes too advanced (showing features available in snapshot builds only), I came to consider recommending a paid-for solution, just for the sake of having someone to blame if the documentation was bad.
But that would have been too easy to surrender that way! Instead, I reverted to the more courageous tactics of the open source addict:
- explore the provided running examples,
- if not enough, browse the test cases,
- if still not enough, trace debug with the source code attached to the IDE.
Monday, September 17, 2007
Saved By The Tickler
A few days ago, Sun has rolled out a new version of their Developer Forums. Since then, using these forums has turned into a nightmare:
Oh, maybe not, there is still the fancy JAVA Nasdaq ticker...
- All my watches are regularly lost, preventing me to follow-up with people asking questions, effectively killing the main value these forums are supposed to offer.
- The new text editor mangles any text input that is anything else than plain text: copying/pasting from any source ends up with the addition of funky tags that appear only when you save (or preview) your post.
Oh, maybe not, there is still the fancy JAVA Nasdaq ticker...
Sunday, September 09, 2007
Performance Driven Refactoring
I have recently talked about how fun it is to refactor code in order to increase its testability. Similarly, I have discovered another kind of refactoring driver: performance.
Starting to load test and performance profile an application you have developed is always an exhilarating time: I compare this with the Whack-A-Mole game, where, instead of funny animal heads, you hammer your classes down the execution tree until most of the time gets spent in code that is not yours.
Interestingly, I have seen the design of my application evolve while optimizing the critical parts of it. It is truly refactoring, as no feature gets added, but the code gets better performance wise.
Consider the following example that has arisen. Here is the original application design:
Profiling shown that computing the values of the context was really expensive and that these values were not always used by the target object.
I refactored to the following design:
In this design, the context values are only computed when the target object requests them, using a simple callback mechanism.
One could wonder why I did not simply remove the original context object and made O2 call O1. This would work but would have several disadvantages:
Starting to load test and performance profile an application you have developed is always an exhilarating time: I compare this with the Whack-A-Mole game, where, instead of funny animal heads, you hammer your classes down the execution tree until most of the time gets spent in code that is not yours.
Interestingly, I have seen the design of my application evolve while optimizing the critical parts of it. It is truly refactoring, as no feature gets added, but the code gets better performance wise.
Consider the following example that has arisen. Here is the original application design:
Profiling shown that computing the values of the context was really expensive and that these values were not always used by the target object.I refactored to the following design:
In this design, the context values are only computed when the target object requests them, using a simple callback mechanism.One could wonder why I did not simply remove the original context object and made O2 call O1. This would work but would have several disadvantages:
- unnecessarily increasing coupling between these two classes,
- visible design change, while I wanted the refactoring to respect the existing contracts between objects (the context in that case).
Tuesday, September 04, 2007
High Quantum Leap?
I am new to JPA and discovered today that HQL is not JPQL. This sounds pretty obvious but the circumstances when I was reminded this cruel reality were puzzling.
First let's start with my mistake! I wrote something like this:
instead of writing that:
i.e. HQL instead of JPQL.
You might think that I must be a lousy tester to release code that does not work but the trick is that it was working fine and passing the integration tests.
The issues was that the JPA provider I am using, Hibernate, was not running in strict mode hence was joyfully accepting the HQL queries. Everything was fine in the integration tests run on Jetty but when deployed on JBoss, where a strictly configured Hibernate was used as the JPA provider, all hell was breaking loose.
So conclusion one is that yes, I am a lousy tester: always target the same platform for your integration tests than for your deployments. There are simply too many provided runtime dependencies in an application server to take any chance with them.
And conclusion two is more an open question about the value of standardized Java API built on top of existing proprietary industry standards. Some success exist, like JCR, which is quite an achievement in the complex matter of unifying access to CMS implementations. But I must admit that one could find JPA an off-putting keyhole on Hibernate, spread with tricky drawbacks.
I want to believe that, the same way JAXP started as a gloomy reduction of the capacities of Crimson and Xalan behind wacky factories and ended as a convenient way to unify XML coding in Java, JPA will evolve towards a bright future.
First let's start with my mistake! I wrote something like this:
FROM Magazine WHERE title = 'JDJ'
instead of writing that:
SELECT x FROM Magazine x WHERE x.title = 'JDJ'
i.e. HQL instead of JPQL.
You might think that I must be a lousy tester to release code that does not work but the trick is that it was working fine and passing the integration tests.
The issues was that the JPA provider I am using, Hibernate, was not running in strict mode hence was joyfully accepting the HQL queries. Everything was fine in the integration tests run on Jetty but when deployed on JBoss, where a strictly configured Hibernate was used as the JPA provider, all hell was breaking loose.
So conclusion one is that yes, I am a lousy tester: always target the same platform for your integration tests than for your deployments. There are simply too many provided runtime dependencies in an application server to take any chance with them.
And conclusion two is more an open question about the value of standardized Java API built on top of existing proprietary industry standards. Some success exist, like JCR, which is quite an achievement in the complex matter of unifying access to CMS implementations. But I must admit that one could find JPA an off-putting keyhole on Hibernate, spread with tricky drawbacks.
I want to believe that, the same way JAXP started as a gloomy reduction of the capacities of Crimson and Xalan behind wacky factories and ended as a convenient way to unify XML coding in Java, JPA will evolve towards a bright future.
Monday, September 03, 2007
A Triplet Of Releases
What better day than labor day for releases? Sorry, I could not resist the cheap childbirth analogy! So, I have just released the latest version of NxBRE, the Inference Engine Console and the DSL plug-in.
I have decided not to finalize the implementation of the support of RuleML 0.91 Naf Datalog, mainly because it is not clear how integrity queries are now implemented. The release was worthwhile anyway, thanks to patches, bug reports and feature requests submitted by the community of users.
Enough labor for today!
I have decided not to finalize the implementation of the support of RuleML 0.91 Naf Datalog, mainly because it is not clear how integrity queries are now implemented. The release was worthwhile anyway, thanks to patches, bug reports and feature requests submitted by the community of users.
Enough labor for today!
Saturday, September 01, 2007
Virtual Shelf
Thanks to Vijay, I have discovered Shelfari, a really neat virtual shelf where you can share your experience about your current readings, your previous ones and consult the point of view of others.
You can even integrate a widget on your blog, as you can see on the lower right of this page.
Highly recommended!
You can even integrate a widget on your blog, as you can see on the lower right of this page.
Highly recommended!
Friday, August 31, 2007
Green or Bust!
WordWeb (Dictionary + Thesaurus + Word Finder) wants a better future for all of us.
Read their free version license agreement.
You might find it laughable but I think it is laudable.
Sunday, August 12, 2007
(Still) Waiting For Java 5
After the recent release of the public review of JSR-283, discussions have mainly been focused on the demise of XPath support and the installment of a new query language model. One thing that shocked me, when I browsed through the API, was the complete lack of any Java 5 language constructs, like generics or enumerations.
Or take a look at a the parent POM of a project like Mule ESB: the target JVM is 1.4.
Hence "enterprise" Java is still a 1.4 world. Even if it is possible to run 1.4-compiled applications on recent JVMs, mainly to reap their performance benefits or management features, the Java community is dragged behind by this state of affair.
And this means, we have to carry on with pre-1.5 compatibility features, like erasure, until the corporate world leaves the 1.4 platform for something less retarded. The good thing is that this will inevitably happen.
Or take a look at a the parent POM of a project like Mule ESB: the target JVM is 1.4.
Hence "enterprise" Java is still a 1.4 world. Even if it is possible to run 1.4-compiled applications on recent JVMs, mainly to reap their performance benefits or management features, the Java community is dragged behind by this state of affair.
And this means, we have to carry on with pre-1.5 compatibility features, like erasure, until the corporate world leaves the 1.4 platform for something less retarded. The good thing is that this will inevitably happen.
Thursday, July 26, 2007
Order Is Disorder
Eclipse offers the possibility to auto-sort the members of a class while formatting its code. After seeing the result of member sorting applied to code I have written, I must confess I find this "feature" totally useless at best, deeply asinine at worst because the cons totally outnumber the pros.
If this sounds too harsh, then here is a more polished point of view from this developerWorks article:
Sorting members alphabetically is very often counter-intuitive. Let's take javax.servlet.Filter as an example. Which implementation do you prefer:
The latter is of course the more natural one: time can not be factored out when reading and understanding source code. In this matter, the alphabetic ordering acts as a randomization of the time line of the source code.
On top of time-line ordering, programmers naturally organize related members in groups because it is easier to keep a visual context that covers several methods, hence it facilitates their comprehension. Using the previous example, I would opt to sort the members this way:
keeping the lifecycle methods (init and destroy) visually grouped and time-line sorted.
Here again, alphabetic sorting damages another important factor for code understanding: the distance between related statements.
My conclusion is that member sorting is far beyond formatting concerns and should not be automatically applied. If some sort of sorting is needed, it is better to sort the hierarchical outline of the class, as explained in the aforementioned article:
If this sounds too harsh, then here is a more polished point of view from this developerWorks article:
Sometimes it's nice to have members sorted alphabetically to better navigate in your code. Again, there may be arguments against it. Imagine you structure your code so that methods that call each other are located close together for code navigation. The sort would reorganize them, and they may not be in the wanted order.
Sorting members alphabetically is very often counter-intuitive. Let's take javax.servlet.Filter as an example. Which implementation do you prefer:
The alphabetic order
void destroy()
void doFilter()
void init()
The execution flow order
void init()
void doFilter()
void destroy()
void destroy()
void doFilter()
void init()
The execution flow order
void init()
void doFilter()
void destroy()
The latter is of course the more natural one: time can not be factored out when reading and understanding source code. In this matter, the alphabetic ordering acts as a randomization of the time line of the source code.
On top of time-line ordering, programmers naturally organize related members in groups because it is easier to keep a visual context that covers several methods, hence it facilitates their comprehension. Using the previous example, I would opt to sort the members this way:
void init()
void destroy()
void doFilter()
void destroy()
void doFilter()
keeping the lifecycle methods (init and destroy) visually grouped and time-line sorted.
Here again, alphabetic sorting damages another important factor for code understanding: the distance between related statements.
My conclusion is that member sorting is far beyond formatting concerns and should not be automatically applied. If some sort of sorting is needed, it is better to sort the hierarchical outline of the class, as explained in the aforementioned article:
The outline view offers a nice feature to sort members in the view, but not in the code. The specific settings and how members are sorted can be found in Preferences > Java > Appearance > Members Sort Order.
Wednesday, July 25, 2007
Monday, July 23, 2007
Some Serious Tooling
To further promote Windows Developer Power Tools, O'Reilly has just released two badges to show off the work done on the tools and on the book.
I really like the circular saw: though software engineering is more like plumbing, there are some serious cutting job as well, so a saw like this one can be handy.
Anyway, I start using the badges in the NxBRE sites and documentations.
 |  |
I really like the circular saw: though software engineering is more like plumbing, there are some serious cutting job as well, so a saw like this one can be handy.
Anyway, I start using the badges in the NxBRE sites and documentations.
Sunday, July 22, 2007
Content Rides The Bus
I have just released the very first version of the JCR Transport for Mule. This transport supports JCR 1.0 (Java Content Repository 1.0, as defined by JSR 170) repositories and is a receiver only. It leverages the asynchronous notification mechanism, named observation, to receive events whenever a change occurs in the repository and is not intended for storing nor reading messages from a content repository.
Indeed the use case for this connector is to monitor a content repository for particular events and to transform these events into fully-resolved serializable content-rich objects that Mule ESB can route to interested endpoints or components, enabling them to trigger actions like instantiating work-flow sequences or flushing caches.
Developing this connector using Mule's Transport Artifact was very easy, the biggest part of the code being in the (optional) augmentation of the JCR events with content from the repository. The development environment that MuleSource has opened to developers, named MuleForge, uses all the good tools of the moment like Subversion, Confluence, Jira, Bamboo and, of course, Maven ; with Xircles as the one platform to bind them all in a consistent dashboard.
MuleForge has allowed me to develop, build, distribute and document this transport in a very efficient and professional way. For example, the wiki templates look exactly like the Mule ESB official guide, which is a great plus for the end-users who will experiment a consistent reading experience.
All in all, MuleForge is a smart initiative that fosters creativity and contribution around a powerful and well-established open source product. I vouch the efforts MuleSource has put in setting up this environment will pay: it will nurture projects contributed by a vibrant community of users and developers and will eventually enrich the overall Mule ESB offer.
Indeed the use case for this connector is to monitor a content repository for particular events and to transform these events into fully-resolved serializable content-rich objects that Mule ESB can route to interested endpoints or components, enabling them to trigger actions like instantiating work-flow sequences or flushing caches.
Developing this connector using Mule's Transport Artifact was very easy, the biggest part of the code being in the (optional) augmentation of the JCR events with content from the repository. The development environment that MuleSource has opened to developers, named MuleForge, uses all the good tools of the moment like Subversion, Confluence, Jira, Bamboo and, of course, Maven ; with Xircles as the one platform to bind them all in a consistent dashboard.
MuleForge has allowed me to develop, build, distribute and document this transport in a very efficient and professional way. For example, the wiki templates look exactly like the Mule ESB official guide, which is a great plus for the end-users who will experiment a consistent reading experience.
All in all, MuleForge is a smart initiative that fosters creativity and contribution around a powerful and well-established open source product. I vouch the efforts MuleSource has put in setting up this environment will pay: it will nurture projects contributed by a vibrant community of users and developers and will eventually enrich the overall Mule ESB offer.
Saturday, July 21, 2007
DieSeL for the Engine
Thanks to ANTLR and ANTLRWorks, I have been able to make significant progress on the addition of Domain Specific Language (DSL) support for the Inference Engine of NxBRE. A usable version is available in the SVN repository on SourceForge.
NxBRE DSL, aka NxDSL, main goal is to allow rules authors to use their own natural language to write executable rules. Technically this feature is based on:
In the following example, the words in red are parsed by ANTLR while the ones in green are matched by the regular expression from the definition file.
The terms in italic are captured by ANTLR and the regular expressions to get values for labels, implication actions and atom values.
As you can see, the ANTLR grammar defines and enforces the structure of the rulebase, i.e. the skeleton of the rules, logical blocks and statements.
NxDSL comes with a grammar that allows using French terms for defining the rule structure, thus opening the door to consistently write the body of the rules in the same language, as shown hereafter:
While NxDSL adds extra work for the engine implementor, the positive impact for the rule writers will justify its usage for projects in need of letting non-technical users manage rules.
NxDSL also opens the possibility of writing a plain-text rule editor by leveraging the definition file to provide code assistance to the writer. Anyone feeling like contributing such an editor?
NxBRE DSL, aka NxDSL, main goal is to allow rules authors to use their own natural language to write executable rules. Technically this feature is based on:
- a language-specific ANTLR grammar that strictly enforces the structure of a rule file: this file is not supposed to be edited by the implementer,
- a custom definition file that translates statements into RuleML atoms: this file must be created by the implementer to capture, with regular expressions, the natural language fragments and how they translate in RuleML atoms.
In the following example, the words in red are parsed by ANTLR while the ones in green are matched by the regular expression from the definition file.
rule "Discount for regular products"
if
The customer is rated premium
and
The product is a regular product
then deduct
The discount on this product for the customer is 5.0 %
The terms in italic are captured by ANTLR and the regular expressions to get values for labels, implication actions and atom values.
As you can see, the ANTLR grammar defines and enforces the structure of the rulebase, i.e. the skeleton of the rules, logical blocks and statements.
NxDSL comes with a grammar that allows using French terms for defining the rule structure, thus opening the door to consistently write the body of the rules in the same language, as shown hereafter:
règle "Remise pour les produits standards"
si
Le client est en catégorie premium
et
Le produit est de type standard
alors déduis
La remise pour ce produit pour ce client est de 5.0 %
While NxDSL adds extra work for the engine implementor, the positive impact for the rule writers will justify its usage for projects in need of letting non-technical users manage rules.
NxDSL also opens the possibility of writing a plain-text rule editor by leveraging the definition file to provide code assistance to the writer. Anyone feeling like contributing such an editor?
Thursday, July 19, 2007
Lang for the Commons
I had to deal today with a class that contains an attribute of type java.io.Serializable. When I asked Eclipse to generate the equals and hashCode methods that I needed to be implemented, it warned me that the generated code will not work properly because Serializable does not mandate anything in term of implementation of these two methods.
And as expected, I started to get red lights when my test cases were stuffing byte[] in the Serializable attribute: the hash computation and equality algorithm used for this type was simply not working and two instances of my object containing the same sequence of bytes in two different byte arrays were bound to be different.
Since I was already Commons Lang for building the String representation of my object, I thought I should give a shot at the hashcode and equals builder it offers. Reading no doc and proceeding only by analogy with the toString method, I quickly typed this:
And it worked immediately! Not only it saved me a lot of lines of code but it worked exactly as I expected from the look at the name of the classes and the methods.
Nice API, nice library: you need it.
And as expected, I started to get red lights when my test cases were stuffing byte[] in the Serializable attribute: the hash computation and equality algorithm used for this type was simply not working and two instances of my object containing the same sequence of bytes in two different byte arrays were bound to be different.
Since I was already Commons Lang for building the String representation of my object, I thought I should give a shot at the hashcode and equals builder it offers. Reading no doc and proceeding only by analogy with the toString method, I quickly typed this:
public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this);
}
public boolean equals(Object obj) {
return EqualsBuilder.reflectionEquals(this, obj);
}
And it worked immediately! Not only it saved me a lot of lines of code but it worked exactly as I expected from the look at the name of the classes and the methods.
Nice API, nice library: you need it.
Wednesday, July 18, 2007
July And Still Jolting
DDJ has (finally) published the write-ups for the winners of this year's Jolt Product Excellence Awards.
There is no master page for the different categories, so here is a link that will provide you with search results showing all the relevant pages.
My own write-ups are in the Enterprise Tools and Libraries, Frameworks and Components categories.
Enjoy the reading!
There is no master page for the different categories, so here is a link that will provide you with search results showing all the relevant pages.
My own write-ups are in the Enterprise Tools and Libraries, Frameworks and Components categories.
Enjoy the reading!
Saturday, July 14, 2007
Everything Is Happy (or Content?)
On this sunny Bastille Day, there is at least one good reason to rejoice: the public review of JSR-283 (aka JCR 2.0) has been published yesterday! Knowing that one of the most interesting Java APIs of the moment has just gotten better is a true source of (geeky) happiness and the promise that it will keep shaking and shaping the world of content repositories.
Indeed, JCR has been playing and will keep playing a fundamental role in opening the doors of a domain that used to be the private hunting field of a few mammoth vendors. Of course, this is not about getting great repositories for free, instead the main benefits are allowing users to be in control of their content assets and enabling developers to build innovative content-driven solutions.
I did not have time to dig deep in the specification, but I noticed that observations now produce richer events (source path and indentifiers) and that the previous version of SQL and XPath query languages have been deprecated in favor of an Abstract Query Model (AQM) that incarnates in a new SQL (JCR-SQL2) and a query object model (JCR-JQOM). I was convinced that XPath was a perfect fit for JCR searching but apparently I was wrong! I think JQOM will be the more appealing option for tool builders as mapping query features to this object model will be less clumsy than generating SQL.
Now to my little wish list! As a user of the API, here are the three changes I would like to see in the new version. Some are trivial, like:
Indeed, JCR has been playing and will keep playing a fundamental role in opening the doors of a domain that used to be the private hunting field of a few mammoth vendors. Of course, this is not about getting great repositories for free, instead the main benefits are allowing users to be in control of their content assets and enabling developers to build innovative content-driven solutions.
I did not have time to dig deep in the specification, but I noticed that observations now produce richer events (source path and indentifiers) and that the previous version of SQL and XPath query languages have been deprecated in favor of an Abstract Query Model (AQM) that incarnates in a new SQL (JCR-SQL2) and a query object model (JCR-JQOM). I was convinced that XPath was a perfect fit for JCR searching but apparently I was wrong! I think JQOM will be the more appealing option for tool builders as mapping query features to this object model will be less clumsy than generating SQL.
Now to my little wish list! As a user of the API, here are the three changes I would like to see in the new version. Some are trivial, like:
- A Property object can be single or multi-valued hence offers getValue() and getValues(). I find logical that calling getValue() on a multi-valued property fails but I find deeply counter-intuitive that calling getValues() on a single-valued property fails. By allowing getValues() to return a unique value from a single-valued property, the code needed to read property content would be vastly unified, thus simplified. This would also be conform to the principle of least astonishment.
- An Event has a type property that defines the reason why it was raised. This is defined by a list of static integer while I think it would be better to use a type safe enumeration, as it is done for PropertyType. I can understand that this change would create an ascending compatibility challenge so at least adding an helper class that could render to / parse from String would be very helpful for translating event types to a human readable form (PropertyType offers such methods: nameFromValue and valueFromName). On top of that, making Event serializable would also facilitate its processing.
- A less trivial addition would be to offer a unified way of acquiring a repository. Currently each vendor can offer a different client factory: writing an application that connects to several repositories forces to write specific code (or to use SpringModules). A unified URI-driven repository factory mechanism a la JDBC would be very helpful.
Thursday, July 12, 2007
Skeletons And Open Closets
Before it went to the printed publications paradise, Software Development Magazine was running an "Horror Stories" series for Halloween time every year. It was fun to write, instructive to read and pretty scary as well.
Nowadays, the "Daily WTF", prudishly renamed Worse Than Failure, brings us this kind of story everyday, if not several times per day. A common point between all these stories seems to be the universal existence of software skeletons in IT closets, waiting to jump on poor new programmers laps and make their life a nightmare.
Life being short, it can be desirable to avoid getting aboard a ship that carries such monsters but how to tell that a company is facing "legacy code issues" from a few interviews? This kind of risk might make working for an open source software company a desirable move. Skeletons dislike open closets.
Are open source companies free of monsters? Of course not: for all the pieces of software that are not public (think back office systems, web sites...), there is a risk of facing the ugly spawn of years of software rot. But at least all the public facing code will have to stand to some elevated standards and is "up to the challenge of 1000+ eyeballs reading [it] every day".
Should code skeletons be avoided at all cost? I do not think so. Most of us can not see dead people, similarly management can not see dead programs. IIABDFI is the golden rule but sometimes it becomes clear that there is only that much marathons a dead man can run. Then, if your job is to refactor such a monster so it becomes maintainable and versatile, it can be as challenging as fun.
What should be avoided at all cost is the summoning of new skeletons in closets. With all the knowledge we have now thanks luminaries in our industry, this should be possible.
Nowadays, the "Daily WTF", prudishly renamed Worse Than Failure, brings us this kind of story everyday, if not several times per day. A common point between all these stories seems to be the universal existence of software skeletons in IT closets, waiting to jump on poor new programmers laps and make their life a nightmare.
Life being short, it can be desirable to avoid getting aboard a ship that carries such monsters but how to tell that a company is facing "legacy code issues" from a few interviews? This kind of risk might make working for an open source software company a desirable move. Skeletons dislike open closets.
Are open source companies free of monsters? Of course not: for all the pieces of software that are not public (think back office systems, web sites...), there is a risk of facing the ugly spawn of years of software rot. But at least all the public facing code will have to stand to some elevated standards and is "up to the challenge of 1000+ eyeballs reading [it] every day".
Should code skeletons be avoided at all cost? I do not think so. Most of us can not see dead people, similarly management can not see dead programs. IIABDFI is the golden rule but sometimes it becomes clear that there is only that much marathons a dead man can run. Then, if your job is to refactor such a monster so it becomes maintainable and versatile, it can be as challenging as fun.
What should be avoided at all cost is the summoning of new skeletons in closets. With all the knowledge we have now thanks luminaries in our industry, this should be possible.
Friday, June 29, 2007
Obfuscated by obfuscation
From time to time, I have to add in the list of dependencies of one my projects a library whose byte code has been obfuscated.
Who cares, would you ask? Well not me until I have to step debug into the said library because it is usually easier to follow an execution path than a technical guide. And then the pain begins: obfuscated library are (intentionally) a mess and you can not do anything in debug mode with them.
So here is my messages to vendors and other smart guys who think security by obscurity works: this is freaking retarded! You prevent legitimate users to do their business with your library the way experienced users do. No matter how good you think your user guides are, when something goes wrong, nothing replaces the ability to follow the actual execution of a program. As Bruce Schneier says it:
So please, do not obfuscate the libraries you distribute, no matter how proprietary you think they are. Your value, as a software company, does not reside in the heart of the few bytes that you try to hide. It lies in your people, your know-how and your services.
Let there be light!
Who cares, would you ask? Well not me until I have to step debug into the said library because it is usually easier to follow an execution path than a technical guide. And then the pain begins: obfuscated library are (intentionally) a mess and you can not do anything in debug mode with them.
So here is my messages to vendors and other smart guys who think security by obscurity works: this is freaking retarded! You prevent legitimate users to do their business with your library the way experienced users do. No matter how good you think your user guides are, when something goes wrong, nothing replaces the ability to follow the actual execution of a program. As Bruce Schneier says it:
Security by obscurity: it doesn't work, and it's a royal pain to recover when it fails.
So please, do not obfuscate the libraries you distribute, no matter how proprietary you think they are. Your value, as a software company, does not reside in the heart of the few bytes that you try to hide. It lies in your people, your know-how and your services.
Let there be light!
Subscribe to:
Posts (Atom)