@pokarim
学術論文だとDOIの使用がかなり一般化されていると思いますが、他はそんなことないのかな。。
https://jp.service.elsevier.com/app/answers/detail/a_id/26892/c/10546/supporthub/sciencedirect/
URL、「こちらの図書館にはこの本がある、こちらの図書館にはない(404)」みたいな仕組みになってしまっていて、そうじゃないんやISBNみたいに「この本」を指し示す記号がほしかっただけなんやってなる。
それがURNだけど、あまり使われていない。
それがURNだけど、あまり使われていない。
URLが場所にリンクするようになった経緯、なんだろうな。そもそもコンテンツIDのようなもの(コンテンツIDがあるコンテンツを指ししめす)であるべきだったとおもうんだけど。
URLは場所にリンクするから住所を登録するようなもので引越しするとリンク切れになる。電話番号のように移動可能なものを対象にすればリンク切れを防ぎやすくなる。
これの引用見てると、日本まじでやばいな
https://twitter.com/koreans_school/status/1673488310826844160
https://twitter.com/koreans_school/status/1673488310826844160
プーチン、あいかわらず西側の責にしているけど、敵を外部に設定することで結束を強調するのってけっこう古典的だな。
内部の結束があまりに脆いことを露呈した事件だとおもったけど...。
https://www.bbc.com/japanese/66017202
内部の結束があまりに脆いことを露呈した事件だとおもったけど...。
https://www.bbc.com/japanese/66017202
わかるけど、ソースコードから見るとビジネスとかなんとか、いろいろソースコード外部の存在なのは間違いなくて、コード表現が必要ないものもたくさんある。コード上には変化があらわれないが、ビジネスとしては位置付けが変わっており、コードから読みとられるべき意味が変わってしまうこともあるとおもう。
とはいえ、ヒストリがもう少しコードベースと統合された感じになっていてほしいというのもわかるにはわかるんだよなぁ。現状いろいろなものがソースコードに対してメタな存在でありすぎる (典型的には ticket tracking system のチケット)
「コードを読む」ということと「差分を読む」ということで、ピックアップしたい情報の性質がかなり違っているとおもう。コードを読むときにはコード間の関連とか論理的な仕組みとか読んでるとおもうけど、差分を読むときに読みたいのはビジネス的な経緯なんじゃないかな。
私も基本的に feature ブランチみたいなのはどんどん rebase/fixup/edit していって、意味的に小さくまとまったきれいなコミット群として再構築してから merge するようにしている。こうすることでブランチ全体のレビューを個々のコミットのレビューへと分割できるようになる (もちろんその際分割が適正か、悪意がないかは別途疑う必要はあるが)
コミットログ、実際の作業経路とは異なった形で再構築することがけっこうある。インデントを揃えるのは単独のコミットで、そのあとにコードの修正を別コミットでやるとか。diff としての見易さにそって再構築する。
ソースコードへのコメントはプログラム構造に沿った形の記述しかできないので「過去にぜんぜん違う構造だったコードについての評価と解説のログ」みたいなのは残せない。そういう点でやっぱりソースコードそれ自体はあくまで(日々変化する環境の中に身を置くプロジェクトの) スナップショットでしかなくて、時間という構造に沿ったコメントとしてのコミットログは代替できない価値を持っているように思う