A lot of stuff today, but I'm trying to expand my coverage to include stuff that's related to Planet Team System, such as SOA, testing and development processes.
- /? is your friend. Until formal docs are written, you can see all the parameters that each command-line tool accepts by calling the .exe with the /? option.
- Do yourself a favor and set up the PATH environment variable. The "Visual Studio Command Prompt" shortcut has not yet been updated in CTP to include the profiler tools in the path. Sorry. So you'll need to add the following path yourself: \Program Files\Microsoft Visual Studio 8\Enterprise Developer Tools\Performance Tools
WARNING: When you add this to the path, especially if you are using tab completion that automagically adds quotes, be sure that all quotes are removed before you set it. Unfortunately, quoting the path can cause Windows to fail to load DLLs in there that the profiler tools need.
Paul Ballard has posted a link to an article by Michele Leroux Bustamante (aka dasBlonde) about choosing technologies to communicate across tier boundaries and component boundaries (being able to restrict or allow particular communication technologies is a feature in Whitehorse, which is part of Visual Studio Team System):
In the creation of Service Oriented Architectures, service boundaries define the interactions between applications. Internal to those applications is the concept of tier boundaries and component boundaries. Which technology should you use to communicate across these boundaries? In this article, Michele Leroux Bustamante, with a little help from her friends, looks at the options available.
Speaking of SOA, Craig McMurtry has a nice, two-part post about what he thinks SOA is really about. He contends that SOA is not just a way for re-purposing existing applications, but is really a better way for software entities to communicate with one another in general:
All anyone's supposed to be thinking about in IT at the moment is how to adopt a service-oriented architecture, and how to prove that they have. Of course, the problem is that no-one can agree on what exactly a service-oriented architecture is, and to the extent that they can, their vision of it is rather trivial. In this series of posts, I'm going to propose a way of understanding service-oriented architecture that explains why it is important in a wide variety of contexts. And when I'm done doing that, I'm going to become quite adamant that queues aren't services for a whole bunch of reasons that most people should agree with. 'Cause I'm really quite sick and tired of hearing that a queue-based architecture can be a service-oriented architecture. That's true only if we suck all of the significance out of the term, “service-oriented architecture.”
The term, service-oriented architecture refers to somehow incorporating services into the design of an application. I say, somehow because there is currently no consensus on how services ought to be used in truly service-oriented solution.
Mike Cohn, author of User Stories Applied (which has been getting great reviews on Amazon, by the way), has an excellent presentation on Selecting an Agile Process: Comparing the Leading Alternatives (PDF, 837k). It is the slide deck from a half-day tutorial he does that includes overviews of the main agile processes: Extreme Programming, Scrum, Feature-Driven Development, Crystal, and DSDM. Mike does an excellent job presenting the essence of each agile process in just a few slides, with lots of pictures (I'm a picture kind of guy). Highly recommended!
Zoe Goldring has posted a great list of books that should be of interest to anyone that does software testing:
Recently some of the test leadership and test managers at Microsoft pulled together a list of recommended reading for people interested in or starting a career at Microsoft in Software Test Engineering or Software Development Engineering in Test. Below is a list of the top five books recommended by the test leadership as well as an augmented list of references.
Lastly, Happy Birthday to Me!