If you are in the Sacramento area next Thursday, come by the SacRuby Meetup! I will be presenting on using Chef for server and configuration management. I will be talking about using Chef on a large scale with a cluster of servers, all the way down to aiding management of a single server.

If you are in the area, please stop by! Pizza and refreshments are normally available.

Meetup details: http://www.meetup.com/sacruby/calendar/14122667/
Date: Thursday, August 19th
Time: 7:30pm til we go home
Location: 10911 White Rock Road, Rancho Cordova, CA 95670 (see details for number to call to get building access)

The main talk starts at 7:30, however we will also have a Ruby Clinic starting at 6:30. Bring your questions, problems, or other issues in and we’ll try to help you out.

I’ve talked about the Papercut tool I’ve written before. I initially wrote it to scratch an itch I had with previewing and testing emails during the development process.

Recently though while working on Trunks, I’ve been feeling the need for an email testing tool for staging environments. Since Trunks involves several moving components, I have a staging environment set up so I can do live testing on features. Often times that testing involves emails. Since I run the staging environment with a snapshot of the live database, I want the emails to be sent and viewed for testing, but don’t want them going out to live accounts. Would hate for a user to mistakenly receive an email from my staging environment!

In comes Papercut Web Edition.

Papercut Web Edition provides you with an SMTP account that you can connect to, authenticate with, and send emails two. It works just like the desktop Papercut where messages sent to it are only stored locally, not sent on to their destination. It then allows you to view the messages through the website.

With this, when you set up a staging environment, you simply point it to the SMTP server and off you go. In something like Telligent Community, just a matter of quickly checking the Email Settings, or with a Rails app, just need to edit your “staging” environment configuration.

The service is provided free of charge. It is simply ad supported, so while using it you will see an AdSense banner on the side. I’ve tried to make it unobtrusive while at the same time striving for the service to generate something in return. I may be changing it to use some different ads if it gets some sponsors, as I don’t expect AdSense to really draw in a whole lot.

Currently, it will delete messages after they are 2 hours old. It is intended for testing emails, not retaining them, so the idea is you trigger the email, view it online, and then are done with it… or simply proving a way for emails to be safely sent while you test other aspects of your app.

I have several more features that will be coming down the road. Right now, it is rather simplistic as I created it quickly to solve my problem. But it has some big things coming to help tackle some other emails testing annoyances I’ve felt. It’ll also have support for attachments, embedded images, forwarding messages onto a live account, and much much more.

So the most important piece? The URL!

dummysmtp.com

All good names with Papercut in them were taken… and as a site URL, “papercut” has more connotations with paper and pain than email. Dummysmtp is very descriptive of what it does… may the SEO gods look fairly upon it.

Sign up today and try it out! Go forth and test emails… safely!

When configuring our Selenium tests to run out build server, one issue I ran into is that there wasn’t a lot out there in terms of how to get this set up. A few people had posted about having done it, but not how they did it. Overall, it isn’t incredibly difficult, but there are a few things that I got hung up on.

The way we run it is we start the selenium server in the background, and then have NUnit tests that run the stories. We can’t start Selenium in the foreground because then we couldn’t move on to the NUnit tests, but we also needed to register it as a Windows service on demand. To do that, we used a utility called Non-Sucking Service Manager (NSSM). It is like srvany from the Windows Resource Kit, but it works on Windows Server 2008 (and there was no publicly available Windows Resource Kit for 2008 I could find).

Here is our setup/teardown NAnt targets:

<target name="start.selenium">
	<property name="jdk.bin" value="${environment::get-variable('JDK_BIN')}" />
	<exec basedir="${common.folder}" program="nssm.exe" commandline='install Selenium "${jdk.bin}\java.exe" "-jar ${source.folder}\libs\selenium-server.jar"' />
  <exec program="net.exe" commandline="start Selenium" />
</target>

<target name="stop.selenium">
  <exec program="net.exe" commandline="stop Selenium" failonerror="false" />
	<exec basedir="${common.folder}" program="nssm.exe" commandline="remove Selenium confirm" failonerror="false" />
</target>

On top of that, it is important to set the “nant.onfailure” property to a target that does all of your cleanup. Since we’re using NUnit, an error in the unit tests will signal a build failure, but we still want to ensure our cleanup runs. So set the “nant.onfailure” property to the name of a target that runs all cleanup tasks (including “stop.selenium”).

Proper cleanup is very important, since in our case, the selenium.jar is in with the source and if it is still running, Team City will be unable to cleanup the working space and cause it to instantly fail any future builds before it even gets to executing your script. Because of this, it might also be good to have the server do a scheduled task that calls “net stop Selenium”. If it is stopped already, no harm, if the service doesn’t exist, no harm, but just a bit of an extra measure. And finally, to be extra extra safe, I actually call our main cleanup target at the beginning of the build as well and set failonerror=”false”. Since we’re registering and running background processes, didn’t want the test to be brittle and need my intervention. I don’t want “Ken, can you fix the build” emails.

So few things to point out about using it:

• One thing I got hung up on, you need the quotes around the “-jar …” parameter on the exec line to nssm.exe. I was missing that originally and wasted a lot of time, since I’d see the Java process start and be running in the process list, but couldn’t communicate with the Selenium server. The “-jar …” line is a the parameter to java.exe though, and not nssm.exe, so it needs to know it is all one parameter.
• We have the location of the JDK set in the environment variables. I don’t like hardcoded paths in the scripts.
• Be careful of quotes! I had to have the JDK_BIN set to a property because otherwise I’d get down to invalid quotes. You can’t have commandline=’….”-jar ${environment::get-variable(‘JDK_BIN’)}”‘…. the second set of single-quotes will be closing the first one, not opening a new set.
• The “common.folder” and “source.folder” are just properties pointing to where some common utilities are and the current working directory for the source.

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.