Thursday, September 27, 2007
So my new blog is at http://weblogs.asp.net/jimjackson/. That's right! I'm a Microsoft Sponsored Blogger. Not really but it sounds cool right? Me, moveon.org and Rush Limbaugh are going to really have an impact on this election! Wait, that's not right. I'm going to post the tips and tricks that I learn while spinning up on Sharepoing 2007 and Visual Studio 2008. That's pretty much it.
Tuesday, August 07, 2007
I waltzed into the house proudly displaying the broken shovel as proof of how hard I was working. My grandpa looked at the shovel, scowled and yelled "Hell boy, ANYONE can break a shovel!" I was crestfallen. The proof of my hard work turned out to be nothing more than a measure of how little I knew about using my tools.
Jump forward 25 years and I find the lesson still applies. I am always impressed at how easily some developers and managers in the software provisioning industry are always trying to:
- Use a piece of technology to solve a problem in direct conflict with that technology's expressed purpose.
- Decide not to use a technology that is specifically designed to solve a problem because it was 'not invented here' or because it would mean learning something new.
As software developers, it is our job to enhance the state of the art in what we build. We must know enough about the problem and our tools to know what is possible, what isn't and where the lines become fuzzy. For example, a developer who will not use generic collections but insists on manually boxing and unboxing collection contents has not learned the capability of his tool set. Similarly, a developer who insists that databases are 'too much overhead' and decides to wrap a complete custom transactional solution around XML files has gone around the bend only to find an unfortunate and painful hole in his own foot. (The second example is anecdotal!)
We must, as an industry, overcome the stigma of budget and schedule overruns resulting in unusable software. To do that, we must first consider what kind of tool will best suit the job at hand and then strive to use that tool appropriately. If your software is needlessly complex and unmaintainable, it may be that you've done nothing more than break your shovel.
Friday, January 12, 2007
Tuesday, January 02, 2007
At any rate, the authors did do a good job of researching related information freely available on the web. Unfortunately, it was printed and there was no ebook published with the print edition. The result is that I bookmarked all the links that I thought would be helpful and then located their actual URL (many published values are post-MSDN2). Here are the pieces I found useful.
- Continuous Integration for TFS
- MSDN Article on Using Team Foundation Build
- GUI for MSBuild Sample
- MS Build Sidekick
- Team Build Ticker
- Visual Studio 2005 Extensibility Center
- MSBuild Community
- MS Services Build Framework (SBF) Tasks
ASP.Net Applications in Team Build
- Team System Team Build TechNotes for ASP.Net Deployment Projects
- Building a default ASP.Net project in Team Build
- VS 2005 Web Deployment Projects Information
MSF Process Integration and Customization
- The Origin of Personas
- Why there are 5 missing CMMI process areas
- Starting Point for Customizing MSF Process Guidance
MS Threat Analysis and Modeling Tool
- MS Application Thread Modeling Blog
MSF Document for SCAMPI Requirements Roadmap (CMMI)
- MSF CMMI Reference.xls
MS Visual Studio Developer Center
- MS Visual Studio Developer Center (requires free membership)
Work Item - Process Template Editor
- VSTS Customization Toolkit
- Team Plain for Team System (TFS Web Access)
TFS Version Control
- Branch Merging Primer
Team System Requirements Authoring Starter Kit
- RASK Starter
- RASK Code Definition
- RASK Download