David Jacobus

Wow! What a product.  I have been training when not consulting.  The training has been interspersed with some consulting.  I am currently engaged with a company with whom we provided discovery documentation and later re-engaged to implement SharePoint 2007 as an intranet site.  The team consists of three members: Principal Consultant (He is really an Enterprise Architect), Consultant (me) and a Project Manager.  We have been tasked to Setup, Install, customize and deliver a solution that will take content that has existed in: Lotus Notes, eRooms, File Shares and an existing Portal (contributed to over a period of ten+ years).  About 6-9 Terabytes some of which will migrate into SharePoint.  The Portal Architecture was the most pressing need of our Principal Consultant as has been our main focus over the last two months.  We started with a two level standard publishing portal which is loosely described as a static (design top level: with a stove pipe traditional architecture and a few functional repositories: like "Employee Services") and a second level that is all the ad hoc sites spun up with a short life span.  The second level would publish content to the top level.  After some portal usability tests we found this taxonomy wouldn't fit the organizations culture nor was it easy to understand.  Our Principal Consultant agonized for a few weeks and came up with a three level design that is a marvelous concept.  The top level would become a sort of Yahoo style portal which is really just a bunch of links to real content that exists elsewhere.  The top level would be based upon the content query web part which would seek content from the second level. How it is accomplished is by using content types with pages that allow us to categorize content when a page is created with the intent that content from the page would propagate to the top level.  The third level would use traditional content publishing pushing content to the second level.  In addition, I was tasked to provide 5 Frameworks: Business Data Catalog, Web Part, Web Services, Workflow, and InfoPath Forms.  These have been my primary concern as each is from 25 to 50 pages.  The problem is what to put in the documents as each category has many books, blogs and SharePoint tribal content just to describe them.  I am still working on them

I just retired as a teacher and have been offered employment as a developer for Neudesic which is based in Southern California with offices all across the United States.  I will be primarily developing for SharePoint Server 2007.  I am busily acquiring the namespaces and classes that I will be working with and I thought it might be good to reflect and share my thoughts on this conversion process from and educator to a developer.  I have been at it two days now and see that I have always been a reasonably good coder with lots of experience in VB, ASP.NET, J#, JAVA and C++.  I have had to convert over from VB.NET to C# and haven’t really had any difficulty at all so far because the base classes in the NET framework are the same and syntactically C#, C++, JAVA and J# share are much the same.  What I see as my biggest shortcoming is a solid underpinning in XML from a declarative standpoint.  I mentioned this in a previous post about WPF and XAML.  Documentation coming from Microsoft seems to be split into what is done in code and what is done declaratively in XML.  I see a need for educators to offer this to our students as that is what is being used in industry.