xPathFinder

{

The short version:
I'm releasing xPathFinder, a tool I wrote for doing XPATH expressions against xml files on the file system. You can get information about it as a tool by going to the website. Here are some screenshots:

 

The long version:
Not too long ago I ran into a problem that I thought would be common but didn't seem to have a canned solution. We use a webservice to store some data in a database but we also store the xml files transmitted on the file system as a defensive maneuver in case the database is unavailable or the xml is invalid. After a while I was dealing with a lot of xml files - far too many to search one at a time and needing more structured lookup than a desktop search tool offered. This is the raison d'etre of this tool. Of course it could have been a quick script in -insert language of choice- but this was something I needed to do repeatedly and have more facility with than console output. I'm also planning to make it simple enough for our client to use. It was a goal of mine to get it up before the end of the year so I'm happily posting this a day early.

One more footnote to this tool - stylistically I've done quite a bit of blending between Windows Forms and Web by leveraging the WebBrowser control heavily for things I thought would be easier to quickly generate html for as well as the feedback mechanism which allows users to report bugs or request features. It's so tightly coupled that while it will work without an internet connection, it's a much more limited experience. I really like this model and will probably start doing more blending like this for new work.

You can get more detail from the website or just ask directly by submitting feedback.

Future plans?

1. XPATH functionality works for most xml documents, but namespace heavy documents with prefixes seem to throw a curve ball.
2. What I'm posting was actually a fast prototype I intended to use to make this tool in WPF from - I'm not sure that the WPF step is still necessary but I may release an updated version since this is a fairly straight forward utility.
3. I'd like to make it open source. Not sure of what steps to follow, but CodePlex is probably the best starting point. I always promise myself I'll clean up my code before doing something like that but maybe I should just bite the bullet since I think the idea is sound enough.

}

Installing ASP.NET 3.5 MVC Preview

{

Code Climber has this great list of what you need to download and the order in which you must install it. I just completed my installation and have begun to poke around.

}

Someday Language: F#

{

There's a lot to learn these days (whenever isn't there a lot?) and one thing I will do for 2008 is make a list of technologies I'd like to dive into with some sense of priorities. 

Among the ASP.NET MVC, Powershell 2.0, and Iron Python (for starters) I've been interested in F#. First as a topic on Hanselminutes but I lurk on Harry Pierson's blog and he's been posting about it quite a bit.  Here are some links:

1. F# Overview on hubFS
2. From DevHawk:

• F# as a Second .NET Language
• Functional Programming
• Pattern Matching
• Type Inference
• Assorted Goodness
• Assorted Not-So-Goodness

Someday it is.

}

Mads Samples

{

Mads Kristensen has a listing of his code samples. One thing I like about Mads' samples is that they are all very straightforward without unnecessary layers of abstraction.

}

The FogBugz Salesman

{

Once or twice people have confused what I'm doing with sales. Some time back I met with a prospective client and kept having to explain that I actually do write code and would probably be a lead developer on any work they gave us. The reaction I had for even the mere perception that I was "sales" was a little surprising to myself although with some reflection I realized it was because I conflated most of what I disliked about salesmen into an image I couldn't deal with for myself:

• Style over substance
• Shallow understanding
• Pandering for a quick buck

But once in my life I was a happy salesman. Some time back I pushed the company I worked for into adopting FogBugz and really building a large part of our lifecycle around it. I did so enthusiastically after reading Joel's early essays on bug tracking and seeing how well it applied to our situation.

I've seen other bug tracking software since but still think the FogBugz experience was best.  It seems simple, but because of how much thought has gone into the product, I gather a lot of work has gone into keeping it stripped from unnecessary features.

To be clear, I don't work as a bona fide "in house" developer. But as a consulting company, I spend a lot of time playing that role or working with people in it.  It's therefore conflicting when I read his understanding of what it means to work in house. Phil Haack had it right in the middle of 2005 when he wrote of the irony of this disdain towards the people that would be excited to use his software in the first place.

I wonder what kind of conditioning it is - maybe that I've liked musical artists who are fairly open about loathing their fanbase - but I still miss the simplicity and elegance of FogBugz. 

What's sad these days is that as much as I'd like to slip on the poorly fitting suit and do my sales routine, we get Sharepoint for free (okay, not free but let's just say Microsoft does an excellent job making it seem so) and it's the environment in which we track what I'd gotten my previous company to use FogBugz for so effectively.  I'm not a big Sharepoint fan (that's an understatement) so I'd even be tempted to go The Powers That Be and ask for FogBugz if I couldn't predict the answer right away.

Tomorrow I'll be unflustered but I've got a few comments on what it's like to be in house:

1. In a small enough company, it's great to have decision making power.  I've used technologies like Ajax and Perl where a larger environment would have involved committee meetings with some manager shooting me down for doing things differently. You don't have to be a renegade to do this, just document what you do well and communicate with anyone you're working with that may have to look at it on your behalf.

2. In consulting it helps a lot to condition your client.  First build confidence with a track record of success, after which the client is usually willing to listen to you when you'd like to do things "right" or improve a piece of software even if it's getting by functionally.  After a while, depending on the client, they will usually just trust your judgement and stay away from technical arguments unless there's some disproportionate cost.

3. Software is never finished.  This is true even for what is developed in house.  As a result the process of continual improvement still exists.  It takes a tremendous amount of discipline to try to develop things right when there's a small budget or a tight deadline but I always think of those moments I've spent late at night hacking the ugliest workarounds because of a bad initial effort. Most of the time finishing when it's "good enough" is about the taste and craftsmanship of the person who writes the software; whether they tried to think of the future or not.

4. From working in both a "software company" and a "consulting company" I understand that software development is always a process of coming to terms with friction - all the unexpected realities and circumstances of real life and real users. Different places will have different kinds of friction; where an in house developer may have to deal with the kind of discipline it takes to write unit tests on a deadline a programmer at a software company may have the dilemma of trying to be all things to all people.

}

Comment Spam Begone

{

I maintain a few personal websites, one of the closest to my heart is phoDak, a photoblog.  I wrote the site using ASP.NET about two years ago and intended it to be a low key, personal area to post pictures.  I had absolutely no validation on comments and my "what will be" attitude worked for a long time until about a week ago when I saw a comment spam link to porn right off the most recent picture.  No longer avoidable, I looked into a few ways to block unwanted comments and came up with a hybrid approach:

1. Use a photo/word as validation for a human user, just like Jeff Atwood's blog.
2. I heard about Akismet from Phil Haack who mentioned it in passing on a Dot Net Rocks episode. I found a free library and wrote about 10 lines of code:

AkismetManager akismetManager = 
	new AkismetManager("my key", "my site");
string ip = 
	Request.ServerVariables["REMOTE_ADDR"].ToString();
if(akismetManager.IsValidKey()){
	AkismetItem item = 
		new AkismetItem(ip, Request.UserAgent.ToString());
	item.AuthorName = 
		CommentOwnerTextbox.Text;
	item.AuthorUrl = 
		CommentURLTextbox.Text;
	item.Content = 
		CommentTextbox.Text;
	if(akismetManager.IsSpam(item)){
		akismetManager.SubmitSpam(item);
		return;
	}
}

Q.E.D., really. Somewhat Mort-ish for me to lean solely on the library but it works beautifully: my spam comments since implementation remain at absolute zero.

}

CodeMash: I'll be there!

{

On a whim I've signed up to be at CodeMash 2008.  After learning about the conference when Hanselman posted he'd keynote, I mapped out that Sandusky, OH (Whiskey, Tango, Foxtrot!) is none too far (an audio book's worth of distance).

I'm really looking forward to the opportunity to walk among Elvis and Einstein, hopefully gleaning some direction along the way. The session list is impressive, I'm thinking it will be hard to choose a particular direction.

I've been studying Python of late, so I'm really looking forward to Bruce Eckel's Why I Love Python. Another interestingly titled Python presentation Crash, Smash, Kaboom Course in Python will be run by MIT alum Catherine Devlin.  Finally on the Python front, I'll try to squeeze into the Getting Started with Django session.

On the "indy" .NET programming, I'm interested in the Introducing Castle session from Jay R. Wren. Because Hanselman is going to be there I can't imagine no mention of ASP.NET MVC stuff, so hopefully it will somehow be mentioned at least comparatively.

Jesse Liberty is going to present on Silverlight, so that's something I won't miss either. There are other Microsoft technology presentations I should see but it would be hard to sit in on a Sharepoint session when I could be learning Python design patterns.

The other area of interest I'll have is the Dojo stuff, two sessions in particular: Overview of the Dojo JavaScript Toolkit and Working Offline with Dojo+Google Gears, both by Kevin Dangoor.

Well, it should be interesting from start to finish, I'll be working on my note taking skills so that I can share what I do learn.

 

}

Tis the Season

{

Don't get me wrong, I love Christmas too, but I really like the Advent Calendars that wind up the year. 

24 ways
Drew McLellan and his crew have been putting together web development tricks to round out the year for the last few years.

Perl Advent Calendar
None too late and looking like it was designed by a Perl programmer.

Two advent calendars I'd love to see:
1. Microsoft .NET
2. [Iron] Python

}