2017年に以下の記事を書いていました。最近も時々この記事が引用されたりX (Twitter) でもいまだにシェアされたりしているのを観測しています。 blog.stenyan.jp なおこれはもはや7年前の記事で、ベースの考えは大きくは変わっていないものの、普通に自分用のチャンネルをいまは作っています。 運用次第で良し悪しある まず結論としては、チャンネルを作ったほうが良いとか作ってはいけないということよりも、使われ方（運用）方法次第で上手く回らない可能性があるよねという話だと思っている。なので、Xなどでtimes不要論が流れてきても「結局どう運用しているか次第だな〜」とニュートラルよりな気持ちで静観している。 例えば以下のような運用の場合はひょっとすると見直した方が良いかもしれない。 チームのチャンネルでは基本的に何も書かずに、自分の分報に仕事に関する考えや思いを書き続けている→チーム

yapcjapan.org 前夜祭からアフターイベントまで全部参加しました。楽しかったです。プロポーザルも出してはいたけど落ちちゃったので、またの機会に出直したいです。 イベントもトークもどれも最高だったのは言わずもがなという感じなので、トークの合間の「廊下」とか懇親会で話した話題について書こうと思います。 退職・転職話 自分が 株式会社はてなを退職します - stefafafan の fa は3つです という記事を先日公開したところというのもあり、退職おつかれさまでしたとか次の会社はどこですかみたいな話を何人かにされました。初めての退職なのでこういう風に話しかけられることも新鮮な気持ちでした。 印象に残っていることははてなOBに言われた「すてにゃんが思っている以上に、はてなのコードのベースレベルは高いので、もしかしたら他の会社にいくとギャップに驚くかもしれない」的なことですね。確かにはて

2024年1月31日を最終出社日として、新卒から8年半ほど勤めていた株式会社はてなを退職します。次の会社は決まっていますが、そちらについては入社エントリでお話しします。 はてなでの思い出 サーバー管理・監視サービス「Mackerel」 出版社向けWebマンガビューワ「GigaViewer for Web」 マンガ家向けWebサービス「マンガノ」「ジャンプルーキー！」 ソフトウェアエンジニアとしての発信 退職を決意した理由 今後が楽しみ はてなでの思い出 社内でいくつかのプロダクトに関わらせていただきました。「Webアプリケーションエンジニア」という職種でサーバサイドやフロントエンドのコードを書いたり、TerraformやAWS CDKのコードを書いたり、時にはスクラムマスターやテックリードなどもしてきました。「はてなブログ」のような社名を冠したサービスには結局携わらないまま転職することにな

株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki

現役はてな社員ということもあり、ドッグフーディングの意味も込めてずっとはてなブログを利用してきました。ブログを書く時は基本はてなブログの記事編集画面から直接編集してきましたが、このたび公式でGitHubテンプレートリポジトリが公開されていたので使ってみることにしました。(自分ははてなブログチーム所属ではありませんが、株式会社はてなのエンジニアなので宣伝記事ではあります)。 staff.hatenablog.com セットアップについて 基本的にリポジトリのREADMEに書いてある通りぽちぽちしていれば簡単に記事を全部リポジトリに同期できて非常に楽でした。記事の同期の際に下書きエントリも公開状態になっちゃうのかと少し気になりましたが、そこは初期セットアップの際に下書きも取り込むかどうかのフラグがあったので安心ですね。 github.com なお、自分はWebアプリケーションエンジニアであり日

以前会社で「Team Topologies読書会」に参加した際に、認知負荷には3つの種類があることを知りました。それ以降新しいメンバーのキャッチアップについて考える際に毎回この3つの種類について思いを馳せるようになっています。 チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon 心理学者ジョン・スウェラーが提示する三つの種類とは「課題内在性負荷」「課題外在性負荷」「学習関連負荷」です。Team Topologiesにも書いてあったようなことを元に軽く紹介します。 課題内在性負荷とはタスクに直接関連する負荷であり、プログラミング言語そのものの知識などを含むそうです。 課題外在性負荷とはそのタスクというよりは周りの環境に関連する負荷であり、覚えにくいコマンドの羅列だったりするそうです。

同僚が1on1の際に他の人がどういう話をしているのか気にされていたので、便乗してブログに書きます。 ということで人が1on1の時間に何を考えてどう使っているのか気になっている1on1で何を話すか考えてる - tomato3713’s blog 前提 株式会社はてなは新卒から所属しており、今年で9年目 現在チームでテックリードをしている。Webアプリケーションエンジニアとしてコードも日々書いている とはいえ自分もメンティーは持っていなくて、1on1してもらう側の1人 最近1on1に向けて考えていること 前提に書いてある通り、自分はこの会社では古参で普段の仕事の仕方だったり同僚とのやりとりやカルチャーについての大きな悩みや不安はないです。その代わり、テックリードや30歳になったエンジニアとしての悩みや考えはあります。ということで以下のようなことを考えています。 テックリード どのような振る舞い

私はいま会社でテックリードをしていますが、いちエンジニアとして技術的改善をチームに提案するスキルに関してまだ課題感を持っています。その際同じくチームに所属しているエンジニアリングマネージャー（EM）の方にヘルプしていただき、実際に提案資料をペアライティングした中で湧いたイメージがあるのでブログとしてまとめて自分の考えを整理してみようと思います。 効果的なストーリーテリングのための既存のフレームワーク 技術的な提案をするには効果的なストーリーテリングをするスキルが必要だと考えています。私はストーリーテリングに関して詳しくありませんが、仕事を通じて以下の二つのフレームワークを知りましたので軽く紹介します。世の中には他にもいろいろあると思いますが、基本的な考え方は近いのかなと想像しています。 空・雨・傘 STARフレームワーク 空・雨・傘 EMの方と会話する中で「空・雨・傘」というフレーズを何度

OSSへのちょっとしたコントリビューションに成功したので、どういう流れでコントリビュートしたのかブログに簡単に流れをまとめてみようと思います。OSS活動してみたいけどどういう流れでやれるのか気になっている方の参考になれば幸いです。なお今回の修正Pull Requestはこちらです。 github.com 経緯 GitHub App の権限で Songmu/tagpr を利用する - stefafafan の fa は3つです とかにも書いたのですが、個人的に作ったライブラリにこちらの Songmu/tagpr を導入したら便利になったので、そのままはてなで運用している以下のリポジトリとかでも使ってみてはどうかとブログチームの方に紹介しました（自分はブログチームではないのですが、Slackの雑談チャンネルでおもむろに紹介しました）。 github.com このあと軽くウォッチしていたら、なぜ

最近少しずつ技術系のイベントでの発表機会を増やそうとしています。その中で、大きめなイベントだとまずCall for Proposals (CfP) という、プロポーザルを出したらそれによって選考が行われ実際に発表できるかどうかが決まる制度があります。ここで出したプロポーザルは必ずしも通るわけではないですが、出さない限り発表はできません。 プロポーザルを出すためにネタがないといけませんが、最近自分は「完璧な資料やアウトラインはないけども、当日までにまとめることはできそうだな」という感じのものをプロポーザルとして出したりしています。 具体的には、 Go Conference mini 2023 Winter IN KYOTO では、自分が社内でチーム横断の「Goサブ会」という職能グループのオーナーをやっているのでその話についてのプロポーザルを出しました YAPC::Hiroshima 2024

Go言語でsliceの重複排除について書きます。Go 1.21前提です。 slices パッケージを使っての重複排除 Go 1.21から slices パッケージが増えました。ここに生えている関数を利用して重複削除のコードが書けます。 pkg.go.dev 例えば int の slice の重複排除は以下のように書けます。 integers := []int{1, 2, 2, 1} slices.Sort(integers) // [1 1 2 2] uniqValues := slices.Compact(integers) // [1 2] slices.Compact は連続する値を1つにまとめる関数なので、重複排除したい場合は slices.Sort で先にソートする必要があります。 User という struct の slice を id で重複排除したい場合はどうすればいいかと

弊チームではGitHub ActionsからGoogle Cloud Runにアプリケーションをデプロイしてプレビュー環境として利用しています。具体的な構成などについては以下の記事をご参照ください。 developer.hatenastaff.com 先日、内部で使われているGoogle CloudのCLI gcloud のバージョンが上がったことによりこの環境が正常に動かなくなって困った事例があったので、今回これを機にバージョンを固定することにしました。 gcloud のバージョンが上がってどのように壊れたのか 445.0.0 (2023-09-06) から 446.0.0 (2023-09-12) に上がった結果以下の Issue Tracker にあるような挙動の変化がありました。 https://issuetracker.google.com/issues/300221542 弊チ

社内向けに周知を書いてたけど、そのままパブリックにも書けばいいかとおもって書きます。関連エントリ: aws.amazon.com gs2.hatenablog.com 概要 AWS Lambda Function を Go1.x Runtime で動かしている場合は、2023/12/31に非推奨になるので対応しましょう 厳密には Deprecation Policy の Phase 1 の状態 になります。セキュリティパッチなどのアップデートがこなくなり、新規作成もできなくなります (既存のFunction はそのまま利用可能） なお、Phase 2の「既存の関数の更新もできなくなる」のは 2024/1/30 となります（こちらはAWSより届いたメールに書いてありました）。 影響の有無の確認 以下のいずれかの状態のLambda Functionが対象となります。 .zip file の形式

仕事でGoを書いているので参加しました！ gocon.jp LT落選 実はLTを申し込んでいましたが落ちています。社内で「Goサブ会」というチーム横断の会をやっていて自分が運営メンバーの1人ということでついでに話そうかなと思って応募してみましたが、これはまた別の機会に話そうと思います。 github.com 当日 今回GoConで採用されたrebakoはあまり使ったことがなかったのですが、すぐ慣れました。YouTube Liveだけで配信するよりはアイコンが沢山並んでいて盛り上がっている感は感じられてよかったです。特に2つの部屋で同時並行で進んでいるときはタブを切り替えるよりは部屋移動している感じがでていました。 発表はどれも面白くて、無限に情報インプットできました。参加してよかったです。またあとで自分が聞けなかった部屋の資料も目を通そうと思います。海外の人もオンラインならそのまま発表を配

English translation of this post: GitHub Reusable Workflows vs. Composite Actions | stefafafan's tech blog Composite Actions を触っていたところ、 Reusable Workflows との違いが分かりづらいと感じたので自分の中で考えた使い分けについて整理してまとめてみました。 使い分けイメージ Composite Actions Reusable Workflows 使い分けイメージの根拠 みなさんの使い分けや Tips も教えてください 参考 使い分けイメージ Composite Actions リポジトリ内の「この一連の steps をよくやってるな」というのを部品として切り出したいときに使うと良い Custom Actions を自作する際に、 JavaScr

English translation of this post: Read the book "The UNIX Philosophy" | stefafafan's tech blog あけましておめでとうございます。『UNIXという考え方―その設計思想と哲学』という本を読んでいたら年越していました。 この記事は はてなエンジニア Advent Calendar 2022 の 1月1日の記事です。*1 昨日は id:tkzwtks による コーポレートサイトドメイン引越しの裏側 - Hatena Developer Blog でした。 今回は表題の本を今更ながら読みましたので、感想を軽く書きます。 この本で紹介されている9つの定理 設計思想に関する定理 開発プロセスの話 細かい手法の話 全体的な感想 この本で紹介されている9つの定理 この本では以下の9つの定理が紹介されていました。 ス

この記事ははてなエンジニア Advent Calendar 2022の29日目の記事です。*1 昨日は id:koudenpa による 破棄し忘れたクラウドリソースに半年間金を払い続ける方法 - koudenpaのブログ でした。 今回は私のはてなエンジニアとして個人的に意識していることを一部紹介します。*2 ソフトウェアエンジニアとしての働き方 新しい概念を発明するのではなく社内外にあるものをもとに検討する 業務で利用しているOSSについて自分が気になった箇所・ハマった箇所は他者も気になっているはずなので issue を探したり、なければ自分で立てたりPull Requestを出す 自分がハマった箇所や解決した方法については社内外に公開する リモートワーク時の振る舞い 何事もテキストとして残す オンライン上の存在感を高める 終わりに ソフトウェアエンジニアとしての働き方 新しい概念を発明

このエントリは Mackerel Advent Calendar 2022 および GitHub Actions Advent Calendar 2022 の20日目の記事です。*1 今回はMackerelのサービスメトリックを投稿するためのGitHub Actionsを新規で作ったのでその紹介をします。 GitHub Actions経由でメトリクスを簡単にMackerelに投稿したい 既存のGitHub Actions yutailang0119/action-mackerel-api susisu/setup-mkr 自分のユースケースでの気になり stefafafan/post-mackerel-metrics の紹介 実際に活用している事例 テクニック紹介: 他のStepからMultiline Stringの受け渡し 初めて作ったGitHub Actionについての感想や困りなど

去年認定スクラムマスターになって、実際に自分の開発チームにScrumを導入したり、最近ではチーム内でテックリード交代して開発プロセスの高速化についてより考えるようになってきた。 Agile, Lean, XP, DevOps, Four Keys, Team Topologies など様々なフレーズを見かけたり本を読んだりしたところ大体皆同じ場所を目指していると感じるけど、イマイチ自分の脳内インデックスが貼れていない気がしたのでこのエントリで軽く考えを整理してみようと思う。 とにかく改善のサイクルが回っていない (ソフトウェア開発に限らない) 開発速度が上がらない (ソフトウェア開発者側) Extreme Programmingのプラクティス DevOpsのプラクティス チーム内での連携が上手くいっていない チームの構成がイマイチ・他チームとの連携が上手く取れていない まとめ とにかく改善

たとえばGoで書かれているプロダクトのCIをGitHub Actionsでやっていて、Goのバージョンがあがるたびにこのファイルを毎回ちまちま更新しているとあまり面白味のない作業になってしまう。最近だとGo 1.18 から 1.19 にあげるときに以下の go-version に書いてる数字を 1.19 にあげる必要があった。 steps: - uses: actions/checkout@v3 - uses: actions/setup-go@v3 with: go-version: 1.18 - run: go version actions/setup-go@v3.1.0 からは go-version-file に go.mod のパスを指定することによってそこからバージョンを取得して使ってくれるようになった。便利。 .go-version にも対応しているようです。 github.