Jan 21

The “killer app” phenomenon

Java, JavaScript, PHP, Tech 3 Comments »

Cedric is talking about the killer app phenomenon as it related to programming language. Of course, the term killer app doesn’t quite fit so well with languages, but the abstract concept is “reason it hit a tipping point”.

For Java it wasn’t the Applet as Cedric pointed out. I think it is a mix of:

  • No more memory management (language feature)
  • C like (not a huge leap)
  • JVM worked OK on the server side (although a bit crap at first, ended up becoming top notch)

For PHP though, I think it is much clearer:

  • Deployment. PHP was built for the Web. Remember how painful Perl was back then? PHP fit the jump from CGI to “oh, to do rich dynamic stuff we can’t fork() every time”. PHP was easy to setup with Apache, it just worked, and soon it was deployed on all hosting providers. This is why it is still a winner for so many people
  • Simple, scripting based: easy to go from Perl to PHP. Easy enough for the people who liked the deployment issue to hack away (e.g. the non CSci folk)

And JavaScript? The killer app was Netscape, and the fact that it was like PHP in that people could hack away.

Jan 07

Andi Gutmans Predicts

PHP, Tech with tags: , 1 Comment »

Andi Gutmans, of Zend, has put together his own list of predictions for 2008.

Andi is a really good bloke. I met him a few years back when I actually advised Zend on a couple of matters. What impressed me the most was how rounded he was. He wasn’t a “PHP is better than anything else out there” kind of guy. He appreciated aspects of other platforms, and we had some good chats about Ruby and Java. It was a real pleasure, and it caused me to take on a serious project in PHP. I had scoffed at 5000 functions in one global namespace, but there were things about PHP that I actually enjoyed, mainly from a pragmatic stand point (deployment was one!).

Let’s take a look at his thoughts:

Java on the Web continues to lose market share

This depends on what you mean by “Java”. I think that the JVM could be used more and more for deployments, even though Andi thinks that it is ill suited. LAMP is nice, but the JVM has some advantages, although it has some serious disadvantages too.

I do think that the Java community has been spreading. Some jumped on Rails. Others tried .NET. Others are playing with Python. Adventurous ones are playing with Erlang. Not all are abandoning the Java platform though. As well as staying with the new world of Spring Web Flow, Seam, Tapestry 5, and Struts 2, others are on the VM with Grails. Some of the folk that jumped to Rails are looking back at JRuby to get a better deployment model, or integration.

2008 will be a mixed year for Java, but not necessarily a bad one.

The next layer of the virtualization eco-system will start thriving

This looks exciting. I do hope that we get there in the next year or so. I want to get a computer that has a few hosts installed for me all under virtualization.

Hybrid Rich Internet Applications become an accepted “standard”

We have seen Microsoft and Adobe both giving lip service to the Ajax crowd. AIR has good support for Ajax applications. Using the Webkit engine is great, but a browser is more than a renderer, and I look to see the implementation to grow in 2008. For example, I want more plugin support (other than Flash).

I agree with Andi that noone is going to “win” this one. Flex will do well. Ajax will do well. I obviously hope that the Open Web will progress a lot with new browsers, and with Gears there to innovate, push, and be there as a platform to prop up browsers that don’t do their job.

I am not sure that I agree with the importance of the Open Ajax Alliance piece. I have yet to see anyone other than vendors talk about it. No-one seems to care.

“Hardware On Demand” becomes real

I don’t want to deal with a hosting provider anymore. I want to develop an application with a new tool (probably web based) that allows me to work through the entire develop, debug, publish lifecycle.

One of the major non-Eclipse vendors will lead a new Eclipse.org tooling project

I have mixed opinion here. I am not an Eclipse fan. It feels bloated. I don’t get “perspectives”. It suffers from not having a dictator on top making sure that it all works well together. Instead you get a million plugins. Aptana has done a good job at using Eclipse but having it not really look like Eclipse.

What about PHP?

I wonder what 2008 will be like for PHP, Andi. I have no doubt that it will continue to power a huge number of websites. But, what is PHP doing in 2008 to increase its share in the non-hacker-kiddie crowd? Is the Zend Framework going to compete with Rails and the like? How is PHP going to evolve? I want to be able to do richer DSLs with full open classes and meta-support.

Dec 16

Running PHP in your J2EE server?

Java, PHP, Tech 106 Comments »

Caucho has a cool feature in their new server. They have PHP integration via their Quercus, a PHP implementation in Java.

To use PHP you can just register a PHP servlet (com.caucho.quercus.servlet.QuercusServlet).

You can also tie in PHP code to call any Java code via:

package example;

import com.caucho.quercus.module.AbstractQuercusModule;

public class HelloModule extends AbstractQuercusModule {
public static String hello_test(String message)
return "Hello, " + message;

and then using it like:

<?php echo hello_test("World") ?>

Another example of using Java as the platform, and various dynamic languages on top. JRuby. come to papa. Ruby on Rails on JVM.

Dec 01

God forbid you have extra space at the end of your PHP file!

PHP 2 Comments »

While working on an Ajax app using PHP on the server, I have had an interesting time seeing the quirks of PHP.

The first item to get used to is being in HTML mode by default, so when you want to write real PHP classes and such in their own files you have to make sure to have the magic:


… your code …

Normally this isn’t a huge deal and you find out quickly.

Recently though a developer made some changes and suddenly no output was to be seen in their area of code. From looking at the errors it told us that “headers can’t do anything since you have already started to write to the browser”. It turned out that the developer had put in a new file, and it had an extra bit of space at the end of the file.

A PITA for sure. So, now we have a script to check for this :)

# --------------------------------------------------------------------------
# seekingalpha-checkphp - make sure extra space isn't at the end of PHP files
# --------------------------------------------------------------------------

if (@ARGV < 1) {
print "checkphp: need file(s) to check\n";

foreach my $filename (@ARGV) {

my @contents = readFile($filename);
my $IS_SPACE = 0;

foreach (reverse @contents) {
if (/\?\>/ and $IS_SPACE) {
print "Warning: check PHP file: $filename\n";
next FILE;

if (!/^\s*$/) {
print "PHP file OK: $filename\n";
next FILE;
} else {
$IS_SPACE = 1;

# --------------------------------------------------------------------------
# Functions
# --------------------------------------------------------------------------
sub readFile {
my $filename = shift || die "readFile: need a filename";

open FILE, $filename or die "readFile: couldn't open $filename\n";
my @contents = <FILE>;
close FILE;

return @contents;
Nov 09

Symlinks and directories, versus EAR files

Java, PHP, Ruby, Tech 4 Comments »

Another post in the realm of dynamic platforms, and this time my thoughts are on deployment.

I have been working on a large web application, that is now in production.

The project before this one was on a large stack (WebSphere) and the deployment was a nightmare.

In development we had simple war’s and developers were all setup with expanded versions so they weren’t wasting time ziping up changes for a simple text change :)

However, the deployment issues were another story. They needed to be ear’d and run through a million checks on this, that, and a bit of the other.

We had to have our build system scripted to handle this all, and there were constant problems.

From that, I am now on a system where there are no such beasts as EARs. You just have good ole files and directories that the server looks too. Development is pretty much the same as deployment (bar a few optimizations that are taken care of via environment).

To jump between releases we can easily change a symlink and we are moved. An issue? we can move right back. No need to deploy/redeploy/undeploy in containers.

Bah I hear you scoff. What about all of the tools for deployment! How mickey mouse is this file based crud!

We have nice scripting via tools like Switchtower, which handles deployment very nicely indeed, and is easy to extend to do you will.

Lighter, and yet simple. Switchtower is still new-ish, so it may not do everything that you need in your deployment world… but it is getting there.

Oct 20

Zend PHP Framework, and Eclipse member

PHP, Tech No Comments »

Zend has stepped PHP up to the plate lately. At their conference they just announced the Zend PHP Collaboration Project:

The Zend PHP Collaboration Project is an open source initiative through which the PHP community and Zend’s corporate partners will create an industrial-grade, de facto standard PHP Web application development and deployment environment, said company co-founder and CEO Doron Gerstel.

To begin with they have a web based framework, and then they have tools on top of this, created in the Eclipse foundation.

The heavy hitters at the conference were Marc Andreessen and Rod Smith (of IBM)

Marc came out hitting with “the simplicity of scripting language PHP means it will be more popular than Java for building Web-based applications.

He also said:

“My new company is running a combination of Java and PHP. This is something I get no end of crap about”

The hardest problem for PHP to get over is the stigma.

I hope Zend takes PHP to the next level, gets it into the enterprise, and we see more competition :)

Oct 20

Zend PHP Framework, and Eclipse member

PHP No Comments »

Zend has stepped PHP up to the plate lately. At their conference they just announced the Zend PHP Collaboration Project:

The Zend PHP Collaboration Project is an open source initiative through which the PHP community and Zend’s corporate partners will create an industrial-grade, de facto standard PHP Web application development and deployment environment, said company co-founder and CEO Doron Gerstel.

To begin with they have a web based framework, and then they have tools on top of this, created in the Eclipse foundation.

The heavy hitters at the conference were Marc Andreessen and Rod Smith (of IBM)

Marc came out hitting with “the simplicity of scripting language PHP means it will be more popular than Java for building Web-based applications.

He also said:

“My new company is running a combination of Java and PHP. This is something I get no end of crap about”

The hardest problem for PHP to get over is the stigma.

I hope Zend takes PHP to the next level, gets it into the enterprise, and we see more competition :)

Sep 25

War of the Web: Revenge of the Dynamics

Ajax, HTML, Java, JavaScript, Lightweight Containers, Microsoft, PHP, Perl, Ruby, Tech, UI / UX, Web Frameworks 933 Comments »

As I was watching “24 hour party people” on DVD, I heard the main character talk about the ebbs and flows of the music business. He is talking about the scene in Manchester at the end of the 70’s, and into the eighties. Moving from Joy Division to Happy Mondays and New Order.

I think that we are in a new chapter for the web, and as is often the case, the wheel of time is repeating history for us.

There are a few dimensions to the current war though. They are on the client side (DHTML Ajax vs. simple HTML vs. Flash/PDF vs. XAML) and on the server side (Rails vs. Java vs. PHP vs. .NET).

Let’s start at the beginning.

Perl: Birth of CGI

Do you remember how the web changed as it moved from static HTML connected content to dynamic websites? That came about due to CGI, and how our nice web server would now fork off our programs to generate the HTML.

I remember my first CGI programs were written in C, and Scheme. I quickly moved on though, and found the beauty, and craziness of Perl.

I spent quite some time with Perl, trying to get by without writing too much NSAPI and ISAPI code (oops, I guess that core dump hurts the entire server?).

I really enjoyed the community at that time. #perl was interesting (some of the time), and CPAN became the holy grail. As soon as you thought you needed something, someone had kindly put that functionality up into CPAN. I even have some of my own modules hanging out there, and helped with others.

Over a short time period, we had developed some fairly rich web modules. We didn’t have to work with $ENV{’SOME_CGI_ENVIRONMENT’}, or STDIN or the like. Our framework abstracted all of that for us, and gave us a simple model. We lauched at the folks who generated html via methods such as b("whee") and we stuck close to HTML itself, allowing our design teams to simply open the html files and see what their stuff looked like. We even had the notion of components, and special tags that you could create. <$mytag name=”…” /> was nice because the name of the tag was the key for the framework to dynamically discover that functionality. No config files, or interfaces, in the strict sense. The coupling was based on a name.

In retrospect, life was pretty simple for web development, a lot simpler than some of the frameworks we have today!

But, we moved from Perl. CGI was not the nicest for our high load servers. It was crazy to think that we would fork a process for every little request that came in, and that a Perl interpreter would start up, load the program, do the work and then die off.

We naturally moved to solutions such as mod_perl, and that helped. It was so new though that it was buggy and we had a lot of problems. Some of the problems had nothing to do with mod_perl itself, but due to laziness and side-effects.

When you work in an environment like CGI you can be a very bad man indeed. If you don’t close something correctly, or don’t play totally nice with resources, baaaah who cares? The server is going to kill me in 2 seconds anyway, so I will get my job done and have him kill me. In mod_perl world though, these programs start to live longer, and they get fat and oily.

Java: No more stinking processes!

Remember the beginning of Java (Oak!). We were building applets, and feeling the pain very early on.

Servlets were the big thing though. We ported our Perl based framework over, and were able to see significant performance improvements at the time. Some of the team loved the change, others hated the verboseness and static typing.

The nice threading model that Java gave us was huge though, even with the poor JVMs back then (Microsofts was by far the best remember!).

This is when we moved from the world of Perl to having Java start to take over. That isn’t to say that there wasn’t competition. In the waters we saw the lurkers of ColdFusion, ASP, and the beginning of the PHP revolution. Java came up with JSP to compete with these tag based approaches, but it was the advent of the rich MVC style frameworks that really spurred everyone on.

In my opinion Java is still in the hot-seat, especially in the corporate world.

Preparing for the server war

The troops are being gathered. Strategies are being worked out. We are currently getting ready for a new battle on the server side.

What’s happening?

  • Ruby on Rails: Whatever you think about Rails, it has lit a fire under the server side web development community. Many have jumped on the bandwagon, claiming real productivity improvements. Some of the PHP converts enjoy a richer language, which is still nice and dynamic, with a framework that enforces clean MVC techniques. Some of the Java community are frankly a little bored of Java, and enjoy the new challenge. They also love the freedom of the language, and the fact that they now have just ONE stack to worry about. Will the Rails buzz keep growing? Will it be the Perl of Web 2.0?
  • Java: Java isn’t going down without a fight. Some argue that the problem with web development in Java is that it has been too complicated and heavy for much usage. I have personally called for the need of a common stack for Java, and people have stepped up to the plate. On one side we have companies that will certify a set of technologies (JavaServer Faces + Spring + Hibernate). Then we get frameworks taking on simplicity themselves (WebWork now embedding Spring). Finally we have initiatives like JBoss Seam, which is trying to combine the component models of JavaServer Faces and the backend. Seam aims to give you the power of the Java tier, but also giving you a simple productive environment. So, Java frameworks are rising to the challenge of Rails, and we will soon see how much of the success of Rails is Ruby, and how much can be duplicated in other platforms.
  • PHP: We can’t discount PHP. A lot of “serious engineers” (read: anyone who isn’t a PHP developer thinks they are serious) poo poo the PHP world. Yet, by all accounts, there is a LOT of PHP development going on out there. PHP has the advantage of being something written JUST for the web. Take a look at how Wordpress came along (PHP based blogging software) and in no time at all there were thousands and thousands of plugins that you could simply drop into your Wordpress system. Literally, you drop in a file and you are done. There are numerous PHP frameworks that are aiming to mimic, and compete with Rails, so we can’t forget about these guys. The question with the PHP community is: will it grow more into the enterprise, or will it be for script-kiddies.
  • .NET: Never discount Microsoft. ASP.NET keeps getting more productive, and it is hard to compete with their end to end story, which includes fantastic tooling in their latest Visual Studio. And, we get Avalon and XAML along for the ride, as well as the futures of C# 3.0 which takes a lot of ideas from the dynamic languages and puts them into a static structure (such as: var foo = new Bar(); and the relational/xml integration)

It is going to be an interesting couple of years, as all of these platforms mature, and take eachother on, trying to get mindshare!

Client Side: JavaScript is cool again

But what about Ajax? The battle for the client side is going to be just as hot as on the server. And they will even intertwine with eachother.

Firstly we have the big debate of how far Ajax is going to go. Is it a one hit wonder? or will it become a standard part of our toolbox and even just be called dhtml again?

As an Ajaxian, I obviously have my thoughts on this matter. But there is a lot of competition inside and outside of Ajax:

  • Flash/PDF: Adobe/Macromedia are a definitely force to be reckoned with. Flash is almost ubiquitous, and PDF is used everywhere. Now the companies are combined, what do they have in store for us?
  • Avalon/WPF/E/XAML: Microsoft announced WPF/E, which is a subset of XAML that will be ported on various platforms and available in many browsers. This means that you can build your rich application in the .NET set of tools, and have it run in Safari on Mac OSX. Impressive. When are we actually going to see this in a form that we can deploy to the real world?
  • HTML: How much do we want to work in the open (ish) world of HTML. A large group of developers do not want to jump into any monopoly, and will therefore want to stick to a more open environment. But, another set will just want to use the best tool to add business value. What will the split be?

JavaScript will play a big role in this war. JavaScript 2.0 offers big improvements, that many people will cheer for. Also, the same people who poo-poo’d JavaScript in the past have come to realise that it really is a great language. It may not be what they are used too (it uses prototype-based OO vs. class-based OO), but it is powerful and robust. There are some features missing, and a big question around libraries. JSAN and others are trying to build a CPAN for JavaScript. We also worry about the black box of the JavaScript VM in the browsers, and cross-browser bugs are truly real painful. Fortunately, frameworks like Dojo and Prototype are trying to help us out on that front.

We are also seeing that we need to take JavaScript from the former:

“That is just crappy code that the web dood View-Source’s and pastes into the web pages”

to the future:

“JavaScript also needs to be engineered, and is a first class citizen”

Thus we finally see more unit testing of JavaScript code, and professional ways of creating modules and namespaces for our code. We also see great advantages with features like E4X where XML becomes a native type.

JavaScripts increased popularity, thanks to Ajax (and Flash/ActionScript) has also drawn it into the server side. Mozilla Rhino gives you a quality Java-based approach, so why not use a cool dynamic scripting language for certain tasks on the server side? You don’t have to use JavaScript for everything, but it has its place, and that place is growing.

The Battles Join

This is where the battles are joining. We have JavaScript bleeding across the layers, and we have the need for server-side frameworks to support the new Web. It isn’t enough to generate simple HTML and be done with it.

Today’s frameworks need to be able to help us build Ajaxian components, and help us write this applications quickly and cleanly.

There are various directions that frameworks are going in here.

  • JavaScript Code Gen: Why not give you a simple macro that splits out the ugly JavaScript that you would have to write?
  • JavaScript Framework Code Gen: Spitting out low-level JavaScript is too much work. Many frameworks are writing on top of a higher level JavaScript framework like Dojo or Prototype. Now the code-gen is less, and you get the benefits of the rich functionality, browser compatibility, and visual effects available from these frameworks.
  • Tools and Widgets: Should developers even care if a piece of their page is Ajax or not? Some frameworks give you drag and drop editors that let you setup widgets or components. Some happen to be ajaxian. Some are not. Who cares?
  • Markup based: A lot of frameworks are giving us markup based solutions. That is one of the strengths of Microsoft Atlas, not the fact that they added support for $() etc. Are we going to want to build using markup or via programatic APIs?


It is hard to predict the winners of the new battles, and the losers will not die off totally, but it is an exciting time to be watching web development. The dynamic languages of Ruby, JavaScript, and PHP are making a big run, and people are realising that they aren’t just cheesy scripting languages that can’t be used. It’s time to take them serious.

We are going to start really working out what makes sense for usability on the web with rich interfaces. And, at the same time we will get simpler and simpler backend tools to make the generation of rich web experiences easier and easier.

I am looking forward to seeing this battle!

Aug 23

Write PHP in Perl with PHP::Interpreter

PHP, Perl, Tech 72 Comments »

Ever written a Perl application and wished that you could write some PHP in there? Ok, probably not too often…. but now you can!

This came about via Bricolage Now has PHP 5 Templating and how:

And finally