Wednesday, December 30, 2009
It's Resolution Time
Friday, May 15, 2009
How to Review Presentations Effectively
Monday, May 4, 2009
Review of Presentation Zen
When I read books, I often take notes. Sometimes I take notes in the books themselves, other times I put notes down in notecards, I will also put notes in a personal wiki. You could say that I don’t really have a system. One thing is fairly consistent, I normally don’t go back and look at the notes (whether I can’t find them because of my “system” or I just don’t think about it). So with my most recent read, I’m going to try something new… I’m writing about it in my blog.
Presentation Zen is an extremely good read. I wouldn’t be doing it justice by putting my notes in a personal file. This book should be shared. I know I’m not the first reader or reviewer of this book, but I think word needs to spread about its virtues. I have put off reading this book because I really haven’t done many presentations in the past. When I signed up to speak at the Richmond Code Camp, I finally had a good reason to pick it up.
Presentation Zen is definitely tied in specifically about giving presentations; however, its lessons transcend this single topic. The approach to presentations given here deal with design, storytelling, and simplicity. These are valuable lessons for people of all walks of life, especially software developers. Be warned, you will not look at presentations the same way again. In fact, some presentations that you previously tolerated will become nearly intolerable.
One of the reasons I think this book was enjoyable and timely for me is that it shares elements with some other great books I’ve read in the last year. I strongly recommend all of the following: Pragmatic Thinking and Learning: Refactor your Wetware by Andy Hunt, A Whole New Mind by Dan Pink, Outliers by Malcolm Gladwell and Zen and the Art of Motorcycle Maintenance by Robert Pirsig.
All of these books challenge the reader to approach things with a different mindset. There are consistencies through all of these books that seem surprising, since all of the authors are from different fields. Also, every one of them is extremely relevant to software development. That’s interesting because only one of the books was written by a software developer.
Back to Presenation Zen, I hope to improve my presentation style and maybe achieve the level of design and the naturalness of delivery that Garr Reynolds describes in its pages. As I am not there yet, I am hooked on his blog where he posts videos of masterful presentations that capture this style.
Sunday, April 26, 2009
Richmond Code Camp Recap
Ok, so this can’t be a full blown recap of the Code Camp. I wasn’t able to stick around the whole day. My wife and I celebrated our 6th anniversary this weekend. So there was no way I could get by with spending the whole Saturday at a technical conference. However, I really enjoyed the time I spent there. It was a great environment, and I thought the organizers did a great job.
I presented a talk titled “Continuous Integration or: How I Learned to Stop Worrying and Love the Build”. I felt like it was fairly well attended and well received by those that were there. I’m pretty new to presenting, so I think it went about as well as I could have expected. The main glitch was the resolution of my screen vs. the resolution of the projector. I didn’t realize the projector was cutting off my slides until about halfway in. Instead of fixing it, I tried to keep driving forward. I think it would have gone better if I had taken the minute or two to fix the discrepancy.
Anyway, I felt like I had a great audience and really enjoyed their participation. Also, I felt like I did get the point across that Hudson rocks. Hudson is a great tool to present Continuous Integration as an accessible practice. I mean, I can spin it up from scratch and have new projects running in a matter of a few minutes. I wouldn’t even dream of doing that with other CI tools in a live demo in front of a crowd.
So, with the success of this weekend, I’m going to take this talk to some other venues. Next up, I’m penciled in to present this at May’s Richmond Java User’s Group. I’ll have to rework some of the demo to translate the .NET project and tools to the Java platform. I love the fact that I’m able to use the same talk for audiences from different platforms and languages.
This is really exciting for me. For the last year and a half, I have had two major career goals. First, to be equally proficient between the .NET and Java platforms. Second, start presenting at user groups and conferences. This is great because I am knocking both out at the same time.
Friday, March 27, 2009
Getting Started with Rake on .NET Projects
I attended Developer Day in Durham last weekend, and had a blast. The event was very much Ruby-centric, which is a little out of my comfort zone. However, there were plenty of things that I’m bringing back to my day job on .NET and Java projects.
The first two things I resolved myself to do: 1)write less XML, and 2) try to incorporate scripting languages (starting with Ruby) into my routine tasks. This led me to Rake. Rake helps me accomplish both goals at one time. I get to stop writing XML for my build scripts, and use Ruby to build my projects.
There are a lot of blog posts on Rake and even some on Rake with .NET. However, I didn’t find one that got me running build scripts in Rake from scratch. I’m focused on the simplest case for .NET. If you want more general Rake information, go to Martin Fowler’s article. If you want a more complete (and very entertaining) tutorial, check out the Rails Envy site.
So here it goes…
1. Get Ruby
I’m on a windows machine, so I used the One Click Installer. I ran the installer, re-booted my machine, and was good to go with Ruby (Rake is delivered as part of the Ruby install).
2. Find a Project that Needs Building
I set up a very simple solution that has two class libraries (DoStuffInDotNet and TestStuffInDotNet). One has a single class with limited functionality. The other has a single NUnit test. I have also included a tools folder, which contains the NUnit test framework.
3. Create a Rake File
I created a file called rakefile.rb. I’ll break down each part of the file below.
The first line sets up the default task. In this case, it is calling the build task. So, from this folder, “build” executes by simply typing in “rake”.
task :default => :build
The next line shows that “build” is a composite task that is comprised of the “clean”, “compile”, and “test” tasks.
task :build => [:clean, :compile, :test]
The “clean” task is just calling Ruby’s FileUtils class to remove the contents of the “build” folder.
task :clean do
FileUtils.rm_rf("build")
end
The “compile” task calls MSBuild to execute on the solution under the AutomatedDebug configuration. AutomatedDebug is a setting I created in Visual Studio’s Configuration Manager. The only difference between this and the default Debug configuration is that my output path is set to “..\..\build\Debug\”. This will put the output of the rake build into the “DoStuffInDotNet\build” folder.
task :compile do
params = '/t:Rebuild /nologo /v:m /p:Configuration=AutomatedDebug src\DoStuffInDotNet.sln'
msbuid = 'C:\\WINDOWS\\Microsoft.NET\\Framework\\v3.5\\MSBuild.exe'
sh "#{msbuid} #{params}"
end
The final task is “test”. Rake uses the current execution directory as its working directory, so I am using FileUtils to change the working directory to the “build\Debug” folder. Then I execute NUnit against the test dll.
task :test do
FileUtils.cd 'build\\Debug'
exec "..\\..\\tools\\nunit\\nunit-console.exe TestStuffInDotNet.dll"
end
From the cmd window, you can just run the command “rake” from the directory that contains rakefile.rb.
In effort of completeness, below is the full code in rakefile.rb. Like I’ve stated early, this is a stupidly simple example. However, I hope that it can help you get started if you are looking to start from ground zero.
task :default => :build
task :build => [:clean, :compile, :test]
task :clean do
FileUtils.rm_rf("build")
end
task :compile do
params = '/t:Rebuild /nologo /v:m /p:Configuration=AutomatedDebug src\DoStuffInDotNet.sln'
msbuid = 'C:\\WINDOWS\\Microsoft.NET\\Framework\\v3.5\\MSBuild.exe'
sh "#{msbuid} #{params}"
end
task :test do
FileUtils.cd 'build\\Debug'
exec "..\\..\\tools\\nunit\\nunit-console.exe TestStuffInDotNet.dll"
end