自分にやさしく学ぶプログラミング

プログラミング学習記録、備忘録

capistranoでデプロイしたらpumaを再起動するために必要だったこと

capistranoでデプロイが完了したらそのままpumaを再起動して欲しいんですが、gemや設定の追加が必要だったので、備忘録として書き残しておきます。

ご注意！！

ここに書いてあることは全てcapistrano-pumaのREADMEに書いてあります！ ただ、capistrano関連の設定が個人的にややこしくて正解に行き着くのに時間がかかったので、今後のために今回の環境でうまく行った手順を控えておこうというのが、この記事の目的です。 これからデプロイされる方は、本記事の記述はあくまで参考程度に留めておいていただければと思います🙇‍♂️

実行環境

前提

とりあえずcapistranoのデフォルトのタスクは全てエラーなく完了する状態になっていることとしてます。

必要だったこと

capistrano-pumaをインストール

Gemfileに下記を追加

  # group: :development ブロック内
  gem "capistrano3-puma", require: false

bundle installも忘れずに

必要なタスクを追加する

Capfileに下記を追加

require "capistrano/puma"
install_plugin Capistrano::Puma
install_plugin Capistrano::Puma::Daemon

pumaの設定ファイルをサーバーにアップロード

ローカルマシンのターミナル上で下記コマンドを実行

cap production puma:config

これによりデプロイ先にshared/puma.rbが生成されます。
（ここよくわかっていなくて、再確認しようと思って試しにshared/puma.rbを消してからデプロイしてみたのですが、デプロイ時に自動的にshared/puma.rbが生成され、特に問題なくデプロイできてしまいました。まあcapistrano-pumaのGitHubにこれしないとpumaが動かないよと書いてあるので、そういうものなんだと思っています・・・）

capistranoの共有ディレクトリ設定を追加

config/deploy.rbに下記を追加

append :linked_dirs, "log", "tmp/pids", "tmp/sockets"

append :linked_dirsにより、指定したフォルダがsharedに生成され、各リリースバージョン間で共有されるようになります。

以上の設定で、デプロイ終了後にpuma:restartが走ってpumaが再起動されるようになりました🙌

capistranoでデプロイしようとしたら"The engine "node" is incompatible with this module."と怒られて止まった

タイトルの通りですが、cap production deployしたらnodeがincompatibleだと怒られてデプロイできないという現象が発生しました。

実行環境

参考リンク

実際に表示されたメッセージ

00:08 deploy:assets:precompile
      01 /home/yuta/.rbenv/bin/rbenv exec bundle exec rake assets:precompile
      01 yarn install v1.21.1
      01 warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix pack…
      01 [1/4] Resolving packages...
      01 [2/4] Fetching packages...

（中略）

error browserslist@4.14.0: The engine "node" is incompatible with this module. Expected version "^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7". Got "13.3.0"
error Found incompatible module.
(Backtrace restricted to imported tasks)
cap aborted!

（後略）

解決に至る流れ

デプロイ先の環境でバージョン確認してみると14.0.0でした。

$ node -v
v14.0.0

エラーメッセージと合わないので、which -a nodeしてみたところ、nvmの他にsystemにもnodeがインストールされていました。 （ていうかここで確認するまでnvm使っていること自体忘れていた・・・）

$ which -a node
/home/yuta/.nvm/versions/node/v14.0.0/bin/node
/usr/bin/node

そこで/usr/bin/node -vしてみたところ

$ /usr/bin/node -v
v13.3.0

案の定、デプロイ時はnvmを経由せずsystemの方のnodeを参照してしまっているようです。
多分/usr/bin/nodeはもう使わないので、アンインストールしておきました。

$ sudo rm -rf /usr/bin/node

さらに、どうもnvmを使う場合はcapistrano-nvmを入れた方が良さそうなのでGemfileに追加。

  gem "capistrano-nvm", require: false

これによりconfig/deploy.rbにnvm関連の値が設定できるので、下記のように追記しました。

set :nvm_type, :user
set :nvm_node, "v14.0.0"
set :nvm_map_bins, %w{npm node yarn rake} # ここにrakeを入れるのがポイント

基本capistrano-nvmのreadmeにある例そのままですが、自分の場合はnvm_map_binsにrakeを含める必要がありました。

この状態でcap production deployしたところ、無事最後まで完了しました！
めでたしめでたし。

プログラマー一年目の最大の学びは「手順書を書くこと」

これは「フィヨルドブートキャンプ Part 2 Advent Calendar 2020」の20日目の記事です。

昨日は@beta_chelseaさんの「すばやく確認OKをもらうためのセルフレビュー」でした。 セルフレビュー＆レビュー時に気をつけるべきポイントが具体的にまとめられていて、とても参考になります！どんなに気をつけているつもりでも、どんなに間違えようがないと思っていても、自分のPRを改めて見直すと大体一箇所はtypoとかが紛れ込んでいます。実装者とレビュアー、両方の時間と集中力を無駄にしないよう、自分もセルフレビューを怠らないようにしていきたいです！

はじめに

自分は2020年3月にフィヨルドブートキャンプを卒業して、プログラマーとして株式会社ラグザイアという受託開発の会社に入社しました。

プログラマーになって初めての年末を迎え、この一年を振り返ってみると、色々大変なこともあったにせよ、やっぱりプログラマーに転職してよかったし、そのための勉強の場としてフィヨルドブートキャンプを選んで本当によかったなぁとしみじみ思う今日この頃です。

そしてこの一年は本当に多くのことを学んだ一年だったのですが、今回は自分にとって就職以降最大の学びである「手順書を書く」ことについて、体験談と併せてまとめたいと思います。

ことの始まり

今年の9月くらいからアサインされた案件で、約30個のAPIを作成する機会がありました。

あまり複雑な要件ではなかったのですが、新規の案件だった（既存コードがない）ことや、未経験の要素がいくつかあったため、最初の枠組み作りで思った以上の時間を使ってしまいました。それでもどうにか頑張って大体の枠組みが出来上がり、さああとはバシバシAPIを追加していくぞ、という段階に入りました。

基本的には各API毎に同じようなコードのセットを追加していくだけなので、基本コピペの単純作業・・・と思っていたのですが、いざPRを出してみると、必要なバリデーションが一部漏れていたり、コピペ元の名残が紛れ込んでいたりして、なかなかスムーズにマージされない状況が続きました。

スケジュール的にも明らかな遅れが出始めたので焦りが募り、最終的にはリベースにミスってデグレが発生し、追加作業が発生してさらに遅れて、そのせいで余計に焦って・・・という悪循環に陥り始めました。

面談でアドバイスをもらった

そんなとき、ちょうど月一で実施している社内の先輩との面談があったので、そこで上記の状況を説明して相談してみました。

「自分としてはスクリプト作った方がいいと思うんですが、それはそれで時間かかりそうなので、どうしたもんかと・・・」と言うと、先輩は「スクリプトもいいと思うけど、それより先にチェックリスト作った方がいいかもね」と助言してくれました。

先輩曰く、チェックリストならスクリプトほど時間かけずに作れるし、スクリプトを作るにしてもやることが洗い出されていた方が作りやすいはず、とのこと。

なるほど！！！！！

つくってみたらそれは（結構なボリュームの）手順書だった

アドバイスを受けて、さっそくチェックリストを作っていきました。

仕様書を読みつつ、APIを追加するときの作業を思い浮かべて、必要そうなことを一通り書き出してみたものの、なんかスカスカしている気がします。やっぱり手を動かしながら書いてみないと漏れがありそうだ、と思い、今度は作業しながらひとつひとつ項目を足していきました。

すると、必要な作業が順番にリストアップされた作業手順書が出来上がりました（当たり前ですが）。

自分が書いた手順書を見て自分でびっくりしたのですが、「基本コピペの単純作業」と思っていた一連の作業は、リストアップしてみると実は30を超える手順からなる、なかなかに複雑な作業だったのです。自分は自分の作業を過小評価する傾向があるということがよくわかりました。

そんなわけで、チェックリストを作るつもりがいつの間にか手順書になってしまったのですが、これが絶大な効果を発揮してくれました。

（ちなみにチェックリストを作らなかったわけではなく、手順書の中にチェック項目を箇条書きで埋め込む感じにしました。あと結局スクリプトも並行して書きました。）

手順書を書いた途端作業が楽になった

手順書を用意したことで、一番最初に感じたメリットは、なんと言っても「次にやることを思い出さなくていい」ことでした。手順書がない状態だと、「・・・で、次何やるんだっけ・・・ああ○○を足すのか・・・」という思考を挟まないと作業が進まないのですが、手順書があればその必要がなくなります。手順が3つくらいなら書き出すまでもないかもしれませんが、30以上の手順となると、テキストに起こされているかどうかで全然違うと思いました。

また、無駄な思考を挟まなくて良くなったおかげで、自分の疲労度もだいぶ減ったし、逆に終業間際の疲れていて時間もないという状況でもミスが発生しづらくなりました。疲労軽減により余裕を持ってセルフレビューできるようになり、アウトプットの品質が一定以上に保たれ、PRがスムーズにマージされていくようになりました。

実際、手順書を作る前まではAPI一つ追加するのに一日以上かかることもあったのですが、手順書を用意してからは複数件安定して追加できるようになりました。

また、手順書を作ったおかげで、別の作業をしてから再度APIの追加作業に戻るのもとてもスムーズになりました。例えばあるAPIを作成途中に、前に出したPRにコメントが付けられて、そちらを先に対応したいという場合でも、手順書の今行なっている作業のところに印をつけておけば、一旦手を離してもスムーズに作業が再開できます（製造業で言うところの「仕掛り」のイメージ）。

あるいは、一通りのAPI追加が終わって別の機能追加に着手したのち、仕様が修正されて新しいAPIの追加が必要になった場合も（実際そういう場面がありました）、手順書があれば頑張って手順を思い出す必要もなく、楽にAPIを追加できました。

フィヨルドで勉強してたとき、もっと〇〇しておけばよかった

今回の件で「フィヨルドの時にもっとこうしておけばよかった」ということが２つあるので、それも書いておきます。

まず一つめは、「質問することにもっと慣れておけばよかった」ということです。幸いにも就職した会社に月一の面談制度があったからどうにかなりましたが、もしも面談制度がなかったら？そもそも月一の面談を待たずに誰かしらに相談できていればもっと解決が早かったかもしれません。

自分はまだ質問したり誰かを頼ることにためらいがあって、それはやっぱりちょっと恥ずかしいとか、自分で黙々とやった方が気が楽とか色々な思いからなのですが、仕事する上では早めにヘルプを出せた方がやっぱり効率がいいと思います。特に、コロナでリモート勤務が続く情勢下では、テキストでぽんぽん質問を投げられたら色々楽になると思います。

フィヨルドにはQ&AもSlackもあるし、そういうところでもっと気軽に発言して、慣れておけばよかったなぁと思います。

そして二つめは、「効率化のための工夫を色々試してみればよかった」ということです。フィヨルドのカリキュラムはすごく実践的で、特にスクラム開発はほぼ開発業務そのものですが、実際の業務との唯一の違いは納期がないことです。自分はわりとのんびり勉強を進めてしまってましたが、個人的にでも締め切りを設定して、それに間に合わせるための工夫をしておけば、業務に入ったときに納期に追われて焦る気持ちを和らげることができたかもなぁと思います。

とはいえ、そういうことがちょっと不十分だったにしても、業務をしながらでも改善していけてるので、「まあいっか」とも思います。この二つは個人的な課題として、もっとうまくやれるように来年以降も意識していきたいです。

最後に

以上、手順書を書いたら幸せになったというお話でした。ちなみに案件の方はギリギリでしたが期限内に納品でき、ひとまずめでたしめでたしでした。

ただ、本当にギリギリだったので、やっぱりもっと作業スピードをあげたいし、自分の作業時間の見積もりをちゃんとできるようになりたいです。

色々課題もありますが、それでもやっぱりプログラミングは楽しくて、最初に書いた通りプログラマーになってよかったなぁと感じます。

来年も楽しく仕事して成長していきたいと思います！

プログラミングや勉強における疲労への対処、勉強継続のポイント

背景

僕が卒業したフィヨルドブートキャンプには、関係者が自由に質問・回答できるQ&Aがあって、日々色々な疑問が上がっては解決されていくのですが、 先日「気の抜き方、休み方が分からず、（勉強を）一回休むと癖になってしまいそうで怖い」という相談が上がっていました。
多くの方が親切な回答を寄せていて、すでに解決済みとなっていますが、自分もこのテーマに関して思うところがあったので文章化してみました。

文章の目的

自分は一時期メンタル不調で休職してまして、そのときリワークプログラムというのに参加して半年ほど色々勉強してました。
そこで教わったことを踏まえて、疲労とストレス、その対処、勉強の継続について、自分が思うポイントをまとめてみようと思います。
一応、上記の相談の回答になりうるものとして、「フィヨルドでの勉強」を念頭に置いて書いていきます。

はじめにご注意

  • 下記、「疲労」と「ストレス」をほぼ同じものとして書いてます（別物とは思うのですが、まとめてしまった方が説明がわかりやすい気がするので・・・）。
  • 自分はあくまで患者として下記の話を臨床心理士さんから教わっただけで、ちゃんと裏どりした情報ではないです。必要に応じてご自身でも調べてもらえればと思います。
    • その臨床心理士さん自身は博士号もとって継続的に勉強されてる方であり、下記の情報も信頼できるものと思っています。
  • さらに言うと下記はあくまで「僕の解釈」です。正式に教育を受けたわけではないため、認識違い等あるかもしれませんので参考程度で・・・

疲労と疲労感は別物

大前提として、「疲れた」と感じることと、本当に身体や脳が疲れているかどうかは別の話です。
自分にとってストレスのかかることは、ごく短時間でも「疲れた」と感じます。
逆に、楽しいことや充実感を感じられることは、かなり長時間ぶっ通しで取り組んでも「疲れた」とは感じにくいです。
僕がフィヨルドで勉強していたときのことを思い返すと

  • わからないことが多くてプラクティスの進捗が出ない日が続いているときは、勉強を始める前からすでに疲れている
  • プラクティスが順調に消化できていってる時は、連日長時間勉強していてもそんなに疲れを感じない
    • でも少なくとも眼精疲労は溜まってて、肩が凝ったり目がしょぼついたりはしている（が、気になっていない）

みたいな感じです。
何が言いたいかと言うと、疲労感を感じてないからと言って疲れてないわけじゃないと言うことです（逆も然り）。 いくら楽しいことや充実感のあることでも、何か活動すれば脳なり体なりがそれだけ疲れるのです。

疲労を自覚するには

じゃあどうやって疲労を自覚すればいいかというと、自分の「疲れてるかどうか」の感覚はあてにならないので、具体的な症状を見ます。
上の僕の例で言えば、「いつもより目のピントが合いづらいな」と思ったら、「疲れてる」ってことなんだろうなぁという感じです。 他にも僕のサインで言うと、「耳鳴りがする、肌が荒れる、独り言や貧乏ゆすりが増える、よく壁やものに体がぶつかる」などがあります。 ちなみに脳が疲労している時の症状として一般的なのは、「集中力・やる気・思考力・作業効率・注意力の低下」らしいです。
こんな感じで、自分が疲れているときのサインをいくつか把握できているとちょっと安心できます。

　無理ができるのは10日間まで

ストレスを受け続けた場合（ ≒ 疲労を溜め続けて解消しない場合 ）の話です。
心身とも正常でニュートラルな状態から、ストレスフルな状況に置かれると、直後は体の各所の機能が低下して元気がなくなったりします。
ところがそのまま数時間から一日くらい経過すると、「抵抗期」というのに入って、逆に身体の活動量・抵抗力が大きく上昇します。 「抵抗期」は高いパフォーマンスが出せる状態になり、疲労がマスクされて疲れを感じづらくなります。
この状態は最長で10日間程度継続できると言われてるそうで、この期間のうちにストレスフルな状況から抜けて、きちんと休息をとることで、比較的スムーズに正常な状態に戻れます。
「抵抗期」の間は勉強や仕事の進みがよくなるので、自分では「まだまだいける」と思ってしまうのですが、実際にはストレスや疲労が蓄積されており、ダメージを受け続けている状態です（身体症状として、寝付きが悪くなったり、胃腸の調子が悪くなったりすることがあるそうです）。
そしてその状態がさらに続くと、最終的には「疲弊期」に入って、身体の活動量・抵抗力が大きく低下します。 この状態に入ると復活するまでにはまとまった休息が必要になるそうで、復帰までに時間を要します。
まとめると、無理ができるのは10日間までで、それ以上の無理は不調が長引くことになって効率が悪いので、早めに休息をとりましょうということです。

フィヨルドの勉強での「疲労」と、それを解消するための「休息」

フィヨルドでの勉強（もしくはプログラミング）を考えた場合、これによる疲労のメインは脳の疲労だと思います。 フィヨルドで勉強すると太腿が筋肉痛になるという人は、まあいないと思うし、それはここで考える問題とは別の問題です。
つまり「長時間画面を見つめて色々考えること」に疲れているのです。
脳の疲労なので、これを解消するためには脳を休ませる必要があります。
と言っても、脳の活動を完全に止めたりはできないので、「脳の別の部分を使う」、「脳ではなく体を使う」という方向の活動が「休息」として働きます。
例えば軽い運動をしたり、ヨガやマインドフルネスをする、十分な睡眠とることなどが休息として考えられます。
また、五感を使う活動も有効だそうです。 アロマオイルや香水の匂いを嗅ぐ、マッサージやお灸をする、好物を食べる、好きな音楽を聞くなどなど。
ちなみに（これは自戒ですが）、TVゲームは「長時間画面を見つめて色々考えること」なので、脳疲労に対する休息としては不適切です。

「休息」とは何か？

上のように、休息と言っても色々な形がありますが、抽象化すると「休息」とは「脳を含む体の普段使っていない部分を使って、好きなことをその後影響が出ない程度に楽しむこと」と言えます。
「勉強や仕事を休むこと」は休息の一部分（一段階）であって、その休みを使って何をするかが大事です。
また、まとまった時間休まなくても、ごく短時間で済む「休息」もありえます（上記アロマオイルの匂いを嗅ぐなどは1分以内でできます）。 もちろん、たいていの場合は時間のかかる活動の方が、それによって解消される疲労の量も大きくなりやすいと思います。
なので、自分にとって「休息」となる活動を所要時間や準備の大変さなどで分けて色々ストックしておけると、業務中や平日用の「休息」と、休日用の「休息」をどちらも併用していけるようになり、効率よく疲労を解消しながら勉強や仕事を継続できると思います。

「休むと癖になりそうで怖い」という不安は正しい

勉強であれなんであれ一日でも休むと休み癖がつきやすく、継続しづらくなります。 これは活動を休むことにより、再開するために必要な意志力のハードルが上がってしまうためです。
この問題の解決は至ってシンプルで、「休まなければいい」のです。 ただし、「起きてる間は休まず勉強しろ！」って話ではありません。 十分な休息はとりつつ、全く何もしない日を作らないということです。
例えば何かの本を継続して読む必要があるのであれば、一日１ページでもいいので読み進めます。 さらにいうならページ半分、最悪読んでるページをとりあえず開くだけでもいいです。
とにかく、完全な０は無くして、ほんのちょっと、触るだけでもいいので休まず継続することが大事です。
ただし、これはあくまで平常時の話です。 高熱が出ているとか、とてつもなく疲れて気分も沈み切っているとかいう場合は、寝るなりなんなりで体調を元に戻すことに集中すべきです。

継続するためのポイント

何かを継続するために大事なポイントが他にもあるので、下記にまとめてみます。

  • よほどのことがないかぎり、毎日やる（平日だけ、土日だけとかもNG）
  • 具体的な開始タイミング、やること、量を決める（家に帰ったらそのまま机に座って教科書を１時間は読む、朝食食べたら３時間はプラクティスに取り組む、など）
    • ここで、開始前に休憩を差し込まないことがポイントです。「帰って手を洗ったら即、朝食を食べて食器洗ったら即」などに設定します。後に回すとそれだけハードルが上がってしまうことになります。
  • ハードルを少し下げる代替案を用意（しんどいときは近くのカフェでスイーツ食べながらやってもいい、など）
  • ハードルを下げ切った最低ラインも用意（どんなに辛くてもとりあえず机に座って本を開くだけはする、コード１行は書く、資料眺めるだけはする、など）

ちなみに、モチベーションの維持という観点で言うと、あまり先々のことを考えすぎず、ちょっと先のすぐ手の届くところにあるゴール（「これができたら嬉しいな」と楽しみに思える程度の目標）を見て取り組んでいくと、モチベーションが維持しやすいです。

まとめ

  • 疲労を感じてなくても脳や体は疲れてるかもしれないので、意識的に休息を取り入れつつ、体が発するサインにも気を配ると良い
  • 休息とは、脳を含む体の普段使っていない部分を使って、好きなことをその後影響が出ない程度に楽しむこと
  • 休息にはいろいろな形があり、短時間で休息をとる方法もある
  • （心身が健康であるという前提で）何かを継続したい場合は、休まず毎日やる方が楽（ほんのちょっと、本開くだけでもいいので全くやらない日は作らない）

例）自分はどんな方法で休息をとっているか

ここまで偉そうに書いてきましたが、自分もここに書いていることが100％実践できているかというと全然そんなことないです・・・。
ただ、体のサインに気を配ることと、いろんなタイプの休息を用意して実践することは心がけています。
参考までに、自分がやってるおすすめの休息方法を挙げてみます。

簡単にできるやつ（平日用）
  • 音楽を聴く：むしゃくしゃしてる時はロックとかアニソンとかを大音量で（暗い部屋で一人で踊ったりもするとなおよし）
  • 猫に触る：至福
  • アロマオイルを嗅ぐ：焚くのがめんどくさいので瓶から直接とか、ティッシュやハンカチに振りかけてそれを嗅いだりしてました
    • 今は家に猫がいるのでできません・・・
  • 友人と話す：いろんな気持ちを抱え込んでいると疲れるので、定期的に人と話して発散すると楽です
  • お灸：せんねん灸とか簡単にできて気持ちいいです
  • 自律訓練法：心がざわついてる時にやるといい気がします（詳細説明は難しいので調べてみてください）
  • 紙の漫画を読む：ディスプレイの画面を見るよりは休息になっている・・・はず・・・
    時間がかかったりちょっと大変なやつ（休日用）
  • 市場にいく：市場は色々ないいものが揃ってるので眺めるだけでも楽しいです
  • 料理をする：頑張った分がほぼ確実に成果として得られるので好きです
  • 魚を捌く：料理の中でも普段使わない神経を使うし、なんか非現実感が味わえるので楽しいです
  • 車を運転しながら大声で叫ぶ：家とかだとなかなかできないけど車で走ってる時は叫び放題です（ただし安全運転で）
  • 公園の芝生に寝転ぶ：天気がいい日にやると最高
  • 焚き火：火は落ち着くしあったかいし肉が焼けて最高
  • 温泉：最高

随分な長文になってしまいました。
以上、読んでくださった方の参考になれば幸いです🙇‍♂

RubySilverに合格したので学習メモを公開

昨日Ruby Silver受験してめでたく合格しました！

実は受験は２回目で、１回目落ちたのが悔しかったので頑張って勉強しました。
その際作った学習メモが結構効いたなぁと思ったので公開してみます。
これから受験する方の参考になれば・・・。

最初にご注意

このメモはあくまで個人用に作ったメモですので、誤字やわかりづらい表現が含まれていると思います。 また、内容が100%正しいことを保証するものではありません。
正誤については必ず公式のリファレンス等をご自身で確認するようお願いいたします。

学習メモ

早速ですが今回作った学習メモがこちら↓

docs.google.com

試験前の２週間くらいの間、ひたすら練習問題を解き続けて、間違えたところやわからなかったところが出るたびに書き足していった感じです。
このメモですが、大きく下記の点がよかったと思っています。

  • 自分にとってわかりやすい分類でまとめられる
  • 問題を解く→間違ったところを書くという2段階を踏むことで定着しやすい
  • 単純なテキストより、スプレッドシートの方が一覧性が高い気がする

「メモやノートを取る」というのは勉強の基本動作なので、今更な話ではあると思います。
ただ、社会人になって以来テストというものがすっかりご無沙汰になっており、今回改めて基本の大事さや有効性に気付いたという感じでした。

そのほか大事だと思ったこと

  • なるべく早い段階で公式の教科書に目を通す
    • これを読んでおかないと出題範囲がイメージしづらいと思う
  • なるベく多くの種類の練習問題を解く
    • いろんなサイトで例題が公開されてますが、それぞれなんとなくの偏りがある気がするので、満遍なくやった方がいい
  • 本番で使うPCのマウス設定が極端すぎてマウスポインタが高速で移動しても平常心を忘れない
    • 僕はすごく動揺した

振り返って

勉強は大変だったけど、おかげでRubyの知識はだいぶ定着して、コーディングが少しスムーズになってきた気がします。
最後になりますが、１回目不合格だったときに励ましてくださり、２回目合格を祝ってくださった上司、先輩、同僚の皆様、そして受験費用を出してくださった株式会社ラグザイア様(現在私が勤務中の会社です)、まことにありがとうございました🙇‍♂

(2020/10/10追記)認定書が届いた！

Matzのお名前入りの認定書とステッカーが届きました！
こういうのもらえるの結構嬉しい😊

参考になった記事等

体験記

例題

  • Ruby一問一答
  • REx
    • この記事を書いてる時点でエラーで動かなくなっているが、これが一番使いやすかった
    • 2020/10/10現在復旧している模様
  • silver_j.md

iCloud管理下のフォルダでgitリポジトリをクローン ⇄ rm -rf 繰り返したら、覚えのないファイルが生成されつづけて困った話

私は普段MacBookAirで開発を行っており、データはほぼ全てiCloudと同期を取っている。
そのおかげでクリーンインストールからの復元も簡単なわけだけど、開発中のリポジトリもiCloud管理下に置いた結果、えらく困ったことが起きた。
話せば長いのでざっくり説明すると、

  • iCloud管理下のDocumentフォルダでgit cloneとrm -rfを繰り返していたら、覚えのないファイルが大量に生成されるという現象が発生
  • リポジトリをiCloudの管理外に置いたら解決した
  • gitのリポジトリ（というより同名ファイル？）の削除と復元を短時間の間に繰り返すと、iCloudとの同期が取れなくなることがある模様
  • 開発中のリポジトリはiCloudで管理しない方が良さそう

というお話。

発生した現象：ローカルリポジトリに知らぬ間にファイルが増えている

GitHub上のとあるリポジトリを、自分のMacのDocumentフォルダ下にクローンしたのだが、いろいろエラーが出たりしたため、何度かリポジトリをrm -rfしてgit cloneし直すということを繰り返した。
そのうち問題が解消されたようだったので、ひきつづきコードエディタで開発を進めようとしたところ、ふと気づいたら知らないファイルが大量に生成されていた。
どうやら既存のファイルと同名のファイルが増えているようで、"Gemfile 5"とか"~~ 3.rb"のように、既存のファイル名にスペースと数字が付加されていた（下図参照）。 ちなみにファイルの中身は既存のファイルとまったく一緒だった。

これはファイルが増えた時のコードエディタ（VScode）のエクスプローラ画面。403個のファイルが新たに生成され、各ファイル名の末尾にスペースと数字が付加されている。
ファイルが増えた時のコードエディタ（VScode）のエクスプローラ画面

なんだろうと不思議に思いつつ、増えたファイルを全部削除したのだが、しばらくするとまた同じようなファイルが増えている。
仕方ないのでローカルからリポジトリごと削除して再度クローンしたが、それでも直らない。
他のアプリを全て終了してみても、Macを再起動しても、果てはMacのクリーンインストールまでしてみたが、それでも症状は改善しなかった。

リポジトリをiCloud管理外に置いたら直った

色々試してもうまくいかず困っていたところ、同じフィヨルドブートキャンプで勉強中の@imaizumimrさんから、「iCloudとの同期が取れてないのでは？」との指摘をいただき、こんな参考記事を教えていただいた。

amksystem.com

リポジトリを置いていたDocumentフォルダはiCloud管理下にあるので、その可能性はありそう・・・。

と言うことで、ホームディレクトリ直下（iCloud管理外）に新しくディレクトリを作り、そちらにリポジトリを置くようにしたところ、知らないファイルが増えることは無くなった！

考察

今までもソースコードはiCloud管理下のフォルダに置いていたが、今回のように同期が取れなくなることはなかったと思う。
いつもと違う点としては、リポジトリをrm -rfしてgit cloneし直すというのを何度か繰り返したことくらい。
短時間に同名のファイルを消したり復元したりを繰り返すと、iCloudの同期が狂うということか？

まとめ

今回得られた教訓は、「iCloud管理下には開発中のリポジトリを置かない方が良さそう」と言うこと。
Document下に置くのは本当に「書類」だけにしといた方がいいのかも。

Dropboxなど、他のクラウドサービスではそういったことは起こらないと言う意見も聞いた。サービスごとに同期性能には差があるらしい。
でも結局のところ、継続的なバックアップ目的なら、外付けHDDを用意してTime Machineを 使うのが一番安全なのかもしれない。
Time Machineに対応したNASを用意する方法もあるらしい(下記のリンク参照)ので、そのうち試してみたい。

blog.jnito.com

MacのクリーンインストールはiCloud使ってれば怖くない（けど時間かかる）

最近色々よくないことが起こるので、半ば御祓の意味も込めてMacをクリーンインストールすることにした。
やってみた感想としてはタイトルの通りで、iCloudにデータを全部置いていれば何もこわくないなという印象。
12H程度の時間が取れれば、とりあえず使う分にはこれまでと同様の環境が再現できる。

注意：下にも書いたが、 .から始まるファイル ユーザーのホームディレクトリにおいてあるファイル はiCloudに保存されないので、必要な設定ファイルはどこかにコピーしておいた方が良さそう。

ざっくりとした手順

せっかくなのでmojaveからcatalinaにアップデートしてからクリーンインストールした

  1. 復活させるアプリを把握するため、アプリ一覧の画面の写真を撮っておく
  2. 環境設定からmacOSをアップデート（これだけで２時間くらいかかる）
  3. クリーンインストール　公式を参照
    （ここでネットに接続する必要があるが、自動接続してくれないので、SSIDとパスワードを入力する必要がある）
  4. インストールが終わったら、Siri とか TouchIDとかの例の設定をやっていく
    （この中でAppleIDが連携できる）
  5. MacOSが立ち上がったら、googleアカウントの設定だけはしておき、あとはしばらく放置
  6. 数時間後に確認すると、iCloudのデータがローカルに落とされてアクセスできるようになってるはず

これでユーザー辞書も復元されてました。

ちょっとだけの後悔

上記手順5のとき、Xcodeだけはインストールしときゃよかった・・・

そこそこの後悔

.から始まるファイル ユーザーのホームディレクトリにおいてあるファイルはiCloudに上がってなかった・・・まあgithubにdotfilesリポジトリ作って、ちゃんとpushしておけば大丈夫（僕はしてなかった） あとcatalinaからzshになるんでしたね。。