Saturday, July 07, 2007

Save streaming music to disk from WinAmp using Streamripper

Streamripper is a plug-in for WinAmp 5.0 that will allow you to save streaming music to disk. Simply download the latest version and run the installer. When you start WinAmp an additional window titled "STREAMRIPPER" will be open as well. While listening to a stream that you want to record, click the start button in the Streamripper window. StreamRipper will beging to save the files in a folder on your desktop by default. To change the location of the save folder, click the config button in the Streamripper window, select the File tab and change the output directory to wherever you want Streamripper to save to.

A thorough tutorial on how to use Streamripper with WinAmp can be found here.

Submit this story to DotNetKicks

How to automatically embed DotNetKicks "kick it" links into your Blogger posts.

DotNetKicks is a social bookmarking site, kind of like Digg but targeted at .NET developers. The stories are moderated using a democratic system where articles get votes, called kicks. The more kicks you get the higher up you move in the story hierarchy. When a story is submitted it starts in a pending stories queue. If you get enough kicks your story will be moved from the pending stories queue to the front page. This might all sound like fun and games but what really perked my ears up was their integration with Google's AdSense to earn money for submitted stories. DotNetKicks will split 50% of the ad revenue for clicks through to stories you submit. Nice.

The trick is getting submitted, if your readers aren't aware of DotNetKicks they won't know to submit and/or Kick your articles. You need a way to let them know about the site, but without being crass about it. I didn't want to manually submit my post every time I blogged, so I used Blogger's template system to help do it for me.

<p><a expr:href='"http://www.dotnetkicks.com/submit/?url=" + data:post.url + "&title=" + data:post.title' expr:id='data:widget.instanceId + "_kickit"'><img alt='Submit this story to DotNetKicks' expr:src='"http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=" + data:post.url'/></a></p>

I created a tag that I inserted into my Blogger posts template that will automatically display the number of kicks the article has received so far. If you click on the link and the story hasn't already been submitted you will automatically be redirected to DotNetKicks article submission page with the link and title already filled out for you. If the story has already been submitted your vote will be added to the kicks counter.

To add the tag into your post template go to the Template tab under your Blogger accounts Customization section. Select "Edit HTML" and check the "Expand Widget Templates" check box. Scan the template until you find a line that looks something like "<p><data:post.body/></p>". That is where the Blogger templating engine inserts the body of your post. I inserted my tag to appear directly below the body of my posts but you can play around with whatever position you like by using the "Preview" button. You'll have to save the template to apply the changes when you are satisfied.

PS, I used the above steps to post this article to DotNetKicks.

Follow up: The URL changed for submitting links, the snippet in the article has been updated to output the correct link.

Submit this story to DotNetKicks

Friday, July 06, 2007

Programming without source control is like coding without pants.

Sure, I can code with no pants on. But if I'm working on a team it's better if I put on some nice slacks.

Submit this story to DotNetKicks

Wednesday, July 04, 2007

One Shall Stand, One Shall Fall

I just got back from seeing the Transformers movie. All I have to say about that is, "Mr. Bay I am sorry for doubting you." This is what summer popcorn adventure movies are supposed to be. Simple, straight-forward action, driving music and just enough humor and light romance to keep it fun. And gigantic robots smashing the shit out of each other.

Personally, I have quite a history with the Transformers franchise. The first thing I ever purchased with my own money was a first generation Optimus Prime. I had to do chores at my father's truck shop for several weekends before I saved up enough money. $13.00 American. As with all children's fancies I eventually traded him for a new Rodimus Prime around the time of the first Transformers movie. Big mistake, Rodimus was never as much fun as Optimus.

I'm pretty sure I did more than my fair share of whining and wheedling whenever my mother got too close to the toy section, but my biggest showdown with my mom was over the Transformers movie. We were at a Jewel that had a video rental center towards the front of the store that was carrying the object of my desire. I don't recall the entire event completely, but I'm sure it went something like this. As my mother entered the cashiers line to pay for our daily bread when I began my attack. She was informed of the movie and just how important it was, but she resisted. As she packed up our groceries and moved out towards the door I realized the object of my desires was not in our possession, I became frantic. I remember stomping and crying and yelling that I was being abused and she probably didn't love me or care about me. She kept her will and I didn't get the movie that day, but I like to think I put up quite the scene. I have to admire her fortitude, I was quite the showman.

Autobots, transform and roll out.

Submit this story to DotNetKicks

Monday, July 02, 2007

Naming Conventions for Project and Solution Folders

Small Solution Structures

If the project space is small I'll just name the folder and solution to match the fully-qualified namespace.

Folder
c:\FrogsBrain.MyFancyPants

Solution
c:\FrogsBrain.MyFancyPants\FrogsBrain.MyFancyPants.sln

Namespace
FrogsBrain.MyFancyPants

Larger Solution Structures

If the solution directory tree is very deep or there are many projects are under the root namespace I will break the solution folders up to remove redundant uses of the root name.

Folder
c:\FrogsBrain\MyFancyPants

Solution
c:\FrogsBrain\MyFancyPants\MyFancyPants.sln

Namespace
FrogsBrain.MyFancyPants

This will help keep to avoid errors when a path can get too long and wreak havoc with some source control tools.

Project Structures

The project names will follow suit, leaving out the name of the solution.

Folder
c:\FrogsBrain.MyFancyPants\Library
OR
c:\FrogsBrain\MyFancyPants\Library

Project
c:\FrogsBrain.MyFancyPants\Library\Library.csproj
OR
c:\FrogsBrain\MyFancyPants\Library\Library.csproj

Namespace
FrogsBrain.MyFancyPants.Library

Output
FrogsBrain.MyFancyPants.Library.dll

The exception is that the project output will be the fully-qualified name of the project. This makes identifying the assembly easier and prevent collision of names like Library.dll.

Folders Not Divided By Namespace

Inside of projects I try to follow the same structure but if a folder is not to be included in a namespace or I want to group some files without changing the namespace structure I will create a folder with a "_" prefix.

Project
c:\FrogsBrain\MyFancyPants\Library\Library.csproj

Folders
c:\FrogsBrain\MyFancyPants\Library\_build
c:\FrogsBrain\MyFancyPants\Library\_configuration
c:\FrogsBrain\MyFancyPants\Library\_documentation
c:\FrogsBrain\MyFancyPants\Library\_contracts\ISomeView.cs
c:\FrogsBrain\MyFancyPants\Library\_service\ISomeService.cs

Namespace
FrogsBrain.MyFancyPants.Library

Output
FrogsBrain.MyFancyPants.Library.dll

All files inside of "_" prefix folders are considered to be in the same namespace as their parent folder.




I've tried variations of these structures but will be implementing this as the standard structure for all projects I am responsible for in the future. It's the cleanest and easiest to manage layout I've worked with and has grown from experimentation over a couple years. So, if you look at some of my code and it doesn't already follow this pattern it will eventually.

Submit this story to DotNetKicks

Structuring NAnt Buildfiles For CCNet builds.

I get all verklempt over automated builds. The usefulness of scripting your builds and running them on an automated system cannot be overstated. Period.

Preventing bloat and keeping your builds in sync with the code base is difficult if you don't keep them close. Typically code will be split into separate files to make it more maintainable, build files are no different. I've found that a single build file for anything but the simplest project can grow very unwieldy quickly but by keeping only one coordinating build file at the solution level and splitting the builds up by project, automated builds can be easier to implement and manage. Also, by keeping the files alongside the code they are the building the builds stay in sync with the code they are building.

For example, I have a solution containing 3 projects. One is an executable, two are libraries. The folder structure and the naming of the solutions typically follows the structure of the namespaces.

Let's work from a root folder named 'source' sitting on C:.

c:\source

Inside of here I have a solution folder named FrogsBrain.MyFancyPants, the solution will match the name of the folder.

c:\source\FrogsBrain.MyFancyPants\FrogsBrain.MyFancyPants.sln

I'll go ahead and add my standard folder to hold my master build script.

c:\source\FrogsBrain.MyFancyPants\_build\FrogsBrain.MyFancyPants.build

The primary concern of this build file will be to call the project builds in the correct order and perform any global configuration for those projects.

Now I will build the project folders.

c:\source\FrogsBrain.MyFancyPants\Library\Library.csproj

And this too will contain a folder for it's respective build file.

c:\source\FrogsBrain.MyFancyPants\Library\_build\Library.build

The pattern will be repeated for the other two projects.

c:\source\FrogsBrain.MyFancyPants\Library\UI.csproj
c:\source\FrogsBrain.MyFancyPants\Library\_build\UI.build
c:\source\FrogsBrain.MyFancyPants\Library\Tests.csproj
c:\source\FrogsBrain.MyFancyPants\Library\_build\Tests.build

VS.Net Solutions can hold items that are not inside a project. Unfortunately, whenever you just add a Solution Item, VS.Net will ignore the folder structure and link to the item directly underneath the solution name. To imitate your physical folder inside your solution, add a new Solution Folder and name it '_build' to match your physical folder, then add the master build file as a Solution Item inside that folder.

Now your VS.Net Solution will look like...

FrogsBrain.MyFancyPants
    _build
        FrogsBrain.MyFancyPants.build
    Library
        _build
            Library.build
    UI
        _build
            UI.build
    Tests
        _build
            Tests.build


Now your build files will be added to source control and versioned alongside the code they are building. This will make executing automated builds easier because the location and naming of the build files will be standardized, making the process easier and more repeatable.

Submit this story to DotNetKicks

Expanding My Source Control Horizons.

I have really enjoyed using SourceGear's Vault source control server for all my personal development needs for quite a while and I have been nothing but happy with them, I need to expand my horizons.

What I really like about SourceGear, aside from their excellent products, is that they seem to really get how to cater to the small, independent software developer. By providing a free single-user license they put themselves within reach of the developer who could not otherwise afford their product. They also are owned by an individual who really seems to know how to communicate with developers on their level. Through his blog about the daily issues of his software firm and excellent book, Business of Software, which I own and recommend picking up. Also, they support developers desire to extend their products with an automation API and a set of NAnt extensions.

But comfort breeds complacency. I need to try new stuff and see what's out there.

The world of source control tools has seen a surge of growth and even better, competition over the past couple years. The list of actively developed source controls tools, that are within the reach of a mere mortal developer, has grown tremendously and the choices are all very attractive.

So, I've decided to play around with a couple vendors that have licenses that appeal to me. So here's a brief description of what I want in terms of features and licensing.

Cheap, or at least reasonably priced, since I'm not writing packaged software for sale at this point, I'd like a vendor who has discounted licenses for open-source software developers and teams. I like to constantly merge/check-in my code to the repository so having to break flow by leaving the comfort of VS.Net is not desirable. Also, I don't like having to memorize the command-line utility, I am a GUI brat and although I've worked with services and console apps for years I prefer managing the server via some form of GUI, web-based or standalone application doesn't matter. There also needs to be the ability to integrate with CruiseControl.NET and NAnt. Also, labeling needs to be easy, branching and merging of branches should be simple operations. The creation of repositories and working structures needs to be painless. Checkins needs to be atomic and transactional, individual pieces of changelists need to be easily rolled back and commit failures cannot corrupt the repository.


I know that my needs are very MSDevcentric. Hey, it's my list, if you want stuff for whatever platform you work in then that's your wish-list. So basing my requirements off that list I've looked around and have picked a couple tools that I am going to evaluate and report on before I decide whether to just stick with Vault or begin using another tool for my everyday use.


  • Perforce

    Very attractive open-source developer friendly licensing. An excellent book that covers Perforce as a tool is The Build Master which I own and have read.


  • Subversion

    CollabNet binaries, can't beat the license, FREE! I don't own this one yet but will be ordering it from Amazon. Version Control with Subversion


  • Visual Source Safe 6/2005

    From personal and painful experience, "Blech". I inherited it at my job but it's better than everyone working off a shared folder.


  • SourceGear Vault

    What I currently use, but will list it's merits. Vault is also covered in Coder to Developer, which I read cover-to-cover but then gave away as a gift to an excellent Agilist developer when he moved on to another company. Also, I think it's where I first heard about Vault.


  • Team Server

    I love me some CodePlex, best place for MS-based OSS projects I know of but I'm going to focus on the SCM aspect.


  • Surround SCM

    The current likely candidate for replacing VSS at work.



As I work through the different tools for the next couple weeks I'll update on my experiences using those tools in my day-to-day development tasks.

Submit this story to DotNetKicks