Second thoughts about AJAX

At the end of 2006, it seems that the Ajax hype is finally cooling off. Perhaps this is a good time for a sober analysis. Ajax has indeed changed the Internet landscape, but has it really transformed the web into web 2.0, or has it been just a cosmetic face-lift? The jury is still out on that. In my opinion, Ajax is not just cosmetics, but cosmetic surgery. As such, it comes with the inherent dangers of the same. What is more, Ajax has failed to deliver on its web 2.0 promise. The real web 2.0 is a slow evolutionary process from an information delivery platform to an application delivery platform. Ajax looks more like an intermediate step to me. Currently we are in web 2.0 alpha stage at best.

However, there is one thing that Ajax has achieved. It has pointed out the shortcomings of the traditional web architecture quite plainly. Number one: state information has to be piggy-backed onto a stateless protocol; number two: the granularity of a page as the smallest unit of information is too crude for a web application; number three: web pages lack a mechanism for creating rich and sophisticated graphical user interfaces. Ajax addresses all three of these problems. It eliminates the need for state preservation by packing workflow into a self-contained page. It asynchronously loads small units of content and updates pages dynamically. It provides UI components and event models to the application by means of JavaScript libraries. So, what is bad about Ajax?

Ajax breaks the back button. Ajax doesn't preserve state. Ajax suffers from network latencies. These are the conventional objections, of which I have to say they are somewhat silly. The broken back button can certainly be fixed; besides it is a small cost for a greatly enhanced UI. State preservation reduces to the same problem. Network latency and response time constitute a much bigger problem for web applications that always reload entire pages, therefore it's hardly and argument against Ajax. So, again, what's bad about Ajax? From the user perspective – nothing really. Ajax does a lot to jazz up web applications and enhance user experience. From a software engineering point of view, however, Ajax is a real nightmare.

Web applications are already a complex mix of technologies, and Ajax adds even more complexity. The principal problem is that the code base is split into client side code and server side code and that they use incompatible languages. This naturally leads to code duplication, increased overhead, reduced maintainability and -in the worst case- Spaghetti code. As long as the client side code deals exclusively with display logic, the separation does not really constitute problem, except that you now have two different kinds of display logic. However, more serious problems loom when controller logic and business logic find its way into the client side code. The temptation for this to happen is just too great. Less experienced programmers and programmers working under pressure of time are especially susceptible. Sooner or later, you might find core logic added to the front end.

The second problem is that Ajax tries to solve an issue which it cannot really solve, namely that of creating a dynamic, rich GUI on a static, penurious platform. Granted, the Document Object Model allows for some dynamics, but the core problem is really given by the inherent limitation of HTML. The standard HTML elements just don't provide enough flexibility and extensibility for a rich GUI. The solution for this problem is not yet in sight, although several approaches exist, such as XForms, and proprietary user interface markup languages, such as XUL and XAML. Some of these solutions provide for Ajax-style refresh mechanisms, others are extensible, but none of them provides a solution to all GUI demands. Perhaps worse, there is currently no universal browser support for any of these languages. Ajax only appears to solve this problem, but in reality, it scripts its way around it.

The third problem is -quite plainly- JavaScript itself was well as browser-specific DOM implementations which make JavaScript/DOM code difficult to create and to work on a great variety of browsers. JavaScript defies or at least complicates standard development procedures, such as debugging, unit testing, integration testing, and automatic code generation. The same test procedures have to be run on different browsers. To cut down on development time, Ajax programmers often use libraries. Unfortunately, libraries tend to bloat web pages, because they provide fixed bundles of functionality, whether needed or not. Ultimately, a JavaScript programmer finds himself with a set of tools and procedures reminiscent to bronze age software standards.

Finally, developers should think hard about when to use Ajax and when not to. According to the KISS principle, throwing in Ajax just for the fun of it, is a bad idea. For example, if you have to display a hierarchical data structure with thousands of nodes, an Ajax tree component that can load nodes and branches dynamically, certainly comes in handy. If all you need is to display a DHTML menu and a few popup windows, you might not need Ajax at all. Using Ajax only for reloading partial page content is likewise a bad idea, in my view. Iframes offer a much cleaner and more maintainable solution to this particular problem. The tendency is of course that web applications become ever more complex and users become ever more demanding. Hence, it is inevitable that web GUIs and traditional GUIs will eventually converge. When this happens, Ajax will probably have served as a stepping stone to the final solution.

The Ruby Rush

RubyOne would think that the Klondike times of web development are finally over. The frenzied placer mining period of the late 1990s came to an end in 2001. Since then, Internet growth has decelerated, development platforms have matured, and developers have -hopefully- learned the lesson. Technologically, however, the period from the dot-com-bust to today has been a boon. Web development languages have not only proliferated, but they also became more robust and more powerful. Today's web development arsenal is fitted with languages and tools that incorporate modern software engineering concepts. One of the more remarkable additions to this arsenal is the Ruby language.

The Ruby language is actually not that new. It's originator, Yukihiro Matsumoto, released the first version in 1995. Between 1995 and the early 2000s Ruby became popular in Japan, but it wasn't very well known internationally. This has changed with the introduction of Ruby on Rails, a web development framework for Ruby based on the model-view-controller architecture. Currently Ruby is in version 1.8.5 and Rails in version 1.16. During 2006, the Ruby on Rails combination has experienced an extraordinary adoption rate. Not only has it spurred worldwide interest in the Ruby language, but it also prompted a wave of Rails-like MVC frameworks for other development platforms, such as PHP and Python. It isn't Klondike, but since even long-time Java luminaries are migrating web development to Ruby on Rails, one may rightly speak of a Ruby Rush.

So why Ruby? The Ruby on Rails framework promises to combine the high productivity of dynamical script languages with the scalability of statically typed languages like Java or C++. Writing code is as easy as it gets, whereas large enterprise projects are still manageable and maintainable. Productivity is comparable to 4-GL tools, yet without the inherent limitations of the code generation approach. Ruby on Rails runs on all major operating systems; it works with a wide variety of web servers and it supports many databases, including MySQL, PostgreSQL, SQLite, Oracle, SQL Server, DB2, and Firebird. Minimal configuration, easy deployment, and well-integrated support for AJAX are further advantages. Last but not least, Ruby on Rails is free open-source software.

What is Ruby, exactly? The Ruby website explains: “A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.” Ruby is a one-pass interpreted, fully object-oriented language. Every bit of data is an object, even primitives, such as boolean and integer variables, and every function is a method. Ruby supports single inheritance, parametric polymorphism, and mixins instead of interfaces. It allows procedural programming by making stand-alone functions and variables implicit members of the root object. Other features include automatic garbage collection, multi-threading, iterators and closures, operator overloading, reflection, meta-programming, and exception handling. It's syntax is a quite unique and terse; it contains some elements of Perl, Python, Lisp, and Smalltalk.

Ruby on Rails is distributed via RubyGems, the standard packaging manager for Ruby libraries and applications. Rails expands on the underlying philosophy of Ruby, such as “Don't repeat yourself” (DRY), “Convention over configuration”, and the “principle of least surprise”. It provides a complete command-line driven framework for web development, including scaffolding to quickly construct the program logic and views to perform CRUD operations. Rails implements a strict MVC separation, where the model corresponds to the RDBMS model and the object-relational mapping, the view is commonly provided by embedded Ruby (.rhtml) files or .XML templates, and the controller contains most of the application logic programmed in Ruby.

Ruby Home Page: http://www.ruby-lang.org Rails Home Page: http://www.rubyonrails.org

Climbing mount Java

You don’t want to build your programming career on dynamic languages alone, but you find C++ too messy, C# too proprietary, Delphi too underpowered, and D too esoteric? Java is your friend. Not only does Java top the TCPI list of most popular programming languages, it also offers an established framework for everything from mobile application programming to enterprise development. Mount MerapiMoreover, it is designed as a cross-platform language from the outset. The “write once, run everywhere” philosophy isn’t a mere vision, or an overly optimistic design goal. With Java it is a reality. The greatest appeal of Java, however, may be its extremely solid software engineering foundation.

Everything in the Java world, from programming paradigms, code conventions, documentation to unit tests and build systems is standardised. These standards are applied industry-wide; they come as part of the package, and they are supported worldwide by the Java community. Programmers are almost forced to write maintainable, extensible, reusable, and well-documented code with Java. This is something that many other development platforms claim to achieve, but often fail to deliver. Naturally, the solid software engineering foundation that Java offers comes at a cost. The cost is complexity.

If you are new to Java and eager to learn the language, you are well advised to allocate ample time to the learning process. Despite what some book titles claim, and what might be your experience with scripting languages, Java cannot be learnt in 24 hours. Other book titles suggest “Java in 21 days”, which is somewhat more realistic. Since Java has acquired important new features in version 5.0, e.g. enums, annotations, generics, a month is probably needed to become familiar with the basics, more if you are also new to the object-oriented programming paradigm.

“Okay, yet this would be the same for C++ or any other statically typed OOP language,” you say. Yes, but Java is more than a language. It is a platform. It consists of dozens of development tools, hundreds of APIs, and thousands of classes that do everything from database access to 2D rendering. Sun has illustrated this neatly in its SDK documentation, where the Java SE platform is depicted as a brick wall, every brick representing a major API or technology. The Java language itself composes only the uppermost layer of the wall. Extrapolating the time it requires to learn Java, a year seems reasonable to become familiar with each and every of the pictured Java SE components.

And this is merely the beginning. We haven’t yet touched upon enterprise development with Java EE, e.g. Enterprise Java Beans, web development with JSP/Servlets, XML, web services, and so on. We also did not mention third party tools and systems, such as Java IDEs, Ant, JUnit, Tomcat, Jboss, Hibernate, Struts, and what else belongs to the advanced Java programmer’s toolkit. From this it becomes clear that climbing mount Java is an extensive journey that requires significant efforts. Mastering the platform is something that probably takes several years of continued education and practice. Hopefully, this does not discourage newcomers. The rewards, I believe, are substantial.

So what’s a good starting point? Close to the source, namely on Sun’s own homepage, there is the indispensable JDK/Java SE documentation, which was already mentioned. Sun also offers a highly usable tutorial, which features general as well as specialised trails and topics. For those interested in Java training and certification, there are two excellent web sites, www.javaranch.com and www.javablackbelt.com. These sites offer copious training material; they are a beacon for newcomers. Finally, there is a plethora of Java books on the market. For a beginner, a combination of a reference (“Java in a Nutshell”, David Flanagan), introductory text (“Head First Java”, Sierra and Bates) and a cook book (“Effective Java Programming Language Guide”, Joshua Bloch) probably makes sense.

Database duel – MySQL vs. PostgreSQL

Almost all non-trivial applications need to store data of some kind. If the data has the form of records, or n-tuples, it is typically handled by a relational database management system (RDBMS). Relational databases are conceptually founded on set theory and predicate logic. Data in an RDBMS is arranged in tables whose elements can be linked to each other. Today almost all RDBMS use SQL (structured query language) to implement the relational model. RDBMS with SQL have been in use since the late 1970s. Previously an expensive corporate technology, the first open source RDBMS became available during the late 1990s. Presently PostgreSQL and MySQL are the most popular open source RDBMS.

MySql LogoPostgreSql LogoBoth database systems are widely used for web applications. Although MySQL has a much larger user base (est. 6 million installations by 2005), the growth of PostgreSQL has recently accelerated. The latter came initially out of an academic environment. PostgreSQL was developed at the Berkeley University as a successor of the proprietary INGRES database. Until 1995, it used QUEL instead of SQL. Since version 6.0, the software is maintained and advanced by a team of volunteers and released free under the BSD license. In contrast, MySQL was developed in a commercial environment by the Swedish company TCX Dataconsult, and later by MySQL AB. It started out as a rewrite of the mSQL database and began to acquire more and better features. MySQL is released under a dual licensing scheme (GPL and paid commercial license).

Since the PostgreSQL developers had a head start of almost 10 years, the PostgreSQL database had hitherto more features than MySQL, especially more advanced features, which are desirable in an “enterprise” computing environment. These include advanced database storage, data management tools, information replication, and backup tools. MySQL, on the other hand, used to have an edge over PostgreSQL in terms of speed. It offered better performance for concurrent database access. Lately, this gap is closing, however. PostgreSQL is getting faster while MySQL acquires more enterprise features. The crucial 5.0 release of MySQL in October 2005 has added stored procedures, triggers, and views.

Let’s look at the commonalities first. Both systems are fully relational, using SQL for data definition, data manipulation, and data retrieval. They run on Windows, Linux, and a number of Unices. MySQL also runs on MacOS. Both databases come with a graphical GUI and query builder, backup, repair, and optimisation tools. They offer standard connectors such as ODBC and JDBC, as well as APIs for all major programming languages. Both systems support foreign keys and data integrity, subselects, transactions, unions, views, stored procedures, and triggers. Among the high-end features that both RDBMS offer are ACID-compliant transaction processing, multiple isolation levels, procedural languages, schemas (metadata), hot backups, data loading, replication (as an add-on in PostgreSQL), table spaces for disk storage layout, terabyte scalability, and SSL. MySQL and PostgreSQL also both support storage of geographic information (GIS). PostgreSQL additionally has network-aware data types that recognize Ipv4 and Ipv6 data types.

Now, let’s look at the differences. PostgreSQL is an object-relational database which means that it has object-oriented features, such as user-definable database objects and inheritance. Users can define data types, indexes, operators (which can be overloaded), aggregates, domains, casts, and conversions. PostgreSQL supports array data types. Inheritance in PostgreSQL allows to inherit table characteristics from a parent table. PostgreSQL also has very advanced programming features. In addition to its native procedural language, PL/pgSQL (which resembles Oracle’s PL/SQL), PostgreSQL procedures can be written in scripting languages, such as Perl, PHP. Python, etc., or compiled languages, such as C++ and Java. In contrast, MySQL (since version 5.0) only supports a native scripting language that follows the ANSI 2003 standard.

PostgreSQL/MySQL Comparison Chart

MySql PostgreSql Comparison Chart

The most evident advantage that MySQL offers –in terms of features– are its so-called pluggable storage engines. One may choose from a number of different data storage models, which allows the database administrator to optimise databases for the intended application. For example, a web application that makes heavy use of concurrent reads with few write operations may use the MyISAM storage engine to achieve top performance, while an online booking system may use the InnoDB storage engine for ACID-compliant transactions. Another interesting characteristic of MySQL not found in PostgreSQL is its support for distributed databases, which goes beyond mere database replication. Functionality for distributed data storage is offered through the NDB and FEDERATED storage engines, supporting clustered and remote databases respectively.

There are further differences, of course. MySQL is generally faster than PostgreSQL. It maintains a single process to accept new connections, instead of spawning a new process for each connection like PostgreSQL. This is a great advantage for web applications that connect on each page view. In addition, the MyISAM storage engine provides tremendous performance for both simple and complex SELECT statements. Stability is another advantage of MySQL. Due to its larger user base, MySQL has been tested more intensively, and it has historically been more stable than PostgreSQL.

PostgreSQL has a slight advantage over MySQL/InnoDB for concurrent transactions, because it makes use of Multiversioning Concurrency Control (MVCC), a mechanism found only in enterprise-grade commercial RDBMS. Another advantage of PostgreSQL is its relatively strict compliance with the ANSI 92/99 SQL standards, especially in view of data types. The ANSI SQL implementation of MySQL is more incomplete by comparison. However, MySQL has a special ANSI mode that disregards proprietary extensions.

In view of backup/restore capabilities, MySQL provides somewhat less convenience than PostgreSQL and commercial enterprise RDBMS. Nevertheless, hot backup and restore operations can be performed with both systems. Both PostgreSQL and MySQL/InnoDB allow transactional tables to be backed up simply by using a single transaction that copies all relevant tables. The disadvantage of this method is that it uses a lot of resources, which might compromise system performance.

With MySQL, a better solution is to use the replication mechanism for a continuous backup. PostgreSQL allows recovery from disk failure through point-in-time recovery (PiTR). This method combines file system level backups with a write ahead log, that records all changes to the database. Thus it is possible to recreate snapshots of the database of any point in time. In most cases, a crashed databases can be recovered up to the last transaction before the crash. The PiTR is also convenient for large databases, since it preserves resources.

MySQL Strengths

  • Excellent code stability
  • Excellent performance, fast CONNECT and SELECT
  • Multiple storage engines to choose from
  • Larger user base (thus larger number of applications and libraries)
  • Support for distributed databases
  • Many high-quality GUI tools available
  • Commercial support widely offered

PostgreSQL Strengths

  • Object-oriented features
  • Advanced programming concepts
  • Supports multiple programming languages
  • High ANSI SQL conformance
  • Mature high-end features
  • Robust online backups
  • Very liberal BSD license

In summary, PostgreSQL and MySQL are both mature products with many enterprise level features. They are both catching on with the best commercial RDBMS and are presently making inroads into the high-end market. The philosophy of both RDBMS differs in several ways. Roughly speaking, MySQL is targeted at developers who expect a workhorse database with proven performance, while PostgreSQL is suitable for developers who expect advanced features and programming concepts. MySQL offers more deployment options, whereas PostgreSQL offers more flexibility for developers.

Freebie of the Month: PSPad

A good plain text editor is the Swiss army knife of every programmer. Unfortunately, the Windows operating system offers only the “Notepad” program in this category, which is the equivalent of a $1.50 plastic knife. If you want to do more than opening an occasional README.TXT, then Notepad is definitely underpowered. This situation has created a market for commercial text editors, such as Ultra-Edit, CodeWright, EditPlus and others, which are excellent products, however, these programs are not free. In the open source arena there are well known editors, such as GNU Emacs and vim, which have evolved on the Unix platform. These editors are very powerful, but they are quirky and not exactly easy to learn and use. Why put up with a learning curve, when more user-friendly products are available? A multitude of freeware text editors with varying features is available for the Windows platform.

When I searched the Internet for a freeware editor, I was looking for raw power, speed, and features. In that order. The PSPad editor written by the Czech author Jan Fiala fits the bill perfectly. First of all, it is fast. Even on a modest Pentium IV computer, it starts up in less than two seconds. This is an important characteristic, since a text editor might get loaded dozens of times in succession for viewing or changing different files. It also makes it convenient to use PSPad when I don’t want to fire up a “heavy duty” IDE, such as Eclipse.

PSPad’s look is neat and functional. It presents itself with customisable tool bars, tabbed editor windows and a logically structured menu. Text windows can also be floated or tiled. The feature set of PSPad can compete with commercial high-end products. It includes syntax highlighting for dozens of programming languages, auto backups, macros, hex edit mode, integrated diff comparisons, pluggable text converters, customisable short-cut key map, spell checker, support for Windows, Unix, and Mac line endings, support for different character sets, HTML formatting and HTML validation through Tidy. This makes it ideal for editing a wide variety of file types from C++ source files to HTML pages, SQL statements, XML files, and shell scripts.

One feature I really liked is the multi-language code explorer, a feature that is otherwise only found in high-end IDEs. The code explorer seems to be capable of displaying almost anything from the DOM tree of an HTML document to a PHP or Java class. However, the most important aspect of a text editor for me is powerful search and replace capability. In this area, PSPad once again delivers. PSPad supports Perl-compatible regular expressions for search and replace operations, which is a make-or-break criterion for automated text processing. It also supports search and replace in multiple files, even recursively in subdirectories, which is again great for automated processing. The only limitation is that it cannot do both at the same time. It either processes regular expressions or multiple files, but not both. I am not sure why this limitation exists. Without it, PSPad would be pretty close to perfection.