I'm one of the organizers and presenters at the St. Louis Day of .NET. On Saturday, Dec. 13, please come check out the large variety of sessions we will have available and walk out with more knowledge (and some cool prizes). The majority of the presentations will cover products and technologies covered at the recent PDC.
St. Louis Day of .NET
Hope to see ya there!
Thursday, November 6, 2008
I'm doing a Live Meeting presentation on the following today. I hope you guys can join. Sorry for the late notice! :(
"Crack the code on better ROI with in-house development projects
Do you create or integrate applications for your organization? Successful software development requires transparency and structure. Although most of your team understands the value of formal process and advanced tools, it is often difficult to justify their costs.
Quilogy can recommend custom activities for ALL roles on your development teams to improve project quality and overall success. Our deep experience can help you efficiently plan, develop and test your custom development projects and get more value out of your investments in process and tools.
Quilogy has been developing software for nearly two decades and has parlayed that knowledge into a set of codified rules for application lifecycle management. Join us as we take a hard, quantitative look at how your business can save money, improve quality, and reduce time to market. We’ll show you how to get started; you just have to take the first step."
We will eventually post a link to a recording of this presentation as well.
"Crack the code on better ROI with in-house development projects
Do you create or integrate applications for your organization? Successful software development requires transparency and structure. Although most of your team understands the value of formal process and advanced tools, it is often difficult to justify their costs.
Quilogy can recommend custom activities for ALL roles on your development teams to improve project quality and overall success. Our deep experience can help you efficiently plan, develop and test your custom development projects and get more value out of your investments in process and tools.
Quilogy has been developing software for nearly two decades and has parlayed that knowledge into a set of codified rules for application lifecycle management. Join us as we take a hard, quantitative look at how your business can save money, improve quality, and reduce time to market. We’ll show you how to get started; you just have to take the first step."
We will eventually post a link to a recording of this presentation as well.
Wednesday, August 13, 2008
Intro to SharePoint & SOA
I've been developing and configuring SharePoint for about 4 years now. I was involved with the MOSS 2007 TAP Program and used it to gain an all-expense paid trip to Europe to train others upon its release. Let me start off by saying 'I love the product'. It integrates well with Office products and if my contacts on the product team are telling the truth, this will improve immensely in "Office 14". The document management capabilities are the best I've used in a web-based solution. Finally, it has a fairly simple object model that make it easy to interact with.
However, one thing I've learned is SharePoint is NOT a development platform - nor do I believe it is truly intended to be - nor do I believe it should ever be. SharePoint is a 'portal' application. (See here for the community definition.) It is intended to be a central access point to other applications. What I have been guilty of and what I continue to see others fall prey to is the temptation of developing even the smallest applications within SharePoint. Most often these applications take the form of complex web parts with lists as data sources or ASP.NET web pages stored in various locations within the SharePoint database or file structure. Often, this tight-coupling to the SharePoint server breaks SOA tenets and/or wreaks havoc on any kind of flexibility requirements. (The ALM difficulties of developing and deploying apps in SharePoint also indicate the need for small one-man efforts.)
Resources from Redmond Developer Magazine:
Platform Rising
SharePoint Does It All
Forrester Report (this one costs money folks!):
Now Is The Time To Determine SharePoint's Place In Your Application Development Strategy
Having said all of that, I truly believe SharePoint is integral to any SOA initiative in Microsoft-friendly enterprises. Its use of web services to provide access to its object model is extensive. The various ways SharePoint provides access to external data is also SOA friendly. Like Microsoft CRM provides services to expose its related entity data and Team System provides client object model access to work items, etc., SharePoint should act as a way to have your other applications interact with your documents, simple lists, and even kick off workflows.
Sidebar: Speaking of workflows, I've also seen too many developers go straight to Visual Studio to develop workflows. SharePoint Designer reminds us all of FrontPage, but there really is a lot of power there. When the workflow becomes complex enough to really warrant Visual Studio development, try to build custom workflow activities. These activities can then be used throughout your enterprise. Workflows that map critical business processes should be treated like any other application and not be tightly coupled to SharePoint. Host the workflow in a service and let it call into your custom database, document library, etc. (I've talked to developers that have made state machine workflow versions of existing sequential ones as if the fact that it is a state machine somehow will improve the end-user experience. When writing methods, some logic is easier to do recursively than iteratively and vice-versa. The same is true for state machine versus sequential workflows.)
So, keep your portal a portal. Build your web applications in ASP.NET and put a hyperlink to them in your portal pages. Don't struggle trying to get AJAX or Silverlight to work in SharePoint, thereby adding significant time and complexity to your efforts. Do it faster and keep the larger enterprise in mind outside of SharePoint. As developers and architects, it's important we keep the business needs in mind and not simply push products and technology to its limits because we can get away with it.
However, one thing I've learned is SharePoint is NOT a development platform - nor do I believe it is truly intended to be - nor do I believe it should ever be. SharePoint is a 'portal' application. (See here for the community definition.) It is intended to be a central access point to other applications. What I have been guilty of and what I continue to see others fall prey to is the temptation of developing even the smallest applications within SharePoint. Most often these applications take the form of complex web parts with lists as data sources or ASP.NET web pages stored in various locations within the SharePoint database or file structure. Often, this tight-coupling to the SharePoint server breaks SOA tenets and/or wreaks havoc on any kind of flexibility requirements. (The ALM difficulties of developing and deploying apps in SharePoint also indicate the need for small one-man efforts.)
Resources from Redmond Developer Magazine:
Platform Rising
SharePoint Does It All
Forrester Report (this one costs money folks!):
Now Is The Time To Determine SharePoint's Place In Your Application Development Strategy
Having said all of that, I truly believe SharePoint is integral to any SOA initiative in Microsoft-friendly enterprises. Its use of web services to provide access to its object model is extensive. The various ways SharePoint provides access to external data is also SOA friendly. Like Microsoft CRM provides services to expose its related entity data and Team System provides client object model access to work items, etc., SharePoint should act as a way to have your other applications interact with your documents, simple lists, and even kick off workflows.
Sidebar: Speaking of workflows, I've also seen too many developers go straight to Visual Studio to develop workflows. SharePoint Designer reminds us all of FrontPage, but there really is a lot of power there. When the workflow becomes complex enough to really warrant Visual Studio development, try to build custom workflow activities. These activities can then be used throughout your enterprise. Workflows that map critical business processes should be treated like any other application and not be tightly coupled to SharePoint. Host the workflow in a service and let it call into your custom database, document library, etc. (I've talked to developers that have made state machine workflow versions of existing sequential ones as if the fact that it is a state machine somehow will improve the end-user experience. When writing methods, some logic is easier to do recursively than iteratively and vice-versa. The same is true for state machine versus sequential workflows.)
So, keep your portal a portal. Build your web applications in ASP.NET and put a hyperlink to them in your portal pages. Don't struggle trying to get AJAX or Silverlight to work in SharePoint, thereby adding significant time and complexity to your efforts. Do it faster and keep the larger enterprise in mind outside of SharePoint. As developers and architects, it's important we keep the business needs in mind and not simply push products and technology to its limits because we can get away with it.
Sunday, May 11, 2008
Why Team System?
I'm a HUGE fan of Visual Studio Team System. I think the software development industry is in major need of a more structured and disciplined approach. Developers have long enjoyed the freedom afforded them by the nascent technology. Hackers were crucial in the early days of the computer revolution. These lone rangers were the innovators researching the technology before business even understood how they would use it.
However, now the tide is turning. The majority of custom application development done today is commissioned in order to answer a market need. Line-of-business applications are assembled by many people working together in a variety of roles. As the size of development projects has grown, so has the need for improving process and tools. In the past, these things were arguably overhead that slowed down the innovation.
I think it's imperative our industry embraces this trend. I want to push innovation as much as the next futurist. However, business people and general consumers look at software as a necessary evil to get things done or something they are forced to use due to company policy. While underground R & D and hacker innovation was enough in the past, today's larger efforts require the support of businesses and end-users.
I think Microsoft Visual Studio Team System seeks to address this need. Giving development teams the platform for process and the tools they will need to improve communication for distributed development, mitigate risks to promote project success, and reduce the cost of development and maintenance.
Visual Studio Team System is made up of several SKUs. The sheer number of features in the total product is as intimidating as the price tag. If you haven't looked into the various parts, here is breakdown of what I like about each one:
Team Foundation Server 2008
By far the most critical piece of VSTS, the server component replaces your crappy source control software (you are using source code control, aren't you?) with a truly enterprise-ready system. How do I know your source control system is 'crappy'? You are most likely either using SourceSafe or some open source system and getting exactly what you paid for.
Additionally, the metrics capturable in the Team Foundation Server data warehouse will give you quantitative metrics exposing exactly what's going on in your projects. This includes work item and bug tracking as well as tracking the quality of your code and automated builds.
(Note: This product works well in a Java-based environment as well!)
Test Edition 2008
The most likely product to change your current development process and improve the quality of your projects. Test Edition adds to the automated unit test capabilities in Visual Studio Professional Edition by giving you the ability to incorporate manual tests, recorded web tests, and load testing into your project. The most useful feature is code coverage (also available in Development Edition). Even if your application passes all of the tests written for it, that statistic likely means nothing if the code covered by those tests is 25%. Test runners simply publish their test results to a build and optionally include code coverage metrics produced by any combination of manual or automated tests.
Database Edition 2008
For a variety of reasons (good and bad), software applications still include a lot of business logic in the database (i.e. stored procedures, triggers, etc.). Traditionally, this code was either not kept in source control or code units were manually scripted out and saved to a shared location (often email!). By integrating with Microsoft SQL Server (support for other databases to come), this code is kept in Team Foundation Server with the rest of your source code. This script management isn't limited to your logic either. All of your database objects (i.e. tables, views, constraints, etc.) can be kept in TFS as well. This allows you to store "the truth" in TFS rather than on your production server, which often ends up out of sync with your development environments.
Another useful feature of Database Edition is test data generation. The tool can read your imported schema and generate massive amounts of test data with a simple click. Like the schema scripts above, this test data can then be repeatedly deployed as needed.
Development Edition 2008
While nowhere near as significant as the above features, Development Edition includes the aforementioned code coverage, code analysis, and code profiling. Code analysis is basically an integrated FxCop to help developers maintain some basic level of code quality. Code profiling is useful in those situations where performance is critical. Bottlenecks can be located quickly.
Test Load Agent 2008
Listed at the bottom of this list only because of its niche usage. It's actually very handy to simulate 1000's of users in a remote test environment. Additionally, the price is very competitive.
Architect Edition 2008
This is the least valuable of all of the products. (Although all that will change with the release of "Rosario".) Architect Edition will only find value in the larger enterprises where so-called "Ivory Tower Architects" work only in a strategic fashion never really dealing with lower-level details. It basically supports very high-level blueprints of applications for use during conceptual planning and initial design.
However, now the tide is turning. The majority of custom application development done today is commissioned in order to answer a market need. Line-of-business applications are assembled by many people working together in a variety of roles. As the size of development projects has grown, so has the need for improving process and tools. In the past, these things were arguably overhead that slowed down the innovation.
I think it's imperative our industry embraces this trend. I want to push innovation as much as the next futurist. However, business people and general consumers look at software as a necessary evil to get things done or something they are forced to use due to company policy. While underground R & D and hacker innovation was enough in the past, today's larger efforts require the support of businesses and end-users.
I think Microsoft Visual Studio Team System seeks to address this need. Giving development teams the platform for process and the tools they will need to improve communication for distributed development, mitigate risks to promote project success, and reduce the cost of development and maintenance.
Visual Studio Team System is made up of several SKUs. The sheer number of features in the total product is as intimidating as the price tag. If you haven't looked into the various parts, here is breakdown of what I like about each one:
Team Foundation Server 2008
By far the most critical piece of VSTS, the server component replaces your crappy source control software (you are using source code control, aren't you?) with a truly enterprise-ready system. How do I know your source control system is 'crappy'? You are most likely either using SourceSafe or some open source system and getting exactly what you paid for.
Additionally, the metrics capturable in the Team Foundation Server data warehouse will give you quantitative metrics exposing exactly what's going on in your projects. This includes work item and bug tracking as well as tracking the quality of your code and automated builds.
(Note: This product works well in a Java-based environment as well!)
Test Edition 2008
The most likely product to change your current development process and improve the quality of your projects. Test Edition adds to the automated unit test capabilities in Visual Studio Professional Edition by giving you the ability to incorporate manual tests, recorded web tests, and load testing into your project. The most useful feature is code coverage (also available in Development Edition). Even if your application passes all of the tests written for it, that statistic likely means nothing if the code covered by those tests is 25%. Test runners simply publish their test results to a build and optionally include code coverage metrics produced by any combination of manual or automated tests.
Database Edition 2008
For a variety of reasons (good and bad), software applications still include a lot of business logic in the database (i.e. stored procedures, triggers, etc.). Traditionally, this code was either not kept in source control or code units were manually scripted out and saved to a shared location (often email!). By integrating with Microsoft SQL Server (support for other databases to come), this code is kept in Team Foundation Server with the rest of your source code. This script management isn't limited to your logic either. All of your database objects (i.e. tables, views, constraints, etc.) can be kept in TFS as well. This allows you to store "the truth" in TFS rather than on your production server, which often ends up out of sync with your development environments.
Another useful feature of Database Edition is test data generation. The tool can read your imported schema and generate massive amounts of test data with a simple click. Like the schema scripts above, this test data can then be repeatedly deployed as needed.
Development Edition 2008
While nowhere near as significant as the above features, Development Edition includes the aforementioned code coverage, code analysis, and code profiling. Code analysis is basically an integrated FxCop to help developers maintain some basic level of code quality. Code profiling is useful in those situations where performance is critical. Bottlenecks can be located quickly.
Test Load Agent 2008
Listed at the bottom of this list only because of its niche usage. It's actually very handy to simulate 1000's of users in a remote test environment. Additionally, the price is very competitive.
Architect Edition 2008
This is the least valuable of all of the products. (Although all that will change with the release of "Rosario".) Architect Edition will only find value in the larger enterprises where so-called "Ivory Tower Architects" work only in a strategic fashion never really dealing with lower-level details. It basically supports very high-level blueprints of applications for use during conceptual planning and initial design.
Thursday, March 6, 2008
Team Build Server 2008 Requirements
Here are some tips to be aware of when setting up a 2008 Team Build server:
From MSDN,
In order to run tests during build, Team Edition for Testers must be installed on the build computer. In order to run unit testing, code coverage or code analysis, Team Edition for Developers must be installed on the build computer.
The Build Server components are already capable of building the vast majority of the project types. However, if you want to simply compile your projects and you don't need to run code analysis or tests, then you don't need to install any Visual Studio 2008 editions.
Additionally, if you just want to build Web Application projects:
- On the computer running Team Build, navigate to the "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0" directory.
- In this directory, create a "WebApplications" directory.
- Place the "Microsoft.WebApplication.targets" file in the "WebApplications" directory. This file can be found in the same location on your development computer with Visual Studio 2008 installed.
Subscribe to:
Posts (Atom)