Freezing Headers/Columns in a Scrollable DataGrid

  • Posted by justin on September 28, 2005
  • 0 comments

Interesting article on how to implement freezing the headers/columns in a Datagrid like you can in excel.  This solution however only works in IE 5+ because it uses the CSS expression stuff.

http://www.richardxin.com/FreezeHeader.aspx

 

Excerpt of article

Freeze Header

.Freezing
{
   position:relative ;
   top:expression(this.offsetParent.scrollTop);
   z-index: 10;
}

<HeaderStyle ... CssClass= "Freezing" ...></HeaderStyle>

Freezing Columns

.FreezingCol
{
   LEFT: expression(document.getElementById("freezingDiv").scrollLeft);
   /*freezingDiv is the name of the div to make your datagrid scrollable */ 
   POSITION: relative;
   z-index: 1;
}  
 
e.Item.Cells(0).CssClass = "FreezingCol"
e.Item.Cells(1).CssClass = "FreezingCol"


PDC Pre-Conference: The Art of Building Reuseable Class Libraries

  • Posted by justin on September 13, 2005
  • 0 comments

Summary:  Lots of good information about guidelines we should be following.  It is going to take a bit to make all of the suggestion 2nd nature in my day to day coding.  Many of the suggestions are things that I do today but it is good to understand more around why it is the best practice than a just because answer.  The book that they gave away looks like it has a ton of good information in it. 

Details:

  • Got a free copy of the Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries
    • Publisher: Microsoft Press
    • Authors: Krzysztof Cwaline and Brad Abrams
    • ISBN: 0–321–24675–6
    • The books looks pretty good with lots of good examples of what to do and what not to do.
  • Who is this class for?
    • Developers building reusable library or component
    • Developer Building apps to explicitly understand the rules of the .NET framework and WinFx
  • Quote of the Day:
    • I have yet to see any problem, however, complicated, which, when looked at the right way did not become still more complicated.
    • Being complex is easy, being simple is hard.
  • Project Cost:
    • Recent Gardner study, May 2002
    • 79% labor
    • 11% hardware
    • 10% software
    • The way to get more done with less money is to built the common bits of code in a well design library that is easy to use.  This will save all of the other developers the time and effort to understand how to use the library
  • 4 Keys of framework Design
    • The power of sameness
    • framework design matters
    • tools for communication
    • the pit of success
  • The Power of sameness:
    • Are things as easy to understand and use as driving a car.  If not your framework is too complicated.
    • Naming Conventions
      • PascalCasing – each work starts with an uppercase letter
      • camelCasing – first work lower case, other uppercase
      • SCREAMING_CAPS – all upper case with underscores.  It is not in the design guidelines and is not easier to read.  Microsoft dropped it completely from public APIs
    • Blink: the power of thinking without thinking.
    • All types and publicly exposed  members are PascalCased
    • Parameters are camelCased
    • Hungarian Notation
      • Do not use Hungarian notation in publicly exposed APIs and parameter names
      • the prefix codes are arbitrary and difficult to learn
        • they make it harder to read an identifier name
      • Hungarian was developed for a time when languages were loosely typed and IDEs were not as powerful
        • e.g. “out” and “ref” parameters information now conveyed at the call site
    • Abbreviations, acronyms, initialism and the like…
      • Avoid them!
        • they are a classic JLT (jargon loaded term)
        • OK to use them once they become words
          • HTML, XML,etc.
      • Don’t just spell them out
        • use a meaningful name
      • Abbreviations of more than 2 letters are cased as words, otherwise all upper
        • IO vs. Html
    • Good naming is hard – it takes time
      • be meaningful but brief
    • Use US-English, if going to be used Internationally
      • Colour vs. Color
    • Principle of least surprise – you want to make sure you give developers what they expect to see.
    • Look for prior-art
      • NumberOfElements vs. Count
    • Suffixes and Prefixes
      • interfaces prefix with “I”
        • A tribute to COM
      • Exception and Attributes suffixed
      • public interface IFormattable{}
      • public class NameAttribute : Attribute{}
      • public class PrinterOnFireException : Exception{}
    • Optimize globally and not locally
      • Example: if all exceptions take the 1st parameter  as a message dont change your exceptions to take a parameter name 1st instead unless the developers are only going to use your exception all the time
    • Dangers of Method Overloading
      • A single operation should do a single thing
      • Good method overloading is a single thing – all overloads are semantically the same
      • Don’t overload when the methods are semantically different
      • Incorrect overload
        • string.IndexOf(string value){}
        • string.IndexOf(char[] value){}
      • Correct overload
        • Convert.ToString(int value){}
        • Convert.ToString(double value){}
    • Method Overloading: Defaults
      • use appropriate default values
        • simple method assumes default state
        • more complex methods indicate changes from the default state
      • use a zeroed state for the default value such as 0, 0.0, false, null, etc)
    • Constructors and Properties
      • Constructor’s parameters are shortcuts for setting properties
      • No difference between public and protected variables from a guideline standpoint
    • Should have guidelines for different areas.  e.g. Win32 versus .NET.  They may be the same but if there is legacy guidelines that everyone knows, it is not worth the effort or ROI to change the guidelines. 
    • Summary:
      • Influence of expectations
        • naming conventions and common suffixes/prefixes
      • Habits win out over the special cases
        • Common exception pattern
      • With great power comes great responsibility
        • method overloading
      • Meet developers where they are
        • constructors and properties pattern teaches us to meet developer’ expectations
  • Framework Design Matters
    • The role of a framework development process
    • process of framework design is very different from prototyping and implementation
    • developers and api designers look at design space from different perspective
    • similarly to implementations framework design must be…
      • simple
      • integrated
      • consistent
      • evolvable
    • well designed framework must be simple
    • focus on top scenarios
      • DO define top usage scenarios for each major feature area
      • DO design APIs by first writing code samples for the main scenarios and then defining the object model to support the code samples
      • DO NOT require users to explicitly instantiate more than one type in the most basic scenarios.
      • biggest issue for many developers from a usability standpoint is that they can not find the type that they should start with. 
      • example sample:
        • Stopwatch watch = new Stopwatch();
        • watch.Start();
        • Thread.Sleep(1000).
        • Console.WriteLine(“”);
    • Namespace Factoring
      • ???
      • ???
    • Naming
      • Do favor readability over brevity. 
      • Do not use abbreviations or contractions as parts of identifier names
      • Do not use any acronyms that are not widely accepted and then only when necessary
      • Do reserver the best type names for the most commonly used types
    • Exceptions
      • Do use exception messages to communicate framework usage mistakes to the developer
    • Well designed framework must be explicitly designed
      • Api design is not something that just happens magically.  it is an explicit process and requires allocating time and resource.  Can sometimes be an expensive process sometimes
      • Review Scenario Samples
        • Solicit feedback on the scenario samples
        • feedback from non-experts.  Make sure that all developers can use and understand the purpose of the class.
    • Well designed framework is a part of an ecosystem
      • EditorBrowsableAttribute
        • Always
        • Never
        • Differs per language
      • Naming Related Members
        • Example, may have write over and append methods. For intellisense you may want to name the methods, WriteOver and WriteAppend versus .Append and .Over.
      • Nobody just uses the framework, there is also intellisense and debuggers that have to interact with your components.
      • DebuggerAttributes
        • Several in system diagnostic namespace
        • DebuggerTypeProxy – tell debugger how to show contents of an instance
      • CLS Compliance
        • Do apply CLSCompliantAttribute to framework assemblies
        • [assembly:CLSCompliant(true)]
        • contract between framework and language designers.  They are public views of your framework so that all CLS Compliant language will see these things.
        • for example: public unit Id.  compiler will throw an error saying that not CLSCompliant since unsigned int are not required to be implemented by all languages.
    • Well designed framework must be integrated
      • API designer should ensure that a particular component plugs in well with others.
      • Use common abstractions
        • Do use the lest derived parameter type that provides the functionality required by the member
        • Do use the least specialized type possible as a parameter type.
      • type name conflicts
        • Do not introduce generic type names such as Element, Node, Log, and Message.
        • what is wrong with using generic name because namespace spacing make it possible.  It comes down to user experience.  Most of the time you will not fully qualify the method name and it will ultimately be confusing and hard to maintain.  User has to type more and has to fix it when the compiler errors on the short name. 
    • Well designed framework must be designed to evolve.
      • frameworks have to stand the test of time.
      • interfaces vs abstract classes
        • Do favor defining classes over interfaces
        • classes make it easier to not make breaking changes because you can just add the new methods/properties.
      • Control Extensibility
        • Do not make members virtual unless you have a good reason to do so and you are aware of all the costs related to designing, testing and maintaining virtual members.
        • Once you make members virtual there is less tweaks you can do to the API without affecting users
      • Test Abstractions
        • Do provide at least one type that is an implementation of an interface
        • Do provide at least one API consuming each interface you define (a method taking the interface as a parameter or a property typed as the interface.
    • Well designed framework must be consistent
      • Naming consistency
      • Section 3.5.2 in the book.
      • Example: System.EventArgs – Do add the suffix EventArgs
    • Common Patterns and Idioms
      • Attribute Design
      • Collection Usage
      • XML Usage
      • The Async Pattern
      • Dispose Pattern
      • Section 8 and 9 in the book
    • Summary
      • Framework design does not happen magically
      • Best frameworks are designed upfront by framework designers
      • There are several qualities of a well designed framework that require focused framework design process.
  • API Design Experience: The API Review
    • Demonstrate how the API design experience really goes
    • Show you some common mistakes and common fixes
    • Review and Comment ahead of time
    • Expert should be doing the code review
    • A non-expert should review the public interface of the framework to make sure it is easy to understand and use.

 

  • Communication Tools
    • Your developers can’t read your mind
    • Focus on the developer not on you
    • You must communicate
      • Examples of what consumers need to know
        • Will this operation block?
        • How do I customize the type
    • Documentation alone is not enough
    • Good documentation on a bad API is like lipstick on a pig
    • Dont force consumers to become archaeologists of your framework..follow a common vocabulary
    • Define Namespace
      • Organizational principle to allow consumers to:
        • find relevant functionality quickly
        • Exclude less relevant functionality
      • Not about implementation issues
        • security, identity, size, perf
      • Not a billboard to advertise your organization
    • Define Class
      • A conceptual model for a thing which can hold state, perform actions, etc
      • Common API design problems
        • Grab bag types (lack of cohesion)
          • Example: System.RunTime.InteropServices.Marshal
        • Modeling overly abstract
          • Example StreamReader vs File
    • Define Struct
      • A domain specific extension of the intrinsic type system
        • Example: Point, Complex, etc.
      • Expert use: perf optimization when GC-Hep allocated objects are not warrented
        • Example: an Enumerator
      • Common API design problems:
        • overuse to avoid GC
        • instance size over 16 bytes
        • are not immutable
    • Define: Static Class
      • Container for a set of highly related static members. 
      • commonly used for
        • Full OO encapsulation not warranted
          • Example: System.Math
        • Convenience methods for a more complex design
          • example System.IO.File
      • Common API design problems
        • Doing it “by hand”: and getting it wrong
        • Loose Cohesion
    • Define Exceptions
      • encapsulation of error details used in a structured exception handling system
      • common api design mistakes
        • using error codes rather than the exceptions
        • creating far too many exceptions
          • only create new exceptions if callers will handle them differently
    • Define: Enum
      • Container for named constraints
      • Common API Design Mistakes
        • Accepting the default values
          • public enum Colors
          • {
            • Red = 0,
            • Green = 1,
            • Blue = 2
          • }
        • using “magic” constraints instead
          • SetColor(Colors.Red)
          • SetColor(1);
    • Define: Flags Enum
      • my laptop crashed so I missed this slide
    • Define Constructor
      • my laptop crashed so I missed this slide
    • Constructors are lazy
      • do minimal work in the constructor
        • be lazy
        • only capture the parameters
      • Dont do more than you need to do.
    • Define methods:
      • used to expose actions or operations
      • common api design problems
        • using properties where methods should be used
    • Properties versus Methods
      • use a property
        • if the member logical attribute of the type
      • use a method
        • if the operation is a conversion such as ToString()
        • if the getter has an observable side effect
        • if order of execution is important
        • if the method might not return immediately
        • if the member returns an array
        • if operation is expensive
    • Define Fields
      • useful for exposing implementation details thereby constraining your ability to evolve the framework
      • or just use properties :)
    • Const ve Readonly
      • Const:
        • compile time evaluation
        • stable across versions
      • readonly
        • runtime evaluation
        • unstable across versions
      • Should only use const if the value is never ever going to change.  Good example of const is Pie (3.14)
    • Define Properties
      • logical backing field.  useful to encapsulate access to state allowing a degree of flexibility in implementation
      • Common api design problem
        • property vs method
      • use read only properties where appropriate
        • do not use write-only properties
      • property getters should be simple and therefore unlikely to throw exceptions
      • properties should not have dependencies on each other
        • setting one property should not affect other properties
      • properties should be settable in any order
    • Events
      • Expose callback operation
      • Event handler is a delegate that describe the contract
      • common api design problems
        • using bad terminology
          • events are not fired or triggered they are raised
        • not using verbs
          • click, paint, etc
        • not using strongly typed EventArgs to allow for extensibility
    • Static Members
      • statics are the .NET equiv of global variables or global functions
        • not object oriented
        • save evils as global
        • but can be very useful
          • System.Math – full modeling not required
  • Pit Of Success
    • Is using your framework correctly like using a mountain?
    • Enable the Pit of Success by avoid the perilous summit of complexity
      • Make the simple things simple and the hard things possible
    • Exceptions and the Pit of Success
      • When to throw an exception
        • exceptions rather than error codes
          • robust: failures get noticed
        • your method is defined to do something
          • if it succeeds in performing its purpose, erturn
          • if it fails to do what it was written to do throw an exception
      • What exception to throw
        • use or subclass existing exceptions if at all possible
        • only create seperate classes if you think developers will handle the exception differently, how will your user handle this exception different than the other 3 exceptions.  if nothing is different then no benefit in providing another exception.
    • Catching Exceptions
      • consider including a try/catch at the top of a thread’s stack if the error can be handled properly
        • unhandled exceptions at the top of the main thread will terminate the app
      • in 2.0, unhandled exceptions at the top of the stack on any thread will terminate the app
        • but avoid catch blocks in finalizers
      • Be aware: In many cases it is “appropriate” to let the app terminate
      • Be aware of (but ignore) exceptions that dont inherit from System.Exception
        • Allowed in v1.0/1.1 addressed in 2.0
      • See UnhandledException event on AppDomain
    • More features != more value
  • Designing for Extensibility
    • Abstract and Base classes
      • prefer broad shallow hierarchies
        • less than or equal to 2 additional levels – Rough rule!
      • Contracts and responsibilities are difficult to maintain and explain in deep complex hierarchies
      • Consider making base classes not constructible (i.e. use Abstract Classes)
        • make it clear what the class is for
        • provide a protected constructor for subclasses to call
        • System.Exception should not have had a public constructor
    • virtual methods
      • method call virtualizes at runtime
      • the static type does not matter
      • this is the danger and power of virtual methods
        • Danger: owner of base classes cannot control what subclasses do
        • Power: base class does not have to change as new subclasses are created.
    • Overriding
      • dont change the semantics of member
        • follow the contract defined on the case class
      • all virtual members should define a contract
      • dont require clients to have knowledge of your overriding
      • should you call the base? you should specify it in the contract of if you need to call it or not
    • Virtual and non-virtual
      • use non-virtual members unless you have specifically designed for specialization
        • have a concrete scenario in mind
        • write the code!
      • think before you virtualize members
        • references to base types must work with derived types without knowing the difference
          • Must continue to call in the same order and frequency
          • Cannot increase or decrease range of inputs or output
    • Interfaces versus Base Classes
      • favor using base classes over interfaces
        • base classes version better in general
          • allows adding members
        • members can be added with a default implementation
        • Interface are good for versioning behavior (changing semantics)
    • interface usage
      • interfaces are useful
        • solves the multiple root problem
      • the smaller, more focuses the interface the better
        • 1–2 members are best
        • but interfaces can be defined in terms of other simpler interfaces
        • examples: IComparable, IFormattable
    • Quote: The great proof of madness is the disproportion of one’s designs to one’s means.

PDC - Team System Pre-Conference

  • Posted by justin on September 11, 2005
  • 0 comments

Summary: I attended the Team System Pre-conference session today.  The first part of the session was a marketing overview kind of session.  There was a lot of good information.  Based off the marketing material, it looks like something that I need to look into to see if it would improve the process on my projects or if it is going to just add overhead for the sake for better tracking.  The 2nd half of the session was nothing but demos.  The first thing that I noticed with the demo is that the integration between project or excel is still not fully automated like it needs to be so there is some overhead from a PM standpoint.  Concept of VSTS is very good but I think it is not completely ready for prime time.  Maybe this will change by the time the final release comes up.

Notes from Session:

  •  July CTP of VSTS using June Version of SQL2k5 so you need 2 machines to run the beta.  One for VSTS and one for Sql2k5 
  • Everything can be extended.  Config is based on XML.  Easily can extend. 
  • Sql2k5 Express includes reporting services.  Much easier to deploy than msde
  • Everything is built on top of web services. 
  • Project and Excel plug-ins
  • Few Editions:
    • Team System:
      • Team Edition for Software Architects
      • Team Edition for Software Developers
      • Team Edition for Software Testers
    • Team Foundation Server
      • Sits in the backend, accessed by http or over network
      • provides us with checking in and out code
      • reporting services
      • process tracking
    • Team Suite
      • Includes all 3 of the team system editions
  • Features by Edition
    • Class Designer
      • Part of VS Pro Edition
        • UI for designing classes.
        • It is a visualization of the code
        • 2 representation: 1.) text 2.) graphical
    • Architects
      • App Designer: How the app work logically
      • Logical Infra Designer: How the app is deployed
      • Deployment Designer: What is required to deployed
        • service packs
        • os
        • components
        • etc
      • Visio and Uml modeling
      • Team Foundation Client
      • VS Pro Edition
      • Collectively called whitehorse
    • Developers
      • Dynamic Code Analyzer:
      • Static Code Analyzer:
      • Code Profiler: Unit Testing:
      • Code Coverage
      • Team Foundation Client
      • VS Pro Edition
    • Testers
      • Load Testings
      • Manual Testing
      • Test case management
      • Unit Testings
      • Code Coverage
      • Team Foundation Client
      • VS Pro Edition
  • Team Foundation Services
    • Collaboration
      • Work Item Tracking
        • Scenarios, Qos Reqs, Risks, Tasks, Bugs, Custom
      • Reports
    • Software Configuration Management (SCM)
      • Three tier, Sql2k5, Web services API
      • Merging, branching, shelving
    • Building Management
  • There is not web UI to log work items. Have to use VS to log them
  • Team Foundation Version Control
    • Description: Integrated Software Lifecycle suite
    • Team Size: scalable
    • Storage: sql2k5
    • Security: windows integrated
    • Remote Access: optimized web service
    • Multiple Checkout: yes, thanks to the merge engine
  • VSS 2005
    • Description: Version Control
    • Team Size: Individuals and Small
    • Storage: File System
    • Security:
    • Remote Access:
    • Multiple Checkout: No
  • Team system Extensibility
    • Team System Sensibility tool kit.  free download.  will eventually be part of the SDK
    • Team Foundation Services
    • Add your own methodology templates
    • VSIP have already announced extensions:
      • Borland
      • Amerpoint
      • Olenick and Associates
      • Brightwork
      • Osellus
  • Team Foundation Beta will contain a Go Live License when VS2005 is released Nov 7th.
  • Team Foundation Server will be released Q1 06.  VS2005 released Nov 7th.  Team Foundation Beta 3  will be released Nov 7th
  • Team System for Project Managers
    • No direct mapping to a Team System edition
      • all editions have capability for PM activities
      • vs2005, excel, project, browser
    • Activities
      • create and configure the team projects
      • assign work items
      • monitor status by querying work items or viewing reports on the project portal
  • Team Explorer
    • where in vs2005 where you can view work items, bugs.  can add work items/bugs
    • can launch reports
    • everything add thru vs is immediately available thru the sharepoint portal
  • Team System for Architects
    • Problem Space
      • todays connected system are more complex
      • communication problems between:
        • architects and developers
        • development and IT operations
      • modeling tools have poor history of success
    • Two architects types (sub-roles):
      • software/application architects (AA)
      • network/infrastructure architects (IA)
    • activities
      • create logical datacenter diagrams
      • create application diagram
      • compose application components into “systems”
      • create trial deployment diagrams
        • validate AD against LDD
      • generate deployment reports
      • implement application components (web services), thus kicking off development
  • Developing for Operations
    • avoid last minute disputes with IT when is come to deploying your apps to their servers
    • System Definition model (SDM)
      • provides a common language for describing all aspects of an IT system (constraints and settings)
      • allows validation of two SDM documents
    • UML vs DSL
      • is UML dead? No
      • Uml is great for documentation
      • DSL is great for precise software development
  • two cools SDKS out that you can play with
    • SDM SDK
    • ?
  • SDM:
    • defines: Applications, application hosting, logical machines and network topology, and hardware
  • Logical Datacenter diagrams
    • how communicate flows
    • what services are being used
    • does not include stuff like firewalls
  • app diagrams
    • SOA designer
    • various services that are running and are interacting with other services
    • how the application connects to other applications/services.
    • can generate the projects based off the diagram. 
    • builds all of the web service proxies
    • currently they do not implement wse
    • tell it how security works
    • can reverse engineer current projects
  • Team System for Developers
    • Problem Space
      • Developers are not writing quality code
      • no/inadequate source code control
      • no way to relate code changes to justification
    • Activities(besides writing code)
      • run unit tests with adequate code coverage
      • run static analysis
        • can easily run performance test for a method just by right clicking on it.
      • profile code
      • check-in, check-out code
        • associating comments and/or work items
    • Developers and Testers have some overlap.  Both can write and run unit test
  • Unit Testing
    • More powerful and easier to use than NUnit
      • right-click your code and choose “Create Tests”
      • Tests are just another type of source code
    • Code coverage does not ensure quality.  It just means that you are at least testing something.  If you have a lot of untested code with business logic then you should be writing a lot more automated unit tests.
    • Rolls up report into nice output that you can easily/quickly tell how much you are covered.
    • When doing a build can have it run code coverage as part of the build
    • Can define checkin policies
      • can make unit test be made to pass before checking
      • can make a certain percent of code coverage
  • Static Analysis
    • basically FxCop
    • Easier to write own rules
    • Tests your code for common problems, best practices, naming guidelines, etc.
    • A ton of built in items to check for.
    • if code fails, then it can reject the code and flag that it needs to be fixed before a release can be done
  • Integrated Checkin
    • Can diff current working version vs what is checked in
    • What can you associate?
      • Other files that you are checking in “Changeset”
      • Comments
      • Work Items
    • Check-In Policies
      • can enforce that a clean build is done before checking
      • can enforce that the code is applied to a work item.  this ensures that you checkin is associated to work item.  basically generates a changeset. 
  • Team System for Testers
    • Problem Space
      • Testing tools are not integrated
      • No version control for tests
      • No integrated notification mechanism
    • Activities
      • Unit testing and code coverage (overlap with dev)
      • Web testing (record and playback URL interactions)
      • Load testing (simulate multiple users)
      • Test management (manual and 3rd party tests)
      • 3rd party testing software is being integrated in such as mercury
    • Generic Test
      • Command line test.  Can be used to call external test that returns results and capture them and store the results in VSTS
  • Web Testing
    • Have access to viewstate
    • Can simulate users and think times
    • think times: basically add a buffer in for the time a user takes to do something,  example: user pulls up page, reads some help, then fills out form.  If this took 30 seconds, you can tell the test to 30 for seconds before going on.
    • Testing Web Applications is important
      • What is response time for common tasks
      • has the upgrade broken basic functionality
      • do searches still work
    • many external, third-party solutions
      • variations in capability and flexibility
      • not integrated
    • web testing in team system
      • any URL that is http based
      • recorded or code based;with validation
  • Load Testing
    • Is there a tool integrated for windows forms testing?  Microsoft does not provide one but some third party vendors are working on them.
    • Manual Test
      • Questionnaire.  Basically a problem resolution document
      • Can be used for stuff that can not be automated.
    • Can do distributed load testing
      • Control from one machine but use multiple machines to do the testing.
      • Can define how much of the load each machine takes and how many threads each machine starts
    • How does you app work under load
      • which operations see the most impact?
      • what is the processor and disk utilization
    • Load test an existing unit test
    • Load test an existing web test
    • Many ways to visualize the results
      • graphs, tables, and xml
  • Team System for Everyone Else
    • Can access real-time reports on the portal.  Can be customized for each user.
    • Can use excel or project to maintain work items
    • Can use team Explorer or command-line utilities to view/edit projects artifacts – no need for VS
    • Built on Sharepoint Web Services.  Can integrate into your own web site.
    • Does not require Sharepoint portal server.
    • Is optimized for Sharepoint WSS.
  • Summary:
    • VS 2005 Team System is for the entire team, not just the developers
    • All the tools are integrated into VS
    • Not all team members need VS
      • Excel, Project, Team Explorer, and IE
  • Attendee Questions:
    • for load testing with cpu performance it does not require manual analysis but it will be added directly.
    • if you need testing but also need architect, you will want to install Team Suite.  You can also install multiple editions of Team System onto the same system.  The CTP are Team Suite.
  • Resources:
  • Demo:
    • Part 1: Project Managers and Architects
      • Create and configure a new team project
      • Assign work items
      • create and validate architectural diagrams
    • Part 2: Developers, Tests, Deployment
      • Implement the application, using class designer
      • Check-in, check-out, shelve, and merge code
      • Run unit tests, code coverage, and static analysis tests
      • run web tests and load tests
      • generate and analyze reports, including a deployment report
    • Scenario
      • AdventureWorks wants to create a new web app
        • Enterprise blog application n-tier
        • team will be 1pm, 1 ia, 1 sa, 1 dev, 1 tester
        • must use sql2k5
        • must use web services
        • must be 3 tier
        • must be able to deploy to new datacenter
        • all code must be unit tested
        • all code must follow defined “best practices”
        • all code must be checked into/out of SCC
        • development team must use vsts
        • project has to be shipping in 3 hours
    • Team Explorer is available in all versions.  It is how people get access to add/modify work items, project documents,etc.
    • Each person that is going to change data needs a cal license.  All users have read-only access by default and do not require a cal license
    • Some Reports:
      • Work Remaining: Show Remaining Work, Resolved, and Closed
      • Velocity of Bug Fixes
      • Unplanned Work: amount of planned work versus unplanned
      • Quality Indicators: # of test that passed, failed, ignored, and amount of code coverage
      • Code Churn: detects when a project will fail.   According to Microsoft they can predicted 93% of the time if the project will fail.
      • Bug Rates: Active, Newly, and Resolved bugs.
      • Reactivations: How many false task and bug item do we have
      • Bugs by priority: Are we finding and triaging the right bugs?
      • Actual Quality versus Planning Velocity: How fast can we go compared to how many bugs we generate.
    • Can easily build your own reports using the built in reporting services.
    • Does not completely integrate with Project and Excel.  There is still a decent amount of manual steps that a PM would have to do.
    • Reports can be at the project level or drilled all the way down to an individual developer.
    • Can associate work items to other work items so that you get a dependency.