Monday, May 18, 2009

JMX is my favorite rapper!

JMX rules! Some of his best songs: Where the Enterprise at, Xml Gon Give it to 'Ya, Ruff Ryders MBean Anthem, Can't Stop Being Greedy.

The biggie commerce (big e-commerce) project I've been working on is now dev complete and we are working on some production readiness tasks. My job today was instrumenting the most important pages of the application with JMX so we can get statistics on requests/sec, responses/sec, and successes and failures on a per page basis. Word.

I'm new to JMX and it took me some time to get it working in Jetty and Tomcat with Spring. Here are a few of the snags I ran into and what I was doing wrong.

  1. Getting Jetty's MBean server to start when we are using the builtin jetty Ant task. There isn't lots of documentation out there about getting Jetty and JMX working when you are starting Jetty via the builtin Ant task. Here is what I did. I added the jettyXml attribute to the jetty tag like this:
    <jetty ... jettyXml="web/target/main/webapp/WEB-INF/jetty.xml"> ... </jetty>
    My jetty.xml file contains the following:
    <Configure id="Server" class="org.mortbay.jetty.Server">

    <Call id="MBeanServer"
    class="java.lang.management.ManagementFactory"
    name="getPlatformMBeanServer"/>

    <Get id="Container" name="container">
    <Call name="addEventListener">
    <Arg>
    <New class="org.mortbay.management.MBeanContainer">
    <Arg>
    <Ref id="MBeanServer"/>
    </Arg>
    <Call name="start"/>
    </New>
    </Arg>
    </Call>
    </Get>

    </Configure>

    The jetty.xml tells Jetty to start an MBean Server and adding the jettyXml attribute will let Jetty know where to find the jetty.xml file. It seems obvious, but I had to really scour the web to figure that one out. The tricky 'ah-ha' bit is the fact that you can define your jmx stuff in jetty.xml rather than in jetty-jmx.xml, because of course the jetty ant task doesn't have an attribute for jetty-jmx

  2. Spring was silently ignoring my JMX annotations, thus none of my MBeans were being exposed. This took me hours to figure out. Here is the explanation I found buried in the spring JMX docs.
    Do not use interface-based AOP proxies in combination with autodetection of JMX annotations in your bean classes. Interface-based proxies 'hide' the target class, which also hides the JMX managed resource annotations. Hence, use target-class proxies in that case: through setting the 'proxy-target-class' flag on , , etc. Otherwise, your JMX beans might be silently ignored at startup...
    The nub of it is I don't get to use spring's fancy 'ManagedResource' annotations to define and name my MBeans. Instead I have to describe each one in XML. Not a huge deal, but unfortunate. Stupid AOP stuff!
  3. Jconsole, which is the default tool Java gives you for connecting to JMX enabled systems, doesn't work in Ubuntu. Man oh man. If I could have the time back that I wasted before I realized that. You just get a blank window when you connect to your server with Jconsole in Ubuntu. I think the compiz desktop effects are probably the culprit here. Lame.
I spent most of the day dealing with my configuration woes, so I didn't get to work on the interesting part yet which is instrumenting the controllers. I'll post about that if it turns out to be interesting. This post is mostly a "what not to do" post. Hope it helps someone.

Monday, May 11, 2009

Building your resume


And when I say "building your resume" I literally mean creating a build system for a resume with config files, LaTeX and Rake. Why in the name of Knuth would I do such a thing?
  1. Because it is AWESOME!?!
  2. Version control! So how old will I be when my resume reaches 1.0?
  3. Hosting on GitHub means my resume has an RSS feed!
  4. LaTeX's Inline comments make for fun Easter eggs and color commentary.
  5. A really keen potential employer could 'watch' my resume via GitHub. Heck they could even fork my resume and add things they would like to see me learn.
  6. I could add a Rake task to publish my resume somewhere or to email it directly or even to tweet me whenever someone builds my resume.
  7. Rake task for spellcheck.
  8. I could have build parameters for adding or hiding certain sections of my resume... for example swapping out the objective at compile time.
  9. They say "blogs are the new resumes" but I say, "GitHub is the new resume!"

Sunday, May 3, 2009

Evolution of a Programmer


In a recent discussion about the Intentional language workbench on the Software Craftsmanship mailing list Dave Hoover made the following comment:
If programmers from 30 years ago looked at my typical day today, I bet they would think I was more of an analyst than a programmer. The high level code that I get to work with typically keeps me very close to the domain language of my customer... the problems I'm generally solving aren't related to computer science and optimizing milliseconds, they're translating my customer's desires into executable software.
I thought this was interesting and I agree with Dave. To some extent I wish this was even more true than it already is. Writing software and solving problems 'close to the metal' can be interesting and rewarding, but being able to bring my ideas and my customer's ideas to life quickly and elegantly is really what it is all about for me.

Saturday, May 2, 2009

Filtering What Goes Into Your Shell History


I wrote a post here that has a few techniques for filtering what goes into the shell history. It is unwise to store sensitive or dangerous commands in your history. An example of a sensitive command would be one with an inline password. Executing such a command would store your password in cleartext in your history file. An example of a dangerous command is 'rm -rf' If you were to accidentially execute this by using ctrl-r or ! or !? then you could potentially lose important data or destroy your system. Bash offers configurations that let you ignore commands, including the ability to ignore any command that is prepended with a space. It is handy, especially for anyone who makes good use of their shell's history features. Btw, I know a couple folks out there who use zsh. For you guys, know that zsh offers a subset of the bash functionality (HIST_IGNORE_SPACE) so you should check it out.