USBケーブル、常時接続しておくものは黒、たまにしか接続しないものは赤、と色を分けています
— magnoliak🍧 (@magnolia_k_) 2022年4月3日
そうすると赤色のケーブルが見えると違和感が出て「片付けなきゃ」という気持ちになります
いろいろなプロセスを作り上げていく上で、「こっちじゃないな」という違和感をどうやって感じさせるか？というのは大事な設計観点だったりしますよね。
自宅のインターネット環境をau ひかりに変えた
フレッツテレビや、ひかり電話を解約することにした。 だったら何の回線でもいいんじゃないか？ということで、自宅のインターネット環境を「au ひかり」に変えてみた。
せっかく工事が発生するなら、NTTのダークファイバーを使っていないauにしてみよう、という理由でauひかり。
回線速度については、具体的な数字を書いても「タイミングとか環境による」ので、あまり参考にならないので載せないけど、平均的には速くなった。5Gコースとか、10Gコースなども申し込める地域だったけど、そこまでは不要だったので申し込まず。
ホームゲートウェイがONUと分かれるのは、唯一のフレッツに対するデメリット。ホームゲートウェイの無線LANがIEEE802.11axをサポートしているのはちょっと嬉しい。活用できる機器はあまり無いけど。
設定項目も特段目新しいものはなく、特に追加で設定することもなく、あっさり利用開始。
以前、フレッツがIPoEのIP v6接続になった時に、Meraki Go + Apple Musicが接続できなくなった、というエントリを書いた。
とりあえず、これは解決した。久しぶりにMeraki Goを復活させることができた。単にデザインが好きなだけなんだけど。
ということで、あっさりつながって、速度も（ベンチマーク上は）速くなって、月々のインターネット回線費用も下がった（オプションを利用しなくなっただけど）ので、乗り換えは成功。
方法論は、問題は解決してくれない
ドメイン駆動設計と向き合うんじゃなくて、ドメインと向き合うんですよ
— magnoliak🍧 (@magnolia_k_) 2022年3月26日
でも方法論に関する技術書、結構分厚いし、内容も難しいから結構集中して、自分の使える時間をかなりがっつり注ぎ込んだり、読書会でみんなで読んだりしないとそもそも読み終わらなくて。
その関心度の集中の結果、「これだけの時間をかけたのだから、きっと良いものなのだ」というバイアスがかかってはいけないし、現実のプロジェクトではほかにも対応しないといけない課題は山のようにあるし、方法論にだけこだわってはいけないんだよね...
issueを書く時に気をつけること...まずは「書くこと、書かせること」そして「感想や予測ではなく、事実だけを書くこと」
issueの書き方
— magnoliak🍧 (@magnolia_k_) 2022年3月26日
1. 題名は観測された事実を書き、感想や予測を混ぜない
2. どういう挙動を期待し、何が違うのかを明確にする
3. 発見されたときの環境条件を明らかにする
4. 自分でも再現できたか、できたらその手順は何かを示す
5. 再現できない場合は、可能な限りその時の実行条件を明らかにする
とりあえず最初の「題名は観測された事実を書き、感想や予測を混ぜない」を特に意識的にやってみるだけで、ずいぶんと印象は変わるはず。
そもそも「0. issueは口頭ではなく、書いて文書で伝える」というのが有るかも https://t.co/jQ704XxU5f
— magnoliak🍧 (@magnolia_k_) 2022年3月26日
あと、そもそも書かない、というのがけっこう有って、エントリは有っても実質中身が無いとか、延々と口頭で説明するとか。
とにかく書いてみる、書かせてみる、まずは書いてみないことには始まらない。
ちゃんと指導しないと、最初は誰でも「○○が変だ」「挙動がおかしい」みたいなissueを書きがちだけど、それはしょうがないよね
— magnoliak🍧 (@magnolia_k_) 2022年3月26日
教育されていないんだから
いつの日か、issuepilotが出来上がる日も来るかもしれない。
issueの添削やってくれる教育サービス
— magnoliak🍧 (@magnolia_k_) 2022年3月25日
が有ればいいのに
「issueは題名が9割」みたいな感じで指摘が始まるの
修正案は独自AI「diffペン先生」が書いてくれるの https://t.co/VoKLs055sX
コードから読み取りたいことは何なのか、定義が必要じゃないか
・実装の意図を読み取る(コードブロックとかメソッドのレベル)
— magnoliak🍧 (@magnolia_k_) 2022年3月22日
・処理方式／設計思想を読み取る(クラスとかモジュールのレベル)
・ユースケースの目的を読み取る(APIやパブリックインタフェースのレベル)
・ドメインの知識を読み取る(全てのコード全体のレベル)
みたいな読み解くレベルがあるなって https://t.co/4kt36ut7L5
書いてあることは分かるけど、意味が分からない、みたいな時があるけど、コードから読み取りたい(もしくは意図が書かれてないから読み取れない)ことの正体に名前がついてると、少しは混乱が収まるかもしれない。
一つきっかけが有れば、そこからの理解は早いんだけど、そもそも今何を読むとろうとしてるのか、それを意識して読まないとずっと分からない…が続くよね
