Ricardo's Blog

Updates from RSS

  • 06:13:09 pm on March 3, 2014 | 0 | # |

    This blog is no longer updated, please subscribe here instead:



  • 08:23:49 pm on November 8, 2011 | 0 | # |

    The new 0.4.0 version of the Android Connector for M2E (m2e-android) has been released. The Android Configurator is an Maven Integration for Eclipse (m2e) plug-in that adds maven support for the Android Developer Tools (ADT) and the Maven Android Plugin. It brings the power of Maven dependency management into the ADT.

    Updates for this release include:

    • Support for ADT 15.
    • Support for the android-maven-plugin rename.
    • Minor bug fixes.

    Special thanks to Anthony Dahanne, Tijl, and all the githubbers who reported bugs and provided feedback. Any problems, please report them here.

  • 01:41:12 pm on October 22, 2011 | 0 | # |

    As part of a work spike we recently looked at cleaning up some technical debt within our application performance monitoring. Through previous iterations our existing monitoring is all over the place, with metrics captured at multiple points including Spring handler interceptors, exception resolvers and annotation-aspects.

    While our team differed on the exact approach, we all agreed the current situation was unacceptable and we needed to unify our approach. At my company we have many internal APIs, including one for monitoring. However, in our experience many of them suffer from Not Invented Here syndrome: symptoms including idiosyncratic coding standards.

    But the biggest problem is that internal APIs are often stale, with unfixed bugs, no obvious means to push upstream changes, and often using outdated dependencies (such as Spring 2.5.x). We simply lack the resources to keep them up-to-date.

    With this in mind, we decided it would be better to use an open source monitoring library. The main benefit being that public, open source libraries tend to attract more developers and are, so the theory went, better supported. So I took the responsibility to review the current Java, open-source monitoring libraries. To keep the spike time-limited, we specified a check-list of possible features we’d like to see:

    1. Counts or hits
    2. Timings (including average timings)
    3. Standard deviations
    4. Distinguish timings and counts between success and failure
    5. Spring support
    6. JMX support
    7. SPI for customising monitoring if some of the above aren’t fulfilled

    So here are our findings:


    Jamon is probably the most established monitoring framework, so it was one of the first ones we looked at. While it certainly covers all the metrics we wanted (and then some) there was no JMX support and limited Spring support. With poor documentation and no obvious means to customise its functionality, we decided not to go with it.


    Another contender is perf4j, which takes an interesting approach to monitoring by extending logging frameworks. It has support for many familiar logging APIs, including log4j, slf4j, commons-logging and java.util.logging. This makes a lot sense and with helpful documentation and out-of-the box Spring/JMX support this seemed like a good candidate.

    However, while it covered most of our timing metrics (as you would expect) it didn’t seem to support counts/hits at all. What is more, you have to extend the framework via various logging framework SPIs which seemed like a lot of work.

    Java Simon

    The new kid on the block, Java Simon, seemed like the likeliest candidate: it comes with Spring and JMX support, handles all the required metrics and has a clean, simple API that is easy to extend. There also appear to be some performance gains over Jamon, although these are probably marginal at best.


    Even though we settled no Java Simon, none of the above really met our exact requirements. But Java Simons long-term support (version 3.0 was released this month) and easy to extend SPI made it the likeliest candidate for us.

  • 09:36:42 am on August 13, 2011 | 0 | # |
    Tags: , , , ,

    The new 0.3.0 beta version of the Android Configurator for M2E (m2e-android) has been released. To install please see the new Getting Started guide:


    Note: Please uninstall the old 0.2.x alpha version of the m2eeclipse-android-integration plugin when you update.

    This new version improves build performance thanks to new incremental builder. Your Android builds will be faster as they no longer run a Maven shell and only rebuilds when relevant files have been modified. Slow builds was the number one complaint about the old alpha line.

    I’d like to thank Anthony Dannane for getting the Tycho command line working so that we could run the m2e-android build through continuous integration. Also thanks to Felix Dahlke and Jeremiah Johnson for their contributions, and Igor Fedorenko for his valuable advice on the m2e-dev mailing list.

    Please report any bugs to the issue tracker.

  • 09:22:40 am on August 13, 2011 | 0 | # |

    This web-site has moved to my new company domain at:


    Please update your subscriptions accordingly.

  • 12:37:22 pm on April 16, 2011 | 0 | # |

    So you’re building your typical database-driven web application. You turn to your story board and see that your business analyst has raised a story to allow your testers to stub some of the services you call. It’s a reasonable request so off you go, writing your stub code.

    But how will your tester modify your stub settings? They need some interface to hook into the application and pass in stub test data so they can perform their testing. You figure ‘I’ve already got a web interface set-up, I’ll leverage that and create a secure web console for my application’.

    Right? Well, I think you might be wrong and you should use JMX instead. Here are three reasons why:

    1. Security: Most web application frameworks start with the assumption that your web resources are publicly available and you have to put security in after the fact. By default JMX usually has to be explicitly switched on. What is more, JMX is served off non-standard ports that won’t be open on your firewall unless you explicitly request it.
    2. Less code: JMX managed beans are lightweight and don’t have the overhead of controllers or front-ends.
    3. Separate security model: Inevitably, the security requirements for your web application will be different to those for your console, so using JMX makes sense because it has a completely separate security model.

    In reality, the main problems stem from mixing user-facing front-ends with internal web console interfaces. For example, you might sensibly block all access to your test console on production. However, you may find yourself forced to work around production configuration copied on your staging configuration.

    Of course, there are disadvantages to JMX over web consoles. For example, JMX requires specialist software to be installed and users need to be trained with this software, whereas a web console can be operated with a common web browser. What is more, most test frameworks like Selenium are designed to work with web interfaces automatically.

  • 01:29:43 pm on February 12, 2011 | 2 | # |

    Released new beta version 0.2.5 of Maven Integration for Android Development Tool. Maven Integration for Android Development Tools is an Eclipse plug-in that adds support for M2Eclipse/Maven integration with the Android Developer Tools (ADT) and the Maven Android Plugin.

    This update is a bug-fixing release for issue 40 which was forcing a full build for incremental changes for non-Android projects. User’s should see performance improvements for their non-Android projects.

    See Releases for a full list of changes in this release. See GettingStarted for how to install and start using Maven Integration for Android Development Tools or install from the update site. Alternatively Maven Integration for Android Development is available via the Eclipse Marketplace.

    This is also the first update release of Maven Integration for Android Development Tools so please raise a ticket for any install/update issues.

Next Page »