Raible Designs

Building Rich Applications with Appcelerator

This afternoon, I delivered my Building Rich Applications with Appcelerator talk for the 3rd time at Colorado Software Summit. When I first proposed this topic, I hadn't used Appcelerator and saw this as a good opportunity to learn more about it. I'm glad I did.

IMO, Appcelerator is a lot like Dojo in how it parses pages and turns HTML with special attributes into JavaScript widgets. I can't help but think a pre-compilation step would be nice to speed things up. I like Appcelerator's extensive Widget Library, and I especially like that they re-use many widgets rather than re-creating their own. Finally, I really dig the "SOA in a browser" approach where everything is a message and you can easily publish and subscribe to events - on the client and server. Below is my presentation, please let me know if you have any questions.

Applying Flash to Java: Flex and OpenLaszlo with Dustin Marx

If you're going to choose Flex or OpenLaszlo, chances are you're targeting Flash. The Flash Player allows you to abstract the browser idiosyncrasies and give users a better experience. It hides the browser quirks from both developers and users. It's also a highly ubiquitous web browser runtime environment. It provides a user experience way beyond traditional HTTP request-response. Also, its visual effects and "richness" rival of non-browser desktop applications.

Mark's blog stats show that 95% of readers are using Flash 9 and 1% is Flash 10. All others don't have their version exposed. Most other sources claim that Flash 9 has 98% penetration in mature markets. One of the nicest things about Flash is it frees users from limitations of traditional web applications. Request/response is largely a thing of the past and Ajax-like behavior was built-in from the beginning.

Flash Criticisms: has reduced SEO as well as bookmarking and URL history support.

Flash Player Criticisms: not open source, no significant alternative, no 64-bit player, loading performance and it's only useful for games, movies and annoying advertisements.

The good news is Flash is getting better. There's currently a SWF Searchability initiative with Google and Yahoo!. For bookmarking and URL History, you can use "deep linking" with mx.managers.BrowserManager and mx.managers.HistoryManager. Flash Player issues are also being addressed. There's a Flash Open Screen Project, there's a 64-bit player in Adobe Labs and Flash 9/10 is much better than in the past.

To prove that Flash is a compelling technology, all you have to do is look at Microsoft's Silverlight and Sun's JavaFX. These are direct competitors that are fairly new and prove that companies like what Flash has.

Flex
Flex is not Flash. Flex requires Flash (9+), but Flash does not require Flex. Flex is a language and framework and applications are compiled into .swf files. Flash is the runtime environment that executes .swf files. Flex 3 is FREE. The Flex SDK, compiler and debugger are open source. They have no license costs. BlazeDS is also open source and has no license cost.

Flex MXML was formerly called Macromedia XML. It's an XML-based presentation/layout language that's editable with any text editor or IDE. MXML is to ActionScript 3 as JSP is to Java. MXML provides the layout and ActionScript provides the dynamic business logic.

ActionScript
ActionScript is an ECMAScript implementation that's been proposed as the Edition 4 implementation. It's not your older sibling's JavaScript. It uses class-based object-oriented features and static typing. Thanks to the Flash Player, it works the same across multiple browsers. Most of the things you can do with MXML, you can do with ActionScript. However, MXML typically requires less LOC.

ActionScript allows packages, interfaces, inheritance, objects and methods. It includes extensive XML Support, particularly E4X (ECMAScript for XML). It has a large class library and can talk directly to the Flash Player. Finally, it has many Java-like features and it's syntax looks similar.

At this point, Dustin started doing demos of two popular Flex components: RichText Editor (which creates horrible HTML) and Data Grid. More third-party Flex components seem to appear every day. Examples include flexlib, ASDIA as well as all those listed on FlexBox. Additionally, it's not too difficult to create your own Flex components (no proof provided).

Flex's property binding is one of Dustin's favorite features, but he says he has a difficult time conveying how cool it is. Property binding allows you to tie data in one object to data in another object. Updates in one object affect another. To use it in MXML, you can use curly braces or the tag. In ActionScript, you can use the BindingUtils object. You can also use Flex's metadata annotation "Bindable" to denote bindable objects.

To compile Flex applications, you can use mxmlc from the command line. You can use Ant with the <exec> task or using Flex's Ant Tasks. You can also invoke mxmlc from Java as long as you include mxmlc.jar in your classpath. FlexBuilder is an Eclipse-based IDE that's not included with the free Flex SDK. It's not a free product and can be used as a plugin or a standalone IDE.

Flex and Java
There's two predominant out-of-the-box methods for Flex to communicate with Java EE backends.

• HttpService: traditional HTTP request/response.
• WebService: SOAP-based Web Services.

If the above two methods aren't fast enough, you can use BlaseDS and it's additional options.

• Web Messaging: HTTP publish/subscribe with JMS, ColdFusion and/or other Flash/Ajax client.
• Remoting with AMF: access server-side objects from Flash client-tier as if they were hosted there.

Flash applications can access either a client's machine or a remote site, but not both. You can use a crossdomain.xml file on your server to allow remote Flash clients to connect. This file allows access for both Flex and OpenLaszlo applications.

BlazeDS adds proxy server support for HTTPService and WebService. To use, set the useProxy attribute to "true". Features include authentication and logging. It adds a new RPC mechanisms called RemoteObject. This object allows ActionScript and Java EE transparent integration. It also adds publish/subscribe messaging with a JMS Adapter available. Lastly, it adds Ajax support to your Flex application.

GraniteDS is an open-source (LGPL) alternative to Adobe LiveCycle and is similar to BlazeDS. It has COMET-like functionality and supports Spring, Spring Security, EJB 3, Seam and Guice.

Flex Frameworks: Cairngorm (Adobe Consulting), Pure MVC, Mate and many others.

Flex 4 (Gumbo) will have improvements for designers (easier customization, better tool support), improvements for developers (faster compiler, two-way data binding) and will leverage new features of Flash 10.

OpenLazlo
OpenLaszlo 4 is XML-based and uses an XPath syntax for data access. OpenLaszlo was actually created before Flex and is ECMAScript-based. Unlike Flex that requires Flash 9, OpenLaszlo is architected to deploy on different runtime environments, including: Flash 7/8/9 and DHTML. Dustin believes OpenLaszlo would be a lot more appealing if your source code could be compiled into Silverlight or JavaFX.

OpenLaszlo's syntax looks a lot like Flex, except it does not use namespaces. OpenLaszlo's Constraints are similar to Flex's property binding, except the syntax is a bit different. You use ${} in LZX tags or applyConstraint() and LzDelegate in scripts. OpenLaszlo's event handling is similar to Flex and JavaScript event handling. All attributes have an implicit "on" event that is triggered when an attribute's value is changed. Event handlers can be written CSS-style in LZX nodes or using the <handler></handler> tag. Script code can be embedded in LZX XML in many ways:

• Inside event attributes
• Within <script></script> tags
• Within <method></method> tags
• Within <handler></handler> tags
• In a separate file (<script src="someFile.js" />)

Dustin believes the debugger and view-source tools in OpenLaszlo are much better than the ones available for Flex.

For the rest of the presentation, Dustin covered many of Laszlo's feature, how they relate to Java as well as how to integrate SWF and HTML. SWFObject is Dustin's preferred method for adding Flash to HTML. One of its nifty features is it allows SWF-to-SWF communication.

This talk was an excellent and in-depth overview of Flash, Flex and OpenLaszlo. I especially liked all the details on ActionScript and the different methods for remote communication. Nice job Dustin!

What's Coming in Spring 3.0

This morning, I delivered my What's Coming in Spring 3.0 talk for the 2nd time at Colorado Software Summit. Since there is no Spring 3.0 source code to speak of, I was unable to do the "Choose Your Own Adventure" demo at the end.

The good news is I was able to easily upgrade the Spring Kickstart application from Spring 2.0 to Spring 2.5.5 (using annotations). When 3.0 is released, I hope to update this project to use 3.0 as well as show what I needed to change. If I get ambitious, I might even change the UI to use Flex or Ext JS to show a RESTful client. Below is my presentation - hope you enjoy.

Comprehensive Project Intelligence with Jason van Zyl

In this talk, Jason is going to talk about m2eclipse, Nexus, Hudson and Maven. On his Maven bullet-point, it says "The best is yet to come (and we'll fix a bunch of stuff)!"

m2eclipse
The m2eclipse plugin has improved greatly in the last 4 months - there's now 5 full-time developers working on it. If you use the m2eclipse plugin, you never have to leave the IDE for your Maven-related work. m2eclipse has a Configuration Framework that turns Maven's mumbo-jumbo (Jason's words, not mine) into Eclipse talk. The m2eclipse+configuration framework has integration for WTP, JDT, AJDT and they're working on one for Flex. Below is a screenshot of how m2eclipse helps developers stay away from using command-line Maven.

Now Jason is showing a demo of m2eclipse and creating a new Maven project from existing archetypes. It looks like m2eclipse uses "Nexus Indexer" as its Catalog. Presumably this is a Sonatype-hosted service. The Nexus Indexer contains an of Maven Central and is very fast. It's dynamically updated as new things are deployed to Maven Central.

If you use m2eclipse and open a pom.xml, you'll get a visual view rather than an XML view. This UI has tabs for Overview, Dependencies, Repositories, Build, Plugins, Reporting, Profiles, Team, a Dependency Hierarchy and Dependency Graph. You can easily add new dependencies and it finds things quickly because it's using the Nexus index. In addition to visually adding dependencies, you can modify the raw XML and get things like groupId and version code-completion.

Once you have your dependencies listed in a "Maven Dependencies" container to you can "Materialize Project" to create a project from the binary dependency. You'll get the source as a new project in your workspace as well as having your binary dependency turned into a source dependency.

You can easily create a run configuration that runs certain goals, allows you to activate profiles and uses an embedded version of Maven or an external installation. I asked Jason if the Dependency Hierarchy had a right-click -> exclude feature and he said it doesn't exist yet, but it will in the release after next. For now, the pom editor is just eye candy and doesn't have actions.

For Maven Plugins, m2eclipse has workspace resolution so you can develop a plugin and use it in a project at the same time w/o having to install the plugin over and over.

Sonatype has created a Project Materializer Plugin that allows a team lead to create a project for developers. It allows you to create a welcome page that has links, cheat sheets, News and Updates and Tasks for the developer. It also materializes Eclipse projects in the background. Cheat Sheets are a series of tasks that can be run to show developers how to do things.

Another big feature in m2eclipse is nested project support. It only works in Eclipse 3.4 though.

Nexus
Nexus is a repository manager that allows you to keep the cruft from the outside world out of your system. It's primarily for Repository and Configuration Management. It has fine-grained security for authentication and authorization. One nice feature of its security system is you can prevent certain users from seeing source JARs. It also has virtual repositories (a savior for OSGi lovers). UI is written in Ext JS and acts as a simple REST client for Nexus. It has a full REST API using RESTlet.

A repository manager allows you to protect yourself from the Open Source Ghetto. The OS Maven Ghetto has bad POMs, repositories in POMs, mixed snapshot and release dependencies and screwed up metadata. Not only does it offer protection, but it allows you to aggregate repositories and publish your internal artifacts to it. It also allows you to schedule tasks that clean out snapshots so your repositories don't grow out of control.

Typically people deal with OSGi runtimes manually. OSGi can dynamically update dependencies that you drop into your bundle repository. However, many folks maintain their OSGi runtime and bundle repository locally. Some people are trying to get an OSGi runtime to resolve against a P2 repository. P2 is what Eclipse uses for their repository management. Nexus has the ability to lock down the versions that are available to an OSGi runtime. Furthermore, you can use Nexus to manage the versions that get deployed to all your servers. This makes it a lot easier for QA and Production to manage versions of your artifacts. OSGi is great for modularity and solving classpath issues, but it does have issues with versions and how its ranges work.

You can see Nexus in action at http://repository.sonatype.org. It can be configured entirely through the UI, an XML file or through the REST API. RSS feeds exist for configuration and repository updates.

Nexus is free and open source with a GPL license. The next version (1.2) will contain a Plugin API to allow extensions. All of Sonatype's enhancements for its commercial version will be written as plugins. A matrix of what's available in the open source version vs. commercial version should be published sometime next week.

Hudson
Jason believes that Hudson is the future of continuous integration, on-demand results and release management. They're writing all their extension points in Hudson as Maven plugins and Plexus components (with the work they've done, using Spring components should also be possible). Other enhancements they've made to Hudson:

• Integration of JSecurity
• Implementing a similar REST layer as Nexus and creating a UI using Ext JS
• Automatic installation of external Maven installations
• Drools Workflow Integration

They've also enhanced Hudson so it can easily test/publish Maven projects without using the free-form project template. Hudson works well for doing Eclipse headless builds for Eclipse plugins. If you need to test against multiple databases, multiple OS's, it does support a grid-based system that's easy to setup. Hudson does have web services integration that allows you to kick off builds from within Eclipse. Sonatype uses Hudson to run all their nightly builds of Maven.

Maven - the best is yet to come
The three big things coming in the next version of Maven are:

• Refactored Project Builder: includes a spec for building a pom, domain-specific parsers (attribute-based XML, Groovy and Ruby) and mixins.
• Mercury: a new repository and transport layer. Developed by the Jetty people and is super fast (async client with connection pooling and parallelization). Has atomic downloads and deployments (with Nexus), full PGP support and a WebDAV client built-in.
• Maven Embedder: re-written to actually work.

Overall, a good talk with lots of demos. I'm definitely looking forward to Maven improvements in the future.

Building LinkedIn's Next Generation Architecture with OSGi by Yan Pujante

This week, I'm attending the Colorado Software Summit in Keystone, Colorado. Below are my notes from an OSGi at LinkedIn presentation I attended by Yan Pujante.

LinkedIn was created in March of 2003. Today there's close to 30M members. In the first 6 months, there was 60,000 members that signed up. Now, 1 million sign up every 2-3 weeks. LinkedIn is profitable with 5 revenue lines and there's 400 employees in Mountain View.

Technologies: 2 datacenters (~600 machines). SOA with Java, Tomcat, Spring Framework, Oracle, MySQL, Servlets, JSP, Cloud/Graph, OSGi. Development is done on Mac OS X, production is on Solaris.

The biggest challenges for LinkedIn are:

• Growing Engineering Team on a monolithic code base (it's modular, but only one source tree)
• Growing Product Team wanting more and more features faster
• Growing Operations Team deploying more and more servers

Front-end has many BL services in one webapp (in Tomcat). The backend is many wars in 5 containers (in Jetty) with 1 service per WAR. Production and Development environments are very different. Total services in backend is close to 100, front-end has 30-40.

Container Challenges
1 WAR with N services does not scale for developers (conflicts, monolithic). N wars with 1 service does not scale for containers (no shared JARs). You can add containers, but there's only 12GB of RAM available.

Upgrading back-end service to new version requires downtime (hardware load-balancer does not account for version). Upgrading front-end service to new version requires redeploy. Adding new backend services is also painful because there's lots of configuration (load-balancer, IPs, etc.).

Is there a solution to all these issues? Yan believes that OSGi is a good solution. OSGi stands for Open Services Gateway initiative. Today that term doesn't really mean anything. Today it's a spec with several implementations: Equinox (Eclipse), Knoplerfish and Felix (Apache).

OSGi has some really, really good features. These include smart class loading (multiple versions of JARs is OK), it's highly dynamic (deploy/undeploy built-in), it has a service registry and is highly extensible/configurable. An OSGi bundle is simply a JAR file with an OSGi manifest.

In LinkedIn's current architecture, services are exported with Spring/RPC and services in same WAR can see each other. The problem with this architecture comes to light when you want to move services to a 2nd web container. You cannot share JARs and can't talk directly to the other web app. With OSGi, the bundles (JARs) are shared, services are shared and bundles can be dynamically replaced. OSGi solves the container challenge.

One thing missing from OSGi is allowing services to live on multiple containers. To solve this, LinkedIn has developed a way to have Distributed OSGi. Multicast is used to see what's going on in other containers. Remote servers use the OSGi lifecycle and create dynamic proxies to export services using Spring RPC over HTTP. Then this service is registered in the service registry on the local server.

With Distributed OSGi, there's no more N-1 / 1-N problem. Libraries and services can be shared in one container (memory footprint is much smaller). Services can be shared across containers. The location of the services is transparent to the clients. There's no more configuration to change when adding/removing/moving services. This architecture allows the software to be the load balancer instead of using a hardware load balancer.

Unfortunately, everything is not perfect. OSGi has quite a few problems. OSGi is great, but the tooling is not quite there yet. Not every library is a bundle and many JARs doesn't have OSGi manifests. OSGi was designed for embedded devices and using it for the server-side is very recent (but very active).

OSGi is pretty low-level, but there is some work being done to hide the complexity. Spring DM helps, as do vendor containers. SpringSource has Spring dm Server, Sun has GlassFish, and Paremus has Infiniflow. OSGi is container centric, but next version will add distributed OSGi, but will have no support for load-balancing.

Another big OSGi issue is version management. If you specify version=1.0.0, it means [1.0.0, ∞]. You should at least use version=[1.0.0,2.0.0]. When using OSGi, you have to be careful and follow something similar to Apache's APR Project Versioning Guidelines so that you can easily identify release compatibility.

At LinkedIn, the OSGi implementation is progressing, but there's still a lot of work to do. First of all, a bundle repository needs to be created. Ivy and bnd is used to generate bundles. Containers are being evaluated and Infiniflow is most likely the one that will be used. LinkedIn Spring (an enhanced version of Spring) and SCA will be used to deploy composites. Work on load-balancing and distribution is in progress as is work on tooling and build integration (Sigil from Paremus).

In conclusion, LinkedIn will definitely use OSGi but they'll do their best to hide the complexity from the build system and from developers. For more information on OSGi at LinkedIn, stay tuned to the LinkedIn Engineering Blog. Yan has promised to blog about some of the challenges LinkedIn has faced and how he's fixed them.

Update: Yan has posted his presentation on the LinkedIn Engineering Blog.

Appcelerator with Matt Quinlan

This evening I attended the Denver Open Source User Group meeting where the Basic Concepts talk was on Appcelerator. Matt Quinlan (Twitter, Blog, LinkedIn) was the presenter. I arrived 10 minutes late, so I didn't hear any of the intro stuff. Below are my notes from the event.

The Appcelerator developers liked the "onclick" syntax, but found it was too limited to do everything they wanted. Rather than onclick, they use an on attribute. For example:

<div on="click then l:show.box">
Click me
<div>

"DOM Manipulation is JavaScript cruft."

Appcelerator allows you to implement the Observer pattern in the browser. In addition to allowing DOM elements to subscribe to messages, server-side objects (in any language) can subscribe as well. In Appcelerator syntax "l:" means local and "r:" means remote. The messages that are passed to the server are JSON and have payloads. JSON is more popular than XML because you can eval() it and create JavaScript objects from it. Appcelerator allows you to do Declarative Ajax. On the server-side, you can annotation Java and C# classes with @Service to subscribe to messages. In other languages (i.e. PHP), Javadoc-style comments are used.

Tagline: The seamless fusion of RIA and SOA.

Web Expression Language
Goal is to eliminate 90% of the JavaScript you write. Example syntax:

on="[condition] then [action]"

Conditions include DOM events (click, focus, blur, change, mouse events), key events (up, down, press), other (history, drag/drop, selected, resize, iPhone orient, sortXYZ), subscribe to custom message. Actions include Scriptaculous effects (show/hide, fade, move, drop, grow), set element value (static, dynamic, bind), set CSS class or attribute, execute custom JavaScript, publish custom message.

Now Matt is doing a demo on http://try.appcelerator.org. This site consists of a form that allows you to type in Appcelerator code and run it. 3 attributes can be added to any tag: draggable, droppable and resizeable.

Client-Side
Add simple tags to your HTML to inject RIA widgets. Add single property to existing HTML elements for dynamic behavior. Eclipse Plugin built on Aptana, but is generally targeted towards web developers moreso than business analysts (no drag and drop of widgets).

Server-Side
Server-side development done with your IDE of choices. Based on your server-side tehchnology platform. Easily create services using annotations.

App Command
The app command is similar to Rails' GEM command. Allows you to build scaffolding and deploy to cloud (AppEngine, Amazon S3). It also allows you to pulldown components from the main server and auto-updating.

Examples:

• appTunes: widget that wraps Flex Cover Flow widget
• Snapshot: photo editing application
• Radio Javan: Persian music online
• SkyBlox: wireless company

Appcelerator allows you to create prototypes easily by using a JavaScript file with mocks for the server-side objects. In the next version, you can "annotate" the UI and allow end-users to Ctrl+Click on elements and add feedback. For an example of this, see http://dev.appcelerator.com/pearson.

When starting with Appcelerator, you can start by crawling (including appcelerator.js for widgets) then move to walking (decouple server-side and client-side) and finally running (developing working prototypes with mocks for server-side).

"Let's face it, ASP, JSP, PHP and Ruby are just lipstick on CGI."

Xebia RIA Framework Contest

Last year, I blogged about the Xebia Web Framework Contest where Struts 2, GWT, Wicket and MyFaces (JSF) were all used to develop the same applications. It seems they've done it again this year, comparing RIA frameworks (English translation) this time.

The winner? Flex - which doesn't surprise me a whole lot.

After this day, the Flex team, has clearly demarcated from its competitors. After two sprints of development and ownership, it could devote the third and final sprint to get rich quick and easy application, focusing only on the features and user experience. It is thanks to the wealth of high-level components, the wealth of documentation available and a maturity framework that the team has made the Flex application's most successful.

Good stuff - thanks Xebia!

Ajaxified Body

I've often wondered if it was possible to use Ajax to reload the main content of a web application without reloading the header, menu and footer. SiteMesh allows you to move these common elements to a decorator that gets wrapped around each page. Below is a diagram of how SiteMesh works.

You can read the Introduction to SiteMesh article if you're interested in learning more about SiteMesh's basic features. By default, SiteMesh decorates text/html responses and ignores any other content type (e.g. image/gif). It also contains an <excludes> configuration element that allows you to turn off decoration when a URL matches a certain pattern. For example, the following allows you to disable decoration when "ajax=true" is passed in the URL.

<excludes>
    <pattern>**ajax=true</pattern>
</excludes>

To optimize the loading of an application so the common elements aren't loaded for each page, it should be possible to create an Ajaxified Body where the primary content area (PCA) of the site is loaded via Ajax rather than refreshing the whole page. The header, footer and navigation bar often stays the same from page-to-page, so it doesn't seem to make a whole lot of sense to load them each time the page loads. The image below shows the PCA (of an AppFuse Light application) as a grey square with a red border.

Implementing an Ajaxified Body consists of the following steps:

1. Adding SiteMesh and moving common elements to a decorator.
2. Remove common elements from each individual page (if you're using includes).
3. Configure SiteMesh so decoration is disabled when the requested URL contains "ajax=true".
4. Write JavaScript that modifies all <a href=""> links (and buttons with onclick='location.href') in the PCA to have an onclick handler.
5. The onclick handler should call a JavaScript function that loads the link's URL + ajax=true using XMLHttpRequest (XHR).
6. Add XHR success handling to replace the PCA with the loaded content.
7. Add XHR error handling to go to the URL normally when response.status != 200.
8. Inspect the response HTML for <title> element and replace document.title if exists.
9. Inspect the response HTML for <head> element and append to current if exists.
10. Inspect the response HTML for <script> and <link> elements (JavaScript and CSS) and evaluate them if they exist.

As a proof of concept, I created a prototype using AppFuse Light (Prototype/Scriptaculous for Ajax). You can see a demo at the following URL. You can also download a patch or the source for this project.

http://demo.raibledesigns.com/ajaxifiedbody

Below are a number of things I discovered while writing this prototype:

• The hardest part of implementing this seems to be coding the exceptions. It's possible you'll have some links with existing onclick handlers and you may have to disable "ajaxifying links" for those links.
• A progress indicator is important or the page might load so fast that the user doesn't visually detect it changed. This can lead to a worse user experience because they don't see the flash of the blank page they're used to when a page load occurs.
• While forms can be submitted via Ajax, there's no harm in leaving existing form behavior in place where the full site is reloaded after submitting a form.
• If a particular page needs to change the common elements (header, menu, footer), it should be possible to do that with JavaScript after the PCA content loads.
• If the success/error indicator is outside the PCA, it may need to be populated and displayed/hidden with JavaScript after the PCA loads.

I'm sure my implementation can be improved, but I'm also curious to see what you think of this idea. I know it's not revolutionary, but it's something I'm considering adding by default to AppFuse and AppFuse Light. Do any Ajax frameworks do something like this out-of-the-box?

Update: Thanks to everyone for the great feedback - keep it coming. I agree that adding history support is a must. I'll try to do that in the next day or two. This post has also been featured on Javalobby and Ajaxian.

Update 2: Added history support.

Performance Testing Memcached

Earlier this week, co-workers and I did some performance testing with Memcached. We wanted to see how long it'd take to send different sizes of objects over the wire to Memcached on a remote server.

We setup a simple environment with 2 Mac Pros both running 2 x 2.8 Ghz Quad-Core Intel Xeon processors and 12GB of RAM. We used one machine as a Memcached server and one machine running an application with the addition of a new Servlet Filter. The Servlet Fitler read a size parameter and used it to set the size of the object being written and read from the Memcached server. We used JMeter to put load on the box. The following describes the load and the results.

Write Times
Write tests were performed with a single user executing 1000 sequential remove then writes.

Read Times
Read tests were performed using 50 users with 1 sec. ramp times executing 100 reads each.

During our tests, Memcached was started using the following settings:

memcached -d -m 2048 -M -p 10171 -vv

If you've done similar performance testing with Memcached, we'd love to see your results.

Abbie gets her first tooth and The Bus looks great!

Today was quite the day. First of all, Jack and I took Abbie to A Wild Smile to get a couple front teeth yanked. She has her first adult tooth coming in and her baby teeth weren't getting out of the way. Before and after pictures are below:

This afternoon, I drove to Colorado Springs to see The Bus and speak at the Colorado Springs Open Source User Group. The Bus looked great. Motorworks Restorations has done a lot of very detailed work (i.e. replacing corners, stretching the frame, replacing window and door drains) in the last couple of months.

We talked for a good hour about the possibilities in wheels, transmission, engine, suspension, gauges and interior. My favorite topics were the air bags, 6-cylinder 911 engine and safari windows. Click here to see the full set of pictures I took. Quote of the night: "It's going to be better than it was when it was brand new."

After leaving the bus, I delivered my Web Frameworks of the Future Presentation to a bunch of guys (and gals) at a nearby library. It was a fun presentation because I got to meet a lot of folks I had name recognition for, but had never met. All in all, a very good day.

Tomorrow marks my last day of work before I head out on a week's vacation in Munich for Oktoberfest. I have a feeling the days are going to get a lot better from here on out.