タイトルどおりのTipsです。
ケルヒャーのホース、どれだけがんばっても抜けないときはありませんか？
ここでいうホースは本体とノズル側をつなぐ黒い部分のホースです。（下の写真参照）
そんなときは、水道の元栓を閉め、電源はつないだ状態で、ノズルから水が出なくなるまで水を出し切りましょう。
水が入っている間は水圧の関係でホースが抜けませんが、水がなくなると簡単にホースが抜けるようになります。
・・・というのを知らなくて、さっき、死ぬほどがんばって「抜けないっ！抜けない～～～～っ！！！！」とケルヒャーと死闘を繰り広げていました。
（メーカーもひとこと本体に書いてくれたらいいのに・・・）
今までも何回か苦労した記憶があるので、今度からはちゃんと水を出し切ってからホースを抜くようにします！
KARCHER (ケルヒャー) 高圧洗浄機 K2.400 ハイパワー コンパクト
Qiitaに「【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法」という」記事を書きました。
この記事はざっくりいうと、こんなRSpecのコードよりも、
describe 'キャンセル処理' do let(:user) { create :user } let(:reservation) { create :reservation, user: user, start_at: '2017-08-10 10:00'.in_time_zone } context '24時間前をすぎるとキャンセル料が発生する' do before do travel_to '2017-08-09 10:00'.in_time_zone reservation.cancel! end after { travel_back } let(:billing) { user.billings.first } it { expect(user.billings.count).to eq 1 } it { expect(billing.amount).to eq 500 } end end
こんなコードの方がいいよね？というお話です。
describe 'キャンセル処理' do let(:user) { create :user } let(:reservation) { create :reservation, user: user, start_at: '2017-08-10 10:00'.in_time_zone } context '24時間前をすぎた場合' do before do travel_to '2017-08-09 10:00'.in_time_zone end after { travel_back } it 'キャンセルするとキャンセル料が発生する' do reservation.cancel! expect(user.billings.count).to eq 1 billing = user.billings.first expect(billing.amount).to eq 500 end end end
「えっ、なんで？」というその理由はQiita記事の中に詳しく書いてあるので、そちらを参照してください！
一時期は僕もletやbeforeやsubjectをあれこれ駆使して、DRYでカッコいいテストコードを書こうとしていました。
しかし、最近はそういったテストコードはやめて雑にコードを書くようにしています。
RSpecの機能を駆使しまくって書いたテストコードは書くのにも時間がかかるし、書いてからしばらく時間が経つと、ぱっと見てよくわからなくなるし、新しいテストコードを追加するときも「これ、どこに追加したらいいんだ・・・？？」と迷いがちになります。
なので結局、現在は「愚直にベタ書きして上から下に素直に読めるコードを書くのが一番いいや」という考えに至っています。
まあ、RSpecの機能を使った方が効率が明らかによくて可読性や保守性も落ちない、というときは、RSpecの機能も積極的に使うんですけどね。
そのあたりの話は以前書いたこちらのQiita記事に書いてあります。
そういえば今回書いたのはおよそ2ヶ月ぶりのQiita記事でした。
この夏は本の出版準備やらなんやらでバタバタしてたので、ブログやQiitaを書く時間があまりなかったんですよねえ。
とはいえ、別に書くのをやめたわけじゃないので、書くネタと書く時間ができたらまたなんか書きます。
よかったら僕のQiitaアカウントもフォローしてやってくださいね〜。
Qiita記事の中で使ったArrange、Act、Assert（AAA）は先日読んだ「Effective Testing with RSpec 3」に載っていたテストコードの原則です。
本で学んだ知識をさっそく実戦で使ってみましたw
昨日、「こんな洋書を読んだよー」っていうブログを書いたら、Twitterでこんな質問をもらいました。
どのように洋書を読んでいますか？
— urimaro (@urimaro) 2017年9月11日
読み切るのにどれくらいかかりましたか？
洋書を読むと和書より頭に残らないことが多いので、ぜひ参考にしたいです。
どれだけ役に立つかわかりませんが、140文字で返信するには短すぎるのでこのブログに返信を書いてみます。
ここでいう「洋書」とは、「英語で書かれたプログラマ向けの技術書」のことを指します。
質問主のurimaroさんは「洋書を読むと和書より頭に残らないことが多い」とおっしゃっていますが、その感覚は僕もわかります。
英語はそこそこ得意とはいえ、母国語と同じレベルで英語を読めるほど僕の英語スキルは高くないです。
わかりにくい表現かもしれませんが、日本語を読むときって写真を撮るように文章が読めるんですよね。
ページを開いてその瞬間に目に飛び込んできた文字で、だいたい内容が把握できる感じです。
もちろん詳細はしっかり読まないとわからないんですが、ざっくりした内容はページを上から下にざーっとスキャンするだけで理解できる気がします。
洋書だとそういう読み方をするのはちょっと難しいです。
昔に比べると多少できるようになってきましたが、日本語の本に比べるとまだまだです。
「頭に残る、残らない」もこの理由に近いのかなーと思ったりします。
日本語は読むというより、「見る」だけで頭に入る、頭に残る。（写真を撮って脳内のアルバムに残すように）
英語はそうはいかない（ので、頭に残りづらい）。
もちろん英語でも100%抜け落ちていくわけではないですが、「洋書を読むと和書より頭に残らない」というのは僕も同感です。
読み切るのにかかる時間はまちまちですねー。
これは洋書・和書に関係なく、です。
速い、遅いは次のような条件によって変わってきます。
はい、当たり前の話ですね。
先日読んだ「Effective Testing with RSpec 3」の場合は、RSpecに関する予備知識はすでにあるし、もともと書評を書くためだったので、ばーっと読みながら「この内容をブログに書こう」というポイントを探していく感じでした。
なので、さっきの条件でいうと「速い x 速い」になるので、結構速く読み終わりました。
具体的には土日の2日間、トータルで7-8時間ぐらいです（それでもまあまあかかってるか）。
予備知識がない技術書を読むときなんかは、日本語の本でも読むのは遅いです。
（だから、まだ読み切ってない技術書が何冊かあります・・・）
洋書の読み方については昨日のブログでもちらっと書いたんですが、「全部理解しようとせず、多少わかりにくい内容があってもどんどん読み進める」というのが一番のポイントかな、と思っています。
そりゃもちろん全部理解するのが理想的ですが、一般的な日本人は和書と同じレベルで洋書を理解するのは無理です。
「細かいところはわからないけど、だいたい6割ぐらい理解できてるかなー」と思えれば、とりあえずは十分なんじゃないでしょうか。
知らない単語が出てきたときも、最初は調べずにとりあえず読み進めていくと、何度か同じ単語に遭遇するうちに、「あー、たぶんこんな意味なんだろうなあ」というのがだんだんつかめてきたりします。
「結構頻繁に登場するし、何度遭遇してもまったく意味の予想がつかん」というときだけ、辞書を引いて意味を調べます。
あと、日本語でも同じですが、文章の読みやすさはその本を書いた人によって変わってきます。
「1文をやたら伸ばしたがる人」や「慣用句っぽいフレーズをやたら織り交ぜてくる人」の文章は読みにくいです。
何冊か洋書を読んでいると、「あ、この人の英語はわかりやすいな」とか「うーん、この人の英語は非ネイティブにはちょっと厳しい・・・」みたいな感じで、著者のクセが見えてきます。
1冊目に運悪く「読みにくい英語を書く人」にあたると不運ですが、めげずに何冊か読んでいくと「あ、この洋書はなんかわかりやすいぞ」という洋書にめぐりあえるかもしれません。
とはいえ、技術書に登場する単語や言い回しはだいたいよく似たものが登場します。
GitHubのREADMEが理解できる人なら、洋書もだいたい理解できるはずです。
特に、コードがたくさん載ってれば載ってるほど、理解しやすくなりますね。
上から下へと順に読まずに、先にコードを読んでから前の文章に戻る、という読み方もよくやります。
なんかまとまりのない話になっていますが、どんなふうに洋書を読んでるかなーと考えたときに思い浮かぶ話はこんな感じです。
「でもやっぱり英語で読むのはいやだなー。あの技術書が日本語に翻訳された嬉しいのになー」と思う人も多いかもしれません。
ただ、翻訳は翻訳で「翻訳の質」が翻訳者によって大きく異なるのが難点です。
僕も「日本語版が出てるなら、日本語版でいいかー」と思って日本語に翻訳された技術書を読むときがありますが、たまに「うわ、これはつらい・・・」と思う翻訳に出くわすことがあります。
わかりづらい翻訳を連発されると、「うーん、原著を買うべきだったかな」と思ってしまいます。
僕が思うに、受験英語っぽい訳し方（長文を後ろから前へ訳すような訳し方）になっている日本語訳は非常に読みにくいですね。
あと、「もしかしてこの人、ふつうに日本語で文章を書かせてもあまり文章がうまくないのでは？」と思うケースもときどきあります😓
全部が全部、とは言いませんが、「普段はふつうに現場でコードを書いてる技術者ですが、今回初めて翻訳にチャレンジしてみました！」みたいな人が翻訳をしている場合は、読みにくい翻訳になっていることが多い気がします。
逆に「昔から何冊も技術書を訳しているプロの翻訳者」だとハズレを引く可能性が少ないです。
個人的な感想だと、長尾高弘さんという方が訳した技術書はどれも読みやすくて、「さすがプロの仕事だなあ」といつも感心しています。
というわけで、このエントリでは洋書の読み方について、思うところをあれこれと書いてみました。
思いついたことをつらつら書いていっただけなので、あまりまとまっていませんが、いくつか参考になる部分が見つかれば幸いです。
和書に比べると洋書はニッチな技術書がたくさん出版されているので、技術者の人は絶対洋書が読めた方がお得です！
「この技術は気になるな－。でも日本語の本はまったく出てないんだよなあ」と思うときは、ぜひ洋書にチャレンジしてみてください。
「この技術が知りたい」というモチベーションさえあれば、なんとかなるはずです。
もし、洋書を読んでいて行き詰まりを感じたら、僕が今回書いたような話が参考になるかもしれません。
最後は経験がモノを言う、みたいなところもあるので、1冊で挫折せずに何冊も読んでみるのがいいと思います。
がんばって「翻訳を待たずに洋書が読める技術者」を目指しましょう！
昨日書いた「Effective Testing with RSpec 3（洋書）」の書評です。
blog.jnito.com
「そもそも基本的な英語力が低いんです」という方は、このエントリを読むと参考になりそうな情報が載っているかもしれません。
blog.jnito.com
僕はもともと英語は得意な方でした。なんで得意なのかはこのエントリに書いてあります。
blog.jnito.com
