Netuality

Nice excerpt from an Inc. article :

Future Beef's real albatross, says Darrell Wilkes, was an expensive computer system that ran enormously complex software from J.D. Edwards. “We were pouring all this data in, but we could never get the data out,” says Wilkes, whose job, as the company's cattle and supply expert, was to monitor the progress of about 300,000 head of cattle. And these weren't just any cattle. These were Future Beef cattle, raised by ranchers who met its standards for feeding and monitoring their herds. Wilkes had to keep track of which steers had been given certain region-specific mineral supplements, which had been fed their necessary doses of vitamin E, which had been measured for yields of particular tissues and fats, and what the optimum dates were for shipping each steer off to the slaughterhouse.

When Wilkes asked his staff for the numbers, they didn't have a clue. They had not been able to retrieve the data from the computer system.

“I swore a lot, and jumped up and down a lot, but it didn't do a lot of good,” he says. “We would have been better off going in there with a very simple system. At least the simple systems give you your damn yield report.”

Click here to read the whole article.

If Trustudio Python plugin stops functioning after installing the shiny new Eclipse 3.0M3, try pydev instead. I've been using it for the last few hours – so far, so good. Well, you'll get nothing more than some syntax coloring, but that's the current level of all Python plugins for Eclipse for now.

No, I am not a seasoned PHP programmer and I do not intend to become one. But we do live in a harsh economy where all IT projects are worth considering, thus my occasional incursions in the world of of PHP-driven websites.

I am not new to PHP either, but – coming from a Java world – immediately felt the need of a serious MVC framework.
Nobody wants to reinvent the wheel each time a new website is built. Just launch the obvious “PHP MVC framework” on Google and the results pages will be dominated by four open-source projects :

• PHPMVC is probably the oldest project and implements a model 2 front controller/li>
• Ambivalence declares itself as a simple port of
  Java Maverick project
• Eocene a “simple and easy to use OO web development framework for PHP and ASP.NET”,implementing MVC and front controller
• Phrame is a Texas Tech University project released as LGPL, heavily inspired by Struts.

The choice is not easy. There are no examples of industrial-quality sites built with either of these frameworks.
(some may say there are no examples of industrial quality sites built with PHP but let's ignore these nasty people for now).

There are no serious comparisons of the four frameworks, neither feature-wise nor performance-wise.
In the tradition of open-source projects, the documentation is rather scarce and examples are “helloworld”-isms.
Yes I am a bloody bastard for pointing out these aspects – since the authors are not paid to release these projects – and perhaps I could contribute myself with some documentation. However, when under an aggressive schedule I feel it's easier to write my own framework instead of understanding other people's code and document it thoroughly.
However, I have a nice hint for you. The first three frameworks are using XML files for controller initialization (call it “sitemap”, “descriptor” or otherwise; but it's just a plain dumb XML file). So you should safely ignore them in a production environment.

Because, the “controller” is nothing more than a glorified state machine. The succession of states and transitions (or “actions” or whatever) should be persisted somewhere. XML is probably a nice choice for Java frameworks, where the files are parsed and the application server keeps in memory a pool of controller objects.

But: PHP sessions are stateless. The only way of keeping state is via filesystem or database, usually based on an ad-hoc generated unique key, which is kept in the session cookie. More: PHP allows native serialization only for primitive variables; a complex object such as the controller can not be persisted easily, so it has to be retrieved from XML and fully rebuilt. Unlike in Java appservers, objects cannot be shared between multiple session, thus pooling is not an option. Thus, in PHP, the XML approach is highly un-recommended, since this means that the XML files are parsed for each page that is viewed on the site. Although PHP's parser is James Clarks's Expat, one of the fastest parsers right now (written in C), note that the DOM object must be browsed in order to create the controller object (which is becoming more and more complex as the site grows). This is called heavy overhead, no matter how you look at it.

There are a few reasons about why you need XML in a web framework, however this does NOT apply to PHP apps. Myth quicklist:

• it's “human-readable”. Come on, PHP is stored is ASCII readable files and even if you use Zend products to compile and encrypt your code, why on earth would you allow readability and modification of the controller state machine on the deployment site ?
• easier to modify than in code. This is probably true for Java and complex frameworks, but in PHP is significantly simpler than Java.
• automatically generated from code by tools such as Xdoclet or via an IDE. If you're writing it in Java, because PHP does not have such tools.

This means that the only serious candidate (between these considered here) for a PHP MVC framework is Phrame, which stores the sitemap as a multi-dimensional hashmap. Thus, you should either consider Phrame or (for small < 50 screens) sites you'll be better off writing your own mini-framework, with a state machine implemented as a hashed array of arrays and some session persistence in the database. I chose to serialize and persist an array containing primitive variables, using PHPSESSID as the primary key in order to retrieve and unserialize the array, all coupled with a simple "aging" mechanism for these users with the nasty habit of leaving the site without performing logout first.

Finally a last world of advice : use PEAR ! This often overlooked library of PHP classes includes a few man-years of quality work. You'll get a generic database connection layer (PEAR-DB) along with automatic generation of model classes mapped on the database schema (DB_DataObjects), a plethora of HTML tools (tables, forms, menus) and some templating systems to choose from. All in a nice easy to install and upgrade package.

Don't put a heavy burden on your upgrade cycle using heterogenous packages downloaded from different sites on the web, just use PEAR.

Or simply ignore the PHP offer and wait patiently for your next Java project. Vacations are almost over.

Having recently stumbled upon this thread on Sitepoint community forums, I found a certain Mr. Selkirk advocating page controllers instead of front controller – meaning that the state machine logic is distributed in each page/state. I have some pragmatic problems with the approach since this means that a large (hundreds of pages) site would imply modifying each page if a new generic transition appears.

On this same thread, there's a sensible approach coming from an Interakt guy which I also happen to know personally [hi, Costin]. He describes PHP website design using MVC (from a controller point of view) as having 3 steps :

• Design your site with a fancy IDE which will generate a lot of XML gunk
• Let the framework compile the XML to good old PHP code, prefectly human-readable and all
• Enjoy ! Speed and structure.

Unfortunately his solution is not exactly open-source nor free, and I'll gladly use my 500 maccaronis for a shiny new flat screen. Besides, it looks like my PHP episode is coming to an end (I see some serious consulting on Java apps on the horizon). Anyway my piece of advice to Costin (as a non-customer) is “don't do any serialization, keep the code clean as the bottleneck usually comes from the database – and the world will be a better place to live”.

On a lighter note, there is John telling us cool stuff about PHP:

Does this reloading of all data on every HTTP request mean that PHP is not scalable? Fortunately, as I've said before in other posts, that's a superficial view of things. The reloading of data is precisely the reason why PHP is scalable. The way PHP works encourages you to code using state-less designs. State information is not stored in the PHP virtual machine, but in separate mechanisms, a session variable handler or a database.
This makes PHP very suitable for highly scalable shared-nothing architectures. Each webserver in a farm can be made independent of each other, communicating with a central data and session store, typically a relational database. So you can have 10 or 1000 identically configured PHP web servers, and it will scale linearly, the only bottleneck being the database or other shared resources, not PHP.

Whew ! Only if vendors 'knew' that removing state information from their appservers, it would instantly become very suitable for highly scalable shared-nothing architectures. Somenone should tell this to IMB, BEA and Sun. And maybe to Microsoft. Oh, only if the things were that simple !

PS For those wondering about my sudden passion into PHP, there is an older entry on my weblog explaining the whos and the whats.

Short sample from the rants of a software engineer temporarily converted into a lazy network administrator…

Should you ever need to install a forwarding DNS proxy on Debian, which also acts as DNS for the local network, don't even think about using Bind. This is a very powerful tool, but can be difficult to configure, definitely not for the faint at heart. The frequence of Bind vulnerabilities is sometimes worrying, and you'll have to dedicate more time to Bind administration than you dedicate to walking your dog at dawn. A dubious pleasure, especially when you don't have a dog.

Next contender is a stable, rock solid, simple to use tool : djbdns. Which might prove problematic on Debian, because djbdns and daemontools are not (yet ?) in the main distribution. A kind soul on the net offer some 'homemade' Debian packages, that you'll easily install. Then, you'll quickly remove it, since these packages do not have the slightest intention to work on the current Debian Sarge. My last choice was to compile from scratch and maintain djbdns by myself. With the fresh memories of administrating a bunch of Gentoo servers (perfectly comparable with walking a pack of 23 to 426 dogs, depending on how often you update your systems) – I decided to skip this option. Note to self : never ever maintain software packages built from source needing frequent manual updates.

Hopefully, there's dnsmasq to save the day. In my case, the night. An apt-get install dnsmasq later, I have a working DNS server, resolving internal names from /etc/hosts and forwarding all the other queries to my ISP DNS servers. As a bonus, it also makes for a nice DHCP server, which I don't need for the moment but might come handy later, who knows ?

Recently, an Indian poster on a Slashdot thread ('India Outsourcers Find Back Door in Canada') mentioned that:

Software Developers in India (including me) are paid 350 times the prevailing minimum wage in India.

I thought it would be interesting to make a comparison with the same data in Europe:

• in a country such as France, this makes 402.640EUR/month.
• in one of the countries wich has recently join EU, such as Hungary, this means almost 67.000EUR/month (Hungary does not have the biggest wages in the recent wave of new EU members).
• finally in a country such as Romania which is scheduled to join EU in 2007, 350 times the minimum wage is however close to 25.000EUR/month and rising with two figures percentage in the last couple of years, due to economic growth. Romania and Bulgaria are considered the poorest countries to join EU in the next years.

Outsourcing in India is more than just a temporary industry trend … and will touch all EU as strong as it does with US. Dear US developers, would you please let us join the club ? (we'd rather not, but you know …)