# Friday, 25 April 2008
My new book Code Leader: Using People, Tools, and Processes to Build Successful Software is now available and in stock at Amazon and hopefully soon at stores near you.  The initial outline for the book came from a post I did a while back, This I Believe, the developer edition.  Writing up that post got me thinking about a lot of things, and I've continued to expand on them both in the book and in presentations since then. 

There is a lot of content in the book about working with tools like SCC, static analysis, and unit test frameworks to build better software more efficiently.  I think if I were to sum up the focus, it is that we as developers owe it to our project sponsors to work efficiently and effectively, and there are lots of incremental changes that can be made to the way we work, both in terms of tools and processes to make that happen. 

The reality of modern software development (mostly) is that since the physical constraints like CPU time and memory/disk space have largely fallen away, the goal of any development project (from a technical standpoint) should be optimized for developer productivity.  That includes a wide array of factors from readability of design, how clear developer intent is to future readers, and how resillient our software is to future change to reducing barriers to developer productivity like implementing a good CI process.  Working together as a team across disciplinary and physical boundaries is at least as big a challenge as writing good code. 

I agree very much with Scott that the why and how of software development are often just as important (and harder to get right) than just the what.  I hope that I have something to contribute to the discussion as we all figure it out together...

Friday, 25 April 2008 11:31:59 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [2]  | 
# Monday, 21 April 2008

Several people asked me for my slides from my presentation last week, so here they are.  I'm trying to get them posted on the InnoTech site as well.

Monday, 21 April 2008 11:10:56 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 10 April 2008
If you are doing anything even remotely involving Ajax or client side script, and you like Firefox like I like Firefox, go and get a copy of Firebug.  I quite literally don't know what I would do without it.  Firebug provides very comprehensive script debugging, allowing you to set breakpoints in your JavaScript, step through it, etc.  It also shows you all the requests and responses for all your post-backs, and lets you examine HTML, CSS, and script as well as the client side DOM at "run-time".  It's been invaluable in helping me figure out how ASP.NET Ajax is supposed to work and what's wrong with the JavaScript I'm writing (it's been a while). 





Good stuff.

Ajax | ASP.NET | Work
Thursday, 10 April 2008 10:56:03 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

First, there was a few ideas rattling around in my head, then there was a blog post, and now you can buy the book. :-)


The most difficult challenges facing most of us these days are not about making code work.  That's relatively easy, compared to making code that you can work on and maintain with other people.  I've tried to bring together a bunch of issues and practical solutions for writing code with a team, including defining contracts, creating good tracing and error handling, and building a set of automatic tests that you can rely on.  In addition, there's a bunch in here about how to work with other developers using source control, continuous integration, etc. to make everyone's lives easier and more productive.
Thursday, 10 April 2008 10:41:33 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
Thanks to one of the other SoftSource guys here (yay, Ben!) we got the problem resolved.  Turns out if was also a problem under VS 2005, but only sometimes and nobody noticed.  Huh.  Anyway, there was a bit in the base page that was creating a control dynamically and inserting it into the control hierarchy.  In order to find out where it was supposed to go, it was recursively traversing the control hierarchy looking for the right one, before LoadViewState.  This causes the repeater to be created too early, and when ViewState comes along, it sees the control has already been created and so does nothing. 

This goes to show once again, just don't mess with the control hierarchy.  Nothing good can come of it.  Even better, just don't use repeaters and come up with a better way of doing things.  I'm finally doing some "real" Ajax using client side JavaScript to make asynchronous callbacks.  Sooooo much better than using update panels.  Yes, it requires writing JavaScript (of which I'm mildly scared) but it turns out to be pretty easy, and the pages are not only much more responsive, but much more deterministic in their behavior.  We're now essentially only rendering the full page once, then making all the changes client side.  The programming model is a bit harder, but the results are worth it.

Thursday, 10 April 2008 10:32:49 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 25 March 2008
Yes, once again repeaters and ViewState are the bane of my existence... 

We have several pages that follow essentially the same pattern:  we have repeaters that include text boxes/check boxes, etc.  We need to retrieve the values from those controls in order to get feedback from the user.  To do that, the controls themselves are set to AutoPostBack=true.  (To make things more complicated, these repeaters are sitting inside an ASP.NET Ajax UpdatePanel.) When the post back happens, we grab the updated values from the repeater items, save them, then re-databind the repeaters.  This is less than optimal, I have come to see, but it worked.  That's worked, past tense.  As soon as we moved the project to VS 2008, it completely fails to work.  I'm pretty sure that ViewState is involved, since essentially we were relying on the repeaters being populated from ViewState before being databound.  That seems to no longer be the case.  To make matters worse, when I tried to code up a trivial example to demonstrate the problem, it works fine.  Curses! 

I'm down to two possibly explanations, neither of which I've been succesful proving so far.  Either something in the page is touching those repeaters before LoadViewState, thus screwing up the object creation, or the new 3.5 version of Ajax is passing ViewState differently on Async PostBacks.  Either way, we're working around it right now, but it would still be nice to know what happened.

My key learning from this whole experience?  Repeaters are the work of the devil, and writing HTML by hand wasn't such a bad idea. :-)

Tuesday, 25 March 2008 09:43:11 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
I'll be speaking at next month's InnoTech Oregon conference, at the convention center April 16th and 17th.  The session is entitled "The Code is the Easy Part".  I'll be speaking on practical steps you can take to improve your software project, specifically around making it easier and more effective for developers to work together as a team.  Specific topics include starting a Continuous Integration process, effective use of source control, and using tests as a means of expressing developer intent.

It looks like there's a little something for everyone at the conference, including some stuff on development practices and "agile" methodologies.  Should be fun.

Tuesday, 25 March 2008 09:34:33 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 14 March 2008
Once again I'll be teaching at the Oregon Institue of Technology this coming Spring term.  This time around the topic is building an application using C# in Visual Studio 2008.  We'll be covering an entire application lifecycle, including design, coding, test, build and deploy.  We'll go into detail about effective use of source control, how to set up a Continuous Integration process, how to write good unit tests, etc.  Along the way we'll be covering some of the new .NET 3.5 features like LINQ and all that entails.

Spread the word, and come on down if you are interested.

The official course title is .NET Tools with C# (CST407) and it will be Wednesday nights at the Hillsboro campus.

Friday, 14 March 2008 10:02:43 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 22 January 2008
I've been poking around a bit with the new ASP.NET MVC stuff, and so far I am very favorably impressed.  Sure, there are some things to work out, but I think they represent exactly the right level of abstraction for getting serious work done.  One of the things I've noticed lately since I've been doing lots of ASP.NET work is that the "classic" (if that works here) ASP.NET postback model is very very good at making the trivial case trivial.  If all you want is a simple form that pretends to have button click events, it's super easy.  Unfortunately for many of us, however, it is also very very good at making less trivial cases really hard.  At some point (and relatively quickly, I think) we spend a lot of time fighting the ASP.NET model rather than taking advantage of it.  I have spent hours trying to deal with the fact that ASP.NET is trying to make me code like I was writing a windows forms application when what I'm really writing is a web app.  I shouldn't have to worry about whether or not I need to handle some bit of rendering in OnInit or OnPreInit.  I know what HTML I want, but ASP.NET can make it hard to get there.

The new MVC model is the level of abstraction I'd like to work at.  I know I'm writing a web app, so better to embrace that fact and deal with requests and responses rather than trying to pretend that I have button click events.  The MVC model will make it very easy to get the HTML I want without having to fight the model.  I haven't logged enough time to have found the (inevitable) rough edges yet, but so far if I was starting a new web project I'd definitely want to do it using the MVC model.  The fact that it is easy to write unit test code is an added bonus (and well done, there!) but what really strikes me as useful is the model. 

If you want a web app, write a web app!

Tuesday, 22 January 2008 13:38:41 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 26 December 2007
A while back I was having a problem with getting events to fire from a drop down list inside a repeater.  In that case, I turned off ViewState for the Repeater control, and everything worked fine after that.  Well, last week I came upon a situation (much to complicated to go into here) where that just wouldn't work.  I needed the ViewState to be on, and knew there should be a reasonable way to make it work.  To make a (much too) long story short, after talking it through with Leo I discovered the error of my ways.  I was populating the items inside the drop down list during the Repeater's ItemCreated event.  Apparently that's bad.  I took exactly the same code and moved it to the handler for ItemDataBound, and everyone was happy.  Now I can leave ViewState on, correctly populate the items in the list, and actully get the SelectedIndexChanged event properly fired from each and every DropDownList. 

It's the little things...

Wednesday, 26 December 2007 12:13:48 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |