フロントエンドのテストツールとか気になっているやつ

テストツールというかサービス中心なんだけど、書籍情報も。

  • WebGUIのテストIDE Katalon Studio
  • JavaScriptのテスティングフレームワーク
  • iOS Appiumで並列テスト
  • AIでテストをやるっていう話
  • テスト戦略書籍まとめ
続きを読む

機械学習のテスト、自動テスト入門書籍など気になっているやつ

ここ1ヶ月くらいで気になったものまとめ

続きを読む

Scrumを破る話とその補足。Scrumありがとう、そしてさようなら -Scrum 破- #rsgt2017 で発表してた

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年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透明性、検査、適応の3本柱を強化してきました。

私達はいまやスクラムに別れを告げつつあります。スプリントは1日以下で、ロール(PO, SM, Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。

このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。

背景とかこのチーム(基盤チーム)でわかったこととか

世界最高の製品開発チームとは何かを追求する実験場が基盤チームと言われればそうなんですが、単純にこのチームで仕事をするのが楽しいし、いろいろやっていることがどうも他の人と違うらしいってことはわかってきているので、事例紹介してフィードバックもらったり、誰かの参考になればいいかなぁと。

まぁ普通に考えて頭悪いとは思うんですけど、このチームを通してわかったのはマイクロマネジメントこそ最高である。っていうところですかね。以前の自分と比較して、プロジェクトマネジメントでマイクロマネジメントできないのは才能が足りないんだろうなって思うようになった。マネジメントはあらゆるリソースの使い方を考えて最高の成果を出すということが目的かなぁと思っていて、解像度が低い状態でしか判断できないって辛いよねっていうかね。高解像度かつ大画面なモニターがいいように、マネジメントもそのほうがよっぽどうまく違和感に気づけるのになーみたいな。

この発表は誰かに強制するものでもないし、ある状況ではこういったやり方や考え方もあるということを話しているだけな感じです。 ので、僕も例えば全く別のチームにいったり転職したりしたら、きっと違うことを考えるんだろうなぁとは思います。

Scrumの破であるという理由は、Scrumの3本柱である透明性、検査、適応は変えていなくって、この3つを重要視することは変えずにそれら以外は瑣末なルールだと解釈してScrum Guideを基盤チームオリジナルにどんどん変えていっているっていう感じです。

あぁ、そういう意味だとScrum GuideもGitHubにあると基盤チームでforkして公開するとかできて楽しそうですね。なによりチーム的にもわかりやすいかもしれない。

今までにいただいたフィードバックとか

  • 控えめに言ってクレイジー
  • 理想はこれなんですよねー
  • ちゃんと聞くと当たり前のことを突き詰めているだけなのがすごい
  • Extreme Scrum なんだよな
  • もうScrumとかどうでもよくね
  • kyon_mmは今後何年たっても「僕たちはまだScrumを忠実にやっているだけなんですよ」とかいいそうだよね。
  • タイムトラベラーやな kyon_mmさんはタイムトラベラー
  • そろそろ何周かしてしまっていて、勘違いしている人と話があっちゃいそう

今後とか現在とか

現在も形を変えてこのチームとして仕事をしていて、非常にたのしくやっています。できれば2017年の成果もどこかで話せたらいいなぁと考えています。 例えば、 #RSGT2018 (日本最大のScrumのカンファレンス 2018/1/11 - 1/12)とか。ただ、まだ公募に出していないので、ここでVoteしてね!って言えないんですが。 僕の話もいいわけですが、もしScrumとか製品開発に関わっているのであれば、これを読んでくださっている方はきっと #RSGT2018 で発表する素質がある気がするのでみなさんも公募を出してみてはどうでしょうか? 採用されなくても別に恥ずかしいとかはないと思いますし、去年は非採用のセッションをひたすら発表する別イベントがたっていたりしましたし、まず考えをまとめてみるだけでも、とても有意義かと思います。

次のサイトで 画面右側の + Propose Sessionボタンを押せば登録できます。

confengine.com

全体のことが書いてあるページはこっち

Regional Scrum Gathering Tokyo 2018 - Tokyo, Japan | ConfEngine - Conference Management Platform

まぁなんにせよ、ソフトウェア開発組織としての知見共有とか悩み共有して次の一歩を踏み出すという場はとてもよいと思っているので、その1つとして自分も貢献できたらなって思っています。

参考書籍

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

エクストリームプログラミング

エクストリームプログラミング

アメリカ海軍に学ぶ「最強のチーム」のつくり方

アメリカ海軍に学ぶ「最強のチーム」のつくり方

チームワークの心理学: エビデンスに基づいた実践へのヒント

チームワークの心理学: エビデンスに基づいた実践へのヒント

お気に入りの生産性あげるための工夫(アプリとかブラウザ拡張とか)

オススメのものを列挙するよー。

1日の過ごし方

大切にしているコンセプトは「もっているものを最大に使いこなす」ということで、手を使える時間はプログラミングとか、たまにしか手を使えない時間は電子書籍か動画、耳しか使えない時間は音声ってつかいわけています。なので、手が空いているときはできるだけものを作るようにシフトして生活している。

  1. 起床したら気になる記事をInoReaderとかはてなブックマークから検索して、Pocketに共有。
  2. シャワーあびたり身支度する時間、通勤で歩いている時間、などはPocketで共有した記事を音声読み上げで聞く。
  3. 音声読み上げできなかった記事は、空き時間に目視で確認。(大抵は業務時間の隙間とか)
  4. 気になったソースコードはPCのChromeでSourcegraph for GitHubを使って確認して、必要そうだったらcloneする。
  5. 手が動かせる時間ができたら、いろんなものを動かしてみる。

実践している時間はバラバラなんでよくわからない。

InoReader

いろんなブログとかRSSで購読するためのWebサイト、スマートフォンアプリ。 スマートフォンで見て気になったらSlackとかPocketとかはてなブックマークに共有しています。 PCブラウザで見るときはショートカットキーが使えて便利。

www.inoreader.com

Pocket

Webページをまるっとスクレイピングして保存できるWebサイト、スマートフォンアプリ。 Androidで音声読み上げを入れれば、記事を読み上げることができる。 これで、シャンプーしながらとか歯を磨きながらでも勉強できるようになりました。神ツールだと思った。

getpocket.com

Sourcegraph for GitHub

GitHubのコードをブラウザ上でIDE的に見ることができる。 なんとコードジャンプもできてまぢ便利。神ツールだと思った。

chrome.google.com

ポモドーロテクニック

25分毎に1度休憩するというテクニック。 で、これはお手製ツールを使ってやっています。25分過ぎると、アプリが全画面表示になって作業を強制的にストップするようにしています。 結構便利です。集中して仕事したいときはかならずポモドーロテクニック使っていますねー。

Chrome拡張で便利なのはStrict Workflowっていうプラグインかな。25minの間はTwitterとかが見れなくなります。(どのサイトを見れないようにするかはカスタマイズできます)

chrome.google.com

ブラウザ上で英単語翻訳

ブラウザで表示している画面で、ダブルクリックした英単語とか選択した英単語を日本語に翻訳してくれる拡張をつかっています。 いろいろあるんですが、最近は、速訳!英辞郎®英和辞書っていうやつを使っています。 ページの翻訳はChromeそもそもできるんでね。

chrome.google.com

スクラムとかアジャイルのワークショップ 2017.05 版

毎月スクラムに関する勉強会を開催していて、そこでワークショップをやることがあります。 また社内で勉強会をやることもあります。 そこでいままで実施したワークショップの一覧があるといいなぁとおもったのでまとめておきます。 yattomさん、みほらぶさん、角さん、たかえすさん、川口さんありがとう!!!

nagoya-scrum.connpass.com

カンバンゲーム

www.slideshare.net

www.slideshare.net

バルンガ

www.slideshare.net

紙ヒコーキ

dev.classmethod.jp

振り返り

speakerdeck.com

↑の中で次の5つを実施 * +/Δ * Circle of Question * Value Stream Map * KPT * SMART Goal

プロダクトオーナーの意思共有

d.hatena.ne.jp

フィアレスジャーニー

www.slideshare.net

download – Fearless Journey

mocha-cocoa.blogspot.jp

スプリント期間と見積もり

speakerdeck.com

happylilac.net

プログラミング言語雑感 2017春

まえおき

kyon_mm のスキルでは。。。っていうだけで、皆さんがどうなのかはしりません。

Groovy

こまったらまずこれで検討するやつ。(.NETと比較して)どこでも動いてよい。IntelliJ IDEA + Gradleでつかっておけば問題ないやつ。

GrabやGradleの恩恵がすさまじく、可搬性の高いスクリプトやアプリケーションの開発にもってこいですね。くわえて、Spockっていうすばらしいテスティングフレームワークがあるだけで採用したくなる。Groovy自体も漸進的型付きなかんじがあって、そこそこに静的な型検査ができるのもいいなーとか。

WebアプリケーションつくるときはさいきんはRatpackっていうフレームワークでつくることがおおいですが、ガチな運用したことがないので結局はGrailsがいいっていう場面はあるのかもなーっていう見解。

C#

Visual Studio.NET Frameworkから離れなければとりあえず安定している。いつも不満なのは、Visual Studioで出来る操作をMSBuildでやるにはどうしたらいいのか調べるのに苦労しています。誰かサクサク知る方法を教えてください。

async/awaitの変換回りはかなり気色悪い(褒めている)とかあるんですが、(LangExt っていうライブラリをつかえば)そこそこつかえるかなぁとはおもっています。 いつも不満なのは、ASP.NETとかADO.NETとかそういうやつですよ。(あれー)

F#

.NET Frameworkでアプリケーションつくるときの第一候補とする言語。C# とかいう言語では最近REPLができたそうですが、F# は古来からありますよ! みんなでレッツF# !

F# はアクティブパターンがつかいやすくてマヂ神! ってかんじですかね。タイププロバイダーとかいうおもしろ機能はいろいろ使いこみたいんですが、まだ使いこなせていないです。 あ、あと弊社? で開発している FQC っていうコンパイラの後ろ部分(IL生成部分)があるので、こいつへのPullReqとかおまちしております。

ほかの言語

よくわからん。とりあえず、言語仕様書とGetting Startよめばなんとかなるだろという雑な扱い。 Javaは最新の言語仕様書読めていないし、C++はそもそもたいしてしらないです。言語仕様書がうすい言語は勉強しやすくてよいですね。(そうだろうか。。。)

Erlang

最近勉強しているのは、CoqからErlangの生成とかできるのではーと妄想して調べていたら、PPLでそんな話があったとかで、やっぱりそうなるよねー!っていう話をステーキたべながらしていた。 Erlangカッコイイなーってあこがれこそあれど、なかなかたくさんのコードを書こうとすると、なれがたりていないです。。。(静的型検査がないやつで、たくさんのコードを書くことにそもそもなれていないってだけです)

JavaScript

JavaScriptは僕にはむずかしいので、Vue.js でいいかんじにやっておしまいです。Vuejsの日本語ドキュメントすばらしい。課金したい。 一時期は、AltJSで生成すればなんとかなるとかおもっていましたが、JavaScript書くほうが楽な場面そこそこあるなーっておもっていました。 それもWebAssemblyでなんとかなるのかもーっていう夢がひろがってよいですね。

Java

Groovyを実行する基盤のやつ。ヴァルハラ〜。各プログラミング言語とかビルドツールがJava9にスムーズに対応できるのか不安。

OCaml

なごやで公用語のやつ。プログラミングの基礎っていう書籍でつかわれているしね。

いまだに自分はプロダクトにしろツールにしろ仕事でつかったことがないので、いつかつかってみたいとおもって幾年ってかんじです。 Emacs以外でいいかんじにつかえるIDEがほしいです。JetBrainsさんつくってくれませんかね。

Scala

東京で定番化?流行?しているらしい。個人的にはGatlingつかわないWeb企業ほぼないとおもっているので、Scala書いたことないWeb系の人いるほうが希少なのではーくらいにおもっている。

VDM++

形式的な仕様に憧れてさわってみたりしているものの、「おれがつくったほうがもっといいDSLつくれそう」というサイクルをとおして振り出しにもどる系の言語です。もう最近はVDM++でいいんじゃないだろうか。。。っていう気がしなくもないですが、B-Methodとどっちにすればいいんだーってなやんじゃいます。

ふりかえり

JetBrainsさんがいないと生きていけないです。

Java女子部でSpockの入門ハンズオン講師しました。 #javajo

Java女子部というコミュニティで2017/03/25に半日間のハンズオンでSpockというテスティングフレームワークの使い方を教えてきました。 Javaはだいたい書けるけど、Groovyとかよくわかりません!みたいな人に最低限のGroovyの使い方とSpockを教えるみたいな感じです。

javajo.doorkeeper.jp

すすめかたはだいたい次のような感じです。

  1. GitHubからソースコードをダウンロードしてもらう
  2. kyon_mmがスライドで概要をつたえる
  3. kyon_mmがIDEでサンプルコードをひらきながら解説する
  4. 参加者がサンプルコードのテストが失敗している部分を通るように直す
  5. kyon_mmがテストが通るようにコードを記述するのデモする
  6. Groovy/Spockの基本については2 - 5を繰り返す
  7. 解説がおわったらペアプロでTDDライクにSpockをつかいながらコードをかいてもらう

いわゆるKoan形式とか4clojureみたいなかんじといいますか、テストが通るように修正することで機能を学んでいくっていう感じです。

speakerdeck.com

github.com

スライドに誤解をまねくような表現がないように配慮したつもりですが、もし違っていたらツッコミもらえるとうれしいです。 Groovyの解説はJava8のまま書いても動かないところを中心にしました。

また、当日サンプルコードがいくつか間違っていたので修正したものをGitHubにあげています。

正規表現のところに // によってエスケープがなんたらというテストを最初書いてしまっていて、 動かなかったのは、文字列としてであって正規表現でのテストではなかったためです。現在のGitHubのmasterでは文字列のテストに移してあります。すみませんでしたー><

全体的には自分の知識が再整理されたとか、TDDとはなんだーとか、自動テストの考えかたとかいろいろ興味をもってもらえたのがとても勉強になりました。 呼んでいただいたJava女子部の皆様には感謝です。特に声をかけていただいた、あやさんありがとう! Java女子部はもっと怖い人のいるところだとおもっていましたが、みなさん優しかったですし、楽しい人達でした。 参加者のみなさまからも楽しかったと言ってもらえたので、やってよかったなーっておもえました。

今後も関わるのであれば、Java女子部でF#をつっこむのは難しいでしょうし、GatlingとかBetamaxとかGebでしょうか。

GroovyとかSpockまぢべんりな子なので、ぜひ使ってみていただけると嬉しいです。 また、スライドやGitHubはご自由に使っていただいて構いません。みなさまでSpockを愛でる方向で。

Enjoy Spock!