2004-12-16

Five faces of a web application: Web GUI, web service, CLI, API, data

While working on our new web application DC5, a total rewrite of its predecessor DC4, it occurred to me that you could say there's five ways of looking at a web application, five interfaces that matter to its users.

Getting any of these right, making it beautiful, is an art in itself. Getting all of these right seems to be the ultimate goal for a web application, and should result in a wonderfully versatile and transparent piece of software:

  • The web interface: Naturally, the GUI (graphical user interface) will get a lot of attention while you're developing your web application. Functionality, design, usability, security, browser compatibility are the important things to consider. Often, there's two web interfaces, one for administrators and one for end users. Expect to see lots of web applications exposing a beautiful HTML user interface, but neglecting some of the following interfaces -
  • Web services: Today, people start to expect that your web application will provide network access to its data in the form of XML over HTTP (be it SOAP, XML-RPC or REST). This is a good thing - integrating data from multiple sources and locations is becoming so much easier once your data has URLs and a well-defined XML format. Seems to me that choosing protocols, URLs and formats takes some time...
  • Command line interface (CLI): Probably the most-neglected interface of web applications. Imagine you're an adminstrator and have to import lots of data into the web application. You will not want to do this through a web page, nor through a web service. Or you want to do a batch update, and the modifications you'd like to apply would be easy to express in Perl, or in XSLT: A good web application will provide you with command line executables or scripts, allowing you to process its data with standard Unix tools. You have the most power at your fingertips while you're at your server's command line!
  • Application Programming Interface (API): Even if you weren't planning that users interact with your web application from within a programming language, you would still need to develop and maintain a consistent API for yourselves (the application developers) - you use it to implement the three interfaces above. Once you have such an API, you may as well document it and advertise its use to others. Encouraging users to program add-ons using your API may at best result in a community contributing valuable code to your application. And at least, the users who have knowledge of your application's programming language will less likely be drawn away because of missing features.
  • Data structures: What will happen if you throw away all your code, keeping just the data of your web application? Will there be a meaningful directory or database layout, easily accessible and comprehensible by outsiders, or by yourselves two years later? It will be even better if your users know which data they may modify directly, without using your application; this would bring the power of SQL (or find/grep/sed) to them.
Thu, 16 Dec 2004 15:30:30 +0000

Camels and Rubber Duckies

Joel Spolsky - Camels and Rubber Duckies

"A lot of other good technologies have doomed themselves with high prices: Apple WebObjects was irrelevant as an application server because it started at $50,000. Who cared how good it was? Nobody ever used it! Anything made by Rational. The only way these products get into the hands of users is with an expensive full-frontal sales pitch. At these prices, the sales pitch is made to the executive, not the techie. The techies may well actively resist bad technology with good sales that the executives force down their throats. We have lots of FogBugz customers who have high-priced Remedy, Rational, or Mercury products sitting on the shelves after investments of well over $100,000, because that software isn't good enough to actually use. Then they buy a couple of thousand dollars worth of FogBugz and that's the product they really use. The Rational salesperson is laughing at me, because I have $2000 in the bank and he has $100,000. But I have far more customers than he does, and they're all using my product, and evangelizing it, and spreading it, while Rational customers either (a) don't use it or (b) use it and can't stand it."

Thu, 16 Dec 2004 10:21:08 +0000
2004-12-14

The present and future value of Python

Jon Udell's Vancouver Python Workshop talk on The present and future value of Python:

"The endgame here is a hybrid data engine with object, relational, and XML surfaces. Could you build such a thing in Python? I don't see why not. If you can build a scalable high-performance object database like ZODB in Python, I'll bet you can build the kind of hybrid I'm talking about. Of course, there's not an infinite supply of Jim Fultons. And a lot of companies are chasing the universal database holy grail. Oracle and IBM have gotten pretty far down that road already. At the other end of the commercial spectrum, OpenLink Software's Virtuoso has been delivering the goods for a couple of years now. In the open source world, I'm not sure where things stand. Postgres and ZODB and MySQL and Berkeley DB XML are all pieces of the puzzle, but I don't see any plan for fitting them together."

See also The Register - IBM moves the database goalposts...

Tue, 14 Dec 2004 12:21:35 +0000
2004-12-13

Software Engineering Practices for Large-Scale PHP Projects

From 2002, J. Scott Johnson's Software Engineering Practices for Large-Scale PHP Projects presentation (viewable with Internet Explorer only):

"Aspects of Large Scale Projects:

  • Version control
  • Design notes
  • Code reviews
  • Knowledge capture
  • Bug tracking
  • Test plans
  • Event Logging Throughout The Code
  • Error Handling Throughout The Code
  • Dynamic Error Alerting (to administrators)
  • Redundancy
  • 0 Data Loss
  • Translation
  • Human Understandable Error Messages
  • Separate the HTML from your code
  • Separate the text from your code
  • Documentation"
Mon, 13 Dec 2004 11:28:09 +0000
2004-12-07

A HOWTO on Optimizing PHP

John Lim - A HOWTO on Optimizing PHP with tips and methodologies:

"In this chapter, we explain why optimizing PHP involves many factors which are not code related, and why tuning PHP requires an understanding of how PHP performs in relation to all the other subsystems on your server, and then identifying bottlenecks caused by these subsystems and fixing them. We also cover how to tune and optimize your PHP scripts so they run even faster."

Tue, 07 Dec 2004 15:47:53 +0000

Apache JMeter

"Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions. [...] It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load."

Tue, 07 Dec 2004 12:55:42 +0000
2004-12-06

Tyranny of the geeks

Sriram Krishnan - Tyranny of the geeks:

"Nowadays, it is the 'in'-thing to be CSS-aware. If you're dumb enough to use a table tag, you're branded as a clueless moron. However, no one really tells you why table tags are bad. In fact, the equivalent CSS for generating something like your standard sign-up form is downright scary. And with every browser (Opera, Firfox, IE) having a different idea on what 'right' CSS is, you're much safer with table tags. For those using CSS and use divs and floats to build their tables, I ask them why. Why do something that is so un-intuitive? I could teach a kid about rows and columsn.

[...] A year ago, I read up a lot on the Semantic Web and RDF. I have to admit that I didn't understand any of it. Any of it. Ontologies, RDF, OWL, what not. However, you see blogs and enclosures getting the same effect with only a fraction of the complexity. I dont need smart agents to find what I want - I just search in Google and it is usally smart enough to give me what I need. I dont have high hopes for the semantic web unless they simplify and do it real soon."

Mon, 06 Dec 2004 11:45:32 +0000
2004-12-01

Which PHP libraries do you use?

Harry Fuecks asks - Which PHP libraries do you use?:

"For interest, wondering what PHP libraries people use? By use I mean libraries you actually trust and are willing to use / have used on a live website."

The replies (comments) are interesting, a lot of people seem to use PHPMailer and ADOdb, and JpGraph. PEAR stuff gets used (but also rejected/criticized) a lot.

Wed, 01 Dec 2004 14:14:58 +0000