2013/1/27(日)「第33回 館山若潮マラソン」に参加してきました。
公式サイト
http://www.tateyama-wakasio.jp/index.shtml今回もエントリーはもちろん、フルマラソン！（42.195km）
去年は初マラソン含め、フルマラソンを３回走り、すべて完走できました。
そしてその初マラソンが、この館山若潮マラソンだったのです。
風景が素晴らしく、運営もスムーズで、沿道の応援も多く、とても素晴らしい大会なのです。
ただ、今回は12月に引っ越してから環境が変わったこともあり、ほとんど練習できてませんでした。
また先週は深夜0時前後の帰宅が何日かあって、かなり疲弊もありました。
ということで、今回はモチベーションも上がらず、完走はムリだろう、と薄々思っていました。。。
そして当日の大事件！
なんと、両国駅発―館山行きの館山若潮マラソン臨時特急が、まさかの信号故障で2時間遅延！
館山駅の到着が、マラソン受付終了の9時に間に合わないどころか、スタートの10時さえ間に合わない始末。。。
一気にモチベーションがダウン、この時点で完走はさらに遠のいた。。。
一応、主催者側の配慮もあり、遅延組の第二スタートが10:50に新設されました。
更に、関門の時間制限も撤廃してくれたし。この配慮は主催者側のファインプレーですね。
マラソンは警察の交通規制とか、数千人規模のボランティアによる運営などから成り立っているんですが、
主催者側がよく臨機応変に対処してくれたと思います。
ということで、約2時間遅れの10:05くらいに館山駅に到着。。。
もうフルマラソン、10:00にスタートしちゃってるなぁ、と残念な気持ちになりながら、急いでシャトルバスに乗り込みました。
会場に到着後は急いで受付を済ませ、荷物を預け、トイレを済ませ、ナンバーカードと計測チップを装着し、、、
と、慌ただしく準備。
以下はそんな中で撮影した会場の風景↓ テントとかシートとか、いろいろありますねー
そして、なんとか、10:50の第二スタート開始時刻に超ギリギリ間に合いました。
↓は10:50第二スタート組のスタート地点。マラソン臨時特急の遅延組がこの前にも後ろにも多数います。
この時点で、今日は完走は諦めました。。。特急遅延のせいで、モチベーションは急降下。
雰囲気や風景を楽しみながら行けるとこまで行こう、と、目的を切り替えました。
今日はハーフマラソンのつもりで。
今日は素晴らしい快晴で、なんと富士山が見えました。
スマフォを持って走ったんで、激写。このマラソンは海辺を走るんですが、絶景です。
でも、スマフォって結構重い。。。来年は置いていこうと誓った。
んで、今日はとても暖かったので、ウィンドブレーカーを脱いで手に持って走ったんですが、これが結構邪魔です。
去年はかなり冷たい風が吹いていて、ウィンドブレーカーは必須だなぁ、着てきてよかったなぁ、と
去年はつくづく実感したもんですが、今年は着ると暑いくらいのポカポカ陽気でした。
ということで、ハーフの21km過ぎ時点まで走って、今日はフェードアウトしました。
いちおうハーフのタイム計測地点は跨いだので、ハーフのタイムは計測されているはず。
他の収容組と共に収容車に回収され、バスでスタート地点まで戻ってきました。
ほんと、完走したかったよ。。。
会場からシャトルバス乗り場への帰り道、フルマラソンのコースを歩くんですが、5時間30分前後のペースで
ゴール直前のコースを走るランナーとすれ違うんです。
みんな、ヘロヘロな状態なんですが、あと少しのゴール地点目指して走る姿が眩しい。
このタイムは去年の私のタイムくらいなんですが、リタイアした自分と、目の前を走るランナーの輝かしさの、
あまりのギャップに、自分への不甲斐なさと悔しさで涙した。。。
もう一度、体を鍛えなおそうと誓った。
12月の引越し前はジムに週2回通って鍛えていたんですが、こっちでもジムに通う。
可能な限り、帰宅後に走る。
あと、JR東日本は、今回の特急電車の遅延に対する対処について猛省してもらいたい。
乗車組の目的地は１つなのだから、故障区間の先である千葉駅に別の臨時列車を用意する等の対応はできたはず。
錦糸町から千葉まで普通列車で乗客を向かわせ、ターミナルである千葉駅から別の臨時列車を出せばいいのではなかったのか。
もちろん、ダイヤの詳細はわからないのでなんとも言えないが、マラソン専用の特急列車にしては、
あまりにも対処が酷いと思った。
来年こそは、若潮館山マラソンをまた完走して、自己ベストを更新したいと願う日だったのでした。
2013/1/22(火) 「アジャイルサムライ読書会 横浜道場 特別編"ワールドカフェ再び"」に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/2148Togetter
http://togetter.com/li/443871ゆかりんノート
https://yukar.in/note/ckFrXC以下の書籍をターゲットとした読書会なのです。
一応ここ数カ月は皆勤で出席してるかな。
今回は特別編ということで、ワールドカフェを行いました。
ちなみに私、ワールドカフェ形式でディスカッションをやったことは横浜道場以外でも何回かあったのですが、「ワールドカフェ」という名称があったなんで今日まで知りませんでした。
ググったところによると、↓のようなカンジでやるプラクティスらしいです。今回もコレでやりました。
■ワールドカフェとは■本物のカフェのようにリラックスした雰囲気の中で、テーマに集中した対話を行う。
■自分の意見を否定されず、尊重されるという安全な場で、相手の意見を聞き、つながりを意識しながら自分の意見を伝えることにより生まれる場の一体感を味わえる。
■メンバーの組み合わせを変えながら、４～５人単位の小グループで話し合いを続けることにより、あたかも参加者全員が話し合っているような効果が得られる。
■手順
- テーブルごとに4名着席して、グループにする。他にもいくつかグループをつくる。
- 提示された共通のテーマについて各テーブルで話し合う。
- 30分ほど話し合い、1人をホストとして残し、3人は別々のテーブルへ移動する。
- ホストがそれまでの内容を新たな3人に伝え、新たな4人でまた話し合う。
- 2.～4.を２、３回繰り返す。
- グループ内や全体で話し合った内容を共有し、まとめる。
参考（引用元）http://world-cafe.net/about-wc.htmlhttp://link-space.sub.jp/worldcoffe.html今回は4名のテーブルが5つあり、テーブル移動は1回で、計2回のディスカッションを行いました。
■ワールドカフェでディスカッションしたいテーマ参加申し込み時のアンケートから集められたテーマとして以下がありました。
■レジュメ＆各テーブルで選んだテーマ
■最初のテーブル「どこまでアジャイル／スクラムのプラクティスを崩して良いか」自分のテーブルでは、どこまでプラクティスを崩してやって良いか、というテーマでディスカッションしました。
以下はディスカッションの中で出た話。
■自分以外は新人が二人のチームなので、プランニングポーカーをやっていない。経験がないメンバーに見積もりをやってもらっても精度が上がらないので。
→ ストーリーポイント本来の相対値ではなく、新人という要素を考慮した絶対値で見積もりを行うのはどうか。例えば私が作業すると3時間のタスクを新人が作業すると10時間かかる場合、そのタスクをその新人に割り当てた上で、「10時間」という数値を割り当てる。（単位付きで）
人にタスクが単位付きで割あたってしまう弊害はあるが、見積もりの精度は上がるのでは。
■モチベーションが上がらない時は作業効率が下がる。その時は、従来のストーリポイントの数字に、モチベーションが上がらない場合の作業効率性を考慮した「ストレスポイント」が加算されるのが実状。でも、実際の見積もりでは積まない。
■守破離、という言葉があるが、いきなり破をやってないか？
■チームの人数はMAXで7人くらいだと思う。それ以上の規模だと、自分がプロジェクトの規模を見積もれないレベルになる。（見積もりがブレる）
■プラクティスを自分のチーム用にカスタマイズする必要があってするなら、全然アリでは。例えば3名のチームで朝会をやってるが、30分かけてる。話すネタがいつもあるし、余ったら勉強会みたいのやったり。
■プランニングポーカーの数字は、少し余裕を持った値を提示するようにしてる。（自分の能力が低いと周りから思われるかもしれないが、その方が自分もプロジェクトもうまく回る）
■次のテーブル「アジャイルを上手く導入するには」アジャイルを上手くチームに導入するにはどうしたら良いか？というテーマです。
テーマに「導入」を選んだテーブルは、他にも２つくらいありました。
■やれるところからやる。例えばインセプションデッキから１つ２つピックアップしてやってみる。
■アジャイル、という用語を前面に出さない。
■Do AgileではなくBe Agile。
■そもそもアジャイルの定義がみんな違うので、最初に意識を合わせる必要がある。
■結局は人次第。面接してアジャイル向きの人員を集めるとか。
■ペアプロ（ペア作業）できない人はアジャイルに向いていない。会話できることが重要。
■アジャイルに向かない人はいる。その場合、スクラムマスターの判断で、その人をチームから外す。
■そもそも何故アジャイルである必要があるのか、という点から考える。
■最初は「アジャイルやってみたい」という興味（Do Agile）から入ってもいいのでは。きっとみんな、最初はそうだったはず。やってるうちにきっとアジャイルの本質に気づいていく。素振り重要。
（これ、そういや道場の意義そのまんまかもしれないと後で気づいた）
■シェア各テーブルの気づきをシェアする時間では、各テーブルのオーナーが順に発表をしました。
持ち時間は各テーブル5分ずつです。以下はそこで出た意見の一部。
■外せないプラクティスについて。
・レトロスペクティブ
・インセプションデッキ
・朝会に全員同席
■全員が同じ帽子をかぶり分けるのは実際は難しい。スキルの差は数倍どころじゃないので。
→ スキルが足りない人には個別のタスクを割り当てて、その人に責任を持たせる。
---
道場主の質問に参加者が回答してる真っ最中、道場主が自ら5分ぴったりで打ち切る容赦ないタイムキープ。一同ワラタ。
■KPT最後にいつもどおりKPTです。
最初のテーブル、ペンが全部かすれた字しか書けなくて、Problemに書いておいた。
■ビアバッシュ22時からはビアバッシュタイム。今日はピザでした。
今日のワールドカフェの感想とか、ScalaやHaskellの話とか、リア充の定義についてとか、ドラクエの復活の呪文の仕組みの話とか、もろもろで盛り上がりました。
今年最初の横浜道場でしたが、今回もとても充実したヒトトキを過ごせました。
ワールドカフェという言葉の、「カフェ」でリラックスするような感じ。
ワールドカフェ、話は盛り上がって良いのですが、自分用にメモ残すのが難しいです。ディスカッションに夢中になってると特に。実際の現場でやる時は、書記みたいのテーブル毎に置いてもいいのかも、と思いました。
最後に道場主さんはじめスタッフさん、会場提供者さん、ありがとうございました。
2013/1/21(月) 「Enterprise User eXperience Design -ユーザー中心設計の実践 -」に参加してきました。
DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/2407Togetter
http://togetter.com/li/442836場所は麹町のKDDIウェブコミュニケーションズです。
参加者は30名位でしょうか。
講師は日立ソリューションズの柳生さんです。スライドはこちら。
（↑クリックすると資料に飛びます↑）
資料のダウンロード先：
www.hitachi-solutions.co.jp/forum/download/tokyo.htmlPDF：
http://www.hitachi-solutions.co.jp/forum/tokyo/vol62/pdf/pb_seminar62_2.pdf
最近、UXという言葉を聞く機会がとても多くなりました。
先日11/8(木)には、Devloveのイベント「Enterprise User eXperience Design - ユーザー中心設計の実践 -」にも参加して、そんときはブログにも書きました。
コチラあと、12月のDevlove2012でもUXのセッションがあり、黒須先生のお話を聴講しました。
弊社でも、UXのイベントを○○に実施する、みたいなメールが社内MLで飛んできたりと、身近なところでもUXを目にするようになりました。
ということで、ちょうど今回もUXがテーマですし、参加することにした次第です。
あと、今日の講師の柳生さんのお話にも「親会社」という言葉が何度か出てきましたが、私、ソコの社員なのです。。。
やっぱ同じグループ会社のUXの取り組みがテーマということもあり、なおさら興味がありました。
以下、講演の資料にない柳生さん口頭説明部分を中心に、自分用メモ。
■Devloveの紹介- 2/20にDevloveで「実践反復ソフトウェア開発」というテーマのイベントをやる。（個人的に楽しみだ）
- Devlove2012で鈴木雄介さんが「ソフトウェア品質モデル」というのを紹介していた。こんなの↓
→ そこで紹介されていた４つを、バランス良くこれからはやっていかねばならない
→ Devloveでは、今後のイベント毎にどれをにフォーカスしてるのか、毎回言うことにした。
→ ちなみに今回は「利用時品質」がテーマ。
■柳生さんによる講演真ん中の文字は、縦で見ると13に、横で見るとBに見える。
→ 人間には、前後の情報からものを判断する、という特性がある。
・文脈効果
・認知の仕方
→ これがUXの根底。人間中心設計。
- 自己紹介：昔、ITブラック四天王と呼ばれるような会社にいた。
当時はUXという言葉はなかったので、ユーザビリティと呼んでいた。
３つのポイント。これが重要。
- ユーザの体験に着目する。
- その体験を豊かにすることを考える。
- 結果として、付加価値の高いモノやサービスが作れる。
例：コーヒーを飲む体験で考える。
- 缶コーヒー： 手軽
- スタバ： お店の雰囲気がくつろぎを狙っている
- ホテル： 行き届いたサービスと景色がよいところ
→ 付加価値の違いが見えてくる。これがUX
UXだけでなく、ユーザビリティとアクセシビリティも大事。
高齢者とか障害者が使えるようにしていくのがアクセしビリティ。
UXでは、「誰のためのものですか？」「その人にとってどうなれば使いやすいのか、嬉しいのか」を考える。
パスポートの電子申請は今はできなくなっている。e-Taxも使われない例の１つ。
ITPro 「利用者視点に欠けていた行政サービスの実例--パスポートの電子申請」 財務省が公表、「旅券の電子申請は一件当たり費用が1600万円」
http://itpro.nikkeibp.co.jp/article/COLUMN/20060713/243238/パスポートの電子申請が使われない原因 → 申請に住基カードとカードリーダーが必要。
UXが考慮されなかった最たる例。
その反省として、2009/7に電子政府ユーザビリティ・ガイドラインができた。
実際はあんまり進んでないようである。ただ公共系の人は押さえておく必要がある。
使いにくさは慣れれば問題ないかというと、新人がまた使いにくい思いをして慣れるまで時間かかる。
→ 大きな問題。
ISO9241-210では、計画を立てたあと、４つのステップを回す。
１．「利用状況の理解と明示」：現場を明らかにする。
２．「ユーザー要求の明示」：ユーザがどのような要求を持っているのかを明らかにする AS IS調査。
３．「ユーザー要求を満たす解決策の作成」：どうすればユーザの要求を満たせるのかを考えていくところ。
４．「要求に対する設計の評価」：自分達が考えた対策がマッチしているのかをしっかり評価する。
→ 会社で推奨しているが実践はできていない。これからやるとこ。
最近はUXの費用対効果を示すことは無理なんじゃないか、と考えている。社内でも説明するのが難しい。
エスノグラフィのことを「行動観察」と呼ぶ企業もある。
ビデオカメラでお客様の作業を撮影するのは、お客さんの理解がないと難しい。
マウスを動かせる面積が少ない作業環境で、マウスをたくさん動かす操作が必要となるシステムがあって、そのときはエスノグラフィでその問題点に気付けた。
エスノグラフィの難易度は高く、できるまで３年かかる、という意見もある。言葉より行動。
グループ・インタビューの対象は、これから作ろうとしているシステムのエンドユーザ。（聞きに行く）
エンドユーザ4,5人に集まってもらって、いろいろ聞く。WEBサイトとかあれば、実際に見ながら話を聞く。
グループ・インタビューでは、質問の深堀りをしていく。なぜなぜ。なぜ？を２回は繰り返す。
なぜ２回なのか。
→ 聞きすぎると詰問されていると感じる人がいる。
→ 弟子入りした感じで相手を師匠と思って聞くと聞き方がやわらかくなる。
ペルソナは、この人のためにいいもの作ろう、という思いを全員で共有するのが重要。
ペルソナに氏名とかも与えて、顔写真も用意して具体化する。
ペルソナは作って終わり、じゃなくて、「この人のために！」という思いを共有するのが一番重要なこと。
論文公開サイトを使うのは大学の先生。ただ企業の研究者もいたりするので、違う観点で4名分のペルソナを作成した。。
→ ペルソナとシナリオを使って、お客さんを交えて議論した。
→ お客さんに好評だった。あと仕様がブレなかった。
インスペクション評価は、仕様を確認できるものがあれば、すぐできるところがポイント。
ただ専門家が必要なので難易度は高い。
ユーザビリティ・テスティングでは、あえて「テスティング」という用語を使っている。
→ これは、「単体テスト」とか、その「テスト」とは別ものだと理解してもらうため。
ユーザに操作のシミュレーションをやってもらう。エンジニアはお客の隣に座って、お客さんに指示し、お客さんに実際に操作してもらう。
→ エンジニアはお客さんの感情とかしぐさを見る。
→ お客さんは考え込むとだまってしまう。そのとき、今何を考えていますか？、と聞く。
ユーザビリティ・テスティングの専用の設備がある企業もある。
→ 部屋がマジックミラーとかで仕切ってあって、お客さんとエンジニア側が分離されており、お客さん側からはエンジニア側が見えない。この状態でお客さんに操作してもらう。（お客さん側の、監視されている、という意識を軽減できる）
日立ソリューションズだと、二部屋を用意して、延長コードで部屋を繋いで、モニタ越しにやっている。
→ お客さん側の「見られている」という意識を軽減でき、テストに集中してもらえる。
ユーザビリティ・テスティングをやってみると、開発者はかなりへこむ。
→ ユーザは言いたい放題言うので。。。でも第三者の視点を気づくことが多くて、非常に好評。
第三者の視点が非常に重要。で、何人を対象にすればよいか、というと、5人。
→ UXで著名なヤコブ・ニールセンの経験より。
日立ソリューションズのUX施策の取り組みの成果
→ ソフト開発だと、エンジニアはユーザと接する機会がほぼない。これが変わった。
→ ただ、人に興味が持てない人は難しい。人が好き、って人じゃないとダメ。
→ 開発が好き、って入社してきた人はUXはやっぱだめだった。
■Q&AQ1.
新日鉄住金ソリューションズに所属しているが、UXが実案件に繋がることがなかなかない。
実際、お客さんにはUXにお金を使ってもらわなきゃいけない。
どういう案件だとこういう提案がとおりやすいか？
A1.
自社製品の開発案件が良いのでは。研究開発とかも説得しやすい。
受託開発だと、お金の面で理解してもらえない。提案までは行くが、受注までは行かない。
---
Q2.
UXセンターを作るとき、社内で啓蒙活動とか偉い人を説得することをやったとおもうが、どうやったか？
A2.
組織を作る、という所については、棚ぼたで出来ちゃったのが正直なところ。
親会社の日立から日立ソリューションズにUXの人が来て、その人がこーゆうことやっていこう、という話になった。
---
Q3.
UXのデメリットに費用対効果が示しにくい、というのがある。売り上げに直結しないという問題に対し、上司にツッコまれたときにどう説明するか？
A3.
ネガティブな数字を見せる。
今○○だけ悪いんです。それを改善するとこれだけ改善できるんですよ！という話にもっていく。
「削減」という言葉には経営者は敏感なので、いいかも。
■ダイアログウチの班は4人でしたが、ダイアログのネタとして以下が挙がりました。
１．ペルソナの作り方
２．エスノグラフィをやる現場に行けるのは一部の人だけ。それをプロジェクトにどう持って帰って共有するか。
３．インスペクション評価において、意見の集約をどうするか。（声の大きい人の意見に流れないようにするには？）
１．ペルソナの作り方ペルソナで想定する人をシミュレートするのが難しい。同じイメージを共有するにはどうしたらいいか。。。
ペルソナは、対象を予想して作るのはよくないのではないか。
ペルソナは、対象者の人の好みとか趣味まで決める。
特に開発の後期になると、都合のいいペルソナを作り始める。
ペルソナの対象は一人でもいいのかも。ペルソナは共有イメージを持つことが目的なので。
２．エスノグラフィをやる現場に行けるのは一部の人だけ。それをプロジェクトにどう持って帰って共有するか。エスノグラフィは難易度が高い。誰でもできるわけではない。
→ 訓練を受けた人が現場に行くべき。特に、ユーザインタフェース設計に近い人が良いのでは。
→ で、そこで出た情報をどう共有するかが重要。
３．インスペクション評価において、意見の集約をどうするか。声のでかい人の意見がとおってしまうのではだめ。
ペルソナを持ち出して説得するのがよいのでは。今回想定しているペルソナは、これを望んでいるんですよ。という説得の仕方。
他の班で出たダイアログの議論共有マクドナルドの60秒ルールについて商品がぐちゃっとなって出てきて、がっかりした。（店員が急いで作るので）
たかがマクドナルドでも、商品の期待値がCMに含まれている。
写真とかで表示されている商品の姿が期待値としてあるので、その差にがっかりする。
本質的要求と付加価値という部分に差異があると、満足度は下がる。
by 柳生さん
期待値をコントロールすることは大事。
期待値が最初から高いと、お客さんをがっかりさせることがある。期待値が程良いとはどうあるべきか、という研究がある。どこに提供価値があるか、を考える必要がある。
UXを売るためにはまだUXを売る段階に来てない。受託開発なのでお客さんに提供して対価を得られることが必要。
そのために、定量的な数値を出していきましょう、という話をした。
お客さんの方からパラダイムシフトが起こって、お客さんの方からUXを求めるようになれば変わるのでは。
今後、UXが認知されてきたときに、我々が答えられるようにしておかなければならない。
エンタープライズならではのUXUXとかはコンシューマ分野だと多いが、エンタープライズには特有の特性がある。開発のモデルだったり顧客との関係性だったり。どうやったらそこにUXを重ね合わせられるのか。
日立ソリューションズも受託じゃなく社内からUXをやってる。受託でもできるところからUXをやっていく。お客さんから「UXの話を聞かせてくれ」という話が最近は来ることがあるので、そういうところからとっかかりにしていく。
UXがお客さんの心の余裕に繋がっていくことがある。
自分達エンジニアがUXの大事さを感じられないと、お客さんにUXを進められない。
ディズニーの従業員はディズニーが好き、という統計もあるように、自らUXのありがたみを感じることが重要。
UXのノウハウの蓄積方法日立ソリューションズでは、会社としてUXに取り組む、ということを運よくやってもらえた。
親会社の日立製作所のデザイン本部がUXに取り組んでいたので、それを教えてもらった。
次に、あるプロジェクトに協力してもらってUXの施策をやった。
次にUXを実践しようと思って、自社で協力してもらえる人を選んで、ユーザビリティテストをやってみた。
そのような形でUXのノウハウを蓄積してきた。
HCD-Net（人間中心設計推進機構）に参加してみるとかも良いのでは。
産業技術大学院大学でもUXの講義がある。お金と時間が必要となるが、有効な手段の１つ。
HCD-Netは学問が付いているのが特色。
ゲーム業界は、UXはすごく進んでいるけど体系化されていない。そういう残念な状況があるので、アカデミックに知見をまとめているHCD-Netは有用だと思う。
最後にDevloveからお知らせ2/23にHCD-NetとDEVLOVEとゲーム業界でイベントをやる予定をしている。テーマは「テスト」
★感想：同じグループ会社のUX紹介、ということもあって、大変興味深く聴講させていただきました。
ダイアログで議論した、ペルソナを如何に作るか、という話もいろいろ考えさせられましたねー。
いずれにせよ、UXを意識して設計をする、ということが重要だと思いました。妥協するともうダメですね。
柳生さんpapanndaさん始め、運営＆会場提供者さん方々ありがとうございました。
2013/1/20(日) 「第7回 スタートHaskell2（最終回）」に参加してきました。
Partake（告知サイト）
http://partake.in/events/60b9a21c-8282-4abe-8820-099d65f69a62togetter
http://togetter.com/li/442212
以下の書籍をテキストとした、セミナー形式と演習形式を組み合わせた勉強会なのです。
会場はいつもの IIJ 大会議室 (17階)です。参加者は50人弱でしょうか。
今回は最終回ということで、モナドの残り（14章）とZipper（15章）が範囲です。
予習は不完全な状態でしたが、可能な限り目を通し、写経してから参加しました。
■14章「もうちょっとだけモナド」 @ffu_ さん以下、メモ。
- 差分リストを使うと右結合になるのはウソ。
- 関数結合はオーダー１。詳細は@kazu_yamamoto さんの資料参照。
- Blaze BuilderがHaskellでは一般的になり、ByteStringにもBlaze Builderが付いている
- 今は差分リストではなくBlaze Builderが使われている。
- 最近は差分リストを学ぶのは意味が少なくなってきている。
- ByteStringはテキストはビルダーが付いているのでそれを使いましょう。
- 差分リストの名前はprologに由来する。「差分」という語からのイメージとは異なる。
- 不変の初期値を与えて実行したいときにReader Monadを使う
- 圏論では、Monadはjoinで作られている。でもHaskellではjoinは使わなくてもいける。
- joinをするときにはバインドをすべき。
- 関数名にMつけてhoogle探すと、Monad対応版の関数が見つかったりする
- @kazu_yamamoto さんのブログ「例題で比較する状態系のモナド」
- 関数idは、最初は何に使うかわからない。foldで関数合成する際の初期値に使える。
- Maybeモナドは途中でescapeするためのモナド。Stateとは別に考えた方が良い。
■15章「Zipper」 @shokos さん - 木構造やリスト、ファイルシステムをHaskellで効率的に扱うにはどうすればよいか、のお話。
- 個人的に15章は写経する時間がほとんど取れず、本に目を通したくらいだったので消化不良気味です。無念。。。
■LT1「Haskellで作るOS: Metasepi」＆「簡約!λカ娘(4)の紹介」
@master_q_hentai さん
- 今日もあいかわらず、面白いネタとトークが繰り広げられました。
- Haskellの型システムの恩恵を活かしたOSを、Haskellで作る！とのことで、斬新すぎる。
- あと「簡約!λカ娘(4)」の頒布会と、中身の紹介もありました。
■演習タイム15時から30分ほど休憩タイム。そのあとは17時過ぎまで演習タイムです。
演習問題http://wiki.haskell.jp/Workshop/StartHaskell2/exercise14
問題「Writerモナドを使ってみよう」 解答例： @igrep さん
問題「Stateモナドを使ってみよう」 解答例： @apstndb さん
問題「Readerモナドを使ってみよう」 解答例： @apstndb さん
ダメだ、ぜんぜんスラスラ解けない。。。
と、17時くらいまで悩んでました。17時過ぎからはLTタイムです。
■LT2「Hakyllとlivereloadの組み合わせによるブログ更新」 @kei_q さん
- Hakyllという、Haskellによる静的ページ生成ツールを使ってブログを自動更新するお話。
- エディタで記事を書いて保存すると、自動的に検知してブラウザが更新され、最新のブログが表示されるように改良したとのこと。
- 毎日１つ、HaskellのTipsを書く事を今年の目標にしている。
- ブログ自動更新を実現するため、ローカルでWeb Socketを使っている。この発想がおもしろい。
■LT3「永続スプレー木と永続スプレーヒープ」 @kazu_yamamoto さん
（↑クリックすると資料に飛びます↑）
- zigとzagという操作で、アクセスしようとするノードがルートになるよう木が動的に構成される。
- スプレー木とZipperの関係のお話。
★感想：さすがに最終回だけあって、難しかった。。。
でも、いちおう全７回、皆勤で参加して、なんとかHaskellの思想とか利点は理解できたと思います。
モナドとかも、マスターしたとはとても言えませんが、面白そうということはわかった。
あとはIFPH読書会の方で、引き続きHaskellを継続していこーと思ってます。
普段使ってるJavaとかと全然違う空気を感じられるHaskell勉強会、とても刺激的。
最後に、全７回、とてもスムーズに運営してくださった関係者の皆様、ありがとうございました。
2013/1/15(火) 「エキスパートPythonプログラミング読書会 第二期 13」に参加してきました。
connpass（告知サイト）
http://connpass.com/event/1623/togetter
http://togetter.com/li/439828以下の書籍をターゲットとした読書会なのです。
場所はいつもの目黒で、参加者は15人くらいでしょうか。
今回のテーマは「第11章 テスト駆動開発」ということもあり、とても興味がありました。
最近は以下の書籍でちょうど勉強しているトコですし。
通称、GOOS本。オンラインの写経会にも参加してますし、先日もこのネタでDevlove2012のブログ書きました。
こちらは最近購入して写経している最中。横浜である読書会に参加しようと思って。
あと、GOOS本を進める上でも有効かな、と思って進めてます。
ということで、以下は当日の自分用メモ。
- 「エキスパートPythonプログラミング」の訳者の一人である稲田さんがTDDに関するブログ記事を書いている。
- プロダクトコードが変更になると、そのテストコードも修正が必要になることが多い。テストコードの修正が膨大でメンテが困難になるなど、TDDが負の遺産になることがある。
- Selenimuというツールがある。Webアプリケーションのテストに特化したツール群らしく、SeleniumがWebブラウザを操作してテストを実行してくれるらしい。
お客さんがシステムに詳しくない場合でも、お客さん自身でテストデータを作ることが可能、というのがコンセプトらしい。
- 「ひたすらプロダクトコードを書いて、途中からテストを書く」という進め方を取っているという紹介あり。
- テストコードはプロダクトコードが変わると壊れることがあるので、いきなり最初からは書かないという思想。
- リグレッションテストは途中からでも書けるので、最初から書かなくても大丈夫、という思想。
- TDDをやる場合は、ポイントを絞る。TDDの恩恵がある部分に対してやる。
- プロジェクトにTDDを導入する際は、TDDを自分でやってみせるのがいいのでは。
- テストコードは、プロダクトコードを書いた自分自身が書かないと成長しない。テストコードとプロダクトコードを別の人が書くのは意味がないのでは。
- プロダクトコードとテストコードを書く時間の割合は、テストコードを書く時間の方がかなり多いのでは。数倍になることもある。
def add(a, b):
""""return a+b"""
return a+b
add関数を上記のように定義して、コマンドラインからhelp(add)と実行すると、"""で囲んだ内容がその関数の仕様として表示されるようになる。（ソースのコメントがドキュメントになる。Javadocのようなもの？）
プロダクトの使い方をわからせるために便利。（ドキュメントの中にテストが書いてある）
ドキュメントに「文章」と「使い方」をペアで書いておき、「使い方」がテストとして動作する。
ドキュメントに書いた「使い方」がそのままテストとなるので、ドキュメントとコードが乖離しない。
プロダクトコードが変わるとドキュメントのテストが失敗して、プロダクトコードとドキュメントの乖離がすぐ検知できるので。
- 清水川さんのブログに、TDDのハンズオンについて書いた記事がある。
- doctestは受託開発では使われないかも。ドキュメントにテストコードを書くことになるが、受託だと納品が発生するので。受託開発ではなくライブラリ開発なら、doctestは使えるかも。アプリ開発に使うのは時間の無駄。
- テストジェネレータは資産になるが、単体テストは負債でしかない、という意見あり。
- FIT/FitNesseとかCucumberとかを使ってテストを自然言語で書くのは、実は結構大変で負債、という意見あり。
FIT/FitNesseは受け入れテストで表形式でテストデータを作成できるが、お客さんにその表を作成してもらえない場合が多い。要件さえ決めきれないお客さんなのに、テストデータなんか書けるか、という問題がある。
- プロダクトコードにassert文を埋め込むこともある。デバッグ時はテストコードを有効にし、リリースする場合に削除することができる。アプリは無理だけどライブラリなら使えるかも。
- 単体テストはsetupとteardownで独立性を持たせることが基本。順序性を持ったテストは良くない。
- 「エキスパートPythonプログラミング」の訳者の一人である森本さんがTDDに関するブログ記事を書いている。
- 森本さんがPytestの原文ドキュメントを翻訳している。
- noseとpytestでは、テストランナーがテストを探す順序が異なる。検索の正規表現が違うらしい。
- pytestよりnoseのプラグインの方が使いやすい。
- Pythonで今からテスト書くなら、pytestの方がnoseよりいいかも。森本さんの日本語マニュアルがあるし、QuickCheckというツールがあるし、テストカバレッジの機能が追加されたし。今ならpytest一択という意見あり。ただ、noseはpytestに比べプラグインが豊富という利点がある。
- Python標準のテストドキュメントあるが、わかりにくいので、pytestのドキュメントを読んだ方がいいかも。
- 外部依存をなくしたテストをするのがスタブとモック。
- PyPIにmockというライブラリがある。またPython3.3でmockが標準で取り込まれた。
- minimockはクセがあるので、Pythonに標準で取り込まれたmockの方を使うほうがいいかも。
- mockの良さは、テストコードを書かないとわからない。
- xUnit Test Patternsという書籍がある。
xUnit PatternsというWebがあり、これをブラッシュアップしたのが書籍になった。
Webで無料で観れるが、本を買った方が良い。
- 清水川さんがxUnit Test Patternsの一部を翻訳している。
- 「テストダブル」という用語を理解しておくと、他の言語のテストとかでいろいろ役立つことがある。
「テストダブル」
テストがダブル、つまり代役を用意する。俳優がスタントマンと交代してやる、というイメージ。
テストの順序とか、テストが何回呼ばれたかとかを後で検証できる。
- xUnit Test Patternsは、テストのパターンを知るには良い本。ただ分厚くて重い。（電話帳より厚いらしい）
テスト用語に迷ったら読むと良い本。
- minimockは、xUnit Test Patternsの「テストスタブ」に書いてあることしかできない。
- Python標準のmockは、xUnit Test Patternsにある用語の大体全部できる。
- DDD（ドキュメント駆動開発）
- やりすぎよくない
- 境界値テストを書こうとすると破綻する
21時からはビアバッシュ＆LTタイムです。今日はお寿司でした。
LTネタ：QuickCheckについて- テストスイート用のテストケースを生成してソフトウェアテストを行うための、Haskellで書かれたコンビネータライブラリらしく、多数の言語に移植されているらしい。(by wikipedia)
- データ型の定義域に存在するランダムデータを使ったテストを自動生成し、繰り返しテストしてくれるらしい。
- 前回テストに失敗したテストデータをQuickCheckが覚えていて、その近辺のデータを使ったテストを機械学習で生成し再テストもしてくれるらしい。（shrink：シュリンク）
- QuickCheckが生成したテストを行うだけでカバレッジが90%を超えることもあるとのこと。
- QuickCheckの商用ライセンスは、年間300万円/人らしい。3人月のコストでテストの効率が劇的に向上する可能性がある、という事実と天秤にかけることになる。
★感想：本に無いことを非常に多く学べた勉強会でした。やっぱ社外の勉強会に参加する意義はここにあると思います。脱線した内容が濃いのです。
あと、TDDはテストを書いた分だけ上手になる、という話が出ましたが、先日のDevlove2012でもt-wadaさんが同じことをおっしゃってました。やっぱ、そうなんですかねー、なるほどなぁ。
今はTDD関連の書籍の写経やってますが、とにかく手を動かしてテストコードを書く練習をまずは繰り返してみようと思います。
あと、会社でやってるユニットテストで、順序性を持ってしまっているものを見かけますが、これもダメだなーと再認識しました。setupとteardownが必要そうです。
LTで紹介されたQuickCheckも、実に興味深いですねー。
講師の清水川さん、運営者さん、会場提供者さん、有意義なお時間をありがとうございました。
-->
