はてなブックマーク

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

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

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つの部屋で同時並行で進んでいるときはタブを切り替えるよりは部屋移動している感じがでていました。 発表はどれも面白くて、無限に情報インプットできました。参加してよかったです。またあとで自分が聞けなかった部屋の資料も目を通そうと思います。海外の人もオンラインならそのまま発表を配

ブログを書くまでがYAPCということで書いていきます。 yapcjapan.org 前日祭 前日祭から参加しました。 yapcjapan.connpass.com 自分ははてな社員だし、もっと登壇とかしていきたいしということでYAPCにプロポーザルを出したのですが残念ながら採択されず、その代わり急遽開催が決まった前日の Reject Con で話せることとなりましたという経緯です。ありがとうYAPCスタッフ各位、そして id:papix 氏！ blog.yapcjapan.org ということで、この週は仕事しつつ Reject Con の登壇資料も用意しつつで結構落ち着きがなく、正直「はやくReject Conの自分のターンが終わってほしいな」という気持ちでもんもんとしながら当日を迎えました。スライドにはあまり文章を多く書きすぎないことを意識してその場で話すようにはしたけど、そもそもマイク

English translation of this post: I've created a new tech blog using Astro and Vercel | stefafafan's tech blog これまで記事を書くのにはてなブログを使ってきましたが*1、これとは別に英語で技術記事を書くためのブログを用意したい気持ちになりました。Mediumが使われがちですがせっかくならAstro試してみたいなと思って今回試しました*2。以下がとりあえず完成した英語専用のブログです。 blog.stenyan.dev やったこと AstroPaper というテーマがあったので、GitHubのテンプレートからリポジトリを生成 Vercel に登録して、先ほど作ったリポジトリを連携 独自ドメイン登録するために、VercelからCNAMEの値を取得してDNSに登録 あまりにも簡単ですごい

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つの定理が紹介されていました。 ス

最近Androidで一部のサイトのツイートボタンを押したら「入力した単語の検索結果はありません」というエラーとともに前の画面に戻されシェアに失敗することがある。この件について軽く調査・検証してみる。 注意: 2022/12/30 時点の検証なのでまた仕様は後ほど変わる可能性が大いにあります。 いつ頃から発生しているのか この文言そのままでツイッターを検索してみる。 twitter.com 見たところ 2022/12/16 あたりでシェアしようとしてこの表示がでるとつぶやいている人がいます。これより前にこのエラーを見てる人もいますが、また別の原因のようです（ユーザページを開こうとしてこれが表示されるなど）。具体的にいつからというのはここからはわからないが、2022年12月から頻発してそうということはわかります。 いくつかのパターンのツイートボタンを埋め込んで試す ブログにはHTMLが書けるの

この記事ははてなエンジニア 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のプラクティス チーム内での連携が上手くいっていない チームの構成がイマイチ・他チームとの連携が上手く取れていない まとめ とにかく改善

github.blog という記事を今日みて、 echo "::set-output name=hoge::fuga" みたいなことをやってたのがdeprecatedになると知った。以下のドキュメントを参考に置換すればOKとのことだったので、せっかくなのでsedでやってみた。 https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter find .github/workflows -type f | xargs sed -i '' -e 's/echo "::set-output name=\(.*\)::\(.*\)"/echo "\1=\2" >> $GITHUB_OUTPUT/g' ちなみにはじめは sed -i

たとえば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.

Google Cloudに手でたてたリソースをTerraformに落とし込むときにterraformerみたいなツールを使ってみようと思ってググってたら公式ドキュメントに gcloudを使ったやり方が紹介されていたので試してみました。（ドキュメント曰く、GAになる前の機能なので、いずれ変わる箇所もありそうです）。 この記事ではその使い方や気になった箇所について軽く紹介します。 cloud.google.com Terraform形式になるように一括でエクスポートする Terraformにインポートするためのスクリプトを生成する 生成されたインポートスクリプトを実行する ハマり所・気になり所 bulk-exportコマンドで出力されないリソースがある bulk-exportコマンドでリソース指定でフィルターしたときにエラーが発生するリソースがある terraform plan したらエラーが

最近私は Firebase Authentication を利用したWebアプリケーションを開発しています。Pull Requestごとのプレビュー環境を用意しようとした際に表題の「承認済みドメイン」をどうするかがネックになり色々と調べて最終的にGitHub Actionsで対応したので、そのときわかったことなどをこちらの記事に書きます。 承認済みドメイン (Authorized Domain) とは 今回の困りごと 世間の様子 作戦 実装 認証周り APIを叩く jq 技を使う GitHub Actions 完成系のGitHub Actions 承認済みドメイン (Authorized Domain) とは Firebase Authenticationを利用すると、「メール・パスワード」「Google認証」「Twitter認証」などなど色々な方式でのアカウント登録周りの認証を実現できま

我々も「スクラム」やるぞ！と言われても、イマイチどうしてスクラムでやりたいかが伝わっていないことがあると思います。あまり乗り気でない開発者は以下のようなことを感じているかもしれない。 スクラムを導入したところで嬉しさがわからない スクラム独自の用語が沢山あり、覚えるべき概念が多そうに感じる・学ぶための労力が割にあわないと思っている そもそもチーム改善とかに興味がない 改善に興味がなかったら厳しそうですが、スクラムを導入する嬉しさは簡単にでも紹介できたほうが良いと思うのであらためてちょっと整理してみます。 そもそもどういうことができているチームが優秀なチームかというのを考えると 以下のようなことができていると、優秀なチームなのかなと私は考えています。 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている） タスクが急遽差し込まれたり、方針が変わったときにスムー

最近チーム用にGASとclasp (CLIで操作できるようになるツール) で Slack bot を作りました。今回そのbotの話はしませんが、bot作ってわかった細々としたことを軽くまとめて共有します。 Google Apps Script 毎日分単位で特定の時刻に発火してほしい場合はスクリプトからトリガーをセットすると良い 日本の祝日は動かないようにしたい場合は祝日カレンダーを使うと良い clasp 変更を素朴にデプロイし続けるだけでは足りず、バージョンの切り替えも必要 clasprc.json のcredentialsをGitHubのRepository Secretsに登録しておけば、mainブランチにマージ = デプロイを実現できる Slack ユーザに対してメンションを送りたい場合はSlackのMember IDが必須 Layout blocks を使うと綺麗に文章をフォーマッ

id:Songmu さんの以下のエントリを読みました。自分も読んでいて共感できるところあったので、はてなブックマークのコメントに一瞬書きかけたけど、せっかくならブログに書こうと思い書いてみます。 songmu.jp 自分の性格 自分は元々上昇志向がある方だと思う。難しい議題に挑戦してコツコツとがんばった結果良い成果を出せるような人間だと思っている。というかそうであると自分自身勝手に期待している。 あと、自分は常に勉強とか仕事とかで中の上以上にいる、もしくはいるべきだと思ってしまっている。常にというのは、学生時代から社会人になったいまもという意味。 一方で何かが上手くいかなかったらわりと自分自身が責任を感じるし、周りのメンバーが滅入ってると自分も滅入る。 苦しかった事例 高校生時代*1は、元々中学オール5でやってたので勉強に自信があった自分が、段々勉強が難しくなって文系科目で成績を落とし始め