近況 〜株式会社ラグザイアを退職して株式会社エンペイに入社します
はじめに
この記事は「Rubyist近況[1] Advent Calendar 2021」の19日目の記事です。1スレ目はコチラです。
近況
退職
今月いっぱいで株式会社ラグザイアを退職します。
12/10 が最終勤務で今は有給消化期間中です。
最後の半年くらいでかなり大きい機能の追加があったんですが、なんとか終わらせてから去ることができました。
技術
ここ2年は仕事では TypeScript と React ばかり触っててました。
ESLint 力・お型付け力はかなり高まった気がします。
Ruby・Rails はほとんど触れてませんが、仕事の課題を解決するために Gem 作ることで Ruby 使ってました。
2020 年に katarina を出したのと、あと退職前に papath というちょっとした Gem を出す予定です。
体調・私生活
仕事が忙しすぎて生活が不規則・不摂生になりすぎて皮膚がかなりアレなことになっています。一時期は痒みがひどすぎて仕事になりませんでした。
今は皮膚科にかよいつつ、食生活も見直しながら改善に努めてます。
元々体は健康・丈夫な方なんですが、それでも無理をしすぎるとここまで体って壊れるんだなということを実感した1年でした。
いのちだいじに
入社
来月からは株式会社エンペイにJOINします。
正式な入社は来月なんですが、今週頭から有給消化期間を利用して先立って業務委託でお手伝いさせてもらっています。
入社した経緯
以前から同じフィヨルドブートキャンプの卒業生で一緒に輪読会をやっていた 小口さん に声をかけてもらって、エンペイのブログを読み漁ってみてカルチャーに一目惚れしました。
一応以下のようなことが転職先としての条件でしたが、仕事が相当バタバタしていたのとマルチタスクがあまりに苦手なのとエンペイが自分の働いてみたい条件とマッチしすぎていたのとで結局転職活動はエンペイ1本でした。
- 自社サービス企業
- サーバーサイド・フロントエンドのどちらも触れる
- Rails を使っている
- アーリーステージくらいの規模感
実際に入ってみて
楽しい。とにかく楽しいです。
ブログに書いてあるままのカルチャーでした。
CTO の 田野さん をはじめメンバーがとにかく褒めてくれるので自己肯定感が爆上がりします。
Slack へのレスやリアクションもめっちゃ早いです。
まだ JOIN して1週間ですが、開発体験はすごく良いです。
一番驚いたのは README やドキュメントがかなりしっかり書かれていることです。
困ったときは Notion か README を探せば何らかの情報が見つかります。
もし不備が見つかったときでも気づいたメンバーがシュッと直しているのをよく観測します。
Ruby のバージョンは 3.0、Rails のバージョンは 6.1 です。
そしてここぞとばかりに JOIN して1週間にして早速パターンマッチと右代入を使ったアカウントがこちらですw
今までは受託開発の会社ばかりで初めての自社開発なのでまだまだキャッチアップしていかないといけないことが山程あるんですが、新しい知識・経験・学びが多くて苦にはなってないです。
来年やっていきたいこと
JavaScript のコミュニティ立ち上げ
フィヨルドブートキャンプでも JavaScript に躓く人が多い印象なので、JavaScript に関して質問しやすい場を作りたいなーと以前から思っていました。
またリファクタリング 第2版の輪読会をやりたいな〜とも目論んでいます。
一番の問題はどの曜日のどの時間帯にやるかなんですがw
積ん読消化
読みたい本があまりに溜まっているので、来年は本を読む年にします。
「失敗から学ぶRDBの正しい歩き方」とか「モノリスからマイクロサービスへ」とか
LT・発表
仕事が忙しすぎて今年はLT・発表する機会がすごく少なかったので来年はもう少し増やしていきたいところ。 Omotesando.rb でコンスタントに LT するくらいに戻していきたい。
OSS
OSS活動も今年はほとんどできなかったので、来年はもっとやっていきたいですね。 gem_rbs_collection とかコントリビュートしていきたいなー。
生活改善
今年は私生活がひどく荒れたので来年は住環境や食生活、運動習慣を少しずつ以前の健康だった頃に戻していきたいですね〜。
終わりに
来年はもう少し健康に生きたいですね。 転職活動も無事終わったし来年も一年頑張るぞい!
レビューするときにやっていること・気を付けていること
はじめに
この記事は「フィヨルドブートキャンプ Part 2 Advent Calendar 2021」の19日目の記事です。Part 1もあります。
最初書こうとしていたネタがいまいち筆が進まなかったので今日急遽このテーマにしました。
最近のフィヨルドブートキャンプのチーム開発のプラクティスでは現役生同士でレビューをしているので、自分がレビューする際にやっていることや気を付けていることをただただ書きなぐって「レビュワーになってこれからレビューをしないといけないけどレビューって何すればいいの・・・」というフィヨルドブートキャンプ現役生の助けに少しでもなればいいなぁと思っています。
読んでほしい人
- これから初めてレビュワーを担当する現役生
- レビュワーをすることに苦手意識を持っているエンジニア
- レビュワーをするのが大変そうでいつも他の人に任せてしまっているエンジニア
- どんなことを考えながらレビューをしているのか知りたい人
注意事項
- 自分も常に全てできているわけではないです
- 全部が全部万人に合うわけではないです
- 「これいいな、やってみよう」と思ったものを見つけて試したり自分にあうやり方にカスタマイズしていったりしてもらえれば
先に伝えておきたいこと
この後色々書いてますが、あくまで自分の例です。
レビュワーをするときはあまり難しく考えず自分やチームの知識が深められれば OK、ちょっとでも学びを得られたら大成功、くらいの精神で気楽にやってほしいです。
バグを見つけようと気負う必要もないですし、気の利いたコードの書き方を提示しないでも大丈夫です。
「何も指摘できそうにない・・・指摘できる自信がない・・・」という場合はわからないところやちょっとでも気になった箇所について質問してみるだけでも OK です。
それでスキルや知識が向上すれば万々歳です。
やっていること
自分が使っているエディタでコードを読む
レビューをするときは基本的にローカルのマシン上で普段使っているエディタ、自分の場合は RubyMine を使ってコードを読んでいます。
GitHub の Pull Request 上でも読むことは可能ですが、ローカルのエディタで読むことには以下のメリットがあります。
- 変更箇所以外のコードを把握しやすく、エディタ次第ではコードジャンプも利用できる
- Diff が見やすい
- typo チェッカー、Lint のチェック、型チェック(TypeScript 等の場合) 等が利用できる
一方、レビューしたいけど別の作業中でコミットしていないファイルが手元にあることはよくあります。
そういう場合は、作業中のブランチに tmp のコミットを積んだり stash したりして現在の作業状態を退避しておきます。
@onk さんのブログにあるように TODO.txt を書いておくか tmp のコミットのコミットメッセージかに残しておくかをやっておくとレビューが終わった後に作業を再開する(場合によっては翌日だったり翌週だったりになる場合もある)ときにすごく便利です。
参考
概要・背景 → 全体の差分 → コミットごとの差分の順に確認
レビューでコードを読み進めていく手順としては以下の順番で進めています。
- Pull Request の Description や関連 issue を読んで概要や背景を把握
- Pull Request 全体の差分を確認
- コミットごとの差分をコミットメッセージも含めて確認
他の人がどうしているのかはわからないですが、自分の場合は各コミットのコミットメッセージまで確認しています。
ここに実装・修正の意図や理由、経緯、参考にした情報等がしっかり書いてあると、必要なコミュニケーションの量も減るのでレビューするときにすごく助かります。
Pull Request の Description に書かれていれば十分、という主張もありますが個人的にはコミットメッセージにもきちんと情報を残しておいてほしいです。
コミットメッセージがしっかり書かれているとレビューが終わった後もバグ調査の際や後に別の人(将来の自分含む)がその場所のコードを読むときに役に立ちます。
もし修正理由を書けるほどコードを理解していない場合はペアプロ・モブプロをして理解を深めつつコミットメッセージを整えていってもいいかもしれないです。(これはあくまでジャストアイディアです)
コミットメッセージの良い書き方についてはいいブログ記事やスライドがたくさんあるので参考リンク先を読んでみてください。
参考
コードには How
— Takuto Wada (@t_wada) September 5, 2017
テストコードには What
コミットログには Why
コードコメントには Why not
を書こうという話をした
実際に操作してみる
自動テストがある場合でも、一度は実際に手動で動かしてみて確認してみるのをオススメします。
ここで動かす際は、他の色んな機能と組み合わせて動かしてみたりコードを読んでいて気になった条件分岐のところを確認してみたりこんなことしたらどうなるだろうという意地悪な使い方をしてみたりするのがコツです。
アプリケーションにもよりますがまれによく仕様の見落としや思わぬバグを見つけられたりできます。
どんな人間にもミスや見落としは必ずあるので、実際に操作して確認するときだけは「信頼しても信用するな」の精神で自分も他人も信用しない意地の悪い人間になって色んな操作をしてみてください。
気を付けていること
いいところを探し、褒める
レビューを受ける側も人間なので、指摘ばかりだと気分が落ち込んでしまいます。
なのでレビューというプロセスの中で一度は相手のことを褒めたり称賛したりするようにしています。
人はネガティブな情報の方が印象に残りやすいので、それを打ち消せるくらいにやるのがコツです。ちょっとしたことでもとにかく大げさにオーバーリアクションに、絵文字や bot 等も使って盛大にやります。
コミットメッセージとか README の更新とかサボられがちなことをきちんとしてるのを見たらもうその人は天才、英雄、伝説ですよ。
テキストで伝えるのが難しければビデオチャットを利用する
これテキストにするの難しいなーとちょっとでも感じたらビデオチャットで口頭と可能ならコードの修正例も添えてやり取りするようにしています。
あとこのときに同時編集可能なドキュメントツールを使ってメモを取りつつやり取りし、終わった後に Pull Request に何らかの形で反映しておくとログとして残せて便利です。
HRT を欠かさず相手が嫌な思いをしないように気を配る
HRT とは
- Humility(謙虚)
- Respect(尊敬)
- Trust(信頼)
の3つを合わせたものです。
HRT についての詳しい説明はここではしません。詳しくは Team Geak を読んでみてください。
Team Geak に
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。
とあるように、ちょっとした謙虚・尊敬・信頼の欠如から人間関係のトラブルは発生します。
そうならないよう、自分は以下のようなことをしています。
- 絵文字や語尾の伸ばし棒(ー・〜)を意識的に使い表現が柔らかくなるようにする
- 言い切りや断定的な表現、強い表現を使わない
- 相手の実装を尊重し自分のコメントはあくまで一意見ということをしっかりと伝える
- IMO や nits、MUST 等を使ってコメントのニュアンスを伝える
あとこれはここ最近得た学びなんですが、自身の心や時間に余裕がなくなると人間どんなに気を配っていても気づかないうちに性格や言動がキツくなります。
なのでそうなる前に、適度に休息やリフレッシュをするのをオススメします。
過去の失敗
コミュニケーションにはとにかくやりすぎくらいに配慮することをオススメします。
自分は現役生時代にこれを知らずに悪気なく行っていたレビューによって人間関係でトラブルを起こしたことがあります。
「エンジニアなら〜することが当然なので」のような言葉を使ってしまっていた記憶があります。
この出来事は今でも後悔しています。ただ後悔しても当時のこの出来事はやり直せません。
ちなみにその時 @komagata さんから「この本を読んでみては?」と教えてもらった書籍が Team Geak です。絵文字や伸ばし棒を使ったテキストの表現方法もこのとき @komagata さんから教えてもらいました。
その後もレビューとは関係ないですが自分の人間的未熟さから気を配っているつもりでも相手に不快な思いをさせてしまい Twitter でブロックされてしまったことも何度かあります。
一度こじれた人間関係を修復するのは本当に至難の業(一生修復できないかもしれない)ですし、その人の性格によっては本当に落ち込みます。
自分の場合、毎回しばらく仕事も私生活もできないくらい落ち込みますし涙が止まらなくなるし自分が嫌いで嫌いでしょうがなくなります。
自分も相手も誰も幸せにならない悲しい結果しか残りません。
ただ、人間関係がこじれる可能性は完全にはゼロにはできなくても、普段から最大限配慮して行動し、至らないところは改善を続けていくことで可能性を少なくしていくことはできます。
少しでも嫌な思いをする人が減っていくことを願っています。自分も少しでも相手に嫌な思いをさせる回数を減らせるよう日々精進していきます。
もし、改善したほうがよさそうな行動をとってしまっていたときは DM 等で教えてもらえると幸いです。
参考
おわりに
半日くらいでガーッと勢いに任せて書いた記事なので色々と至らなかったり雑だったり無駄に暗い話をしていたりする箇所もあると思うので何かあればご指摘ください。
明日は @machida さんと @yana-gi さんです。
コミュニティ初参加の手引き(フィヨルド生向け)
これは「フィヨルドブートキャンプ Part 2 Advent Calendar 2020」の25日目の記事です。 前回はlamp@FjordBootCampさんの「フィヨルドブートキャンプを卒業しました!」でした。
はじめに
自分はコミュニティに参加するのが好きでコロナ前の世界線では月平均8〜12回くらい、オンライン開催全盛のコロナ後の世界線では月に40回以上がデフォルト、多い月では50回近く参加しています。(今年のコミュニティ・勉強会参加回数を超ざっくりカウントしたら300回は余裕で超えてておそらく365回以上参加しているっぽかったです)
1日1回以上参加しているとか、よくわからんですね🤪
最近はミートアップ等でコミュニティについて聞かれることも多く、オンライン開催全盛の現在は選択肢がすごく多くて迷ってしまう人がたくさんいる気がするので、今回はこれからコミュニティに参加される方に向けて色々書いていってみようと思います。
なんでコミュニティに参加するといいの?
インプット・アウトプットすることが好きな人たちが多く集まっているので、得られる情報の幅がめちゃくちゃ広がります。
また、大体のコミュニティは slack のワークスペースか discord のサーバーが用意されているのでミートアップ外の時間でも質問することができます。
コミュニティに参加している多くのエンジニアは質問すれば喜んで答えてくれるので、どんどん質問するほうがお得です。コミュニティに参加する際は、質問魔になることをオススメします。
自分の場合ですが、転職前は Kobe.rb や Rails Follow-up Kobe、Rails Follow-up Osaka 等に毎回のように参加して自分の書いたコードをレビューしてもらったり疑問や質問をどんどん投げたりしていました。
プラクティス外でコードを書くことで実装の経験値もつくし、加えてレビューしてもらうことでよりいいコードを書くための知見も得られます。
さらに色んな場所で質問することで、質問の仕方がうまくなりますし、1つの質問に対して色んな角度からの回答をもらうことで様々な考え方を知ることもできます。
他にはプロのエンジニアと接することができる、というのもあります。
転職についても色々と相談したりできるので、フィヨルドブートキャンプの中でもコミュニティに参加している人の方が転職活動がうまくいっている印象があります。
平成Ruby会議の裏話
ちなみに自分が昨年登壇した平成Ruby会議の裏話を1つすると、Proc について色々調べ始めたのは 西脇.rb & 神戸.rb の Rubyプログラミングキャンプ 2018 のアイスブレイクで伊藤さんが書いた↓のようなコードがわからなかったからです。(実際のコードが手元にないためニュアンスだけですが)
foo = -> (bar) { p bar + 1 } [1, 2, 3].map(&foo)
このときまでチェリー本・パーフェクトRubyを通読していて「Rubyはほぼほぼ理解した」と思っていたんですが、まだまだ Ruby について知らないことが多くあるんだなと認識できました。
このキャンプの後に色々調べていくうちに Proc 周りについて色々と知見が得られたのが、平成Ruby会議登壇につながったのでした。
このように「知らない・わかっていない」ことをはっきりと「知らない・わかっていない」と認識することができるきっかけを得られるのも、コミュニティに参加する魅力だと思います。
※ さらにいうと翌年の Rubyプログラミングキャンプ 2019 in 松江 では登壇前の練習・レビューの機会も頂いたので、西脇.rb & 神戸.rb の存在なしでは自分の平成Ruby会議は語れなかったりします。
学習がどの程度進んだ段階で参加するべきなの?
これに関しては、結構色んな方から「Rubyのプラクティスに入ってから・・・」「Railsのプラクティスに入ってから・・・」という言葉をよく聞くんですが、「参加するべきタイミング」というものはなく、どのタイミングで参加しても大丈夫です。
これはRubyコミュニティかつもくもく会系に多いんですが、「Ruby」コミュニティといってもRuby以外のことをやっている人が結構な割合います。
なので、HTMLやCSS、LinuxやGit等についてのプラクティスの段階でも遠慮せず参加しちゃいましょう。
初心者だからと遠慮することはないです。
コミュニティや勉強会の開催者側の思いとして、参加してくれる事自体がすごく嬉しいと思っている人がほとんどだと思います。
どのコミュニティも、参加したら暖かく歓迎してくれると思います。
どんなコミュニティに参加すればいいの?
一番はじめは手を動かしたり質問のできる勉強会がオススメです。
ただ、LTや発表がメインのコミュニティに参加するのはやめとけ、というわけではないです。
もしLTや発表がメインのコミュニティに参加したい場合、わからない単語がたくさん出てくると思うので、メモれる限りメモって終わった後にググることをオススメします。
ちょっとでも参加したい・気になるという気持ちがあるなら思い切って参加してみましょう。
おすすめコミュニティ
後日追記します🙏
とはいえ
一番最初に参加するのはすごく緊張するので、はじめは知り合いが参加しているコミュニティに参加するのがおすすめです。
まあ、オンライン開催の間は大概自分が参加しているので気になったり参加してみたかったりするコミュニティがあれば気軽にフィヨルドブートキャンプのSlackでお声がけください(笑)
最後に
皆もっと気軽にコミュニティに参加するのデス
そしてもっとインプット・アウトプットするのデス
p.s. 締めに大遅刻かましてしまって本当に申し訳ない🙏
平成Ruby会議01で登壇してきました
はじめに
2019/12/14に開催された平成Ruby会議01で「Procのススメ」というテーマで話してきたのでそれについていろいろと振り返ってみました(本当はもっと早く書ききるつもりだったんですが体調が最悪だったり筆が進まなかったりで結局年末ギリギリの公開に(;´д`)トホホ…)
発表の経緯
今回の発表なんですが、元々この発表は社内での発表で使おうとしていたネタでした。
それを完全に勢いで、締め切りの1時間前くらいにasakusa.rbの帰りの電車で急いでCfPとして書いて提出したら通ってしまったのでした。
応募数が結構多く激戦と聞いていたので「まあたぶんダメやろなー」と思っていたんですがまさかまさかの採択。
通知メールを見た瞬間は嬉しさ半分もう逃げられないというプレッシャー半分でした(;^ω^)
CfPの内容は↓に書いたので省略しますm(_ _)m
当日までにやったこと
登壇が決まったあと、11/9〜11/10に西脇.rbと神戸.rbが毎年合同で開催している合宿があってそれに参加登録していたので、発表慣れしている伊藤淳一(@jnchito)さんに「合宿中に発表慣れしている伊藤さんにコツとか聞きたい・・・。」と投げてみました。
そしたら「雑な出来でもいいから、みんなの前でちょっと発表してみせてほしい。」という旨の返答をいただけたので合宿中にレビューしてもらうことに。
スライドは社内発表用にある程度できていたのでそれをそのまま使用しました。
結果どうだったかというと・・・
時間はかなりオーバー(うろ覚えだけど10分くらい)
指摘やアドバイスもめっちゃもらいました。
その後スライドはほぼほぼ作り直して、本番のスライドにはこの当時のスライドはほぼほぼ残りませんでしたw
このレビューないまま本番のぞんでいたらだいぶヤバかったと思います、感謝!
また、当初の資料の&修飾子の説明があっているか確認するために、rubiniusやC実装のparse.yを読むというのをやりました。
これまでも読んでみたい読んでみたいと思いながら後回しになっていたのですごくいい機会になりました。
当日について
当日はかなりギリギリまで資料作成と素振りをやってから会場入りしました。
その影響で金子さんの発表は全く聞けませんでした・・・( ゚∀゚)・∵. グハッ!!
その後も自分の発表が終わるまで他の人の発表聞く余裕が全くありませんでしたOTL
発表慣れしていると自分の発表もこなしつつ自分の番が来るまでの他の方の発表も楽しんだりできるものなんでしょうか・・・?
本番の発表は、
- 資料の例示がナンパラっぽいブロック変数のままだった(ナンパラでもうまくいくか確認できてなかった)
- 会社の紹介が慣れていない感が出てしまっていた
- 経過時間の確認のためにスマホのストップウォッチを開始と同時にスタートしていたが、自動ロックの設定を外していなくて役に立たなかった
といった反省点はありましたが、時間不足でカットすることもなく、伝えたいことは全部伝えられました。 用意していた笑いどころでもしっかり笑いとれましたし発表中にツイートもしてもらえていたのでなんとかうまくいったのかなーと思います。 始まる前は「誰も来なかったらどうしよう・・・」という不安もあったんですが、結果多くの人に聞いてもらえてよかったです。
発表を終えて
発表を通して、発表前よりもより多くの知識と自信がつきました。
CfP出したときはparse.y読むことになるとは思ってませんでした(;^ω^)
大変だったけど、めちゃくちゃ楽しくていい経験になったのでこれからもこういう場での発表のチャンスがあれば挑戦してい後と思います。
まずは発表中にやると宣言したGemの開発とQiitaの記事書くのをやっていくぞ〜!
最後に、運営の皆様、レビューしてくださった神戸.rb & 西脇.rbのメンバー、当日発表を聞いてくださった方々、ありがとうございました!ヾ(´∀`)ノ
平成Ruby会議01で採択されたCfP
この記事はCfPアドベントカレンダー17日目の記事です。
発表タイトル(※本情報は当選時にLPに掲載されます)
Procのススメ
発表の概要(※本情報は審査にのみ利用します)
意外とみんな知らない、明日からすぐに使えるかもしれないProcを使ったテクニックを紹介します
この発表を聴いた人が何を持ち帰れるか(※本情報は審査にのみ利用します)
知ってると得するProcの使い方
当日の資料
最後に
改めて見てもよく通ったなぁ、このCfP・・・(´∀`;)