It's interesting to me that Continuous Integration wasn't originally built into this product. I believe Microsoft is going to have an uphill battle winning over those of us who have gone through great pains to integrate and implement CI with CruiseControl.Net,
Subversion, Nunit, NCover, et al.
While these third party/open source tools are not likely to provide the rich integration with Visual Studio that TFS can provide, I've now got so much invested in these tools that it would be fairly low ROI to look at a Team Server implementation.
Are there any real must-haves in implementing a Team Foundation Server approach into my Source Control/Build process that aren't immediately obvious on the
home page of the product (keeping in mind the use of Subversion as a source control solution)?
The ability to convert from one format to another is, to me, always a win-win situation. The source software continues to be a viable content development platform (e.g. designers continue to get to work in Adobe product suite) and new software is afforded
a migration/conversion path from existing technologies (e.g. VS guys can work with existing content).
It's sad to me that vendors don't see these scenarios as opportunities. I mean, wouldn't it be nicer to see the headline "Microsoft and Adobe work together to ensure seamless integration between Flash and Expression design tools"? Wouldn't you be more inclined
to accept a solution that used either company's technology than to eschew all current formats for a new one?
I for one think a tool like this ought not be a tool, but rather an implicit feature in both Expression/Orcas and Flash. Making customers conform to your product line is so, 1999.
Interesting. I wonder if LINQ, and therefore BLINQ, becomes less relevant when the database access layer is abstracted away from the ASP.Net front-end application via a SOA (using web services, for example). I haven't had a chance to look at the LINQ feature
set in detail, but it seems that a direct view into a given database is going to become less and less of a common thing to have at design time (for enterprise app development).
So, while it seems LINQ would be useful to me as a developer if my application was like...
Browser --> IIS --> .Net App_Code --> Database
...the reality is that my applications tend to be more like...
Browser --> IIS --> .Net App_Code --> Web Service Proxy --> Middle-tier Web Service Endpoint --> Middle-tier Business Logic (Java, C#, whatever) --> Data Abstraction Layer (e.g. Hibernate or other ORM) --> Database.
Is there a feature of LINQ that would serve a useful purpose in my more abstracted environment?
Good luck to Mr. Scoble and his family in future endeavors. I've almost no activity in these forums, but I feel compelled to say that I have enjoyed the rawness of his interview style and his lack of fear when discussing real issues that exist with Microsoft
as a company and a social ecosystem.
Channel9 will continue to thrive and be a great resource, but it would behoove successors to seek out a level of deference to the "grassroots" mission of Channel9 that Scoble clearly espoused.