NHibernate is now my framework of choice for working with a relational database. With a little bit of knowledge and a willingness to research, it’s pretty straightforward to make NH jump through whichever hoops you need it to. That said, there are certainly a number of friction points which can slow down any development effort. Mostly, these can be solved with a couple of tricks and tools which can be applied at various stages of a project.

Fluent NHibernate is a method of cutting down on XML mappings which are commonly associated with NH. While in the past, tools such as ActiveWriter have enabled developers to bypass the most laborious parts of creating mappings, Fluent NH takes it a step further and provides a strongly typed means of setting up your entity mappings without even touching XML. You can either use the auto mapping facility or fully customise the mappings, but it’s all done with full intellisense support and a serious lack of angle brackets.

Once the mappings have been defined – either in XML or in code – you need to start working with the database itself. NHibernate has a built-in facility which can help you out here, by generating the database schema based on your entity mappings. In fact, in the latest releases, you can even update the existing schema without having to delete and recreate, which makes it possible to preserve your test data during development. This allows you to go end-to-end from the mappings direct to the database and keep in that context throughout the development process.

Here’s a quick aside: some of the criticisms put against ORMs are that a developer with great SQL knowledge can tweak and craft code better than any autogenerating tool. From my point of view, every query would have to be written to a high standard, all column choices would have to be perfect every time. NHibernate’s generated code has been reviewed by experts and it will be produced in the same way time after time, to the same level of quality.

With that in mind, I don’t really have a problem letting NH control every part of my database interactions. What I do need is a way of ensuring that if the mappings i’ve created are wrong, or are sub-optimal, that I have a method of finding out what’s going on. NH Profiler is a piece of software which has recently started a beta phase and hooks in to NH itself to provide real-time analysis of what queries and sessions are being used by your application. As well as reporting, it also provides suggestions if it detects sub-optimal behaviour. Lazy loading, for example, can cause some nasty performance problems if used incorrectly, so NH Prof can pick up situations in which it would be better to change mappings to specify eager loading.

Over the last six months, new features and community involvement have transformed NH from a great development framework to the premier ORM for rapid development teams. The bumps have been smoothed, and we can get on with leveraging the wonderful work of the NH team.

I’m sure there are a load of posts professing their love for Delicious Library. It’s pretty sweet. I downloaded it just after Christmas for no reason other than I thought it was really cool, but since then I’ve started to realise that some features could be real-world useful. Making an inventory of your possessions could be useful for insurance purposes, which is a most sensible use of this great program. I can also use it to track items that I’ve lent to people, because it integrates with Address Book on OSX.

I borrowed a bluetooth barcode scanner from my friends at Internetware and used that to zap over 500 items – books, DVDs, CDs – and Delicious Library ate them all up. It can be configured to read out the title of the item you’ve scanned so you can confirm it’s been inserted correctly, which was great for us as we bleeped our way through our bookcases in another room. The novelty of it didn’t really wear off either, in fact I found myself looking for more stuff to scan even when I’d finished the bulk of the items.

I’ve now got an attractive, searchable database of many of my possessions, and the Delicious Library publish feature means I can expose it to the web. My library currently holds 442 items and certainly gives a good look at my interests – most of my books are science fiction, for example.

When adding new items, Delicious Library offers the ability to use a webcam (such as my iMac’s built in iSight) as a barcode scanner. This feature’s been pretty disappointing and it requires quite a few attempts to get it to work, but adding items manually is pretty straightforward. New items can be automatically filtered using the smart shelf feature, which currently pulls all sci-fi and fantasy stuff into a separate area. In short, Delicious Library is much recommended!

After a while working on it, I converted the scratchpad for the routing documentation into a proper patch for Castle’s website. Gauthier Segay also contributed some sections, and I hope we can now provide some fixed, formal information on Monorail’s current routing system. Thank you to Markus Zywitza for applying the patch.

If you see something that looks incorrect, or something that’s missing, then you can help fill in the gaps by patching or just writing it up and someone else will try and create a patch for you.

The next missing docs I plan to address are the fluent registration API for Microkernel, but there are a lot of features I’m not 100% on. Alwin has been doing some great work here so that patch will probably be coming pretty soon. In the meantime, any contributions would be gratefully received!

“Have you done any Windows Mobile development?”
“A tiny bit. Isn’t it just like Winforms but on a phone?”

And from such an innocent beginning, a world of pain did explode into my universe. Just like Winforms on a phone is it? What’s the difference between the Compact Framework, Smartphone development, Pocket PC development, Windows Mobile? So many terms! So little time!

Windows Mobile is the operating system, just like Windows Vista. The Compact Framework is just like the .NET Framework on the desktop. As for the difference between a Smartphone and a Pocket PC, well, you’ve got me there. I picked Smartphone because my device had phone functionality and it seems to be working so far. There are separate SDKs for each, so I assume there are some key differences which escape me. With Windows Mobile 6, the Smartphone and Pocket PC SDKs are now Windows Mobile 6 Standard and Windows Mobile 6 Professional, respectively. I think.

Actually I think the real difference in these is the templates for projects you create and the emulators you are provided with. Professional, or Pocket PC, provides emulators for bigger screens. Microsoft has this to say about the naming kerfuffle:

With Windows Mobile 6, we are revising our SKU taxonomy and naming to better align our brand and products with the realities of today’s mobile device marketplace. The historical form-factor based distinction between Windows Mobile powered Smartphone and Windows Mobile powered Pocket PC Phone Edition is blurring dramatically. We want our taxonomies and terminology to evolve to better reflect the evolution of the mobile device industry.

So in order to reflect the blurring of the mobile device form factors, they’ve changed from having SDKs named after the types of device to SDKs named “Standard” and “Professional”. Hmm. How about having a single SDK called “Mobile Device SDK” and allow me to pick the device dimensions from within my project on the fly? Back at the start of this tale, I assumed that picking Windows Mobile for development would allow us to target a range of different devices, large and small, and in fact I can do that. I can deploy my application to a Windows Mobile phone with a big screen and to one with a small screen. The SDK split seems pretty artificial with that in mind.

Naming conventions and confusions aside, it is nice to be able to write against a single API and deploy to any Windows Mobile device. Or it would be if it worked.

My bugbear here is with a particular class: CameraCaptureDialog. Take the Samsung Omnia for example. You can certainly pop up the camera using CCD.ShowDialog(), but can you retrieve the filename of the image you took? You cannot. That’s because the Omnia’s camera supports taking multiple images one after the other until you explicitly close it.

How about the HTC Diamond? Well that opens fine, and returns a filename too, but if you try and re-open the camera straight after processing the filename, to allow the user to take another photo, it fails silently and doesn’t show the camera. If you try and do the same thing with the HTC Touch, it freezes.

Part of the issue is that the Compact Framework leaves too much up to the manufacturers and doesn’t give enough control to the developer. We can set the resolution of the camera for example, but we have no shortcut of setting it to the maximum resolution available. If you try and set it to a resolution which is not supported, some devices reset silently to a much lower resolution.

Microsoft need to extend camera support for .NET developers and give a lower level of access. They need to push device manufacturers to adhere to the Windows Mobile APIs and be more precise in how they are specified. And they need to simplify and modernise their mobile development framework so that developers can be fully aware of all the options available to them.

As previously promised, the TickerTape is now on Google Code. It wasn’t under any kind of source control before, so this is a handy step if I want to move development forward. I do plan on doing so in the near-to-medium-term, but if you are using the TickerTape and would like to contribute any improvements, the move to Google Code means that I’ll be happy to accept good patches. If you’re not sure how to patch something but have found a problem, feel free to register it in the Issues section.

I’ll be filling out the Google Code project page with some documentation soon. I’ll also be repointing the TickerTape file references on older posts to the new downloads, so I apologise if you see some republished posts in your feed reader.

I reserve the right to be excited by this one; in fact pretty much everyone’s gone “oooooh” when they’ve seen it. Last week I received the author copies of Learning Ext JS from Neel at Packt, and the book looks great. I’m going to talk a little bit about the way I approached the writing, and how I feel about it all after the fact.

Each chapter which I wrote was supposed to be around 25 pages, consisting of 6000 words. When I write a blog post, a good one is around 1000 words, so that was my comparison. I’ve not done any real writing since high school, so while I’ve continued to put out a lot of words, they’ve never been particularly well thought out, scheduled, or planned in any way. So six thousand words a chapter did cause a bit of a problem when I tried to churn out a few pages every night.

One of my techniques was similar to one of my main development ideas – don’t get bogged down in thinking how something should be done in the perfect way; just get started and refactor later. In this case, change refactor for edit, but you get the idea. I suspect this is writers block, and it was definitely a problem for me. Pushing on and getting something down turned out to be much more productive than mulling over “better” ideas. Another problem wasn’t necessarily thinking what to write, but making each chapter stretch out to the required number of words. Quite often I’d have a good couple of evenings when the writing was going well only to find that I’d underestimated how far an idea would stretch. In these cases I’d try and go in to detail on working with the subject matter or I’d think up another example to try and illustrate my points in a different or more advanced way.

Even when the initial drafts were completed, there was still a matter of sending them off for review. Editing sounds like it’s going to be the easy bit, but when you’ve been working on something for a few months you’re most likely sick of the sight of it, so revisiting it isn’t going to be high on your agenda. Still, it was an education reading over comments about my own writing, bringing me down to earth or giving me a buzz depending on how each chapter and paragraph was received. How often do you really get an outside, independent person to review your work?

Even when the edits were complete, there was still more: promotional material to be written, screenshots and code samples to be made available, blog posts to be written. After all that, and a few extra weeks, the physical copies arrived in the post and pretty much made the whole harrowing process worthwhile. Writing a book was always one of those things I’d quite fancied doing and never imagined I would, so being able to contribute to Learning Ext JS ticks a pretty cool box for me.

My TickerTape project has turned out to be one of my most popular, turning up in some unexpected places. I do get comments on it now and then, and a few people have mentioned some issues with it which I would like to fix – in particular CPU and memory usage on some browsers. My current plan is to put all material on the TickerTape on Google Code so that I can track issues, document usage, and accept patches. I will try and do this sometime this month.

Update: The TickerTape is now available on Google Code.

A few months ago I was approached by Packt Publishing to help out with one of their up and coming publications. After reading some of my blog posts and seeing some screencasts I’d done on Ext JS, they felt I’d be a good candidate to co-author a book on the subject. I quizzed them quite a bit before committing; the offer was so out of the blue that I felt I needed as much information as possible, but it’s flattering to be offered such an opportunity anyway. When I felt I could make an informed choice, I accepted, and became part of the Learning Ext JS team.

The other authors are Shea Frederick and Steve “Cutter” Blades. Shea did the first block of chapters:

1. Getting Started
   Setup Ext JS to be used on your page and troubleshoot common installation problems.
2. The Staples of Ext
   Explore some of the foundational components and configuration of Ext JS.
3. Forms
   Create complex forms, database-driven combo boxes, and populate form fields with data.
4. Buttons, Menus, and Toolbars
   Use toolbars to create compact complex navigation for your web application.
5. Gridsâ??Making Data Intuitive
   Render database-driven grids that include paging, complex rendering, and user interaction.
6. Editor Grid
   Go past the standard grid, and set up an editor grid that edits data in line.
7. In an AJAX World, You Need a Good Layout
   Create a layout that provides a very flexible and attractive user interface.

I did the middle lot:

8. Ext JS Does Grow on Trees
   Demonstrating how to display and manipulate hierarchical data.
9. Windows and Dialogs
   Focusing on displaying information in pop-up containers.
10. Effects
    Add spice to your applications with compelling visual effects.
11. Drag and Drop
    Learn how to move and rearrange elements within your application.

Steve rounded it all off with the final chapters:

12. Itâ??s All About the Data
    An introduction into the various types of data Stores, the kinds of data they can consume, how that data is defined, and how to get it.
13. Code for Reuse: Extending Ext JS
    An introduction to creating custom application components by extending existing components of the framework.
14. The Power of Ext JS: What Else Can You Do?
    A look at many of the utility classes of the library, including formatting and state management, as well as Community Components and resources.

It was certainly a learning experience. I thought I knew Ext JS pretty well before this, but having to fill 20 pages of text about a single part of the framework lead me to discover a lot of new things, not least how to fill out text to make it interesting, rather than a lecture. I’d like to thank the Packt team, my co-authors, and of course the Ext JS team for the opportunity – one I never dreamed I’d have.

Learning Ext JS is available for pre-order on the Packt Publishing web site, as well as some mainstream retail sites such as Amazon. If you do decide to purchase – and I strongly urge you to! – then please let us know what you think by leaving a review on the Learning Ext JS Amazon page.

At Plastiscenic, I organise all the boring stuff using Freshbooks. In fact, Freshbooks make sorting invoices, estimates and time tracking a bit of a breeze. I was mulling over the past month of work when it struck me that I was thinking about things in completely the wrong way: I was trying to ensure that I was busy all the time, when in fact all that matters – from a business perspective – was that I was earning enough.

Freshbooks has a record of all of the Plastiscenic invoices, and therefore the amount we’ve brought in during a given month. It also has an API. I decided to quickly flex my PHP muscles and come up with a cash-orientated way of viewing my performance via my invoice data.

I created a web invoice widget for Freshbooks which uses the Sparkline PHP Graphing Library to generate a graph of the past 12 months. Ones in which invoice totals exceed the specified upper threshold are marked in green, and ones which are lower than the lower threshold are red. Everything else is black. To the side of the graph, there’s a numerical readout of the invoice totals from this month and the previous month, again coloured accordingly.

In terms of the actual scripts involved, you need to edit FbInvoicePerformance.php and enter your Freshbooks API token and API URL which can be obtained in your Freshbooks account. Then just tweak index.php from the archive according to your needs. The good and bad variables are the high and low thresholds for colouration, and the HTML in that file it just boilerplate for demonstration purposes and can be hacked as you like. Notice the readout function for displaying the numerical invoice totals. The FbInvoicePerformance class powers the whole thing but it’s pretty small and usage should be clear from the index.php file.

This Freshbooks invoice widget is completely unsupported by me. Sparkline requires PHP 4.0.6 or newer (including PHP 5) and GD 2.0 built as a PHP module, so bear that in mind if you try and use the widget. There’s no demo, but you can download the widget here.

Recently I’ve set up a network attached storage computer on my home network. As well as providing RAID storage for all the devices in the house, it acts as a central download server for everyone to use. Key to this strategy is SABnzbd, a Python application which downloads binaries from newsgroups, and which sits on the server as a daemon, grabbing files on a schedule or when we ask it to. The functionality of this software is incredible, but more than that, there is a great deal of documentation for each feature directly linked from the web interface. This enabled me to set up advanced features such as RSS feeds, categorisation, and post-download scripts, in order to shift SABnzbd from being handy to indispensible.

This post is not about SABnzbd though – it’s about documentation. My latest project has been a very quick CMS solution using Monorail, and I’ve been taking advantage of the new features available in Castle’s trunk. The new routing in Monorail, the fluent API for component registration in Microkernel, and more new features, have all been making my life easier… once I’ve figured them out. I’m in awe of the people who have produced these features and I’m not adverse to digging round test cases where I can, in order to find out how to use them.

However, it would unarguably be better if the Castle documentation reflected these new changes. It’s understandable that the documention lags behind these features, and since I don’t have the intimate Castle knowledge needed to contribute to fixing bugs or adding new code, I figured it’d be good to try and work on this documentation. Castle uses an XML based documentation format which is just fine for final docs, but not that great for scrabbling down notes and filling out information. For that, I’ve decided to use the using.castleproject.org wiki, a site designed to hold tips and tricks for the Castle Project.

I’ve set up a simple system of tagging which allows people to search out stuff in need of documentation and then tag it when it’s complete. At that point, I plan on converting it into a patch for the official Castle documentation. In this way we can get the rapid prototyping of a wiki combined with an easy route to formal documentation. I think barrier for entry is a definite problem for contributing on many projects, and documentation can be a good place to start. For Castle, I’m trying to make even the barrier for entry for even that documentation very low. So if you can help out with the routing documentation or the validation documentation or anything else that’s missing or incomplete in the main Castle docs, please pitch in and try and help!

(Also published on my LosTechies blog)