最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日本でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果

モデルあい子。モデルアイコン公式。 @komumodel 別業の話。 中学を卒業して、 16歳から60歳まで 「食パンを型に詰める作業」だけしてくれていた方がいましてね… みんな小ばかにしていたけどその人、ずっとそれを果たしてくれました。 定年で退職されて（当時延長雇用は無かった）、事件が起きます。 「味が変わって戻らない…」 大切な技能でした。 2021-10-20 13:00:39 モデルあい子。モデルアイコン公式。 @komumodel 「詰めるだけでなんでそんな給料持って行くんだ」とかささやかれていたのは知ってます。 でも、本当に大切な仕事をなしえてくれていました。 当時は延長雇用は無く、「疲れたからゆっくりするよ」と言って最後に握手させてもらえた記憶がよみがえります。 2021-10-20 13:02:10

「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまでC#DIDependencyInjection依存性の注入 DIはインタフェース定義しなくても十分実用的だし、むしろそっちの方が本質だよ、という話をします。C#や.NETを使っていますが、それに限らず普遍的な内容です。 インタフェースと実装に分けるとか無理。DIなど不要！ 中堅社員のA氏は、「DIっていちいち実装とインタフェース分けないとダメなんでしょ？。さすがにやってられんわ」と言って頑なにDIを導入しようとしません。 DIはテスタビリティと併せて語られることが多かった為か、A氏は「注入するクラスは基本的にインタフェース定義しましょう」という記事ばかりを読んでいたのです。 インタフェースと実装を分けるとは、例えば次のような事です。 services.AddScoped