誰かに質問をわざわざしに行くのが苦手な私が、それを克服した話
背景
私はもともと誰かに質問をするのが苦手な気質。 ランチや移動中にカジュアルな話をしていて「そういえば」くらいのノリで聞くのはできたけど、改めて「質問なんですけど・・・」みたいに人の席に行って聞くのが苦手だった。
問題点
エンジニアをやっていると分からないことはたくさん出てくる。 ドメイン知識についてや難しい技術について。
ドメイン知識についてはそもそも聞かなきゃわからないことが多い。 サーバの中をひたすらあさったり、コードを読んだりして推測することはできるけど、時間はかかる。
(自分にとって)難しい技術についても、ブログ読んだりドキュメント読んだりすればいつかは扱えるようになる。 大体の場合は通勤時間にスマホで雑にブログとか5個くらい読んで大まかな用途みたいなところを掴んで、公式ドキュメントで理念や細かいHowを読み込むと自分のものになっていく気がする。 たまにブログ情報も少なかったりドキュメントが貧弱なミドルウェアとかにぶち当り、無駄に時間をかけてしまう。
そういう時、詳しい人に「ねえねえ、10分だけちょっと最初の概要だけ教えてよ」と話を聞いて、そのあと自分で触ってみるとすっきり問題なく使えることが多い。
わかっちゃいるが聞けない
質問の仕方として「自分が何が分からないのかはっきりさせてから聞きなさい」と教育されてきたからなのかカジュアルに人に聞けない。 分からないことが分からない時には誰かに話してはいけないような気がしている。でもその時間が長く続きすぎるなら、10分だけ時間をもらったほうが良さそう。
克服しつつある
最近、あるプロダクトのSRE的な部分のリーダとして仕事をするようになった。 必然的に、誰かに技術や仕事の進め方、ドメイン知識を伝えないといけない。 私が仕事を振る時、相手に最初に短い時間をとってもらって出来るだけ方針やはまりどころを伝えようとするけども、それでも伝えきれないものが出てくる。または、ある程度進んだけど次のステップで困っているなどの相談がくる。 その時に(みんなじゃないけど)私の机のところにカジュアルに話を聞きに来てくれる人がいる。
仕事の進め方ってみんなやり方がバラバラで、Slackメンションしてから時間とってもらっていいでしょうか?みたいにちゃんとする人も、しゃべりながら近づいてきて問答無用で会話を始める人、逆に詰まっているのに話を全然持ってこない人など。 その中でピカイチの成果を出すのはやっぱり躊躇なく話を聞きに来る人。
こちらの時間は取られてしまっているのだけど、それでもその人がウンウン唸って詰まる時間が少ないので仕事はスムーズに進む。チームとしてトータルコストは低そう。 そういう風に人の仕事ぶりを見るようになって、忙しくなってきた自分がコストを低く結果を出すためには、やっぱり誰かの力をテコとして使うのがいいんだろうなと思ったりする。すべての内容を聞くのは相手の時間を使いすぎるのでいまいちだけど、一番詰まるところだけを人の力を使って解決してしまうのが良いのかなと。
終わりに
まだ克服できていない部分ももちろんある。意識して克服していきたい。 ”人に質問をする”のが苦手という断片的な部分よりも、最小コストで結果が出せているかな?という点にこだわっていきたい。 この文章を書いたのは、後から自分が見て、ちゃんと出来るようになっているかな?というのを確認したいがため。
チームがうまくまわるようにAnsibleのPlaybookでGitHubプルリクテンプレートを使いたい話
目次
背景
最近インフラを触り始めた人と一緒に働くことが多くなってきた。みんなに効率よく経験を積んでもらいつつ、インフラチームをうまく回すための施策を細々考えている。この記事はその中の一つについてのメモ。 私は「こういう内容が良いのではないか」と思って作ったものなので今後チーム内外の意見をもらって内容が書き換わる可能性は大いにある。
GitHubのテンプレート機能はどう使うか
レポジトリのルートディレクトリに PULL_REQUEST_TEMPLATE.md という名前でファイルを置くと、プルリクを作るときに自動的にその内容が書かれる。 詳しい置き方や仕様についてはググれば出てくるのでここには書かない。
テンプレートを作るにあたり気をつけたこと
- 後からプルリクを見直したときに、何をやっているか分かるか。後から新人が入ってきたときにプルリクをトレースして学ぶことができるようにしたい。
- 開発環境や本番環境に全て(半)自動反映になっていれば最高だが、今のところそうなっていない。 反映漏れ事故をなくしたい。
- コードだけ書いて本番に反映せず満足してしまう人もたまに居るので、きちんとデリバリーしようという意識を持ってもらうために、それを促す記述を入れたい。
- プルリクを出した後のネクストステップを意識するとスムーズに仕事が回るので、それを考えてもらいたい。
- 時間は無限ではないので緊急度や重要度を意識して、やらなくて良い仕事はやらない。ネクストステップがない場合もある。
- よく分からないことをプルリク出してもレビュアが気がつかなければプルリクが通ることがある。事故の元なので曖昧なことは表明してもらってみんなで解決したい。
テンプレート内容
# 概要 ### 経緯 issueやconflenceリンクがある場合にはそれを張っても良い。 ### このprの目的 課題は何か ### 変更点概要 この変更によりどう解決されるのか # 本番/開発環境更新 ### 反映タイミング 開発環境と本番環境への反映を行うタイミングを記述する。以下の選択肢から1つ選択して詳細を記述する。 * 開発環境に反映済み * 対象サーバを記述する * マージ後開発環境にのみすぐ反映する * しばらく開発環境で動作を確認したい場合に選択。もしくは緊急度が低く、本番へは次のサーバリプレイス時に入れば良いという場合 * 反映すべきサーバを書いておく * マージ後すぐに本番に反映する * 緊急度が高い場合 * 本番更新チケットを作成して、リリースタグを切って反映する。参考: http://hogehoge.jp * 反映すべきサーバを書いておく ### 動作確認手順 更新後に行う動作確認の手順を記述する。すでに開発環境で動作確認を行っている場合にはその内容を書く。 できるだけprを出した本人以外でも動作確認ができるように書く。自明な場合には記述しなくてもよいが、レビュアーはレビューをする段階で分からなかったら確認するのが望ましい。 # 関連issue/pr/外部リンク # その他 ### 今後の課題 次に解決すべき課題があれば書く。 ### 実装に関する留意点 困ったことやイマイチな点など。
初めて会社でAPIを書いて学んだことメモ
これは何
普段主にインフラエンジニアとして働いている私が、会社で初めてAPIを一つ書いたので、そこで得た学びや考えたことを記録しておこうと思います。
何を学んだこと・考えたこと
仕様書を書こう
どのようなAPIなのか、目的やリクエストパラメーターやレスポンスフォーマットについて定義する。 特にAPIの場合はレスポンスフォーマットが変わるとクライアント側でパースするのに困ってしまうのではっきり定義しなければならない。 APIは使う側ありき。
レスポンスフォーマットの統一性
他のAPIとできるだけ揃えた方が良い。統一性がないと使う時に大変。 ドメイン全体でJSONのうちのMeta情報やDataオブジェクトをどのようなフォーマットにするのかというのを決めておき、各種APIはそれに従うのが良い。何も決めずに走り出すとメチャメチャになってしまうのでまず共通ルール。共通ルールはフレームワークへ落とし込んでおいて、そのフォーマットから外れなければ簡単にレスポンスを作れるようにしておく。 共通ルールをしっかり作っておくと大枠は固定されるので、後から細かいところをちょっと変えるにしても混乱が少ない。
DBで保持しているデータとAPIのJSONのキー名は必ずしも合わせる必要がない
裏で使っている名前に引きずられがち。利用者にとって使いやすい名前にする。
例えばDBで公開状態をpublic_status
という名前で持っており、0,1の値を取るとする。どちらの値がpublicなのかちょっと分かりづらいと感じたとする。その場合、public_status
にこだわらなくても、APIレスポンスとしてはデータ要素が削除されているかというのが重要であるなら is_deleted
という名前で返してあげるのが親切。
時間はUnixTimeで返そう
JSTやUTCで帰っていると使いづらい。DBでJSTで保持していても変換してUnixTimeで返すと良い。
エラー応答についても定義しておこう
主なエラー応答やステータスは共通ルールとして定義しておこう。 各APIの仕様書においては、特殊な条件やちょっと迷いそうな場合についてエラー応答について記述しておこう。
仕様書はコードからすぐに参照できるように書いておこう
@see などで参照リンクとしておいておこう。 簡単な説明はコードにコメントしてしまった方が良いが、長くなるなら仕様書に切り出してリンクを貼っておくのを忘れずに。1セットで管理していく。
コードフォーマットはエディタに任せよう
エディタに微妙にフォーマット設定が入っていなくて細々としたPRコメントを沢山もらっしまった。 フォーマットについてはプロジェクトのREADMEにすべて明記して新しく入った人が迷わないようにする。可能であればエディタ設定ファイルなども共有しよう。 人間がやることではない。機械に任せられるのは機械に任せよう。
テストを書こう
PRコメントに長々と手動の動作確認の結果を書くのはよくない。TDDの考え方を取り入れて仕様が決まったら先にテストを書いてしまうのが良い。
コメント: とはいえ今回のケースでいうと、それなりにテスト書くのに苦労したので先に書くのは難しかったかも。Seleniumでテストを書いたのだが、他の開発者がMacだったが私だけWindowsでテストを回したので無駄に苦労した。開発環境は可能なかぎり教えてくれる人と合わせた方が良い。
同じような応答を返すWebFrontページがあるなら仕様を合わせよう
WebFrontページとソート順や件数などの仕様が異なると混乱を招く。仕様がくいちがうならその旨を理由と合わせて明記しよう。
障害電話受け1番になった時に使える三つの心得
これは何
システムに障害が起こった時に電話が一番にかかってくるようになった人のための心得。具体的な障害対応手順ではなくて、元気にSREエンジニアとして生き残っていくための心得。
心得
1. 本当の優先事項は何かを考える
仕事の電話がかかってきた。(仮に)今は奥さんの誕生日食事会の途中だ。さあ電話に出て対応をするか? そういう時には対応をしてはいけません。他の人に任せましょう。ほっておけば2番目の人が電話を受けてくれます。 人生で重要なことの優先順位をつけましょう。電話がかかってきたら必ず仕事、なんてことはやってはいけません。そういう風に考えていると24時間いつでもかかってくる電話を所持していると精神が持ちません。気をつけましょう。 エンジニアとしても人としても長生きしましょう。 (補足:待機人員として拘束時間になっているならちゃんと出ましょう。しかし特に決まりもなく電話を持たされている場合には法的には何も拘束力がないと理解しています)
2. 最初にやることを意識する
まずは他の人も呼びましょう。 あまりにも軽微な障害なら一人で対応しても良いですが、すぐに問題原因が特定できない可能性があるもの、影響範囲が狭くないものの場合にはチームメンバーが気がつけるようにSlackで@channelしましょう。躊躇なく。 その目的としては以下のような人員を増やす目的があります
- 問題原因特定のための人員
- 原因特定後、手作業が発生した時に対応する手として
- 影響システムや社内一次報告、関係会社などに連絡する連絡人員として
- SREの知見は少なくてもユーザ目線で障害発生や復旧を確認できる動作確認人員として
なんにせよチームメンバならやれることはあるはずなので人を集めましょう。 上にはいろいろ理由は書きましたが、一人で対応するとテンパったりミスをしたりするのでオブザーバでもいてもらった方が良いです。
3. 障害対応は実況しよう
やったことは生のコンソールログを含めてSlackに貼っておこう。他のチームの状況なども可能なかぎり一つのチャンネルに集める。これの目的は以下のもの
- 途中から対応に参加した人が状況を把握できる
- 手分けして対応をしている場合に他の人の状況が把握できる
- ミスや考え違いをしていたら他の人が気がつくことができる
- 振り返りに使うことができる(後で見て情報ないと本当に困るので、やってみると効力がわかるはず)
実際にやったことだけでなく、障害原因の予想や、対応方針、ふわっとした違和感なども投げましょう。少しでも情報を表に出してみんなで考えることが大切です。書くことで自分の考えも整理されます。
終わりに
これらは電話をもらって頑張って死にそうになっている同期や後輩を見て考えたことです。
長生きしましょう。 ストレスためすぎているなと思ったら電話をおいて海にでも出かけるのも良いです。この投稿で言いたいことはこれがほとんで全てです。
応用情報技術者試験を受けたので記録しておく
これは何
2017年10月にIPAの応用情報技術者試験を受けました。12月合格発表で、結果が出た(合格した)ので、考えたことを記録しておく。
結果は?
点数は午前75、午後68ですれすれというほどでもないけどなんとも言えないところ。とはいえ、資格試験はボーダを超えるのが重要なので目標通りではあるのでOK。
応用情報って何
IPAが言ってる7段階のレベルの3に当たるもの。そろそろきちんとエンジニアとしてやっていくかな〜と考えているような人が受けるレベル。 午前試験と午後試験で分かれている。午前試験の開始が(特に私の所属する企業の)エンジニアの起床時間と比べて早いのが特徴的。 詳しいところ気になる方はググる感じでよろしくお願いします。
なぜ受けたか
- 大学が化学系で、情報系出ていないのでコンプレックスがある
- 受かると会社で一時金が出る
- 幅広い知識も業界内の専門外の人と話す時に重要と思った
- 経産省の調査で、諸外国含めたIT人材のレベルとお給金、的な資料を読んだ。だいたい自分のレベルとお給料の市場相場が一致しているのだなと気がついて、知識ベースアップのために受けてみることにした。(また、米国水準だと同じレベルだとお給金もうちょっと良さそうなので英語もぼちぼちやる) 参考資料: http://www.meti.go.jp/policy/it_policy/jinzai/27FY_report.html http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_global.pdf
対策は?
前提知識(試験前のレベル)
午前試験
過去問見てみると業務で見たような単語が多い。過去問道場で雑にやってみると午前試験が無勉強で4割くらい取れる感じだった。最初のテキスト半分くらい読み終わった終わった段階で午前試験の過去問5割くらいだった。
午後試験
午後試験は10分野のうち4分野選択するのだが、私はセキュリティ、アーキテクチャ、ネットワークが無勉強で5〜10割くらいでばらつきあるが平均で合格点取れそうだが、あと1分野はどれも5割切りそうなのでどれとるか迷うレベル。
勉強時間は
多分30時間くらい。移動時間にやっていたのが多いので測定不能だがだいたいこれくらいだろう。平日の移動時間に10分くらいの細切れ学習時間の積み重ねと、土日のどちらかの1〜2時間くらいをカフェでのんびり参考書読む感じだった。 おそらく午前試験に20時間くらい。午後試験に10時間いかないくらい。
学習内容
午前試験
- 参考書を読む「キタミ式イラストIT塾 応用情報技術者 平成29年度」。この参考書はわかりやすくてよかった。他の参考書も買ったが、なぜそうなるのかとか書いておらず「公式」とか書かれていたのでゴミ箱に捨てた(比喩)。まずは本の7割くらい苦手分野を中心にざっくり読んだ。
- 過去問道場というサイトで電車内でちまちま過去問やる。過去問題解きつつ、わからなかったら参考書やググる。気になったものがあったら好奇心のままに調べる(ただし移動時間10分くらいの長さだけ。基本深くは潜らない)。
午後試験
だいたい1週間前(本格的には前々日)から午後試験対策をした。参考書は2週間前くらいに中古の安いやつ買った。「2014 応用情報技術者午後問題の重点対策 (午後問題対策シリーズ)」。この本も解説が詳しくてなかなかよかった。正直あんまり読んでないけど。版は古いがどうせ資格試験なんて大して内容変わらないだろうと思っての安いやつ。試験では新しい話題も出てきていたが、正直ベースがあればやはり解けるので新しいのにこだわらなくてもいいなと思った。業界内にいる人は普段から最新技術もなんとなく話を聞いているだろうし。 セキュリティ、ネットワーク、アーキテクチャは傾向だけさらっと見て、あと一分野どうするか決めるためにいろいろ解いてみた。
どれにする? 午後試験の問題は当日選べる。一夜漬けするならどれだ。
- マネージメント: 雰囲気で半分取れるが安定しない。博打なので無し。
- 情報システム開発: 過去問見る感じだといろんなフロー的なのとか出てくる。雰囲気でとけるが、しっくりこないのでとりあえず無し。他に選択肢がなければやる。
- アルゴリズム: 一つの大問に平均20〜30分が標準だが、問題によって40分くらい時間をかければ7割取れそう。できるようになれば硬いが、一夜漬けは無理そう。他の大問が早く終わって当日楽そうだったら(時間をかければ解けそうだったら)選ぶ
- データベース: 正規化とか設計の方はなんか本読んだことあるのでわかるが、普段ゴリゴリにSQL書いていないので副問い合わせとかなんか空欄にされるとなんかよくわからん。1週間ちゃんと対策すれば7割硬そうだがとりあえず無し
当日ぱっと見、情報システム開発の分野がテストケースの話で点数そこそこ取れそうだったので選択。なんとかなった。
辛かったこと
- これが一番難しいとされている。会場が家に近かったのでなんとかなった。
- 会場が寒い。雨の日だったこともあり午前試験で凍えてしまった。次の日から風邪引いた。ちゃんと厚着していくこと。
やってよかったか?
- 幅広いなんとなくの知識はついた。情報卒コンプレックスは多少解放されたが、次はさらに高度試験受けないと。完全解消にはやはり情報系大学院いくのが良いか。
- 正直午後試験はもうちょっと時間かけてやった方が身になった。知っている知識でごり押しした。
- BNF記法とか身近だけどあんまり意識していないものに触れられたのでよかった。
- 一番よかったことは、勉強習慣がついたこと。受験時代にやったようなことを思い出したので最近プライベートでもいろいろ自発的に学ぶようになった。
ansible vmware_guest_find モジュールを用いたVM存在確認と後続タスクの制御
これは何
ansibleによるVMwareのVMインスタンス管理の話。 VMインスタンスをコマンド一つで作成して初期設定ができるようにAnsibleで管理している。すでに存在するVMについては、うっかりRebootしたりNW Restartなどが走らないように存在チェックをしてそれらのタスクをスキップしたい。
vmware_guest シリーズの module について
- vmware_guest module
- VMを作るためのモジュール。ansible version 2.2 より使用可能。
- vmware_guest_find module
- vmware_guest_facts module
コードとハマリどころ
コード
# vmware_guest_findはすでにVMがいれば戻り値としてvm_folder.foldersにVMがいるディレクトリが入る(ここで、vm_folderはregisterで定義した変数)。居ない場合もしくは認証がうまく行かなかったなどの場合にはエラーになり、vm_folder.msgにその原因が書かれる。 # 後続のタスクは、VMがまだ居ない場合にのみ実行したい。 - name: check vm exists on vsphere vmware_guest_find: hostname: VMホスト名 username: ユーザ名 password: パスワード name: VMインスタンス名 datacenter: データセンタ register: vm_folder ignore_errors: yes # とりあえず ignore_errorsにしたけどfailed_whenで制御した方が綺麗だったかも。そのうちなおすかも。 - name: create and setting vm block: - name: create vm # ここら辺の中身は今回は略 include: create_vm.yml tags: create_vm - name: setting vm include: setting_vm.yml tags: setting_vm when: (not ("folders" in vm_folder)) and (vm_folder.msg | regex_search("Unable to find folders for VM"))
解説
vmware_guest_find module の戻り値。 Debugで見てみる。
- name: debug debug: msg: "{{ vm_folder }}"
VMがいるとき
"msg": { "changed": false, "failed": false, "folders": [ # これが帰ってくるのが特徴的 "/vm/hoge/development" ] } }
VMがいないとき
TASK [../ex_roles/vsphere_vmmaker : debug] ****************************************************** ok: [test-vmmaker] => { "msg": { "changed": false, "failed": true, "msg": "Unable to find folders for VM test-vmmaker" } # msgが帰ってくる。他の原因でmodule実行が落ちると他のmsgが帰ってくるのでそれを利用する。 }
- find と言う名前がついているので戻り値にBooleanが帰ってくるかと思ったらVM Folderが帰ってくるのだった
- ない時にはFalseが帰ってくるかと思ったらErrorになってしまうのだった
- 単に「find module実行が落ちたらVM設定する」にしてしまうと、なんらかの拍子にmoduleが落ちると意図せずcreate vm, setting vmが走ってしまって嫌だったので、それを念入りに回避するためにmsgを見ている
- もっと綺麗にかければよかったけど安全策をとった形
- find moduleはまだ安定していないので後方互換を取らないかもしれない、と言う注意文言があったのでmsgは変わるかもしれない(This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface. と書かれていた)
- msgがマッチしている時にだけ設定が走るので、msg文言が変わっても実行しないという安全側に倒れるので良い
コメント
インフラエンジニアがバックエンド書けるようになるために paiza と progate を使っている感想
これは何
バックエンド開発ができるようになるためにお家でPaizaやProgateを使ってPHPやRailsをお勉強している話。
目次
背景
私はメインの専門領域はWebインフラエンジニア(サーバエンジニア)なわけですが、そろそろアプリケーションコードもそこそこ書けるレベルじゃ無いと仕事がしづらいなと思ってきた。 だいたいコードの関連箇所の概要教えてもらったらコードを読み書きできるけども、自分一人で完全に問題箇所特定して修正してチューニングする、みたいなことがちょっとしにくい気がする(感覚的なもので、まだ何が知識として足りないか分かってないのでふわっとしている)
どう学ぶか?
会社で
一番いいのは会社で仕事としてアプリケーションコードを書くのが良い。とはいえ、私のメインで関わっているシステムはレガシーすぎるので「綺麗なコード」とか「良いアーキテクチャ」というのを学ぶのがなかなか難しい。本とか読めばある程度分かるのだろうが、ベースである程度読み書きして体に染み込んで無いと辛いところはある。
インフラ領域においてはやはりレガシーなところに放り込まれたが、3年という潤沢な時間をかけて試行錯誤しながら(なんとか動くくそコードを量産しながら)なんとか良い状態とは何かというのがなんとなく分かったつもりである。同じようにアプリケーションについて試行錯誤し続けるのも無駄な気がした。
自分で
となると、まずは独自で学習するしかない。ある程度分かってきたらそこそこ新しいシステムでアプリケーションコードを書かせてもらうように交渉するのが良さそう。 というわけで教材を探すわけである。とは言っても能動的に探したというよりも、問題意識を持っていたらTwitterで流れてきたのが目についてそれに飛びついた形。 さて、前置きが長くなったがPaizaとProgateについて。
Paiza
主観的な内容
競技プログラミングを学ぶためっぽい感じの内容だった。お題が出されてそれを実装する。主に実装速度(と高レベルになると実行速度)が見られる感じ。 実装速度を求められるのは新鮮で、就職活動をするときに自分の実力を知るためにFizzBuzzを時間計って頑張って書いたのを思い出した(10分以内にかけないくそプログラマもいる、と書かれている記事を読んだ後にやって7分くらいでできたので安堵したのを覚えている)。
選んだ言語
仕事でPHP関係が多いので、まずは最低限PHPコード読むのに苦労しない程度学ぼうと思ってPHPを選ぶ。
内容とレベル感
ざっくりやってみて、Bレベルまでは解けるのは分かった。このレベルだと、想定回答時間内に終わらないことも多いが、最終的になんとか回答できる感じ。Cレベルは普通にふわっと書いて終わるレベル。
Bで苦労するものがまあまああるので、Aは無理そう。
しばらく頑張ればBがスイスイ解けるようになるだろうと思ったが、今そうなりたいかと言われるとちょっと違うと思ったのでここで終わり。
自分とマッチしているか
ところで、Paizaは求人と紐付いているだが、きている求人があわなさそうなのが多いのでちょっとないかなという感じ。提案されるお給料にコーダーとしてのお値段を実感した。コードだけ書きたいわけでもなし、ここを極めるのは自分の進む違う感じがして一旦終わり。
Progate
主観的内容
Railsの教材を選んだ。そのせいか、コードを書くというより、アプリケーションを実際に作ってみるというのに重きを置いている感じ。ちょうど何か自分で全部作りたいなと思っていた時期だったので、マッチした。他のRubyの教材とかは雰囲気違うかも。
内容とレベル感
内容としては、「一気に全てを学びましょう」ではなくて、RailsだったらRailsの機能に焦点を当てているところが特徴的。当然、見た目それっぽいアプリケーションを作るためにはHTMLやCSSの知識も欠かせないわけだが、そこらへんは「ここにもう書いてあるのでコピペして該当箇所に貼ってね」という感じで、本当に基礎のところを知っていればスムーズに学びを進められる。綺麗なWebサイトつくるために後でそのコースも取ろうかな、と思わせる作り方なのがよかった。 今の所レベル26までやって、微妙に完全脳死ではできない感じでちょうど良い。
自分とマッチしているか
今の所結構良さそう。Railsはアプリケーションを高速で作るのに適していると聞くし、後で自分のプロダクト作るときに使えそう。裏の細かい技術的なことはインフラやってる経験から後からまあまあ調べられると思うし「だいたいこんなんで作れるだろう」というレベルまでいければ御の字。しばらく頑張ってみたい。
おまけ
N予備校
ちょっとだけやってみた。環境構築からしっかり学ばせるというコンセプトが強い。そこらへんは個人的には間に合っているので別にこれじゃなくていいかなというところ。本当のエンジニア初心者には結構良いかもしれない。関係ないが、世界史とかの講義を聞いていると「なるほどそういうことだったのか」という学びが大きいので、そういう一般常識的なものを学ぶのにむしろ使いやすそう。しかし講義は1時間とか長いのでもうちょっと細切れの方が楽だなあと思いつつ、ちゃんと流れで理解するためにはそれくらいのまとまりは必要だろうなどと思ったりする。
まとめ
昔は本使ってRails触ってみて続かなかった。Webサービス使うとうまく進捗や理解を管理してくれるので楽で楽しくやれる。微妙にお金はかかるけど専門書買うのより安かったりして最近麻痺してお金をいろいろ突っ込んでいる。