More JEdit macros for rails

I have been using JEdit more and more for my rails development, I have gone back and forth between it and Epsilon, however JEdit is starting to win out. I have upgraded to the latest pre version (4.3pre9).

I have modified a number of macros to do my bidding, and I dumped the Ruby Plugin because I kept running into things it did that I disliked, and it still seems a little buggy.

The best thing I did was update the ruby.xml Language mode to fully indent properly, like unindent end else rescue etc, and do this when you type those words. This is now possible with some new features in the 4.3pre9 series.

I also wrote a HAML language mode.

The plugins I currently use are...

• Buffer Selector
• BufferTabs
• Common Controls
• Console
• CssEditor
• CtagsSideKick
• ErrorList
• Highlight
• Info Viewer
• Latest Version
• Log Viewer
• MacroManager
• OpenIt
• Project Viewer
• QuickNotepad
• RecentBufferSwitcher
• SideKick
• SuperAbbrevs
• SwitchBuffer
• Tags
• TextTools
• XercesPlugin

The macros I have downloaded, modified or written to help with rails development are...

• Expand_Hash.bsh - My macro to expand # to #{} when in a string
• Go_to_Ruby_method_v0.5.bsh - Downloaded from the macromanager
• Open_Related_File.bsh - Downloaded from the macromanager
• Search_Ruby_documentation - A modified version of the one I downloaded, modified to use qri, and select from a list if multiple hits
• Run_Test_Case.bsh - My macro to run a specific test case or specification. Bind it to a key (I use Shift-F11), put the cursor in a test case or specification and type the shortcut, and that specific test case will run, the results going to the console plugin.
• Select_Super_Abbrevs.bsh - My macro to select from a list of matching SupperAbbrevs
• Find_Next_Selected.bsh - Downloaded from the macromanager

I have linked the ones I have written or modified so you can download them if you like.

Updated ruby.xml ruby language mode to handle case/when properly

A Tale of Three Modules

In which a weird problem with testing and simply_helpful leads us down the rabbit hole to appreciate the way Ruby modules are included into classes, and how the ordering of such events can be important.

(This is a long one folks; sorry 'bout that)

Ruby is so forgiving. As _why so eloquently stated, "Ruby loves me like Japanese Jesus!".

I've been working in Ruby for, I guess, over five years now, and so I've come to take this love for granted. Ruby lets me do whatever I want. Let's write some code, yeah?

1
2
3
4
5
6
7
8

class Monkey
  def name
    "Bonobo"
  end
end

mike = Monkey.new
mike.name

Yeah, real nice. Real sweet monkey there. But hang on, I just realised that I forgot to add a method! Aaaargh!!? I cannot has cheezeburger? :'(

No, wait. This is Ruby, remember? Ruby will forgive me, and let me add the method to the class any time I like!

1
2
3
4
5
6
7
8
9
10
11
12

class Monkey
  def eat(food)
    case food
    when Banana
      "yum"
    else
      throw :poop
    end
  end
end

mike.eat :some_rubbish

Phew! Thank you Ruby! You are so kind! So leniant! You never scold me with a hurtful recompile. Except...

.. it's not always that simple. Let's drive over to the car-keys-in-a-punch-bowl mixin party to see how Ruby can sometimes behave in ways less forgiving.

1
2
3
4
5
6
7
8
9

module A
end
module B
  include A
end
module C
  include B
end
C.ancestors # => [C, B, A]

The ancestors method shows every module - and I mean every module - that has been "mixed in" to the receiving class or module. So, in this case, we see that C has included B, and also has included A (because B included A). This is obvious when we define some methods in these modules:

1
2
3
4
5
6
7
8
9
10
11
12

module A
  def a; end
end
module B
  include A
  def b; end
end
module C
  include B
  def c; end
end
C.instance_methods # => ["a", "c", "b"]

All our methods are there. And, while Ruby smiles kindly down upon us, we can even add methods to those modules afterwards and have them available. Check it:

1
2
3
4

module A
  def new_a; end
end
C.instance_methods # => ["a", "new_a", "c", "b"]

But now watch this. We're going to build our three modules as before, except that we're going to include a new module into A after A has been included into B

1
2
3
4
5
6
7
8
9
10
11
12

module A
end
module B
  include A
end
module X
end
module A
  include X
end
B.ancestors
# => [B, A]

So you see, even though A now includes X (so we'd expect to see [B, A, X] as the ancestor list), it doesn't work. We can check the ancestors of module A to be sure that we really did include X in there:

1
2

A.ancestors
# => [A, X]

Yup, we did. And it gets even hairier. Methods defined on our "missing" module are not available to classes that include B.

1
2
3
4
5
6
7
8
9
10
11

module X
  def hello
    "dave"
  end
end
class D
  include B # which includes A, which we'd hope (but doesn't) include X
end
d = D.new
d.hello
# => NoMethodError: undefined method `hello' for #<D:0x4ec14>

So here's the deal - when Ruby included A into B, Ruby internally scans up through all the ancestors of A at that point, tying all of the modules found into the inheritance hierarchy of B to make the methods available to any instances.

However, when we later try and include X into A this has no effect on B, or anything that includes B either, because their inheritance hierarchy's are already determined. In other words, this inclusion is not dynamic. Oh, Ruby! Why hast thou forsaken us?

A bit of background

The reason I got stuck into this was due to an obscure testing problem that I came across with Rails. When testing views that used the simply_helpful plugin (now a "legacy plugin" since the features have been rolled into edge), I found that helper methods from that plugin were missing, despite working under script/server in any environment:

1
2
3
4
5
6
7
8

test_should_show_object(MonkeysControllerTest):
ActionView::TemplateError: undefined method `div_for' for #<#<Class:0x8360ec8>:0x82b8cb4>
    On line #1 of app/views/monkeys/show.rhtml

    1: <% div_for @monkey do %>
    2:   <b>Name:</b>
    3:   <%=h @monkey.name %>
    4: <% end %>

If we take a look at simply_helpful's init.rb, we can see that these modules are definitely being declared as helpers, so why aren't the methods available in the view?

Digging around using the breakpoint mechanism, I discovered the dynamically created class which views are evaluated in. This class is available as self at this point, so let's examine the modules which are included in it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

irb:001:0> self.class.ancestors
=> [#<Class:0x8346208>, #<Module:0x841e43c>, MonkeysHelper, 
     #<Module:0x126a5e0>, ApplicationHelper, #<Module:0x30ffe24>, 
     ActionView::Base, #<Module:0x1257cc4>, Engines::RailsExtensions::Templates::ActionView, 
     Authentication::Helper, ActionView::Helpers::UrlHelper, ActionView::Helpers::TextHelper, 
     ActionView::Helpers::TagHelper, ActionView::Helpers::ScriptaculousHelper,  
     ActionView::Helpers::PaginationHelper, ActionView::Helpers::NumberHelper,  
     ActionView::Helpers::JavaScriptHelper, ActionView::Helpers::PrototypeHelper,  
     ActionView::Helpers::JavaScriptMacrosHelper, ActionView::Helpers::FormTagHelper,  
     ActionView::Helpers::FormOptionsHelper, ActionView::Helpers::FormHelper,  
     ActionView::Helpers::DebugHelper, ActionView::Helpers::DateHelper,  
     ActionView::Helpers::CaptureHelper, ActionView::Helpers::CacheHelper,  
     ActionView::Helpers::BenchmarkHelper, ActionView::Helpers::AssetTagHelper,  
     ActionView::Helpers::ActiveRecordHelper, ActionView::Partials,  
     ActionView::Base::CompiledTemplates, ERB::Util, Object, Base64::Deprecated,  
     Base64, Kernel]

The key here is the 6th member of this rowdy band, the charming-yet-anonymously-named #<Module:0x30ffe24>. This module is actually created in ActionController::Base, as the master helper module:

1
2
3
4

irb:002:0>ActionController::Base.master_helper_module
=> #<Module:0x30ffe24>
irb:003:0> self.class.ancestors[5]
=> #<Module:0x30ffe24>

When you call helper within a controller (as is happening in simply_helpful's init.rb), you're actually mixing in methods and modules to this master helper module.

Furthermore, we can look at the ancestors of this module right here in the view breakpoint:

1
2

irb:004:0> self.class.ancestors[5].ancestors
=> [#<Module:0x30ffe24>, SimplyHelpful::RecordTagHelper, SimplyHelpful::RecordIdentificationHelper]

Huzzah! There are the simply_helpful modules that we're seemingly missing. But why aren't they listed in the ancestors of the self class available to the view? I think you see where we're going here.

Somehow, and only when testing, and this might not even apply to Edge Rails, the master helper module is being included into the view's anonymous class before the plugin gets loaded. Weird. Thankfully, there's a quick-if-dirty fix - we just need to make SURE that these modules get included into the main view class by adding this to the bottom of test/test_helper.rb:

1
2
3
4

class ActionView::Base
  include SimplyHelpful::RecordIdentificationHelper,
          SimplyHelpful::RecordTagHelper
end

Phew.

(Incidentally, this might be a similar problem to this)

(Also: Thanks to David Black for helping me figure this out!)

Managing database.yml with Capistrano 2.0

Jeremy Voorhis posted a really great Capistrano recipe for managing database.yml which dynamically creates a database.yml file in your shared directory on setup, and symlinks your app’s database.yml once it’s deployed. This is great if you don’t version control your database.yml file for security reasons or working with multiple developers.

changes the syntax for task callbacks and gets rid of the useful render method.  However, using ERb, Ruby's built-in templating system, isn't much more difficult than using the old render method.  Here is Jeremy's script updated for Capistrano 2.0 using ERb and the new namespaced callback syntax.

require 'erb'

before "deploy:setup", :db
after "deploy:update_code", "db:symlink" 

namespace :db do
  desc "Create database yaml in shared path" 
  task :default do
    db_config = ERB.new <<-eof base:><<:><<:><<:>

Until I get better syntax highlighting for this blog, check out the Pastie for the color version. For more info on whats new in Capistrano 2.0, check out Jamis’ preview and Geoff’s post. Also, props to Jamis for suggesting I use ERb directly.

Update: Updated code to use its own :db namespace instead of the default one. The database yaml file will be created by the default :db task, and the symlink will be created by the db:symlink task. Note how namespaces in Cap 2.0 allows us to have two symlink tasks, one in the deploy namespace and the other in db.

Managing database.yml with Capistrano 2.0

Jeremy Voorhis posted a really great Capistrano recipe for managing database.yml which dynamically creates a database.yml file in your shared directory on setup, and symlinks your app’s database.yml once it’s deployed. This is great if you don’t version control your database.yml file for security reasons or working with multiple developers.

changes the syntax for task callbacks and gets rid of the useful render method.  However, using ERb, Ruby's built-in templating system, isn't much more difficult than using the old render method.  Here is Jeremy's script updated for Capistrano 2.0 using ERb and the new namespaced callback syntax.

require 'erb'

before "deploy:setup", :db
after "deploy:update_code", "db:symlink" 

namespace :db do
  desc "Create database yaml in shared path" 
  task :default do
    db_config = ERB.new <<-eof base:><<:><<:><<:>

Until I get better syntax highlighting for this blog, check out the Pastie for the color version. For more info on whats new in Capistrano 2.0, check out Jamis’ preview and Geoff’s post. Also, props to Jamis for suggesting I use ERb directly.

Update: Updated code to use its own :db namespace instead of the default one. The database yaml file will be created by the default :db task, and the symlink will be created by the db:symlink task. Note how namespaces in Cap 2.0 allows us to have two symlink tasks, one in the deploy namespace and the other in db.

RailsConf 2007 Notes

All my notes from the RailsConf sessions are here. They don’t contain everything from the sessions I attended, just mostly things that were either new to me or were of some importance. O’Reilly put up most of the presentation slides on their site. Does anyone have notes on Uncle Bob’s Clean Code presentation? The one on the O’Reilly site is Java-specific. He didn’t do a Java talk at RailsConf did he?

If anyone was at Dante’s on Saturday night, and took pictures of the Exta Action Marching Band, I’d love to see them.

RailsConf 2007 Notes

All my notes from the RailsConf sessions are here. They don’t contain everything from the sessions I attended, just mostly things that were either new to me or were of some importance. O’Reilly put up most of the presentation slides on their site. Does anyone have notes on Uncle Bob’s Clean Code presentation? The one on the O’Reilly site is Java-specific. He didn’t do a Java talk at RailsConf did he?

If anyone was at Dante’s on Saturday night, and took pictures of the Exta Action Marching Band, I’d love to see them.

Giving You More Free Time

(and previously Hobo and the Sexy Migrations plugin) gave us automatic created\_at and updated\_at fields in our migrations, using the timestamps keyword.

How about bringing some of this sexiness to generators and taking it a step further? Well my patch was accepted and Rails now automatically adds timestamps to all generated migrations. So when you generate a model, scaffold, or resource, you will get timestamps for free. It is the equivalent of adding created\_at:datetime and updated\_at:datetime to your generators. So

script/generate model post title:string

script/generate model post title:string created\_at:datetime updated\_at:datetime

This is nothing significant but I hope it saves people a few keystrokes. If you don’t need timestamps you can always just delete the associated lines from your migration file and the fixtures. Just another example of Rails making it easier to do common things. This is currently only available in Edge Rails.

Giving You More Free Time

(and previously Hobo and the Sexy Migrations plugin) gave us automatic created\_at and updated\_at fields in our migrations, using the timestamps keyword.

How about bringing some of this sexiness to generators and taking it a step further? Well my patch was accepted and Rails now automatically adds timestamps to all generated migrations. So when you generate a model, scaffold, or resource, you will get timestamps for free. It is the equivalent of adding created\_at:datetime and updated\_at:datetime to your generators. So

script/generate model post title:string

script/generate model post title:string created\_at:datetime updated\_at:datetime

This is nothing significant but I hope it saves people a few keystrokes. If you don’t need timestamps you can always just delete the associated lines from your migration file and the fixtures. Just another example of Rails making it easier to do common things. This is currently only available in Edge Rails.

Quote of the day - DHH on designers

"Now there is dynamic real pieces of data. They don't have to use Lorem Ipsum to fill it up with crap."

DHH on designers using Rails view templates from the Scott Hanselman podcast

Nice podcast. Some great material in there.

Quote of the day - DHH on designers

"Now there is dynamic real pieces of data. They don't have to use Lorem Ipsum to fill it up with crap."

DHH on designers using Rails view templates from the Scott Hanselman podcast

Nice podcast. Some great material in there.

Quote of the day - DHH on designers

“Now there is dynamic real pieces of data. They don’t have to use Lorem Ipsum to fill it up with crap.”

DHH on designers using Rails view templates from the Scott Hanselman podcast

Nice podcast. Some great material in there.

Quote of the day - DHH on designers

"Now there is dynamic real pieces of data. They don't have to use Lorem Ipsum to fill it up with crap."

DHH on designers using Rails view templates from the Scott Hanselman podcast

Nice podcast. Some great material in there.