HAML Tip

January 28th, 2008 by comment desi

So we were having an issue with haml and using a text-area output. It had indentation when it should not have and double indented after doing a save. A quick google search brought me to Ray Morgan’s Blog for the answer. Basically instead of using the = sign use a ~ and it will preserve whitespace. Thanks Ray. I am posting it here so I will remember where to find it if/when I forget what the answer was in the future.

ˆ Back to top

Call Me! A quick how-to for getting dialable phone numbers in your Rails app.

January 22nd, 2008 by comment desi

This might be something everyone knows but just in case I figured I would post a quick how-to on getting a clickable phone number in your Rails app. This example is only for the iPhone user_agent but you can make it work for other types as well as long as you know the user_agent.

Place the following code snippet in your application.rb file

 session :mobile => true, :if => proc { |request| Utility.mobile?(request.user_agent) }

  class Utility

    def self.mobile?(user_agent)
      user_agent =~/(iPhone)/i
    end
  end

Then in your view or your presenter code put a check for the session variable and if it is set then display the clickable phone number with the tel protocol in the href like so


"tel:#{contact.phone}"

and if its not set then just do things normally. Make sure you have the check there because if you don’t then when someone clicks the link in the browser it will complain about not understanding the tel protocol.

ˆ Back to top

A Hello World for Ruby on Ragel 6.0

January 13th, 2008 by comment Ana Nelson

This is an updated version of this tutorial. This updated version is compatible with Ruby 1.8 and Ruby 1.9, and Ragel 6.0. A version of this tutorial in Portuguese is available here.

By the end of this post, you’ll be able to turn a simple string “h” into the much longer and more interesting string “hello world!” using the magic of Ragel, all from the comfort of Ruby. Ragel is a very powerful state machine compiler and parser generator, which is at the heart of software like Mongrel and Hpricot. It’s able to generate C, C++, Objective-C, D, Java or Ruby code.

Ragel has excellent documentation provided by the author. My goal here is just to give you some context so that the documentation “sticks” when you read it, and to give you a working example which you can modify as you explore Ragel’s functionality. If you want to skip ahead, the full example is here.

The first step, of course, is installing Ragel. The Ragel home page has a Download section which lists ports for various platforms. If you already have Ragel installed, check that the version is 6.0 or higher. You can also compile and install Ragel from the source. Even if you don’t want to install from source it’s handy to have a copy of it to get some examples to play with. The subversion repository for Ragel is located here:

http://svn.complang.org/ragel/trunk/

As usual the test/ directory is your friend, also check out the examples/ directory. As per this thread, try searching for “LANG: ruby”.

When writing Ragel code, you create a file with a .rl extension. The .rl file is written in the “host” language, in this case Ruby, and the Ragel machine specification is embedded within the Ruby code using special delimiters. There’s actually no obligation to specify a state machine, so a perfectly valid .rl file is:

puts "hello world"

Don’t worry, I’m going to do a better Hello World than that, but this is a good place to start. To convert this .rl file into an executable .rb file, use the “ragel” command with a -R flag to indicate that you want Ruby code.

ragel -R hello_world.rl

This will create a file entitled hello_world.rb with the following contents:

# line 1 "hello_world.rl"
puts "hello world"

I’ll, er, leave executing that file as an exercise for the diligent student.

Ragel actually does this conversion in 2 stages. First it creates an XML file, then converts the XML to Ruby. If you want to view this intermediate XML then you can pass the -x flag in addition to the -R flag.

ragel -R -x simple_state_machine.rl > simple_state_machine.xml

Now, let’s write some actual Ragel. Start a new .rl file or download the example and read along. We’re going to create a machine which prints “hello world!” when it’s passed the string “h”, and does nothing otherwise. To indicate to the ragel compiler that we are writing instructions for it, and not Ruby code, we need to place our Ragel code within double-percent-sign-curly-brackets %%{ and }%% , or you can enter a single line instruction by just typing %%. (See page 6 of the User Guide.) Here’s our state machine specification:

%%{
  machine hello;
  expr = "h";
  main := expr @ { puts "hello world!" } ;
}%%

A quick overview of what’s happening here. The name of this machine is “hello” (Ragel makes us name it). It recognizes a single token, the string “h”. When it encounters that token, it performs (in Ruby) the action:

puts "hello world"

Now, if you were to run the ragel command on this file it would compile, but you would basically end up with a blank Ruby file. We have only specified the machine, we also have to tell Ragel to actually translate this machine into Ruby code using Ragel’s write statements. The first write statement we need to add is

  %% write data;

If you add this line after the state machine definition block, it will compile, as long as you remember to add a blank line afterwards. (After you’ve worked with parsers for a while you come to appreciate newlines in a whole new way.) After adding this line and compiling, you should have a rather significant Ruby file with lots of class << self statements all generated by Ragel. You don't need to study this code, at least not right now. It's pretty dull and ugly. And, if you run the ruby file at this point, you won't see any output.

There are 2 more write statements to add, and for convenience we're going to place them within a ruby method. The argument to this method is going to be the string we want to parse. Ragel expects to find a variable named "data" containing an array of ASCII codes, so we will need to convert our string to an array. This is done very easily in Ruby using the unpack method.

def run_machine(data)
  data = data.unpack("c*") if data.is_a?(String)
  %% write init;
  %% write exec;
end

write init tells Ragel that we want to generate initialization code for the state machine. The code Ragel generates here is:

begin
  p ||= 0
  pe ||= data.length
  cs = hello_start
end

The variable p keeps track of which character in the data string we are currently parsing, starting at 0. pe is an upper limit for p. cs stores the current state of the state machine, and here it is initialized to the starting state of the state machine. These variables are discussed in the User Guide.

write exec tells Ragel to write the meat of the parser (finally!). The code generated here will actually take an input (the data argument) and determine what the state of the system should be based on that input, executing any actions which might be triggered along the way. Let's add some puts statements so we can follow the code execution.

def run_machine(data)
  data = data.unpack("c*") if data.is_a?(String)
  puts "Running the state machine with input #{data}..."

  %% write init;
  %% write exec;

  puts "Finished. The state of the machine is: #{cs}"
  puts "p: #{p} pe: #{pe}"
end

Just add 2 more lines at the end to call run_machine with various arguments and then we can actually compile and run our state machine.

run_machine "h"
run_machine "x"

And here we go...

Running the state machine with input 104...
hello world!
Finished. The state of the machine is: 2
p: 1 pe: 1
Running the state machine with input 120...
Finished. The state of the machine is: 0
p: 0 pe: 1

It worked! Now, to help us interpret the values of p, pe and cs let's take a look at the state chart of this state machine. Ragel has built-in Graphviz support to create state charts. We need to use the -V flag instead of -R.

ragel -V simple_state_machine.rl > simple_state_machine.dot

If you render the resulting simple_state_machine.dot file in Graphviz, you should get something like this:

State Chart for Simple State Machine

We can see that the state machine has only one possible transition, from state 1 to state 2. When we passed "h" as the parameter to run_machine we did indeed end up with the variable cs (current state) equal to 2 at the end of our run. When "x" was passed, we ended up with cs = 0. 0 is the error state, indicating that an error occurred in the state machine. (You can tell that 0 is the error state by reading some of the variable assignments generated by write data, the code I said was dull and ugly.)

In the label 104/4:18 over the arrow transitioning from state 1 to state 2, the 104 corresponds to the ASCII code for the letter "h". (Type "?h" in irb.) The / indicates that an action is being performed, and 4:18 tells us that the action starts at line 4, column 18 of the .rl file. Had we given our action a name, that would have appeared here instead of the file position.

By the way, here's the (textmate-specific) shell script I use to run all these steps quickly:

ragel -R simple_state_machine.rl
ragel -V simple_state_machine.rl > simple_state_machine.dot
dot -Tpng simple_state_machine.dot > simple_state_machine.png
open simple_state_machine.png
ruby simple_state_machine.rb
mate simple_state_machine.out

Now, try running this code:

  run_machine "hh"

You should get:

Running the state machine with input 104104...
hello world!
Finished. The state of the machine is: 0
p: 1 pe: 2

You don't get "hello world!" twice. Sorry. Our state machine is only looking at a the first character we pass. It knows we gave it two characters, the variable pe = 2, but after it evaluates the first character it's in a final state. There's no arrow coming out of the state 2 circle. So, passing additional input results in the system entering the error state. If we want the entire data string to be evaluated, we need to make a small change to our machine specification.

main := expr+ @ { puts "hello world!" } ;

Endless Simple State Machine

(Try expr* instead of expr+ and see how the state chart is different.)

Now, try running this new state machine with inputs "hhh" and "hxh":

Running the state machine with input 104104104...
hello world!
hello world!
hello world!
Finished. The state of the machine is: 2
p: 3 pe: 3
Running the state machine with input 104120104...
hello world!
Finished. The state of the machine is: 0
p: 1 pe: 3

When we pass "hhh", we get a "hello world!" for each "h". When we pass "hxh", we get the first "hello world!", but when we hit the "x" we enter the error state, so the last "h" doesn't get evaluated.

Here's one more example, this time without defining a run_machine method:

  %%{
    machine hello_and_welcome;
    main := ( 'h' @ { puts "hello world!" }
            | 'w' @ { puts "welcome" }
            )*;
  }%%
    data = 'whwwwwhw'
    %% write data;
    %% write init;
    %% write exec;

Hello and Welcome State Machine

welcome
hello world!
welcome
welcome
welcome
welcome
hello world!
welcome

So, there you go. Hours of entertainment await you. We've only scratched the surface of Ragel's features here, but you should now be able to navigate through the User Guide without too much trouble. If you need a better reason than "fun" to play with Ragel, then bear in mind that parsers are a great tool for constructing Domain Specific Languages (DSLs), and state machines are magic code shrinking machines for situations where you need to keep track of the, er, state of something and control the transitions between states (i.e. business logic). I would highly recommend everyone to read this article about Ragel which inspired me to check it out. If you're into Rails, then take a look at the acts_as_state_machine plugin which might be more intuitive than Ragel at first. If the DSL angle is more your cup of tea then you might want to look at ANTLR instead, which has a different focus and feature set than Ragel.

ˆ Back to top

Programming from the (under)ground up

January 5th, 2008 by comment lisa

Hello. Welcome to my first article.

And my brand spankin new, made-from-scratch stab at programming. It’s going to be a bumpy ride: bumpy like fun-old-rollercoaster-bumpy not trainwreck-bumpy (universe willing).

Please allow me to rattle off some quick background facts so you know what planet I’m coming from. I’m a 26 year old retired bartender. I did that for more years than I care to say (ok fine, 8). I fancy myself an amateur artist; basically, I paint for therapy and fun. I’ve always liked things of a nerdy nature (i.e. writing very basic html in a webshell on angelfire when I was 13, Magic the Gathering, guys who majored in Astrophysics, etc). I consider myself very confident and intelligent, and it’s a shame that went to waste for so many years. That being said, years of bartending with no substantial plans for the future wore me out and made me feel quite desperate for awhile.

Then something changed. I got beat down so much by the universe’s way of telling me to stop f’ing around, that I got fed up with being fed up. Well, Desi McAdam happens to be one of my favorite people on the planet and a very close friend, and she had always offered to teach me programming…intensively. She and my other longtime friend/ROR evangelist Obie Fernandez had always told me they thought I’d be a great programmer. I didn’t know what they were talking about. So I called up my dear Desi and said “I’ll do whatever it takes. Let’s do this thing.”

I thought I was going to be learning in my off time while still bartending and getting tutored whenever Desi was in town. I knew this would take a very, very, very long time, but I felt ready for the challenge.

As it turned out, she and Obie were down here in Florida on the beach working with this fabulous guy Mark Smith. I had met him some weeks before, and we all had a great time together. They wanted to bring an apprentice on to the small team, so voila! Here I am. I am now in full on training starting with nothing but my instinctual and intellectual abilities and no experience. I am extremely grateful for the opportunity I have, and I intend to give back to Desi and Obie by trying hard to be a bad ass programmer.

Desi is putting alot of effort into being my personal, full-time tutor, and I think she rocks socks for it.

So I’m offering up myself, my victories, and my many future foibles here for your musing and amusement.

Cheers and enjoy

ˆ Back to top

Migrating from Test::Unit to RSpec

January 4th, 2008 by comment jacqui

At Streeteasy, nearly half of our tests are still written in Test::Unit, so it’s hard to see what our actual test coverage is using Rcov.

I read recently that RSpec got support for Test::Unit interoperability. Obviously now is the time to make the switch from Test::Unit to RSpec. You can do it without a mass exodus from Test::Unit. Use your existing tests inside the RSpec test harness.

So here’s how I converted all out legacy tests to rspec.

Step One: update RSpec

This is fairly self-explanatory and written up elsewhere. However, in short, I updated both our rspec and rspec_on_rails plugins, remembering to rerun

$ ruby script/generate rspec

Make a back-up copy of the spec_helper if you’ve customized it. Compare it to the one generated for the new rspec version to see if there’s been any significant changes, and if so, merge them into your helper.

Step Two: move your files from test/ to spec/

This is what I did: I copied test/unit/* to spec/models/, renaming them appropriately:

  ## current_path is a hash where :tu => test::unit path and :s => spec path
  def make_tests_specs(current_path)
    current_path[:tu].each do |file|
      unless file == "." or file == ".."
        full_file = File.join(current_path[:tu].path, file)
        if File.directory? full_file
          spec_file = full_file.gsub(/test/, "spec")
          spec_file.gsub!(/unit/, "models")
          spec_file.gsub!(/functional/, "controllers")
          FileUtils.mkdir_p(spec_file) unless File.exists? spec_file
          make_tests_specs({:tu => Dir.new(full_file), :s => Dir.new(spec_file)})
        else
          new_spec = File.join(current_path[:s].path, file.gsub(/_test/, "_spec"))
          puts "converting TestCase #{full_file} to ExampleGroup #{new_spec}\n"
          File.copy(full_file, new_spec)
        end
      end
    end
  end

Step Three: change your assertions

While that would move all my tests over to the specs directory and rename them, I figured, why should I stop there? I realized I could probably do a lot of the Test::Unit to RSpec syntax conversions programmatically. Here are the regular expressions I used to do the substitutions – while these worked great for our codebase at StreetEasy, your mileage may vary, so be sure to use caution before running this against your code base (and hey, you do use source control, don’t you?):

if line =~ %r@require.*?test_helper@
  new_file.puts "require '#{RAILS_ROOT}/test/test_helper'"
  new_file.puts "require '#{RAILS_ROOT}/spec/spec_helper'"
elsif line =~ %r@class.*?TestCase@ and line !~ %r@Controller@
  new_file.puts "describe 'transitioning from TestCase to ExampleGroup' do"
elsif line =~ %r@class\s*(.*?)Test@
  new_file.puts "describe #{$1}, 'transitioning from TestCase to ExampleGroup' do"
  new_file.puts "integrate_views"
elsif line =~ %r@def setup@
  new_file.puts "before do"
elsif line =~ %r@def test_(.*?)\n@
  new_file.puts "it \"should #{$1.humanize.downcase}\" do"
elsif line =~ %r@assert_response :success@
  new_file.puts "response.should be_success"
elsif line =~ %r@assert_response :redirect@
  new_file.puts "response.should be_redirect"
elsif line =~ %r@assert_redirected_to (.*?)\n@
  new_file.puts "response.should redirect_to(#{$1})"
elsif line =~ %r@assert_equal (.*?),\s(.*?)\n@
  m1 = $1
  m2 = $2
  unless m1.nil? or m2.nil?
    unless m1.match(/nil/) or m2.match(/nil/)
      new_file.puts "#{m1}.should == #{m2}"
    end
  end
elsif line =~ %r@assert assigns\(:(.*?)\)$@
  new_file.puts "assigns[:#{$1}].should be_true"
else
  unless line =~ /^class.*?Controller.*?rescue_action.*?end$/i or line =~ /require '.*?_controller'/i or line =~ /^#/
    new_file.puts line
  end
end

The above block of code will convert any response (:success, :redirect, redirect_to), assigns, and equality assertions. It will change your method declarations to “it ‘should…’ do/end” block syntax. It will require both the test_helper and spec_helper. It will integrate_views by default on your functional (controller) tests; you might want to go through those by hand later and separate out the front-end stuff into a set of view tests, depending on how you feel about them.

You could definitely write more substitutions – there are more assertions in Test::Unit, of course. If your code base makes extensive use of other assertions you’ll probably want to add to the regexes above. In our case, however, I found the above satisfied converting the most straight-forward Test::Unit assertions, leaving me with the slightly more complicated examples to convert by hand, which brings me to the next step.

FYI, you can find a table of Test::Unit assertions and their RSpec equivalents here on the RSpec documentation site.

Step Four: run rake:spec and see what happens

You might as well see what situation any automated conversion process left you in. I had a few errors during this phase – mostly due to the fact that I forgot to move my fixtures, woops – but it didn’t take me very long to resolve them.

Step Five: go through each sparkling new spec and convert any remaining Test::Unit-based assertions into RSpec syntax.

The good news: you can take your time on this step since RSpec now plays nice with Test::Unit. I was in a particularly motivated and productive mood after finding myself with a big directory full of specs (and an amazingly empty test/ directory) so I just went through them all right then and there. It took me most of the afternoon, but when I left work that day I was able to see this, which is just awesome:


$ rake spec
........................................................................................................................................................................................................................................................................................................................................................................................................................................................

Finished in 70.023361 seconds

440 examples, 0 failures

As you can see from the amount of time it took all 440 examples to run, we could definitely benefit from a greater use of mocks and stubs in our controller tests. 70 seconds is a tad bit long. That’s next on the to do list – mock and stub wherever I can in our controller tests, followed by integration/big picture testing using Story Runner, and then, if there’s time*, refactor our specs to be better organized and efficient – I can think of several places where I had wished for nested examples, or could have used shared examples, had I been aware they existed at the time.

I’ll be writing up my experience with Story Runner in the next couple of weeks. Til then, though, best of luck in your specs!

* always a compromise when you’re trying to do things the right way and add business value simultaneously.

For more information Behavior Driven Development, check out Dan North‘s article, “Introducing BDD.”

You can find the documentation for RSpec at http://rspec.info.

Many thanks to Joshua Sierles, Paul Marsh, and Josh Knowles for their time in reviewing this!

ˆ Back to top

RubyEast Recap, Slides, and Other Thoughts

September 30th, 2007 by comment desi

I spoke at RubyEast this past Friday and I think the presentation went pretty well. It was my first presentation in a speaker/audience type setting so I was very nervous. I have presented at Agile 2006 but it was a game (interactive) and was co-presented by several other people. This presentation was the first time I stood in front of a room full of people and spoke and everything went very well. Like I said I was really nervous but as soon as I got started the nervousness went away. I think I am very lucky because I was able to present to a room full of very nice/cool people and that made the experience a great one. I want to actually thank the people who came to hear me present and who gave me great feedback and encouragement afterwards it really made my day. If you are interested here are the slides for the presentation. A Tour Of Rails Testing using RSpec

I didn’t get to see many of the sessions because I was busy preparing for my talk but I was able to catch Obie’s presentation – Advanced ActiveRecord which was really good (and I am not just saying that because he is my boyfriend). I also caught the ending Keynote where Nap (I actually don’t know his real name) announced the Rails Rumble winners. There were several screencasts and it made me wish that Obie, Clay, Nick and I would have had time to get the video that was shot of us over the weekend edited and ready for prime time. We had a blast doing the competition and while we didn’t win (we got honorable mention) we learned a lot and I think we all grew closer in those 48 hours. The teams that did win did a tremendous job on their apps and well deserved the loot. Take a look at the winners there really are some great apps. Rails Rumble Winners

Friday evening a bunch of people got together after the conference and played several games of Werewolf which is a really fun game to play. I got to know a lot of people during that game and it was a great way to wind down.

Couple of other thoughts before I end the post. ShesGeeky (un)Conference sounds like it is going to kick major ass so any of you ladies out there who can attend make sure you get registered. Additionally, ladies if you want to talk during the conference please contact the organizers.

GrrrlCamp seems to be getting a good footing. I was lucky enough to meet THE Gloria this past Friday and I look forward to being a part of GrrlCamp.

I have taken on an apprentice and she will soon be posting to the blog about her experiences. I am in the process of trying to see if creating an apprenticeship type program run by DevChix is possible because after speaking with Sonia (one of the women on DevChix) she helped me figure out that I would really like to have a program that fits the apprenticeship model rather than a mentoring program. Look for more to come on this in the future.

ˆ Back to top

Ruby East Registration Open

August 16th, 2007 by comment desi

Ruby East registration is open. It is a one day Philadelphia based Ruby on Rails Conference that is being held 9/28. They have limited space so if you are planning to go you should probably go ahead and register. I am pretty happy to say that there will be 3 DevChix members presenting at the conference. I think it will be a great day.

ˆ Back to top

Twitter4R on Rails

July 26th, 2007 by comment mbbx6spp

Last night Twitter4R version 0.2.4 was released with a fix that makes using Twitter4R in Rails much easier.

So let’s quickly kick the tires to see how this all works:

  1. Install the Twitter4R v0.2.4 (or above) Ruby Gem: sudo gem install twitter4r
  2. Create a new rails application: rails twitter4rails
  3. After setting up your config/database.yml to your personal tastes and tweaking the Rails configuration settings in environment.rb, scroll to the bottom of environment.rb and add the following:

    gem(‘twitter4r’, ‘>=0.2.4′)
    require(‘twitter’) # loads core library
    require(‘twitter/console’) # loads a helper method we will use
    require(‘twitter/rails’) # added Rails extensions for Twitter4R

    module YourAppNamespace
    ENV["RAILS_ENV"] ||= “test” # assume test environment if no RAILS_ENV set.
    ClientContext = Twitter::Client.from_config(“#{RAILS_ROOT}/config/twitter.yml”, ENV["RAILS_ENV"])
    end

  4. Now in your controllers you can access YourAppNamespace::ClientContext object as you need to or any other part of the Twitter4R API.

If you still want more, feel free to check out the following links:

ˆ Back to top

will_paginate array?

July 23rd, 2007 by comment desi

Today I started putting pagination in the app that I have been working on. Based on recommendations from Obie I decided to use “will_paginate”, a rails plugin for pagination put out by the err the blog guys. It worked amazingly and the view helper was great! I really like the fact that I can apply the same look and feel to all page pagination throughout the app… well umm.. until I wanted to add pagination to a collection not generated from a finder or association. Since I really wanted everything to look the same and behave the same I did the following little trick so that you can call paginate on a plain old array.

class Array
  def paginate(page=1, per_page=15)
    pagination_array = WillPaginate::Collection.new(page, per_page, self.size)
    start_index = pagination_array.offset
    end_index = start_index + (per_page - 1)
    array_to_concat = self[start_index..end_index]
    array_to_concat.nil? ? [] : pagination_array.concat(array_to_concat)
  end
end

Before folks say anything about the above code.. yes I know it could be more concise if I didn’t use all the local variables but I wanted it to be really clear what I was doing here so.. leave it alone.

Now basically you can say

myarray.paginate(params[:page], per_page)

If you want to see it work yourself feel free to run this spec.


require File.dirname(__FILE__) + '/../spec_helper'

describe 'Given we call paginate on an array' do
  it 'should return an array containing the first 3 elements of the org array when page = 1 and per_page_count = 3' do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = 3
    expected_array = ["a", "b", "c"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it 'should return an array containing the last 2 elements of the org array when page = 2 and per_page_count = 3' do
    array = ["a","b","c","d","e"]
    current_page = 2
    show_per_page = 3
    expected_array = ["d", "e"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it 'should return an array containing all the elements of the org array when page = 1 and per_page_count = 5' do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = 5
    expected_array = ["a","b","c","d","e"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it 'should return an array containing all the elements of the org array when page = 1 and per_page_count greater than org number of elements i.e = 6' do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = 6
    expected_array = ["a","b","c","d","e"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it 'should return an empty array if you ask for a page that does not exist' do
    array = ["a","b","c","d","e"]
    current_page = 3
    show_per_page = 5
    expected_array = []
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it 'should return an empty array if you ask for a negative page number' do
    array = ["a","b","c","d","e"]
    current_page = -1
    show_per_page = 5
    expected_array = []
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it 'should return an empty array if you ask for a negative per_page number' do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = -5
    expected_array = []
    (array.paginate(current_page, show_per_page)).should == expected_array
  end
end
ˆ Back to top

FOSCON III: Really Radical Ruby

July 19th, 2007 by comment audrey

The Portland Ruby Brigade is hosting our third annual evening of Ruby fun, next week during OSCON. FOSCON III will be held Tuesday, July 24th, at Holocene in SE Portland. I’ve helped plan this the last two years, and it’s a really great opportunity to learn more about Ruby and meet interesting people who work with it. There’s also still time to sign up for a lightning talk, if you have something you’d like to show off. Here’s the official announcement:

Once again the Portland Ruby Brigade will be hosting an evening of wide ranging talks about Ruby. This year the focus is on people doing strange things with Ruby. Strange, of course, is anything just a bit outside the expected. If you’ve created a new Ruby-based interface for hacking your brand new internet-enabled phone (rPhone anyone?) or composed your latest bit of metaprogramming magic, we’d love to hear about it.

Rather than having a fixed list of presenters, we’re keeping it open-ended and free form. We’ll use the lightning talk idea and give you each a 10 minute (give or take a few) slot to tell us what you can cram in. Make it especially interesting and we might even give you an extra minute or two. Let us know (send email to tlockney+foscon@gmail.com) in advance if you are interested in presenting or show up early on the 24th to sign up for a possible slot.

This will all be taking place on Tuesday, July 24th, 7:30PM at Holocene here in Portland, Oregon. This just happens to be the same week as O’Reilly’s Open Source Convention and the final day of Ubuntu Live. So if you’re in town for either of those or close enough to come join us anyway, you’re more then welcome.

There will be plenty of Ruby fun going on and lots of socializing with other people interested in Ruby. Last year, FOSCON II was overflowing. We’ve found a new venue to fit you all in, so why would you miss it?

ˆ Back to top