Intro
Josh Susser does the intro. He thought it would be interesting to get authors of popular frameworks together.
Speakers
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.
