Tonight’s Forecast: Cloudy with a Side of SharePoint

I just got back from a nice little event put together by our friends over at SoftArtisans called “Cloudy with a Side of SharePoint”. It was a freeform discussion at a local beer pub on all sorts of topics, but nominally “What’s up with SharePoint in the cloud?”.

Of course, you can get a bunch of techies together over beers without the conversation ranging all over the place (it was great to catch up with some folks I haven’t seen in a while), but we did indeed talk about SharePoint in the cloud.

Some of the more interesting takeaways for me…

Having servers in the cloud where novice developers can’t break things very easily (the sandbox is *supposed* to make that the case) means that the number of developers expected to start working with SharePoint over the next 3 to 5 years may be more possible. As more and more techies jump onto the SharePoint bandwagon – it’s everywhere, don’t you know – we have the danger of even more horribly badly implemented solutions than we’ve had in the past. SharePoint is a truly huge beast and it takes a *very* long time to get good with it. By adding a protective barrier between SharePoint and these newbies, the ecosystem may grow more safely and even faster.

The possibility of increased uptime because “the cloud” is a dedicated service (we were generally lumping together Office365 with FPWeb in the conversation tonight, but there are other good shops as well) with highly trained people running it (we hope, and so we’re told) can certainly be appealing. Interestingly, no one I talk to really seems to care about the “money back guarantee” behind Office365. After all, if it’s down, it’s down, and if your content goes missing, the money you get back certainly won’t cover it.

Finally, as we went around the table, it was interesting that even in a relatively small group there are very different views on what “SharePoint in the cloud” means as well as the impact it may have on each of us. The small-shop, high end consultants worry about developing in Office365’s sandbox and what it takes away; the partners who develop products see issues when it comes to licensing and as well as new opportunities; and of course there’s me, thinking that the cloud doesn’t change a heck of a lot about how I think of SharePoint, though there may be more people interested in the courses I teach at USPJA.

It was great to join in the banter with Ian Dicker, Ryan Thomas, Rob Windsor (Rob is infiltrating the US from his native Canada and his incursions have not gone unnoticed. First BASPUG last night and then CWASOS tonight.), Mike Gilronan, and Claire D. Willett, Ben Jones, and David Wihl from SoftArtisans. Unfortunately I was a little late and missed my pal Sadie Van Buren who had to cut out before I got there.

And no, there was no BAITR tonight, at least not at my end of the table.

p.s. Claire called it both CWACOS *and* CWASOS, so I’m right either way. She and Ben want it to be a monthly thing, so stay tuned if you’re in the Boston area…

Office365 Makes Developing in SharePoint’s Middle Tier More Relevant

If you’ve stuck your head out from under your rock at all recently, you’ve heard about Office365. There was a huge hullabaloo in NYC and elsewhere yesterday to accompany the “big announcement” (which most of us have been hearing about for probably six months now) as Microsoft launched Office365 globally .

It may not surprise you to know that the reason I’m excited about Office365 has little to do with Office365 itself. Office365 is simply SharePoint (with Office, Exchange, and Lync too, but I’m all about SharePoint) in “the cloud”. Some of us have been using SharePoint in the cloud for a long time already, through the good work of people like FPWeb. In fact, I’ve had my Sympraxis Consulting site in the cloud with FPWeb since late 2008 and it’s where I do all of my SPServices development as well as where I host my public-facing site. (Yeah, my public-facing site for Sympraxis is a bit tired; it serves me little purpose in the grand scheme of things, though is is where you can see my demos and such.)

So why does Office365 have me excited? Why, its limitations, of course! For every whine I hear from a “real” SharePoint developer, I see an opportunity for a SharePoint Middle Tier developer. All of the Middle Tier development techniques work great with hosted SharePoint, regardless where it is, because we don’t need to touch the server. All of our code (XSL, XML, CSS, jQuery, JavaScript) goes into the database just like any other content.

So if your organization is thinking about moving to the cloud, seriously think about which business requirements you can fulfill by developing in SharePoint’s Middle Tier.  Read the white paper called The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint which I wrote last April and see if it doesn’t start to make a little more sense now that you’re thinking about cloud computing. (Yes, I can be prone to saying “I told you so”, but I won’t do it this time.)

My recent survey about SPServices usage (more details on those results will be forthcoming) says that 26% of SPServices users may be heading in the cloud direction, and they are already well-equipped to take advantage of it.


Here comes a shameless plug for a business I’m a part of and extremely passionate about. If you’d like to learn more about Middle Tier development techniques, consider taking one of my courses at USPJ Academy. I currently have three courses available in both collaborative and self-paced versions which cover SharePoint’s Middle Tier:

  • Data View Web Part Basics
  • Enhancing the User Experience with jQuery
  • Introduction to the SharePoint Web Services

So hurray for Office365!

SharePoint Myths – Part 2

DaVinciCode.jpgLast week I had the privilege to hear the well-known author Dan Brown speak at a dinner for my alma mater, Phillips Exeter Academy. You undoubtedly have heard about a little book he wrote called The Da Vinci Code. Not only is Dan a talented author, but he’s also a deep thinker on topics of religion vs. science, and by all accounts a genuinely nice guy. Dan talked about a concept I don’t think I’d heard about before: Proof by Incredulity. Simply put (and probably paraphrasing Dan unfairly), the idea is that there are times when we look at two known (often opposing) possibilities and because one seems absolutely impossible to us (we’re incredulous), we decide that the other must be true. Thus the endless debate about creationism vs. the Big Bang. We decide that the one which seems far-fetched to us must be false, thus the other is true. We usually don’t consider the fact that there may be “middle truths”, or blends of the two truths which are the actual case.

About a year and a half ago I did a post called SharePoint Myths – Part One, thoroughly expecting that it would be a long series of posts. I haven’t gotten back to it until now, though I certainly try to dispel myths whenever and wherever I can. Sometimes this makes me seem like I’m pooh-poohing what others believe, but that’s not it at all. I just want to try to add to the discussion by avoiding proofs by incredulity or any other lack of hard facts.

So what does all this flowery (hopefully not precious) rhetoric have to do with SharePoint Myths? Well, a few days ago I spotted yet another discussion about where to store scripts within SharePoint, this time over at SharePoint Overflow in the thread Where do you deploy scripts that are loaded in a masterpage? There have been many threads on this topic that I have spotted over the last year or so as jQuery, in particular, has become more popular. (The best thread, IMO, was at the old SharePoint Overflow. It seems that the Stack Overflow overlords have decided to disappear all of the old content in the migration to SE 2.0. Bad move. The upshot in this case is that I can’t point you to a really good thread.)

<UPDATE dateTime=”2011-06-08″>
The overlords restored all of the old content since I posted this, so here is that really good thread I wanted to point to originally.

The discussion usually devolves into a lot of absolute statements about how large script files are and what a huge expense they add to page loads. I’ve always believed that this wasn’t the case, based on everything I understand about how browsers work. In most cases, browsers cache files like script files and images locally to reduce unnecessary HTTP traffic. But might I be wrong? Could it be true that SharePoint wasn’t smart enough to allow caching of frequently downloaded files?

I’m a big fan of empiricism. Facts are far more immutable than innuendo. I’ve especially enjoyed some of James Love’s recent work on benchmarking where he doesn’t take things for granted. If he doesn’t see the data, he ain’t buyin’ it. That’s just plain good thinking. Check out his recent blog posts SharePoint 2010 Performance with Item Level Permissions and SharePoint 2010 Performance with Item Level Permissions Part 2.

I’m going to apply nowhere near that sort of rigor here, but I am going to show you some real, live, actual facts based on some small tests I’ve run.

I like to store my scripts and CSS in Document Libraries, generally at the root of the Site Collection. So if I do that, am I incurring a huge overhead in the browser? Well, I turned to my environment where I develop SPServices. It’s a WSS 3.0 site hosted by FPWeb “in the cloud”. (When I first set it up, it was just hosted by FPWeb. Now it’s “in the cloud”.) Given that it’s WSS 3.0 and it’s multi-tenant, one would expect that it is sort of the lowest common denominator when it comes to sophistication. I’m not saying that the good folks over at FPWeb aren’t doing a great job keeping it running well (they are). I’m just saying that there’s less you can do to tune that environment than some fancy-schmancy SharePoint 2010 Server farm.

I have a test page I’ve been using lately for developing the new $().SPServices.SPComplexToSimpleDropdown function (still in alpha). It’s a basic EditForm which I’ve customized and of course I’ve added references to the jQuery library and SPServices. I took at look at the network traffic when I load that page. First I loaded it in IE and watched the traffic with Fiddler since IE8 doesn’t give me any capability to do so:


Huh, the requests returned a 304, which means that the file hasn’t changed since the last download and therefore the browser will use the cached  version.

Well, that could be due to Microsoft’s affinity for the Level 1 IE browsers, right? Let’s take a look with Firefox. Firefox with the Firebug extension gives me the capability to watch the network traffic:


Huh. Cached again.

Let’s make a change to the SPServices file and see what happens. As expected both browsers downloaded the fresh copies of SPServices from the Document Library.



Refresh again in each:



Cached again.

Even when the file is reloaded, the byte count is about 45k. This is also interesting because I’m loading the unminified version, which actually weighs in at 143.88KB (147334 bytes). The smaller download size is due to the fact that both IE8 and Firefox Gzip files when they are downloaded. (Sure, there are some older server OSs which may not support that, but we’re talking about SharePoint and IIS here.)

Again, the point here is not my rigor. I’ve only done a couple of refresh-change-refresh cycles. I’m not going anywhere near as far as James has investigating performance for item level permissions. However, I have at least tried to see what the real situation is.

Script files in Document Libraries in my test environment are indeed cached. Now I know for a fact that there are all kinds of ways to make this not be the case. Most of the instances I’ve run into were just plain mistakes and caused by a lack of understanding of the tools involved. For instance, an F5 set to never allow caching (yeah, they are built for load balancing, so…) or forced browser policy settings which reduce the possibility of caching. The point is that you need to look at real data in your own environment. As with everything in SharePoint (and really all software use and development, plus much of life), it depends. Telling people with authority that something is an absolute truth without taking a look into the details is abhorrent in my book.

Statements like “I would think that…” or “One time I saw…” are fine because they are essentially disclaimers. Statements like “It is always the case that…” or “You have to…” imply authority based upon actual knowledge. If one doesn’t have actual knowledge, then one should avoid presenting their thoughts as such.

Ultimately, it becomes a discussion based upon proof by incredulity. “SharePoint does all of these things I know about wrong or oddly, so I know it can’t do this part right.” Uh-uh. Do some testing. Gather some data. And use language that indicates what your *actual* level of knowledge is. We’ll all be better off because we’ll have better information to work with.

BTW, I think storing scripts in Document Libraries is a grand idea.

Comcast Email Woes – Part Two (And Final?)

Image representing Comcast as depicted in Crun...

Image via CrunchBase

You just knew that there would be at least one more post on this, didn’t you? I certainly did, thus the Part 1 (Probably) on the last one.

For those of you who don’t read every single one of my posts (shame on you), I had been having trouble sending email to my wife’s Comcast email account for about a week. I contacted Comcast to try to figure out why and had a less than satisfying experience so I decided to post about it. Well, as of yesterday, things seem to be back to normal. Of course, I haven’t heard anything at all from Comcast, nor do I really expect to. So problem solved, I guess, and me none the wiser.

One thing I didn’t mention in my other post was the great experience I had with my email provider, on this, as well as any other things like this. Whenever I put in a ticket with FPWeb, I get fast, helpful responses. No, they can’t always solve everything instantly, but that’s the way the world works. The point is that they try hard, they are pleasant about it, and they get it done. That’s why when the guys over at FPWeb told me that they thought the issue was on the Comcast end, I believed them.

In fact, when I wrote the first post and let them know about it (just because I thought they would get a kick out of it) Eric at FPWeb took it upon himself to fill out the Comcast form that “Roselyn” sent me to ( as well, just in case it might help.

I can’t say much for Comcast on this one, but as usual, I’ll recommend FPWeb. I use them for both my Exchange-based email and my SharePoint (WSS 3.0) hosting, and they are great. And no, I’m not getting anything for saying this; I’m just a happy customer. Given that I’m a one-man band, they certainly don’t have to pay as much attention to me as they do. But they do, and that matters a lot.

The Magic of Hosted WSS

Whoa, I’m really falling down on my blogging lately.  It’s not that I don’t have as much to say, it’s that Twitter and other things end up taking more of my time these days. ("Microblogging" is the word we use to make tweets legitimate.)

So here’s something. I think I may have outlined this a bit before, but I thought it might interest someone out there to know how much I manage to wring out of my $29/month of hosted WSS.  My friends over at keep me up and running and manage to make me feel like a Very Important Customer, even though Sympraxis Consulting is just a one man shop at the moment (that would be me).

WSS is generally pooh-poohed by the SharePoint aficionados out there as too low end to be useful.  (Of course, Microsoft would also love it if everyone purchased licenses for MOSS.) However, I’m using my WSS site for a number of things, and I think that this is pretty impressive given that it’s free software:

  • As my Internet-facing site ( — This is fairly vanilla, though I do have a custom master page with custom CSS and a little jQuery just to give it some sizzle.
  • As my Intranet (permission-protected)– While I have a custom master page and CSS applied here, the branding serves little purpose other than to give me a visual cue where I am.
  • As my Extranet (permission-protected) – When I’m working with clients, I set up a site for each where we can share documents, etc.  These are plain vanilla Team Sites or even Blank Sites to start. To date, these sites have gotten very little use.  (It’s always surprising how little people who hire you to build SharePoint stuff for them actually want to use SharePoint to collaborate on the process!)
  • As a demo site for some of the stuff I build ( – This is a vanilla Blank Site with some customized pages with JavaScript, jQuery, etc., which I use as a place to demo some of the jQuery Library for SharePoint Web Services functionality and some other stuff.
  • As my development platform for my jQuery Library for SharePoint Web Services (permission-protected) — This is where I’m doing my "work".

All this without ever touching the servers!