そこまで熱烈なファンというわけではないけど、CHEMISTRYのライブに行ってみたら

昨日、妻と一緒にCHEMISTRYのライブに行ってきました。

「へ～、ライブに行くぐらいCHEMISTRYが好きなんだ」って思われるかもしれませんが、実は熱狂的なファンというわけではありません。
僕も妻も知ってるのはシングル曲ばかり、しかも初期のシングル曲ばかりで最近の曲はほとんどわかりません。

ただ、車の中や家の中でBGMとしてかける機会が多く、妻も僕も「（他の曲はよく知らんけど）よく聴く曲は大好き」なので、試しに一度ライブに行ってみようと思い、チケットを購入しました。

・・・が、チケットを買ったのが半年前の8月で、かなり日が空いたために若干熱が冷めてしまい、「あー、そういえば今日がライブの日かあ。まあ、チケット買ったし、もったいないから行くか」というかなり低いテンションで会場に向かいました。
僕も妻もこんな低いテンションでライブに足を運ぶのは初めてです（ファンのみなさん、すいません💦）。

で、感想はだったかというと・・・、

すごかった！感動した！！行って良かった！！！

いやあ、あの二人、めちゃくちゃ歌がうまい。
もちろん、プロだから当たり前と言えば当たり前なんですが、たまに「あれ、CDの方がなんかうまい・・・」みたいなアーティストもいるじゃないですか。
でも彼らは完璧だった。
いや、むしろ、CDよりも迫力があって熱がこもってて、CDで聴くよりもずっと良かった。

そして二人のハモりも完璧。
めっちゃ気持ちいい。

すごい声量だし、あんなにいっぱい歌ったら最後の方は声が枯れるんじゃないかと思うけど、最後まで安定した歌唱力でした。
いったいどんなトレーニングしたら2時間半も完璧に歌い続けられるんだ・・・。

あと、CDで聴くと、どっちの声がどっちがわからなかったけど、ライブで聴くとどっちが歌っているのが明らかなので、声の聞き分けができるようになりました。
少し太くて男らしさを感じる方が川畑さん。
少し細くて若干甲高さを感じさせる方が堂珍さん。
はい、覚えました。
まだわからないときがたまにあるけどw

MCも「近所のお兄ちゃん」っぽい気さくな感じで、それはそれですごく親しみやすさを覚えました。
特に堂珍さんのトークが少し天然っぽい感じで面白かったです。

ボーカルの二人だけでなく、バックバンドの演奏もタイトですごく良かった。
ライブに行く前は「もしかしてライブはカラオケ？」とか思ったけど、ちゃんとバンドが生演奏してました。
僕は楽器を弾く人なので、歌だけでなく演奏の方にもしっかり耳を傾けるんですが、みんな上手かった（当たり前か）。
あー、僕もあれぐらい弾けるようになりたい・・・。

冒頭でも書いたように基本的に初期のシングル曲しか知らない人なので、知らない曲もたしかに多かったですが、有名どころのシングル曲はちゃんと全部歌ってくれたし、歌と演奏が素晴らしいので知らない曲も普通に楽しめました。
MCでも「初めて来た人も楽しめるように、いろんな曲を歌います」と語ってくれて、僕らのようなライトなファン（？）のこともちゃんと考えてくれているのが嬉しかったですね。

ライブの評価は結構辛口な僕の妻も「めっちゃ良かった！！」と、むしろ僕以上に感動していました。
今日は大阪でライブをやっているので、今日も見に行きたいそうです（笑）。

というわけで、そこまで熱烈なファンでなくても、CHEMISTRYのライブはすごく楽しめるということがわかりました。
生の演奏と生の歌声の方がCDよりも圧倒的に素晴らしいので、（熱烈なファンでない）みなさんも機会があれば行ってみてください！

参考： CHEMISTRY ＠ たつの市総合文化会館 赤とんぼ文化ホール 大ホール (兵庫県) (2018.03.03) | ライブ・セットリスト情報サービス【 LiveFans (ライブファンズ) 】

CHEMISTRY TOUR 2012-Trinity-(初回生産限定盤)(DVD付)

Rails 5.1とRSpec 3.6に対応した「Everyday Rails - RSpecによるRailsテスト入門」をリリースしました

お待たせしました！
ついに「Everyday Rails - RSpecによるRailsテスト入門」（以下Everyday Rails）の改訂版をリリースしました。
すでに日本語版Everyday Railsを購入されている方は、Leanpubのサイトにログインして最新版の電子書籍ファイルを無料でダウンロードすることができます。

このエントリでは今回アップデートされたEveryday Railsの内容を紹介します。
また、価格改定の予告も含まれているので、まだ購入されていない方はそちらもご一読ください。

Everyday Rails - RSpecによるRailsテスト入門 | Leanpub

改訂版の3大変更点

変更点その1：Rails 5.1 + RSpec 3.6に対応

これまではRails 4.2 + RSpec 3.1を対象にしていましたが、改訂版ではRails 5.1 + RSpec 3.6が対象になっています。

移り変わりの速いRailsの世界では最新のgemに追従しないとあっという間に情報が古くなってしまうので、アップデートを心待ちにしていた方も多いと思います。
これでもう安心ですね😄

ちなみに現時点のRSpecの最新版は3.7なので、少しだけ古くなっています。
ですが、RSpec 3.7で導入されたシステムスペック（System Spec）については原著者のAaronさんがご自身のブログ記事でサポート情報を載せてくれています。
こちらの記事も後日翻訳して、このブログに載せる予定です。

2018.3.12追記：ブログ記事を翻訳しました！

上記のブログ記事を翻訳しました。
フィーチャスペックからシステムスペックへ移行する手順については、こちらの記事をご覧ください。

変更点その2：サンプルアプリケーションの変更

これまでは顧客管理アプリケーションがサンプルアプリケーションになっていましたが、改訂版ではプロジェクト管理アプリケーションに変わっています。

従来の顧客管理アプリケーションと同様、プロジェクト管理アプリケーションも非常にシンプルなRailsアプリケーションですが、ファイルのアップロードやJavaScriptを使った更新機能など、実践的なテストコードを書くための機能が用意されています。

プロジェクト管理アプリケーションのスクリーンショット

参考：サンプルアプリケーションのソースコード

ソースコードはGitHubで公開されているので、自分のローカル環境で動かすことができます。

ちなみに、このアプリケーションで"bundle install"を実行すると以下のようなエラーが出るかもしれません。

$ bundle install
Fetching gem metadata from https://rubygems.org/............
Fetching https://github.com/thoughtbot/shoulda-matchers.git
fatal: Could not parse object '0b2e0da6035b9c45b0430bc6eb9a8bab4aeba50e'.
Git error: command `git reset --hard 0b2e0da6035b9c45b0430bc6eb9a8bab4aeba50e` in directory
/Users/jit/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/bundler/gems/shoulda-matchers-0b2e0da6035b has failed.
If this error persists you could try removing the cache directory
'/Users/jit/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/cache/bundler/git/shoulda-matchers-e04e9ade87805b3667f97d976fd84556605e66f8'

このエラーが出たら以下のコマンドを実行して、shoulda-matchersをアップデートしてください。

$ bundle update shoulda-matchers

変更点その3：本文の大規模なリライト

RailsとRSpecの対象バージョンが変わり、さらにサンプルアプリケーションも変更されたので、当然本文も大きく変わってきます。
それだけでなく、以下のような変更点も本文に反映されています。

• 使用する周辺gem/ライブラリのアップデート
  • 例：ヘッドレスChromeの使用
• 昨今のトレンドの反映
  • 例：コントローラスペックよりもフィーチャスペックやリクエストスペックを重視する
• 著者（Aaronさん）が最近よく使うツールやテクニック
  • 例：FactoryGirl/FactoryBotのトレイト（trait）

その結果、本文の内容は7～8割リライトされています。
なので、これはほとんど新しい本と言っても過言ではありません！

前半は従来の文面を再利用した箇所が比較的多いですが、後半に進むにつれ、新しいトピックがどんどん増えてきます。
以前の版には載っていなかったテクニックもたくさん登場するので、ぜひ一通り読んでみてください！

なお、このエントリの最後に改訂版のもくじを載せているので、興味がある方はそちらも参考にどうぞ。

アップデート手順

すでにEveryday Railsを持っている方は以下の手順でアップデートできます。
（もちろん無料です！）

1. Leanpubにログインする
2. ライブラリページに移動する
3. 購入済みの書籍一覧からEveryday Railsを選択する
4. "Download this book"欄から電子書籍ファイルをダウンロードする

注：これは英語版Everyday Railsをダウンロードする画面です

さらに：3月中にもう一度アップデートする予定です

改訂版の翻訳は一通り完了していますが、2018年3月中にもう一度アップデートする予定です。
ただし、次のアップデートでは翻訳の品質向上や誤字脱字の修正（もしあれば）など、日本語のブラッシュアップが中心になります。

内容自体は変わりませんし、現時点でも普通に読む上では問題がないため、それほど気にしなくても大丈夫です。
（改訂版は複数のエンジニアにレビューしてもらい、報告されたフィードバックは一通り対応しています！）

さて、ここまではEveryday Railsをすでに持っている方に向けた情報を書いてきましたが、このエントリを読んでいる人の中にはEveryday Railsをまだ知らない方もいるかもしれません。
そこで以下では、Everyday Railsを知らない方や、まだ持っていない方に向けた情報を書いていきます。

そもそもEveryday Railsって何？

Everyday RailsはRSpecでRailsアプリケーションをテストする方法を紹介した電子書籍です。
「RSpecをまったく使ったことがない」「テストコードを書け、とはよく言われるけど、何から手を付けていいかわからない」といった、初心者さんのために、易しく・詳しくテストの書き方を説明します。

原著者はAaron Sumner氏（@ruralocity）で、日本語版の翻訳チームは僕・伊藤淳一と、Akiさん（@spring_aki）、魚振江さん（@blueplanet42）の3名です。

必要な前提知識

RSpecの入門書なので、RSpecの使い方は丁寧に説明していますが、Railsの仕組みやRubyの文法はある程度理解している前提で書かれています。
「RailsやRubyもまだまだ初心者」という場合は、「Railsチュートリアル」や拙著「プロを目指す人のためのRuby入門」を先に読んでおくと良いかもしれません。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

どこで売ってるの？

Everyday RailsはLeanpubという電子書籍販売サイトでのみ購入可能です。
町の本屋さんやAmazonでは販売していないのでご注意ください。

Everyday Rails - RSpecによるRailsテスト入門 | Leanpub

電子書籍の対応フォーマットは？

提供される電子書籍ファイルのフォーマットは以下の3種類です。

• EPUB（MacやiPhoneのiBooks、および一般的な電子書籍リーダー用）
• MOBI（Kindle用）
• PDF

1冊購入すれば、どのフォーマットもダウンロード可能です。
またDRMフリーなので、手持ちのパソコンやスマホなど、複数の端末に保存して読むことができます。

EPUBファイルをMacのiBooksで開くとこんな感じです

試し読みはできますか？

はい、できます。
購入ページにサンプルページへのリンクがあるので、ここから1章と3章を試し読みすることができます。

【予告】次回アップデート時（3月）に価格を改定します

これまで日本語版Everyday Railsは最低価格16ドル（約1700円）、希望価格20ドル（約2100円）で販売してきましたが、この価格を見直し、次のように改定します。

改定後の販売価格

	ライセンス数	最低価格	希望価格
パーソナル	1	$19.00	$23.00
スモールチームパッケージ	3	$51.00	$69.00
ラージチームパッケージ	10	$150.00	$230.00

価格改定のスケジュール

販売価格はすぐには変更しません。
上に書いた、2018年3月の次回アップデート時に新しい価格を適用する予定です（具体的な日付は未定）。

ですので、それまでであれば今の価格でお買い求めいただけます。
もちろん、一度購入すれば今後も無料でアップデート可能です！
（すでに購入済みの方も、この価格改定による影響はまったくありません）

2018.3.31追記：価格改定を適用しました

2018年3月31日に本書をアップデートし、同時に価格改定を適用しました。

価格改定の理由

価格改定の理由の一つは、改訂版の翻訳作業に思った以上の工数がかかったことです。
前述の通り、改訂版は「ほとんど新しい本」になっているので、この工数分を新しい価格に反映させてもらいました。

もう一つの理由は、「本書の内容は価格に見合うだけの価値が十分ある」と自信をもって言えるようになったためです。
日本語版は初版のリリースから4年が経過し、開発の現場におけるRSpecの定番の教科書となりました。
この改訂版も「それだけの金額を払った価値はある」と思っていただける内容になっているはずです！

ところで最低価格と希望価格って何？

Leanpubでは購入者が購入価格を変更できる、ユニークな仕組みを取り入れています。
制作者が妥当と考える価格が希望価格で、購入者が選択できる一番低い価格が最低価格です。

購入価格は購入ページのスライダーで変更できます。
（スライダーを右に移動させると希望価格以上の価格で購入することもできます！）

なお、誰がいくらで購入したのかは制作者には分からないようになっているのでご安心ください😅

チームパッケージって何？

上の販売価格表に出てきた「スモールチームパッケージ」と「ラージチームパッケージ」は、複数のユーザーでまとめ買いする際に割安で購入できるオプションです。
職場でEveryday Railsを共通のリファレンスとして購入したりする場合にご利用ください。

チームパッケージの詳細や、ライセンスの考え方については以下の記事で詳しく説明しています。

改訂版をレビューしてくれた木原さんの感想

最後に、僕の同僚で改訂版をレビューをしてくれた木原忠大さんの感想を載せて、このエントリを締めくくります。

本書はRSpecをよく知らない頃に一度読んでいて、当時、書き方がわからなかった初心者の自分にはとても役に立った覚えがあります。

現在では、私もある程度RSpecを使いこなせるようになっています。
ですが、今回の新版を改めて読んでみると、いつのまにか知らない機能が増えていて、RSpec経験者にも役に立つことがたくさんありました。

また、テストを読みやすく書いているか？テストの速度を意識して書いているか？など、自分のRSpecの書き方を見直すきっかけにもなりました。

本書はRSpecの初心者と経験者のどちらにもおすすめです！

まとめ

というわけで、このエントリではRails 5.1とRSpec 3.6に対応した「Everyday Rails - RSpecによるRailsテスト入門」について紹介しました。

本当に長い間お待たせして申し訳ありませんでした。
ですが、改訂版は翻訳者として「この内容なら自信をもってお勧めできる！」という内容になっています。

すでに購入された方も、まだ購入されていない方も、新しくなったEveryday Railsをぜひチェックしてみてください！😉

Everyday Rails - RSpecによるRailsテスト入門 | Leanpub

改訂版のもくじ

改訂版Everyday Railsのもくじは以下のとおりです。
興味がある方は参考にしてみてください。
（長くなるので最後に載せました）

1. イントロダクション

• なぜRSpecなのか？
• 対象となる読者
• 私が考えるテストの原則
• 本書の構成
• サンプルコードのダウンロード
• コードの方針
• 間違いを見つけた場合
• gemのバージョンに関する注意点
• サンプルアプリケーションについて

2. RSpecのセットアップ

• Gemfile
• テストデータベース
• RSpecの設定
• rspec binstubを使ってテストスイートの起動時間を速くする
• 試してみよう！
• ジェネレータ
• まとめ
• Q&A
• 演習問題

3. モデルスペック

• モデルスペックの構造
• モデルスペックを作成する
• RSpecの構文
• バリデーションをテストする
• インスタンスメソッドをテストする
• クラスメソッドとスコープをテストする
• 失敗をテストする
• マッチャについてもっと詳しく
• describe、context、before、afterを使ってスペックをDRYにする
• まとめ
• Q&A
• 演習問題

4. 意味のあるテストデータの作成

• ファクトリ対フィクスチャ
• Factory Girlをインストールする
• アプリケーションにファクトリを追加する
• シーケンスを使ってユニークなデータを生成する
• ファクトリで関連を扱う
• ファクトリ内の重複をなくす
• コールバック
• ファクトリを安全に使うには
• まとめ
• 演習問題

5. コントローラスペック

• コントローラスペックの基本
• 認証が必要なコントローラスペック
• ユーザー入力をテストする
• ユーザー入力のエラーをテストする
• HTML以外の出力を扱う
• まとめ
• Q&A
• 演習問題

6. フィーチャスペックでUIをテストする

• なぜフィーチャスペックなのか？
• インストールが必要なgem
• フィーチャスペックの基本
• CapybaraのDSL
• フィーチャスペックをデバッグする
• JavaScriptを使った操作をテストする
• ヘッドレスドライバを使う
• JavaScriptの完了を待つ
• まとめ
• 演習問題

7. リクエストスペックでAPIをテストする

• リクエストスペックとフィーチャスペックの比較
• GETリクエストをテストする
• POSTリクエストをテストする
• コントローラスペックをリクエストスペックで置き換える
• まとめ
• 演習問題

8. スペックをDRYに保つ

• サポートモジュール
• let で遅延読み込みする
• shared_context （contextの共有）
• カスタムマッチャ
• aggregate_failures （失敗の集約）
• テストの可読性を改善する
• まとめ
• 演習問題

9. 速くテストを書き、速いテストを書く

• RSpecの簡潔な構文
• エディタのショートカット
• モックとスタブ
• タグ
• 不要なテストを削除する
• テストを並列に実行する
• Railsを取り外す
• まとめ
• 演習問題

10. その他のテスト

• ファイルアップロードのテスト
• バックグラウンドワーカーのテスト
• メール送信をテストする
• Webサービスをテストする
• まとめ
• 演習問題

11. テスト駆動開発に向けて

• フィーチャを定義する
• レッドからグリーンへ
• 外から中へ進む（Going outside-in）
• レッド・グリーン・リファクタのサイクル
• まとめ
• 演習問題

12. 最後のアドバイス

• 小さなテストで練習してください
• 自分がやっていることを意識してください
• 短いスパイクを書くのはOKです
• 小さくコードを書き、小さくテストするのもOKです
• 統合スペックを最初に書こうとしてください
• テストをする時間を作ってください
• 常にシンプルにしてください
• 古い習慣に戻らないでください！
• テストを使ってコードを改善してください
• 自動テストのメリットを周りの人たちに売り込んでください
• 練習し続けてください
• それではさようなら

ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア

はじめに

「プロを目指す人のためのRuby入門」を出版して以来、本で学んだ内容をブログに載せてくれている方をよく見かけます。

それ自体は著者として大変嬉しいのですが、たまに「ん？これはちょっと・・・」と思うようなブログ記事を見かけるときがあります。
具体的にいうと、本の内容を丸写ししているだけのブログ記事です。

このエントリでは本の丸写しがなぜいけないのか、かわりにどういうブログを書けばいいのか、ということについて書いていきます。

本の内容を丸写ししているブログの例

本の内容を丸写しをしているブログというのは文字通り「丸写し」しているブログです。
具体的なイメージを共有するために「こんな感じ」という例を載せておきます（特定の誰かのブログを意図しているわけではありません）。

タイトル「第2章 2.2.3 文の区切り」

「プロを目指す人のためのRuby入門」を読んでいるので、勉強した内容をメモしていきます。

Rubyは基本的に改行が文の区切りになります。セミコロン（`;`）等の記号を使って明示的に区切りを示す必要はありません。

# 改行ごとにメソッドが実行される
1.to_s       #=> "1"
nil.to_s     #=> ""
10.to_s(16)  #=> "a"

一方、セミコロンで明示的に文の区切りを指定することもできます。使用頻度は高くありませんが、1行に複数の文を入れたい場合に使われることがあります。

# セミコロンを使って、3つの文を1行に押し込める
1.to_s; nil.to_s; 10.to_s(16)

文が続くことが明らかな場合は、文の途中で改行することができます。

# ( で改行しているので、カッコが閉じられるまで改行してもエラーにならない
10.to_s(
16
)       #=> "a"

# ( がない場合は10.to_sと16という2つの文だと見なされる
10.to_s #=> "10"
16      #=> 16

バックスラッシュ（`\`）を使うと、文がまだ続くことを明示的に示すことができます。ただし、使用頻度は高くありません。

# バックスラッシュを使って10.to_s 16を改行して書く
10.to_s \
16      #=> "a"

この調子でがんばって勉強していこうと思います。

「プロを目指す人のためのRuby入門」を持っている方はわかると思いますが、最初と最後の一文以外は完全に本の丸写しです。
ここまで極端ではなくても、これに近い感じのブログ記事をいくつか見てきました。

技術書の内容を丸写しすることの問題点

技術書の内容を丸写しすることは大きく分けて2つの問題点があります。

問題点その１：引用の範囲を超えて無断転載と見なされる

ブログを書いてる本人には悪意がなく、純粋に「自分が勉強した内容をブログにメモしただけ」と考えているのはわかります。
ですが、技術書や他の人が書いたブログ記事の内容を必要以上にブログに盛り込んでしまうと引用ではなく「無断転載」と見なされる恐れがあります。

2018.01.23 16:00追記
引用や転載の基準や判断は法律が関わるところであるため、素人がうかつに発言するのは危険だと判断し、以下の記述を取り消します。

引用は無断でやっても構いませんが、転載は執筆者の許諾が必要になります。

引用と転載の境目を定量的に示すのは難しいのですが、丸写しの割合が記事全体の2割～3割までなら引用、それを超えると転載かなという気がします。

感覚的な基準で言うと、あなたのブログを読んだ人が「おっ、このブログを読んでいったら本を買わずに済むじゃん。ラッキー！」と思うような内容であれば、それは転載にあたると思います。

問題点その２：実はちゃんと理解できていない恐れがある

意図せず無断転載と見なされるのも問題ですが、ブログを書いた本人にとってそれ以上に問題なのは、こっちかもしれません。

これは僕の持論なのですが、技術をちゃんと習得したかどうかの判断基準のひとつは、「その技術を自分の言葉で説明できるかどうか」だと思っています。

逆に言うと、「自分の言葉で説明できていないなら、その技術をちゃんと習得していない恐れがある」ということです。

この話は以前発表で使ったスライドにも載せています。

わかりやすい技術記事を書くための心構えとテクニック / #railsdm 20171206 - Speaker Deck

そもそも本を丸写しするだけなら、誰でも手を動かせば書けます。
本人は勉強したつもりでも、実はちゃんと頭に入っていなかった、というのは困りますよね。
なので、丸写し以外の書き方を実践していく必要があります。

オリジナルなコンテンツを書くためのアイデア

ここまでは少し厳しい話を書きましたが、自分が学んだことをブログにアウトプットすること自体は大変良い習慣です。
ですので、このエントリを読んで「ぎくっ」とした人もブログは続けてほしいと思います😃

では、無断転載にならず、なおかつ自分のためにもなるオリジナルな技術ブログはどのように書けば良いのでしょうか？
個人的にオススメしたい執筆スタイルを以下に挙げてみます。

その１：章単位で内容を要約する

本の内容を右から左へコピーするのではなく、その内容を短くまとめてみましょう。
自分が「ここは重要」と思ったところだけを残し、それ以外の部分を切り捨てると要約が完成します。

たとえば以下のような感じです。

タイトル「プロを目指す人のためのRuby入門・第2章の重要ポイント」

「プロを目指す人のためのRuby入門」の第2章を読み終わりました。個人的に重要だと思った点をピックアップします。

メソッド呼び出しの()は省略できる

# ()を省略しない場合
1.to_s()

# ()を省略する場合
1.to_s

nilとfalseだけが偽で、それ以外は真

# nilとfalseは偽、以下の値はすべて真

# trueそのもの
true

# すべての数値
1
0
-1

# すべての文字列
'true'
'false'
''

メソッドはdefで定義する

def add(a, b)
  a + b
end
add(1, 2) #=> 3

（以下省略）

要約を作っていくときの大事なポイントは「どれだけ情報を捨てられるか」です。
「あれもこれも」と思い始めると結局丸写し（＝無断転載）に近づいていってしまいます。
なので、「短くできるほど勝ち」の精神で、必要最小限の内容だけを残し、その他の情報をどんどんそぎ落としていきましょう。

2019.01.04追記：ただし「これ、本を買わなくても内容がわかるじゃん！」みたいな要約は避ける

上にも少し似たようなことを書いていますが、要約は要約でも「これ、本を買わなくても内容がわかるじゃん！」というような要約は避けた方が良いです。
以下のブログ記事にそのあたりの話がいい感じにまとめられているので、こちらも参考にしてみてください。

その２：自分の感想を積極的に散りばめる

本を読みながら「この機能は初めて知った！」「今までに使ったプログラミング言語とはここが違う！」と思った部分があれば、その気持ちをブログに散りばめてみましょう。
もしかするとあなたのブログを読んだ他の人も「へえ、そうだったのか」と勉強になるかもしれません。

今まではJavaしか使ったことがありませんでしたが、JavaとRubyではこんなところが違うと思いました。

# 変数名やメソッド名はスネークケースを使う
hello_world = 'Hello, world!'

# メソッド呼び出しの()を省略できる、文の終わりのセミコロンもいらない
foo.bar

# メソッドの戻り値はreturnを使わずに書く
def add(a, b)
  a + b
end

# （以下省略）

その３：自分の言葉で説明してみる

少し前に「自分の言葉で説明できていないなら、その技術をちゃんと習得していない恐れがある」と書きました。
であれば、その反対で「自分が理解した内容を自分の言葉で説明するのが良い」ということになります。

「自分の頭の中ではこんなイメージで理解した」というポイントがあれば、それをブログにアウトプットしてみてください。

たとえば、以下の例ではRubyのunless文に関して、英語のunlessの意味を併記している部分が「本に載っていない独自の説明」に該当します。

Rubyではif文の反対のunless文があります。英語のunlessには「～でない限り」という意味があるので、うまく使えば自然な英文のように読める条件分岐が作れますね。

status = 'error'
# okでない限り、メッセージを表示する
unless status == 'ok'
  '何か異常があります'
end
#=> "何か異常があります"

その４：自分で実験した結果を載せる

本を読みながら「こんなことをしたらどんな動きになるんだろう？」と思った部分があれば、それを実験してみましょう。
そして、その結果をブログに載せてください。
これなら確実にオリジナルなコンテンツになりますね。

Rubyでは"!"や"?"で終わるメソッドを定義できると書いてあったんですが、二つを合わせて"!?"で終わるメソッドは定義できるのか試してみました。

irb(main):001:0* def really!?
irb(main):002:1*   "Hello"
irb(main):003:1> end
SyntaxError: (irb):3: syntax error, unexpected '?', expecting ';' or '\n'
def really!?
            ^
(irb):3: syntax error, unexpected keyword_end, expecting end-of-input
	from /Users/jit/.rbenv/versions/2.4.3/bin/irb:11:in `<main>'

やってみたら構文エラーになりました。"!?"で終わるメソッドは定義できないようです。

まとめ

というわけで、このエントリではブログに技術書の内容を丸写しする問題点と、その改善案を説明してみました。

繰り返しになりますが、ブログに学習内容をアウトプットするのは非常に良い習慣なので、ぜひ続けていってください！
そして、ブログを書く際にはここで紹介したような改善案を実践してみると、さらに本の内容が自分の頭に定着すると思います。

僕も本の筆者として、オリジナルなコンテンツをもった「プロを目指す人のためのRuby入門」に関するブログ記事がたくさん出てくることを楽しみにしています！😄

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)