We had several requirements, many of which are not common:

* We needed 40, 50 or more buttons on a page.
* We needed each button to retweet a story whose url and title was not the url or title of the current page

We looked at TweetMeme’s button:

TweetMeme Retweet Button

and Topsy’s button:

Topsy Retweet Button

at the time, I do not think TweetMeme allowed us to set the title of the retweet, preferring instead to fetch the title from the url we specified (which was sloooow)

They both ended up being kind of slow for us. We had 40 or 50 to add to each page which was taking 2 or 3 seconds.

Then we found another approach on John Resig’s blog

Easy Retweet Button

This approach was much faster, and allowed us to have much more control over the bitly-ification and the fetching of the current ‘number of retweets’ to display.

Oh, and of course we have John Resig’s blog on the Mattters JavaScript News Channel :-)

You can tell this book was rushed to press, so there was not the ‘fluff and padding’ that so many books have these days in order to beef up their page counts and bookstore shelf widths. Just crisp, detailed information on the subject(s) at hand. Excellent!

Most of the book is about XAML - the reason I bought the book in the first place. The content was presented in a literate, organized matter and, there being nothing much else to say on the matter. After starting to read (about 1/2 way through) Windows Presentation Foundation by Chris Sells & Jan Grifffiths (also largely about XAML, and also a very good book), I realize that WinFX: Beta was a very nice introduction - but that other, supplemental material is helpful understand the XAML in more depth.

Software Factories

The nugget here, in amongst fairly good yet lengthy descriptions of what a framework is (I spent my time in chapters 4 “Paradigm Shift”, 5 “Software Factories” and 17 “Frequently Asked Questions”), is that what might be called Domain Specific Frameworks (DSF) - which is a Framework targeted at supporting a particular kind of application, but also with support for minor variations amongst the possible applications built from the framework - can provide a measure of improvement on today’s average development process because:
1) The problem with most frameworks is that they are too general, and the related disease is that they are too big, and

2) The DSF still has all the benefits of a framework: a large body of (hopefully well-designed, bug-free) functionality required by the apps in the given domain which helps the coder know what to do and where to do it

This may, I think, provide more benefits over the Domain Specific Language (DSL) approach because:

1) They both have a similar learning curve where one has to learn either the DSL or how to use the framework but one rarely has access to the implicit framework behind the DSL for debugging and the inevitable tweaking.

2) it is a clearer, cleaner perspective of just what ‘domain specific’ means

The author also tries to tie the management of the common artifacts of software development (design docs, test plans, etc.) to the idea of the DSF. This is because the suppliers of the DSF know much more about the structure and required content of the artifacts of the resulting applications built on their DSF than do the suppliers of a general framework.

This does seem to be a large advantage - a ready made process for development of a class of applications (i.e. the factory line), but down this road lies cul-de-sacs like PowerBuilder - very, very successful, but do we as an industry want to go there?

Ruby on rails is nice, but at what point do these domain specific frameworks become a force in and of themselves? (They all seem to eventually take on an almost religious sanctity. Coders are a strange bunch, aren’t they? :-).

Do we have a choice? The champions of a DSL for every application, and the tower of Babel of XML specifications make it seem like we are headed there in any case. Other professions have a number of specialties as well, but there may turn out to be ridiculously large number of special ‘languages’ and a bifurcation of our profession into 1000s of little specialties. Par le vous X121.4ML?

Or maybe this is as it always was - except before the obscure specialty that only a few of us understood was your employers special collection of proprietary frameworks and tools, the knowledge of which was very nearly worthless outside of that environment. If so, then the move to a more standardized Software Factory for each and every little domain may indeed be an improvement on what we have now.

P.S. Hopefully MSFT does not hijack what is essentially a good idea and turn it into yet another over-hyped process sludge.