The Great Git Commit

Posted by declanmg, Sun Jan 11 21:40:00 UTC 2009

Do you suffer from a fear of commitment? Well, if you're working with a new version control system then you're not alone! One of the big barriers to becoming a contributor to a Open Source project is the effort it takes to make your first commit. In order to celebrate the launch of Ruby Ireland's first Open Source project rubyjobs.ie and to help you make that first commit happen we are running a competition1 - The Great Git Commit!

The rubyjobs source code is hosted on the Internet at a place called GitHub. To manage source code you use a program called git.

All you have to do is download the project from GitHub using git, add your favourite quote to the file the_great_git_commit.txt and then reupload to GitHub. All quotes will be published on the Ruby Ireland website - the closing date of Tuesday February the 10th. You are more than welcome to add a quote after this date - albeit with slightly less fame and fortune that the Ruby Ireland community would otherwise bestow upon you! All developers are encouraged to participate - you don't need to have anything to do with Ruby Ireland. It doesn't matter if you intend to contribute to rubyjobs.ie or not - or indeed if you are a Ruby developer at all - the goal is to get you comfortable with Git and GitHub whilst having a bit of fun.

'The Great Git Commit' Instructions
This is your mission, should you choose to accept.

  • Install git on your machine
  • Set up an account on GitHub
  • Visit the rubyjobs project repository on GitHub
  • Fork the project, so that you have your own copy of the project that you can manipulate (see that big 'Fork' button staring at ya on GitHub. Yes, click that one!)
  • Download your fork of the project (that you just created) using git's clone command
  • Add your quote to the file /doc/the_great_git_commit.txt (nothing offensive please - Ruby'ers are a delicate bunch!)
  • Commit your change to your local repository on your machine
  • Push your changes to your repository on GitHub using git's push command
  • Once your done you should see your commit when you look at your fork of the project on GitHub - congratulations!
  • Now you need to let other developers know that you have added the quote. To do this create a 'Pull Request' (via GitHub's web interface) which is like a little email that goes out to related developers on Github letting them know that you've made a change. When other developers receive your message they will then decide whether or not to pull your changes into their fork.
  • Hurrah! You've made your first commit! Kudos, karma and kode await you!

    1 Err... Competition kind of infers that there will be a prize. Don't be fooled by this!

0 comments | Filed Under: | Tags:

RubyIreland members: where are you based?

Posted by Aidan, Thu Aug 02 15:32:00 UTC 2007

I though it would be interesting to see what the geographical spread of Ruby Ireland members is. So let us know by taking the poll above. If I've missed your city/town/region/country, select other and enter the name in the text box.

0 comments | Filed Under: | Tags:

Handling connection failures with capistrano

Posted by Rob, Mon May 28 10:03:00 UTC 2007

We’ve had some problems with handling connection failures/timeouts with capistrano, because it currently (1.99.1) causes capistrano to exit from an exception trigged by Net::SSH. We wanted to handle this just like a command failure. I’ve not had time to form a proper patch for capistrano to submit upstream for this because of an impending deadline, but we’ve put a monkey patch in place (re-opening classes in ruby is just, well, awesome). I will of course write a proper patch for this once I’ve time, including being more specific about the Exceptions we wish to catch :)

You can use this to have capistrano treat a connection failure as a command failure:

module Capistrano
  class Configuration
    module Connections    
      # Hack, we return a fake connection which always reports closed.
      class FakeConnection
        def initialize(server)
          @server = server
        end

        def open_channel(&block)
          logger.important "could not open channel", @server if logger
          { :closed => true, :server => @server }
        end
      end

      class DefaultConnectionFactory
        def wrapped_connect_to(server)
          begin
            connection = capistrano_connect_to(server)
          rescue Exception
            FakeConnection.new(server)
          end
        end

        alias capistrano_connect_to connect_to
        alias connect_to wrapped_connect_to
      end
    end
end

0 comments | Filed Under: | Tags:

attr_history, almost perfect

Posted by Rob, Thu May 24 14:01:00 UTC 2007

I wanted to have an attr_history method that would behave like attr_accessor :foo but also keep a foo_history variable around so I can look back through the values the variable held during it’s life time.

Googling around and some help from Chris McGrath led me to write this:


module AttrHistory
  def attr_history(*syms)
    syms.each { |sym|
      class_eval(<<-EOS, __FILE__, __LINE__)
        attr_reader :#{sym}
        attr_reader :#{sym}_history

        def #{sym}=(value)
          @#{sym}_history ||= []
          if @#{sym}
            @#{sym}_history << @#{sym}.dup
            @#{sym}.replace(value)
          else
            @#{sym} = value
          end
        end

        def has_#{sym}_history?
          not @#{sym}_history.empty?
        end
      EOS
    }
  end
end

I was really pleased with the fact it worked, even that it was possible. I love the the shiney things you can do with *_eval and so on. There is just one problem, in that I can’t get it to behave quite like attr_accessor does. Because of the way Ruby parses code (explained at: http://www.rubycentral.com/book/language.html#UO) I end up having to use self.foo= when referring to the setter, because otherwise ruby thinks it’s a local variable. That’s a real shame in this instance, as I actually want the stuff to be available in an “DSL”-like environment similar to RSpec. As it is, the user must prefix the setters, self.foo= instead of simply foo=, which is a bit ugly. Oh well.

The code for using Spex (which I’ll release soon, certainly before the next meeting) ends up looking like:

klass :name => /^Xsd(AnyUri|Byte|HexBinary|String|Xmltext)$/ do
  self.name = 'String'
end

The ‘self.’ really bugs me. If anyone knows how to fix that, please let me know :)

Chris made a good suggestion that I just pass in a variable ‘k’ to the block so they can do k.name = which would resolve properly and not be so ugly. I think I’ll go with that for now, but I’d love to properly “fix it”. Not sure it’s possible though.

1 comment | Filed Under: | Tags:

Free Apress books

Posted by Aidan, Wed May 23 11:06:00 UTC 2007

Apress sent us some review copies of some of their recent ruby/rails books along with some Apress branded notepads.

The books are

  • Beginning Ruby, Cooper
  • Rails Solutions, Williams
  • Beginning Ruby on Rails E-commerce, Hellsten, Laine
  • Practical Ruby Gems, Berube

If you are interested in reviewing any of these books see the thread on the mailing list.

P.S. Thanks to Apress for sending these out.

0 comments | Filed Under: | Tags:

Dude, where's my String?

Posted by Rob, Tue May 22 20:10:00 UTC 2007

Ruby passes by reference, so I thought the following code would work just fine…


#!/usr/bin/ruby

class Filter
  @@filters = []

  def Filter.apply(string)
    # We don't actually use the Filter instance,
    # but don't worry about that.
    @@filters.each { |f| yield string }
  end

  def initialize
    @@filters << self
  end
end

Filter.new()
Filter.new()
Filter.new()
Filter.new()

Filter.apply('foo') { |string|
  string += 'h'
  puts string
}

So, after the last iteration ‘foohhhh’ should be printed. But no. Hmm. But Ruby passes by reference… So… Eh?

I asked on #ruby.ie on freenode and Chris McGrath suggested I try << instead of +=, it worked. The deal is that string += 'h' translates to string = string + 'h', which is fine, obvious even. The problem is that the + operator causes a copy of the combined string to be returned, and string adjusted to point to the new instance of String. I would have expected this to change string in all scopes, but it only affected the local scope. Subsequent filters did not see the new string.

<< differs in that it is a method on the string instance itself which does an in-place change. This allows the other filters to see the change. Subtle, and a little surprising to me. Nice to know the fix, thanks Chris :)

0 comments | Filed Under: | Tags:

Speed up Rails tests using an in-memory database

Posted by Olivier, Wed May 16 19:30:00 UTC 2007

One cheap solution to speed up your unit tests is to configure the test database to run in-memory. If your code isn’t database specific, you’ll simply have to follow Geoffrey Grosenbach’s instructions.

Other links you might want to check out on this topic:

0 comments | Filed Under: | Tags:

Welcome to RubyIreland.com

Posted by admin, Thu Apr 19 11:18:00 UTC 2007


Introduction

Welcome to RubyIreland.com, the website of the Ruby Ireland group. We share one passion: the Ruby programming language.

Participate

If Ruby interests you, even if you have no experience with it, do not hesitate to join us. To get in touch, you are encouraged to:

  1. participate on the mailing list
  2. chat on our irc channel: #ruby.ie on irc.freenode.net
  3. engage in our monthly meetings Ruby Tuesdays

Looking forward to meeting you soon!

0 comments | Filed Under: | Tags: