They all look the same!

That’s a mess and it drives me crazy. One nice way to organize your shells, at least by group, is to color code them so they stand out better. For example, I use the following color scheme for my typical shell groups:

• SSH: Green on black
• Git: Purple on black
• CMD: Yellow on black
• PowerShell: Default white on blue

I also use custom sizes and font setups so I can get a little real estate onto my shell rather than the default Microsoft setup. The basic 80×25 default layout isn’t helping anybody!

Default Shell Layout. Yuk!

Here are some simple steps to customize the font for your shell and color code them in a way that makes it easy to navigate to:

1. Left click the little icon in the top left corner of window and click on the “Properties” menu item. You will get the “Command Prompt Properties window as illustrated below.

2. Beginning with the color tab, select the screen text and background you would like. I’m a sucker for the classic terminal black background so I usually sticky with it. Try the green or yellow colors because they stand out better against the black background.

Command Window Properties

3. Choose a layout that is suited for you. I’ve been using 90×40 lately so change the “Width” on the “Screen Buffer Size” and “Window Size” to 90 and the “Height” on the “Window Size” to 40. Leave the height on the “Screen Buffer Size” at 300. This dictates how much scrollable vertical area you can go back and review with the scrollbar on the right.

Choose Layout

4. The default font settings are a pretty chunky 8×12. Recent versions of Microsoft Windows have allowed for using True Type fonts. You can experiment with these a little to suit your needs. I use the Lucida Console font with a size of 12.

Font Settings

Tada! Look how nice that new shell looks! The font is smaller and nicer looking and you’ve got lots more real estate to issue and perform commands! Below is an example of my cmd, ssh, PowerShell, and Git shells all in one place but which are easily selectable because of the simple color coding:

Completed Shell

Try some experimentation with the fonts and colors to get a system that works for you. You’ll only have to configure the properties one time and will save LOADS of squinting while switching between windows!

SSH, Git, PowerShell, CMD

Today my friend Sara Chipps and I are announcing the creation of the MVC Melee! The contest will be a 48 hour competition where teams of ASP.NET MVC developers will have 2 days to come up with a rad web application idea and put it in action. The public will judge. Prizes will be given. Bragging rights will be secured.

What the what?

MVC Melee is based on the Rails Rumble which has been going on for a couple years now. It’s a wonderful competition which has produced some amazing web sites. I tried last year to get a team together but couldn’t make it happen. After the rumble was over I wondered why we didn’t have a similar competition in the MVC space? Sara concurred and the MVC Melee was born! The Rails Rumble folks have been very supportive so far which has been great!

How’s it work?

The rules are pretty straight forward. We’ve launched an informational site with the details of the competition, FAQ, etc. Naturally there is a twitter account too. Teams should be 1 to 4 people and any resources you use for your site should be free. The constraints are very heavily based on the Rails Rumble rules but modified where applicable. This is our first time out so we have to be a little conservative about what’s allowed to be used. Future melees may be easier to open up to additional libraries such as home brew MVC frameworks.

Lets get it on!

We anticipate registration will open around May 1st so start thinking about web site ideas and team candidates! Aesthetics and usability are part of the judging criteria so think about having a designer on the team who can sling Photoshop and CSS like a ninja.

I’m REALLY looking forward to see what folks can come up with in 48 hours! Help us spread the word and join the melee!

An interesting choice the Horn project team made was to keep the repository (not the design pattern, the actual place where the project meta data is stored) building from source and eschew binary packages altogether. Paul actually makes a very compelling case for this choice in his presentation at DSL DevCon.

While I agree that having the build from source option available is a good idea, I don’t think it should be the default option. Or at least, I think that a binary install option of equal weight should be available.

The Horn dependency and package system is based, at least in part, on the Gentoo Linux Portage manager. When Gentoo first showed up on the linux scene I started using it as my linux desktop and server of choice. The Portage system has awesome dependency resolution and listed the latest and greatest versions of packages like KDE, Gnome, and all the STABLE versions my favorite applications. I highlight stable because that’s what I like to use – the stable version – especially for important or production situations.

The thing I hated about Gentoo was waiting for packages and their dependencies to compile. Most small applications built fast. Most large ones, like x-org, Gnome, and KDE didn’t. The process usually went something like this: Start build, go to bed, wake up the next day and hope there were no build errors.

Now to be fair, there are no packages in Horn that will take all night to build. However…

log4net Build Failure

This is what happened when I tried to install log4net from source. The build failed. This happens more often than people may think. And it’s why I think a “install from binary” option is needed.

Pauls argument for building from source via his presentation goes something like this:

1. All developers like to use the bleedingest edgiest version of a software package so we all download from trunk and compile.
2. Because of this, we have dependency issues during builds because the source from a dependent package may be out of date. Thus, that package also needs to have the freshest source pulled and built. (ie, dependency checking and resolution)

I agree that these are issues. But only when building from source. The question then becomes, do most developers use the latest trunk builds of open source projects like Nhibernate, Castle Windsor, and MVCContrib?

Having spent a lot of time on both the MSDN and ALT.NET side of the developer camps, I’m comfortable saying that a lot of people don’t want to build from source. They don’t want to use the latest bleeding edge version. They just need the package to work stably and reliably. Horn pulls the source from the repository itself where the project is hosted. (so far only svn is supported but git is on the way) There is no gateway to be sure packages are stable and feature complete. Just because something builds doesn’t mean it’s ready to be tagged as the next version.

This raises some more questions which I haven’t been able to answer myself yet: Who decides what packages are inside of Horn right now? Presumably Paul and his team are playing things a little close to the vest right now, adding prominent open source projects to their repository, and making sure they build correctly.  And that’s the right thing to do. But who decides when the next version of a package is ready to be included in the repository? Does the original developer team have a say? If they commit each night and the Horn build “checker” doesn’t fail does this mean that a new build of a project is available each day? In the future, will I be able to add my own open source project to the Horn repository? Will I have any control over how often it’s versioned?

I’ve actually been thinking a lot about this problem over the last couple of months and I think I have a solution which I’ll detail in a future post.

For now, however, I really do wish the Horn project team well. I’ve already joined the Google Horn Developer Group to follow the goings on and will hopefully be able to inject some opinion about adding binary support.

Give the Horn project a look. It very well could be the future of .NET package management for community and open source projects!

After deciding on how I wanted the app to look and feel, I got to work. At least, I tried to. Strait away I ran into issues in both trying to write a Windows Explorer extension in .NET and POSTing a multi-part form POST. I don’t want to devolve into too much of a rant but it IS 2009 and we STILL can’t write simple Explorer extensions using managed code which just reinforces my feeling that .NET programmers are second-class Windows citizens. Version 4.0 is around the corner and I still have to import kernel32.dll to perform some basic OS functions.

The other problem, POSTing a multi-part form POST turned out to be a little bit more surmountable an issue. The goal was to use the Baconfile API to upload a file. In other languages such as Ruby, constructing a multi-part form post is actually quite simple. In C# it is not. Between HttpWebRequest and the WebClient Upload method, there was no way to create a custom post whereby I added some arbitrary number of POST parameters.

After awhile I found Brian Grinstead‘s post about how he had constructed his own class that enabled users to create their own custom-formed multi-part form POST. Considering how often a function like this is used, especially on public APIs, I was as surprised as he was that this kind of functionality wasn’t in the .NET framework itself. His example class worked flawlessly.

I needed to add some tweaks such as basic http auth and so I created a new GitHub project to support the work.

I plan to add more functions such as a cookie container, ActiveDirectory auth, and whatever else seems logical. If I’ve missed something and there really IS an easy way to do this using out-of-the-box classes in the .NET framework, please let me know.

For those who don’t already know, John Resig is the author, and primary maintainer of jQuery, one of the leading Javascript frameworks. Comparatively speaking, jQuery is newer than some of the other frameworks like script.aculo.us, but has picked up enormous adoption in a fairly short amount of time. There is a reason for this. And it’s not JUST because jQuery is good.

As you might have guessed from the title of his session, John did not talk about how to use jQuery. This wasn’t a “kickstart” class. His talk was about how to treat your open source project, for lack of a better phrase, like a business.

Make it SUPER easy to get started.

One of the rules John went over was about making your project/product extremely easy to get started with. That means:

1. Complete (and up to date) documentation.
2. Easy to read documentation.
3. Clear cut examples that actually WORK in practice.
4. Make it easy to download!

If these all sound like no-brainers, it’s because they are. And you wouldn’t believe how many projects don’t follow any of these tenets.

Treat your users like you’d treat your customers.

Being available to their users for help and advice is something that some, but sadly not all, product-based businesses understand. For open source project owners, this means being active on your wiki, your forums, and your email lists. John had a great anecdote about a help request he received to his personal email account. Instead of ignoring the user or reeling off a terse “RTFM” response, he exchanged a few messages with them and eventually got them sorted. It turns out this user was a head architect at Amazon.com. You never know who your users are – treat them all like customers. Satisfaction guaranteed.

Track your trends!

The jQuery project makes HEAVY use of Google Analytics to track their adoption, usage, and attrition. Between the end of 2007 and beginning of 2008, the team saw a sharp drop in jQuery adoption and then a very gradual climb. Eventually they surmised that, for whatever reason, users and developers “forgot” what they were doing over their holiday break and came back to work in the new year with new priorities. To combat this anomaly, the team timed the most recent release of jQuery for the beginning of January 2009. The results showed that they still saw the usual post-holiday attrition but it was followed by a SHARP adoption which brought jQuery usage up to higher levels than before the holiday season. Some BUSINESSES don’t track usage trends this well! If this sounds a lot more like marketing, that’s because it is. People won’t come, and more importantly stay, just because you built it.

Build a team.

It may be surprising to learn that jQuery only has around 4 full time maintainers at any given time but the total team is comprised of about 25 people. The other 20 people complete the team and are what elevates the jQuery project to a level most open source projects don’t reach. There are dedicated documentation team members, evangelism folks, and example writers. There are people who monitor the forums, update the wiki, and keep the message of the benefits of jQuery fresh. One person can’t do it all. But a few dedicated people can make a HUGE difference in the “completeness” of your project.

Everyone has to start their project somewhere. However, if you are serious about improving the lives of your users, then treat your project like a product. Treat your organization like a business. Make it easy to adopt. Make the documentation and examples stellar. And above all, treat your users [customers] with respect and show them patience. It will pay dividends.