As we all know, the economy is still struggling, and although the IT sector is rebounding well, the developer job market has always been and continues to be somewhat finicky.  The key is to have a steady stream of opportunities.  This is one of the primary goals behind the SharePoint Developer Network- to make it easier for SharePoint developers to find jobs and other opportunities – not just through networking, but with a dedicated jobs board that is always up to date.

Admittedly, I’m relatively new to Twitter, but I recently saw the power of the Twitter platform at the recent SharePoint Conference in Las Vegas.  Simply by following @SPC09, people all around the world were able to receive up-to-the-minute accounts of nearly everything that was happening at the conference.

So I started thinking, “wouldn’t it be great if the SPDEVNET jobs board had job alerts that developers could subscribe to?”  After a bit of research, I found that I could setup the SharePoint Developer Network site so that when new SharePoint jobs appear in the index, they can be immediately sent to Twitter.  Now all you have to do is follow @SPDEVNET and new SharePoint job opportunities will magically appear on your favorite Twitter client as they come into the site.

Currently, the job tweets are sent for all jobs and are available to anyone with a Twitter account.  It’s not perfect yet, but it’s a start.  I’m now looking into ways to setup a more customizable subscription mechanism, so that members can filter their own personal alerts according to category, geographic region, etc.

Enjoy.

One of the great things about Windows Workflow Foundation is the support for declarative no-code workflows that reference pre-compiled workflow activity libraries.  With enough of these activity libraries in place, you can use SharePoint Designer 2007 to build some pretty powerful applications without writing any additional code.  But it also presents a kind of chicken-and-egg problem.  You first need a bunch of quality activities you can stitch together using the declarative tool.

Ryan Miller has published a set of Workflow Activities that you can install on a SharePoint server and then use them from SharePoint Designer to manipulate sites and site collections in ways that go beyond what the out-of-the-box activities allow you to do.  He presents them in a codeplex projectthat contains two categories of activities: site management and list item management activities.

The site management activities include things like creating sites and site collections, setting the site title and theme, activating features and manipulating site groups.  At the item level, there are a couple of unique activities for copying, updating and removing list items.

Check them out.

Microsoft today released a set of videos on Channel 9that showcase the new features of SharePoint 2010 from a developer perspective.  Here are some of the topics that caught my eye:

• SharePoint 2010 Developer Roadmap
• Visual Studio 2010 Tools for SharePoint 2010
• Services Architecture
• Enterprise Content Management
• Accessing External Data
• SharePoint 2010 Security

There are 15 units so far.  Each one consists of a series of videos, so there’s a lot of material already available for viewing.  I expect there will be much more coming in the weeks and months ahead.  Microsoft appears to be determined to avoid the problem we experienced with SharePoint 2007 where there was so much technology, but too little documentation for developers.

Now to find the time to go through them all.

Exciting times, eh?

It's kind of surreal, but the day has finally arrived when I can say "it's done"! My new book, Professional SharePoint 2007 Records Management Development:
Managing Official Records with Microsoft Office SharePoint Server 2007 is on its way to store shelves and is available directly from Wiley.com, Amazon.com and other online retailers.

  This book is for developers who need to build records management solutions, and who need to understand the ins and outs of the records management framework that is built into the SharePoint platform.  For a more complete synopsis and to review the TOC, just click the image to the left to visit the Wiley information page.

One thing you'll notice is that Wrox is now using a new cover format.  If you expected to see my face on the cover, you won't.  Those shrewd marketing folks at Wiley decided to give the entire Wrox line a "makeover".  I have to say I was a little disappointed at first, but I actually like the new cover design.  Who am I to argue with the marketing guys, right?

Once you get the book, you’ll also notice that I took a slightly different approach than some of the other development books out there, in that I tried to structure the chapters so that the code in later chapters builds on and extends the code presented early in the book.  On the one hand, it adds consistency because you end up with a set of reusable components that can be applied to many different types of solutions.  On the other hand, it means that in order to understand and use some of the later examples, you have to dig into the earlier ones.  I know this may be a bit frustrating for some readers, but I’m hoping that the end result justifies the approach.  I’d be very interested in getting your feedback, so don’t be shy.

On the up side, there is a LOT of code included with the book, and the kicker is it’s ALL available online NOW.  That’s right, you can download the HUGE set of code examples directly from Wrox RIGHT NOW by just clicking on the “downloads” tab on the book’s information page on the Wiley site.

As always, I'm here to serve, and I'm especially eager to hear what you think.  Wiley has setup a forum just for this book at the Wrox Programmer to Programmer site.  Just log in to the P2P site and search on my name and you’ll find the forum.

Thanks to everyone who helped make this book a reality, especially Eli Robillard, Dan Attis, Aaron Cutlip, Todd Meister, Stacy Draper and all the folks at Wiley.  It was a long and arduous road, but it was also a wonderfully enlightening and strengthening experience thanks to everyone involved.

-John

You've probably heard by now that the next version of SharePoint will drop the "Office" moniker in favor of the more direct and easily understandable "Microsoft SharePoint Server 2010"  (read the Microsoft SharePoint Team Blog Post).  I agree with my colleague Bil Simser that it sounds like something from a science fiction novel (2010 The Year We Make Contact).  On the other hand, I see the logic.  It's just like all the other software titles from Microsoft that continually evolve to meet the changing needs of users.  Office 2003.  Exchange Server 2007.  SharePoint Server 2010.  Join the club, eh?

Sure there's the implied shift away from the whole "Office Business Applications" (OBA) theme, where the line between client and server components was blurred in favor of the more holistic "Office System" approach.  I can live with that.  I'm not sure it's taking hold anyway - at least not for the developers I've talked to.  Most of the SharePoint developers I know who come from an ASP.NET background seem to have trouble thinking of themselves as Office developers.

And sure, there's the potential confusion between Windows SharePoint Services (now "Microsoft SharePoint 2010") and the new server version of the product.  But maybe that's a good thing.  According to Tom Rizzo, we should just refer to it as "SharePoint" and stop stressing over the licensing model anyway.

And what about the "12 Hive"?  Will there be a "2010" folder to contend with now?  Will it change to "14" maybe?  And how about the namespaces, like "Microsoft.Office.RecordsManagement.InformationPolicy"?  Will they change?  I doubt it.  Something to think about, though, as you plan your next SharePoint project.

I dunno.  I'm with Rizzo.  I don't think the name really matters that much.  After all, we are in the middle of a content explosion.  The paradigm IS continually shifting.  Maybe we need a more generic name so we can focus more on the solutions we build and less on the particular features of a particular product version.

Oh, wait!  "Feature".  My bad.  We were talking about SharePoint features, not SharePoint Features.

This is soooo much fun!

SharePoint training provider Combined Knowledge will host the first European SharePoint Best Practices conference in London April 6-8, 2009.  Microsoft veteran Joel Oleson will deliver the keynote and the speakers list reads like a "who's who" of the top SharePoint experts, MVPs and Microsoft product team members. 

I'll be presenting a session on designing and building records repositories using the powerful records management features provided by Office SharePoint Server.  I'm pretty excited about it, since this will be my first trip to London.  The conference will be held at the Queen Elizabeth II Conference Centre, which is right in the middle of all the London sights, so I'll be sure to stay busy before and after my talk! :)

Hope to see you there.

Mark you calendars!  Microsoft has announced the SharePoint Conference 2009, which is scheduled for October 19-22 in Las Vegas.  This promises to be a very exciting conference because it will be packed with information about the next version of SharePoint, codenamed SharePoint "14", while at the same time including real-world guidance for the current version. 

This is one conference that is not to be missed - so you'll definitely see me there.  (BTW, this will be my first time in Vegas, so any tips you have for what to do (and what NOT to do) will be most welcome!)

Early bird registration is available here. 

As every SharePoint developer knows, the CAML is an ornery beast.  Get too close - it'll spit at you, and as soon as you get knee-deep in the hot sands of SharePoint-land, it's just a matter of time before it bites you in the ass!

But wait!  There's hope for all you erstwhile CAML-geeks!

Announcing the CAML.NET IntelliSense project

I've added a new component to the CAML.NET toolset that aims to help you tame that sometimes finicky, but ever-popular and oh-so-useful CAML language.

Click here to download the CAML.NET.Intellisense installer.

You probably already know how to add the SharePoint schemas to Visual Studio so you get IntelliSense when editing CAML files.  If not, here's a link to a great article by my friend Andrew Connell that walks you through the procedure.

This is a good first step, but we can take it even further by copying the core schema files and then extending them so they provide more information.  Specifically, we can add the detailed guidance from the SDK that is scattered all over the Internet and that developers seem to have a hard time finding. 

Let's face it - even with an up to date set of bookmarks, who wants to go searching all over the place for that missing tidbit that tells you just what that obscure attribute is for when you're right in the middle of building the CAML for your feature?  If you're like me, this quickly becomes a major distraction.  Hard enough to stay focused in the first place!

Using Annotated Schemas

The main idea behind the CAML.NET IntelliSense project is to extend the core schemas in two ways:

1. Gather as much information as possible about each element and attribute and place it into xs:annotation elements so that it pops up in context while editing; and
2. Identify and replace as many xs:string types as possible with enumerated types so the valid values for each attribute also popup in context while editing.

For example, using the core WSS schemas directly, we get a drop-down like the following while editing a Field element:

That's better than nothing, but it doesn't say what the attribute is for, so unless we're already familiar with it, we have to refer back to the SDK either online or in the CHM file.  On the other hand, using the enhanced annotated WSS schema, we can provide more information in context.  We only need to refer to the SDK documentation when we really need it.  Most of the time, we just need a hint, which is what Intellisense is all about, right?

Extending the Core Schemas with Enumerated Types

In addition to annotating the schemas with the corresponding SDK documentation for each element, we can go one step further and change the plain vanilla xs:string types to custom enumerated types so we get the list of valid choices for the attribute values.  This comes in very handy and also helps to eliminate those nasty little typos that can be *really* hard to find (and the CAML gets mighty snippy about).

There are lots of places in the SDK documentation where the expected attribute values are listed in the description, but are not enumerated in the schema.  This again means that we have to go digging through the documentation to discover what SharePoint expects the attribute values to be.  This can be an enormous waste of time - even if you have a pretty good idea of what the values are.  Who can keep all that detail in their head?

So, I've tried to find and enumerate as many attribute values as I could so they are available at your fingertips when you need them.  Each enumeration is also annotated, so you get contextual help for the available values as shown below.

Here's another example that shows the enumeration of list template types when adding a ListInstance element to a feature.  This is a biggie.  How many times have you had to hunt down the table of list template type identifiers?

Installing the Enhanced Schemas

The CAML.NET IntelliSense download package includes an MSI installer that copies the extended schemas into the local Visual Studio schema cache, so all you have to do is run the installer and then close and re-open Visual Studio.  The current version handles both Visual Studio 2005 and 2008.

Note: If you're already using the wss.xsd schema from the 12 hive, you should remove the previous catalog file from the Visual Studio schema cache.  You may also have to fiddle with your IDE settings a bit because Visual Studio somehow remembers the previous schema settings and adds both the old and the new schemas for files that have already been edited, event after you have removed the old catalog file.  This can interfere with the new catalog file you've just installed.  In the worst case, you will have to choose "don't use this schema" from the "schemas" dialog for files you have already started editing.

As you can imagine, there are a LOT of elements and attributes to deal with.  I've made a pretty good start at addressing the most frequently used items, and I'll continue to add more annotations as my schedule permits.  If you find missing or incorrect annotations, please drop me a line or leave a comment and I'll update the schema. 

Now you can ride that CAML high in the saddle and head on out to the SharePoint.  You know - the oasis?  Right next to the 12 hive!  See you there!

"The camel has a single hump,
The dromedary two;
Or else the other way around,
I'm never sure.  Are you?"

- Ogden Nash

Stay tuned for CAML.NET 2.0!

Last week I had the privilege of speaking at the SharePoint Saturday event in Virginia Beach.  I talked about the upcoming release of CAML.NET 2.0, and I did a session on records management in MOSS.  The turnout was very good, with people coming in from all directions - some to speak, some to listen - but everyone came away with a very positive experience.

First of all, it was held at the brand-spanking new Advanced Technology Center at Tidewater Community College in Virginia Beach, which is kind of an interesting story.  It's actually part of the Virginia Beach public school system - an innovative approach to providing high school students with literally everything they need for all things geeky!

The list of speakers was impressive, and I've got to hand it to Susan Lennon and the other organizers, who did an amazing job their first time out.  Becky Isserman (who is coming to Jacksonville to speak at our next JOG meeting next month!) gave a great talk on using Silverlight in SharePoint.  Todd Bleeker was there and they had to arrange a special room just for Joel Oleson because of the large turnout.  Joel's talks were very interesting and provided everyone with a unique perspective on SharePoint Governance and strategies for migrating to SharePoint.

You can download my records management slides from here.

This "SharePoint Saturday" idea is picking up steam around the country.  There is another one scheduled for New York and probably more to come throughout the year.  It's kind of like a code camp just for SharePoint.  I'm looking forward to participating in more of them.  If there's one happening in your area, then I highly recommend it.

Stay tuned.

The SharePoint API can be vexing for developers who are not used to the little 'gotchas' that pop up here and there.  This can lead to lots of wasted time when all you want to do is determine if a list contains a certain field, or perform a standard operation on a list.  For example, say you have a task list and you want to get the list of overdue tasks or the list of tasks that will become due in the next week.  Of course, you could write the code in a separate utility library and pull it out when you need it.  But wouldn't it be great if you could simply extend the SPList object so that it included your custom properties and methods?

What I'm after here is a way to essentially derive a new class from SPList that includes my additional properties and methods without having to embed the original SPList object inside of it.  That way, I can pass the same object to code that expects a standard SPList object and avoid having to build additional infrastructure around my extended class to make it look and behave like a standard SPList.

Let's start with a simple example - determining if a list contains a given field.  Normally, we'd have to write this in a for loop or inside a try/catch block to avoid the exception that is thrown when testing for a non-existent field.  The code might look something like this:

Turns out that as of version 3.0 of the C# language (.NET Framework 3.5), it is possible to write your own custom code and attach it to any .NET class as an extension method.  The method appears as part of the IntelliSense for the extended class, and the compiler generates the appropriate IL code to call your extension method as though it were part of the class.  This means you don't have to own the code for the class in order to extend it or otherwise modify it in any way.

To add this method, you would start by declaring a namespace to hold your extension and then declaring a static method that takes an SPList as the first parameter, prefixed with the "this" keyword.  So the same method from above could be packaged as follows:

All you have to do to use the extension is include the namespace in your code.  The nice part is all that IntelliSense goodness and the handy illusion that your method is now encapsulated within the definition of SPList.

Extension methods can make it easier for novice SharePoint developers to approach the object model without having to divide their attention between the core API and custom class libraries, which tend to have a broader focus than simply extending a given component.