Mojo's blog banner
  • “The Keys to Agile Software Development” Jon Kern

    The tech crew enjoys some breakfast before the morning keynote.
    The tech crew enjoys some breakfast before the morning keynote.

    Notes from TheServerSide Java Symposium March 2009

    Jon’s a fine fellow, but his talked (to me) seemed mostly to be stating the obvious.  I’ll just provide his “Rules to Code By:”

    • It’s the Business, Stupid
      Not all shiny new toys should be fondled
    • A fool with a tool is still a fool
    • Don’t mistake activity for progress
      Hard to get work done when you are always in meetings
    • Your team should hit a stride
      Development should feel cyclical and rhythmic
    • Be impatient
      Don’t tolerate waiting (for long)
    • Be lazy
      Don’t do tedious, mediocre chores over and over
    • Have fun — or take a break
  • “The Amazing Groovy Weight-Loss Plan” Scott Davis

    Notes from TheServerSide Java Symposium March 2009

    Scott Davis was the perfect presenter for the deadly “after lunch” session period. Interesting that his Groovy introduction is in a breakout room rather than the main ballroom, and there is not an empty seat in the house. Everyone is fascinated by these new powerful JVM languages, including me.

    Scott started by asking who was a Java programmer in the house, a silly question at a Java symposium. He followed by asking who were Groovy programmers, and two or three hands went up. Followed by “Aha! Just by adding one JAR file to your classpath, you’re all Groovy programmers too.”

    He immediately quit using slides, and went directly to live coding. Fabulous for a software talk! He started with a one-line “Hello, World” and then moved on to show off Groovy’s object and dynamic type features.

    He’s using javap to explore groovy-created class files and show how the underpinnings relate directly to the Java infrastructure.

    Admittedly, these powerful JVM languages are very seductive. They call them scripting languages, and yes, they’re great for scripting. But full powerful languages like Groovy, Scala, JRuby, Jython, and even JavaFX have enormous potential. I’m being torn in about five directions for new projects.

  • “Spring for the Advanced Java Developer” Rod Johnson

    Notes from a session at TheServerSide Java Symposium March 2009

    Rod addressed some emerging best practices based around annotation-based application configuration using Spring 2.5 and later.

    The emerging best practice is to use the @Autowired annotation rather than @Resource. He demonstrated how to disambiguate bean references with @Qualifier. He also showed how to create your own custom annotations and use them to disambiguate similar types:

    @Autowired
    public void setOrderServices(@Emea OrderService emea, @Apac OrderService apac) { ... }

    @Emea
    public class EmeaOrderService implements OrderService { ... }

    @Apac
    public class ApacOrderService implements OrderService { ... }

    (What was unclear to me at the time is whether or not these custom annotations required some definition elsewhere, but I’m not entirely conversant on how annotations work.)

    He also spent some time on the @Component meta-annotation, and the concept of stereotypes.  Spring comes with several pre-configured stereotypes:

    • @Service
    • @Repository
    • @Aspect
    • @Controller

    It’s a powerful concept.

    So here’s the big question for me. Why are we configuring with annotations now? It doesn’t do away with the need for context XML files. He indeed mentioned the pros and cons for using Spring 2.5 annotations:

    Component scanning pros:

    • No need for XML (potentially)
    • Changes picked up automatically
    • Works great with annotation driven injection
    • Highly configurable (whatever that means)

    Component scanning cons:

    • Not a 100% solution (can’t do everything with annotations)
    • Requires classes to be maintained
    • Need to take care not to scan an excessive number of classes (use filtering)
    • Don’t get valuable application blueprints documented in application XML

    He makes a decent case for mixing and matching XML configuration with annotation configuration.

    The emerging best practices (he says) include:

    • Use XML for classes that you can’t or won’t annotate, such as third party components (data sources, message queues)
    • Use annotations and classpath scanning for application objects
    • Jump into XML for complex injection behavior and per-instance configuration (like injecting lists and maps)

    He suggests the Spring Web Flow example application for examples.

    He recommends moving away from the old Spring MVC inheritance model in favor of the @Controller stereotype. (Need to go back to his slides for other recommendations.)

    The rest of the presentation covered features coming up in Spring 3.0. One nice feature is the ability to embed property value injection with a @Value annotation and a new expression language. Example:

    @Value("#{systemProperties.favoriteColr}")
    private String favoriteColor;

    @Autowired
    public void init(@Value("{systemProperties.databaseName") String dbName)

    I was happy to see this presentation, because I’ve really been resistant to using annotation based configuration and component scanning. I do like the XML blueprint for an application, and I like having one place to look for how my application is configured. (I even try to avoid using multiple application context XML files, which avoids having to hunt through several files to find my bean configuration.)

    Things that happen by magic like autowiring make me a little uncomfortable. He pointed out that the Spring IDE is a good practical solution for actually browsing through your app configuration.

  • “How Spring Fits into the Java Landscape” Rod Johnson

    Notes from TheServerSide Java Symposium March 2009

    At a keynote talk, you expect sweeping generalizations and “big picture” insights.

    Rod pointed out some things that I have watched happening over the past two decades, namely the rise and fall of complex monolithic software systems as an expensive luxury that falls in favor of simplicity along with economic cycles.

    “Enterprise Java” has a reputation for complexity, based on the early (failed) J2EE platform, and giant enterprise software systems like those from IBM and BEA. “Complexity is the single biggest killer of projects,” he says. I concur.

    “Economic downturns reduce software complexity. Truly bad ideas need a booming economy to survive.” I never thought of it like that, but it should have been obvious.

    Service Oriented Architecture (SOA) is one of those complex frameworks that he claims is doomed at this point.

    So the movement now is to “lean software,” simpler modular systems that don’t try to solve every problem but focus on doing one or two things well.

    His examples, past giants of complexity: IBM, BEA, Sun. Today’s leaders: Spring, Hibernate, Ruby on Rails, Django, Grails, Eclipse ecosystem.

    In terms of business management, this means that companies move away from the large portfolio software solutions that require huge quantities of support and complexity. The movement is toward point solutions that are smaller and more targeted. This is a pendulum that directly follows the economic cycle.

    Nicely done.

  • “Leveraging Groovy for building Java applications” Hans Dockter

    Notes from a talk at TheServerSide Java Symposium March 2009

    Hans is the project lead for a build system called Gradle. He presents it as a step beyond Ant and Maven.

    I think he has a point. His system uses Groovy scripts as build scripts instead of XML. The advantages of having a full language available in build scripts is pretty clear. (Try writing a conditional clause in Ant XML. Ewww!)

    Gradle is a build toolkit and collection of small frameworks, rather than one monolithic build framework. It seems to me like this is a step back toward customization and away from “convention over configuration.” But the truth is that one build convention can not serve all build situations, and there’s probably nothing more customized in individual companies than their build, test, production, and deployment environments.

    (At MyAds we built a custom version of the Maven Release plug-in just to support our version numbering system. One size does not fit all, especially in building applications.)

    Hans says it’s easier to write and use Ant tasks in Gradle than in Maven. Gradle is using dependency management based on Apache Ivy, which I’m not familiar with. He recognizes the value of dependency management as introduced by Maven, so I have a feeling Apache Ivy won’t disappoint. I crave good dependency management, even though it can lead to Maven dependency hell at times. Ivy appears to be leveraging the Maven dependency infrastructure, as well as supporting SVN dependencies.

    So I like the concept of using a full dynamic OO language for writing build scripts, especially if the API toolkit is sufficiently intuitive that it doesn’t have a large learning curve. Gradle is worth investigating.

    Link to presentation here.

    Gradle roadmap here.

  • “Sexier Software with Java and Flex” James Ward

    Notes from TheServerSide Java Symposium March 2009

    I was interested in this talk because we use a lot of Flex in MyAds for MySpace. Ward is an Adobe guy.

    He began with some flashy demos, an interesting way to enter car accident information for an insurance form on a web site, and a desktop application called SalesBuilder.

    Flex components: Client runtimes (Adobe AIR, Flash, PDF), Frameworks (Ajax, Adobe Flex 3), Servers/Services (LiveCycle, ColdFusion, FlashMedia Server, etc.), Developer tools (Creative Suite 3, FlexBuilder).

    The core VM for Flex is the Mozilla Tamarin open source virtual machine. I didn’t know that!

    Two primary languages for writing Flex: ActionScript, and MXML. He says “It’s a real language, not just a scripting language.” Okay. 🙂 The FlexBuilder IDE compiles MXML and ActionScript, binds to the Flex Class Library, and creates a .swf file (“swif”).

    Nice, live coding of a simple app to update Flickr tags in Flex using Flickr’s RESTful API. Starts with MXML to instantiate variables and objects. (But it’s still XML. Ew. He did say you can do it all in ActionScript if you prefer.)

    Ah, the XML appears to provide a scaffolding that makes a configuration environment for ActionScript classes, which look more like a “real” language. Clearly much of the power of the language is going to be found in the class library.

    The example made for a great live demo of the whole Flex development process, end to end, complete with debugging and examining data in vitro. That makes for a powerful talk. Oh wait! He’s using Eclipse for the live coding. Interesting.

    http://flex.org/tour for an interesting “Tour de Flex” showing fun available Flex components.

    Very good performance demo of the ActionScript Message Format (AMF), a proprietary data format  optimzied for Flex. In his demo he’s showing a Tomcat server running on his local machine, and walking through the back end code that communicates with the Flex front-end.

    Spring has built integration for Java webapps with BlazeDS for web messaging with Flex front-ends.

    With two minutes left, he decided to build a Flex chat client, and showed two clients exchanging chat messages. Impressive.

    Presentation slides here.

  • “Intro to JRuby” Neal Ford

    Notes from TheServerSide Java Symposium, March 2009

    Why Ruby? He talks about the known good language features, but the biggest reason is Rails. Ruby is actually an older language than Java.

    JRuby 1.1 incorporates a just-in-time (JIT) compiler, and in many tests is faster than the Matz Reference Implementation.

    In answer to a question, JRuby would exclude some gems that incorporate native extensions, but many gems are beginning to include Java native extensions.

    JRuby can incorporate and use Java classes in four different ways, and the implementation lets you use Ruby-native syntax for accessors.

    Java Ruby
    emp.getName(); emp.name
    emp.setName(“Homer”); emp.name = “Homer”
    emp.isManager() emp.manager?

    Camel case Java names can be called with underscores, i.e. url.to_external_form vs. url.toExternalForm().

    He then gave examples of language features, including closures, open classes, shadow meta-class, modules a.k.a. mixins.

    Because of the dynamic nature, tests are not optional in Ruby projects. Being interpreted, tests need to find runtime errrors.

    You can do Swing in Ruby, but it’s a little weird. Fun to be able to reopen classes and modify behavior. There’s an open-source framework, swiby = jruby + swing.

    Very interesting use case: using JRuby to run Java tests. Making mock objects in Ruby is right in the language’s sweet spot, whereas mocks in Java require all kinds of perverted twists to make Java do what it doesn’t want to do, and create types.

    I guess Ruby is beautiful if you’re deep into meta-programming, partly because it makes it easy. It doesn’t take a lot of code to do what you want to do.

    He states that while JRuby is at least as fast as native Ruby, JRuby is profoundly slower than Java, in exchange for faster development time.

    Link to the presentation here.

  • “Just Enough Early Architecture to Guide Development” Jon Kern

    Notes from TheServerSide Java Symposium March 2009

    Jon Kern from TogetherSoft, doing this since the 80’s.

    Trick Q: How is software built? What’s the most important piece? Requirements? Customers? A problem? A: 1. People 2. Process, and 3. Tools

    Q: How do we start? Use cases? Architecture? Domain? Just start coding? Is architecture emergent? A: It can be … as long as the right amount is “emergent” soon enough, lest you end up with a lot of wasted efforts and excessive refactoring.

    Typically 10% of the project time is architectural.

    His talk has a lot of good information in the slides, that only partially coincides with his conversation. His main point is “balance” in architecture — never let one area of activity get too far ahead of others. You don’t need all requirements prior to defining architecture.

    Then he discusses several example cases. I guess mostly it seemed fairly obvious to me.

    Link to the presentation here.

  • “On the lam from the furniture police” Neal Ford

    These are random notes from Neal Ford’s keynote talk at TheServerSide Java Symposium.

    The “furniture police” he mentions are the management folks that unintentionally take productive people and squeeze them into environments such as cubicle farms that make productivity difficult. It’s also a metaphor for every distracting thing in the workplace.

    The reference comes the book Peopleware: Productive Projects and Teams by DeMarco and Lister.

    One of our major assets as programmers is our ability to stay focused and concentrate for long periods of time.

    Another book reference: Pragmatic Thinking & Learning by Andy Hunt.

    Brain functions and hemisphere roles are significant. Our right brain is a major source of insights, and is non-verbal. Hard to pass communication directly from the right brain.

    An effective technique is to “silence the chatter” from the left brain with with repetitive tasks that are not too difficult, such as mowing the lawn, playing tetris, showering.

    He NEVER gets any deep insights while watching TV. I concur.

    Insights are fleeting.

    He brought up mind maps, showed a free Eclipse plugin, and mentioned a tool called Personal Brain.

    Book references: The Humane Interface by Jef Raskin. “locus of attention” as a key to UI design.

    FLOW — The Psychology of Optimal Experience by Miahly Csikszentmihalyi — “in the zone”

    Good analogy for being interrupted when “in the flow” is being waked when sleeping. A five-minute interruption really takes 30 minutes.

    Mentioned a TweakUI power tool for Windows that will silence balloon tips that are constantly popping up.

    Screen dimmers black out the rest of the screen, leaving you focused on one area: “jedi concentrate” and “doodim”

    “Don’t shave a yak.”

    Advocates “war rooms” rather than cubicles. Best is offices with doors.

    email = efail. Instant messaging bends flow but doesn’t tend to break it. Preferred.

    Todo list for you and your company:

    For company:

    • Create brain-friendly workspaces, offices, war rooms
    • Try pair programming, at least on the hard parts
    • Create collaborative spaces
      Software development is more about communication than technology

    For you:

    • Software development is not purely left brain, engage entire brain
    • Quiet chattering left brain
      Find ways to leverage background processing (like showering or cooking)
      Create an exocortex
    • Find and preserve “flow” within your environment
    • Wrest control of our environments away from the furniture police — gently
    • build insanely great software
  • Updating an old platform, and running PHP4 and PHP5 together.

    Jane and I wanted to set up WordPress blogs with all the bells and whistles, and we had a quiet “pajama” weekend on tap.  My poor old server is running an old SuSE distribution (9.2) which hasn’t been supported with updates for several years now.

    So you know what the food chain is like for manual updates. This requires that library, this patch, etc.

    My system was way behind for Apache 2, running MySQL 4.0, and PHP 4. WordPress runs fine on PHP 4 (as best I could tell), but right away we found that we wanted plugins that required PHP 5.

    I’ve come to hate distribution RPM files, and trying to navigate the weird package layouts of config files, libraries, binaries, data, and log files. I’ll venture that the problem isn’t really RPM files inherently, but the particular choices made by SuSE in (for instance) their apache distribution are just mind-blowingly convoluted. I also struggle with rpm’s myriad options and puzzling behaviors and interactions.

    So, indulge me, I decided to build everything from source and install to /usr/local (though MySQL was very good about providing pre-built binaries in non-RPM form).

    The PHP 5 build wanted Apache libraries, and rather than install an apache-dev package, I decided to build the latest from source. Apache is a nice smooth build. Their default install in /usr/local is really easy to manage (which made SuSE’s Apache choices that much more befuddling). I kept my old httpd config file and directory structure, and eventually threw out SuSE’s /etc/init.d/apache2 script in favor of a simple one that runs apachectl.

    MySQL was a much more difficult upgrade. I started off blundering right into the latest 5.1 to see what would happen. First problem, their binary wanted the latest C++ standard libraries. No one offers that as a simple binary download! (Why bother? Everyone gets it from their distribution.) That meant building gcc.

    The gnu C compiler has a few straightforward library prerequisites that I was able to build without too much trouble, but the compiler build itself is a monster, about three hours of build time. The build worked great, and I confess that I didn’t put together the required infrastructure to run a full gcc test suite — that would have been a few more hours, I’m sure.

    But there it was — a fresh new gcc and libstdc++. To get the libraries out of your build directory, you have to find them in the tree and “make install” each component individually. Not too difficult, but it’d be a nice thing to find in the documentation. Now be sure /usr/local/lib is in your load path or LD_LIBRARY_PATH includes it.

    MySQL 5.1 came up fine, which gave me the surprise discovery that I can’t upgrade directly from 4.0 to 5.1. I had to backup and install 4.1, do its upgrade, then 5.0, do its upgrade, then 5.1. In the end, all of the data survived just fine, including all the users and permissions through several admin schema updates.

    With Apache and MySQL all current and running, that left PHP5. It built and installed as an Apache module just fine. The next discovery is that at least one of the sites I host was not capable of running PHP5.

    A search found several blog entries talking about how to make PHP4 and PHP5 co-exist peacefully — run one as an Apache module, and the other as a CGI. Individual directories can be directed to the appropriate handler.

    I had no trouble getting either PHP4 or PHP5 to run as an Apache module, but it took some study to figure out why PHP wouldn’t run as a CGI using the instructions written maybe last year.

    PHP can build a command line module two ways, as a straight command line interpreter (CLI) or as a CGI processor. Granted that the CGI module has security considerations, but still many distributions provide both versions as php and php-cgi executables. There are configure options to enable or disable both.

    What they don’t tell you in the INSTALL file is that the makefile will refuse to build the CGI version if you include the apache extension system (apxs).

    So based on this experience, I have a few recommendations:

    • Don’t be shy about building from source, and installing to /usr/local. It’s nice and clean most of the time. Be sure you have /usr/local/lib in your LD_LIBRARY_PATH environment.
    • For the two versions of PHP, use a –prefix variable of /usr/local/php4 and /usr/local/php5 to keep them separate.
    • Watch out for this “feature” of PHP’s “make install”: It will put a LoadModule line in your httpd.conf file. If you end up with both PHP4 and PHP5 modules loaded, apache will not run. (Sorry for the downtime, guys!)
    • In your .htaccess files AddHandler directive, watch out for using just “php-script” as the handler type. If your httpd.conf is as muddled as mine, it’s likely to be in use somewhere else and cause confusion. I used “php5-script” and everything worked.
    • “Premature end of script headers” is a catch-all apache error that just means something went wrong with your CGI script. It’s horribly unhelpful, and could point to any number of different problems. In my case, the really BIG problem is that I was trying to do CGI scripting with the CLI version of PHP. The CLI version doesn’t bother writing headers at all.

    Maybe soon now I’ll go through all my Apache httpd.conf includes and clean everything up, then flip over PHP4 to CGI and PHP5 to apache module.

    This project made me a lot more confident about an upcoming new server build sometime later this year. That’s definitely due. And not SuSE this time, probably Ubuntu’s server edition.

    Catch you next time …