最近のMacとiOSデバイスのバックアップ環境を紹介してみる

はじめに

もはや僕の仕事と生活においては欠かすことができなくなってしまったMacとiPhone。
いや、僕だけでなく、僕の家族もほぼ同様です。たぶんみんなスマホなしでは生きていけないはず。

ふだん当たり前のように使っているMacやiPhoneですが、これがある日突然壊れてデータが全部吹っ飛んでしまったら大変です。
データがなくなること自体が大損害ですし、精神的なダメージも大きくなります。

なので、万が一の事態に備えてしっかりとバックアップを取っておくことが重要だと思います。
そこで今回のエントリでは、我が家のMacとiPhoneのバックアップ環境を紹介します。

【もくじ】

仕事用のMac = 外付けSSD + TimeMachine

仕事で使っているMacは外付けSSDにバックアップを取っています。
バックアップツールはmacOS標準のTimeMachineです。

外付けSSDは直接Macにつながず、EIZOの27インチモニタをUSBハブとして使っています。

EIZOのEV2785はUSB-CポートからMacに給電もできるので、Mac本体に接続するUSBケーブルは1本だけで済みます。

blog.jnito.com

外付けSSDはコンパクトのなので、ケーブルボックスの中に入れています。
電源ケーブルも接続する必要がないので、デスク周りもスッキリです。

SanDisk PortableSSD 1TB 【PS4 メーカー動作確認済】 USB3.1 Gen2 最大転送550MB/秒 SDSSDE60-1T00-GH25 3年保証 エコパッケージ

EIZO FlexScan 27.0インチ ディスプレイモニター (4K UHD/IPSパネル/ノングレア/ブラック/USB Type-C搭載/5年間保証&無輝点保証) EV2785-BK

サンワサプライ ケーブル&タップ収納ボックス Sサイズ ブラック CB-BOXP1BKN2

実は紆余曲折あった外付けSSDまでの道のり

もともと仕事用のMacは、このあと紹介する家庭用のMacと同様、無線ルーター経由のNASにバックアップを取っていました。
しかし、macOSをCatalinaにアップグレードした影響なのか、最近頻繁に「Time Machine でのバックアップの検証が完了しました。信頼性を向上するために、Time Machineは新規バックアップを作成する必要があります。」というような警告が出るようになってしまいました。

この警告が出るとゼロからバックアップをやり直すことになります😣

ネットの情報をあれこれ調べ回って試行錯誤したのですが、どうしてもこの警告を消すことができず、泣く泣く外付けSSDに乗り換えました。

【参考にしたが解決に至らなかった情報源あれこれ】

• 【解決】Time Machineが 「バックアップの検証が完了しました。信頼性を〜」とポップアップを出してきた場合の修復方法 | DROP DESIGN | 福岡のフリーランスWEBデザイナー
• TimeMachineで検証エラーが発生した場合の復旧方法 · zephiransasのチラシの裏
• GitHub - chase-miller/time-machine-sparce-bundle-fix: Time Machine Sparsebundle Fix
• Time Machine fails verification and keeps… - Apple Community

下のページではセキュリティ対策ソフトが影響しているのではないかという情報が載っています。
弊社ではFalconというセキュリティ対策ソフトを使っていて、もしかしてその影響かな？と思ったのですが、サポートセンターに相談したりしても結局解決できずじまいでした。

• macOS CatalinaでのTMバックアップ失敗、原因はセキュリティソフト? - iPhone Mania

ほかにも「Acronis True Image」や「Carbon Copy Cloner」など、サードパーティー製のバックアップツールも試してみましたが、こうしたソフトも数日使うとエラーが出たり、TimeMachineと比較するといくつか不満が出てきたりしたので、採用には至りませんでした。

• Best Mac Backup Software 2020: Free & Cheap Backups - Macworld UK

そんなこんなで、この3ヶ月ぐらい、ひたすらバックアップツールに関する試行錯誤をしていたのですが、最終的には「USB接続したHDDやSSDが一番安定する」という結論になり、この方式に至ったのでした。

外付けにするとFinder上の取り外し操作がちょっと面倒

この方式の難点は、「MacからUSBケーブルを外す前にSSDの取り外し操作をしないとMacに怒られる」という点です。
雑に外してバックアップデータが壊れても困るので、いちおう取り外し操作をするのですが、ちょっと面倒ですね・・・😣

家庭用のMac = BuffaloのNAS + TimeMachine

一方、家庭用のMacは無線ルーター経由で接続したNASにTimeMachineでバックアップを取っています。
仕事用のMacとは異なり、こちらは安定してバックアップが取れています。

この方式については以下のブログ記事で詳しく説明しています。
blog.jnito.com

ASUS WiFi 無線LAN ルーター RT-AC68U 11ac デュアルバンド AC1900 1300+600Mbps 最大18台 4LDK 3階建 【 iPhone X / XS 対応 】

BUFFALO リンクステーション スマホ・タブレットで使える ネットワークHDD(NAS) 2TB LS210D0201C

iOSデバイス（iPhone、iPad）= iCloudストレージ

我が家にはiPhone 4台、iPad 2台の合計6台のiOSデバイスがあります。
ちょっと前までは家庭用Macに接続して、Mac本体のSSDにバックアップを取っていました。

ただ、このやり方だと、「いちいち6台のiOSデバイスを抜き差しするのが面倒くさい」「Mac本体のストレージ容量がバックアップデータだけで食い潰される」という問題がありました。

とくに、バックアップが面倒くさくなってくると、バックアップの間隔が何ヶ月も空いてしまい、いざというときにバックアップデータが古すぎて大事なデータが失われてしまった、という問題が起きかねません。

そこでつい最近、iOSデバイスのバックアップはすべてiCloudストレージに保存することにしました。
こうすれば、電源につないでいる間に勝手にiOSデバイスが毎日バックアップを取ってくれます。
これで「バックアップの間隔が何ヶ月も空いてしまう」という問題は解決です！

意外と安い？iCloudストレージ

以前からiCloudストレージの存在は知っていたのですが、iCloudストレージは値段が高い、というイメージでした。
しかし、改めて価格を見てみると、2TBでも月額1300円で「意外とそこまで高くないやん」と思いました。

https://www.apple.com/jp/icloud/ から抜粋

我が家は6台のiOSデバイスがあり、ストレージ容量を合計すると700GBぐらいありました。
なので、2TBを契約するしかないのかな？と思ったのですが、実際にバックアップを取ってみると6台合わせても76GB程度でした。
というわけで、現在は200GB（月額400円）のプランを選択しています。

月額400円で6台ぶんのバックアップの面倒さから解放されるなら、全然ありなのでは？というのが僕の見解です。

写真 = Googleフォト（無料プラン）

写真や動画はどんどん増えてMacやiPhoneのストレージを食い潰してしまうので、すべてGoogleフォトにアップロードし、MacやiPhoneからは定期的に削除するようにしています。

Googleフォトは圧縮ありの無料プランで使用しています。
僕は圧縮されても画質の劣化が全然わからないので、特に問題視していません。

Googleフォトに写真をバックアップ（？）するリスク

MacやiPhoneから写真データを消してしまうとGoogleフォトのデータが唯一のマスターになってしまうので、厳密に言うと、これはバックアップではないんですよね。
なので、何らかの原因でGoogleフォトのデータが消えてしまうと、写真データがすべて消失してしまうというリスクがあります。

普通に使っていれば消えることはないと思うのですが、僕が何かやらかしてアカウントがBANされてしまったり、僕が突然死んで家族にログイン情報を引き継げなかったりしたら、写真にアクセスできなくなるかもしれません。

弊社ソニックガーデンのメンバーとこのあたりの話をしたところ、「GoogleフォトとAmazon Photosを併用している」とか「Dropboxのストレージも意外と安いので、そこに放り込んでいる」という意見がありました。

あと、自分が突然死んだときにそなえて「アカウント無効化管理ツールを設定しておくといいよ」という話もありました。

• アカウント無効化管理ツールについて - Google アカウント ヘルプ

ただ、このツールはG Suiteアカウントでは使えないみたいです。
僕はG SuiteアカウントでGoogleフォトを利用しているため、この方法は使えません。

とりあえず、妻のGmailアカウントを共有アカウントに設定しているので、僕が死んだときはこれを使えばなんとかなるかな？
これに加えて僕もAmazon Photosを併用した方がいいかもしれませんね。

追記：iCloudストレージにそのままバックアップする方法もあるようです

Twitterで以下のリプライをいただきました。情報ありがとうございます！

むちゃいい記事！　写真はiOS/macOSデフォルトの写真アプリもおすすめですよ。iCloudのストレージ容量は使うものの、端末には縮小版だけ保存して容量を節約しつつ、高解像度版をクラウドにおいとけます。何も意識せず同期されてて気持ちいいです。

— なかにしゆう🐈 (@youcune) August 30, 2020

まとめ

というわけでこのエントリでは我が家の最近のMacとiOSデバイスのバックアップ環境を紹介してみました。
バックアップは「よし、バックアップするぞー」とこちらが意識することなく、勝手にバックアップを取ってくれるのが一番ですね。
iOSデバイスも自動的にバックアップされるようになったので、これでバックアップに関するストレスからは解放されたことになります。

みなさんもよかったら参考にしてみてください！

【Ruby初心者向け】伊藤さんってなんでそんなにRubyについて物知りなんですか？への回答

はじめに

僕はフィヨルドブートキャンプでメンターをやっています。
その一環として生徒さんが書いたRubyのコードをレビューすることもよくあります。
そんなとき「そこはこんなメソッドが使えますよ」「こう書いた方がシンプルですよ」みたいなコメントを入れると、「なんでそんなにたくさんメソッドを知ってるんですか？」「どうしたら豊富な知識を身につけられるんですか？」という返事が返ってくることがあります。

このエントリではその質問に対する回答をあれこれ書いてみようと思います。

【もくじ】

前提として

まず前提として、初心者の方から見ると僕は「伊藤さん、すげー」ってなると思いますが、そういった「この人、すげー！」という評価は非常に相対的なものです。
僕だって「この人、すげー！それに比べたら僕なんて・・・」と思うことはたくさんあります。
つまり、僕は自分自身をすごいと思っているかというと別にそんなことはないです（でもRuby歴半年の人よりは確実にRubyが書けると思っていますが！）、と言い訳した上で本編へ進みます。

仕事で毎日コードを書いてるから（コードを書いてる時間が長いから）

単純な話ですが、僕は毎日仕事でRubyのコード（主にRailsアプリケーション）を書いています。
仕事でRubyを使い始めてから8年が経ちました。

仮に年間240日、1日あたり5時間コードを書いたとすると、「5時間 x 240日 x 8年」で、9600時間コードを書いてきたことになります。
まあ、これだけコードを書けば曲がりなりにも「Rubyチョットデキル」なプログラマにはなれるのではないでしょうか。

・・・みたいな話をしても、初心者の方は絶望してしまうと思うので、もう少し「初心者でもなんとかできる方法」を僕自身の経験から話しますね😅

とことんリファクタリングする

「徹底的にリファクタリングする」という精神でコードを書くと、いろんな便利メソッドや便利な言語機能を習得しやすくなります。
僕は昔からこんな感じでコードを書いています。

1. まず直感でコードを書く（この時点では汚くても良い。動きさえすればOK）
2. テストコードも一緒に書く（この時点でいったんgitにコミット）
3. もっと短く書ける方法はないか、もっとスマートに書ける方法はないかと自問しながら公式ドキュメントを読みまくって使えそうなメソッドを探し、リファクタリングする

具体的には以下のようなポイントに気を付けながらリファクタリングします。

• ローカル変数を無くす
• 条件分岐やループのネストは1段までにする
• ブロックはなるべくネストさせない

# こんなふうにブロックがネストするのはNG
text.split(' ').each do |word|
  word.each_char do |c|
    # ...
  end
end

• 短くシンプルに書きつつ、可読性も重視する。短さと可読性を天秤に掛けなければならないときは可読性を取る

上のようなポイントに気を付けながらリファクタリングしていくと、多くの場合、メソッドチェーンが最適解になることが多いです。
具体例を挙げるとこんな感じですね。

# リファクタリング前
def to_ints(hex)
  r = hex[1..2]
  g = hex[3..4]
  b = hex[5..6]
  ints = []
  [r, g, b].each do |s|
    ints << s.hex
  end
  ints
end

# リファクタリング後
def to_ints(hex)
  hex.scan(/\w\w/).map(&:hex)
end

ちなみに上のコードは拙著「プロを目指す人のためのRuby入門」に出てくるサンプルコードです。

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

こういうコードの書き方を繰り返していると、だんだん「カッコいいコードの書き方」が自分の道具箱に増えていきます。
（やりすぎると中二病っぽいコードができあがりますが、それは誰もが一度はかかる「はしか」みたいなもの、ということで・・・w）

リファクタリングに欠かせない、テストコードとgit

また、リファクタリングするときは「テストコードがあること」と「リファクタリングが終わるたびにgitにコミットすること」も重要です。

テストコードはリファクタリングによってプログラムが壊れていないかどうかをチェックするために使います。
テストコードがあれば「コードを変更！テスト実行！パスした！よし、次！」という勢いをずっとキープできます。

テストコードがないと、「コードを変更！プログラム実行！えーと、ここがこうで、こっちがこうだから・・・たぶん大丈夫かな。じゃあ、次」みたいなテンポになるので、リファクタリングの効率が悪くなります。（さらに、テストコードがないとバグを作り込んでしまう可能性も・・・）

リファクタリングの仕方がまずくてテストが落ちるときは、いったんコードを変更前の状態に戻したい、と思うことがあるかもしれません。
そんなとき、gitで「以前正しく動いてコード」にロールバックできれば、プログラムが壊れてしまっても怖くありません。

コミットはドラクエのセーブデータのようなものです。（と言っても若い人たちはわからないか）「何かあったらここに戻りたい」というタイミング（＝リファクタリングが1つ進んだ時点）で、gitにコミットする癖を付けましょう。

コードレビューしてもらう / コードレビューする

コードレビューもその言語に関する知識を増やすのにたいへん有効です。
コードレビューは「自分がされる側」になるときと、「自分がする側」になるときの2パターンがありますが、どちらも勉強になります。

特に相手のスキルが高ければ高いほど、もっといい書き方を教えてもらったり、自分がレビューするときに「こんなメソッド知らなかった！」という新しい発見があったりすることが多くなります。

モブプロやペアプロをする

モブプロやペアプロにもコードレビューと同じような効果があります。
コードレビューはたいてい非同期にコミュニケーションになりますが、モブプロやペアプロは同期的なコミュニケーションです。
すなわち、その場でリアルタイムにお互いの知見を交換し合うことになります。
コードレビューと同じく、スキルの高いメンバーがいると、より有益な知見を得ることができるはずです。

人に教える

他の人にコードの書き方を教えることもまた、自分の勉強になります。
中途半端な知識だと相手にうまく教えられないので、教える側も必死で勉強することになります。
「自分は初心者だから教えられることなんて何もない」と考えずに、「教えることで自分も成長するんだ！」という気持ちで積極的に人助けする方が、良い結果が得られるはずです。

ちなみに「人に教える」というのは直接顔を合わせながら教えるというのはもちろん、Teratailやスタックオーバーフローのような技術系Q＆Aサイトで質問に答えることも、人に教えることに含まれます。

コラム：自分で自分好みの勉強会を主催してみる

「コードレビューしてもらうにも、モブプロやペアプロをやるにも、人に教えるにも、自分は今仕事でコード書いてるわけじゃないから、そんな機会自体がないんです😣」という方も多いと思います。
そんな人は近くでそういったことをやってる勉強会がないかチェックしてみてください。

え？「勉強会もやってないよ！」って？
じゃあ、勉強会を自分で主催してみましょう！

最近はちょっと活動が少なくなってしまいましたが、僕も西脇.rb＆神戸.rb（旧名 西脇.rb＆東灘.rb）というRubyコミュニティを主催して、自分が面白そうと思ったテーマで勉強会を開いていました。
具体例をいくつか挙げるとこんな感じです。

• 西脇.rb & 東灘.rb ペアプログラミング In Action - 西脇.rb ＆ 神戸.rb | Doorkeeper
• 西脇.rb & 東灘.rb Ruby リファクタリング Dojo - 西脇.rb ＆ 神戸.rb | Doorkeeper
• Rubyistのためのテストコード相談会 ～テストの書き方に悩んでいませんか？～ - 西脇.rb ＆ 神戸.rb | Doorkeeper

最近は新型コロナの影響でリアルに人が集まる勉強会は開催しにくくなってしまいましたが、オンラインイベントとして勉強会を開催することも可能です。
何十人も集まるような大きな勉強会を開く必要はありません。
最初は参加者が2〜3人でもOKです。
「二人集まれば勉強会」を合い言葉に、小さな勉強会を主催してみましょう😉

情報をインプットする

単純にRubyに関する情報を書籍やネットから収集することももちろん有効です。
また、これは自分一人でもできます。

（できれば中級者以上の）技術書を読む

「いろんなメソッドの使い方を知る」「いろんな言語機能に精通する」という目的であれば、初心者向けの本よりも以下のような中級者向けの本を読んだ方が良いと思います。

Effective Ruby

改訂2版 Ruby逆引きハンドブック

手前味噌ですが、僕が書いた「プロを目指す人のためのRuby入門」でも中級者向けのテクニックを紹介したりしています。

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

Rails関連であれば最近改訂版が発売された「パーフェクトRuby on Rails」が良いかもしれません。

パーフェクト Ruby on Rails　【増補改訂版】

技術書ではありませんが、僕が以前Qiitaに書いたこちらの記事でもRubyやRailsの便利メソッドをたくさん紹介しています。
qiita.com

Ruby Weeklyを読む

Rubyに関する技術情報を毎週発信してくれるRuby Weeklyという無料のメルマガがあります。

• Ruby Weekly

英語のメルマガですが、英語の勉強を兼ねて購読してみると良いと思います。

週刊Railsウォッチを読む

週刊Railsウォッチも毎週RailsやRubyに関するお役立ち情報を提供してくれます。
こちらは日本語で読めるので、日本人でもハードルが低いはずです。

• 週刊Railsウォッチに関連した記事一覧｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社

Ruby/Rails界隈のスーパーエンジニアをTwitterでフォローする

Ruby/Rails界隈のスーパーエンジニアをフォローするのもやはり有益な情報を得るのに役立ちます。
少し前の記事ですが、以下のブログ記事は今でも十分有効なアカウントリストだと思います！

• 今すぐフォローすべきRuby界のスーパーエンジニア - blog.sorah

あと、スーパーエンジニアではないですが、ときどきRubyやRailsに関するお役立ち情報を発信しているアカウントはこちらです👇

• https://twitter.com/jnchito

情報をアウトプットする（丸写しではなく自分の言葉で）

自分が学んだことをブログやQiitaにまとめると、記憶の定着に役立ちます。

たとえば、僕の場合は「RubyのTimeとDateTimeの違いがよくわからない！調べてみよう」と思い、あれこれ調べまくって、わかったことをQiitaに書きました。
そのときに書いた記事がこちらです。

qiita.com

この記事を書くことで、僕はTimeとDateTimeの違いを完全に理解しました。
（というか、このとき以来、DateTimeクラスを使うことはなくなりました！）

他にも僕は毎年Rubyのバージョンが上がるたびに新機能のまとめ記事を書いていますが、これもRubyに新しく追加されたメソッドなどを覚えるのにとても役立っています。

qiita.com

でも、丸写しはダメ！🙅🏻‍♀️

ただし、このときに注意したいのが「本やネットの記事を丸写ししない」ということです。
著作権上、無断転載にあたるから良くない、というのももちろんそうなのですが、それ以上に「学習」という観点においては「右から左へ書き写すだけ」ではその技術をちゃんと理解できていない恐れがあるのが一番の問題です。

逆に「○○って何ですか？」と突然聞かれたときに、ネットを見ずに自分の言葉でちゃんと説明できるのであれば、その技術をきちんと理解できていることになります。

このあたりの話はこちらのブログ記事に詳しく書いています。
blog.jnito.com

丸写しになるのを避けるために、「もし、タイムマシンに乗って、その技術を知らなかった頃の自分自身に教えるなら、どうやって説明するか？」を想像しながらアウトプットすると、きっと良いアウトプットになると思います。
qiita.com

本を書く or 翻訳する

これはなかなかハードルが高いと思いますが、本を一冊書いたり、海外の技術書を翻訳したりするのもめちゃくちゃ勉強になります。

僕は「Everyday Rails - RSpecによるRailsテスト入門」という本を翻訳することで、RSpecの使い方をマスターしましたし、「プロを目指す人のためのRuby入門」という本を執筆することで、Rubyの細かい言語仕様を理解することができました。

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

「伊藤さんってなんでそんなにRubyやRSpecに詳しいんですか？」の答えのひとつがここにあることは間違いありません。

登壇する

本の執筆はハードルが高すぎるかもしれませんが、勉強会で登壇するのは本の執筆に比べればまだハードルが低いと思います。

Qiitaやブログを書くときは「誰が見てるかわからんし、反応もほとんどないから適当でいいや」となるかもしれませんが、登壇の場合はそうはいきません。

その場で自分の発表内容を評価されるので、おのずと「ウソを書かないように気を付けなきゃ」「ちゃんとわかりやすく説明しなきゃ」という意識が働きます。
そうやって発表内容をブラッシュアップする過程で、対象の技術に関する知識をより深めることができます。

「いきなり30分近い登壇をこなすのは怖くて無理！😣」という人は、持ち時間が5分程度のライトニングトーク（いわゆるLT）からトライしてみると良いかもしれません。

その他：特定の分野のスペシャリストを目指す

僕が「RubyやRSpecについて詳しい人」と思われているのは、「その分野に関するスペシャリストだから」という見方もできます。
つまり、昔も今もそこにフォーカスを絞ってるので、「RubyやRSpecをよく知ってる人」という地位をキープできています。

それ以外の分野、たとえばJavaScriptやDockerといった分野に関しては、「プログラマという仕事上、ある程度は知っているし、経験もあるけど、RubyやRSpecほど詳しくない。むしろ、知らないこともたくさんある」という状態です。

もちろん、JSやDockerについても詳しく知っておいて損になることはないのですが、次から次に新しい技術が登場してどんどん複雑化するこの業界において、すべての技術に精通した完璧超人を目指すというのはほぼ不可能です。
であれば、自分の得意な分野を絞り込んで「その道のスペシャリスト」を目指した方が、エンジニアとしての生存確率を上げられるかもしれません。

・・・と、偉そうなことを書きましたが、僕がRubyやRSpecのスペシャリストであるのは、「RubyやRSpecが好きだったから」という単純な理由です。
好きなことだといくら時間をつぎ込んでも苦痛にならないので、おのずとスペシャリストになれます。
このあたりの話はこちらのブログ記事に以前書いています。

blog.jnito.com

まとめ：3年ぐらいがんばれば大丈夫

というわけで、今回のエントリでは「伊藤さんってなんでそんなにRubyについて物知りなの？」というRuby初心者さんの質問にあれこれ答えてみました。

ただ、当然ですが、僕も最初からRubyやRSpecをすらすら書けていたわけではありません。
僕だって初心者の時代がありましたし、その頃は四苦八苦しながらコードを書いていました。
冒頭にも書いたように、僕が物知りになったのは、単純に「8年間ずっと仕事でRubyのコードを書いてきたから」というそれだけの理由かもしれません。

「8年？そんなにかかるの！？」と思われるかもしれませんが、必ずしも8年かかるわけではありません。
そうですねえ、僕の感覚でいうと、「3年ぐらい」です。
初心者の人でも3年ぐらい一生懸命勉強してたくさんコードを読み書きすれば、かなり自信が付いてくると思います。

「3年ぐらいがんばれば大丈夫」という話は、以前書いた下のブログ記事にも書いています。
blog.jnito.com

とはいえ、3年と言われても「長いなあ。大変そうだなあ」と感じる人はたくさんいるでしょう。
その3年間を短く感じられるようにコツがあります。
それは「技術を楽しむこと」「技術を好きになること」です。

好きなことや楽しいことをやっているとあっという間に時間が過ぎていきます。
ふと気づけば「え、もう3年？」という状態になっていて、そのときにはそれなりのスキルが身に付いているはずです。

でも、「プログラミングってなんか楽しくないな」「難しいことばかりで心が折れそうだな」と思ってる人も、「自分には適性がないんだ」と諦めないでください。
もしかするとそれはフロー理論でいうところの「不安状態」にずっと陥っているせいかもしれません。

blog.jnito.com

「不安状態」にいる人は、ちょっと無理して頑張りすぎている可能性があるので、もう少し気を楽にして、自分に合ったレベルまで難易度を下げてみると、またプログラミングが楽しくなってくるはずです。
高い目標を掲げることも大事ですが、すぐに心が折れてしまうような無理な目標を設定するのはやめましょう。
それよりも自分に合った目標をコツコツこなしていく方が、絶対成長できます。

なんだかんだいっぱい書いてしまいましたが、以上が「伊藤さんってなんでそんなにRubyについて物知りなの？」という質問への回答でした！

2021.1.10追記：「3年やればうまくなる」という話が本に書いてあった

自分の経験上、「3年ぐらいやれば何でもうまくなるはず」と思って上のような話を書きましたが、先日読んだ「世界一わかりやすい 教える技術」という本にほぼ同じ話が書いてありました。

料理にしても、スポーツにしても、語学にしても、ソロバンにしても、プレゼンにしても、ルービックキューブにしても、どんなことも、だいたい５０００時間をかけて練習すれば、熟達するということが明らかになっています。

５０００時間というのはどれくらいの時間かというと、１日５時間で毎日練習すると、３年間で５０００時間になります。もし、土曜日と日曜日は休みたいというのであれば、平日１日７時間練習すれば、３年間で５０００時間になります。

つまり、だいたい３年でうまくなれるということです。

向後 千春. 世界一わかりやすい 教える技術

僕の感覚だけじゃなく、世間的にも「3年」という数字はそれなりに根拠がある、ということですね。

世界一わかりやすい 教える技術

あわせて読みたい

5年前に浜松Ruby会議01で登壇したときのスライドです。
ここに書いてある話も、今回のエントリとほぼ同じ内容になってるんじゃないかと思います。

【おわび】2020年8月5日〜14日に販売したチェリー本のEPUBファイルに不具合がありました

タイトルの通り、2020年8月5日から14日にかけて販売したチェリー本のEPUBファイルに不具合がありました。

どんな不具合ですか？

Apple BooksやReadium、Calibreといった電子書籍リーダーを使って、EPUB版「プロを目指す人のためのRuby入門」（通称チェリー本）の1.6節や2.5節、11.4節などを開くと、"error on line 188 at column 102: expected '<'"のようなエラーメッセージが表示されます。

エラーの表示例

また、電子書籍リーダーによってはそもそもEPUBファイルが開けない（異常終了してしまう）、といった不具合も発生するようです。

対象者は誰ですか？

2020年8月5日から14日にかけて、技術評論社の電子書籍販売サイト（Gihyo Digital Publishing）からEPUB版のチェリー本をダウンロードした人が対象になります。

なお、以下の方は対象外です。

• PDF版をダウンロードした方
• Gihyo Digital Publishing以外のサイトから電子版を購入した方
• 2020年8月4日以前、または2020年8月15日以降にEPUB版をダウンロードした方

不具合はどうすれば直りますか？

Gihyo Digital Publishingにログインし、マイページから再度チェリー本のEPUBファイルをダウンロードしてください。
2020年8月15日以降にダウンロードしたファイルであれば不具合が解消されています。

マイページにてチェリー本をクリックすれば再ダウンロードできます

不具合の原因は何ですか？

Gihyo Digital Publishingの配信システムに一時的な問題が発生していたそうです。
現在は解消されています。

読者のみなさまにはご不便をおかけして大変申し訳ありませんでした。
今後とも「プロを目指す人のためのRuby入門」をよろしくお願いいたします。

gihyo.jp

あわせて読みたい