Tech Blog

Jay's Technical blog

A Night Of Ajax In Ohio (Akron-Cleveland Area) In October

24 August 2007
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

Dave Balzer (of DevAuthority fame) and I have been talking about my trips to Ohio once a month, and how I have been itching to speak (and would really love to speak in the State of my birth). 

We need to plan far in advance so that Dave can get a place lined up.  He (not me) probably should put some kind of sign up form so we know how many to expect. 

Do we have anything together?  Well, actually I do know what I'm going to do my talk on.  I'm going to do a somewhat informal talk which involve my into to MS Ajax, Best Practices with MS Ajax (will also apply to other Ajax libs, BTW), and my alternative to JavaScript (aka my Script#/SilverLight talk).  All in all I figure that I can talk for about 2 hours on the subjects (possibly longer with your questions).

This will all happen mid-month in Ohio.  (to steal a variation on Jeremy's line about the ALT.NET conference). If you line in Ohio and think Ajax sux and especially MS Ajax... or if it's not TDD enough for you, come on in and give me crap.  I tick you off sometime in the past, come meet me, and find out what a jerk I REALLY am <grin />.

Seriously, we'll be digging in to MS Ajax and you should come away with some good tools (knowledge) for assessing Ajax patterns in your development.

BTW, stay tuned to my blog and Dave's...


BDD, Git 'R Done (GRD) Dev, and Testing progress

14 August 2007
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

A few weeks ago I wrote a comment on Scott Bellware's blog that, like a lot of the TDD crowd, I was becoming enamored with BDD.  I think I probably perplexed Scott a bit until he realized that I was leaving out the TDD component which I guess in the truest sense is of the methodology can't really be left out.

Regardless, some of the discussions on this stuff is finally starting to sink in and I can see what I could be testing.  Now before anyone rejoices that you converted the Dev Theologian to TDD; I'm still not doing TDD (nor will what I end up doing be called TDD).  I just finally figured out how to best exploit the Unit testing tools to give me what I've wanted for some time.

You see as a Git 'R Done (GRD) programmer, I care a lot less about having tests for everything.  What I want is to test the "low lying fruit."  I've been struggling for a couple years on how to determine what that is.  I have stated again and again, TDD doesn't provide me enough ROI for me to do it.

So first let me tell you briefly of my journey over the last several months....

The Journey
It all started a couple months ago.  I was going through my yearly "maybe I should do TDD" phase (BTW, this replaced my yearly "I should learn c++" phase), and was reading some stuff on xUnit testing frameworks.  I happen to read Phil Haack's blog and noticed that he had posted some stuff on MBUnit.

If you are a TDDer you are probably well aware of MBUnit.  If not then let me tell you, MBUnit has a number of niceties that make it easier to test certain scenarios.  The one that threw me over the top was Phil's post on the RowTest which is a way to create a parameterized test and provide tabular data for that test (Ok I forget exactly which post it was... it might have been this one as well... or maybe it was this one).

Anyway I now had an Unit Testing framework that didn't look like I was going to be working really hard to use it... now I needed to solve my other problem.  What should I test?  What's the low lying fruit and more importantly can I test something that will benefit me today and tomorrow (in other words I want a notable ROI).

Enter BDD
The BDD guys are really dealing the big questions about TDD.  Let me quote from the NSpec homepage:
"In essence, what Dave is saying is that the test oriented nomenclature gives us too many reasons not to write tests, especially when the pressure is on."

Actually as I re-read the NSpec homepage, Scott B's comments about BDD being coupled to TDD don't seem entirely true.  Especially the comments about 1:1 testing.  The main idea with BDD is that you take scenarios or stories (to use Agile terminology) and create tests out of these scenarios.  In the UML world these would be with use cases (well sort of) that tests get tied to.

Anyway, as I looked at this, I began to see how and what to test at least from a very simplistic manner.  Test the spec and the scenarios that fall out of it; so, don't worry about testing everything.   I have been told by a TDDer a few years ago that one should always test every class and here are a few examples of what to test: class instantiation, test for null against an unistantiated class, and , serialization  (if you need this.. since he was a SOA guy he felt you always needed it).  I won't comment on any of these these examples except to say "ROI??"  It costs almost nothing to do these tests but am I gaining anything by just having tests for the sake of tests?

A GRD Testing Methodology??
So I have been thinking about BDD and how it can be used by a TAD (Test After Development) developer.  What I want is to be able to test something and know that the client is going to say "hey that pretty much does what I expect it should." Using a BDD like approach to unit testing will give me that.  I can test the spec based on my understanding.  If I use the scripts that BDD provides I can know that I pretty much understand the spec.  With this info it should be easy to come up with tests that take care of my low lying fruit.

I would love to layout a full blown GRD Testing methodology.  Unfortunately I am blazing away at new ground for myself (and honestly I'm not that smart).  I've made quite a bit of use of MBUnit in the last couple weeks, and am getting the hang of it (it's quickly becoming a tool in my debugging arsenal).  I'll try to put up some posts as I gain experience so we can explore what this means to a GRD programmer (but again, I'm not that smart).

Don't worry I'm not going all ALT.NET on you.  Nor am I going all TDD on you either.  So if you hate my methodology ideas, you probably still will.  If you like my ideas then you probably will see some logic in where I'm going.

Do yourself a favor, go read up on BDD.  You'll find some stuff there that is thoroughly useful no matter what camp you fall into. 

[tags: BDD, Git 'R Done Programming, GRD, ALT Testing]


Future Silverlight 1.1 Frameworks...

04 August 2007
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

I've been in a fairly interesting discussion in email with Justin-Josef Angel.  I won't get into the full content of the email for now.  But we were discussing the merits of Silverlight (SL) 1.1, and I mentioned something that I have been thinking about for a bit.

I decided it's a theoretical piece of info that I want to share with the world and maybe someone will build it for me (and for all of us). 

One of the things I see with SL 1.1 is that we are going to see some really interesting framework grow up around it.  The one that rolls immediately off the top of my head is an MVC or MVP framework. Now I know I have been critical of the values of these for a lot of reasons that I won't go into, but I do see value in this for SL. 

It could  be implemented in a number of ways.  For instance, you could have the controller back at the web server (possibly associated with a WebService, some kind of REST service, or even the code behind of a page... OK, maybe not the code behind), and when interactions take place in the SL it would call back to the server for direction about what to do next.  I know that's not exactly pure MVC, but it would be darn close.

I could also see where the controller is actually a class in the SL app, so the WebService becomes just the data layer to the SL app.

The real point is with even the baby CLR we are getting with SL 1.1, all this stuff should be possible.  The major benefit is that maybe we can escape the leaky abstraction that Ayende wrote about (remember I'm not a TDD guy, but I might become a BDD guy... but that's another story).

[tags:Silverlight 1.1,MVC,MVP,Silverlight frameworks]


Tampa Code Camp &amp;quot;.NET as an Alternative to JS in the Browser&amp;quot; Slides and Demos...

02 August 2007
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

Ok, I'm finally posting my slides and demos from my Silverlight and Script# talk at the Tampa Code Camp this past July. 

Since Silverlight 1.1 Alpha Refresh just came out (and so did VS 2008 Beta 2), I went ahead and updated my Silverlight demos to use latest bits...

[tags: SIlverlight demos, Script# demos, slides]