In Valid Logic

Recently, I’ve been working on migrating our build process at Telligent from using Cruise Control .NET to use JetBrain’s Team City. Cruise Control has served us well, but after looking at the feature set of Team City, it had a number of things that we were wanting to leverage as we continued to expand our build process. Was asked on Twitter what I liked so much about Team City versus Cruise Control, but there wasn’t a good way to sum it up in 140 characters. So here is a brief list of some of the reasons:

1. No XML configuration files. Granted, our builds are in NAnt, so we’re still married to XML, but creating a new build doesn’t need to take any XML editing anymore. Our build scripts have no hard coded values, everything it needs it passed in from Team City. So we can go an existing build, click Copy, then just edit the configuration settings as needed.
2. It queues builds. We run a number of daily builds at 4pm Central and at that time, the build server comes to a screeching halt because all of them run at the same time. We’ve had to stagger them an extend the timeout limit on several because of how slow it gets. Team City instead runs one at a time, queues the others, and lets you prioritize the queue if you need to bump things up.
3. Does more for you. First of all, it exports the source from the main repository cache for you. When building, you want to avoid working off the main repository cache since then you can get stuck with collisions on update, but with CC.NET, we always had to do the export and everything ourself. Team City takes care of and reverts the source to a clean state one each run.
4. Artifacts and cross dependencies. In CC.NET, we always had a network share set up where we’d place built packages, but with Team City, they can be loaded back into the main site for storage and easily accessible. On top of that, you can place dependencies between builds and have the artifacts extracted. For instance, we have one built that fully packages a release every day. We have another build that our Selenium tests. We have a build dependency on them so that Team City extracts our latest package and the build script sets it up in IIS and runs against it. As time goes on and we get more of our subcomponents into Team City, ensuring all subcomponents stay up to date will be automated and far easier.
5. Streaming build log. No longer do I need to wait for the build to be done to see what is going on. Team City can stream the build log to the browser, so I can see where its at, what is hung up on, or if it did something wrong that wasn’t an error, can stop the build and correct it.
6. Easily customize builds. A while ago, we’d built a “preview build” and then a short while afterwards, realized there was an issue with the build. Not with the code, but just the build process. We needed to send an updated one, but wasn’t sure if the latest code was at a release-worthy state. Luckily, Team City makes it super easy. Right through the interface, I was able to kick off a new build of the same SVN revision as the earlier one. It also was intelligent enough so that in the history, it distinguishes it so someone knows it is different and in the description, says it is a build of an earlier commit and out of line with the other builds.
7. Test history. We’ve just started pulling in our test builds, but one nice thing I’ve immediately notice is some of the rich reporting it has around test stats. For instance, it shows when a test started failing (if its been in multiple builds), allows you assign someone to be responsible, allows you to track a test’s history, and even identify problematic tests (probably ones that fail the most). You can even track the test duration and see it change over time.

Overall, would have to sum Team City up as just being incredibly refined.

I know a number of people who have larger Cruise Control setups than us, but overall Team City brings a lot to the table and the cost factor makes it a dead on winner. Team City can easily pay for itself just in terms of productivity. But on top of that, it is free up to 20 build configurations!

Typically, branding is a good thing. It brings you recognition, people remember your product/company, and you hope all that translates into sales. But branding can also be over done. Take for example, Smart Assembly (or rather "{smartassembly}") which was acquired by Red Gate back in September. Don’t get me wrong, Smart Assembly makes and awesome product, but the whole "{…}" thing has been over done.

For example:

1. All emails from them use "{smartassembly}". Even one hand typed support response did.
2. The press release when Red Gate acquired them uses "{smartassembly}".
3. The MSI you download is "{smartassembly}.Setup.msi"
4. The default install location is "C:\Program Files\{smartassembly}"
5. The executables are "{smartassembly}.exe" and "{smartassembly}.com" (.com is the command line runtime)
6. And yes, the project files you save are ".{sa}proj".

The branding can also get in the way of using the product. Smart Assembly is an obfuscation tool, so it would seem reasonable to integrate into your build process. NAnt is of course a popular tool for automated builds. NAnt scripts use $"{…}" to denote variables. While this doesn’t create a conflict, in my opinion, it clouds your scripts with excess brackets and takes away from the experience. (Note: I originally said it conflicts with using NAnt, I was wrong, since I jumped ahead of myself forgetting that it needs a ‘$’ too)

Branding is cool and all, but when it gets in the way of your user experience by overuse, its gone a bit too far.

This afternoon, finally zipped up and released a new version of Papercut. This release features:

• Our first release to CodePlex! Yes, Papercut is now a CodePlex project, and also hosts the source. Feel free to grab the source, contribute patches, and enjoy.
• Fixes a long standing bug with the handling of quoted printable messages where stray equal signs (=) would show up within messages. I had fixed this bug a while ago, but was slow to actually package up a release.
• The forward message dialog box now remembers the settings you enter. I had to use Papercut this afternoon, found myself wishing it remembered the settings, so I quickly opened the project and added it in.

So please head on over and download it now!

I frequently read stuff on WebHostingTalk. Yesterday I was catching up on the happenings of the week when I saw a post of a type I’ve seen elsewhere before. The premise is “we’re a software development company, we’re writing this product, what do you, our target customer, want in it?”

I always see those types of questions as a danger sign.

First, you should already know your customer base. Would you want a company who has no idea about taxes writing accounting software? Hmm. Maybe this way… would you want an auto mechanic who was given a manual on heart surgery to do your bypass? You, yourself, cannot solve a problem unless you understand the problem.

Working with a target audience is good. However I’d argue, show them something and ask for feedback, don’t just ask them at the beginning without having anything to show. Also, narrow down who you ask. If you ask the world, you will get inundated with responses, but how to do you know the quality of those responses? Find target customers to work with. Those interested in your product, who have a reputation in the field or some sort of credibility, and allow their interests to be vested in your success.

By asking the world and trying to meet all those requests, you’ll lack a sound focus on your product and scope. You may end up trying to do everything instead of tackling what is important. If you have to ask what the customer wants without having anything started, how do you actually know what is important?

In the post they also say they’re beginning development within 72 hours and hope to have a prototype in a few weeks.

If you don’t know your customer, how can you begin in 72 hours? What are you going to begin? You don’t have a plan, priorities, or anything yet. And to get a prototype out in a few weeks with no game plan is unlikely.

Not to rag on anyone or anything. I wish them the best of luck, but far to often people over simply the process of building a product. Products aren’t easy. It is easy to write a program, but there is far more work to turn it into a product.

Last year, I had introduced Papercut as a simple utility for testing email capabilities of a site or application.  Since then, I’ve used it quite frequently and occasionally get emails from others who’ve also found it useful (I always appreciate those).

Tonight, I am pleased to release a new release.  Although it isn’t ground breaking, it fixes a few minor nuances I’ve had and adds some new functionality I’ve really been wanting.

• Added the ability to send messages on to a live email server.  Get the test message in Papercut but want to see it in a live client?  Can forward it on and chose which mail server to send it to and the from/to users in the SMTP commands.  It doesn’t alter the message, only the commands executed on the server (so it will go to the specified user).
• Ensure the window is raised to the top when you click the tray icon and it is already open.
• Changed the raw view of messages to use a fixed width font (Consolas or Courier New) and widened the default window some so a full line would fit in the main view.
• Fixed an issue with clicking the delete button too quickly.  It would try to delete the same message twice and could cause an error.  It will now handle rapid clicking.
• Added multiple selection in the message list so you can now do bulk deletes.  Hit Ctrl-A, select all, and hit delete.  Yay!

Now for the linky details:

Project page

New binary download

New source download

 I find it interesting that back in September, Apple rejected a "Pull My Finger" application, when a recent application named iFart has had tremendous sales, and was an easy $30k income for Apple.

So Pull My Finger wasn’t good enough, but iFart was.  And despite both seeming similar, Apple is making money regardless.  It sounds like there is no rhyme or reason to App Store approvals.  Its kind of discouraging when you’re considering doing iPhone development and your work might be considered of "limited utility".

Before I get into this post, I need to give a warning, as I may unintentionally rub a few people the wrong way. This post is about some blogging apps, and while I work at Telligent, who offers Community Server and Graffiti CMS. This is my own opinion and while not about us vs them at all, Telligent offers applications for blogging. Though I link to some other blogs/people for my points in this post, it is nothing against them.

For ages, the classical example of a developer’s first foray into a new language was always the simple "Hello, World" program. These days though, it seems like our classic friend has been replaced with writing a blogging app. For instance, the ever-famous "Create a weblog in 15 minutes" Rails screencast. Or other developers say "every beginning Rails developer should write their own blog software" (nubyonrails.com).

The problem with this? Blogging software is overrated!

Seriously, talk about a polluted atmosphere… look at all your options just for .NET that I can think of off the top of my head: .Text (people still use it), Community Server, Graffiti, SubText, DasBlog, BlogEngine.NET, DotNetNuke, and now Oxite. That is just the .NET world… remember, we’re the small guys when it comes to the internet at large (compared to LAMP).

What about the world of Ruby? Perl? Python? PHP? There are probably enough derivatives of blogging apps to populate a small country.

Releasing a new MVC framework? HEY! Write a blogging app! Azure was announced… if someone hasn’t already, you know a blogging app designed for Azure is coming. When Google App Engine came out, knew some one would.

Learning a new language? Write a blog engine! Not to pick on Leon, but that is what he did.

Or as mentioned earlier, all the cool kids are writing their own blogging app. I recently thought of writing my own, but then I stopped myself asking why? Why scratch an itch I don’t have. What issue do I have that none of the other applications can solve? What need do I have that isn’t being met? NONE! I use Graffiti, and although I may be biased, it does everything I need. I have no itches. Why waste my time writing something I don’t actually have a need for and no problems to solve? I’m not going to spend my personal time coding something if I don’t even deem it useful.

Or another way I saw it… writing the shortest blogging app. The one mentioned there is only 657 lines of code, while the closest one in its comparisons is a hair under 7k. Note the author makes some concessions, about its a blog and not a blog engine, but seriously. I was looking at it thinking "ohh cool", but then ended up settling on "so?"

And recently, there is all the Oxite drama. That has been hashed over plenty, but what I don’t get is why is there so much attention given to it? Ok, a Microsoft sample app that is a example of what not to do… they have done it before. Or take their Channel9 video, which talks like "holy crap this is innovative!" Every time they say "cool" or "awesome" in that video I cringed. The communities response has been overly dramatic as well. I stopped following Rob Conery on Twitter over the weekend because I’m tired of hearing about Oxite. Ok, Rob is helping them refactor, I get it, but do we need the constant status updates? I love SubSonic and like Rob’s blog, but I get a sense of Superman coming in and single handily saving the day.

Seriously, blogs have been done. Want to write something related to blogging? Ok, fine, but do something innovative, not the same old thing. Disqus was innovative. Oxite isn’t.

And again, nothing against the Oxite team, Rob, or anyone else… just my personal rant about being tired of hearing about blogging. Yes, I am blogging about my dislike of blogging apps. It oozes with irony.

About two months ago, I’d posted about some work I was doing with Warehouse after it was open sourced.

At the time, I had mentioned that I wasn’t certain what direction I’d be going in the future; whether I’d continue to work on the original Warehouse code base, or port it over to Merb/DataMapper and go from there. In the course of thinking about it though, I’d taken a chance to sit back and think about what my goals would actually be with it… what was I look for, why would someone want to use it versus what was already out there, etc. I wanted solid and valid goals, otherwise I felt it would either not be useful, or I’d risk losing momentum on it, similar to the Warehouse team did.

I came back to it with a clear goal: focus on being a developers personal mega-plex. I realized the reason I was considering this at all was because the existing options left a gap. As a developer, I always have several side projects. Some I work on for a weekend, but I still want to keep them around. In my Warehouse install, I had about 25 repositories, but could have easily had more. At that number, I’m looking at upwards of $50/month to keep them with the rest of my code at Github, Beanstalk, or elsewhere. Additionally, they’d clutter the UI and get in the way of me getting to my active repositories. I wanted a UI that worked better with high numbers of repositories. I didn’t want to use multiple services. I still use Subversion for my Windows work, I’ve tried git on Windows and it isn’t the same since the command line is so weak on Windows. I tried TortoiseGit, but it was problematic (though I am optimistic). There were a number of other features I started thinking of as well as I began to think of it as a developer’s personal black book.

So I started from scratch, laid down some code, and while working on it, started thinking about how this really isn’t suited well as an application you’d run yourself. It integrates a lot with external systems, such as Apache for Subversion and SSH for git. It becomes user ownership sensitive and installation story gets complex. It really works best as a hosted service, where you can just use it.

However, taking something from an application to a service is not a simple transition. It is something that really calls for a lot of thought and direction.

So right now, I have this application that I created. I put it up and began using it a couple of weeks ago, and I really like it. It now has all of my git and Subversion repositories. Only myself and a couple of co-workers have started using it, but it isn’t really ready for the masses. That transition I mentioned? It isn’t one that I’ve mentally crossed and committed to yet. Where it goes from here, I’m not sure yet.

Today I stumbled across a post by Ken Howard referencing the need for developers to regularly "sharpen their saw". That is a phrase I regularly hear, though most of the time it is referring to the way developers stay sharp by being on the edge of emerging technology and aware of new techniques/methodologies.

I’d like to offer an alternative: sharpening the saw is also the process of being critical about your own and others code. An excellent way to do that is through pair programming. Pair programming is simply put: working together (2 or more developers) on the same task. All too often, developers can be thought of as silos, where they are each given their own tasks, they complete them, and all the tasks come together to form the project. However there is far more to be gained from working together rather than separately.

At Telligent, I’ve been working on our Search Feature Team (aka Super Search), which is comprised of three others and myself. Pairing is something we’ve only recently begun to adopt at Telligent as a part of our new focus on true agile processes. To many, pairing can be a fairly intimidating thing. You are asking someone to be critical of your code, and you to be critical of someone else’s. In a silo workplace, people can often be guarded of their own work, taking criticisms as directed at them versus their code, as there is more of a sense of ownership. Additionally, it can also be viewed as wasteful of time, since if you have 3 people working on the same thing for an hour, you burned three man-hours.

On the contrary, I think pairing is far more productive. Some quick reasons:

• First, it is not about criticizing code, it is about looking at it critically. Code is never perfect, code is never bug free. Suggestions are meant to improve the product.
• You are not the developer you were a year ago, you are not the developer you were a month ago, not even a week ago. You are always learning, evolving, and adopting new and better practices. Don’t feel at blame for poor code from a year ago. Realize you know better now. I’m probably more critical of my own code now than other people’s. When pairing, I’ve looked at my own code and thought "WTF was a thinking back then?" "How did I ever pass this off as a test?" I look forward to refactoring my own code most of all.
• Pairing with others provides alternative views to solving the problem at hand. By offering alternatives, it helps you flesh out the best structure from the beginning rather than finding out further own the road that the solution at the time didn’t fit all your requirements. Additionally, thinking out alternatives helps you further your knowledge, as someone else might know about a technique you aren’t as familiar with. It gives you a chance to interactively learn from others.
• Questioning the code you’re working on helps you fully understand your own reasoning for choosing your solution. Others might not understand the goal/process, or might have alternative ideas (which you might not even go with). By thinking out alternatives and working to explain your solution, you not only help someone else learn, but also help yourself by gaining a better understanding of what you are trying to do.

So get out and pair with someone else! Even if they aren’t familiar with what you’re doing… in many cases, that presents a unique opportunity. We’ve been starting to pair daily and I definitely feel it showing in the quality of my code each day. If you work at Telligent and are looking to pair, feel free to drop a line! I know others like Leon are always welcoming to lend a hand as well.

Have found myself reviewing the options out there for managing my side projects. Most developers always have some ideas for programs or sites lurking in the back of their mind. I always like to get my ideas down in some form or another, and the program ideas I do take action on, I always like to track them. Sometimes though, I get the feeling there just isn’t an issue tracker/project management app geared towards single person “teams”. I’ve tried several solutions, but for various reasons, don’t quite fit what I want:

• Basecamp: Only gives you one project with the free one, and $24/mo is a bit much.
• Tada List + Evernote: Need a little bit more than a todo list, and don’t like idea streams being so separate.
• Unfuddle: I was using Unfuddle for quite a while, and it works well, but sometimes a bit more than I need.
• Sifter: I’ve started trying out Sifter lately and like it a lot, might work well with Evernote for documents, but then they’re separate again.
• No Kahuna: I just signed up for No Kahuna today and it looks interesting, but it doesn’t feel quite as refined as some others like Sifter or Unfuddle.

May sound confusing, with some being too basic, and some being too much, but trying to find a middle ground. What I’d really like is a numbered todo list with a wiki/document type space. Not looking for multiple users, iterations, etc. Maybe some light tagging in place of categories, basic milestones (v1.0, v1.1, etc), and some basic priorities, but that is extra fluff. A numbered todo list would work for most things.

I did get the thought of doing my own as a weekend project… like I said, a numbered todo list with documents, but refrained (for now) since I have enough on my plate. Though sometimes it does seem like there really isn’t anything aimed at this market, and end up just combining tools or leveraging things meant for teams.