半空洞男女関係

思ったこととかプログラミングしてるときのメモとか色々かいてます。メールはidそのままgmail

GitHubのPersonal Access Tokenを作るページに値を渡す

https://github.com/settings/tokens/new でPersonal Access Tokenを作成できるけど、Query Paramaterで値を渡すとスコープとかを調整できる。

  • description
  • Note のところに入るやつ
  • scopes
    • カンマ区切りで欲しいスコープを渡す。
    • 例: repo,gist,read:org,workflow

例えばGPRを使うためのTokenを発行するためのURLはこんな感じになる

https://github.com/settings/tokens/new?description=gpr_token&scopes=read:packages

この仕様がドキュメントに乗っているかわからなかったんだけど、WebStormとかでTokenを作るときにこのURLに誘導されて便利ーとなったのでメモしておく。

何かしらオンボーディングする時に便利だと思う。

Swiftのguardのわかり方

久々にコードに触れるようになってきて、Swiftを読み書きしている。Swiftの guard は次のような感じで使うことが多いと思う。

guard let foo = item.foo else { return }

そのイメージだと、 何かを否定する条件だった場合に結構頭がこんがらがる。

guard !canceled else { return } // これはどっち?

これは、以下のコードと意味的には一緒になる。今までは以下のコードの方がわかりやすくて好みだった。

if canceled { return }

よくよく考えてみると、 guard は条件のところに前提条件を記載するようになっている。すなわち、「これは前提条件だ。保てないなら、elseの先へ」という感じ。こう捉えると、guardも読みやすくなった。

guard !canceled else { return } // キャンセルされてない状態が前提条件だよ!守れないならさよなら!

前々チームで一緒だった人に教えてもらったけど、guardelse の先は return するなり throw するなり、フローから抜けることが強制されるらしい。知らなかった。うっかり抜け忘れるということがなくていいですね。

いろいろなスコープ調整

nekogata.hatenablog.com

この記事について数日前からちょくちょく考えていたんだけど、スコープ調整って2回くらいチャンスがある。

一つ目は開発が始まる前で、企画やデザイナーが「こういうことやりたいんですよね」「見積もるとこれくらいです」みたいなやりとりをしている時期で、この時の「スコープ調整」のやり方はブログに書いてある通り「こういう方法もありますよ」みたいな話がしやすい。

二つ目は開発が始まった後のことで、もうすでに始まってしまった開発が意外とやってみたら大変で、6月に出したいつもりだったけど6月まではここまでしか終わらないです、どうでしましょう、みたいな状況。こういう時はブコメにも書いたようなゴールポストをいじくるような一次元的な「スコープ調整」をしてしまいがちではある。この二つ目の状況において、「じゃあなんとかして価値を届けたいのでなんとか工夫してみましょうか」みたいなことをするのは結構難易度が高いとは思う。

でもスクラムのスプリントゴールっていうのは多分そういうことなんだと思う。今のところこういう仕立てがいいと思うんですよね、とPBIを使ってPBLに表現されているけど、達成したいことはスプリントゴールに書いてあることである。スプリントゴールに書いてあることが達成できるんだったらこういう方法でもいいじゃん。という「スコープ調整」を毎日していくことがスクラムとかでやっていきたいことなんだろうなと思う。

そういえば最近スクラムスクラムってけしからんな、と思っていたけど、なんやかんややっぱりよくできたフレームワークだなとも思っていて、心の故郷はアジャイルとXPにありながらも、お道具箱にはスクラムキット入れておきたいよなとか、そんな気持ちになっている。