これはなに？
この記事のオマージュ。分からないことを書くというのは来年に向けてよい取り組みだと感じたので真似してみる。
来年の今頃にこの記事に多少でも赤ペンを入れられるようになっていることを目標に頑張る。
2020年のあいだはちょっとずつ項目足したり更新するかも。
分かっているフリをする技術リスト
クリーンアーキテクチャ
巨人から街を守るための壁みたいな図のやつ。内側は外側に依存してよいが、外側が内側に依存してはいけないというルールが全て。
Jamstack
サーバーレス的なざっくりした世界観におけるひとつのベストプラクティスだと思っている。 HTTP リクエストに対して動的に処理を実行する必要がなく、静的なコンテンツを返却すれば良いというユースケースにおいて利用できる。
- 静的サイトジェネレーター
- CDN
- ヘッドレス CMS
- ビルドツール
- ホスティングサービス
あたりが充実し、実用性が高まったことで注目されていると思っている。
WebAssembly
Wasm と書かれることも。ブラウザで実行可能なバイナリ。 JavaScript と比べて高速。多くの言語で開発可能だが、よく目にするのは Go や Rust あたり。
高速でブラウザで実行可能とは言え、既存の JavaScript を置き換えるようなものではない。例えば DOM 操作なんかは JavaScript でやったほうが良い。
機械学習や全文検索などの大規模なデータ、計算量を必要とするケースで利用するのが良さそう。
一方で、クラウドコンピューティングが安価になり、高速通信が可能になってくると、時代としては「重い処理はサーバーで、必要なデータは全部送っちゃえ」な世界観も強まってきているので、どの処理がローカルで実行されるべきか、どの処理がサーバーで実行されるべきかという見極めは、今後テクノロジーにおけるひとつの勘所になってきそう。
TailwindCSS
いわゆるユーティリティクラスみたいなものだけが定義されている CSS フレームワーク。
BEM でもなんでもいいが、「この要素はこのようなスタイルが当てられているべき」と CSS を定義しても、同じ要素が別のページに表示されるときにはちょっと違う表示にしたいなー、なんてことが起こったときに .hoge > .fuga みたいな親要素に依存する CSS が書かれがちになり管理が難しくなってくる。それぞれの要素に一意のクラス名を与えないことでそれを未然に防ぎたいというアプローチ。
ある意味では style のベタ書きに近い。複数のスタイル定義のスニペットに意味のある名前を与えてあげた感じのものが TailwindCSS だと認識している。
CSS のビルドが賢くなって、使われていないクラスはバンドル時に削除 (purge) ができるようになったので実用性が出てきた。
Rails
最近フロントエンド界隈で親の仇のように憎まれているフレームワーク。
データベースからフロントエンドまで一気通貫のデータ構造を持つので、小さい組織で素早く動くアプリケーションを作るのは得意だが、そのアプリケーションが年齢を重ねるごとに身動きが取りにくくなる。多くの場合フロントエンドに全てのしわ寄せが来るのでフロントエンドの担当者からは好ましく思われない。
M1 (Apple Silicon)
修士1年のことではない。
Arm 製のプロセッサ。これを搭載した Mac はとても速い。しかしながら、現時点では Docker for Mac のプレビュー版しか動かない。