ToDo:
いやすごい面白かった。流行りものかつ長いもの、斜に構えてしまうものがあるのだけど、とても良かった。最初の10巻くらいはちょっと疲れる感じだったけど
流行り&長いで言うと、鬼滅はまあいいかという感じだったけど、呪術もなかなか良いなあという感じ
(20:07)
は割と好きな雑談トピックの一つなんだよなぁ。グーグルとかでも、大雑把なとこでは合意がある程度あるけど、細かく聞くと微妙に違ったり、なるほどその視点は良いな、みたいなのも多いし
https://twitter.com/shinh/status/1378585722404229122
の続きなんだけど、解けた解けないを重視しすぎたせいで明らかに不適切な評価をつけてしまったと感じて反省しているケースが一つある。直感ではこの人は強い、と思っていたし、興味深い視点を次々と出していたのだけど、なんかしら僕が想定している模範解答には直接辿りつきはしなかった。今思い出せば絶対に良い評価をつけてるのだけど、なんか当時は「ウーンやっぱこれ解けてないし、前の解けたけど微妙ぽい感じの人が落ちたことを考えると……？」と思って、悪い評価をつけてしまった。当時、 accept/reject をハッキリ書きなさい、と教育されていたことも、悪い方に働いたと思う。幸い、たぶん僕が calibrate されてない面接官で信用されていなかったこともあるのか、他の人が良い評価をしてくれたおかげで、その人は accept となったし、実際入ってからも活躍しているという認識。でもアレは本当に良くなかったなあ、と思っていて、面接になるべくなら関わりたくないと思い続けている。人の人生を左右するのはこわい
これ以外のケースではうまく面接できてるかというと、別にそんなことはなくて、ほぼ全ての面接の後で、「あの時これを聞いておけば、この人のいいところをもっと引き出せたかもなあ」などと思わないことはほぼ無いような気がする。あとどうしても労働の質にムラがある人間なせいで、面接の質にもムラがあって、調子悪い時に当たった人は申し訳ないなあ……というのもよく思う
「いいところを引き出せた」と書いて思い出したのだけど、アラ探しをするよりは、いいところをたくさん探して、その量が合格量に達したか、で判断するのが良いと思っている。人間の長所というのは本当に色々あって、同じ問題を出しても、分析力が良い、逆質問の仕方が良い、単にコード書くのが速い、コーナーケースの作りかたが良い、色んなパターンのグッドシグナルがある。アラ探しをしていると、どれか一つだけの尺度だけの判断になりがちで、その典型的な例が僕のやらかした「正解してないから不合格」だった、と思っている
「自分が答えを知っている必要もない」とツイッターに書いて、実際面接のちょっと前に自分が「ウーンどうしようかな？」と考えてたようなことを聞いてみたりとかもする。これはちょっと注意が必要で、「相手が自分より大幅に賢い場合に相手に教えてもらうことになるので、その相手の説明を自分が理解できるくらいの考察は自分に必要」というのがある。このへんに open-ended な質問の面白さがある気がするけど、僕はこわいので、自分が平均的な人よりかなり詳しい程度自信があることについてだけ、この手の問題を出すようにしている気がする
なんか色んなこと考えたり書いたりしたけど、元の nuc さんの「お茶をする」「よい面接は漫才のように進む」あたりの表現は本当に簡潔かつ適切な表現で、面接とか問題を出している、というよりは、未来の同僚との雑談、みたいな意識があるよねえ、と。ただ「お茶をする」の方はあの文章の他の部分と同様、賢い人サロン的な気持ち悪さも感じてしまうけど
(20:06)
https://www.creativ.xyz/shakaijin-first-anniversary/
そうそうこういう、実際に役に立ったことがあった、みたいなの見たかったなと思ってたのだった
C++ でいうと std::find を気軽に書くくらいの人は、やってみると役に立つかもねくらいの感覚がある
(18:26)
https://www.amazon.co.jp/dp/B08YJWRJ4V
おもしろい。
中で行なわれいる CTF がエスパー問題乱舞な感じで、これリアリティないなあ……と思ったけど、よく考えるとモデルが SECCON ぽいので、なんかむしろとてもリアリティ満点だったんじゃないか、とか思ってしまった。
いや、今はだいぶ良くなってるんだけど、僕が参加した最初の2年くらいの印象が悪すぎるんだよな SECCON ...
(18:39)
https://twitter.com/takigare3/status/1377821095617724417/photo/3
ffrk のプロテスバグを思い出した
http://shinh.skr.jp/m/?date=20150511#p01
(12:48)
いつもの競プロは役に立つか話。
競プロと仕事の能力の相関が高いか低いかっていうと、まあ相関はあるだろうけどそれほど大きくもないみたいな話は、まあ自明で良いと思う。ところで面接の結果と仕事の能力の相関も、これは高くしようとして努力しているわけだし、競プロとの相関よりはあるのだろうけど、そうはいってもギャップがある。
面接もゲームである以上 cracking code interview みたいな攻略法が出回ってくるし、 rebuild.fm のどこかで話されていたけど、そういう定型は外すようにしている、みたいな話もあると思う。
で、なんか、攻略法が出回ってる状態だと、競プロに打ち込んで面接クリアする人の方が、面接対策に打ち込んで面接クリアした人より役に立つというのも普通にありそうだよなあ、とも。競プロは娯楽でゲームでパズルという側面が強いので、なんというかそのへん強い人って、頭の回りとか良くなってて基礎的な能力が上がってて、業務知識より長い目で見ると有用という可能性もないでもない。
いや、そうだとしてもフツーにプログラム書いて基礎的な能力上げれば良かろう、と言われれば、それはそう。それはそう、というか、思い出してみると僕が SRM ちょっとやってた時の気持ちって、ある程度強い成績収めてから「競プロね、あれ面白くないしフツーにプログラム書いた方が面白いし役に立つと思うよ」て言ったらカッコ良くない？てのがモチベーションの一部にあったんだけど、なんとも言えない微妙な成績にしかならないので、どうしようもなくなったんだけど……
直接的に役に立つ立たないでいうと、マラソンや CTF の方が直接的に役に立ってるような気もしないでもない。なんかでもそれ以上に、仕事がマラソンや CTF の役に立った、って印象の方がはるかに強くて、ひっくりかえっている。いや、ひっくりかえっているかというとそんなことはなくて、プログラミングコンテスト自体、「いろいろ強いプログラマいるけど、プログラミング力を比べてみると面白くない？」的に発生している気がするので、案外それが本来のありようなのかもしれない
僕自身は中途半端な立ち位置なんで、競プロ大好き、って人はに「普通にプログラム書く方が楽しいよ、つまんない作業もついてくるけど……」って言いたくなるし、競プロやらない、って人には「一回やってみると手軽に世界が広がるよ、ドハマリする必要はないと思うけど……」って言いたくなる
(16:42)
https://bugs.ruby-lang.org/issues/17768
i = 0
(i += 1; "hoge#{i}") while i < 10
^^^^^^^^^^m
p m # hoge10
なるほど最後のになるのか
(17:51)
「物理学者,機械学習を使う」を読んだ
https://www.amazon.co.jp/dp/4254131291/
オムニバス系はたのしくて良い。
読んでるとこう、「あっこの単語見るたびに意味わからんなーとなってたやつだ……」みたいなトラウマが蘇える。全く覚えちゃいないので強くてニューゲームとはならないのだけど、「この単語適当にスルーしてると後で何度も出てくるから雑にでも把握しておいた方が良い」くらいのことは(トラウマという形で)覚えているので、全くのニューゲームではない。
ぱっと思い出すのは、ハミルトニアン、エルミート、ユニタリ、 SU(2) あたり。なんかさすがにこのへんのやつくらいであれば、 wikipedia 見たらそうそう……みたいな感じにはなる。が、まあやっぱ物理物理してる章はかなりつらいので、流し読みになる
物理学の発展から半導体ができて、情報科学が発展して、それが物理に帰ってきて計算物理が第二の実験になった。物理からインスピレーションを得た機械学習をまた物理が取り込んで第三の実験となる、という考えかたは面白いなと。物理ってこう原理から計算みたいなのが大事な印象があったけど、なんかまあ言うてもともと結構モデル化しまくってるわけで、そのモデル作るのが人間から機械になってもそんなに抵抗ないもんなのか、それともこの人たちが異端なのか
あとなんかお気持ち的なのがちょくちょくあるような気がしたので面白かった。物理から見た機械学習の意味みたいなやつとか……統計力学と情報結びつけるやつとかあやしいけど楽しくて(忘れると熱が出るやつ)、あれと似たなんかを感じる
それにしても相変わらず素粒子とかはマジで何言ってるのかさっぱりわからんな……となった。
(19:03)
https://twitter.com/hikari_is_here/status/1371679437629063168
We 使う系は、僕はほぼ使わないけどよく見るよなあ。
(12:31)
https://twitter.com/odashi_t/status/1371321602760081411
日本人が英語書くとなぜか語気が異常に強くなるなと思うことがある
これときどき思う。なんというかたぶんあまり自信がないから短くさっと書こうとしてると思っていて、短い文章が基本無礼なのだよな
コードレビューしていて、テスト書いて欲しいとしよう。まず、
Please write a unittest.
は、たぶんあんまり丁寧じゃない。日本語でも打ち解けた仲じゃない相手から「テスト書いてくれませんか？」て帰ってきたら「ちょっと怒ってる？」と思うと思うので、英語特有の話じゃないと思う。どうやったら丁寧になるかっていうと、なんか深く考えず長くすればたぶん丁寧になる。例えば
Could you write a unittest, please? Thanks!
くらいで僕的にはほど良い感じになる。この Thanks! は、なんでやってもらう前から感謝してんの？となるけど、「トイレを綺麗に使ってくださってありがとうございます」の Thanks! で、中学校とかで教えるといい気がする。あと動詞 + you 使うとどこまで薄めても命令形なので
It'd be great if you add a unittest. A unittest will be really appreciated.
とかもいいのかもしれない。知らんけど、たぶんそう。
Would you mind if I ask you to write a unittest?
くらいまで行くと僕は慇懃無礼というか British English (日本語訳: 京都弁) かな？となるような気がしている
あとそもそも意味なく長くするのでなくて、ちゃんと正攻法で長くすると丁寧になると思っている。自明なものでも理由を添えると丁寧になる気がしていて
This function looks fairly complex to me. Write a unittest, please?
だと please の部分は同じだけど、威圧感を感じなくなると思う。でも前文が
This function is complex.
だとちょっとこわいかもしれない。なんかとにかく断定系がこわいので looks とか to me とかで、「お前のコードは普遍的に複雑だ」を避けて、「僕には難しいなあ」という感じにすると良い気がする。僕は動詞に全てランダムに may とか might をつけて、意味もなく、 it looks like とか I think を頭にくっつけたり、 maybe とかを乱舞させたりして、なんか敵意の無さをアピールしている。たぶんやりすぎて違和感ありまくりな文章になってると思うけど、敵意を読み取られるよりはマシだと思っている……
あとそもそも書く内容を消してしまうというのがあって、テスト書くのを依頼しようと思うと、相手が初コントリビューションとかだと書き方とかも説明しないといけなくなって、テストの書き方英語で書いてる時間で自分書けるよ、となる。で、そうなのであれば単に
How about ``` diff --git a/hoge_test.cc b/hoge_test.cc ... ```
とパッチを送りつけるなり
Let me add a unittest as a follow-up, thanks!
とか言って後で自分でやってしまえばいい。これについては akr さんの「超簡単! 英語でバグレポート」が素晴らしいと思う
https://staff.aist.go.jp/tanaka-akira/pub/2015-11-08-oedo-rubykaigi-05-akr.pdf
| 前 | 2024年 5月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | 31 | |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。