Showing posts with label IronRuby. Show all posts
Showing posts with label IronRuby. Show all posts

Tuesday, April 12, 2011

pik, IronRuby, MRI, and a .Net Project

On a recent ASP.Net MVC project I was leveraging IronRuby and Cucumber to get some BDD specs in place to drive development. Though this post isn't about the benefits of BDD, it was very easy to get the specs worked out with my Product Owner, and the demos went really quickly. For the most part, I was using IronRuby to run functional tests at the controller level.

Then we decided to add on some GUI tests. With Ruby and Cucumber already in place, we decided to give watir a try. Except once we went on to using watir, IronRuby was no longer needed to test the website. We could instead use MRI 1.9.2 as our interpreter and get a little more speed out of our watir tests, and leverage the latest version Cucumber.

Since we're doing our development in Windows we don't have the luxury of RVM, but pik is a great solution to switching Ruby interpreters on Windows. During development, a few pik switch statements keeps all our cucumber tests in sync with either our IronRuby testing or our watir testing. However, if we wanted to run them all at once I had to write a little batch file to handle it. (I'm a dev, I'm lazy, I just want to type one line in the command prompt and have it all kick off...)

After knocking the rust off my batch file fu, here is the contents of that batch file...

@echo off
@call pik sw 100
@call rake
@call pik sw 192
@call rake watir

Here's what's happening in our little five line helper file. First line just doesn't echo your commands back out to the command prompt. After that we call pik sw 100, which is pik switch to IronRuby 1.0.0. Then our default rake task is called, which builds the project, runs the unit test suite (in nUnit in this case), then run the IronRuby cucumber tests. pik sw 192 is switching to Ruby 1.9.2, then calling rake watir just runs our watir tests against the already built website. Pretty straightforward.

Now that was only for our dev machines in order to do one line build test, test, test during development. Our CI server was much easier to configure.

We were using TeamCity as our CI environment when we added watir to the mix, but the batch file wasn't needed as TC allows for different build tasks to use rake and specify which interpreter to use. So it was as easy as add an IronRuby build task call the default rake task, then create another rake build task and call the watir task in the rake file. We have since switched from TeamCity to Jenkins, but the set up with a build task per interpreter is identical.

(Don't have pik installed and you're a Windows using, Ruby loving programmer? Ben Hall's post on getting pik installed and running is the best reference I've found.)

Thursday, August 5, 2010

Why Not Add Some Ruby?

If twitter is good for one thing it’s starting debates amongst your friends. Today didn’t disappoint as Mike started us off with: “things i miss from rails while i'm doing java: rails.”

It started in the productivity trap, which is going to be subjective toScreen shot 2010-08-04 at 10.53.23 PM the developer doing the work, so it’s a tough one to measure. Can I do some things faster in Ruby than I can C#? Yes, but the inverse is still true.

One point I need to make is I’ve seen a few of these discussions and often they become Rails v. C#/.Net, which isn’t really a fair comparison because Rails is a web framework. To go apples to  apples, you need Screen shot 2010-08-04 at 11.01.34 PMto compare Rails to ASP.Net MVC, not .Net in general. You wouldn’t compare WebForms or WPF to Ruby or Python, would you? (You shouldn’t compare WebForms to much of anything…but I digress.)

So, Jon asked a pretty valid question: Why don’t more people switch? Since I come from a .Net background, I’ve really only seen this debated as it pertains to .Net.

For a number of the arguments around the IDE, Intellisense, Static v. Dynamic typing, there are plenty of other blogs that have covered this, here’s a recent one I really liked: Ruby is Scary.

For my quick entry here, I’ll say this…I can have VIM or TextMate open and have a couple tests written before the VisualStudio splash screen has closed. Also, those two tools have yet to throw an “Out of Memory” exception on me, can’t say the same for Studio.

And I don’t really miss intellisense.

On with the show…

On the heels of Jon’s question Bill Sempf jumped in. As a bystander, Bill was very much representing the average .Net dude, and the arguments I’ve heard from the average .Net dude. (Bill has looked into Ruby, we’ve paired writing Ruby. That’s not really the point here, though.)

Ruby, the Average Dev, and the Complex System

@JonKruger: That's not my problem. I just don't think that 80% of the dev teams out there can handle coding in Ruby. (link)

That was Bill’s entry to the discussion, and I’m not sure I can disagree with him. However, I’m going to be snobbish and self centered and say I want to work with the 20%. If you’re in the 80% and can’t code Ruby…or Python, or F#, or any other language you have to learn…I don’t want to work with you. You can stay in “The Enterprise.”

@JonKruger: My point is those stories are told by top-tier devs, and not everyone is one of those. (link)

Again, tough to disagree with Bill’s assertion here. Not everybody is a rock star, and that’s cool. If you’re a budding rock star, you’ll be able to write some effective Ruby code.

In between those tweets were a few others, mainly around supporting complex systems using Ruby. Personally, I haven’t written a large scale application in Ruby, so I can’t lean on any experience here in writing the typical central Ohio “claims app” in Ruby.

What I have done with it has worked well. So my first counter to Bill’s argument on the complex systems: Use it where it fits. Ruby brings a great set of DSLs to the table for testing, web frameworks, and testing. Yeah, said it twice. Year one of Codemash (Jan of ‘07) I listened to Neal Ford talk about DSLs to help write your applications and Polyglot programming. Using Ruby to support your app – to write build scripts, tests, POC web sites – falls right in on the polyglot thing.

On the testing side, I’d much rather read a batch of RSpec tests than a batch of nUnit tests. Cucumber is already helping my current team get through some testing issues. Let me repeat that: I’m using Cucumber in a .Net environment RIGHT NOW to help the team get better test coverage on their application.

Learning a New Language

@JonKruger: There is a difference between learning the language, and being productive in it. (link)

I’m in total agreement with Bill here. Which is why I’m such a big fan of the incremental approach to using Ruby on your projects.

Great place to start: use Rake as your build script. I’ve done this for a couple years now, it’s a great way to dip your toe into Ruby, get comfortable with the language and a few of its concepts without really getting in on your production code. On the .Net side, use Albacore with Rake and you’ll have a build script in no time.

Next up you can start writing some tests in it. That’s a pretty good way to pick up a new language, anyway. And with the nice testing tools with Ruby, you can learn a new language and ease some testing pain.

But, the main point here, don’t be afraid of picking up a new language. How many do you know already? If you’re a web developer, you probably already know Javascript, CSS, HTML, C# (or some back end language), a little SQL, and a healthy dash of XML. Picking up another one isn’t going to be too difficult.

Essence v. Ceremony

I first heard this from Neal Ford, possibly at eRubyCon a couple years back. But, Stuart Holloway had a great blog post about it prior to when I heard Neal speak.

To me (and many others), Ruby gets to the essence of what you’re after quickly. I find myself working within it’s idioms easily, not fighting them constantly with adapter patterns, dependency injection, and ORMs. I find that my tests flow naturally from the various testing tools I use in Ruby, and the code that makes those tests pass benefits from that.

So, to Bill’s point, maybe Ruby isn’t ready to have average devs write big, complex, “enterprise” systems in it. But, it is ready to support what you’re writing today. Right now. Why not give it a try?

Unless you’re afraid of learning…

Saturday, July 31, 2010

IronRuby: Rake, Albacore, and you

In my post about setting up to run Cucumber with IronRuby, I included steps to install Rake and Albacore, but didn’t use them. In this post, we’ll put them to use.

RakeUsing Rake in .Net isn’t really a new idea, and a number of people have been using it for a while. I’ve used rake to compile and run the tests on all my .Net projects for at least the last year. Before Albacore came along to make my Rake tasks easier, I was copying the set-up from the folks at Fluent nHibernate. (FNH has used rake to build as far back as I can remember it existing and is now utilizing Albacore as well.) Now with IronRuby in the mix, rake is going to take on even more fun in your .Net projects.

For my example I’m again going to use my TestingSeaPound project, and specifically the rake file I’m using in that project. Pop it open real quick, and we’ll look through it.

At the top, you’ll see the standard Ruby require statements. In this file we’re including rake, the task library for RSpec, Cucumber, the task library for Cucumber, and Albacore.

Following the required libraries are a number of tasks that are combining the tasks that are defined later in the file. This is a way keep your rake file nice and dry. Define each task as needed, combine them in a call such as task :spec => [:msbuild, :rspec] to reuse them in different situations. From the command line in the directory where this rake file lives, if I enter “rake spec” it’s going to build the code then run RSpec

The only task in this list to take note of is the :default task. That’s the task that will run if you’re at the command prompt and just enter the command “rake”.

MSBuild

Skip down to the line that includes msbuild do |msb|. That’s our first task definition, and in this case we’re using the Albacore library. The top line of that task that includes the path_to_command is needed to build a .Net 4.0 project. I believe a fix is in the works, and may already be in place, but when I set up this file this was the way to call the .Net 4.0 compiler.

The next two lines, properties and targets, should look pretty familiar to anybody who has set up a .Net build in the past using MSBuild or Nant. Here we’re just saying what configuration we want to compile in, and what our target build is. Following that I’m setting the verbosity to quiet to keep the command line output fairly small.

The last line should be fairly obvious, it’s the path the solution file. Since MSBuild is very good at picking up a solution file and building it, why fight it? Pass the solution to MSBUild and let it do its thing.

nUnit

The next task down is our nUnit test runner. This is again an Albacore task, and it’s just pointing the test assemblies at the nUnit console app.

These two tasks are the only Albacore tasks in the file, so here’s as good a place as any to let you know the magic going on under the covers with Albacore. It is in essence building the correct command line arguments for MSBuild and nUnit and then shelling out to run them. Now, there’s more work going on than just that, but that’s the bulk of if. Albacore is giving us a nice DSL to write .Net build tasks. I’m only using two, there are a lot more available.

One important note: to this point our rake file hasn’t required IronRuby. You can use Albacore to build your project and run .Net based testing suites with MRI, IronRuby isn’t a requirement. I know as a .Netter that may seem odd, but we’re really not leveraging the Iron part of IronRuby.

Yet…

RSpec

The next two tasks are both RSpec tasks, and they’re running rspec against our .Net app. The first task is the default runner where it outputs a period for each passing test, the second will output the describe blocks and spec names.

NOW we need IronRuby. Not so much for the rake task, but because RSpec isn’t going to be able to test our dlls without the Iron added to our Ruby.

Cucumber

The final two tasks are Cucumber tasks. The first outputs the standard cucumber output, with each feature and specification output in their full glory – minus line numbers because I turned those off with the –-no-source option. The second task outputs the cucumber specs very much like nUnit and RSpec do, with a period for each passing test.

Once again we need IronRuby. Since I’m using the Ruby version of Cucumber in this case, we need to add the Iron to get it to reach into our dlls and do its magic.

That’s all for the tasks required to build and run the tests for this sample application. If you pull down the code and go to the root of the project and enter “rake all” at a command prompt, you’ll build it and run each suite of tests in order. Give it a try.

Thursday, July 22, 2010

IronRuby at CONDG

Off the top, apologies for the rather dark color scheme. The slides I think I can change the contrast on a little and they’ll be fine, but I know better than to use a dark color scheme for my ide and/or text editor. I guess the editing of the config file in Rails was just all black, sorry about that. (On the config side, you didn’t miss much, though.)

HOWEVER! :)

I just uploaded a PDF of the slides and you can look at them in whatever color scheme really makes them pop! You can get it all here: http://github.com/timwingfield/TestingSeaPound/tree/CONDG

Not a total cop out, please take a look at the code sample if you want to see the complete test classes from the examples - both the nUnit and RSpec ones. The rails app uploaded is the same one I created in the presentation, complete with the poorly named controller.

Again, sorry for the dark background in places, but thanks for coming out to watch.

(And big thanks to Kruger for making me remember how much I miss AutoHotKey after moving to the Mac. Windows devs, download AutoHotKey as soon as you read this.)

Friday, July 16, 2010

IronRuby: 0 to Cucumber in 15 minutes

Screen shot 2010-07-14 at 8.50.18 PM

Once again, a 140 character (or less) “outburst” gets me in trouble with a follower and I end up with a blog post. This one is one I probably should  have written a while back. I’ve enjoyed working with IronRuby the last few months, so this little intro is long overdue.

First things first, you’ll need to install IronRuby. Head off to the download page, and click on your msi of choice and let the installer do its thing.

Since my goal here was to get cucumber ready to roll against some .Net assemblies, you’ll need to install a few gems. IronRuby comes with Ruby Gems already installed, so thankfully to install the ones you need you just need to type ‘igem install’ a few times.

Screen shot 2010-07-14 at 8.49.47 PM“Wait, what? igem? WTF?” Yeah, that’s one of the IronRuby-isms, putting an i on the front of a couple of commands. If you’ve done a bit of Ruby, you’ll have a little muscle memory to retrain, but it’s a small hurdle. (You’ll also type ‘ir’ instead of ‘ruby’ to run a script and ‘iirb’ instead of ‘irb’ to get to irb.)

So, on with our gem installing…

igem install rake

First install is rake. I’m not going to use it right away on the cucumber running, but I’ll use it at some point, I always do.

igem install albacore

Like rake, I’m not going to use this one right away, but I’ve found it to be the one must have gem if you’re using rake with your .Net builds and test runners. It just makes you life that much easier.

igem install rspec

I’m not starting out writing rspec in this example, but cucumber is going to use its matchers.

igem install cucumber –-version “=0.6.4”

This is the one we’re after for this example. Be sure to add that version command on there because IronRuby isn’t quite ready for the latest version of Cucumber. But, 0.6.4 is going to get the job done for us.

igem install iron-term-ansicolor

The first time you run cucumber, it’s going to advise you to install this gem to get color coding in the terminal window. Go ahead and do it now, and you skip that warning. (Or don’t, and check the message for yourself. ;) )

Now all you need is some features, some step definitions, and a dll to write it all against. As luck would have it, I have just that written up in a code sample that I just used at Codestock a couple weeks ago. (And also coming soon to an Ohio user group meeting near you…) Here’s the root of that project: http://github.com/timwingfield/TestingSeaPound

The features directory there is where you’ll find my cucumber samples and the dll they are running against. Download it and give it a shot. Once you get it downloaded, open the command prompt in whatever directory contains the features directory (not the actual features directory) and type:

cucumber features

Happy IronRubying!

Friday, May 14, 2010

Upcoming Speaking Events

As is normal for me this time of year, I’ve got a number of events that I’m attending to do a little speaking and a little learning. This round will take me to three states, but only one time zone (thank goodness).

Indy Tech Fest, May 22

I’ll be presenting on Lean Software Practices. We’ll go through the seven principles of Lean Software Development, and I’ll present some experiences with each as I’ve practiced Lean over the last few years.

Indy Tech Fest might not be too familiar to us here in central Ohio, because it’s outside our MS region. (gasp) But, the folks in Indy do a bang up job with their events, and they have a large, active .Net community. This is my second year venturing west to join the folks at Indy, and it was a great time last year.

The Path to Agility, May 27

This is the first Path to Agility conference, and it’s being put on by the Central Ohio Agile Alliance at the Arena Grand theater in the Arena District of downtown Columbus. They’re bringing in Ken Schwaber to keynote the event, so I am most decidedly on the undercard.

I’ll be presenting my Kanban experiences over the last few years. It’ll introduce Kanban and how to use it to deliver software. I’ll relay the good experiences and the bad experiences.

There is quite a line up for this conference, and there’s still space available. If you can get a Thursday off work, it’ll well worth the $100 to attend. There are some top notch local agile people presenting. (The Clippers are at home that night, stick around for some baseball.)

Central Ohio Day of .Net, June 5

imageThe “home” event. Can’t miss this one, it’s a great time every year.  Getting the Cincy, Dayton, and Columbus folks under the same roof has made for a great event the last two years.

I’ve been selected to give two talks this year. Upside, I’m giving two talks. Downside, it’ll cut into my hallway sessions.

The schedule isn’t out yet, so I don’t know which session fits where. I’m presenting a beginning IronRuby talk, where we’ll get it installed, bang out some ruby code, hit a few CLR objects, and possibly take a few whacks at a piƱata to bring the fun level down a little. The second talk will be the same Lean presentation I’m giving in Indy.

Codestock, June 25-26

image My second trip to Knoxville to get in on Codestock. This is a great event. It’s got .Net roots, but offers quite a bit outside the normal .Net conference sessions. There are a lot of choices to make on what to attend over the two days. They did move to downtown Knoxville this year, so I’m looking forward to the new venue.

I’m speaking twice here, as well. I’ll deliver a Kanban talk, and an IronRuby talk. The IronRuby talk is going to go a bit deeper on testing than the one I’m giving at CODODN.

An added benefit to Codestock is Wendy and the boys go along, and we turn it into a mini-vacation. So, I’ll get a little pool time in, which usually doesn’t happen at conferences not named “Codemash.”

Ohio User Group Tour, July 22, 27, 28

We’re going to IronRuby it up at the Columbus, Cincinnati, and Dayton user groups in July. This talk is going to go into testing our C# code with IronRuby, and what advantages there are to this. The reason the CODODN talk is the beginning talk is because I was scheduled talk for these user groups back in December. Since it’s roughly the same crowd, we’ll do the intro at Day of .Net and dive into the testing at the local user groups.

Expect to see some RSpec running against C#, Rails running on IronRuby, Sinatra running on IronRuby, and mabye we’ll get crazy and put a Rails front end on an nHibernate repository or something. All hell’s gonna break loose during this one!

If I survive all this, I’ll have like 3 weeks of summer to kick back and relax…