Semergence

• Dell Dimension 2400 Specs
  (tags: dell manual)

• Product: Amazon’s SimpleDB | High Scalability
  Large list of links related to Amazon SimpleDB
  (tags: simpledb database)

Coding Horror: Size Is The Enemy

Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly.

• YouTube - Demetri Martin - “The Jokes With Guitar”
  (tags: humor video)
• Character Entities » CSS, JavaScript and XHTML Explained
  convert html entities to unicode characters for javascript
  (tags: html)

• Home - Parleys - Parleys.com - a Belgian Java User Group initiative
  (tags: programming video)

So a future version of Rails will get Pluggable Controller Caching. That’s a good idea, and good on Rails for formalizing this extensibility. Better than monkey patching.

Looking at the implementation, though, leaves me cold. Let’s look at a code snippet:

 def read(name, options = nil)
    super
    @ether.get(name)
 end

With some commentary:

Invoking super for each method call ensures that the proper messages get logged for each action

Wow, way to trust your users! </sarcasm> Requiring a call to super is very bad practice. Any time you are relying on a client of your class to call something, you’re risking someone forgetting to make the call.

It’s better to use the Strategy Pattern. Here, you finalize the API method (here it is read) and provide an abstract method or your subclasses. Marking the method as final (which I don’t think you can do in Ruby, but I digress) ensures that a subclass can’t override your functionality, and the abstract internal method ensures that your client doesn’t have to call back to super.

Here’s how I’d fix it:

 def read(name, options = nil)
    # some logging and error handling
    read_internal(name, options)
 end

protected

def read_internal(name, options = nil)
  raise "Subclasses must implement this method"
end

Ta-da! No more forcing the user to call super, thus making your algorithm safe and well encapsulated.

• Flex and Ajax Comparison
  (tags: ajax flex)

• Emprise JavaScript Charts :: 100% Pure JavaScript Charts
  (tags: charts)

• Extended HTML Character Set
  (tags: html unicode)

UPDATE: Everything works now. Turns out I had a plugin installed that monkey patched the SQL Server Adapter. This plugin was from an older version of Rails, and the Rails 2.0 adapters now extend from AbstractAdapter. Fixing the parent class in my plugin monkey patch (to extend from AbstractAdapter) fixed this up and now I no longer get the error.

I just installed the SQL Server Adapter Gem from gems.rubyonrails.org for my new Rails 2.0 project:


gem install activerecord-sqlserver-adapter --source=http://gems.rubyonrails.org


When I attempt to use it, I receive this error message:

TypeError: superclass mismatch for class SQLServerAdapter
        from /var/lib/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:190
        from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
        from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from /home/sladd/development/workspace/DSES2/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require'
        from /home/sladd/development/workspace/DSES2/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in'

Any ideas? My database.yml looks like this:

development:
  adapter: sqlserver
  mode: odbc
  dsn: dses_rollup
  username: sa
  password:

Has anyone successfully installed the new SQL Server adapter as a gem into a Rails 2.0 project?

I’ve asked the Ruby on Rails Talk Google Group, so we’ll see if that turns up any help.