転職ドラフトからオライリーの本たくさんもらったので欲しかったやつとりあえず全部読んでみた。 <pr> 紹介コード RVSC を使うとお互いにもらえるので気になる人は是非。 https://job-draft.jp/sign_up?utm_term=RVSC </pr> オブザーバビリティ・エンジニアリング 良い本。トレーシングやOpenTelemetryの本と思って買っていたが、実際はオブザーバビリティを確保するための色々な手法を紹介している。そのような手法が発達するまでの歴史の流れの解説も面白かった。従来のメトリクスとモニタリングだけでは現代の分散システムのデバッグが困難ということで、 オブザーバビリティ・エンジニアリングを導入する上での説得に使えそうな文言がたくさん散りばめられている。その手法の一つが、そもそも問題が起きてからデバッグのためにデバッガを挟み込んでデプロイしたくないという

はじめに とても前になるが、コグニカル というサイトが盛り上がっていた。 これは知識を体系的に記述されていて、分からない概念があればその概念の理解に必要な概念を逆引けるサイトだ。コンピュータ以外にも数学や理工学全般を学べる。 コメントを見ると、インターネットを使った学習で、自分の分からなかったことを辿れる学習や体系だっていることに対して価値を感じているようだ。「誰が何のためにどうやって作ったのか情報がぜんぜんなくて怖い」というコメントがあるが、同感だ。怖い。そして教育工学を専攻していた身としては地に足ついたアウトプットが人の役に立っていて羨ましくも思うし、尊敬する。 実はこのような教授手法は古くから研究されている。それは知識をネットワークで表現するだけでなく、個々人の学習履歴や成績を元に次に学ぶものを提案する方法も提案されている。コグニカルを知った時にその技術についてのブログを書こうと思っ

はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自

仕事の都合上、Django を覚える必要が出たので、その素振り課題が欲しい + スプラトゥーンを強くなりたいというニーズが出会って スプラトゥーン 3 反省会会場 を作りました。 色々技術的な挑戦をしたのでそのまとめをします。 スプラトゥーン 3 反省会会場とは スプラトゥーン 3 反省会会場は、自分のスプラトゥーン３プレイ動画を録画して、後から見返して反省をするためのサイトです。ただ反省文を書くためだけに作っていたのですが、どうせなら改善点のアドバイスなどがもらえるようにと思って Youtube への紐付けと反省文を外部から見られるようにしています。 反省文を書こうと思ったきっかけはウデマエを上げたいからで、普段同じようなミスをしている気がしているのでしっかりと反省することと、その反省すべきシーンだけを後から何度でも検索して見返せるようにすることが目的です。 いまではご飯を食べる時は常に

毎年無限スクロールの実装をしているのだが正直なところ実装したくないので依頼されたときの反論材料として実装したくない理由を言語化しておこうと思う。 無限スクロールとは 無限スクロールが何を指すかを知らない人のために解説すると、ページにコンテンツを足す方式でページネーションする UI を指している。例えば Twitter のように下にどんどんコンテンツが伸びていく UI が良い例だろう。そのような UI を無限スクロールと呼ぶことが正式なのかは知らないが、このような体験の実現を支援するライブラリに infinite-scroll というものがあり、少しは普及している呼び方なのだと思い無限スクロールという言葉を使う。一方で WEB フロントエンド文脈で無限スクロールと言うと複雑 GUI やドローイングツール実装における "無限平面" のようなニュアンスもあるが、今は無限平面のことを指しているわけ

Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ

さて、年末が近づいてきましたが今年も 「Redux 使うべき使わないべきか」という話で盛り上がりましたね。 僕もずっと悩める人なのですが、@f_subal さんの Tweet や @takepepe さんの Next.js の状態管理 2020 が示すように Read 要件・Write 要件の多さで使い分けるという指針には深く納得をしました。 Redux の代替になるツールやノウハウもより活発に出てきて、Redux 以外の選択肢を考えるにあたって様々な学びがあった 1 年でした。 自分も色々と Redux 以外の選択肢を試していたのですが、その中で「やっぱ Redux を使えばよかった」と思ったときがあったので、これから Redux を剥がそうと考えている人に向けてその失敗談を語りたいと思います。 自分も手探りで正解がわかっていないところなのでアドバイス・反論・指摘などがあれば頂きたいです