  |
はてなキーワード: コンパイラとは
プログラミング言語で動的言語を嫌って静的言語こそ至高みたいな主張の人って結構みかけるんだけど、なんでみんな偉そうでマウント取ろうとしてるの？
パフォーマンス面での優位ならまだわかるけど主張は基本型がないことをディスってる
頭が良ければ脳内で整合性の取れるコードを書けるわけだから、コンパイラのサポートがなくても書けるほうが優秀なのは自明のはず
コンパイラにサポートしてもらわないとまともなもの書けないよというほうが能力としては劣ってる
劣っててコンパイラのサポートがほしいならそれでもいいんだけど、なぜ自分が無能だということを偉そうにアピールできるのかがわからない
自分頭悪いので静的言語じゃないと書けないんですーとか言われたらじゃあそういう言語使うかとなるけど、
動的言語とかゴミ使う価値ないとか、◯◯言語は消えるべき、とか言われたらお前の頭が悪いだけなのになぜそれに合わせる必要があるの？としか思えない
anond:20240324030115 へつづく
春から修士2年で，今はまだ就活中だがそのうち終わるし，授業ももう無いしで，なんか純粋に知的好奇心を満たすやつをやりたくなってきた
この一年で徐々に徐々に，回路触りたいとか，低レイヤやりたい欲求が再燃しつつあった
本や部品を買うためにバイトを増やすと，肝心の活動に避ける時間がなくなってしまうし
もちろん，研究でもある種の好奇心は満たせるし，就活で停滞していたぶんを早く取り返したい気持ちもある
自分の受け止め方は，
→ググっても出てこないことを調べて，ググったら出てくる情報にする，新規性と客観的な正しさが重要
進学しない人でも実績増やせば奨学金の免除も狙える(大学院の話)
でもまあ，一発ネタでもなんでもいいけど，解決したい課題とかテーマが必要な感じ，独自性があるといろいろと受けがよい
チーム開発したとか，身近な人に使ってもらったWebサービスとかだと，エンジニアでない人事担当者にも伝わりやすそう
→金が儲かる，なんか社会の役に立つ(たぶん)，なんか金儲けに役立つスキルが身に付く
動機(金が儲かる，人の役に立つ)があるおかげで，もともとそんなに興味が無いようなことでも，調べて勉強したりするきっかけになって面白い
みたいな感じなんだけど，
ArduinoでLEDをチカチカさせる，CPU作る，みたいなことはわかる人にはそれなりに評価されるのかもしれないが，短期的に対外的評価に繋がりにくいように思うし，すぐには自分の生活をよくしないので，学生の自分ですら後回しにしがちだったと気づいた
ネガティブな意味ではよくわかっていないコンピュータシステムの上でいろいろやっている負い目とか，
コンプレックスだったり，インプットが足りていないままアウトプットに偏った活動をしている劣等感とかだろうか
就活や就活向けの思考に疲れ始めているせいで，そうゆうコンピュータクラフト系に癒しを求めている部分もあると思う
自分のこれまでの活動をうまく利用して，有利に就活を進められる場を提供してくれたサポーターズなどのサービスやイベント，
品定めするような目線を受け続けているとアンチ金儲け主義のような意識が芽生えてくる
会社が金儲けのために使う道具として自分がどれだけ優れているかばかりアピールしていると，そうではない側面が盛んに自己主張をはじめる
就職活動が念頭にあるので，自分の経験をわかりやすく就活で有利になるパッケージにしよう，みたいな考えにいつのまにか陥ってしまっていた
同年代が経済的な豊かさを手に入れ，どんどん人生の次のステージに進んでいくのを見ていて，焦りもあった
パンだけじゃ 生きていけねえ，し，
せめて高収入だったり，他人にすごいと思われるような職について，自分を慰めてやりたかったのかもしれない
あと一ヶ月もしたら，これまでの活動は内定承諾という形で一旦精算されそうなので，
残りの時間は研究と，別に新しい何かを生み出さないかもしれないただ好奇心を満たすための活動に使いたいと思い始めた
(面接では，一日も早く御社で活躍できるような人材になれるように勉学に励みます，みたいな顔をしているが)
別に社会人になっても，休日に自室で一人で自作CPUを半田付けしていてもいいし，多分やってると思うんだけど，
終わりが見え始めたら，周りに興味をもってくれそうな人がたくさんいる今の環境は尊く得難いものであると気づいてきた
そんなことを考えながら，いろいろググっていたらCPU自作を手芸に例えたとても秀逸な投稿を見かけた
裁縫も編み物も商業的にはほとんど機械化していて，実用品を手に入れる目的なら買った方がはるかに早く安く性能もいいが，
まさに手を動かして作る楽しさを味わうために取り組む趣味的な活動として残り続けている
自作CPUとかは短期的には対外的評価を得にくい活動かもしれないが，それ自体が純粋に自分の好奇心を満たし，
達成感や充足感を与えてくれるので精神的な意味では「すぐに自分の生活をよくしてくれる活動」と言えるかもしれない
1. コードはプログラマーと宇宙の秘密のやり取り。でも、宇宙は時々 "42" って言っちゃったりすることもある。
2. プログラミングはエラーを見つけ出す冒険。ただし、その冒険にはときどきドラゴンも混ざっていることがある。
3. 真のプログラマーは "Hello, World!" を書くことで宇宙の秘密を解き明かすことができます。それから "Goodbye, World!" と言ってサヨナラします。
4. プログラムは人生のコントロールセンター。ただし、"Ctrl+Z"（元に戻す）は人生には効かないことがあります。
5. コードは時には詩よりもラグビーの試合のよう。問題に突進し、バグをタックルしまくります。
6. プログラミングはあなたが言うことではなく、コンパイラが理解することです。コンパイラが言うことを聞く賢明さが必要です。
7. コードは魔法のスペルブック。しかし、時々 "Abracadabra" を打っても期待通りのことが起こらないことがあります。
8. デバッグは魔法の水晶玉のよう。時には見通しがよくなく、ぼんやりしていますが、それでも未来を予測しようとします。
9. コードは時間のカプセル。将来の自分に向けてメッセージを残すことができます。ただし、時々 "TODO: 未来の自分、これを修正してください" というメモしかありません。
10. プログラムは宇宙のレゴセット。ただし、説明書がなく、最初からピースが1つ足りないことがよくあります。
セキュリティソフトウェアの研究開発、という仕事を自分の経験をもとに紹介します。主な想定読者は、情報セキュリティ関連を仕事にしたいと考えている学生や若手、特に、いわゆる「低レイヤー技術」に惹かれている人です。
低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合 - 覚書を読んで思い出したのですが、セキュリティキャンプなどで、セキュリティに興味のある学生とやり取りをしていて、ソフトウェアエンジニアリングの分野でセキュリティ関連のキャリアが議論されることが少ないと感じました。自分はセキュリティソフトウェアの研究開発に１０年以上携わっていることもあり、この職業は低レイヤー技術をセキュリティに活かせる面白い選択肢だと思っているので、紹介してみることにしました。
セキュリティソフトウェアの研究開発では、アンチウイルスやEDRなど、文字通りセキュリティ機能を提供するソフトウェアを研究、開発します。
「研究、開発」と書いたように、この職業には研究と開発の両面があります。
研究は、実現可能性や価値が定かでないアイディアを調査、試験実装する、という仕事がその一部です。例えば、ファイルをディスクに書き込まないマルウェアを検知したいが、どのような技術的選択肢と課題があるかを評価する。実現可能な場合は、開発チームと協働して実装、出荷にこぎつける。あるいは、製品として実装された機能がバイパスされないか調査したり、バイパスされてしまった場合にはその原因を究明したりして、製品を改善するために開発チームと協働する、という場合もあります。
開発は、研究との対比という意味においては、できると判っているアイディアを保守性の高い状態で実現する作業だといえます。保守性の重視は研究との大きな違いで、例えば、研究では、コメントもテストものない書き殴りのコードで十分であっても、開発の工程では、5年後でも改修が必要になるため許容できなかったりします。製品という大きなコードの中での開発であるため、別のチームや利害関係者との連携も、研究の場合よりずっと重要です。例えば、リードのポジションであれば、研究工程で実現可能と分かったアイディアが、既存の機能に統合する形で実装されるべきか否かアーキテクトと議論したり、テスト計画を品質保証のチームと練ったり、プロジェクトのスケジュールを調整したりします。
研究は、既定の手法がなく、闇の中を手探りで進める面があり、最終的に製品レベルにこぎつけずに終わる場合も多いです。判りやすい成果が出ない場合があるので、好き嫌いが別れやすいです。自分は、職業としては研究３，開発７くらいのバランスが好きで、趣味では逆に研究８，開発２くらいになってます。趣味では成果が出ようが出まいが過程が楽しければ満足、という個人的な考え方がこの違いとして出ているようです。
この職業のおいて、低レイヤー技術に明るいことは、ほかの多くのエンジニアができないことができるという付加価値、だと自分は考えています。例えば、特定分野の詳細を知っていることでその分野の研究、開発が効率よくできたり、新しいアイディアが生まれたりします。具体例をいくつか挙げると、OSの仮想メモリー管理に親しみがあれば、プロセスのメモリーを走査してメモリー上のみに存在するマルウェアを検出する機能をより効果的に設計、実装できる。プロセッサーの機能の詳細を知っていれば、CETという新しいプロセッサーにしかないセキュリティ機能を、他のプロセッサー機能を使って疑似的に実現するというアイディアを思いつく。などです。脆弱性の知識や探す技術も、とても価値があります。脆弱性を知らない人と、知っている人では、どちらが脆弱性の少ない設計や実装をできるでしょう。自社の製品の脆弱性を、開発中に発見するのと、テスト・出荷後に発見、改修を加えるのではどちらのコストが少なくて済むでしょう。コンパイラーの知識は検出ロジックを書くための独自言語の開発に、エミュレーターの実装経験はマルウェア解析エンジンの開発に役立ちます。
ただ、低レイヤー技術は付加価値であることに注意してほしいです。
まず前提として、ほかの平均的なエンジニアができることに加えて低レイヤー技術があるべきです。セキュリティソフトウェア開発者の多くは、実はセキュリティや低レイヤーのエキスパートではありません。優秀な開発者であることに加えてこれらを必要条件にしてしまうと、人が雇えなくなってしまうためです。そのため、一般的なエンジニアリングの能力に加えて低レイヤー技術やセキュリティという強みがあると、大多数の開発者ができない（したがらない）ことを任せられる人、と差別化してもらえる可能性が高いです。一方、エンジニアリングに対する素養や意欲なしでは、セキュリティソフトウェアの研究開発職は難しいです。その場合、研究者のほうがあっています。（ちなみに自分は、脆弱性解析とマルウェア解析を専門とする研究職にも各２年ほど就いていました。）
ここからは一般論になりますが、OSに詳しくても、プロセッサーに詳しくても、バグハントが得意でも、それを会社が求める結果を出すために使えなくては意味がありません。会社は、あなたがやりたい仕事をくれません。会社は、会社が必要としている仕事をもってくるだけです。
ではどうやって「会社が必要とする仕事」と「あなたがやりたい仕事」の重複を最大化するか。
まずは、上司にどういう仕事をしたいかを明示的に、繰り返し話しておきます。さらに、能動的に、自分からプロジェクトのアイディアを提案して意欲を示すことも心がけます。あなたの仕事を最終的に選ぶのは上司である以上、上司からの理解は必須です。良い上司（そして良い上司であることを可能する、良い上司の上司）は、必ず、あなたの能力に対する信頼度に応じて、あなたの意向を考慮してくれます。言い換えると、まずはやりたい仕事を主張する前に、与えられた仕事をこなして信頼を得る必要があります。個人的な経験では、これは１年あれば十分で、１年たっても状況に変化がない場合、あなたの仕事ぶりが上司の信頼を得るのに不十分か、あなたがやりたい仕事をうまく伝えられていないか、上司やその上司あるいは会社に問題があるか、あるいはこれらの組み合わせの可能性が高いです。
上記がうまくいかない場合、チームや会社を変えることを検討しましょう。チーム異動はリスクの少ない選択肢です。これも、実現するか否かは、上司からの信頼の程度に大きく依存します。会社を変えるのはリスクが大きいですが、上司やその上司を変えるよりも現実的です。新しい会社でもうまくいかなかったら、また新しい会社を探せばOKです。最終的にあった会社に行きつくか、自分の能力やコミュニケーションに問題があることに気づくと思います。
最後に、「会社が必要とする仕事」と「あなたがやりたい仕事」の重複を追求しないことも視野にいれておきましょう。仕事はあくまでお金のためであって、やりたい仕事のほうが楽しいが必要要件ではない。……という視点を持っておくと、些細なミスマッチで不満をためて、そこそこ良い環境から性急に転職してしまう、という状況を防ぎやすいです。隣の芝生は青い、ということを忘れないように。
セキュリティソフトウェアの研究開発は、セキュリティに深く関わりつつ低レイヤー技術を付加価値として自分を差別化できる面白い職業です。
ところで自分は７年務めた研究開発職を退職しました。おめでとう、ありがとう。これからは、また違う低レイヤー技術＋セキュリティの研究開発をしていきます。
