Posted by Kevin
Sat, 03 Nov 2007 12:55:00 GMT
So who doesn’t know what JRuby is? (eerie silence). Cool, well we won’t talk about that toooo much, but it’s a java implementation of ruby. Lots of IDEs are getting support for ruby these days, and a lot of that is actually because of JRuby, since IDEs written in java were able to jack the jruby parser and utilize it for their own devious purposes (variable renaming, syntax highlighting, etc).
The jruby compiler is the first ruby compiler for a general-purpose VM. It’s ready for use! We’d recommend ahead-of-time compilation rather than just-in-time compilation for many apps. Lots of neat compiler optimizations are in there – cached literals, using native java features, etc. The ObjectSpace#each_object method has also been removed unless you pass a certain flag into jruby since it’s really slow to implement that particular method in java.
Jruby does not support standard C ruby extensions, but they would recommend pulling in native java libraries instead, as (they reckon) most of the things you would want to accomplish have already been implemented in java. Rmagick is currently being ported.
It is possible, as one might expect, to pull in java from ruby with jruby. A common use-case for this is to create GUIs with java swing, and the ruby swing abstraction actually does a lot to simplify the swing API and make it more enjoyable to use.
Upcoming features are Hibernate-backed persistence, Ruvlets (Ruby Servlet-like API), Rspec, and many others. Good times.
Posted in Rubyconf | no comments | no trackbacks
Posted by Kevin
Sat, 03 Nov 2007 12:49:00 GMT
How delightful to be awake at 9:00 and to witness this microsoft employee trying not to get tarred and feathered by the rubyconf hoardes. Sounds like the timeframe for the release of IronRuby is fairly loose. It will certainly be interesting to see how ruby running in the .net CLR will affect the future of ruby.
Posted in Rubyconf | no comments | no trackbacks
Posted by Kevin
Fri, 02 Nov 2007 18:24:00 GMT
What’s a strategy for playing werewolf? Paying attention to the details of what is going on. This is a also a good strategy for writing C extensions to ruby – maybe you’re pair programming and maybe you’re not, but if you have a bug, your code will likely crash hard; pay attention!
Don’t be afraid to write a ruby extension, but there are definitely things that you should be aware of before you start:
- you will often have two objects that are representing the same thing, but one is the C object and one is the ruby object – do not give these variables the same name! Use a naming convention that differentiates them
- ranges for your data types are important during conversions!
- allocate resources and deallocate resources in the same place if possible!
- do not destroy an object that does not belong to you!
- check function return values!
- make sure you use rb_ensure!
- executing arbitrary code and using tainted data are potential security concerns!
- unit testing is hard, as many C libraries were not built with unit testing in mind, but functional tests that execute your extension code are quite necessary!
- convert C++ exceptions to ruby exceptions at C++/Ruby boundaries and vice versa!
- use the Pstore database if you need a database – it’s simple!
- implement to_s and inspect for any custom classes! they’re useful!
- use virtual destructors when doing inheritance!
- there are tools to help – Rice, etc!
- damn straight!
Posted in Rubyconf | no comments | no trackbacks
Posted by Kevin
Fri, 02 Nov 2007 18:23:00 GMT
These slight technical difficulties. Handled fairly elegantly. Hot guy.
I was surpised with how many of you said you had written a parser when Jim Weirich asked the question this morning, since I would have expected very few folks to have written parsers with classic context-free generated grammars. And then again, I was surpised with how few of you said you had written a parser when Jim Weirich asked the question this morning, since I know that lots of folks have written parsers – at least parsers like regular expressions to parse strings.
Parsing Expression Grammars are mad hot since they can do recursion – and Treetop is a Parsing Expression Grammar.
Arbitrary ruby is not allowed inside of a treetop grammar as at yet – maybe in the future.
And…this live coding followed. Good times parsing a mathematical expression and testing the various pieces.
One of the cool things about Treetop is that it does not “lex”, unlike many other parsers. There are cool posibilities with sharing well-constructed grammars and reusing grammars inside of other grammars to construct more complex grammars. Neat. Really enjoyable presentation.
Posted in Rubyconf | no comments | no trackbacks
Posted by Kevin
Fri, 02 Nov 2007 17:32:00 GMT
One of these homies just got married last month – his good. They also re-wrote their company’s 10-year-old package processing system (most recently in java) in ruby – their good.
Their messaging system, AP4R is:
- LIGHTWEIGHT AND ROBUST, apparently
- open-source
- simple to use
- used by various companies, including their 500-person firm in Japan
- backed by the mascot apar, an armadillo, which is the most important feature
- able to handle “busy” tasks and “heavy” tasks independently, resulting in better performance
- able to play nice with capistrano (deployment goodness)
- testable with functional tests (shortcut but fast-running) and async tests (better tests but slower)
They demo’d a shopping cart application, and the performance gains that can be had by using AP4R to processing the slow back-end processes asyncronously, while giving the user immediate feedback.
There are features planned for upcoming releases! Sounds like AP4R is a living organism, and well worth looking into for the right application.
Posted in Rubyconf | no comments | no trackbacks
Posted by Kevin
Fri, 02 Nov 2007 16:23:00 GMT
Dude, Talbott, has actually spoken at all seven ruby conferences – damn dude. He gave love to why, and started live coding a blog in camping: creating posts, viewing posts, adding comments – good stuff.
Now, breaking some eggs…
Contrasting camping with rails:
- rails favors convention over configuration, but camping has no configuration.
- rails is boring (david said so); camping is zesty
- rails encourages conformance; camping encourages experimentation
Dude got all sales and marketing-centric, and realized while hacking one day that feeding his creative side is incredibly important. Regular, varied and appealing tasks are what we need – if we learn something new at every turn, no matter how small, we will be happier and more productive.
Talked Rubyconf vs. Railsconf:
- hobbyists at rubyconf, professionals at railsconf
- generalists in ruby, focus in rails
- vitality from ruby, momentum from rails
Thanks for coming; now help out our ruby community – go hack something!
Posted in Rubyconf | no comments | no trackbacks
Posted by Kevin
Fri, 02 Nov 2007 16:18:00 GMT
Most of Jim’s talk was spent chilling out with my workmate Jeffmo in the car on the way to Charlotte, North Carolina. Jeffmo apparently lost all the contents of his wallet on one occasion, including $2000, only to have it turn up six months later (with all of its contents).
Jim was discussing how one might go about implementing a pure-ruby SQL abstraction. A node for a table, a node for a column, a node for an operator, and a node to represent your mother as well. The code examples were neat, but at the end of the day, his basic conclusion was that it’s impossible because, among other things, you can’t override || and && in ruby.
He offered encouragement to experiment with out-of-the-box solutions for problems, even though a standard approach suffices in most situations – made me think of gabe.
Posted in Rubyconf | no comments | no trackbacks
