Open ID Providers for .NET Part 1

OpenID is sweeping the web. With announcements by Microsoft and Google recently to support the OpenID Framework, things have effectively gotten huge! One of the things I’ve been wondering about is WCF Security and how one could integrate with OpenID. Here’s what I’ve been able to dig up and implement so far.

First off, it is a good idea to review what OpenID is. Check it out at openid.net for a starting point. A good read is available at the what page for OpenID. However, if you want to get into the nitty gritty internal workings of OpenID, it is a little trickier. The developer page is a good place to start, but it is somewhat minimal. Once jumping out from that page the information gets more useful. Plaxo has an interesting recipe for OpenID and also OpenID for non-Super Users are great. Both get into the grit more.

But skipping past a ton of the existing specifications and documentation might be a better idea once I realized that there truly were some .NET libraries for Open ID.

Out of these two examples ExtremeSwank definitely has the best documentation out. Easy to read code examples are even available. I started to just go with ExtremeSwank, but after looking up integration notes on OpenID support in BlogEngine.NET I decided to download both.

For my pending BlogEngine.NET Integration I found the following articles:

I’ll have the follow up to my discoveries soon, so stay tuned!

…and if you do want to read the specifications, feel free.

Fixing A Build :: Tip O' The Day

The Scenario

A Continuous Integration (CI) Build, which I’ll dub “Cib”, takes approximately 1 hr & 30 minutes. The build takes into account various builds from various platform technologies; Java, .NET, and PHP. The emphasis of course being that no single stack is available. To build the end solution all of these stacks need to be rolled into the build.

At a build time of 1 hour and a half, there is little ability to accurately watch the build, assure check ins work, or to be accurately notified of what is or is not being included in the build if numerous check ins are occurring.

What instead needs to occur is a short build. Builds in a CI environment really should not take a long time to compile, if they do, you really lose most of the CI benefit. So how long is acceptable? I’d prefer something around 5 minutes, not much more, and definitely less if possible. In most scenarios, no matter how big the project, this is possible. So what are the solutions?

Just to get a few ideas I spoke to a few guys at work about their ideas. Both Josh W. (Code Recon & System Configuration Guru) and Robert S. (Build Management Ace) gave me some good ideas. A few other conversations were had about what others had done in the past and two solutions came up the most preferred first steps.

The Solutions

  1. Split Em’ Up; Functionally, Technically, Departmentally, or However. The first thing in a multi-technology stack environment is to split up the individual builds. If need be split up various solutions into independent development teams functional segments. At some point, the solutions or projects would be broken down enough to have reasonable build times. These smaller segmented pieces are what should be setup for continuous integration. With that completed, then keep a single large, long running build as a daily build. Whatever the case, just leave it solely as a build versus a continuous integration build.
  2. Autonomous Continuous Integration Builds. Setup the builds autonomously on the build server and monitor only the build or build(s) that you need for daily development. On TeamCity this is super easy, probably is easy on VSTS, and I know it can be done with Cruise Control. It is important to monitor and be able to track any error that occurs during the segmented builds, specifically the one pertinent to a particular developers efforts.

Summary

I’m sure there are many other solutions. If you have any, please do leave a comment. Overall, the point is, continuous integration is NOT a long running build. At best, one could call that a scheduled build. A continuous integration build must be efficient and run in a reasonable amount of time. The safest range is between 2-5 minutes. Of course, less time is better.

Final on PDC 2008

Overall, after reviewing all the PDC 2008 gadgets, tools, software, frameworks, and all that jazz, I’m content. Not particularly wowed or overly enthralled, but content with the results.

There is however one piece that I can’t help but feel I should learn a LOT more about. That is Visual Studio Team Server. The reason being, is that there are just too many awesome features that enhance productivity in awe inspiring ways. However, I’m not retracting all of my current complaints about the bugs and failures of VSTS 08. Over the next few weeks I’ll probably be working on getting a local copy of VSTS running so that I can experiment with these features, and figure out what the work around are for these other issues. Stay tuned for this, however I hold no promise yet, just the plan to do this.

Also check out The Future of Unit Testing PDC 2008 Video also. This is another area were I’m somewhat interested. I’ve never been truly impressed by Microsoft’s Unit Test Framework, but am very happy with the fact that they’ve gone forward with pushing unit testing.

Last note related, sort of, to the PDC 2008 slew of events. Google had announced Open ID support around the time Microsoft did. However there is a major catch, Google Forked OpenID. This, in summary, sucks. I’m not real happy about Google doing this. It’s possibly going to push me back toward the services that Microsoft offers. Still, Google has a huge lead in services and capabilities, maturity of APIs, and other such things, but I’m thinking Microsoft will be coming up fast and furious.

On another note, there are a number of other blogs that have come to my attention that are great reads. If you intend to keep up with technology of the Microsoft Stack these are must reads. Here are two that I’ve taken to.

  • Stephanie Saad’s Weblog – Stephanie has some great reads, not super frequent, but good entries about how Microsoft dog foods the VSTS product. Pretty interesting stuff.
  • Peter Provost – Peter covers a lot of stuff, including why he hates the term “Unit Testing” because it creates too many arguments (debates, whatever). He has a great approach to things, check it out.

WebTrends Connect

I had wanted to go to the WebTrends Connect Seminar Event in Seattle, but since I’m working on future products at WebTrends I assumed I’d get a good read of the materials anyway. Amber Case & Ryan Summers attended the recent WebTrends Connect Seminar Series event in Seattle and I’m glad to see the information she’s posted, it’s a good read so check it out. It’s always good to read reviews like this from Amber, she’s really good at digging into parts of data often not treaded upon.

One of the major components of the seminar was “The 2nd Generation is Closed + Proprietary, whereas the 3rd Generation is Open standard-based”. I’m super stoked to be working on that 3rd generation and can’t wait to start applying what the future will look like when we can get this data together!

The entire industry really has pushed toward this over the last few years and slowly but surely (or maybe quickly depending on your point of view) we’re all starting to converge on this fact. XML, Javascript, HTML, RSS, and more are out there to provide us connections to this data. The key problem is getting the data, and when we have the data getting it presented and filtered the way it is useful.

I’ll have a lot more on this in the near future and some other unique articles on other blogs I’m writing for so stay tuned and I’ll provide links to the topics.

VSTS TFS 2008

If anyone out in the blogosphere is looking to purchase Team Foundation Server for a development group, don’t. I’ve tried being all happy and uppity and effervescent about TFS 08, thinking that it might be smoother or more put together than TFS 05. I tried really hard, I wished, and I hoped. But wishing, hoping, and all that doesn’t do a thing for the reality of it. TFS is not trustworthy, the oddities and ghost issues that just come up are ridiculous. When Subversion is so cheaply available (re: FREE) I don’t see why the torture of TFS for the sole purpose of source control is needed.

Just today I was getting the latest, as one often has to do, and BOOM, I have conflicts. Mind you, my box didn’t have a single file on it that was in any way remotely connected to source control. There WAS NO WAY TO HAVE a FREAKING CONFLICT! I honestly don’t get it, how can Microsoft not fix this type of thing?

Anyway, I digress, at least no code (knock on wood) has disappeared yet. I have officially, after a mere 2 weeks of working with TFS Server become a non-fan and paranoid TFS User.