GitHub プロフィールを作る

概要

気になってた、GitHub のプロフィールカードを作ってみた。

出来上がりはこんな感じ。

f:id:su-kun1899:20210111225645p:plain

作り方

Managing your profile README - GitHub Docs

ここに載ってる。

ユーザー名と同じ名前で public リポジトリを作ると、 README に書いた内容が自分のプロフィールに反映されるようになる。

Activity を画像にして載せる

github.com

github-profile-summary-cards を使うと、よく使ってる言語とかを画像でビジュアライズして載せられる。

Add to my profile README · vn7n24fzkq/github-profile-summary-cards Wiki · GitHub

手順は Wiki にある。

workflows を作って、 GitHub Actions で実行すると画像が生成されるので、出来上がったファイルを README.md で読み込ませれば良い。

ちなみに定期実行になっているので、先々の活動も勝手に反映してくれそう。

private リポジトリの内容も反映させる

Includes commits and top language stats for private repos. · Issue #5 · vn7n24fzkq/github-profile-summary-cards · GitHub

private リポジトリの内容も読み込ませる方法は上記 Issue から辿れる。

Personal Access Token を発行後、それを yml で使うようにして再実行すればOK。

必要な権限についても Issue で言及されている。

参考

simple-minds-think-alike.hatenablog.com

リモート環境下におけるスクラムイベントのちょっとした工夫 #リモートワーク #scrum #スクラム

これは コネヒト Advent Calendar 2020 5日目 の記事です。

はじめに

コロナの影響もあり、現在は在宅勤務が中心になっています。

コネヒトの開発チームはスクラムを採用していますが、スクラムイベントもリモートで行うようになりました。

この記事ではリモート環境のスクラムイベントを効果的にするために僕らが行っている工夫をいくつか紹介しようと思います。

デイリースクラム

工夫: スピーカーのバトンパス

デイリースクラムは順々に話していく形式が多いと思います。

オフラインであれば並んでる順に自然と話せばいいですが、ビデオ会議だとイマイチスピーカーの順番が定まりません。

またオフラインに比べて、「話し終わったのかどうか」を意外と察しづらい問題があります。

とても小さな工夫なのですが、話終わったあとに次の人にパスを渡します。

「次は○○さん、お願いします」

自分の話が終わったら、これを言うだけでスムーズに進行していきます。

f:id:su-kun1899:20201205230801p:plain

スプリントレビュー

工夫: 自由参加にする

オンラインのビデオ会議のいいところは、場所の物理的な制約を受けないところです。

会議室に入れる人数は限界がありますし、オープンスペースであってもデモが遠くだと見えづらかったりもするでしょう。

僕らはレビューの開始前に、全社員がいる Slack チャンネルでアナウンスし、 Zoom のリンクを共有しています。

f:id:su-kun1899:20201205230637p:plain
お知らせの様子

スプリントレトロスペクティブ

工夫: チェックイン

オンラインのビデオ会議は、良くも悪くも複数人が同時多発的に会話するようなコミュニケーションには向いていないと思います。

そのためレトロスペクティブのような場では、ひとりひとりの発言機会やその時間がオフラインに比べて短くなりがちです。

そこで僕らはレトロスペクティブの最初にチェックインを行っています。

簡単な質問をひとつ用意し、それに対して全員がひとことずつ回答します。

  • このスプリントを天気で表すと?
  • このスプリントは前のスプリントに比べてよかった?悪かった?
  • このスプリントで一番がんばったことは?
  • etc

最初に全員が一度発言することで、参加意識が高まっていきます。

チェックインの詳細については「アジャイルレトロスペクティブズ」という書籍で紹介されています。

バックログリファインメント

工夫: 司会は開発者

これはリモートに限ったことではないですが、リファインメントの司会は開発者(の代表者)が行っています。

以前はプロダクトオーナーがバックログアイテムを説明することが中心でした。

プロダクトバックログについては当然プロダクトオーナーの方が詳しいですが、司会進行をある意味「詳しくない側」である開発者が行うことで、不明点や懸念点を顕在化しやすくしています。

スプリントプランニング

工夫: 一度解散、そして集合

開発チームは機能横断で構成されていますが、メンバーの中では当然専門領域が異なります。

そのためプランニングでは大枠のスプリントゴールを確認したあと、大きく2つのチーム( Native アプリチームと Web チーム )に分かれて細かいタスク出しや見積もりを行っています。

ただそのままだと作業の優先順位や完了目処の認識がずれたりする可能性があります。
(このAPIは早めにほしい、など)

そのため、両チームの見通しが判明したら、改めて最終的な認識合わせとスプリントゴールの調整を行うようにしています。

おわりに

コネヒトの開発チームで行っている、スクラムイベントの工夫をいくつか紹介させていただきました。

スクラムはチームの状況により細部のやり方が大きく変化するものだと思います。

この記事で紹介した工夫が、少しでも誰かのヒントになれば幸いです。

明日は nkuroda さんです。

qiita.com

(追記) イベントやります!

コネヒトでは12/17にオンラインイベント開催予定なので、ぜひ参加してみてください!

connehito.connpass.com

「入門監視」を読んだ

入門監視を読んだ

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

最近仕事で、アプリケーションのアラート周りの整理をしている。

一緒にやってる同僚がこの本の読書会を社内で企画して、せっかくなら読んでみようと思ったのがきっかけ。

アンチパターンがまとまっている

SQLアンチパターンなんかもそうだけど、「こうするといいよ」以上に「これはやめとけ」がまとまっている方が実用的な気がする。

正解は割とコンテキストによっていつも違うけれど(というかない)、アンチパターンは割とどんな場合でも変わらないことが多いと思うから。

運用も含めて学べる

何をどう監視するか、ということも勿論丁寧に書いてあるんだけど、それを日々運用していったり、改善することをイメージできるように書いてあると思う。

アラートを仕込んで、じゃあアラートが飛んできたらどうするんだっけ?みたいなことを想像できる。

監視の起点

監視の起点がシステムというよりは、エンドユーザーとかビジネスKPIという感じで書かれていて、いいなぁと思った。

ツールは目的じゃないけど

ツールが目的にならないようにという警告をしているんだけど、一方で SaaS の活用を推奨している。

すごく同意できるなぁと思った。

OSのメトリクスはあんまり?

OSのメトリクスは直接的には何も分からないので、監視としては微妙というようなことが書いてあった。

それはそうだなと思いつつ、「何か起きている可能性がある」とか「何が起きているか分からないのでどこから調べるか」の大きなヒントになった経験があるので、大事にしたいなとは思うのだった。

たぶん相対的な重要度の話をしているのだとは想像しつつ。

難しいところもあった

難しくてわからないところもそれなりにあった。

たとえばネットワーク監視のあたりとか。

デファクトっぽいツールの紹介も聞いたことがなかったり。

インフラエンジニアの人だったら常識なのかなとか、オンプレだと結構身近なキーワードだったりするのかなとか。

まとめ

監視を起点にまとまった本は読んだことがなかったので、とても勉強になった。

入門監視 読書メモ · GitHub

Web API の JSON レスポンス等で、null を返すのかプロパティごと削除するのか

概要

表題の通りの疑問なのですが、個人的な結論は出ていないです。

返しても意味がないなら消してよいのではという意見

まぁそうだよねぇ、という気がする。

softwareengineering.stackexchange.com

required と nullable は同様に扱おうという意見

クライアントを混乱させるなってことっぽいけど確かに、という話。

でもどっちがいいとは書いてない。

opensource.zalando.com

感想

意味がない値なら返さなくていいかなー、という気がする。

そもそも null に意味をもたせるのは可能な限り避けたいし。

ただ配列の場合は空配列を返したほうがいいのかなって思う。

これは Effective Java なんかで言われてる、空のコレクション返すのと同じ理由。

AWS CLI v2 の Docker イメージで JSON が Parse Error になる #AWS #Docker

概要

AWS CLI を Docker Image 使って利用してみたのだが、出力に jq を噛ませたところ parse エラーになった。

出力に制御文字が入り込んでいるみたい?

tty オプションを外してみたら解消された。

動作環境

  • Mac OS 10.15.5
  • Docker for Mac
  • Docker version 19.03.12, build 48a66213fe
  • aws-cli/2.0.36 (Docker Image を使用)

AWS CLI のイメージを使う

docs.aws.amazon.com

公式に従って導入する。

認証情報の設定等はこの記事では省略。

下記のような感じでコマンドが叩ければ OK 。

$ docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli --version
aws-cli/2.0.36 Python/3.7.3 Linux/4.19.76-linuxkit docker/x86_64.amzn.2

長いので、 alias を設定しておく

alias aws='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

jq を噛ませると Parse Error が発生する

AWS CLIiam list-access-keys を実行する。

JSON 出力した結果を jq に噛ませたら Parse Error になってしまった。

$ aws iam list-access-keys | jq .
parse error: Invalid numeric literal at line 1, column 2

一度ファイルに出力して中身を見てみると、制御文字?っぽいものが紛れ込んでいた。

[?1h=
{[m
    "AccessKeyMetadata": [[m
        {[m
            "UserName": "xxxxxx",[m
            "AccessKeyId": "xxxxxx",[m
            "Status": "Active",[m
            "CreateDate": "2020-08-01T08:21:24+00:00"[m
        }[m
    ][m
}[m

[K[?1l>

tty オプションを外してみる

色々調べてみたところ、 tty が悪さをしているようで、改行コードが CRLF になっちゃっているみたい?

tty オプションを外してみると、制御文字が入らないようになった。

alias aws='docker run --rm -i -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

-it-i にしている

参考

GAS (Google App Script) の Moment.js の出どころを調べる #gas

概要

GAS でも Moment.js が使えるらしいが、どこもプロジェクトキーを書いてあるだけだったりして、出どころがよく分からない。

そもそもプロジェクトキーはサポートが終了したようなので、スクリプトIDを知りたい。

Moment.js の公式サイトや GitHub リポジトリにそれっぽい話はない。

Google が作ってるって書いてある人もいるけど、ホントか。。?となったので調べてみた。

あるサイトからスクリプト本体へたどり着く

public な GAS ライブラリをまとめているっぽいサイトを見つけた。

Moment - GAS Library Management (public)

Moment.js が Google の下にあるが、そもそもサイト自体ももうメンテナンスされていないようである。

ただ、ここからスクリプトの本体にはたどり着けた。

https://script.google.com/a/connehito.com/d/MHMchiX6c1bwSqGM1PZiW_PxhMjh3Sh48/edit?usp=drive_web

ライセンスとかも明記しているし、ちゃんとしている感。

バージョンは Moment.js 本体とは別物のようだ。

関係者っぽい人

同じサイトから、データの元になっているスプレッドシートを見つけた。

More Google Apps Script Libraries - Google スプレッドシート

「More Info」に期待してクリックすると 404 なのだが、URL を見ると今はなき Google+ で、アカウント名っぽいのは分かる。

https://plus.google.com/u/0/+EricKoleda/posts/ThnVjUgU3E9

んで、探してみると、 Google の中の人のようなことと、 GSuite 関連の開発をしている人っぽい。

https://twitter.com/erickoleda

https://github.com/orgs/gsuitedevs/people

Google+ の投稿が消えてるので想像になるが、おそらく「GAS で Moment.js 使えるようにしたぜ!」的なアナウンスだったんじゃなかろうか。

まとめ

結局個人でやったものなのか、Google として出しているものなのか確証はない。

GAS で公開ライブラリ探したり使ったりするときは皆どうしているのかな?

なんか GAS で外部ライブラリ積極的に使おうって気持ちにはならなかった(Google公式の拡張みたいなやつは別にして)。

「SCRUM BOOT CAMP THE BOOK」にコラムを書きました (そして旧版の思い出) #scrumbcbook #devsumi

5/20 に SCRUM BOOT CAMP THE BOOK の増補改訂版が発売されました。

学習と成長を促進する Scrum ですが、 Scrum 自身も成長を続けています。

スクラムガイドの改訂を取り込み、よりパワーアップしているので、ぜひ読んでみてください。

ご縁があって、僕もコラムという形で参加しています。

とても思い入れのある本なので、自分の名前が載ることになったのは非常に感慨深いものがあります。

発売イベントも開催予定(オンライン)なので、よかったら参加してみてください(枠追加されたようです)。

connpass.com

「SCRUM BOOT CAMP THE BOOK」の思い出

ここからはただの個人的な思い出話です。

旧版を読んだのは 2013年の2/14です。

なぜこんなに正確に覚えているかというと、デブサミの会場で購入したためです。

当時の僕はチームやプロジェクトのリーダーをやるようになっていて、ある程度の自信を付け始めていた頃です。

要件定義をして、設計してテストして。。みたいなことを割とうまくやっていたと思います。

そんな中、新規サービスの立ち上げに関わらせてもらっていたのが正にデブサミのタイミングでした。

event.shoeisha.jp

サービス開発において無力だった

新規サービスではそもそも要求や要件がまったく定まっていません。

ああでもない、こうでもない、という会議が繰り返され、一体いつになれば作り始められるのか、作り始めたと思ったらやり直し、ただ時間だけが過ぎていく。。そんな状況でした。

そんなとき、たまたま手にとったのが (旧)SCRUM BOOT CAMP THE BOOK でした。

すぐ読み終えた

帰りの電車で読み始めて驚きました。

不確実で不透明な状況に立ち向かうためのヒントが SCRUM BOOT CAMP THE BOOK には散りばめられていたからです。

そのままの勢いで読み進め、その日の夜にはもう読み終えていたと思います。

直人さんの話を聞きに行く

タイミングとは不思議と噛み合うもので、デブサミの二日目に著者の一人である西村直人さんのセッションがありました。

当然、是非話を聞きたいと参加を決めたのでした。

event.shoeisha.jp

Action!!

その年のデブサミのテーマは「Action」でした。

それゆえか、直人さんの話も何か「行動を始めよう」という主旨の話だったと記憶しています。

「ひとりでペアプロを始めた」という本気か冗談か分からない話を聞いて、自分は強く背中を押されました。

Scrum に大きな魅力を感じたのは間違いありませんでしたが、少し距離を感じていたのも事実です。

プロジェクト自体はウォーターフォールだし、チームのリーダーと言ってもサブチームの一つにしか過ぎないし、そもそも関われる範囲は開発に限られるし。。

やらない理由はいくらでもありました。

でもこの講演を聞いて、「できることは何か少しでもあるはずだ」「どんな形でもいいから始めるんだ」という気持ちに切り替わりました。

Scrum を始めてみた!

土日を挟んで週明け、「やり方を変えてみたい」と、チームのメンバーを集めて思いを伝えました。1

プロダクトバックログというよりも、Excel に書いたただの TODO リストだったかもしれません。

スクラムマスターも、プロダクトオーナーもいませんでした。

見積もりは、カードもないプランニングポーカーでした(せーので数字を言う、みたいな)。

でもあの時、一歩を踏み出したことから色々なことが動き出したと思っています。

何よりも、変化と学習と成長を楽しめるようになりました。

よりパワーアップした SCRUM BOOT CAMP THE BOOK が、僕と同じように、誰かが一歩を踏み出すきっかけになればいいなと思います。


  1. 当時「やってみましょう」と賛同してくれたメンバーのみんなには今でも感謝しています