This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

脳が壊れて2つに割れてる心配があるな

電気椅子が交流でなく直流な話なぁ

おいしい焼肉はいかが

電気椅子が電気によるショックではなくジュール熱で焼け死ぬというの、首吊りが窒息ではなく首の損傷で死ぬというのに近い「そっちか〜」感がある

首の損傷と書いたけど、脳への血流が滞るのが「損傷」かは微妙

生ポインタとスマートポインタの話をしているのかと思った

異世界セマフォ……ｳｯ

This account is not set to public on notestock.

有用なのはわかるんだけど、まず 100W フルで給電できる USB PD デバイスを見たことがねえんだよな……

いやもちろん需要が高まりすぎてオレオレ規格が乱立する前にデファクト標準規格を作っておくのが最適解なのはわかってるんだけど

個人的に USB について思うのは、規格のバリエーションにちゃんと名前を付けろということと、マークやら端子の色やらだけでなく、ちゃんと規格が一発で識別できるよう端子やケーブルの形状を工夫してくれということですね……

たとえば (直に端子が出ているデバイスはさておき) ケーブルの端子の持ち手部分に「USB 3.1 Gen2」とか書いてあったっていいと思うわけですよ。まあそれが必須にできない以上は規格でなくベンダーの案件だと言われるとそうかもしれないけど……

あるいは USB の人々の野望としては常に最新の規格のケーブルとデバイスで世界を満たすことで非互換から解放されたいという気持ちでもあるのかもしれないけど……

ところで私は HTML の Living Standard みたいなのが大嫌いです

Universal Serial Bus 、たしかに名前を見てもデータ転送のためのものだとは誰も言ってないんだよな…… (?)

This account is not set to public on notestock.

3相交流、もはや serial かよくわからない感じになってきたな

単相の交流であれば、まあギリギリ「差動伝送みたいなもんじゃん！」で済みそうだけど、3本……？

よく考えてみれば、 USB はせっかく端子が沢山あるのに VBUS と GND から電源を伝えることばかり考えていて、差動信号として D+ と D- から交流100V15Aの電力を送れるようになる可能性を見落としていたな #適当

🤔

This account is not set to public on notestock.

「新しいUSB」「新しいUSB (1)」なども忘れないであげて (???)

30k円で15.6インチのモバイルディスプレイを買うか悩んでいて、それだったらもうちょっと金出せば 31.5 インチくらいの据置きディスプレイ買った方が QoL に貢献するのでは？ みたいな気持ちも拭えなくてどうするか

This account is not set to public on notestock.

@toshi_a 囲み文字 - Wikipedia https://ja.wikipedia.org/wiki/%E5%9B%B2%E3%81%BF%E6%96%87%E5%AD%97

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

秀丸か？ 秀丸か？？？w と思ったらサクラだった (秀丸も上位だった)

This account is not set to public on notestock.

まあﾎﾟﾖｸﾞﾔﾏとは言ってないからね……

This account is not set to public on notestock.

こういうとき old gear があればいざというときのサラダになるんですよ

ところでこれは廃棄するか悩んでいるきんぴらごぼう

まあ賞味だし食えるでしょ (開けた)

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

edが治ってvimvimとか言ってる人がいたので vim の方が良さそう (???)

https://twitter.com/AoiMoe/status/328509181193756674 #tw

This account is not set to public on notestock.

✘ IDEは使わない
◎ IDE はライセンス貰えないし無料でもインストールさせてもらえない

みたいなのはありそうでこわいね

This account is not set to public on notestock.

SKKの操作がわCannaくてWnnと唸るわけですね (?)

1940年東京オリンピック - Wikipedia
https://ja.wikipedia.org/wiki/1940%E5%B9%B4%E6%9D%B1%E4%BA%AC%E3%82%AA%E3%83%AA%E3%83%B3%E3%83%94%E3%83%83%E3%82%AF

> 開催権を返上

返上できる権利だったの……

ワイは vim ユーザやぞ

授業課題の Java コードとかも vim で書いていた

Scheme 書いてるときは流石に「これ Emacs 勉強した方がいいか……？」と思ったけど、 Java くらいなら C++ みたいなもんだし vim でよくないですか？ (?)

This account is not set to public on notestock.

これすき

自分の動機やモチベくらい自分の手で扱わんかいと思うわけだけど、こういうこと言うと健常者の健常マウンティングだとか言われちゃうんでしょうね

他人には自分を喜ばせる責任はないんだから自分でどうにかするしかないんやで

まあ人気だの評価だのが (あたかも正確な数字であるかのように) 細かく出せるようになってしまって、それに一喜一憂してしまう人はこれからも絶えることはないのだろうなぁ

もっと自分の芯を貫いてハードコアでやればいいと思うんですよね。アクセス解析なしの自前 web サイトでコンテンツ公開するなんてそんなに難しいことじゃないし、実際そうしている人も沢山いる

動画配信者がスパチャで狂わされていく (ファン主観) 話を思い出したわ

This account is not set to public on notestock.

料理だ…… (?)

たぶん勘所をわかっていないことは問題の本質ではなく、「わかっていないものを変更して動くことを根拠なく信じられる」というメンタルというか行動原理がマズいんじゃないかなと思っている。しらんけど。

モチベでも理念でも何事もそうだけど、自分の中から生えているものを核にしないと外的要因ですぐ揺らぐし、そういうものの持続性を信用できないのであまり重要視していないというのはある (個人の感想)

何かにつけ「哲学」だのなんだのと原理主義的なことを言ってしまう理由の一つがコレ

お前は何を求めているのか、何をよろこびとするのか、行動が何に裏付けられているのか……そういう「本質」を常に自分に問い続けることで自分を知ることができるけど、まあ人に求めるのは酷なのかもしれないね

異常独身成人男性としてもな

まあ自分とかいうクソッタレを直視すると憂鬱になるの、それはそうという感じしかない

This account is not set to public on notestock.

日本語ネイティブ話者が日本語文法の質問に (正しく) 答えられないみたいな話などを聞いていても思うんだけど、典型的用法に特化した †柔軟な† 文法 (や文法への理解) はエッジケースに弱いのよね。
で、日本語非ネイティブが出力する典型的でないエッジケースなどでパーサが狂う。

なので、より厳密に言うなら「パースしづらい」よりも「いつか平常レベルの文法理解ではパース困難なデータに遭遇してしまう (その頻度が高そうである)」という方が正確な表明ではある

たぶん文脈: https://twitter.com/lo48576/status/1395025879143616516

This account is not set to public on notestock.

自然言語は (一部の例外を除いて) 本質的に解釈の一意性の保証ができないことが共有事項となっているのが効いている気はする

設定の記述やプログラムの記述は大抵多義性があると死ねるので

逆に法文みたいなものは接続詞の優先順位がどうのみたいな (自然言語にしては) 奇妙なお約束が多数発生していたりして、自然言語的な「便利な (そして厳密で正確な解釈が困難な) 文法」が曖昧さを許容できる特定の用途にしか向いていないというだけの話ではある

「省略できたら楽じゃん、 optional にしよ」みたいなのは “自然言語的” な発想である、みたいな雑なラベルを付けても良いかもしれない (ほんまか)

意味論的多義性を確保しつつ構文的には一意な解釈を可能にしようとした例として、計画言語 Lojban などがあります

Strippers, JFK, and Stalin Illustrate Why You Should Use the Serial Comma |
https://www.verbicidemagazine.com/2011/09/20/strippers-jfk-and-stalin-illustrate-why-you-should-use-the-serial-comma/

自然言語の構文的ガバで困る例、 oxford comma の有無などは一例として挙げられそう

そも言語というか記号列は解釈のルールを伴わないと “意味” を持てないわけで、人間の知能について十分なりかいが及んでいないのであれば自然言語についての理論が枯れているわけがないのも当然といえば当然のことではある

This account is not set to public on notestock.

反語や “圧” をかける文章みたいに構文自体が (メタでない) 情報を持っていることがあるので確かに区別は難しそう

This account is not set to public on notestock.

This account is not set to public on notestock.

まあ難しいと言ったのは不可能と断言するほどの確信を持っていないだけで、私も現時点では実用的に可能な気はしていないです

自然言語のモデルはようわからん

雨の中わざわざ荷物を届けてくれた配達員に、この格好で応対してしまった

This account is not set to public on notestock.

https://misskey.io/notes/8ma9gxs11r

squash は原則避けるべきという考え。より正確には、 squash せずに各コミットがいくつかの条件を満たすような行儀の良いコミットをこころがけるべき。

この話、何度も書いている割にはひとつのスレッドでまとめたことなかったのか……ちゃんと整理する必要があるな

(いや記事にしろという話だけど)

前提として、 CI やテストは任意のタイミングで走らせることがある。
たとえば push のタイミングだったり、たとえば定期的だったり、たとえば全コミットだったり。

で、少なくとも master や develop のテストで「全てのテストが通る」ことを求めるのは当然だと思うんですが。
対照的に feature ブランチや fix ブランチでは、テスト駆動開発のように「最初に (現時点では失敗する) テストを追加して、ブランチが merge 可能になった時点でテストが全て通っていることを期待する」のような運用もありえるわけですね。そうすると、 feature や fix ではテストは通っていなくともよいが最終的に全部通るようにしろというくらいになる。

テストはそれでいいんだけど、問題は lint とか build ですね。
私は基本的に「すべてのコミットで (例外なく) コンパイル・ビルドできるべき」と考えていて、 lint もまあ原則そうですね。

部分的に実装した関数が unused であるみたいなことは考えられるので、そこは実装の順番とかプロジェクトのポリシー次第だけど、個人的にはコミット時点でのツールチェインで lint の警告が出ないことを制約として課している。

では、なぜ全てのコミットで build が成功しないといけないか。それは、 git blame の能力を損なわないため。

git blame は「特定の問題がある新しめのコミットと、問題がない古めのコミットを手掛りに、その間のどの時点でバグが混入したかを発見する」というもの。
つまり、「あるコミットを選んだとき、今注目しているバグがそのコミットに入っているかそうでないか」を必ず判定できてほしい。

もしビルドが通らないコミットが間にあったり、そういうのが連続していたりすると、どのような意図でのどのような変更で、どの時点で不具合が混入したのかを追跡できなくなってしまう。

クリティカルな理由はこんな感じ。

加えて「レビューしやすさ」の観点でもコミットの粒度には注意すべきだと思っていて、コミットは「○月△日の変更」とかではなく「どのような理由や意図で、どのような変更を引き起こした」というのを自然言語で説明できるべき。
たとえば「ネットワーク経由でデータを取得する機能の実装に備えて、タイムアウトのオプションを追加した」とか。そういう「意味」や「意図」でコミットは分かれていてほしい。そうするとレビューもかなり楽になる。

squash すると「どの部位の変更が、どのような小目的なのか」というのが見えづらくなる。

また、全てのコミットでコンパイルが通るべしというルールのもとでは「先にあった変更は、後のコミットで新規追加されるものには (少なくともその時点では) 依存していない」という依存関係も読み取れる。
関数の中身がダミーで将来的に相互依存するようになるなどはあるかもしれないが、それでも「誰が何に依存している」とか「新しくこれがあれに依存するようになった」とかを少しずつ読めるようになる。
一気にあらゆる変更が入ってくるよりはずっと読みやすい。

まあ現実には「今更になって3つ前のコミットの誤字や欠陥に気付いた」みたいなことはあるわけだけど、そういうのは git commit --fixup で「特定のコミットに対する修正」として分離された小さなコミットにしておいて、 merge を要求する直前に git rebase -i --auto-squash でコミット修正コミットを反映させる、という形で直すべき。

同じブランチで導入した変更について後から「fix typo」とかいって typo を直すだけの別コミットが入っていたりすると、 fixup を使ってくれと思いますね。まあ説明するのがダルいので諦めて merge してしまうこともあるけど

さておき、私が (少なくとも git-flow を使っているとき) squash すべきでないと考えている理由とか運用ポリシーはこんな感じ。
あとで文書にまとめるかもしれない (有限時間以内とは言ってない)

長いスレッドになったけど、本質はこの2つですね。

https://mastodon.cardina1.red/@lo48576/106306527663315229
https://mastodon.cardina1.red/@lo48576/106306537602121922

git blame での追跡しやすさを損わないためにコミットを分けるべき、ただし全コミットはビルドに成功すること。
変更の意味・意図や依存関係を読み取れるようにするためにコミットを分けるべき、ただし各コミットの変更は言葉で説明できるような意図を持っていること (そしてそれがコミットメッセージになる)。

This account is not set to public on notestock.

https://pao.moe/@nukosu/106306589465583774

これもあったわ、私は lint の一貫としてコードが整形済であることの検査も入れてたので明示的に書き忘れてた……

This account is not set to public on notestock.

thinking シリーズだ

うぅ……すまねえ…… thinking_faces リポジトリのﾌﾟﾙﾘｺそのうち merge するから……

カラースキームは molokai とか好きだったなぁ

まあ好きでない点もいくらかあって、部分的に上書きしたりしてた

my new gear...

This account is not set to public on notestock.

superDIY.
極度自作 (しなさい)

とかも欲しいわね

This account is not set to public on notestock.

goto fail; の話はやめてやれ！

ボイチャしながらでもｹﾞｯﾑのﾀﾞｳﾝﾖｯﾖが実行 50 MB/s (400 Mbps) 安定して出ていて、悪くない感じだ

This account is not set to public on notestock.

さーて SSD 増設するぞー

水素の音ォ〜！

new gear な SSD に SATA ケーブルが付属していなかったが、予備の SATA ケーブルがあるので実質勝ちですねこれは (長さが足りるとは言ってない)

政府向けシステムの話をするときの前提知識
https://anond.hatelabo.jp/20210520175754

いま増設した SSD のセットアップしてるんだけど、 LUKS で暗号化するのはいきなりディスク全体が良いのだったか、 GPT でパーティションひとつ作ってその中にするのが良いのだったか……

This account is not set to public on notestock.

他のディスク見ると、 何故か /dev/sdb だけダイレクトに LUKS で暗号化されていて、それ以外は GPT で単一パーティションにしてあったんだよなぁ (何故……)

他のメリットとしては、 GPT パーティションを作るとパーティションラベルを割り当てられる

argon2i は key derivation function やね

切捨御免はごめんで済んでいたし警察も不要だった

図書館の貸し出し履歴、捜査機関に提供　16年間で急増：朝日新聞デジタル
https://www.asahi.com/articles/ASP5V45Q1P5MUTIL03Z.html

えぇ……

カフェか何かでも併設されてんのか？？？