あずにゃん (@ Michi Ramen) http://foursquare.com/v/50f74169e4b08087631dbf2d
フレームワークを作るとかでない限りinheritanceが無用のものと化した今、初学者がオブジェクト指向を学ぶ必要って本当にあるのか……?
何か物を作るためにプログラミングを今から覚えるなら、オブジェクト指向よりImmutabilityを学んだほうが良い気がする。構造体を可能な限りImmutableに扱うという概念さえ覚えれば、そこそこ壊れにくいシステム設計が自然に導出できるようになるのでは
よく分からんからとりあえず株買って何が起きるか見てみるか(半年前に機運があったけど結局なにもやってない)
ドメインモデルをレスポンスモデルと兼任するやつ、センシティブな情報をViewに送りたくないという要望が発生した瞬間に崩壊するので死への一本道
おとなしくMVVMしましょう。現代ならGraphQLとか使うとそこそこ自動的に分離できるし……(今度はコードの重複がつらくなるけど)
DBモデルとドメインモデルの兼任はガチガチに型検査しようと思うとHaskellくらいの柔軟性がないと厳しいけど、よくわかんないデータはとりあえずデフォルト値でいいやくらいのゆるふわ感だとうまく行くっぽい(今やってるプロジェクトは20個くらいモデルがあるけどうまく回ってる)
MVVMはいい感じにバインドしてくれるやつがないと厳しいというのはそれはそうで、GraphQL周りはモデルからSchemaを自動生成するやつやSchemaからモデルを自動生成するやつで溢れかえっている(どうすればいいんだろうね)
あとどっちかというと読む側よりユーザが送ってきたデータをVerify / Sanitizeするあたりが厳しい。生データのモデルとVerifiedなデータのモデルを分けようとかし始めると沼
GraphQL自体は中立で、スキーマ→モデル型もモデル→スキーマ型も主要言語はどっちもライブラリがある雰囲気……(闇)
弊プロジェクトはサーバサイドでモデル→スキーマ型の自動生成を自力で書いたので大丈夫です。クライアントサイドはよく分からんのでまだ手書きしてる
まあ自作モデル→スキーマ変換器があればそこからTSの型情報生やすのも一瞬だしいけるいける(時間があるとは言っていない)
闇の深さは異常なクエリ送ってくるインターネットの異常者対策のほうがやばい。パラメータ書き換えたりして変なリクエスト送ってくるやつは攻性防壁で脳を焼き切られてほしい
なんか知らんが、smhnのユーザをmikutterでプロフィール表示してもトゥートが取得されないな。他の鯖の人のトゥート一覧は取得できるのでsmhnの問題っぽい
mastodon_account_viewerのpm::Statusってなんやねんって思ったらやっぱりおかしいっぽいな
@ahiru e1402f57 (Merge branch 'topic/1430-delayer-1.1.2' into develop)
【感想・レビュー/osa_k】を読んだ https://bookmeter.com/reviews/86969619
Go、errを特にfmt.Errorfで包むこともせずに投げ直すパターンが標準ライブラリでもよくあるけど、あれやっていい理由があまり分かってない。元のerrが発生するまでの経路が2つ以上あり得ると原因を特定するのがつらくならない?
まともにモジュール分割されてればモジュール境界をまたいだ時だけ情報を増やせば十分、みたいな発想なのかな
pkg/errorsでスタックトレースを積むようにすれば、常に明示的に投げ直さないといけない以外はJavaの検査例外と同じような使い勝手になるのか。手の届かないライブラリ部分がアレな時は困るけど……
結局スタックトレースが強力すぎて、取れるならとりあえずくっつけておけば何が起きたかの半分は記録できて、あとはエラーメッセージがパラメータの記録すればおしまいって感じっぽいな。Javaじゃん