give IT a try

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

Q. チェリー本の学習時にサポートが切れたRuby 2.4を使ってもいいの?

追記:改訂2版が発売されました

Ruby 3.0に完全対応したチェリー本の改訂2版が2021年12月に発売されました。今後はなるべくこちらを使って学習されることをお勧めします。

はじめに

先日、Ruby 2.4の公式サポートが終了しました。

Ruby 2.4 公式サポート終了

ですが、これは別に驚くべきニュースでもなんでもありません。
Rubyは毎年12月25日に新バージョンが公開され、毎年3月末に古いバージョンがサポート対象外になっていくので、これは予定通りの動きです。

ところで、拙著「プロを目指す人のためのRuby入門」(通称・チェリー本)では、このRuby 2.4を説明対象のバージョンにしています。
これから本書を使って勉強しようと考えている人は、「えっ、Ruby 2.4ってサポートが切れてるけど、使って大丈夫なの?」と思うかもしれません。
そこでこのエントリでは、チェリー本の学習時に使用すべきRubyのバージョンについて説明します。

最初に結論:Ruby 2.4でもいいし、Ruby 2.5以上でもOK!

最初に結論を言うと、勉強で使用するならRuby 2.4でもいいし、Ruby 2.5以上でも構いません。
詳しい話は以下に書きます。

Ruby 2.4を使う場合

公式サポートが切れると、Ruby本体のバグ修正やセキュリティパッチのリリースがなくなります。
もしRuby 2.4を使って、外部に公開するようなアプリケーションを開発している場合はこれが深刻な問題につながる可能性があります。

ですが、チェリー本のサンプルプログラムはローカルマシン内に閉じた簡単なものばかりです。
なので、学習用として使うのであれば、Ruby 2.4を使い続けても問題はありません。

Ruby 2.4の問題点

ただし、Rubyのバージョンが古くなっていくと、「最新の開発環境にうまく対応できなくて、インストールにすごく苦労する」という現象がときどき発生します。
今はすんなりインストールできると思いますが、数年すると「Ruby 2.4をインストールしようとしたらエラーが出た」みたいな問題が起きるかもしれません。
その際は無理に頑張らず、新しいバージョンのRubyをインストールして学習することを検討してください。

また、最新のRubyでは本書の説明と異なる部分もいくつかあるため、業務で新しいバージョンのRubyを使ったときに「あれ、こんな構文あったっけ?」と疑問に思うことが出てくるかもしれません。
そうならないように、Ruby 2.4で学習が終わったら今度は次の項で紹介する説明記事を参考にして、Ruby 2.5以上の新機能や新構文もチェックしておきましょう!

Ruby 2.5以上を使う場合

Ruby本体はバージョンが上がっても、大半の部分で後方互換性が維持されています。
ですので、Ruby 2.5以上のバージョンでチェリー本を勉強したとしても、9割以上の内容は有効です。

ただ、そうは言っても「100%同じ」というわけにはいきません。
そんなに数は多くないものの、中には「チェリー本に書いてある内容と、実際に動かしたときの挙動が異なる」という部分もところどころに出てきます。

そういうときのために、Ruby 2.5、2.6、2.7の各バージョンについて、チェリー本の説明との差異をまとめています。

qiita.com
qiita.com
qiita.com

Ruby 2.5以上のバージョンを使って学習する場合は、事前にこれらの記事に目を通しておくと、安心して学習が進められると思います。

このような最新バージョンとの差異の説明は、今後も引き続き行っていく予定です。

Q. ところで、Rubyのバージョンってどうやって変更するの?

特定のバージョンのRubyをインストールしたり、複数のRubyのバージョンを切り替えて使ったりする場合はrbenvというツールを使います。(Mac/Linux環境の場合)

github.com

なお、rbenvのインストール方法や使い方についてはここでは詳しく説明しません。
これらはネット上にたくさん情報があるので、そちらを参考にしてください。
(意外と技術の移り変わりが激しい分野なので、なるべく1年以内に公開された情報を参考にするのをお勧めします)

Q. Ruby 2.3以前を使って勉強するのもありですか?

ありと言えばありですが、チェリー本が発売された当時(2017年)ならともかく、2020年現在にわざわざRuby 2.3以前のRubyを使う理由は特にない気がします。
何か特別な理由があるならやむを得ないと思いますが、そうでないならRuby 2.4以上で学習することをお勧めします!

まとめ

というわけで、このエントリではチェリー本の学習にサポートの切れたRuby 2.4を使ってもよいのかどうかについてまとめてみました。
ここに書いた内容で疑問点が解消しなかった場合はこのブログのコメント欄や、Twitterのメンションなどを使って、お気軽にご質問ください。

今後とも「プロを目指す人のためのRuby入門」をよろしくお願いします!

【初心者ITエンジニア向け】上手な質問は「相手にエスパーさせない質問」です

はじめに

この春からITエンジニアになったみなさん、どうもおめでとうございます。
これからたくさん勉強して、立派なエンジニアを目指していきましょう!

・・・と言っても、最初はわからないことだらけだと思います。
一人では解決できない壁にぶち当たったときは、他の人を頼って質問した方が学習効率が良いです。

とはいえ、質問するときは上手に質問しないと、自分も答える人も無駄に時間を食ってしまいます。
というわけで、今回のエントリでは「上手な質問」について書いてみたいと思います。

なお、ここで想定している質問は、社内掲示板のようなオンラインでの非同期な技術系Q&Aを想定しています。
ですが、基本的な考え方は対面で質問する場合も変わらないと思います。

まずはネットで質問のセオリーを学ぼう

上手な質問のしかたについては、すでにネット上に優れた資料があります。
これらの資料に目を通してもらえれば、僕が言いたいことの9割以上は伝わるはずです。

僕が言いたいことの「残りの1割」については以下でお話しします。

僕が考える重要ポイント=回答者にエスパーさせないこと

回答する立場に立ったときに一番困るのが、「困っているのは伝わるが、あなたの状況がよくわからない」という質問です。
隣の席に座って、一緒に画面を覗きながら「ほうほう、なるほど」と話ができれば一番いいのですが、掲示板のようなオンラインのQ&Aではそういうわけにはいきません。

情報が不足していると、回答者は「もしかしたら、こういうエラーメッセージが見えているのではないか?」「もしかすると、こんなことをしてるのが原因ではないか?」と想像力をフルに働かせなければならなくなります。
僕はこういう行為を 「相手の状況をエスパーする」 と呼んでいます。

Untitled

上手な質問はエスパーする部分が少ない質問です。
あまりうまくない質問はエスパーする部分が多い質問です。

思考実験:もし「田舎のおばあちゃん👵🏻」から電話がかかってきたら?

たとえば、田舎のおばあちゃんから、「なんかなあ、インターネットができへんねん。なんでやろか〜?」と電話がかかってきた状況を想像してみてください。
「いやいや、おばあちゃん。ネットができない、ってそもそもどういう状態なの??😅」って聞き返したくなりますよね?
ブラウザが起動しないの?Yahoo!にアクセスできないの?もしかしてパソコンすら起動しない??などなど、こちらは想像力を働かせておばあちゃんの状況を確認しないといけません。

これと同じで、自分が質問をするときに「Railsが起動しないんです。どうしたらいいですか?」みたいな質問をしていないか、自分で自分の質問を見直してみましょう。

電話ならその場で情報のキャッチボールができますが、掲示板のような非同期のコミュニケーションではキャッチボールするのにお互い時間がかかります。
ですので、回答者がエスパーする余地がないぐらい、情報を豊富に載せておきましょう。
情報が少なすぎることよりも情報が多すぎることの方が100倍マシです。

その点を踏まえて、上で紹介したネット記事を読み直してもらうと「なるほど、たしかにこれは全部エスパーする部分を少なくすることにつながってるな」と思ってもらえるはずです。

あと、質問の最後に「もし不明な点や不足してる情報が何かあれば、追記するので教えてください」みたいに書いておくと、「おっ、この子は回答する人への配慮もちゃんとできているな」と思われるので、goodです👍

まとめ

こんなにいろいろポイントを挙げると、「ハードルが高い!質問するのが怖い😭」と思われるかもしれません。
ですが、たくさんコードを書かないとコードが書けるようにならないのと同じで、何度も質問をしないと質問力は鍛えられません。

新人のうちは「まあ、まだ新人だからな」と許される場面も多いと思うので、どんどん質問して質問力を鍛えていきましょう💪

あわせて読みたい

質問は「恥ずかしいから誰からも見えないところでこっそり質問する」ではなく、「恥を捨ててみんなの前で質問する」のが正解です。
というわけで、こちらの記事もあわせてどうぞ。
blog.jnito.com

【初心者ITエンジニア向け】スキルアップに役立つアウトプットと、役に立たないアウトプット

はじめに

ネットなどを見ていると初心者エンジニアに向けて、「アウトプットは大事だよ!だからブログやQiitaに技術記事を書こう!」というメッセージをよく見かけます。

しかし、なんでもかんでもアウトプットすればいい、というわけではありません。
Qiitaとかを見ていると、スキルアップに役立つアウトプットと、役に立たないアウトプットの2つに大きく分かれるなと思いました。

それぞれ具体的にどういうアウトプットなのか、以下で説明します。

スキルアップに役立つアウトプットとは

スキルアップに役立つアウトプットは、「自分の経験がベースになっていて、なおかつ、自分でもよくわかっていない点を詳しく調べた上で書いたアウトプット」です。

たとえば、こんな感じです。

  • bundle installコマンドを実行したら、"[DEPRECATED] The `--path` flag is deprecated"という警告が出た(←自分の経験)
  • なんだこれ?なんでこんな警告が出るの?どう直せばいいの??調べよう!(←自分でもよくわかっていない点を調べた)
  • 警告の原因と直し方をQiitaに書く

ほかにも、「いいかげんなことを書くとツッコミ(マサカリ)が入りそうだから、ツッコまれないように技術知識を固めておかないと!」みたいなプロセスを経て出てきたアウトプットは自分のスキルアップに役立ちます。

つまり、アウトプットするために「よくわかってないところがある!ちゃんと調べて、正しい情報を書かないと!!」って考えて行動に移す点(=自分の力で正解を探し求めること)が、自分のスキルアップに役立つわけです。

スキルアップに(あまり)役立たないアウトプットとは

スキルアップに役立たないアウトプットの典型例は、「書籍やネットの情報を右から左へ書き写しただけのアウトプット」です。

たとえば、こんな感じです。

  • RailsのMVCについてネットの情報を読んで勉強した
  • MVCについてわかったことをまとめてQiitaに投稿した(←ただし、大半がWeb記事の書き写し)

こうしたアウトプットがスキルアップにまったく役立たないとは言いません。
ですが、こういうアウトプットは「アウトプット」と呼ばない方がいいのではないかと思います。
あえて呼ぶなら「ネット上に公開した自習ノート」です。

先ほど説明した「スキルアップに役立つアウトプット」とは異なり、自習ノートは「最初からそこにある正解をただ書き移すだけ」です。
なので、自分の血となり肉となる要素が少ないです。

また、「ネット上に公開した自習ノート」はスキルアップに役立たないだけでなく、元ネタとなったWeb記事や書籍の著作権侵害にもつながりやすくなります。
なので、自習ノートを書くのであれば、Qiitaやブログのようなパブリックな場所ではなく、自分にしか見えないクローズドな場所に置いておく方が良いです。

まとめ

「アウトプットは大事だよ!だからブログやQiitaに技術記事を書こう!」というメッセージを何も考えずに受け止めると、「ネット上に公開した自習ノート」を書いてしまいがちです。

しかも、「bundle installしたら警告が出たから直し方を調べてみた」みたいな記事よりも、「RailsのMVCについてまとめました」みたいな記事の方がはるかにイージーなので、ついつい後者のような記事を量産したくなるかもしれません。

ですが、「アウトプットは大事だよ!」とアドバイスをくれた先輩エンジニアは、おそらく「bundle installしたら警告が出たから直し方を調べてみた」みたいな記事の方を求めていると思います。
初心者エンジニアの方はその点を踏まえて、自分がネット上に何をアウトプットすべきかを考えてみましょう😉

参考情報

"bundle installで警告が出た"の元ネタは、僕が書いたこちらのQiita記事です。
qiita.com

自習ノートをネット上にアウトプットすることの問題点はこちらのエントリにもまとめてあります。
blog.jnito.com

追記

本エントリは僕個人の感想です。
全員に強制するつもりはないですし、いろんな意見があってもいいと思います!