October 2006 - Posts
I added the icons/links to my site and feed thinking that they were useful, but the more I think about it, the more I think they're a waste of space. As Phil says over on Signal vs. Noise, "It's the content, not the icons". And frankly, the content of this blog hasn't really been something that would warrant a lot of link love of late. Can you saying Boring, with a capital B? I'm not sure I can either, but my most recent content has been pretty lame. I'm thinking I should ditch all the icons, especially in my feed and start writing things that may actually be of interest to someone. What do you think? Are they worth keeping around or are they just a pain in the ass?
I've been reading a lot now that I'm working in the city. As such, I'm finding I need to mix things up a little more then I used to. I'm currently reading iWoz. So far it's a pretty good read. I'm always interested in reading about how successful people got to where they are, and Steve Wozniak has definitely had is fair share of success. As a guy who hasn't ever done any hardware related work, I find a lot of the things Steve did when designing his early Apple I and II computers fascinating. To think that he laid out his entire design on paper before building a thing, and then wrote complete programs in machine language once again on paper, is just nuts.
I've also been spending some of my "free time" experimenting with some technologies available for helping visualize social networks. My dad is doing a lot of work in the area, and there is some very interesting technologies out there that do a great job of helping to visually see how people within a network are connected. I've recently been experimenting with Virtual Earth and checking out how it can be used to geo map social networks. I'll likely post some more on my experiences and talk about how fun its been to use Linq on a semi real project.
Anyway to round out my current reading list I picked up a couple books that my good friend Sam highly recommended.
iWoz: From Computer Geek to Cult Icon: How I Invented the Personal Computer, Co-Founded Apple, and Had Fun Doing It
The Hidden Power of Social Networks: Understanding How Work Really Gets Done in Organizations
Essential Windows Workflow Foundation (Microsoft .Net Development Series)
Microsoft Windows Communication Foundation: Hands-on
Dare has a nice post where he outlines his top five list of signs your software project is in trouble. When talking about his "Schedule Chicken" sign he says:
The main problem with schedule chicken is that you can be "date driven" or you can be "quality driven", you can't be both.
Well put.
Alex has added compile time query checking to Base4.NET! It's cool to see so many "O/R Mappers" adopting the strongly typed query expressions that I've blogged about a couple times. Now that I'm used to using strongly typed query API's I have a really hard time falling back to older API's that don't have such support.
In addition to the querying benefits, we've also made use of our code generated "query" classes for building bulk update statements, as well as "select into" statements for copying data between tables. I've been meaning to write a post on the topic, but since I haven't gotten around to it I'll give a little teaser here.
Bulk Updates:
Customer.Update().Set(Customer.Columns.Name == "Foo").Where(Customer.Columns.Age > 21).Execute();
And Bulk Copy/Moves
CustomerStaging.Select(CustomerStaging.Columns.FirstName, CustomerStaging.Columns.LastName)
.InsertInto(Customer.Columns.FirstName, Customer.Columns.LastName)
.Execute();
More to come later...
tags: base4, linq, queryapi, orm
Ayende continues with some more enhancements to the Query API for ActiveRecord. Adding support for automatic joins is something I've been thinking about trying to add for a while to our Query API but I've never gotten around to it. Hopefully, I'll be able to lift some ideas from Ayende if and when I do. 
Post.FindAll(Where.Post.Blog.Author == ayende &&
(Where.Post.Title == "Overloading" || Where.Post.Title == "Operator"));
One of the things that I talked a lot about in some of my previous posts about how we run our agile process is tasks. They have become a very central part of our process, and as such, have become our obsession. You see, when doing estimation it is very important to break things down into manageable tasks, otherwise you end up with riskier (and less accurate) estimates. It's well documented that developers are better at estimating smaller tasks than larger ones. Thus, we break everything into nice small manageable units of work. We then have our whiteboard full of each and every task that's necessary for building out the features for the current iteration. Throughout the week we can look at the whiteboard and see all the remaining tasks. When we finish one task we go to the board and find another. By the end of the week we aim to get all the task cards to go green since that signifies the completion of all the work.
Not quite. Unfortunately, our iterations aren't about getting our task cards to go green. They're about working software. By following our tasks we get a large portion of the way to our goal, however, it's my suspicion that they prevent us from getting as far as we need to.
You see, while task cards can help guide you along your way, they can also blind you. Rather than deciding what the most important thing for you to do next is by thinking, you instead rely on your task cards. Instead of seeing with your own eyes the software work, you instead rely on your task cards. Rather than thinking about how best to design something, you instead rely on your task cards.
Don't let your task cards control you. If you need to use them as a guide, and use them as a barometer for where you are in the iteration, so be it. However, do not obsess. Do not live vicariously through a little white task card. Instead think about what your building. Think about what the software needs to do. Think about the most important things to complete. Think about your software, not your mother f'n task cards. 
Troy Magennis has been posting a lot of interesting content on Linq. He recently posted about the limitations that he ran into when working with the Standard Query Operators, and how he's looking to overcome those limitations by writing a set of "Extra Linq Extension Methods" that do what he wants. It will be interesting to see how many alternate implementations and extensions for the Standard Query Operators are released as people find flaws or shortcomings in the default set.
tags: linq, sqo, xlinq, linq to xml
Ayende has been doing some cool stuff with operator overloading in ActiveRecord queries. As I mentioned in some of my previous posts we've done a lot of the same things with our "Query API". While it's not as nice as Linq, its a decent substition for the time being.
If you're doing any kind of Indigo (WCF) development you'll want to checkout: "Exception Handling in Windows Communication Framework and Best Practices".
My own best practices are as follows:
- Never use returnUnknownExceptionsAsFaults. Instead, log the exceptions that occur on the server side and look there when you need to debug the service.
- Always create FaultContracts for your exceptions and specify them in your service contract rather than wrapping .NET exceptions. It's not that much more work to create a FaultContract and it ensures you don't leak information. Specifying them in your service contract allows consumers to know what to expect from you when things go wrong. Being explicit with your services is a good thing, so make it explicit what you are expecting to go "wrong".
- Always implement IErrorHandler so that exceptions are logged and sanitized appropriately.
Technorati tags:
indigo,
wcf,
.net3,
winfx
A couple weeks ago I talked about how we run our one week iterations. I've received a couple questions regarding how we actually pull one week iterations off using the "schedule" that I outlined. The main questions people generally have when I mention that we use one week iterations are:
- When do you have time to fix bugs?
- Is there always enough time to fix all the bugs within such a short timeframe?
- Is it always possible to have a demo after 1 week?
- What happens when people take vacation?
- What do you demo when you spend the week doing framework libraries or infrastructure tasks?
Before moving onto answer each of these questions I should probably thank Patrick Altman for covering many of the common questions I get asked in his "One Week Itererations" post.
When do you have time to fix bugs?
As I mentioned in my last post we usually have a couple hours on Friday dedicated specifically to fixing bugs. That certainly doesn't mean that's the only time we spend working on issues that crop up. Throughout the week as we finish tasks and stories we let our QA & product teams know what things are done. They can also take a look at our whiteboard to see what's ready (or maybe only semi-ready) to be tested. If they think its worth testing they go ahead and start looking for issues. If they find "bugs", we scrutinize them and tell them that what they found is a feature not a bug and move on. You see, if you never let QA report a bug, then you never have any to fix. You didn't realize it was so easy did you? Ok, not exactly. When a "bug" is found our QA and product team typically lets us know of the "bug" by either stopping over and announcing the bug to the team, or by telling the pair that worked on the story/task which the bug is related to about the bug. After a short discussion, we either fix the issue right then, create a task card to remind us to fix the bug, or deem it not worth fixing due to the fact that other parts of the story which are not finished are what is making it a bug (aka: what was being tested wasn't quite ready to be tested).
Is there always enough time to fix all the bugs within such a short timeframe?
No. The iterations that we just finished today resulted in a handful of bugs which could not be finished by the time we closed out the iteration. We usually try and fix any bugs that are left after an iteration at the start of the next iteration. From time to time we carry the bugs longer, but, we usually try not to since the longer we wait to fix the bug the longer it will take development to remember what needs fixing.
Is it always possible to have a demo after 1 week?
We've only canceled our demo 1 time. We've also had several demos go poorly, and several demos that had to be mostly discussion and/or showing of FIT documents because what we planned to get done didn't get done. It really sucks when this happens, but it does happen.
What happens when people take vacation?
We simply put it into the schedule and deliver slightly less functionality. We currently have 7 full time developers, so we can typically churn out at least 1-2 business stories per week which are demoable. You should keep in mind that the demo isn't always all that exciting, but it does happen, and we are demoing new business functionality.
What do you demo when you spend the week doing framework libraries or infrastructure tasks?
What are framework libraries and infrastructure tasks? The only time we spent a full week doing "framework" and "infrastructure" stuff is when we implemented our security infrastructure. Every other week we've worked on business stories, along with framework/infrastructure stuff. We typically tie any technical stories that we need into the business stories that product is asking for. This results in slightly higher estimates, which product isn't always thrilled with, but such is life.
I have plenty more things to write about but considering this post has been sitting within Live Writer, in half written form for about a month I think I'll post what's here so far. What other questions, concerns, or thoughts do you have?
Roy has a writeup on why he believes each unit test should only have a single assert. I tried this in the past and didn't like the clutter that it resulted in. The [Test] attribute as well as the method declaration add additional information that we need to parse. If we increase the amount of information that we need to parse past a certain level, our tests begin to feel cluttered and unwieldy. My belief is that a unit test should be testing one single thing. If you need 2-5 asserts to test that one thing than so be it. With that said, I think Roy makes a good argument for 1 assert per unit test. I think I particularly like the idea for those just getting started with TDD and unit testing.
tags: tdd, unit testing, agile
Eric White has put together a nice tutorial on Functional Programming using C# 3.0. Eric walks through the steps that he took while trying to learn about functional programming. On my way to and from work I read Eric's tutorial and I really enjoyed it. Eric talks a lot about the language features in C# 3.0 that allow functional programming, as well as how Linq takes advantage of ideas such as lazy evaluation. Anyway, its well worth the read.
Technorati tags:
linq,
linq to xml,
xlinq