Posted by Kevin
Sat, 03 Nov 2007 14: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 14: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 | 1 trackback
Posted by Kevin
Fri, 02 Nov 2007 20: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 20: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 | 3 trackbacks
Posted by Kevin
Fri, 02 Nov 2007 19: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 18: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 18: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
Posted by Kevin
Wed, 26 Sep 2007 01:06:00 GMT
I just spent a couple of weeks over in Zambia marrying myself off – here is the evidence.
Posted in Zambia, Personal | no comments | 134 trackbacks
Posted by Kevin
Sun, 22 Apr 2007 18:04:00 GMT
As it turns out, it’s not the greatest idea to store your personal documents on a company computer. I was talking with some of my workmates over dinner the other day about what happens in the moments immediately after you get canned.
In many cases, there really isn’t any chance to salvage personal documents from your company computer, cover up frivolous instant messenger logs, or any of the other things that you would likely do given 15 minutes at your computer. I guess the reasoning is that fired (and therefore disgruntled) tech workers, rather than doing something useful, would prefer to delete all of the company’s code or bring down the corporate website for a while. No comment.
Now it’s not that I’m planning to get fired this week, but one may as well take any obvious precautions and follow standard best practices. So I rolled on over to lifehacker to find myself an online backup solution; I ended up settling on mozy.
It’s been a delight as I’ve gotten into it for the past 24 hours or so. This mozy link does include a referral code that will get you (and me, wink) an extra 256MB on top of the free 2GB.
It’s a bit ridiculous that this is the way I was finally convinced to back up my documents, but the end justifies the means I suppose. So if I do happen to get fired this week, I’ll now be happy as a clam, at least as far as having access to my personal documents is concerned.
Posted in Struggle, Software, Productivity | 2 comments | no trackbacks
Posted by Kevin
Mon, 29 Jan 2007 04:36:00 GMT
So I sat down to create a website today and, as one might expect someone who wanted to create a rails application to do, ran the command:
I knew I didn’t need a database for this particular application, so, as one might expect someone without a strong grasp of language to do, I googled for words that don’t exist: databaseless rails application.
The friendly people in the search results, who apparently also enjoy making up words, were busy discussing how to go about prying rails free from ActiveRecord’s evil clutches (ActiveRecord being the database layer built into rails). There was, however, a lone voice calling out, “maybe rails is overkill for your application if you don’t need a database.”
“A web application not built in rails?!?,” I thought, “That’s frickin’ ridiculous!”
Two hours later the job was done. The secret? Why the lucky stiff and his mini-framework, Camping. As it turns out, Camping is a neat little web framework. The best thing (I can’t believe I’m saying this) is that all of the code for the entire application can be, if you so choose, in one file. So when I went to archive away the code in subversion, I didn’t have to engage in witchcraft like setting up the svn ignore property on multiple files and directories, or pulling lots of libraries into the application by way of svn externals.
The flip side to all of this is that when I installed the recommended gem, it grabbed what seemed to be a heck of a lot of other gems as dependencies. Rails has moved away from this kind of server-dependent configuration by encouraging people to package all of their application’s dependencies into the application itself. But I still think it’s cool that the application is in one file. :)
So by all means, give camping a shot the next time you want to write an afternoon-sized web application.
Posted in Software, Experimentation | 2 comments | no trackbacks
