Despite Sprocket or similar tools I decided to go for the plain old ANT approach. Why? It was the most practical tool, you have full control of what you are doing and the other tools did not quite what I wanted.

One part of this ant solution was to configure production setting in several source files. I rediscovered just how powerful and really simple this great tool is. Once you get used to is configure,combine,pack and deploy your php/js/html/css is a piece of cake:

Here some excerpts
In order to have just one source file I defined some custom preprocessor variables in my various files:

//@@prod@@ $config['base_dir']="";
/*@@dev@@*/ $config['base_dir']="Foo/";

<!--@@js-dev-start@@ -->
<script type="text/javascript" src="assets/js/jquery.plugin1.js"></script>
<script type='text/javascript' src='assets/js/jquery.plugin2.js'></script>
<script type="text/javascript" src="assets/js/jquery.plugin3.js"></script>
<script type="text/javascript" src="assets/js/jquery.plugin4.js"></script>
<script type="text/javascript" src="assets/js/jquery.plugin5.js"></script>
<!-- @@js-dev-end@@ -->
<!-- @@js-prod-start@@ <script type="text/javascript" src="assets/js/jsbuild.js"></script> @@js-prod-end@@ -->

then in ant this looks as follows:

<echo message="Configuring PHP config for production" />
  <replaceregexp byline="true" flags="m">
            <regexp pattern="^.*@@dev@@.*$"/>
            <substitution expression=""/>
            <fileset dir="${build.dir}" >
                <include name="php/config/*.php"/>
            </fileset>
        </replaceregexp> 
        <replaceregexp byline="true" flags="m">
            <regexp pattern="^.*@@prod@@(.*)$"/>
            <substitution expression="\1"/>
            <fileset dir="${build.dir}" >
                <include name="php/config/*.php"/>
            </fileset>
        </replaceregexp>

And for the javascript in my php – view files

<echo message="Configuring referenced Javascript for production" />
<replaceregexp flags="sg">
            <regexp pattern="@@js-dev-start@@[^\@]*@@js-dev-end@@"/>
            <substitution expression=""/>
            <fileset dir="${build.dir}/php/view" >
                <include name="**/*.php"/>
            </fileset>
        </replaceregexp>
        <replaceregexp byline="true"  flags="m">
            <regexp pattern="^.*@@js-prod-start@@(.*)@@js-prod-end@@.*$"/>
            <substitution expression="\1"/>
            <fileset dir="${build.dir}/php/view" >
                <include name="**/*.php"/>
            </fileset>
        </replaceregexp>

Applying the concat task for js and css concatenation and apply java to invoke the yuicompressor and you’re done.

On one of my favorite sites on scaling you can find out all the tricks how popular SNS and web 2.0 sites overcame the drawbacks of using such a scripting language in the long term, which served them well at the start for a quick front-end result. Why drawbacks? I agree scripting languages are actually a trend, think of Groovy or RoR, however for a solid backend with good session data handling, distributed caching, management tools, security etc. I would still prefer a compiled language, statically typed, sandboxed with security features, with all the API’s and services like Java has to offer – or maybe C#.

So thinking of todays Social Networking Applications, most require a lot of session data a combined solution: scripting in the front-end and the JVM/JEE in the backend would maybe a good solution. The backend might be a messaging layer or business logic layer with domain oriented architecture or something else.

There it comes the guys from Caucho Resin, an appserver I have used actually once for a University project long long time ago, have implemented the complete PHP language in Java! They call it Quercus and as of the time of this post its version 3.1. Quercus is deployed as a standard webapp and can be run on any JEE container. A Drupal installation apparently benefited from a 4x improvements over standard mod_php. However for a fair performance comparison it has to be compared with op-code caches – i heard good things about XCache – (php code compiled and cached), which typically reduces server load and increases the speed of PHP code anywhere from 2-10 times. Also lighthttp maybe faster than apache.

Performance aside, more important to me is actually to test if I can integrate my php app with my JEE apps and share a Persistence layer /ORM cache as well as clustering aspects with e.g. Terracotta. I will defenetly follow up on this with some results of this technology “mash-up”.

What are the big differences to the Java (web) development experience?

• interpreted (no compiler to check for errors, just a parser)
• dynamically typed (->no “parse-time” type checking in the IDE ..)
• essential procedural, object handling completely rewrittten from version 4 to 5 now basic oo functionality
• hunderts of statically callable base function; e.g. very easy to download & store a file: $contents = file_get_contents($url). However you see that many things grew historically without a overall concept: how do you test the existence of a substring in a string strstr | strrpos | stripos (hint 0 equals false))
• Very “close” to the HTTP request-response model
• the script execution is determined by the HTTP request (e.g. check ignore_user_abort )
• MySQL and Postgres integration modules for persistence
• Caching, Pooling is different due to the fact that a PHP process in its pure form only lives during one Web request:3 ways a PHP can run in a Web Server:
  - as CGI wrapper: instance of the php interpreter created and destroyed for every page request
  - module (e.g. mod_php, mod_fastcgi) in a multiprocessor web server like Apache. Apache/FastCGI can reuse php instances
  - plugin to web server

  This means that connection pooling is not really possible.
  Caching:
  - page scope: not necessary in php. All variables within includes are acessible
  - request scope: not supported natively, but can be implemented via session
  - session scope: see PHP Session. Data stored within a text file in php/tmp or similar. Data must be serializable (It is not possible to serialize PHP built-in objects!)
  - application scope: does not exist

• Generally faster code-test iterations.
• Quick infrastructure setup: Apache, php, Apache-php integration (e.g. mod_php), Editor.
• More difficult to manage complex/larger projects because:
  - interpreted & dynamically typed: errors only found at runtime
  - Exception handling difficult
  - OO-shortcomings
  - …

This is just a short list of my thoughts, not striving to achive completeness.

What I am talking about is the testing. Its quite astonishing that this is not thought through at all: Facebook does not offer a Test environment (!). So this means developers have to test their apps in the real Facebook which means. Developers have to create 2 apps one for test one for prod with different configurations canvas urls etc. as well as create Testusers - or they want to annoy their friends with test apps.

If your like me you prefer debugging to changelogginguploadtestchangeuploadtest cycles. With Facebook Apps this was not straigthforward so therefore here is a easy end-to-end explanation for you how to setup your php facebook app for local debugging – which i didnt find on the net.

Prerequisistes: You have apache and php 5.x installed.

1. Set up your computer for portforwarding. Portworward.com has good explanations for all different kind of configurations and routers.
2. Get yourself a alias from dyndns.org, something like myfacebookapp.dyndns.org pointing to your ip. In order to update your dynamic ip if you have one, install the dyndns updater.
3. Try accessing your apache file via your dyndyns alias(myfacebookapp.dyndns.org). Keep in mind that many routers do not support ip loopback, therefore you might need to go through a proxy to do that. Also make sure to configure your firewall to open the ports your forwarding.
4. If this all worked you are ready to setup your php environment. Startup (or install) your php ide of choice with integrated xdebugging for php (like Netbeans 6.7 or Aptana 1.5)
5. You need to configure your php.ini file to support the xdebug. At the end of your php.ini file add:zend_extension_ts=”c:/php/ext/php_xdebug-2.0.5-5.2.dll”
   xdebug.remote_enable=on
   xdebug.remote_handler=dbgp
   xdebug.remote_mode=req
   xdebug.remote_host=localhost
   xdebug.remote_port=9000

   As you see I use windows change your path to the xdebug .dll / .so as you need. You might need to download it from xdebug.org

6. Now you should be ready to startup a debug session of a file locally. Test it
7. In order to debug HTTP Sessions its important that you have the parameter XDEBUG_SESSION_START= (for Netbeans its XDEBUG_SESSION_START=netbeans-xdebug) in your request url. So this gets a bit tricky for facebook apps since facebook is calling the canvas url I think that cannot contain query params (I guess ..) . Anyway no need to try or think either there is a nice firefox plugin that does that for us.

That’s it: Fire up a debugging session in your ide, add a breakpoint in your facebook app and try access your facebook app from facebook. You should end up in your local debugging session.

If you enjoyed this post consider sharing :