2022年学んだ技術

筆者情報

今年からフリーランスとしてフロントエンドエンジニアをやっています。仕事では React + Redux Toolkit + TypeScript というごく普通の技術スタックです。

前職は受託開発会社で色々やっていましたが、直近1年はWordPressを触っていました。

Cloudflare Workers

2022年一番趣味で触った気がする。8月に無職になって暇になったので調べていた。「エッジサーバー上で動くFunction as a service」と言えば大体伝わると思う。

とにかくResponseが早い。無料プランなのにデプロイしたHello Worldレベルのコードが20-30msレスポンスを返す。

ちょっとした外部APIへのRequestでAPI Keyを秘匿して通信するために使ったり、キャッシュしてオリジンサーバーへのRequestを減らしたり、定期実行したりと色々使える。 関連するミドルウェアも豊富で、S3互換のR2や、Key-Value形式で保存できるKVがある。組み合わせればお手軽オレオレファイルアップローダーも作れる。

開発体験も良い。公式が用意しているwranglerでサクッとボイラープレートを用意したり、GitHub Actionsのworkflowを利用して自動デプロイ環境を簡単に組むこともできる。

ただ、既存のFunction as a serviceとは違い結構制限がある。 File base routingではなかったり、ワーカーの各種APIが少し癖がある。 またResponseの早さという旨味を活用するにはキャッシュしたりKVに保存/読み出しするなど、パフォーマンスを意識して書く必要がある。

とはいえ豊富にあるExampleやDocumentを見ればだいたい作れると思う。

次々発表される新機能の中で、Puppeteerが動く「Workers Browser Rendering API」はかなり注目している。 Vercel functionでPuppeteer動かそうとしたら諸々の制限で挫折したので、多少課金が必要でも使うと思う。

blog.cloudflare.com

npm ( Pure ESM パッケージの公開 )

npm の公開についてHello Worldレベルのことはしたが、それから最新状況を全然キャッチアップできていなかったのでおさらいした。

npm の CommonJS と ES Modules のアレコレも最近やっと落ち着いてきて、 Pure ESM という形式でnpmを公開することで、公開時のビルド設定やpackage.jsonに頭を悩ませる必要がなくなった、ということを知った。

TypeScriptで型付きでPure ESMで公開するときには具体的にどうすればいいのかは調べて下記でまとめた。

zenn.dev

自動テスト(単体テストコード)

恥ずかしながら仕事でも趣味でもテストコードを書く習慣が全然なかったので実行が早いと言われているVitestを使ってUnit Testを書いていた。

テストコードを書いた感想としては、後でテストしやすいように実装するので、基本的な「関数の責務や小さく保つ」「引数と返り値を意識して設計する」を意識してコード書けるようになった気がする。

前職で細かい修正のたびに手動テストして、それが開発の度に雪だるま式にチェック項目が膨れが上がるという辛い経験があるからか、自動テストは書ける段階から書いていきたい。新しいフレームワークを入れるにしても、どうテストを書くかも意識していきたい。

手動テストに対する所感はベテランの人も述べていて、やっぱり自動テストでコードを書いたり捨てたりできるポータビリティの担保は大事、と思った。

yshibata.blog.ss-blog.jp

これはDBにデータを投入してチェックする時のUnit Testを書いた記録。

zenn.dev

2023年に触りたい技術の領域

• 機械学習
• AWS & GCP

機械学習に関してはキーワードは点々とは耳にしているが、手を動かしていないのでどう動いているか実感がない。画像中の物体認識や自然言語処理をやれたら面白いことできそうだなと思いながら学んでいる最中。

AWSやGCPは、自分が無料でデプロイできるサービスばかり使っているのと、インフラをガッツリ構築する機会が仕事でもないので後回しを続けているが、いい加減一人で一通りできるように向き合いたい。

まとめ

大体の場合は技術やライブラリは必要に駆られて1ヶ月程度でキャッチアップしながら仕事で学んだ方が良いと思う。なのに、こうやって趣味の時間で技術を学んでいるのは面白さを感じているからではあるが、問題に対して対応できる手札を多く持っておいた方が良いと考えているからでもある。

経験を積む中で、別のアプローチだったらあっさり解決することを不適切なアプローチで労力かけて解決しているんじゃないかと疑心暗鬼になることがあり、その不安を軽減する意味合いもある。どうやっても大変な事はあるが…

そもそもとしてそれは解決するべき事なのか?という議論もしたいが、自分に降ってくる時点で「やると決まった事」なので自分がwhyを入れる余地が無い…辛い!

とりあえず目の前の問題に向き合いながら、目の前の問題で埋もれないように頑張っていきます。

Web フロントエンド実務未経験でフリーランスとしてフロントエンド案件に参画して2ヶ月の感想

参画する前の状態

Web フロントエンド(主に React + TypeScript)を趣味で 2 年ぐらい触っていたけど、実務としてフロントエンドをがっつり触る案件に恵まれなかったという状況でした。

受託開発会社でWeb エンジニアとして 3 年ぐらい働いていましたが、どっちかというとコード書くより社内での Google Workspace 導入とか社内 Wiki 整備とかそういう DX 系のことの方が多かったです。

良かったこと

• 思っていたよりコードをガシガシ書く
• 思っていたより趣味でやっていることもちゃんと通用すると実感できた
• 「フリーランスとして活躍してるエンジニアは全員バキバキにできる人」という先入観がいい意味で崩れた
• 良くも悪くも React + TypeScriptを採用している現場のことを知れた

前職だとコード書く仕事が少なかったのでそういうものかと思っていましたが、現在の現場では毎日ガシガシ書いています。 もちろんコード書くだけじゃないですが、前職とは全然違うので良い意味でカルチャーショックです。

前述の通り、趣味ではフロントエンドやっていたけど実務では無縁だったので「通用するかな?」と思ったけど幸いなことにやっていけています。

「フリーランスで使えない奴はすぐにクビ切り」とあらゆるところで脅されまくってビビり散らかしていていましたが、結構初歩的なことで詰まっている人も居て、それに対して質問していい雰囲気があったので安心しました。

フロントエンドは変化が激しいというのも落ち着いてきて、複雑なUIを作る際にはReactが「枯れた」立ち位置にはなってきたと思います。 ただ、Reactはフレームワークであり、良くない設計であれば腐ります。 その点では基本的な「関心の分離・捨てやすいコード」を意識した書き方はどこでも大事。

悪かったこと

• 責務が分断されすぎて、トラブルがあった時に責務を超えて動けない
• 契約の交渉がよくわからない

趣味でやっているときは基本的に 0 から 10 まで全部 1 人でやってしまうので、責務が分かれていると「あーこれ自分で巻き取ってしまえばすぐに終わるのに」ということを考えてしまいます。

とはいえ担当する責務が多くなると自分のキャパシティを超えて期待通りにできないこともあるだろうなというので、責務が決まっているのは一長一短だと感じています。

案件の交渉ですが、自分自身が経験が浅すぎるのであんまり強く言えないかな、と弱気になっているところと、交渉自体が人それぞれ過ぎて知見がないので未だに分かっていません。主導権をある程度握らないと駄目だなとは思っていますが…難しい。

まとめ

結果論にはなりますがフリーランスとしてフロントエンドの実務経験を踏み出してよかったと思います。良い意味で色んな「壁」を壊せたと思います。

退職してフリーランスエンジニアになるためにやった役所手続き

お断り

これは自分がフリーランスエンジニア(個人事業主)として開業するために行った役所の手続きの記録です。案件の獲得のノウハウはありません。

概ねの場合、これで充分だと思いますが、不安なら市役所の窓口に聞けばだいたい教えてくれます。そこで確認してください。

覚えるのが苦手な人は「退職後2週間以内にやらなきゃいけない手続きがある」と覚えてください。

やったこと

最低限やる必要があるもの

• 退職直前まで在籍していた会社へ退職証明書発行を依頼 (年金、保険の手続きで使います)
• 役所で国民健康保険への切り替え (退職してから2周間以内)
• 役所で国民年金への切り替え (退職してから2周間以内)
• 開業届を税務署に提出 (実際に仕事するまでに出す必要あり、それより早くてもいい)
  • マイナンバーカードがある場合は電子で申請できます
• 確定申告 (2月~3月にやるもの、そのための準備を日頃からする)

必須ではないがやっておくと良いもの

• 仕事用のメールアカウント取得 (Gmail でいいです)
• 仕事用の口座開設 (ネット銀行で確認できる方がいい)
• マイナンバーカードの取得
  • 自己証明で使えるため。運転免許証がある人はそちらでもいいです。

やったことの解説

前提

自分はこういう書類や手続きに関してはかなり面倒くさいと感じている方なので、省力化できるなら省力化する方針です。

うっかりミスも多いほうなので、便利なシステムがあるならガンガン利用します。

仕事用のメールアカウントの準備

まずは個人用のメールアカウントと仕事用のメールアカウントは分けましょう。 個人用のメールに埋もれて仕事用のメールを見逃す可能性があります。

また、仕事中にTwitterやYoutubeをうっかり開いて集中できなくなったり、機密情報をSNSにお漏らしするリスクを減らすためです。

メールアカウントはGmailでいいです。寧ろ、Google Meetで商談することも多いため、Gmailアカウントの方がスムーズです。

お金があるなら独自ドメインを発行するのもありですが、ドメイン費用を払い忘れて失効したりとか、独自ドメインでGmailを使うためにGoogle Workspaceのプランに加入するとかでお金がかかるのでGmailで充分です。

開業届を税務署に提出

開業届の書類は freee開業 で作成しました。必要な事項を入力すると、必要書類をPDF形式で出力するので、後は印刷して一部手書きと捺印して完成です。

マイナンバーカードを発行していれば freee 経由で電子申請できるそうなのですが、自分は発行していなかったので税務署に持ち込みしました。

結局後述する年金と保険の件で役所に行ったので、この点は別に気になりませんでした。

www.freee.co.jp

作成した書類は下記のようなジッパー付きのクリアケースに入れて持ち込みました。手続きするための書類を色々まとめる必要があるため、クリアファイルよりはこのような入れ物の方がいいです。

Amazon | コクヨ クラシカル ポーチ A4ケース クリア F-VBF230T | ペンケース | 文房具・オフィス用品

ちなみに開業届を出すと、失業給付金がもらえなくなるので、退職後に暫く休んでから開業したい人は気をつけてください。

厚生年金→国民年金&関東ITソフトウェア健康保険組合(ITS)→国民健康保険への切り替え

役所で手続きしました。この手続きは退職後2周間以内に行う必要があります。

特に保険は忘れると保険適用外で医療費を払うこともあるため、できれば退職した翌日に切り替えするのが望ましいです。

切り替えに必要な書類は地方自治体のWebサイトを参考にしてください。 自分の場合は自己証明の書類として運転免許証があるのでそれを使いました。

年金と国民健康保険の支払いはクレカ、口座引き落としに切り替えができるケースがあります。コンビニ支払いでも可能ですが、忘れると後が大変なのでこれも自動で決済されるようにします。

ITSですが国民健康保険に切り替えず、任意継続もできます。この場合は会社と折半して払っていた保険料を全額自分で払うようになります。

www.its-kenpo.or.jp

自分は2年後に再度手続きするのを忘れそうなのでさっさと切り替えました。

確定申告 & 仕事用の口座開設

来るべき確定申告の記録のためにfreee会計、仕事用の口座はfreeeとの連携のためPayPay銀行を利用しました。

確定申告は過去にやったことがあるのですが、怠い記憶しかありません。また個人事業主のため、収入や経費の記録するツールが必要です。

そこでfreeeを利用することにしました。元々仕事でfreeeを使っており、操作に慣れているためです。

また、開業届の作成をfreeeで作成したため、そのまま会計もエスカレーションした形です。

仕事用の口座はfreeeとの連携を考慮してPayPay銀行にしました。連携に関してはまだ会計を入力していないのでよくわかりませんが、運用してみて気が付いたらまた別のブログ記事として起こす予定です。

PayPay銀行開設の際に屋号を必須で求められていたのでとりあえず「エンジニア」を屋号にしました。

www.paypay-bank.co.jp

まとめ

軽いはずみでフリーランスになったとはいえ、こういう手続きに苦手な意識があって不安でした。しかし、やってみると情報がWebサイトに掲載されていたり、ツールがあるため難しくありませんでした。

来るべき確定申告についてですが、ぶっちゃけ開業や税制について理解があやふやなので、freee開業に登録して届いた開業ガイド読んで勉強します。

3年4ヶ月勤めた受託開発会社を退職して無職になりました

Hasta la vista, baby

退職エントリーです。 2022/07/31 をもって 3年4ヶ月勤めた受託開発の会社を退職しました。

こういう内容を長々書くのはいかがなものか、という意見もありますが、他の人の退職エントリーを読んでて自分も転職の意思が言語化された経由があるので、自分も書きます。

退職した理由は下記に続いています。

会社の事業の方向と自分がやりたいことが噛み合わないため

一番の退職理由です。

会社の方針として非IT系企業のDX支援事業に注力すると発表がありました。具体的はグループウェアの導入提案や補助になる想定で、コードを書いてソフトウェアを開発することから離れそうでした。

一方で、自分は趣味の時間でもコードをガリガリ書いたり、ライブラリをチェックしたりするのが好きです。コードを書いて、プロダクトを開発して、それを改善するサイクルが好きです。

物事の解決に対して、コードを書くという「手段」に拘るのはエンジニアとして不適格かもしれません。ただ自分はコードを書く工程が好きで、それが一番パフォーマンスが出せると思っています。

また、色んな会社のテックブログにて、新入社員が新機能や開発の改善をしました、などの発表をしていることを見かけます。会社に3年もいるのにまともにプロダクト開発ができていない自分からすると衝撃的で「こんな世界もあるんだ」という思いと同時に、歴だけ長くてまともに実務でコードを殆ど書いたことがない自分には、激しい焦燥感が募りました。嫉妬しました。

会社には、そういうチャンスは今後は残されていないか、あってもかなり少ないと思ったため、見切りをつけました。

仕事上の心労から離れるため

詳しいことは省きますが、仕事上の心労が去年あたりから無視できないレベルで酷くなりました。

平日では仕事終わりの時間になると急激に眠くなって残業が辛くなる、寝起きの時間が制御できず寝坊するなどの睡眠リズムの乱れがあったり、休日中も無気力感が強くずっと寝込んで、やっと動けるのが日曜日の午後、というのもありました。

食事をしているときや趣味を楽しんでいるときでもずっと仕事上の悩みが思い浮かんで、辛い気持ちがずっと晴れませんでした。

心療内科にも行こうとしたのですが、4ヶ月待ちと言われて通うのも断念しました。

仕事はずっと忙しく、休職するには診断書がないと言い出しにくかったため、結局無理に仕事を続けて更に悪化しました。

心身がもう限界近かったので、現在の仕事から離れることを決意しました。

受託開発ではなく、自社サービス会社で開発をしたい思いが強くなった

受託開発をしていて自分が辛いなと思ったのは「自分が開発している機能で喜んでいる人数が少ない」ということです。

受託開発の現場では直接のお客さんが居て、その人の要望通りに作ります。 ただ、中には「なんでこんな仕様なの?」「これは前提となる要望が間違っているんじゃないか?」といった無茶な注文もあります。 しかし自分が居た会社で開発するものは、使用者が数人規模であることが多く、断る要因も少なく、部分最適化のような場当たり的実装をやることがしばしばありました。

言われたままのものを作るための場当たり的な実装を何度かやっていて、「もっと汎用性を持った手段を作ってみたい」と要望を抱くことがあり、モチベーションが上がりませんでした。

そういった経験からどうせ手間をかけて開発するなら、実装するものに対して納得感をもって取り組みたいですし、部分最適化よりは広く存在している課題を共通化して汎用性をもたせた解決策を作ってみたいです。 ある程度の汎用性を持った機能を開発できる経験は、多くの人数が使っているソフトウェアの開発ではないと得られないと思っていて、自社サービスの会社にあるんじゃないかと思っています。

今後はどうするのか

8月以降はフリーランスエンジニアとして活躍する予定です。

フリーランスエンジニアには年齢要因で単価や求められる職種があり、30歳という年齢を考えると、バリバリに開発して経験を積んで単価を高めていくチャンスは、今後多く残されていないと感じています。

なので、1年ぐらいお試しでフリーランスをやって、良かったら数年続けて、その後に進路を考えてみたいです。

ただ、エージェントに登録して2ヶ月近く探してもらっても仕事が無いので、フリーランスを諦めるかもしれません。

最後に

8月以降の仕事が決まっていないので、8月は夏休みになりそうです。ちょっとしたバカンスで休みます。

開業届は出しますが、このまま全然フリーランスの仕事がなかったら普通に就職活動する予定です。

30 歳で受託開発会社を退職してフリーランスのエンジニアとして実務の開発経験を積もうとしている

概略

7 月末で 3 年間勤めた受託開発会社を辞めることにしました。

退職理由としては「実務上の開発経験がほとんど詰めず、雑用業務ばかりで、今後もそういうのに関われる可能性が低いため」です。

自分自身は Web 技術が好きで、特にフロントエンドの領域を独学していて面白いと思っているので業務でもそういうことに関わっていきたいと思っていたのですが、案件の運がなさすぎて今の会社ではそういう開発業務に殆ど関われませんでした。

そのため「経験年数の割に、開発経験がない」というのがコンプレックスになっていて、その上、自分のキャリア的には良くないと自覚していました。

そこで色々考えた結果としてフリーランスエンジニアとして転職しました。

退職後の選択としてフリーランスを選択した理由

Web フロントエンドポジションを志望しているのでそのポジションの求人がある会社に転職しようかと思っていたのですが、2 社連続で「開発経験積ませてあげる」と言われて入った会社で開発経験を積むことができなかったため、次に会社選びに失敗して実務の開発経験が積めない場合はキャリア的にも厳しくなります。

会社に所属する以上、「開発だけやってください」とは言い切れず、それとは異なる業務をやってもらう必要が出てくるので仕方ないです。ただ、自分の場合は開発の業務が少ないどころかほぼないため、かなり意欲的には落ち込んでいました。

そのため、事前の面談である程度業務内容を把握して、了承するか否かが選べて、あまりにダメなら案件から降りることができるメリットがあるフリーランスを選択しました。

フリーランスは契約が切れてしまうとその間無収入になるとか、単価交渉をするとか、デメリットもあるのですが、自分にとってはそのデメリットを補ってでも「実務の開発経験が積める」メリットを得たいと思っています。

何故実務の開発経験を求めるのか

趣味で Web 技術で遊ぶのが好きで、暇な時は技術情報サイトや GitHub や気になるライブラリのドキュメントを読んだり、それを元に実装したりするのが好きです。

ただ、実際の開発現場では「実務上で開発経験があるか」がかなり重視されます。これは求人票を見ても「実務の開発経験 3 年以上」というのを何度も見かけた体感からです。

また、フリーランスのエージェントさんとも話したのですが、趣味で学習してポートフォリオにして宣伝できるけど、実務で開発経験の方が強く評価される、ということも聞きました。

というわけで「実務経験を積むための実務経験がない」という悪循環を断ち切りたいために、実務経験を求めています。

退職後のあれこれ

7 月末で退職した後は、1 ヶ月程度休養を取る予定です。

退職を決意できたのも、GW で 10 日ぐらいボーッと現職から離れて正常判断ができたのが大きく、自分には休養が必要だと実感しました。

キャリア的に空白が開くのは良くないと思うのですが、現職で休職するか限界まで迷うぐらいに疲弊したのと、ここ最近の健康状態が全然良くないのでそれを治したいです。

休養後はフリーランスの案件を受注できるように、需要の高い技術や、自分の興味のある技術を独学しながらアウトプットしていきたいです。

サーバーサイドの勉強とか、逃げ続けている AWS/GCP や Rust などを、最低限できるようになりたいです。

余談

フリーランスになるにあたって、自分自身がフロントエンド開発経験積めればいいと思っていたので、あんまり単価を気にしていなかったのですが、現時点の単価予定額を周りに伝えたら「あまりにも安すぎる」「馬鹿すぎる」とボロクソ言われました。フリーランスになる前からフリーランスのことで怒られました。

15%OFFセールに釣られてアーロンチェアを買った

Mr_ozin with Aeron Chair

感想

まだ2日しか使っていませんが、ゲーミングチェアを使っていた時の「ある程度座っていると腰の疲れが溜まって休憩したくなる」というのが無くなって、疲れが溜まらず、ずっと座っていられます。

座面のフレームがガッチリしているため、座る時のポジショニングも迷わずスッと座れて直ぐに集中体制できます。

また、深く座ると背面のポスチャーフィットが当たって直立の姿勢がキープできます。

まとめると、「座り方を矯正されるが、疲れることなく姿勢をキープして集中できる」という感じです。

以下は買うまでの流れです。

---

筆者の情報

諸般の関係で質量の多い体型になっています。脚はかなり太めです。 がっちり体型の人が座るとどれが合うのか、という参考にしてください。

• 身長 : 161.9cm
• 体重 : 100kg
• 用途 : プログラミング、ゲーム

買った経由

ハーマン・ミラーのゲーミングエディションがセールで15%OFFでした。ちょうどその時使っていたゲーミングチェアが合わないと思い始めた頃なので買いました。

※現在はセール終了しています。

https://jpgaming.hermanmiller.com/

試座したところ

とはいえ20万円を超える椅子を試し座りなしで買うのは抵抗があったのでショールームに行ってきました。

• 大塚家具のショールーム
  • 新宿の店舗では「オカムラ」「エルゴヒューマン」「ハーマン・ミラー」のモデルが試し座りできるのでお勧めです。
  • IDC OTSUKA 新宿ショールーム
• ハーマン・ミラーのショールーム
  • 決定する前から買おうかと思っていたのでショールームにも行っていました。
  • 2日連続で通いに行ってお世話になりました。
  • ハーマンミラーストア丸の内

候補

• ハーマン・ミラーの「アーロンチェア」
  • 候補の中では、一番座れる姿勢の幅が狭い、よく言えば雑に座ってもポジショニングが定まりやすい
  • ベストポジションが50だと、40~60ぐらいの余裕を感じるような作り
  • 暑がりなのでメッシュ素材が助かる
  • 腰椎のサポーターがあるおかげか背筋をシャキッとさせることができる
  • サイズはBが一番ちょうど良かった。Aだと狭く、Cだと座面がデカくて最低にしても脚がつかないです
    • ガッチリ体型だとこの印象です。他の体型の人は公式のサイズ表を見てください。
    • https://store.hermanmiller.co.jp/c/about_size_aeron_chairs
• ハーマン・ミラーの「エンボディチェア」
  • アーロンのような座面フレームの出っ張りがないので、脚が太い自分がガニ股で座っても問題なし
  • 背中が椅子の背面の全体で支えられているような構造なので、負荷が分散される感じ
  • メッシュ生地ではないが、サラサラとしていてさわり心地がいい。冬はヒヤッとしなさそう
  • アーロンのようにABCのサイズが無いが、座面は背面を細かく調整できるので問題なし
  • 下半身がかなりがっちりしている、太ももにものが当たるのが嫌、ガニ股になってしまう、ポジショニングに余裕を持ちたい人だとアーロンよりこちらのほうがいいと思います
  • 余談ですが、肘掛けが内側に湾曲しているのでお腹周りが大きい人だと調整中にあたります
• オカムラの「コンテッサ2」
  • シンプルだけど懐が広く、ポジショニングに余裕があるのにさっと集中できる感じ
  • 座面にアーチがかかっているが、緩やかなので矯正される感じがなく座れる
  • アーロンのように色んなところが細かくチューニングできる、大体の人には合うと思います
  • 試座した段階だと疲れないので正直第一候補に近かった

選んだ結果

候補の中からスッとポジショニングが定まる「アーロンチェア」を選びました。「コンテッサ2」も買おうかと思いましたが、納期が30日以上かかるっぽくて、買いたい気持ちを熱い内に消化したかったでので断念しました。

「エンボディチェア」も「アーロンチェア」と同じぐらい快適だったため、だいぶ迷いましたが、暑がりなのでメッシュ生地を優先しました。

まとめ

高い椅子を買うと腰を労ることができる、というのはよく言われていますが、正しい姿勢が定まりやすくポジショニングを考えずに集中しやすくなる、という側面もあります。

20万円前後するので気楽に買えるものではありませんが、高い椅子は早く買って使うほど対費用効果が高くなるので、早めに手に入れることをお勧めします。

ゆめみ社のフロントエンドコーディング試験をやってみた

取り組んだものは下記です。

notion.yumemi.co.jp

応募する予定はありませんが、フロントエンドの素振りの課題としては面白そうと思って取り組んでみました。

やってみた感想として、適切に作ろうと思うと意外に設計に頭を使うのと、Unit Test の経験値がないことを突きつけられて面白かったです。 自分にはフロントエンドの実務経験が一切ないので、自分の中でバラバラに知見があった ESLint や Prettier、husky や GitHub Actions をアプリケーション開発の中で使用する、経験が得られてよかったです。

また、コミットやブランチの運用も採点対象になるそうなので、普段ものすごい雑にやっていたコミットやブランチ運用に緊張感を持って、他人が見ることを意識して取り組めました。

テストは 100％カバレッジを通そうとしましたが、モチベーションが尽きてしまったのでこれで終了です。

------------------|---------|----------|---------|---------|-------------------
File              | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
------------------|---------|----------|---------|---------|-------------------
All files         |   97.22 |    97.43 |   95.23 |   97.22 |
 src              |     100 |      100 |     100 |     100 |
  setup.ts        |     100 |      100 |     100 |     100 |
 src/components   |     100 |      100 |     100 |     100 |
  Chart.tsx       |     100 |      100 |     100 |     100 |
  Prefectures.tsx |     100 |      100 |     100 |     100 |
  Title.tsx       |     100 |      100 |     100 |     100 |
 src/lib          |   95.02 |    95.83 |     100 |   95.02 |
  client.ts       |     100 |      100 |     100 |     100 |
  constants.ts    |     100 |      100 |     100 |     100 |
  hooks.ts        |   84.84 |     92.3 |     100 |   84.84 | 21-24,45-46,49-52
 src/test         |     100 |      100 |      80 |     100 |
  utils.ts        |     100 |      100 |      80 |     100 |
------------------|---------|----------|---------|---------|-------------------

成果物

着手して 10 日ぐらい経っているが、実動は 24 時間 ( 3 日 ) ぐらい。本業が忙しかったり体調を崩してなかなか進めなかったのと、 Vitest の設定にちょっと苦戦したので思ったより時間がかかってしまった。

population-app-iota.vercel.app

リポジトリ

github.com

注意した点

dependencies を最小にする

• 脆弱性を極限まで減らすため。また、依存関係をシンプルにして React の知識があれば誰でも読み解けるようにするため
• 基本的に Web API、React の API だけ使って構築する。Redux も使わない
• グラフは自作するのが大変なので recharts を使った
• 最終的に 3 つのライブラリだけ dependencies になった

github.com

Linter と Formatter の設定

• プロジェクトを作ったら 2 コミット目で設定完了するぐらいの勢いで早めにやっておいた
• husky と lint-staged を使ってローカルで自動実行できるようにした
  • Unit Test と違ってこの辺りは実行環境に影響されないため
• 手動実行を信じない、CI の Lint や Formatter で弾かれないようにした

Unit Test

• テストと実装をセットで考えた
• Jest に近い API の Vitest を使ってみた
• 基本的にテストしやすい形で書くので、関数の責務を小さくする必要があった
  • 引数や返り値を適切に設計する必要があった
• React をテストするのに @testing-library/* 系のテストライブラリの使い方を理解した

CI/CD の設定

• CI は GitHub Actions で設定
• 適切にキャッシュを使って実行サイクルを速く下
• 各ステップ毎に name を振ってどこまで終わったかを分かりやすくした
• 実行環境に左右されないように、Unit Test は CI で実行し、ローカルでは実行しない方針にした
  • Node.js ではあまり影響はないと思うが、実行環境を統一することでトラブルを減らした
• CD は Vercel で設定
  • お金をかけたくなかったのと、設定が楽なので採用した。Pull Request にプレビューホスティングされるのありがたい
• API キーを漏らさないために、ローカルでは .env.local を、CI/CD では環境変数から API キーを渡すようにした
  • アプリケーションを Chrome の開発コンソールの Network タブを見てしまうとバレてしまうが仕方ない

反省点

• モックを適切に使ってカバレッジ 100％にしたかったが、できなかった。もっと簡単な例で素振りをする
• Custom Hooks が汎用性のない、ロジックの切り出しになったため、再利用性が薄くなってしまった
  • 重複したところも多い。また、適度な抽象化を行いたい
• Prop Drilling になってしまったため、素直に React.createContext() でコンテクストを使えばよかった
• テストの書き方も Example を見つつ書いているが、どこまで書けばいいかわからなかった
  • ここら辺は実務経験がないことがネックになっていると感じる
  • とはいえこれはグループ毎に文化が分かれていそう

まとめ

テックリード職を前提として取り組んだが、フロントエンドのテックリードなら 1 つの JavaScript フレームワークに精通して、Unit Test のテストフレームワークの使い方や書き方を覚えていて当然とは感じた。

複数の JavaScript フレームワークを知っていることより、Linter、Formatter、Unit Test を CI 上に乗せて一連の流れを構築できる方が、開発する側としては大事だと改めて感じた。

個人的に TypeScript に関しては「型があるから JavaScript」より難しいとは思わず、寧ろ実行する前にエラーになる原因が明らかになる点で JavaScript よりは難易度が低いと思っている。

当初の目論見通り、JavaScript のフレームワークの素振りとしてはよかった。

個人だと、どうしても動けばいいレベルで、あまり複雑にならないためテストがおざなりになってしまうので、いい勉強になった。