Session 1
Building Rails to Legacy Applications
Robert Treat
Of course greenfield applications are the easiest to use in Rails, but what about existing schema? How do you get rails to coexist and work successfully with Rails?
One option is to use your database to help fix the problem. Views can make legacy schema look far more rails-friendly. He demo'd that in PostgreSQL, you can create a rule that lets view write-backs work. Once you set these insert/update rules, you can treat your view as rails-friendly tables and thing should be far easier.
Using the database requires less knowledge of Ruby and Rails, and it does make things look like more what you expect to see from book examples. It does have the major drawback of having to support two schema.
The other option is to make rails smarter about how it That is, you can use ruby code to manipulate Active Record to match our data model. First off, edit your environment.rb to set
pluralize_table_names = false. Another adaptation to make is to tell your model to use a differently-named primary key. That way rails knows to look for foo_id rather than just id.
Slides at http://www.brighterlamp.org/
Session 2
I'm 200, You're 200
David Sklar
sklar@sklar.com
In Web 2.0, we make lots of assumptions about other services being up, and who we can depend on and who we can't. So, what is your app dependent on? What contingencies do you have if it's not there.
Dependency is needinging something that's not yours (eg. physical control, organizational control, intellectual control). This includes server dependencies (content, per-machine hardware and software, internal- and external-network calls, content created by others), code dependencies (who wrote it, how it works, who wrote the documentation, who knows where the documentation is wrong.), business dependencies (who supplies your feed, how many of your folks are in the National Guard, what are your copyright and patent risk, what's in your SLAs and are the penalties helpful?).
You can mitigate real-time dependencies with planned modes of degradation based on data freshness, application features and read/write data. Avoid live web service calls when possible, instead making calls offline, which lets you sanity check and cache the results. You can also create a local data store for when the remote service has blips. To degrade features gracefully segment your app into non-interdependent parts. Further, you can build code with the idea of having pluggable external dependencies - eg use map provider Y instead of G, or ad protocol G instead of X. APP, S3 and "ad html" are already starting to fill that need. Monitoring your dependencies to know when to switch needs to happen.
In summary, examine your dependencies and your risk exposure, and plan for and mitigate those risks accordingly.
Slides at http://www.sklar.com/
-Bill
Tags: OSCON06, Ruby on Rails
No comments:
Post a Comment