1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235

<?xml version="1.0"?>
<project name="hello" default="build">
 
  <!-- root directory of this project -->
  <property name="project.dir" value="."/>
 
  <!-- root directory of Scala installation -->
  <property name="scala.home" 
    value="C:\\Program Files\\Scala"/>
 
  <!-- root directory of Tomcat installation -->
  <property name="server.home" 
    value="C:\\path\\to\\Tomcat\\installation"/>
 
  <!-- URL for Tomcat's manager application -->  
  <property name="server.manager.url" 
    value="http://dev:8080/manager"/>
 
  <!-- account name for Tomcat's admin account -->  
  <property name="server.manager.username" value="admin"/>
 
  <!-- password name for Tomcat's admin account -->  
  <property name="server.manager.password" value="admin"/>
 
  <!-- location of scalatest.jar for unit testing -->
  <property name="scalatest.jar" 
    value="C:\\path\\to\\scalatest-1.0\\scalatest-1.0.jar"/>
 
  <target name="init">
 
    <!-- derived path names -->
    <property name="source.dir" value="${project.dir}/src"/>
    <property name="web.dir" value="${project.dir}/web"/>
    <property name="classes.dir" 
      value="${web.dir}/WEB-INF/classes"/>
    <property name="lib.dir" 
      value="${web.dir}/WEB-INF/lib"/>
    <property name="webapp.dir" 
      value="${server.home}/webapps/${ant.project.name}"/>
    <property name="test.dir" value="${project.dir}/test"/>
 
    <!-- scala libraries for classpath definitions -->
    <property name="scala-library.jar" 
      value="${scala.home}/lib/scala-library.jar"/>
    <property name="scala-compiler.jar" 
      value="${scala.home}/lib/scala-compiler.jar"/>
 
    <!-- classpath for the compiler task definition -->   
    <path id="scala.classpath">
      <pathelement location="${scala-compiler.jar}"/>
      <pathelement location="${scala-library.jar}"/>
    </path>
 
    <!-- classpath for project build -->   
    <path id="build.classpath">
      <pathelement 
        location="${server.home}/lib/servlet-api.jar"/>
      <pathelement location="${scala-library.jar}"/>
      <fileset dir="${lib.dir}">
        <include name="*.jar"/>
      </fileset>
      <pathelement location="${classes.dir}"/>
    </path>
 
    <!-- classpath for unit test build  -->
    <path id="test.classpath">
      <path refid="build.classpath"/>
      <pathelement location="${scalatest.jar}"/>
    </path>
 
    <!-- definition for the "scalac" 
      and "scaladoc" ant tasks -->
    <taskdef resource="scala/tools/ant/antlib.xml">
      <classpath refid="scala.classpath"/>
    </taskdef>
 
    <!-- definition for the "scalatest" ant task -->
    <taskdef name="scalatest" 
      classname="org.scalatest.tools.ScalaTestTask">
      <classpath refid="test.classpath"/>
    </taskdef>
 
    <!-- definition for the "reload", "deploy" 
      and "undeploy" Tomcat tasks -->
    <taskdef name="deploy" 
      classname="org.apache.catalina.ant.DeployTask">
      <classpath 
        path="${server.home}/lib/catalina-ant.jar"/>
    </taskdef>
    <taskdef name="reload" 
      classname="org.apache.catalina.ant.ReloadTask">
      <classpath 
        path="${server.home}/lib/catalina-ant.jar"/>
    </taskdef>
    <taskdef name="undeploy" 
      classname="org.apache.catalina.ant.UndeployTask">
      <classpath 
        path="${server.home}/lib/catalina-ant.jar"/>
    </taskdef>
 
  </target>
 
  <!-- compile project -->
  <target name="build" depends="init" description="build">
    <buildnumber/>
    <tstamp/>
    <mkdir dir="${classes.dir}"/>
    <mkdir dir="${lib.dir}"/>
    <copy file="${scala-library.jar}" todir="${lib.dir}"/>
    <scalac 
      srcdir="${source.dir}" 
      destdir="${classes.dir}"
      classpathref="build.classpath"
      force="never"
      deprecation="on"
    >
      <include name="**/*.scala"/>
    </scalac>
  </target>
 
  <!-- create a deployable web archive -->
  <target name="war" depends="build" description="war">
    <war destfile="${project.dir}/${ant.project.name}.war"
      webxml="${web.dir}/WEB-INF/web.xml"
      basedir="${web.dir}"
    />
  </target>
 
  <!-- creates a deployable web archive with all classes
    packed into a single jar file -->
  <target name="packedwar" 
    depends="build" description="packedwar">
    <jar destfile="${lib.dir}/${ant.project.name}.jar" 
      basedir="${classes.dir}"
      duplicate="preserve">
      <manifest>
        <section name="Program">
          <attribute 
            name="Title" value="${ant.project.name}"/>
          <attribute name="Build" value="${build.number}"/>
          <attribute name="Date" value="${TODAY}"/>
        </section>
      </manifest>
    </jar>
    <delete dir="${classes.dir}"/>
    <war destfile="${project.dir}/${ant.project.name}.war"
      webxml="${web.dir}/WEB-INF/web.xml"
      basedir="${web.dir}"
    />
    <delete file="${lib.dir}/${ant.project.name}.jar"/>
  </target>
 
  <!-- deploy project on Tomcat server -->
  <target name="deploy" depends="war" description="deploy">
    <mkdir dir="${webapp.dir}"/>
    <copy todir="${webapp.dir}">
      <fileset dir="${web.dir}"/>
    </copy>
    <deploy url="${server.manager.url}"
      username="${server.manager.username}"
      password="${server.manager.password}"
      path="/${ant.project.name}"
      localWar="${project.dir}/${ant.project.name}.war"
      />
  </target>
 
  <!-- update and reload project on Tomcat server -->
  <target name="reload" 
    depends="build" description="reload">
    <copy file="${scala-library.jar}" todir="${lib.dir}"/>
    <copy todir="${webapp.dir}">
      <fileset dir="${web.dir}"/>
    </copy>
    <reload url="${server.manager.url}"
      username="${server.manager.username}"
      password="${server.manager.password}"
      path="/${ant.project.name}"/>
  </target>
 
  <!-- remove project from Tomcat server -->
  <target name="undeploy" 
    depends="init" description="undeploy">
    <undeploy url="${server.manager.url}"
      username="${server.manager.username}"
      password="${server.manager.password}"
      path="/${ant.project.name}"/>
  </target>
 
  <!-- build unit tests -->
  <target name="buildtest" depends="build">
    <mkdir dir="${test.dir}/build"/>
    <scalac 
      srcdir="${test.dir}" 
      destdir="${test.dir}/build" 
      classpathref="test.classpath"
      force="never"
      deprecation="on"
    >
      <include name="**/*.scala"/>
    </scalac>
  </target>
 
  <!-- run unit tests -->
  <target name="test" 
    depends="buildtest" description="test">
    <scalatest runpath="${test.dir}/build">
      <reporter type="stdout" config="YFABRT"/>
      <membersonly package="suite"/>
      <!-- <reporter type="graphic" config="YFABRT"/> -->
      <!-- <suite classname="suite.TestSuite"/> --> 
    </scalatest> 
  </target>
 
  <!-- delete all build files -->
  <target name="clean" depends="init" description="clean">
    <delete dir="${classes.dir}"/>
    <delete dir="${project.dir}/doc"/>
    <delete dir="${test.dir}/build"/>
    <delete file="${lib.dir}/scala-library.jar"/>
    <delete file="${project.dir}/${ant.project.name}.war"/>
  </target>
 
  <!-- create API documentation in doc folder -->
  <target name="scaladoc" 
    depends="build" description="scaladoc">
    <mkdir dir="${project.dir}/doc"/>
    <scaladoc 
      srcdir="${source.dir}" 
      destdir="${project.dir}/doc" 
      classpathref="build.classpath" 
      doctitle="${ant.project.name}" 
      windowtitle="${ant.project.name}"/>
  </target>
 
</project>

The directory structure differs slightly from that for a standalone application. We have an additional web directory for web content. It contains the WEB-INF directory where all class files and  libraries go. During development, class files are directly copied to the server without packaging. This ensures faster deploy/test cycles. In addition, there are Ant tasks for putting class files into a single jar  and for creating a distributable war file (war, packedwar). I have tried to keep the number of properties that need to be changed down to a minimum. Obviously, you need to set the home directories of your Scala, Scalatest, and Tomcat installations. You might also have to change the admin password for the Tomcat manager application which is used for automated deployment. Here is a summary of the defined targets:

• build = compile your webapp and put class files into the WEB-INF/classes directory.
• war = build a deployable web archive.
• packedwar = build a deployable web archive with all class files packed into a jar.
• deploy = deploy your webapp on Tomcat server.
• reload = update project files on server and reload application.
• undeploy = remove webapp from Tomcat server.
• test = build and run unit tests (using Scalatest).
• clean = delete all build files.
• scaladoc = create API documentation from sources and put it into the in ./doc directory.
• package = create a distributable zip archive that contains all dependencies plus Scaladocs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172

<?xml version="1.0"?>
<project name="helloworld" default="run">
 
  <!-- root directory of this project -->
  <property name="project.dir" value="."/>
 
  <!-- main class to run -->
  <property name="main.class" value="app.HelloWorld"/>
 
  <!-- root directory of Scala installation -->
  <property name="scala.home" 
    value="C:\\Program Files\\Scala"/>
 
  <!-- location of scalatest.jar for unit testing -->
  <property name="scalatest.jar" 
    value="C:\\Program Files\\...\\scalatest-1.0.jar"/>
 
  <target name="init">
 
    <!-- derived path names -->
    <property name="build.dir" value="${project.dir}/build"/>
    <property name="source.dir" value="${project.dir}/src"/>
    <property name="test.dir" value="${project.dir}/test"/>
 
    <!-- scala libraries for classpath definitions -->
    <property name="scala-library.jar" 
      value="${scala.home}/lib/scala-library.jar"/>
    <property name="scala-compiler.jar" 
      value="${scala.home}/lib/scala-compiler.jar"/>
 
    <!-- classpath for the compiler task definition -->   
    <path id="scala.classpath">
      <pathelement location="${scala-compiler.jar}"/>
      <pathelement location="${scala-library.jar}"/>
    </path>
 
    <!-- classpath for project build -->   
    <path id="build.classpath">
      <pathelement location="${scala-library.jar}"/>
      <fileset dir="${project.dir}/lib">
        <include name="*.jar"/>
      </fileset>
      <pathelement location="${build.dir}/classes"/>
    </path>
 
    <!-- classpath for unit test build  -->
    <path id="test.classpath">
      <pathelement location="${scala-library.jar}"/>
      <pathelement location="${scalatest.jar}"/>
      <pathelement location="${build.dir}/classes"/>
    </path>
 
    <!-- definition for the "scalac" and 
      "scaladoc" ant tasks -->
    <taskdef resource="scala/tools/ant/antlib.xml">
      <classpath refid="scala.classpath"/>
    </taskdef>
 
    <!-- definition for the "scalatest" ant task -->
    <taskdef name="scalatest" 
      classname="org.scalatest.tools.ScalaTestTask">
      <classpath refid="test.classpath"/>
    </taskdef>
 
  </target>
 
  <!-- delete compiled files -->
  <target name="clean" depends="init" description="clean">
    <delete dir="${build.dir}"/>
    <delete dir="${project.dir}/doc"/>
    <delete file="${project.dir}/lib/scala-library.jar"/>
  </target>
 
  <!-- compile project -->
  <target name="build" depends="init" description="build">
    <buildnumber/>
    <tstamp/>
    <mkdir dir="${build.dir}/classes"/>
    <scalac 
      srcdir="${source.dir}" 
      destdir="${build.dir}/classes" 
      classpathref="build.classpath"
      force="never"
      deprecation="on"
    >
      <include name="**/*.scala"/>
    </scalac>
  </target>
 
  <!-- run program -->
  <target name="run" depends="build" description="run">
    <java classname="${main.class}" 
      classpathref="build.classpath"/>
  </target>
 
  <!-- build unit tests -->
  <target name="buildtest" depends="build">
    <mkdir dir="${build.dir}/test"/>
    <scalac 
      srcdir="${test.dir}" 
      destdir="${build.dir}/test" 
      classpathref="test.classpath"
      force="never"
      deprecation="on"
    >
      <include name="**/*.scala"/>
    </scalac>
  </target>
 
  <!-- run unit tests -->
  <target name="test" depends="buildtest" description="test">
    <scalatest runpath="${build.dir}/test">
      <reporter type="stdout" config="YFABRT"/>
      <membersonly package="suite"/>
      <!-- <reporter type="graphic" config="YFABRT"/> -->
      <!-- <suite classname="suite.TestSuite"/> --> 
    </scalatest> 
  </target>
 
  <!-- create a startable *.jar with proper 
    classpath dependency definition -->
  <target name="jar" depends="build" description="jar">
    <mkdir dir="${build.dir}/jar"/>
    <copy file="${scala-library.jar}" todir="${project.dir}/lib"/>
    <path id="jar.class.path">		
       <fileset dir="${project.dir}" >
         <include name="lib/**/*.jar"/>
       </fileset>
    </path>
    <pathconvert property="jar.classpath" pathsep=" " dirsep="/">
      <path refid="jar.class.path"></path>
      <map from="${basedir}${file.separator}lib" to="lib"/>		
    </pathconvert>
    <jar destfile="${build.dir}/jar/${ant.project.name}.jar" 
         basedir="${build.dir}/classes"
         duplicate="preserve">
      <manifest>
        <attribute name="Main-Class" value="${main.class}"/>
        <attribute name="Class-Path" value="${jar.classpath}"/>
        <section name="Program">
          <attribute name="Title" value="${ant.project.name}"/>
          <attribute name="Build" value="${build.number}"/>
          <attribute name="Date" value="${TODAY}"/>
        </section>
      </manifest>
    </jar>
  </target>
 
  <!-- create API documentation in doc folder -->
  <target name="scaladoc" depends="build" description="scaladoc">
    <mkdir dir="${project.dir}/doc"/>
    <scaladoc 
      srcdir="${source.dir}" 
      destdir="${project.dir}/doc" 
      classpathref="build.classpath"
      doctitle="${ant.project.name}"
      windowtitle="${ant.project.name}"/>
  </target>
 
  <!-- create a zip file with binaries for distribution -->
  <target name="package" 
    depends="jar, scaladoc" description="package">
    <zip destfile="${build.dir}/${ant.project.name}.zip">
      <zipfileset dir="${build.dir}/jar" 
        includes="${ant.project.name}.jar"/>
      <zipfileset dir="${project.dir}" includes="lib/*"/>
      <zipfileset dir="${project.dir}" includes="doc/*"/>
      <zipfileset dir="${project.dir}/txt" includes="*"/>
    </zip>
  </target>
 
</project>

Download “helloworld.scala” with Ant build file.

Fortunately, the designers of Scala provided built-in Ant tasks in the compiler library, which makes the integration of Ant straightforward. The XML code above shows the build.xml for a typical Scala standalone application, such as a GUI program or a console application. It is reasonably complete and it provides Ant targets for all common tasks:

• build = compile your project and put class files into the ./build directory.
• run = run program.
• jar = create a startable jar archive from class files.
• test = build and run unit tests (using Scalatest).
• scaladoc = create API documentation from sources and put it into the in ./doc directory.
• package = create a distributable zip archive that contains all dependencies plus Scaladocs.

The directory tree is kept as simple as possible:

• build - temporary directory for class files and other binaries
• lib - contains external dependencies (*.jar files)
• src - contains Scala source code tree
• test - contains Scala unit tests
• txt - contains files (such as license text) that are packaged with the distributable zip archive

If your project depends on external jars, all you have to do is to drop these into the ./lib folder. Ant will take care of creating appropriate class paths, entering them into the manifest of the startable jar file, and including them in the distribution package. The Scala library is packed automatically so that the resulting package can be deployed on computers that don’t have Scala installed (only a standard JRE is required). To use this Ant script on your computer, you need to change the values of the scala.home and scalatest.jar properties to match the location of your Scala and Scalatest installations (never mind the latter if you use another unit testing framework). If you are working in a team, it is good practice to put Ant properties into a separate properties file, so that the build file can be checked into a source code management tool. I have included them here for simplicity.

One of the advantages of using Ant is that it has very good integration with IDEs, such as Eclipse. The only twist is that Eclipse does not honour the classpaths defined in build.xml for its own incremental compilation process used to mark syntactical errors. Thus if you import the Ant project into Eclipse, you have to tell Eclipse about the dependencies using the Project/Properties/Java Build Path option.

So, what speaks against using a web framework? Plenty actually, especially at the lower end of the spectrum and especially with dynamic languages. The main problem with web frameworks is that they add overhead. This means that the added functionality and structure is bought at the cost of performance degradation. The graveness of this problem depends on the system architecture. One  needs to keep in mind, that dynamic languages are interpreted at runtime, which makes them CPU-intensive and relatively slow. Because the life cycle of a script is essentially stateless and single-step, classes and data structures need to be rebuild and reloaded (in theory) at each request. In practice, this does not happen, because servers are designed to provide at least rudimentary caching. However, the runtime performance of interpreted languages is typically several magnitudes smaller than that of a compiled language, which magnifies the problem.

To illustrate my point, consider these benchmarks for PHP frameworks kindly provided by Paul M. Jones. According to these figures, a trivial PHP page is served by Apache 2 at a performance reduction of 43% compared to static HTML. The use of various PHP web frameworks further reduces performance by 85% - 95% compared to a PHP page that merely echoes content. Although it can be expected that these figures develop inverse logarithmically with increasing application code complexity, the slowdown is significant. PHP offers a number of remedies, such as  opcode caching, object caching, and products such as Zend Server, APC, and MCache, yet performance is unlikely to get even close to that of a compiled language.

Furthermore, there is the question whether the complexity of the project justifies the complexity introduced by a web framework. Would you use a web framework for building a guestbook script? Probably  not. What about a blog software? A photo gallery? A bulletin board? These types of applications are the mainstay of dynamic languages, such as PHP. It is the area where PHP really shines. Think of Wordpress, phpBB, Mediawiki, Drupal, osCommerce, Coppermine and other popular applications. They all have one thing in common: they don’t use a framework. Hence, before choosing a web framework for PHP development, it may be worth pondering if any is required. This suggestion may sound a bit contradictory, having just reviewed the Zend framework in a previous article. However, in my own practice I haven’t come across many complex PHP projects.

The commercial PHP projects I worked on during the last 10 years can roughly be divided into three categories: 1. extensions and customisations of open source packages, 2. intranet information systems, and 3. e-commerce systems and “catalogware”. Although the latter two may be considered candidates for web frameworks, the size of these projects was almost always small enough to do without. On several occasions, I chose to implement an “ultralight” MVC architecture by hand instead of using an out-of-the-box framework. The main reason for this was again performance. The “ultralight” approach is defined by implementing only the required functionality, which results in highly specialised design. In practice, this means slimming the controller, reducing DB abstraction to a thin wrapper around the native library, and foregoing a templating system in favour of embedded PHP.

The advantage of this approach is that you get separation of presentation and business logic, componentisation, and customisable control flow without the performance cost of full-blown framework. The disadvantage is that it is slightly more laborious to implement and less flexible. Don’t get me wrong. I have no problems imagining scenarios where I would want to use a PHP web framework such as the Zend framework. However, in these cases I’d probably be drawn towards using Java or (hopefully) Scala in the first place. In summary, I have found myself using PHP mostly in situations where a web framework seemed dispensable, while I have been using Java mostly in situations where a web framework seemed essential.

The Scala job statistics published today at www.itjobswatch.co.uk does not look all that promising either. Scala skills are requested only in 0.025 % of all IT Jobs, however, this number has grown tenfold since last year.

Source: http://www.itjobswatch.co.uk/jobs/uk/scala.do

So what does this tell us?

If you program in Scala, you must be either an academic, a hobbyist, or a programmer with too much leisure time. Currently, there is no significant demand for Scala professionals. But this might change. The Java community has received Scala quite positively so far and the language has a rapidly growing fan base. There are several high-profile websites that have recently begun development efforts in Scala, notably Twitter and LinkedIn. There are also a number of large-scale commercial projects in Scala being started recently. Martin Odersky, the creator of Scala, is quite upbeat about the commercial future of Scala. In this talk, given at LinkedIn earlier this summer, he outlines his vision for the near future of Scala. He also mentions a number of companies that have taken up projects in Scala, among them Ebay, LinkedIn, NatureNews, OfficeDepot, SAIC, Siemens, Sony, Twitter and Xerox.

The first thing to notice is that the framework has grown up and I mean this quite literally from a few megabytes in its early days to a whopping 109 MB (unzipped) distribution package. Only about 21 MB are used by the framework itself; the rest contains demos, tests, and… the dojo toolkit… an old acquaintance, which is optional. The documentation for the ZF was excellent right from the beginning and it has staid that way. Included is a 1170-pages PDF file, which also bears testimony to the growing size and complexity of the framework. Gone are the days when one could hack together a web application without reading a manual.

One of the first things to realise is that ZF is glue-framework rather than a full-stack framework. This means, it feels more like a library or a toolkit. ZF does not prescribe architecture and programming idioms like many other web frameworks do. This appears to fit the PHP culture well, though it must be mentioned that most ZF idioms come highly recommended, since they represent best OO practices. Another thing that catches the eye is the lack of an ORM component, which may likewise be rooted in traditional PHP culture. If you want object mapping, you would have to code around ZF’s DB abstraction and use Doctrine, Propel, or something similar. Let’s get started with this item.

Database Persistence
ZF provides a number of classes for DB abstraction. Zend_Db_Table implements a table data gateway using reflection and DB metadata. You only need to define table names and primary keys. Zend_Db_Adapter, Zend_Db_Statement and Zend_Db_Select provide database abstraction and let you create DB-independent queries and SQL statements in an object oriented manner. However, as you are dealing directly with the DB backend, all your data definitions go into the DB rather than into objects. Although this matches with the traditional PHP approach, it means that you need to create schemas by hand, which may irritate people who have been using ORM layers, like Hibernate, for years. On the other hand, a full-blown ORM layer likely incurs a significant performance cost in PHP, so maybe the ZF approach is sane.

Fat Controller
Like many other frameworks, ZF puts a lot of application logic into the controller, and this is my main gripe with the ZF. It seems to be the result of the idea that the “model” should concern itself only with shovelling data from the DB into the application and vice versa. A case in point is the coupling between Zend_Form and validation. This leaves you no option, but to put both into the controller. I think that data validation logically belongs to the model, while form generation logically belongs to the view. If you pull this into the middle, it will not only bulge the controller, but it is likely to lead to repetition of validation logic in the long run. That’s why I love slim controllers. Ideally, a controller should do nothing but filtering, URL rewriting, dispatching, and error processing.

MVC Implementation
Having mentioned coupling, it would do ZF injustice to say that things are tightly coupled. Actually, the opposite is the case, as even the MVC implementation is loosely coupled. At the heart you find the Zend_Controller_Front class which is set up to intercept all requests to dynamic content via URL rewriting. The rewriting mechanism also allows user-friendly and SEO-friendly URLs. The front controller dispatches to custom action controllers implemented via Zend_Controller_Action; if non-standard dispatching is required this can be achieved by implementing a custom router interface with special URL inference rules. The Zend_Controller_Action is aptly named, because that’s where the action is, i.e. where the application accesses the model and does its magic. The controller structure provides hooks and interfaces for the realisation of a plugin architecture.

Views
Views are *.phtml files that contain HTML interspersed with plenty of display code contained in the traditional <? ?> tags. It should be possible to edit *.phtml files with a standard HTML editor. The Zend_View class is a thin object from which View files pull display data. View fragments are stitched together with the traditional PHP require() or with layouts. It is also possible to use a 3rd party templating system. Given the <? ?>, there is little to prevent application logic from creeping into the view, except reminding developers that this is an abominable practice punishable by public ridicule.

Layouts
Layouts are a view abstraction. They enable you to arrange the logical structure of page layouts into neat and clean XML. These layouts are then transformed into suitable output (meaning HTML in most cases). As you can probably infer, this takes a second parsing step inside the PHP application, which is somewhat unfortunate, since PHP itself already parses view components. While layouts are optional, they are definitely nice to have. I think it’s probably the best a framework can do given the language limitations of PHP, which only understands the <?php> tag. If the XML capabilities of PHP itself would be extended to process namespaced tags like <php:something>, then one could easily create custom tags and the need for performance-eating 2-step processing would probably evaporate. Ah, wouldn’t it be nice?

Ajax Support
ZF does not include its own Javascript toolkit or set of widgets, but it comes bundled with Dojo and it offers JSON support. The Zend_Json class provides super-simple PHP object serialisation and deserialisation from/to JSON. It can also translate XML to JSON. The Zend_Dojo class provides an interface to the Dojo toolkit and makes Dojo’s widgets (called dijits) play nicely with Zend_Forms. Of course, you are free to use any other Ajax toolkit instead of Dojo, such as YUI, jQuery, or Prototype.

Flexibility
As mentioned, ZF is very flexible. It’s sort of loosely coupled at the design level, which is both a blessing and a curse. It’s a blessing, because it puts few restrictions on application architecture, and it’s a curse, because it creates gaps for code to fall through. A case in point is dependency injection ala Spring. In short, there isn’t much in the way of dependency management, apart from general OO practices of course. Nothing keeps programmers from having dependencies floating around in global space or in the registry. A slightly more rigid approach that enforces inversion of control when wiring together the Zend components would  probably not have hurt.

Overall Impression
My overall impression of the ZF is very good. It is a comprehensive and well-designed framework for PHP web applications. What I like best about it that it offers a 100% object-oriented API that looks very clean and makes extensive use of best OO practices, such as open/closed principle, programming to interfaces, composition over inheritance, and standard design patterns. The API is easy to read and understand. The internals of its implementation likewise make a good impression. The code looks clean and well structured, which is quite a nice change from PHP legacy code. ZF still involves a non-trivial learning curve because of its size. I’ve only had time to look into the key aspects, and didn’t get around to try out more specialised features like Zend_Captcha, Zend_Gdata, Zend_Pdf, Zend_Soap, and web services, and all the other features that ZF offers to web developers. If I had to choose a framework for a new web application, ZF would definitely be among the top contenders.

It contains an array of typical benchmark algorithms implemented in 35 popular (and not so popular) programming languages all running on various Linux servers. There are many complexities involved in measuring programming languages execution speed. The web development arena adds even more complexities. Much depends not only on how the algorithms are implemented, but also on how the compiler and the server are configured. For example, there are different JVMs, there are script caches, accelerators, server tunings, and what not. The languages I’d like to compare here are Java, Scala, and PHP. You will find comparison graphs for each of these below.

Three charts:

1. Java vs. PHP
2. Scala vs. PHP
3. Scala vs. Java

Three bar groups:

1. Execution time
2. Memory use
3. Size of source code

Bar pointing down means: faster performance, lower memory usage, and reduced source size.

Basically, these charts confirm what experienced programmers already know. Both, Java and Scala outperform PHP by several magnitudes. To be precise, Java and Scala execute 28 times faster on average. The performance of Java and Scala is similar, which has to be expected since both languages run on the Java virtual machine. Java gives slightly better performance in some algorithms while its memory requirements are lower. For PHP fans who find these benchmarks disappointing, there is some consolation. PHP appears to be less of a memory hogger, and perhaps more importantly, it performs quite favorably when compared to other dynamic interpreted languages, such as Perl, and Ruby.

You can compare more language benchmarks yourself at the following URL: http://shootout.alioth.debian.org/u64q/benchmark.php.

When I downloaded the PDT plugin for PHP development, I found a bug in it that prevented Eclipse from creating a PHP project from existing sources. After some research on the Internet, I found that this was a well-documented bug which had been fixed in the meantime. I tried installing the latest PDT release via the Eclipse install & update feature, but the process came to a crashing halt with a message that demanded some mylyn jars that could not be found. Although I had no idea why PDT required that particular jar, I dutifully installed the mylyn plugins with the required version number.

Unfortunately, this did not impress Galileo, as it now demanded other jars when installing the PDT update. - Perhaps a case of workspace pollution, I thought. - Clearly, it was time for a fresh start. I scrapped the installation and started anew with a blank workspace and a new install location. This time, everything seemed to install fine. I was able to create Java and PHP projects. However, Galileo suddenly wouldn’t open *.xml, *.xsl, or *.html files any more. It complained that there was no editor for this content type, which appeared fishy since both web tools (WTP) and PDT were installed. I tried to solve the problem by playing around with the configuration, but to no avail.

After several fresh attempts and considerable time spent with looking up error messages on the Internet, I decided to stay with Ganymede. Since I had wasted my entire morning and since I had some real work to do as well, this seemed to be the best course of action. Maybe I will give Galileo another go when an updated distro package becomes available. With Ganymede I never ran into this sort of trouble, despite having PDT, WTP, the Scala plugin and Jboss tools installed. I am still clueless as to what went wrong and I wonder if anybody else had a similar experience.

Apart from consistency and conventions, the most important point to get right is semantic precision. The identifier name should be stated as clearly and as intelligible as possible, without being overly wordy. Ambiguity is the greatest enemy here, especially when there are several identifiers floating around that have similar, yet subtly different meanings. Consider the following example:

1
2
3
4
5
6
7
8
9
10
11
12
13

for (Event event: events) {
  trainees += event.trainees.size();
  if (event.status == 1 && event.end >= time) {
    for (Person train : event.trainees)
      if (train.passed) {
        trainee.add(train);
        trained++;
     }
     else training.add(train);
  }
  else if (event.status == 0 || event.end < time) {
    training.addAll(event.trainees);
}

This code looks convoluted because of the overuse of the word “train”. What it does is this: it iterates over all workshop events and creates a collection of trainees that have successfully completed a workshop and another of trainees that did not complete a workshop or are still being trained. It also counts the total number of trainees and the number of successful ones. Apart from the ambiguous “train…”, readability suffers because of non-descriptive variable names and the use of constant integer literals. Here is a more readable version:

1
2
3
4
5
6
7
8
9
10
11
12
13

for (Event workshop: allWorkshops) {
  numOfTrainees += workshop.trainees.size();
  if (workshop.status == COMPLETED && workshop.end >= today) {
    for (Person trainee : workshop.trainees)
      if (trainee.passed) {
        graduates.add(trainee);
        numOfGraduates++;
     }
     else peopleInTraining.add(trainee);
  }
  else if (workshop.status == CANCELLED || workshop.end < today) {
    peopleInTraining.addAll(event.trainees);
}

This brief example shows how to transform an ambiguous piece of code into one that can be read and understood quite easily. The question is: what are the underlying principles? Unfortunately, the answer to this question is complicated. Rather than attempting an analysis, I suggest to look at existing best practices that are widely adopted. Steven McConnel describes such a set of practices in his acclaimed book Code Complete (2nd Edition) in Chapter 11, The Power Of Variable Names. He writes: “An effective technique for coming up with a good name is to state in words what the variable represents. Often that statement itself is the best variable name. It’s easy to read because it doesn’t contain cryptic abbreviations, and it’s unambiguous.” In the remainder of this article, I will try to present a summary of Steve McConnell’s set of best practices.

Describe the “what”, not the “how”. A good identifier name relates to the problem domain rather than to the solution approach or algorithm. For example, the name tmpStateArray might hold an array of communication states of different chat users in a chat application. The name is clearly computerish and algorithm-oriented; a better name would probably be chatStates or communicationStates. Likewise, names such as bitFlag, statusFlag, optionString, etc. should be avoided unless it is totally clear what they mean.

Aim for optimum identifier length. Identifier length is important. It is almost always a compromise between conveying sufficient meaning and maintaining readability; in other words, it’s always a compromise between ambiguity and length. Consider the number of graduated trainees in the sales department. The name numberOfGraduatedTraineesInSalesDepartment is most unambiguous, but rather unwieldy. The names trainees, salesTrainees, gradSalTrn  on the other hand, are more convenient but too short and too ambiguous. A reasonable compromise would be numGradTraineesInSales.

Qualify computed values. If a variable is used for a computed numeric value, such as totals, averages, etc. qualify the variable name accordingly. Examples are: num…, count…, sum…, average…, max…, min… and so on.

Use common opposite names for variables that express the boundaries of an interval, or an operation that involves opposites, such as begin/end, first/last, min/max, old/new, lowest/highest, next/previous, source/target, sender/recipient and so on.

Use letters i, j, k for loop index variables and iterators. This convention is probably as old as C-programming and it is a good practice, since there is no point in inventing fancy names for loop index variables. As always, there is an exception to the rule. If the index is used outside the loop, for example to count records, then a more descriptive name such as recordCount makes the reference outside the loop more readable.

Use is… or has… prefixes for boolean variables and methods that return boolean values. For example, the variable name isCustomer expresses boolean semantics much clearer than just customer. An exception to this rule are words that clearly express a yes/no status, such as ready, done, failed, found, etc.

In an object-oriented language, use nouns for classes, objects and interfaces. Use verbs for class methods and functions. Sometimes, it is also meaningful to use adjectives for interfaces or methods, for example Quadratic, Sharable, isQuadratic(), or isShared().

Avoid scope prefixes unless your language forces you to do so. For example, it was customary in the past to prefix class names or functions with module names, for example: Payroll_EmployeeRecord, Payroll_Allowances, Payroll_Reimbursements, and so on. This practice battles namespace pollution, but it is a very poor replacement for actual namespaces, because it leads to incredibly long and cluttered identifiers. Use this only if your language does not support the notions of modules, packages, or namespaces.

Avoid shadowing. If you use identifiers in nested scopes, don’t use the same names to avoid shadowing. For example, if you declare a local variable with the same name as a field/member of the class, then the former shadows the latter. This is not a neat programming trick, but a recipe for disaster. It is quite confusing to read, and even more confusing to debug. An exception to this rule would be getters and setters, where the field/member is explicitly qualified with ‘this’.

Avoid reusing variables, unless the semantics are maintained. Imagine you have a variable named count which is used in one loop to count records, and in another to count errors. It may be tempting to reuse the integer already declared, but it is far more readable and maintainable to use two separate integer variables appropriately named recordCount and errorCount.

Make abbreviations readable and unambiguous. For example, the abbreviated prefix rnd is often used to denote a random value, but it could also mean rounded. If it isn’t clear from the context, write it out; for instance, write randomAmount instead of rndAmount. As a general rule, source code is read more often than it is written, thus readability is more important than writing convenience. With this in mind, if an abbreviation just saves one or two characters, always write out the word.

Create abbreviations that can be pronounced. For example, use stringPos rather than stringPstn and recCount rather than rcrdCount. It should be possible to read program code aloud without twisting your tongue. Apart from the advantage of being easier to communicate, pronounceable identifiers are also easier to remember.

1
2

scala> 1.2 - 1.0
res1: Double = 0.19999999999999996

Oops. Shouldn’t that be 0.2? Yes it should, but since the number 0.2 cannot be represented exactly in binary form, the result is a little bit less. This problem becomes annoying when Floats or Double values are used to represent money. It gets worse when multiplication or division operations magnify the error, as for example in the case of interest calculations. Simply put, you can’t guarantee the exactness of calculations down to the cent when you represent monetary amounts as floating point values. The Java language has a type called BigDecimal which solves this problem. It offers arbitrary scale fixed point arithmetics that allows precise financial calculations. Unfortunately, Java’s BigDecimal class has a rather unwieldy API which is a pain to use. No problem, you may think, because Scala offers a wrapper for BigDecimal that lets you use it like a normal number. That is true, but try this out:

1
2
3

scala> val b: BigDecimal = 0.1
b: BigDecimal =
  0.1000000000000000055511151231257827021181583404541015625

Oops again. This doesn’t look much better. What is more, the BigDecimal wrapper class in Scala has abstracted away the control over rounding behaviour and precision offered by the Java API. Of course, you could follow another approach and use Long values to represent money and scale them to the required precision, say one ten thousands of a Dollar. However, there are a number of problems with this approach. First, the value range is limited by MAX_LONG/scale. Second, you have to do complex formatting every time you print the values. Third, you have to code rounding manually because remainders are discarded in integer arithmetics:

1
2

scala> 59L / 10L
res2: Long = 5

With this in mind, I have created a Scala currency type that offers arbitrary precision fixed point arithmetics with an easy-to-use API. It is based on the Java’s BigDecimal type - why reinvent the wheel? Let’s repeat the first arithmetic operation using the currency type:

1
2

scala> Currency(1.2) - Currency(1.0)
res3: Currency = 0.20

This time the result is correct. It is correct, because the currency type automatically takes care of rounding. By default, the result is rounded to the second decimal place using the ROUND_HALF_UP rounding mode, which means that 1.555 is rounded to 1.56 and -1.555 is rounded to -1.56. Unlike the rounding for Float and Double values, the rounding is symmetric, which is standard in most financial calculations. If you need a different rounding behaviour – no problem. With the currency type, you have complete control over precision and rounding behaviour.

1
2
3
4
5
6
7
8
9

scala> val c = Currency("1234.56789", 4)
c: Currency = 1234.5679
 
scala> val d = Currency(0.1, 20)
d: Currency = 0.10000000000000000000
 
scala> import Currency.RoundingMode._
scala> val e = Currency(22.78, 2, ROUND_DOWN)
e: Currency = 22.78

The first expression creates a currency value with a precision of 1/10000 (= four places right of the decimal point) from a string argument where the fifth decimal place is rounded up in construction. The second expression creates a value of 0.1 (10 cents) with a precision of 10^-20 or 20 places after the decimal point. The third expression constructs a value of 22.78 with a special rounding mode that stipulates that values should always be rounded down. The effect can be seen when performing an arithmetic operation:

1
2
3
4
5
6
7
8
9
10
11

scala> e * 1.1
res4: Currency = 25.05
 
scala> val f = Currency(22.78, 2, ROUND_UP)
f: Currency = 22.78
 
scala> e == f
res5: Boolean = true
 
scala> f * 1.1
res6: Currency = 25.06

In this example, the first operation e * 1.1 yields 25.05. We create another currency object with the same value, however with a different rounding mode. When performing the same operation on the second value f, the result differs by one cent from the first because it was rounded differently. This means that arithmetic operations with currency values that have different precision and/or rounding modes are not transitive. This is of course intended behaviour.

The above examples show simple calculations with non-specific currency values. In addition to the numeric amount, the currency type optionally takes a currency designation in the form of an ISO 4217 three-letter code. For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

scala> val salary = Currency(4789.90, "USD")
salary: Currency = 4789.90 USD
 
scala> val bonus = Currency(500, "USD")
bonus: Currency = 500.00 USD
 
scala> val holidayInEurope = Currency(2400, "EUR")
holidayInEurope: Currency = 2400.00 EUR
 
scala> salary + bonus
res7: Currency = 5289.90 USD
 
scala> salary + holidayInEurope
MismatchedCurrencyException

You can add, subtract and compare amounts in the same currency (or of a non-specific currency value), but when you try to add two different currency values, you get an exception. Alternatively, different currencies could be implemented as different subtypes, as suggested in Ch.20, Programming in Scala (Odersky, Spoon, Venners). This has the advantage that currency mismatches can be detected at compile time. However, it complicates the design and makes mapping the currency type to a database rather awkward. I think that the disadvantages outweigh the benefits, so I implemented the currency type as a “monolithic” class that knows about all currencies. With this design, it becomes easy to format currency values for output.

1
2
3
4
5
6
7
8
9
10
11
12

scala> salary.format
res8: String = $4,789.90
 
scala> import java.util.Locale
scala> holidayInEurope.format(new Locale("de", "DE"))
res9: String = 2.400,00 €
 
scala> holidayInEurope.format(new Locale("fr", "CH"))
res10: String = € 2'400.00
 
scala> salary.format("\u00A4 #,##0.0000")
res11: String = $ 4,789.9000

The currency class offers a severalfold overloaded format method that formats currency amounts according to either the default locale or a chosen locale. Alternatively, you can specify a formatting pattern and/or symbols to use, or you can use Java’s DecimalFormat class for formatting. Thus you have total control over the formatted output. The currency class can also verbalise amounts in four languages.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

scala> salary.say
res12: String =
  four thousand seven hundred eighty nine Dollars ninety Cents
 
scala> salary.sayNumber
res13: String =
  four thousand seven hundred eighty nine 90/100
 
scala> val pesos = Currency("1538.20", "MXN")
pesos: Currency = 1538.20 MXN
 
scala> pesos.say(new Locale("es"))
res14: String =
  mil cincocientos treinta y ocho Mexican Peso veinte Centavo
 
scala> pesos.sayNumber(new Locale("es"))
res15: String = mil cincocientos treinta y ocho 20/100

Finally, the currency class provides a number of convenience methods, such as percentage(), setDecimals(), abs(), fraction(), integral(), pow(), symbol(), getAllCurrencies(), etc., and a number of factory methods and conversion methods to simplify programming with currency values.

View Source Code.
Download source code and API documentation.

I should have said “almost all” hardware. Unfortunately one piece of hardware refused cooperation with Linux, namely my Novatel USB modem. Since I’ve come to rely on 3G mobile Internet, this is a knockout criterion. No modem, no Internet. After hours of scouring the Web for possible solutions and  trying out various settings, I gave up in frustration. There wasn’t anything I could do except zapping the Linux partition and installing old friend XP. To attenuate my disappointment, I will make it a dual boot machine, though. Note to hardware vendors: please take Linux seriously and provide drivers for your nifty electronics. That would make life much easier. I guess I have to postpone my switch-over to Linux for another year. Hopefully I will be able to resist the urge to buy another piece of exotic hardware in the meantime.