macOS版の1PasswordでSSHキーの管理が便利になってた - Mitsuyuki.Shiiba
GitHubの鍵を1Password管理に ちょっと前に、azuさんの記事を読んでSSHの鍵を1Password管理にするのいいなと思ったので efcl.info GitHubのAuthとSigningの鍵を1Password管理にしておいた。 GitHubの鍵を1Password管理にしといた。簡単だった。よいー。https://t.co/Vo2OA230V5— Mitz Shiiba (@bufferings) March 25, 2023 azuさんの記事だと、SSHの鍵以外も色々やってるんだけど、そのへんはまたの機会に。 便利 GitHubにアクセスするときに、macOSのTouch IDを使って指紋で認証するだけでよくて便利。しばらくは有効なので、毎回認証が必要なわけじゃないのも便利。 なんだけど、tmuxで新しいペインとかウィンドウを開くたびに聞かれてしまうのか、有効期限が短い
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
サイボウズさんのマネージャー話を読んで想像して遊んだ - Mitsuyuki.Shiiba
サイボウズさんの、この記事を読んだ blog.cybozu.io とても面白い。良いなと思う。ぼーっと想像して遊んでみる。全部想像だよ 職能横断チームへ 2019年の組織変更ではマネージャーをなくしたことに目がいくけど、職能ごとの組織から職能横断のプロダクトチームに変更したことがまず興味深い 職能横断のプロダクトチームだと良さそうなのは プロダクトのことを第一に考えることができる 職能間の壁をなくして全員で取り組むことができる 結果として、プロダクトをより良くするための開発サイクルが速く回るようになったんじゃないかな。それと、開発・テスト・リリース・運用など全てのフェーズからのフィードバックをチームが得られるので、そこからの改善も進んでそう。とても良さそう 職能別組織が持っていた良さ 一方で、以前の職能別組織の場合に良かったのは 自分の専門領域に集中して取り組むことができる 専門知識を持っ
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
これからは git restore を使ってみようかな - Mitsuyuki.Shiiba
Gitの基本的な使い方のおさらいをチームのLearning Sessionでやろうかなと思ってドキュメントを眺めてたら、あれ？こんなんあったっけ？と思うコマンドがあった。 git restore と git switch Git 2.23で導入されたみたい。去年の夏か。 https://github.blog/2019-08-16-highlights-from-git-2-23/ まだExperimentalみたいだけど、面白そうなので触ってみた。今日は git restore の話。git switch はまた気が向いたら。 https://git-scm.com/docs/git-restore ## リストアの前にWorking Treeとかの話をざっくり GitにはWorking TreeとStaging AreaとGit Directoryという3つの場所がある。 file.t
僕らのモブプログラミングは「全員でプログラミングをする」ということではなかった - Mitsuyuki.Shiiba
## 去年の夏ぐらいからサポートしているチーム で、それまでもちょこちょこモブプログラミングを試してはいたんだけど、3月からは思い切ってそれを基本として開発をするようにした。つまり、3月からは1日中モブプログラミングをするのを毎日やってる。 プログラミングだけじゃなくて、設計も、運用も、テストも、全部モブでやってるので、僕らはそれをモブワークと呼んでる。 ## やっていく中で学んだのは モブプログラミング（モブワーク）は「全員でプログラミングをする」ということではなくて「全員で考えて取り組む」というだけのことだった。 サービスにとってどう動くのが良いかを全員で考える。 目の前のプロジェクトのことだけではなく、少し先を見据えてメンバー間の知識やスキルの共有や、チームがまだ詳しくない分野の学習をすることも含めて、どこにトレードオフスライダーをセットするのが良いかを全員で考える。 ## 全員でプ
#RSGT2019 に行ってきたメモ（これにて完了） - Mitsuyuki.Shiiba
昨日は、帰りの新幹線でさらっと感想を書いたのだけど #RSGT2019 に行ってきたメモ - Mitsuyuki.Shiiba どうもこのままではしばらく余韻に浸ってしまって、来月喋らせてもらうスクフェスへの頭の切り替えに時間がかかりそうなので。今日は感謝を込めてもうちょっと詳しく書いて、RSGT2019を自分の中で完了させておこうと思う。こんな流れかな。 RSGT? 1日目 2日目 3日目 RSGT2019 あとがき ## RSGT？ 2019.scrumgatheringtokyo.org よたさんが「カンファレンスじゃなくてギャザリング」って言っていた通り、セッションだけじゃなくて参加者同士の交流が中心にあるイベント。僕自身は、そこまで人との交流が得意な方ではないのだけど、ここは敬意にあふれていて、意見や立場の違う人達がお互いの違いを尊重しあう空気に満ちているので、自然と「お話したい
実践DDDのサンプルプロジェクトが学びしかない - Mitsuyuki.Shiiba
IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ﾉД`)ｼｸｼｸ github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。 DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba
devlove-kansai.doorkeeper.jp モブプログラミングやってきました！面白かったー。疲れたー。面白かったー。 モブプログラミングって？ チーム全員(プロダクトオーナー含む)が集まって、1人だけがコードを書いて、それがスクリーンに映しだされてて、その他の人みんなでやいやい言いながらものを作っていく。というスタイル。ルールは「ドライバー(コードを書いてる人)は、ナビゲーター(周りでやいやい言ってる人)に言われた通りにコードを書く。ドライバーが自分で考えてコードを書くのはダメ。」という感じ。 やってみた 7人ぐらいのチームで、プロダクトオーナーからのお題に対してTDDで実装をやってみた。2部制でやったのだけど、第1部はKotlin + IntelliJ IDEAでローマ数字の計算を。Kotlin全く知らないし、IntelliJも全然慣れてない。第2部はJavaで自動販売機を
#Java本格入門 は実践的だなー！ - Mitsuyuki.Shiiba
Java本格入門を読み終わりました。著者の谷本さんからいただきました。ありがとうございます。もし面白くなかったらどうしようwとドキドキしながら読み始めましたけど、全然そんなことはなくて色々と勉強になりました。本当に読んで良かったです。周りの人にもおすすめしたい一冊です。 楽天ブックス: Java本格入門 - モダンスタイルによる基礎からオブジェクト指向・実用 - 谷本心 - 9784774189093 : 本 機能ごとにひとめぐりしてくれてるところが良い 僕は1.4の頃にJavaに入門して、その後は新しい機能が追加されたらそれをチェックしていく、という感じでつけたしつけたしやってきたので、頭の中がごちゃごちゃしていたのですが。Java本格入門では、基本的な文法からJava8の機能までを時系列ではなく機能ごとにひとめぐりしてくれてるので、頭の中が整理されました。 また、自分が知識を更新してい
「スクラムでは割り込みはできません！」って言わなくていいような仕組み - Mitsuyuki.Shiiba
昨日は、娘達とクッキーを作ってて、余った白身でラングドシャクッキーを作って美味しかった。ども。椎葉です。 F-team, L-team 牛尾さんの記事にF-team、L-teamってあるんだけど、これ、今僕のいるチームでやってることだー。って思った。Microsoftさんの最先端のチームと同じ思想に辿り着いてたってことで、なんか嬉しいなー。 simplearchitect.hatenablog.com Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。 だいたいは同じなんだけど、ちょっと違う部分があるのでそれをメモしておく。以前からの流れでOps TeamとDev Teamって呼んでるんだけど、今流行りのDevOpsとは関係ないので注意ね。 Ops Team
「スクラムの価値基準」にピンとこなくてウロウロしてきて、腑に落ちた。 - Mitsuyuki.Shiiba
スクラムガイド2016年版 RSGTの発表のことを色々考えてたら、そもそもスクラムって何だっけー？って思ってしまって、スクラムガイドを読もうとしたら、あれ？2016年版ってのがある http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf さらーっと読みながら、あれー？スクラムの価値基準とかあったっけなー？全然覚えてなかったー。って思ってたら、スクラムガイドの最後に「2016年版ではスクラムの価値基準が追加されたんだよ！」って書いてあって。おー！そーなのかー！って思った。 スクラムの価値基準 Commitment, Courage, Focus, Openness, Respectの5つ。実際にはこんな風に書かれてる: スクラムチームが、確約（commitment）・勇気（courage）・
JUnitのテストメソッド名をどういう風につけたらいいかなー？ - Mitsuyuki.Shiiba
って話になって、チーム内で盛り上がった。例えばこんな感じのテストを書きたい時。 「ジュースを買う」メソッドに、お金とジュースの番号を入力したらそのジュースが返されて、在庫が一個減る。 メソッドはこんな感じかな？ Juice buyJuice(int inputAmount, int juiceId) これでどう？ buyJuice_shouldReturnJuice_whenInputAmountIs130Yen え？でもこれだと、なんかこう・・・在庫が減ってることとかは表せてなくない？ えー、じゃあこういう感じ？ buyJuice_shouldReturnSelectedJuiceAndOneLessInventory_whenInputAmountIs130YenAndSelectedIdIsValid いや、長いね・・・。 ふむ。。。全部をメソッド名に書かない方が幸せなんじゃない？
node.js の logging library の winston のソースを読む - Mitsuyuki.Shiiba
node.js を使い始めて javascript かわいいなーと思い始めたこのごろ まだ javascript の扱い方から勉強してるんだけど そんなわけなのでソースを読んで勉強しようかなと winston を選んでみた winston は nodejitsu 社が作ってる Flatiron ってオープンソースフレームワークのモジュールの一つとして開発されてるす いくつか便利機能があるんすが query とか、例外ハンドリングとか、profiler とか そのへんは今回は触らずにロギング周りを見ていくす この記事は 東京Node学園祭2012 アドベントカレンダー の 26 日目の記事です。 ファイル lib の中身はシンプル ├── winston │ ├── common.js │ ├── config │ │ ├── cli-config.js │ │ ├─
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
