はてなブックマーク

仕事柄、リファクタリングやアーキテクチャの変更、新しい何かを入れることが多い。 その時についつい、 「まずは影響のないところからはじめて、何某」 とかやりがちなんだけど、このアプローチは正しいが、落とし穴もある。 影響が少ないということはそれだけ使われてなかったり、どうでもよい機能であることが多い。そういう機能を対象に小さく始めることは正しいものの、正しく効果測定ができなかったり、インパクトが出せないことで結果的に作業が進まなくなることもある。 僕自身はそこは意図的に使い分けていて、趣向としてはリスクとベネフィットがいいバランスならば、最初からビッグインパクトを狙いに行くことが多い。むしろ、このリスク、何かあった時の影響をいかに抑えるかが腕の見せどころだと思っていて、正直100%安全！！！みたいなところまでできないことの方が多いけど、何かあったダメージより、ベネフィットがでかいみたいなのを

僕にはない。 この前、YouTubeで堀江さんがomakase.aiの創業者に、こんなん俺もすぐ作れるって言ってて、omakase.aiの創業者の方、激おこしてたんだけど、僕は堀江さんの感覚、結構わかって、OpenAIなり、何かしらの生成AIサービスをバックエンドにして、ファインチューニングするなり、ガードレール作るなり、インデックス食わせるなりで工夫するくらいなら参入障壁も低いし、何より、ビジネスのコアコンピタンスを握ってないから、危うさを感じる。 これは前職のGMOインターネットグループの熊谷代表がよく言ってた言葉で、「刀の柄を持て」っていう言葉がある。ちょっと記事は古いけどこういうこと。 熊谷正寿 - 公式サイト おかげさまで21周年Ｗｅｂ２．０　マッシュアップ時代への警鐘 | 熊谷正寿 - 公式サイト おかげさまで...https://www.kumagai.com/?eid=29

パッケージ名変更と参照アップデートを一挙にこなす「pachanger」を使いこなそうGoの大規模プロジェクトを運用していると、次のような悩みはありませんか？ 「パッケージ名を変えたい。でも既存ファイルで大量に参照してるから、変更が大変そう…」「別ディレクトリにファイルを移動して名称を整理したいけど、他のファイルの参照先を書き換えるのが面倒すぎる…」「リファクタリングするたびに動かなくなるコードの修正に追われる…」「パッケージがでかすぎてビルドやテストが遅い」これらを“爆速”で解決してくれるのが、pachanger です。 この記事では、pachangerの基本的な使い方と、実際のユースケースや運用上のコツを紹介します。 「パッケージ名変えるとか怖すぎ…」から「このツールでパッケージ名を自由に変更できる！」 へと意識が変われば、あなたのGoプロジェクトの開発体験が大幅に向上するでしょう！ 1

転職活動は、iPhoneのトップ画面から興味があるサービスを選んで、その運営企業のWEBサイトからエントリーシートを出して、３社受けました。転職活動において大事にしていたのは、自分が普段使うサービスでありドッグフーディングできること、企業の中にあんまり知り合いがいないこと、未経験の領域であることの3点です。知り合いについてはペパボに10年いた事で、ある程度自分の経験、経歴で下駄を履かされていたこともあり、それを外したかったという意図があります。また自分がペパボで採用活動に関わっていたことからエージェントに払う対価がそれなりにかかることを知っていたので利用せず、正門から行きました。 GOに決めた理由は、個人として日本のモビリティに対して思うことがあり、それを当事者として取り組みたいと思ったからです。また同じ領域に取り組む企業は複数ありますが、交通業界様々あるので、自分の実現したい未来に一番近

今週からデータパイプラインとか、データエンジニアリングと呼ばれるあたりを中心に触り始めた。 というのも、ここ数年は自社のあらゆる商材のDevOpsやSREと呼ばれるような領域の仕事をしていたのと、リバースエンジニアリングが得意で普段触らないリポジトリのパフォーマンスの問題とかもひょいひょい改善できることが増えてきて、全然楽しめなくなってきたからだ。 いや、厳密には楽しい、障害や課題が発生しているときは最高に楽しいのだが、可用性が高くなれば高くなるほどそういう機会はなくなり、本来SREが取り組むべき自動化や、最適なキャパシティの制御、セキュリティ対応などが中心になっていて、それも結構得意であるがゆえに、つまらんみたいな感じ。 自社のデータパイプラインはほとんどオンプレの部分がないのと、僕が得意な可観測性を高める、可用性を高める、同じ問題を二度と発生させないような取り組みの余地が結構あるので、

僕はよく手が早いと言われるのだけど、そんな中で気をつけてることを整理してみた。大きくは下記の３点につきる。 複数タスクは抱えるが、並列で進めないイベント駆動で動くことを原則として、探索行動をしない暫定対応ではなく、最初から必殺する複数タスクは抱えるが並列で進めない僕はだいたい平時2〜4くらいのタスクを抱えている。しかし、だいたい1個〜2個に集中して片付けて、次に手を付けるっていう感じで進めている。 この2つをさばくときは、例えば1つ目のタスクのコードを書ききってしまって、レビュー待ちとかの問に、2つ目のタスクの設計を考えたり、あれこれ進めて、レビューコメントが付いたらまた1つ目に戻ってぐわーってやる感じ。もう少し小さいスキマ時間、例えばchefのapplyとかコンパイルだとSlackで適当に人に絡んでわけのわからないことを言って去るという感じのことをしている。 ともあれ、これの利点は基本的

先週、資料作りながら時間があったので、ホスティング事業部のメンバーのレビューとかに入ってて、2個思ったことがあった。 一つはDB設計においてカラムのあり方や、名前の名付けにおいて、今いるメンバーがわかるような名前ではなく、明日入ってきたメンバーにも分かる名前にすべきだし、カラム名から投げられるクエリがわかるようなカラム名したほうがいいという話をした。 これ結構ある話で、自分たちはわかるから安易なネーミングにしたり、設計したりしがちなんだけど、あなたがいま悩む10分は将来他人の1時間、1不具合、1手戻りを防ぐことになるのだ。 もう一個はちょっとした修正でも、既存の実装がダサければ、ボーイスカウト精神でリファクタリングをすること。 僕はいまだかつて時間に余裕のある仕事をしたことがないし、自分の目の前にある微妙なコードは、いつか治すという守られない決心、それが堆積した歴史であると思っていて、暇が

今日からです。 ペパボではチーフテクニカルリード(CTL)、テクニカルリード(TL)と呼ばれる職種が定められているエンジニアリング・マネージャー的なキャリアと、シニア・プリンシパル、プリンシパルと呼ばれるエンジニアリング・スペシャリスト的なキャリアが2軸ある。 僕はもともと2年ほど前にシニア・エンジニアだったのだけど、CTLができるタイミングで初代ホスティング事業部のCTLになった。 その後、ホスの技術改善やあれこれやるうちにスキルが上がっていったので、シニア・プリンシパルに立候補して、無事通過した。 今の所僕以外前例がなかったから、とりあえず兼務でやってたのだけど、シニア・プリンシパルという役割は国内、ひいては世界を基準においた場合に、優れた実績を出して初めて評価に値するというスタンスで仕事をしている中で、マネージメントもやりながらシニア・プリンシパルという立場であれこれやることに限界を

僕はお昼休み英会話してるか、どっかで一人でご飯しながら本を読んでるか、チームメンバーとご飯食べてるんだけど、最近は詳解システム・パフォーマンスを読んでいる。 その中でknown unknownという概念が紹介されている。それは、システムチューニングの局面においてknown-known,known-unknown,unknown-unknownという分類で説明されている。 known-knownは知っていることを知っていること、例えばtopコマンドでプロセスごとのCPUの使用率を見れることを知っているし、見たことがある。 known-unknownは知らないことを知っていること。topコマンドを知っているけど、使ったことはない(観測してない） unknown-unknownは知らないことを知らないこと。これはtopコマンドを知らないこと。 この中でunknown-unknown状態でシステム

昨日の夜からngx_mrubyのmrubyバージョンを上げた際に、SEGVが起こっていたので対応していた。 原因はGCで、FiberオブジェクトのirepがGC時にすでに開放されていることからSEGVになっていることは割と早くわかったのだが、対応方法をどうすべきかと悩んでおったら Matzさんが助けてくれた。 わからなかったら相談するかくらいな気持ちでおったところ、シュッと現れてシュッと解決してくださった。なんというか世界的に使われているプログラミング言語の作者がシュッと現れて、アドバイスをくれる体験、とてもすごいと思ったし、感動した。また同時にエンジニアとしてもリモートで的確な指示で情報を集めて切り分けできるの、力量の差を思い知らされた。 人、技量共に感銘を受けました。 実は僕は以前、OFF TOKYO2017というイベントでお会いしたことがあって、その時の印象は目が神々しいという印象で

今日も9時過ぎに出社。昨日負けたところは早々と修正できた。 日常です pic.twitter.com/FL9JoZ7wTt — まつもとりー / Ryosuke Matsumoto (@matsumotory) May 9, 2018 いるだけで改善される ngx_mruby v2 https://t.co/9wGlpkx26H — Uchio Kondo🦑 (@udzura) May 9, 2018 そこからは別の問題の修正しつつ、メンバーと1on1したりしてたら22時近くなったので、帰ってきてジョギング。 福岡久し振りに晴れ。スッキリぽよ。 pic.twitter.com/Zkjeq0Rk4S — P山 (@pyama86) May 9, 2018 久しぶりに体動かしてとても気持ちよかった。走りながらふと考えてたんだけど、僕どうやってコードかけるようになったんだっけって思うと、元々ペ