Why Free Software Sometimes Hurts

I've been assigned to evaluate a free software, which is a PHP package. I downloaded the package and read through a very brief "readme.first" document. Which indicated that it requires Apache, PHP, and mySQL. Though I never installed PHP before. I thought such combo is a very common and popular combination and I didn't expect too much twist and turn.

First I installed Apache 2.2 for Windows. I had done that thousands times in my life. Then I downloaded and installed PHP5 for Windows. The installer provides automated config for Apache. Pretty!! Finally, I installed mySQL and got it up and running right away.

Everything was ready. I copied the PHP package under the web root and tried to start it. Dada!! Failed. An error message was found in the error log which looks like a program bug in the PHP package. I went through the manual of PHP and asked someone who know PHP better than me. Finally after one day of struggling, I got it working. In fact it could be much simpler. Let see why it took me so long.

1. The PHP5 installer do insert some lines to httpd.conf to load the PHP Apache module, but it forgot an "AddType" statement. I have to add it myself after I found that it is necessary, consulting the installation document.

2. Most PHP programmers use "<? ... ?>" to surround PHP code in the PHP files. While some other PHP tutorial suggest it can also be done like "<?php ... ?>". All files in the PHP package I was evaluating use the pattern "<? ... ?>". However, the default setting of PHP enforce us to use "<?php ... ?>". There is a tiny switch in the config of PHP to enable the use of "<? ... ?>". I need to turn on the switch to make the package work. Hey, why the switch is not turned on by default? Seems to me all PHP programmers prefer the shorter form.

3. Third issue is the connection with mySQL. After more reading of PHP manual, I found that the mySQL connection component is no longer included in PHP5 by default. It turns out that I needed to do 3 things for mySQL connection. First one is I needed to change the "PATH" environment string to let the system found the file "libmysql.dll", which is provided by mySQL. Second is I needed to re-run PHP5 installer to add the mySQL extension for PHP. Finally I modified PHP config for loading the mySQL extension into memory. Why can't they better document these procedures?

Sometimes free software may cost your valuable time in a unexpected way. For some other software which you need to pay, you can call technical support and get your problem solved right away (well, sometimes it may take longer). Luckily I'm never a great fan of PHP.

Under the hood of J2EE Clustering

A very nice article about Clustering in J2EE server. Worth a read.

Click here to read.

Stored Procedure, use or not?

Today I found a discussion about using Stored Procedure for all database call in a software application in here.
The debate have been continued for about 2 years. This is one of the typical software design question that have no absolute yes or no answer. When dealing with this kind of question, developers usually analyze the question in terms of pros and cons, but if we go back and consider the non-function requirement first. It will be easier for us to figure out which solution is better in all situations.
First we consolidate all non-function requirement here, definitely most of them can be achieve with or without using stored procedure, but usually for certain requirement, one solution is better than another. So after we build the full list, we'll have a rule set that can help us to determine we should or should not use stored procedure in our own scenario.

1. Performance
   Usually this is the strongest reason for using stored procedure. Without doubt SP can make database operation faster. However it is also a typical remedy to poorly written queries and poorly designed schema. If you believe in the good old 80-20 rule, doing all DB operation in SP is a waste of development effort. With modern profiling tools it is easy to separate slow queries from others. So you just need to tune those queries that really matters. Or wrap them up in SP. On this point, I think a mixed approach is more suitable.
   
2. Database Portability
   Stored procedures are never portable, but such portability is not always required. Many enterprise use one single RDBMS product and never change. Usually, under two scenario this requirement is necessary:
   
   
   
   1. You application is a product and your end-users can use it on top of different DB
   2. plan to use a different DB with your application in the future.
      
3. Security
   This is usually necessary if you have more than one applications accessing the same DB, so you may just grant certain application to access SP that it really needs, and hiding the entire schema. However, that means you are using the DB as a point of application integration. It may be the only way before we have other application integration technology like MQ or web service. If you have only one application accessing one DB, and doing the integration outside DB. Why you need SP for security?
4. Service Interface
   SP can be treat as interface of service for your application, but now web service is a better way to do so.
   
5. Unit Testing
   No matter you use SP, or data access layer with plain SQL, you have lots of ways to do unit test. So no difference.
6. SP as business logic layer
   PL/SQL and T/SQL is not a good language to implement complicated business, better do it in business service layer.
7. SP as a layer to maintain data integrity
   SP may be a more nature place for maintaining data integrity. Though there is no big different if you do it in the data access layer.
   
8. Stop the ripple effect of DB change
   Both SP and data access layer can do the same job.
   

Finally I want to point out another down side for accessing to DB with SP only. Such practice will easily direct developers to produce a too database centric design. And put too much loading to the DB server. As a matter of fact DB usually is a component that is most difficult to scale up. In contrast, the mid-tier can be scale up easily with modern load balance technology. No matter we use SP or not, we can do some trick like cache to reduce the number of DB access. That can also enhance the performance.