Ridiculous Thoughts

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

Happy Birthday to My Son, Arthur!

I've had this blog engine (Typo) set up for a couple of weeks now but I've been too busy working on some new initiatives in my life to actually post something. Now, I've had some success and I need to start posting in support of those.

What are the new initiatives? I've decided that I want to get mroe involved in two very different communities. By doing this, I'm hoping to grow myself in some specific ways.

The first community is the Ruby on Rails community. I've been a supporter of open source for a while. I'm one of the leading advocates and "go-to" guys on the subject at the Hanover. But in terms of actual participation, I've always just dabbled around the edges. Rails is so much fun though, that I've really made progress on my own site for the first time in years. I hope to leverage this enthusiasm to become a more involved participant.

My first success at that was being selected as a speaker at RailsConf 2006!. I'm going to be speaking about Domain Specific Languages as Rails Plugins. I'll describe more in a later post; but in short, I'll describe some implementation details and have a discussion about the value of DSL's as a unit of resuse.

The second community I want to get more involved in is my local community. I've announced my intention to run for a three year seat representing the Town of Holden on the Wachusett Regional School Committee. I've collected my signatures and I'll be turing them into the town office. Again, I'll be writing extensively on this in the future, why I'm running and what I would like to accomplish.

It sounds like a lot, but I've got this phobia against being bored!

Steve

Happy St. Patricks Day