はてなブックマーク

ブログを書くまでが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でやってたので勉強に自信があった自分が、段々勉強が難しくなって文系科目で成績を落とし始め

最近一部の界隈でWordleという英単語当てゲームが流行っています。 www.powerlanguage.co.uk 5文字の英単語を最大6回のチャンスで当てるというシンプルなゲームです。ただし適当な文字を打ち込んでも存在しない英単語だと弾かれます。1日1単語が出題されるため、SNS上でシェアしあって楽しむことができます。 Wordle 215 4/6 ⬛🟨🟨⬛🟩 ⬛⬛⬛⬛🟨 🟨🟨🟩⬛🟩 🟩🟩🟩🟩🟩— すてにゃん (@stefafafan) January 19, 2022 初手で使う単語は何が良いのか 適当な単語を入れるとあってる文字もしくは位置が違うけど合ってる文字は色がついてヒントとして使えます。（逆に完全に外れている場合は黒色になるのでそれはそれでヒントとなります）。 ということは、初手で使う単語はこのヒントが最大限得られる単語を使えるとお得です。同じ文字

こちらはMackerel Advent Calendar 2021の12日目の記事です。 先日以下のような記事を書いたのですが、Mackerel Advent Calendarを今日みたら空きがあったのでついでにMackerel向けの拡張もさっと作ってみました。 （VS Codeの拡張作りに関する話は以下のエントリに色々書いてるので興味あればこちらもよろしくお願いします）。 stefafafan.hatenablog.com 「式グラフ」とは Mackerelでは実験的機能として、式を書いて既存のメトリックの値を組み合わせて、グラフを作ることができます。 mackerel.io また、同じ「式」を利用して、監視も行うことができます。 mackerel.io おすすめな使い方などについてはこのエントリが参考になると思います。 mackerel.io 式を書くのがちょっと難しい 上記の式ですが

このエントリははてなエンジニアAdvent Calendar 2021の10日目の記事です。今回はVisual Studio Code向けの拡張を作った話を書きます。 拡張の様子 はてな記法そこそこ使っている 自分ははてな社員というのもあり、自社のサービスをちゃんと使っておきたいという気持ちで個人ブログもはてな記法モードで書いています。 ただ普段コード書くときはVS Codeで書いており、VS Codeは現状はてな記法で書かれた文章は認識してくれないので、中々手元で書くモチベーションがあがらない。 また、VS Code拡張作ってる人々が周辺にいたので自分も作ってみたいかもと数日前に突如思い立ちました。 ということで作った 作りました。いますぐインストールしましょう。 marketplace.visualstudio.com ソースコードはこちらです。 github.com 見どころ 見どこ

最近社内の自分が所属しているチームで会議体を見直して「教科書的なスクラム」に近づけようとしている。そんな中表題のようなことを思うようになり、社内のグループウェアで書いてたのをついでにここにも書いてみる。 スクラムイベントというのは5つの要素があって、簡単に説明すると以下のようなものです。 スプリント (以降の4つのスクラムイベントを包括するイベント) スプリントプランニング (スプリントで達成するものを計画する) デイリースクラム (毎日決まった時間でやる定例、お互いの困りなどを聞いたりして、相談にもっていく) スプリントレビュー (スプリント中達成できたものを発表) スプリントレトロスペクティブ (スプリントごとの振り返り) この中で1番大きな期間を持つものが「スプリント」で一般的には1週間～1ヶ月のスパンだと言われているらしい。つまりどういうことかというと、スプリントの中で集中して仕事

2021年現在、スクラムガイドを参照したい場合は最新の2020年のスクラムガイドを読むことになります*1。このスクラムガイド、初出が2009年頃で数年置きに改訂されており、公式サイトから差分が確認できます。 scrumguides.org 一方で、初見で突然この差分のページを読んでもちょっとむずかしいと感じたので時系列ではなくテーマ別に整理してみようと思います。適当に日本語にしたり英語のままだったりしますが読みづらかったらすみません。以下の記事も参考になりました。 www.scrum.org Sprint Planning Release Planning (2010) → 必須ではないため削除 (2011) Sprint Planningで積んだ仕事を必ず終えることにcommitする (2010) → Sprintで終えられそうな仕事をforecast(予測)する (2011) 2つのパ