はてなブックマーク

最近職場でTypeScriptを書いていて、改めて周辺知識のキャッチアップがしたくてオライリーから出ている比較的新しい『初めてのTypeScript』を読みました。 全体としてはJSの基本知識がある人や他の言語での経験があるけどTSの細かい機能や慣習が知りたいという方におすすめできると感じました。原著の発行は2022年6月のようなので、めちゃくちゃ最近の話題に追従しているわけではないかもしれないけど、訳注で最近の事情がちょくちょく書かれていたりとてもありがたかったです。 公式サイトに章ごとに対応した課題があって、これらは英語だけど型を扱うことやTSでコードを書くことの練習になるので非常に有益でした*1。 www.learningtypescript.com 「anyを使いたい場面はなるべくunknownを使いましょう」とか「TSConfigのこういうオプションは基本的に有効にしておきましょ

Mackerel Drink Up 出張版＠福岡に参加してきた #mackerelio - stefafafan の fa は3つです に続いて、翌日福岡で開催されたRoad to SRE NEXT@福岡に参加しました。 sre-lounge.connpass.com Road to SRE NEXT とは？ 元々SRE NEXTという東京で開催されている大きめのイベントがありますが（自分はまだ参加したことはありません）、東京にとどまらず地方のSREコミュニティも活性化したいというものだそうです。 blog.sre-next.dev 「Road to SRE NEXT」は、SREの普及とコミュニティの活性化を目的としたイベントシリーズです。このイベントは、SRE NEXT 2024の運営メンバーによって計画されています。イベントの主な目的は、地方におけるSREコミュニティの発掘と支援、SR

情報のインプットについてたまに悩んでいて、しばらくRSSリーダーとして Inoreader を使ってみていましたが、最近「個人SlackにRSSフィードを流す方式」に戻しました。日々仕事も趣味もSlackやDiscordを眺めているので、そのままの体験でニュースを追うことができるのは個人的に便利です。 個人SlackにRSSを流すためのTips 基本的にはRSSフィードのURLを /feed subscribe URL で登録するだけですが、他にもいくつかTipsがあるので紹介します。 まず特定のGitHubリポジトリのリリース通知を受け取りたいケース。 GitHub Slackアプリの /github subscribe コマンドで releases に購読する方法はありますが、たまに自分が管理していないリポジトリだと権限が足りずに購読できないことがあります。その場合はリポジトリの /r

PHPカンファレンス小田原2024に参加してきました！感想のブログを書きます。 phpcon-odawara.jp 参加するまでの経緯 自分はPHPを書いたことはなかったですし、今まではてなやカケハシでの仕事でもPHPを書くことはありませんでした。PHPカンファレンスは去年のPHPカンファレンス福岡2023に参加したのが初めてで、そのときも「福岡に引っ越したら家の近くで大きめな技術イベントをやっているっぽい。面白そうだからいってみよう〜」くらいの感じで参加しました（前前夜祭で登壇もしました）。 blog.stenyan.jp PHPカンファレンス福岡2023は本当に楽しくて、コロナ禍入ってから大きめなカンファレンスに全然参加してなかったのもあるかもしれませんが、これはPHP書いたことない人でもみんなPHP系のイベントに参加したら絶対楽しいはずと思いました。当日の発表を聞くのもそうですし、連

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

すてにゃん Advent Calendar 2023 というのを一人で開催していたが、2023年には終わりきらなかったどころか、その後こっそり記事を登録していって、3月にやっと終わった形になってしまった。ここでは原因と今後の対応について考えたい。 状況 12/9 頃までは、基本的に1日遅れくらいの状態で記事を投稿していた 個人ブログの記事をGitHubで管理するようにした - stefafafan の fa は3つです 12/10 の記事はさらに遅れて 12/19 に投稿された Fukuoka.go #19 Reboot に参加した #fukuokago - stefafafan の fa は3つです 12/13 の記事でさらに遅れが広がって 12/29 に投稿された エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の

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にも書いてあったようなことを元に軽く紹介します。 課題内在性負荷とはタスクに直接関連する負荷であり、プログラミング言語そのものの知識などを含むそうです。 課題外在性負荷とはそのタスクというよりは周りの環境に関連する負荷であり、覚えにくいコマンドの羅列だったりするそうです。

Go Conference mini 2023 Winter IN KYOTO というイベントに参加して、表題のGoサブ会について発表しました。 speakerdeck.com Goサブ会設立までの経緯について大体資料に書いてありますが、そもそも自分がGo言語への関心が高まっている背景も少し書いておこうと思います。 自分は2015年にはてなに入社して、最初はMackerelチームに所属していたため当時からGoを書いていました。またこのあたりではてな東京オフィスをGoのリリースパーティ会場として活用したりしていたので、Goに対する「やっていき」がありました。 チーム異動して今度はPerlを書くようになり、Goは一旦触る機会が減りました。Perlは古い言語ではありますが色々と便利ではあるし、YAPCなどのコミュニティも温かくてとても好きです。仕事で書かなくなったGoからは一時的に離れちゃいまし

私はいま会社でテックリードをしていますが、いちエンジニアとして技術的改善をチームに提案するスキルに関してまだ課題感を持っています。その際同じくチームに所属しているエンジニアリングマネージャー（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の自分のターンが終わってほしいな」という気持ちでもんもんとしながら当日を迎えました。スライドにはあまり文章を多く書きすぎないことを意識してその場で話すようにはしたけど、そもそもマイク

最近社内でRedashを利用している。色んなデータソースにたいしてクエリを書くことができて便利です。 redash.io ただ、たまに数字の出力で精度について気になることがあるのでブログにまとめておきます。 前提: Redashを開いているタブで開発者コンソールからネットワークの様子をみるとAPIからの結果が確認できる 桁数の多い数字の場合の誤差 小数点2桁までで丸められる件 Edit Visualization で小数点の桁数を変更しても、十数桁以上から結果がずれる 終わり 前提: Redashを開いているタブで開発者コンソールからネットワークの様子をみるとAPIからの結果が確認できる まず前提として開発者コンソールを開いている状態でRedashのクエリを実行すると、APIが叩かれて結果が入っていることを確認できます。これを利用することによってAPIからの結果が丸まっているのか、表示時に

これまで記事を書くのにはてなブログを使ってきましたが*1、これとは別に英語で技術記事を書くためのブログを用意したい気持ちになりました。Mediumが使われがちですがせっかくならAstro試してみたいなと思って今回試しました*2。以下がとりあえず完成した英語専用のブログです。 blog.stenyan.dev やったこと AstroPaper というテーマがあったので、GitHubのテンプレートからリポジトリを生成 Vercel に登録して、先ほど作ったリポジトリを連携 独自ドメイン登録するために、VercelからCNAMEの値を取得してDNSに登録 あまりにも簡単ですごい。 感想 Astro Astroで作られたサイトは素早いという噂だけど確かにパフォーマンスは良くてありがたい (もちろん現時点の私のサイトはたいした画像もなく内容も少ないですが)。 blog.stenyan.dev の P

Composite Actions を触っていたところ、 Reusable Workflows との違いが分かりづらいと感じたので自分の中で考えた使い分けについて整理してまとめてみました。 使い分けイメージ Composite Actions Reusable Workflows 使い分けイメージの根拠 みなさんの使い分けや Tips も教えてください 参考 使い分けイメージ Composite Actions リポジトリ内の「この一連の steps をよくやってるな」というのを部品として切り出したいときに使うと良い Custom Actions を自作する際に、 JavaScript Action や Docker Container Action を1から作る前に Composite Actions でできないか検討すると良い (yamlを1つ用意するだけでハードルが低いため) Reu

あけましておめでとうございます。『UNIXという考え方―その設計思想と哲学』という本を読んでいたら年越していました。 この記事は はてなエンジニア Advent Calendar 2022 の 1月1日の記事です。*1 昨日は id:tkzwtks による コーポレートサイトドメイン引越しの裏側 - Hatena Developer Blog でした。 今回は表題の本を今更ながら読みましたので、感想を軽く書きます。 この本で紹介されている9つの定理 設計思想に関する定理 開発プロセスの話 細かい手法の話 全体的な感想 この本で紹介されている9つの定理 この本では以下の9つの定理が紹介されていました。 スモール・イズ・ビューティフル 一つのプログラムには一つのことをうまくやらせる できるだけ早く試作を作成する 効率より移植性 数値データはASCIIフラットファイルに保存する ソフトウェアの梃