はてなブックマーク

Photo by Baim Hanif on Unsplash 今年いっぱいで株式会社オンザロード(以下OTR)を退職することになりました。そのご報告です。 OTRに入社したのは2011年9月1日で、id:bleis-tift さんにあこがれてでした。はてなでブログを書くキッカケになったのも bleisさんのおかげです。 kyon-mm.hatenablog.com そのbleisさんにあこがれてOTRに入社し、10年在籍し、そしてずっと同じチームで仕事をし、今度は一緒に卒業をすることになりました。OTRには感謝しつくせません。 チーム移籍についての一旦のご報告はこちらになります。 www.kikan47.org 僕がOTRにはいったのは、Jenkinsマスターがくる！みたいなかんじでした。入社すると、Jenkins, Git, Gitolite, Redmineという構成でうごいているプ

15分スプリントの具体的な実践例をYoutubeにあげました。今後なにかの参考になれば幸いです。 www.youtube.com リンク先でチャプター毎にわかれているので、みてみたいところだけかいつまんでみるか、2倍速くらいで見るのをオススメします。 Twitterで実況してくれていた方達のツイートまとめはこちらになります。 togetter.com 動画内で利用していたスライドはこちらになります。 こちらの放送をしたのは、もともとは次のイベントとしてやっていました。 15分スプリントを2年間やったけど質問ある? - connpass やってみてどうだったか この放送をやる経緯自体は 15分スプリントを2年間やったけど質問ある? #15min_sprint at 2020-10-14 21:30 - うさぎ組 にかいたとおりで、おもいのほかたくさんの人にご参加いただけてうれしかったです。

先日 id:terurou さんが 『2時間スプリント』とフルリモートワークなシステム開発 - terurouメモ で私達のチーム(47機関)と仕事をした経験から社内でのとりくみを記事にしてくれていました。おおくの人がこの記事に注目する結果となり、わたしもその１人でした。 こういったショートタームなスプリントについて説明する機会があってもいいかもしれないとおもうようになりました。あくまで 47機関としての話に限定されるとおもいます。 ということで Youtube Liveで公開でやろうとおもいます。時間は1時間から1.5時間くらいを想定しています。 お申し込みはこちらから。 connpass.com チームは最初はなんちゃってアジャイルで、そのうえ仕事の仕方はお世辞にもほめられたものではありませんでした。 そんなチームも2015年頃からアジャイル開発をはじめていて、2017年から徐々にスプ

ご縁があって新刊をいただいたので、オススメする理由を簡単にですが紹介したいとおもいます。 書籍の特徴 わたしがオススメしたいところ 紹介しきれないいいところ 出版イベントがあります わたしがおもうこの書籍のよくないところについて 書籍の特徴 フォント、文字の大きさ、レイアウト、漫画部分など読みやすさにこだわっている 多様なコラム ほとんどの章がチームの悩みから話がはじまる 改訂前から一緒な部分もありますが、わかりやすいのは、多様なコラムのところでしょうか。 前作およびメイン部分の執筆陣ではない人達がコラムを寄稿をしています。そして、30代前後以下のエンジニアになっているのも今の声がはいっているという感じです。 この3つを達成している書籍はなかなかなく、独特の読み味をかんじます。 もっとこういった書籍がふえると導入しやすくなるんじゃないなかなぁとおもいますね。SREとかDevOpsとか1on

COVID-19の影響でIT系の人達はテレワーク導入をすすめているけど、どうなんでしょうね。っていうかんじで勉強会を spring_akiさん、TAKAKING22くんの3人でやってみました。 4月21日と5月5日の2回やり、どちらもLTを数本と、OST(みんなでトピックをきめるディスカッション)。 特に、5月5日は、13:30 - 19:00までのほぼ1日やってみるというものでした。 これらの回の概要、そしてどんなツールをつかったのかを紹介します。またツール選定にあたっておこなった負荷試験のスクリプトも紹介します。 イベント概要 利用したツール Muralは50名付箋のみ同時編集なら余裕、80名以上でもたつく オンラインOSTはいいぞ！ 最後に イベント概要 分散して活動していくアジャイルチームについて議論していく場があればいいなと思って、4月頃に某コミュニティで話していて、特に大きな知

1/8から開催されるRegional Scrum Gathering Tokyo(RSGT) 2020。年に1度の日本最大級のScrumのカンファレンスです。 このイベント内の1/9 13:00 から「チームの再定義 -進化論とアジャイル-」というセッションを3倍楽しむ情報をまとめておつたえします！ Regional Scrum Gathering Tokyo 2020 - チームの再定義 -進化論とアジャイル- | ConfEngine - Conference Platform 前作まで この作品はRSGT2016から続く一連の最新作になります。 2016 : Scrum, Test , Metrics 2017 : スクラムありがとう, そしてさようなら -Scrum 破- 2018 : スクラムが難しいのは幻想 -情熱の再定義- 2019 : 超Scrum入門 2020 : チーム

現代のソフトウェアシステムにおけるシステムアーキテクチャ設計手法や、それらをとりまく各種手法は素晴しい。だけど、わたしはまだまだもっと理想にちかづきたい。 そんな思いから課題をみつめて、自分なりに設計手法をつくってみました。 いまはこれを数理的システム設計とよんでいます。まだαバージョンくらいです。 いままでも、これについては筑波で2度勉強会をしており、今回はAgile Tour Osaka 2019で講演してきました。 アジャイル システム設計 Meetup - connpass システム設計ハンズオン勉強会 -リジェクトすえなみチャンス暑気払い- - connpass Agile Tour Osaka 2019 × miniPLoP 2019年11月9日（大阪府） - こくちーずプロ で、今回はたぶんはじめてスライドを公開しました。 スライドにある通りですが、基本的には僕の経験のみの話

Regional Scrum Gathering Tokyo 2019 というカンファレンスで @ryuzee さんとはなしているときに、 Webサイトみていると、これなんか1ピクセルくらいズレているってすぐわかるよねー。きになる。 と言っていました。わたしもたまにWebサイトつくることにかかわるけれども、(要求されている品質の都合上)なんとなくでやっていることもままあって、厳密に綺麗にしようみたくするのはあんまり経験がないなーと。 で、自分でつくるかどうかはおいといて、まず「それ1ピクセルずれてない?」って自分で判断できるのかためしてみようとおもいました。 Do you think you’ve got a designer’s eye? 次のWebサイトで簡単なテストをできました。 https://www.supremo.co.uk/designers-eye/ クリックすると次のよう

先日、 Scrum Fest Osaka 2019というカンファレンスでとある方からこんな質問をうけました。 きょんさんのチームでは、何度かやればうまくいきそうなTryとかプラクティスがあるときに、いつまで挑戦するとか、いつになったらやめるとかそういった基準とかはありますか？ これ聞かれたときに昔の自分だったら「やれなくなるまでは挑戦しつづける」って答えていたとおもうんですよね。でも、今は違うなーと。 僕が答えたのは「やりたい意思がある限り続ける。やりたくないものをやるのは楽しくない。」で、もっと端的にいうと チームにできるプラクティスは残るし、できないプラクティスは残らない。 というものです。ある種の適者生存というか。プラクティスが正しいから残るのではないというかんじですかね。 ただ、それだと怠惰でルールのないチームは一向に成長しないので、成長するための仕掛けは必要だとはおもいます。 で

2019/1から複業でチーム開発のコーチやアーキテクトをはじめました。(TwitterやFacebookで開業しましたとだけかいていましたのであらためて。) 週2以下の稼動であればおきがるにおといあわせください。 kyon-mm.com たまに今回の私の状況についてご質問をいただくので、ここでまとめておきます。 Q1. 株式会社オンザロードにはいるの？ Q2. アジャイルの発表でみかける基盤チームには所属しているの？ Q3. 会社でアジャイルコーチやらないの？ Q4. 遠方でもきてもらえるの？ Q5. 開発もまかせられるの？ Q1. 株式会社オンザロードにはいるの？ います。現在もはたらいています。とうぶんはいるのではないでしょうかね。 Q2. アジャイルの発表でみかける基盤チームには所属しているの？ 所属しています。現在もチームのなかではたらいています。 Q3. 会社でアジャイルコーチや

はじめてRSGT2019に参加する人、もっとたのしみたい人などたくさんいるとおもいます。ということで、RSGT2016 - 2018まで参加してきた身としての歩き方を紹介します。 本エントリは 「Regional Scrum Gathering Tokyo Advent Calendar 2018」（非公式）26日目の記事です。（は？） adventar.org confengine.com まず会場近くに宿泊しよう 基調講演はきいて損がない ランチでは隣の人に声をかける or さっさと食べてホワイエ（ホール外）でドリンクをのみながら声をかける ランチ後の講演はどれか2,3つ聞いて、それ以外はホワイエ（ホール外）でスピーカーをつかまえる or 休憩する 初日のネットワーキングパーティではここまで話した人をつかまえよう or 気になる人に声をかけよう 2日目もほぼ同様でOK 3日目のOSTは

概要 とりあえず次の動画をみてほしい。 ちまたのアジャイル開発チームはスプリントが1週間だが、私のチームは15minで回している。 学生や新卒に1日スプリントを教えている。彼らは5日程度で1日スプリントをマスターする。 15minスプリントを含んだプラクティスについてスライドにしてほしい、聞きたいという人は RSGT2019の公募にlikeしてほしい。かりにlikeはなくても、RSGT2019に参加しよう。 セッション confengine.com チケットはこちらから！11/16から販売だそうで。 Regional Scrum Gathering® Tokyo 2019 www.youtube.com 概要 背景 スプリント期間の変遷 RSGT2019 参考書籍 生物系の参考書籍追記 背景 このチームが今までどんなふうに開発を経てきたのかはだいたい次のスライドにまとまっています。 簡単に

誰かが書き始めると、他の人も書いてくれることを祈ってこのエントリを書いている。できるだけ、組織全体で使うツール（チャットツールとか）は選ばないようにした。 エンジニアが使うべき便利な windows アプリ一覧、みたいなのってどっかにまとめないの?— 徳永広夢 (@tokuhirom) October 2, 2018 RapidEE cmder 7-zip clibor Chrome, Firefox Mate Translate WinMerge そしてこれジオシティーズなので、大丈夫なのかが不安です。 Git Everything Process Explorer などsysinternals系 Crystal Disk Info ここで触れていないけど、実質必須になりそうなもの RapidEE www.rapidee.com Windowsの“環境変数”をGUIで編集できるソフト。各

「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である このエントリーは 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く に対する返答です。 件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。 私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。 そして発表者様のエントリーを読んでも私の感想は変わりませんでした。 まず、件のスライ

ScalaMatsuri2018というScala言語のカンファレンスに参加してきました。といっても3日間のうちの1日目（というか0日目みたいな位置づけ）のトレーニングデイというものだけですが。 最近Scalaを使っているし、Scalaユーザーにいくつか聞けたらなぁーとかちょっと勉強したいなーって感じで。 2018.scalamatsuri.org 運営の方はおそらく大変だったと思いますがいろいろ対応してくださって助かりました。 ただ、自分が参加したチュートリアルセッションはひどかったです。自分もハンズオンで教えることがあり、失敗を幾度かしてフィードバックをもらっては改善してきました。ので、今回は私がフィードバックをする番だと思いましたので、このエントリにさせていただきます。 トラックとかモチベーションについて Scala入門ハンズオンのタイムライン Implicit入門 CTO座談会 まと

Java言語でうるう秒を扱う方法を調べたのでまとめておきます。Twitterで質問したらたくさんのリプライ、エアリプがありそれらをもとに調べることで達成できました。ありがとうございました。 概要 Java標準APIのOracle実装ではうるう秒を扱えない。Calendar, Dateなどの旧型のAPI、ZonedDateTimeなどのDate and Time APIどちらも。 ThreeTen-Extra というライブラリを使うとうるう秒を扱える。 うるう秒を扱えるということに対して期待していること 4年に1度だけ2/29があるうるう年のように、2年から5年に1度くらいの間隔で世界中の時計が1秒だけ増えることがあります。これをうるう秒と言っています。最近だと日本時間で2017/1/1 08:59:59 のつぎが 2017/1/1 08:59:60 となりました。普段はない60秒があり、1

プロジェクト名や名前空間の雑さはIDEなどの強力さを考慮して決めること IntelliJ IDEAなど => 名前空間やファイル名変更が強力なので、雑に決めてもあとから変更できる Vimのみ => 名前空間やファイル名変更が プロジェクトをつくるときは次の手順でやること てきとうにスキャッフォルドでつくる。gradle initとか。 gitignoreを追加する gitignore.io - Create Useful .gitignore Files For Your Project git init git add git commit で↑までにやったコマンドやWebサービスでの指定方法などをコメントにのこす 要件を確認してアーキテクチャと単語の整理 noteという名前空間をつくり、そこにメモ書き用テストファイルをつくる。 要件をテストコードにはりつける 要件の一部をテストコードに

私が所属しているチームは2017年にいろんなプラクティスを実践してきました。その内容をRegional Scrum Gathering Tokyo 2018で発表しました。 2018.scrumgatheringtokyo.org confengine.com 発表内容の概要 私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。 このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。 チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、 なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。

GroovyのテスティングフレームワークであるSpockは標準ではレポート生成機能はありません。 多くはGradleでビルドしたときのxmlやhtmlを利用していると思います。 Spockにはspock-reportという拡張ライブラリがあり、これを依存関係に追加するだけでテスト結果のレポートを独自に追加で生成できます。 しかもなんと、HTMLだけではなくMarkdownやAsciidocとして生成することもできます。 また、最新のspock-reportではテストコードからレポートに文章を追加することも出来るようになりました。 今回はそんなspock-reportの便利機能をいくつか紹介します。 github.com 本ブログで説明しているサンプルコード全部入りのspockおよびspock-reportのプロジェクトテンプレートはこちら。 github.com 本記事はG* Advent

メールのテストを中心にまとめました。 メールのテストのためのSMTPサーバ SaaS メールのテストのためのSMTPサーバ OSS メールのテストで気にすること Gmailにおける迷惑メール判定の見方 証明書の情報を確認 メールのテストのためのSMTPサーバ SaaS Ethereal Email SaaS的にメールサーバをテストのために公開してくれています。 トップページからアカウントを作成できます。便利ですねぇ。 メールのテストのためのSMTPサーバ OSS github.com こちらはGo言語で開発されているSMTPサーバ。 WebUIもついているし、APIでもいろいろできる。 メール送信内容をSaaSにとばすのが許されない場合には、こっちを使うといいかもしれませんね。 メールのテストで気にすること www.softwaretestinghelp.com そもそもこういったメールの

G* Advent Calendar 5日目の記事です。 JVM上で使えるWebAPIを開発するFWなどは多々ありまして、ハイパフォーマンスなものを探していたらどうやら Light-4Jというものがあるらしいと聞きつけました。 彼が言うにはそこそこ速いということで、ベンチマークも出しているんだぜと。 doc.networknt.com www.techempower.com 鵜呑みにはできないし、使い方とか知りたいので最小限のプロジェクトテンプレートをつくってみました。 github.com JDK8が入っていれば、 ./gradlew run で http://localhost:8081/baz で bazというテキストがレスポンスされると思います。 サンプルプロジェクトを移植しただけなので、Groovyらしさとかテストコードもありませんが。（ルーティング部分だけだったので） Ligh

テストツールというかサービス中心なんだけど、書籍情報も。 WebGUIのテストIDE Katalon Studio JavaScriptのテスティングフレームワーク iOS Appiumで並列テスト AIでテストをやるっていう話 テスト戦略書籍まとめ WebGUIのテストIDE Katalon Studio www.katalon.com テストケース管理、テストコード、CIやチャットとの連携、並列実行などなんでもできるツールっぽい。Katalon Studio。。。 なんだろう。これほしかったやつでは。。。！ってかんじがするのでそのうちつかってみたいですね。 つかったことある人いれば教えてください＞＜ JavaScriptのテスティングフレームワーク postd.cc 結構いろんな視点でいくつも比較していて好感のもてる記事でした。いろいろあって僕も悩むんですよね。 個人的にはシンプルさか

ここ1ヶ月くらいで気になったものまとめ 機械学習のテスト 分散システム bashのテスト 初めての自動テスト テスト駆動開発 SeleniumのTips 機械学習のテスト medium.com ユニットテストの範囲でっていうかんじだったので、まぁこうなるかなぁという感想でした。 困っているところはいわゆるインテグレーションテストとか運用しているデータにたいするテストだとおもいます。 まぁそれでもユニットテストないよりはあったほうが便利な場面もそこそこあるんでしょうかね。ありそうだな。 分散システム 本当は恐ろしい分散システムの話 from Kumazaki Hiroki www.slideshare.net ご存知 kumagi さんの講演資料です。 いろんな論文やブログから、DBなどを中心に分散システムのバグはこんなのがあるんだぜっていうのをまとめてくれています。 RedisやらRDB系

2017/1/13 に開催されたScrumのカンファレンスで「Scrumありがとう、そしてさようなら -Scrum 破-」というタイトルで45min話してきました。 スライドを公開するのずっと忘れていて、何度か再演もしているんだけど公開しました。2016年のチームの成果の話です。 speakerdeck.com カンファレンスのイベントページに書いたセッションの概要はつぎです。 Regional Scrum Gathering Tokyo 2017 - Scrumありがとう、そしてさようなら-Scrum 破- | ConfEngine - Conference Management Platform ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透

オススメのものを列挙するよー。 1日の過ごし方 大切にしているコンセプトは「もっているものを最大に使いこなす」ということで、手を使える時間はプログラミングとか、たまにしか手を使えない時間は電子書籍か動画、耳しか使えない時間は音声ってつかいわけています。なので、手が空いているときはできるだけものを作るようにシフトして生活している。 起床したら気になる記事をInoReaderとかはてなブックマークから検索して、Pocketに共有。 シャワーあびたり身支度する時間、通勤で歩いている時間、などはPocketで共有した記事を音声読み上げで聞く。 音声読み上げできなかった記事は、空き時間に目視で確認。（大抵は業務時間の隙間とか） 気になったソースコードはPCのChromeでSourcegraph for GitHubを使って確認して、必要そうだったらcloneする。 手が動かせる時間ができたら、いろん