Big Visible Cruise++

Inspired by Jeffrey Palermo’s recent post, I figured it was time to finish my post on our “information radiator” setup which has been in my drafts folder for about 6 months.

When we started using CruiseControl.NET for continuous integration a few years back, it didn’t take long for us to decide we needed something more visible than CCTray to let us know when a build was broken. The first solution was an Ambient Orb and a customized version of CCTray running on one developer’s machine. If the orb was green, all was well; pulsating yellow-to-orange meant a build was running; solid red meant something had gone wrong. It worked for a while, but as the team grew and we moved from one office to another, it became difficult to find a location for the orb which would allow it to be seen by everyone on the team. It was time to come up with another solution.

We were moving into a new space yet again back in May of this year when one of the devs on the team came across Big Visible Cruise. Since we work for an audio/video integration company, getting our hands on some spare LCD displays wasn’t terribly difficult, and thus the “App Dev Display Wall” was born (“App Dev” being “Applications Development”, the name of our department within the company).

App Dev Display Wall

The four displays are hooked up to a spare PC buried under the two desks seen in the photo above, and they are definitely visible from anywhere in the room. In the photo below, you can see that we’re currently utilizing three of the four displays, with the bottom-right running Big Visible Cruise. The bottom-left is running a web browser pointing to an internal URL which displays a few metrics for some of our production applications. The top-left is also running a web browser and is currently configured to show a count-down to the next major release we have scheduled.

App Dev Display Wall - Close-up

We also made a few minor modifications to the source of Big Visible Cruise, adding in such things as custom sorting (by last build date/time), number of minutes/hours since the last build and some tweaks to the styling of the individual boxes to make them a little prettier. (We have not yet submitted our changes back to the BVC project, but we’re looking into doing so.)

Big Visible Cruise

Posted by rlaneve | 6 comment(s)

CI with AccuRev and CC.NET

In my last post, I mentioned working with Camtasia to create my portion of a webinar being broadcast later today (3:00 PM EDT). If you're using AccuRev, CruiseControl.NET or both, or just interested in the subject of Continuous Integration or seeing a demo of a great source control system, join us for the webinar.

Additionally, during the webinar I will mention a custom CC.NET labeler we are using and that I would make it available, so here it is.

Disclaimer: try the LastChangeLabeller built-in to CC.NET first before resorting to this one. If you want to try this one, you will need to:
1) get the source version of CC.NET;
2) add the file linked above to the "project\core\label" folder;
3) add the file to the CC.NET "core" VS project;
4) re-compile everything.

[update: I mistakenly listed the start time of the webinar as 4:00 PM EDT in my original post. The webinar actually begins at 3:00 PM EDT.]

Posted by rlaneve | 2 comment(s)

Thinking Like a Programmer

A few weeks ago, I was asked to participate in a webinar being done by AccuRev (the company) around the topic of continuous integration using AccuRev (the software) and CruiseControl.NET. One of the guys on the AccuRev team was preparing a video using Camtasia, and we agreed it would be easier for me to record my part using the same tool and we'd then stitch our two projects together to product the final video. I have used other screen-capture/recording tools in the past for some of our internal training needs, but I hadn't really done one in a while and I had never done one using Camtasia (though I knew of the software and probably tried a demo some years back). So, I grabbed the latest available demo version (5.0) and started playing.

First things first: great software. I found it very easy to use, and very easy to put a few "special touches" here and there. All-in-all, a good experience and I recommended to my boss that we switch to Camtasia whenever we get around to making some new training videos. There was, however, one problem I ran into which was a bit frustrating: no way to change a setting which positively had to be changed to make the software usable for my setup. The solution? Think like a programmer.

First off, let me say there is a very good chance I simply missed it; the setting exists, but I failed to find it.

My goal was simple: record a voice-over for the 10+ minutes of screen shots+slides+video I had spent hours laying out in my Camtasia project. The software made this ability obvious, so I never bothered to verify it was going to work (yes, I know - mistake number one). Of course, when it came time to use the feature I discovered it was not working: the button to actually begin recording audio was disabled, with no apparent way of enabling it or even viewing the cause of it being disabled. I assumed a problem with my setup: I had my Logitech USB microphone plugged in to the computer, which I had never used on this system before (or any system for that matter: I snagged it from my Rock Band pile in the living room) and figured the issue was either with the microphone itself or my sound card or my Windows setup or some other thing unrelated to Camtasia.

Then, while poking around the Camtasia docs and installed applications, I came across the "Camtasia Recorder" program. This is a separate application specifically for recording audio. I fired it up and, again, was unable to record anything. However, in this app, there is an easily accessible "audio options" link which, when clicked, displays the dialog shown below, which made me realize that either Camtasia or my system in general had decided that my default audio device was "Bluetooth Audio" - not my Logitech microphone.

camtasia_audio_options

Upon clicking the drop-down list and selecting the correct option, this application was perfectly happy to allow me to record audio using the USB microphone. I assumed my problem was solved, shut-down the "Camtasia Recorder" application, re-started the main "Camtasia Studio" application and...wait...I still can't record an audio track within my existing project. Hmm... No problem, really. I guess the two apps don't share settings and I just need to find the same "Audio Options" dialog I found in the other application. If you haven't guessed yet, the "Audio Options" dialog was nowhere to be found within the "Camtasia Studio" application. I looked pretty darn hard and no luck. Again: could just be me; maybe it's really there, but if it's that hard to find it's as good as non-existent to me.

After searching Google for a bit and finding no information specific to Camtasia version 5.x, I finally decided to think like a programmer. (I play Mr. Manager role for 85% of my day, so I'm a little slow to come up with bright ideas when needed.) It seemed to me that there must be a setting stored somewhere which Camtasia Studio is using to determine the audio device to use for voice-overs. I just needed to find it. At first, I gave them too much credit: I searched the "Documents and Settings" area on my machine looking for nicely formatted config files. Then I decided it was time to try the registry and, low and behold, I found the culprit.

 

camtasia_audio_options_registry

I jumped back into the Camtasia Recorder application to check the "Audio Options" dialog again, noted the exact name it displayed for my USB microphone and then changed the "WaveInDeviceName" value to match. I re-started Camtasia Studio, loaded up my project and, whaddya know, it was perfectly happy to allow me to record audio using my microphone. Problem solved.

Lesson learned: all software is created by humans, and most of us are not breaking new ground. If you're having trouble getting some third-party software to do what you want, step back and think about how you would have made the software work if you were the one who had written it. You might just come up with a way around your problem.

Incidentally, if you're an AccuRev user or CruiseControl.NET user (or even better, a user of both), come join us for the webinar being broadcast later today.

Posted by rlaneve | 3 comment(s)

BDD Style Specification Reporting via CC.NET

After reading posts by Jean-Paul Boodhoo and Dave Laribee regarding BDD style naming conventions for specifications, my team gave it a shot on a project we started recently. It didn't take us long to agree that we preferred this naming style over the styles (or lack there-of) we had used in prior projects. We even found ourselves catching mistakes - in either the implementation or interpretation of the projects specifications - just by reading through the Dox report generated by the MbUnit GUI runner. We don't generally use the MbUnit GUI, however, and the output of the Dox report, though helpful, was not exactly what we were looking for. Since we have a continuous integration server running builds on every check-in, we decided to take a shot at having something generated during those builds. An example is seen below, which was generated using the MbUnit XML output from running the tests in the NothingButDotNetStore sample Jean-Paul has up on Google Code mixed with a custom XSL file.

Sample CC.NET report from MbUnit Xml log

We modified the build server's config to add a "specifications" report link when viewing the details of a build, and have definitely found it useful to have such an easy-to-read, always available and always up-to-date list of the specifications currently implemented by the project. While we're not quite to the point of being completely happy with what we've got - still some sorting, naming, organizational issues to work out - we definitely all agree that we are better off using this style of naming and having this report readily available for each build.

Here is a zip containing an MbUnit and NUnit version of the XSL we are using to generate reports like the one shown above. As I said, they really aren't perfect, but should get you started if you're trying out a similar style of naming convention. Let me know if you make any improvements.

Posted by rlaneve | 1 comment(s)
Filed under:

App Developer opening in Tampa, FL

Got the chops to juggle multiple projects from design to development to completion? Tired of trying to convince your boss there is actual value in playing...err...*learning* things like Whidbey and Yukon before they're released? Interested in joining a team celebrated by its users as we prepare to build their next generation of applications and tools? Are you in the Tampa Bay area, or always wanted to live in a place you'd be evacuated from several times a year? Then apply now for the Applications Developer position available at Audio Visual Innovations, Inc.!

[Note: the position is incorrectly listed as being in Cleveland, OH right now. It is most definitely in Tampa, FL, and will be corrected on CareerBuilder soon.]

Posted by rlaneve | 1 comment(s)

Two parts FlexWiki, one part reflection, shake vigorously...

While working on the FlexWiki project, I became interested in the feature suggestion known as “Wiki Class Pages”. The idea was to enable automatic generation of pages to document/discuss the classes/methods/etc... of a given assembly. Basically, you get online documentation combined with the commenting/discussion abilities of a wiki. This functionality is not quite complete - dare I say, nowhere near complete - but it's certainly at a point to start showing others and testing against various assemblies. The current implementation displays a class' or interface's public constructors, fields, properties and methods using reflection, which is then combined with the information in the XML documentation generated by the C# compiler. My personal site has two assemblies being auto-documented: the FlexWiki engine itself and another GDN project called “DotNETShipping”. My real intent is to use this functionality on my internal development wiki where I work, but it may be useful for public projects such as those I just mentioned.
Posted by rlaneve | with no comments

Made It!

After finding out LAX was closed this morning, we decided to drive from San Francisco instead of waiting around indefinitely. Turns out, it was a good choice. Four hours in the car and now we've arrived.

More to come, I'm sure.

Posted by rlaneve | 2 comment(s)
Filed under:

PDC Session List - PDF

I believe Julia is travelling and didn't think she'd have a chance to update her PDF session list, so I went ahead and created a new PDF from my updated XML file. This one is only by timeslot, though - I didn't make one by track like she did. Maybe I'll get a chance on the flight out to San Francisco this evening.

PDC Sessions by Timeslot (PDF)

Posted by rlaneve | with no comments

PDC Session List as XML - Updated

My XML version of the PDC sessions list has been updated, and now includes Pre-Con sessions, BOF sessions and the panels on Thursday. Get the updated file here. (Hopefully, Julia will have a chance to update her PDF versions!)
Posted by rlaneve | 1 comment(s)

Job Opening - Tampa, FL

Ok, ok...I promised myself I wouldn't post anything other than .NET related information to this blog, but the job is certainly .NET related!

I'm looking for an Applications Developer in the Tampa, FL area. Apply via CareerBuilder at the link below if you're interested, and feel free to contact me for me for more information.

http://www.careerbuilder.com/JobSeeker/Jobs/JobDetails.asp?SiteID=cbdetshr&did=J357W6FQYG84X08R5L

Posted by rlaneve | with no comments
More Posts Next page »