RE:統計的品質管理の功罪 - うさぎ組
概要 SNSで『統計的品質管理の功罪』というスライドについての意見を多数みかけたので、僕も読んでみたので感想を書きます。 ゆえに発表場所では多くのコンテキストが語られているかもしれませんが、スライドからはこう読めるよっていう感じです。 僕の感想は一言でいえば「タイトルは違うほうがいいし、SQCの勉強してないですよね？よく言えますね。」って感じです。 お酒飲みながらのLTだったらありかもーくらい。 もしSQCに村を焼き払われたという事情があるのであれば、SQCを徹底的につぶすくらいの非難なり、手法なりもってくるほうがよいのではないでしょうか。 つまり、マサカリ投げるなら徹底的に投げろ。 発端や背景 SNSで下記のスライドに対する言及が多数ありました。 統計的品質管理の功罪 from 工 久納 "辛いよねー"と共感するか、"コンテキスト広く言いすぎじゃないか？"と批判するかの2つが多かったよう
2014年に読んだ技術書で良かったもの - うさぎ組
概要 新刊にかぎらず、今年読んでいて「あー、良書だなー」って思ったものをあげています。これ、ダメじゃないの？とか、あー、やっぱりこれいいよねっていうコメントもらえると嬉しいです。 基本は、.NETにおけるWeb APIやFW開発でQA * POな人が思う良書です。今年は技術書より論文、言語仕様書、実装を読んでいることが多かったので、去年の半分の30冊くらいしか読んでいないかな。 開発チーム系 エッセンシャル スクラム 作者: Kenneth S. Rubin出版社/メーカー: 翔泳社発売日: 2014/08/01メディア: Kindle版この商品を含むブログを見る スクラムなんとなくわかっているんですけど、自分以外の状況よくわからんしなー、進め方変じゃないかなぁっていうときに、読むとめっちゃ参考になります。 組織パターン 作者: James O. Coplien,Neil B. Harri
Webアプリケーションのパフォーマンステストを勉強する方法 #SWTestAdvent - うさぎ組
はじめに これはソフトウェアテストあどべんとかれんだー 2014 の14日目の記事です。 明日は id:kokotatata さんです。 概要 パフォーマンステストを入門するための情報を紹介します。発端は@ryushi さんが次の記事でなにやら不思議な言及をされていたというところです。 正直に申し上げて負荷テストって恐ろしく難しい種類のテストなんですけども、特にその難しさについては書いていませんので、きっと名古屋辺りのうさぎさんが補足資料を提示してくれるでしょう。よろしくお願いします。 注意 ここにあるのはkyon_mmの私見です。なので、「なに、こいつ大げさだな。。。」とか思ったらコメントで「それはお前が勉強不足だからで、世のエンジニアの感覚と違います」とか書いてください。温度感重要です。 参考書籍 基本的にはこれらを読めばいいのかなと思っています。この記事で書くのはこれらで言っているこ
Web API The Good PartsはWeb API開発必携の書籍でした。 #apijp - うさぎ組
はじめに これはWeb API Advent Calendar 2014の二日目の記事です。 明日はid:nobusueさんです。 概要 これはWeb API The Good Partsという書籍の感想です。Web API開発に関わる人なら必ず読んでおいたほうがいいでしょう。ここ3年くらい「URI設計はどうすべきなのか」「APIバージョンはどうすべきなのか」「続きのデータをどのように取得すべきなのか」などについて綺麗にまとまっています。 最後にWEB API開発やレビューで使いたいチェックリストがあるのも素晴らしいです。 Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 全体 本書はWeb APIの設計、実装、レビュー、運用について細かく書かれていま
週刊ソフトウェアテスト 2014-創刊号 #swtest_jp - うさぎ組
前書き ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。創刊号なので、若干時期が広めになってるのと、選択基準がまだハッキリしていない部分もございます。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！ Summary CIaaS(CI as a Service)のCircle CIに無料のプランが追加されました。個人的には、CloudBeesの無料枠からの移行組をとろうとしているのかなぁ？と感じました。 HTTPSの無償利用が実現に向けて動き出しました。実現すれば、HTTPSのテストをしづらかったたくさんの開発チームが救われそうです
テスト戦略のたった3つのチェックリスト - うさぎ組
本稿はSoftware Testing ManiaX vol.9に寄稿したものになります。ご興味ある方はJaSST、WACATE、コミックマーケットに参加して買ってみてください。 さーくるWACATE ちなみにkyon_mmの心情的にはだいぶ押さえて書いています。本音を言えば「なんですかそのテスト計画？昼寝しながらでももっといいの書けますよ」「訓練をしないで戦地に向かうことに恐怖を覚えないなら、いますぐこのマサカリを首にかけてやる」って気持ちを必死におさえて書きました。偉いです。自分をほめたいです。 そういう雰囲気で書いているのであまり整理されていない内容ですが、皆様の何かのご参考になればと思います。突っ込み歓迎ですが、こういった文章ですのでface2faceだとコンテキスト共有しやすいと思われます！ はじめに ソフトウェアを開発していくなかで、品質を考えるということは非常に重要なことです
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
「今夜、Webアプリの正しいUIテストの方法が決定されます」に参加しました - うさぎ組
ずいぶんと前のイベントですけど、参加してきました。 今夜、Webアプリの正しいUIテストの方法が決定されます : ATND 楽しかったかと言われると微妙なんですが、知らないツールとか知れたのはよかったかなぁと思いました。たぶん自動化に拘っているからあまりいい意見が出なかったんだろうなって思いました。もっと、UIレイヤのテストエンジニアをガツガツあつめて話させたら面白かったのでは。という気がします。「このUIの手触りっていいよね」とか言えるテストエンジニアを。 youtubeが公開されています。2本目の41分38秒あたりでid:kyon_mm(僕)が質問しています。あと、当日は英語なのをいいことにバカスカ言いたい事をtweetしてました。たぶん、Togetterとかにはのっていないはず。 第10回 html5エンタープライズナイトセミナー（講演編「UIテストの自動化は何が良いのか、どのよ .
ソフトウェア開発では出来るだけ言葉遣いに気をつけよう。さもなくばマサカリを受けろ。 - うさぎ組
はじめに 言いたい事はわかるんですけど、ふわっと言葉を使っていると間違っていることもあります。 ということで、ほとんど自戒なのですが、今や私も気になる部分は多々あるので、私が思う気を付けたらいいよっていう言葉のリストを以下にあげます。気をつけましょう。 なお、本稿では実際の定義は皆様に調べていただく方向ですので、書いておきません。これ調べたらいいよ的なガイドワードくらいです。 証明する 例えば「このテストによって証明されている」これやばいですね。 テスト界隈からも証明プログラミング界隈からも数学界隈からも目を付けられます。 少なくともそれはなごやに囲まれる事を意味します。 基礎 書籍や記事やイベントで「基礎」とみかけますが、結構な割合で入門と勘違いしているケースがあります。それはよくないです。基礎 と 入門は違います。入門向けな予定なのに、基礎と書いたがために、こわい人たちが大挙した勉強会
僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組
昨日、@irofさんと飲みながら自分を思い返すと「ちゃんとソフトウェア開発を勉強しはじめてから3年間たった」つまり「@bleisさんを知ってからこの5月でまる3年間たった」 それまでの僕はデザインパターンもオブジェクト指向がなんたるかも、バージョン管理もなにも知らなかった。 毎日言われたことをこなす仕事をして、変えたいけど誰も教えてくれないし、学び方すら教えてくれなかった。 それなりに努力してたけど、よくはわかっていなかった。 そんな状態から抜け出したのが3年前。このブログの先頭でも書いた。当時僕は21歳かな。（ちなみに就職したのは19歳のとき） →【このブログをはじめるきっかけ - うさぎ組】 この3年間でやったことをふりかえってみようと思いました。 ちょっとわかりにくいだろうけど、2009年5月からの12ヶ月周期で書いてみます。 こうやって振り返るのはあくまで僕のためであって、何かを誇
プロジェクトに計画はあるのに、設計はないのだろうか？ - うさぎ組
昨日、PMI中部の勉強会に参加してきました。 【3月27日 「本当にPMは育成出来るのか？」(PMIJ中部 3月度定例会)(愛知県)】 その日いろんな意見を交換したり、懇親会でもたくさんの話を聞いていて疑問がでました。 「プロジェクトにはプロジェクト計画というものがあるのに、設計や実装といった言葉がないのはなぜなのか」 僕の意見も含めてその場で出たのは「チームビルディング」や「WBSの作成(PRODUCTバックログの作成)」などがそれにあたりそうだけど、ハッキリとはわからない。といった感じ。 経緯 なんでこういう疑問が出たかというと、大きくは2つあります。 計画という言葉があると、テスト戦略 -> テスト設計 -> テスト実装 -> テスト実施 と思い浮かんだので、プロジェクトにはそれがあるのか気になった。 本会での話で「目的を伝えきれずにタスクだけを渡してしまうことがあり、PMが行う目的
プログラマーが「テストを書く」といい、テストエンジニアが「テストをする」という理由について - うさぎ組
以前にGistに書いていたのですが、忘れそうなのでリンク貼りつつ、転載しておきます。 【プログラマーが「テストを書く」といい、テストエンジニアが「テストをする」という理由について.md】 はじめに ここに書かれているのは、「主目的」であって、プログラマーもしくはテストエンジニアが「他のことを考慮していない」という意味ではありません。あと、僕の解釈なので一般論というわけではないないです。 プログラマー：「テストを書く」 プログラマーは基本的に「テストを書く」というと思います。実際に書いているんですけど。これ、手動テストしかなかった時代は、どうやって言っていたのかわかりませんけど、これは非常に的を得ていると思うのです。プログラマーの主眼は「要求を設計し実装すること」にあります。そしてその意志はプロダクトコードとなって表現されます。そう、プロダクトコードというのは、表現手段なんです。なので、彼ら
Groovy基礎勉強会開催報告 #GroovyBase - うさぎ組
イベント募集ページ：【Groovy基礎勉強会 - connpass】 Togetter：【2013/03/09(#GroovyBase)Groovy基礎勉強会 - Togetterまとめ】 スライド The History of Groovy #GroovyBase from Kyon Mm 感想 名古屋以外での基礎勉強会は初めてだったのですけれど、無事におわってよかったです。 JGGUGの方達をはじめとして、たくさんの方にご支援いただいてうまくいきました。 僕はGroovyのザックリとしたお話を発表という形にして、個々のGroovyの基礎について他の発表者が担当してくださいました。 僕はちょこちょことGroovyを2年くらいつかっている感じなので歴史と言っても経験があるのは1.7.xとか1.8Betaくらいで、それ以前の情報はブログとかがメインで調べた感じです。 実際に1.7.xの頃にグ
#HDIfes でテストの入門的な話をしてきた。 - うさぎ組
イベントページ HDIfes #01「価値のためのテスト」 - HDIfes UXDx開発xゲーム 情報交換会 | Doorkeeper スライド http://goo.gl/vWaF3 イベントについて イベントページみてください。 発表の感じ 先人が作り上げて来たソフトウェアテストや品質といったもののエントリポイントをいくつかとりあげてみました。 テスト系の人がいない中で、テストの話をするというのは結構チャレンジングでした。 今回参加した人達がソフトウェアテストについて共通して悩むとしたらテストがうまくいっているかいないかの基準がわからないといったことだと思い、それらの助けになるようなテストの手段以外のところを出来るだけ話として盛り込みました。 他の人達の発表がテストの手段(発表内では目的や効果についても言及されていました)の話が多かったのでバランス的には少しとれたのかなぁと思います。
Enterprise User eXperience Designに参加してきた #devlove - うさぎ組
ものすごい久しぶりな気がするDevLOVEに参加しました。 前に参加したのは2011/04あたりな気がします。というか、2回目ですかね。 Enterprise User eXperience Design -ユーザー中心設計の実践 - - DevLOVE | Doorkeeper papandaさんとご挨拶 僕から一方的に知っているだけだと思ってた@papandaさんから認知されていたようです。 きょんくんを知っているとはマニアックでございますね。Scrum道Expoで発表を聞いたのが直近な気がします。 講演 どんな内容かはTogetterとスライドを見てもらうのがよいかもしれません。 slide >日立ソリューションズのUX向上施策 http://www.hitachi-solutions.co.jp/forum/download/tokyo.html Togetter >2013/01
TDDの自殺 #kyon_mmAdvent - うさぎ組
はじめに 僕は熱心にTDDを勧めているエンジニアです。 ですが、この2年でTDDが銀の弾丸ではないことも気付き始めました。 その気づきの一つがこのTDDの自殺です。 先にFacebookで投稿したところ、評価をもらえたので投稿します。 「読み手を選ぶエントリーです、(`・ω・´)ｷﾘｯ」 これを読んで「kyon_mmも落ちたものだ」と思ってもらっても構いませんし、「迷惑な話だ」ということであれば僕に猛抗議をしてもかまいません。 TDDとはなにか TDDは開発者を支援するフレームワークと定義します。 TDDは「開発者の意図を確認すること」「開発者が心地よいコードを書き始める事」を支援するフレームワークです。 TDDの基礎 TDDを支えるものとして次の要素があります。 客観的で頻繁にも実施できる検査群、確認し易い検査結果群、RED,GREEN,REFACTORのライフサイクル。 これらによって
うさみみエンジニアが2012年に買った技術書 - うさぎ組
追加 2013/01/01 ここから 僕の読書方法Togetter 【うさみみさんの本の読み方 - Togetterまとめ】 (2012年の【僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組】のときに「どのように読書しているか」への質問ツイートへの返答をまとめたもの) 追加 2013/01/01 ここまで なんかTwitterでつぶやいたら気になるとの事だったのでのっけてみます。 （個人的には他人のが気になるので、これを見た人が自分のを公開してくれるとうれしい とりあえず、新しく買ったり、借りたりして読んだ技術書は全部のっけます。 2011年に既に買っているものは省いています。 その中でもいいなって思ったのは前半で括りだしてみました。 「いいな」っていうのは「今の自分にぴったりだったな」っていう意味で良書かどうかはまた別かもね。 うさみみ的によかった新しく読んだ書籍たち
Groovyは衰退しました #gadvent2012 - うさぎ組
G* Advent Calendarの9日目になります。 G* Advent Calendar 2012 : ATND 前はid:touchez_du_bois さんのAST変換の無駄使い - とある技術の謹書目録です。 次はid:fumokmm さんです。 マニアックな話を書きます。とATNDに書いたのですが、高度とかではなくてですね。誰も書かなさそうなものをちょこっとかいてみようかなぁと。 タイトルに特に意味はない。という元ネタすら知らないです。（おい あ、以下の文章はGroovyをdisっているように見えるかもしれません。disっているので気にしないでください。Advent CalendarでまさかのGroovyDis。。。 でも、僕はGroovy本当に大好きです。 I Love Groovy!! Groovyの静的コンパイルがイケてない Groovyは2.0になり静的コンパイルがで
ソフトウェア開発で見積もりのための定量化はできないんじゃない？ - うさぎ組
素人がそう思ったよ。間違っていると思うよ？入門しようと片足つっこんでいるときの独り言だよ？的な。でも、こう思っているよ？的な。 メトリクスとかをふくむ定量的なデータは傾向を測るものであって、特定チームの特定期間にしか使えないというもとに活用出来ると思った。 根底にあるのは「僕は1年前と同じようなコードは今では書かない。」のような「以前よりもっと綺麗な設計/実装ができる」というのがあります。 だから、例えば行数でも相対値でも違うものになる。 行数：コードの行数。コピペがないコードだとしても設計方針でまるで違ってくる。 ストーリーポイント：実現するための相対的なコスト見積もり。 他にもいろいろあると思うんですけど、きっとどれもが他人(成長する前の自分含む)と比較しにくいものだと思うのです。常に変化していく。 例としては(経験による感覚)、5,6人以下固定チームで2ヶ月目から9ヶ月以内くらいのチ
わかめのモナド浸し(モナドカンファレンス) を開催します。 #わかめモナ化 - うさぎ組
イベント申し込みページ「わかめのモナド浸し -モナドは悟りを開くのか-」 【わかめのモナド浸し - connpass】 きっかけ 以前から@j5ik2oさんとTwitterで「モナドのイベントやりたいですね！」って言っていていつやろうか迷っていました。 するとTwitterで わかめちゃんを名古屋に呼んでモナド漬けにする会まだー 2012-10-04 15:32:45 via Tween 「あぁ、これは@vvakameさんの口癖をモナドにしてしまうようなモナドだけのイベントやればいいのか。そうか。」という発想にいたり、募集ページたてました。 イメージ-> @vvakame 「プージャでカレー！それとモナド。」「モナドかわいいよ、モナド。」「JSXのパースむずかしいなー。モナド。」「名古屋楽しかった！モナド！」 みたいな。 @j5ik2oさんも参加してくださるようです！@j5ik2oさんはS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
