I've been using Gentoo on my Linux servers for the past several years, and it's a very nifty piece of software/distribution. Although compiling all the required packages can be a bit slow, the installation process is very well documented. I can testify that that installing Gentoo takes less than 24 hours, the working days for a basic system (including X windows) and the night to compile KDE. The other components, such as JDK, Apache, Tomcat (or Resin) take another hour or two.
Normally, it should be even quicker than that. The aforementioned figures are based on my latest experience installing Gentoo on a virtual PC on my Windows XP laptop using VMWare. Running Linux on my laptop allows testing software that runs comfortably only on Linux
As you might have guessed, I am extremely happy with the results. If you occasionally need to perform testing on a Linux server, I recommend running one with VMWare+Gentoo combination.
Thursday, April 27, 2006
Tuesday, April 25, 2006
1st chapter of Tapestry in Action
I just finished reading the first chapter of "Tapestry in Action" by Howard M. Lewis Ship. I really like the style of the author. The introductory chapter clearly explains the conceptual differences between Struts, a servlet controlled framework, and Tapestry, a component controlled framework. The author also does a very good job of pointing out the weaknesses in Struts.
After 4 years of Struts, I am a little scared of the different programming model. Nevertheless, I can't wait to read the rest of the book to see if Tapestry lives up to its promise.
After 4 years of Struts, I am a little scared of the different programming model. Nevertheless, I can't wait to read the rest of the book to see if Tapestry lives up to its promise.
Monday, April 24, 2006
XML ain't a programming language
I happen to consider Spring a pretty nifty framework. Actually, many of the developers I know consider it nifty and I don't have any reasons to object. It is well-documented and rich in functionality.
After spending a day reading the documentation, I came to the conclusion that I had not understood it well enough and resolved to reread it at a later time.
The ability to configure a large application at deployment time through configuration files is hardly a new concept. Every Servlet container does it. Log4j does it. Logback does it, as well as any serious framework with an emphasis on flexibility and extensibility. Logback uses Joran package for its configuration parsing. Joran is derived from Jakarta Digester. Although amazingly powerful in certain aspects, as Jakarta Digester, it is not a general bean definition package.
IOC frameworks offer functionality beyond Digester derived configurators, in particular the ability resolve circular bean dependencies. You can configure many if not hundreds of beans using Spring. Unfortunately, this will cause your beans.xml to balloon to gargantuan proportions.
It seems that Spring allows a beans.xml file to be broken to smaller chunks by importing bean definitions from another file. I find it far more difficult to read bean definition files in XML than Java code. The difficulty increases exponentially with the size of the bean definition file. However, according to the documentation, the list of imported files must precede beans definitions in the importing file – a rather severe and unexpected restriction to say the least.
My impression is that IOC frameworks such as Spring need to offer support for a very large set of tools to be useful. Sucking in ever larger parts of the Java universe, it reinvents the Java language in XML. However, XML does not make a fun programming language.
I wonder if it is possible to deliver the promise of IOC non-intrusively and without resorting to large XML files.
Interestingly enough, unit testing presents a similar set of problems. However, as larger and larger portion of the Java universe gets mocked, we get farther and farhter away from the sprit of unit testing. Altough configuring unit tests is sometimes a non-trivial task, as far as I can tell, unit testing does not seem plagued by large config files in XML.
After spending a day reading the documentation, I came to the conclusion that I had not understood it well enough and resolved to reread it at a later time.
The ability to configure a large application at deployment time through configuration files is hardly a new concept. Every Servlet container does it. Log4j does it. Logback does it, as well as any serious framework with an emphasis on flexibility and extensibility. Logback uses Joran package for its configuration parsing. Joran is derived from Jakarta Digester. Although amazingly powerful in certain aspects, as Jakarta Digester, it is not a general bean definition package.
IOC frameworks offer functionality beyond Digester derived configurators, in particular the ability resolve circular bean dependencies. You can configure many if not hundreds of beans using Spring. Unfortunately, this will cause your beans.xml to balloon to gargantuan proportions.
It seems that Spring allows a beans.xml file to be broken to smaller chunks by importing bean definitions from another file. I find it far more difficult to read bean definition files in XML than Java code. The difficulty increases exponentially with the size of the bean definition file. However, according to the documentation, the list of imported files must precede beans definitions in the importing file – a rather severe and unexpected restriction to say the least.
My impression is that IOC frameworks such as Spring need to offer support for a very large set of tools to be useful. Sucking in ever larger parts of the Java universe, it reinvents the Java language in XML. However, XML does not make a fun programming language.
I wonder if it is possible to deliver the promise of IOC non-intrusively and without resorting to large XML files.
Interestingly enough, unit testing presents a similar set of problems. However, as larger and larger portion of the Java universe gets mocked, we get farther and farhter away from the sprit of unit testing. Altough configuring unit tests is sometimes a non-trivial task, as far as I can tell, unit testing does not seem plagued by large config files in XML.
Wednesday, April 05, 2006
Race condition at the post office
Although only the fourth or fifth largest in Switzerland, the city of Lausanne currently possesses the biggest post office in the country. This post office is located at Place St-Francois at the center of the city. When you enter the post office, you are greeted by two ticketing machines, one at each entry of the office. After pressing a button, the machine spits out a ticket with a number printed on it. You wait until your number is displayed on one of the large and clearly visible digital panels hung at opposite ends of the office. When it's your turn, the panel chimes and then displays your number next to a letter, 'A' through 'R', symbolizing one of the 18 counters, each manned by a clerk.
My ticket read 811, with an estimated waiting time of 5 minutes. During those five minutes I got distracted and nearly missed the call for my number by counter 'N'. Actually, after several unanswered calls to my number, the clerk at counter 'N' gave up on 811 and called the next customer, in this case customer number 815. During the 20 or 30 seconds in which I failed to respond other counters summoned numbers 812, 813 and 814. Fortunately for me, I arrived a second before customer 815, and the clerk had already started serving my requests. Thus, ticket number 815 was consumed, with its owner stuck behind counter 'N' until I was done. There was no way for the clerk, who became aware of the problem, to resuscitate ticket 815 so that its owner could be more quickly served by one of the 17 other counters.
How would you design a ticketing service which would be simple to use for the clerks and still avoid race conditions?
After thinking more about this problem, I am beginning to think that contrary to the consequences of race conditions occurring in entirely automated systems, humans cope extremely well with inferequent race conditions -- or at least in this case we did. It was spontaneously obvious for all participants that customer 815 needed to wait patiently until the disrupting client (yours truly) was served. Thus, I tend to think that in presence of unintentional mistakes the current system is just fine as it is.
However, a malevolent customer could reproduce the aforementioned race condition at will. In an easier and totally devastating attack, the customer, or should I say foe, could ask the ticketing machine for n tickets instead of a single ticket.
It is infinitely harder to design systems capable of thwarting malevolent participants than systems dealing with distracted but otherwise benign users.
My ticket read 811, with an estimated waiting time of 5 minutes. During those five minutes I got distracted and nearly missed the call for my number by counter 'N'. Actually, after several unanswered calls to my number, the clerk at counter 'N' gave up on 811 and called the next customer, in this case customer number 815. During the 20 or 30 seconds in which I failed to respond other counters summoned numbers 812, 813 and 814. Fortunately for me, I arrived a second before customer 815, and the clerk had already started serving my requests. Thus, ticket number 815 was consumed, with its owner stuck behind counter 'N' until I was done. There was no way for the clerk, who became aware of the problem, to resuscitate ticket 815 so that its owner could be more quickly served by one of the 17 other counters.
How would you design a ticketing service which would be simple to use for the clerks and still avoid race conditions?
After thinking more about this problem, I am beginning to think that contrary to the consequences of race conditions occurring in entirely automated systems, humans cope extremely well with inferequent race conditions -- or at least in this case we did. It was spontaneously obvious for all participants that customer 815 needed to wait patiently until the disrupting client (yours truly) was served. Thus, I tend to think that in presence of unintentional mistakes the current system is just fine as it is.
However, a malevolent customer could reproduce the aforementioned race condition at will. In an easier and totally devastating attack, the customer, or should I say foe, could ask the ticketing machine for n tickets instead of a single ticket.
It is infinitely harder to design systems capable of thwarting malevolent participants than systems dealing with distracted but otherwise benign users.
Subscribe to:
Posts (Atom)