sudo gem install SyslogLogger

# edit /etc/rsyslog.conf

!logtarget
*.*  /var/log/logtarget/production.log

# edit config/environments/production.rb

config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new('logtarget')

References:

• syslog overview
• Logging rails to syslog with sysloglogger
• SyslogLogger

I’d like to serialize it all. The first approach

render  ml => workout.to_xml(:include => :laps)

Cool, we get workout data with laps, but no points.

Reading through the to_xml implementation it makes sense that you can only get to first level associations. For my purposes, I just wanted to avoid repeating my data model in my rxml files.

Here’s what I came up with.

module Builder
  class XmlMarkup
    def add_record!(record,options = {})
      options = {:builder => self,:skip_instruct => true}.merge!(options)
      ActiveRecord::XmlSerializer.new(record, options).serialize
    end

    def add_record_attributes!(record)
      record.attribute_names.each do|name|
        attr = ActiveRecord::XmlSerializer::Attribute.new(name,record)
        tag!( attr.name, attr.value.to_s, attr.decorations )
      end
    end
  end
end

Now, in my rxml view I can write this.

xml.instruct!(  ml, :version=>"1.0", :encoding=>"UTF-8" )
xml.workout do
  xml.add_record_attributes!(@workout)
  xml.laps do
    @workout.laps.each do|lap|
      xml.add_record!(lap, :include => :points)
    end
  end
end

Here’s some sample code I used to remove layouts from all my integration and functional tests.

class ApplicationController

  # remove layout to improve test time
  def render_with_layout_disabled(*args)
    args << {:layout => false} # force layout to always be false
    render_without_layout_disabled(*args)
  end

  alias_method_chain :render, :layout_disabled
end

Tonight I’ve found that I get about 188% increase in integration test time and about 248% increase in functional test time by removing the layout.

Disabling the layout was pretty easy using alias_method_chain. My next question is does doing this break anything or make the test less meaningful? My thinking is no. Tests should be small in what they test. We can have a test to specifically test the layout of our application. Repeatedly testing the layout is redundant. So, making this change to my application for my tests seems like a good move.

The list of improvements include:

* Scalable Map – resizes with the browser width/height
* Back Button Support – after searching clicking the back button will return to the previous state
* Caching – I use a lot more caching now so performance should be much better

Updates: (things I forgot to mention)
* Entrance Level data
* Search Certainty raiting stars
* Nearly Validating markup all but the MS specific namespace validate

And of course, who can ignore Rails? The backlash from heavyweight web frameworks has been significant. We now know that EJB 1 & 2 were based on an entirely flawed set of use cases. Because of the damage this (still slowly dawning) realization has wrought to Sun’s reputation, it’s hard to know whether EJB3, which probably should have been called something else to disassociate it with the failures of its predecessors, will succeed, despite the fact that EJB3 is like a breath of fresh air. You look at the code and it makes sense; no bizzarre and obscure interfaces and concepts to puzzle over while thinking, “I wonder why I have to do this? Well, these guys are clearly smarter than I am.” (I tried to understand EJB1, but when I first heard that entity beans didn’t actually work, my brain refused to let me invest any more time, which turned out to be the right choice). As a result of all this, someone said “hey, all I want to do is create a database and use it from the web. Why should I do all that work?” As it turns out, such activities seem to be about 90% of all we ever do in “Enterprise” programming, and EJB 1/2 were solving an entirely different problem, and making the 90% incredibly difficult in the process. Thus, the Rails approach of “just connect the database to the web.”

This one reflects my current experiences, in learning zope, using php, and now rails

My own experience in web frameworks was with Zope. In an interesting parallel with EJB3, Zope is now on version 3 which is a from-the-ground-up redesign, and everything I’ve seen of it indicates that, like EJB3, it represents a great deal of rethinking of the problem. I’ve been bumping up against the problem of “but all I want to do is connect a database to the web” in Zope2 for several years now. Oh, it’s definitely something you can do, but unfortunately it’s past the knee of the “Z-shaped learning curve,” and is only trivial if you live and breathe Zope every day. Don’t get me wrong; Zope is an excellent system and incredibly powerful, and Zope3 may be much easier, but I’m out of steam. I have realized that on my site, I really just want to do a collection of simple things, and I don’t want to relearn Zope every time I want to accomplish something. So — sorry, Jim (Fulton, not Kirk) — I’m going to find something drop-dead simple to solve my drop-dead simple problems. Probably PHP5, which actually includes most of Java and C++ syntax, amazingly enough, and I wonder if that isn’t what made IBM adopt it.

Update:
I wanted to add, I don’t really see the point in arguing for or against python/ruby. I think they are pretty comparable languages; So, it really comes down to preference and task. Right now there is rails, so I’m using ruby. What I like about ruby in this respect, is it has block structure just like Javascript, but really something like PHP is even better in this respect because it uses the same kind of block structure (e.g. {} vs begin end).