On Wednesday afternoon, I attended the session, “Creating Compelling User Experiences”, by Ben Galbraith from Mozilla. It was a very interesting session, with lots of quotes from user interface luminaries. My favorite was a quote from usability expert Louis C. K. - “Everything’s amazing, and nobody’s happy”.
My take-aways were:
- Good back-end software is necessary, but not sufficient - if your software has amazing capabilites, but the users hate the interface, they probably won't use it.
- When thinking about user interface, break it into to categories - visual design and interaction design. Again, if your ui looks great, but is inconvenient to use, people won't use it. If it's easy to use, but ugly, you may also drive people away.
- Users expect to be able to customize your software, but will be overwhelmed by too many choices, and probably will be overwhelmed even by a relatively small set of simple choices if they are layered. Much better is a choice like "Vanilla, Chocolate, or Strawberry?". Advanced users will want more, and you should give it to them, but not force it on the majority who don't. Provide reasonable defaults.
- Only end-users can truly personalize your software - hence the success of GreaseMonkey, etc.
The “Maximizing Java Performance on Multicore Platforms” session was presented by Kingsum Chen, a Principal Engineer for Intel, and David Dagastine, Java Performance Lead for Sun.
While there was a little bit of discussion about multicore Java performance in general (it boiled down to “break your workload up into as many threads as your hardware/os can handle”), most of the discussion was about Sun and Intel have worked together to do extensive optimization of the JVM specifically for Intel’s new Xeon 5500.
Apparently, the work has paid off handsomely - this Sun/Intel collaboration claims an eight-fold increase in benchmark throughput in the last three years. They have also worked very hard to make Java on 64-bit architectures at least as fast as on 32-bit (and sometimes faster). Some of the optimizations include memory addressing, garbage collection, array copying, string cache, and XML transformations (they claim a 3x throughput on XML transformations).
Assuming a server with dual-Xeon 5500s running 64-bit Solaris, Linux, or Windows, the general performance recommendations include:
- Use JVM 1.6 update 14
- Turn on JVM optimizations (some are on by default w/ Solaris):
- Leverage plentiful hardware threads
- Minimize writes to shared data
- Run 1 JVM - optimizations don't currently work across JVMs (they're working on this, though)
- Choose your garbage collector appropriately (new parallel gc now default on all platforms).
- Use large pages ( -XX:+UseLargePages) - works by default in Solaris, may take some system-level configuration on other operating systems - can give 5% - 15% improvement.
- Use NUMA if available (-XX:+UseNUMA)
Recommended tools included Visual VM, Lint for Java, JDump, and Intel’s VTune. VTune was demonstrated, and was very impressive.
At dinner time, Adobe threw a party at a bar / restaurant around the corner from the conference. It was an extremely short demo, followed by an Open Bar, free food, and about a dozen pool tables. Happy campers all the way around.
In the evening our own (Chariot’s) Aaron Mulder led the “Birds Of a Feather” (BoF) session on Open Source tools for SOA. It was an interesting discussion, with lots of real-world examples, and a good bit of audience interaction.
Items covered included XML mapping tools like CXF and Jersey, Messaging infrastructure including ActiveMQ and JBoss Messaging, “Re-usable Integration Logic” projects including Apache Camel and Spring Integration, and full-on ESB products like Mule, ServiceMix, OpenESB, and JBoss ESB.
The major take-aways here were:
- You can often get away with messaging and xml mapping, or one of the integration projects, without going to a full ESB.
- Integration projects often work out with open-source tools, but sometimes wind up moving to commercial vendors.
- Those who do go the full-ESB route with open-source tools rarely need to go to commercial vendors.
- SOA governance is mostly a political / organizational problem, not a technical problem. Solve the organizational problem first, then pick a tool that meets your needs. There is no magic bullet.