去年は結局ブログを1つも書かなかったのですが、
理由としてはあまり自分が関心を持てる技術を最近使っていないというところにもあります。

mocriのサービス終了後からは社内のとあるSNSを作る事業部で主にエンジニアやPjMとして働いています。
このサービスは自分が参入するよりも１年ほど前から開発が開始していたので途中参加となります。
そのため、自分の関心のあるアーキテクチャーにはなっていないというのがいちばんの理由です。

今年も去年の振り返りを書いてみようかと思います。
ただ今年は今開発しているmocriというプロダクトの開発で採用した技術やサービス開発についての４年間の振り返りを書こうと思います。
これをこのタイミングで記述する理由としては、１つの節目を迎えたと感じたためです。

もう2022年に入ってしまいましたが、そういえば2021年の仕事や技術を振り返りをしていなかったので振り返ってみました。
ただ、2020年に比べるとそこまで大きく何かをやったわけでもないので、軽く振り返りつつ仕事や個人的に関心のあった技術について今回は振り返ってみようかと思います。

2020年の仕事や技術について振り返ってみました。

前年に引き続きReact NativeによるiOS/Androidアプリの開発と、React Native本体への初PR

React Nativeは2020年になってからバージョンアップ頻度が遅くなったものの、
変わらずiOS/Androidアプリケーションの開発に非常に役立っているという印象です。
世の中的にはFlutterの採用事例が多く見られるようになり、そちらへ流れる方も多いのですが、
Reactそのものや言語的な書きやすさでいえばまだReact Nativeに分があるというのは個人的な印象です。

今までPolyrepoによるクライアントやバックエンドの開発を行ってきましたが、
規模が大きくなるにつれて問題が発生しやすくなったり、作業効率に影響が出るようになってしまったため、この度Monorepo構成へ移行しました。
そのときの手順について紹介したいと思います。

yarnからpnpmへ移行する理由

yarnをv1からberryに移行した当初も pnpm の存在は認知していましたが、シンボリックリンクを使う関係で動かないパッケージがいくつかあったので、当時は berry を使う選択をしていました。

しかし、最近利用者が増えてきてシンボリックリンクに対応したパッケージが増えてきたのと、
Next.jsを開発しているVercelもpnpmを支援しているというのもあり、この度乗り換えることにしてみました。

yarnからpnpmへ移行する理由

yarnをv1からberryに移行した当初も pnpm の存在は認知していましたが、シンボリックリンクを使う関係で動かないパッケージがいくつかあったので、当時は berry を使う選択をしていました。

しかし、最近利用者が増えてきてシンボリックリンクに対応したパッケージが増えてきたのと、
Next.jsを開発しているVercelもpnpmを支援しているというのもあり、この度乗り換えることにしてみました。

yarnのv2(Berry)が登場してしばらく経ちましたが、依然v1を使い続けている方が多いかと思います。最近になってやっと問題なく移行できると判断できるようになってきたので、この度移行してみました。

ここ数年でARMインスタンスを使う環境が業界的にも整備されてきたかと思います。
ARMインスタンスは処理によりますが速度的にはx86_64と同等かそれ以上となるケースがあるのと、
x86_64のインスタンスに比べると費用も安いので、そろそろEKSノードの各インスタンスもARMインスタンスへ移行したいと考えました。

CircleCIから移行しようと思った理由

今まではCircleCIのPerformance Planを使い、iOSビルドはmachineタイプをlargeにして少しでもビルド速度を速めると行った手段をとっていたのですが、
それが急に年間契約でなければmacOSのlargeが使えなくなってしまったというのが一番の理由です。
さすがに年間契約をするほどの覚悟はなかったため、これを機に移行することを決意しました。

ここ数年でARMインスタンスを使う環境が業界的にも整備されてきたかと思います。
ARMインスタンスは処理によりますが速度的にはx86_64と同等かそれ以上となるケースがあるのと、
x86_64のインスタンスに比べると費用も安いので、そろそろEKSノードの各インスタンスもARMインスタンスへ移行したいと考えました。

Docker Desktopが2022年2月より有料化されるという情報が出てから、
Docker Desktopの代わりとなるツールを色々試していましたが、ようやく個人的に納得のいく代替手段が見つかったので記事にしてみました。

kopsはAWSのEC2インスタンス等にKubernetesクラスタを簡単に構築できるプロビジョニングツールです。
(正式表記はいつからか kOps とOが大文字になったようですが、記述しづらいのでこのブログでは全部小文字表記にしてます)

まだAWSのEKSが登場したての頃はワーカーノードの管理も設定も大変で東京リージョンでも使えなかったということもあり
kopsを使ってKubernetesクラスタの構築を行っていたのですが、
数年運用していくつかの問題点が上がってきたため 近年ある程度運用事例も増えてきたEKSへ移行を行いました。 今回はその内容について紹介させていただきたいと思います。

結構ハマったので備忘録として記述しておきます。

kopsで構築した Kubernetes 1.11 系のクラスタを
1.12系にアップグレードする際に、 calico が起動しないで失敗する場合があります。
このときに考えられる原因としてはいくつかあるのですが、
kops のある程度古いバージョン (1.11系？) で構築したクラスタをアップグレードする際に発生しやすいです。
(しやすい、と濁しているのは確証があるわけではないのでおそらくという感じです)

私が今まで静的サイトを作成する際には、
インデント記法で簡単にHTMLコーディングができるPugや PostCSSを使ってCSSでNested記法を使えるようにしたりという環境構成をとっていました。 ただ、近年この構成には周辺ツールのサポートが少なかったり、それ故にエディタにプラグインを追加したりなど設定が多くなりがちであるという点からも、あまり利点が感じられなくなってきました。 そこで今回、Next.jsとvanilla-extractを使って静的サイトをコーディングすることにしてみました。

Next.jsにおけるi18n対応についてです。
公式サイトを見ると i18n 対応についてはいくつかライブラリが紹介されていますが、
今回は私が最初に選定した、 isaachinman/next-i18next を使ったことによる失敗談と、
代わりに採用した lukeed/rosetta を選定した理由についてお話したいと思います。

Next.jsでgrpc-webを使う場合の注意点

grpc-webには2つの実装があります。
前回紹介させていただいたgrpc-webの記事はgRPC公式の実装(grpc/grpc-web)なのですが、
この公式の実装については以下の問題点があります。

Next.js + TypeScript + CSS ModulesでStorybookの環境構築をするにあたって、思ったよりも面倒だったので書き残しておきます。
(Storybook v5 & v6対応版です)

Next.js はSSR対応したReactを使ったUniversal JavaScriptフレームワークで、Vueを使っている Nuxt.js とよく比較されています。
セットアップがとにかく簡単で、TypeScript対応も非常に簡単です。(tsconfig.json の空ファイルを置いておくと自動的に中身を作ってくれます！)
今回とあるSPAを作成するにあたって Next.js を採用したため、そのとき考えたアーキテクチャー設計を書き残したいと思います。

私が今まで静的サイトを作成する際には、
インデント記法で簡単にHTMLコーディングができるPugや PostCSSを使ってCSSでNested記法を使えるようにしたりという環境構成をとっていました。 ただ、近年この構成には周辺ツールのサポートが少なかったり、それ故にエディタにプラグインを追加したりなど設定が多くなりがちであるという点からも、あまり利点が感じられなくなってきました。 そこで今回、Next.jsとvanilla-extractを使って静的サイトをコーディングすることにしてみました。

Docker Desktopが2022年2月より有料化されるという情報が出てから、
Docker Desktopの代わりとなるツールを色々試していましたが、ようやく個人的に納得のいく代替手段が見つかったので記事にしてみました。

iOS/Androidアプリケーションのバージョニングはセマンティックバージョニングを採用しています。
しかし、バージョニングを行う際に、どのような修正でメジャーバージョンを上げるのか、 どのような修正でマイナーバージョンを上げるかなどの判断がしづらいケースがあります。

React Nativeでのenvファイルの読み込みといえば react-native-config が有名なのですが、
v1.0.0 以降、iOSでどうも上手いこと動かず、issueを漁ると /tmp/envfile を作らないといけないといった記述がみられて微妙な感じになっていました。
そのためずっと 0.x.x バージョンの react-native-config を使っていたのですが、
react-native-ultimate-config の存在を知ったので今回乗り換えてみました。

現在React Nativeで mocri というiOS/Androidアプリケーションを開発しています。
このアプリケーションは2019年3月にiOS版をリリースし、その3ヶ月後の2019年6月にAndroid版をリリースしています。
(mocri で使用している技術については過去何度かWEBエンジニア勉強会の方でも軽く紹介させていただきました)

iOS/Androidアプリケーションのバージョニングはセマンティックバージョニングを採用しています。
しかし、バージョニングを行う際に、どのような修正でメジャーバージョンを上げるのか、 どのような修正でマイナーバージョンを上げるかなどの判断がしづらいケースがあります。

2021年2月以降、App Store Connectを利用する全てのアカウントで2FAによる認証が必須になるようです。
これまでCI用に2FAを有効にしていないアカウントで対応していた方もいたかと思いますが、その方法が今後は取れなくなります。 2FAが有効なアカウントではSMS認証などで発行された6桁の番号をその都度入力する必要があるのですが、CIで使う場合は自動で動いているので当然入力ができません。

Next.jsにおけるi18n対応についてです。
公式サイトを見ると i18n 対応についてはいくつかライブラリが紹介されていますが、
今回は私が最初に選定した、 isaachinman/next-i18next を使ったことによる失敗談と、
代わりに採用した lukeed/rosetta を選定した理由についてお話したいと思います。

Next.jsにおけるi18n対応についてです。
公式サイトを見ると i18n 対応についてはいくつかライブラリが紹介されていますが、
今回は私が最初に選定した、 isaachinman/next-i18next を使ったことによる失敗談と、
代わりに採用した lukeed/rosetta を選定した理由についてお話したいと思います。

Next.js + TypeScript + CSS ModulesでStorybookの環境構築をするにあたって、思ったよりも面倒だったので書き残しておきます。
(Storybook v5 & v6対応版です)

Next.js はSSR対応したReactを使ったUniversal JavaScriptフレームワークで、Vueを使っている Nuxt.js とよく比較されています。
セットアップがとにかく簡単で、TypeScript対応も非常に簡単です。(tsconfig.json の空ファイルを置いておくと自動的に中身を作ってくれます！)
今回とあるSPAを作成するにあたって Next.js を採用したため、そのとき考えたアーキテクチャー設計を書き残したいと思います。

margin-top と margin-bottom はどちらか一方に寄せて使う方がスタイリング時にわかりやすくなると言われており、
マークアップをする人たちの中ではよくこのどちらをつけるかという話で盛り上がることがあります。
CSS TrickがTwitterでアンケートを取った結果では margin-bottom 派の方が61% と margin-top 派よりも多かったようですが、
実際は恐らくそこまで差はないのではないかと思います。
今回は margin-top をつけるケースと、margin-bottom をつけるケースの各々の利点や欠点についてピックアップしていきたいと思います。

Next.jsでgrpc-webを使う場合の注意点

grpc-webには2つの実装があります。
前回紹介させていただいたgrpc-webの記事はgRPC公式の実装(grpc/grpc-web)なのですが、
この公式の実装については以下の問題点があります。

一昨年grpc-webが正式リリースされたこともあり、grpc-webでAPIを作成するケースも少なからず増えてきているのではないかと思います。
それまではHTTP通信でgRPCを扱うケースではgrpc-gatewayを使うことが多かったかと思いますが、grpc-gatewayはRESTのエンドポイントを別途定義する必要があったり、
クライアントコードの自動生成には対応していないということもあり、(swaggerの定義は書き出せるのでやろうと思えばそこから作ることは可能)
せっかくgRPCを使っている割にはあまりメリットを享受しづらいという問題がありました。
その点grpc-webはクライアントコードの自動生成ができるのと、RESTのエンドポイントは不要なのでgRPC本来のメリットを享受しやすいかと思います。
(余談ですが、Envoyを使っていればgrpc-gatewayを使わずとも gRPC-JSON transcoder というFilterを使えばエンドポイントは自動生成できるので、クライアントコード生成を考慮しないのであればこちらもおすすめです)

Next.jsでgrpc-webを使う場合の注意点

grpc-webには2つの実装があります。
前回紹介させていただいたgrpc-webの記事はgRPC公式の実装(grpc/grpc-web)なのですが、
この公式の実装については以下の問題点があります。

一昨年grpc-webが正式リリースされたこともあり、grpc-webでAPIを作成するケースも少なからず増えてきているのではないかと思います。
それまではHTTP通信でgRPCを扱うケースではgrpc-gatewayを使うことが多かったかと思いますが、grpc-gatewayはRESTのエンドポイントを別途定義する必要があったり、
クライアントコードの自動生成には対応していないということもあり、(swaggerの定義は書き出せるのでやろうと思えばそこから作ることは可能)
せっかくgRPCを使っている割にはあまりメリットを享受しづらいという問題がありました。
その点grpc-webはクライアントコードの自動生成ができるのと、RESTのエンドポイントは不要なのでgRPC本来のメリットを享受しやすいかと思います。
(余談ですが、Envoyを使っていればgrpc-gatewayを使わずとも gRPC-JSON transcoder というFilterを使えばエンドポイントは自動生成できるので、クライアントコード生成を考慮しないのであればこちらもおすすめです)

最近久しぶりに静的サイト(LP)を一から作る機会があったので、
静的サイト作成用のプロジェクトを作り直してみました。
static-site-starter-kit

３年ほど前に作ったfrontend-templateというリポジトリもあったのですが、
こちらはSugarSSやFuseBoxなど、現在のトレンドから外れたアーキテクチャで構成されていたのと、また独自スクリプトが多数あってメンテに難があったため、 2020年向けと思われる内容に書き換えています。
そんなに大した内容ではないですが簡単に説明すると以下の仕組みをテンプレートとして構築しています。

Next.js + TypeScript + CSS ModulesでStorybookの環境構築をするにあたって、思ったよりも面倒だったので書き残しておきます。
(Storybook v5 & v6対応版です)

Next.js はSSR対応したReactを使ったUniversal JavaScriptフレームワークで、Vueを使っている Nuxt.js とよく比較されています。
セットアップがとにかく簡単で、TypeScript対応も非常に簡単です。(tsconfig.json の空ファイルを置いておくと自動的に中身を作ってくれます！)
今回とあるSPAを作成するにあたって Next.js を採用したため、そのとき考えたアーキテクチャー設計を書き残したいと思います。

今度はNode.jsのバージョン管理コマンドを作成しました
https://github.com/kkoudev/ndw

使い方

使い方は上記リポジトリのREADMEにあるとおりです。
Node.jsのインストールのほか、yarnのインストールにも対応しています。
インストール時に主要コマンドである node, npm, npx, yarn をインストール先ディレクトリ(デフォルトだと /usr/local/bin)に作成します。
あとは通常通り node コマンドや yarn コマンドを実行すると、.node-version で指定されたバージョンで各コマンドを実行することが可能になります。

PostCSSのプラグインである postcss-webfont を作成しましたので、公開しました。
https://www.npmjs.com/package/postcss-webfont

どのようなプラグインなのかというと、
CSSにfont-faceのルールセットを一定のルールに従って記述しておくことで、アイコンフォントの自動生成と、アイコンごとに対応するCSSのルールセットを作成するプラグインです。
(gulp-iconfont と gulp-iconfont-cssのPostCSS版というイメージです)

普段私が利用しているSugarSS用の stylelint 設定ファイルをnpmパッケージとして公開しました。
https://www.npmjs.com/package/stylelint-config-sugarss-recommended

SugarSSはPostCSSでSassライクなインデントベースのシンタックスで記述できるAltCSS言語の一種となります。Sassに慣れた人がPostCSSへ移行する際や、pugのようなインデントベースなHTMLメタ言語と合わせて利用するには特におすすめです。
https://github.com/postcss/sugarss

タスクランナーといえば近年 gulp が非常に人気が高く、利用者も未だに多いことかと思います。 しかし、バージョン4が何年経ってもリリースされない現状を垣間見ると、これ以上 gulp に依存するのは今後新しいアーキテクチャが出てきた際に追従できない可能性が出てきます。そこで、完全に gulp をやめてしまおうというのが今回の趣旨です。 しかし、gulpを無くしてしまった場合、今までのビルドしていたものはどうやってビルドするの？となるかと思います。 これは非常に単純な話で、例えば pug や babel にはビルドするための専用のCLIツールが配布されています。gulpのプラグインも実はこれを呼び出しているに過ぎないので、自作することは簡単なのです。

最近久しぶりに静的サイト(LP)を一から作る機会があったので、
静的サイト作成用のプロジェクトを作り直してみました。
static-site-starter-kit

３年ほど前に作ったfrontend-templateというリポジトリもあったのですが、
こちらはSugarSSやFuseBoxなど、現在のトレンドから外れたアーキテクチャで構成されていたのと、また独自スクリプトが多数あってメンテに難があったため、 2020年向けと思われる内容に書き換えています。
そんなに大した内容ではないですが簡単に説明すると以下の仕組みをテンプレートとして構築しています。

PostCSSのプラグインである postcss-webfont を作成しましたので、公開しました。
https://www.npmjs.com/package/postcss-webfont

どのようなプラグインなのかというと、
CSSにfont-faceのルールセットを一定のルールに従って記述しておくことで、アイコンフォントの自動生成と、アイコンごとに対応するCSSのルールセットを作成するプラグインです。
(gulp-iconfont と gulp-iconfont-cssのPostCSS版というイメージです)

普段私が利用しているSugarSS用の stylelint 設定ファイルをnpmパッケージとして公開しました。
https://www.npmjs.com/package/stylelint-config-sugarss-recommended

SugarSSはPostCSSでSassライクなインデントベースのシンタックスで記述できるAltCSS言語の一種となります。Sassに慣れた人がPostCSSへ移行する際や、pugのようなインデントベースなHTMLメタ言語と合わせて利用するには特におすすめです。
https://github.com/postcss/sugarss

最近久しぶりに静的サイト(LP)を一から作る機会があったので、
静的サイト作成用のプロジェクトを作り直してみました。
static-site-starter-kit

３年ほど前に作ったfrontend-templateというリポジトリもあったのですが、
こちらはSugarSSやFuseBoxなど、現在のトレンドから外れたアーキテクチャで構成されていたのと、また独自スクリプトが多数あってメンテに難があったため、 2020年向けと思われる内容に書き換えています。
そんなに大した内容ではないですが簡単に説明すると以下の仕組みをテンプレートとして構築しています。

Next.js + TypeScript + CSS ModulesでStorybookの環境構築をするにあたって、思ったよりも面倒だったので書き残しておきます。
(Storybook v5 & v6対応版です)

Next.js はSSR対応したReactを使ったUniversal JavaScriptフレームワークで、Vueを使っている Nuxt.js とよく比較されています。
セットアップがとにかく簡単で、TypeScript対応も非常に簡単です。(tsconfig.json の空ファイルを置いておくと自動的に中身を作ってくれます！)
今回とあるSPAを作成するにあたって Next.js を採用したため、そのとき考えたアーキテクチャー設計を書き残したいと思います。

Next.js + TypeScript + CSS ModulesでStorybookの環境構築をするにあたって、思ったよりも面倒だったので書き残しておきます。
(Storybook v5 & v6対応版です)

TestFlightにはPublic Linkという公開URLから一般ユーザーをベータ版へ参加させる機能があります。
この機能は2018年9月から使えるようになった機能です。

TestFlightにはPublic Linkという公開URLから一般ユーザーをベータ版へ参加させる機能があります。
この機能は2018年9月から使えるようになった機能です。

現在React Nativeで mocri というiOS/Androidアプリケーションを開発しています。
このアプリケーションは2019年3月にiOS版をリリースし、その3ヶ月後の2019年6月にAndroid版をリリースしています。
(mocri で使用している技術については過去何度かWEBエンジニア勉強会の方でも軽く紹介させていただきました)

go のバージョン管理を行うためのコマンド gvw を作って公開しました。
https://github.com/kkoudev/gvw

グローバルの環境変数を汚染しないことを意識して作成しています。

使い方

上記リポジトリのREADMEに記載しています。
コマンド実行時には gvw exec go … と記述する必要こそあるものの、goenv のようにディレクトリ単位でバージョン指定が可能で、かつ goenv init のような処理は一切不要です。

PostCSSのプラグインである postcss-webfont を作成しましたので、公開しました。
https://www.npmjs.com/package/postcss-webfont

どのようなプラグインなのかというと、
CSSにfont-faceのルールセットを一定のルールに従って記述しておくことで、アイコンフォントの自動生成と、アイコンごとに対応するCSSのルールセットを作成するプラグインです。
(gulp-iconfont と gulp-iconfont-cssのPostCSS版というイメージです)

普段私が利用しているSugarSS用の stylelint 設定ファイルをnpmパッケージとして公開しました。
https://www.npmjs.com/package/stylelint-config-sugarss-recommended

SugarSSはPostCSSでSassライクなインデントベースのシンタックスで記述できるAltCSS言語の一種となります。Sassに慣れた人がPostCSSへ移行する際や、pugのようなインデントベースなHTMLメタ言語と合わせて利用するには特におすすめです。
https://github.com/postcss/sugarss

タスクランナーといえば近年 gulp が非常に人気が高く、利用者も未だに多いことかと思います。 しかし、バージョン4が何年経ってもリリースされない現状を垣間見ると、これ以上 gulp に依存するのは今後新しいアーキテクチャが出てきた際に追従できない可能性が出てきます。そこで、完全に gulp をやめてしまおうというのが今回の趣旨です。 しかし、gulpを無くしてしまった場合、今までのビルドしていたものはどうやってビルドするの？となるかと思います。 これは非常に単純な話で、例えば pug や babel にはビルドするための専用のCLIツールが配布されています。gulpのプラグインも実はこれを呼び出しているに過ぎないので、自作することは簡単なのです。