SEMATカーネル勉強会 第２回に参加してきました！ #sematj

ちょうど東京の用事と日程が重なりラッキー！ということで、SEMATカーネル勉強会へ参加してきました。
以下に資料もアップされています。

開発のよいやり方を形式値にして共有しよう！　〜パターンマイニングワークショップ〜
https://www.facebook.com/events/550763354987282/

パターンについての解説を聴き、ワークショップを時間オーバーの盛り上がりで行いました。
鷲崎さん、川口さんはじめ、みなさまありがとうございました。

パターンとは

パターンとは、
　特定の「文脈」で繰り返し起きる「問題」とその「解決」の記述
と定義されていました。
資料も見て頂くとして、ワークなどの中でポイントだなと思った点がいくつかありました。

• 「文脈」「問題」「フォース」をどう切り出すのか？
• 「フォース」は、理由に通じるところであったり、物事の仕組みであったりすることがある。手段や制約といったところであったりもする。
• 「問題」は「解決」によって変化するものである。

パターン候補の簡易マイニング

資料にも書かれている、
　経験的なコツや暗黙知を、言語化して形式知にしたもの
ですが、暗黙知をどうやって形式知にして再利用可能にするか、ということへの一つの解として、パターン形式で書いてみるというのがあるんだなと思いました。

チームでのワークで「パズル的な要素」ということがでました。パターンの種になりそうなものを「パターンの形式」に当てはめていく中で、「文脈」から「結果」までのスジが通っているような、いないような、しっくり来ない状態がありました。そこをチームのメンバーの経験などで「文脈」や「問題」などを当てはめていくと、いい感じにピースがはまったんじゃない？というものがでてきました。
パターン形式で書く過程において共有を行う事で、メンバーが共通的に考えているような形式に集約されていくんだな、という印象でした。
また、他のチームは具体的なパターンから抽象度の高いパターンに変わっていたというところもあったり、他のパターンへの展開がありそうという話があったり、いろいろ面白かったです。

パターンを使いやすい形に改善していく

というお話が川口さんからありました。
GoFのデザパタのように、いいものをまとめたもの、がパターンと思っていたので、これは重要だなと思いました。
確かに、いろいろなことをカイゼン、カイゼン言っているのに、これはいいものだから！、と思考停止しちゃ駄目ですね。
特にいろいろなところで揉まれたパターンではなくて、チームの中で出してみたものなどには、この視点が欠けたら駄目だなと思います。

パターンランゲージ

パターンでコミュニケーションが取れる、つまり言語としてパターンを使える、という話だったと思います。
パターンの中の「解決」について、より具体化した新たなパターンであるとか、関連性の話や、抽象度の話もありました。

SEMATとパターンの関連

SEMATのアルファは状態を捉えるものであり、パターンは文脈（状態）の変化を表現したものとなるため、パターンの「文脈」「結果」をアルファで表現できるんじゃないか？という可能性がある。
って、最後にチラッとお話しされていたのと、頂いた資料をみてずらっと書いてみました。
アルファの置かれる状態が定義されていて、その状態変化がパターンで表現されることで、具体的なプラクティスになるということかなと思いました。あってるかな？



パターンに関しても、勉強するのと実際にチームで使い、パターン化して形式知にしてみたいなと思う勉強会でした。
次回も用事が絡む・・・なんて可能性は低いわけですが、引き続き注目していきたいなと思います。

最後に、「ブログ書くまでが勉強会」パターン、どうでしょうか？w
　　　文脈：勉強会に出席した。
　　　問題：スライドや資料だけでは後々思い出せない事が多い。
　フォース：・人間覚えていられる事には限度がある。
　　　　　　・重要な事は資料や本などでも調べる事ができる。
　　　　　　・メモはそのうちなくなる。
　　　解決：状況や感想も含めてブログに書く。
　　　結果：振り返りが出来て思い出すきっかけとして残る。

第32回勉強会(2013/07/06) Githubハンズオン に行ってきました！ #nds32

第32回勉強会(2013/07/06) Githubハンズオンに行ってきました！
飲んでいるままで、感想ですw　＃思います多いww

（おもにデザイナー向け）やさしいGithubハンズオン

GithubのHands-onでした。

Windows版のSourceTreeがある、というところでしたが、非常に楽しめました。

My Page作るのがイマイチ分かってなかったので収穫でした。

今回は範囲外だよなあ、と思いながらRebaseの話があっても良かったかな、とか。

はじめてのnode.js

マージしてたら9割ぐらい聞いて（ry

ごめんなさいm(__)m

実録！勘違いが生んだ悲劇。〜えッ！？修正なんて聞いてないんだけど…。

リアル。まじリアル。

デザインの部分では要求定義って難しいなあ、と思います。

見える部分ということでお客様と合わせやすい、というよりも、出しても出しても見れば言いたい事がある、って感じ。

契約とかの話もでましたが、それことトリアージみたいなことが重要なとこだと思います。

高校生長岡ラーメン選手権の告知

チラっ、チラっ（-- #YAuth

Keynote+Gimpでアイコン作成

 興味深い内容でした。
アプリを作るときのアイコンとか、”アイコン 商用利用可 改変”、"Icon Createvie Commons"とかググってる自分としては、フラットデザイン！www

Rでダイエット

Rといえば、統計、ぐらいのイメージでした。

実際、統計だったんですけど、食わず嫌いでした、すみません。

シンプルに情報の偏りを出すあのデモは、衝撃的でした。

言葉だけのビッグデータ、DWHではなく、アカデミックなところでのRは非常に落ちるものがありました。

VCS入門

お世話になってますw

NDSの（ry

プロジェクト・アンブレラ、まじリスペクトです。@civicさん。

懇親会

楽しかった！

自ら行動する技術者についての首都圏と地方における違い

JaSST'13 Tohoku の情報交換会で、そんな話題がありました。で、地方を盛り上げていくにはどうしたらいいのか？という感じ。
参加者からの質問がきっかけでパネルディスカッションのお題になったものでした。具体的な質問は失念orz

追記： @leecom さんから質問を教えてもらいました。ありがとうございます！「大都市圏ではない国内各地域のIT技術者・管理者がもっと元気に、より高い成果をあげるために自ら行動するようになるには何が必要でしょうか？」でした。

首都圏だからといって「自ら行動する技術者」の割合が多いわけではない、という意見。母数の大きさから大勢いるように見える。
そこから、母数の大きさから実数が多くなる事で、「なにかをしたい」というときの始めやすさ（勉強会するにも人数が集まるとか）はあるのではと。
また、同様の理由で、自発的な行動へとつながる「刺激」が多くなるのも首都圏の利点ではないかと。

組織内でも「刺激」の多寡がある。１０ウン年同じ領域の同じ仕事をやり続けているベテランにとって、「刺激」の重要性は低く同じ方法で同じく仕事を回す事に重きが置かれる。
そのようなところに、例えば新人が配属されたとして「自ら行動する技術者」になる「刺激」を享受する機会は少なくなるのではないかと。
反面、地方ではやる気のある人で集まって勉強会などを行うから母数の多い首都圏と比べて、議論の密度は濃いのではないか？という話も。

JaSST'13 Tohokuでの議論を正しく捉えているか、が心もとないのですが、こんな話があったと記憶しています。


ここからは私の感じている事です。
新潟にいる私は、「地方」にいる技術者です。丸１０年ほど開発に携わっています。
私は、「刺激」があるだけでは不十分で、「きっかけ」が必要ではないかと思います。
現在、「刺激」を受けることはインターネットの普及なんて大昔という勢いで、むしろ取捨スキルが必要なぐらい、刺激多すぎと言う状況ですw
しかし、その「刺激」を軸に自ら行動へとつなげる「きっかけ」は、また別のところにある気がします。

私の場合、ソフトウェアテストPRESSが初めての「刺激」だった気がします。そこからテストについて興味を持ち、自分の視野の中での「開発」について疑問を持ち、アジャイルといったテスト以外のことへも興味を持ちました。直交表、XDDP、USDM、マインドマップ、Redmine、Hudson（Jenkins）、xUnit、あげればきりがないです。
しかし、本とネット、自分の周りでの実践というところから外へ出ることはなかったです。頭にはなんども「新潟で勉強会があればいいのに。東京はいろいろあるよなあ」と思いながらもです。

私にとっての「きっかけ」は、JaSST'11 Niigataでした。あの、JaSSTが「新潟」で！、って有給とって行きました。スエットでw
それはもう「刺激」を受けました。なんか違うんですよね、本とかネットとかだけでは感じれないものがあると思います。
そして、@3rd_Violin さんに乗っかって、すわにいが始まりました。今も続いています。
最近はNDSにも参加したりしました。そして、あのTDDBCが、「長岡」1.0で！wも参加しました。

でも、まだWACATEは行った事無いし、Agile Japanも行った事無いし、JaSST Tokyoも行った事無いです。shinagawa.redmineも行った事無いです。
今でしょ！なのかもですが、やっぱり時間も金もかかります。
今の私には、「行きたい！だがしかし」ですが、昔の私には「新潟でもあればなあ。。いやない。」だったわけです。
そういうところが、「地方」にはあるんじゃないかなあ、と思うわけです。
私の内向きな性格が反映されているのでw、地方の人みんながこんな感じで考えてるわけではもちろんない（というか反例はいくらでもあるw）ですが、こんな封に考えてるのって私だけかな？


今回は第二の故郷wってことでJaSST'13 Tohoku行きましたが、やっぱり行ってよかったなあ、と思ってます。
新潟も、「NDS」に「すわにい」といろいろな「きっかけ」の場があるって、最近やっと気がつきました（ちゃんと検索しろ＞俺w
「行きたい！だがしかし」の自分のためにも、少しでも新潟に「きっかけ」の場を作れるようにと、そこに集まった人たちと「刺激」を受け合う事ができたらいいなと、改めて考えた次第でした。

JaSST'13 Tohokuに参加してきました！ #jassttohoku

JaSST'13 Tohoku（以降JaSST）に参加してきました！
新潟以外のJaSSTは初参加。コミュ症なんでドキドキでしたが、すごく楽しい一日になりました。
@nnasaki さんが、Togetterで当日のつぶやきをまとめてくださっています。
というわけで、感想をつらつら。

午前の勉強会

JaSSTは午後からで、午前中は東北デベロッパーズコミュニティ（TDC）の「ソフトウェアテスト勉強会（番外編）～レッツ！テスト！～」に参加しました。
@kitanosirokumaさんが、講師としてお話しされながら、実際に使われているWebサービスに対して、チームで探索的なテストを行うというワーク形式のものでした。実際に動かしてバグを見る、というのは非常に面白いし、JaSSTの中でも触れられていた、「達成感」を感じる事ができ、いいお題だなあ、と思いました。
特にポイントだと思ったのは以下。

• 意図をもってバグを狙う。それによって、見つかっても見つからなくても次につながる。
• できるだけ情報源を使い切る。

情報源としてソースもあったので、私ソースみたいです！って、ソースから重大バグ探しをしてました。
Railsわかんねww、って感じの時点で切り返した方が良かったかな、と後で思ったりもしました。

最後にチームごとに一番重大だと考えたものを発表して、その中でも重大だと参加者が考えたチームに送られる「ネモリン賞」を頂きました！
そして、おいしいお菓子を頂きました！やったね！w

午後のJaSST

そしてJaSSTです！とりあえず、タイムテーブルはこちら。

基調講演：「開発を楽しくするソフトウェアテスト」　@yumotsuyoさん

命題的な講演でした。テストに限らずソフトウェア開発の現場では、楽しく開発をするということが「目指す」になっている現状があると思います。
まあ、仕事だから楽しい事もあれば辛い事もあるのは当たり前なんですが、そこで思考停止してたらいかんですよね。
日頃から考えている事に対しての一つの視点という意味で、非常に楽しく考えながら聞きました。
特にポイントだと思ったのは以下。＃書ききれない。。。

• 出来事 -> 考え -> 気分 という思考の流れ。
• 「楽しい」の意味、仕掛け。達成感。ゲーミフィケーション。
• 全員の立場でのソフトウェアテストに向き合う。
• テスト対象に対して、ユーザーの視点から論理的に分解していく。
• やるってきめたらやる！

事例発表1：「ソフトウェアテストの7原則とゲンバで向き合う」 @snskさん

もう、ほんと、ね！って、感じでした。
「ソフトウェアテストの7原則」について、経営層・マネージャが知るべき事、現場の技術で達成できる事に分け、それぞれへの対策を示されていました。私、JSTQB FL持っているのに、７原則知らない時点で終わって（ry

• 自然の法則！
• 品質モデルからトレーサビリティが取れるテストを考える。十分性の条件。品質モデルを決めることが重要。
• 初期からチームを組織しなくても、テストリーダーが一人だけでも最初から開発チームに加わるべき。もっとテストに関して開発の計画段階から考えるプロセスが必要だと感じました。

事例発表2：「SeleniumとJenkinsではじめる受入テストの自動化」　@masanobuimaiさん

最近Web系に手をつけているのでSelenium気になって、実はこれを聞きにきた、という感じでした。
動画でのデモもあり、イメージが掴みやすかったです。

• SeleniumIDEでアサーションまで入れれる！これは知らなかった！
• Seleniumのクセがあるとのこと。万能でないってのは、どんなツールでもそうですよね。
• 意外にJenkins、Seleniumを知らない参加者が多かった。これは本当に意外だった。
• JenkinsのSlaveもこんなに簡単に作れるのか、という感じ。
• というわけで、やるしか！

ライトニングトークス

それぞれ味のある面白いトークでした。

• このLTが黒歴史wwww

テスティングライブ：「テスティングライブ～新人K　初めてのテスト～」

非常に斬新な企画でした。もう、なんというか、面白かったですwww
とても言葉では表せないですが、とりあえず演技には見えなかったwww

情報交換会：「ゆるパネ」

JaSSTの申し込みアンケートの質問にパネリストが答えるという形で進行・・・なんだけど、ゆるい？ゆるいの？www
とてもアツい感じでした。

懇親会

なかなか自分から口を開くのが苦手なんですが、大学の後輩の @hinac0 と酒が入ると少しは口が回るようになる体質のおかげでw、いろいろお話しできて楽しかったです。
@hinac0 からもSeleniumの話を聞きたかったので、自動化の話ができてよかったです。
バスの時間で帰らないとだめだったのが、残念。。。。

というわけで

ほんと楽しかったです！
みなさまお疲れさまでした！

JavaScript+QUnitでTDDしてみた。

TDD Boot Camp 行ったので復習を兼ねて JavaScript で TDD してみました。
なんでC言語でやら（ry

お題

JQueryを使ってFizzBuzz、にしました。
ちなみに、JavaScriptはわかりません。Google先生に誰が知ってるか聞きました。
JQueryもわかりません。Google先生に誰が知ってるか聞きました。
いろいろ調べ過ぎてどこみたかも不明ですが、ツイート参照ということで、先人に感謝。

準備

環境は QUnit + Eclipse + JSDT Plugin という感じでやりました。
jsTestDriver を使おうとしたのですが、うまく行かず、テストの実行自体はブラウザです。
JQueryはダウンロードしてきて、main/js/external/ というフォルダを作っていれました。

QUnitの準備

QUnit は npm で入れました。package.jsonを作ったので、PJルートで以下のコマンドでインストールされます。
/node_modules にインストールされるので、そこのパスをみるように実装しています。

$ npm install

テスト実装のHTMLは /test/html/runner.html です。
基本的にはオフィシャルをみれば分かる感じでしたが、 #qunit-fixture のdivタグの中に、評価条件のHTMLを入れるというのがポイントでした。
テストコードの setup() でタグを置き換えても良さそうでしたが、今回は複雑ではないので固定にして、プロダクトコードの body と一緒にしています。
ちなみに、 #qunit-fixture の divタグ内は、テストケースごとに初期化されます。

この状態でブラウザで runner.html を開いておいて随時テストを実行します。

TDDをやった経過

TODOリストも随時コミットすれば良かった・・・と思ったのは後の祭り。
でも、最終的なものをコミットしています。
Red -> Green -> Refactoring の流れのうち、Red -> Green でコミット、 Refactoring でコミットを基本にして、 Red -> Green -> Refactoring でコミット、大きなリファクタリングでのコミットと、ログで経過が追えるようにしました。
仮実装、三角測量といった TDD Boot Camp で体験した事を意識してやりました。

気になるポイント

• ”Refactors that Expected exchanges Result.” のコミットで修正したのですが、 QUnit では (期待値, 実測値) ではなく (実測値, 期待値) なんですね。
  ちゃんと調べてやらないから（ry
• そもそも大きくないコード量なのですが、”Refactors selecting colors.”のコミットは、if文がちょっと・・・でリファクタリングしたのですが、なんかもっといい方法がありそうな？
• HTMLからのイベント（onClick）、表示を扱うViewModel（fizzbuzz_vm.js）と、fizzbuzzのロジックを扱うModel（fizzbuzz.js）に分けて作りはじめました（最後までそうなのですが）。MVVMって言葉に憧れてwこういう名前にしただけですが、イメージ合ってるのかしら？
• モックを使う必要は今回なかったですが、ModelとVM分けたのでテストを書きやすくなった、というかテストすべき範囲がはっきりした感じはしました。
  Modelの振る舞いという視点と、操作とそれをきっかけにした表示更新という視点で分けやすくなりました。　＃当たり前？

残課題

• 折角の JavaScript なんで BitBucket 上で動かしてみれるようにしてみたい、、、、と index.html を入れてみたんだけども動かず。
• jsTestDriver がイマイチうまく動かず。Phantom.js での CI 以外にも各ブラウザでテスト実行できるのは良さそうなので、もうちょっと調べてみたいです。

最後に

やっぱ、TDDいいです。楽しい。TDD Boot Campバンザイw

TDD Boot Camp 長岡 1.0に参加してきました！ #tddbc

TDD Boot Camp 長岡 1.0に参加してきました！
ずっと参加してみたかったTDDBCが長岡で！、ということで飛びつきました。
長岡での開催にアクションして頂いた @masaru_b_cl さん、講師の @t_wada、TAのみなさま、協賛のNDSのみなさま、本当にありがとうございました。

時系列で心に留まったところをメモをみながらピックアップします。

自己紹介

• みなさんの自己紹介。県外から参加されている方もいました。
• 学生さんから普段はPMをされている方まで、幅広い人が集まっている印象でした。

Keynote

• @t_wada さんのキーノートからスタート。
• 「現代ソフトウェア開発の三本柱」として、VCS、テスティング、自動化のお話。関連して頭に浮かんだのが、VCS、ITS、CIという三種の神器でした。ITSの位置づけも重要だけど、３脚椅子のメタファーを４脚椅子にすると足を一つ削っても結構安定するから駄目だな、って思いましたw
• 「テスト」という言葉の捉え方について。Developer Testing, Customer Testing, QA Testingという分類で説明され、TDDの文脈ではDeveloper Testingが該当。テストに関する用語の標準化という意味ではISTQBの用語集もあります、ってツイートしました。
• TDDのこころもち、というお話。なるほどなあ、という感じ。サイクルが1分 -> 1分 -> 2分というのは衝撃的でした。
• TDDの真の目的は健康。健康なコードと健康なチーム。健康第一ですよね！

ペアプログラミングによるTDDデモ＆写経タイム

• 写経タイムだ！と思ったのに、CppUTestでやろうと思ったらEclipseではまってついていけずorz
• ペアとは終始話をしながらやっているなという印象。沈黙がない感じでした。
• アサートファースト。テストケースの後ろから書いていくことで、テストも見やすくなるとのこと。
• 仮実装、三角測量といった方法。なるほどなあ、という感じ。

ペアプログラミングによるTDDハンズオン

• @bei_kan さんとC言語＋CppUTestでハンズオンしました。ありがとうございました！＞べいかんさん
• ペアプロではキー配列とかショートカットとかが普段と違うと大変だと痛感。私のPC（MBA）でやらせてもらったので、私はよかったですが、ペアのべいかんさんには不自由をおかけしちゃいました。
• そして、久々すぎるC言語ですっかり忘れている・・・・からのでしたorz
• 初のペアプロでしたが、いわゆるペアプロの効用といわれていることを実感できた感じがしました。そして、とても楽しいけど疲れる（＾＾；
• リファクタリングするとコードが本当にきれいになっていくし、振る舞いがかわればきっちりRedになるし、もうなんていうか、楽しい！　大々的にリファクタリングする場面があったのですが、あのときテストが通ったのはキターーーー！でしたw
• TODOリスト大切ですね。道しるべになって達成感が生まれました。
  

レビュータイム

• 各言語のペアからLT形式で感想とコードの発表。
• テストケースの粒度がやはり言語、ペアによって差があるなと思いました。クロージングでもでたテスト技法のあたりだったり、テスト設計だったりをこころにとめておくと、変更に強いテストコードになるんじゃないかな、と思いました。

クロージングセッション

• 最後に @t_wada さんのクロージング
• TDDの効果に関する数字的なところの紹介。
• TDDによる欠陥密度の低下と実装時間の増加、開発時間が短くなっているというアンケート結果、デバッグの仮説検証プロセスを短くすることで工数が見込みにくい部分を少なくできる、などなど、なるほどなるほどでした。
• 「こんなとき」の足がかりになる本の紹介。技法ドリルの本が出てきたときには、よし！と思いましたw
• グリーンバンドの話。そう、プロフェッショナルですもん！

その他

• 懇親会には残念ながら参加できず。。。
• グリーンバンドゲット！
• やっぱり、コード書くって楽しい！

という感じで、時間をみてお題をもう一度TDDで書いてみたいなあ・・・と思ってます。

Redmine XLS Export Plugin で Iconv::InvalidEncoding

掲題のエラーになる、とのチケットが発行されました。
BitNami Redmine Stack使われてますねえ。
https://github.com/two-pack/redmine_xls_export/issues/23

エクスポート時にspreadsheet内でIconvを呼び出しているところが該当箇所でした。
UTF-8 から UTF-16LE の変換で失敗しています。

Iconv::InvalidEncoding (invalid encoding ("UTF-16LE//TRANSLIT//IGNORE", "UTF-8")):
spreadsheet (0.8.5) lib/spreadsheet/encodings.rb:38:in initialize'

spreadsheetを調べてみるとruby 1.8と1.9で処理が分かれていました。
1.9.x以上はString#encodeメソッドなどで変換してます。
1.8.x以下は、Iconvを使って変換しています。
今回問題が起きている環境はRuby 1.8.7でした。

そもそもUTF-8でないデータが渡ってきてるのでは？？と思いBitNami Redmineでの文字化け情報がないかなあ、、、と調べたら以下がありました。
これによると、データベースはずいぶん前からUTF-8になっているようなので、大丈夫そうです。。。
■[redmine]bitnami::redmine で文字化けしなくなった！

他を調べると以下のようなものもありました。環境問題っぽいのでそれで終わりにしました、、、なのか？w
http://stackoverflow.com/questions/4965796/convert-utf-8-to-unicode-in-ruby