Tech Blog

Jay's Technical blog

regarding Windows 7

13 January 2009
Jay Kimble

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

I installed the Windows 7 beta 1 the other day on my Mac (and actually now also on my Laptop which had a partition that had been reserved for something else. I’m really not that passionate about new OSes. Brian Peek is way more passionate about this stuff than me.

First of all, if Windows 7 wasn’t beta I would buy enough copies to install it on every machine I own. Seriously. To say I like it doesn’t quite say enough. With Vista I had to be convinced and honestly I ran it initially because it gave me some goodwill in certain circles (Blog Papa you know who you are). It grew on me, and I can say that I like Vista and I do promote to folks, but I warn them that Vista is something that you have to force yourself to use a bit (and you should never upgrade an existing OS… my experience has shown that to be true). With Windows 7 that is not the case.

Right Windows 7 feels like Windows 98 SE felt to me in days gone by. You may have forgotten, but despite the hoopla of Windows 95 there were a lot of compatibility woes that some users were complaining about. Windows 98 introduced a few new features to this core, but was still not incredibly stable. Windows 98 SE was really a Win98 bug fix that ended up being IMNHO the best of Win9x. Windows ME felt more like an OS determined to convince me that I wanted something new -- Windows XP.

Windows 7 has the slick look of Vista without some of the warts that folks have complained about. It’s fast. It feels really stable, and if it were available I would buy it tomorrow. In fact I’m really struggling with just running flat out as my main OS.

My buddies at lunch today asked me what the new features were. I scratched my head and said that it has a slightly new look, some new power management features and…. it’s fast! 

Ok, I do know that one of the techy features is that it has a new core/kernel that is very small… and that MS is planning on stuffing this small core into it’s Windows Mobile OS. It’s also going to be used to power some of the new Atom-powered devices.

How fast? Well I can launch Word and Excel in less than 2 seconds; and also VS.net 2008 also launched in less than 2 seconds… these are of course clean installs and my watch was my stop watch (so not very scientific). I was running a couple additional apps (including Live Writer with this post loaded up).

Anyway, good job Windows team!


TUX: Next Meeting - Wed. Jan 14th 7:00pm

07 January 2009
Jay Kimble

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

If you missed the MSDN Flash (thanks, Joe or whoever got us listed... I forgot to do it), here’s what’s going on.

Shawn Cady will continue his 8 part series on "What is User Experience?" If you missed the first one you will still get something out of this one. (We will be putting that first one online in the future). This was a great presentation and not to be missed. His first one was very informative, fun, and at times veering into some dangerous territory (we talked about UX on certain types of web sites that a polite "G Rated" blog like mine doesn’t talk about... but it was all in a tasteful fashion, so no reason to worry about us).

Jay Kimble (me) will be taking Marc Aniol’s example from last meeting and will simplify the JavaScript code by utilizing the new declarative aspects of the new MS Ajax 4 Preview JS library. For those who don’t know declarative in this case means that we can make for less code by attaching functionality via attributes on the HTML tags.

Everything starts at 7:00pm although Pizza will be there a little earlier. We try to shut things down by 9:00pm.

[Small update: if you need directions, etc, go to the TUX website for those details].


Test Driven Development (TDD) or Behavior Driven Development (BDD)

06 January 2009
Jay Kimble

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

[Sorry it’s been a long day and this is a rather stream of consciousness post... ]

If you have followed my blogging for any length of time you’ve seen me jousting (sometimes shouting) with the Agile crowd of Testing First. Actually I think my complaints have been more in line with some of the nuances of their architectural advice. We won’t get into that arena right now though.

[Digging out my best Katy Perry voice]

So, I tried BDD and I liked it
Yep, you heard me right. Not only that by I fired up moq and mocked/isolated/faked/doubled (pick a word for "fake version of an object") in one of my tests. And, oh yeah, I did it all first. Since you are all in shock, let me throw one more thing out there. I used SpecUnit.Net to do this all. You may not know what the big deal in that is. SpecUnit.Net was written by none other than Scott Bellware (he would be the guy I spent a lot of time shouting at in my blog).

Ok, so now that all the shock has died down, you may be wondering how this all happened. Again, if you’ve been following along, you would see that I have had a serious fascination with BDD. In fact last month I went to a CodeCamp and attended a session by Sean Chambers (session content is mostly presented in this post). It really hit some chords, and I vowed to try it the next easy opportunity I could.

So yesterday after Christmas break, my boss tells me, "I’m changing all your priorities. Here’s your new priority/project." I was then given a spec document with some rules for how the new feature would work (lot’s of use cases). On the spot I saw this as a perfect BDD opportunity. I built a test project/solution, added in all our support DLL projects and began to write Contexts, Observations, and Concerns (all BDD terms). I let the tests lead me and today I needed to test one final thing and realized that I should isolate things so I used moq which caused me to make a few API changes. All in all it was an excellent experience. I ended up with 2 concerns, 46 observations/tests, and 2 Contexts. I used Scott B’s reporting tool and got a couple warnings about my tests that implied that I might have a context hiding there which is probably true.

For the unenlightened, let me try to (poorly) define the terms. Context roughly equates to your setup code for each test; it’s a little more involved than that, but essentially you should have a context where all this runs. Observation is pretty much a test (although they should correlate to your "rules" from the spec document). A Concern is like a way to categorize all this stuff together, it can go beyond a single test class, but the idea is that you probably have say an "Order System"; that would be a concern. The Observations might be "do not ship the product if the customer hasn’t paid (there would be a context of "Customer has Paid" and "Customer has not paid"). Again this is all really , really rough... go to a real BDD gurus site.

So does that mean you’d switched ships, Jay?
Not exactly. I mean at one level it means that I will be developing more code this way whenever I can. I think I’ll always stay my own pragmatic self (which is not to say that Agile guys aren’t pragmatic... I’ve met my share of them now and they aren’t who I’ve been beat up by). I will be adopting some of their practices where it makes sense. I finally got a testing success so who knows where I’m heading.

Advice for the Agile Evangelist
I think you guys need to abandon TDD as a starting point. BDD makes more sense to the average corporate developer. Every project has specs (no matter what you call them). Writing tests using those specs first really makes sense. It’s why I was very interested in this methodology the first time I read about it. The methodology also answers all those newbie questions immediately. Stuff like

- Do I gotta test first? [yep, if you want to make sure your code passes the spec’s rules... it’ll also help you see the edge cases that should have questions raised with the customer/client/business owner]

- What do I test? [You test the spec. First and foremost... I know this skirts into dangerous waters here... but convincing people to test something will lead to more testing if it proves to make code more stable, etc.]

I found it easy to get into the "red, green, refactor" rhythm, and even caught some minor problems along the way. I imagine a newbie would have the same result. Now from here you have a platform to talk about improving someone’s ability to test.

The end-result for my code
Well, time will tell, but my back-end API changes don’t allow the UI to violate any of the rules. It was the type of spec where I have some fields that cannot be changed which has some additional effects on other objects. When a field is read only it CAN’T be written to. The individual properties enforce this functionality. Additionally the other rules were easy to implement. And all this happens outside of the Data Layer and not in the UI Layer (thank heavens!) I know none of this is rocket science, but there are a really large number of places in the UI where these things can be violated (I needed to make sure the Business Objects took care of business).


Client-side Scripting 101 Part 1: The Reasons

02 January 2009
Jay Kimble

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

[Welcome to my multi-part tutorial on. I know I did an introduction earlier in the month, but before we dig in deep into this I thought it would be good to get a few questions out of the way.]

Why is this (Client-side Scripting) all that important to me?
You may be thinking "Hey Jay, my company bought Telerik/Component Arts/Component One/{fill in some other ASP.NET tools suite} and it seems to do everything I need and more. I can see some places where a little client-side code is helpful, but it’s not that important, is it?"

Well, I’m definitely not one to criticize the third party tools vendors, but their tools are just that tools. If your site grows large enough you will run into a place where you need to tweak their tools, and my experience is that all the ones I’ve mentioned have really nice client-side APIs that underlie their server-side components. Stuff that will really let you push the envelope of their tools. But, you probably already know that. The hard part is for all the great things these tools can do, sometimes you need something else (usually a little more light weight). In order to do this you need a background in client-side technologies so that you are able to assess your solutions. 

For instance, in my day job I created an MS Ajax behavior that takes a regular HTML table and adds a selection behavior. We did this to replace the big name grid we are using because, while this grid does amazing things, it also comes with a price of a heavy footprint and a larger than desired viewstate (we’re trying to slim our pages for performance sake). I also have created 2 additional behaviors: one injects client-side paging to a regular HTML table, and the other provides sorting functionality via the column header row. All of these behaviors inherit from a common class that wraps the table. My lightweight behaviors are simple components that can handle up to about 1000 rows which make them really useful for smaller sets of data. I tried them on as many as 5000 rows which gave OK but sluggish performance, and with 10,000 rows was simply unusable (I was using all three components, so it might be possible to use say just the paging and get decent performance).

It comes in handy to be able to build these types of lightweight components (which incidentally only took me about 40 hours to build all 3 which included server-side extenders).

Our first term: Client-side (or Ajax) Behavior
Since I have thrown the term "behavior" out a couple of times, let’s go ahead and define what it is exactly. In the realm of MS Ajax (and other frameworks), a client-side behavior is a client-side component/class that injects functionality into an HTML element. In MS Ajax, it is a separate component that is associated with an HTML element. When activated, it usually sets up UI events (onclick, onfocus, etc.) to intercept some UI interaction and apply new interactions. It can also inject additional css classes/styles or html elements on the page to apply a particular look (which is what the Ajax Control Toolbox’s Drop Shadow and the Rounded Corners behaviors do). It all depends on what the component needs to do. If you have played with any MS Ajax toolbox on the server side, you have probably throw Ajax Extender controls on a form; extenders are a server-side wrapper for the client behaviors. I hope that’s clear. If not fire off some comments to me at the bottom of this post and I’ll try to better explain in the comments (and will update this accordingly).

One of my goals for this blog series is to take you from knowing a little bit about client-scripting (and maybe nothing) to being able to build your own behaviors and extenders.

JavaScript is like a foreign language to me... Why couldn’t this be easier?
This may shock you, but I struggle with it too -- and I’m a(n admittedly) self-proclaimed guru with it. Two weeks ago (I was off last week) I wrote a very simple JavaScript component/class and I forgot something. I set up a timer event and it wasn’t making the call correctly into my class. Eventually I realized that what was happening was that I was calling a method within my JavaScript class and the instance of that class was being lost. I needed to use the MS Ajax "Function.createDelegate" function to get a wrapper function that wouldn’t lose the instance of my class. This is a total pain in the you-know-where. I actually told my boss that this is the exact reason I use Script# since it takes care of this stuff for me.

What the Heck is Script#?
Script# is a life saver! It is the invention of Nikhil Kothari (MS Ajax Architect and SilverLight2 Architect, and he is one of my heroes... I hope I get to meet him at Mix09). What it does is let you write C# code in Visual Studio against a framework (either Nikhil’s or MS Ajax... there are also jQuery extensions and a few others for it as well). This framework has a set of CoreLib replacements (System, etc.) that consist of set of .NET dlls and a set of JS client libraries. When you compile this code, you get a DLL which can be used in other Script# projects (yes, there are VS templates for creating a new Script# project), and  a set of JS files (debug and shrunk runtime versions). Script# makes it easy to create multiple inherited classes (an object tree if you will) as well as it handles things like passing functions around.

So that means I don’t have to know anything about JS right? Cool!
Hang on there! You will need to know a little bit about this stuff as it will help you read the code generated by JS. You can always patch bugs with Script#, but testing will (at this time) always exist in the JS side (in a browser), so you need to know enough to get around the source code that gets generated. The line numbers will always point to a line in the generated JavaScript (for instance), so your going to need to be able to read the JavaScript file and determine where the problems exist (you can still fix the code in your C# code, and can write debug messages that show up in the JavaScript console (or in VS if you are debugging the script running in IE).

So next up will be a column on JS OOP Basics.