Archive for the ‘Shows’ Category
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 people I 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:
And from Microsoft:
And special thanks to my teammates:
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 case
- An 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?
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)
Use Case Tutorial
We've started a document template library. There you can find the Use Case template that we promised you.
We had a lot of people in attendance, and many great comments afterward. I was particularly impressed with the diversity of experience represented by the people who wanted to talk after the presentation. I spoke with people completely unfamiliar with generics, as well as some who have already been using the techniques presented.
What most impressed me, though, is that all of these people, regardless of experience level, found something to take away from the discussion. The beginners will be opening angle brackets for the first time for something other than HTML. And the experts will be experimenting with composite algorithms.
It just goes to show that no matter how much we know, there's always more to learn. Enjoy the adventure.
I've just launched a topic site for my upcoming .NET Generics presentation. I'll post audio and video when it's recorded, but you can get a preview of the slides and material.
If you are in Texas, please come to tomorrow's presentation at the Dallas .NET Users Group. It's at the Microsoft campus in Las Colinas, on November 8 at 6:30.
Generics are a powerful mechanism for code reuse. Most .NET developers have used generic collections, but few have used the language feature to its fullest potential. Generics let us declaratively build algorithms out of smaller components.
I'll present the syntax and some basic patters in both VB.NET and C#. All of the examples are based on practical scenarios. Complete source code is available in both languages.
If you are in the Dallas/Ft. Worth area, please join me on November 8 at 6:30 at the Microsoft Campus in Las Colinas. I'll be presenting .NET Generics: More than containers. This is a bi-lingual presentation -- C# and VB. Details at the Dallas .NET Users Group.
For those of you who cannot attend, I'll post the slide deck and audio. But I hope you can be there, if not for me then for the free pizza and prize giveaways!
At Handmark, we use Subversion for source code control. (Check out this Subversion Quickstart at the Polymorphic Podcast.) Like most systems, it supports concepts like branching and tagging. The mechanics for each system varries, so check your documentation for those details. But a more interesting question is, how do you manage branches and tags? Where do you make your changes? What steps do you take when it's time to release?
There are essentially two schools of thought for branching: for features or for releases. We've chosen to branch for features and merge into the trunk to build a release. But another option would be to make all code changes in the trunk and branch at the point of release. You choose your policy based on where you will accept instability. If you can tolerate an unstable trunk, then branch for releases. If you need to isolate instability in the branches, then branch for features.
We've chosen to branch for features because our priorities change quickly. This strategy allows us to isolate changes away from each other, put them on hold for a time if necessary, and keep the trunk stable. All builds are performed from the trunk, so changes must be merged from their branches to the trunk prior to release.
Once we've build a release, it moves through various staging areas. A build starts in integration, moves to testing, and finally into production. At each point along the way, there are checks in place to ensure that it is ready to move forward. The pipeline is rigid in that no build may pass another on the way to production, and no build can move backward. If a build fails one of the checkpoints, it drops out of the pipeline. If we need to expidite a change to production, the build that's currently in the pipeline is dumped.
We find that this policy works best for our environment. It may or may not apply to yours. Choose the policy that fits your team, discuss it, document it, and stick to it.
Russell Elledge and I have been conducting interviews at Handmark, looking for help on our Pocket Express and On Demand applications. In this office, we work on the server side, focusing on making these applications robust enough to handle the large numbers of cell phones that are out in the world. So one question that Russell likes to ask our candidates is as follows:
Name five things that you always do in a scalable enterprise application.
This is an open-ended question designed to create discussion and debate, as well as to test the boundaries of their experience. I thought we could all benefit from Russell's experience, so I asked him to answer the question. This is his list:
- All information must be a transient in memory.
- All information must be in a universally accessible data store or file system.
- Use an RPC technology to force the creation of tiers in a system.
- Use SOA where possible to help force vertical scalability.
- Control your resources.
- Author in administrative capability.
- Seperate OLTP processing from reporting.
The three-tiered application is a ubiquitous pattern for a solid design. The three tiers are:
- User interface
- Business logic
- Data access
The dependency is straight down. The user interface depends upon the business logic. It feeds events from the user back into the business logic. It does not directly access the data. The business logic layer invokes the data access layer in order to read and write raw data from the database and other sources, like web services.
While this pattern successfully sheids the user interface from the raw data, it does not effectively sheild the user from the implementation.
Alan Cooper's book About Face 2.0: Essentials of User Interaction Design describes the difference between the implementation model and the conceptual model. The conceptual model is how the user thinks about the problem, and the implementation model is how the program solves it. The differences between the two cause confusion on the user's part, and bugs on the program's. The user interface's direct dependency upon the business logic means that the implementation of the business logic becomes visible to the user.
Here's my solution
On several occasions, I have had the need to insert a fourth layer into an application. Between the user interface and the business logic, I have added an interaction layer. In this case, the dependency is not straight down: the interaction layer does not completely hide the business logic from the user interface. Instead, the interaction layer is the entry point into the business layer. It fills in the gaps when the conceptual model differs from the implementation model, but it steps out of the way when the two coincide.
- User interface
- Business logic
- Data access
It is difficult to inject this layer after the fact, so I have resolved to put it in place on every application, whether it seems to need it or not. The application might really be what-you-see-is-what-you-get. But just in case you need to see something slightly different, the hook is in place.