Ridiculous Thoughts

According to this: http://blog.codefront.net/2008/04/27/living-on-the-edge-of-rails-18/ the functionality provided by the MySQL Bigint has finally been integrated into the recently released Rails 2.1, and I’ve gotten reports from a couple of users on this, though I haven’t tried it myself yet.

I’ll continue to support the plugin for older versions of Rails, but I won’t be doing anything other than bugfixes. I may also move the plugin to git hub with the rest of my projects in a couple of weeks. If that happens I’ll announce it here.

Finally, thanks to Mike Mangino of http://www.elevatedrails.com for mentioning the plugin in his RailsConf 2008 talk on Facebook apps. You can see the details, and download the slides, of the talk here: http://en.oreilly.com/rails2008/public/schedule/detail/1829.

Steve

There seems to have been a lot of interest in my plugin for enabling MySQL bigints in Rails migrations.

I got a few questions and two patches from Tomasz Wegrzanowski of Trampoline Systems. I’ve reviewed and incorporated these patches in this release. Many thanks for submitting the patches.

The changes in this release are as follows.

1. bigint primary keys are now signed. This complies with the rails standards and allows the next item to work. See below for suggested next steps on this.
2. bigint foreign keys now work. The signed/unsigned incompatibility fixed above was causing problems.
3. The plugin is now transparent to other databases. It has been tested with Oracle and Postgres. I’m interested in hearing if there are issues with the other databases.

I believe that there are other plugins that enable unsigned integer support. If somebody wants to make this plugin compatible with one of those plugins, I’ll gladly incorporate the changes.

Feedback is always welcome below, Steve

I know that everybody using Rails has a thorough and robust testing suite to go with their app.

When I went to implement OpenId in my app. I used the open_id_authentication plugin and this excellent tutorial.

Testing of my controllers became an issue though. I didn’t want to set up OpenId’s for each of my test users. As a solution I created the following mock object.

Take this code and put it into a file called open_id_authentication_mock.rb.

module OpenIdAuthentication 

  EXTENSION_FIELDS = {'email' => 'user@somedomain.com',
                      'nickname' => 'cool_user',
                      'country' => 'US',
                      'postcode' => '12345',
                      'fullname' => 'Cool User',
                      'dob' => '1970-04-01',
                      'language' => 'en',
                      'timezone' => 'America/New_York'}     

  protected

    def authenticate_with_open_id(identity_url = params[:openid_url], fields = {}) #:doc:
      identity_url = normalize_url(identity_url)
      if User.find_by_openid_url(identity_url) || identity_url.include?('good')
        # Don't process registration fields unless it is requested.
        unless identity_url.include?('blank') || (fields[:required].nil? && fields[:optional].nil?)
          extension_response_fields = {}
          # fields[:required].each do |field|
          #   extension_response_fields[field.to_s] = EXTENSION_FIELDS[field.to_s]
          # end  
          fields[:optional].each do |field|
            extension_response_fields[field.to_s] = EXTENSION_FIELDS[field.to_s]
          end
        end

        yield Result[:successful], identity_url , extension_response_fields
      else
        logger.info "OpenID authentication failed: #{identity_url}" 
        yield Result[:failed], identity_url, nil
      end
    end

  private

    def add_simple_registration_fields(open_id_response, fields)
      open_id_response.add_extension_arg('sreg', 'required', [ fields[:required] ].flatten * ',') if fields[:required]
      open_id_response.add_extension_arg('sreg', 'optional', [ fields[:optional] ].flatten * ',') if fields[:optional]
    end
end

Take this code and put it into a file called open_id_authentication_mock.rb. This mock is not a wholesale replacement for open_id_authentication.rb in the plugin. That file has the Result class and other code that is needed in the functional tests. I don’t want to have to maintain that code as it evolves in the future.

Add the following line to your test_helper.rb

load File.join(RAILS_ROOT,'test', 'mocks', 'test', 'open_id_authentication_mock.rb')

This will cause the mock’s methods to be loaded and to replace those in the plugin.

This mock does a little more than just stub out the plugin’s functionality. It will return a successful result if the requested openid_url is in the database, or if the url has the word ‘good’ in any part of it. This allows you to structure positive and negative tests through the contents of the url.

The mock will also return a set of static results if simple registration fields are requested. This met my needs, I’ll be happy to post a change to this if somebody wants to make this part more robust.

I hope all of this is clear and helpful. Comment below with any suggestions.

Steve

I am putting the finishing touches on a web site to provide some tools and material for table top role playing games.

I am leaning towards only supporting login through OpenID.

Why, you ask? What about users that don’t have OpenIds?

That’s a good question. DHH spelled out the advantages of OpenId here. This is why I’m supporting. I could choose to offer traditional registration with a userid and password, managed by me. From my perspective, that’s more code that I have to maintain and it undoes many of the advantages I was supposed to gain by offering OpenId.

From a users perspective, if they don’t have an OpenId they will have to fill out a registration form on my site. There isn’t much additional effort to have them to get an OpenId which they can use on many sites.

In fact I can use myopenid’s affliate site to make it even easier for them.

By only supporting OpenId everybody wins. I don’t have to manage passwords and logins and related code and users, if they have to signup, get a shiney new OpenID.

Comment below and let me know where I’m wrong?

Steve

I received some feedback that edge Rails broke some things in the mysql_bigint plugin. I've checked in a new version that works correctly with edge rails. Thanks to Jamie Orchard-Hayes for a patch that fixed a few of these issues!

As always, just contact with additional issues.

Now, I've just got to make some time to repackage all of this for resubmission to the core team as I promised back in August...

Steve

Thanks to everybody who attended my talk on DSL's yesterday at RailsConf. I had a lot of positive feedback and I thoroughly enjoyed giving it. A couple of great points came up in the Q&A session, that I will be addressing here over the next few of days.

1. Determining when you need a full fledged DSL vs. a library of classes and methods. In particular one person pointed out that deck.shuffle in my example was probably fine.

2. Is there (or should there be) a distinction between XML, or other mark-up, based DSLs and executable DSLs like the ones I was discussing.

I've posted the slides for my talk here. If you have feedback, positive or negative, on the talk or ideas on the above questions, please comment below!

Steve

OK, I've got two plugins ready to go in support of my RailsConf 2006 Talk. I've been looking for some information describing the right way to actually publish the plugin so that people can find it with the usual install command.

ruby script/plugin install mysql_bigint

So, I didn't find anything that explained it, but I've poked around a bit and I think I've figured it out. I'm going to document the process that I use here; hopefully that will help others in the future.

Preparing your plugin

Before you publish your plugin you need to be sure that it is ready to publish. Like anything that you put out for public consumption, people will make judgments about you based on what they see there -- so put your best foot forward.

1. Nice Clean Code. Make sure that your code is clean. It should be appropriately commented, reasonable filenames, etc. Lots of people look at plugin code for ideas on their own plugins or to look for problems or potential improvements. Make this as easy as possible.

2. Tests Execute. Make sure that your tests execute correctly, preferable on a clean install of Rails. Nothing will turn people off to a plugin faster than tests that don't execute.

3. README In Place. Use RDoc formatting for your README file and make sure that it adequately documents your plugin. At a minimum it should include the following.

   • Installation instructions: including direct from your repository and by plugin name.
   • Usage instructions: detailed documentation on how to use the plugin.
   • Feedback instruction: how can users get in touch with you to report bugs, submit patches, or just comment.

4. LICENSE File In Place. Include a copy of the license for your plugin. Most Rails things use the MIT license, but you can use whatever you want.

5. Create a META.yml file to assist the rails scripts, repositories, and other tools in working with your plugin. This is relatively new, but will be important in the future.

6. Enable public access to your subversion repository. You need to have public read access established to your subversion repository. I use the repository that is available as part of my Dream Host hosting package. RubyForge and Source Forge are other options for repository hosting. Note that you probably don't want to use the common trunk, tags and branches directories in you repository. This is because the command "script/plugin install http://svn.plug.net/coolplugin/trunk" will install a plugin called trunk rather than coolplugin. If you plan to create more than one plugin, create a plugins directory instead of trunk. Then you can place all of your plugins under there which will make things easier in the next step.

Registering the Plugin

This is the final step to releasing your plugin, registering it so that people can find it.

Start by going to http://wiki.rubyonrails.org/rails/pages/Plugins and editing the page, to add your plugin to the list there. Follow the guidelines established by plugins in the existing list. If you have existing documentation on the web, perhaps generated by using RDoc on your README file, you can use the homepage: section to reference that. The important piece is to set the svn: line to point to your repository so that people know where to go to get your plugin.

The script/plugin discover command scrapes this page to get the list of known repositories. If you used /plugins/ instead of /trunk/ in your repository your repository will be picked up. This will allow people to add your repository to their list of sources and add your plugin by name, like this:

script/plugin install cool_plugin

While the Rails wiki seems to be the most important place to register your plugin, you should also register your plugin at Agile Web Development. They have a growing database of plugins that is searchable and easy to use.

Conclusion

That's it. I hope that this is helpful to everybody. If you have suggestions or improvements to this process comment below!

Steve

I've updated the abstract for my RailsConf talk. There's a talk immediately after mine that is going to focus on the details of implementing a Domain Specific Language in Ruby. Therefore, I'm going to talk at a little higher level about designing and using a DSL. Leave me some feedback if you have thoughts on this.

Domain Specific Languages as Rails Plugins

“Reuse is Vastly Overrated”—DHH 1/21/2006.

Reuse of business logic between applications is difficult. By definition business logic is what distinguishes one business from another and one application from another. However, DSL’s might provide a reusable context to describe business rules within a domain. The DSL provides a middle ground between impractical or constraining reuse and laborious coding from scratch.

In this talk we will look at the usage of some common Rails DSLs and the design of a new DSL for managing randomness in hobby/adventure game apps. We will end with some discussion of packing DSLs as plugins, pitfalls of DSLs and common domains in Rails that need DSL plugins.

Steve

Only 10 More Days...

I am starting to count down to RailsConf 2006 and feeling a little overwhelmed by all that has to get done before the conference starts.

Most of the material I need for my talk is ready to go, but I'm still hoping to have my Game DSL ready before the conference starts so that people can see it. This has all be complicated by the untimely death of my laptop while Ubuntu over the weekend.

I'm looking forward to meeting everybody and generally having a good time. I'll be posting an outline here for my talk, so stop back by if you want to see, or provide feedback before the talk begins.

Steve

In the application I'm working on now I have a few tables with some largely static data, or a lot of initial data that needs to be loaded when the table is first created from the Rails migration.

I want to load the same data into my development, test and production environments so DRY tells me not to manually insert the data in the migration and have the data in fixtures for testing. Additionally there are 100's of rows so I really don't want to add the data one item at a time in the migration.

Can we tell a migration to load the fixtures after it has created the tables and indexes?

It took some digging, but yes you can! Here is the code.

  Fixtures.create_fixtures('test/fixtures', %w{archetypes tile_types tiles})

The first argument is the directory where the fixtures can be found and the second is an array of fixtures to be loaded. This will load the fixtures into the environment where the fixture is being run. As usual Rails will figure out YAML vs. csv fixtures for you.

Hope this helps! Steve