ToDo:
長年、日本語ではなんというのかさっぱりわからん単語の一つだったのだけど、今日検索したら「水をさす」というのが出てきて、なるほどー！と思った
improve もよくわからんとずっと言ってるのだけど、それは「いや、改善でしょ？」と言われる。まあそうかもしれんのだけど、改善と improve 、割と語感違うくない？ improve の方が軽いというか……
(22:26)
大学の時、「セキュリティの人は変わった、気難しい方が多い。やっぱり攻撃とかを考えてると性格が悪い考えかたをしていくことになるのかな」などと先生が言っているのを聞いて、そんなもんかな、と思っていた
会社で働くようになって、多くはないけど、関わったセキュリティ専業の人は、全て良い人だった。グーグルは押しなべて平均より性格の良い人が多い集団だったと思うけど(おかげで僕は「貧すれば鈍する傾向が強い」の確信度を高めた)、その中で見ても良い人達だったように思った。
まあ偶然いい人ばかりと会ってたのかもしれない。実際、プロダクトを作っている人の「セキュリティレビューが厳しくて〜」みたいな愚痴だかなんだかを聞いた記憶も結構ある
けど、僕としては、ローンチを止める強い権限を持つだけに、好ましくないコミュニケーションをしていると仕事にならない、て感じなんじゃないかなあ、と思っていた。というのは、セキュリティというのはどこまでいってもトレードオフで、「薄い確率でセキュリティやばいからローンチできない！」て言い続けると永遠にローンチできないことになるので、そのあたりをちゃんと理解している人は、かなり丁寧に、問題点を整理しつつ、お互いの妥協点を探ってくれる印象があった。
たとえば、このシステムは A と B が良くなくて、 A は簡単だからなおしてほしい、 B は本当は X を使うのがスジなのだけど、それは結構大変でローンチが遅れてしまうから、とりあえず現状でいいけどハック Y を入れてゴマかえば attack surface はだいぶ減るから、ローンチ後に全力で X に置き変えてね、みたいな
逆に、セキュリティ本職でないけど詳しい人がセキュリティのアドバイスをしてくれてたこともあって、まあその人個人の資質が大きいのだろうけど、その人は原則論的な主張が強くて、やりにくいこともあった。その人はとても優秀なのにも関わらず、なかなか昇進できなかったのだけど、まあそのコミュニケーションスタイルのせいだろうなあ……と思っていた
なんだろうな、個人的には、実際のプロダクトに密接に関わる、完璧ではないが、費用対効果のうまい落としどころを探す……みたいなセキュリティが結構好き
(11:47)
https://github.com/systemd/systemd/issues/3302
一行 2k までしか fgets で読んでないから、 2k 越えのぶんが次の行として解釈されるみたいな話だと思う。このレベルの有名&重要OSSでこんなことやってるってすごいなあ、という気持ちがある。 C やめて C++ 使った方がいいんじゃないかな……
(12:07)
https://mofmoffox.hatenablog.jp/entry/2020/06/05/232311
いたときから、選考に時間かかるの申し訳ないなあと思ってた。
ただ、雑に扱われた、は外から見るとそうなるのわかるんだけど、僕の感覚ではむしろ、人事的処理を丁寧にやりすぎてて(採用だけでなく昇進なども)、オーバーヘッドが大きくなりすぎて、遅くなってる、と感じてたかなあ。
やまあそれにしたってもっと早く返事できるのなんかがんばれよ感はあるけど
(11:54)
なんていうかこうMSてもうIT大企業で一番綺麗な企業みたいな気持ちがみんなあると思うんだけど、なんかそれでもこういうの見ると、歴史の動きみたいなのを感じてゾクっとするものがある……素直にスゲエ、と思うというか
https://japan.zdnet.com/article/35153989/
(15:44)
https://gist.github.com/mala/08fdbc680d84bb1b2305688282f26cea
僕はネットの S/N が良いと幸せなので、いいこと言うなあ、と思う。個人的には。けど、まあなんかこういうのは愚行権をみたいなやつで、そして認めないのもなんか違うと感じている気がする。愚行権が何故だいじかというと、僕に取って自明に「愚行」に見えても、人にとっては大事だったりするから。そこは人それぞれだから、人に迷惑をかけない範囲で適当に愚かなことしていいよ、という考えかたは好きだ
例えば腐女子が検索避けに / を入れるとかも、個人的には好きでないというか、嫌悪感を覚えるレベルだけど、まあいいかと思っている。なんで嫌悪感を覚えるかは、正直、自己正当化できないレベルに感覚的な理屈な気がする
あとアイスバケツチャレンジぽさもあるなあとか
なんだろう。インターネットの秩序より「コロナに対して気の効いた注意喚起してる俺面白い」て自己満足(に僕には見える)を重視する、てのはまあアリなのかなあと
実際には、自己満足どころか、かなり広く支持されている行為で、だからこそ苦言を言っているのかな、と勝手に想像したり。そういうかんじ
(21:59)
賢く中立的であるべき、みたいなこと思ってるのかな、とも思う。つまり空白を入れてるくらいなら、共立明民党というのがあったとして、「共、立、明、民、党(※AI注: ソーシャルディスタンスを喚起するために、故意に空白を入れているようです)」みたいな読みあげをして欲しいわけですよね……SF的には。
機械が賢くないから機械の読みやすい表記を取りたまえ、てのは、 SEO のアドバイスとしては良くて。アホだからやめろというのもそれも良くて(たとえば僕はもとの投稿を悪いとは思ってない)。ただなんか、僕自身はなんか、人間は愚かなので、機械が勝手にうまいことやれよって、そういう気持ちになっている気がする。
サイトを以降した時に、明示的に 301 を出してくれればそりゃいいんだけど、「移転しました。移転先はコチラ(コチラが青下線)」みたいなのがたくさんあって、そういうのをちゃんとトラックすることによって、検索会社は利益を増やし、サイト管理者は http を理解せずすみ、検索エンジンユーザは適切なサイトを発見できる、みたいな
なんかでも、「共 和 党」と「民 主 党」を大統領候補がやったとして、前者だけサーチされないことが起きかねない感は今のシリコンバレーにはある、みたいな印象があって、それはなんかさすがにアレかもしれない
(22:34)
人的リソースが無限に近くある会社から、普通に有限というか普通に小さい会社に移ったことで、スタイルを変えてみたトピックがいくつかあって、そのひとつがコードレビューかなあと思う
コードレビューで撃墜ケース探すのは、楽しくはあるんだけど、時間の無駄であるということがある。昔は topcoder の撃墜フェーズは良いものだと思ってたけど、今思えば良ろしくない。何が良くないかって、コードの問題を探す一番良い方法はテストを書くことであって、目を皿のようにして眺めることではない。
というわけで、とりあえずテストを見る、てのはなんか割ともともとしていた気がする。が、最近はもっとテスト偏重にしている気がする。CI通ってんならええよ！みたいな。PRで変更したと主張してることについて、その主張が満たされるならこういうテストが通るはずだよね、て想像をして、そういうテストがあるかな、って見て、あるならまあたぶんコードはええやろ、くらいの感じでやっている。テストが無いなら、暇があるなら撃墜ケース考えるけど、無いなら深く考えず、こういうテスト書いてみてーというだけですます。テストだけ書いてもらえば CI で次から情報が増えるので……
人的リソースが無限にあるなら、前職のような丁寧なレビューの方が良いことは多いのだろうけど、なんかああいうのは、余裕のある会社だからやれることという感じがするんだよな。あるものでなんとかするって感じだと、コードレビューは真っ先にサボりたいところである。ただそういう余裕が無いようではいいものは作れないという気もしないでもないが……
あと、スタイルは……なんか個人的に int を auto で受けるのとかだけはホント勘弁してくれという気分なので、そういう自分の宗教の表明は、初回は言うようにしてる。関数名が小文字スタートvs大文字であるとかは、(昔の？)LLVMみたいにファイル内で大混乱してない限りは、正直そんなに問題にならない、のでまあなんでもいいやという気持ち
(00:32)
https://north.thco.mp/2020/02/05/why-i-dont-use-apple-products/
https://juangotoh.hatenablog.com/entry/2020/02/06/183424
どちらも読むとバランスがいい感じになった
まあなんかマーケティングとかヨイショ記事がこわい、というのはあると思う
最近会社の僕のまわりだと「macなの？なんでlinux使ってないの？」くらいの勢いなので、逆方向のハラスメントが起きている
(18:26)
| 前 | 2024年 11月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。