Relational Modeling Framework - Nathan Sobo

Intro

Video of interaction model that drove thinking

Grockit - it is all common - pushing events collaboratively. This is harder than asynchronous model.

Client needs to respond to to the server in an asynchrounous manner.

All rendering occurs in the browser modifying the DOM as needed.

How do you model this? With a relational model. They build a relational model in the browser.

It is good because you don't need pointers, you just use foreign keys and scalar values. Really flat, really easy to serialize and move across the wire.

However, it is difficult to work with. Things are indexed by id, etc.

Demo

Lots of live coding. See the video (up soon) at GoGaRuCo.com

New project is "June" - based on Unison, but Unison is being deprecated.

The most primitive object in June is the set

System for working things in the browser.

It behaves as you would expect any relational model. Support add/remove etc. Example has User, Pet, and Species. Updating Tuples. Testing with Screwunit

Can have events on sets (i.e. on_insert, on_remove, on_update )

Events have other stateful information passed through a hash in changed attributes for each event.

on_update(function(model, changed_attributes) {
  if (changed_attributes.name) {
    print(changed_attributes.name.old_value + " was renamed to " + changed_attibutes.name.new_vaue );
  }
});

Also has join model:

var stephs_species = stephs_pets.join(Species).on(Pet.species_id.eq(Species.id)).project(Species);

Also has has_many, and others will be implemented too.

Nathan can live code very well. He is writing a lot of really cool code and talking about it at the same time. Like this:

relates_to_many("pet_species", function() {
  return this.pets_relation
    .join(Species).on(Pet.species_id.eq(Species.id))
    .project(Species);
});

Can also remotely access the entire server-side database (don't worry, there will be a security model):

var remote = June.remote("/domain");

However, you can't pull the whole database down to the browser. So, you can get a subset of the data that the client requests.

Security: Only give the browser access to things the user is authorized to see. Every Tuple acts as it's own database.

Objects that have specific permissions only receive tuples and events that pertain to them.

Arduino is Rails for hardware hacking - Greg Borenstein

Intro

Greg Borenstein

Obligatory safety talk

Electrical engineering is for experts!

Physical computing is for everyone!

• Artists!
• Idealists - Fab labs in India
• Hackers - Cockroach driven robot. Cockroach runs, spins ball, drives robot

Physical computing is programming for stuff read inputs from your surroundings and modify them based on logic

[Arduino](http://www.arduino.cc/)

Open source hardware and software project that makes physical computing really easy

• Program via USB
• power via 9v
• 14 digital i/o pins
• AVR microcontroller
• 6 analog i/o pins

Most of the API is for sensing and controlling the physical world.

HELLO WORLD - make an LED blink on and off

class HelloWorld < ArduinoSketch
  output_pin 13, :as => led

  def loop
    led.blink(500)
  end
end

RAD is Ruby Arduino Development

In a hardware demo, everyone is required to go "Oooooooooooh" (even if it doesn't work)

rad command generates a project directories

You can buy an Arduino board for ~$30 from Make or a Dorkboard for ~$6

Bell rings as a post commit-hook for git

.git/hooks/post-commit require 'bell.rb' Bell.ring exit 0

Demo Reason + Archeopteryx playing a drum

• Play midi via Reason
• Playing same midi through arduino, a motor, a drumstick and a snare drum

Archeopteryx: code describes patterns with channels, and randomness.

Reason sends midi to Tascam midi device, Tascam sends to Arduino, which turns solenoid attached to drumstick.

Physical computing is for everyone, if you've ever wanted to make your code interact with the world, now you can.

Q: Can you use this to play rockband?
A: Yes. You can use a photoresistor to detect notes coming across the line.

Q: Are there latency problems with midi playback?
A: The clockspeed of the arduino is fast enough to keep up with the playback.

Lots of nice prizes. Some people weren't there. They lost!

Zach won an iPhone!

Webrat: Rails Acceptance Testing Evolved - Bryan Helmkamp

Intro

Bryan Helmkamp ( more about him ). He works at WePlay. He is the co-author of "The RSpec Book"

Links:

• bit.ly/wbrt-ggrc
• Twitter: @brynary #webrat
• brynary.com

Audience Poll: How many people know and use webrat (50%+ using, 25% using)

Webrat is an awesome tool everyone should use, but it doesn't run on the iPhone, not written in Scala, and there is no Pr0n.

Beer Disclaimer

If you have questions that aren't answered, find him for a beer after the conference

API

Writing a rails integration test how we test websites, traditional methods are brittle and tedious.

Webrat code is more readable than traditionally written integration tests

It behaves like a browser:

• "visit" method - the equivalent typing in a URL to the browser.
• "click_link" - like clicking a link (duh)
• "fill_in" - fills in a field
• "assert_contain" - perform assertions

Uses nokogiri to parse the response HTML and run assertions on it.

How to use it?

#config/environment.rb
config.gem "webrat", :version => ">= 0.4.4"

#test/test_helper.rb
Webrat.configure do |config|
  config.mode = :rails
end

Webrat's Core API

• visit
• click_link
• fill_in
• check and uncheck
• choose
• select
• attach_file
• click_button

Webrat works with RSpec, Shoulda and Cucumber Webrat and cucumber do not have to be used together. You can use Webrat with whatever testing framework you want to use. Webrat also works with Rails, Sinatra and Merb.

Webrat can do input matching to labels. Webrat encourages you to put good labels on your form fields.

Webrat verifies HTTP Status codes for you behind the scenes.

• Automatically makes sure you don't get 500 HTTP server errors.
• Also ensures that fields exist

Verify HTML content

response.should contain("Hello, world!")
response.should have_selector("li", :class => "new", :count => 2)
response.should_not have_xpath(".//meta[@name='robots']")


response.should have_selector("#album li:nth-child(3)") do |li|
  li.should have_selector("img", :src => photo_path(@photo))
  li.should contain("Vacation Photo")
end

When things go wrong Webrat uses '''save_and_open_page''' and writes out the current response body and brings up the page.

Webrat Adapters

• Rails
• Merb
• Sinatra
• Selenium
• Mechanize (can use to scrape other websites i.e. google)

Evil plot is to write adapters so he can test everything at once.

Selenium

Webrat started as an alternative to selenium, but it now includes a selenium adapter. Bryan suggests not using selenium whenever possible. You should start with the traditional webrat mode and not the selenium mode. Unfortunately, it's the only way to test a real browser, such as javascript.

# selenium doesn't support transactional fixtures
class ActiveSupport::TestCase
  #...
  self.use_transactional_fixtures = false
  #...
end

setup do |session|
  session_host "localhost:3000"
end


Webrat.configure do |config|
  config.mode = :selenium
end

Webrat talks to the selenium client gem to talk to the Selenium RC server which then drives a browser (IE, safari, and/or firefox).

Sometimes you'll need to an action differently when a browser is actually present. These commands let you write code for a specific context: webrat.simulate - traditional webrat simulation mode webrate.automate - drive a real browser

# is not run in normal webrat mode
  webrat.automate do
end

# is not run in selenium webrat mode
webrat.simulate do
  ...
end

The 'selenium' object is exposed from the selenium client gem. You can use it directly within your tests.

Automating a real web browser is SLOW

One more thing...

rack::test - gives you a quick way to generate requests to any rack enabled application Makes it easy to test complicated routing of requests through rack apps. For example, a rails metal that routes to a sinatra app.

Rack::Test API

get post, put, delete head request ...

Questions

• Q: How do you deal with links with the same names?
  

• A: Webrat has a method called "within" which allows you to scope your selectors to be inside an HTML tag.

• Q: Does it have support for checking HTML validity?
  

• A: No, that is outside of the scope of core webrat. However, we have talked about the ability to capture

• Q: Where does the output of save_and_open_page go?
  

• A: Into Rails' tmp directory

• Q: Selenium client has some interesting screen grab is that being exposed?
  

• A: Webrat has that in Selenium mode now.

Using Shoes to Have Fun - Tim Elliott

Intro

He rode his bicycle from Chico. He works at Trevidia, and is a Rails developer

Links:

• The Shoes website - To get and learn about Shoes
  
• The Shoe Box - A collection of user apps written in Shoes
  
• Nobody Knows Shoes (comic book)

Shoes

The highlight is the fun that he has found by programming in Shoes. This was originally a talk about iPhone, but he wanted to put more fun into it.

why the lucky stiff wrote a comic about Shoes. In 2003, why wrote a blog post called "The Little Coder's Predicament". It is a call to arms for all programmers, beginning and expert, to have more fun.

Such as the old Commodore 64 program, written in BASIC: 10 PRINT "TIM RULES" 20 GOTO 10

You could do really fun things really easily, even if you didn't own a C64!

However, Ruby is harder for kids (especially on windows) to get started with:

• Ruby one click installer
• RubyGems

• Sqlite

  rails cat_app script/generate etc...

That lets you "make a cat", but not too exciting for kids. Involves too many other languages (HTML, CSS, Javascript). They want cats to jump around the screen and do cool stuff.

Shoes

• One installer
• draw and animate

Shoes is not a Gem

Couldn't use a standard ruby distro, had to install a new one, but this is because shoes is not geared towards developers, but people who are installing for the first time.

Shoes is a GUI toolkit that embeds Ruby. It includes a packager and a few gems.

Very flexible but understandable layout engine.

Example of Shoes: Shoes.app do stack do para 'wanna click a button?' button('sure') { alert 'woot' } end end

"Stacks" and "Flows". You can do simple or complex layouts using these two principles.

Flows act like left floated html elements.

Everything is wrapped in a Shoes.app block, and does a class eval.

You can put your own classes outside the app block and use them inside, but there's a gotcha. Once you use classes from outside the app block, the class eval doesn't work, but there is a workaround.

Shoes keeps an array in the form of an in-memory stack that remembers everything. So when you start putting controls in, Shoes knows where to put them. it is always tracking which container you are in, so you can get an idea of where everything shows up.

Also watch out for long-running tasks at the OS level, this can kill the app performance (due to green threads).

Demo of Shoes:

Drawing some ovals

Shoes online manual

Shoes itself comes with online documentation when you install it, which has a nice search tool and examples.

Shoes is also good for rapid prototyping, such as desktop apps or iPhone apps. The advantage is that you get to do it all in Ruby.

Sharing with friends

It is easy to share. If you are running shoes, you can use a packager that comes with it to create an executable installer which runs on Windows, Linux, or OSX.

It will be small, a few meg, and still under ten even if you use video.

You can use ruby-debug to interactively debug.

`Shoes.setup do gem 'ruby-debug' end

require 'ruby-debug'

Shoes.app do debugger end ` Shoes has a gem installer gui and will install gems includes in the Shoes setup block, this gets included in the package.

It includes native HTTP download libraries for all platforms, because ruby http lib is slow and for other issues.

In the git distro, it includes "bloopsiphone" which lets you create Atari-like sounds and noises, and it also has an easy API.

Be creative and have fun, make robot apps, make the robots eat each other. This is a great way to connect your passion with non-programmers, because everyone likes robots eating other robots.

Q: You mentioned development for the iPhone can you go into more detail? A: You can't run ruby on the iPhone yet but its still useful for prototyping.

For the second day of GoGaRuCo, my fellow Pivots David Stevenson, Zach Brock, and Ryan Dy are helping out with the live-blogging duties (Tom Sawyer says live blogging is SOO FUN!).

We are ALL writing the blog posts collaboratively, using the Coda editor which is based on the SubEthaEngine:

Conference Organizers Extraordinaire!

Intro

Works for Engineyard. Getting to Rails 2.3, will be at RailsConf. Engineyard is hiring.

Does Ruby Scale?

Yes. So does LOLCODE.

Scaling != Speed

Is Ruby Fast?

Rub/Jruby around 23-30 in the Great Language Shootout.

In reality, Ruby is fast enough for the vast majority of use cases. Odds are slow code is your fault.

How do you write fast code?

Step 1. Write Slow Code

Don't worry about performance the first time around. Odds are you don't know what will be slow. Just write the codebase

Step 2. Use Science

Don't stab in the dark. Use the scientific method. It is the most important tool science gives us, we should use it.

Scientific Method

Step 1. Define the Question (It needs to be specific)

Step 2. Gather Information

Step 3. Form a Hypothesis

Step 4. Perform experiment and collect data

Step 5. Analyze interpret

Step 6. Publish results and retest

Scientific Method reworded for code

1. Why is my code so slow?
2. Where is the time/memory being spent?
3. Why is the chunk of code slow / a memory hog?
4. Change code. Collect before/after metrics
5. Compare metrics
6. Deploy

Defining the Question

"My app feels slow" is not specific enough.

"Why is action X taking more than 100ms on average?" is a better question.

"Why is 60% of the merb dispatch cycle in content negotiation?" is a good one too.

"Why are my Mongrel processes growing to 300MB of memory?" (Gets laughs)

Our Scenario and Question

QUESTION: "Is route generation as fast in rack-router as it is in Merb and Rails?"

Gather Information

Tools: Rbench, ruby-prof/kcachegrind, EXPLAIN ANALYZE, log files, New Relic/Fiveruns, memory_usage_logger, bleak_house

He shows some data from the benchmarks, comparing rack-router and merb routing, and rails routing. This answers the question that Merb route generation is NOT as fast.

So, rephrase the question. How do you make it fast? Benchmarks aren't good for this. He used Rubyprof which provides a lot of ways to set up test and output data. He uses the "call graph" output, which he can open in kcachegrind. It is available via macports.

He then shows the graphical output of kcachegring. Top left shows the methods which take longest, lower left is call stack, showing aggregate ('incl') and individual time ('self') spent in methods.

Sort by "self", and it turns out Array::map is the one taking most individual time. Most of the calls occur in Rack::Router::Condition::generate_from_segments. This is a good place to look and spend time trying to speed up.

Hypothesis

Most of this logic can be removed and moved somewhere else. You can check Git logs to see how he did it.

Perform Experiment, collect data, analyze, interpret

Rewrote the code, it was faster.

Publish and retest

Twitter and let everyone know about it.

More Examples

Shows more kcachegrind examples. Shows how it can show source code annotated with performance data.

Remember - you don't have to go through all the steps or feel bad because you didn't in the past, just keep them in mind to figure out quicker where things are happening.

The Garbage Collector

Conservative mark and sweep. Every time it runs, none of your ruby gets executed. The goal is to get the garbage collector to run as little as possible.

The way object allocation works is ruby boots and gives you 8 meg of memory. When your code runs, it allocates memory. If it can't, it will run the garbage collector.

Avoid creating unnecessary objects

Don't need to do this:

records.dup.values # records is a Hash

Use DataMapper's identity map. It will not create a new object if it doesn't need to. This will drastically reduce the number of objects created.

Beware of modifying Large Strings

Don't do parse time operations

For example, slash at end of line to split up code

Beware of closures

Be lazy

"No code is faster than no code" - merb motto:

• Cookie handling
• memoize in the reader
• Procs as method arguments (instead of just arguments)

Lambdas

Sexy, but slow. Sometimes you need them, but keep in mind they are more expensive than method dispatch.

def my_method
  yield
end

vs.

def my_method(&block)
  yield
end

"Compiling" your code

• Iterating is slow
• Ruby's AST is fast

class_eval For The Win.

Intro

Josh Susser does the intro. He thought it would be interesting to get authors of popular frameworks together.

Speakers

• Tim Elliott - Shoes
• Greg Borenstein - RAD
• Jay Phillips - Adhearsion
• Blake Mizerany - Sinatra
• Yehuda Katz - Merb /Rails
• Josh Peek - Rails

Bios

Tim: Been a contributor to shoes since december. Kind of scary to put code out there, and speak publicly. One thing about Shoes is that people are very receptive. It is fun, a framework/toolkit for creating Gui apps. Written mostly in C, it embeds ruby. Lowers the barrier to programming by making it super easy to make fun apps. Shapes, animation, music. It is NOT an MVC framework, it is more like writing a script. You often just need one file, it is straightforward. It is written to be compiled and shared with your friends. Unlike a web app, your Ruby code actually runs on other peoples machines. That makes it more unpredictable due to library, OS and environment differences, which is a challenge to Shoes. Since ruby usually runs on Unix, there are challenges to running it on windows. It has a main loop, so since ruby uses green threads, if the OS does disk access, it can make your app pause, even if you are using ruby threads in your app.

Greg: RAD - Ruby Arduino Development - an open source hardware platform for hardware hacking. Can easily program physical devices, sensors, actuators, things that jump and blink and do things. It is based off the 'processing' project, which is in C++, a predecessor of Shoes. He wanted to to it in ruby, though, so it would be eash for new people without a lot of hardware experience to get started. Ruby is great for that. Unlike other frameworks, you have things above and below you in the stack. There are contributors who are old-school hardware guys who submit complex C code against a shoebox full of obscure hardware, so that is a difference as well. Hard to test, if things blink and beep in the right order, then the tests are passing. He wants to get experience about how to manage complexity, especially when other people add things to it.

Jay Phillips: Adhearsion. He was a web developer, but wanted to get in to telephony development, because it was a foriegn technology he knew he could do if he tried. One of the first things he did was hook into Arduino to control his locks remotely via telephony. He encourages everyone to think out of the box and play with new technologies. Adhearsion is a framework for backend telephony development - you call into a phone network, and it does stuff like recording, playing hold music, etc. Adhearsion rests above Asterisk, and a couple of other things. Asterisk has a couple of different options for servicing phone calls - peer-to-peer, UDP protocol. Conferencing as well, but that is more complicated. Sometimes need special hardware. One of the most interesting things about ruby is the ability to play with other people's code. Adhearsion has a plugin system. The new version is really exciting, and it exemplifies the dynamism of Ruby. It lets you pick up anonymous modules based on file and directory conventions, and extend them with features from a bunch of other different objects. It is a really impressive technology, and the conventions and features of ruby support this. At a philosophical level, Adhearsion is trying to bring open source and modern software principles to the telephony industry, which is very old-skool and backward. It is a big opportunity and a new frontier for Ruby.

Blake: Sinatra. He created Sinatra because he had an itch, and he needed speed. He is a big fan of MVC, but it is not for everything. It was far too much for what he needed, and so Sinatra was born. Ruby is great for Sinatra because of closures. They are cool, and he wanted to make a framework which leveraged the power of closures in ruby. It is a microframework in the truest sense of the word, 800 lines right now. It is getting smaller too, by pulling logic out of Sinatra and moving it into Rack. It is a good rack citizen, and Sinatra doesn't hide the power of Rack, it exposes it to you.

Yehuda: Merb. He didn't create it, but was the lead for a year or so. The hardest thing about maintaining a framework is that they start with a strong sense of identity. Then, people try to do different things, and want the framework to do it. It is hard to make the decision of whether a given feature should be added to the framework/api, or whether it is application-specific code that only one guy ever needed and it will have to be supported forever for just a few people. One of the best things about ruby is that all code is executed code. This means you can define methods anywhere in your app, and have them do things. That is really powerful. Ruby is not a slow language, but nothing is free. For example, in C, an if statement is cheap. In ruby, however, 'cheap' things add up. As you add support for a lot of cases, you end up with a lot of code just testing for application edge cases. Unless you do a lot of mind-warping complex things to deal with these situations, you will end up with a lot of slow code.

Josh: Rack. Rails contributor, working on Rack integration to Rails. Best thing about rack is that even though it is a port of Python WSGI, it doesn't split up methods and have nasty wrappers. In ruby, you can really distill the API into just a call and environment hash. This is really nice and simple, and shows the power of Ruby. Going forward in Rails 3.0, with the Merb/Rails merge, he is looking forward to figuring out how to share code with other frameworks. Prior to the merge, he was interested in how to share code with merb, but even though that is moot, it still strengthens the Ruby ecosystem of web frameworks if things work together.

Questions

Q: Josh Susser: What is the language feature about ruby that is most helpful in making a framework? Blake: Metaclasses and Closures. Allows cool tricks like has_many, etc. Yehuda: Languages without closures are not really an option for frameworks. Most languages in the world don't have closures and that is painful.
A: Greg: We need to craft classes with just the methods we want, such as the main loop in Arduino. Being able to grab code and rip the guts out at the last minute would not be possible without method defintion and evaling.
A: Josh: Open classes. Really nice, such as the goodies ActiveSupport adds to Ruby.
A: Yehuda: Community. Not that the community is awesome, but the Rack thing. A grass-roots effort about sharing code. For example, WSJI is not supported fully by Django. In Ruby with Rack, everyone agreeing to standardize is awesome and powerful. That is a feature of the community in that we love to cooperate and share code.
A: Jay: Ruby has one of the best communities of any programming language. Rubygems is a great example. Agility, such as switching to Github. It is like a school of fish darting around, making "tron-like" right turns and chasing new and exciting stuff. Rspec is another example - people come to ruby without any Test-driven development experience, and new people can pick it up. Cucumber and other tools build on Rspec.
A: Tim: Ruby brings in amazing creative people, like Why the lucky stiff.
A: Yehuda: When rspec came out, it could hook into rails in a way that would not be possible with Java. You can make many little mutations quickly. With the little mutations, the good ones win quickly. In other languages, it is harder.

Q: Josh Susser: You've talked about community, and even non-rubyists recognize this. All these frameworks are open source. Is there anything about ruby that encourages open source contributaion?
A: Jay: It is a scripting language. Everything is open and revealed for the most part. This supports the Open source mindset.
A: Yehuda: Rails and Ruby is MIT licensed. This is corporate friendly, so big corporations get into it. Even if 20% of the big corporations contribute back, this is still more than GPL licensed communities. It is easy to just monkey patch and just make it work, without having a lot of protocols for contributing back

Q: Does the extensibility of the language itself have an effect, e.g. C extsiosn to MRI?
A: Jay: Extensibility of Jruby is great - you can write java code. That's more powerful than C extensions
A: Greg: Jruby and rubinius are bringing new world of interoperability
A: Yehuda: When you make a new ruby implementation, it is expected that there is good integration with the lost language.

Q: You all write frameworks, and Rails has abstractions like ActiveSupport core extensions. Other frameworks have similar libraries. Do you have a library of core extensions for the framework, and do you have plans to share it.

A: Jay: Adhearsion will use ActiveSupport. It introduces a moving part, though, which has caused at least one bug. For example, Adhearsion can load a rails app, but this will pull in a random version of activesupport.
A: Josh: In the future, it will be easier to pick and choose parts of Activesupport
A: Yehuda: Merb created Xlib to solve this problem, which is a smaller more extensible activesupport. A precondition. Also, the gem version dependency problem SHOULD be licked in Rubygems 1.4.
A: Blake: Sinatra should be able to interoperate, and where it doesn't, patches are accepted
A: Yehuda: Problem is that we operate in a global space. We need to make it easier to use ActiveSupport without pain.
A: Tim: Shoes it is a low-level C problem, hasn't needed active support.

Q: Frameworks need to be modular and reusable. Yehuda talks about stable APIs. On Rspec, there's no separation between DSL level and Library. how do you address that?
A: Blake: GOod question. At one point in Sinatra, we talked about what we wanted in 1.0, but the important thing is what we DIDN'T want in 1.0. If we trim things out prior to 1.0, you can always add them back. Hard to pick though.
A: Greg: in Rad, there is a balancing act between doing it in native ruby, and the C level. Hard decision. Would like to have a URL where the Arduino libraries live, and keep the logic out of the framework. Sometimes it is hard, because that is ugly and you want to simplify it. You can write inline assembler in a Rad class, which has different problems than other plugin architectures.
A: Yehuda: Biggest thing for frameworks is to write things like you would expect your plugin authors to do. Don't write something massive with a plugin API. Instead, write something small, and use your own plugin API to do more complex things. It is hard to do, and tempting to make a "secret" thing that only you use. But then you are forced to give people access to your magic api.
A: Greg: I added a secret API for my talk (gets laughs)
A: Jay: Agreed. Also you need to allow people to write tests for their own extensions. If the framework changes (new rails version, for example), you want your clients to be able to catch it. Should be simple for app developers to write tests.
A: Blake: With the github fork queue, it is easy to accept patches, but then you get a flood. It is a balance between accepting stuff and protecting the framework.

Q: Have you ever wanted to overload a method?
A: Yehuda: You can use *args and option hashes and optional arguments.
A: Greg: In C you can do that, and I hate it.
A: Blake: Sometimes I want to, such as recursive operations in erlang.
A: Yehuda: If people could do overloading, they wouldn't use optional arguments. It is easy to have one method that calls out to multiple methods. People would create scary ruby code because of idioms they bring from other languages.
A: Jay: You can unbind methods in Ruby too. This would be complex.
A: Yehuda: Ruby is guessable. If you add complexity, it is harder to find the right thing to do

Q: How do you feel about the prolifiration of language implementations
A: Totally badass
A: Greg: Rad could never work because of Ruby2C.
A: Tim: Exciting.
A: Yehuda: People got burned by Javascript. Ruby has done it right by holding all implementations to a high standard of compatibility. Jruby spends a lot of time to work with Rails and Merb, and other stuff. We have to hold them to a high standard of compatibility.
A: Yehuda: Ok to import Java's concurrent hash. Not OK to hack around MRI implementations, or layers like Jquery or prototype for Ruby.

Q: Community - everyone moving to github. Why? Is it because Chris wrote github, or what?
A: Greg: Got a ping to stick Rad on Github. A month later, I got a pull request that did tons of work for me that got me started. The power of that completely sold me on Github.
A: Blake: Heard from Chris, saying it was cool when I saw him pushing it to my SVN repo. It was big to see Linus talk about it too.
A: Jay: Less excited by git than github. The social network is the important thing. When you put code on github, you are not creating an open source project, you are just putting code out there and letting the community know about it and how to find it. The ability to watch people, fork, submit patches, etc is good. There's a tangible benefit to Adhearsion after the switch to Github, people see other people contributing and there was a big increase in patches.
A: Yehuda: It is a mistake to say it is better than Subversion, early merb started on subversion. but the big thing about distributed version control is that people can have copies of your repo and constantly pull changes. For example, I just merged months of changes back to Rails, and it wasn't too bad; we wrote a script to help. It would not have been possible with Subversion, I would have gone home and cried. Github is awesome, but it isn't git - it could have been Mercurial.

Q: What can we do to move community to Ruby 1.9?
A: Jay: Get rails on 1.9
A: Yehuda: Why do you want the community on Rails 1.9?
Q: Performance and speed improvements
A: Yehuda: You could use Jruby or Ruby 1.9. In some random cases, like ERB templates, 1.9 can be many times slower. I benchmark everything, and there is really wierd 1.9 behavior, outlying blips of slowness. We need to encourage people to look at all implementations and find one that works. It's not obvious that there will be a big benefit of 1.9
A: Jay: Gem compatibility is a big thing. There's a website "is it 1.9 compatible". We've got ourselves into a rut with a lot of gem code out there written on 1.6. People should write for compatibility. If I wrote for 1.9 compatibility, I'd break Jruby support.
A: Yehuda: Jruby 1.9 should work for most things now.
A: Blake: This is a great job for a duplex proxy.
A: Yehuda: We should try to make sure our code works on as many interpreters as possible, but it is not the most importatnt thing.

Here are some Rubyists at GoGaRuCo. Look for more pictures to be added to this slideshow later.

I THINK the following slideshow will eventually show everyone's photos tagged with 'gogarucorubyists', but it doesn't look like Flickr has them indexed yet: