Unfortunately, that means for those that are still using cuke4duke, you’ve got problems to deal with. The voodoo magic that is cuke4duke does not install gems very well. I don’t know precisely why this is, but it ends up with many problems. Things that will install just fine using a jruby command line, or in native ruby barf a horrible death. Often regarding some YAML::Syck thing.

ERROR:  While executing gem ... (ArgumentError)
      undefined class/module YAML::Syck::DefaultKey

Really sucks and makes it difficult to actually use cuke4duke unless you’ve already got all the gems you need installed.

After much investigation, I discovered that cuke4duke uses a GEM_HOME of ~/.m2/repository/.jruby . So a simple command can get the gems you want installed into that folder:

java -jar jruby-complete-1.6.4.jar -S gem install json --version=1.5.4 --no-rdoc --no-ri -i /home/dkowis/.m2/repository/.jruby

Unfortunately, if there’s another “gem” command in your path, it will use that instead of the one in your jar file, so you have to munge your path as well to prevent it from doing so.

Finally, I needed a way to get this into our project’s Maven POM so that we could easily set up other peoples boxes and the configuration isn’t lost in some terribly manual process of running that command over and over.

This is the solution I came up with:

        <profile>
            <id>install-gems</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.6</version>
                        <executions>
                            <execution>
                                <phase>generate-test-resources</phase>
                                <configuration>
                                    <target>
                                        <property file="gems.properties"/>
                                        <macrodef name="install-gem">
                                            <attribute name="gem"/>
                                            <attribute name="version"/>
                                            <sequential>
                                                <java jar="${maven.dependency.org.jruby.jruby-complete.jar.path}"
                                                      fork="true"
                                                      failonerror="true"
                                                      maxmemory="64m"
                                                      newenvironment="true">
                                                    <arg value="-S"/>
                                                    <arg value="gem"/>
                                                    <arg value="install"/>
                                                    <arg value="@{gem}"/>
                                                    <arg value="--version=@{version}"/>
                                                    <arg value="-i"/>
                                                    <arg value="${user.home}/.m2/repository/.jruby"/>
                                                    <env key="PATH" path="${java.home}/bin"/>
                                                </java>
                                            </sequential>
                                        </macrodef>
                                        <install-gem gem="json" version="1.5.4"/> <!-- needed to get json to behave with jruby -->
                                        <install-gem gem="cucumber" version="1.0.3"/>
                                        <install-gem gem="cuke4duke" version="${gem.cuke4duke.version}"/>
                                        <install-gem gem="nokogiri" version="${gem.nokogiri.version}"/>
                                        <install-gem gem="rspec" version="${gem.rspec.version}"/>
                                        <install-gem gem="rest-client" version="${gem.restclient.version}"/>
                                        <install-gem gem="jruby-openssl" version="${gem.jrubyopenssl.version}"/>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

One can then run the command ‘mvn test -Pinstall-gems’ and the gems will be installed as part of the test-resource-generation phase. This only has to be done once whenever new gems are added, or on initial setup. Once it’s done, you’re good to go with the normal cuke4duke workflow.

Hopefully this will save other people some time :)

I wanted to figure out how to require/load/import additional files into the deploy.rb file so that I would be able to drop recipes in to a config/recipes directory.

Turns out this is the solution.

I ended up using this to simply load all the recipes in the recipes directory:

#load in all the other recipes
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), 'recipes')
Dir['config/recipes/**/*.rb'].each { |recipe| require  File.basename(recipe, '.rb') }

I looked into upgrading cucumber-rails, and apparently they recommend using Capybara instead of webrat for Rails 3. So I make the necessary changes. Unfortunately Capybara only has a get method. You can only visit pages. Any posts should be exercised by the web forms. This is far less than useful. It has proven to be a huge pain the butt. Hours of trying to find how people do this to no avail. Until I find an obscure answer, at the bottom of a StackOverflow posting.

That code on github is the key to testing APIs. It appears to use some of the more internal guts of the Capybara page drivers to accomplish it’s goal. Works for me.

I am surprised to see that there are few integration test frameworks that support this kind of web service test. Especially since where I work, this is what we build. Having Cucumber features describing those API calls makes everyone’s job easier. I find it unfortunate that it seems to be somewhat ignored by the testing community. Hopefully this will contain the necessary words for other people that are searching for the same thing I spent hours searching for, and will find it in far less time.

It appears that the original gem is unmaintained, and so I just forked it and updated some parts.

You need to install openssl-devel, zlib-devel, bison, gcc, make, patch, tar, and maybe gcc-c++ (although I don’t think this one is needed).

Go get the latest ruby 1.9 source, as of this writing 1.9-p378, and extract it somewhere. Then go get the patches on this bug, at the specific comment. You will need to apply at least the openssl-build-fix patch, since fedora uses openssl 1.0 and it’s not yet into ruby 1.9. Then follow your typical ./cofnigure, make, and make install stuff. I installed mine into a prefix of /opt/ruby so that it wouldn’t affect any fedora ruby stuff that it might want. I then added ruby’s path to the end of my user’s PATH variable.

That’ll get you a working ruby 1.9 in Fedora.

Woot.

EDIT:

Man, this guy has all sorts of good stuff: http://www.vim.org/account/profile.php?user_id=9012

cucumber, rails, ruby, git-vim integration. VIM FTW!

Anyway, there’s also something called grails. It’s groovy’s rails application framework. I’m hoping that it’ll be more useful to me than ruby on rails was. Whilst I was able to get some stuff done in rails, I wasn’t able to do quite what I wanted to do. Things didn’t interoperate the way I wanted them to. Building things to be completely REST-ful was a pain. It may simply be that I don’t know enough to do fully RESTful applications.

Also, testing was a pain in rails. I found several testing frameworks, but none quite fit what I wanted to do. That may have had something to do with my insistence upon using constraints in my database. Rails isn’t built to handle constraints, it wants your database to be dumb. I don’t really think that’s a good thing; having constraints in your database allows the database to make more intelligent optimizations regarding the data. Since rails assumes there aren’t any constraints on the database, it generates tests that break databases that use constraints. There are a few work-arounds, but none that exist well enough to actually run all my tests at once. I can piecemeal them and if I do them in the correct order, everything works just fine.

Regarding ruby itself, I miss the ability to create threads. I’ve finally understood threading in java, and how to efficiently and effectively use threads to handle things. Lacking a similar threading operation in ruby (at least an obvious one) I had a lot of trouble trying to implement some of the things I wanted to do. I love the dynamic-ness of ruby, and I like the ability to just write code and it does mostly what I think it should. There is probably a good way to do threading in ruby, I mean, people have written webservers entirely in ruby, I just haven’t figured it out. I’ll probably still use ruby for things, I’ve got a project or two churning around in the back of my mind to use ruby on, but for now, I think I’ll stick with Java.

This has turned more into a rant about what I don’t like about ruby and rails. I guess I’m hoping that grails will live up to my expectations more than rails did, and that groovy will give me the dynamic fun that I enjoyed with ruby.

require 'net/http'
require 'uri'

proxy_addr = 'localhost'
proxy_port = 8118

url = URI.parse('http://shlrm.org/baconflowchartvj8.jpg')

Net::HTTP::Proxy(proxy_addr, proxy_port).start(url.host)   do |request|
  puts "Connected to teh proxy"
  # connected to mah proxy
  to_save = url.path.split(/\//)[-1]
  File.open("c:\\" + to_save, 'wb') do |f|
    puts "opened file"
    request.request_get(url.path) do |response|
      content_length = Integer(response['content-length'])
      total_count = 0
      response.read_body do |str|
        if str.length > 0 then
          total_count += str.length
          print "Complete: #{total_count} of #{content_length}:  "
          puts "%4f" % (1.0*total_count/content_length*100)
        end
        f.write str
      end
    end
    puts "Written file"
  end
  puts "done connecting"
end
puts "all done"

So that’s it.

Unit testing in ruby is just like unit testing in any other language. Assert_* methods abound.

Using the debugger is similar to using gdb or some other debugger as well. There’s a list of commands, you can set breakpoints and watch variables. Nothing very surprising there.

The author offers up a “checklist” for going through your program to ensure that it all works. He firstly reccomends that you run the program with -w. Keep warnings on, so you can resolve issues. He mentions an interesting issue with precendence regarding {} and do…end. To quote the example source code from the book:

def one(arg)
  if block_given?
    "block given to 'one' returns #{yield}"
  else
    arg
  end
end
def two
  if block_given?
    "block given to 'two' returns #{yield}"
  end
end
result1 = one two {
  "three"
}
result2 = one two do
  "three"
end
puts "With braces, result = #{result1}"
puts "With do/end, result = #{result2}"

Which produces:

With braces, result = block given to 'two' returns three
With do/end, result = block given to 'one' returns three

So that’s something to keep in mind. Another gotcha that caught me, is that output may be buffered. I was writing a program to theif images from a website, and I wanted to use print “.” to show completion of an image, but the software wouldn’t show anything. puts “.” would work, but that put a newline character. I hacked around it by calling $stdout.flush to force it to put the . to the console. Setting “sync” on the thing may have worked better.

Also of note is a benchmark module built into ruby. You can profile and run benchmarks and it’ll provide you pretty statistics after running. I’ve used the java profiler before in the past, and it can really help you identify slow parts of your software.

That’s mostly the core of the language, and how to build programs. Now, I get into more of the grunt work of building ruby software. I’ll have to look into section two and see if I’m going to jump directly into rails or not…