give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

今年も西脇.rb&神戸.rbでRubyプログラミングキャンプ 2018を開催しました

はじめに

ちょっと前の話になりますが、2018年11月10日と11日の2日間、「Rubyプログラミングキャンプ 2018」という開発合宿イベントを開催しました。
主催者は僕とAkiさん荻さんの、西脇.rb&神戸.rbメンバーです。

開催場所は去年に引き続き、兵庫県丹波市にある「新たんば荘」でした。

また、参加者は全員で11名で、今回は女性エンジニアの方も2名参加してくれました。
地元である関西圏からの参加者が多かったですが、中にははるばる東京から深夜バスで参加してくれた方もいました(すごい!どうもありがとうございます😆)

写真で振り返るキャンプの様子

どんな様子だったのか振り返るために、当日撮った写真をあれこれ載せていきます。

ちゃんと看板が出てました。


f:id:JunichiIto:20181230054157j:plain 設営前の多目的ホールの様子。


f:id:JunichiIto:20181230054429j:plain みんなで協力してこんな感じにテーブルを配置しました。


f:id:JunichiIto:20181230054523j:plain アイスブレイクの目的で最初にやったのは「プログラミングかるた」です。


基本的には「もくもく会」なのですが、困ったことがあればいつでも相談してよい、というスタイルです。


f:id:JunichiIto:20181230081914j:plain スクリーンにコードを映しながら、みんなで「このコードの設計はどうするのがいいか?」みたいなことを話し合ったりもしました。


そういえば、ちょうど紅葉がきれいな季節でした。


f:id:JunichiIto:20181230055333j:plainf:id:JunichiIto:20181230055341j:plain
f:id:JunichiIto:20181230055337j:plain 今年は料理も豪華で美味しかった!


f:id:JunichiIto:20181230060008j:plainf:id:JunichiIto:20181230060203j:plain
f:id:JunichiIto:20181230060019j:plain 2日目の朝は近くにあった小さな山にみんなで登ってみました。


f:id:JunichiIto:20181230062304j:plain 最後の締めくくりは各人の成果発表会です!


f:id:JunichiIto:20181230062615j:plain あっという間の2日間もこれでおしまい。みなさんお疲れ様でした!

(写真提供:@tanaka4410@kazenomachi_@t_oginogin@spring_aki@jnchito

各人の学習テーマ等

前述の通り毎年この合宿では、2日間かけて自分が作りたいものを作ったり、勉強したい技術を勉強したりする「ロングもくもく会」をやっています。
また、RubyやRailsとある程度関連がある技術であれば、必ずしも「Rubyそのもの」を勉強しなくても構いません。
プログラミングスキルも不問なので、「超初心者です」という人でも「参加したい!」という気持ちさえあれば誰でも参加OKです。

今回はVue.jsやReactといったフロントエンド系JavaScriptの勉強や、自作Railsアプリの開発、RSpecの勉強をしている人がいました。

僕はというと、何か勉強をするというよりも、この合宿の直後に控えていたRubyConfに向けて、「プロを目指す人のためのRuby入門」の英語版サイトを作っていました。

https://ruby-book.jnito.com/en
f:id:JunichiIto:20181230065409p:plain

僕はサイトの作成途中で途中でCSSの組み方に迷って、他のメンバーにヘルプを求めたりしました。
こんなふうに、ハマったら誰かに助けを求めることができるのが、みんなで一緒に取り組むもくもく会のいいところですね。

まとめ

というわけで、このエントリでは先日開催した「Rubyプログラミングキャンプ 2018」の様子をあれこれ書いてみました。
参加してくれたみなさん、どうもありがとうございました!

最近はいろいろ忙しくて、西脇.rb&神戸.rbとしての活動は年1回の合宿ぐらいしかできてないのですが、この取り組みは今後も続けていくつもりですので、興味を持った方はぜひ来年のRubyプログラミングキャンプへ!

イベントの告知はDoorkeeperを使ってやっています。よかったら以下のページからメンバー登録をよろしくお願いします😃

西脇.rb & 神戸.rb | Doorkeeper

空気がカラカラ!コンビニない!Airbnbを勘違い!RubyConfでLAダウンタウンに行ってきました

写真で見るLAダウンタウン

僕が滞在していたのはカリフォルニア州ロサンゼルス(LA)のダウンタウンと呼ばれる街です。
「ダウンタウン」というと、普通の一般名詞っぽく聞こえるかもしれませんが、そういう名前の街(つまり地名であり、固有名詞)です。

あと、一般名詞としての「ダウンタウン」は「中心街」っていう意味があるらしいですね。
直訳して「ダウンタウン=下町?」みたいに考えないようにしましょう。
実際、LAのダウンタウンはビジネスの中心街みたいです。

Airbnbの宿からRubyConfの会場へ向かう道


RubyConf会場周辺の風景


何の建物かわからないけど、鏡みたいでキレイ


高いビルがたくさん


夜になるとこんな感じ

ダウンタウンで印象に残っていることベスト3

ここからはダウンタウンに滞在して印象に残っていることを3つ挙げてみます。
(どれもあまりいい思い出ではないので、ベスト3というよりもワースト3かも!?)

空気が乾燥しすぎ!!

LAに着いて一番ビックリしたのは、空気がめちゃくちゃ乾燥していたことです。
「日本の夏はジメジメして過ごしにくい」とよく言いますが、LAの街はその真逆で乾燥しすぎて過ごしにくかったです。

日本に住んでいると「乾燥しすぎ」と言われてもいまいちピンと来ないかもしれませんが、イメージとしては「ずっと微風のドライヤーを顔の手前で当てられているような感じ」です。
普通に呼吸をするだけで、鼻の中と喉の奥がヒリヒリしてきます。

ちょうど僕がLAを訪れた頃は山火事がずっと続いていて大変な時期だったんですが、「これだけ乾燥すれば、そりゃ山火事も消えへんわ」と納得してしまいました。

ちなみに余談ですが、行きの飛行機の中から山火事らしき煙が見えたりしました↓

あと、排気ガスのせいか(もしくは山火事のせいか?)、お世辞にも「空気がきれい」とは言えない環境だったので、数日で喉の調子が悪くなりました。

本当はずっとマスクを付けておきたかったんですが、アメリカ人は「マスクをしている人を怖がる」という噂を聞いていたので、LAでは「郷に入れば郷に従え」の精神でマスクは付けずに過ごしていました(Airbnbの宿に戻ったら毎日速攻で装着したけど)。

とりあえず、持っていって良かったものは第1位は保湿クリームです。
持っていけば良かったと後悔したものはのど飴です!

コンビニが全然ない!!

今年の7月は家族でハワイに行ってたんですが、ハワイにはABCストアというコンビニがいたるところにありました。

LAも大都会だし、コンビニはさすがにあちこちにあるっしょ〜!・・・と思った僕が大間違いでした💧

とりあえずダウンタウンに着いて、「まずはペットボトルの水を確保しよう」とコンビニを探したんですが、コンビニがぜんぜんっない!!
サブウェイみたいなファーストフード店はところどころにあるものの、コンビニは歩けど歩けどまったく見当たらず。
(コンビニもなければ、スーパーマーケットもない)

30分以上歩き回ってようやく、ビルとビルの隙間の暗くて分かりにくい場所に、ひっそりと1軒だけコンビニがあるのを見つけました。
(めっちゃわかりにくかった)

というわけでみなさん、(場所によるのかもしれませんが)アメリカは街中であってもコンビニがあるとは限らないので、十分気を付けましょう😣


ダウンタウンの街で初めてセブンイレブンを見つけたのは、4日目の昼でした・・・。

治安の面ではちょっと怖い

ロサンゼルスもめちゃくちゃ広いので場所によるとは思いますが、とりあえずダウンタウンの街は治安の面で若干不安を感じることがありました。
大きな通りを歩くだけならいいんですが、そこから一つ隣の通りを歩いたりすると、街並みや歩いている人の雰囲気が一変して、「あれ、ここは一体・・・??💧」みたいな気持ちになったりします。
そういえばホームレスの人もときどき見かけたりしましたね。

ちなみに、ダウンタウンの近くにはスキッド・ロウと呼ばれる「かなり危険な街」があるそうで、そこへは絶対に足を踏み込んではいけないと観光ガイドブックに書いてありました。
(僕の中ではスキッド・ロウ=懐かしのLAメタルバンドですが・・・)

スキッド・ロウ(紙ジャケSHM-CD)

スキッド・ロウ(紙ジャケSHM-CD)

別に、特別何か怖い目に遭った、ということはないのですが、観光の街だったハワイ・ホノルルに比べると、街を歩くのに若干緊張したところがあります。

Airbnbに泊まったのは・・・壮大な僕の勘違いだった😣

RubyConfに向かう前に書いたブログエントリで、僕はこんなことを書いていました。

続いて宿の確保ですが、これは会社のメンバーから「海外のホテルは高い割にイマイチなケースがあるから、Airbnbで取るのがいいよ」と言われました。


Airbnbを利用するのは初めてだったので、「スーパーホスト」と呼ばれる評価の高いホストの宿を選択しました。
また、移動で体力を消耗しないよう、会場に近い宿を選びました。
こちらは5泊6日(現地時間の11/12〜11/17)で7万7785円(1泊あたり約1万5000円)です。


id:koic さんはRubyConfの会場になっているホテルを予約して、1泊3万4000円程度だったそうです。
たしかに金額だけ見るとAirbnbの方が安そうですが、これだけでAirbnbに軍配を上げるのは時期尚早な気もします。
実際に泊まってみて、満足できるかどうかが大事なポイントですね。
 

RubyConf 2018に行ってきます 〜初めての海外カンファレンス参加&海外一人旅に向けた準備について〜 - give IT a try

というわけで僕は今回、一般的なホテルではなく、Airbnbに泊まったんですが、感想はというと・・・正直失敗だった気がします😣

空き家じゃなくて、ホストさんも一緒に住んでるマンションだった

というか、僕はAirbnbのことを完全に勘違いしていました。
僕の中では「Airbnb=空き家を貸し出すサービス」だと思ってたんですね。
以前に1回だけ、日本でAirbnbを利用したことがあるんですが、そのときも空き家に泊まりました(自分で申し込んだのではなく、僕はついていっただけですが)。

ですが、今回僕が借りたのはAirbnbのホストさんも普通に住んでるマンションでした。
あれれ?僕一人で泊まれるんじゃないの・・・??

一応、専用の個室は用意されているんですが、それ以外の場所はホストさんと共用なので、「赤の他人と一つ屋根の下で住んでいる感覚」が僕にはどうしても馴染めませんでした。

お友達と夜遅くまでおしゃべりされるのはご勘弁・・・

いや、これが「お互い別々の部屋に籠もって、ホストさんとはたまに顔を合わすだけ」だったら、まだ大丈夫だったかもしれません。
僕が一番面食らったのは、ホストさんが自分の友だちをリビングに呼んで、夜遅くまでガヤガヤと話し始めたことです。

僕が泊まっていた個室はリビングの脇を通っていかないと、バスルーム(トイレ+シャワー室)に行けません。
トイレやシャワーぐらい気軽にぱっと行きたいですが、僕が部屋から出たら確実にホストさんやお友達の目に止まります。

f:id:JunichiIto:20181228115857j:plain
雑に書くと部屋の配置はこんな感じ

彼らは陽気なアメリカ人なので、僕を見かけたら絶対「ハーイ、ジュンイチ!」と声をかけてきます。
いや、声をかけられても僕、何も話すネタはありませんし・・・。

しかし、お友達はいつまで経っても帰る気配はありません。
でも僕は慣れない海外生活で疲れてるし、シャワーを浴びてさっさと寝たい!
仕方がないので、意を決して僕は個室のドアを開けてバスルームに向かいました。

「ハーイ、ジュンイチ!」

あちゃー、やっぱり見つかった!

ホストさん「紹介するね、この子は私の友だちの〇〇〇だよ」

お友達「Nice to meet you!」

僕「Hi, nice to meet you too...」

Rubyプログラミングとか何か共通の話題があるならまだ雑談も続くかもしれませんが、全く相手のことを知らない初対面の人といきなり英語で雑談なんて、レベルが高すぎて僕には無理です。
しかも、僕は寝る直前で体力もほとんど残っていないし・・・。

Airbnbの滞在中、こんなことが2日ほどあり「あー、ヘタこいた〜!!」と僕はAirbnbの個室で頭を抱えていたのでした。
この宿泊スタイルは、旅行中も現地の人と積極的にコミュニケーションを取りたい人向けかもしれません。

Airbnbの答え合わせ:×「個室」○「貸切」

ちなみに僕はどうすればよかったのかというと、「貸切」と表示されている宿を選ぶべきでした。
僕が今回選んだのは「個室」だったので、「(ホストも一緒に住んでいる家の)個室」になってしまいました。(そんな仕組みだとは全然知らなかった・・・)

f:id:JunichiIto:20181228062108p:plain

しかし、当然同じ条件なら「個室」よりも「貸切」の方が高いので、そうなるとだんだんホテルに泊まるのと変わらなくなってくるかもしれません。
ホテルにしろ、Airbnbの貸切にしろ、部屋代が高くなるときは2人以上で泊まってみんなで割り勘するのが良い気がします。


僕が泊まったAirbnbのリビング。すごい、ここが使い放題!?と思ったら、ホストさんと共用でした・・・。

あと、余談ですが、Airbnbのホストさんは若い女性でした。
その点も「えっ、同居状態で泊まっても大丈夫なん?」と面食らったポイントの一つです。。

日帰りサンディエゴ観光

そんなこんなで、僕にとってのLAダウンタウンは、どちらかというとあまり楽しくない思い出の方が多い場所でした😓
(RubyConf自体は楽しかったけど、それはあくまでイベントの評価であって、ダウンタウンという街の評価とは無関係)

今回のRubyConfツアーはスケジュールがキツキツで、ほとんど自由に羽を伸ばす時間がなかったのですが、最終日だけフリーだったのでサンディエゴ観光をしてきました。
サンディエゴはロサンゼルスから車で3時間ほど離れた、カリフォルニア州最南端の街です。

f:id:JunichiIto:20181228103613p:plain

以下はサンディエゴの海岸沿いで撮った写真です。

海岸沿いの公園を散歩


現地では有名な?巨大なカップルの像


ベトナム戦争や湾岸戦争で活躍した空母ミッドウェイ


f:id:JunichiIto:20181228121637j:plain サンディエゴの夕焼け


サンディエゴの港に停泊するヨットと海岸沿いに立ち並ぶビル


サンディエゴの海岸沿いは、比較的のんびりした雰囲気で何かと緊張しがちだったダウンタウンの街よりも楽しく過ごすことが出来ました。
観光するならダウンタウンよりもサンディエゴですね。

でもなんでサンディエゴ?

僕がサンディエゴに向かったのは、実は「現地に住んでいる僕の親戚に会いに行く」という目的があったからです。

僕の祖父の兄は戦前にアメリカに移住しており、アメリカには血のつながった遠い親戚が住んでいます。
彼らはいわゆる「日系アメリカ人」になります。

日系アメリカ人 - Wikipedia

彼らとはFacebook等で今でもときどき交流しているので、今回RubyConfに行くついでに、彼らと会うことにしたのでした。

下の写真は現地で再会した僕の親戚たちです。



その他、お役立ち情報や所感など

さて、ここからは「初めての海外旅行」に嬉しい?お役立ち情報や、雑多な感想をあれこれ書いていきます。

持っていって良かったノイズキャンセリングヘッドホン

僕は飛行機の中の「ゴオーーッ」というエンジン音が気になってぐっすり眠れない人なので、試しにBOSEのノイズキャンセリングヘッドホンを買ってみました。

「本当に効くんかな?」と思いましたが、ノイズキャンセリング機能の効果は絶大でした!
完全に無音とまではいかないものの、音楽を流してしまえばほぼ無視できるレベルまでノイズが聞こえなくなります。

もともとは飛行機のエンジン音を聞こえなくするのが目的だったのですが、Airbnbの宿で「リビングで話し続けるホストさんとお友達の会話」を打ち消すのにも役立ちました(苦笑)。
さらに、帰りの飛行機では修学旅行の高校生軍団が隣に座ってきてうるさかったので、そのしゃべり声を聞こえなくするのにも役立ちました。

というわけで、ノイズキャンセリングヘッドホンは今回大活躍したアイテムの一つです。
ちょっとお高いですが、海外旅行中に静かにリラックスできる時間がほしい人はぜひ持っておくと良いと思います。

飛行機で使う場合はアダプタの購入をお忘れなく!

ちなみに、僕が乗ったJALの787はヘッドホンジャックがこんなふうに二股に分かれているタイプだったので、機内の映画等をノイズキャンセリングヘッドホンで聴きたいときは事前にアダプタを購入しておく必要がありました。飛行機にマイヘッドホンを持ち込みたい場合はご注意ください。


Lyft/Uberはめっちゃ便利

飛行場からダウンタウンまでの移動にLyftを利用しました。
あと、RubyConf後に日本人エンジニア同士で晩ご飯を食べた後に、レストランからAirbnbの宿へ移動するのにUberを使いました。
(このときは体力的にくたびれていたのと、夜道を一人で歩いて帰るのがちょっと不安だったので)

LyftやUberはめっちゃ便利ですね!
スマホで事前に行き先が指定できて、料金や到着予定時刻も事前にわかるので、便利なことこの上なかったです。

飛行機からダウンタウンまでは、シェアライドっていうのかな?他のお客さんと相乗りしていくタイプを選んだんですが、これも特に困ることなく、お得に移動することができました。

ちなみに、LyftやUberのアカウント登録にはSMS認証が必要になるので、日本にいる間に事前にアカウント登録を済ませておくのが良いと思います。

現地の通信はauの世界データ定額を利用した

今年の夏にハワイに行ったときはイモトのWifiを使ったんですが、今回のアメリカ旅行ではauの世界データ定額というサービスを利用してみました。
1日980円で24時間、現地の回線を使ってデータ通信ができるようになるサービスです。

ただし、料金的には上記の980円に加えて、日本の契約プランと同じデータ通信料金がかかります。
イメージ的には毎日980円の追加料金を払って、日本と同じ料金プランを海外で使い続ける、みたいな感じです。

世界データ定額(2020年2月1日より新コース登場!)| 海外で使う(au世界サービス) | au

専用ルーターを借りたり、SIMを差し替えたりする必要がなかったので、「すごく手軽」という意味では悪くないサービスでした。
料金的にもこれぐらいなら許容範囲かな〜と思います。

飛行機の中でもWifiを利用してみた

最近では飛行機の中でもWifiが使えるようになったみたいです。
そこで今回、試しにこのサービスを利用してみました。

料金は24時間で18.8ドル(約2080円)です。
機内でクレジットカードを使ってオンライン決済できます。

Wi-Fiのご利用(国際線 機内Wi-Fiサービス)(機内・ラウンジ) - JAL国際線

感想は・・・うーん、遅い。
飛行機の中でWifiが使えるだけでもすごい!という見方もできますし、実際ネットが使えるのは大変ありがたいのですが、画像がたくさん使われているサイトやYouTubeの類いはほとんど使い物になりませんでした。(3G回線ぐらいのイメージ?)

それなりの利用料金を取られるので、もうちょっと速くしてもらうか、それが無理なら半分ぐらいの値段にしてほしかった、というのが正直な感想です。
今後の発展に期待、という感じですね。

余った小銭をゼロにする方法

ハワイに行ったときもほとんど現金を使わなかったので、今回は100ドル(約1.1万円)だけ日本で両替して持っていきました。
が、予想通りほとんど現金は使いませんでした。

「どうしようかなー、このまま日本に持って帰っても仕方ないんだよな〜」と思っていたんですが、実はこんな方法で小銭をゼロにすることができました。

空港の土産物屋さんで買い物をする
 ↓
先に現金で払う
 ↓
現金で足りなかった分をカードで払う

レジで "I would like to pay by cash first, then pay by card. Okay?" みたいに質問したら、すんなりOKがもらえたのでこれは便利です。
帰国直前に現金が余って困っている人はぜひ試してみてください。

f:id:JunichiIto:20181228101638j:plain
それにしてもアメリカの小銭はどれがいくらなのか、見分けるのがめっちゃ難しい・・・。

テスラがたくさん走ってた

証拠になるような写真は撮ってないのですが、アメリカの街では高級電気自動車(という呼び方でいいの?)のテスラをよく見かけました。
日本ではまだまだ珍しい車だと思いますが、アメリカだと「あ、テスラ!」「またテスラだ」というぐらい、1日に何度もテスラが走っているのを見かけました。

アメリカでも高級車であることは間違いないのですが、アメリカの中では一応「国産車」になるので、日本よりは気軽に買いやすいんでしょうね〜。

Tesla

まとめ

というわけで、このエントリではRubyConf 2018に参加するために訪れたLAダウンタウンと、サンディエゴ観光の話をあれこれ書いてみました。

今回はあまりスケジュールに余裕がなかったので、観光もちょこっとしかできませんでしたが、本当はもっといろんなところに足を運びたかったです。
できればロサンゼルスの大きなギター屋さんにも行ってみたかったんだけどな〜。
まあ、それは次回以降の楽しみにしておきます。

みなさんも海外のテックカンファレンスに参加するときは、今回書いたようなエントリの内容も参考にしてもらえると嬉しいです。
Let's try 海外カンファレンス!

あわせて読みたい

RubyConfやハワイ旅行関連のエントリです。
こちらもあわせてどうぞ〜。

RubyConf 2018で初英語LTしてきました 〜登壇の準備から当日話した英文まで全部公開します!〜

はじめに

以前もこのブログでお伝えしましたが、僕は2018年11月にロサンゼルス(LA)で開催されたRubyConf 2018に参加しました。

上記のエントリにも書いたとおり、僕は2日目に開催されたLT(ライトニングトーク)大会に参加して発表してきました。
LTではあるものの、これは僕にとって初めての英語の登壇でした。

このエントリでは、発表内容の詳細や発表に至るまでの準備、英語で発表するときのポイントなど、もしみなさんが英語で発表することになった際に役立つ情報をまとめてみます。

f:id:JunichiIto:20181217052625j:plain
RubyConf 2018でLT中の僕(Photo by Kazumi Karbowski)

LTに参加しようと思ったきっかけ

RubyConf 2018への参加費用は僕が勤めているソニックガーデンに補助してもらいました。
そのときに会社のメンバーから「じゃあ、来年はRubyConfに登壇することが補助の条件ね」と冗談半分(いや、全部本気?)で言われました。

ただし、「来年のRubyConfでは登壇者になってね」と、なかなかハードルの高い条件を付けられております(ひー😂)。

RubyConf 2018に行ってきます 〜初めての海外カンファレンス参加&海外一人旅に向けた準備について〜 - give IT a try

この話をブログに書いたところ、Rubyコミッタの笹田さんから「LTに出てみたらどう?」と提案されました。

最初は「えー、そんなの無理無理!!」と思ったんですが、RubyConfが近づくにつれ「アメリカに行く機会なんてそんなにないし、LTは現地で申し込めるみたいだし、いっちょ清水の舞台から飛び降りてみるか」と考えるようになりました。

LAに到着してから準備を開始

さて、なんとなく「LTをやってみよう」とは思っていたものの、10月〜11月はかなり多忙でまったく何も準備できないまま飛行機に飛び乗りました。
以下に登壇までの準備作業を書いていきますが、この準備はどれもLAに着いてから始めたものです。

過去の動画を見てLTの雰囲気を確認

RubyConfは毎年、すべての発表が動画としてYouTubeにアップされています。
LT大会の動画もYouTubeにアップされているので、まずこの動画をチェックしてどんな内容がLTとして発表されているのかをチェックしました。

RubyConf 2017: Lightning Talks - YouTube

この動画を見る限り結構「何を話しても自由」という印象で、中にはまったくRubyと関係ない話をしている人もいました。
なので、僕も自由にテーマを決めて問題なさそう、という確信を得ました。

登壇テーマは日本の講演内容を英語に焼き直すことに決定

英語で発表するのはいろいろハードルが高いので、ゼロからテーマを考えるよりも、過去に日本語で発表した内容を英語に直す方が簡単そうです。
また、コードがたくさん登場する発表の方が伝わりやすそうですし、LTだったら多少笑いが取れる話の方が向いてるかな〜とも思ったりしました。

そんなふうに考えた結果、今回は今年1月にRuby関西で発表した「プロを目指す人のための例外処理(再)入門 」という話がピッタリかも?と判断し、このスライドの内容をLT向けに短く再編集することにしました。


再び過去のRubyConfの動画をチェック

それからもう一度、過去のRubyConfの動画をチェックしました。
ただし今回はLT以外の動画も含めて視聴しました。

RubyConf 2017 - YouTube

目的は英語っぽい言い回しや、発表のスタイルを研究するためです。
また、日本人の発表も視聴して、日本人とネイティブの英語の話し方の違いみたいなものもチェックしてみました。

スライドを作成

インプットとして必要な情報はだいたい収集したので、次はアウトプットです。
今回は前述の日本語スライドをベースにして、英語版のスライドを作っていきました。

僕は普段スライドのテキストは少なめにして、口で話す内容を多めにする、というスタイルを取っているのですが、英語版では日本語版よりもテキストを多めに入れました。
これは発表当日に頭が真っ白になっても、スライドの内容を口に出して読めば何とか前に進めるようにするためです。
また、僕の英語の発音が悪くても、現地の人はスライドをみれば内容がわかる、という効果も狙っています。

(英語版のスライドはのちほどお見せします)

口に出して何度も練習する

スライドができたら次は練習です。
これは英語も日本語も同じですね。

特にLTは5分間という制限時間があるので、オーバーしないように気を付けなければいけません。
日本語に比べるとしゃべるスピードはさすがに遅くなってしまうので、かなり内容を削らないと5分に収まりませんでした。

また、英語っぽい抑揚の付け方も意識してみました。
日本人が英語を話すと、平坦でボソボソしたしゃべり方になりがちなので、できるだけ大きな声で、なおかつオーバーなくらい抑揚を付けて話す練習をしていました。

また、今回はちょっと無理でしたが、できればネイティブの友人にも聞いてもらってフィードバックをもらうのが理想的ですね。

LTに(急いで)申し込む

LAに来てから慌てて準備したものの、だいたい準備が整ったので、いよいよLTの申込みです。
聞くところによると、毎年LT大会はあっという間に定員が埋まってしまうみたいです。

申込みは2日目の基調講演が終わった後に、受付付近にあるボードに自分の名前を書き込む方式です。そして、早く名前を書き込んだ人から順に発表していきます。

LT大会の全体の時間は1時間半で、ボードに名前を書き込んでいても1時間半経ったところで打ち切られます。
何人ぐらい発表できるのか受付の人に聞いたところ、「そうねー、全部で20人ぐらいじゃないかなー」と言っていました。

せっかく準備したのに発表できずに帰るのは残念すぎるので、基調講演が終わった直後に受付へダッシュしました。
結構急いで駆けつけたつもりだったんですが、僕は14番目でした。

f:id:JunichiIto:20181216083507j:plain

僕はなんとか間に合いましたが、秒速さんとkoicさんは出遅れてしまったようで(28番目と29番目)、お二人の出番が回ってきませんでした・・・。(残念😣)

ちなみに当日、最後の出番が回ってきた人は18番目の方でした。(僕も危なかった!)

こんなふうに英語で話しました

というわけで、こちらが今回作成した英語のスライドです。

実際どんな内容をしゃべったのか、以下で英語と日本語訳をスライドとともにご紹介します。


f:id:JunichiIto:20181216070149j:plain
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を楽しんでますか?おお、いいですね。僕も楽しんでます!さて、今日は「アンハッピーな例外処理」についてお話しします。しかし、英語で発表するのは今回が初めてです。なので、これは僕にとって大きなチャレンジになりますが、がんばってやってみます。


f:id:JunichiIto:20181216070155j:plain
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です。大丈夫ですね?


f:id:JunichiIto:20181216070201j:plain
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・・・。これでいいんですかね?ダメですよね。


f:id:JunichiIto:20181216070206j:plain
But, some years ago...

ですが、何年か前に・・・


f:id:JunichiIto:20181216070211j:plain
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" 「ん?何ですかこれは?」彼はこんなふうに答えました。「これねえ、しょっちゅう出てくるんですよ。だから、こうやって繰り返し保存ボタンをクリックするんです。カチカチカチカチカチッ!!」


f:id:JunichiIto:20181216070215j:plain
Oh, really??

げえっ、マジで!?


f:id:JunichiIto:20181216070220j:plain
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節が入っていました。これが「アンハッピーな例外処理」です。この例外処理は単にエラーコードを表示するだけなので、通知も来ず、ログも残されません。ですから、エラーが起きてもまったく気づけません。不運なことに、ユーザーはこんなイケてない手順書を作っていました。「もしこのエラーが起こったら、再試行を繰り返すこと。」いやいや、再試行しないで!お願いだから僕たちに連絡してください。調査の結果、この問題の根本原因がわかりました。デッドロックです。ひどいテーブル設計のせいでデッドロックが頻発していたのです。みなさんは主キーが全くないテーブルを見たことがありますか?---ない?ですよね。


f:id:JunichiIto:20181216070225j:plain
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エラーページを表示したり、ログを残したりしてくれます。メンターをつかまえてコードの設計について相談することを検討してください。みなさん、「ハッピーな例外処理」を書きましょう!


f:id:JunichiIto:20181216070230j:plain
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のアカウントもあります。


f:id:JunichiIto:20181216070235j:plain
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テスト入門」という電子書籍を翻訳しました。みなさん、この本は知っていますか?すばらしい。この本を翻訳したんです。


f:id:JunichiIto:20181216070239j:plain
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さんが「本書の刊行に寄せて」のメッセージを書いてくれました。現在英語版の出版社を募集中です。もし関係者の方をご存じでしたら、その方を僕に紹介してください。


f:id:JunichiIto:20181216070245j:plain
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

完璧な英語ではありませんが、できるだけ抑揚を付けたり声色を変えたりして、平坦でボソボソしたしゃべり方にならないように心がけたつもりです。いかがでしょうか?

発表の反応

前述の通り、今回の発表は少し笑いを取ろうとしていました(爆笑ではなく、あくまで少しです)。
英語で話してうまく伝わるかどうか不安でしたが、まあまあウケたんじゃないかと思います。

また何人かの現地のエンジニアさんから「面白かったよ」「初めてには見えなかった」といった感想をいただきました。(やった!)

LTの真の目的(?)「プロを目指す人のためのRuby入門」の英語版を出すという野望

今回の発表では、最後に「プロを目指す人のためのRuby入門の英語版を出したいので、誰か関係者を紹介して!」とお願いを入れました。
ダメもとのお願いだったんですが、現地エンジニアさんの中に1人、「知り合いがいるからちょっと聞いてみてあげる」と言ってきてくれた人がいて、ビックリしました。
ただ、その知り合いの方の会社ではIT関係の技術書は取り扱っていなかったみたいで、結局話を進めることはできませんでした。残念〜。(でも話をしてくれたのはありがたい!)

ちなみに、「プロを目指す人のためのRuby入門」は本気で英語版を出したいと思っているので、英語版の著者ページも作っています!

Introduction to Ruby Programming for Future Professionals
f:id:JunichiIto:20181216091834p:plain

まとめ

というわけで、このエントリではRubyConf 2018で初めて英語でLTした話をいろいろ書いてみました。

登壇する前は英語で発表なんて自分にできるのか!?と不安に思っていましたが、実際にやってみると意外となんとかなりました。
もちろん、日本語で発表の準備をするよりも時間はかかりますが、時間さえかければLTでない普通の発表でもなんとかなるんじゃないかという気がしてきました。
(ただし、質疑応答の時間にネイティブの人から早口で質問されたりしたら、ちょっとテンパるかもしれませんが・・・)

みなさんももし、僕と同じように英語で発表する機会がやってきたら、今回のエントリを参考にしてもらえると幸いです😃

あわせて読みたい

RubyConf 2018全体の参加レポートはこちらのエントリにまとめてあります。

「伊藤さんはいったいどんな英語の勉強をしてきたの?」「僕は英語が苦手なんだけど、どんな勉強をしたらいいの?」という方は、こちらのエントリを読んでみてください。

英語っぽい抑揚の付け方(緩急の付け方や声色の高低、強弱など)については、こちらの動画が参考になるかもしれません。
(ジョーク動画として作られていますが、英語の勉強教材としてはなかなか良いですw)

ウィル・スティーヴン 「頭良さそうにTED風プレゼンをする方法」

あと、僕は普段「ジリアン・マイケルズ」のDVDを見ながらトレーニングしているので、発音や抑揚の付け方はこのDVDに出てくるジリアン先生のしゃべり方にも影響を受けています。
別にこのDVDである必要はありませんが、海外の映画やドラマなどを普段から見ておくと、いざというときの登壇や英会話に役立つかもしれません。

ジリアン・マイケルズの30日間集中ダイエット [DVD]

ジリアン・マイケルズの30日間集中ダイエット [DVD]

おまけ