Programming
CodeStock 2008
I'm a little late posting this as I was on vacation last week (or at least that's my excuse), but CodeStock registration is now open. Here's the info:
CodeStock's mission is to bring the best and brightest code experts to East Tennessee for a one day conference open to all developers. This is not a trade show with slick salesman giving prepared demos - this is a gathering of real programmers learning about the latest in technology from each other. Sign up now at CodeStock.org and join us for CodeStock 2008!
- Keynote by author and MVP Jeff Prosise
- 30 amazing sessions, by industry leading speakers
- An area reserved for Open Spaces (self-organizing sessions)
- Great prize giveaways including: VSTS 2008 Team Suite with MSDN Premium ($10,939 Value!)
- Space is limited, register today!
What's SharePoint Good For?
In a previous post I discussed some of the trials and tribulations I've encountered with the mandate that we replace our current document management system with SharePoint. From the comments on that post, it sounds like pretty much everyone hates SharePoint to some extent.Now, users, tend to hate anything that requires that they follow procedure or document their work, so it's not entirely SharePoint's fault. But some of it might be that SharePoint is being used for things it shouldn't be used for. It's a tool, and just like any other tool, it's only good for certain situations. And even more to the point, it seems to have certain economies of scale as far as productivity goes.
Linking Membership to other tables
I ran into a very simple problem today that, unfortunately, had a somewhat complex solution. A user's Active Directory login name had changed, and I needed to update his record in a web application which uses Membership to handle its logins.
Now, of course, the easiest way to uniquely identify your users is by username. You can easily get the ID of the currently logged in user from User.Identity.Name. Of course, as I discovered, this is a Bad Idea, because now I have to update 14 fields in 11 tables.
Instead, it's best to user the ProviderUserKey property of the MembershipUser. This means it takes one extra step to get the current user's ID: Membership.GetUser(User.Identity.Name).ProviderUserKey
On the other hand, you can pass the ProviderUserKey value into Membership.GetUser just like you did the username.
Questions about Document Management with SharePoint
This is something of an expansion of my question on Twitter from last week.
We are currently using a third-party document management system for the entire company. All documents are categorized within a hierarchy (rather than a flat category structure). It's got both a web-based component as well as a desktop component which provides integration with Office and other applications. (This last part is an annoyance, as it tends to make Office unstable.)
However, it's an old version of the product and we need to either upgrade or look for something new. Between some of the annoyances people have with it and the licensing and support contract costs, we're trying to find an alternative. A newer version of the product in development is going to use SharePoint as its platform. Since we've had a bit of experience creating intranet sites with SharePoint, this is what my boss is wanting us to use. (Currently, we're using WSS3, but we can license MOSS2007 if necessary.)
I know how to use some of the document management features of SharePoint libraries--versioning, check-in/check-out, Explorer integration--but going from document management features to enterprise document management system is a big leap that I'm not willing to make without some serious planning and evaluation. It's difficult, however, as we're not really sure what we need--we have a vague idea of what features people need and what annoys them, but no hard-and-fast requirements other than it needs to be a replacement for our existing DM system. (This is made even harder by the fact that we have no dedicated DM administrator anymore.) Quite simply, we don't know that we won't implement something and then have the users tell us it's completely unusable.
The last time I looked at using SharePoint for this purpose, I got bogged down in trying to recreate our DM system in SharePoint. This ended with a lot of tinkering with hacking a cascading drop-down field feature and messing with InfoPath forms for Office integration. My problem with SharePoint is that I don't do much development with it, so when I do, it's always poking around in books to figure out how to do something very particular. What ends up happening is I ask the question, "how do I make this work in SharePoint?" rather than "how is this supposed to work?" and then "what's the best approach to use in SharePoint?", and that just ends in kludgy implementation. I have a feeling there's an approach we need to take with SharePoint that won't be mimicking our current DM system's approach, but will still meet all of our current requirements. The problem is, I don't have the experience to do this.
We need the hierarchy of categories and we need to be able to force users to profile their document before they upload it. Integrating both of these into Office would be nice--I imagine if we don't have that, we're going to get some pushback from users. We're also under quite a bit of pressure, as our current support agreement has run out, we're at least a version behind on our current DM software, and the age of the hardware is going to force us to switch or reinstall soon.
So the question is: has anyone used anything like this before? If not, is there a good source of "best practices" for this sort of thing? Or doing it right so far over our heads that we just need to call in a consulting company to give us some direction?
Fixed!
After some amount of counseling on here, plus Chad's diagnosis that I should just buy a new case, I ended up finding a micro ATX power supply on Newegg. With shipping, it cost me about $40.
I got it Monday but only found time to install it today. My desktop is working again. w00t!