All for very different reasons, processor vendors, software developers and industry gurus are engaged in talk frenzies about how to leverage multiple core hardware. Some consider the dangers. Some even fight about it.
Beside the obvious enthusiasm of experimenting such a surge of computing power right under our fingers, exploiting this power requires a skillset that is not widely available, at least not in the world of the ugly enterprise applications where people have to develop for the naturally parallelized environments that are application servers.
In this austere world of server side business applications, which are not CPU intensive but are greedy of external resources like RDBMS, there is not much room for developer hand made parallelizing of tasks: it is usually limited to executing long running operations via decoupling mechanisms like messaging.
This said, there are many ways to hurt your server by developing applications in a careless way. Assessing your skills (or your troops) is essential: this is why, following the model of the great Threading Maturity Model introduced by Alan Zeichick a few days ago, I would like to introduce the Threader Maturity Model, oriented towards people and not organization.
0. Unawareness. Complete rooky who writes a web application that can only accommodate one concurrent user and complains why is the server not working better (do not ask for names).
1. Awareness. Developer who has bumped on concurrency discussions, found them scary and prefers to let a more senior programmer deal with threading and concurrency.
2. Experimentation. Developer who dares playing with threads and concurrency, but still errs on the side of double-checked locking, interruption swallowing and the likes.
3. Hotspot. Developer has read enough on the subject and has crashed into enough walls to decide to program carefully, with still a certain level of insecurity and the fear of thread skeletons hiding in some dark closets.
4. Utilization. Developer has an excellent knowledge of concurrency issues and has a toolbox well fitted with patterns he knows when to apply and for what purpose. He can decide what is worth to parallelize and what is not.
5. Adoption. This is also known as "Being Brian Goetz". At this level, the developer has an intimate knowledge of the memory model, the concurrency mechanisms and all that pesky internal details. He is able to think in all the dimensions of multi-threaded development (time, space and whatnot). Nirvana is nearby.
UPDATE 01/2008: Alexandra Weber Morales has published a great compilation of Alan's, Larry's and my take on this subject. It is on DevX.
Tuesday, January 23, 2007
Sunday, January 21, 2007
Don't Be God Either
Though Google has agreed to work with NGOs to develop a code of conduct, some people keep suspecting the giant of Mountain View to nurture a secret agenda for world domination. Are they getting too suspicious or paranoid? Or are they seeing too small of a plot? After all, for Google, the world is certainly not enough.
I think that if Google was actually bound to drift away from its "Don't Be Evil" motto towards some more cosmic grand plan, the following would inevitably happen:
I think that if Google was actually bound to drift away from its "Don't Be Evil" motto towards some more cosmic grand plan, the following would inevitably happen:
- Google would buy T.G.I. Friday's but instead of renaming it GoogleRestaurant, as logic suggests, would simply redefine the acronym as "Thanks Google It's Friday",
- Google would buy Godiva but instead of logically renaming it GoogleChocolate, would rebrand it as Googleiva,
- Google would become the official sponsor of The Young Gods, but only if they accept the new moniker of The Young Googles.
Labels:
Google
Friday, January 19, 2007
Editor's Pick
Today is the Windows Developer Tools Day, as unilaterally proclaimed by the folks at O'Reilly, and everyone is invited to share their best tools on the Windows platform. Having contributed a presentation of NxBRE, an Open Source .NET Business Rules Engine, to their Windows Developer Power Tools book, you could expect me to talk about it, as the selfish nerd I am.
But no, I prefer to share my passion for jEdit, my choice for an all purpose versatile open source editor. Funnily, when discussion comes to editors, geeks just go berserk and try to prove how superior is their favorite tool. I will try to avoid this kind of flame war and will just share what I like most about jEdit:
But no, I prefer to share my passion for jEdit, my choice for an all purpose versatile open source editor. Funnily, when discussion comes to editors, geeks just go berserk and try to prove how superior is their favorite tool. I will try to avoid this kind of flame war and will just share what I like most about jEdit:
- It is easily extensible to support new features via an integrated plugin manager. Each plugin could contribute new views that you can dock anywhere and create your own environment. I personally use the XML support plugins a lot and dock them all around the editor window for a great work environment.
- Adding syntactic coloring for new languages is just a bliss. For example, I created what is called a mode to simplify the edition of WAC files in just a few minutes.
- The integrated HyperSearch facility just finds things on your hard drive without referring to any particular animal or having to index the terabytes of source code you write on weekends just for fun.
- It is cross platform, which means I can use it when I work on Linux or Mac. How can this matter to a Windows developer? Well, sooner or later, you will be exposed to an OS that is not a member of the Microsoft galaxy so how cool will it be to just use the same tool everywhere?
- It can open files not created on Windows systems without stumbling on different flavors of Newline and showing everything on one line. Again, this might seem like unnecessary for an hard core Windows-only-and-the-rest-of-the-universe-can-die developer, but again it happens more often than expected when you start to share files with people in the rest-of-the-universe!
Labels:
Tools
Wednesday, January 17, 2007
Monday, January 15, 2007
V for Vancouver
I am now entering the final countdown (3 days to go) before my departure to Vancouver, BC where I will start a new job and, hopefully, a new life! When you announce this kind of crazy endeavor, usually people go "wow" and say how great it is and also how so not for them such a thing would be possible.
The most common opposition is: "you know what you are losing but you do not know what you are earning". Well, I am all but an adventurer though, since I still try to start new software projects, I should have a good level of risk taking (or I am just a too naive). Besides, on a pure professional basis, I know what I am leaving behind (a great company with great people) but I also know that I am joining a great company with great people!
On a more personal basis, I hope to find over there a place for my family to call home, which would be a great gain for strangers and sojourners like us.
The most common opposition is: "you know what you are losing but you do not know what you are earning". Well, I am all but an adventurer though, since I still try to start new software projects, I should have a good level of risk taking (or I am just a too naive). Besides, on a pure professional basis, I know what I am leaving behind (a great company with great people) but I also know that I am joining a great company with great people!
On a more personal basis, I hope to find over there a place for my family to call home, which would be a great gain for strangers and sojourners like us.
Friday, January 05, 2007
Sewer 2.0
ZePAG has posted a great entry in his blog that somehow echoes an old rant of mine.
Since he makes some interesting comparisons between IT and different subjects like sewer technologies, I felt like bouncing on the yucky pictures he links to and suggest dubbed image titles:
Since he makes some interesting comparisons between IT and different subjects like sewer technologies, I felt like bouncing on the yucky pictures he links to and suggest dubbed image titles:
- Screw pumps: dependency injection,
- Primary screen: welcome page,
- Primary clarifiers: client side validation,
- Aeration tank: O/R mapping,
- Secondary clarifier: server side validation,
- Final clarifier: database level constraints,
- Chlorination tank: garbage collection.
Labels:
Fun
Wednesday, January 03, 2007
One Click To Share Them All
Optrata is doubly blessed by a strange moniker (that sounds like patatra, a French onomatopeia for the sound of a thing falling heavily on the ground) and a bold mission statement (to unify all the private life exposing tools of the web behind a unique page).
By the look of their "please bookmark me so I can appear on radar screens" links:

I feel inclined to suggest them to urgently change their goal and work on creating a unified bookmark tool that would submit a page to the numerous sharing systems out there...
By the look of their "please bookmark me so I can appear on radar screens" links:

I feel inclined to suggest them to urgently change their goal and work on creating a unified bookmark tool that would submit a page to the numerous sharing systems out there...
Labels:
Fun
Saturday, December 30, 2006
The Day My iPod Became Just Another Appliance
This is today as my iPod officially joined the rank of my electronic appliances that need to be reset from time to time. The screen had a bizarre circular shift of 15% to the left, showing part of the left side of the screen on its right part. Everything was frozen with the backlight on.
For the record, so far only my oven and my dishwasher needed a little reboot from time to time. Now they are three in the club! Interestingly, they are all reset using an odd combination of front panel keys. Appliance makers do what they can with what they have, but only a few keys are needed for this maintenance operation (look on Windows: Ctrl + Alt + Del do the trick).
My wild guesses concerning the cause of failure for these diverse but similar software controlled appliances:
For the record, so far only my oven and my dishwasher needed a little reboot from time to time. Now they are three in the club! Interestingly, they are all reset using an odd combination of front panel keys. Appliance makers do what they can with what they have, but only a few keys are needed for this maintenance operation (look on Windows: Ctrl + Alt + Del do the trick).
My wild guesses concerning the cause of failure for these diverse but similar software controlled appliances:
- Oven: heat excess in the control panel,
- Dishwasher: humidity too high in the control panel,
- iPod: overall system too cold as it stayed overnight in my entrance.
Labels:
Fun
Friday, December 29, 2006
Busy Buzz For Lazy Bees
After Sony, who really screwed up their buzz marketing for the PSP3, Microsoft does the same stuff for Vista.
Mmmh, what could be the reason for these two companies (not the tiniest or dumbest on earth) to miserably fail a marketing campaign? What can make them so desperate to have people talk about their glimmering new products?
The answer might be in the common points between the PSP3 and Vista: expensive, unattractive, deja vu.
Do you find I am tough? Well, let's get tougher: guys, next time, ask a buzz specialist to advise you, else drop the idea. A failed campaign is not something you want to experiment. Again.
Mmmh, what could be the reason for these two companies (not the tiniest or dumbest on earth) to miserably fail a marketing campaign? What can make them so desperate to have people talk about their glimmering new products?
The answer might be in the common points between the PSP3 and Vista: expensive, unattractive, deja vu.
Do you find I am tough? Well, let's get tougher: guys, next time, ask a buzz specialist to advise you, else drop the idea. A failed campaign is not something you want to experiment. Again.
Labels:
World
Thursday, December 28, 2006
NxBRE 3.1.0Beta1 Is Out
I have just posted a beta release of NxBRE 3.1.0, which is mainly intended for those interested in testing one of these two new features:
- A regular expression matcher operator has been added to the Flow Engine (which is also available in the Inference Engine),
- The implication scheduling in the agenda has been improved to limitate the number of fired implications, hence yield to better performances with large rule bases.
Labels:
My OSS
Friday, December 22, 2006
Unexpected Performances Can Occur (Sometimes)
I just can not believe the message Khalid Khalil has just posted on NxBRE's open discussion forum!
Using object pooling, Khalid has reached a throughput of 2000 requests per second with the Flow Engine, one of the two engine flavors available in NxBRE. It is far beyond the performances I was expecting for my tiny business rules engine: way too cool!
Using object pooling, Khalid has reached a throughput of 2000 requests per second with the Flow Engine, one of the two engine flavors available in NxBRE. It is far beyond the performances I was expecting for my tiny business rules engine: way too cool!
Labels:
My OSS
Tuesday, December 19, 2006
Behind Closed Doors
My friend Stuart Hogue, Strategy Director of frog design inc. in NYC, has published a pretty interesting article about hyper exclusive social networks.
I find significant that his article comes at a time when Metcalfe's law is under criticisms. In different replies to IEEE Spectum, Robert Metcalfe stands by his law stating that the value of a network is equal to the square of the number of users. His opponents are mainly saying that: "The fundamental flaw underlying (...) Metcalfe's (...) law is in the assignment of equal value to all connections or all groups".
So the key and maybe the mathematical justification of hyper exclusive social networks might lie in this principle: not all connections have similar value, hence dedicated selective network will maximize their value by selecting only people who will engage in high value relationships.
In practice, it is true that I have quickly dropped Orkut and Friendster to favor the more selective LinkedIn network. I am still waiting to see returns from the highly selective Blue Chip Expert network, to which I have recently been invited. If you visit their homepage, you will appreciate the main picture: a closed door that looks very serious!
Is the true value of social networks waiting behind closed doors?
I find significant that his article comes at a time when Metcalfe's law is under criticisms. In different replies to IEEE Spectum, Robert Metcalfe stands by his law stating that the value of a network is equal to the square of the number of users. His opponents are mainly saying that: "The fundamental flaw underlying (...) Metcalfe's (...) law is in the assignment of equal value to all connections or all groups".
So the key and maybe the mathematical justification of hyper exclusive social networks might lie in this principle: not all connections have similar value, hence dedicated selective network will maximize their value by selecting only people who will engage in high value relationships.
In practice, it is true that I have quickly dropped Orkut and Friendster to favor the more selective LinkedIn network. I am still waiting to see returns from the highly selective Blue Chip Expert network, to which I have recently been invited. If you visit their homepage, you will appreciate the main picture: a closed door that looks very serious!
Is the true value of social networks waiting behind closed doors?
Labels:
Tools
Saturday, December 16, 2006
All I'm askin'
A recent and insightful Computer article from Stephen Jenkins (Concerning Interruptions) led me to rethink my authoritative position on working with headsets (read Kindly Kill That Headset).
I think the crux of the problem is not about knowing if programmers need isolation to avoid frustrating and concentration killing interruptions (this is granted), but actually respecting this need for isolation.
If everybody would respect this need by refraining from asking out-of-context questions (the most brain resources consuming ones) and by saving interruptions for better times (like planned meetings, lunch time or pit stops), programmers would need less to stick headsets on their ears and would therefore be more available for direct in-context questions from fellow team members.
Aretha was right: it's all about respect!
I think the crux of the problem is not about knowing if programmers need isolation to avoid frustrating and concentration killing interruptions (this is granted), but actually respecting this need for isolation.
If everybody would respect this need by refraining from asking out-of-context questions (the most brain resources consuming ones) and by saving interruptions for better times (like planned meetings, lunch time or pit stops), programmers would need less to stick headsets on their ears and would therefore be more available for direct in-context questions from fellow team members.
Aretha was right: it's all about respect!
Labels:
Craftsmanship
Tuesday, December 12, 2006
Proxy That Proxy
One day or the other, you will wake up with the bold idea of deploying several EAR files in your JBoss 4.0.x Application Server. Why bold? Because it is almost sure that:
If your EJBs only take and return classes from the JDK, rejoice! There is hope for you! Indeed, you can remove this problematic casting:
which generates exceptions because the looked-up interface has been loaded by a different class loader than the one you cast to, by using a dynamic proxy that directly implements the business interface of your remote EJB.
To simplify this, you can leverage Spring Framework's SimpleRemoteStatelessSessionProxyFactoryBean, which will lookup your EJB, create it for you and return a dynamic proxy that implements the business methods. By this mean, the need for casting is removed.
Of course, as I said before, this only works if you exchange primitives or objects from the JDK (because they are loaded from a common hierachy of class loaders that includes the system class loader). But it is a viable alternative to keep in mind...
- you will need to isolate the class loaders of the EAR files (for example to load different versions of the same class in the different applications),
- you will want EJBs to communicate between the different EAR files.
If your EJBs only take and return classes from the JDK, rejoice! There is hope for you! Indeed, you can remove this problematic casting:
HomeInterface hi = (HomeInterface) lookedUpHome;
which generates exceptions because the looked-up interface has been loaded by a different class loader than the one you cast to, by using a dynamic proxy that directly implements the business interface of your remote EJB.
To simplify this, you can leverage Spring Framework's SimpleRemoteStatelessSessionProxyFactoryBean, which will lookup your EJB, create it for you and return a dynamic proxy that implements the business methods. By this mean, the need for casting is removed.
Of course, as I said before, this only works if you exchange primitives or objects from the JDK (because they are loaded from a common hierachy of class loaders that includes the system class loader). But it is a viable alternative to keep in mind...
Labels:
Tools
Saturday, December 02, 2006
Hetero-Genius
In the November issue of Computer, there is an interesting article from David Alan Grier, titled "The Benefits of Being Different", which talks about a subject I am currently particularly sensitive to: the dangers of uniformity in IT systems.
My reflection started a few weeks ago when IEEE Spectrum published a seminal article (Shrink the Targets). Indeed, after the rise and establishment of Microsoft supremacy on personal computers, we are in a great need of diversity because homogeneity has many hidden catches we have to pay one day or the other.
Homogeneity makes IT systems fragile because the same flaw or weakness is reproduced on hundred of thousands (if not millions) of machines, making all of them sensitive to a well targeted attack. The discussions about the superiority of a particular OS or tool (like a browser) that end up with plans for the worldwide replacement of one by another, are childish and futile. All these pieces of software have reached such a great level of quality that you can not select them on pure technical basis. So there is no supremacy to target, as replacing one domination by another one, would leave us with a situation as fragile as before. We must see the advent of non-geeky tribes who will recognize themselves in the usage of a particular combination of OS and tools, who will be empowered so they can assume their choice without being exposed to nasty technical problems or being pointed as originals.
Homogeneity carries another risk: the supremacy of a particular tool or vendor always induce the usage of proprietary file formats. Being locked-in a vendor tool because its features are so above the competitors is nothing bad: it benefits the user and, moreover, it never lasts. Competition always catch up. Then open source tools come in, disrupt the model and force everybody to think harder about increasing the quality of the tools and the services that gravitate around them. But being locked-in because your own personal data are locked-in a proprietary file format is nothing that can be accepted anymore. Diversity forces vendors and tool makers to enable data exchange, freeing the content that was held captive.
In a time when our most precious material assets are mainly digital (does not this feel like a quasi oxymoron?), homogeneity is no longer an issue. Let us be hetero-genius!
My reflection started a few weeks ago when IEEE Spectrum published a seminal article (Shrink the Targets). Indeed, after the rise and establishment of Microsoft supremacy on personal computers, we are in a great need of diversity because homogeneity has many hidden catches we have to pay one day or the other.
Homogeneity makes IT systems fragile because the same flaw or weakness is reproduced on hundred of thousands (if not millions) of machines, making all of them sensitive to a well targeted attack. The discussions about the superiority of a particular OS or tool (like a browser) that end up with plans for the worldwide replacement of one by another, are childish and futile. All these pieces of software have reached such a great level of quality that you can not select them on pure technical basis. So there is no supremacy to target, as replacing one domination by another one, would leave us with a situation as fragile as before. We must see the advent of non-geeky tribes who will recognize themselves in the usage of a particular combination of OS and tools, who will be empowered so they can assume their choice without being exposed to nasty technical problems or being pointed as originals.
Homogeneity carries another risk: the supremacy of a particular tool or vendor always induce the usage of proprietary file formats. Being locked-in a vendor tool because its features are so above the competitors is nothing bad: it benefits the user and, moreover, it never lasts. Competition always catch up. Then open source tools come in, disrupt the model and force everybody to think harder about increasing the quality of the tools and the services that gravitate around them. But being locked-in because your own personal data are locked-in a proprietary file format is nothing that can be accepted anymore. Diversity forces vendors and tool makers to enable data exchange, freeing the content that was held captive.
In a time when our most precious material assets are mainly digital (does not this feel like a quasi oxymoron?), homogeneity is no longer an issue. Let us be hetero-genius!
Labels:
Platform
Saturday, November 18, 2006
Mapping panacea
To paraphrase the golden hammer saying, I have the feeling that nowadays, because you have object mapping frameworks, everything looks like an object!
What is it with developers who seem to get infatuated with such tools? Does everything need to be mapped to objects? Of course not! Here two recent cases that kind of drive me nuts:
What is it with developers who seem to get infatuated with such tools? Does everything need to be mapped to objects? Of course not! Here two recent cases that kind of drive me nuts:
- Why reading XML files when I can map them to objects? Well, maybe because what you are looking for is actually... data. So please save your application from the miseries of JAXB 1.x (which does not even care to mandate a clear concurrent behavior in its API) and use SAX, XPath or any other efficient XML reading tool!
- Why querying the database when I can map it to objects? Well, maybe because you are performing batch operations that are mainly data retrieving oriented and the overhead your O/R mapper will add plus its memory consumption will put your virtual machine on its knees. So please take the fast lane!
Labels:
Tools
Thursday, November 16, 2006
Feeding the White Rabbit
So now that, for my birthday, I got my own Nabaztag, a white WIFI rabbit that can move its ears, display light signals on 5 RGB LEDs and play digitized sounds, the big question is: how to keep the funny bunny happy?
I guess by feeding it properly.
The default services offered for free by the vendor are pretty basic: weather, stock exchange, email account watcher... And the coolest: rabbit Tai Chi! Hey, what do you expect: they are free, right?
Since the animal has an HTTP based API that allows controlling its ears, lights and sounds (including a nice TTS feature), I do not see any reason to subscribe for the advanced paying services! It will be much more fun to write services for it!
So I came with the first one today, an appetizer for the white rabbit: the service connects to the GMail accounts of the family members and builds a vocal summary of the emails waiting to be read. And that's already cool ;-)
There are many other funny things to do: a service that would report the daily statistics of my open source projects could be fun. Another one that would connect Maven to the animal and that color the poor thing in red whenever a build is broken or unit tests are not A-OK, would be terrific.
You might wonder what is the moniker of this new family member? Knowing that if you know his name, you can make it speak and that the thingy sits in the middle of our living room, where any sentence rated above G are not welcome, I would say that we will call it "secret". For now.
I guess by feeding it properly.
The default services offered for free by the vendor are pretty basic: weather, stock exchange, email account watcher... And the coolest: rabbit Tai Chi! Hey, what do you expect: they are free, right?
Since the animal has an HTTP based API that allows controlling its ears, lights and sounds (including a nice TTS feature), I do not see any reason to subscribe for the advanced paying services! It will be much more fun to write services for it!
So I came with the first one today, an appetizer for the white rabbit: the service connects to the GMail accounts of the family members and builds a vocal summary of the emails waiting to be read. And that's already cool ;-)
There are many other funny things to do: a service that would report the daily statistics of my open source projects could be fun. Another one that would connect Maven to the animal and that color the poor thing in red whenever a build is broken or unit tests are not A-OK, would be terrific.
You might wonder what is the moniker of this new family member? Knowing that if you know his name, you can make it speak and that the thingy sits in the middle of our living room, where any sentence rated above G are not welcome, I would say that we will call it "secret". For now.
Labels:
Fun
Saturday, November 11, 2006
Centralized Configuration Management for JBoss
NOTE 12-MAY-2009: This particular post is driving a lot of traffic on my blog. Even if the JBoss Properties Service is still worth using, nowadays, I would not advocate the management of properties in SVN, as it is problematic security wise and requires the need of an HA repository. I would rather embed default properties values in my project and allow the overriding of some values (passwords...) via a simple file created in a well known location on the server.
Managing configuration of application servers and the applications they host in a centralized and rationalized way is a requirement for any corporate doing its own hosting. Not only configuration differs between server instances and the applications they host but also between the different environments they exist in (ie. development, integration, QA, pre-production and production).
JBoss 4 user guide shows how to leverage the Service Binding Manager to handle server configuration in a central way. This is a great approach but I think we can go further by leveraging Java system properties in conjunction with two other features of the server: the Properties Service and the fact that JBoss parses all XML configuration files (including J2EE deployment descriptors) and resolves ${references} to system properties. Moreover, if you use the Spring Framework in your application, you can also leverage its PropertyPlaceholderConfigurer to retrieve configuration information from Java system properties.
As shown above, the main idea is to store configuration information as properties files in a Subversion repository and have the different JBoss Application Server retrieve these configurations through HTTP and thanks to this kind of configuration of the Properties Service (in properties-service.xml):
These system properties will then be loaded at JBoss startup time (or on any modification, like a touch, of the properties-service.xml file) and will be available for use in many different places like:
Another interesting feature of the Properties Service to leverage is the fact you can provide a list of URLs: all the properties will be loaded from these URLs, the latest ones having the precedence on the first ones. This can be used to organize configuration in a hierarchy, with global settings, server specific settings and application level settings loaded from a common place and mixed together in the Java system properties. Here is an example of such a configuration:
As you can see, not only is JBoss a versatile application server, but it is also an extremely configurable one that can be easily tuned to fit the needs of large companies with complex deployment constraints.
Managing configuration of application servers and the applications they host in a centralized and rationalized way is a requirement for any corporate doing its own hosting. Not only configuration differs between server instances and the applications they host but also between the different environments they exist in (ie. development, integration, QA, pre-production and production).
JBoss 4 user guide shows how to leverage the Service Binding Manager to handle server configuration in a central way. This is a great approach but I think we can go further by leveraging Java system properties in conjunction with two other features of the server: the Properties Service and the fact that JBoss parses all XML configuration files (including J2EE deployment descriptors) and resolves ${references} to system properties. Moreover, if you use the Spring Framework in your application, you can also leverage its PropertyPlaceholderConfigurer to retrieve configuration information from Java system properties.
As shown above, the main idea is to store configuration information as properties files in a Subversion repository and have the different JBoss Application Server retrieve these configurations through HTTP and thanks to this kind of configuration of the Properties Service (in properties-service.xml):These system properties will then be loaded at JBoss startup time (or on any modification, like a touch, of the properties-service.xml file) and will be available for use in many different places like:
- XML server configuration files that configure ports and host names (for web server, invokers, JNDI tree...),
- J2EE deployment descriptors to avoid hardcoding of parameters (like user name and password used to connect an MDB to a remote JMS destination),
- application parameters provided they are read from Java system properties (which is easy and nice to do if you use Spring).
Another interesting feature of the Properties Service to leverage is the fact you can provide a list of URLs: all the properties will be loaded from these URLs, the latest ones having the precedence on the first ones. This can be used to organize configuration in a hierarchy, with global settings, server specific settings and application level settings loaded from a common place and mixed together in the Java system properties. Here is an example of such a configuration:
As you can see, not only is JBoss a versatile application server, but it is also an extremely configurable one that can be easily tuned to fit the needs of large companies with complex deployment constraints.
Labels:
Tools
Saturday, November 04, 2006
New Position: File Name Manager at Oracle Corp.
Goals:
To fully enjoy this post, go to these pages (9i, 10g & 10gR2) and download the different versions of the JDBC driver: you can not miss them, they are all named ojdbc14.jar. You can then try your skills by figuring out sensible names for these files!
- Rename Oracle JDBC driver file names so they actually differ between different versions,
- If possible, improve the manifest files so there is more difference than the "Implementation-Time" attribute between two different versions.
- A true desire to help developer teams and production departments making sense of the different driver releases.
To fully enjoy this post, go to these pages (9i, 10g & 10gR2) and download the different versions of the JDBC driver: you can not miss them, they are all named ojdbc14.jar. You can then try your skills by figuring out sensible names for these files!
Labels:
Hiring
Sunday, October 29, 2006
A 16 Months Iteration
I have finally been able to release a first alpha version of jinFORM, 16 months after the project started. The title is voluntarily provocative: it was not an iteration but a slow maturation!
Why did it take so long? As explained in jinFORM news, part of the time has been spent waiting for a presentation server able to render some much needed features of XForms 1.1. Initially, Chiba was targeted as the presentation server but testing and experiments have finally pushed the project to use Orbeon Presentation Server, which offers a more stable XHTML + JavaScript rendering, a better compliance to standards (XForms, XML Pipelines...) and the much needed XForms 1.1 features mentioned before.
So, what is jinFORM 0.1.0 worth? Not much for production: you can only fill simple forms with repeating sections, but without computation or logic. The only submission that is currently supported is for saving the XML instance built by the form behind the scene.
Then, was it worth the effort and why should anyone care about this project? Well, anyone with a slight interest in the intimates of Microsoft Infopath file format (aka XSN) should be interested to see how jinFORM transforms this proprietary form definition to XForms.
Because an XSN file is simply a CAB stuffed with XML, XSL and extra files, described with a documented manifest, groking its content is fairly easy. Doing anything with it is another thing. Take the XSL for view rendering (usually named view1.xsl) that is generated by Infopath. Because this XSL relies on implicit MSXML objects for supporting many extension function calls, jinFORM has to pre-chew it and implement similar functions in order for anything to work.
When designing this XSL, Microsoft, of course, had anything but elegance or portability in mind. It is cluttered with prescriptive commands like xsl:for-each, traps like testing for the existence of a function and using another one and oddities like using a function to retrieve the current document on which this XSL applies. Surprising approach from Microsoft? After they love functions and procedural programming: why would they embrace the template concept that is underlying XSL transformation?
There are still many things to add in jinFORM to make it really usable but it is a good first step. Foundations have been laid, now let's build on it!
Why did it take so long? As explained in jinFORM news, part of the time has been spent waiting for a presentation server able to render some much needed features of XForms 1.1. Initially, Chiba was targeted as the presentation server but testing and experiments have finally pushed the project to use Orbeon Presentation Server, which offers a more stable XHTML + JavaScript rendering, a better compliance to standards (XForms, XML Pipelines...) and the much needed XForms 1.1 features mentioned before.
So, what is jinFORM 0.1.0 worth? Not much for production: you can only fill simple forms with repeating sections, but without computation or logic. The only submission that is currently supported is for saving the XML instance built by the form behind the scene.
Then, was it worth the effort and why should anyone care about this project? Well, anyone with a slight interest in the intimates of Microsoft Infopath file format (aka XSN) should be interested to see how jinFORM transforms this proprietary form definition to XForms.
Because an XSN file is simply a CAB stuffed with XML, XSL and extra files, described with a documented manifest, groking its content is fairly easy. Doing anything with it is another thing. Take the XSL for view rendering (usually named view1.xsl) that is generated by Infopath. Because this XSL relies on implicit MSXML objects for supporting many extension function calls, jinFORM has to pre-chew it and implement similar functions in order for anything to work.
When designing this XSL, Microsoft, of course, had anything but elegance or portability in mind. It is cluttered with prescriptive commands like xsl:for-each, traps like testing for the existence of a function and using another one and oddities like using a function to retrieve the current document on which this XSL applies. Surprising approach from Microsoft? After they love functions and procedural programming: why would they embrace the template concept that is underlying XSL transformation?
There are still many things to add in jinFORM to make it really usable but it is a good first step. Foundations have been laid, now let's build on it!
Labels:
My OSS
Subscribe to:
Posts (Atom)