Peter Seale's weblog

Thursday, November 06, 2008 8:16:47 PM UTC 
I had a moment of sudden disorientation during an elevator ride recently.

First, let me explain the elevator setup. In our fancy downtown building, we have a bank of five (or is it six?) elevators. Our elevator bank is housed in the center of the building, lining both sides of a short hallway. As fancy as we are, we aren't fancy enough to justify glass windows or any of the other elevator luxuries. The doors open, you get in, the doors close, and your new, smaller world is the four brushed-metal elevator walls.

So, as the scene had played out hundreds (or possibly thousands) of times before, the doors opened, I got on the elevator, the doors closed. This time, however, I was distracted—more so than usual—and wasn't paying too much attention to where I was walking.

As the elevator began its descent to the ground floor, and as is quite unusual for me, I had a new thought intrude—which elevator am I on? And which way do I turn when the door opens—left or right? I had no idea.

And for a brief moment, I was suddenly disoriented—almost in a physical sense.

We'll get back to the elevator story in a moment.

Conference that shall not be named so that keyword searches shall not pick it up

Last weekend I attended the open spaces event in Austin, and while I'd like to post something saying "it was a great time, well worth it, etc," I can't. There were only two impressions I have after attending the conference.

One: I'm not ready. I'm not even currently using the tools discussed by (and at times, designed by) the other attendees, nor (with my current technology stack) am I planning to use them. Tools aren't everything; my "I'm not ready" feeling also goes for the softer topics like lean/agile/kanban, which are definitely of interest to me, but not in the sense that I have any authority to make changes outside of myself. I'm not a "Big Tymer" like Manny Fresh and Baby.

Before we move onto the second impression, let me talk for a second about my learning queue, by way of Billy Hollis.

Learning queue

I listened to a fascinating Deep Fried Bytes podcast interviewing Billy Hollis. Most interesting to me was his discussion of how no one is keeping up with the .NET framework—while Microsoft is now pushing Azure and Windows 7 and C# 4.0 and whoops, throw out the old Workflow Foundation, we're pressing the reset button on Workflow 4.0—while all this is happening, of the developers Billy Hollis interviews, only ~1 out of 10 are using generics. Generics, which were introduced in 2005, and as Billy Hollis pointed out, not a large topic to learn, are still not in regular use by 9 our of 10 developers.

Sample bias noted, even if the developers he interviews aren't representative of the developer population, this is still something to sit up and take note. The key takeaway is that almost everyone is far behind. And he illustrates this with some stark (if anecdotal) numbers.

Meanwhile, over the last several years I've focused on SharePoint. I've been learning about web parts and workflow and InfoPath and web content management publishing features and ASP.NET app pools and IIS6 and XSL and Solution packages and Feature packages and governance and taxonomies and IA and so on—I've immersed myself in the SharePoint world. It was tough to keep up, especially given the magnitude of SharePoint itself.

But, at some point in the past, I publicly and officially declared, "I'm done." No more SharePoint learning, except what I need for my job, today. And it's really freed me up, in terms of mental weight. Now that I know I no longer need to learn how to do SharePoint workflow, for example, why would I ever want to learn it—especially now as they've announced WF4.0 will be completely new? Why would I want to research SharePoint object disposal best practices, when I myself no longer need this to get things done at work?

But something else happened, something unintentional. At the moment I declared I was no longer going to learn SharePoint—at that moment I experienced a similar moment of disorientation. If I'm not going to be a SharePoint guy in the long term, what now? The elevator doors will open soon; left or right?

Back to the conference

And we're back to talking about the open spaces conference I just attended. This was the conference where I was to meet up with what would become my new community of practice. This would be the group with which I could identify.

But for whatever reason, it didn't work out that way.

I've already mentioned that at the conference, I got the strong impression that I wasn't ready to attend; that I needed to do some homework before even being able to process most of what was discussed in the sessions, much less contribute.

Surprisingly, at this conference I also had a strong moment of disorientation again. Instead of cementing my understanding of software development into a rigid cast, and allowing me to fall into something of a comfortable pattern as I expected, I felt distinctly less comfortable afterwards.

I don't think it's necessarily a bad thing to be uncomfortable. If we're following the elevator story from earlier, a dubious metaphor to begin with, but hey, here we are at the end and we can't exactly go back and invent a new and possibly worse metaphor—well, let's stick with the elevator story. At the open spaces conference last weekend I experienced a kind of career vertigo—I'm in the moment just before the elevator doors opens. It's uncomfortable, but I'm sure the sensation will pass. And when it does, my world will have grown.

Tuesday, May 20, 2008 8:00:39 PM UTC 

This last Saturday I attended the Austin Code Camp 2008. I didn't take notes so am unable to post coherent bullet point recaps of each session; instead I will post what must be, by logical extension, incoherent.

The Krewe of Austin

Something is noticeably different between the various Houston community events and the code camp I attended in Austin. A few notable things about this code camp that I liked:

• The code camp did not feature an "Introduction to Silverlight" session. This is the simple, effective test by which I will measure all future conferences: is there an intro to Silverlight session. If there is, then good chances are most of the sessions will be useless. Further down the road, change out "Silverlight" with whatever new UI framework/data grid/designer tool that is "up to two years away from release." I'm officially tired of these type of talks, 4 LIFE. Call me back when you're running a "Best Practices in Silverlight Smackdown."
• The code camp was heavy on OO principles. This is a good thing; between "patterns cage match" and "IoC jumpstart" and "OO design" and "mocks and stubs", my brain was assaulted by lots of OO. Which is good, I haven't gotten this much in the 3+ years of involvement with Houston user groups and events. Not to gripe on my home city, let's stay positive etc.
• The remaining slots were filled by oddball (but useful oddball) sessions—in particular I liked our "Sarbanes Oaxley fishbowl talk" with heavy audience participation. I also liked the advanced SharePoint session, which helped me identify two major bugs in my project that I discovered by asking about the presenter's 12 lines of code. Let me repeat this for emphasis: he only had time to show the barest minimum of code, and yet I managed to pick up two places I need to change my own code, from that tiny snippet shown for just a few minutes. Sigh, SharePoint is hard sometimes.
• Informal and efficient. You kind of showed up, you picked up a drink in the hall if you needed one, the presenters passed out books at the end if they remembered, registration took no longer than any other user group meeting. Self-service over concierge; it worked; awesome.

#1 benefit of attending: INSPIRATION

As sarcastic as I usually am, I want to let you, my dear reader, to know that the following is genuine and there will be no punchline involving abhorrent use of embedded MIDI and/or MARQUEE tags and BLINK tags that still work in Firefox for some reason.

But really, I did get one thing out of the code camp that I can't say I get anywhere else: I left feeling inspired to get awesome. I don't know at what precisely, I don't think it matters. What matters is that I've got the energy now. I'm motivated.

Yeah, now to act on newfound motivation—noted. Track record: not good; will try anyway.

So what do we take away from this rambling incoherent post?

1. Thanks to the organizers/speakers of the code camp, it was awesome and at least one person (me) enjoyed it. I would like to place an order for ONE MILLION MORE of these camps; please schedule at your earliest convenience.
2. I'm looking forward to the Houston Techfest 2008 [placeholder link; website not updated from 2007]. If anyone reading this a) also hates intro sessions, b) is willing, and c) is competent enough to be an authority on a given topic, please submit your session to the Houston Techfest organizers. You can even be from Houston, you don't even have to be from Austin to give a good presentation. It's great how that works.

Monday, May 05, 2008 8:00:29 PM UTC 

I just fixed an odd 403.14 server error on my Server 2008 VM, and what was the problem? My application was set to the "DefaultAppPool" app pool. The cause? "DefaultAppPool" doesn't exist, and yet my web site is somehow set to run on "DefaultAppPool". "DefaultAppPool" didn't event exist at the time I created the web application in IIS, much less now. By all means this should not have been a problem—IIS should set newly provisioned web sites to an existing, non-imaginary app pool—yet it was a problem.

So, advice: don't delete the default app pool, even in the new hotness that is IIS 7 and Windows Server 2008. You certainly can do so—I'm not saying it's impossible to get along without the default app pool; I'm just saying that you'll have surprises. And not the "congratulations, it's the prize patrol" type surprises, more like the "congratulations, your vehicle has been towed!" surprises.

You don't have to take my word for it—instead listen to Joel Oleson (talking about IIS6), and I quote:

Wednesday, February 27, 2008 10:30:22 PM UTC 

Declaration: I'm overwhelmed

I've been cranky recently about Silverlight, and I admit, it's not all warranted. What has been particularly bugging me is everyone's open-armed welcoming of YET MORE CRAP TO LEARN.

Learning one language a year: we'll try

I've also been cranky about the Pragmatic Programmers' "one language a year" quote. Dave and Andy, circa 2001, did not have to take into account the flood of Microsoft-centric frameworks, tools, and products in which we're all drowning. Scott Ambler has a fun diagram on his site that lists ".NET" as a single data point on his skill investment portfolio. One!

.NET: more like thirty

Leon Bambrick has posted a list of items he will NOT learn. This is an excellent start, but by no means a final list. Let's try out my list:

Not learning on my free time, from Microsoft

I'm taking a stand against learning all of this on my free time. Something (a lot of somethings, as you will see below) has got to give.

By all means, I'll browse an introductory session in order to get a vague idea of what each one of these things do; for whatever sick reason, I don't mind listening to 15 hours of audio podcasts a week. With all these podcasts, I figure I can get a glossed-over introduction to pretty much anything. But I'm not going to, say, try and run a hobby project with anything listed below.

Here goes.

Frameworks/libraries

1. Astoria
2. Volta
3. Entity Framework
4. LINQ to SQL
5. LINQ to XML
6. WCF
7. WPF
8. WPF/E - Silverlight
9. Atlas/ASP.NET AJAX
10. ASP.NET WebForms
11. WinForms
12. Smart Client Architectures
13. CAB
14. Enterprise Library (this should count as thousands of points)
15. VSTO
16. DotNetNuke
17. Acropolis - ok, thankfully this has been canceled. One less thing to learn.
18. XNA
19. .NET Compact Framework
20. .NET Micro Framework
21. Mobile development
22. .NET Tiers - or whatever the code generation framework is called

Office developer technologies

1. "OBA" - my summary is that I think this framework is the 100% best choice for 0.1% of all applications built. So is it worth it for you to learn?
2. The various older Office technologies you probably aren't even aware exist (Outlook Forms anyone? Yeah, thought so).

Languages

1. Boo
2. F#
3. Spec#
4. AnythingElse# 
5. IronPython
6. IronRuby
7. IronAnything
8. PowerShell V2 features (no way! I know.)

Server Products

1. Project Server (MOPS) - yes, I'm aware this runs on top of SharePoint. Remember this is my free time.
2. BizTalk
3. SQL Server
4. Active Directory
5. Exchange
6. Office Communication Server (or whatever it's called; the PBX/IM/telephony server from Microsoft)
7. IT related products (MOM/SCOM)
8. IAS
9. TFS admininistration/customization
10. Server 2008 - well, at least the parts I'm uninterested in. This is one of the few things I think may be worth my time. Then again, the server product line seems to be the most quickly expiring skill (Server 2000 skills in demand, anyone? I thought so).

Non-Microsoft technologies

I'm holding off doing in-depth learning of the following, despite my interest in them:

1. Python/Django and/or TurboGears
2. Ruby/Rails and/or Merb
3. ANTLR
4. Emacs/Lisp of some kind
5. Linux OS - for the Mono stack. I've dual-booted in the past, but I just don't have the energy to keep up with anything Linux.
6. Perl - believe it, Perl.
7. SAP ERP - just kidding! That's just crazy talk. I'm not crazy, which is why I work with SharePoint.

That feels better

I assure you that my technical learning queue is absolutely huge; I won't talk about it today (IT'S BORING!). But look at all the junk I'm NOT learning! Isn't this appalling? What's more appalling, is that at one point in time I believed I should be keeping up with all these things! No way, not anymore—it's liberating to be able to just, ignore something. I'll be frank: it's an awesome experience. Definitely try it sometime. Try it out on your boss*! Just, Ignore

* Do not try this

Wednesday, February 27, 2008 10:00:17 PM UTC 

"Learn at least one new language every year."

    -Andy Hunt and Dave Thomas, The Pragmatic Programmers

For a while now many of us in the .NET space have complained of the never-ending torrent of new technologies and frameworks coming from Microsoft. While excited by the potential benefits (and yes, the shiny bits), we're so inundated with NEW that it's impossible to keep up. Something has to give.

Arrival stage left: the Pragmatic Programmers, circa 2000/2001, who inform us in their "Your Knowledge Portfolio" section that in order to be well-rounded developers, in addition to the learning we do related to our job, we need to set a goal to learn at least one new programming language every year.

What's unfortunate about this whole situation is that I actually think this advice is harmful.

One language a year: unattainable

No one learns a language a year, year after year. Except Ted Neward, and let's face it, he's nuts, and therefore doesn't count. So why should we set it as a goal? So we can fail, unless we're Ted Neward? GREAT.

Now I'm depressed

Why set unrealistic goals for ourselves?

Why a year?

Why not 18 months? Am I still broadening my horizons if I take 18 months to learn Lisp? or 10 years to learn C++?

Alternative to '1+ language/year'

Instead of hyperfocusing on '1+ language/year', why not take other advice offered by the Pragmatic Programmers on the very same page? I particularly like the way they present learning as an investment [the following is paraphrased]:

• Invest regularly
• Diversify portfolio
• Balance portfolio for risk
• Buy low/sell high (get in on technology early)
• Portfolio should be rebalanced periodically.

See! All this is useful, spot-on, helpful advice! And what's more, I don't even feel a sense of crushing despair!

Generalizing specialists

Let's work this from another angle: on this page Scott Ambler discusses what it means to be a generalizing specialist. The summary, by example, is that instead of sticking your head in the sand and learning SharePoint Designer 2007 to the exclusion of all other things (i.e. becoming a 'specialist'), you make a conscious effort to learn things that are NOT related to SPD 2007, however lucrative it may be at the time.

Nowhere on the description of generalizing specialists is there a mention of yearly language learning quotas.

So what language are you learning, Peter?

I'm going to make a conscious effort this year to learn C#. Wait a minute dude, I'm supposed to know C# already! Well, sure, yeah, but I would like to, you know, REALLY know C#. I would like learn C# such that I'm effective with it—such that when I read Bill Wagner's Effective C#, I'm not surprised by any of his 50 discussions of C# programming. Think about it.

I want to learn all the C# 3.0 features, aside from LINQ. I don't even honestly know if there are other 3.0 features, oops. Wait, extension methods. Awesome, I didn't totally forget.

I'd like to learn C# to the point that the very sight of Java code disgusts me. I want to see an Eclipse window and feel the physical urge to puke. That's how awesome at C# I want to be.

I'm not going to promise I will be C# dominant by EOY 2008. It may take longer. But I will work at it, on a regular basis. And I will get better.

And I think this is all the Pragmatic Programmers ever intended in the first place: pick a language; learn it and gain some perspective; pick another language; absolutely don't stop learning after your first language; don't take too long to learn the new one; constantly learn. There we go; that wasn't so bad.

Tuesday, February 19, 2008 2:00:37 AM UTC 

While writing my last (admittedly-grumpy) update, I made a reference to the fact that I couldn't get Silverlight working on Firefox. As it turns out, as it always turns out, it was me.

Culprit: Flashblock

My exotic Firefox plugin ecosystem, specifically Flashblock, was to blame. What was happening is that the magic that was allowing me to browse the web sans Flash ads was the same magic that prevented Silverlight from loading. Unlike its excellent "opt-in" Flash placeholder, Flashblock blocks Silverlight, period. Flashblock was in fact, acting a little too well.

Thankfully, at least from what it says in the Flashblock changelog, it looks like Flashblock will soon support Silverlight. Phew! For a moment there I was going to have to make a difficult decision: absence of Flash, or presence of Silverlight? Crisis averted!

While we're here - Silverlightblock

I know I may be way ahead of the market here, but could someone go ahead and make a SilverlightBlock plugin? So that, by the time someone figures out Silverlight is an excellent platform for obnoxious and intrusive multimedia advertisements, I'll be prepared? THANKS IN ADVANCE!

Saturday, February 09, 2008 1:47:05 AM UTC 

I've just finished reading this entry titled Why Microsoft Will Win and Dominate the Web linked off of DotNetKicks.com. The author of this blog post claims that, as Microsoft succeeded in the 80s by creating a better developer platform (the original Windows was a better developer platform than the Mac), Microsoft will again succeed by creating a better platform. This time Microsoft's platform is Silverlight, and it is poised against the web.

Let's be very clear about this:

• Silverlight 2.0 is in an early alpha/unstable state.
• Silverlight 2.0 does not emit standard (or even quirky) HTML. As such,
  • it cannot be indexed by search engines, and
  • it will not work on mobile devices. We'll get to the "mobile devices" bit later.
• Last time I checked, Silverlight 2.0 had less than 5 controls to use. E.g. textbox, button, dropdown control. I'm fuzzy on the specifics; there might have been as few as 0 (zero) controls. No databinding.
• The last four times I tried it, Silverlight 1.0 would not install on Firefox on Windows. I don't know why either, but I do know it doesn't bode well for the future.
• The MSDN home for Silverlight reference material lists a grand total of about 30 pages (as of 2008-02-08).

The checklist represents Silverlight 2.0, today. In my opinion, this is the only legitimate Silverlight you are allowed to talk about. And let me tell you, the Silverlight above, as of today, isn't going to dominate anything.

So when I read a description of Silverlight 2.0 that looks something like:

• A platform on which fantastic applications can be built.
• The best development toolset provided for the web.

If you compare their list with my list, let's just say they don't match up one for one.

Where did they go wrong?

How could we veer so far from each other, and still talk about the same product? Am I overly pessimistic? Yes. Yes, I am.

Magical Fairyland Silverlight

What has happened is that this guy allowed his enthusiasm to get away from him. Which is fine; it's good to be enthusiastic. However, what's not okay is that, in his enthusiasm, he mistook Silverlight with "magical fairyland Silverlight." Instead of describing Silverlight's impact on the future web, he got a little turned around, and perhaps, just perhaps, a little carried away. What he ended up describing was not the future Silverlight platform, but a mirage.

With this context in mind, let's compare the two lists again:

Silverlight 2.0, as observed by Peter Seale, 2008-02-08:

• Silverlight 2.0 is in an early alpha/unstable state.
• Silverlight 2.0 does not emit standard (or even quirky) HTML. As such,
  • it cannot be indexed by search engines, and
  • it will not work on mobile devices. We'll get to the "mobile devices" bit later.
• Last time I checked, Silverlight 2.0 had less than 5 controls to use. E.g. textbox, button, dropdown control. I'm fuzzy on the specifics; there might have been as few as 0 (zero) controls. No databinding.
• The last four times I tried, Silverlight 1.0 would not install on Firefox on Windows. I don't know why either, but I do know it doesn't bode well for the future.
• The MSDN home for Silverlight reference material looks like it's a grand total of about 30 pages (as of 2008-02-08).

Magical fairyland Silverlight:

• A platform on which fantastic applications can be built.
• The best development toolset provided for the web.

Now it makes sense!

The Golden Rule

PLEASE stop comparing unreleased, FUTURE versions of your product with the CURRENT crop of competitors.

In this case, it's especially important to note that magical fairyland Silverlight (or anything moderately resembling it) won't be released anytime soon, because in the future, by the time something resembling magical fairyland Silverlight actually arrives, it might already be too late! Consider the following emerging markets:

• sub-$200 laptops
• 3G cell phones
• iPhone
• iPod
• BlackBerry
• Google's Android
• TV set-top browsing devices (e.g. gaming consoles, DVR)

Do all these things run Silverlight? By the time we're all checking our GMail from our iPhone on the bus, or checking our "Microsoft Live Passport Flickr For The Web" from our SmartPhone, IM'ing from our iPod, or emailing a Google spreadsheet on our android phone, will those devices be Silverlight compatible? Will search engines update themselves to index Silverlight content by then, or will our Silverlight apps remain invisible to Google search? Like so many other technologies have done in the past, will this platform sink as well? I don't know. BUT NEITHER DOES THAT OTHER GUY!

This happens all the time

Don't get me wrong; this sort of thing happens all the time. .NET guys compare .NET 3.5 to Java 1.1. Java guys compare Java 7 to .NET 1.1. Windows guys like to complain how expensive Macs are; Apple guys like to complain about how insecure Windows is. Linux guys complain about IIS security. SharePoint guys like to put on the rose-colored glasses when it comes to describing the SharePoint pie chart of features.

It's everywhere if you look for it.

I guess I just had to write this up, on behalf of all the other times I've seen this sort of wishful thinking happen. If you take anything away from this post, let it be "don't get caught up in the potential of a product without taking a hard look at what it is, today." There, that wasn't so bad.

Tuesday, October 09, 2007 4:43:48 AM UTC 

And to clarify, this is a good thing!

Maybe you haven't all heard the news: Microsoft is developing a new ASP.NET MVC framework. Go check out the original story for details. I'll cut-and-paste the featureset directly lifted from Jeffrey Palermo's entry:

ASP.MVC framework, summarized

• Natively support TDD model for controllers.
• Provide ASPX (without viewstate or postbacks) as a view engine
• Provide a hook for other view engines from MonoRail, etc.
• Support IoC containers for controller creation and DI on the controllers
• Provide complete control over URLs and navigation
• Be pluggable throughout
• Separation of concerns
• Integrate nicely within ASP.NET
• Support static as well as dynamic languages

If that was too much for you to read, allow me to attempt to summarize this visually:

 

Alternately:

 

Lastly:

 

Now I don't want to sound like I'm going overboard with pre-release enthusiasm—this announcement is significant not because we're getting "new stuff." Microsoft has, uh, announced new stuff before.

The key difference with this announcement is, as far as I know this is the first time Microsoft has released something new that bears absolutely no resemblance to FrontPage Server Extensions.

If that last sentence just made you angry, sorry: that wasn't my intent. Let me try to approach this from a different angle. I'm going to attempt to say the exact same thing in a different way; here goes: for once, we are not being treated to a new data grid, or a new designer, or a new UI stack (well, we are, kind of), or a new way to talk to databases, or another remoting/marshaling/service framework. We're not being treated to demos that tell us we can build applications "without a single line of code."

Maybe you haven't seen that demo before. You'll know when you see it.

A third way to describe this is that Microsoft is, for once, moving away from the smart UI approach to software development.

Take your pick of descriptions; whichever one offends you the least is the one I meant to say.

Authority

I'm not a mega-expert in a general sense, so I don't want you to quote me on any of this.

SharePoint

"Well Peter," you may ask, "where does SharePoint fit into all this?"

First, I will again point out that I'm not a mega-expert, so don't attach too much weight to my opinions. With that disclaimer in mind:

SharePoint is heading in a separate direction. While with this release the vanilla ASP.NET stack is focusing on quality, SharePoint is still busy adding features (and if there's time, writing some documentation). While vanilla ASP.NET is essentially deprecating portions of its framework, the SharePoint framework grows bigger and bigger.

What makes this such a complex subject is that SharePoint development cannot be summarized as easily as traditional imperative programming. While SharePoint allows for what is known as artifact development (loosely defined: stuff you change in Internet Explorer or FrontPage), SharePoint also exposes a deep object model, a stack of web services, and an underlying XML schema for everything (yes I mean CAML). This mix of web services, API and XML is referred to as assembly development (let's just call it "programming").

Dealing with SharePoint primarily as a programming platform, on par with "build it from the ground up" frameworks like ASP.NET, is certainly my goal. But even once I think I've mastered all there is to know about SharePoint; once I've built my own collection of tools and scripts to make all aspects of SharePoint development tolerable; once I have a sufficient library of samples from which to borrow on any project; once I can effectively answer the questions like "how do we patch an in-production SharePoint application"—at that point, SharePoint development at its pinnacle will still not resemble the new ASP.NET MVC framework. Let's do this by the numbers:

SharePoint's "software engineering quality" scorecard (as compared to ASP.NET MVC's new features):

• SharePoint: nope! Natively support TDD model for controllers.
• SharePoint: nope! Provide ASPX (without viewstate or postbacks) as a view engine
• SharePoint: nope! Provide a hook for other view engines from MonoRail, etc.
• SharePoint: nope! Support IoC containers for controller creation and DI on the controllers
• SharePoint: nope! Provide complete control over URLs and navigation
• SharePoint: N/A Be pluggable throughout
• SharePoint: nope! Separation of concerns
• SharePoint: too vague to judge Integrate nicely within ASP.NET
• SharePoint: who knows Support static as well as dynamic languages

I don't want this post to sound too negative regarding SharePoint, but it's probably too late, what with all the red marks above. Unfortunately this is the truth: if you're doing SharePoint development, you should realize that "high quality code by default" is nowhere in the SharePoint playbook. SharePoint provides a lot of benefits; it's just that "designed for software quality" isn't one of them.

I swear I'll get positive and gung-ho on SharePoint and post all about it here.

Alchemy

One topic I'd like to work on later is the feeling I get sometimes that I'm performing alchemy. Today I discovered that the SPLimitedWebPartManager will happily give you a collection full of ErrorWebParts, for most of the webs in a site collection. Sometimes. The web parts work (most of them); it's just that when you visit them using the SharePoint Object Model, they are transmutated into ErrorWebParts.

So what do I do to fix this? Look for more opportunities for using blocks? Poultices and cremes? Try accessing the deprecated SPWebPartCollection instead? Leeching? Attempt to unload, then reload the SharePoint assembly from my AppDomain to see if this fixes the problem? Attempt to rebalance the humours? Search Usenet? Search Google? Search the Technet forums? Examine the logs in Excel using lists and pivot tables? Examine the logs in Excel using qualitative mathematics (and no, Google, I didn't mean quantitative mathematics)?

It feels that way sometimes.

Friday, October 05, 2007 6:00:45 PM UTC 

I found out recently that Microsoft will be releasing source code for the .NET framework and libraries. There are some caveats, but we're all in agreeance: this is good news. Thanks, Developer Division, for opening up your code*!

Now, if you will allow me to turn my attentions toward the Office team.

Why Is Everything Related to SharePoint Obfuscated?

If it's not already clear: the only thing we gained from the announcement yesterday is an official blessing from Microsoft saying "yes, it's okay if you look at our source code." We are already (allegedly) doing this unofficially and in an unsanctioned manner, today, with a little additional help from Lutz' Reflector. But in the distant tomorrow, with the release of Visual Studio 2008, we'll be bona fide. Bona fide!

It seems like such a small chasm we've crossed; such an easy step to take! Well, yes, but I haven't told you about Office yet.

By example: the InfoPath Migration Tool

In the beginning, it's always simple. In the beginning, I just needed to know why did my InfoPath forms break after I moved everything to a new server? In theory this should be a simple question. Yeah. 

I've discussed elsewhere the problem of discoverability when working with SharePoint; this discoverability problem can be described by saying answers like this aren't easy enough to come by. It turns out, after this entire ordeal was over, I found this excellent page on the Office Center describing InfoPath migrations. Continuing:

After browsing Google, checking the Technet Forums and USENET, I (allegedly, Your Honor) decided to look into the source of this InfoPath Migration tool. If you don't know what the InfoPath Migration tool does, I'll quickly say that if you're moving InfoPath forms around, this tool makes the job a great deal easier. I'm thankful this tool exists, to be sure.

Anyway, because this tool was not working as I expected, I needed to be able to answer an entirely different simple question: does this InfoPath migration tool change the URN of each InfoPath form? I.e., if you have one form template and 1000 individual forms, does this tool update all 1000 individual forms, as well as the 1 template?

The answer I (allegedly, Your Honor) received from Lutz' Reflector is (allegedly) illustrated below:

Now we're getting to it

So the question I pose is: what harm is it to you, Someone In the Office Division, to skip the extra step of obfuscating this tool? Just, you know, release it like 99% of everyone else is doing? (ok, ok, 99% is an exaggeration; a significant portion of vendors release their source code un-obfuscated, but additionally release in Debug mode, granting us richer decompilation information. Yes, you'd be surprised to find what is released in Debug mode)

Why not open this one tool up? No one's sharing any secret InfoPath sauce in this tool; this tool works on InfoPath's XML documents directly. Allegedly; I wouldn't know.

Furthermore

The Developer Division has promised to open up much of their code; why not open up some (or most!) of the SharePoint code?

Or, and this should be more reasonable to consider, take a different approach from today: instead of obfuscating everything, please consider instead why obfuscate at all? The idea is: please don't obfuscate by default.

Just say no! No to drugs, and no to obfuscation! And no to both drugs and obfuscation (an especially deadly combination)!

Epilogue: the InfoPath answer

I was (allegedly) unable to decipher the raw, obfuscated IL inside of Reflector. So, defeated, instead of (allegedly) harvesting the answer directly from the source, I ran an experiment to find out what happens in this specific case.

I will point out that this is a terrible practice: combine two gargantuan, opaque frameworks, perform limited experiments on their interaction, and draw conclusions from any pattern that emerges. In science, they call this "testing a hypothesis", i.e. even if you get the desired result, they're not proven, and they can be disproved later. So having given a strong disclaimer, allow me to present the results.

After running the experiment, I concluded that InfoPath forms (specifically, the XML forms containing just the data) are 1) not modified by the InfoPath migration tool; instead, 2) InfoPath forms are modified during the "attach content database to MOSS web application" step of a WSSv2 -> MOSS migration. 3) Changes made to the web application's public URL afterwards did not affect the InfoPath forms (as it probably should have).

This is important to note, because if you're attaching your content database to a temporary (dummy) web application, then rename or otherwise move your web application's public URL, then guess what! Dead InfoPath forms**.

I'll make one last disclaimer: those three points above are not guaranteed to be true.

Footnote

* Everyone should be generally pleased with this announcement. It's not a full-blown "do-whatever-just-don't-sue-us" MIT-style license, but it's closer now. There are about a hundred arguments for or against this, either way, and they're probably all already represented among the 700+ comments responding to the announcement itself. I'm just saying: at the very least, you have to admit this announcement seems to lack malice. Contrast this with the Office Ribbon license.

** Dead InfoPath forms means, dead until you fix it. It's just XML, and if you don't like to think in XML, then it's just text, and you can certainly do something programmatically either way. But as you learn with SharePoint, it's best if you leave these sorts of uncertainties alone and figure out what everyone else has already done in this case. And they aren't writing programs to manually manipulate every InfoPath form's data as if it were a text file, I'll tell you that much.

Tuesday, July 17, 2007 6:14:20 AM UTC 

Introduction - The Audio Flood

I've reached the limit. I can't handle any more podcasts, sorry; there's just too much out there now to handle it any more. In my previous roundups (2006-04-28 and 2006-08-02), I indicated that I was still looking for new podcasts—i.e., I was still able to keep up. Now it's just too much, and I'm forced to prune my podcasts.

With this in mind, let's define what I like to see:

Review Criteria, Quickly

I'm looking for quality, software development-related (mostly .NET) content, for some definitions of "quality" and some definitions of "mostly .NET." I listen to some shows for practical knowledge and some shows just to pick up the flavor. I've also discovered I don't like news shows, so you may notice I've left out almost every highly-ranked tech podcast listed on Digg (including DiggNation itself).

Without further ado I present:

Worthwhile Programming Podcasts

Wednesday, January 17, 2007 11:18:18 PM UTC 

This is a quick note to myself: the direct download link for the Indy Project 10 Installer is here. This link will save me from searching through 10-20 "extra value added" pages the next time I need to find it.

Also for my information, their main page may be found at a more obvious URL: The Indy Project - www.indyproject.org.

The Indy Project is, as far as I can tell, the only real (free) FTP library available for .NET. Apparently there's a SharpFTP library in the works, but from the SharpFTP changelog (checked ~2007-01-17), it looks like they're busy…implementing some of the more basic FTP commands.

Sunday, May 14, 2006 5:01:31 AM UTC 

I've just uploaded a copy of my FTP log downloading utility. I built this specifically so that I could grab my DiscountASP log files from the web server on a nightly basis.   You might ask: Why build an entire console application for this one purpose when you could have gotten the same thing done using:

• curl - I probably could replicate all this functionality using a batch file and three calls to curl
• A free utility that does basically the same thing
• Perl Script Written Ten+ Years Ago

The point isn't why.  The point is that it's done, and that I've made a beautiful installer to help install it on your PC.

Check out my project page if you're interested:
weblogs.exe project page

Guilty footnote: .NET Framework 2.0 required.