Rants, rambles, news and notes from another geek

Visited States

I remember doing this once a few years ago…

I should dig that old one up and see if it is different…

[via Brad Wilson]

Visual Studio Code Name "Orcas" October 2006 CTP

Hightlights of this CTP:

  • ADO.NET 3.0 Advancements
  • LINQ over XML (XLinq)
  • Multi-targeting
  • Improved 64bit application working set
  • Lightweight reader/writer lock with deadlock-free upgrade support.
  • A high performance trace listener which logs XML to disk in the event schema.
  • Getting VSTO and/or controls off machine policy/legacy policy migration
  • Security Platform Parity - Suite B support: AES
  • A new date time data structure that can specify an exact point in time relative to the UTC time zone.
  • New IO types that expose almost all pipe functionality provided by Windows.
  • A new high performance set collection.

Many congrats to the team. You can download it from MSDN: http://www.microsoft.com/downloads/details.aspx?FamilyId=C09B5A2D-EB6A-44B6-8BBD-3764A2FDA9CE&displaylang=en


TestDriven.NET 2.0 Has Shipped!

Wow. After years of work and headaches, my good friend Jamie Casdale has just announced the version 2.0 RTM version of TestDriven.NET.

It has always had a great feature set:

  • Right-click and run the tests found in classes, fixtures, projects, solutions, etc.
  • Run in the debugger
  • Run w/ external runner
  • Test failures go to Output window and Task list
  • Double click on test failure and go straight to the failing test code
  • Configurable key bindings for even easier running of tests

And now adds some very cool new things:

  • Code coverage - NCover + Team Coverage
  • Reflector support - ‘Go To Reflector’ functionality available on the Code, Disassembly, Call Stack, Modules, Project References and Solution Explorer windows.
  • Repeat Test Run - Redo whatever test-run you did last

But I can’t really do it justice, so check out Jamie’s post. It has better descriptions, screenshots, and more.

Go get it! Come on… you know you want it.

Code Camp 2.0 Talk: How I Pwn3d the World of Warcraft UI With Lua

Today Brad Wilson and I presented this talk at Seattle Code Camp 2.0. Here is the session description for those of you who didn’t make it:

World of Warcraft is arguably the most successful massively multiplayer game in history. Millions of players from hundreds of countries all playing together to kill monsters and each other. What could be more fun? Well, for many geeks one thing that is more fun is taking advantage of the very extensible nature of the user-interface by writing addons and extensions in a programming language called Lua. Join Brad and Peter for this fun session where you will learn how to bend the WoW UI to your will. (We promise to leave some time at the end for a little game-time demos and Q&A.)

As promised, here are a number of links to the information we discussed today. I hope you enjoyed the talk as much as we enjoyed giving it.

Lua Information

World of Warcraft API Information

WowAce Libraries Information

MadLibs for Agile Principles

J.D. Meier, one of our PM/Architects, recently emailed around this questionnaire and I just noticed that he blogged it too. I originally replied via email, but decided that since he blogged it, I can too.

My answers are bold and underlined but the rest of this is from his email to me. (See J.D.’s blog post&nbsp_place_holder;for his blogged version which is slightly different):

MadLibs can be an interesting approach to capturing or identifying principles, practices, values … etc.

Here’s an example attempting to encapsulate principles of agile development:

  • Write code to pass tests over _writing code that you don├óΓé¼Γäót yet need. _
  • Measure progress by working software over measuring against a stale project plan.
  • Improve internal consistency and clarity of code through re-factoring over locking in the design before you know what you need.
  • Build releasable software in short time periods over shipping software too slowly to be relevant to the customer.
  • Close cooperation between the business and developers over eliminating conversations between those who know what they need and those who are able to provide it.
  • Respond to changing and emerging requirements over building what you thought you needed before you started.

Of course, you can also leave off the front and contrast with the behavior you’d like to change

  • Evolutionary and emergent discovery of requirements and designs over document-centric practices.

I wonder how others would answer these… or what other sentences you might want to say instead?

Mmmm... Deep Fried Bacon

via The Traveling Grammy & Bompie Road Show:

What you can fry just depends on the size of the fryer or the limits of your imagination. Grease alone does not a feast make, it takes a good batter to top off the death-by-eating endeavor.

Here’s a little video on a place in Snook, Texas that fries bacon, dipped in batter and served with a side of cream gravy to dip it in because bacon + grease + batter just doesn’t have enough fat or calories.

Check out the big bellies on the owner and a couple of the customers. The owner looks like the live model for the fat human cross-section my doctor has in her examining room to show you what all your yellow and brown fat looks like under your skin. I hope this cafe has some of those easy-to-use heart attack paddles.

Oh, what do you call a person from Snook? Why Snookums, of course.

Oh dude… I totally want some Chicken Fried Bacon for lunch… or breakfast… or dinner… or brunch…

Seattle CodeCamp 2.0 This Weekend

If you are going to be in or near Redmond this weekend, I suggest you check out the Seattle CodeCamp that will be going on.

One important change that I just found out about: the venue has changed!!

IMPORTANT – Venue Change!
10/24/2006 5:00:00 PM
Due to an unexpected turn of events, the location for Seattle Code Camp v2.0 has changed. We are now holding Code Camp at the DigiPen Institute of Technology, which is located at:

5001 NE 150th Ave
Redmond, WA 98052 [map]

A huge thank you to the folks at DigiPen for opening up their doors to us on such short notice. See you at Camp in Redmond!

I think this is across the highway from Microsoft, halfway between main campus and “Red-West” on 50th.

Also, the schedule/agenda has been posted.

Hope to see you there!

Specifications Are Like Object-Oriented Messages

I don’t remember when I first came up with this metaphor, but I’ve used it with a few people over the last couple of months and it seems hold water.

Specifications are big in software development. Requirements specifications, design specifications, message specifications, protocol specifications, etc. They are everywhere. But when you start to explore the various agile development methodologies, you will find many people claiming that specs are dead.

I’m not so sure. In fact, I disagree. Specs are alive and well. They never went away. But something is certainly different.

Before I go there, however, let me bring you back to the 1970s and 80s and the invention of Smalltalk and other message passing languages. The idea was that object oriented systems weren’t about functions but were instead about messages. You send a message to an object and it might give you an answer.

We now often find ourselves calling these things methods instead of messages, but ultimately they are the same thing. You send a message (call a method) on a C# or Java object and you get an answer. Interestingly, this is one of the reasons that (right or wrong) we can easily map web-service operations onto modern object-oriented implementations. Service becomes object and operation+message becomes method+parameters. What could be clearer?

(Please don’t get all carried away attacking that part, I’ve been a WSDL first guy for years–search my 2003 archives if you don’t believe me. I’m trying to make another point here.)

An interesting thing about a difference between web services and object oriented programming is the “chunkiness” of the information being passed. Well-designed web services typically use very chunky method calls with very little (ideally no) state expected to be maintained between calls. You fire in all the information that the service could possibly need and you get back your answer.

Interestingly, the dominant thinkers in the object-oriented space have been reaching a conclusion that is in the other direction. Smaller, simpler objects that do less with each call. Pass&nbsp_place_holder;less information, but make a lot more calls and use a lot more objects. You may have heard this called “lots of little objects”. You may not agree with it from a pragmatic standpoint, but it certainly does lead to highly cohesive (single minded) objects that can be well tested and can be easily combined together in new and exciting ways.

At the one end we have web services which use chunky protocols and are not very nearby (typically on a server somewhere out there on a LAN or WAN). On the other hand we have in-process objects that are really nearby (just a pointer reference away) with whom we communicate quickly and easily in a chatty rapid fire way.

At this point I can hear you asking, “Peter, what the hell are you talking about? I thought this was about Specifications?”

I’m coming to that.

One thing that used to attract a lot of developers to Extreme Programming (XP) was the myth about “no documentation”. Yes, I said myth because it is patently untrue. There is lots and lots of documentation on an XP project. It just doesn’t take the same form as people were used to on a plan-driven or waterfall project.

Remember that one of the core principles of XP is the idea that the team should be physically co-located. All in the same room if you can swing it. By being all together in the same space, they can spin off design discussions whenever they need to happen. They have index cards on the wall to track features and requirements. There are lots of whiteboards around with architecture diagrams, meeting notes and every other bit of information relevant to the team. It is a chatty environment.

But when you are working with a team that is offshore, you have to do things a bit differently (even when you are doing agile development). You don’t have the whole team together all the time. Your offshore team members&nbsp_place_holder;can’t swing your chair around and chat with the guy next to them. They can’t look at the whiteboard with the most recent architectural sketch. They need to have more information passed to them in larger chunks.

Ultimately the reasons for the communication styles used between these people are the same as those used with web services and object oriented programming. Communication is about messages. The closer together the two parties are, the richer their discussion can be. The more frequently they can talk. The easier it is for one to ask a question. But as the distance between the two parties increases, the more you have to change the way the dialogue occurs.

Move team members out of the office and you have to write a bit more of a spec for them to make sure they know what to do. Move them to another building and the spec has to get richer and more complete. Move them across the country… or around the world… and the spec had to get even more precise.

Jedidja Bourgeois Lives!

My good friend Jedidja (pronounces zhe-dee-zha -&nbsp_place_holder;but we call him&nbsp_place_holder;Casper) from our Ireland sub has finally started blogging. He is an up-and-coming agile evangelist and all-around good guy.

He has just started his blog over on MSDN blogs: http://blogs.msdn.com/agilemonkey/

His introductory post is up and hopefully some interesting content is on the way.


Recommended Reading List

Lately I’ve given a number of talks at conferences, user groups and around Microsoft and I always end up mentioning a lot of my favorite books. I’ve also been doing some hiring for patterns & practices and&nbsp_place_holder;candidates always ask what books I would recommend they read.

So, as promised, here’s the list…

Agile Software Development

Test-driven Development, Unit Testing&nbsp_place_holder;& Refactoring

Architecture, Design and Patterns

.NET, C# and Related Topics

**&nbsp_place_holder;If I could only have 16 books about software development on my bookshelf, that is my list.