Sometime back I started a personal blog over on msn spaces in addition to my more tech-focused blog here. Being the lazy guy I am and not wanting to have to open two different tools to post to both my technical blog here and my personal blog over there, one of the first things I did was to find out if spaces supported any of the blogging APIs.

A quick google search brought me to Dare's disappointing explanation that the MSN team wasn’t fond of the existing APIs and were exploring options.

Ok, that's fine, I thought. It's in beta, they're figuring things out. I can wait a month or two. Well, I got tired of waiting, so I rolled my own makeshift solution. I’ve put it in a gotdotnet workspace in case anybody else finds it useful.

Introducing PostToSpaces - a MetaWeblogAPI web service endpoint that allows users to submit posts to an MSN Space.

Get it here (via gotdotnet): Download

What is it? It’s a simple little web service that simply intercepts a MetaWeblog.newPost method call, creates an SMTP mail containing the post, and sends it to the MSN Spaces email address configured for Email Publishing for the space. No more, no less.

To use it, you’ll need a server to host the service that has a configured smtp server. Follow the instructions below.

INSTALLATION INSTRUCTIONS
-------------------------
1. Copy the service to the desired server and configure a virtual directory to point to it.
2. Change the config values in the web.config to point to the appropriate SmtpServer
   and to use your Send From Email Address as configured in your MSN space.
3. When calling the newPost method, parameters should represent the following:
    - blogid = [not used]
    - username = [MSN space name]
    - password = [MSN space email publishing secret word]
    - post = [struct containing your post title and description]
    - publish = [not used]

In a follow up post, I’ll talk about how I hooked PostToSpaces up with BlogJet for unified posting goodness…

This time from the perspective of ROI: Free Time is Not Free

(via Rob Chartier)

http://departments.bloomu.edu/english/111/pullmethod.htm

Sounds familiar doesn’t it?

It seems that Scrum meetings (just the meetings – not the full-scale methodology yet) are starting to catch on at my workplace. However, I’ve heard grumblings from co-workers on other teams that talk about how their “scrums” are droning on and on and not being very productive. I think this may be due to a lack of understanding or clear definition by the scrum leader as to what the meeting should look like.

I found an excellent article that sums it up in a nutshell…

Scrum meetings defined:

The Meeting

As an integral part of the Scrum methodology, teams meet frequently – daily or every other day. The meeting usually lasts fifteen minutes, occasionally longer, but never more than thirty minutes. This provides enough time to address obstacles, but does not allow time to define solutions. Problem-solving discussion is held later, where only those who are involved in the problem attend. Having the meeting focus on raising but not solving issues is definitely a factor in making these meetings effective.

During the meeting, the Scrum Master (usually the team leader) asks three questions of each team member. Each team member answers those three questions. That’s it. Meeting over.

Here are the three questions:

1. Relative to the Backlog (list of incomplete tasks), what have you completed since the last meeting?

2. What obstacles got in the way of your completing this work?

3. Relative to the Backlog, what specific things do you plan to accomplish between now and the next meeting

I also like the XP concept of standing up during these meetings to reinforce the idea of keeping them short. I think, in the end though, it all rests on the meeting facilitator’s shoulders to keep the meetings efficient and meaningful.

This is one of the best papers I've ever read for making the case for Agile Methodologies. It's long, but well worth it. So fight through (that means you, Scott).

Here's an excellent excerpt about the problem with doing up-front requirements sign-off (i.e. taking the Waterfall approach):

Here's the problem. Suppose you say to customers, "Okay, we're going to give you a system to solve XYZ problem. We're going to gather all of the requirements, analyze them, and write them down in a big book for you to review. Your job is to make sure we have gotten everything right, because once we start coding, you can't make any changes. So we're going to ask you to sign-off on the requirements, and then if you want any changes, we'll estimate the cost and you'll have to approve the change.

Now let's assume that the customers don't really know what they need to solve XYZ problem (that's why they asked you to solve it). Thus, they are worried that they might forget to tell you something as you gather requirements, so they try to be very thorough. The process does not ask them to be sure that they need something when they put it on the requirements list; the process encourages them to put everything on the list unless they are certain they will not use it.

Is it any wonder that a system developed under these rules will have many features that end up in the rarely-if-ever used category? In our standard approach to defining scope, we build in tremendous incentives for excessive scope. Freezing scope usually has exactly the opposite effect that we desire. It does not prevent scope creep; it causes scope bloat.

FYI, I ran across this via another excellent post by Darrell Norton with a response to concerns about agile approaches. If you are interested in this subject, you should read that as well.

I've always felt that there are really two main problems with searching the web - either you can't find what you're looking for because the content doesn't exist / hasn't been indexed, or you can't find what you're looking for because too much content exists.

The first issue seems to be the one that gets the most focus, but I find the second equally frustrating.  Well, Scott Mitchell came up with an idea that touches on both ends of the problem (a twofer, if you will).

He proposes using a gmail account as a knowledge base to subscribe to specialized content such as USENET groups, forums, Yahoo! Groups, etc, and then taking advantage of their mass storage and excellent search capability to perform focused searches on content that is often missed by search engine spiders.  Brilliant!

A very nice little Google Suggest-like control:  http://www.codeproject.com/jscript/jsactb.asp

Jim Shore (of FIT and NUnitASP fame) says he doesn't like CruiseControl.  I have to respectfully disagree on this one.

He says:

CruiseControl is a traffic cop: it doesn't help you follow the rules; it just tells you when you've broken them. If the team does their job, and never breaks the build, you'll never hear from CruiseControl. So why use it? I've seen two common reasons:

1. The build does fail--often enough for CruiseControl to be valuable.
2. The automated build process is too slow to wait around for.

First off, I disagree with the implication that value is wholly derived from the frequency of use.  There are many things that I don't use often, but I think are highly valuable.  The alarm for my home security system has never sounded, but I think the security system is still a valuable and crucial part of my home.  I've rarely filed a claim on my car insurance, but I haven't cancelled it yet due to lack of use.  Or, closer to home, my virus scanner runs nightly, and unless something goes wrong, I never hear from it.  I haven't heard from it in months in fact....is it even worthwhile to have anymore?  Yes, of course.

These analogies are obviously not perfect.  I understand what Jim is saying though.  If each individual of a team is truly 'doing the right thing' and writing tests (good, fast tests) first before a line of code, getting latest code and running all tests before checking in, etc, then you should rarely, if ever, experience integration problems. And yes, CruiseControl can be used as a crutch to avoid fixing inherent problems with slow tests or unstable code. 

But let's not throw the baby out with the bathwater.  CruiseControl is a tool that can help you identify the problems that arise when this type of development utopia fails to materialize.

Rather than a traffic cop, I prefer to think of CruiseControl as a health monitor.  Every time someone checks something in, CruiseControl runs some tests, checks some reflexes, listens to the project take some deep breaths, and gives it a thumbs up or thumbs down.  On the projects I've used it on, we've set it up to receive notification of the good news and the bad news.  And, in this case, the check it provides becomes a palpable development rhythm.  A heartbeat.

The great thing about it is that as you get a feel for the rhythm it provides, you can feel when things are not going as they should be before it reaches the state where the build is actually breaking.  The team isn't checking code in as frequently as before, perhaps the project is slipping a bit.  Or, the build is taking longer than it used to, perhaps some test refactoring is in order.  Or, perhaps, a performance problem is getting bigger.  And, when something does fail, you know immediately.   Everyone does.   It's the fail fast principle at it's best.  What's not to like about that?