株式会社はてなに入社しました
自宅のインターネット環境を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
書いてあることは分かるけど、意味が分からない、みたいな時があるけど、コードから読み取りたい(もしくは意図が書かれてないから読み取れない)ことの正体に名前がついてると、少しは混乱が収まるかもしれない。
一つきっかけが有れば、そこからの理解は早いんだけど、そもそも今何を読むとろうとしてるのか、それを意識して読まないとずっと分からない…が続くよね
printデバッグに絵文字を使うと捗る話
雑にprintデバッグしたい時、👺を使うと、赤くて目立ちます
— magnoliak🍧 (@magnolia_k_) 2022年3月21日
あと、目線が有るんで、「あ、ここを見るのね」ってわかって便利です(なにが?)
というツイートをしたら意外と反応が多かったので、ブログのエントリとして残しておきます。
printデバッグの時は冒頭に内容を示す文字列を書いておくと思いますが、その時に冒頭に「👺」を差し込んでおくと赤くて目立つし、珍しく横を向いてる絵文字なので、「ここから先を見ろ」って分かりやすい。
あとまず普通出てこないので、検索し易い。
macOS だと「おに」の変換で出てくるのでタイプ数も少ないし。
ちなみに👺はUnicode上ではgoblinという名称だけど、Tenguじゃダメだったのかな…
— magnoliak🍧 (@magnolia_k_) 2022年3月21日
iOSの鬼の絵文字も👹ちょっとイメージ違うしなぁ https://t.co/BcX4pO17aR
まぁ当然別に区別できれば何でもいいんですけど、絵文字の普及でUnicodeの文字の扱いがまともになって良いですね。
絵文字が普通にどこでも使えるようになってきて、色を付けてみたい時に、古代のエスケープシーケンス技法を発動しなくても良くなったし、プレーンテキストに落としても色がついたまま表示できるのが良いんですよ、この方法
— magnoliak🍧 (@magnolia_k_) 2022年3月21日
当然終わったらちゃんと消しておきましょう。突然コンソールとかログに👺がたくさん出てくると驚いちゃいますからね。
このままリリース https://t.co/IREAvWNOmO
— 🐼🐱🍺 (@hiuchida) 2022年3月21日