I’m sure I’m the only person in the world who ever wants to know what the command line arguments for running processes is, but in the remote chance that someone else out there might need this some day, here you go.

We’ve got a few programs at work that do a lot of interprocess communication (IPC). They initialize the IPC communication in a variety of different ways, but one way is by command line arguments that were passed to them. From a debugging standpoint, it is very useful to be able to determine what the command line arguments were that were passed to the process.

The easiest way to get this information is with Process Explorer. You can either right click the process and select its properties, or you can add a custom column with the command line. What you’ll get is something like this:

You can see that I passed “haha.txt” into GVim.

Sometimes, though, I want that information faster. Why not from Powershell? The System.Diagnostics.Process object doesn’t provide any means (that I’m aware of) to retrieve the command line arguments from an already running process. Yes, there is the StartInfo.Arguments property, but it is only there for letting you pass arguments to a process that you’re going to start. It doesn’t populate that information from a running process.

You can get it from WMI, though, using a command like this:

Get-WmiObject win32_process -Filter "name like '%vim.exe'"

You can grab the command line from it by doing this:

Get-WmiObject win32_process -Filter "name like '%vim.exe'" | select commandline

So yeah, that works. It sure isn’t quite as easy as typing this, though:

ps *vim | select commandline

Sure wish I could do that. Sure glad that I can! Powershell has the ability for you to tack on your properties. It isn’t quite monkey patching like in Ruby, but it’s close. Here’s how to do it.

You’ll first need a ps1xml file to contain this information. I put mine in ~/Documents/WindowsPowerShell/TypeData/System.Diagnostics.Process.ps1xml. It will look like this:

<?xml version="1.0"?>
<Types>
    <Type> 
        <Name>System.Diagnostics.Process</Name> 
        <Members> 
            <ScriptProperty> 
                <Name>CommandLine</Name> 
                <GetScriptBlock> 
                    $id = $this.Id
                    $result = Get-WmiObject win32_process -Filter "ProcessId = $id"
                    $result.CommandLine
                </GetScriptBlock> 
            </ScriptProperty> 
        </Members> 
    </Type>
</Types>

What this does is tell Powershell that, for every System.Diagnostics.Process instance it sees, add a new ScriptProperty to it with the name CommandLine. The GetScriptBlock section defines how to actually retrieve the value for the new property. In there, you just put Powershell code. So, I’m doing almost the same WMI query as before except that I’m searching by ID instead. It’s faster that way.

To inform Powershell about this, just run this:

Update-TypeData ~/Documents/WindowsPowerShell/TypeData/System.Diagnostics.Process.ps1xml

You’ll probably want to put that in your profile so that it runs every time you start Powershell. Here’s a screenshot of it in action:

The .NET open source community has really started to embrace git in the past few months. Ayende has moved pretty much all of his open source work over to github, Fluent NHibernate is there, FubuMVC is there, the list just goes on. If you haven’t had a chance to delve into git (or other distributed SCM tools like mercurial), you should definitely check one of them out.

If you’re like most .NET developers, chances are quite high that you’re developing on Windows. In case you’re unaware, git was originally written to manage the Linux source code. What this means is that it has a very different philosophy than your standard Windows application. For one, it is primarily used from the command line. And yes, I realize that a plethora of various GUI tools for git exist. The only one I personally use is gitk, though, and only then to get a high level view of the repository. The rest of the time, I use it entirely from the command line (Powershell actually). I wanted to share some tips on using git in Windows and making the experience better. (note that this isn’t a “git tutorial,” it’s a “setting git up on Windows tutorial.”)

Install MSysgit

First off, you have two options for running git in Windows – msysgit or cygwin. I’ve used both, but I currently prefer using msysgit, mainly because when I’m on Windows, I want to use Powershell. Most posts you’ll read from Windows users using git actually use Git Bash that ships with msysgit, though. I’ve used this option as well, but as I said, I like my Powershell. If you want to use git from any command prompt (including cmd, git bash, or powershell), you’ll want to choose the option to add the git directory to your path when you install msysgit. (you might have to restart before the PATH changes are effective)

After the install, you can verify things are set up correctly by pulling up powershell and typing get-command git. If everything was installed correctly, you should see something like this:

You can now type “git --version” to verify that the install worked. Mine outputs “git version 1.6.5.1.msysgit.1”.

Use Console2

The next step is one of the most important ones in my opinion. Don’t use the default cmd.exe. Use a better one. I recommend Console2. It’s a tabbed console host for windows. You can use it to host the standard cmd prompt, powershell, cygwin, git bash, etc. It has much better font and color support, too. None of this adding fonts to the registry so that cmd.exe can use Consolas mess. Here’s what mine looks like:

I’ve customized my colors so that the black is more of a dark gray and some of the other colors aren’t quite as bold. I’ve changed my font to Consolas, I’ve got the menu, toolbar and status bar hidden, I have copy on cursor select checked, and more. Some people don’t care about aesthetics when coding or using the command prompt, but I do.

Enable color with git

Speaking of aesthetics, I cringe every time I see someone run git status and see no color. I don’t think I knew how big of a difference existed until I ran git on an Ubuntu VM where color support is enabled out of the box. Here, I’ll just show you a couple screenshots for comparison.

Without color…

With color!

Now, if you’ve used git, you may be aware of the git config option (or see ~/.gitconfig) to turn color on. I actually have mine set to auto. This means that git tries to determine, based on your terminal, if it thinks you can handle color or not. It doesn’t think Windows can handle color very well, so auto on Windows means no color. So, if I’m not using the global color option, what am I doing to tell git to use color anyway? I’m using an environment variable tweak that I learned about via one of the msysgit issues (see http://code.google.com/p/msysgit/issues/detail?id=326&q=color&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary#c5). Here’s the line from my powershell profile:

$env:TERM = 'cygwin'
$env:LESS = 'FRSX'

This line basically lies about the running terminal - “hi git, my terminal isn’t actually powershell or cmd.exe or console2, it’s actually cygwin.” The second line provides arguments to less (the default git pager) on how to render its output.

Here’s how this changes things…

Before:

After!

It’s pretty clear now what’s changed.

What’s could still improve?

The only thing I’m currently missing from git when using it via Powershell now is the tab completion. Git provides a bash_completion script so that you can tab complete all of the various commands, the branch names when switching between branches, the various file names when adding or removing, etc. I’ve started to create my own version of tab completion when using Powershell by tweaking PowerTab (Gaurav Sharma started the initial research to do this… check out his post at http://techblogging.wordpress.com/2008/10/13/context-sensitive-auto-completion-using-powershell-powertab-and-git/) but it isn’t yet nearly as powerful as what the bash_completion script provides when using a bash terminal. I’m hopeful that future versions of Powershell will provide a better (easier?) way to hook tab completion up, particularly for utilities that aren’t Powershell-aware. The TabExpansion function is a little too global for my taste – unless I’m missing something, if you want to add to the tab completion functionality that already exists, you pretty much have to re-implement all of the tab completion functionality.

That’s pretty much it. Don’t be afraid of the command line and don’t be afraid of command line tools.

EDIT: added the $env:LESS setting – just setting TERM doesn’t seem to work in all cases.

I picked up a new computer as a Christmas present to myself last year… hadn’t gotten around to seeing what the stats were for it until recently, though.

Not too shabby at all if I say so myself. It would be amazing with an SSD in there, but I did upgrade from a approximately 160 GB of storage to a terabyte so I’m not complaining. I particularly enjoy seeing a lot of graphs in task manager, too.

This thing is awesome.

It’s 2010. Seriously. Can you believe it? Aren’t we supposed to have flying cars, hoverboards, and have space ships that can reach Jupiter? I mean, really, we’re way beyond the year 2000 now. As a kid, I remember thinking how awesome it will be to actually get to live in the future. I guess I should be consoled in the fact that TVs are a lot bigger. That’s a plus.

So, with 2009 as a distant and 5 day old memory, I’d like to share my thoughts on how the year went.

Professional Life

FSDNUG has continued to thrive over the past year. I really look forward to the meetings and getting to hang out with everyone. As I mentioned in my last post, I’m taking over as president for 2010. The real test for me will be to see what I will be able to say about the group next year

I continued speaking occasionally at developer events this year, including giving my PowerShell talk the Shreveport, LA DNUG, the Little Rock, AR DNUG and the Conway, AR DNUG as well as at the Northwest Arkansas Code Camp. I’m planning on continuing to practice my speaking skills this year… if I can only pick a topic to talk about! I also gave an open spaces session on Event Driven Architecture at devLink. With all of my presentations this year, I received the INETA Community Champion award!

At work, this past year got me pretty excited because, this year more than any prior year, I get the feeling that more and more people are starting to understand practices like SOLID as well as the purposes behind TDD. We’re also seeing more of a mentorship role starting to occur and, though it is still in its infancy, I think it could really help our developers mature.

Outside of my day job, I got to deploy my first Ruby application, a pretty basic Sinatra application. It gave me the chance to completely step outside of my .NET comfort zone for a little while to just get a taste of what’s possible. I haven’t deployed a Rails app yet, but that’s next on the list. I’m also a huge fan of git now.

Personal Life

Away from the computer, my wife and I took charge of coordinating the LTC (Leadership Training for Christ) activities that our youth group at church works with. To be entirely honest, that role was more intimidating for me than any of my user group presentations had ever been. I feel like I know how to talk to developers. I didn’t really know if I knew how to speak to teenagers. I’m still not sure if I do, but the LTC convention this year was a lot of fun and we’re already ramping up to start for this year.

Looking forward…

I’m planning on increasing my Ruby knowledge even more – I realize now that the best way to do this is to work on something. I’ve already got a project in mind so that’s in the works.

I feel like there is so much out there to learn, and not in a bad way. I love learning something new every day. I just want to do a better job of helping to dispense that knowledge this year!

And by the way, if you happen to know when we’re going to get those flying cars from Back to the Future, my internal 10 year old sure would like to ride in one.

Almost 2 years ago a few guys in the Fort Smith area decided we needed a .NET User Group here. We’ve fairly consistently had a good 20 to 30 people show up to every meeting since then. Michael Paladino has done a great job serving as FSDNUG’s president since that time… but earlier this year he moved up to the Northwest Arkansas area. As you might imagine, it’s pretty tough to be the user group president when the group you’re presiding over meets a good 45+ minute drive away. Well, he finally stepped down this month which means someone else has to take the reins.

For good or bad, I’m his replacement

I just wanted to publicly thank Michael for the hard work he’s put into FSDNUG. I’m still pretty intimidated by the responsibility, but I’m also looking forward to it.

If you haven’t attended a meeting yet, stop by some time. The meetings serve as an excellent way to supplement the training and knowledge that we as developers have to have in order to stay afloat.

If you’re already attending the meetings but you’ve got some suggestions on ways we can improve, let me know.

Thanks to all the members - I’m looking forward to starting the meetings back up in January!

I just wanted to share a quick tip on something that had been tripping me up. I’ve happily been running Windows 7 x64 for around a month now. At work, our VPN hardware doesn’t support 64-bit (different topic, don’t ask), so I wanted to use the VPN client from within Windows XP Mode. Sounds good, right?

One problem. The VPN client couldn’t see outside networks. In fact, I couldn’t even ping.

The default networking adapter seems to be “Shared Networking (NAT)” – just change it to your actual network adapter.

Success!

My first Ruby application recently went live a month or two back. I’ve been meaning to get some experience with Ruby for quite a while now, but it took a real project to actually get a chance to really do something with it. Of course, “real project” in this case is a project that just as easily could have been coded in static HTML .

The project turned out to building a website for Arkansas Pediatric Therapy, which is the company that my wife does speech therapy for. The initial requirements for the site were to just get some static content out there, but it still gave me an opportunity to use some Ruby to build the site.

Because the site really has no database needs of any kind yet, I ended up choosing to use Sinatra instead of Rails. For deployment, I used Heroku. I was also able to incorporate some basic integration with the Google Maps API. For my JavaScript framework, I used jQuery. For the web design, I ended up asking one of my coworkers, Tim Franklin, to help me out. His web design skill far exceed mine, so that was definitely the right choice.

So, basically, I took the initial requirements to build an easy static HTML site and ran! Was it overkill? I don’t think so – I ended up learning a lot and I don’t have duplication of HTML all over the place. It should be pretty easy to add dynamic content later if I wish to. It really didn’t take a lot more time either. (NOTE: I did use webgen at first to build a static HTML version of the site. If you really just want static content, I can definitely recommend using it to take advantage of templates.)

But… the post title is about IronRuby… did I use IronRuby for this site? Actually, I didn’t. I might’ve tried it, but I’m pretty sure that Heroku doesn’t support IronRuby currently. Maybe some future site can take advantage of IronRuby. What I want to do is share some of this cool Ruby knowledge with my predominantly .NET readership using IronRuby.

So, here are the steps you can take to build your first Sinatra application using IronRuby!

Downloading, Installing IronRuby, and Adding it Your Path

First, you’ll have to download IronRuby. At the time of this post, it looks like the most current version is 0.9.1 though I used 0.9.0 for the post. The release is just a ZIP file, so all you have to do is extract it and go. I would recommend extracting the zip to your C:\ drive (or root somewhere) as opposed to somewhere under Program Files. Why? Well, I initially dropped mine under Program Files and received an error when trying to install the sinatra gem. I ended up finding this post to fix it – the problem is that the one of the paths is too long (check out all the information about the infamous MAX_PATH constant).

You should have a directory that looks something like c:\ironruby-0.9.1 with the rest of the files underneath it. Next, you’ll need to add the bin directory to your path. For now, I’m just going to add it to my PowerShell profile instead of adding it for the entire system. Here’s all you have to do:

$env:path += ';C:\ironruby-0.9.0\bin'

Once this is done, the IronRuby commands should all be in scope. You can verify this by running “Get-Command ir*” which should return all of the commands under the IronRuby bin directory.

Installing the Sinatra Gem

.NET developers share code by sharing their assemblies. Ruby developers share code by using gems. If you wish to use a .NET library, you usually have to pull up a browser, download a zip file, extract it and then add a reference to the assembly. If you wish to use a gem, you use the gem command and ask it to install it for you. Like so:

gem install sinatra

Then, to actually “reference” the gem in your code, you just “require” the dependencies you have.

require 'rubygems'
require 'sinatra'

Of course, we’re using IronRuby, so the commands are slightly different.

igem install sinatra

If you wish to see all of the gems installed locally, just run:

igem list –local

After installing Sinatra, you should see at least the following gems installed:

NOTE: If you happen to be at work and are behind a proxy, you might have trouble with the gem install command. Ruby and RubyGems take the Unix/Linux approach to proxies. That is, they’re expecting you to have an environment variable set up named HTTP_PROXY. I have a PowerShell script that I run to initialize this for me, but it basically just does this (assuming you have populated the required PowerShell variables):

$env:http_proxy = "http://$username:$password@$proxy:$proxyPort"

I use the Get-Credential cmdlet so that I don’t have to hardcode my username and password anywhere.

Patching Sinatra to run with IronRuby First

Now… you’re not done with installing Sinatra yet. Sinatra doesn’t yet support IronRuby out of the box (as of sinatra 0.9.4 anyway). Check out the IronRuby documentation on patching Sinatra to get it to run under IronRuby. Basically, you can open the base.rb code file (mine was under C:\ironruby-0.9.0\lib\IronRuby\gems\1.8\gems\sinatra-0.9.4\lib\sinatra) and paste in the patched code. Comment on the post if you’re unsure how to read and apply a patch.

Your First Sinatra Application in IronRuby

Now, we’re ready to create the first IronRuby code file. Below is the code:

require 'rubygems'
require 'sinatra' 

get '/' do
  "My machine name is #{System::Environment::machine_name}"
end

Pretty easy, huh? I’ve already pointed out the require statements further up the post. The next three lines illustrate the magic and simplicity of sinatra (and of Ruby). Sinatra bills itself as a “DSL for quickly creating web applications in Ruby with minimal effort.”

What those lines say is, when the ‘/’ path (the root of the site) receives an HTTP GET, respond with the string “My machine name is” and then the evaluated machine name that sinatra is running on. Note that I’m using System.Environment.MachineName from the .NET Framework. Note also that I reference the MachineName property using machine_name instead. This illustrates IronRuby’s name mangling feature which maps CLR property and method names to use Ruby’s naming standards.

Running It!

To run your code in sinatra, you use the ir command (ir = IronRuby) against your Ruby source file. You should see something like the following when you run it:

In case you missed it from the screenshot, sinatra outputs that it “has taken the stage on 4567 for development.” 4567 is the port that sinatra is listening on. This means you can browse to http://localhost:4567.

You should see something like the following when you browse to this address.

So, there you go. Your first Sinatra app with IronRuby. If there is interest, I’ll share more about how you can use Sinatra including how to use ERB to have templates with Sinatra.

So, it didn’t occur to me until today that I was creating a trilogy here.

If I had thought about it ahead of time, I would’ve given my titles more creative names like “devLink”, “devLink Strikes Back” and “the Return of devLink.” The true test will be to see if the second post is everyone’s favorite.

Oh well. Maybe next year.

Managed Rootkits

The first session I went to on Saturday was an Open Spaces session on Managed Rootkits convened by Bill Sempf.

Before I continue, read that sentence again. Didn’t see it yet? Here’s a hint: Managed Rootkits. You know, managed… as in managed langauges… like .NET. Get your attention yet? It did mine, which is why I showed up! Of course, I expected to be completely lost because, in my mind, rootkits are hard stuff that take a computer genius to find and fix. Surprisingly though, the concept behind managed rootkits is easy.

But first, some background. Bill had attended Defcon which is where he had originally heard about managed rootkits in the first place (note that his post links to a page that includes a demonstration). That’s how the entire session came to be.

So, wanna know how to hack the framework?

First, take mscorlib. (that’s the primary .NET assembly by the way)

Next, take ildasm. (that’s the MSIL Disassembler – the built-in Reflector if you will)

Disassemble mscorlib into IL.

Write your own IL and paste it in the IL you got from disassembling mscorlib.

Find ilasm on your machine. (you guessed it, that’s the .NET Assembler)

Assemble your modified IL into a new mscorlib.

Drop it in the GAC.

You L33T hacker you.

The entire reason this works is because, once an assembly has been installed into the GAC, the framework doesn’t run additional checks to verify that the assembly matches the hash in its strong name. So yeah, strong naming doesn’t protect assemblies.

Once we were all up to speed on the logistics, we discussed if this was, in fact, a zero day exploit. It’s not. Why? Because you still have to have administrative privileges to modify any files in the GAC. As Raymond Chen points out, “if you have full trust, then you can do anything.”

Anyway, it was a very interesting conversation. I made the point that, even if it isn’t a security vulnerability, there is the whole user perception issue. For example, if an assembly that your application uses is modified so that it posts your credit card information out on the internet, network trace tools are going to show that it is your application that is connecting to the internet. If your computer were already infiltrated to the point that someone could modify mscorlib on your machine, though, managed rootkits likely aren’t your biggest concern. Oh well, it sounded like a good argument at the time.

Domain Driven Design

The next session I attended was on Domain Driven Design with Craig Berntson. Here’s the synopsis from his blog:

Domain Driven Design is a way to design and develop enterprise applications so that they are easier to maintain, enhance, and extend. DDD is overkill for many of the applications we develop today, but still has principles that can be applied to most of the apps we write. In this session, you will learn to apply these concepts.

My personal feelings regarding this talk was that he did an excellent job at actually communicating DDD. He contrasted the typical data-driven design for applications to driving the design of the system from the business domain. He also did a good job of explaining it in terms that everyone could understand. It was a very good talk.

Lunch over Open Spaces

Over lunch, I went back to the Open Spaces area to see if there were any sessions going on then. A group of people were all sitting in one area so I assumed it was going to be a great conversation. It certainly was, but it wasn’t a planned session. It wasn’t even technical in nature at times… I remember discussing favorite Family Guy episodes at one point…

Architecting Architectural Stuff

My last session was on Architecting Modern Distributed Applications with Clint Edmonson. He has posted his slides and thoughts on the conference on his blog. He shared a diagram that he had seen at an internal Microsoft presentation that showed the various architectural layers in typical applications and showed how you could use the diagram to help make decisions like self-hosting versus hosted solutions versus moving entirely to the cloud. A comment he made in passing but that I thought had a lot of merit was adding in a ping operation to all of your services so that you can quickly and easily determine the state of what is working and what isn’t. I know hardware almost always has this, but I hadn’t really considered putting it in software. I know, you’ve probably been doing it for years.

Closing Circle

At the end of the day, I went to the Open Spaces closing circle where we went over the week, discussed how we could more effectively publicize Open Spaces to the rest of the conference attendees, and other things related to the conference. I was a jerk and had to leave early, but it was all positive while I was in the room. I’m pretty sure it didn’t erupt or anything after I left

Once again, kudos to John Kellar and team for planning another amazing devLink. If you’re interested in seeing more and better pictures than I’ll ever be able to take, David Giard has posted a link to his pictures on his blog. If you weren’t able to attend this year, go next year.

Yesterday, I blogged about the first day of devLink – today, I’ll continue the recap with, you guessed it, day 2.

The Open Spaces side of devLink started on day two, so that’s where I went. Like last year, Alan Stevens kicked everything off with the opening circle. (if you’re unclear on the Open Spaces concept, I gave it more time in my post from last year)

Convening my first open space session

Last year, I didn’t have the guts to jump out there and provide a topic that I wanted to convene. This year, though, I thought I’d give it a try. So, I threw out Event Driven Architecture using tools like MassTransit or nServiceBus. Of course, when I brought it forward, I only said MassTransit and a few people came up to ask if I was referring to “mass transit” as in buses or trains. I guess I could’ve been more clear in my explanation. My primary purpose in picking this topic was entirely selfish – I hoped that someone would show up who knew more about it and they could do most of the talking!

Let’s just say it didn’t quite work out that way

I still think it went well. I ended up going over the very basics of EDA and MassTransit and having a discussion about how EDA can vastly decrease coupling in applications as well as how it also completely changes the way a system is architected over all. Interestingly enough, Maggie Longshore mentioned that, in embedded software development, messaging was the norm instead of the typical “call a webservice and wait” that is typical of .NET code. I also spoke about the similarities between EDA and UI patterns like the event aggregator. I mentioned Udi Dahan’s domain events post as well. During our discussion, Jim Wooley mentioned Linq to Events (or the Rx Framework) and pointed everyone to an introductory article on the Rx Framework. I’m still trying to wrap my head around that post!

Towards the end, the conversation drifted off into… just about everything else. We spoke about adding scripting functionality to applications (using tools like PowerShell, IronRuby or IronPython). As the convener, it was my role to ensure the conversation stayed on topic, but I was having fun just jumping around to different topics at the end. I think it went well.

jQuery Plugins are cool

Next, I went to an “eyes front” session from Elijah Manor on writing jQuery plugins. He has posted the slides from his presentation on his blog. Having read “the world’s most misunderstood programming language” from Douglas Crockford, I now consider myself somewhat of a JavaScript fanboy so I really enjoyed the talk. My hands-on experience with jQuery has been fairly limited up to this point and really only included using the Lightbox plugin and a few other tools, so the session was an eye opener. Probably one of my favorite parts of the talk was when Elijah shared some must have developer bookmarklets. I had heard of Firebug Lite before, but the jQuery specific bookmarklets were new to me.

Mono is cool, too

After Elijah’s talk, I went to Sarah Dutkiewicz’s talk on cross platform C# using Mono. I’ve been following Mono from a distance for a few years, so it was good to hear Sarah’s talk. After her presentation, we spoke about things like MonoDevelop, Banshee and other open source things. I wasn’t able to keep up entirely because my Mono experience thus far includes opening MonoDevelop and building Hello World, reading Miguel de Icaza’s blog, and listening to the Hanselminutes episode on Mono and Banshee.

// TODO: Add Mono to the list of cool things to look at some day!

Learning Rails in the hallway

On the way back to the Open Spaces room, I ran into a group of people learning Rails from Leon in the hallway. Note that this wasn’t a planned session - it just happened. Two or three people were sitting on a bench in the hall while everyone else was sitting in the floor. Most had laptops, but a few were looking over shoulders. If I can find a picture, I’ll post it – a picture would communicate this a lot better than I can.

UPDATE: thanks to Matt Brewer for providing a link to the above picture of the impromptu Rails learning session with Leon – and thanks to John Kellar for posting it to his Facebook photo album!

Final Open Spaces Session on… I’m not entirely sure

I was convinced that the final session of the day was on distributed source control. Later, I think I heard it was on DSLs (domain specific languages). In either case, it turned into another fun and random conversation.

I’ll finish up the devLink review covering day 3 soon!

I’ve now attended devLink three times, with each time getting progressively better. This year marked the first time for devLink to be split across three days (from Thursday, August 13 through Saturday, August 15). Day one included preconference-like sessions that were longer in length with days two and three more closely resembling prior years. Like last year, this year also included Open Spaces, which ran over days two and three.

Ruby Enlightenment

My first session of devLink was with Leon Gersing covering Ruby-Koans: Path to Ruby Enlightenment. Let me start this way – I have never been to a session that was presented in quite the way that Leon gave this presentation. Let me give my alternate title for this presentation: “Learning Ruby through Pair Programming using Test Driven Development.” It was amazing. The guys at EdgeCase have created an open source library called Ruby Koans. From the project’s README:

The Ruby Koans walk you along the path to enlightenment in order to learn Ruby. The goal is to learn the Ruby language, syntax, structure, and some common functions and libraries. We also teach you culture. Testing is not just something we pay lip service to, but something we live. It is essential in your quest to learn and do great things in the language.

Leon helped everyone get Ruby othat was done, we broke up into pairs and went through the koans. Leon walked around the room and helped whenever someone ran into a question or a problem.

Let me share the first koan with you as an example. Pull up your favorite command prompt and go to the directory where you extracted ruby_koans. Once in that directory, run rake (rake is to ruby as make is to C or as nant/msbuild is to C#/VB.NET).

The rake file changes the directory to the koans directory and then executes the various ruby files in it, which are unit tests. The first test fails in the ./about_basics.rb file on line 10. Here is what that file looks like:

You don’t really even have to know programming to see what you should do here. Just change the false to be true to get your test to pass. Once that is done, move to the next test and so on.

The koans start at the simplest level and then move up to higher levels of complexity to expose you the Ruby language.

Thanks to Leon for sharing this with us and helping to bring us all closer to Ruby enlightenment!

(thanks to the devLink site for the above picture of the Ruby Koans session)

Closures Explained

The next session was with Chris Smith on closures, lambda calculus, and functional programming with both C# and F#. I already had a basic understanding of closures, but I got a lot more from this talk. Surprisingly, lambda calculus’s name is far more complex than the actual concepts that it introduces. Unfortunately, I still can’t read more than half of the F# examples out there. I seriously need to try it out on some personal projects to understand it. Luckily, the ideas behind it are more solid now. Great job Chris!

The Lost Art of Simplicity

The opening keynote was presented by Josh Holmes on the Lost Art of Simplicity. He posted the slides from when he gave his presentation earlier in the year, so I won’t spend a lot of time speaking on it. I do want to share a few thoughts that I got from it, though.

Josh brought up the thinking that a lot of developers have when they see an application or other project: “I could build that in a weekend.” I saw this thinking a lot from people when stackoverflow.com was built. Josh pointed out the disconnect between this and then explaining to our users that a new feature will take eight months.

That sort of hit me in the gut

He’s right, of course – we do this all the time, particularly in “enterprise” development.

Another comment he brought up that was both true and funny at the same time is that we as developers don’t speak human, we speak geek. How right he is.

And now for something completely different…

Lunch boxes do more than carry food

They carry code. Below is a picture that Micky McQuade took of me trying to explain closures of all things to Anthony Ford. My communication skills were lacking at the time, so I decided to try to communicate with code and, seeing as how the lunch box was the closest writing medium I could find, I used it.

The code snippet below is approximately something like:

void Foo()
{
   var x = 5;
   var nums = new List { 1, 2, 3 };
   nums.ForEach(n => Console.WriteLine(x));
}

I wanted to show how, if the lambda were moved out to its own function, it wouldn’t be able to access the x variable.