No Fluff Just Stuff

Podcast on Pulse in education and training

Kenneth Kousen — Thu, 21 Aug 2008 13:00:02 CDT

A couple of weeks ago I participated in a BriefingsDirect podcast about using Pulse in academic and training environments. For those who aren’t aware, Pulse is a product created by Genuitec (the same people who make the MyEclipse IDE) that allows you to manage Eclipse profiles and plugins. I’ve used MyEclipse in my academic courses at Rensselaer at Hartford for several years, so they asked me to be on the podcast.

The other people on the podcast were Michael Cote, an analyst with RedMonk, and Todd Williams, VP of Technology for Genuitec. The podcast was hosted by Dana Gardner, principal analyst at Interarbor Solutions.

The podcast itself and a verbatim transcript are now available, and can be found here.

This was my first time being interviewed on a podcast, and it was quite an experience. I would say that it was an interesting experience, but one of the most obvious things that jumps out at me from reading the transcript is that I use the word “interesting” far too often.

Top 5 reasons why Out Of Office messages are wrong

Emmanuel Bernard — Thu, 21 Aug 2008 11:00:02 CDT

Grails Training - Aug. 26 - 28, 2008

Thu, 21 Aug 2008 09:00:00 CDT

No Fluff Just Stuff is pleased to announce the Grails Training, Aug. 26 - 28, 2008.

Catch these Featured Sessions

Essence vs. Ceremony Pop Quiz

Stuart Halloway — Thu, 21 Aug 2008 08:00:02 CDT

Neal and I have been talking a lot about Essence vs. Ceremony this summer. In most of the examples I give, it is easy to tell which is which.

But that isn't always true. Consider this example from Scala. Does the application trait improve essence, or lead to more ceremony? I will post my answer next week.

Rotor v2 book draft available

Ted Neward — Wed, 20 Aug 2008 16:00:02 CDT

As Joel points out, we've made a draft of the SSCLI 2.0 Internals book available for download (via his blog). Rather than tell you all about the book, which Joel summarizes quite well, instead I thought I'd tell you about the process by which the book came to be.

Editor's note: if you have no interest in the process by which a book can get done, skip the rest of this blog entry.

One thing that readers will note that's different about this version of "the Rotor book" is that it's not being done through one of the traditional publishers. This is deliberate. As Joel and I talk about on the .NET Rocks! show we did together, the first Rotor book was on the first version of Rotor, which shipped shortly after the .NET 1.1 bits shipped to customers. That was back in the summer of 2001. Dave, Geoff and I shipped the book, I did a few conference talks on Rotor for the relatively few people who had an interest in what was going on "under the hood" of the CLR, and then we all sort of parted ways. (Dave retired from Microsoft entirely shortly thereafter, in order "to focus on the two things that matter in life: making music and making wine", as he put it.) Mission accomplished, we moved on.

Meanwhile, as we all knew would happen, the world moved on--Whidbey (.NET 2.0) shipped, and with it came a whole slew of CLR enhancements, most notably generics. Unlike how generics happened in the JVM, CLR generics are carried through all the way to the type system, and as a result, a lot of what we said in the first Rotor book was instantly rendered obsolete. Granted, one could always grab the Gyro patch for Rotor and see what generics would have looked like, but even that was pretty much rendered obsolete by the emergence of the SSCLI 2.0 drop, bringing the Rotor code up to date with the Whidbey production CLR release.

Except the book was, to be blunt about it, left behind.

Speaking honestly, the book never broke any sales records. Sure, for a while there it was the #1 best-selling book (in Redmond, WA, to my total shock and surprise) on Amazon, but we never had the kind of best-seller success that that of, say, Programming Ruby or pick-your-favorite-ASP.NET book. In the book publishing world, this was kind of the moral equivalent to watching your neighbors' slide show of their vacation: boring for most people not in the pictures, unless you were really interested in either the place they were visiting or what they did there. Most of our audience were either people working on the CLR itself (hence all the copies sold in Redmond, get it?), people who were researching on the CLR (such as the various Rotor research projects that came over a few years after its release), or people who just had that itch to "get wonky with it" and learn how some of the structures worked. Granted, a lot of what those people in the last category learned turned out to be pretty helpful in the Real World, but it was a payoff that came with a pretty non-trivial learning curve.

Fast-forward a few years, to the end of calendar year 2005.

By this point, .NET 2.0 has been out in production form for a bit, and Mark Lewin, then of Microsoft University Relations (I think that was his job, but to be honest my recollection on that point is kinda fuzzy) approached me: Microsoft was interested in seeing a second edition of the book out, to keep the Rotor community up to date with what was going on in the state of the art in the CLR. Was I interested? Sure, but the rules surrounding a multi-author book and subsequent editions are pretty clear: everybody has to be given right of first refusal. Thus a two-fold task was under way: find a co-author (preferably somebody from the CLR team, since my skills had never really been in navigating the Rotor source code in the first place, and I hadn't really spent a significant amount of time in the code since 2001), and get Geoff and Dave to indicate--in a very proper legal fashion--that they were passing on the second edition.

Ugh. Lawyers. Contracts. Bleah.

John Osborn then broke the bad news: OReilly wasn't interested in doing a second edition. I couldn't really blame them, since the first hadn't broken any kind of sales record, but I was a bit bummed because I thought this was the end of the road.

Mark Lewin to the rescue. Apparently his part of Microsoft really wanted this book out, to the point where they were willing to fund the effort, if I and my co-author were still interested. Sure, that sounded like a workable idea. And once the book was done, maybe we could publish it through MSPress, if that sounded like a good idea to me. Sure, that sounded good. Then Mark dropped the suggestion that maybe I could talk to Joel Pobar, former CLR geek extraordinaire, to see if he was interested. Joel had impressed me back when we'd briefly touched bases during the first book-writing experience, so yeah, sure, that sounded like a good idea. He was on board pretty quickly, and so we had the first step out of the way.

Next, we had to get OReilly to release their copyright on the first book, so we (and possibly MSPress) could work on and publish the second edition. This turned out to be a huge part of the time between then and now, not owing to any one party's deliberate attempt to derail the process, but just because copies of contracts had to be sent to the original three authors (myself, Stutz and Geoff) to sign over our rights with OReilly to a Creative Commons License, then copies had to be sent to everybody else so all the signatures could appear on one document, and so on.

Did I say it already? Ugh. Lawyers. Contracts. Bleah.

Then, we had to get a contract from Microsoft signed, and that meant more contracts flying back and forth across the fax lines, and then later the US (and Australian) postal system, and that was more delays as the same round of signatures had to be exchanged.

Just for the record: Ugh. Lawyers. Contracts. Bleah.

Finally, though, the die was cast, the authors were ready to go, and.... Hey, does anybody have the latest soft copy of the Word docs we used from the first edition? A quick email to John (Osborn) took longer than we thought, as OReilly tried to find the post-QA docs for us to work from. (I had my own copies, of course, but they were pre-QA, and thus not really what we wanted to start from.) More rounds of emails to try and track those down, so we can get started. Oh, and while we're at it, can we get the figures/graphics, too? They're not in the manuscript directly, so.... Oh, wait, does anybody know how to read .EPS files?

Then began the actual writing process, or, to be more precise, the revision process. We decided on a process similar to the way the first book had been written: Joel, being the "subject matter expert", would take a first pass on the text, and sketch in the rough outlines of what needed to be said. I would then take the prose, polish it up (which in many cases didn't require a whole lot of work, Joel being a great writer in his own right) and rearrange sections as necessary to make it flow more easily, as well as flesh out certain sections that didn't require a former position on the CLR team to write. Joel would then have a look at what I wrote, and assuming I didn't get it completely wrong, would sign off on it, and the chapter/section/paragraph/whatever was done.

And now we're in the process of doing that cosmetic cleanup that's part of the overtime period in book-writing, including generating the table of contents and index, since, it turns out, we'd rather publish it ourselves than through MSPress (which they're OK with). So, readers will have a choice: get the free download from Microsoft's website (once we're done, which should be "real soon now") and read it in soft-copy, or buy it off of Amazon in "treeware version", which will put a modest amount of money into Joel's and my collective pocket (once the relatively modest expenses of self-publishing are covered, that is).

This will be my first experience with self-publishing (as it is for Joel, too), so I'm eager to see how the whole things turns out. One thing I will warn the prospective self-publisher, though: do not underestimate the time you will spend doing those things the editorial/QA/copyedit pass normally handles for you, because it's kind of a pain in the *ss to do it yourself. Still, it's worth it, particularly if you're having a hard time selling your book to a publisher who, for reasons of economy of scale, don't want to publish a niche book (like this one).

Anyway, like many of my blog postings, this post has gone on long enough, so I'll sign off here with a "go read the draft", even if you're a Java or other execution engine/virtual machine kind of developer--seeing the nuts and bolts of a complex execution engine in action is a pretty cool exercise.

Oh, and if anybody's interested in doing a similar kind of effort around the OpenJDK (once it ships), let me know, 'cuz I'm a glutton for punishment....

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Ajax running on borrowed time

Richard Monson-Haefel — Wed, 20 Aug 2008 13:00:02 CDT

From erikbianchi.com: "JavaScript has remained virtually unchanged for over a decade now and with ECMA’s recent announcement, about dropping the ECMAScript 4 proposal, JavaScript will continue to remain essentially the same for at least another 5 years."

An Attempt to Define Value

Johanna Rothman — Wed, 20 Aug 2008 11:00:02 CDT

Jim, in his comment on Intuition is Not Enough for Knowing About the Project Portfolio, said:

I am having trouble with the definition of the word “value” in this context. Do you mean showing progress, as in earned value, or value to the customer, such as in ROI or payback period? Value has become a loaded word. Please define your terms.

To me, value is some visible form of progress. I prefer working product. I can live with a demo. I can live with a prototype. In some very small number of organizations, I can briefly live with a document. A document ceases to be visible progress after a very small period of time, such as a few days, maybe a week. Demos and prototypes also lose their value over time, if they do not become working product.

Managers can’t make good decisions about the portfolio if they can’t see visible progress, so they can tell if the money they’ve spent is worth the time they’ve invested.

If I really knew how to calculate ROI (and not make it be a number I can just make work), I would use ROI. But that’s a bigger rant for another time.

Taking SwingBuilder's binding for a spin

Andres Almiray — Wed, 20 Aug 2008 08:00:02 CDT

Those of you that follow @shemnnon's blog will surely know that he has revamped how binding is supported in the development versions of Groovy 1.6.x (here, here and here). Impatiently as ever, I created my own distro of groovy 1.6-beta-2-SNAPSHOT and gave it a try, quite fitting with the latest JavaFx Script experiments.

One of the appealing features of JavaFx Script is that it has binding baked right into the language, it also sports the notion of triggers. You can attach any function on a trigger, whenever the trigger receives a biding update event the function will be called. This is akin to PropertyChangeListener and PropertyChangeEvent, only you don't see those classes in the open with JavaFx. So here goes, three simple binding/triggers examples on JavaFx Script and Groovy. The examples are not comprehensive, binding both languages can cover a broader spectrum. It is important to note that binding in Groovy is provided by a set of APIs (SwingBuilder and the bind factory) not by the language itself.

The first snippet exemplifies binding between two components, the label's text will be updated every time text is written on the textField, first comes the JavaFx Script version
And now its Groovy counterpart

Maybe there is another way to setup the binding between the label and the textfield on JavaFx Script, but you can't define variables while building the content unless you do it inside a function, this means that those components are not built close to the place where they are inserted into the UI hierarchy. Clearly that is not a problem with the Groovy version. The next snippet introduces one level of indirection, a textModel. Now the label will bind to a third object that holds a text attribute. A button is also added to 'trigger' the update
The code is pretty much self explanatory, I would say the same holds true for the Groovy versionObservableMap is an utility class that fires up PropertyChangeEvents every time a property is added, updated and/or removed from it, in contrast observable beans usually fire events when a property is updated only (more options for you!). I can hear someone at the back saying 'but you JavaFx Script does have triggers, why don't you use them instead?' certainly I will. So let's remove the button and bind the label, textField and textModel, adding a console printout just to show that the model is being updated as expected, and it in turn updates the labelIt only took two binding calls and one trigger, sweet. What about the Groovy version? well, we don't have triggers (yet) that make the code short but it is certainly doableNotice that a regular PropertyChangeListener has been registered with the ObservableMap, this is how triggers are implemente in Java/Groovy. Binding the textField's text to the textModel's text property is also a bit more verbose than before. As a matter of fact that syntax used to be the previous one, so you can see that binding has been improved, just a bit but good enough I think it is possible to cook up a trigger dsl to reduce the amount of code required to create triggers in Groovy, don't you think? we have metaprogramming on our side after all.

Keep on Groovying!

Compass 2.0.2 Released

Shay Banon — Tue, 19 Aug 2008 16:00:02 CDT

Compass version 2.0.2 released. This is a bug fix released for Compass 2.0 and is recommended for all Compass users. Full change log can be found here.

How Buildings Learn

Michael Nygard — Tue, 19 Aug 2008 13:00:02 CDT

Stewart Brand's famous book How Buildings Learn has been on my reading queue for a while, possibly a few years. Now that I've begun reading it, I wish I had gotten it sooner. Listen to this:

The finished-looking model and visually obsessive renderings dominate the let's-do-it meeting, so that shallow guesses are frozen as deep decisions. All the design intelligence gets forced to the earliest part of the building process, when everyone knows the least about what is really needed.

Wow. It's hard to tell what industry he's talking about there. It could easily apply to software development. No wonder Brand is so well-regarded in the Agile community!

Another wonderful parallel is between what Brand calls "Low Road" and "High Road" buildings. A Low Road building is one that is flexible, cheap, and easy to modify. It's hackable. Lofts, garages, old factory floors, warehouses, and so on. Each new owner can gut and modify it without qualms. A building where you can drill holes through the walls, run your own cabling, and rip out every interior wall is a Low Road building.

High Road buildings evolve gradually over time, through persistent care and love. There doesn't necessarily have to be a consistent--or even coherent--vision, but each own does need to feel a strong sense of preservation. High Road buildings become monuments, but they aren't made that way. They just evolve in that direction as each generation adds their own character.

Then there are the buildings that aren't High or Low Road. Too static to be Low Road, but not valued enough to be High Road. Resistant to change, bureaucratic in management. Diffuse responsibility produces static (i.e., dead) buildings. Deliberately setting out to design a work of art, paradoxically, prevents you from creating a living, livable building.

Again, I see some clear parallels to software architecture here. On the one hand, we've got Low Road architecture. Easy to glue together, easy to rip apart. Nobody gets bent out of shape if you blow up a hodge-podge of shoestring batch jobs and quick-and-dirty web apps. CGI scripts written in perl are classic Low Road architecture. It doesn't mean they're bad, but they're probably not going to go a long time without being changed in some massive ways.

High Road architecture would express a conservativism that we don't often see. High Road is not "big" architecture. Rather, High Road means cohesive systems lovingly tended. Emacs strikes me as a good example of High Road architecture. Yes, it's accumulated a lot of bits and oddments over the years, but it's quite conservative in its architecture.

Enterprise SOA projects, to me, seem like dead buildings. They're overspecified and too focused on the moment of rollout. They're the grand facades with leaky roofs. They're the corporate office buildings that get gerrymandered into paralysis. They preach change, but produce stasis.

Does Your Team Have STDs?

Jared Richardson — Tue, 19 Aug 2008 11:00:04 CDT

Last week I was talking with a friend about a common ailment on development teams today. And it seems to be getting worse.

Perhaps you've seen it already in your shop. Once one person catches an STD, it seems to spread quickly.

STD, of course, stands for Shiny Things Development.

Oh cool! Check that out... it's new and cool. Let's include it in the product! Why? Umm... it solves some problem. And didn't I just say it's shiny and new?

How many shops have you met that have insane development infrastructures "just in case" things get crazy? Anytime the shop has a list of tools and libraries where every single one requires a specific version for anything to work, someone there has STD.

What's the problem with STD? It generally indicates a lack of discretion and promiscuous use of technology. Rather than saving yourself for something that actually works, you're chasing down every new product and technology. Sure, it might be fun to try out new stuff

Need Help with BackUpWordPress

Johanna Rothman — Tue, 19 Aug 2008 08:00:02 CDT

I’ve been using BackUpWordPress to backup my blogs. I successfully upgraded Hiring Technical People to a newer version of WP and of BackUpWordPress. I upgraded this blog, Managing Product Development, to the newer version of WP, but now my newer version of BackUpWordPress is not working. I’m pretty sure it’s all about file permissions.

If you have experience with this and insight, please email me, jr at jrothman dot com. I can’t figure out what I’m doing wrong and want to keep backing up! Thanks.

Name Soup

Alex Russell — Mon, 18 Aug 2008 16:00:01 CDT

There still seems to be an amazing amount of FUD going around regarding the Harmony announcement. There is clearly a very different perspective from those who have been sitting inside the WG for the past year (as Kris Zyp and I have been lucky to). Inside the WG, the change seems a welcome way to break a logjam of reasonably held opinions of people who are all acting in good faith. From the outside, it all looks like confusion and game-playing.

One of the things, though, that keeps getting me frustrated as I read the “coverage” is that the names people use are confused. Probably because the names are confusing. Here’s a quick glossary:

ECMAScript 3

Aka: JavaScript, ES3, ECMAScript 262-3, and JScript.

The current JavaScript that every browser implements (more or less). This is the current ratified standard and represents the 3rd edition of the ECMAScript spec. It is very old. Nothing else in this list is (yet) a ratified standard of any sort.

ECMAScript 4

Aka: ES4, “JavaScript 2″.

A new language which was to be mostly backwards compatible but add optional (gradual) typing and class-based inheritance. Based loosely on Adobe’s ActionScript 3. This is the language effort which died as a result of Harmony.

ECMAScript 3.1

Aka: ES3.1. A set of small additions to ES3.

Planning for this edition was started at Microsoft and Yahoo’s behest late last year, causing the split in the working group which has been healed by the Harmony announcement.

ActionScript 3

Aka: AS3

Adobe’s current JavaScript-like language, only with many features lifted from languages like Java which also enforce types and class-based semantics. This was the starting point for much of the work which became known as ES4.

Tamarin

A JIT-ing byte-code virtual machine (VM) which is at the core of the Flash Player and was donated by Adobe to the Mozilla Foundation. This is the VM that runs ActionScript 3 code today but will likely run “real” JavaScript for Mozilla in the future. It is not a full implementation of ES3 or ES4, but instead implements its own byte-code and needs to be wedded to a “front end” (like the ActionScript 3
compiler from Adobe) in order to be usable by programmers.

Tamarin-tracing

A VM which implements the same byte-code language as Tamarin (known as “ABC”) but which is designed for use in mobile devices and other scenarios where code size and VM footprint are important. It implements trace-tree JIT-ing as a way to speed up hot-spots. Also donated to Mozilla by Adobe.

TC39

The name of the ECMA technical committee which is chartered to evolve the JavaScript language.

Harmony

A new code-name for a language which is to come after ES3.1. It will feature many of the things ES4 was trying to accomplish, but may attempt them from different directions and will
focus much more on incremental, step-wise evolution of the language.

JavaScript 2

A now-defunct name. This name was originally given to Waldemar Horwat’s first proposal at a large-scale evolution of the JavaScript language in 1999. That effort did not succeed (although Microsoft implemented some of it in JScript.NET) and subsequent work via the current TC39 charter to build ES4 has sometimes been given the name “JavaScript 2″, but it never really stuck. Not a name that describes any ratified standard or current proposal.

ECMAScript

The formalized name of the JavaScript language. Since Sun Microsystems owns the name JavaScript and has no idea what to do with the trademark (but has been benevolent thus far), the ECMA committee which standardized the language was forced to adopt a different name.

Cloud-Oriented Architecture (COA)

Scott Leberknight — Mon, 18 Aug 2008 13:00:02 CDT

With all the hype this year about cloud computing and things like Amazon EC2/S3 as well as Google App Engine and Bigtable, you can feel it coming. Soon vendors will be peddling COA (Cloud-Oriented Architecture) solutions, probably combining them with their SOA solution and somehow probably getting their ESB solution into the mix as well. This past weekend at the Enterprise Architecture BOF at the Southern Ohio Software Symposium, we had a discussion about cloud computing among other things. Ted Neward even coined the term "Enterprise Service Cloud" and I came up with "Cloud Service Bus," surely the next Big Thing. Any vulture (I mean, venture) capitalists out there want to invest in my new Cloud Service Bus company? I have a pretty brochure ready to go!

The big difference I see with regard to cloud computing is the fact that, unlike your typical ESB/SOA peddling vendors, companies like Amazon and Google already have cloud or cloud-like solutions in place a la Amazon EC2/S3 and , and Google App Engine and Bigtable. Now all of those things just mentioned are not "the cloud" (whatever "the cloud" actually is defined to be), but it doesn't matter because the point is these companies have designed, implemented, and most importantly, run their critical business operations on these platforms. That in and of itself is more important than all the vaporware and marketing hype any other vendor comes up with. Rather than having to get customers to believe that a solution works via marketing and then force it down their IT staff's throats, Google and Amazon are basically saying "Hey why not use stuff that we use and have proven can scale up to handle huge loads and huge amounts of data?"

To me as a developer this is a much more appealing approach for several reasons. First, it means there won't be (or shouldn't need to be) any "golf-course deals" where the vendor sales guys and customer CIOs/CTOs/CEOs meet up and decide on the technology stack independent of any real technical analysis, investigation, or input of the people who will be charged with implementing the vendor stack (and they better do it well else it's their job on the line to boot).

Second, I can base my decision to use a Google or Amazon service based on their actual track record in delivering these services and eating their own dog food, since they are trying to monetize their existing investment in proven highly distributed and scalable infrastructures. Yes, there have been Amazon outages this year and whenever it happens it is big news because it is right there out in the public, as opposed to a company whose IT operations are totally in-house and which isn't going to publicize their downtime statistics. I'd wager on Amazon and Google's availability over probably most other companies. Of course I have no way to prove that last statement, but the mere fact that I can get objective statistics on their services helps in my decision making process and planning.

Last, I can decide how much or how little to outsource to the Amazon or Google infrastructure; for example some organizations might choose to keep their most sensitive data (e.g. customer information, credit card numbers, etc.) in-house but outsource everything else to, say, an Amazon EC2/S3 infrastructure. There is still some level of vendor lock-in here, but there is with anything else short of you implementing your own solution from scratch. And if, by leveraging proven solutions by companies like Amazon and Google, you are able to deliver real value to your customers faster and are able to scale up, out, and beyond without needing to build that infrastructure yourself, then I'd say that could potentially equate to a big win.

So when that vendor comes calling with their shiny new COA solution, be very afraid, and make sure you know your options and present them objectively. We as an industry have more buzzwords and hype (at least from my perspective) than almost any other, and this causes more money than I can possibly imagine to be wasted every year on solutions that don't (and never will) work as advertised. Developers often have a feeling that the VDD (vendor-driven development) solutions just won't work, but cannot convince their managers or their managers' managers of this fact, which is why communications skills are critical in today's world. I don't know about you, but I don't want to be the person who becomes responsible for implementing a solution I don't believe in.

"The Cloud" and cloud computing are definitely here to stay forever, and as Amazon and Google have proven, can add huge amounts of value to businesses. I am sure there will be other companies perhaps trying to implement similar strategies and monetizing their investment in their own infrastructure, and that will be mostly a good thing to have different options and competition to further push the Cloud Service Providers (CSPs) to continually improve their offerings. Get ready, because our toolboxes have just become a lot bigger.

jSilhouette update

Andres Almiray — Mon, 18 Aug 2008 11:00:02 CDT

A couple of days ago there was an announcement on this blog about jSilhouette's 0.1 release, followed by a comparison between the geom, scene and jfx demos (regular Java, Project SceneGraph and JavaFx Script each).

Things have changed a bit. Jacek Furmankiewicz brought to my attention that Project SceneGraph is licensed under GPLv2 (no classpath extension) which means both jsilhouette-scene and jsilhouette-jfx must use the same licensing scheme. But jsilhouette-geom does not, in fact it has been re-licensed to ASL 2.0, this means that starting with the next release commercial use of jsilhouette-geom is no longer a problem. The commercial usefulness of the remaining modules lies in Sun's will to re-license Project SceneGraph to GPLv2 with classpath extension.

Some other updates

Donut shape has been added to all modules. Donuts may be circular or polygonal.
Default values have been added to some attributes in the jfx module, alleviating the pain of setting each attribute.
Groovy demo (GraphicsBuilder based) available!

Here is an screenshot on the latest demo app

Nice Nimbus look &feel, you may be thinking that this is the new version of the jfx demo, but it is not! this is the Groovy version (ShapesDemoGroovy.groovy) , the green color is darker in jfx, remember? let's revisit the stats, shall we?

	geom	scene	jfx	groovy
LoC	369	505	619	369
Tokens	1486	1855	2644	2194
Source file size (bytes)	16412	21000	20626	15311
Compiled code size (bytes)	104K	60K	76K	92K

The Groovy version beats the JavaFx Script version in almost all categories (the source file is even shorter than the Java2D version) but these numbers do not reflect how small the code can be in each version. For example I discovered that the jfx version has some commas (,) between attribute declaration (which bump the char and file size), I was surprisewd to find out JavaFx Script was happy with them as not even a slight warning is given by the compiler, nice!; the Groovy version harnesses the power of native syntax for Lists and Maps to reduce variable declaration; defaults values are not really used that much in all versions.

I also mentioned previously that making the second and third demo was quicker once the first one was done, in this case it was no different. The jfx version was copied almost verbatim, added some Groovy sugar here and there (even had to add a MetaClass hack due to how SwingBuilder handles look&feel in the 1.5.6 version (the new one is slicker thank @shemnon for that)). Quick comparison between how the jfx and groovy versions initialize the frame, first the jfx one

SwingFrame {
   title: "jSilhouette Shapes (JavaFX)"
   visible: true
   closeAction: function() { System.exit(0); }
   width: 500
   height: 400
   content: BorderPanel {
      center: canvas /*an instance of Canvas*/
      left: GridPanel {
         columns: 1
         rows: 10
         content: [
            SwingButton { text: "Arrow"    action: drawArrows },
            SwingButton { text: "Balloon"  action: drawBalloons },
            SwingButton { text: "Cross"    action: drawCrosses },
            SwingButton { text: "Donut"    action: drawDonuts },
            SwingButton { text: "MultiRoundRectangle" action: drawMultiRoundRectangles },
            SwingButton { text: "Rays"     action: drawRays },
            SwingButton { text: "RegularPolygon" action: drawRegularPolygons },
            SwingButton { text: "RoundPin" action: drawRoundPins },
            SwingButton { text: "Star2"    action: drawStars },
            SwingButton { text: "Triangle" action: drawTriangles }
         ]
      }
   }
}

Where each draw* function is of the form

Here I'd like to take the opportunity to mention that the function signature must have Void as its return type otherwise a compilation error will be thrown. If the return type is not specified then it will be the same type of the last evaluated expression, in this case Node[], SwingButton expects its action function to return Void. I'm sure a tool (like NetBeans' jfx plugin) would have drawn a red underline/popped an error/whatever under the offending code before attempting a full compile on the code by myself, but I went with the "manual" way: Vim + command line compiler, so there, had to be more careful

Here is the Groovy version

Where shapes is a Map initialized like

The Groovy version requires some 'blumbing'

Fix SwingBuilder.lookAndFeel to accept a List of L&F identifiers (available in Groovy 1.6.x).
Set the preferred L&F.
Tell the frame where it should be located by default (locationRelativeTo: null)

The native syntax for Lists and Maps comes in our aid here. Iterating each entry (String,GraphicsOperation) it is a matter of hooking up the proper values on the button's text and action. Notice that each time a button is clicked a new GraphicsOperation is created (a group) that has a 'global' property applied to all its children (borderColor: 'black') and antialias is turned on. GraphicsPanel is smart enough to know when it should repaint itself (similar to JSGPanel and Canvas). Of course some would say you may iterate over a sequence in the jfx version in order to build the buttons in a loop, sure you can. You could also create a java.util.Map that holds each label and related function, but the code is not as concise as the Groovy one. Assuming hypothetical classes javafx.util.LinkedHashMap and javafx.util.MapEntry
Yup, hypothetical is more like it (my code that is, still have to learn more about JavaFx Script) but you get the idea. Back to jSilhouette, I'd like to have proper javadocs/javafxdocs in place before releasing the next version, so it will take a couple of days more.

Feedback is always appreciated.

Testing Anti-Patterns: Invisible Code

Jason Rudolph — Mon, 18 Aug 2008 08:00:02 CDT

As we’ve seen over the last several weeks, it’s remarkably easy for code to earn the badge of 100% test coverage without necessarily having a strong test suite. In each of those examples, the coverage analysis tool performed its task flawlessly: it reported exactly which portions of our code were executed as a result of running the tests. The all-green coverage report showed us that the tests indeed touched all of our code, but it was up to us to acknowledge that simply touching a line of code doesn’t mean that you’ve exercised and verified that line of code in a meaningful way. Some folks interpret this acknowledgement to mean that coverage analysis is meaningless, but that unfortunate conclusion overlooks the real benefit of a coverage report: it’s not about getting to 100% test coverage and assuming victory, it’s about highlighting any areas of our codebase that we’ve forgotten to test entirely.

As with any tool, to make effective use of coverage analysis, we need to understand its purpose, its capabilities, and its limitations. In all of the previous examples, we looked at code that was already in the coverage report. In other words, the coverage tool knew about this code and was able to watch the code and assess its coverage upon completion of the test suite. But if we’re using the coverage report to help us find untested code, how do we deal with code that the coverage tool might not be aware of in the first place?

Let’s start with a sample Rails app that represents the beginnings of an online store. The project currently contains the following files (as well as some others that I’ve omitted for the sake of brevity).

[store]$ tree
...
|-- app
|   |-- controllers
|   |   |-- application.rb
|   |   `-- products_controller.rb
|   |-- helpers
|   |   |-- application_helper.rb
|   |   `-- products_helper.rb
|   |-- models
|   |   `-- product.rb
|   `-- views
|       |-- layouts
|       |   `-- products.html.erb
|       `-- products
|           |-- edit.html.erb
|           |-- index.html.erb
|           |-- new.html.erb
|           `-- show.html.erb
|-- config
|   |-- boot.rb
|   |-- database.yml
|   |-- environment.rb
|   |-- environments
|   |   ...
|   |-- initializers
|   |   |-- inflections.rb
|   |   |-- mime_types.rb
|   |   `-- new_rails_defaults.rb
|   `-- routes.rb
|-- db
|   |-- migrate
|   |   `-- 20080810220638_create_products.rb
|   `-- schema.rb
...
|-- lib
|   |-- product_ftp_importer.rb
|   `-- tasks
|   |   |-- data_load.rake
...
|-- test
|   |-- fixtures
|   |   `-- products.yml
|   |-- functional
|   |   `-- products_controller_test.rb
|   |-- integration
|   |-- test_helper.rb
|   `-- unit
|       `-- product_test.rb
...

37 directories, 63 files

After installing the rails_rcov plugin, we can easily produce a coverage report to see where we currently stand.

According to the coverage report, we’re not aware of any code that isn’t touched by at least one test. But is that really the whole story? The number of test-related files sure accounts for a small proportion of the overall app. We can see that we have test/unit/product_test.rb and test/functional/products_controller_test.rb, but do those two files really encompass all the developer testing needed for this application?

Out of Sight, Out of Mind?

What about that mysterious file hanging out in the lib directory?

[store]$ tree
...
|-- lib
|   |-- product_ftp_importer.rb
...

Just judging by the name of the file, that sure sounds like functionality that deserves testing, but for some reason it’s not listed in the coverage report. And if we take another look at the test files listed above, there are no test files that obviously correlate to product_ftp_importer.rb. So, how is it that we have 100% coverage?

In order for code to show up in a coverage report, we need to instruct the coverage tool to assess that file. The approach for doing so tends to vary from tool to tool. With rcov, we first have to tell it which files constitute our test suite (i.e., the files we want rcov to run). But that alone is not sufficient; we also have to ensure that application files (i.e., the files whose test coverage we want to measure) get loaded as part of the test suite. Adding this require statement anywhere in our test suite is enough to shed some light on the elusive code in product_ftp_importer.rb.

require File.expand_path(File.dirname(__FILE__) + "/../lib/product_ftp_importer")

It’s hard to feel good about 45 lines of untested FTP-processing voodoo, so how can we unearth this invisible code as soon as it tries to sneak its way into our app?

Ensure that your coverage task knows where to find your tests, always place new tests where the coverage task can find them, and use a consistent naming scheme so that a simple file-matching pattern can distinguish test files from non-test files.
If you’re using rcov, add a quick script that will crawl your project tree and require all application files. Adding individual require statements one-by-one is not a reasonable solution. If someone’s not going to write the test in the first place, they’re sure as heck not gonna take the time to tell the coverage report about that misdeed. So, walk the tree and require any Ruby file that you encounter in places where application code is likely to turn up. At the very least, in a Rails app you should include all subdirectories under app (being aggressive enough to catch any new directories that might get added there) and the lib directory.

(Not So) Scenic View Ahead

View templates have long been a favorite dumping ground for misplaced application logic. This problem can often go undetected, because view templates fly under the radar of the coverage report. Most developers know they should minimize the application logic included in the view, but when a deadline’s looming, the lure of throwing some code in the view “just this once” is often hard to resist. For example, what’s so wrong with having the view decide whether to display a particular product in the list?

<% for product in @products %>
<% if product.quantity_in_stock > 0 && product.quantity_in_stock > product.pending_backorder_count %>
<!– display purchasable product here –>
<!– … –>
<% end %>
<% end %>

Well, how exactly will we verify that the view is indeed displaying the right products and suppressing the others? We could manually test each scenario by visually inspecting the resulting UI, and that might be good enough for us to have confidence that the app is doing the right thing as of this moment. But code has a life of its own, and it will grow and change over time, and we want automated tests to make sure that this page continues to display the correct data even after those inevitable changes.

So we decide to write tests to verify that we’re displaying only the right products. And since this logic is inside our view template, we need to write tests that will render our view template and then dissect the resulting HTML to verify that it contains the products that should be present and that it does not contain the products that should not be present. But in order to render the HTML, we need to invoke some controller action. And because that lone if statement needs at least four different test cases to check the various conditions, we get the joy of doing all that setup and dissection at least four times. That’s a big enough pain that it quickly becomes very tempting to let this bit of logic remain untested, remain out of sight of the coverage report, and remain “good enough.”

We can do better than that. When something’s too hard to test, we should refactor it until it’s easy to test. [1]

We’re going to need this logic outside of the view anyway, so the sooner we get it into the model the better. Sure, the view will only display those products that are available for purchase, but we need that logic for server-side validation as well. Before we process an order, we need to make sure that we still have the product in stock. If we leave the logic in the view as is, then we’ll be forced to duplicate that logic elsewhere inside our order-processing code. There’s clearly no justification at all for leaving this logic in the view.

<% for product in @products %>
<% if product.available_for_purchase? %>
<!– display purchasable product here –>
<!– … –>
<% end %>
<% end %>

When we encapsulate this logic in the Product class itself, we can test that logic in isolation, without any dependencies on controllers, and without the need for fragile HTML-parsing to verify the result. Once we perform this refactoring, unit testing the #available_for_purchase? method becomes trivial, and we can refer to that method wherever necessary without unnecessary duplication.

Better still, if we know that we only want to display the products that are available for purchase, we can ensure that our controller provides only those products to the view in the first place. With this approach, our view then enjoys the pleasant simplicity of just displaying the list of products.

<% for product in @products %>
<!– display purchasable product here –>
<!– … –>
<% end %>

The coverage report isn’t going to alert us to business logic lurking in our view templates. It’s up to us to keep our views from becoming too smart for their own good, and it’s up to peer code reviews to keep us honest.

Raking for Buried Treasure

While it’s tempting to let our views acquire too much business logic, there’s usually an obvious place to move that logic once we realize the error of our ways. (In Rails, you’ll typically relocate that logic to a model class or to a helper, either of which are easily tested in isolation.) But what about the other parts of our application where untested code tends to hide out and germinate?

Perhaps we have some code that only needs to run at application start-up. In Rails, we’re talking about code in environment.rb or config/initializers. In Grails, BootStrap.groovy is home to this logic. In either case (or in most any other framework), we’re not likely to see those start-up “scripts” included in the coverage report, nor is there a natural and obvious place for testing any complex code that we may need to include in the start-up process. We’re used to testing models and controllers and helpers and mailers, but where does this start-up logic fit into the mix?

Data migration suffers from a similar problem. Rails migrations are great for creating and dropping tables, adding and removing columns, etc., but sometimes we need to do more than just alter the schema; sometimes we want to push data around as well. Schema transformations are essentially declarative code, and really don’t warrant anything beyond visual verification of the results. But when it comes time to migrate 10 million records from some legacy database into our hip new application, chances are we’re not just talking about simple declarations anymore. What’s the worst that could happen though? This code only has to run once. And who wants to write a bunch of tests for code that we’re only gonna run once and then throw away? And once again, there’s no obvious place for us to add tests for this kind of data conversion functionality in the first place. Surely a simple Rake task will suffice.

namespace :db do
namespace :load do
desc ‘Load products from csv’
task :products do
require ‘csv’
require ‘environment’
CSV.open("#{RAILS_ROOT}/db/input/csv/product-catalog/products.csv", ‘r’).each_with_index do |row, idx|
next if row[0] == "Product"
p = Product.find_or_create_by_name(row[0])
p.description = e.purpose = row[5]
p.sku = row[3]
p.price = row[4]
p.save
shipping_options = row[1].split("|")
shipping_options.each do |o|
p.shipping_options << ShippingOption.find_by_name(o)
end
vendors = row[2].split("|")
vendors.each do |v|
p.vendors << Vendor.find_by_number(v) unless v.downcase == ‘none’
end
end
end
end
end

Indeed, a simple Rake task will suffice, but that’s certainly not what we’re looking at above. While we could write tests for this logic in its current state, doing so is unnecessarily difficult. We’d be restricted to solely black box tests. To test each individual decision point, we’re forced to also construct a new file holding the appropriate dataset, run the Rake task, and then inspect the state of the data in the database. For every decision point.

Scripts Can Be Classy Too

We shouldn’t have to also test the ability to read a file (i.e., line 7) just so that we can test the ability to populate a vendor based on a given vendor number (i.e., line 21). For sure, we want one good end-to-end test to verify that all the cogs are working together correctly. But if that’s our sole testing strategy, then we’ve made testing just painful enough that it probably won’t happen at all.

Whether we’re talking about hard-to-test code in start-up scripts, hard-to-test code in migration scripts, or hard-to-test code hiding out in the handful of other custom scripts that an application tends to accumulate over time, the answer’s the same in each case. Just because the coverage report doesn’t see this hidden code doesn’t mean that it’s not worth testing. And just because our framework-of-choice might not provide a convention for testing this logic, that doesn’t mean that we should just punt.

When something’s too hard to test, we should refactor it until it’s easy to test.

namespace :db do
namespace :load do
desc ‘Load products from csv’
task :products do
require ‘environment’
importer = ProductCsvImporter.new("#{RAILS_ROOT}/db/input/csv/product-catalog/products.csv")
importer.run
end
end
end

In the case of this Rake task, and in each of the cases discussed above, by simply moving the logic out of the script and into a proper class (or module), the testing strategy goes from clumsy at best to downright obvious. We no longer need to invoke the whole script in order to verify the particular unit of functionality that we want to test. Instead, we test that functionality in isolation, and allow the script to resume its trivial role of merely calling our well-tested class.

Use It Wisely

In order to make effective use of coverage analysis, it’s important for us to understand what a coverage report is telling us and what it’s incapable of telling us. Tools are imperfect, but we can adopt strategies to make sure we’re reaping the maximum benefit from the tools we choose to employ. With good naming conventions and an agreed-upon application structure, we can easily configure an intelligent solution that allows the coverage tool to automatically pick up any new source files that we want included in the report. With a commitment to testing all application logic - regardless of whether it’s needed in a model, a view, a script, etc. - we’ll extract the code that would otherwise be buried in a dark corner of our app. We’ll benefit from the ability to test it in isolation, and we’ll allow the coverage tool to assess that code, giving us a more realistic and complete view of our codebase.

Invisible code is hidden technical debt, but the sooner you expose it, the sooner you can start to pay it down.

Notes

[1] In past posts in this series, I’ve advocated test-driven development (TDD) as means for combatting the various testing anti-patterns. Invisible code is no exception. While this post is geared more toward uncovering invisible code so that we can give it the testing it deserves, developing test-first is the best bet for preventing invisible code in the first place.

This series is taken from the How To Fail With 100% Test Coverage talk. Check the schedule for a talk near you.

–

Thanks to Muness Alrubaie, Justin Gehtland, and Greg Vaughn for reading drafts of this post.

Agile 2008 - Sanjiv Augustine - The effect of Agile Projects on Middle Management

Bob Payne — Sun, 17 Aug 2008 16:00:01 CDT

I talk with Sanjiv Augustine about his work with Agile Project/Portfolio Management and the Middle Managers that execute projects within organizations. Sanjiv and I have worked together for years on client engagements, training and publishing. More recently we have been working to kick off Agile Philanthropy. LitheSpeed was the sponsor for the LiveAid Stage this year and you will be seeing more of Sanjiv and LitheSpeed in the years to come here on the Agile Toolkit Podcast.

Enjoy.

-bob payne

eRubyCon 2008 Day 2

Josh Holmes — Sun, 17 Aug 2008 13:00:02 CDT

Yesterday I wrote a write up of eRubyCon 2008 Day 1.

- Charles Nutter started up with JRuby. I'm always impressed by people that are able to make their weekend project their full time job. I was further impressed that Charles was up with the rest of the speakers until closer to 4am than any of us should really admit, drinking really good scotch and solving the world's problems.

Charles talked about the JVM and Java as both a problem and a great asset. There are a lot of people that look at the J in JRuby and automatically associate it with all of the things that they don't like about Java. Charles answer is to separate the JVM from the Java language. He did a really good job of talking about the things that the JVM brings over the standard Ruby runtimes such as world class garbage collection, memory compaction, thread handling and the like. He did a number of really compelling demos around threading in particular. One of the things that he said here is that JRuby and IronRuby are really the only Ruby implementations that are able to do native threads because they are the only ones that are built on production quality VMs that handle that native threading for them.

One of the great quotes was "We write a lot of Java. So you don't have to..." - Charles Nutter

After setting the stage, he pulled up a long list of features and said - "There's way too much for me to cover in the time left - what do you want to see?". that was fun. The first suggestion that he showed was 2D graphics that flashed a bunch of little balls around the screen. It was even responsive to voice commands. The second suggestion was to show Rails running on JRuby. He showed that they are running Rails on Ruby 1.8.6 (java). Next he brought up image_voodoo to do more 2D libraries. Lastly, he showed "java_inline" which allows you to inline Java code similar to the Ruby_inline which allows you to inline C right in your Ruby code.

- Evan Light came up next. Unfortunately I was putting out a few small fires. Fortunately Michael Lettere wrote up a small write up so that I could include it here.

Evan Light hates EJBs.
EJB encourages difficult to test idioms, private fields, private static final fields.
Nice demo code "public class DeepThought" <--- How do you test that?
You COULD shoot the guy who wrote it, but don't do that.
Very good use of humor, engaged the audience.

- The lunch keynote was Neal Ford. Neil Ford is an amazing speaker. What’s cool about him is that every time I see him speaker, I wonder how he could get any better. And then he does. Today’s talk was about complexity. One of the core concepts that he talked about is the idea of Language Lockdown. It’s when language writers put in features to protect people from themselves and cut down on the stupid things that you can do. The idea is that if you do that the lower end (read cheaper) developers will still be productive. “What they are trying to do is strap a rocket to the ass of a turtle. What they are actually doing is putting chains on the rabbits than can go fast.”
The problem with that take though is two fold. First, it is not a linear line between the top developers and the lower end developers. What that means is that on the curve, a highly productive programmer will get done in one day what it will take an average developer more than a week to do and the weak developer a month or more. To point out the second issue, Neal quoted one of my other favorite speaker - “Bad developers will move heaven and earth to do the wrong thing” - Glenn Vanderburgh
One of the huge questions that he put out there is “How much of your enterprise software simple services accidental complexity?”. It’s a great question.
As he was wrapping up, he left us with the thought that “Courage is contagious. Cowardice is infectious”.

- Following Neal was Stuart Halloway again. He was talking this time about how one can fail with 100% test coverage. It’s an interesting topic because for so many people, 100% test coverage is the holy grail that they shoot for. The first thing that he pointed out is that you might cover all the lines, but not all the branches so it depends on how you measure things to get to 100% coverage. The second thing that he points out is that you can cover all the code, but not all the corner cases. The example that he used is testing if a value is above or below $25.00 but forgetting $25.00 even. Oops. Then you can start writing way too much code and too much complexity into your tests. Now you need to test your tests and you’ve taken too much time writing them. Then he talked about the “ugly mirror” where the test is really a mirror of the code where you’re covering the line but using the code that you are trying to test while testing – oh dear I have a headache. This is where he says that you are allowed to write literals in your tests.
Neal Ford piped in - “It’s ok for your test to be moist, not drenched”.
The next topic was slow tests and how dangerous they are. The short version of the issue is that if the unit tests don’t run in under 1 second, developers are not going to run them. Functional tests should run in under 2 minutes. If they don’t, then factor them so that they run on different schedules, parallelize them on different machines to get the normal check-in process back under the 2 minute mark if possible.
The last type of fail that he talked about is shallow tests. The quote that he referenced is “No automated test suite can ever replace exploratory testing.” - Jay Fields. The goal is that once the unit and functional testing passes, that people will put themselves in the clients seat and go spelunking and try out a bunch of stuff.

- The next talk was a very unique idea called “Dialogue Concerning the Two Chief Modeling Systems”. They wrote a play! The guys from EdgeCase, Joe O’Brien, Jim Weirich and Chris Nelson, acted out a normal project for them. They started out on twitter talking about the new project that they just landed. Then they actually started with the early on meetings that they have. Joe played the cowboy dev lead who insists that it’s a “simple rails app” and decides to do a data first model. Chris played clueless nub and Jim played the seasoned architect that was concerned about requirements analysis, separation of layers and behavior driven models. Joe, ready to start slamming code out, starts pairing with Chris. The first thing that they tackle is a simple calendar event. Then they have to schedule reoccuring events. Joe, the cowboy, just decides to replicate the events in order to do the reoccurence. The next requirement is rescheduling the reoccuring meetings.... Oops. They have neatly coded themselves into a corner and start hacking out a solution. At that point, Chris decided to take a walk and went to see what Jim thought of it all. Jim started writing out CRC cards and started thinking about higher level ideas, bringing in light-weight design patterns around temporal expressions from Martin Fowler and so on. Jim, the architect, is blithely ignoring “implementation details” such as where to store the data and performance. When performance sucked – they went back to the drawing board. Jim and Joe had to eventually come together. Of course the answer was to write a DSL... :)
Great talk. The good news is that Neal Ford is following them so there won’t be a let down as we end the day...

- The last talk of the day was Neal Ford talking about Design Patterns in Ruby. One of the things that he pointed out fairly early on is that the Design Patterns book, even according to one of the authors ( Vlissides), should have been called “Making C++ Suck Less”. Even the Smalltalk that’s in the book was really C++ written in Smalltalk syntax. He covered a number of different patterns including the Iterator and the Interpretor pattern. There were a number of circumstances where he pointed out that the issues addressed by the pattern were addressed by the Ruby language. For example, the interpretor pattern’s intent is really addressed by DLSs which are dead easy to implement in Ruby. The only problem with this session is that it’s at the end of the day and my brain is a little mush at this point.

Dan Pritchett on Availability

Michael Nygard — Sun, 17 Aug 2008 11:00:01 CDT

Dan Pritchett is a man after my own heart. His latest post talks about the path to availability enlightenment. The obvious path--reliable components and vendor-supported commercial software--leads only to tears.

You can begin on the path to enlightenment when you set aside dreams of perfect software running on perfect hardware, talking over perfect networks. Instead, embrace the reality of fallible components. Don't design around them, design for them.

How do you design for failure-prone components? That's what most of Release It! is all about.

Storytelling

Alex Miller — Sun, 17 Aug 2008 08:00:02 CDT

I’ve been taking a lot of walks lately and listening to podcasts, and I’ve become kind of addicted to podcasts oriented around story-telling. Perhaps the best is This American Life with Ira Glass. This NPR series every week takes a theme and tells a series of stories around it. They do an amazing job of putting together a riveting show every week. You can subscribe on iTunes but to reduce bandwidth they only provide the most recent episode.

Last week’s episode “Fear of Sleep” featured a number of good stories, but the one that stood out for me was Mike Birbiglia’s stories about him acting out his dreams. For one, it’s really funny, as only extended personal stories can be. For another, the presentation is just pitch-perfect - the pauses, the word choice, the pacing, etc. Of course, the comedian background should make this no surprise.

Of course, Mike’s performance was actually taken from a show at The Moth, which I’ve never heard of before. Apparently, they do storytelling shows in both New York and LA. Even better, they have a podcast. :) So, now I’ve been working my way through their podcast and enjoying it immensely.

Anyone else have any favorite story podcasts to share?