https://gihyo.jp/magazine/SD/archive/2024/202409
Supabase 使ってみたいんだよなあ. Firebase のメリットはクライアントから使えるデータベースと認証・認可の連携だと思うので, そのあたりが Supabase だとどうなっているのか気になる.
DNSの設定変更は「すぐに設定が反映されない」というポイントが大きなトラブルのものになります。
これ. DNSはクリティカルな部分だから事前検証とか仕組みでカバーできるようにならないかな. dig コマンドよくわからないで使ってたけど, 解説があって助かる.
DX Criteria はいいぞ. ただ活用できるようになるまでのハードルもそこそこ高いと思うので, なかなか時間を割いて取り組むのも難しいと思っていた. 「チーム」のテーマに絞ってやるのは確かによさそう.
まさか分割キーボードが出てくる とは思わなかった. 自キ活はいいぞ.
サーバーサイドから見てクエリの難しさや Read Heavy な特定の領域でしか活用できないことやクライアントとサーバーでインターフェースを切らないことによるN+1問題とかが懸念としてあって食わず嫌いしていた.
内容としては初めに「第1章：GraphQLとは利点・注意点を整理して輪郭をつかむ」 GraphQL の特徴について解説があって, あとに続く第2章で実装してみるオーソドックスな内容. 丁寧に書かれていて実装例も GitHub にあって GraphQL をはじめてみるにはかなりとっつきやすい内容になってる. 個人的には「第5章：GraphQLアプリケーションの実運用 パフォーマンス改善，セキュリティ対策，APIの進化戦略のプラクティスを押さえる」の内容が良くて, GraphQL はクライアント主導でとにかくリリースして計測してから直すという考え方がわかった気がする.
Rust のエラーハンドリングを知ってしまうと Go のエラーハンドリングはどうもボイラーテンプレートを書いているように感じてしまう. とはいえ Go のコードとして示す愚直なスタイルは他の言語にもそのまま適用できるので, Python とか TypeScript とかで言語を超えてエラーハンドリングを統一するのもいいかもしれない.
特定の言語のエラーハンドリングだけでこれだけの紙面を割くのはなかなかすごいなと思ったけど, そもそもエラーハンドリングは難しいもので, そのうえ C++ や Java の例外のような言語固有の複雑さがあった経緯があるのだか ら, これぐらい丁寧に解説されるべきなのかもしれない. その点 Go Way としてきちんと示されている Go は良い言語なのだと思った. 余談だけどAPIで書き方を規定している Rust と対照的だなとも思った.
Javaにはきちんと検査例外として設計する文化がかつてありましたが、今では非検査例外にラップして投げるのが一般的です。
細かい上に本筋からそれるけど言い過ぎだと思う. Java のエラーハンドリングは戻り値として返す場合 (Optional), 回復可能なため上位層にゆだねる検査例外, 回復不可能な非検査例外に分かれるはず1.
いい記事. こういうの『マスタリングTCP/IP』とかで勉強したような気がするけど, こういうところで手軽に学べるのはとても良い.
一方ZOZOTOWNのカート投入機能には［カートに入れる］ボタンを押した時点で在庫を引き当て有効期限まで確保するという特徴があります。これは「ZOZOTOWNではお客様にリアル店舗のように安心してお買い物を楽しんでほしい」という思いから作られたためです。
こういうビジネス上での意思決定をエンジニアリングで解決していくのがいい. こういう意思決定がエンジニアに伝わっていなくてより作りやすいように作り変えてしまうということも多いはず.
単にネットで調べてもベストプラクティスに辿り着けなかったりするので, こういうのめちゃくちゃ助かる.
「捕まえてもどうにもならないやつとどうにかなるやつってのをまず見分けなければならなくて...」 21分ごろ. 101. A Philosophy of Software Design (2/3) w/ twada | fukabori.fm https://fukabori.fm/episode/101 ↩