Working Actor Podcasts

Agile is Relative by Scott Ambler.The Agile Manifesto.Scrum on Wikipedia.

Derek, Ricky, and I attended the Office Developers Conference in San Jose, CA. There we competed in the national Infusion Sleepless SharePoint Developer's Competition. After the all-night coding competition, we enjoyed the ODC. At the Bill Gates keynote, I had the opportunity to ask "What is the next killer app?" The answer was that it is not one app as it has been in the past, but the ability to quickly develop custom applications. I agree completely. We presented our solution during the ODC, with Rock Band playing in the background. Even though we didn't have all the pieces working perfectly, our story really came together. We presented our solution with confidence, and the judges seemed genuinely impressed. During the keynotes of the second day, they announced the winners. Apparently the judges were impressed, because team Strongbad took the grand prize! We had the rest of the ODC to celebrate our victory, learn even more about SharePoint, and play some Rock Band. If I ever have the opportunity to compete in this kind of event again, I'll jump at it. The skills I learned and the peopleI met will stay with me for a long time. Winning is just icing.

The Infusion Sleepless Roadshow was an intense weekend of SharePoint training and competition. It was a thrill to participate.I'd like to thank Infusion for presenting the event, and Microsoft for being a fantastic host. In particular, from Infusion:Sheldon FernandezNadeem MithaDevon JonesRory RichardsonAnd from Microsoft:Zain NaboulsiChris KoenigAnd special thanks to my teammates:Derek SandersonRicky Ma

Ivar Jacobson codified Use Case Analysis in 1986 as a way of expressing functional requirements. Since that time, the technique has been improved and formalized. It is now part of the Rational Unified Process. Why should I write use cases?Use Cases help the systems analyst or software designer to understand the system under construction.Help customers understand the system being built. Users can validate that the use cases are correct.Use cases are an easy to understand and interpret way of communication the functionality of a system to an implementor. What goes into a use case?The name of the use caseAn identification number that will uniquely identify the use case. This number WILL NOT CHANGE, even if the use case is modified or deleted. This is important for tracking history.Actor - What actor or actors are going to be the focus of this use case?Goal - What is the end result of this use case.Preconditions - What must already be true about the actor or system before this use case is valid.Triggers - What triggers this use case? A user inserting their ATM card? The predetermined nightly batch processing time? etc.The Success Path - What happens when everything goes right with this use case. This description should start with the trigger and tell the story of how the state of the target system changes.Alternate Paths - This section talks about what can go wrong and how the system will respond to those error conditions.Post Conditions - This describes what state the system will be in once the use case has been executed to completion. Business Rules - Call out any business rules that apply to this use case. (RE: I'm not sure about this one...I got this from Wikipedia...not sure I like it) What is the scope of a use case?How does a use case compare to a story in agile methodologies like Scrum? Advantages of User Stories Do I have to choose one or the other? Should I strive for 100% feature coverage with use cases? As a developer, if my company doesn't perform use case analysis, can I write use cases on my own?When you have all of your use cases, what next? (discussion about dynamic behavior running through static strcuture)Good Links: Use Case Tutorial -- http://readysetpro.com/whitepapers/usecasetut.html

.NET generics are useful for more than just containers. They are a powerful mechanism for code reuse.We've used generic collections. Instead of just a list of objects, we can declare a list of Person. This is good, because the compiler helps us ensure that only Person objects are stored in the list. It also eliminates the unnecessary cast as we extract a Person from the list. And finally, this lets us type a dot after a list method and see the properties of a Person.But the power of generics goes deeper than that. They let you declaratively compose types in order to create behaviors in relatively few lines of code. Instead of creating a custom class off in another file to perform a specific function, you can put together pieces right where you need them. This composition is declarative, so your intent is captured as concisely as possible. To get started, you need to master the syntax and learn a few basic patterns.A strategy is a specific procedure for accomplishing a goal. The goal itself is expressed as an interface. The interface separates the consumer of the goal from its various implementations. By replacing the implementation, you can change the behavior of the system.A policy is more general than a strategy. It is a generic set of rules with room for interpretation. When the strategy is itself generic, then it is a policy; it can be applied to several types.A strategy or policy is chosen to accomplish its own goal. But a generic algorithm composes smaller snippets of code to accomplish a larger goal. Unlike a strategy, an algorithm has little value on its own. It must be put into context to be truly useful.One algorithm can be written in terms of another. It can use the encapsulated code and alter its behavior. This lets us declare a new algorithm by composing existing ones, rather than implementing entire new classes.A factory method wraps the constructor of a generic class so that the compiler can use type inference. When used appropriately, the syntax for expanding generics disappears.