This two year old post about Rasmus Lerdorf’s PHP scaling tips (slides) is interesting in the context of what we’ve learned since then. APC now seems common, and it’s supposedly built-in to PHP6. Still, I’d be interested in seeing an update. Are MySQL prepared statements still slow?

And that’s where Rasmus’ latest presentation comes in. We don’t learn anything about MySQL prepared statements, but we do learn how to find choke points in our applications using callgrind and other tools. In his examples, he can do a little over 600 transactions per second with both static HTML and simple PHP, but various frameworks — with many inclusions and function calls — can slow that to under 50 transactions per second (I suppose they’d explain that in a TPS report).

JSONLint, a JSON validator, was the tool I needed a while ago to be able to play with JSON as format for exchanging data in some APIs I was working on a while ago. And now I like JSON well enough that I’m thinking of using it as an internal data format in one of my applications, especially because it’s relatively easy to work with in JavaScript. Or, at least that’s the promise.

What I’ll need is an easy way to manipulate the contents of a simple array, and these JSON editors may give me a start.

The Braincast JSON editor was the first I found, but it doesn’t allow creation/expansion of the JSON. Katamari’s JSON editor seems to work and has a lot of features and a post 2005-looking interface, but that doesn’t make it simple. Worse, I don’t think it’s available for me to re-use, modify, or extend in my projects. Thomas Frank’s JSON editor, on the other hand, does have the features I need and a GPL license. That’s the place to start.

Extra: a JSON diff.

Robert Hoekman, Jr is speaking now on Designing the Obvious, his book and philosophy:

These principles include building only what’s necessary, getting users up to speed quickly, preventing and handling errors, and designing for the activity.

I just added the book to my must read list, but what I’m hearing here sounds like instructions to a sculptor: chip away all that is not David.

Designing the Obvious, Robert Hoekman Jr, design, web applications, WordCamp, WordCamp2007, WordPress

Web 2.0 has matured to the point where even those who endorse the moniker are beginning to cringe at its use. Still, it gave me pause the other day when Cliff (a sysop) began a sentence with “Web 2.0 standards require….”

Web 2.0 is now coherent enough to have standards? We used to joke about rounded corners and gradient blends being the rule, but something more has indeed emerged. O’Reilly defined Web 2.0 by example, Time Magazine echoed Kevin Kelly’s assertion in naming You as person of the year: Web 2.0 is about people. And “the rules” are emerging as a matter of market forces and natural selection.

Open Source

No matter your position on the Free Software Foundation’s philosophy, open source development reduces costs while improving quality and helps projects get to market faster with new ideas.

Flickr is among those that’s been rather public about their use of the LAMP stack, though Google and others have quietly built their business on it too. WordPress, a rare example of a downloadable Web 2.0 application, has enjoyed active development (and even a resurrection) due to its GNU license.

Still other Web 2.0 applications extend the open source model further. Open source content, or the user’s ability to declare a Creative Commons license on their content in these Web 2.0 applications is becoming common (and demanded by some). We may argue about the efficacy of Wikipedia, but the fact is that it’s among the most likely sites to appear for a web search and it’s consistently ranked among the top sites for traffic.

Wikipedia’s early contributors, looking at a young site with an unclear value proposition, could trust that their work would be protected by license (specifically, the GNU Free Documentation License).

Built for Remixing

Amazon reports that almost a third of their sales are attributable to remixers and boasts 180,00 registered developers of their API.

Google Maps didn’t include a public API when first released, but the community responded with enthusiasm and quickly reverse engineered the JavaScript to build new applications. Google responded by releasing a public API, making internet mapping and Google almost synonymous.

Dan Cat mashed up flickr and Google Maps on his own before Yahoo!/flickr snatched him up to build those features into flickr’s own site. But the company still enjoys the efforts of developers building applications to the flickr API, independently developing new features and adding value to the service.

Like open source, remixability and APIs engage a larger pool of talent than is available inside any company and serve two very important audiences: those who want features and those who care about their exit strategy. Neither group is remarkably large, but both are influential, passionate users. (More: Usability, Findability, and Remixability, Especially Remixability.)

Well Behaved and Social

Predictable and reliable URLs are essential to allowing users to bookmark and link to your site; well-formed semantic markup makes it easier for screen readers and search engines to make sense of the content. Semantic markup and microformats aid in remixability, contribute greatly to the Semantic Web, make site redesigns easier, and generally display better in a broader variety of formats and clients (think HTML vs. RSS).

People are anxious to leave comments telling us how right or wrong we are, so a site without comments/trackbacks/pingbacks is turning its back on its users. Good sites recognize the value of their users and cultivate the community. Caterina Fake did a lot of that for flickr (see her comments on my first photos there), while MetaFilter exists entirely as a community.

That doesn’t mean users are itching to build somebody else’s site, the lesson is that personal value precedes network value. Good sites make it easier for people to do what they want to do, not what their boss or the site’s creator wants.

If it isn’t obvious already: empower the user to achieve their own goals and control their experience.

rules, web 2.0, web applications, open source, remixability, social software, well behaved

I’ve been working on MySQL optimization for a while, and though there’s still more to done on that front, I’ve gotten to the point where the the cumulative query times make up less than half of the page generation time.

So I’m optimizing code when the solution is obvious (and I hope to rope Zach into giving the code a performance audit soon), but I’m also looking at optimizing how PHP works.

Once upon a time, most of us ran PHP as a CGI, and every time a request came in, the PHP interpreter would have to launch, read/compile/execute the script, then spit out the result and shutdown. Now (hopefully) everybody’s running PHP as an Apache module, so all the time spent launching the interpreter, allocating memory and other resources for it, and then shutting it down and cleaning up after it, is done just once for each thread of Apache.

It might not sound like much, but I had a chance to compare CGI vs. module performance recently and found that a fairly simple, but frequently accessed script running as a CGI completely swamped a server as a CGI (creating a load average over 20), but was hardly noticed when running as a module.

But even as a module, the PHP scripts still need to be interpreted and compiled before they can be executed. And because of the way PHP works, this is done every time the page/script is requested.

Java programmers, among others, criticize PHP for this, but that small inefficiency is part of what makes PHP so easy to use (and popular). And that ease of use means people are building some really interesting apps worth scaling.

Anyway, there’s a solution to eliminate that inefficiency in PHP: intermediate code caching.

By caching the executable code generated by the interpreter, then the using the cached copy instead of the source script for the next request, you can enjoy the benefits of PHP’s easy development and compiled code’s fast execution time. A number of projects all promise anywhere from double to 10X jump in performance.

• ionCube PHP Accelerator
  This has the most recognizable “brand,” and some hosting providers even offer it, but it’s offered only in binary form and the license seems intentionally ambiguous (um, not free?).
• Turck MMCache for PHP
  Has a good performance chart, and is GPL’d, but development appears to have ended in 2003.
• afterBURNERr*Cache
  Yeah, I had to point to a page in the Wayback Machine, this project is dead.
• Zend Platform Performance Suite
  A commercial suite that includes piles of goodies, if you pay.
• APC: Alternative PHP Cache
  It’s under active development and includes Rasmus Lerdorf, the guy who created PHP, among the project leads. License: BSD-style (non-copyleft)

I haven’t actually tried any of these yet, but I’m looking for information and suggestions, and I’m likely to try APC, maybe even Zend soon. Just as soon as I make an app compelling enough (and large enough) to need it.

php, caching, acceleration, zend, apc, intermediate code cache, optimization, scaling, web applications

Just when we started wondering how much longer flickr would be beta, they announced gamma.

The new design had me scratching my head for a bit, but I’m coming to like the changes. The menu/toolbar in the header has direct links to a lot more stuff, while the stuff in the footer has many fewer links. I can’t really tell if there are any links missing there, or if they’re just organized better, as I really only used one or two of them anyway.

Searching is improved, and now there’s a fancy menu that pops up when you mouse over a buddy icon. Go take a look at it all.

Overall, it’s a nice improvement to my favorite online application.

beta, flickr, gamma, improved, redesigned, web application design, web applications, web design

Yahoo’s Tom Coats was of seven star speakers at Carson Workshops‘ Future of Web Apps Summit last month. As usual, Ryan Eby was pretty quick to point out his slides to me, mostly by way of pointing out Jeremy Zawodny’s translation of them.

If it’s not clear yet: I wasn’t there, though I very much wanted to be, especially given some of what can be found in the post-summit blog posts.

Still, there’s a lot to be learned from just this one slide:

1. Look to add value to the Aggregate Web of data
    
2. Build for normal users, developers, and machines
    
3. Start designing with data, not pages
    
4. Identify your first order objects and make them addressable
    
5. Use readable, reliable, and hackable URLs
    
6. Correlate with external identifier schemes
    
7. Build list views and batch manipulation interfaces
    
8. Create parallel data services using standards
    
9. Make your data as discoverable as possible

I’ve been making a lot of noise about Coates’ point number five in my own presentations about how to build an OPAC for Web 2.0 (though the lesson should be applied to every library application), but there’s a lot to like in all nine. And it’s a bunch easier to understand his point when you read Zawodny’s take on it.

Here are my favorite bits:

Use readable, reliable, and hackable URLs

If the URL is hard to read over the phone or wraps in email, you’re not there yet. Simplicity and predictability rule here. Consider something like http://socialshopping.com/item/12345. You can guess what that URL does, can’t you?

You may not grasp how important this is, but don’t let that stop you from worry about it. This stuff really does matter. Look at how most URLs in del.icio.us are guessable and simple. Mimic that.

Correlate with external identifier schemes

Don’t go inventing complete new ways to represent and/or structure things if there’s already an established mechanism that’d work. Not only is such effort wasteful, it significantly lowers the chance that others will adopt it and help to strengthen the platform you’re building.

You are building a platform, whether you believe it or not.

Create parallel data services using standards

Developers (and the code they write) will want to consume your data. Do not make this an afterthought. Get your engineers thinking about how they might use the data, and make sure they design the product to support those fantasies. Again, always default to using an existing standard or extending one when necessary. Look at how flexible RSS and Atom are.

Don’t re-invent the wheel [link added --Casey].

Make your data as discoverable as possible

The names and attributes you use should be descriptive to users and developers, not merely a byproduct of the proprietary internal system upon which they’re built. This means thinking like an outsider and doing a bit of extra work.

application design, Carson Workshops, FoWA, future of web apps, future of web apps summit, lib20, library 2.0, native to web, native to web of data, summit, tom coates, web 2.0, web applications, web design, web platform

Ryan Eby gets excited over LiveSearch. And who can blame him? I mention the preceding because it explains the following: two links leading to some good examples of livesearch in the wild.

Inquisitor is a livesearch plugin for OS X’s Safari web browser. It gives the top few hits, spelling suggestions where appropriate, and links to jump to other search engines.

Garrett Murray’s ManiacalRage is an interesting blog on its own, but he’s also doing some good AJAX on his search interfaces. Look first at the archive search. But also take some time to appreciate the new content search. Sure, you’ll have some complaints, but it’s his site and not yours and there are some ideas there that are pretty interesting and useful.

live, search, live search, livesearch, ajax, ahah, javascript, web, web applications, library, libraries

Ross Mayfield’s new social software list discusses Ning, Flock, Wink, Memeorandum, Sphere, and Rollyo.

social software, web applications

Top 10 Ajax Applications at A Venture Forth.

ajax, top ten, web applications

I have plans to apply AJAX to our library catalog but I’m running into a problem where I can’t do XMLHttpRequest events to servers other than the one I loaded the main webpage from. Mozilla calls it the “same origin policy,” everyone else calls it a cross-domain script exclusion, or something like that.

Some Mozilla folks are working on a standard to address the problem, but it could be quite a while before browser support is common enough to build for it.

So Plan A was to use simple AJAX with XMLHTTPRequest. Plan B comes from this crazy suggestion at Apple’s developer site: Remote Scripting with IFRAME. It looks like different functions are subject to different restrictions, so the theory is that a JavaSctript loaded in a page in a hidden IFRAME can call functions from the parent page and do pretty much everything we’ve come to expect of XMLHTTPRequest. Here’s an example they offer.

Crazy as it is it works, and it gets around some cross-domain script exclusions for some browsers, but it still gets trapped by Mozilla.

tags: ajax, apple, browser security, browsers, cross domain, cross domain script exclusion, frustration, iframe, javascript, mozilla, remote scripting, web application, web applications, xdomain, xmlhttprequest

That headline might seem a little late among the folks reading this. But we’re all geeks, and if not geeks, then at least regular computer users. Regular computer users, however, are a minority. Worldwide, only around 500 million people have internet access, and fewer than 100 million people in the US have internet access at home. With populations of over 6 billion and 300 million respectively, there’s clearly a lot of growth potential.

Truth is, computers are the poor cousins to phones and television in terms of market penetration. In the US, Nielsen estimates there are over 275 million people with TVs in their homes today, and the CTIA says there are over 180 million mobile phone users.

The market opportunity is clear, but I think our notions of what a “computer” is have to change. Yes, computers have been through a lot of changes in 20 some odd years, but they’re still very much the same. Some might say that cars are basically the same as they were 100 years ago because they all mostly run around of four wheels and be happy with it. But transportation has seen tremendous change. Computers as we know them don’t own the internet any more than cars own the road or railroad or bike trails or skies.

Email was the killer app that made people interconnect their networks, the web was the killer app that got 90+ million users online already. And those users are the critical mass that pushes the development of real web applications — applications that are starting to beat desktop apps at their own game and doing things that desktop apps can’t.

With this flowering age of web applications, the age of internet connected information devices is coming. But we need something different from the computers we’ve become accustomed to. We need a device that is designed to serve the 90 million Americans who have cell phones, but don’t appear to have their own computers or home internet access. We need a device that replaces TVs as the leading entertainment and news medium. Because the information age will have arrived when there’s a dozen kiosks in every mall hawking internet tablets and we see them lined up at Best Buy with differentiated models for the kitchen, living room, the kids rooms, and for camping.

Background: this post is grew out of some discussion at TeleRead, NoSheep, and here at MaisonBisson.

tags: access, change, change computers, computer, computing, critical mass, desktop apps, email, geek, geeks, information age, information system, internet, internet access, internet connected, killer app, market opportunity, network, paradigm shift, penetration, portable computing, web, web applications