Stimulator

機械学習とか好きな技術話とかエンジニア的な話とかを書く

3ヶ月くらいフロントエンドやったのでやったこと一旦まとめ

- はじめに -

9月くらいから趣味でフロントエンド周りをやっていたので、その勉強過程のまとめ。

何が良かった悪かったとか、こうすればよかったとか、所感とか。

 

- 前提 -

前提として9月頭くらいの私のフロントエンドに対する理解と技術的な知識はこんな感じ。

これくらいのレベルからこうやって学んでいったぞという記録になる。


 

- どんな感じで進めたか -

4つWebアプリを作った。3つは友人の手伝い、1つは以下のWebAssenblyを組み合わせたWebアプリで、これは1人で作成した。

vaaaaaanquish.hatenablog.com


  

最初の開発

最初、ElasticSearchを使ったデータ検索系のサービスを趣味開発チームのメンバーが作ろうとしていたので、並び替えやランキングに機械学習が必要だろうという事でバックエンドのElasticCloudや機械学習モデル作成を手伝った。その過程で検索フォームやサジェストが必要になって既存のReact部分を触らせてもらった。

この時は、そもそもComponentという概念が全く理解できておらず、なんかclass作ってStateとPropsでやり取りするらしいくらいの感じでコードを書いていた。友人にFluxかReduxを使ってと言われたので、オススメの本を聞いたら「本でもブログでもなく公式のチュートリアルを見てやれ」「本ならとにかく新しい本を買え」との事だった。

今にして思えば、このアドバイスは神だった。

 
最初はこれを2日程かけてやった。
ja.reactjs.org
react-redux.js.org
React Devtoolsが便利だとか、Reduxが何故必要なのかがよく分かった。
他のブログ記事の野良チュートリアル的なのも見たは見たけど、公式が最新のバージョンでコードを上からコピペしていけば動くのでどこよりも良い。アドバイス通りだ、当たり前だけど。

 
非同期処理なんかもjQueryで適当に書いていた頃とは勝手が違っていて苦労したが、何故かTwitterで回答が得れたりした。


mizchiさんただのOSSタダ乗りおじさんだと思ってたごめんね。

 
頭のおかしい友人は「前時代から入ってきた人はまずはこれでしょ」と言ってAtomic Designを薦めて来たが、この時はマジでよく分からなかった。
atomicdesign.bradfrost.com

後述するが、後々にWebアプリ2,3個作った辺りで「あーなるほど」と思う事があった。


実際に作ってみてから読むと、良いコンポーネント設計が出来るようになる感じはするので時間が空いたら、開発手法を学ぶ的な意味合いでAtomic Designはオススメできる。本家が難しければググれば解釈がいくつか出てくるのでそちらでも。

 
その辺りで、もうちょっと体系的に学べないかと思って調べて、アドバイス通り「新しめの本」ということで以下を読んでみたが、これもなかなか良かった。

Web上のチュートリアルと違って動かせるコードは少ないが、Vue、Angular、Reactの違いとか、何となく書いていたBabel、webpackが何をやっているか、ReduxやFulxがなぜ必要かが体系的に書いてあって、本当に助かった。後半ユニットテストや実際のサービス開発フロー、Sentryやスクラムの話が出てくるがあまり読めてないのでまた読みたい。

これ読んだ辺りから、Qiitaやはてな、Zennで流れてくるフロントエンドエンジニアの間で話題の記事をかなり難なく読めるようになったので、チュートリアルとこの本は結構効いた。


 
理解できてきて記事のシェアが増えてきた

他にもこの辺りでのReduxとの出会い、TypeScriptの学びは大きかった。

Reduxの機構を見た時、「本当にこんな壮大な仕組み必要か?」と思ったが、実際使ってみると簡単で便利だった。後にReact Hooksで多くの機能が代替できる事を知って移行していったが、状態というものが何なのか意識できるようになったのはRedux使った後からだったように思う。最初からHooksでも良い部分が多いけど、Componentやnode.js周りの開発がどれだけ良いか体験できるのも良い。例えばFluxなプロジェクトをReduxに書き換える、Hooksに書き換えることを経験したが、状態管理が1ライブラリで切り離されているので、移行の労力がかなり小さかった。これがいわゆる近年のnode.js開発の良さの1つなのだろう。

TypeScriptへの移行もやった。この辺りにもnode.js開発プラクティスの恩恵があるんだなと感じる体験で、Componentで分かれているのでComponentごとに1つ1つ変えていけば良いし、何よりTypes書けば推論してくれる便利さ、ビルド時のチェック、エディタの補完の進歩が最高だった。以下の本も読んだら良かった。

実践TypeScript

実践TypeScript

フォロワーが書いてるからと思って読んだが、この書籍でNext.jsと組み合わせた時の強力さも知れた。書いてある内容がちょっと古いけど、筆者が追加で最新分に対応した解説しているのでこちらも見ると良い。
Nuxt.js TypeScript - 実践TypeScript アップデート - - Qiita


 
最初のアプリの小話だが、友人はElasticCloudのオススメ設定みたいなので進めていて全盛りプランでお金掛かりまくる感じになっていてヤバと思った。流石フルマネージド。結局まるっと構成を変えてインデックスも機械学習モデル入れやすいように貼り直したりして大変だった。


  

TypeScriptとNext.jsを使った開発

次のWebサービスも辞書のようなサービスを手伝う形だったが、途中まで書かれたサンプルがwebpackだけ使ったCSRだったので「いやこれTwitterでシェアされたりすること考えるとSSR必要じゃないか」という話になってNext.jsをやった。

Google検索やTwitterに出たかったらSSRだNextをやれと最初に知りたかった気もちょっとした。

 
この辺りまでwebpack.config.jsをダラダラ書きまくっていたが、どうやらNext.jsではpackage.json、tsconfig.json(あるいは.babelrc)の簡易なフォーマットを書けば良く、ルーティングもディレクトリ、ファイル名でよしなにできる。Routerの分岐をコツコツ書かなくて良い(すごい)。静的なファイルの配信もクライアントサイドのレンダリングも簡単で、ほとんど何も考えずComponentを書いていけば開発できる事がわかった。すごい。

(最初はなんでGoogleクローラやTwitterのOGPなんかのために頭良い人達がSSRだの何とかRだのに振り回されてんのと思った正直)

 
これも出来るだけ公式のチュートリアルをなぞった方が良い。
nextjs.org

野良のやってみた、ベストプラクティスみたいな記事は半年以内くらいじゃないと若干古かったりDeprecatedだったりする。


コンポーネントやライブラリの使い方がちょっと違うくらいならいいが、特にディレクトリ構成が変わる系(publicとかsrcとか)は後から変更するのが大変な場合もあるのでちゃんと最新バージョンの情報を見たほうが良い(大変だった)。


この辺りでMaterial-UI: A popular React UI frameworkとかのドキュメントをひたすら上から試したり、About splash-screens - AppscopeFavicon Generator for perfect icons on all browsersfaviconやスマフォ向けの画像作ったり、Google Analytics、OGPなんかを一通りやった。

f:id:vaaaaaanquish:20201227210125p:plain:w500
material-uiのドキュメント全部読んだ時の

Tailwind CSSSemantic UIも比較のために触った(Web上の記事も読んだがあんまり良い悪いの比較が理解出来ずmaterial-uiで良いんじゃないという気がするが理解が足りていない気もする)。


 

アプリ手伝いから自分のアプリ開発まで

3つ目はNuxt.jsなアプリをちょっとだけ手伝った。あんまりNextとやってる事は変わらないと感じたけど、逆に変わらないのがすごいなと思った。外枠変わっても書いてるTypeScriptのコード変わらないのすごい。まあでもつまりNext.jsとTypeScriptができれば結構いろんな事に対応できそうだという事もここでわかった。

 
この辺りで、WebAssenbly nightというイベントを聴講して、「あ、こりゃ面白いな」と思って自分のサービス作ってみようとなった。
emsn.connpass.com

 
Rustで機械学習がどれくらいできるか試して
vaaaaaanquish.hatenablog.com
その機能がwasm-packやEmscriptenでバイナリにしてNext.jsで配信できるか試して


できてた


前のブログに書いた通り、wasm周りは結構大変だったが、技術的に面白いものが何だかんだで1万人強に使ってもらえていて、楽しい気持ちになった。


この辺りは本心で、かなり大変な上に「機械学習エンジニアにとってwasmでサービス展開したいモチベーションが薄いので量子化ホスティングまでを考える人が少なくPythonAPIがソリューションになる」「逆にフロントエンドエンジニアやバックエンドエンジニアが機械学習モデルの量子化をやるのかと言うとそれはそれでとなる」という状況で、一部のエンジニアを除いて多く人にとってはちょっとしんどい気もした。

こういうWebサービスやりたいよという会社があったら呼んで下さい。

 
御託はさておき、GAEやFirebaseであまり考えずにNext.jsでWebサービス展開ができるようになった。


 

- できてないこと -

趣味で3ヶ月やってみたものの、まだ出来てない事、分かってない事がいくつかある。

  • ツールチェインのベストプラクティス

先に挙げた「Material UI、Tailwind CSS、Semantic UI」もそうだし、「Express、Parcel、Deno、Gatsby...ないし任意の技術は良いぞ」というのが飛び交っていてまだまだ試す事が多い

  • Babelが何をやってるか

これ結構わからない人多いと思うけど私だけなのかな。使い方は出てくるけど、ES構文とは何なのかとかを知らないと把握できなさそうだなと思う。
こういう所が、こんなツイートにも繋がっている。

これマジでわからん。ESLintどの粒度で書くのが正解なのか、気付いたらNext.js含む回帰テストみたいになってしまう。これを読めみたいなやつないのかな。

わからん。デザインツールから出てきたscssを適応するのも、既存のCSSを改修するのも1日以上かかったし、css-loaderやscss-loaderがCSS Moduleになったからなんぼのもんじゃいって気持ち。PostCSSになっても適切にdisplayやpositionを適切に一発で設定できたことなし。これを使えみたいなやつないのかな。

  • パフォーマンス最適化

この書き方がどういう理由でパフォーマンスが良い、高速であるというのをあまり把握できていない。これを読めみたいなやつないのかな。

  • 複数人での継続的な開発

アトミックデザインなりのnode.jsなり良いところはこの辺にあるんだろうと体感していて、複数人が手を入れても、モジュールのバージョンアップデートも変更もこりゃやりやすいだろうと思うんだけど如何せん仕事じゃないので機会が訪れなさそう。


 

- 所感 -

たしかにnode.js開発しやすい。jQueryをゴリゴリ書いていた時を思うと、Releaseまでの速度も改修のしやすさも、他人のコードの読みやすさも段違いに良い。Railsとの比較が近年多いけど、私はまだRails書きまくってるわけじゃないから何か機能の比較は難しい。それでも大きなフレームワークとは違った、色んな開発の概念を学べてよかったので色んな人がやると良いと思う。

情報の古さみたいなのがヤバいので公式を見に行く精神を忘れるとしんどい。ライブラリの開発がやりやすいこと、早いことが起因しているのだろうけど、ついていけている開発者も少ないのではとちょっと思った。

自分の作ったサービスが使われるのを見るのは楽しい。
機械学習エンジニアの悩みどころの1つに「小さいサービスではやることがない問題」というのがあって、最初から機械学習を前提としていたりしない限り、データやユーザが小さかったり需要がないために(概ね習熟した問題に対して改善フェーズじゃなければ)機械学習モデリングは実は簡単に終わってしまって分析屋かPdMになっていくという事象はよくあるのだが、私は開発に比べたらあんまりという気持ちなので、もうちょっと開発の範囲を広げる方向で何か考えていた。バックエンドやフロントエンドをやってみるのは楽しかったので今後も継続したい。

Rustも書けるWebサービスのアイデアもっと出したい。


 

- おわりに -

あんまりこういうまとめ書く気はなかったけど、最近「初心者のうちに初心者な記事を書かないと、初心者の読者と乖離した記事しか書けない」みたいなツイートを見て「それもそうだ」と思ったので書いてみた(元ツイート見つけられなかったごめんなさい)。


結構楽しかったので普段フロントエンド触ってない皆さんも年末のお供にどうぞ。



 

- 追記 -

2020/12/28 

分からなかった事が分かりそうなgistが作られてました。

めちゃくちゃありがたい。やっていきます。