i'm at the first office developer conference microsoft is putting on this week at the mothership...
there are a lot of people here (or at least more than i expected) -- organizers are estimating around 800 attendees in total...and from 45 different countries...that should tell you the depth that office system development has gained.
i thought i'd give somewhat of a review of what i'm seeing in general...for specifics on some sessions, check out jamesa's blog -- he's been writing about individual sessions...i won't be doing that.
awesome -- my first visit to the conference center...it is cool and well thought out.
great...mariott + free high speed internet = ability to get stuff done
sessions day 1:
well, not so positive things to say for me here...i decided to look at the sharepoint track since that's where i'm working most of these days. most of the sessions are rehashes of PDC, TechEd, etc....same old stuff for me...nothing new...and no talk of “vnext” capabilities...that's a bit disappointing. it is interesting, however, to see that people across the spectrum are facing the same challenges in sharepoint that we all face -- and it's good to hear that we are all approaching them from similar tactics.
ms company store:
um, been there done that...i walked in -- saw all the same stuff i didn't need and walked out...they didn't have the new notebook wireless mice in stock, which was the only thing i was looking for really.
look more for day 2 later...
when developing sharepoint web parts and applications, we use the object model and implement the public functions, etc that are available to us...after all there is quite a bit that are available and most are very useful.
what the documentation doesn't always do a good job of, however, is telling us *who* can perform the task. this is a common theme i see when working with customers and one i hit in my first sharepoint development project *way too late* in the game...we had to completely re-write areas because we made several key assumptions.
developers typically run under administrator privileges in their dev boxes and environments. i'd imagine any sharepoint dev is an admin or at least a site owner on the sharepoint site they are working on...maybe this isn't always the best way of doing things in development (see andrew duthie's thoughts on least privilege).
similar development caution should be used when writing web parts. patrick points to this article regarding some impersonation techniques to ensure that you can “get around” some of these issues. i'd take it one step further and tell you that one thing we did in some instances was to make the sharepoint application pool account the administrator user (either a box admin or part of the portal admin group). this way rather than maintain our security credentials for a domain user in clear text (in order to use impersonation of a named account in the example you have to), our impersonation code simply “reverts” to the process user (which just so happens to be a user with appropriate privileges), then when done...we just revert back.
IFilterShop is at it again...if you need more IFilters for sharepoint, check out these guys...they've just added a chm IFilter and have a bunch others like...
check them out: www.ifiltershop.com
UPDATE: i didn't know about these either, but they showed up in the comment thread so i thought i'd bring them to the surface: http://www.citeknet.com/ (they have some free, fully functional ifilters)