Verbum sapienti satis est.
Wow, am I delinquent on these things. I’m not even sure how many books have elapsed since my last post but I’ll try to highlight the major milestones:
What I Have Read:
Windows Presentation Foundation Unleashed
This for me is THE definitive starter book for Windows Presentation Foundation. I can’t sing praises for it enough but in summary, IMHO, no one who did not write WPF itself should be writing WPF applications without having read this book.
For anyone coming from a primarily Windows Forms (and before that Visual Basic Forms) background (like me) WPF represents a massive paradigm shift from traditional GUI programming. The API is in many places convoluted or foreign to "the way we’ve always done it" and that alone can dissuade all but the edgiest of us from the daunting task of adopting this flamboyant technology. This book systematically walks the reader through 95% of the questions and obstacles between fluency in WPF and sulking away in shame back to lesser platforms.
Further enumeration could only dilute the poignancy of my recommendation to get this book. Also, I read this book many months ago and can’t remember the details I had in mind for this post at the time so you’ll just have to take my word for it GET THIS BOOK!
The Keys to the Kingdom Series by Garth Nix – Mister Monday, Grim Tuesday, Drowned Wednesday, Sir Thursday, Lady Friday
Son of A Witch by Gregory Maguire
StarCraft: The Dark Templar Saga â€“ Shadow Hunters by Christie Golden.
What I Tried to Read:
Software Estimation: Demystifying the Black Art by Steve McConnell
As a Solution Architect here at Catalyst I’m involved in the entire project life cycle from sales to deployment and estimation is a key activity I participate in. Reading this book was me sharpening that particular saw in my toolbox. I’m pretty far into the book but not unlike some previous books I’ve mentioned, reading this book was like eating shredded wheat – good for you but not very tasty. I had to put that down and sojourn in fiction for a while just to get the taste out of my mouth. I imagine I’ll finish it some day.
What I Am Reading:
Code Complete: A Practical Handbook of Software Construction – 2nd Edition by Steve McConnell
That’s right – I couldn’t make it through Software Estimation so I ran away to another Steve McConnell classic. This one is on a subject nearer and dearer to my heart though – software construction. This book isn’t shredded wheat. It’s not the most exciting read ever but I can make a good pace through it. This book and its author are both names that seem to be referenced a lot by other good books so I thought it only proper to give it a once over. So far it hasn’t offered many brand new ideas (nor should it for someone in my position) but it has re-enforced some of my own practices and given me some subtle nuggets of wisdom I’d overlooked in the past.
What I Will Read:
The Software Architect’s Profession: An Introduction by Marc Sewell and Laura Sewell
I’ve read a number of books on software architecture but never one about the software architect specifically. I’m curious to read what this book has to say about the role beyond design patterns and the like.
Superior Saturday by Garth Nix
As promised I finished â€śAbout Faceâ€ť sometime around the turn of the month. In desperation I grabbed â€śThe Pragmatic Programmer: From Journeyman to Masterâ€ť by Andrew Hunt and David Thomas soon thereafter and fortunately so; that very evening my commute home (and my commute the following morning to work) was delayed when my bus broke down on the expressway. Iâ€™ll spare you the Chicagoan sentiment for the Chicago Transit Authority. Also as foretold Iâ€™ve been reading this book in parallel with a fiction work in the StarCraft universe, alternating daily. Iâ€™ve already finished both Gabriel Mestaâ€™s â€śShadow of the Xelâ€™Nagaâ€ť and Christie Golden â€śStarCraft: The Dark Templar Saga: Firstbornâ€ť.
This will not go down as one of my all time favorite books. Itâ€™s shredded wheat; the advice is mostly sound but it just hasnâ€™t taken my attention and run way with it the way previous books have. Iâ€™m about two-thirds of the way through it. I agree with a lot of what it says but Iâ€™m neither dragging my feet nor racing to its end. The book comes from an older and broader experience than the Microsoft .NET sphere and shows strong ties to the Java/*nix community. It has though made me realize some of the severe limitations in some of the text editors I use and caused me to rethink how I view duplication. It makes a real good case for not just avoiding code duplication but (where possible) duplication of knowledge â€“ so DRY (Donâ€™t Repeat Yourself) includes documentation and database schemas, etc.
What? You didnâ€™t think I was going to read a book and not talk about it just because itâ€™s not technical did you? Itâ€™s an ok first stab at a StarCraft book. The author understandably falls into the habit (particularly in the early chapters) of making declarations about the SC races and characters just for the sake of saying â€śHey, this is StarCraft!â€ť For a true fan theyâ€™re adorably transparent but clearly intended to benefit SC laypersons. This might also be an artifact of the main character being from a backwater planet far removed from the events of the game and requiring a lot of exposition. The plot is ok. The good thing about it is it sets up for Firstborn pretty well.
OMG â€“ Finally a book about the Protoss â€“ technically the main character of the book is a Terran male and it takes place entirely in Terran Dominion space but delves pretty deeply into Protoss history by way of this Terranâ€™s â€¦ forced psychic symbiote â€“ a Protoss â€śPreserverâ€ť that holds the collective memory of her entire race. This book is definitely better written (IMHO) than Xelâ€™Naga in that it really draws you into the SC universe without making obvious its attempts to do so â€“ but that may just be because the main characters arenâ€™t as naĂŻve about the military and the three races as in â€śXelâ€™Nagaâ€ť.
Since I will be finishing â€śThe Pragmatic Programmerâ€ť soon Iâ€™m still on the lookout for a quality WPF book. Also Iâ€™ve already started â€śStarCraft: The Dark Templar Saga â€“ Shadow Huntersâ€ť. More on that as it comes. Until next time happy reading!
Wow, it’s been a while since I’ve posted here – my deepest apologies. I usually try to aggregate all the things I want to talk about into one blog post but that tight coupling has delayed some topics that otherwise needn’t be. Therefore to keep you all current with all the bound processed tree carcass (some people call them “books”) I’m using to get me through my morning/evening commute I’m decoupling my book-related post from my normal rants about programming philosophy.
In my last post I mentioned that Iâ€™d just started â€śPatterns of Enterprise Application Architectureâ€ť and planned to read â€śRefactoringâ€ť after that. I have since read them both and at least 1.5 others. I’d actually started my next post when I finished Patterns but due to the aforementioned coupling it never saw the light of day.
After Refactoring I decided to finish another book that I’d skimmed “The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity” by Alan Cooper. The book makes a lot of good points about the fundamental disconnect between the mental models of the end users and software developers (I know Iâ€™ve been guilty of projecting my own level of comfort unto my users). The book makes a strong case for the need of â€śInteraction Designersâ€ť and â€śGoal-Directed Designâ€ť. So much so that after finishing it I went and grabbed a copy of â€śAbout Face 3: The Essentials of Interaction Designâ€ť by Alan Cooper et al. While Iâ€™m still reconciling some of the principles of Goal-Directed Design with Domain-Driven Design (and Test-Driven Development, Object-Oriented Programming, Service-Oriented Architecture, and several other acronyms) About Face reinforces the arguments made by Inmates and really brings to light some of the dunderheaded user interaction decisions we programmers can make. Iâ€™m on page 439 of 567 and should finish the book by the end of this month.
On a related note while trying to internalize the principles of interaction design laid out in the later part of About Face (the first part deals with the GDD process) Iâ€™m becoming more excited about the opportunities WPF has for revolutionizing the way we write user interfaces beyond simply making buttons with buttons inside of them or animated gradients. Iâ€™m actually getting pretty good at making really bad WinForms UI in WPF now â€“ I can throw together in an hour what would have taken me half the time in WinForms and looked twice a good. As I get more into it Iâ€™ll be sure to share my experiences.
Also, conveniently in conjunction with the release of the ASP.NET 3.5 Extensions Preview, and a particularly nasty WinForms UI migration project I think Model-View-Controller is finally starting to click for me. Now there are thousands of articles online about MVC â€“ sadly the vast majority of them are about web applications or Smalltalk. The pattern is mentioned in several books Iâ€™ve mentioned here but every description I read about it is different, shallow, and usually leaves me no clearer than before. For this reason MVC has long been listed as my #1 most irritating and arcane software pattern. Fortunately a recent lecture at the Chicago .NET User Group shed a little light on Microsoftâ€™s ASP.NET implementation (which doesnâ€™t thrill me that much) which serendipitously clicked something into place for me as a WinForms dev â€“ â€śThe Controller is Invoked Firstâ€ť. This re-orientation solidified some things for me. Talking about separating domain logic from presentation logic isnâ€™t anything brand new to me so articles which present MVC that way always miss the mark for me. In fact a co-worker has failed on several occasions to see the distinction between some MVC models and â€śData Bindingâ€ť understandably.
I only had this epiphany around 4pm on Friday and Iâ€™ve been occupied since then assembling furniture for my apartment so sadly no code to show today. But as I play with whatâ€™s spinning around in my head Iâ€™ll be sure to share. In the mean time Iâ€™m watching the â€śArchitecture of Modern Desktop Applications in .NETâ€ť webcast series by Professor Joe Hummel. This isnâ€™t Prof. Hummelâ€™s first series with MSDN and I found his VB series invaluable when I was first transitioning to VB.NET from VB6. This webcast certainly touches on MVC and specifically the application of MVC to desktop/WinForms/Smart Client applications. I recommend his series highly.
As for the book club â€“ Iâ€™m not really sure what Iâ€™ll be reading next. I think itâ€™s time I picked up a good book on WPF and really got my hands dirty. It presents a significant learning curve but Iâ€™ve heard only positive comments about it from people who â€śhave made the transitionâ€ť. I know it sounds like a cult but from what I know now about user interfaces, and user interaction principles I can see a lot of potential in WPF. Windows Forms is a great and productive platform but it pushes a certain style of UI development and leaves you dangling for some of the less generic and more controlled scenarios whereas WPF seems to have a lot of hooks for some very advanced styles of programming. Regardless, if I do read a book on WPF it will have to be in parallel with a non-techie book; in anticipation of StarCraft 2 Iâ€™ll be reading â€śStarCraft: The Dark Templar Saga: Firstbornâ€ť by Christie Golden. Word on the street is that this trilogy sets up a number of important plot points for the final StarCraft 2 campaign and as a total SC junkie Iâ€™m compelled to read this.
Anthony D. Green
Recently Iâ€™ve taken to reading books on software patterns. A few months ago I started the legendary â€śDesign Patternsâ€ť aka â€śGang of Fourâ€ť. This is a classic and I highly recommend it. The book however discusses patterns in a very generic technical context and at that time I needed a book more about domain layer design so I took a break and picked up â€śDomain-Driven Designâ€ť which I also highly recommend. I finished that book a few weeks back and it shed a lot of light on some of the philosophical qualms I was battling at the time. I have since concluded my reading of Gang of Four and it was certainly worth it.
Working on the .NET platform, reading books from the C++/Smalltalk/Java dominated time period is amusing in that often such books emphasize some patterns which we take for granted in .NET because the infrastructure supports and encourages them so transparently. As an example, the Observer pattern (GoF) has been really simplified with .NET delegates and events, and the Mediator pattern (GoF) is almost a given in WinForms development. In some cases the CLR allows a more flexible and elegant implementation and this is true on other platforms where different constructs are given first-class status. In other cases itâ€™s just cool to see how patterns are simply manifested in the framework e.g. Iterator (GoF) -> IEnumerable.
There was, however, one pattern which Iâ€™d been â€śwaiting to readâ€ť since I set out that really ended up saving me on a technical challenge. Books like these on patterns are not necessarily required to be read sequentially but I like to get a thorough exposure to them so I donâ€™t typically skip ahead. Comically this pattern was the very last one in the book: The Visitor pattern.
The Visitor pattern takes the common orientation of polymorphism and turns it on its side. For example letâ€™s talk about persisting objects to some durable storage.
One approach to this is to give responsibility to domain objects for persisting themselves. Your domain base class will declare operations for Saving and Deleting instances from a persistent store and each subclass, having intimate knowledge of its own persistence needs and the database schema can override these to work correctly so that clients neednâ€™t concern themselves with the concrete type of the object being persisted. This is both simple and effective.
I used to default to this methodology myself. Then our Chief Solutions Architect, Micah Swigert, turned me on to the idea of externalizing persistence from domain objects entirely. This opens up interesting possibilities and solves particular problems â€“ e.g. multiple persistence mechanisms and stores can be supported without having to modify objects to support them. However, it reintroduces the problem of a persistence service being able to persist an object correctly based on its concrete type. I became aware of this issue when a co-worker encountered a bug in an application wherein a list of objects was being deleted from the database by a parent object. These objects actually came in two varieties, one of which had its own child objects which in turn needed to be deleted. The code wasnâ€™t taking advantage of polymorphism and as such was littered with If TypeOf item Is â€¦ Then blocks to ensure proper handling. This was being applied on Saving but not Deleting and Foreign Key violations were popping up all over. I argued that these blocks should be refactored immediately and that objects should know how to delete themselves and where applicable their child objects without such type checking by client code (even if that client is a parent object). The refactoring cleared up the problem and the code. But it was only possible because responsibility for persistence was assigned to the objects themselves so how, I asked, would I have resolved this issue in my own style of design whereby objects and object graphs are persisted by external services without resorting to type checking?
Enter the Visitor Pattern. The structure of the pattern as described in Gang of Four is to define a base Visitor interface with one method for acting on each concrete type to be â€śvisitedâ€ť. I know this is a contrived example but it has to be to be simple. Visitor is actually a pattern I think is rarely needed, usually in a non-trivial system, but when needed can be a powerful tool.
Sub VisitSimpleOrder(order As SimpleOrder)
Sub VisitMultilineOrder(order As MultilineOrder)
Each class then has an Accept method which takes a visitor instance and calls the method pertaining to its own type on the visitor thus facilitating the correct behavior for the objectâ€™s concrete type to be invoked without putting this behavior inside the objects themselves.
MustInherit Class Order
MustOverride Sub Accept(visitor As OrderVisitor)
Class SimpleOrder : Inherits Order
Overrides Sub Accept(visitor As OrderVisitor)
Class MultilineOrder : Inherits Order
Overrides Sub Accept(visitor As OrderVisitor)
With such an implementation you could declare a DeletingVisitor which calls the proper Stored Procedure(s) to delete objects or a SavingVisitor which knows to save MultilineOrdersâ€™ child LineItems correctly based on its type, without using If TypeOf â€¦ ElseIf TypeOf trees. This is especially important if youâ€™re using the any of the Table Inheritance patterns.
Some advantages to this are that you can add new operations without defining a new MustOverride method in your base classes, which would break every concrete object; and that all of the logic for an operation is now centralized in the concrete visitor, not littered about all of the concrete classes which must be supported. The disadvantage to this pattern is that in order to support a new concrete class to be visited you must add a new MustOverride method to your visitor base class which will break every existing concrete visitor. As such itâ€™s a good pattern when you want the flexibility to support new operations on a stable hierarchy.
In my case this is just the tradeoff I want. My system must be able to persist all known objects and I could potentially add different persistent stores: Relational Database, XML, serialization over the wire, etc.
This being .NET of course, there are some revisions to this implementation Iâ€™m looking at. For example, to get rid of this monolithic interface declaring all supported types:
Sub Visit(obj As Object)
Interface IVisitor(Of T) : Inherits IVisitor
Sub Visit(obj As T)
Sub Accept(visitor As IVisitor)
This allows me to reuse my visitor interface generically across object hierarchies. A visitor will implement the generic IVisitor interface for all supported types. Potentially dangerous is when adding a new supported type existing visitors wonâ€™t break at compile time (enter automated testing). Iâ€™ve included in the base IVisitor definition an object based method to catch unsupported objects to allow a fallback mechanism, logging, or maybe even just throwing an exception. Another implementational question is how overriding is handled â€“ if a visitor doesnâ€™t explicitly support a concrete type should it failover to its parent type â€¦ all the way to Object? Or should it just break? The former can result in loss of data but may be desirable in some scenarios.
Be on the lookout for more of these pattern posts. Iâ€™ve just started â€śPatterns of Enterprise Application Architectureâ€ť and it looks good. And Iâ€™ve already enqueued â€śRefactoringâ€ť after that. Cheers!
Until recently I’ve been so awe-struck by the massive changes presented by .NET 3.x that Iâ€™ve avoided in-depth research into its bounty. Windows Presentation Foundation is a major paradigm shift that, frankly, intimidates me. But lately Iâ€™ve been digging in around the edges trying to understand what these changes could mean for the future of .NET solution designs.
I finally caved and got myself a copy of VS2008 Beta 2 and am really excited about it. Particularly, Iâ€™ve gotten to play with cool new language features in Visual Basic 9.0. Now, Iâ€™d move to VB9 for local type inference and object initializers alone but this weekend another feature piqued my interest: XML Literals.
In VB9 you can declare XML fragments and document inline in code like so:
Dim telephone = _
You can access nodes in the fragment using a likewise intuitive syntax:
If telephone.<areaCode>.Value = â€ś800â€ť Then
... 'Something about toll-free calls.
As anyone whoâ€™s ever worked with the XmlReader/XmlWriter can tell you this is a vast improvement.
So I got to thinking – VB9 can quickly declare XML literalsâ€¦ XAML (the markup language behind WPF and Workflow Foundation) is XMLâ€¦
Putting 2 and 2 together I whipped up this little proof of concept application.
1. Open VS2008 and create a new WPF Application.
2. Change the default child node of the Window1 thatâ€™s generated from a Grid to a Canvas and set its name to â€śrootâ€ť as below:
<Window x:Class="Window1" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="Window1" Height="300" Width="300">
3. Now open your code-behind file and paste over it with the code below:
Private Sub Window1_Loaded(sender As Object, e As RoutedEventArgs) Handles Me.Loaded
Dim data = From m In GetType(String).GetMethods() Where Not m.IsSpecialName Group By Name = m.Name Into Methods = Group, Count() Order By Name
Dim presentation = _
<%= From g In data Select _
<TreeViewItem Header=<%= g.Name & "() Method" & If(g.Count > 1, " - " & g.Count & " Overloads", String.Empty) %>>
<%= From m In g.Methods Select _
<TreeViewItem Header=<%= m.Name & "() : " & m.ReturnType.Name %> Background=<%= If(m.IsStatic, "Gray", "Black") %>>
<%= From p In m.GetParameters() Select _
<TreeViewItem Header=<%= p.Name & " : " & p.ParameterType.Name %>/> %>
4. Hit F5 to run your project and you should see output like following:
In the end this really brings some of the expressiveness of ASP.NET to the WPF world. Looking at the declarative opportunities XAML opens up in WPF, WF, and even custom .NET objects â€“ What are some cool things you can do with this? Please share your ideas.