> GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
https://www.publickey1.jp/blog/23/github1200mysql_5780.html
> Release v1.2023.13 · plantuml/plantuml
https://github.com/plantuml/plantuml/releases/tag/v1.2023.13
W3C in the news:
"The fediverse is a collection of decentralized social media services that interconnect via ActivityPub, a specification from the (W3C). The fediverse is nothing short of a renaissance on the social web because, for the first time in well over a decade, social media has a chance to be truly decentralized. This has massive implications for developers; it may be the best open platform opportunity since the blogosphere in the early 2000s."
https://thenewstack.io/the-state-of-the-open-web-3-takeaways-heading-into-2024/
日本語記事
>デスクトップ版Googleドライブのファイル消失問題、解決策公開。ただし復元できない場合も - PC Watch
https://pc.watch.impress.co.jp/docs/news/1553587.html
>インターネット広告ポエム2023 - フジイユウジ::ドットネット
https://fujii-yuji.net/2023/12/10/230716
ラムダノートってこんな本も出してるんだねぇ。
>ピアリング戦記 ― 日本のインターネットを繋ぐ技術者たち – 技術書出版と販売のラムダノート
https://www.lambdanote.com/collections/frontpage/products/peering
次期Goの汎用for range。他力本願でほんのちょっとだけ試してみた - 標準愚痴出力 https://zetamatta.hatenablog.com/entry/2023/12/11/100053
長文にチャレンジ。
拙文「Go のエラーハンドリング」でも書いたが
https://zenn.dev/spiegel/books/error-handling-in-golang
Go のエラーハンドリングの戦術は以下の4つに分類できる。
1. nil との比較(エラーの有無を評価)
2. インスタンスの同一性
3. タイプ・アサーションによってエラーの内部構造を取得する
4. エラーメッセージ(Error() メソッドの返り値)を解析する
このうち3番目と4番目の難易度が高いのは直感的に分かるだろう。
3番目はその型の内部構造を知っている必要があるし4番目はあからさまにバッドノウハウ(今どきで言うならアンチパターン)である。
なので,エラーを吐く場合にはできるだけ1番目または2番目のパターンに落とし込めるようにするのがよい。
もうひとつ。
Go では,エラーは Error 型に boxing される。スマートポインタと言ったほうが分かりやすい人もいるかも知れない。
そのため,エラー同士の比較では等価性(equality)ではなく(インスタンスオブジェクトの)同一性の評価となる(実質的にポインタ値の比較なので)。
ここで errors.New() 関数の価値が出てくるわけだ。
この関数を使ってあらかじめ sentinel error を作成しておくことで最初に挙げた4つの戦術のうち「インスタンスの同一性」がやりやすくなる。
さらに Go 1.13 からはエラーを構造化できるようになり errors.Is() 関数でエラーの原因を遡って「インスタンスの同一性」評価ができるようになった。
これにより errors.New() 関数の役割は sentinel error の生成に特化できるようになった。
これが go-err113 の意味である。
とはいえ Go 1.13 以前のコードでは errors.New() 関数にそこまでの意味はない。
特に fmt.Errof() 関数と比較すれば errors.New() 関数は圧倒的にコストが低い。
エラーの有無を評価を評価するだけでいいなら,関数の return のタイミングで errors.New() でエラーを生成しても全然 OK なわけだ。
古いコードではそういう戦術をとっている場合も多いだろう。
コンパイルエラーはともかく lint のルールは絶対ではない。
あるコードに対して lint をかける場合に「そのルールは本当に必要か?」検討するべきだ。
その上で「errors.New() 関数の役割は sentinel error の生成に特化」ことをプロジェクトのルールとするなら lint で積極的に評価スべきだし,そうでないならいっそルールから外すことも検討したほうがいいだろう。
...ここまでで1,100文字とちょっとか。全然余裕だなw 5,000文字とかショートショートが書けるぜwww
#golang >なぜGoでerrors.Newを都度呼び出すことが推奨されないのか
https://zenn.dev/dimdim1996/articles/0b491a71b10b4f
> KotlinのコードからWebAssemblyバイナリを生成可能、Kotlin/Wasmがアルファ版として提供開始
https://www.publickey1.jp/blog/23/kotlinwebassemblykotlinwasm.html
お散歩カメラ 2023-12-10
https://text.baldanders.info/remark/2023/12/10-osanpo-camera/
Big Dipper over Pyramid Mountain
Image Credit & Copyright: Steve Cullen
>都市を六角形タイル状にすれば事故へるのでは?→つくば市の一部で採用され、全ての人の方向感覚を破壊している - Togetter
https://togetter.com/li/2272671
あれだな。城下町のつくりと同じ。態と感覚を狂わせて敵の侵入を阻んでいるわけだw 特に三叉路は感覚狂うよねぇ