Posted by Nick Sieger
Thu, 30 Apr 2009 03:07:47 GMT
From _why’s constructive post entitled “A Selection Of Thoughts From Actual Women”:
Noirin Plunkett: (Regarding Mike Gunderloy’s decision to leave the Rails team.) It seems like so often in these things, even the “good guys” just tsk-tsk and shake their heads, without being willing to stand up and be counted. Actions speak louder than words...
I don’t like to use this blog as a soapbox for non-technical content, but I too have been conflicted over the past week. So I’m standing up to be counted. As a father of two girls who are starting to show an interest in computing, I consider it my obligation. If you agree with me, I hope you will do so as well by posting a brief statement on your own blogs. If you do, send me a link and I’ll link to you from here. So here’s my statement:
I want the Ruby, Rails, open source, and web development communities to be a dignified, respectful, inclusive, and welcoming place. Acts like putting questionable imagery in a conference talk are regrettable and harmful to those aims. We’ve all been witnesses to off-color jokes, misogynistic back channel chatter and unnecessary, trolling comments. I pledge to do better to stand up and call this behavior out when I see it in conferences, online and other public settings. I don’t expect it to go away but I’m not going to tacitly condone it any longer.
I think we can have our cake and eat it too. We can have a welcoming community while still courting the creativity, edginess and even controversy that makes us who we are; we also need to actively listen and be open to alternative viewpoints. There’s always another side to any story and we need to seek it out, especially when it’s drowned out by online discussion boards run amok.
I’m looking forward to continuing the conversation at the Women in Rails panel next week. I hope to see you there.
Update: I think the individual at the source of the incident that sparked this debate has been through enough so I’m following others’ leads and have anonymized the post.
Nick Sieger
Other statements (Thank you!):
12 comments
Posted by Nick Sieger
Sat, 11 Apr 2009 04:10:51 GMT
I was surprised by Tuesday’s announcements as much as anyone else. Ola keeps secrets well. He sent me a pull request for jruby-rack just last week mentioning “some restrictive environments where you can’t start threads”. I didn’t blink, and instead just merged his patch.
Despite the surprise news, it turns out my timing wasn’t bad. Just a couple of weeks ago I was experimenting with the Python version of AppEngine, just to see what the fuss is all about. Even though Google’s had its share of criticism for building a platform that is difficult for developers to leave, the lock-in aspect didn’t bother me. I’m a pragmatist first, and I believe that we as developers are the only ones locking ourselves to a platform. We have a choice, after all. And look at all the developers willfully rushing to develop Cocoa applications for the iPhone. The fact that their code is not useful on any other device isn’t stopping them.
The thing with AppEngine is that it’s a unique platform all unto itself. That may seem brutally obvious, but the point seems to be lost in all the frenzy surrounding the Run-Rails-Struts-Spring-Groovy-Grails-Lift-You-Name-It-Framework on AppEngine this week. I’m not saying it’s a bad idea to try to run Rails on AppEngine; quite the contrary. I’m saying you need to be honest about the trade-offs and constraints. And in the case of Ruby and Rails, boy are there a bunch of them:
- No regular
net/http, restclient, ActiveResource usage. Google has a URL fetch library, and has hooked up Java’s HttpURLConnection to it, but none of the Ruby URL-fetching libraries use it.
- No ActiveRecord. ‘Nuff said. For some folks, that’s a welcome change, but wrapping your head around AppEngine’s BigTable-backed data store takes some thought. You just can’t view it like a SQL engine.
- No RMagick/ImageScience/attachment_fu. No ImageVoodoo even (no javax.image APIs). Google has it’s own image manipulation API.
- Startup/first request processing time is currently an issue. It’s not clear yet how long Google keeps JVMs warm, so if your application is idle, the first few hits to it return 500 errors. I can only assume Google has a plan to address this.
- Crypto. Although java.security and javax.crypto APIs are apparently whitelisted, I haven’t had time to figure out how to leverage them. JRuby’s jruby-openssl gem does not work, which means things like
digest aren’t available. That’s currently a blocker for Rails’ cookie session store.
- 1000-files limit per application. In order to work around this, I ended up jarring up all the Rails gems when deploying a Rails application.
These are just a sampling of some of the problems you’re dealing with on the AppEngine frontier. They’re all solvable; it will take a little time and BST (blood, sweat and tears). The point is you can’t expect a Rails application on AppEngine to behave like all the Rails applications you’ve written previously.
In return for your troubles, you get the AppEngine value proposition, which is actually attractive in a lot of ways: Google runs the platform. You don’t have to worry about it. Transparent scaling, monitoring, logging, everything below your application code is taken care of. Single-step deployment, with application versioning and rollback. Scalable services: BigTable storage, memcached, scheduled tasks. My friend Curt Thompson of Best Buy’s Giftag.com talks about how they leverage AppEngine for a non-toy application. (Curt also helped me get my Python AppEngine experiment up and running.)
In the end, I’m still extremely excited about the prospect of using JRuby and Rails on AppEngine, and can’t wait to see what people build with these tools. If you want a little head start, you can check out the first Rails application I deployed, jruby-rack.appspot.com. The “application environment” page is the main dynamic action in the app, which just enumerates a bunch of request and system environment properties so you can get a feel for how things are set up in the AppEngine Java environment. The source code for the application is linked from the front page. Note that the app was deployed with JRuby trunk and JRuby-Rack 0.9.4; Warbler is not yet using these components but you can build them yourself, drop them in and try them. We’ll be updating JRuby, Warbler and other tools soon to make this process more seamless soon. Stay tuned!
Tags appengine, google, jruby, rails | 2 comments
