Saturday, September 4, 2010
Blu-Ray Region Free sites
Thursday, September 2, 2010
Thursday, July 8, 2010
The file is in use by another program or user
Monday, June 28, 2010
Simple Http Monitor
Thursday, June 10, 2010
Java Visualisation Tools
- APIViz
- Dependency Finder
- ... as well Vizmier once it gets going :-)
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:
Wednesday, April 21, 2010
XPath name-space sample
Monday, April 19, 2010
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
- Get http://alexgorbatchev.com/wiki/SyntaxHighlighter
- Install the .js and .css files into some external location (eg: a Google Sites "file cabinet")
- Add references to the files into the Blogger "Layout"
- ... 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.
Sunday, April 18, 2010
Mule Testing
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
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
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.