Peter Seale's weblog

Tuesday, October 27, 2009 3:59:44 AM UTC 

This is a two-parter. The first part is to say, hey, look at this sweet hack I've discovered in the Oxite source*! The second part is to ask, hey, is this a good idea?
* the refactored Oxite source, that is

Background services

First, let's give a little detail here—background services are long-running tasks that Oxite needs to run periodically. These are things like sending emails and sending trackbacks—necessary, certainly. But, they shouldn't be running while some chump stares at his Netscape window waiting for the site to finish sending 1000 spam trackbacks. He should be able to post to his blog, receive an immediate response indicating the post is now available, and the trackback spamming can commence later. Background services are the things you can put off, the things that don't have to finish before sending a response to your website patrons.

These background services are called by many names—I've heard cron jobs, timer jobs, background jobs, jobs, "the heartbeat," services, and tasks.  In Oxite they're called background services.

Look at this sweet hack!

The full source is below, but I'll attempt a walkthrough of the solution here. First, to explain the problem: we must achieve the impossible—we must somehow emulate a continuously-running Windows service inside an IIS worker process. This means we must periodically trigger jobs to run, but we can't monopolize valuable worker threads. And we certainly can't delay responses to send 30000 spam trackbacks. We've got to run, but we can't run anywhere in the ASP.NET page/request lifecycle! It's a conundrum.

What the Oxite team has done to achieve the impossible is, plainly, to cheat—they use a System.Threading.Timer.

How they manage the impossible is a lot like juggling—magic juggling. Enter stage left: Oxite, the juggler. Oxite takes a background task and throws it in the air. He takes hold of the next background task (let's start calling these things bowling pins) and throws it into the air, and moves on down the line. Before anyone knows what's happened, Oxite has gathered up all the bowling pins, thrown them all into the air, and made his getaway. Unlike most jugglers, Oxite makes no attempt to catch bowling pins once thrown! And this is why it's magic.

Let's try to break this back down into code. When Start() first executes [line 28], the Timer object sets a callback without halting progress [line 43]. This is the juggler throwing a pin in the air.

The callback method is eventually invoked. A thread is spun up* and runs the designated timerCallback() function [line 56]—and, let's make this clear—timerCallback() doesn't block the original Oxite web request; it lives in a new thread. And this new thread does its first dose of work, as shown on line 68 (SPOILER ALERT: it calls Run()).  We're not interested in what Run() does exactly—for today it must remain a spooky mystery, go look it up yourself.
* precisely how the thread is spun up is in fact, real magic, or might as well be to my superstitious caveman brain

Ok. Here's where the "magic" part of magic juggling comes in. Because any dunce can throw bowling pins, and any dunce can catch them, and any dunce, with practice, can juggle. The magic here is inside the timerCallback() method, where the Timer once again sets a callback. Each time a background service awakens, it does its work and, before going back to sleep, sets up the next callback with another call to timer.Change() [line 75]. That is to say, each time the bowling pin makes as if to land, it spins back upward into the air!

So there you have it. Oxite takes a bunch of bowling pins, throws them all into the air, and leaves. As the pins drop down to the ground, the "mystical Timer callback juggling force" propels them back into the air.

And we're running background threads in the web process. Sweet.

Now the question is: is this a good idea?

Now you understand how background tasks work in Oxite—or can now juggle. I get confused sometimes. In any case, congratulations!

Assuming I'm not misrepresenting anything, this is how background tasks work in Oxite. So, now for the question. Is this a reasonably acceptable way to set up background tasks for a site? I've discussed it some on twitter, but is there anything particularly nasty I've missed? Will it kill the process? Will it hang all 25 threads? Or some large portion of them?

I'm curious to hear if anyone has taken this approach, and what their experiences were.

Full source

From http://oxite.codeplex.com/SourceControl/changeset/view/45053#438025:

Tuesday, September 08, 2009 12:32:24 PM UTC 

I'm not going to get into specifics; instead I'm just going to say that my project, today, is painful to deploy. And not only is deployment painful, it's error-prone. And I don't mean "error" in the hypothetical, higher-percentage-than-that-other-hypothetical-percentage sense of the word; the sanitary, almost clinical sense. I mean, oops, there went four hours troubleshooting when I deployed the wrong DLL, preventable kind of error.

So it hurts.

There's lots of pain in the world of software development, but it doesn't have to be this bad. All I need to do is, in the beginning, set aside some time to deploy an empty shell of a project. When I say empty shell I mean, almost literally, a Hello World type of application. If this Hello World application involves seven databases, twenty seven service accounts, a network load balancer and forty web.config files, so be it. If the deployment requires granting of security permissions to these twenty seven service accounts, so be it. Sure, it's going to seem useless, and the tangible payoff will be minimal. Painful? Error-prone? Bring it on. Bring it on at the beginning.

And please, for your own sake, one-click automate the deployment! If nothing else, automate the happy path, which is orders of magnitude easier than building a fault-tolerant deployment. Worst case, your automated deployment fails and you're back to manually deploying. In other words, if you're deploying manually, then you're already living out the worst-case scenario.

And by you, I mean me, today. Again, not hypothetical.

Happy path/sad path by example: copying a folder

Happy path:

1. Copy a folder and contents to a destination directory.
2. You're done! Congratulations!

Sad path:

• Does the source file exist?
• Is the source file unlocked for read?
• Does the destination folder exist?
• Or its parent folder?
• Or its parent?
• Or the parent drive?
• Or parent network share?
• Or maybe you need to connect to the network share with a different service account?
• So this means you need to explicitly drop all current connections.
• Can we drop (delete) the existing destination folder?
• Is the folder locked?
• Is this because we have an Explorer window open to the folder (sooooooooooo common for me)
• Are we overwriting a file?
• Do we have permissions?
• Is the file locked?
• What if some of the file copy operations succeed, but not others?
• Do we have a perfect backout strategy?
• Can we restore the original folder in its entirety?
• If not, can we restore each individually changed item in its entirety?
• Are we running in a transaction?
• Are all our options atomic?
• Do we implement a transaction log of sorts? How do we know without a shadow of a doubt our operations succeeded?
• Did the virus scanner interfere when copying an .EXE?
• On your machine?
• On the remote machine?
• On an invisible HTTP proxy on the network?
• Is the remove file share something crazy like WebDAV, where only some operations are supported?
• Are you sure you're running the WebClient service required to make this WebDAV/explorer integration work?
• Are the file+pathnames reaching the maximum allowable limit, and are you copying to a deeper subdirectory which would cause "too long filename" errors to occur?

IT as a career makes me paranoid—this is a ridiculous checklist for just copying a file. But I've experienced all of these things. Yes, it's ridiculous, and yes, it's real.

Saturday, August 22, 2009 6:55:47 AM UTC 

Hello! I'm Peter and I'm here to present another sweet, sweet linkblog post. In my first link-heavy post, I pulled any links I could remember, from the previous week, year, or decade, a 'best of' of sorts. So don't expect great things from this sophomore effort.

To give the standard introduction: I've pulled anything tangentially related to software development in the .NET space into this linkpost, salted each link with commentary, and grouped into sections. I'm not an authority on most of the articles I link to, so when commenting on them will try to restrain myself.

Random topics

• Reminder: Virtual ALT.NET livemeetings - it's as easy as 1) typing snipr.com/virtualaltnet into your browser, and 2) entering the LiveMeeting. If you want to participate (encouraged), get a cheap mic/headset of some kind. There are three weekly meetings: Australian Monday night, Wednesday night US, and the Central-time Brown Bag meeting on Thursday. I'm definitely a fan. Also, don't forget: VAN records their sessions. Between this, NDC, and the various Ruby conference videos I've found, I'm never looking for something to watch.
• Designing Effective Dashboards [PPTX] - while I hate buzzwords as much as the next guy, and for that matter, while I hate browsing PowerPoint presentations, this has managed to overcome both its enterprisey roots and its PPTX medium! It's a PowerPoint presentation about Business Intelligence, which means I should be falling asleep just writing about it, and yet, here I am! Trust me, it's worth browsing. For a teaser, here's a self-explanatory slide:
  
  
  Business Intelligence is neat-o! Wait, did I say that?
  
  
• The circle of no life:
  
  
  Every now and again I need reminding.
  
• The Bipolar Lisp Programmer - this is partially about Lisp programmers, but also partially about programmer attitudes and, lacking a better word, 'psychology.' I don't like that word. Anyway, the article isn't necessarily based in hard science, but hey, it's a fun read, and you may just recognize something of yourself in it.
• Optimism - the three axes of optimism (or pessimism, if you're one of those people)—interesting because it provides an algorithm to make you more optimistic. Which is a good thing. And yes I said algorithm, which is why I'm linking to it.

Software engineering topics

• (Updated Classic Mistakes List) Coding Horror: Escaping From Gilligan's Island - Classic software development mistakes. You'll recognize a few (or several) from your last project.
  • Classic Mistakes Enumerated - and for more detailed descriptions of the original classic mistakes, here's the original list of 36 classic software development mistakes, copyright 1996.
• AR⊗TA - Artisinal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism - and no, this isn't a joke. This is a type of "post-Agile" thing as it tries to address the reality of failed Agile projects.

My ongoing obsession with learning, which is arguably the skill software developers need most

• Making TDD Stick: Problems and Solutions for Adopters - for those of you trying to teach others TDD, read this article for sage advice. For those of you new to TDD and frustrated by how weird and difficult TDD is, read this quote:
  
          Test Driven Development can be very hard to learn. The learning phase (the time during which it becomes a deeply ingrained habit) typically lasts from two to four months, during which productivity is reduced [2]. Eventually the benefits will be obvious and the technique is usually self-sustaining, but the question is: how to get there? Many developers give up after only a few days.
  
  …then go check out the article to see what tips they have for making learning easier.
• The 7 Phases of Unit Testing - step 1 is "Refuse to unit test because "you don't have enough time."
• We have no class (a personal journey of not learning OO) - here's some honesty about how learning object-oriented programming is a large undertaking. I'm there with you man, I'm there. I'll say that though I "get" the SOLID principles, that building systems of lots of interacting objects is messy. Procedural-based refactorings (e.g. splitting a huge method into smaller methods) are almost always straightforward and can even be measured (see cyclomatic complexity), so you know when you're on the right trail. On the other hand, when you split responsibilities into multiple classes, you get into the world of, yes, I'm going to use the word, brace yourself, here it comes: hermeneutics. Using words I understand: it means that object-oriented design is messy and mushy and it's difficult to say objectively whether a design is better or worse than competing designs. And no, I'm not going to acknowledge the pun, if you noticed, well that's your problem.
• Under Your Fingers [5 min of QuickTime video] - here Corey Haines exhorts us to engage in deliberate practice. Deliberate practice. It's an important concept, and it's something every programmer seems to be lacking. Wax on, wax off.
• The difference between derivation and innovation - Oren gives a rule which explains why so much of the new hotness in .NET is uninteresting to me. Azure, for example, is the same thing you're already doing, but in the cloud…a derivation. See, that sounds better than "it's boring" or "I hate it," right?

My ongoing obsession with TDD, unit testing, and/or producing quality software in general

• Classifying tests - good article that disambiguates unit, integration, and functional tests. Most of you reading this have an incorrect understanding of what a unit test is, and yes I'm talking to you. I'm not going to write your name here in the post, because that would just embarrass you, but trust me, it's you. So read the article :)
• A testing survey on a large project - the title isn't flashy linkbait like "40 Reasons I Can Make You Click This Link,"  but bear with me—this is one of the few places I've seen unit testing, integration testing, and acceptance/functional/UI testing put into a kind of cohesive whole. Being still in the stage where I'm forming a usual style, this type of post is great to gain a sense of perspective.
• Test Review Guidelines - Art Of Unit Testing - Roy Osherove has posted the test review guidelines from his book on this page. Most of the guidelines are unsurprising, excepting the one interesting point he makes about overspecifying tests. These are subtle points and as I struggle with this issue, it's good to read his concrete rules on avoiding overspecification.
• Unit Testing with functions that return random results [Stack Overflow] - This issue has ruined (sorry, produced valuable learning experiences during) no less than two full coding dojos, and has almost derailed a third. Now, every time we even catch a whiff of randomization, it's "uh-oh, let's break all the dojo rules and just work past the issue." So I find it satisfying to see that it's not just us.
• Evolutionary architecture and emergent design: Test-driven design, Part 2 - I'm only interested in the claim in the first section under "moist tests" that "DRY doesn't apply to unit tests." I'm suspicious that those following the "moist test" philosophy are classical TDDers and those who disagree are mockists. Yeah, I didn't make those terms up, see this Martin Fowler article. In fact:
• Mocks aren't stubs - from Martin Fowler. I found this looking for the difference between mocks and stubs, and ended up with an excellent bit of perspective: TDD advice from classical TDDers and TDD advice from mockist TDDers won't always agree, especially in the teensy details like "moist tests" above. Also, coding dojos.

Counter-counter culture (wherein we get to 'why' answers)

• The usual result of Poor Man’s Dependency Injection - Chad explains why in his experience using Poor Man's Dependency Injection (look it up if you're interested) always ends in tears. Up to reading this post, I assumed that allegiance to IoC tools was one of those irrational tribal values, but now (after reading the post) I understand.
• Why unit testing is a waste of time - the "waste of time" title is more inflammatory than the post, but the core point is that unit testing is part of a balanced diet. Part.
  Also, to be clear: unit testing is not a waste of time.

Architectures

• The Tale of the Lazy Architect - Oren describes a composable system. This sounds sweet.
• Submit this Form InfoPath - FAQs - and here is something of the opposite. This FAQ exemplifies why I don't want to ever do anything complex with InfoPath. Not to pick on Kathy the author, that isn't the point—the point is to show what kinds of awful workarounds and hacks you have to do just to make a field read-only, or to pull in a user's email address. For fairness, I should point out that this FAQ is for InfoPath 2007.

Business/organizational development/management/CEO stuff

• Culture [flash rendering of PPT presentation] - the presentation isn't very fancy but the content is dynamite. Here's an analysis of the concepts presented. I particularly like where they discuss corporate values and how the values are often meaningless ("Enron had a nice-sounding value statement"). They've got crazier (crazy in a good way) stuff in there, including a discussion of how they fire average performers. It's almost utopian-sounding.

Wednesday, May 27, 2009 1:08:01 AM UTC 

I'm here today to present the case against a particular piece of NUnit's fluent syntax. But before I do, let's set up a concrete example, something that gives the test meaning. Instead of just writing something down in boring old plain text, I've sloppily remixed a work of art I found via an image search and retitled it "Rebellion Against the (overuse of unrelated, Creative) Commons(-licensed images)!":
 

Solid. Requests for ~/Default.aspx should redirect to the Home controller. Let's get on with the show.

My Gripe: Assert.That syntax

Here is a comparison of the Assert.That syntax, the traditional Assert.AreEqual syntax, and the syntax provided by MSpec's NUnit extensions (MSpec isn't the only framework with these extensions, it's just the one of which I'm familiar):

I don't like the Assert.That syntax, in this scenario.

Look at all that. The new syntax is just…ugh.

I've read elsewhere that it's good because it reads like a sentence. Well, to shock you into elevated awareness, may I jog your memory of something else that reads a lot like a sentence? In case you didn't dare hover over that link, allow me to properly title it:

"My First COBOL.NET Web Application."

Check out the action in the linkage section!

Rock on, COBOL.NET!

Okay, conflating "reads like a sentence" to COBOL is a sucker punch, it's unfair. Let's do this by the numbers.

Comparing the three ways to do the same thing

In all cases, the fewer, the better.

Syntax	Total chars	Chars used by test syntax (by my measure)	Total times Intellisense was necessary*	Of these, times Intellisense couldn't help (e.g. Assert, Is)
Assert.That	66	28	6	2
Assert.AreEqual	58	20	4	1
result.ShouldEqual	53	15	3	0

* "Intellisense is necessary" is roughly defined as "any point at which you can use Intellisense." Definition is left purposefully imprecise.

I could go on for a bit about this, but I'll let the fancy HTML table do most of the talking. If there are any takeaways from this oversized-for-its-topic post, let them be:

• The fewer magic syntax words I have to learn (e.g. Assert, Is), the easier a framework is to learn. By this measure the MSpec extensions are the best, and the Assert.That syntax the worst.
• The fewer characters typed, the easier a framework is to use. Terseness is better when it doesn't impact learnability.
• "Reads like a sentence" is presumably the means to achieve some other goal, not a goal in and of itself. If your fluent syntax doesn't help achieve…whatever that other goal is, reconsider trying to make your fluent interface read like a sentence.

Related counter-point I don't care about today:

• The fewer  extension methods attached to "object," the better.
  NOTE: test frameworks and mocking frameworks get a pass from me because they are supposed to work against any object.

Final note: Better vs Best

I'm complaining today specifically about NUnit's Assert.That(actual, Is.EqualTo(expected)) syntax. I'm not down on the Assert.That() syntax as a whole, just the most commonly used method. And maybe that's what's bugging me—Assert.That has a lot of great stuff in there, allowing fuzzier comparisons beyond simply .AreEqual(), but the most commonly-used scenario is measurably worse than the old syntax.

And the Assert.That(actual, Is.EqualTo(expected)) syntax isn't the worst thing ever. It's not the end of the world. But shouldn't it be better than the thing it's replacing, not worse?

Saturday, May 16, 2009 11:18:50 PM UTC 

In the past I've questioned the viability of linkblogs—does anyone (including, and perhaps especially the linkblog author) have time to read all these articles?

The short answer is no. They couldn't possibly have time to read and evaluate all those articles.

I think it's become something of a cultural expectation that we scan each of the 50+ links in a daily linkblog post as a way of discovering something interesting, without having the expectation of, you know, reading anything. Inevitably the quality of the links degrade, because nobody's reading the articles. As for me, I'm batting .000 on following linkblog links this year…I'm in a kind of "linkblog hitting slump." Maybe it's just me.

This also goes for programming-related aggregators. First we had Slashdot, then briefly, Digg, then Reddit, then the front page of Reddit became something of a wasteland, so we moved to programming.reddit.com, then there was that thing called Hacker News. Somewhere along this timeline DotNetKicks reached critical mass, before slipping into the doldrums of all-ignorance-all-the-time .NET op-ed pieces; ugh. For the record I still think the aggregators do a good job, it's just that they could do better.

Where were we? Ah yes, links.

I've found the following links fascinating for some reason or other, and I personally vouch for them. If I haven't looked at the link, I'll point it out right there (which I do a lot in the "Books" section.)

Links

Podcast series (AKA Super Podcast Roundup Turbo HD Remix)
Podcasts are roughly ordered by how much I like them…but note that if they're listed here, I like them. My first podcast roundup was in 2006.

• Stack Overflow podcast - having read both CodingHorror and Joel On Software, this one's a lot of fun. Revisit old topics, get their unfiltered take on newer topics. It's good to get the unfiltered opinion, even if they're uninformed from time to time.
• Deep Fried Bytes - I like their rusty washers segment. Maybe that's the pessimist in me, but hey, I'd prefer risking listening to an over-critical rusty washers segment over over-exuberant marketing talk.
• Herding Code - when there are four co-hosts, you get better questions, and the guest isn't allowed to spout FUD/ignorance for an entire episode like sometimes happens on DotNetRocks.
• Hanselminutes - I like the recent trend of doing "follow-up" shows to correct inaccuracies on other podcast series.
• DotNetRocks - classic, still going, and like the rest of 'em, DotNetRocks has both good and bad episodes.
• Software Engineering Radio - in theory I like this show, but I'll be honest and say I haven't listened in a long while.  My commute dropped from an hour to just 8 minutes, what can I say.
• Irregularly updated podcasts I enjoy:
  • OOPSLA podcast 2008 and OOPSLA podcast 2007 - some of the best episodes/talks come from this podcast series. Hopefully we'll get the equivalent shows for their 2009 conference.
  • Polymorphic Podcast - Craig's still going, several years later. ASP.NET/web development/object-oriented development topics.
  • Elegant Code - I don't remember the last time they published something, but, hey, we're in the "irregular" section for a reason.
  • ALT.NET podcast - just switched hosts, so we'll see where this goes.
  • Rubiverse podcast - run by the former ALT.NET/now-Ruby guy. His shows are infrequent, but good.

 

Career-oriented (whether the career is freelancing, entrepreneurial, independent consulting, or even working as an employee)

• Daniel James - Building an Indie MMO (Puzzle Pirates) - this is (believe it or not) not much about making games, as it is about building a product. He explicitly mentions that you have to be extraordinarily productive. I'm not selling this well, but trust me, you'll want to check this out. Also, he wears a pirate hat.
• Archaeopteryx by Giles Bowkett - wherein he describes that he'd like to someday have Archaeopteryx (the open source app he built and loves) be his main job. Sometime late in the presentation Giles also says he'd like to describe himself as a "musician who happens to know how to program." It's an engaging laser show, fog machine and all, and as the InfoQ page says, "slides edited directly into the video since there were 500 of them." I don't agree with everything he says, but the career aspect of his presentation is something to think about.
• DHH (creator of Ruby on Rails; 37signals) at Startup School - apparently his talk immediately followed a VC who spent an hour describing how to get VC money. One of the first thing he says is "you don't need VC money" and explains why working in a VC-funded startup is like playing the lottery, instead explaining that you should follow his revolutionary advice and "charge money for your product." Engaging/entertaining, and a lot of straightforward wisdom.
• Do the Hustle, by Obie Fernandez - straightforward talk on the business aspects of independent consulting for Rails folk. Most of this applies to the rest of us.
• ajmoir's description of a hyperproductive software team - this is a Reddit conversation with multiple threads, so for the full story you've got to read all his replies. I think this is important for everyone to read because you need to believe software development can be done, for lack of a better term, "way better." The promise of hyper-productivity is fascinating. Also: Lisp.
• Mark Cuban on Success and Motivation (long, mostly storytelling)
• How to become a famous Rails Developer, Ruby Rockstar or Code Ninja - I haven't watched the presentation, but I did read his transcript. Also you may be interested in the RailsConf video feed…I haven't found anything else I'd recommend.

Screencasts/webcasts/watching presentations on your computer

• Ten Ways to Screw Up with Agile and XP - this presentation is a kind of response to the "post-agile" idea. Like the "post-agile"stuff we're beginning to hear about, he talks about how Agile projects and teams can fail. Unlike "post-agile," he doesn't blame Agile, instead focusing on solutions for the ten common problems he encounters. Highly recommended, especially for those not sold on Agile. Ben sent me this link some time ago.
• Virtual ALT.NET meetings (ongoing) - these are the in-depth presentations I've been looking for.  You can listen in live to any meeting…just plug in a working headset, go to http://snipr.com/virtualaltnet … and that's it. Also, they record sessions! Awesome! http://www.virtualaltnet.com/van/Recordings On my queue of sorts:
• Øredev 2008 videos - I'm digging through these presently. Unlike most conferences, Øredev has provided videos for each track (i.e. "the breakout sessions")! Awesome! Find the videos either
  • Split out by category ( http://www.oredev.org/ in the "Watch the videos from 2008" sidebar)
  • in one big bag of videos on VIddler
• Haven't watched - Lang.NET symposium talks. I think I'll check out the two PowerShell videos and then bail, I mean, hey—I've got plenty to check out without delving into programming language design. But, enough about me: you may find some of the other talks interesting. Big ups to Microsoft for publishing the videos.

Books (.NET development-related)

• JP Hamilton has the only "required reading" book list I've seen that's less than 4000  books. His list has three (3). I'm on 1/3. For the record, I'm okay with longer "required reading" lists, so long as they're given some sort of priority. JP prioritizes his list.
• Free PDF eBook: Foundations of Programming by Karl Seguin - in full disclosure I haven't read this. Karl doesn't directly tell you why you should read his book, but maybe this book review will help you make the decision.
• Object Thinking by David West - I'd like to think the author saw some trollish post on Usenet about object-oriented programming, and started writing a long, detailed response. One thing led to another, and hey! Object Thinking. There's a chapter in this book that has a long discussion about hermeneutics. Hermeneutics. Try and work that one into a sentence.
• PowerShell in Action 2nd Ed. is coming! Excitement! I'm biased, what can I say.

Code camps/Saturday developer events (Houston area, sorry everybody else)

• Austin Code Camp - May 30th, 2009 (soon!) - check out the hot hot hot session proposals! Hot!
• FOSS in Healthcare unconference - July 31st - August 2nd, 2009 - costs money, but maybe it's worth it to you.
• Houston Techfest 2009 - September 26th, 2009. This is the day of the Texas Tech at University of Houston game, on the University of Houston campus. Techfest: est. 600 attendees. Football game: ~30,000 (it's a small stadium). I think we'll have a crowded campus that Saturday!

Everything else

• Using Photos to Enhance Videos - this is one of those jaw-dropping demos. Click click click click click click click.
• Fred Trotter on the "VA VistA Underground Railroad" and how our US government should spend its Healthcare IT money on open source - Healthcare IT has a problem, and I hope an open source ecosystem is a solution. This article is long and gives a lot of history, so you'll get something out of it even if not interested in the politics. Also the links to the VA VistA Underground Railroad were fascinating; folks interested in Behavior Driven Development would be interested by the stories about how "a programmer sits down with a clinician" to write the app. Fascinating for a lot of reasons.
• While we're talking about BDD, you might be interested in the David Parnas' keynote at OOPSLA, wherein he lays out eerily similar goals (see the section on Documentation.)
• The underhanded C contest - 2007's underhandedly-weak encryption contest: "Your challenge: write the code so that some small fraction of the time (between 1% and 0.01% of files, on average) the encrypted file is weak and can be cracked by an adversary without the password." Make sure to look at the criteria for bonus points, and of course, the winning submissions.
• "Is anyone else here worried that they've spent so long looking briefly at everything, that they've still good at absolutely nothing?" - you don't have to click the link, just acknowledge the point. This reddit post has 1000 upvotes.
• Scott Berkun's Project management for beginners (post is short!) - because, aren't we all beginners? You don't see this kind of straightforward talk from the PMBOK (if you do, it's sandwiched between "effectively denying reality" and "having long status meetings." In other news, I think I have a rebellious attitude towards the PMI, judge for yourself.
• Abstract architecture-y type discussion - Design and Develop Versatilities, Not Applications - focus on the idea of what he calls "versatilities," and not so much on the specific technology involved (i.e. SharePoint.) I think it's a noble goal, but no, SharePoint in its current form can't realize the lofty goal he sets forth. Sorry, no. As I said elsewhere, you'll get far more mileage by training your power users to build their own SQL queries and how to use pivot tables in Excel. But the ideal is good.
• Programming Sucks! Or At Least, It Ought To - Alex (the author) runs thedailywtf.com. I don't know what to say about this. Every programmer needs to find the balance between getting real work done the ugly way, and spending time learning new techniques that make the ugliness go away. I haven't found this balance. This goes in hand with Alex's other classic article, Pounding a Nail: Old Shoe or Glass Bottle? - and carries the same assumption that you must live with your (bad) programming environment.
• All this SharePoint Stuff is Going to be Normal Soon - a lot of people see SharePoint as the next "Microsoft Web OS," i.e. that the SharePoint trend will accelerate, and that we'll start to see every future web-based product from Microsoft (and products from other vendors!) run on top of SharePoint. As it is today, the easy answer is "no that's not going to happen," because the cost of running your complex app on SharePoint can't be justified. And for tomorrow the answer still looks to be "no that's not going to happen," because I don't see any fundamental changes taking place. Non-trivial add-ons today write their data to their own database, making their "SharePoint integration" more lip service than truth. I've thought about what I'd like to see in an application framework, and if I could summarize, the one thing SharePoint doesn't support that it needs to: it would be nice if it allowed deep customizations that the product team did not anticipate. I think this is the fundamental problem which at this point is unsolvable for SharePoint. Solving this problem would require re-inventing SharePoint into something that doesn't resemble the SharePoint of today.
  But, who knows, I could be horribly wrong about all this.
• Discussion about Microsoft Gold Partners, titled "Why Your Vendor Screwed Up Your SharePoint Project" - wherein the author (gently, ever so gently) points out that Microsoft needs to change its partner ecosystem.
• How to call BS on a guru - again Scott Berkun. He writes books by the way :)
• The DailyWTF programming contest entry (a calc.exe replacement) which is built entirely in C++ templates. I can't tell you what kind of respect I have for that kind of compiler abuse.
• News: Clojure 1.0 - dismiss this at your own peril. Related: ClojureCLR alpha up.
• Is mutation testing useful in practice [StackOverflow question]? I'm reading through Kent Beck's TDD By Example, and he mentions mutation testing. Years later, it seems like no one's talking about mutation testing. Are we doing something else to test our unit tests? Is this too much overhead? Have we adopted a new mental framework that eliminates the need for mutation testing? Anyway, there's your new-old idea for the day: mutation testing.

Friday, March 27, 2009 4:48:49 AM UTC 

I'm here today to relay two messages:

First: I'm still alive and well

I haven't posted anything of real substance in quite a while (and some of you in the back of the room are shouting "in a while…or ever!" I can hear you.) I'm not here to promise more frequent and meaty updates; instead, I'm here to say that you can expect a lot less from me, at least on this blog.

My growth-as-a-developer plan (I introduced it in detail here) is going full steam. While I'm not on track to hit all specific targets, the most important thing is that I'm seeing real growth. The bits that have been most helpful for me have been a) writing my own mini-project, and b) reading source code.

Lesson: read source code!

I'd like to emphasize how drastically this has changed my outlook. First, reading others source code gives me self-confidence. And yes that's somewhat mean, I know. But it's true, and I try to beat the "you are adequate" drum as often as possible—by reading others' bad source code, you'll better know where you stand. Sometimes you realize you've got a lot to learn; sometimes you realize that hey, you're not all that bad, relatively. Bad source code can be inspiring in its own way.

And let's pull this around to the positive—I've learned a ton reading others' source code. I've picked up lots of little nuggets like using params[] as a method argument, and bigger nuggets like the several different styles of context/specification-ish unit tests. I shouldn't have to explain this; it should be self-evident that one can learn by studying source code. Duh.

Lesson: have a side project!

But more helpful even than reading others' source code is simply getting out there and writing my own. And I don't mean the type of stuff I do at work…let's not go there today. I mean code that is almost 100% logic; data stored in List<T> and passed around as IEnumerable<T>. I don't have a database. I don't have a UI. My project is entirely useless at this point, and will remain useless maybe forever.

But I'm learning a ton! What's great about building my own project is that I'm able to focus on learning specific topics. My focus points for this project are:

• OO (I'll flesh this out further when I know what it means)
• Test driven development (not just unit tests, but actual test-first, drive-out-the-design via tests, TDD)
• Context/specification-style tests

Along the way, as a kind of bonus, I've picked up:

• LINQ to objects - replacing for loops and foreach loops with LINQ calls. Related and also learning: nuttiness featuring delegates.
• Rhino Mocks AAA syntax - with the exception of method argument constraints. If someone wants to show me a good example of using constraints, I'd be ever so grateful—just a link to a project where someone's using RM constraints will work, I'll find it from there.
• NUnit/XUnit/MSpec - in that order, and yes, I switched all my tests over, and yes, the process was ugly. Also you can't claim to know NUnit if all you know is the [Test] attribute and Assert.IsTrue().

What's most important about this whole 'writing my own side project' experience is that it is fun, and I had, and continue to have, the energy to keep at it. I'm never motivated to do self-directed learning, so this boost of energy is the biggest win. If you're one of those people who can't imagine this kind of thing could be fun, well, maybe it's time to try out a side project.

Everything else has suffered

Everything else has become unimportant. Learning the newest wave of MS technology isn't even a concern at this point; I'll pick it up when I need to, or when my side project calls for it. What's surprising to me is that even ASP.NET MVC, which I happen to like, is being shunned with the rest of them.

Also, blogging has suffered. Also, my book reading has suffered.

I've completely stopped reading those futile "here's 80 things you don't know" linkblog posts. Aside from the SharePoint one, which is golden, what are you getting out of your linkblogger? Do they read all the articles they link you to? Are the links relevant/do you intend to read any of them yourself? Are the links accurate/factual? See, I'd prefer a monthly linkblogger who had on average six or seven links, and all six or seven would be interesting. Then, every year or so, there'd appear one starred link. This link would be considered so important you couldn't ignore it, a "must-see" so to speak. …Anyway, that's how I see proper linkblogging. Seven links a month, or so.

But who cares about all that, really. I'm learning a ton, and you can't stop me!

Everything in Balance

I should clarify: I'm coming to this concept as the podcast junkie/blog consumer/programming aggregator consumer person, who didn't have a side project. I've been at it (this side project) a few months now.

So if you're thinking my advice is unwise, that's fine—I'll take this space and make a disclaimer: I intend to use common sense, and re-evaluate my learning strategy from time to time. In particular, I  do intend to read books in the future, hopefully the near future.

Just not right now.

Second: I like reading my own Twitter feed

Way at the top I told you I had two things to say tonight. First was the message that everyone needs to start their own side project even just to help them learn.

Second is to tell you that I'm on twitter. Believe it, twitter.com/pseale. Subscribe! Do it!

Something I've found amusing is that I enjoy reading my own twitter feed. It's either a sign that my tweets are engaging and are chock-full of hilarity and insightful content…or that I like smelling my own aroma.  You be the judge!

Here's a sampling of my twitter bouquet:

 

There wasn't really a point to listing all these out. Well, no reason besides blatantly advertising twitter.com/pseale. Subscribe! Do it!

Thursday, February 19, 2009 5:12:52 AM UTC 

Or, how two unlike things can seem alike!

A while back, I followed a fascinating link from programming.reddit titled Pablo Picasso's version of refactoring: Reducing a drawing to 12 perfect pen strokes.

As the story goes, Pablo Picasso created a series of eleven lithographs of a bull in profile. He first created a detailed, accurate image of a bull. Then, for his next lithograph (I don't know what a lithograph is either, let's just pretend these are drawings from now on) he changed some aspects of the bull, accentuating its bull-ness. As he progressed, he began to remove detail, slowly replacing photorealism with smaller expressions of the same aspect, retaining the bull-ness. His last drawing was twelve or so thin strokes, a stick figure still roughly recognizable as a bull.

As the programming.reddit title indicated, this sounds a whole lot like refactoring!

It's super impressive, and I dearly urge you to look at the progression of Picasso lithographs yourself (click link below):

Now for the dangerous part.

.

.

.

.

.

.

.

.

.

Extra space added so you follow the link before viewing the section below; you'll miss out on the full experience otherwise!

.

.

.

.

.

.

So you're with me, right?

.

.

.

.

.

I was feeling great until I read this, the first comment on the reddit comments thread:

 

This is something with which I want to leave you. The next time someone makes a bad analogy, nail them with this Descartes quote. I can't pronounce Descartes properly, but that won't stop me, and it shouldn't stop you either. If in doubt, try a "dude, the French philosopher dude," sprinkle the word "dude" anywhere you're uncertain; they serve as TODOs for your vocabulary.

 

Aside: in true reddit fashion, this is the next highly-rated comment thread:

 

…and following that, unintentional, then intentional, references to realultimatepower.net.

Linking this discussion to the present day

This misuse of seeming similarity is (among other reasons) why a lot of us are bugged with recent CodingHorror posts. Specifically, let's take list a):

List A: SOLID principles et al

 

Here's list b), in The Ferengi Programmer (emphasis added):

List B: 285 Ferengi Rules of Acquisition

The Ferengi are a part of the Star Trek universe, primarily in Deep Space Nine. They're a race of ultra-capitalists whose every business transaction is governed by the 285 Rules of Acquisition. There's a rule for every possible business situation—and, inevitably, an interpretation of those rules that gives the Ferengi license to cheat, steal, and bend the truth to suit their needs.

And in case that was a coincidence, here's the list from his next post, responding to the standard rebuttal:

List C: processes and methodologies

 

So the question to you: are these three lists the same?

I win either way

My logic is inescapable. If you think the SOLID principles (list A) are in fact, as sneaky and extensive as the Ferengi Rules of Acquisition (list B), and are just the newest in a long line of fad methodologies (list C), then hey: I'll point you to the story about the bull, and how we all thought it was similar to refactoring. Except when you think about it, it's wasn't refactoring, it only resembled refactoring on the surface. I mean, come on, he drew pictures of a bull, it wasn't refactoring. I dare you to say the Picasso bull lithograph series was like refactoring.

And there I have you as well! Because if you refute my drawing-a-bull-isn't-like-refactoring argument, then by the very nature of your disagreement that "these two things aren't alike," you're proving that "these two things aren't alike!" Refute my "bull-metaphor doesn't apply to refactoring" argument to the "Ferengi rules metaphor doesn't apply to the SOLID principles" argument, and you've proven the very thing you're trying to argue against! I have you either way!

Next time I see you I'll collect the five dollars you owe me. And before you say to yourself "but I don't owe Peter $5," remember, my logic is irrefutable and you owe me a fiver*. Descartes says so. THE BULL! Pay up.
*this is a real word, people use it

Sunday, February 01, 2009 10:32:01 PM UTC 

This deserves its own post. After declaring that I won't be writing any iPhone apps, despite my secret dreams of iPhone app fame and riches, I went back and looked for the source of these secret, repressed dreams. Where did I get the idea that there's an iPhone app gold rush?

iPhone app gold rush stories

I didn't write the titles; the following links are as they appeared to me on either programming.reddit or Hacker News. Click each [comments] link if you're interested.

• iPhone Developer Quits Day Job After 'iShoot' Hits Number One - [comments]
• Today I lost a little faith in humanity: iPhone fart app pulls in nearly $10,000 *a day* - [comments]
• ISteam for iPhone earns a bunch of 22-year olds $100,000 in one month - [comments]
• "Crap" iPhone App Milking $200/hr - [comments]
• Developer strikes it rich with iPhone game: Makes $250K profit in two months. - [comments]

Wednesday, January 28, 2009 8:27:42 AM UTC 

I won't recap 2008; I dislike public introspection and what's more, you can read all about my 2008 by visiting my blog's home page, which has everything. I think the home page weighs in at 5MB of content right now. It's huge, and unashamed of its hugeness—my blog wears a T-shirt that says "large and in charge." The T-shirt has prominent pizza stains. Deal with it.

It's already late January, and I've missed the new year's deadline, but I'm still roughly in time for the Chinese new year.

New year's resolutions ahoy!

One thing dramatically missing from my 2008 was a proper book education. I read every programming-related aggregator known to mankind, listened to every programming podcast known to mankind, and read my share of technical weblogs. But I can't say I read programming books. Books!

I shouldn't have to explain why books are uniquely and deeply beneficial to any education. …So I won't.

Resolution: read 6 "fundamentals" books this year

6 is the reach goal, because for me, reading dense textbooks is tough. I used to put myself to sleep reading history textbooks. It turns out, Object Thinking by David West works just as well as a history textbook—even though (in both cases!) I'm interested in the subject at hand, focusing is tough.

Of the six, I'm going to start with JP's short list focused on coding fundamentals—not necessarily design, estimation, DDD, business analysis, project management, management, or whatever other useful fundamental skill you can imagine. Coding, not that other thing.

Sub-resolution: read 3 technology-focused books this year

No specifics here because I don't know which three; I'll know when I need them. I'm just writing this as an acknowledgement that yes, at some point in the next year I'll have to tackle some new frameworks; this space is reserved for three such Unnamed Frameworks.

Okay, so, books. That's obvious.

Resolution: read source code

Another obvious (and easy!) candidate is reading others' source code. Scott Hanselman has covered the why's of this topic well; I'm just here to say "me too." What's unfortunate is that I'm already running out of good samples. Most of the ASP.NET MVC samples don't even cover all the CRUD operations! CRUD!

At this one I'm doing well. So, stay the course!

Resolution: complete and release one minor development project this year

Next: practice. This is easy to describe. If I want to become a strong developer, I need to practice. Others have done a good job explaining why; I'll just say that I plan to do this. And not just attending coding dojos, which are great, but actually doing some self-directed practice. "Practice" isn't a specific goal, so instead, we'll work at one minor development project.

Minor means that it doesn't have to change the world or make me a billion jiggawatt dollars. I'm also going to try to stop reading all the rags-to-riches-iPhone-app stories that appear regularly, seducing me with their plausibility. There's been a lot of those recently (story#1 story#2 story#3 story#4 story#5 story#6).

Anyway, the point is—make a project, finish it, and do so in such a way that I'm not ashamed to release the source code. No ulterior motives, like releasing it later as an iPhone app. But if I were to release an iPhone app—I have a dream where Steve Jobs shows up on my doorstep holding a duffel bag full of cash. He's there making his daily delivery of my iPhone app's earnings. In my dream Steve Wozniak is there too, giving me a thumbs up and another duffel bag full of cash. Woz doesn't work for Apple anymore; he's there because my iPhone app is that good.

Anyway, no iPhone apps.

As a way to practice, make one project; practice techniques while making the app; no ulterior motives. Sounds easy enough. I should clarify that I can't count work projects, no matter how proud of them I may or may not be.

Resolution: boycott more Microsoft frameworks

While boycott is a strong word, it may not be strong enough to express how overwhelmed I am by the tide of technologies and frameworks coming from Microsoft! Also, it's a proven strategy—by boycotting Workflow 3.0 and LINQ to SQL in 2008, I saved a bunch of time not learning these deprecated frameworks. I'm sticking with this general strategy for 2009: if I don't need a technology, I won't pressure myself to learn it.

Putting all this in perspective

These are my technical learning goals for the year. Let me state that by no means is this my life priority for 2009. I think it would be awesome to reflect on 2009 and say "this was a great year," despite woefully failing to meet any of my stated goals above.

The point being, there are more important things than arguing about whether Silverlight matters. You know, life!

Oh and, quick, shot-across-the-bow answer: no, Silverlight still doesn't matter; don't learn it yet.

Final note: if your goal is continuous improvement, ask yourself why?

Something I noticed at the KAIZENC0NF was that there were exclusively enterprise development-related sessions (and I'm culpable as I could have suggested a topic Friday had I been there Friday). This didn't bother me at the time, but as I look back on the conference, it bothers me now. I think it's because I don't want to be truly great at enterprise development. Sure, I'm driven by a desire to be good at what I do. Sure, I want to remain gainfully employed, ideally such that I'm more valuable, rather than less, as time passes. This is all reasonable, and yes, I will put in the requisite effort. I.e., this means I'll spend time learning things I have no interest in learning, i.e. I'll work at it. The key word there being work.

But I'm not passionate about (name your enterprise vertical). I don't get excited learning a technology, framework or skill if I can only use it at work.

And don't think I just mean SharePoint (unpopular amongst .NET developers, an easy target); this applies also to the enterprise development aspects of DDD and Lean (popular, and on an upward arc*), and in learning enterprisey things like data warehouses. Or BPEL, or the abstract concepts behind BPEL. Yawn.
*the key here is to note that yes, I believe they're valuable, but no, I can't seem to get excited about learning them. Don't overreact, I just mean "I can't get excited about learning them."

What's the point of trying to become truly great at enterprise development? Just enterprise development?

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, June 03, 2008 8:00:47 AM UTC 

UPDATE NOTES, 2009-02-02: I own an iPod now, and am now shackled to iTunes like the rest of you (or your Zune equivalent, for the other rest of you). Anyway, point being: I now realize this podcast client roundup no longer matters, because everyone is a slave to their mp3 player. I still think listening to podcasts on your car mp3 player on a long commute is a great idea, it's just that my commute is now 10 minutes as opposed to ~80 each way.

This will be painless and quick.

First, I'll point out that I'm a huge podcast consumer. I've listened to at least 500 hours of audio via podcasts in my daily commute, and have been doing so regularly since ~2005. I've installed every major podcast client, even Carl's Pwopcatcher, to see what works for me.

Criteria

I'm looking for a podcast client that will help me a) get a list of all current and past episodes of all my shows, b) download them, c) automatically and without fuss, d) so that I can play them in my car.

That's pretty much it. In the table below I'll add a feature checkmark for products that do exceptionally well at certain features. I'll also call out unique bad features in the table as well.

Podcast Client Roundup

Feature description	Juice	Doppler	iTunes	FeedStation
Automatically downloads new shows	YES	YES	YES
Permits you to download past shows	YES	YES	-YES-	YES
Consistently and successfully completes downloads	YES		YES	YES
Allows you to schedule downloads for later (e.g. 2AM)		YES
Bittorrent integration (for DNR)	YES	YES
iTunes podcast directory			YES
'I already have iTunes installed' bonus			YES
'I hate the crapware iTunes installs extra' bonus			YES
'Juice kills podcasters' bandwidth by redownloading'	YES
'Juice crashes more than it closes gracefully'	YES

Conclusions

Juice is the best client for most of us who:

• aren't satisfied with the little sandbox iTunes gives you, UPDATE: and don't own an iPod or Zune, which necessarily tie you to their corresponding podcast client
• can't be bothered to manually check each item for download (as FeedStation would have you do). I have 24 feeds, and I just synced, and it turned out to be ~180 new shows. Had I been using FeedStation, that would have been 180 manual "hey I like this episode, let's download it" clicks.
• cannot abide by Doppler's frequent failed downloads. Doppler, you guys are the best, MINUS this one big bad bug! Fix it and I'll switch!

Unfortunately, as is also stated above, Juice is the worst client for any podcast producer. I know for a fact I've downloaded the entire ARCast catalog 4 times (and it's huge). This is probably due to the way Juice stores and compares new podcasts with its podcast download history—the history is so finicky that whenever someone republishes an item in their RSS feed, whether it's to change the date published or even something a human wouldn't notice, chances are good that we (those running Juice clients) will re-download all republished items. Individually, this ends up costing Ron Jacobs (or whoever foots the bill anyway) $0.10 for another 1GB of extra bandwidth every time Juice "starts over" on his feed. Well, who cares, you say, it's only ten cents. Sure, it's ten cents for you, me, and the other 100,000 podcast listeners using Juice. That's a lot of dimes, and there's no end in sight.

So while Juice is the best podcast client available today, you'll never see any podcaster recommend it. They can't afford a 2x-10x jump in their bandwidth bill.

But, just as a secret between you and me (you being the 3 people reading this): use Juice. Or, if you can stomach the limited featurest of iTunes, do that. UPDATE: I've found my way around iTunes. It does let you download old shows, and plus, I own an iPod now, so I'm stuck with it, unless I want to do something crazy like use Songbird. I'm not crazy, so I don't use Songbird.

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 

UPDATE: oops, looks like whoever was providing the Indy package up and disappeared. Oh well. Anyway, all you need to know is there's something called a "FtpWebReqeust" and that the rest of this (oooold) post no longer matters.

Original post

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.