One percent inspiration, 99 percent perspiration (or “how I used an iPad for SharePoint development”)

To break a long-running blog silence, I thought I’d share a run-down of something I recently did. See, we were contacted to see if we could assist in a SharePoint project. The customer was having a number of problems with some custom code, and they had already run well beyond their original schedule. I stepped in, spent some time familiarizing myself with the code and fixed everything I could fix in a reasonable amount of time.

That’s not the interesting part, of course. That begins right after we deployed to production. Because obviously I made the rookie mistake of deploying right before I went on vacation. To top that off, I had spent considerable effort learning concepts that my colleagues weren’t familiar with, so obviously that left me with no fallback. In any case, off to Thailand I went with my wife.

Three days passed – we spent a couple of days getting used to the locale, and one Friday on an Intro Dive, trying out scuba diving – and I had already sort of gotten used to looking at sceneries like this:


Now, those of you who were facepalming and groaning at the end of the second paragraph can probably guess what happened next. I got a rather anxious contact from the customer. There was an issue in production, and it was clearly linked to my changes.

I spent a while gathering information on the situation and trying to provide clues to my colleagues if they were to try and tackle the problem without me. After a bit of back-and-forth SMSing with the parties involved, I began to feel that I really should try to do something about the problem myself. Only I was in Thailand with no computer.

Luckily, our hotel had two rather modern (albeit shabby looking) PCs, complete with Windows 7, cheap internet access and no protocol limiting. Obviously, I wasn’t going to get a development environment running there, but at least it gave me a stepping stone.

My first flash of insight came when I remembered a service called Vaasnet. Vaasnet rents out preconfigured Hyper-V virtual machines by the hour, and one of their preconfigured setups contained SharePoint Foundation 2010. I didn’t take that route at first, though, but instead started out with a blank Windows Server 2008 environment. The first thing I tried to install there was the Cisco VPN client I’d need to access the test environment.

Unfortunately, the VPN story wasn’t that straightforward. Cisco AnyConnect for Windows doesn’t allow for configuration of split tunneling on the client side, and I had zero chance of getting that changed at the server side during the weekend. So every time I tried opening the VPN connection, the client refused because I had a RDP connection open at the same time. For a moment, I considered going around that problem by installing VMware, going all Inception-like and running a VM inside the VM. But it turns out Hyper-V and VMware don’t really get along. Who’d have guessed…

Not to be stopped that easily, I fired up another Vaasnet machine. This time, a SharePoint Foundation instance, since I was going to need that to build my changes anyway. I installed a VNC server on the first machine, opened the VPN and tried VNC’ing in from the other instance – the idea being that the VPN client wouldn’t notice that I’m connected from a remote machine. Well, it worked, sort of. Except of course the VNC connection got cut off, because it was reliant on the same NIC that was now entirely tied up by the VPN.

I fiddled around for a moment, unsure on how to proceed. And then Vaasnet hit on one of their maintenance windows, and I was temporarily blocked from the VMs. So I did the reasonable thing: I grabbed a beer and went sunbathing for a couple of hours. A view like this certainly does help soothe the nerves:


After I got back to the hotel, I set out to install Visual Studio on the SharePoint VM. After that, however, I didn’t really know what I’d do next. So I grabbed my iPad and dabbled around for a moment. Then I suddenly remembered that I’ve got an app called Cloud Connect Pro that can do RDP. On a whim, I typed in “cisco anyconnect” to the App Store search, and I was rewarded with this:


I installed the client, and was pretty pleased with the prospect of at least having the VPN now. I could use the Vaasnet VM to build the solution I was working on, then transfer the files to the iPad. Finally, I could open up the VPN, connect to the test environment and deploy the package. Imagine my surprise, when configuring the connection details revealed this little gem:


See the “Connect On Demand” and “Domain List” there? That’s … split tunneling. So not only did the client exist for the iPad, it was in fact more configurable than the PC counterpart!

From this point onwards, the process was a fairly straightforward, if not too easy change-build-copy-copy-deploy cycle. During which I learned that Visual Studio is really tedious to use over RDP, and even more so on a touch keyboard. I was helped somewhat by ReSharper – the snippets that make my daily workflow smooth really helped over the slow network connection.

After about twenty cycles of testing and probing, I finally hit on the correct solution. Typing the email wherein I asked the customer to try it out was one of the most satisfying work-related things I’ve ever done.

That said, I didn’t mind finishing my beer and turning my attention to this:


(We spent the rest of the weekend buried in the PADI Open Water Diver manual. Then, we started the following week by completing the course itself.)

Good times!

Post Crunch Mode

The previous weekend was a disaster.

I’ve been taking part in a project, immersing myself in SharePoint to better learn it. We had a production deployment deadline on the Friday, just before last weekend. It didn’t exactly go as planned – some bits weren’t as finished as we thought, others were altogether missing. I worked a 14-hour day on Friday, and then we came back on Sunday. That was even worse. We began working around one in the afternoon, and I got to bed around 6:15 in the next morning, after a mad 17-hour dash to force the thing together by sheer willpower.

I slept about five hours, then went back to work for a nominal four hours. On Tuesday, I was at the office for a full day, but I felt like my brain was drained. I was barely functioning. The same was true on Wednesday, at which point I decided to take Friday off altogether. Thursday was a national holiday, so all together it meant four days of rest, which did me a world of good. In addition to that, I went to TEDx Helsinki on Wednesday at noon, so it was a rather light week. Still, I kept feeling the effects of the all-nighter for a long time.

I’ve been reading “Pragmatic Thinking and Learning”, and I came across a passage that described this phenomenon rather well:

“Not only are you less creative when battling the clock, but there’s a sort of after effect: a time pressure ‘hangover’. Your creativity suffers on the day you’re under the gun and remains depressed for the next two days as well.”

Yeah, I can attest to that.

The twisted bit is, our work culture rewards this kind of behavior. There’s generous overtime pay, the appreciation of superiors, acknowledgement of the heroics by peers and what have you. It’s all geared towards working under time pressure. That is, towards working less effectively. Not to mention the time wasted recovering.

(Mind you, I’m not talking about timeboxes – it’s a good idea to limit the time you allocate for a single activity – but real time pressure is a different beast altogether.)

It’s curious, how after reading my “Slack” and “Peopleware”, I’m still just as susceptible to being pulled in as I ever was.

We can do better than this. The madness needs to stop.

SharePoint web part lifecycle

For various reasons, I’ve found myself doing Web Part development for SharePoint 2007. While I suspect I’ll be blogging more thoroughly about it later (possibly even via SharePoint Blues, who knows) , I thought I’d contribute my first useful SharePoint link: The lifecycle of SharePoint Web Parts.

My WebForms experience is rather limited, but on the surface, the list looks a lot like a WebForms control’s life cycle. The reason I needed this list specifically is that I wanted to know the point at which I could safely assume that other web parts would be connected and their data would be available.