本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
https://zenn.dev/shin_semiya/articles/13ecfad2d0f126
> 特にビジネスサイドから理解されないのが1~2ヶ月に1度の映画型リリースではなく1週間に数度の頻度のターン攻撃型のリリースであり、ほぼ全員から理解されないのが会議の長さです。
> しかしこの2つを欠くとスクラム(レベル3)は絶対に機能しません。
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
https://zenn.dev/shin_semiya/articles/13ecfad2d0f126
> 特にビジネスサイドから理解されないのが1~2ヶ月に1度の映画型リリースではなく1週間に数度の頻度のターン攻撃型のリリースであり、ほぼ全員から理解されないのが会議の長さです。
> しかしこの2つを欠くとスクラム(レベル3)は絶対に機能しません。
Create mikotea9 by MikoTurkNode · Pull Request #19743 · TryGhost/Ghost
https://github.com/TryGhost/Ghost/pull/19743
ひどいPRで笑ってる
このアカウントは、notestockで公開設定になっていません。
https://www.reddit.com/r/truenas/comments/u858t7/comment/izx72wt/
> rolled my eyes so hard at this I almost broke my neck.
日本語圏でよく見るクソデカ誇張オタクみたいなこと言ってる人がいて笑っちゃった
万国共通のしぐさらしいw
sqlx (Rust) は offline mode を使おうとするとちょっと癖がある気がするが、概ね便利
3値論理 - Wikipedia
https://ja.wikipedia.org/wiki/3%E5%80%A4%E8%AB%96%E7%90%86
3値論理といっても unknown の場合だけでなく indeterminate の場合もあるので、「hogehoge における3値論理」みたいな言い方をした方がいい
典型的には、第三の値を NaN のような「伝播する」値にするか、 true と false の「中間の」値にするかのパターンが想像しやすい
あとは閉世界仮説に強くこだわるなら NULL を使わない方がいいけど、開世界仮説によって物事を考えようとしているなら NULL を “ちゃんと” 使いたくなる、などのアレもある。着地点としてはちゃんと設計をしましょうねという話だけど。
というか RDBMS における NULL ってまさに float における NaN と近いし、そんな「NULL は異常だ!」って懇々と説かれましても……いや知ってますが……浮動小数点数を使って計算したことないんですか? という気持ちに
まあ意識しない分には qNaN が出てくるより前に sNaN で例外飛んで気付くパターンが多いのかな
それはそれとして現実には RDBMS でいちいち NULL を気にするのがダルすぎるし小数を扱うときいちいち NaN を気にするのがダルいというのは全くもってそのとおりなので、ちゃんとやろうねという感じはある (しっかりスキーマ作って適切に strong typedef をしましょうということ)
自分が使っているもののモデルってやつをどこか早めの段階でしっかり理解しておく必要がある
このアカウントは、notestockで公開設定になっていません。
RDB まわり、どうせしっかりやろうとしてもマイグレーション状況がアプリの想定と一致してないやつとかスキーマをミスってた DB とかベンダー由来の違いとか変なの混入してきそうだし、密結合で全体的に一貫性を持たせるのはあまりにつらそう
DBMS は DBMS、アプリはアプリでちゃんと validation したうえで界面の外側は別世界として信頼せずやっていきましょう、くらいの雑な気持ちがある (パフョーマンス出ないのかもわからんが)
stored function とか、概念を見るぶんにはワクワクするし夢がひろがりんぐなんだけど、アプリから依存するのはちょっと嫌というか (これは実務で RDB を触っていないトーシロの偏見です)
たぶんこの辺りの感覚が、趣味において独立したデーモンとしてのミドルウェアを使いたくない気持ちに繋がっている。外の世界にスキーマを持ちたくなくて SQLite とか Sled とかで茶を濁したくてたまらない
STRICT Tables を使ってない SQLite もそれはそれで大概だけど……
このアカウントは、notestockで公開設定になっていません。
結局別プロセスになってしまったらどう足掻いてもアプリケーションは一貫性とか知識の完全性の幻想を信じられなくなるわけで、だったら最初からそういうものに期待しない方法でやるべきなんだろうな
このアカウントは、notestockで公開設定になっていません。
念の為書いておくと、これは DBMS で strong typedef して NaN を排斥しようという意図ではありませんでした……
このアカウントは、notestockで公開設定になっていません。
でもデータを一度読んで validate してしまえば以後は必ず (バグがなければ) 一貫性を信じられるという状況であれば、もう少し安心して生きられるわけで、やはりアプリに埋め込まれた DB 実装を……
設定ファイルとかだと version = "n" みたいなの持っといてスキーマのバージョンに応じて以後の解釈を動的に変えたりできるわけだけど、それだけでもまあまあダルかったりするし (部分的なロードなり validation の遅延&追加の型変換なりでオーバーヘッドがある)、どこを向いてもつらさから逃げられない
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
機能 #153: 監視サービスを VPS から自宅クラスタへ持ってくる - 鯖缶 - Nopmine
https://redmine.potato.immo/issues/153
このアカウントは、notestockで公開設定になっていません。
RTX1300 の市場価格と倍近く違って、これ待たなくてよかった……となっています (何がこの価格差を生んでいるのやら)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。