After I wrote Fizzler in a burst of development enthusiasm a few months back, it’s been sat on Google Code – a solution in need of a problem to solve. That is until Colin Eberhardt emailed me to report a bug in the selector engine, and to talk a bit about the way he was using Fizzler when working with WPF. This was totally outside the domain I’d anticipated Fizzler being use in, and Colin E has now revealed his project in full. By wrapping part of Fizzler in a few interfaces, thus abstracting it away from HTML and towards a more general purpose solution, he was able to use it to query a XAML UI definition and apply style declarations. CSS selectors for WPF!

This is an amazing use case for a library which I hope will start to see more use in the future. Thanks to Colin E for letting me know about the work which Scottlogic are doing with Fizzler.

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.

Over the past few weeks I’ve been throwing this together in my full time – a class library to pull HTML nodes from a page using a CSS selector. hpricot for Ruby would be a good comparison. It uses the HTML Agility Pack behind the scenes, to clean up the source document, and provide means of reading the document nodes.

I’ve got a limited suite of unit tests which document the current level of support, most CSS 2.1 stuff is in there, and a couple of CSS 3 ones. The unit tests are partially pinched from jQuery’s selector engine unit tests, so thank you to the jQuery team.

It works like this:

SelectorEngine engine = new SelectorEngine(htmlString);
IList nodes = engine.Parse("#p>a");

Pretty simple stuff. There are no binaries yet, as I consider it alpha-quality, but you can check it out over at Google Code. Contributions would be appreciated.

Last week I sat down to create a proof of concept for a Visual Studio-style intellisense implementation written purely in Javascript. I’m quite pleased with the results, although it’s not very robust. Let’s cut to the chase – have a look at the pure javascript intellisense demo, or download an archive.

Now, let me explain what’s happening there before you get too underwhelmed. Basically, when you type, the script runs a tokenizer to split your previous text into chunks. When that tokenizer hits upon a delimiter, in the demo that’s the “.” character, it’ll send your previous token to the server and popup the result in the intellisense box. You can tab to the box and hit enter to select an option. Pressing tab also cycles through the options in the box.

What I’ve written is very simple. The tokenizer can be totally swapped out, so you could define your own rules for parsing your input and obtaining a token. And when the token gets to the server, you can interpret it in any way, returning anything back to be put in the intellisense box.

Like I say, this is proof of concept stuff only but I can definitely see applications for it. It’s been tested in FF3 and IE8 Beta – nothing else. I’ve got an SVN repo online and would happily accept patches or comments. Download Javascript Intellisense here.

For a few months the term “ALT.NET” has been gaining traction on the blogs I read, starting from a post by David Laribee in April. From there it has taken off, with an ALT.NET Conference taking place this week. So it’s perhaps timely that Sam Gentile has written a post entitled “Goodbye CodeBetter and ALT.NET” which talks about the ALT.NET movement and some of the people surrounding it.

ALT.NET is Divisive

ALT.NET is a divisive thing. No matter what they tell you.

So says Sam, and I’m in agreement. The ALT.NET conference is so cliquey that it hurts, and that’s really highlighted by an interesting bit of news that came out yesterday regarding Microsoft’s upcoming MVC framework. I think it’s interesting that they’d talk about it at a conference where most of the people will already be using this sort of technology. Just as I find it pointless that you’d go to a conference to discuss the stuff that everyone there already knows. DDD, BDD, MVC – these aren’t things that will be unknown to people attending the ALT.NET conference.

ALT.NETter A: so… heard of that new BDD business?
ALT.NETter B: Yep.
ALT.NETter A: Oh, well there’s this great new idea called DDD!
ALT.NETter B: Yeah, right into that too.
ALT.NETter A: Oh.

And so on. But wouldn’t that conversation have been a whole lot more interesting if the second developer hadn’t heard of those ideas?

The View from on High

The ALT.NET conference is barely about the underlying technologies or ideas. It mainly serves to allow all of the ALT.NET developers to come together to talk about how great it is that they are all ALT.NET. Us, and them. Back to Sam:

I am not going to use the term “Morts.”

Good, because it’s an offensive term, but it’s one that’s being thrown around by the ALT.NET gang with abandon. Scott Hanselman, a great blogger, had this to say from the conference:

Mort is crying because mommy and daddy are fighting.

That’s the kind of patronising way in which the term is being used; I mean come on, the damn thing is short for “mortal” which is a pretty clear indication of how the people who use “mort” think of themselves: Gods of their domain. Overseers of the lower developers who haven’t had the resources, or the guidance, to work with the fantastic array of non-Microsoft technologies that exist.

And in order to address that imbalance, the ALT.NET mob organise an enormous desert circle-jerk, and I call bullshit. If they really wanted to change things then they should be writing about their techniques in detail, coming up with introductory guides to DDD, TDD, mocking, creating screencasts, or giving talks at mainstream conferences, or producing tools to make the level of entry to these technologies lower than it is.

Abandon ALT.NET – Before it Goes Too Far

A lot of people in the ALT.NET camp may not feel that they’re being divisive but I can tell you that by propagating this idea you’re creating a line in the sand, with the highly-knowledgable on one side and the masses on the other. You’re not encouraging dissemination of your information, you’re just creating another impenetrable gang of developers that is almost opaque to the guy on the ground.

UPDATE: I’ve updated this post on my LosTechies blog – see Why ALT.NET?

I’ve updated Phone2Flickr to 0.2, which while still very much an unstable product is a lot more useful than the earlier 0.1 release. I’ve added a wizard-style preferences screen which guides users through the steps needed to set the program up with their device. More importantly I’ve back-ported Phone2Flickr to .NET 2.0 which opens it up to a whole load more users.

Remind me – what does Phone2Flickr do?

Leave it running in the background and Phone2Flickr will grab photos from your phone when you come into range, and then send those photos up to your Flickr account. You need a Bluetooth enabled device which supports the Obex file browsing service; most new phones will.

Downloading and Contributing

Phone2Flickr 0.2 can be downloaded here. Thanks to Sean Chambers for encouraging the development of the new release!