あずさにゃん〜〜〜
@d_flat_aug7 ハンガリアン記法（それともなぜkかという話？）
PCからはWells Fargoにログインできるのにモバイルからはログインできない現象が発生してて謎
パスワード変えたら入れるようになった（謎）でも指紋認証の設定がバグってるしWells Fargoのアプリがそもそも壊れてる雰囲気あるな
@d_flat_aug7 cはcharに取られてるからドイツ語読みしてkonstの頭文字という説が有力だけど、誰が使い始めたのかは謎
本当に真面目にやるなら古い関数は残しつつdeprecatedにしといて新しい関数に順次移行する……みたいにするけど、8割位のケースではめんどいだけでほとんど意味がないのでやらないですね
コミット粒度というよりレビュー / マージの粒度と言ったほうがいいと思うけど、フルタイムの仕事なら20分で読み切れるくらいが目安だと思っている
ちゃんと静的に型が検査される言語ならシステムハンガリアンはいらないですね
Portal pluginがfollow_userをサポートしてないせいでmikutter落ちるの1万回くらいやってるから直すべきか
git flow を参考にするといいと思います (「この問題の修正」はコミットではなくブランチの粒度だと思う)
まあundoで戻ってこれるポイントを作りたくなったらコミットする、でよさそう
どうしても分割できないデカいfeatureというのはあるので、そういうのをレビューしてもらうときはコミットを論理的なステップに分けといてコミットを1個1個見てね、みたいにするのはやる。ただ他人が同じことをやってくれるのはあんまり期待していない……
@tsutsuii それ、「なぜこのコードが生まれたのか」の背景を知りたいときはどうやって追うんですか……？
何を置いてもチケット番号だけはコミットに書いといてくれないと流石に困るやろ……最悪それ以外が完全に無でもいいから……
最近コミットログ追ってたときにsquash mergeでキレた例です
https://github.com/bootstrap-vue/bootstrap-vue/commit/5bf6733595091cc204d3acc0641f8f0301bcbe9c
GitHubだとticket descriptionという独立した概念がなくてcontributor用のチェックリストとかの有象無象もdescriptionに入ってしまうから、squash mergeしたあとのコメントをいい感じに生成するのが難しいんだな
そのfeatureが何をするのかはPRのdescriptionに書いてあるはずだから、（人手を煩わせないため自動で生成したいと思うと）squash mergeしたらそのテキストを引っ張ってきてほしくないですか？
なんか最近明らかに記憶力が落ちていて、具体的には設計図をあらかじめ書かないとコードが書きにくくなってきている。これが歳か……
記憶をアウトソースしようと思うと出力速度がボトルネックになるので、攻殻機動隊の指先がめっちゃ細かく枝分かれするやつになりたい
電脳直結は非現実的としても、本当に欲しいのは指先が100本になるやつではなくて、メモ用紙に落書きしたテキストと図を適切にタグ付けして索引にしといてくれる何かなんだよな
コード書いたことなくても、論理的に精密な議論ができる数学的センスのようなものがあればいいという認識
変な自然言語を出力されるよりは論理式を出力されたほうがずっとマシなので……
インディード、求人の投稿もできるので死んだゴキに対処する人を見つけることもできるよ（法人格なくてもできるのかは知らん）
Rustでcrate Aが内部的に依存している他のcrate Bの型Tを返してきてて、そのTを自分のプログラム中で明示的に扱いたいときってcrate BをCargo.tomlに追加するしかない？具体的にはscraper::element_ref::ElementRefの返してくるego_tree::NodeRefに対するpredicateを関数として書きたい
うーんやっぱりそうなのか。Transitive dependencyをCargo.tomlに書くの気持ち悪いし、ましてやバージョン指定なんてしたくないんだけど……
@toshi_a でもライザ2はあんまり調合詰めなくても雑に強いムーブできるのがな……
