2021年の振り返りと2022年の目標

大分出遅れた感がありますが、2021年の振り返りと2022年の目標を書きます。

2021年

2021年は変化の多い年でした。

  • 2月 エンジニアのアルバイト開始
  • 5月 エンペイに入社、フィヨルドブートキャンプ卒業
  • 11月 成人
  • 12月 独り暮らし開始

こうして見ると一年前に書いた2021年の目標は3/4は達成したことになります。

  • 3月までにフィヨルドブートキャンプを卒業する
  • 4月~5月までに就職する
  • 10月までに一人暮らしをはじめる
  • 行ったことのない東京のラーメン二郎(19店舗)を制覇する

最後の都内のラーメン二郎制覇は無念ながら達成できませんでした。

原因としては、実家の近所にある二郎系ラーメンに通いつめたことです。

ここの豚マシラーメンは絶品です。トッピングのオーダーが食券に丸をつけるスタイルなので、二郎特有の意味不明なコールをする必要がないのもおすすめポイントです。

経堂の近くに訪れた際には是非足を運んでみてください。

tabelog.com

エンジニアとして

楽しく働いています。

フロント、サーバーサイドどちらも浅く広く触りました。

やったタスクをざっとまとめると以下のような感じです。

  • フロントの軽微なバグ修正
  • メイン画面で使うコンポーネントを一部作成
  • 決済回りのバグ修正
  • Railsの既存コードの改善(ルーティング、コントローラー等)

少なくともマイナスの戦力ではなく、プラスの戦力になっているかな、、と思います。

僕の考える、Railsエンジニアとして就職できる最低レベルは、 「少しでもプラスの戦力として計算できる」 というものです。 「Issueを一人でこなせる」 といっても良いかもしれません。

Railsエンジニアとして就職できるレベルとは - komagataのブログ

2022年の目標

上にも書いた通り一年目はすぐに着手できるような具体的なタスクを進めました。

来年は「この機能は自分が作った!」いえるような大きめなタスクを完遂させたいです。

技術力向上の面でいうと足踏みした一年だったと反省しています。

Githubの草を見ると分かるのですが、土日は勉強しない日が多かったので、今年はもっと貪欲に学んでいきたいです。

とりあえず1月は土日も草を生やします。

以下の分野に興味があるので、たくさん本を読んで手を動かして学んでいきます!

  • Rails
  • サーバーサイド非同期
  • DB回り(設計、チューニング)

実務とプライベートの勉強のサイクルをいい感じに回していきたいです。

気負わずにマイペースにやっていきます〜

チェリー本 改訂2版 を読みました🍒

プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで のプレゼント企画に当選しました。ありがとうございます! 本の到着から時間が経ってしまいましたが、読んだ感想をポエミーに書いていきます。

印象に残った内容

正規表現

実務で正規表現を使ったコードをあまり書いていないので苦手意識がありましたが、本の内容に沿って考えるとそこまで難しくないことが分かりました。 正規表現を使うステップは大きく分けて以下の2つに分類できると考えています。

  1. 文字列の規則性を見つける
  2. 規則を正規表現に変換する

この両方を同時にこなすのではなく、段階を追って考えて行けば適切な正規表現を書けることに気付いたので積極的に使っていきたいです。

パターンマッチ

パターンマッチを使ったコードを実務で見かけどのようなルールで動いているのか非常に興味がありました。
データの構造に合わせて処理を分岐させることでより直感的なコードを書けることが分かりました。 データの実態ではなくあくまで構造にフォーカスを当てたパターンマッチのロジックは、型を厳密に定義する機能と相性が良さそうな印象を持ちました。
将来挙動が変わる可能性のある書き方もあるので、どこまで使うかチームで認識を合わせられると良さそうです!

クラス

第1版を読んでいたとき、「あるクラスのメソッドの中で別のクラスのメソッドを呼び、データをやりとりし、ひとつのプログラムとして動かせるんだ!」と感銘を受けたことを思い出しました。
本の中で一番重いと思われる内容ですが、例題を解くための最低限の知識 -> 例題 -> 深堀 の順で構成されているので、初学者の方でも読み進められるようになっています。

例外処理

例外処理との向き合い方が簡潔にまとまっており、個人的に一番好きな章です。 なんでも例外処理に渡すのではなく、そもそも例外を発生させることを未然に防ぐことはできないか?Rails, Rubyの機能で補足できないか?を検討してから使うようにしたいです。 以下の記事、動画でさらに例外処理への理解を深めたいと思います。

www.youtube.com

qiita.com

本の全体の感想

挫折を防ぐポイントが各章で散りばめられており、絶対に初学者を挫折させない強い意志を感じました。

  • サンプルコードの解説、コメントが丁寧
  • 言語の慣習と規約を明確に分けて解説している
  • 書面の都合で載せられない内容は、伊藤さんのQiita, Zennの記事で解説されている

初学者ではない方でも、Ruby3.0で追加された機能の把握、既存のメソッドの復習、例題を本のコードを写経せずに自分で解くことで更に理解を深めることができます。

初学者の方、第一版を読んだ方、お仕事でRubyを使っている方全員におすすめできる内容となっています! チェリー本を片手にプロになるため精進します。伊藤さん、ありがとうございました!

世界のナベアツのネタをRubyで書いた

Ruby力をつけたいので、Rubyのコードを書く。100日くらい続けたい。 3の倍数と3が付く数字のときだけアホになるネタを書いてみた。

# frozen_string_literal: true

limit = ARGV[0].to_i
1.upto(limit) do |count|
  if (count % 3).zero?
    p 'Aho!'
  elsif count.to_s.include?('3')
    p 'Aho!'
  else
    p count
  end
  sleep 0.5
end

ほぼFizzBuzzzero?メソッドは初めて知った。

docs.ruby-lang.org

調べてみると3以外にも仕様があった。

3の倍数と3が付く数字だけアホになり、5の倍数だけ犬っぽくなります 3の倍数と3が付く数字だけアホになり、8の倍数だけ人探しをしてる感じになります 3の倍数と3が付く数字だけ憤りを感じます 3の倍数と3が付く数字だけアホになり、8の倍数だけ気持ちよくなります 3の倍数と3が付く数字だけアホになり、8の倍数だけ媚びへつらいます 3の倍数と3が付く数字だけアホになり、5の倍数だけナルシストになります 生身のナベアツがまず3の倍数と3が付く数字だけアホになり、モニターに映ったナベアツがそれ以外の数字でアホになります(擬似的なコンビ芸) 3の倍数と3が付く数字だけアホになり、8の倍数だけ青春します 3の倍数と3が付く数字だけアホになり、9の倍数で正気に戻ります 3の倍数と3が付く数字だけアホになり、8の倍数のときに寝起きドッキリになります 3の倍数と3が付く数字だけアホになり、8の倍数のときにクイズ番組に出てる感じになります など

github.com

明日も1問解く予定。

ローカルで立ち上げたbootcampにスマホからアクセスする方法

  1. MacIPアドレスを調べる
    f:id:mashoo1101:20201225143926p:plain
    MacIPアドレスを調べる
    私の環境だと、192.168.1.13になります。

2.bootcamp/config/environments/development.rbに以下を追記してください。 IPアドレスは読み替えてください。

 config.action_controller.asset_host = "http://192.168.1.13:3000"

3 サーバーを起動

rails s -b 192.168.1.13

ログにCannot render console from 192.168.x.x! Allowed networks: 127.0.0.0/127.255.255.255, ::1 という表示が出たら、bootcamp/config/environments/development.rbに以下を追記してください。

config.web_console.whitelisted_ips = '192.168.x.x'

参考

はじめてのコードレビュー

フィヨルドブートキャンプのプラクティスでは、開発に参加して PR を送りマージするというプラクティスがあり、その中で生徒が書いたコードを生徒がレビューすることがあります。 はじめてコードレビューをしたので、個人的なポイントをまとめておきます。

伊藤メンターがレビューでチェックすること

  • コードの可読性、拡張性、変数名、ロジックが複雑すぎないか?
  • Railsらしいコード、Rubyのコーディング規約に則っているか?
  • セキュリティに問題のないコードか?
  • テストコードが書かれているか?

その他のポイント

  • 「これってどういう意味?」と思ったら質問してみる
  • 手元で動作確認する

手元で動作確認する流れ

git fetch origin branchして、git checkout branchする。 dev.classmethod.jp

自分の中のコードレビューのハードルを下げる

フィヨルドブートキャンプを受講しているかたは、課題の提出ではじめてコードレビューをうけると思います。 課題のコードレビューの場合、OKをもらえた/もらえなかったの2択で自分が評価され、学生時代のテストを思い出してしんどいと感じる方もいるようです。 ただあくまでコードレビューというのは、チームのコミュニケーションの1つでしかないので、そこまで気負わなくてもいいと思います。 「これってどういう意味ですか?」と自分が思うことは、他のチームメンバーも思う可能性が高いので、Github上のコメントに残すことで、皆んなが得をするのではと考えています。 少し話は逸れますが、一緒に働きたい人・自分の希望する環境を考える上で、コードレビューの文化があるか、その雰囲気は固すぎないかは大きな物差しになるのでは?と考えています。

私のはじめてのレビューはこちらになります。

github.com

実務に入る前にこのような体験ができるの、本当に貴重だな〜と思います。 コードレビューの質、スピードを上げれるように精進します!

日報を書こう! (日報自動投稿プログラムもあるヨ!)

この記事は4分程度で読めます。

はじめに

これは「フィヨルドブートキャンプ Part1 Advent Calendar 2020」14日目の記事です!

昨日は西田剛さんの 見えてきたエンジニア像 でした。

adventar.org

Part2もあります。 adventar.org

この記事で書いたこと

フィヨルドブートキャンプでは学習した日に日報を書きます。 4月から学習を継続できているのは、日報のおかげなのでは?とやっと気付き、いろいろな気持ちが湧いてきたのでまとめようと思います。 +αで日報に関係したコードを書きたかったので、日報自動投稿プログラムを作ってみました。 当たり前のことしか書けませんが、これが今自分が感じていることです!

なぜ日報を書くのか

データ集計のため

ラクティスの画面ではそのプラクティスにどれだけ時間がかかったか、中央値と平均値を集計し表示しています。 日報は15分間隔でしか学習時間を記録できないので、完全に正確な数値ではありませんが、参考になる数値なのでそのプラクティスの勉強をしたら必ず日報を書きたいところです。 学習したのに日報を書かないと集計されず、正確なデータから遠ざかってしまうので良くないな〜と思います。

お金がもったいないから

月額29800円は決して安くない金額です。 仮に毎日10時間学習したとして、1日の金額は1000円になります。 受講生はこの金額をメンターのお仕事への対価として支払っていて、メンターの基本的なお仕事は提出物・日報の確認と考えられます。 (それ以外にも就活の相談、プラクティスの改良、コミュニティ作りなどもあると思います。いつもありがとうございます!) もし勉強したのに日報を書かない日があったら、受けられるサービスを自ら放棄し、損していることになります。もったいない!

将来の自分、他の人が助かるから

自分だけしか読まない雑に書いたメモは、数日経つと何を書いているのか解読できないなんてこともありました。 日報は自分だけが読むものではないので、最低限他の人が分かるように書きます。 自分は何度も過去の自分の日報、他の人の日報に助けられました。

精神的な支えになるから

しんどいなと思った時は初日の日報を見返しています。 「初日の学習時間が10時間45分だと?! あの時はやる気に満ち溢れていたんだ.. また頑張ろう!」という気持になれます。 将来実務でしんどいなと思った時に鼓舞してくれるのは、自分が書いた日報かもしれません。

しんどい時こそ日報を書こう

振り返ってみてちょっとしんどいなと思う時こそ日報を書くべきだなと感じています。 しんどい時って学ぶことが多過ぎてどこから手をつけていいのか分からないと思います。 そんな時こそ最低限理解しているところ、分からないところを日報に書き、一度頭の中を整理するべきだと思います。 またしんどいという自分の気持ちを伝えるのも、日報が一番手軽だと思います。 その人がどんな気持ちかメンターは察することができないので、しんどい時はそれを言葉にした方がいいと思います。

進捗が出なかったり、何を書けばいいのかわからない時は、勉強時間と感想だけの短い日報でもいいので投稿しちゃいましょう。 何も書かないより何倍も良い!

日報自動投稿プログラム

たまに日報書くのをサボってしまうので日報自動投稿プログラムを作ってみました。 毎日WIPの日報を投稿してくれます。

f:id:mashoo1101:20201214033941p:plain
プログラムによって作成された日報

github.com

使い方

  1. report.rbにログイン名とパスワードを記述してください。
  2. 定期実行にcronを使用します。 crontab -eでエディタが起動したら以下のフォーマットに沿ってcronを登録します。
実行タイミング  Rubyのインストール場所  実行するRubyプログラムのフルパス

Rubyのインストール場所はwhich rubyで確認できます。

5 0 * * * /Users/mashio/.rbenv/shims/ruby /Users/mashio/auto-reporting/report.rb   

5 0 * * *report.rbを毎日0時5分に実行するという意味になります。

qiita.com

日報が投稿されない場合

設定した時間を過ぎても日報が投稿されない場合は、/var/mail/xxxを確認してください。

Mac OSがcatalinaの場合、以下の設定をする必要があります

mac-ra.com

コードの説明

以下ざっくりとした流れです。

  1. JWT Tokenを取得する。
  2. 取得したJWT TokenをAuthorizationにのせて、CSRFトークンとcookieを取得する。
  3. CSRFトークンとcookieをのせて、日報を新規作成する。

最初はcurlコマンドを使って書いていたのですが、読みにくかったのでRubyのコードに書き換えました。 以下のサイトでcurlコマンドをペーストすると、Rubyのnet/httpの形式に変換してくれます。便利〜 https://jhawthorn.github.io/curl-to-ruby/

まとめ

改めて日報って良い仕組みだなと思いました。書くしかない!!