Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Fear and Loathing

Gonzo blogging from the Annie Leibovitz of the software development world.

  • Going Microsoft

    We talk a lot about the ALT.NET community and how it's not anti-Microsoft but rather alternatives to it (and better software development in general). Rather than blabbering on about DataSets over Web Services we talk about objects and domains and cool things that go bump in the night. I wonder as I look at my RSS feeds in the last few months how much of the "alternative" crowd are making more common bedfellows in Redmond?

    Look at the history here. John Lam, Scott Hanselman, Phil Haack, Don Box, and now Rob Conery (and there are probably dozens of others I missed, sorry). MVPs or community leaders from another world, all bringing their super-brains to Microsoft to fold into the collective. Hey, don't get me wrong. I think it's a good thing. A great thing. It just seems all the cool kids are being gobbled up by the Blue Monster and I have to ask. What are things shaping up to? At this rate of adoption what will Microsoft look like in 5 years?

    Like I said, this isn't a bad thing by far. I just wonder if Roy, Oren, Scott B., Jeremy, David, and JP (to name a few) are aimed for aquisition? If there's a group working next to the software aquisition guys looking at people and playing "what-if" scenarios with humans. I'm sure Scott would turn over in his grave before that happened but hey, Microsoft isn't a bad place to work. It's actually a positive experience, a great environment, and recently it seems to have been grabbing some of the top talent there is on the street. So where does it go from here?

    How "alternative" is it if ALT.NET becomes the norm at the place that spawned the original term? Should be an interesting year. Or two. Or three. Or ten.

  • Taming the ActionCatalog in SCSF

    The Smart Client Software Factory provides additional capbility above and beyond what CAB (the Composite Application UI Block) has. A little known gem is the ActionCatalog which can ease your pain in security trimming your application.

    For example suppose you have a system where you want to hide a menu item from people that don't have access to it. This is pretty typical and generally ends up in having to scatter your code with if(User.IsInRole("Administrator")) statements, which can get pretty ugly real quick. The ActionCatalog system in SCSF helps you avoid this.

    Here's a typical example. I've created a new Business Module and in the ModuleController I'm extending the menu by adding items to it:

    public class ModuleController : WorkItemController

    {

        public override void Run()

        {

            ExtendMenu();

        }

     

        private void ExtendMenu()

        {

            ToolStripMenuItem conditionalMenu = new ToolStripMenuItem("Conditional Code");

            if (canManageUsers())

            {

                conditionalMenu.DropDownItems.Add(new ToolStripMenuItem("Manage Users"));

            }

            if (canManageAdministrators())

            {

                conditionalMenu.DropDownItems.Add(new ToolStripMenuItem("Manage Administrators"));

            }

            WorkItem.UIExtensionSites[UIExtensionSiteNames.MainMenu].Add(conditionalMenu);

        }

     

        private bool canManageAdministrators()

        {

            string userName = Thread.CurrentPrincipal.Identity.Name;

            return

                Thread.CurrentPrincipal.Identity.IsAuthenticated &&

                userName.ToLower().Equals("domain\\admin");           

        }

     

        private bool canManageUsers()

        {

            string userName = Thread.CurrentPrincipal.Identity.Name;

            return

                Thread.CurrentPrincipal.Identity.IsAuthenticated &&

                userName.ToLower().Equals("domain\\joeuser");

        }

    }

    For each menu item I want to add I make a call to a method to check if the user has access or not. In the example above I'm checking two conditions. First the user has to be authenticated to the domain, then for each specific menu item I'm checking to see another condition (in this case comparing the user name, however I could do something like check to see if they're in a domain group or not).

    Despite the fact that I could do a *little* bit of refactoring here, it's still ugly. I could for example extract the duplicate code on checking to see if the user is authenticated then do my specific compares. Another thing I could do is call out to a security service (say something that wraps AzMan or maybe the ASP.NET Membership Provider) to get back a conditional true/false on the users access. However with this approach I'm still stuck with these conditional statements and no matter what I do, my code smells.

    Enter the ActionCatalog. A set of a few classes inside of SCSF that makes security trimming easy and makes your code more maintainable. To use the ActionCatalog there are a few steps you have to do:

    • Create a class to hold your actions
    • Register the class with a WorkItem
    • Add conditions for allowing actions to be executed 
    • Execute the actions

    Setting up the Catalog 
    Let's start with the changes to the ModuleController. You'll add some new methods to setup your actions, conditions, and then execute the actions. In this case the actions are directly manipulating the UI by adding menu items to it, but actions can be anything (invoked or tied to CommandHandlers) so you decide where the most appropriate split is. Here's the modified ModuleController:

    public class ModuleController : WorkItemController

    {

        private ToolStripMenuItem _rootMenuItem;

     

        public override void Run()

        {

            ExtendMenu();

            RegisterActionCatalog();

            RegisterActionConditions();

            ExecuteActions();

        }

     

        private void ExtendMenu()

        {

            _rootMenuItem = new ToolStripMenuItem("Action Catalog");

            WorkItem.UIExtensionSites[UIExtensionSiteNames.MainMenu].Add(_rootMenuItem);

        }

     

        private void ExecuteActions()

        {

            ActionCatalogService.Execute(ActionNames.ShowUserManagementMenu, WorkItem, this, _rootMenuItem);

            ActionCatalogService.Execute(ActionNames.ShowAdministratorManagementMenu, WorkItem, this, _rootMenuItem);

        }

     

        private void RegisterActionConditions()

        {

            ActionCatalogService.RegisterGeneralCondition(new AuthenticatedUsersCondition());

            ActionCatalogService.RegisterSpecificCondition(ActionNames.ShowUserManagementMenu, new UserCondition());

            ActionCatalogService.RegisterSpecificCondition(ActionNames.ShowAdministratorManagementMenu, new AdministratorCondition());

        }

     

        private void RegisterActionCatalog()

        {

            WorkItem.Items.AddNew<ModuleActions>();

        }

    Here we've added an RegisterActionCatalog(), RegisterActionConditions(), and ExecuteActions() method (I could have put these into one method but I felt the act of registering actions, conditions and executing them voilated SRP so they're split out here).

    Action Conditions
    ActionNames is just a series of constants that I'll use to tag my action methods later using the Action attribute. The conditions are where the security checks are performed. Here's the general condition first which ensures any action is performed by an authenticated user:

    class AuthenticatedUsersCondition : IActionCondition

    {

        public bool CanExecute(string action, WorkItem context, object caller, object target)

        {

            return Thread.CurrentPrincipal.Identity.IsAuthenticated;

        }

    }

    Next are specific conditions for each action. As you saw from the AuthenticatedUsersCondition you do get the action passed into to the CanExecute call so you could either pass this off to a security service or check for each action in a common method. I've just created separate classes to handle specific actions but again, how you organize things is up to you.

    class UserCondition : IActionCondition

    {

        public bool CanExecute(string action, WorkItem context, object caller, object target)

        {

            string userName = Thread.CurrentPrincipal.Identity.Name;

            return userName.ToLower().Equals("domain\\joeuser");

        }

    }

     

    class AdministratorCondition : IActionCondition

    {

        public bool CanExecute(string action, WorkItem context, object caller, object target)

        {

            string userName = Thread.CurrentPrincipal.Identity.Name;

            return userName.ToLower().Equals("domain\\admin");

        }

    }

    Both conditions contain the same code as before but are separated now and easier to maintain. Finally we call the Execute method on the actions themselves. Execute will pass in a work item (in this case the root workitem but it could be a child work item if you wanted), the caller and a target. In this case I want to add menu items to the UI so I'm passing in a ToolStripMenuItem object. The ModuleActions class contains our actions with each one tagged with the Action attribute. This keeps our code separate for each action but still lets us access the WorkItem and whatever objects we decide to pass into the actions.

    The Action Catalog Itself

    public class ModuleActions

    {

        private WorkItem _workItem;

     

        [ServiceDependency]

        public WorkItem WorkItem

        {

            set { _workItem = value; }

            get { return _workItem; }

        }

     

        [Action(ActionNames.ShowUserManagementMenu)]

        public void ShowUserManagementMenu(object caller, object target)

        {

            ToolStripMenuItem conditionalMenu = (ToolStripMenuItem) target;

            conditionalMenu.DropDownItems.Add(new ToolStripMenuItem("Manage Users"));

        }

     

        [Action(ActionNames.ShowAdministratorManagementMenu)]

        public void ShowAdministratorManagementMenu(object caller, object target)

        {

            ToolStripMenuItem conditionalMenu = (ToolStripMenuItem)target;

            conditionalMenu.DropDownItems.Add(new ToolStripMenuItem("Manage Administrators"));

        }

    }

    Registering The Action Strategy
    Calling ActionCatalogService.Execute isn't enough to invoke the action. In order for your Action to be registered (and called) the ActionStrategy has to be added to the builder chain. The ActionStrategy isn't added by default to an SCSF solution (even though you can resolve the IActionCatalogService since services and strategies are separate). Without the strategy in the builder chain, when it constructs the object it doesn't take into account the Action attribute.

    So you need to add this to a stock SCSF project to get the action registered:

    protected override void AddBuilderStrategies(Builder builder)

    {

        base.AddBuilderStrategies(builder);

        builder.Strategies.AddNew<ActionStrategy>(BuilderStage.Initialization);

    }

    Once you've done this your action is registered and called when you invoke the catalog.Execute() method.

    A few things about actions:

    • You don't have to call catalog.CanExecute for your actions. Just call catalog.Execute(). The Execute method makes a call to CanExecute to check if the action is allowed
    • You have to register an implementation of IActionCondition with the catalog in order to do checks via CanExecute. If you don't register a condition, any action is allowed

    Alternative Approach
    There are lots of ways to use the ActionCatalogService, this is just one of them. For example in your ModuleController you can set everything up, disable all commands, then execute your ActionCatalog which will enable menu items based on roles and security.

    The ActionCatalog lets you keep your execution code separate from permissions management and who can access what. This is a simple example but with little effort you can have this call out to say a claims based WCF service, retrieve users and roles from something like an ASP.NET Membership Provider, and make applying feature level security (including UI trimming) to your Smart Client a breeze!

    Hope that helps understand the ActionCatalog in SCSF! It's a pretty cool tool and can be leveraged quite easily in your apps.

  • Agile in your schools

    After the fishbowl session from the Edmonton Code Camp, one of the big aspects that came out of the discussion was around the lack of Agile and good software development practices (aka ALT.NET) in our schools and universities.

    Chris Chapman posted a comment on my entry about a series of blogs he did last month on this exact topic. Let me tell you this has got to be one of the most definitive and well-researched pieces on the subject I've ever seen. Chris not only highlights a series of key practices (Agile/lean development, TDD, refactoring, etc.) that each university offers (or doesn't as is the case) but has a scorecard and breakdown of the best-of courses to check out.

    If you're about to enter University and feel like you're going to be left out because you're a forward thinker and want to really challenge yourself, check out Chris' findings which may help you see what's out there!

  • Lessons Learned from Edmonton Code Camp 2007

    Got back from the Edmonton Code Camp last night around midnight, after having dinner with the group. It was funny because we all sat around the table (James, Justice, Donald, Rockarts, et. al.) and realized that the entire group was also going to be at DevTeach. Not sure if that's a good thing or a bad thing, but I'm sure we'll be sharing a few beers over it again in November. Anyway, a full day of fun and discussion with a few surprises. I thought I would wrap everything up into this entry although some of these could almost deserve their own post.

    Education Needs to Get Agile

    In a fishbowl session something really came out about learning from a gent who recently (April) graduated from the UofA. He stated that these strange new concepts (MVP/MVC, ReSharper, Domain Driven Design, IoC, etc.) were all alien and he had never heard of any of them during his Comp Sci studies. It was events like the Code Camp that brought them out (or blogs or whatever) and it excited him. There was passion there and I could see a budding ALT.NET developer just wanting to burst out all over the room.

    It's true that Java, C#, and Ruby are new when it comes to the academic space. I mentioned that the world was running on Internet time and schools seem to be running on Glacial time, just waiting for something to happen and not moving very quickly when it does. This I think is a huge problem. If people are coming fresh out of University with lofty goals of building huge Enterprise applications using what they've learned from school, it's obvious this is going to be an issue. It says to me that we, the forward-thinking and always-moving-in-some-direction have a responsibility to educate the educators. We need to get out there and let people know that alternatives exist and the universe is not made up of DataSets and XML. This might go a long way to helping foster diversity and knowledge in the community at large, and help make the shift from academic to implementation be a little smoother. People should be coming out of education hitting the ground running, and not being stopped dead in their tracks, told to abandon what they learned and go pick up a few good books from the Martin Fowler signature series. There's also a responsibility of the educators to know that we are out here and enterprise development isn't just regurgitating patterns and practices that were abandoned years ago. There are alternatives and better ways of building the mousetraps, you just have to be open to understand, discuss, and validate them for the appropriate solution at hand.

    XNA

    I have my dual-head presentation on XNA programming including some remote debugging into the XBox 360 from my laptop. Unfortunately I was in a rush and forgot that I didn't have audio for the 360, so I bought a pair of speakers that morning from the local Staples (I'll use them at work to peeve off the QA people sitting next to me when I blast some Don Ho out on Monday morning). In my fit of excitement I forgot about getting an adapter to plug the speakers into the 360 so no sound during the demos, except when I ran the Windows versions. My laptop wasn't beefy enough to render the Racing Starter Kit (but the sound was there) so it chugged along at 12 frames per second.

    I think there was good interest from the community on XNA programming (although a guy asked me if this session was about "games" and proceeded to walk out when I told him yes) so hopefully we'll see some fun stuff coming out of the Edmonton community. I'm really looking forward to XNA Game Studio 2.0 and the networking support but most of all getting it to run on my regular Visual Studio. You don't know how many times I was hitting Ctrl+F12 and Alt+Insert in Express trying to get ReSharper to work.

    Domain Driven Design

    I think I had fun with my Domain Driven Design session. I struggled with this topic as I couldn't figure out how to squeeze a fairly large topic like DDD into 50 minutes of discussion. I left the session open to talking about issues with development in general, what pain points people were facing, and how DDD might serve to ease the pain (or not in some cases). I covered the basics of DDD which was really only scratching the surface and we spent a little time looking at a fairly rich domain (Ben Scheirman's NHibernate video store series) and dived into writing a builder object and a test using a fluent language to describe the domain better through code.

    For future sessions on DDD I'm probably going to spend more time on building fluent interfaces, maybe a DSL using Ruby or something. Writing academic examples of DDD is a little too brief and doesn't really help grok the principles or values of what DDD personifies. I did talk to a few people after the session and a few lightbulbs turned on as a result of it, so it wasn't a complete loss and people did enjoy the session (based on the feedback forms, although maybe they were being nice because it was so late in the day ;)

    Community and Adoption

    This was probably the coolest sessions of the day and focused on talking about good software design, the community, and how to get the word out (whatever that word is). It's funny having a session at a code camp when there's no code, but this worked (although it wasn't as filled as James' ALT.NET session). One of the reoccurring themes during the session was how does the community get to know about things like ReSharper, DDD, and patterns (to name a few). And more importantly, how does one adopt that in your own organization or community practice when you're the lone wolf?

    This is a challenge. Going back to your office and telling everyone "I just saw this great tool/technique at Code Camp and we should all change to using it" isn't going to fly. My message is clear. Practice, practice, practice. And do. Or do not. There is no try (sorry Yoda). Take what you see and practice it against your work. If there's a pain point in how you build or deploy your application then download NAnt and automate the task. There's no need to ask for permission from upper management. How would that conversation go?

    You: I would like to use [insert tool here] as it would reduce our deployment time by half.
    Pointy-haired boss: Sorry [insert tool here] isn't on our list of approved tools and your job is to code. Get back to work!

    Maybe not the best advice (and some upper-management guys may come back to me on this) but just do it. Do something that works and if it works and is better than what you're doing now, isn't it worth it?

    All in all, a great day and one that spurred new ideas and things to try that might make your geek life a little better.

  • Edmonton Code Camp - here I am!

    Jacked up on Rockstar and hanging out in the Holiday Inn in Edmonton as I hit the Edmonton Code Camp tommorow. Of course in my fit of leaving I forgot the video and still camera, so no pics from me but I'm sure they'll be Flickr coverage of the event from others (sorry Kyle).

    Here's to tommorow and I'll see if I can sneak into a few other sessions and blog about them for you while I'm there (the Donald/Justice session on the future of .NET and James' session on ALT.NET should prove interesting).

    Ahh.. wireless networking and HBO. What more can a geek ask for?

  • Working Remotely

    Kyle just finished up a series of posts on remote pairing and remote working. He's working on our Smart Client project from the Bahamas while we're stuck here in Calgary as the winter months start to show their ugly face. It's a great series and wraps up with some tips (although I have to wonder what he does now as the last few sessions he's been awfully quiet). Now I know the truth.

    Top 10 reasons to work remotely:

    1. You can frag people in Halo 3 during a design session.
    2. You can frag even more people in Halo 3 during the morning Scrum.
    3. Did I mention Halo 3?
    4. Fuzzy slippers! (although I have these and wear them at work anyway, but for those basement geeks here's your big chance to get comfy)
    5. Halo 3 anyone?
    6. Matchmaking on Halo 3 while your remote pair compiles
    7. Waiting for the Matchmaker to pair you up when someone breaks the build and you can't check in anyways
    8. Uhmm... Halo 3?
    9. Halo 3 r0ck$!
    10. And finally you can play Halo 3 without disturbing your co-workers

    So as you can see Kyle gets a tremendous amount of work done remote working with us, and you can too! All you need is a pair of fuzzy bunny slippers, a house in the Bahamas and a copy of Halo 3 (oh yeah, and an XBox 360 helps).

  • Kyle, Justice and Me

    The race is on. Ever go out and ego-surf? It's the art of finding yourself on the Internet. Either blog posts or websites you author, people talking about you, or the amazing coinky dink that you are the same person as someone else. Just a mind-numbing experiement for those that have no life.

    The score so far:

    • "Bil Simser" - Web hits: 45,000 Blog search: 407
    • "Kyle Baley" - Web hits: 682 Blog search: 6
    • "Justice Gray" - Web hits: 95,400 Blog search: 412

    I need to cut down on coffee on Tuesday mornings.

  • Camping out in Edmonton - Code Camp 2007

    I'm heading up to Edmonton this weekend for the Edmonton flavor of Code Camp. Seems only fitting as the freaks came down to our Calgary Code Camp, so I'll reciprocate. I have two sessions I'm talking about and will see if I can bring my video camera (where the heck is that charger?) and post some sessions (or at least Justice grooming himself) on my Silverlight space. Here are the sessions.

    IEntity<Hello World>(new GettingStartedWith(DomainDrivenDesign))
    We'll spend an hour wallowing through aggregate roots, entities, value objects, repositories, and the principles and concepts behind Domain Driven Design. Demos will be on the fly based on what you guys want to see but I'll prep a few things around specifications, identifying aggregate roots, TDDing the domain, and other goodness.

    So you want to play a game? How about thermo-nuclear war, XNA style!
    I won't be teamed up with John The Pimp Bristowe on this, but we'll go double-head on the display as we step through XNA, write a few games and duke it out on the big screen deploying and debugging XBox 360 games from my Windows laptop. It's like rockem-sockem robots, but with less carnage.

    Watch for a wrapup, pics, and potentially damaging video on the weekend after the dust settles. See you there!

  • Trifecta announcements from the CKS Group

    The Commity Kit for SharePoint Group (which I'm a member, but haven't participated recently, bad Bil bad) has three awesome announcements today (along with the software releases that go with them).

    Forms-Based Authentication

    FBA has been available on SharePoint 2007 since the release, however it's been a little hard to implement and worst, there are no facilities for managing users or recovering passwords. No longer. With the FBA modules, you can now basically give SharePoint a DotNetNuke facelift and provide that functionality. This includes user login, membership requests and management, password management, and user and role management.

    Virtual Earth Maps and the Campus Map App

    When I'm at Microsoft, I would sometimes see this uber-cool app which showed the Redmond campus along with facilities, all rendering via Virtual Earth and served up in SharePoint. This app is finally released along with the source code, graciously donated by MSIT Information Services team. Very cool for those that have SharePoint setup and would like to have interactive and live maps added to their sites.

    Windows Live Authentication

    It just had to happen. FBA is nice (now with the new FBA managers) and integrated is cool, but we really want Windows Live ID integration. Here it is in all it's glory.

    If there's any doubt you can't do cool things with SharePoint in the public space, take a look at CKS for ideas, inspiration, solutions, samples, and code. And get implementing!

  • Another SharePoint Sucks Post Released into the Wild

    I'm in a quippy mood tonight and stumbled across a post titled "Why SharePoint Server is Terrible". Of course you know flame-bait like this just gets my blood boiling, especially since there are points here that are completely inaccurate and don't represent the peoples the author is talking about (like MVPs). A few months ago there were blog posts about how bad a development environment SharePoint is and for the most part I agreed with what was being said. It's not great, but it's better than hand coding the world yourself. Now we get this post that goes deep into why (as the author states it, not me) SharePoint is terrible and a failure.

    I'm going to nitpick points here because overall the article is just plain negative on SharePoint. Like I said, in some cases SP blows monkey chunks. Yup, you heard it. A SharePoint MVP saying SharePoint bites. However take that with a grain of salt as it can create major suckage in some areas, it excels in others, so you have to balance what you read (even on this blog) with the context of reality and what business problem you're trying to solve. No technology in the world is going to solve problems, it's how you apply the tool or technology to aid you in a solution.

    The author states that SharePoint is a great idea, but failed for three key reasons:

    1. Far too complex to install, configure, and customize.  It is not agile.
      1. Any particular reason why people associate "agile" with "complex"? I build enterprise systems that cater to thousands of users, written using TDD, built on top of SharePoint infrastructure, and follow agile principles but they're all complex systems IMHO.
    2. It is being sold as a solution to organize unorganized companies.  It is being sold as a system to add process's to organizations that don't have them.
      1. I'm making an assumption the author is one of these "unorganized companies". I for one (and most of my cohorts in crime) would never recommend a product if it didn't suit the needs of an organization. Installing SharePoint for the sake of installing it (because some CEO read a glossy brochure) is nothing about what SharePoint is or does. I for one don't make a dime on the millions billions that SharePoint has made for Microsoft but would never stand behind pushing the product into a place where it didn't belong. I've also never seen it sold by Microsoft to corporations that didn't need or even want it. Grant you, user adoption can be slow as it's IT that sometimes makes the decision to bring it in but I've never seen an IT organization bring in the product when they weren't ready for it, or didn't have an idea of how it fit into an already existing process. Processes don't fit tools, appropriate tools are adapted to support them.
    3. It's rendered HTML is brutal, along with the CSS files.
      1. +1 for the rendering of SharePoint pages which can be painful however it has got 10x better with 2007, Master Pages, and better support for ASP.NET. It's still a little brutal and can be cumbersome due to the large number of styles and classes in the CSS. Brutal rendering? Have you seen the HTML output from other portals (Oracle, PeachTree, etc.). I have and SharePoint is a walk in the park compared to them.
      2. SharePoint OOTB doesn't conform to W3C standards so if that's an issue you'll have to wait or do a lot of customization. Yeah, this sucks and is one of the biggest problems with SharePoint rendering but I don't consider it as a result of HTML vs SomethingElse. Just bad rendering by Microsoft.
    4. It is one of the most unflexable applications I have ever used.
      1. Unflexable? Is that even a word. Unflexible? Maybe inflexible? Inflexible is the inability to change. Considering that SharePoint is an extensible platform that I can build solutions on top of to deliver legal document systems, help desks, training portals, or drive the XBox public internet site I don't consider that even remotely close to "inability to change".

    Okay, so that was 4 reasons not 3, but who's counting right?

    The author goes on to state you have to be a master of many tools. I will admit that SharePoint encompasses a lot of tools and technologies, but I am far from a master in many and some I don't even use. Ever. So do you really have to be a master in everything below to harness SharePoint?

    • SharePoint
      • Redundant, see redundant. So to be a master in SharePoint I have to be a master in SharePoint? This makes total sense.
    • SQL Server
      • If you've ever read my blog, tried to access the database directly, or wrote me and asked me what the name of the sproc is to delete a revision of a document from SharePoint you'll know that my motto is "stay out of the database!". So other than setting up (i.e. installing) SQL Server I fail to see what anyone has to master. In any case, there are guys far smarter than I who can make SQL dance and sing. Let them deal with it.
    • Internet Information Server
      • Again, what must I master here? Install it and turn it on.
    • Active Directory
      • Why must you be a "master" in AD to make it easy to configure SharePoint? In every setup I've done (both virtual, development, production, and otherwise) you install and generally AD is known (as long as the server is part of the domain, well, duh) and it just works. True, I've had problems with say domain groups with "&" and other characters in the name, but being a "master" in AD might help in knowing SharePoint but then it might help in knowing anything connecting to AD (like say your desktop).
    • File Stores
      • With each point here, my brain just gets fuzzier and fuzzier. File stores? Master? SharePoint can index a file share. Point it at it and make sure the crawler account has the right priveledges and you're done.
    • Indexing
      • Indexing in SharePoint can be more of an art than a science, but for all but the largest of installations I've seen or done (meaning 100 million documents spread over 3 data centres), indexing was OOTB and pretty much a brain-dead exercise.
    • Software Development
      • You must be a master in Software Development in order to use SharePoint. If I said this at a conference, half the room would walk out (the half that didn't already walk out when my demos blew up). I mean seriously, "software development" is such a broad term. Yes, if you want to build web parts and solutions using SharePoint you'll need to know what you're doing, but that's true for most anything. Try doing brain surgery without training. It's a messy subject.
    • Search Engines (To help customize the brutal search built into it)
      • I think the search engine needs work and customizing it can be difficult, however again it's perception and what is crap to some is fine for others. I once had a client who said "make it more like google" because they didn't like the search. We changed the style sheet to look like a Google search page and apparently that fixed the "problem" they had with it. Go figure.
    • Database Design and Development
      • I have no idea what database design and development has to do with SharePoint? You don't "design" nor "develop" databases with SharePoint and if you are, then you're doing something wrong.
    • XML
      • Calling any web service requires some understanding of XML. I don't consider the XML coming out of SharePoint web services or the XML config files to be any more complex than anything else that uses XML.
    • .NET 2.0
      • Again, if you're doing development you'll need to know .NET to build web parts but for the majority of clients I work with, they just want a tool that works and don't want (or need) to invest the time/money/effort to build custom solutions with code. A lot can be done with templates, packages, features, and what you can leverage OOTB.
    • ISA Server
      • For front-end web servers knowledge about this is a must, but for the majority of clients SharePoint installs are internal and don't need this. Again, if you need an externally facing system you'll probably have someone that knows ISA.
    • Master Pages
      • Being a master of master pages does not help you with SharePoint. It merely lets you build dazzling looking websites (if you know what you're doing and have a little design savvy) for use with SharePoint.

    I think not.

    I just don't get the whole "Document Management Process" excuse. He basically goes on to say Microsoft is so busy with pushing their SharePoint crack they're ignore people who need to understand document management, and people miss the mark. Document Management, or better yet, Information Architecture, is bloody hard. It's not something you can sit down with 2 guys and a small dog and bang together in an hour (unless you really do have 2 guys and a small dog in which case your IA is probably 5 emails a day and 3 PDF files). It takes a lot of work to figure out taxonomies, best practices, placement, structural and organization change, and adoption. All of which completely hinge on your customer and how mature their understanding of their own information is. No tool on Earth is going to help you do this right as it's all contextual to the organization, so blaming SharePoint for this failure is just asinine.

    Wiki's Rock. Uhh, yeah. I guess so. Grant you Wikipedia is pretty good and at least you can search for stuff. However wikis suffer from two major problems. First, you have to know what you're looking for before you go looking for it. Second, structurally they suck when trying to organize information in a sensible way. Substituting another tool (MediaWiki) for SharePoint to solve an information problem is missing the root cause of the issues. While it may look better in the short term, years from now when you have thousands (or millions) of Wiki pages and you're trying to discover something useful, you'll kick your IT guy in the head who came up with this flavor of the day.

    The author makes a comparison to MediaWiki and BaseCamp. Again, I don't get it. BaseCamp is like an online project management tool (with some document management bolted on the side). True, it's highly customizable from the look and feel but at the core it's a mess and isn't extensible to do anything but what it was designed to do. And MediaWiki, well, it's a wiki. You create content. That's about it. If we want to compare apples to apples, let's talk about SharePoint vs PeachTree vs Oracle vs LiveLink.

    What the author mentions isn't anything new. We've known it for years and it's a sore point for us working with SharePoint. However as with any technology, it's got it's growing pains and it's far from being done. We'll continue to learn, adapt, and make things better. Any software the size of SharePoint *is* inherently complex. The KISS principle doesn't apply across the entire system, but it can be applied (and is) in isolated parts of it where appropriate. A comment on the original blog about Photoshop is interesting. I don't go into Photoshop (much) and when I do it's for simple things (resizing an image) and an alien world. I consider myself a fairly bright guy who can pick up most anything, but PS is a crazy beast with all kinds of secrets of the underworld just waiting to be revealed. There are people on this planet that can make it sing and dance and stand on it's head. I am not one of these people. I however can so similar things with SharePoint so it's all complex, from a certain point of view.

    As Bill English stated, this is a product with a huge install base and revenues of +billions. Yeah, billions of dollars are going into BillG's pocket (or maybe it's Ray now, I can't keep track of those two crazy kids) as a direct result of this product. That speaks volumes. Millions of documents and thousands of sites spread across multiple data centres housing most everything Microsoft does on a day to day business. That speaks volumes. The drive and demand we put on Microsoft to make the product bigger, better, and faster than it ever was (well, at least easier to work with, faster would be nice too... and works on Vista maybe?) is what we do and what people want, and there's demand for this. If it wasn't we wouldn't be asked to speak and continue to communicate and educate people about SharePoint and we would all be living in a WebSphere world wouldn't we?

    I fail to see how this author can write this sort of post without having first hand experience with SharePoint (meaning setting it up in an enterprise environment, not just looking at the pretty pictures on the web or running a VM for a few minutes).