こんなふうに英語で話しました
というわけで、こちらが今回作成した英語のスライドです。
実際どんな内容をしゃべったのか、以下で英語と日本語訳をスライドとともにご紹介します。
Hi everybody. My name is Junichi. I'm from Japan. Are you enjoying RubyConf? Good, me too! Today I am going to talk about unhappy exception handling. But this is my first English speech, so it will be a big challenge for me. But I give it a try.
こんにちは、みなさん。僕の名前は淳一です。日本から来ました。みなさん、RubyConfを楽しんでますか?おお、いいですね。僕も楽しんでます!さて、今日は「アンハッピーな例外処理」についてお話しします。しかし、英語で発表するのは今回が初めてです。なので、これは僕にとって大きなチャレンジになりますが、がんばってやってみます。
Let's begin. Now, I talk about the basic syntax of exception handling in Ruby. Probably, all of you understand the syntax -- begin, rescue and end. Okay?
では本題に入りましょう。まず、Rubyにおける例外処理の基本的な構文についてお話しします。おそらくここにいるみなさんは全員この構文を理解していると思います。beginとrescueとendです。大丈夫ですね?
It is very simple, but some programmers misuse exception handling. They misunderstand "If exception happens, use `rescue`. That's okay." They begin writing `rescue` everywhere -- rescue, rescue, rescue... And they believe "My program is now relialble." Is it okay? --- No!
この構文は非常にシンプルです。しかし、プログラマの中には誤った方法で例外処理を使う人もいます。彼らはこんなふうに誤解しています。「もし例外が起こったら、`rescue`を使えばいい。それで大丈夫。」そして、あちこちに`rescue`を書き始めます。rescue、rescue、rescue・・・。これでいいんですかね?ダメですよね。
But, some years ago...
ですが、何年か前に・・・
I had a trouble at a previous job. I joined a previous company as an in-house software engineer. I became the maintainer of an existing in-house web application. It was a good boy because it had been running perfectly for years. One day, I had an opportunity to talk with one of the users. He showed me his regular operation, and I was watching it. He clicked the save button, then I saw a dialog "System error minus one." "Oh, what? What's this?" He said "We see it very often. So we're clicking the save button again and again, click! click! click!"
私は前職であるトラブルに遭遇しました。私は社内ソフトウェアエンジニアとして前の会社に入社しました。私はとあるWebアプリケーションのメンテナンス担当者になりました。そのシステムはとってもよい子でした。なぜなら何年にもわたって完璧に稼働していたからです。ある日、ユーザーの一人と話をする機会がありました。彼は私に普段の運用方法を見せてくれました。そして私はそれを見ていました。彼は保存ボタンをクリックしました。すると、こんなダイアログが表示されました---"システムエラー: -1" 「ん?何ですかこれは?」彼はこんなふうに答えました。「これねえ、しょっちゅう出てくるんですよ。だから、こうやって繰り返し保存ボタンをクリックするんです。カチカチカチカチカチッ!!」
Oh, really??
げえっ、マジで!?
The code was like this. Actually, it was not Rails. That was ASP.NET in C#, but the basic idea is not different. They are the same. I remember that was an update logic, and it had an unnecessary rescue clause. This is the unhappy exception handling. It just displayed an error code, so it neither notified nor logged. We never noticed even if an error occurred. Unfortunately, the users had a bad procedure, "If you get this error, keep on retry." No! Do not retry, please call us. After the investigation, we found the root cause -- it was dead lock. Dead lock was involved so frequently due to a bad table design. Have you ever seen a table without any primary keys? --- No? Okay.
そのコードはこんなふうになってました。実際にはRailsではなく、C#で書かれたASP.NETでした。ですが、基本的な考え方は変わりません。どちらも同じです。あれはたしか更新ロジックだったと思います。あのロジックには不要なrescue節が入っていました。これが「アンハッピーな例外処理」です。この例外処理は単にエラーコードを表示するだけなので、通知も来ず、ログも残されません。ですから、エラーが起きてもまったく気づけません。不運なことに、ユーザーはこんなイケてない手順書を作っていました。「もしこのエラーが起こったら、再試行を繰り返すこと。」いやいや、再試行しないで!お願いだから僕たちに連絡してください。調査の結果、この問題の根本原因がわかりました。デッドロックです。ひどいテーブル設計のせいでデッドロックが頻発していたのです。みなさんは主キーが全くないテーブルを見たことがありますか?---ない?ですよね。
Anyway, this is the conclusion. What can we learn from this story? First, the misuse of exception handling leads to terrible consequences. Second, what you can do and what you should do or you shouldn't do are different. Third, if you don't have confidence in exception handlings, please do not use `rescue` so casually. Delegate exception handlings to frameworks. For example, Rails can display 500 page or save logs. Please consider asking mentors for help about your code design. Let's do happy exception handling!
というわけで、まとめます。私たちはこの話から何を学べるのでしょうか?まず一つ目。間違った例外処理はとんでもない結果を招きます。二つ目。「できること」と「すべきこと(またはすべきでないこと)」は違います。三つ目。例外処理の書き方に自信がないなら、`resuce`を気軽に使わないでください。例外処理はフレームワークにお任せしてください。たとえば、Railsは500エラーページを表示したり、ログを残したりしてくれます。メンターをつかまえてコードの設計について相談することを検討してください。みなさん、「ハッピーな例外処理」を書きましょう!
Finally, let me introduce myself. My name is Junichi. You can call me Jun. I'm working as a software engineer at a Japanese company called SonicGarden. And I'm mainly developing Rails applications. I have Twitter and GitHub accounts.
最後に、僕の自己紹介をさせてください。僕の名前は淳一です。Junと呼んでもらって構いません。ソニックガーデンという日本の会社でソフトウェアエンジニアとして働いています。主にRailsアプリケーションを開発しています。TwitterとGitHubのアカウントもあります。
I have some personal works. I translated an ebook called Everyday Rails Testing with RSpec. Do you know this book? Great, I translated it.
個人的にやっている仕事もいくつかあります。僕は「Everyday Rails - RSpecによるRailsテスト入門」という電子書籍を翻訳しました。みなさん、この本は知っていますか?すばらしい。この本を翻訳したんです。
And I wrote a book called Introduction to Ruby Programming for Future Professionals last year. The key concept is "Learn Ruby before Rails." Matz kindly wrote the foreword message for this book. I'm looking for an English publisher, so if you know anyone, please introduce him or her to me.
それから「プロを目指す人のためのRuby入門」という本を去年書きました。キーコンセプトは「Railsをやる前に、Rubyを知ろう」です。ありがたいことにMatzさんが「本書の刊行に寄せて」のメッセージを書いてくれました。現在英語版の出版社を募集中です。もし関係者の方をご存じでしたら、その方を僕に紹介してください。
Anyway, that's all. I hope you enjoyed my talk. Thank you very much! See you.
さてさて、これで僕の発表はおしまいです。みなさんに楽しんでもらえたなら幸いです。どうもありがとうございました!またお会いしましょう。
参考: 使えそうな英語の言い回し
今回の発表では以下のような言い回しが含まれています。
こういった言い回しは今回の発表に限らず、他の発表でも使えそうなので参考にしてみてください。
- Today I am going to talk about 〜.
- 今日は〜についてお話しします。
- Let's begin.
- それでは本題に入ります。/ では始めましょう。
- Anyway
- というわけで / それはさておき / とにかく
- First, 〜. Second, 〜. Finally, 〜.
- 最初に〜。2番目に〜。最後に〜。
- A called B
- BというA / 例: a company called SonicGarden(ソニックガーデンという会社)
動画はこちら
今年もRubyConfの全発表はYouTubeにアップされています。
すなわち、僕のLTもアップされているということです!
自分で見返すのは少し恥ずかしいのですが、英語の登壇を考えている方の参考になるかもしれないので紹介しておきます。
僕の発表は00:55:49頃から始まります。
RubyConf 2018 - Lightning Talks
完璧な英語ではありませんが、できるだけ抑揚を付けたり声色を変えたりして、平坦でボソボソしたしゃべり方にならないように心がけたつもりです。いかがでしょうか?