Vue 3を取り巻く状況について移行作業を経験した身の視点で思ったこと
記事を読んでて、以前そこそこ大きめのサービスでバージョン2からの移行作業を経験した者として色々思うことがあったので個人的な思いを書きまとめてみることにします。
筆者自身はComposition APIの難易度よりもエコシステム・コミュニティ周りの影響も強いように思っているため、書き方よりこれらの話がメインです。
Vue全体に対する個人的なスタンス
まっしろな状態から始める場合は全然選択肢に入ると思っています。
一方でバージョン2から3へ移行する場合は、覚悟を決めて時間に余裕を持ってやる必要があります。むしろこれが一番の鬼門です。メンバーがフロントエンド開発に慣れてないとやってられなくなるレベルです。
Vue3への移行の辛さ
筆者が以前関わっていたプロジェクトではComposition APIには移行せず、2時代のOptions APIのまま進めてたのですが、先を見据えた対応を進めていたため、エコシステム・周辺ライブラリの大幅変更に追いつくのに必死でした（VuelifyみたいなUIライブラリを使ってなかったのは救い、、、）。
このとき個人的につらいなと思ったのが以下2点です。
- EOL（サポート終了）のアナウンスタイミング
- 周辺ライブラリの大幅入れ替え・breaking change
順に語っていきます。
EOLのアナウンスタイミング
Vue2のEOLが初めて明言されたのが3が登場して2年近く経った2022年6月のこの記事だったと記憶しています。
表向きはバージョン2.7のアナウンス記事ですが、最後の最後にこの一言が登場します。 ただしこのときはまだVue2のサイトには大きなEOLに関するアナウンスはまだなく、気づかなかった人も結構いたんじゃないかと思います。
This means Vue 2 will reach End of Life by the end of 2023
同年11月頃に以下の記事が投稿されて、EOLへのカウントダウンが本格化。
一方同じ時期にNuxt3も安定版に移行してました...って
VueはまだしもNuxt、もう1年しかないのにNuxt2を使い続けている人達に対してこの仕打ちはあまりにもひどくないですかね。。。 Vue2がEOLを迎えた瞬間、Nuxt2もEOLになるわけですが、未だNuxt2の公式サイトを見てもこの記載はありません。
これではすでに勢いマシマシだったNext.js、早い段階からベータ版と目立ったアナウンスを出していたNuxt3とほぼ同じ時期に安定版が出ていたSvelteKitに逃げたくなります。筆者はすでに逃げましたが。
周辺ライブラリの大幅入れ替え
「Vue 3 migration guide」というアップデート手順が丁寧に記載されているページがある。 このページを見てもらえばわかるが、推奨ライブラリがほとんど入れ替わってしまっている。
一応Vue 2では定番だったVue CLIおよびVuexも引き続きバージョンアップすれば使えるものの、前者はすでにメンテナンスモード、後者も更新がほとんどない。なので、近いうちに非推奨にされそうな雰囲気がしてたまらず、結局推奨の方に変えたほうがいいよねってなる*1。 Piniaは大きいアプリを作っているとこの仕様が本当に痛すぎる…
あと、文面上はバージョンアップだけになっているVue Routerとtest utils（テストツール）もVue 3のAPI 刷新に合わせて変更箇所は多いです。武器になるはずのユニットテストすら当分は全然動かせません。
唯一の希望がESLintのプラグインではないかと思うくらいなレベルです*2。
Nuxtはライブラリごとに基本それ専用のModulesを使うことになるので、その結果どうなったかはお察しの通りです。
おわりに
色々不満を書いてしまいましたが、バージョン2からの移行がしんどすぎるだけで新規でアプリを作っていくならグッドだよというのは強調しておきます。
最後にこの時期移行を頑張っている人たちのために助けになる記事を置いて置きます。
これは移行作業に携わっていたときに書き進めていたメモをもとに書いた筆者の記事です。 主に下準備段階に関してまとめています。
こちらの記事は書き方がメインとなっています。2と3のコード比較も乗っていて非常にわかりやすいです。
Nuxtはこんな記事が最近出てました。
破壊的変更は人が離れるのでやっぱりダメです。
「フロントエンド開発のためのテスト入門」感想
とりあえず1周してサンプルコードも一通りいじったので感想をば。
TL;DR
フロントエンド開発の自動テスト整備に悩んでいる人は絶対読め。 比較的作りやすいメソッドとかstoreのテストしか作ったことない人も読め。 Storybook放置しそう問題も取り除いてくれる。
ただしハンズオン本ではないことには注意。
読み方
よくあるハンズオン本ではありません。サンプルコードをダウンロードして動かして試すタイプの本です。
なので本に書かれていることやサンプルコードを見つつ、実際に業務などでアウトプットしていかないと身につかないかなぁと。 すでにJestを使っているならこんな書き方もあったんだ！みたいな目で見ると読むのが楽しいです。
ちなみにサンプルコードは私のM1 Macbookでも動作出来たので、Apple Slicon勢も安心してください。
良かったところ
Jestのモックにページを割いてくれている
jest.mock/jest.spyonの使い分けについてここまで理解しやすかったのは多分初めてです。
最初にモジュール全体をjest.mockしてしまう→jest.spyonで発火イベントを確認の手法は今後も真似していきたい。
Storybookを放置させないための取り組みが乗っている
Storybookを放置・断念してしまう話を過去何度か聞いたことがあったので、ずっと懸念していたトピックだったのですが、 「既存のJestで作ったコンポーネントテストと一緒に動かしてしまう」はまさに目に鱗でした。 読み終えた後ちょっと調べてみたんですが、手法自体2年くらい前からもうあったんですね。。。
公式でも触れられている。
ライブラリ固有の話をあまり持ち出してない
文中にもある通り、他のフレームワーク・ライブラリでも考え方が流用できるようにという意図もあり、Next.js・Prisma・Playwrightに関しての説明は最小限に留められています。 まずはモダンフロントエンドの実践的なテストテクニックの共有を伝えきってしまいたいという筆者の意気込みが伺えます。
気になったところ
個人的にはほぼ文句なしの内容でしたが、読む前に注意したほうが良さそうな点もあったのであげます。
ライブラリの設定の説明は少ない。
サンプルコードで記載の設定ファイルについての紹介は文中では出てきません。 公式サイトを当たる必要があるので、丸々日本語で知りたい人は少々注意が必要です。
tsx記法に慣れてない人は厳しい
Next.jsをお題にしている以上仕方ないかもしれないが、コンポーネントの記法が異なるVueとかAngularしかやっていない人には少々つらいかも。 知らない人は別記事で記法を見ておいたほうがいいかと。
ビジュアルリグレッションテストがreg-suit推しなのが気になる
reg-suit自体はいいサービス・ライブラリだと思うのですが、日本国外のユーザーがいるのを見たことない上、最終更新が半年前で止まっており個人的には躊躇ってしまいます。あと自前で色々ストレージを設定しないといけなかったりするのもマンパワーがないと辛い、、、
いまはStorybookの会社が出しているChromaticもあるので、こっちのほうが良いかなと思ったりします。しばらく運営は大丈夫だと思いますし、ホスティングするだけで面倒な設定を代わりにやってくれるので。 これもこれでやや金額は高いですが、個人だと（よっぽどテストを回さない限り）無料で使えます。
Chromaticについては、WEB+DB PRESS Vol.134の「はじめての画像回帰テスト」特集で実例を交えて紹介されているので興味ある人は是非是非。 これも非常に面白い記事でした。
余談
いくつかストックが溜まっているので、放置しぱなしのZennの方にも近日少しずつ記事を投稿していこうと思っています。ずっと目標の一つにしてきたbookも書きたいですねー。
モダンフロントエンド関連の書籍の発売が（良い意味で）最近相次ぎすぎや。
CSSの :has()・:is()・:where()を積極的に使って隣にいる要素からスタイルを簡単に置き換えよう
CSS近年登場した:has()・:is()・:where()という3つの擬似クラスについて紹介する。
新し目のクラスということで日本語の資料はまだまだ少ないが、覚えておくと便利なので是非この機会に覚えていってほしいです。
本編前の注意書き
本記事執筆時点（2023/04/22）で、:has()擬似クラスだけFirefoxのサポート対象外です（一応設定でフラグをONにすると使える参考。）。
サポートの最新状況は以下のページを参考にしてください。
:has()擬似クラス
hasの中に指定されたクラスの親要素のスタイル指定が出来ます。 特に子~子孫の要素のスタイルによって親要素のスタイルを変更できることに強みを持っています。
これまではJavaScriptを使わないと使えなかった方法がCSSで指定出来るようになりました。
サンプルコード
以下例のコードを載せました。
See the Pen Untitled by miily8310s (@miily8310s) on CodePen.
例では以下のことを行っています。
greenクラスのimg（緑のレゴの写真）タグを子に持っているarticle要素の背景色を緑redクラスのimg（緑のレゴの写真）タグを子に持っているarticle要素の背景色を赤- imgタグを持たない
article要素は中のテキストを中央寄せに
:has()擬似クラスの書き方
構造は以下の形です。
<親となるCSSセレクター>:has(<子~子孫となるCSSセレクター>) { スタイル指定 }
サンプルコードでは背景色を緑へ変更を以下で実現させています。
article:has(.green) {...}
ちなみに:not()擬似クラスと組み合わせて、子にいない場合のスタイル指定をしたい場合は注意が必要です。先に:not()を指定して上げる必要があります。英語と一緒ですね。
article:not(:has(img)) {...}
:is()擬似クラス / :where()擬似クラス
こちらは使い方は殆ど一緒なので、まとめて紹介します。
:has()擬似クラスが親要素のスタイルについてだったのに対して、:is()擬似クラス / :where()擬似クラスはカッコの中に指定したCSSセレクターに当てはまる要素のスタイルの指定が出来ます。コロン（:）始まりなのに慣れればそのままの意味なので簡単ですね。
サンプルコード
See the Pen Untitled by miily8310s (@miily8310s) on CodePen.
is()擬似クラス / :where()擬似クラス両方記載しています。どちらか一方をコメントアウトしてみると、どっちの書き方でも同じ意味をなしていることがわかると思います。
:is()擬似クラス / :where()擬似クラスの書き方
構造は以下の形です。
:is(<スタイルを当てたいCSSセレクター>) { スタイル指定 } :where(<スタイルを当てたいCSSセレクター>) { スタイル指定 }
サンプルコードではheader、footer要素の文字サイズ変更を以下で実現させています。
:is(header, footer) p { font-weight: bold; } :where(header, footer) p { font-weight: bold; }
複数指定することも出来ます。
サンプルコードでは、headerもしくはmain要素に内包されている、h1・p要素の文字色をピンク色に変えています。
:is(header, main) :is(h1, p) { color: #FF5F9E; } :where(header, main) :where(h1, p) { color: #FF5F9E; }
2つの違い
パッと見違いがなさそうな2つですが、実は決定的な違いを持っています。 :where()擬似クラスで指定したクラスの詳細度が常に0になる点です。
一見気にすることがないような点ですが、実はフロントエンド開発で共通用のスタイル指定に密接に関係してくる問題になります。
例えば共通用のスタイルで以下のスタイル定義をした場合、詳細度は以下のようになります。 詳しい度の数え方は今回触れませんが、2つのクラスを指定している影響で「2」になってしまいます。なので、詳細度を下回るスタイル指定をしてもスタイルの上書きに失敗してしまいます。
// 詳細度が2になる header p, footer p { font-weight: bold; } // 詳細度が1になる。なのでスタイルの上書きが出来ない。 p { font-weight: normal; }
ここで:where()擬似クラスに置き換えて見ましょう。詳細度が同じなので、これでスタイルの上書きが反映されます。
// 詳細度が1になる :where(header, footer) p { font-weight: bold; } // 詳細度が1になる p { font-weight: normal; }
これまでスタイル指定が上手くいかないときは!importantを指定して無理やり適用してしまうケースも少なくありませんでしたが、:where()擬似クラスによって詳細度を小さくしてくれるおかげでこのリスクが減ります。
とりあえずこういった問題を防ぐためにも:where()擬似クラスを優先して使っていきましょう。
参考文献
- WEB+DB PRESS Vol.134 「新機能で CSS の書き方が変わる?」
has()擬似クラス
Meet :has, A Native CSS Parent Selector (And More) — Smashing Magazine
:is() / :where()擬似クラス
New CSS functional pseudo-class selectors :is() and :where()
最近話題の静的ジェネレーターのAstroでは、前述の詳細度の観点からスタイルの上書きに:where()擬似クラスが使用されていることが公表されています。
「Jestではじめるテスト入門」ゆるく感想
約1年前に予約してた「Jestではじめるテスト入門」の電子版の配信が始まっていたので早速読んでみました。
TLDR
- Jestの導入と入門からやりたい人はマストバイ
- TypeScriptわからない人は結構厳しいかも
- ビジュアルリグレッションテストに関する記載は少ないので、UIテスト関係に期待しない方がいい
読もうと思ったきっかけ
当時前職にいたときに、フロントエンド関連のバグが多発していたこともありテストコードを入れていこうと流れになって、ちょうどJestに慣れていく途中の段階でした。そんなとき丁度プロジェクトを偶々知って即予約してたって感じだった気がする。 関数のテストの書き方はわかったけど、コンポーネント系は本当に模索段階だったので本書の触れ込みは本当にぴったしでした。
良かった点
Testing Trophyの概要が日本語で紹介されている
Reactとかで使うTesting Libraryのことを調べていると、Testing Trophyの文字を見たことがあるかもしれません。図は見たことあるだけな人が大多数だと思います。自分もそうでした。日本語で詳細を読めたのは本当に有り難い。。。
Jestの開発者のインタビューが読める
本の序盤にも書いていますが、 以前Jestの開発に携わっていたChristoph Nakazawa氏の貴重なインタビューが記載されています。ちなみに氏は現在東京在住らしい。
Jestという名称の由来と、テストを作成するときのバランスに関する回答は必見。
テストのアプローチにページが割かれている
第3章は丸々テストに対するアプローチの話が書かれています。筆者もなるべくtoBeメソッドを用いてプレーンな文字列などの値で比較するようにしたり意識しているが、そういった良いアプローチと駄目なアプローチが明文化されています。
Jestに慣れている人はここだけ読無形でもいいと思います。
気になった点
Jestのmockに対する記載が少ない
これは入門とタイトル付けされている以上仕方ないかなぁ。。。 ただし業務で使うコード細かくディレクトリ・ファイル分けされているケースが殆どで非同期のテストだと当たり前のように使うので少し記載を足してほしかったかな。
第5~6章が駆け足気味
4章までは読みやすくかったのですが、筆者が変わる5~6章が読みにくかったです。。。文中に「今回zodを初めて使った見た」とか書かれていることから、多分大分模索しながら書いたんだろうなーって印象でした。
お題として退職金控除のアプリが出てくるのですが、筆者も含め人によっては馴染みが薄いお題に対して、コードが一気にドカンと出てくるのでテストケースを読み解くのに苦労しました。これは1周しただけでは理解が追いつかないです。
特に5章でAPIの作成を行うのですが、1つのメソッドを実装した後、残りのメソッドの中身は仕様だけ残しておくから、コードはGitHubのサンプル見てねーはちょっと。。。って思いました。もし改訂する際はコードの記載を追記してほしいなぁというのが個人的な要望です。
UIテスト関係が個人的に期待ハズレ
コンポーネントテスト目当てで買った身としてはStorybookのplay機能やChromaticのUIテストを期待していたのですが、少し触れられている程度で残念でした。実際のケースでどのように活用するのか見たい身なので付録でいいから見てみたかったです。
終わりに
色々気になる点もありましたが、Jestの全体像を日本語で読めるだけでもマストバイだと思います（Jestのドキュメントは減りつつあるCommon.jsベースだし、英語と日本語が混じっているページもあって読みにくい。。。）。またAPIの互換性を持つVitestの台頭もあるので、振り返りとしても読んで損はないはずです。
ちなみに4月下旬には今回不満点にあげたUIテストも含めたフロントエンドテスト本が出るようです。サンプルがNext.jsとのことで非常に楽しみです。 また来月号のWeb-DB pressでもその辺りの特集が掲載されるみたい。
今年中に、テスト駆動開発読もうかなー。
受託から自社サービス系エンジニアに転職します＆2023年の抱負
転職の話
3月からとある自社サービスを運営する会社にフロント兼モバイルエンジニアに転職することになりました。
これまで受託開発を2年間やってきたのですが、
- ずっと同じ案件でルーチンワーク化してきてたこと（しかもフロントの人材が他にいないので、まだ抜けられないと言われた）。
- 同僚が短期間で退職が続くなど、会社の先行きが不安
- 同僚のレベル感と比べ、キャリアなど明らかに違う方向を向いていた
などここでは書けないことも含め、この会社にいるのももう潮時だとと感じ転職したって感じです。
ただしほぼ未経験の状態からフロントエンドをバリバリやらせていただいたことは非常に感謝していますし、現場でしか得られない経験や知識を得られて本当に良かったと思っています。あと同僚との距離感は他の会社には多分ないくらい近かったので寂しいです。
次の会社ではReactをメインに、バックエンドなど色々触らせてくれるらしいので非常に楽しみにしています。
転職をゆるく考えてる人へアドバイス
転職する気がなくてもカジュアル面談はしておいたほうがいいです。他の会社ではこんな取り組みや体制を取っているんだとかは聞いておいたほうがよいです。Webエンジニア界は数年単位で本当に色々変わるので。。。
それとやった案件の記録はつけておいたほうがいいです。詳細も思い出せると今後有利ですし、特に短期間でコロコロ変わると忘れるので。
2023年の抱負
プログラミングについて
正式リリースされたし、Svelte Kitは今年こそちゃんと書きたいなぁって思っています。
毎年新しい言語を一つ覚えるという信条を持っているのですが、昨年はGoを勉強したので、今年は最近のJS/TS界にも関係を持ちつつあるRustをちゃんと勉強したいなぁと思っています。
英語について
昨年はあまりモチベーションが出なかったのですが、とある方の姿を見て再開しようと思っています。
公式ドキュメントとかissueをスムーズに理解できるようになりたいしね。
記事について
プログラミング関係については引き続きZennに書いておこうと思います。 あっちなみに近日つい最近得た知識の記事を投稿する予定です。
この記事はそれ以外のことだったり、早々変わらないであろうプログラミング知識（言語の書き方とか）の話を投稿しようと思います。流石に投稿スペースは上げたい。。。
その他
フルリモート出社になるので、リングフィットなどで運動する習慣はつけておかないと駄目だなぁって思っています。あとサバゲーに興味を持っているのでどこかで一度やってみたいですね。
その他流石に今年はゲームはやりたい。。。
朝活300日超えて色々見えてきたのでまとめる
ここ1年朝活をジミーに続けてきたところ、気がついたら300日を超えていました。大台を超えた記念（？）でちょっと今回の記事で振り返ってみようと思います。
朝活を始めたきっかけ
朝活を始める前、
- 技術などの力をもっと上げたい、でも平日夜の業後に勉強しても頭に入ってこない。月曜火曜はまだしもそれ以降の曜日になると勉強する体力が持たない
- 業後はやっぱりYouTubeやネトフリ見たり、ゲームなど好きなことしてゆっくり過ごしたい
- それでも、技術や英語などたくさん勉強したいことが多すぎる
といったモヤモヤがあり、なんとかしないとと思って始めた感じです。
朝活のルール
負担をなるべく少なくしたいので以下のルールを設けて続けています。
- 平日は必ず最低1時間する
- 休日は朝8時前に起きたときはやる
これを見て、いや休日も含めて毎日やれよって思った人もいたかもしれませんが、自分は体力ないマンですし、フルタイムの仕事は体力を使います。休日も必ずやっていたら多分300日も出来てなかったでしょう。
やってよかったこと
1. 技術力は少しでも上がった
1年で色んな技術本や記事を読んだり、GitHubにあるossのソースコードを見たりしてたくさん勉強できたように思います。朝活しないとここまで技術力は伸びなかったし、知らないままだったでしょう。正直まだまだ勉強し足りない気分ですがw業務でも朝活で得た知識を活かしてそれなりに上手くやれているはず。。。
2. 毎日やったことの記録をする習慣がついた
これまで業務でやっている進捗報告以外で毎日の記録をしてきたことがなかったのですが、良い習慣が出来たなと思っています。前日とか以前やった/思ったことはすぐ忘れるので、今までの記録を見てまだ出来てなかったから今日こそやろうな感じで本日やることを決めてからの朝活ができています。
ちなみにvscodeにmarkdown形式で記録している（notionはコピペ時の挙動が重くて自分は合わなかった）。
3. 夜に作業するよりも何倍も効率が良い
自分はずっと夜型人間だと思っていましたが、実は逆だったみたいです。朝早く起きて作業した方がずっと頭に入ってきました。平日だと業務時間開始時間までしか活動できないので、限られた時間内でやりきる気持ちでやれているのもあるかもしれません。
反省点
勿論、いいことばかりでなく色々反省点も出てきました。
1. やることを勉強にフォーカスしすぎた
他の人のもくもく作業を見る機会が何度かあったのですが、みんな勉強以外もやることに入れていることが多く、自分は勉強しかやってないなっていう気持ちになりました。かつせっかく早起きしてるのに家事とか生活感のある活動も何もしてないことに気付かされました。
今後は勉強以外のことも朝活に取り入れて行こうと思います。
2. やることを多く設定しすぎた
前述したとおりあまりに勉強したいことが多すぎるので、明らかに数時間の活動でやれないだろう範囲でやることを決めてしまったことが多々ありました。そのため、元々問題点として挙げていた
- 業後はやっぱりYouTubeやネトフリ見たり、ゲームなど好きなことしてゆっくり過ごしたい
も出来ていた日が殆どなかったように思います。朝活の続きを夜またやるになってしまうことが多かったです。なので、今後は出来る範囲内で調節しながらやっていこうかなと思いました。
上記で上げたこと以外にも、英単語たくさん覚えようとして覚えられなかった、技術以外の本全然読めてなかったなど色々ありますが上記よりも全然小さい話なので今回は割愛します。
今後意識していきたいこと
ここまで書いてきたことのまとめになっちゃいますが、意識したいことは以下の通りかなと。
- 朝活は勉強に限らず、色々なことを盛り込んでいく
- その日の朝活出来る時間に合わせて、時間の範囲内でやることを設定する
- 夜は基本的にネトフリ見たり、ゲームなど好きなことをして遊ぶ時間にする。余程急ぎでもない限りプログラミング等の作業はしない。
雑な記事になっちゃいましたが、来年にはもっと良い朝活が出来ている自分になれていることを願いますw
ではまた。
今年2022年の抱負
皆さん、あけましておめでとうございます。 さて今年も2022年になったので、記録も兼ねて今年の抱負を上げて行こうと思います。
仕事
一応今の所仕事の範囲を広げていけている感はあるので、今年はフロントエンドの枠を少しずつ超えていきたいなと考えています。あとE2Eテストの稼働が本格化しそう＆自分自身E2Eテストの知見が殆どないので、キャッチアップしていきたいところです。他はまぁぼちぼちやっていく。
また短期間でいいので別フレームワークでの開発機会もいただけたらな気持ちもちょっとあったりします。
フロントエンド開発
昨年もたくさん本や記事読んでかなり量の勉強をしましたが、今年はJS/TSの言語周り・フレームワークのエコシステムの理解に力を入れたいと思いっています。あとSvelteとNext.js。
JS/TS周り
まず今年中にMDNが読みやすくなるというサイ本を必ず読破する。全サンプルコードを順にTSに置き換え＆可能ならDenoで書く形で進める予定。
あと完全に他の方の解説任せになっていたWebpack/Rollup/Babel/ESLint/Prettierの設定方法→エコシステムを学習しようと考えています。↓のスライドを読んだのがきっかけ。
Denoといえば、この本も時間があれば読みたいところ。
Svelte
昨年は一時期コミュニティを追えてない期間が長期化していたため、今年はもう少し追っていけるようにしていきたいです。 まずは昨年読みそこねたこの2冊を読む予定です。本でSapperが使われているところは、SvelteKitの勉強も兼ねてこちらに書き換える予定。
あと、下記記事を読んで、あれ？これ自分でも出来るのでは？と感じたのでSvelte公式リポジトリにも1回は貢献したいと考えています。コンパイラー関係勉強しなければ。。。
https://qiita.com/baseballyama/items/640cf43cd021caf15fba
Next.js
昨年は生Reactを触りまくったので、今年は本腰を入れていきたいところです。追えていない間にかなり進化してた＆使ったことのない機能がまだまだたくさんあるので、まずは下記リポジトリを参考にしながら頑張ろうと思います。自分でRealworldアプリを作ってもいいかもしれない。同じVercel製のSWRやFB純正のRecoilも積極的に使っていきたい。
あと、公式リポジトリのissue一覧眺めていたら結構貢献できるチャンスがありそうなのでこっちも1回は貢献したい。
そういえば、この本ずっと待っているんですが本当に3月に出るのだろうか…？
マークアップ
生CSSはおろか、tailwind CSSも怪しくなってきているので最近知ったdaisyUIから頑張ろうと思います。Chakra UIやMUIみたいのは個人的に好きじゃないのと欲しくなったら自作ライブラリ作るかなって感じ。Svelteがもう少しスタイル指定楽にしてくれたらなぁ。
その他の開発
仕事の節のところで、フロントエンド以外にも広げたいと記載しましたが、一番はバックエンドも勉強して少しでもフルスタックエンジニアに近づきたいなぁと思ってます（フロントだけだとどうしても自作アプリ作るとなると外部API頼りになるし）。
そこで今のところ考えているのがNest.jsとFastAPI。後者に関しては昨年簡単なCRUDアプリを作れるくらいにはかじったりしてた。どっちに重きを置くかはとりあえずNestの方をいじりまくってから考えようと思います。会社の方で最近Udemyの法人プランを契約してくれたのでコース見まくる。
その他はこんな感じ。下に行くほど優先度低め。
- クリーンアーキテクチャ/ドメイン駆動設計など設計手法の知識を深める
- Rust触れる、感触よかったらバックエンドもこっちに寄せたい
- exercism.io でアルゴリズムの学習
- ここで紹介されていたサイト
英語
フロントエンドをメインに食っている（いきたい）以上、英語ドキュメントを読む機会がめちゃくちゃ多い＆単純に欧米のエンタメやゲームが好きなので昨年から英語を真剣に勉強しています。今は英検準1級/TOEIC900点前後レベルを目標に勉強中。
英単語はSVL12000のvol.3までをAnkiにぶちこんで学習中。大学受験用のメジャーな単語帳（ターゲットとかあの辺）→英検準1級の単語帳のルートのほうが単語数も少なくて良かったのではと今更思いつつ後に引けなくなってしまったので頑張る。SVLは正直覚えづらいので、他の方には前述の別ルートで頑張った方がいいよとだけ伝えていきたい。
![究極の英単語 Standard Vocabulary List [上級の3000語] Vol.3](https://m.media-amazon.com/images/I/51guBoi04TL._SL500_.jpg "究極の英単語 Standard Vocabulary List [上級の3000語] Vol.3")
洋画や海外ドラマを観ていると句動詞（いわゆる英熟語）もバンバン登場するので、こちらもCommon Phrasal Verbsとググって出てくるものから順に学習している。
こちらもAnkiに入れながら覚えているのだが、すでに英単語より覚えるのに苦労しているので、イラスト欲しいなと思って以下の書籍を買う予定。
日本の教材が殆どない＆英語サイトで載っているリストと乖離していることが多いのであまりに軽視しすぎるでしょ。。。って感じてしまいます。
idioms（ことわざ）はこれを使うつもり。今年中間に合わないかもだけど。。。
リスニングと発音はマジで出来ない人なので、単語関係が落ち着いたらこれもいい加減読みたいところ。
その他学習と関係ないこと
詳しくは触れませんが、今年は以下を大事にしていきたいと思ってます。特にゲームは昨年勉強しすぎて全然出来なかったので。
- 達人プログラマーに書いていた技術以外の本も読むの実践
- 朝活の継続、土日祝も安定して早起きできるように
- ゲームたくさんする
- 洋画も映画館月 1 ペースでたくさん見る。海外ドラマも観ていきたい
今年の抱負はこんな感じです。仕事もプライベートも色々やりたいこと多すぎて相変わらず毎日大変ですが、適度にパソコンから離れて休みように過ごしていきたいと思います。
今年もよろしくお願いします！
