Merblog

Sequel作者のインタビュー和訳

http://on-ruby.blogspot.com/2008/01/sequel-interview-with-sharon-rosner.html

インタビューは2008年1月と9ヶ月近く前に行われたものですが、発見したのはさっきです。せっかくなので訳してみます。

既に多くのORMがあるのに、新しく書こうと思ったのはなぜですか？（There are already several ORMs out there. Why write another one?）

Sharon: I wrote Sequel mainly because I tried ActiveRecord and it really didn’t fit what I wanted to do. The first thing that frustrated me was the lack of support for multi-threading. I was messing with Mongrel and writing my own web controller framework, and couldn’t get ActiveRecord to work properly with multiple threads. It leaked memory like a sieve, and it just felt wrong. There was also no support for connection pooling for example.

Sequelを書いたのは、ActiveRecordを試してみたものの、やりたいことにいまいちフィットしなかったからだ。欲求不満のひとつめは、マルチスレッディングのサポートが欠如していたこと。Mongrelにかみついて自分のウェブコントローラフレームワークを書いてたけど(訳：自信なし)、ActiveRecordはマルチスレッドではちゃんと動いてくれなかった。ザルのようにメモリリークが起きて、これは「間違っている」と強く感じた。コネクションプーリングもサポートしてなかったし。

The other, even more important, issue was that ActiveRecord is great for dealing with individual records, but if you need to work with multiple records or large datasets, it kinda feels awkward. If you need to filter then you have to write raw SQL expressions, and it’s a bit hard to do GROUP BY and than sort of stuff. Also, ActiveRecord loads the entire result set into memory before you can iterate over it. Not very nice if you work with millions of records.

他にも、これも重要なことだけど、ActiveRecordは個別のレコードが大きな関心事になっている。複数レコードや大きなデータセットを操作したいとき、これはとても不器用なやりかただ。生のSQLを書いてフィルタしなきゃいけないときは、GROUP BYやたくさんのソートよりもずっと手強い(訳：自信なし)。そしてActiveRecordは得られた結果をイテレートし始めるより前に全部メモリにぶち込む。これは百万オーダーのレコードを処理するとき上手いやりかたではない。

So I started from there and tried to design a Ruby interface for databases that would feel like Ruby code, where I didn’t have to switch between SQL and Ruby. So the basic idea was that you can express an SQL query using Ruby constructs, and then iterate over the results just like you iterate over an array or any Enumerable, fetching each record as a Ruby hash with symbols for keys:

まずはDBへのインターフェイスをRubyコードのように感じられるようデザインすることから始めた。SQLとRubyを切り替えなくていいようにね。基本となる考えアイデアはこうだ。SQLクエリをRubyコードのように表現でき、結果をイテレートするときはちょうど配列やEnumerableをイテレートするように、結果の取得はRubyのハッシュとシンボルをキーにして。

DB[:posts].filter(:category => 'ruby').each {|row| puts row[:title]}

I actually wrote Sequel to be used in this project I was working on (and still am), and added more features as I needed them. The development of Sequel is still very much feature-request driven. People ask for stuff and if it’s a good idea we add it the library.

実際のところ、Sequelは自分でやってる（そして今も続けている）プロジェクトのために書いたし、必要とする機能はどんどん追加してきた。Sequelの開発は今も変わらず、非常に機能リクエストドリブンだ。誰かが「こんなのできる？」って訊いてきて、それが良いアイデアならライブラリに追加する。

Apart from that, I like the fact that there are several different ORM’s for Ruby. Each has a different mindset, each has its pros and cons. It’s very much in the Ruby spirit one of the things I like most about Ruby is that you can write the same stuff a million different ways. Some people dislike it, but I think it’s brilliant!

ちょっと話題が逸れるけど、いろんなORMがRubyにあることが好きだ。それぞれが異なったマインドセットを持ち、それぞれが賛否両論だ。これはとてもRubyらしいーー私がRubyの中で最も好きなことのひとつは、同じことをやるのに百万通りのやりかたがあるということだ。それを嫌う人も居る、でも私は素晴らしいことだと思う。

Sequelの中でも、あなたが採用したリクエストの中でクールだったのは何ですか？（What are some of the cooler things that you’ve added to Sequel based on other people’s requests?）

Sharon: Some people were asking for a way to change table schemas easily, so I came up with a DSL for doing that, so you can do stuff like:

何人かが簡単にテーブルスキーマを変更する方法はないかと訊いてきたので、DSLを使って出来るようにした。つまり、こんな感じで。

alter_table :items
  add_column :name, :text, :unique => true
  drop_column :category
end

And Sequel will generate the correct SQL for you.

これでSequelは正しいSQLを生成してくれる。

Another thing that was requested is support for accessing values inside arrays, so we came up with a way to specify array subscripts:

他には配列にアクセスしたいって言われたから、添字演算子を作った。

DB[:items].filter(:col|1 => 0).sql #=> "SELECT * FROM items WHERE (col[1] = 0)"

Sequelはどういう場面で使われていると思いますか？　また、どういう場面では違うアプローチを取るべきだと思いますか？（What spaces do you think Sequel plays well in? Which spaces should be left to a different approach?）

Sharon One of the things that separates Sequel from other ORM’s is that you don’t really have to define model classes. In fact one of the recent changes (in version 0.5) was to divide the code into two separate gems—sequel_core which takes care of connecting to databases and fetching records, and sequel_model which implements an ORM layer on top.

Sequelが他のORMと違うことのひとつは、モデルクラスを定義しなくていいことだ。実際、最近の変更（ver 0.5）ではコードを2つのgemに分割したーーsequel_coreはデータベースへの接続とレコード取得の面倒を見て、sequel_modelは一番上のORMレイヤを実装する。

With sequel_core you can fetch records as naked Ruby hashes, which you can also use to insert and update records. So that gives you a lot of freedom in querying virtually any database, without making assumptions on how the schema looks. So Sequel can be used with legacy databases and also as a general purpose tool for writing short scripts that process records. In fact, Sequel also lets you fetch records with arbitrary SQL and iterate over the results using the same interface.

sequel_coreを使えばレコードの取得を普通のRubyハッシュのように扱える。レコードの追加と更新も同様だ。これによって、スキーマについてあれこれ考える必要から開放され、事実上どんなデータベースにも問い合わせを行えるようになる。そう、Sequelはレガシーなデータベースにも使えるし、ありふれた目的のためにちょっとした短いスクリプトを書くためのツールにもなる。現にSequelは同じインターフェイスで任意のSQLによる結果の取得とイテレートを行える。

Sequel can be used as a general low level database access library. It is built so you can stick any ORM model implementation on top. I know for example that there was an effort to graft Og on top of Sequel, so this kind of stuff can be done. Sequel already has adapters for ADO, ODBC, PostgreSQL, MySQL, SQLite, and DBI. There are also experimental adapters for Oracle, Informix, DB2, OpenBase and JDBC (on JRuby). In that respect, I believe Sequel can a good replacement for DBI.

Sequelはデータベースへの一般的なローレベルアクセスライブラリとしても使える。SequelをORMの一番上のモデル実装に生やせる。例えばOgへの接ぎ木は可能だった。SequelはADO、ODBC、PostgreSQL、MySQL、SQLite、DBI、そして実験的ながらOracle、Informix、DB2、OpenBase、JDBC(on JRuby)のアダプタを既に持っている。この点に関して、SequelはDBIの良い意味で置き換えられると思っている。

The flip side, however, is that Sequel is not really made for Ruby beginners. The API is very terse and very powerful if you know how to use it, but newcomers might be bewildered by how short everything looks. :-) They better stick with ActiveRecord, Og or DataMapper.

しかしながら、実はSequelは真のRubyビギナー向けに作られてはいない。SequelのAPIはあなたが使い方を知るには非常に簡潔でパワフルだが、初心者はその短いコードによって途方に暮れるかもしれない :-)　彼らはまずActiveRecord、Og、DataMapperを試したほうがいいだろう。

他にどんなDBツールを見て、それをSequelに生かしましたか？（What other DB tools have you looked at, learned from as you’ve worked on Sequel?）

Actually a lot of my inspiration came from two Python frameworks: web.py, which is sort of a micro web-framework, and sqlalchemy, which is in my opinion a brilliant piece of work. I haven’t used, but I read a lot of the documentation and grabbed some ideas from there, like for example using a URL to specify a database connection, or the separation between a layer that deals with fetching records and a modelling layer.

実は多くのインスピレーションを2つのPythonフレームワークから得た。web.pyは一種のマイクロウェブフレームワークだ。SQLAlchemyは非常に素晴らしい出来栄えだと思ってる。使ったことはないが、多くのドキュメントを読んで、いくつかのアイデアをここから収奪した。例えばURLをデータベース接続に使うとか、レコード取得とモデルレイヤを分割するとか。

Sequelに携わる中でRubyについて学んだことは？（What have you learned about Ruby while you’ve been working on Sequel?）

I learned a lot about meta-programming. I got a lot from reading the stuff that _why wrote. He’s probably the brightest most genius Ruby programmer in existence today! A lot of parts of Sequel are written using meta-programming techniques. Once you know how to use those, you can do nuclear stuff!

メタプログラミングについて多くを学んだ。_whyが書いたものから多くを得た。彼はたぶん今日のRubyプログラマの中で最高に輝かしい天才だろう！　Sequelの多くはメタプログラミングのテクニックを使って書かれている。これらを知り使いこなせれば、桁違いの仕事ができるようになるだろう！

The biggest discovery I made though was ParseTree. It’s a library that takes your code and gives you back a parse tree made from arrays with symbols in them. It’s the ultimate meta-programming tool. I believe it’s really the next step for Ruby programming and should become part of the Ruby core. Unfortunately, it doesn’t work with Ruby 1.9, at least for now.

最大の発見はParseTreeだろう。このライブラリはコードを配列やシンボルで作られた構文木にしてくれる。究極のメタプログラミングツールだ。これはRubyプログラミングの次なるステップであり、Rubyのコアになるべきだと信じている。残念ながらRuby 1.9では今のところ動かないみたいだけど。

Sequel uses ParseTree to translate Ruby code into SQL. So for example, the following code:

SequelはParseTreeを使ってRubyコードをSQLへと変換している。例えばこんなコードが、

DB[:items].filter {:score > 100 and :category.in('ruby', 'perl')}

Is translated into the SQL statement “SELECT * FROM items WHERE (score > 100) AND (category IN (‘ruby’, ‘perl’))”

 “SELECT * FROM items WHERE (score > 100) AND (category IN (‘ruby’, ‘perl’))”

こんなSQLへと変換される。

The Ruby to SQL translator (I call it “The Sequelizer”) is also smart enough to evaluate Ruby expressions, so you can also use constants, variables and ivars, and make calculations.

Ruby→SQLの変換器（これを「The Sequelizer」と呼んでいる）はRubyの式を評価するのに充分賢い。定数も変数もインスタンス変数も使えて、ちゃんと演算できる。

Another important thing I learned was the value of properly written specs and good code coverage. The thing about rspec is that unlike unit testing, when you write specs you tend to repeat a lot of expectations. I found that with specs the code gets a much more thorough work-out than with unit tests. A lot of stuff gets tested multiple times under different scenarios.

他に学んだなかで重要なのは、きちんと書かれたspecは良いコードカバレッジになるということだ。RSpecがあまりユニットテストに似てないのは、specを書くとき多くの期待を繰り替えしがちだ。specによってコードはユニットテストよりも多くの良い結果を得ることを発見した。ほとんどのものは異なったシナリオ下で複数回テストされている。

RSpec has also proved to be an indispensable tool for debugging, but this really requires a change in how you work. When you work on a bug, instead of just hammering out a solution, you first write a spec that will fail, setting expectations that expose the bug. Only then do you fix your code so the spec will pass. This seems trivial but it’s important when you develop a library used by hundreds of people. When you work this way you can also ensure that the bug doesn’t return when you make changes to your code.

RSpecはデバッグに不可欠なツールだと判明した。これは実際のところどれくらい仕事を変えるだろうか。バグと闘うとき、ハンマーですべてをぶち壊す代わりに、まずspecを書くことで正常動作を定義してバグを白日のもとにさらす。specをパスして始めてコードを直したといえる。これは小さなことだが何百人が使うライブラリの開発には重要なことだ。変更を加えたそのコードではバグが再現しないと保証できるのだ。

I use RCov in conjunction with RSpec to make sure every line of code is covered by specs and as of version 1.0 we have 100% code coverage!

RSpecと合わせてRcovを使って、specがコードのすべての行をカバーするようにしてる。バージョン1.0は100%のコードカバレッジになった！

他のカバレッジツール（たとえばdcovやheckle）は使ってますか？　また、それはなぜ？（Are you using other coverage tools (like dcov or heckle)? Why or why not?）

Both dcov and heckle are things I haven’t looked into in depth. Sequel is not very strong on documentation, and we should put a lot more effort into it. As regards heckle, I tried playing with it a few times, but eventually it would always make the specs hang. Some of the Sequel specs really wreak havoc with Ruby threads and loading/unloading of classes and methods, so I don’t know if heckle can really be beneficial for us. As many other people have already observed, 100% code coverage doesn’t mean there are no bugs or that the code is perfect, but it’s still, together with specs, a good indication of code quality.

dcovもheckleもあまり深くは見てない。Sequelはあまりしっかりとドキュメンテーションされてないから、そこにをもっとがんばるべきだろう。heckleに関しては遊びでちょっと試したことがあるが、いつもspecがハングした。SequelのspecはRubyのスレッドを酷使してクラスやメソッドをload/unloadしまくってるから、なんでheckleが得なのかわからない。多くの人は何らかの意見があるだろうが、100%のコードカバレッジはバグがないかコードが完璧だということを意味しないが、specとともに、これはコードの質が良いことの吉兆だろう（訳：自信なし）。

Railsを使うためにRubyを知るべきかと訊ねる人も居ます。Sequelを使い始めるのにSQLはどの程度知っておくべきか、また実用に至るにはどの程度の知識が必要ですか？（Often, people ask if you need to know Ruby to use Rails. How much SQL do you need to get started with Sequel and how much SQL do you need to know to really use Sequel well?）

That depends. The abstraction provided by ORM’s is never perfect, and if you’re going to deal with a relational database, you pretty much need to understand SQL. But with Sequel, you don’t need to know how columns, strings and other literal values should be quoted, or worry about SQL injection, or what’s the correct order of SQL clauses.

状況次第だ。ORMによる抽象化が完璧になることはないし、SQLをきちんと理解した上でRDBMSとやりとりしたいのかにもよる。でもSequelを使うなら、カラムとか文字列とかいったリテラルをわざわざクオートで囲む必要もないし、SQLインジェクションについて心配することもないし、正しいSQLの語彙を知る必要もない。

There’s a #filter method for specifying record filters, an #order method for specifying the order, a #limit method for limiting the size of the result set and so on. Sequel has idioms for column references (using symbols), SQL functions ( e.g. :max[:price]), array subscripts (as shown above), qualified column names, column aliasing, etc, so the mapping of Ruby to SQL is pretty much complete. There’s also substantial support for sub-queries, which is a believe a unique feature of Sequel. And you can always see what the SQL looks like by calling #sql. Sequel also provides a DSL for defining and changing table schemas. In that respect, you can forget how SQL statements look and manipulate your database using Ruby code.

#filterメソッドはレコードのフィルタに特化しているし、#orderメソッドはオーダーに特化してるし、#limitメソッドは結果セットのリミットに特化してる。Sequelは、カラムを参照するためのイディオム（シンボルを使う）、SQL関数（例えば:max[:price]）、配列の添字（さっき言ったやつね）、特殊なカラム名、カラムの別名、などなど、たくさんのイディオムを持ってる。RubyをSQLにほぼ完璧にマッピングできている。大量のサブクエリサポートはSequel特有の機能だと思ってる。それに#sqlメソッドを呼んで、いつでもSQLを目視できる。Sequelはテーブルスキーマの定義と変更をするためのDSLを提供する。これらの点において、Rubyからデータベースを操作したり参照するのに、どうやってSQLに書き下せばいいのか忘れることが出来る。

So if you’re just writing a blog app and need to put some stuff in a database, you don’t really need to know SQL, but if you’re dealing with large data sets or complex relationships then you better have a good understanding of how relational databases work and how records are fetched, and that involves at least some knowledge of SQL.

いまブログアプリを書いてるとして、データベースに何か入れるとき、必ずしもSQLを知っている必要はない。でも巨大なデータや複雑なアソシエーションを扱うなら、データベースがどうやってレコードを取得するのか、多少のSQL知識が必要になってくるだろう。

SQLをもっと学びたいと思ってる人にオススメの本やサイトなどはありますか？（What books, websites, etc. would you recommend for people wanting to learn more about SQL?）

I’m really not the type that reads books on programming, I just dive right in. There are though tons of articles on the web about the subject. That’s especially useful if you want to look at how to do more complex stuff like multiple joins, sub-queries, grouped queries etc.

私は本をあまり読まずにプログラミングするタイプだから、正しいものを薦められるとは思えない。そのテーマで書かれた大量の記事がウェブにある。中でも有用なのは、複雑なJOINやサブクエリやGROUP BYされたクエリによって、複雑なものを取ってくるにはどうすればいいか書かれたものだ。

Sequelについてもっと多くの情報はどこで得られますか？（Where can people turn for more information about Sequel?）

There are four good places to look:

この4つがいいだろう。

あとコードを見てみるのもオススメだよ（訳注：原文ではGoogle Codeにリンクしてますが、現在はgithubに移ってます）。

Sequel本計画を密かに温めてたりしますか？（Is there a Sequel book lurking in the wings?）

Not that I know of, and I’m not really the person to take on that kind of project. But if somebody wants to go ahead and do it, that would be like super cool!

知ってる範囲では聞いたことないなあ、ていうかどんな人がプロジェクトに関わってるか知らないんだ（訳：自信なし）。でも誰かがそれをやるっていうなら、きっとスーパークールだろうね！


Sequelを使った最高にクールなものはありますか？（What’s the coolest thing that someone’s done with Sequel?）

I’d have to say Hackety Hack, which is a project by _why to make programming accessible to kids. He wraps Sequel a bit to make it more friendly but you can see a bit of Sequel code right there on the front page!

Hackety Hackを挙げなきゃいけないな。この_whyプロジェクトは、子供たちがプログラミングしやすいようにするものだ。彼はSequelをラップしてちょっといじって、もっとフレンドリーにした。Sequelのコードがフロントページにあるから見てみて！

タグ

コメント

名前
本文
2+5=