画像ｱｯﾋﾟﾛｰﾄﾞテスト

ﾖｼ！ (object storage のポリシー設定がかなり雑だったのでちゃんとした)

飲酒運転の怖さを記者が体験　福岡県警主催の飲酒運転体験会（テレQ（TVQ九州放送）） - Yahoo!ニュース
https://news.yahoo.co.jp/articles/aa7f2d6f72135035155c5ce5c889235a31330896

飲酒運転体験会いいな

大人げないアカウントに万が一絡まれてしまったら腹立つのはこっちなんだから、そりゃ自衛するでしょ。
ミュートにしろとか言うけど、理性ない奴は「なんだこいつシカトしやがって」とか「おい聞いてんのか無視すんな」とかで勝手にヒートアップした挙句謂れのないヘイト向けてくるんだから、ブロックした方がマシかもしれんで

ブロックが攻撃的だというのは一理あるかもしれんが、ミュートならそうではないから平和だというのは考えが足りていないと思う。そもそも理性的かつ紳士的に振舞えるような連中だったら普通はそうそうブロック対象にならないという大前提を忘れてやいないか？

有害性の有無という判断基準を勝手に「好き嫌い」に矮小化するのは良くない。
まあ好き嫌いの問題を有害性の有無という言葉に勝手に置き換えてオレオレルールを押し付けてくるアホどもを見てきた反動なのかもしれないけど。

このアカウントは、notestockで公開設定になっていません。

RC though とか言ってそう (???)

☑ Concrete Mathematics はコンクリートの数理の本ではない

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

昔はレビュー欄の始まり部分でタイトルを選択できていた気がするんだけど、最近はできない (というかタイトルがそこに表示されなくなった) 気がする

このアカウントは、notestockで公開設定になっていません。

ドリルを買いに来た人が穴を欲しがっているという人、鍋を買いに来た人は料理を欲しがっているとかドヤ顔で言ってそう (?)

反証可能性は単にそうであるかそうでないかという2値しかなくて「尤もらしいか」という観点を (意図的に？) 潰した尺度なので、反証可能であれば何でも妥当になるというものではないと思う

尤もらしさの尺度の判断に恣意性が紛れ込みやすいというのは実際そうなんだけど、そもそも反証可能でないことについて尤もらしさが無意味である、という最初の一歩が反証可能性の要求に繋がっているものと思っている

重い腰を上げて Minecraft の mojang アカウントを MS アカウントに移行するか〜となったのだが、 Firefox (PC) と Chrome (Android) 両方で「一時的な問題が発生しています」で弾かれるのでかなりクソ

このアカウントは、notestockで公開設定になっていません。

もう一度 (3回目) 試したら今度は「このサイトは一時的にご利用いただけません」になった、マジでマジで何なんだ

kyo.new
hin.new

このアカウントは、notestockで公開設定になっていません。

わかる

他社の MS が取れるなら……と思ったけど、あいつらｸｿﾃﾞｶﾃｯｸだからお高い TLD だとしても不思議ではない

https://www.namecheap.com/domains/registration/results/?domain=hin.new

あ、いいんだ

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

そういうこともあるのか

このアカウントは、notestockで公開設定になっていません。

えー……読みやすいか？

async とか をさておいた話をすると、素朴に「ループが状態を持っていて自分で書き換える」という汎用的でマウンテンゴリラのように強力な構文の読解というタスク自体が脳への負荷大きくてつらい。 reduce と一言で言ってくれればループを読む必要ないのに。

map.map.filter が読みづらいなら
.filter((item) => foo(fuga(hoge(item))))
のように部分的に結合しちゃってもいいわけで。

await Promise でゴテゴテすること自体が本質的な可読性の低下に寄与しているかというと、あまりそうではない気がするなぁ。結局は async なムードであるかどうか、どこで sync な世界に戻ってくるか、くらいしか気にするべきことはないわけで、追加される複雑性は以外と少ない

inspect でのロギングのタイミングが微妙に直観的でない場合があるかもしれない問題なぁ

べつに next のタイミングでチェーンの先頭から適用されるだけじゃんという感じがするけど、直観的でないと言っている人は昔どこかで見たことがある

基本的に高速→言語の問題
メモリ消費量が少ない→言語の問題
文句言われず済む→社会の問題

険しい

まあ前者2つについてはそれこそ言語次第で (たとえばイテレータの方が高速な言語も普通にありうる (なぜなら bound check の省略がしやすいとかコンパイラに渡るメタデータを多くしやすいとかいろいろある))、最後のは……ﾊｲ……

変数の書き換えをメソッドチェーンでやるならそもそもイテレートされる値にそういう書き換え対象の状態を含めるのが定石な気がするけど……

つまり結局は外の状態を直に書き換えることはしない

https://twitter.com/lo48576/status/1550047701936766977

このアカウントは、notestockで公開設定になっていません。

元も子もないけど、まあそう

良識と理性を誰もが信頼できるなら規約なんてものは要らない、そういう考えもある

Rust は try block いつになるやら

まあ下手な仕様で入るよりは粘ってくれとも思うけど

try block どころか try trait の仕様で揉めてる段階だからね

先は長い

それはある

べつにメソッドチェーンに限った話ではないけど、 sync ops in async context はどうにかなるけど async ops in sync context はキツい

前者は async runtime がオフロードする手段とかを提供していることが多いが、後者はどこかの浮いてる async ランタイムなりジョブキューなりに乗せて完了までブロッキングするくらいしか取れる手がないため (そして async ムードな関数は急いで処理を完了させてくれるとは限らない)

Stream trait はまだ core に入ってないから futures ですね

AsyncIterator in std::async_iter - Rust
https://doc.rust-lang.org/1.72.0/std/async_iter/trait.AsyncIterator.html

入ってないというか unstable というか

一応 sync iterator のメソッドに async fn を block_on とかで包んで渡すことは不可能ではないだろうけど、 Iterator を Stream 化したうえで素直にチェーン組んで最後に await からの block_on する方が素朴だし、たぶんスケジューリングとかの都合でもその方が良い挙動になる

このアカウントは、notestockで公開設定になっていません。

カレンダーなし部いくわよ！

強いて言うなら上下の一方向

PrayStation (仏壇) いいな

？

Praystation(HiTECH NINJA Remix) - CytusII Wiki*
https://wikiwiki.jp/cytus-2/Praystation%28HiTECH%20NINJA%20Remix%29

あるんだ……

1st full album『praystation 2 』配信リリース決定 | CVLTE | ソニーミュージックオフィシャルサイト
https://www.sonymusic.co.jp/artist/CVLTE/info/529314

同じグループだからってやりたい放題でワロてる

みんな祈ってる
祈ってないのワイだけ

言語次第と雑に書いたが、正しくは言語処理系次第

昼寝するか

妥当すぎて妥当ショコラになった

このアカウントは、notestockで公開設定になっていません。