Saturday, September 4, 2010

Thursday, September 2, 2010

Radio Station Frequencies

Concert FM is at 92.6
Ryan's station is 106.7

Thursday, July 8, 2010

The file is in use by another program or user

... and this simple utility will tell you WHAT program is locking it
http://ccollomb.free.fr/unlocker/
(It was Excel, for mysterious reasons)

Monday, June 28, 2010

Simple Http Monitor

The easy option is Fiddler (http://www.fiddler2.com/)
Similar is parosproxy (http://www.parosproxy.org/) but it requires a little configuration.

Thursday, June 10, 2010

Java Visualisation Tools

I'd like to investigate these Java Dependency / Visualisation tools...

Sunday, May 9, 2010

Disk Recovery

My daughter's XP machine started losing its mind over the weekend (running very slowly and behaving randomly), and as part of my attempt to fix things I managed to lose the NTFS partition on her hard disk.

Then I found TestDisk , which did a great job of copying "lost" directories off the hard-disk, as well as recovering the partition.

Highly recommended.

PS: Boo-hiss at GParted that messed up that partition table in the first place :-)

Thursday, May 6, 2010

Bean Mapping

While playing with GWT and GAE I discovered the need for Bean mapping, so that beans built via the DataNucleus JDO implementation can get serialised across to GWT without throwing a com.google.gwt.user.client.rpc.SerializationException associated with org.datanucleus.store.appengine.query.StreamingQueryResult.

Normally I like DTO layers anyway, because I want to control the aspects of the Domain that make it through to the client. I've built crappy reflection-based mappers of my own, but have since discovered some nice ones:

This is a simpler implementation, which is allegedly faster than Gilead.


This has nice integration with GWT, Hibernate and other frameworks, which should speed development, but will discourage use of DTOs that differ from the domain objects.
Dozer feels like more my style right now :-)

Wednesday, April 21, 2010

XPath name-space sample

Because I always forget how to pull name-spaced elements via XPath, here's a sample: Here are some XPath expressions that could be used to extract "v:authcode": Also, here are some handy XPath links:

Monday, April 19, 2010

Eclipse key bindings

I cobbled a quick reference guide for myself: Eclipse Key Bindings

Also, "Mousefeed" is a nice helper plugin that tells you key-stroke alternatives whenever you use the mouse.

Nesting JUnit TestCases

I recently decided to see if I could test some Mule configuration using Concordion. I had my Mule unit test, which extends org.mule.tck.FunctionalTestCase, and my Concordion unit test which extends org.concordion.integration.junit3.ConcordionTestCase. Given that my test class can't extend both of them I had to introduce a little delegation.

Here's the somewhat clunky solution I threw together. It works, and I didn't have to change either the Mule or Concordion code base, but there must be a nicer way.

Embedding code samples in Blogger

Getting code samples into Blogger took WAY more effort than I expected it to -- especially as I wanted to avoid HTML-encoding the samples. What I did to achieve this lofty goal was as follows:
  • ... and call the script to perform the magic
<script type='text/javascript'>
     SyntaxHighlighter.all()
</script>
  • Ensure that code sample is embedded within a CDATA section, similar to the following example
<script type="syntaxhighlighter" class="brush: js"><![CDATA[

    function foo()
    {
        if (counter <= 10)
            return;
        // it works!
    }
]]></script>

  • ... and crucially (this was the part that took a while for me to discover), turn off "Convert Line Breaks" on the Blogger "Settings | Formatting" page.
PS: "Postable" is a simpler, but less pretty, option here too.

Sunday, April 18, 2010

Mule Testing

Mule is an open-source ESB, although there is a clear push to use their "Enterprise" commercial version instead. The documentation is ok, and there's a pretty good book "Mule in Action".

Basic configuration of Mule is simple enough, and configuring a system to pull a text message from a JMS queue, perform some logic against the text, and push the message out to an SMTP server, isn't difficult, but the problem I wanted to solve was HOW DO I TEST IT?

I don't want to have to fire up a full-blown JMS service and an SMTP server just to confirm that nobody has broken the Mule configuration prior to deployment. I also need to be sure that the correct email was sent, and I don't want to point my web-browser at GMail in order to check!

The "mule" way to do this testing is to replace these services with lightweight "in-memory" versions, run tests, and then examine behaviour as recorded by the lightweight services.

Instead of Weblogic for JMS, use an in-memory version of Apache-MQ. Instead of a real SMTP server, use "GreenMail"

Split the configuration into pieces.
  • A core file that contains the services
  • A file that contains Mule XML configuration appropriate for unit tests
  • A file that contains Mule XML configuration appropriate for production
  • A file that contains configuration properties appropriate for unit tests
  • A file that contains configuration properties appropriate for production
eg:

A core file that contains the services

A file that contains Mule XML configuration appropriate for unit tests

Note that the jms definition fires up Apache Active-MQ inside a virtual machine (vm://localhost), but that the smtp definition is very generic.

A file that contains Mule XML configuration appropriate for production

Note that we are using a Weblogic JMS queue definition here, rather than the Apache MQ definition used in our test file.

A file that contains configuration properties appropriate for unit tests

A file that contains configuration properties appropriate for production

The unit test

Now we take a quick look at the unit test, which just fires up an in-memory SMTP server running on port 3025, pushes a message into the in-memory JMS queue, and checks that the expected email is sent using the "Greenmail" apis: I actually attempted to write generic stub "connector" classes that my tests could interrogate, but Mule's endpoint classes make assumptions about the connector classes they are connected to (ie: they cast the "connector" that Mule passes them into, for example, org.mule.api.transport.JmsConnector), which meant they blew up when passed my stub connector.

Concordion

Concordion is a simple testing framework to allow for "executable specification", similar to Fit[nesse].
html files with minimal markup are bound to code via a simple adapter class, and run via a JUnit testcase base class.

First write some simple HTML to describe the requirement, eg:

Then apply some trivial markup to identify the 'interesting' bits: We then create a Java class that extends ConcordionTestCase to act as an adapter for the HTML. In this example the class would have method called 'topup' which accepts three parameters (phoneBalance, bankBalance, and topup), and returns a structure containing 'phoneBalance' and 'bankBalance'. eg: When the unit test is executed Concordion generates HTML showing the result of the call, with something pretty, like:
When user Bob has $5 phone credit, and $10 in their bank account, a $8 topup will result in $13 credit on their phone, and $2 in their bank account. Txt message result will be 'Topup successful'

I also took a look at JBehave, which seemed to require much more scaffolding code, for no obvious benefit. It also wasn't as pretty as Concordion :-)

Robot Framework and TextTest look like they might be useful for traditional testing staff.

PS: Mark's idea is worth thinking about.