@ledsun blog

無味の味は佳境に入らざればすなわち知れず

テキストより複雑な構造のデータを扱うWikipediaを作る

モチベーション

専門性を持った不特定多数のユーザに協力してもらい、個人では作り得ない大規模なデータベースを作りたいことがあります。

例えば、Wikipediaは、(記述の正確性や公平性における問題は抱えているかもしれませんが)規模の点で成功しています。

Wikipediaのエディタはオンライン百科事典のエディタとして特化しています。百科事典ではないデータを扱うデータベースの場合、Wikipediaのエディタは機能が合いません。

必要なもの

複雑な構造のデータを扱うたデータベースを作るには何が必要でしょうか?

ブラウザ上で動くビジュアルエディタが必要です。

なぜでしょうか?

インストール不要

インストール不要なため、編集環境を構築するコストが低いです。 編集用のアプリケーションをダウンロードして、個人のPCにインストールするのはボランティアで参加してもらうにはコストが高いです。

エディタの学習コストが低い

編集内容をビジュアルで表現すれば、エディタの操作が直感的になり、操作方法の学習コストが下がります。

データを直接編集する学習コストは高いです。 例えばDBPediaの情報を編集するには、DBPediaのデータフォーマットに関する専門知識が必要です。

つまり

ブラウザで動作するビジュアルエディタを提供することで、不特定多数のユーザーが編集に参加しやすくなります。

先行例

一般消費者向けのアプリケーションも作られるようになりました。

どうやって作ればいいのか?

技術要素は、2005年に公開された、Google Map変わっていません。

ただし、10年間で各要素はそれぞれ高度化しました。 一つのビジュアルエディタのJavaScriptファイルが数千行に達することは珍しくありません。

難しさ

複雑なソフトウェアを、要件に合わせて適切に設計・実装できる、ソフトウェア開発技術者が必要です。

ビジュアルエディタの場合は、次に挙げる難しさがあります。

  • わかりやすい操作方法の設計
  • 選択状態の管理
  • 編集途中状態の管理
  • UNDO/REDO機能
  • データの依存関係に応じた編集
  • パフォーマンス
  • テスト

わかりやすい操作方法の設計

わかりやすい操作方法は、編集したいデータ形式や、想定するユーザーによって変わります。

一般的な指針はあります。例えば、

  1. 編集の敷居を下げるには、ヘルプを参照せずに、マウスまたはタップ操作のみで編集を完了できると良い
  2. PCに慣れたユーザーはキーボードショートカットがあると便利に感じる
  3. ショートカットは世の中の既存のエディタと共通の方が良い

しかし、独自のデータを扱うアプリケーションを作る場合は、アプリケーション毎に試行錯誤が必要な部分は残ります。

選択状態の管理

「マウスまたはタップ操作のみで編集が完了」するには、編集対象のオブジェクトを選択する必要があります。 選択できない場合は、idや座標で編集対象のオブジェクトを指定して編集します。

オブジェクトが選択できると

  • 選択している時だけ編集可能にする(切り取りボタンを有効にするなど)
  • 編集機能やエディタの状態によって選択可能/不可能を切り替える

必要があります。

複数のオブジェクトが選択可能な場合は

  • 複数選択の操作方法の設計(例えばCtrl押しながら、Shiftを押しながら)
  • 編集機能やエディタの状態によって複数選択可能/不可能を切り替える
  • 異なる種類のオブジェクトを選択した場合の動作の設計

が必要です。

オブジェクト生成時に自動選択

オブジェクトの生成後に自動選択したい場合があります。その場合、

  1. データ上のオブジェクト作成
  2. DOM上のオブジェクト作成
  3. データ上のオブジェクト選択
  4. DOM上のオブジェクト選択

の順序を制御する必要があります。 VIrtualDOMで表現できないビューを扱う場合は、モデルの操作とビューの操作が交互に行うため、原始的なMVCでは監視コントローラーパターンが使えません。 監視コントローラーパターンを使うには、MVPパターンを導入し、選択状態の管理をコントローラーから分離します。

編集途中状態の管理

エディタでは編集途中状態を扱います。

たとえば、テキストエディタは編集した文章を保存せずに終了することができます。 エディタを閉じる際に次の動作をしたいことがあります。

  • 未保存データがある旨の警告表示
  • 自動保存
  • 下書き状態として保存

ブラウザのonbeforeunloadを使って、これらの動作を実装します。

UNDO/REDO機能

エディタはUNDO/REDO機能があると便利になります。

VirtualDOMを使っている場合など、ビューがデータの射影として表現できれば、データのスナップショットをとっておくことで実現できます。

次の要件がある場合

  • メモリの消費を減らしたい
  • ビューの更新ロジックが複雑

データ操作を一度コマンドオブジェクトとして生成し、履歴として保存しておく必要があります。 各コマンドで

  • UNDOの実行
  • REDOコマンドの生成

ができれば、UNDO/REDOは実装可能です。

データの依存関係に応じた編集

データ構造によってはデータの依存関係があります。

例えば、ツリー構造の場合は親データを削除した時には子データも削除します。 ビューをDOMのツリー構造として構築していれば、データの親オブジェクトとDOMの親要素を消すことを対応付けることができます。

UNDOがある場合は、親オブジェクトが削除する時は、削除前に持っていた子を保存する必要があります。 UNDO時には保存情報から親オブジェクトと子オブジェクトを両方復元します。

パフォーマンス

DOM操作のパフォーマンスを出すには独特のテクニックが必要です。

DOMへの要素追加のタイミングを気をつける他に、リフローと呼ばれる現象を防ぐ必要があります。

DOM要素の「幅、高さ、位置」を取る場合、ブラウザは描画内容を再計算します。 DOM要素の「幅、高さ、位置」取得と、「幅、高さ、位置」設定を個別に繰り返すと、ブラウザの再描画計算が大量に実行されパフォーマンス低下を招きます。 これとリフローと呼びます。

参照したい全DOM要素の「幅、高さ、位置」取得をまとめて行い。 「幅、高さ、位置」設定をまとめて行うと、リフローが防げます。

テスト

ビジュアルエディタの機能では見た目が重要です。 テストをする際にも見た目の確認が大きなウェイトを占めます。 機能を満たしても、使いにくかったり、使い方が直感的にわからなかったりすれば、要求は満たせません。

一般的な、業務アプリケーションの業務ロジックのテストとは異なるアプローチが必要です。 人間が手と目を使って繰り返しテストすることが、非常に有効です。 テストケースの作成とテスト実施には、忍者式テストというテスト手法が有効です。

実績

作成したビジュアルエディタです。

1on1ミーティングのやり方

1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。

前提条件

弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。

インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。

面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。

やり方

人数

インタビュワーは6人います。ベテランエンジニア5人と営業1人です。

インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。

組み合わせ

もっとも長い期間面談をしていない組み合わせで実施します。

組み合わせは、モンテカルロ法で抽出します。 そのために GitHub - ledsun/interview-lottery: The lottery for interview を作りました。

その他

弊社には遠隔地の拠点があります。 Skype等のビデオ会議で面接を行います。

面談の議事録はインタビュワー間で共有します。

質問内容

面談を円滑に進めるために聞く内容のテンプレートを作ってあります。

  1. 最近うまくいっていること(やっていること)
  2. うまくいっていないこと
  3. (仕事をやりやすくするために)ほしいもの
  4. 個人のビジョン(どうなりたいか?)

KPTを元にしています。

「うまくいっていること」は言いづらいことが多いようです。その場合は、「やっていること」を聞いています。

「ほしいもの」はTeam Geekからパクリました。

「個人のビジョン」は「時々、(自分の)中長期的な将来のことも考えてみてね」ぐらいのノリで聞いています*2

実施方法

各インタビュワーに任せています。統一した方法等はありません*3

個人的には、ほぼKPTです。 インタビュイーに聞いた内容をホワイトボードに書きながら、質問を掘ったり、各項目を関連付けたりして進めます。

若手のエンジニアはメタ認知*4が苦手なので、KPTを一緒にやるとそれなりに効果があると思います。

お互いの負担を減らすために30分という時間制限を設けています。 個人的にはインタビュイーに話したいことがある限り延長しています。 最大で2時間半ぐらいでした*5

やってよかったこと

会社ハックのきっかけに

個人的に一番面白いのは、会社の仕組みをハックするきっかけが得られる点です。 社内の制度に関する質問をもらえると、仕組みを整理するきっかけになります。

ビジョンの時間変化

「個人のビジョン(どうなりたいか?)」に対する答えが、時間とともにに変わることがわかりました。 こまめに面談をしていないと、一年前に聞いたビジョンに今でも同じように興味があると考えてしまいがちです。 経験を重ねるにつれて興味のある分野が変わるのは、ふつうのことだと思います。

若手の成長を実感

ビジョンの変化と一緒です。 課題と思うことや、興味のあることが変化しているのを通して、若手の成長が実感できるのはうれしいです。

やってわるかったこと

エースエンジニアの時間が取られることです。 人によって得意不得意があります。面談が不得意なエンジニアがインタビューするのは負担が大きいようです。

*1:面談やってても辞める人は辞めますね・・・

*2:ビジョンをダシに「もっと頑張らないとダメだ」みたいな話をすると、お互い面倒臭いですよね。

*3:インタビュワーの面談技術向上は課題です

*4:ここでは「自分が知っていることと、自分が知らないことを切り分けて整理すること」の意

*5:経験則ですが、人間には「3時間話を聞いてくれた人を信頼してしまう」習性があるように思えます。

主観でプログラミング言語7種類をあっさり解説

k16's note: 主観でプログラミング言語5種類をあっさり解説を読みました。 なるほど、そういうのもあるのか。

個人的に馴染みがあるプログラミング言語を7つ解説します。

JavaScript

ブラウザで実行できるので、動作を確認しやすい点が良いです。

f:id:ledsun:20160701141331p:plain http://www.modulecounts.com/

圧倒的なライブラリ数です。

一方で、動作環境が多すぎます。

動作環境によって使用可能な文法、APIが違います。 参考資料が、どの環境を対象としているのか、判別するのに苦しむかもしれません。

C#

強力なIDEVisual Studioがある点が良いです。 Visual Studio Communityは無料で使えます。

一つの言語で、いろいろなアプリケーションが作れるのが魅力です。

  • Windowsアプリケーション
  • Webアプリケーション
  • コンソールアプリケーション

C# によるプログラミング入門 | ++C++; // 未確認飛行 Cという強力解説サイトがあるのも心強いです。

開発にWindowsが必要なのが、少し悪い点です。 やろうと思えば、Visual Studio Codeを使って、MacLinuxでも開発可能です。

Ruby

Rubyコミュニティが日本にあることが良い点です。 会いに行ける言語の実装者です。

言語仕様やライブラリ仕様が複雑です。ハードルがちょっと高いです。

VBScript

Windowsでの作業を自動化することができます。

大抵のWindowsに最初から入っています。追加アプリケーションが必要ありません。 他人のPCで動かすスクリプトを作るときに、インストール済みのアプリケーションを気にしなくて済みます。

言語仕様が独特です。他の言語と知識を共有できなく辛いかもしれません。

シェルスクリプト

LinuxUnixでのコマンドライン作業を自動化するのがとても簡単です。 基本的にはコマンドを並べるだけです。

関数を使ったりループを回したり、ちょっと複雑なことをしようとすると、シェルによって文法が変わるのが難点です。

Java

クラスベースオブジェクト指向を知るのに最適です。 オブジェクト指向における再利用のためのデザインパターンをマスターしたいときにおすすめです。

Androidアプリの開発にも使えるらしいです。

C

スタックとポインタを意識してプログラミングしたいときにおすすめです。 実行速度が速い点も良いです。

コンパイラと実行環境によって言語仕様が変わるのが気難しい点です。 gccVisual Studioでは使える文法が変わります。 OSによって使えるAPIが変わります。

日本でアジャイルが流行らない理由

ポジション的なもの

個人的に、アジャイルは「(あんまり未来や遠くのことを考えるのをやめて)目の前にある問題を解決しよう」という思想と認識しています。

現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは? と、思います。

キーワード「エンタープライズ」が出てきているので、業務システムの話をします。

情けないぞアジャイルコーチ

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。

サム・グッケンハイマーの一言

サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー

の方が

「ウォータフォールは一切メリットがないので止めておきなさい」

といったそうです。まあ、ポジショントークマイクロソフトは、これから日本で、Azureを使ったDevOpsを売りたいですよね?

自分の本当の心の中

統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで95%の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている

うしおさんがMicrosoftの中の人である以上、ポジショントークとして扱うのが良いと思います。特に、この画像にde:codeのロゴ入っているのが、ひっかかります。

マイクロソフトの面接での出来事

彼は面接の最初にちょっとびっくりした声で私に聞いた Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か?

DevOpsを売るに当たって、前提として「アジャイルが流行っていない」のどうしようか?みたいな、状況でしょうか? エンタープライズ向けに売ろうと思うと、由々しき事態だと思います。 上司の方の危機感の認識は日本市場に合っているのではないでしょうか?

最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの!そんなの誰もやってないよ!」と本当に驚いていた

なるほどー、そうなのかもしれません。 人類に達成可能である証拠なので、アジャイルを導入したい、自分にとっては朗報です。

ウォータフォールは起源から異なっていた

ウォータフォールの起源はどのようなものか?というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている

私も、そうだと思っていました。久しぶりに見直した日本語のWikipediaに・・・

初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはRoyceだと述べ、ウォーターフォール・モデルの起源がRoyceであるという誤解を広めた。

まじかよ!本日、最大の驚き!!

ウォータフォールを前提とするのが本当に日本のためだろうか?

1日に10回も100回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が15分で当て終わるような時代だ

1日に10回、本番デプロイする必要がある、業務には、どういう業務を想定されているのでしょうか? 個人的には思いつきません。

個人的な経験では 「1日待ってもいいから、ちゃんとテストして、バグで毎日の業務が止まらないことを保証してから、リリースしてください。」 と要望されることが多いです。

1日に10回、本番デプロイできる環境では、業務システムを使って業務を行う方たちも

  1. バグったらシステム管理者に連絡
  2. 再リリースまで休憩

な、やり方に慣れるのでしょうか? 米国に、そういう事例があるのであれば、是非知りたいです。

開発する立場としては、「とりあえず勘で直してリリースした。直ったかどうか、確認して」と言えたら、とても気楽だなと、思います。 正しいやり方かはわかりませんが、緊急回避手段が増えるのはありがたいことです。

自分の恥ずかしい体験談 私はインターナショナルでは無価値である

彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか?みたいな話をしてくれた

これは、うしおさん個人が、アジャイルな現場での開発技術についていけていない話な気がします。 現場で手を動かすのをやめるのが早すぎたのではないでしょうか?

アジャイルコーチのジョークに「もう何年もプログラムを書いていない」みたいな話があった記憶があります。 そのイメージです。元ネタを失念しました。

最も深刻なことは、「経験」を積めないこと

2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった

私は外資系、できれば海外に住むことをターゲットに仕事を探していた

という目的に対しては、残念とは思います。

だけど、あなたの積んだ「経験」は、絶対に他人が詰んだ経験とは異なります。 異なる経験は異なる状況では価値があります。普遍的に無価値ではありえません。

「自分の経験は無駄だった」はただの思い込みです。無駄なのでやめましょう。

日本はソフトウェア開発の後進国

ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた

これは間違いないです。日本人のGithubリポジトリをWatchしたことがありません。 本場で自分の力を試してみたい人は行けばいいと思います。 個人的には食の面で、移住には魅力を感じません。

海の近くで魚介が美味しくて、山の近くで水が美味しいと、食べ物は美味しいです。 シリコンバレーは割と食べ物がおいしいかもしれません。

自分が目指すビジョン

私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ

なぜでしょう?

Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい

遅れていると言われるのが嫌だからでしょうか?

うーんと・・・「ファッションアジャイル野郎が!」と言ってみたいですね(汗

エバンジェリストに期待すること

「遅れている」や「遅れがもっと広がる」という、脅しは必要はありません。 FUDは嫌いです。

  • アジャイルやDevOpsを取り入れた米国や英国の業務システムが、どうすばらしいのか
  • アジャイルやDevOpsが、日本の業務システムが抱えている問題を解決し得るのか

を伝えて欲しいです。

事例さえあげてもらえれば、あとは我々SIerが発注者に売りこみます。

日本でアジャイルが流行らない理由

個人の考えです。

  1. 予算確保にシステムの仕様が必要
  2. システムの発注が請負契約
  3. 発注企業のシステム担当者が、一つのシステムに専任していない
  4. 発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない
  5. 発注企業の業務担当者が、システム開発に専任していない

予算確保にシステムの仕様が必要

95%の会社がアジャイル開発やっているなら、これ教えて下さい。本当に。 システム開発を始める際に、会社内でプロジェクトの期間と目的と予算は決めているはずです。

どういう風にプロジェクトを初めて、どういうときに中止するのか。 リスク管理のやり方が真似できれは、日本の企業もアジャイルな発注ができるはずです。

公共案件の予算管理にも適用できると、大手SIerアジャイルに移行できるのではないでしょうか?

システムの発注が請負契約

よく言われます。これは分割納品にすれば割と回避できます。

ただし、最終納品では揉めることがあります。 発注時の仕様と違うものを納品するには、発注会社のシステム担当者が社内を説得する必要があります。 できなかった場合に、納品のためのごちゃごちゃした作業が必要になります。 プロジェクトは炎上します。

社内を説得できる人は、とっくに「アジャイルのようなこと」をやっています。

「予算確保にシステムの仕様が必要」と同根です。 発注会社(のシステム担当者の上司)はアジャイルなプロジェクト管理をする方法がわからないのです。 開発側の技術や環境の問題ではありません。

発注企業のシステム担当者が、一つのシステムに専任していない

  アジャイルなプロジェクトで1週間に1回リリースすると、発注企業のシステム担当者の時間が足りなくなります。 毎周、検収して次の週のストーリーを考えるのは無理です。

これは、発注企業のシステム担当者が、一つのシステムに専任していないからです。 他の業務に追われています。

この状況では「1日に10回本番デプロイ」魅力にはなりません。 DevOpsを使いこなすためには、発注企業は、システム開発の費用にシステム担当者の人件費をもっと増やす必要があります。

検証環境に「1日に10回本番デプロイ」できると、ソフトウェア開発者にとっては便利です。 手で受け入れ試験を回せるので、システムの理解が捗ります。

発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない

  • ディスクは遅くて、ネットワークはもっと遅くて、メモリはちょっぱや
  • 1万レコードは問題ない。10万レコードはちょっとおもい。100万レコードは重い。1億レコードは色々頑張らないと無理

みたいな感覚を持っていてもらえると、コスト感が通じやすくて嬉しいです。愚痴です。

端から見ていると、業務システムのプロダクトマネージャーは、とても難しい仕事に思えます。

  • 商売の理解。システムをどう活用すればもっと儲かるのか
  • 業務の理解。どういうシステムなら業務がまわるのか
  • コンピュータサイエンスの理解。どういうシステムなら低いコストで作れるのか

すべての知識を持ったプロダクトマネージャーは、非常に稀有に思えます。 数千万円程度の投資をして、外部から登用するか、社内で育てる必要があるように思えます。

それで商売上の価値があるのかは、私にはわかりません。

発注企業の業務担当者が、システム開発に専任していない

日本では当たり前です。業務担当者は、

  • 開発初期のインタビュー
  • 開発終盤の受け入れ試験での確認

ぐらいに参加。システムが稼働し始めてから、本格的に使って混乱します。 慣れてくると、本当の要望が出てきます*1

米国では、「業務設計担当者とアジャイルに開発して、現場の人はマニュアルにしたがって操作するだけ」なのでしょうか? 気になるところです。

「システムを段階的に導入して、現場の業務担当者のフィードバックを生かして、システムを育てていきたい」 と、常々思います。 受託開発では、納品後はシステムはソフトウェア開発者の手を離れます。 「現場の業務担当者のフィードバック」を受ける機会はあまりありません*2

*1:出てこなかったり、謎の思い込みから、明後日の要望がでてきたりするることもあります

*2:プロトタイプを触ってもらってフィードバックを受けることはあります。ただ、本気の要望かというと違う気はします。システム導入への恐怖感は減ります。業務担当者にプロトタイプを触ってもらうことは、システム担当者にはメリットがあると思います

とてか04に参加しました #toteka

d.hatena.ne.jp

椎葉さんの発表がぐっときた

すごかった。 「失敗したチームメンバーがいた時に、笑ったらいかんよ」と説明すると言っていました。 「そこまでやるのか。やると意味があるのは想像できるけど、自分ではできない」という意味ですごかったです。

懇親会で聞いてみました。

実際の説明はもう少し丁寧に「悪気がなくても、思っているのとは違う伝わりかたをするので気をつけてね」 とするそうです。

なんでそこまでやるのか? 「自分が抜けた後も、走る続けられるチームを作りたい」からだそうです。 自分とは立場が違うので無理して真似る必要はなさそうです。

(「チョットデキル人に訊け!」の話題と関係しています。)

track8さんの発表が面白かった

想像できない使用環境に起因するバグをどうやって想像すればよいのか?という話でした。 純粋に楽しめました。

「チョットデキル人に訊け!」が興味深い

「すごいなー」と思ってどうするの?

勉強会ですごい人の話を聞いて「すごいなー」と思ったときにどうすればよいのか、というご相談。

チョットデキル人の回答は忘れちゃいました。 その後自分で考えたことを...

自分が真似できない理由は8割が「自分がその問題に直面していないから」の気がします。 能力が足りていないのは2割ぐらい。

自分の「忍者式テスト」体験を振り返ります。

  • 10年ほど前に「忍者式テストすげー」と思った。そのときは品質保証の手段だと思っていた
  • 5年ほど前に、真似してみたがうまくいかなかった。このときは人力テストハーネスとして使っていた。が、テスト量のコントロールとテストのアップデートができていなかった
  • 2年前に「忍者式テスト」を上手くできた。開発者がテストしたので、集中できないほどのテストはやらなかった。つまらないテストもやらなかった。

10年近く真似できなかった、一番の原因は「忍者式テストで解決したい問題」を扱っていなかったからでした。

(その間にリファクタリング力が上がったのも多少は関係していると思います。)

というわけで、「すごい人のすごい技」はそのうち使えるシチュエーションにぶつかるので、心のメモ帳に書いておけばOKです。 使えるシチュエーションにぶつかっていないのに、真似するのは

ハンマーを持つ人には、すべてが釘に見える。 (アブラハム・マズロー

です。気をつけます。

テストがうまくなりたい

「テストが上手くなりたいモチベーション」が、チョットデキル人が三人とも違って面白かったです。

秋山さん:

プログラマーの頃は上手くなりたいとは思っていなかった。テストを専門にやるようになって、よりチームに貢献するために上手くなりたくなった。

関さん:

上手くなりたいなんて思ったことはない。必要だからやっている。

関さんの、仕事とプライベートをきっちり分けて、仕事に対しては、かっこよさやファッションを持ち込まずに、ひたすらプラグマティックに振る舞うのがすごいです。

和田さん:

最強のプログラマーになりたいので、テストも上手くなりたい。

和田さんはさすがの厨二力です。感嘆しました。 和田さんは、相手のレベルに合わせて、誤魔化しなしの正しい説明をリアルタイムでするのが、すごいです。

モカ・マタリ・アールマッカ

モカ・マタリ・アールマッカというブランドのコーヒー豆を調べたメモ

モカとは

イエメン産とエチオピア産のコーヒーをモカと呼びます。 モカの名称は港の名前に由来します。

モカ とは、イエメンの首都サナアの外港であるモカからかつてコーヒー豆が多く積み出されたことに由来する、コーヒー豆の収穫産地を指すブランド

モカの港からは、イエメン産のコーヒー豆の他、対岸のエチオピア産の豆も一緒に輸出されたため、両国産のコーヒー豆を合わせて「モカ」と呼んでいる

モカ - Wikipedia

モカ港

今はモカ港からコーヒーは出荷されていません。

現在、コーヒー豆集散地の機能は無く

モカ - Wikipedia

豆の特徴

モカ香と酸味が特徴のようです。

モカ香: イエメン、エチオピアのコーヒーのみが有する独特の香りです。ヨーロッパではワインフレーバーと表現されますが、少し違う、と感じながら的確な表現が見つかりません。

味: 柔らかい酸味が特徴。深めに焙煎しても柔らかい口当たりの苦味になります。

辻調おいしいネット / カフェ・マニアックス

生豆の品質はあまりよく良く無いようです。焙煎者の手間(ハンドピック)によるところが大きそうです。

外見: 粒(小粒のものが多い)と色が不揃いで、高級品でも欠点豆が多数混入し、一言で言えば貧相なコーヒーです。

辻調おいしいネット / カフェ・マニアックス

モカ・マタリとは

モカの中でも、モカ・マタリは耳なじみが良いです。コーヒールンバの歌詞に登場したためのようです。

コーヒールンバ」に唄われていたためか、日本でも人気が高い

モカ - Wikipedia

それは素敵な飲みもの コーヒー モカマタリ

西田佐知子 コーヒー・ルンバ 歌詞

産地

イエメンのバニーマタル地方で生産された豆をモカマタリと呼びます。

イエメンのベニーマタール地区で産出される最高級銘柄

イエメン コーヒー豆の詳細

イエメン国内でも、昔から最も優良なコーヒーを産出する地方

アラビア語で「バニー」は「子孫」、「マタル」は「雨」を意味します。  直訳すると「雨の子孫達」となり、名前からも雨に恵まれた地方であることが想像できると思います

「モカ・マタリ」は、本来、このバニー・マタル地方で採れたコーヒー豆のことだけをいいます

「モカ港から輸出されるバニー・マタル」の「マタル」が名詞化して「マタリ」となり、「モカ・マタリ」と呼ばれるようになった

バニーマタル3地域のコーヒー of 待夢珈琲店

豆の特徴

モカ香がなく、フルーティな酸味とスパイシー香が特徴のようです。

味は、甘みが特に豊かで、フルーティーな酸味があり、柔らかく、下にまとわりつくような脂肪感があります。香りは若草の爽やかな香り(特にニュー・クロップが強い)や色々なスパイシー香があり、一般にいわれているモカ臭はありません

バニーマタル3地域のコーヒー of 待夢珈琲店

「醗酵層の歴史が独特の酸味を産む」伝説があります。

モカマタリ独特のフルーティな香りと,甘酸っぱい味わいの秘密は収穫から珈 琲豆に加工される工程で,醗酵層に入れられるところで発生するようです。

イエメンのばあいはアラビカ種であっ ても自然体で天日乾燥(アン・ウォッシュト)され,脱穀機で乾いた果肉部分が削ぎ落 とされます。 果肉の下にはパーチメントという薄くて堅い皮があって,それを剥ぐ手段として醗 酵層に入れられパーチメントが醗酵によって柔らかくなるまで待ちます。 柔らかく名った時点で取り出され,精米機のように豆同士で擦り泡さてパーチメント と豆の表面にこびり付いているシルバースキン(銀皮)という薄皮が剥がされ珈琲豆と いう製品になる

イエメンでは醗酵層が100年前の状態のまま使 われているので,永年積もり積もった発酵菌が繁殖して独特の香りを付けるのだという 報告を聞きました。あのモカマタリの独特の甘酸っぱい香りと味わいは,醗酵層100年の歴史なんです

商品詳細|Dream Coffee(ドリーム コーヒー)

モカ・マタリ・アールマッカとは

欠点豆のおおいモカの中では選別が厳しく、扱いやすい豆が揃っているそうです。

現地で豆の大きさの大きいものだけを手作業で選別した極上豆をアールマッカと呼びます

イエメン コーヒー豆の詳細

イエメンで最新式のイタリア製選別機を所有する輸出業者が、原料の買い付け後、標高2700メーターの清涼な気候の丘陵地帯で保管と選別を丁寧に行っています

10月から2月にかけての収穫期に、3~4回程度、完熟チェリーのみを手摘みで収穫しています。そののち、各家庭の屋根で1週間ほど天日乾燥。そのチェリーはエリアごとの集売・脱穀業者に買い取られ、それを輸出業者が買い取ります。アールマッカを供給している輸出業者は買い取ったチェリーを最新の選別機でしっかり精選

商品のご案内|自家焙煎珈琲豆の製造直売・通販・卸「みずむら珈琲」

マタリの最高級品の一つとして流通している。イエメンの特徴的な短形の豆で、粒もかなり揃っていて、欠点豆も少ない。酸味も綺麗で味の濁りもなく、モカとしては扱い易い優れたコーヒー。ボディは強いが、なぜかモカ香は弱い。あまり徹底したハンドピックはしない方が良いかも

辻調おいしいネット / カフェ・マニアックス

価格

焙煎後で、100g 660〜850円で流通しています。

中間業者を中抜きすると受発注者はWin-Winになるか? 事例:クラウドワークス

結論

中間業者を中抜きは不可能。よりよい中間業者による代替えを目指そう

事例:クラウドワークス

crapp.hatenablog.com

にて、受注者側から見たクラウドワークスの問題点が挙げられています。

クラウドワークスは発注者のためのサイト

クラウドワークスとは、そもそもエンジニアの為に作られたサイトじゃなく、むしろクライアント(発注者)がエンジニアを安く買い叩くためのサービスに過ぎなかった

また

発注する側の手数料は一切かからず、仕事を請けた人間のみが手数料を徴収されるというシステムも印象が良くない。「クラウドワークスが発注者の為のサービス」だと言われる所以

中間業者中抜きへの期待

クラウドワークスにおいては、クライアント(発注者)とエンジニアは直結する。現実世界では、クライアント(発注者)とエンジニアの間に、仲介会社やエージェントなど「余計なもの」が入る。それなら、現実世界ではピンハネされている分だけ、エンジニアの取り分が増えても良さそう

よくある期待です。自分も意味がありそうに思います。

先人の失敗

絵や音楽

プロのクリエイターが、Gumroadで直接取引したときは、既存の流通業者を挟むより値段が安くなりました。

ascii.jp

1回目は初速がすごかったけど。2番目のは今日(アップロード当日の2月21日)の夕方までに16人。前のは57人。2枚合わせて、トータルで108ドルくらい。 とりあえず9000円くらいは儲かったよ

トップクラスのプロイラストレーターでこれです。

伝統工芸

伝統工芸でも起きました。こちらはどこで読んだか覚えていません。

問屋を飛ばした結果

  1. 受注が安定しない
  2. 安い仕事も受ける
  3. 高い仕事も単価が下がる

という話だったと記憶しています。

価格維持力が失われる

実際には期待に反し、価格維持力が失われています。 なぜでしょうか?

中間業者が必要な構造

クラウドワークスの価格低下構造

クラウドワークスでの、価格下げ圧は

  1. 受注側:新規参入者が技術力が低い分安く受ける
  2. 発注側:新規参入は価格と品質のバランスがわかりません。価格で受注者を比較して安い受注者を選ぶ

が考えられます。 この結果、(平均した)案件価格は下がります。

受注者は増える

受注者が少ない市場では案件価格があがるため、新規参入者が増えます。 労働市場は常に受注者が過多になる圧力があります。

受注者が極端に多い市場になると、案件価格が下がります。

価格下げ圧が強すぎると市場は縮小

価格下げ圧が強すぎると、安さを見込んで新規参入の発注者が増えます。 取引される案件の優良率が下がり、経験のある受注者がいなくなります。

まさに

割に合う案件がない

経験のある受注者がいなくなってしまうと、発注者は安く発注できても納品されないリスクを負います。 リスクの高い発注は本業には使えません。 お遊びや片手間の案件なら使えます。 案件の価格は下がります。

案件の平均価格が下がれば、市場は小さくなります。

中間業者の機能1 参入障壁(受注者のフィルタリング)

受注者が増える圧力を止める必要があります。 そこで、中間業者を挟んで受注者を一定以上のスキルにフィルタリングします。

これは同時に価格の維持にもつながります。 受発注者が直接つながるよりwin-winになります。

中間業者の機能2 案件のバッファリング

伝統工芸など、市場規模が成長しない場合は、発注の波を受注者が吸収するのは厳しいです。 中間業者による発注のバッファリングが必要です。

クラウドワークスさまへのご提案

クラウドワークスさまが、受発注者を幸せにするために必要なこと

  1. 受注者を精査して技術が低すぎる人をフィルタ

また、質の良い受注者を集めるため

  1. 発注内容を精査して価格が低すぎる案件をフィルタ

しかし、この作業は案件が増えると、必要な労働力が増えます。スケールしません。

そうだ、クラウドソーシングで外注しよう!(笑

参考リンク

人はなぜ憎しみを抱くのか

要約

なぜ憎しみを抱くのか

  1. 幼少期は親が居なくては生きていけない
  2. 自分の感情と親の意向が矛盾することがある(お腹が空いて泣くvsうるさい)
  3. 生きるために親の意向を尊重する
  4. 親の意向と矛盾する自身の感情を良くないものとして認識する
  5. 感情豊かな人を見ると、自身の感情を思い出す。抑えられなくなる
  6. 憎む

なぜ親は子を憎しみを抱くように育てるのか

  1. 社会のルールや規律を守ることが子供のためと信じている
  2. 子供の感情を直視して相手できない時がある(子を愛する能力に欠けている時がある)
  3. 信じる価値観や、それを守る良い親像を作るために「お前のためだ」と理由付けする

権威主義的な親に育てられた)憎しみを抱いた子はどうなるか?

  1. 父親の権威による支配から逃れようとする
  2. 父親より強力な権威(軍国主義・宗教のリーダー)の支配下に入る
  3. 極右団体のメンバーになる

なぜドイツではナチスが支持を得たのか

  1. 権威主義的な教育(シュレーバー教育)がドイツで流行った
  2. 多くの子が憎しみを抱くように育てられた
  3. (無意識に)憎しみを共有できる人が増えた
  4. 憎しみを肯定する(攻撃の理由付けをする)強いリーダーが求められた

シュレーバー教育は、本書に記載なし。以下を参照してください。

19世紀末、徹底的に子供をしつけるというシュレーバー教育がドイツで流行していた

東京大学東洋文化研究所

感想

精神分析学一般の話として読むとピンときませんでした。 ドイツでナチスが流行った理由の分析として読むと興味深いです。

著者のアルノ・グリューンはドイツ生まれのユダヤ人です。 ナチス時代のドイツに住み、迫害を避けデンマーク経由でアメリカに亡命しました。 ドイツを蔑んで(旧東ドイツでの極右団体による外国人排斥活動など)、アメリカを持ち上げる傾向があります*1

訳者の方が心理学または精神分析学の人でなく、文学の方です。「自分の中の他人」や「親からのテロ」などの訳語が、心理学または精神分析学方面としてふさわしいのかよくわりません。個人的にはわかりにくいと感じました。

単著に見えますが、インタビューをまとめた本です。 体系化されているわけではないので、論理としてはわかりにく点があります。

そもそも古い本です。「権威主義的な教育を受け傷ついた青年が、オイディプスコンプレックスを解消するために、極右活動に参加する」というのは、少しステレオタイプな感じを受けます。 現代の精神分析学でどのような解釈をされているのか気になるところです。

経緯

「生きる技法」の参考文献

本当は「才能のある子のドラマ」を読もうと思ったのですが、その時あまり良い出品がなかったためこっちにしました。

「生きる技法」を読んだ理由

何年も前に羽生田栄一さんが串田幸江さんにオススメしているのを見て、アマゾンのWishlistに入れていました。 誕生日にもらったので読んでみました。

*1:アメリカにも、差別的な活動をする人は、それなりにいそうなものです

日本Kindle化計画 その3

バックエンドサービスの選び方

日本Kindle化計画ではストレージにRedisを使っています。 公開するために、どのサービスのRedisを使うか決めたいと思います。

なぜRedisか?

以下の理由で、Redisを選択しました。

  • セットとハッシュぐらいのデータ構造で十分
  • 今の所1KB程度使っている。100倍使っても大したデータ量にはならない

Redisのホスティングサービス

無料の一つ上のプランの価格で選びました。

予算見積もり

日本Kindle化計画の予定する収入源はAmazonアフィリエイトです。

  1. 現在のKindleアフィリエイト8%
  2. 漫画が平均500円とする
  3. 一冊あたり40円
  4. 5$=615円払うには月に15冊以上購入してもらう必要があります

大きな収入は見込めません。 無料で始められ、仮に負荷が増えた場合もなるべく安いランニングコストで解決できるサービスがほしいです。

サービス本体はHerokuで動かす予定です。Heroku add-onも調査に含めています。

Redis To Go

老舗

Redis Labs

知名度No.1

Heroku Redis

Herokuの公式add-on

15$/月 Heroku Redis - Add-ons - Heroku Elements

Amazon Elasticache

AWSで使うなら

$18/月

選んだサービス

Herokuで使うならRedis To Goが良さそうです。

東京Node学園祭2015に参加しました #nodefest

本編短評

Node Discussionがめっちゃくちゃ面白かった

  • @domenicさんはbabelが好きじゃない*1。moduleはもっと好きじゃない*2
  • Node.jsにES6 moduleサポートが入る目処は立っていない。そもそも仕様が決まっていない。
  • power-assertはNode.jsのコアに入らない。コアのassertはNode.js自身のテスト用という位置付け。Node.jsは標準ライブラリを持たない方針なので、標準ライブラリにも入らない。

講演

  • Paypalでは800人のNode.jsエンジニアが働いている(!)。NASAでも使われている!!
  • npm preversion/postversion便利そう!
  • @kosamariさんがクソかっこよかった!Node学園祭は女性の発表が毎年パワフル
  • 来年のNode学園祭にはDouglas Crockfordさんが来るかも!?(Paypalの中の日本人が交渉してくれるらしい)

懇親会で

@t_wadaさんに聞いた情報

babel6が結構、大変らしいです。

プラグイン機構が変わりすぎてプラグインの対応に11月中ぐらいは時間が掛かりそう。 それが終わっても、プラグインの実行順序を定義する方法がないので、プラグイン間で衝突が起きそうらしいです。

power-assertなどを使っているbabelユーザーの人は、しばらく5のまま様子を見た方が良いのかもしれません。

二次会で

@fossamagnaさんに聞いた情報

最近Node.jsを始めたそうなので「コールバックなAPIはどう?」と聞いたら 「マルチスレッドの設計するよりはマシ」的な回答をいただきました。

なるほど、言われてみれば、スレッド間のシーケンス設計は面倒臭かった思い出があります。 それに比べればコールバックヘルは面倒くさいだけなので良いのかもしれません。

@rvaggさんに聞いた情報

正確には会長(@yosuke_furukawaさん)に通訳してもらって聞いた情報です。

Node.jsにコントリビュートするにはFLAKYテストの修正が取り込まれやすいそうです。 FLAKYテストというのは、成功したり失敗したりするテストのことです。 どのテストが対象かは、下をのURLを見るとわかる

よっしゃ、コントリビュートのチャンスや!

帰り道

Podcastを確認したら、本当にNodeUp: A Node.js Podcastから@dshawさんの声が聞こえました。 @dshawさんの英語は文末が跳ねるから、聞き取りやすいです。 それでも聞き取れませんが。

飛び込みLT

東京Node学園祭飛び込みLT

めちゃくちゃ受けなかったけど、顔とアカウントが一致していない人に話しかけてもらうきっかけになったので良かったです。 こういう道具は常に用意しておくのが良さそうです。

*1:好きじゃないというか、標準として扱われていることに困惑している

*2:好きじゃないというか、やられすぎている

道具としてのプログラミング、目的としてのプログラミング

プログラミングの学習曲線

Ruby on Railsはプログラミングではない! | それでも人は夢を見るの話です。 Ruby on Railsの有料講習を受けたが、受講前にイメージしていたプログラミングと、受講後の自信の能力のギャップに驚いている方の話です。

これは学習曲線の問題な気がします。

自分がプログラミングの勉強を始めた頃の話です。 入門書を読みながら、Perlをぽちぽち入力して掲示板CGI動かしてみました。 ですが、その次にどうすれば、イメージしているプログラミングに近づけるのかわかりませんでした。(その時は)挫折しました。多分、元記事の方も同じような状態なのだと思います。

一つの課題をクリアしたものの、次に何をすれば理想のプログラマに近づけるのかわからず戸惑っているのではないでしょうか?

プログラミングで世界を変えるということ

その後、自分がどうやってこの壁を越え、プログラミングを道具と認識したのかを振り返ってみます。

大学の授業や新人研修でのプログラミングの勉強はしました。課題を解くことはできました。それでも、コンソールに表示するプログラミングと、世間に溢れている(当時は今ほど無いけど)WEBやGUIのプログラミングが遠すぎて、やはりプログラミングが何かよくわかりませんでした。 結局、仕事で3000行ぐらいのプログラム書いたときに、やっとプログラミングが何かわかった気がします。

何が本質的な課題なのでしょうか? あるいは量でしょう。基本的な文法に悩まなくなった時に、プログラミングで解決したい課題に悩むことができます。

おそらく、もっとも重要なことは

現実に存在する課題を解決するプログラミングを書くこと

でしょう。練習問題を解いても、世界は変わりません。現実の課題を解くと、世界をプログラミングでちょこっとだけ変えることができます。

世界を変えることは、小さな変更を繰り返すことです。

職業プログラマのすすめ

プログラマとして就職すると、絶えることなく「解決すべき現実の課題」を提供してもらえます。 しかも、プログラミングスキルに合った規模に分割して「ここだけ書いて」と教えてくれるので、ハードルがぐっと下がります。

ある若者は、自分で書いたプログラムを、実際に使って喜んでいる人を目の当たりにして、プログラミングに対する意欲がガラリと変わりました。これは「自分がプログラミングで世界を変えたこと」を実感したからではないでしょか?先輩技術者と一緒に、現実の課題を解決するのはおすすめです。

他人の課題を解決するのに飽きたら、自分で好きな課題を見つけて解決すればいいのです。それはもしかすると、世界を大きく変えるかもしれません。

Ruby on Railsの複雑度が問題?

Railsはプログラミングでは無いのか | サークルアラウンド株式会社ではRailsの抽象度の問題と解釈してSinatraをすすめています。

なるほどSinatraの方が少し簡単ですし、過去にSinatraの方が簡単なのにと愚痴ったこともあります。 Railsは覚えることが多いので「プログラミング初心者には大変だなぁ、Sinatraの方がまだ良いなぁ」とは思います*1

また、課題を取り組みながら仕組みを、わかりやすく説明してもらえれば、Ruby on Railsの使い方だけでなく、Webアプリケーションの仕組みやデータベースを使う意義などを理解できるかもしれません。

それでも、言われた通りにプログラミングするのと、現実の課題を解決する道具としてプログラミングするのはちょっと違うような気がします。

プログラミング研修の限界

研修課題には解決できない(かもしれない)問題は出せません。また、現実の課題をプログラミングで解決可能な形に解釈するには、独特のコツが要ります*2

現実の課題を解決する形でプログラミングを学んでいくコースを、2ヶ月18万円で提供するのはちょっと難しそうです。

一ヶ月90万を半年間払っていただければやります。人によっては60万円ぐらいでやってくれるかもしれません。 ただし、ゴールは対象者の資質によって大きく変わりそうです、保証できません。 こういう条件で申し込んでくる人はいなさそうですね。 そんなわけで、ビジネスとしては成り立ちません。

まとめ

プログラミングで世界を変える最短経路は

  1. 職業訓練と割り切ってRuby on Railsの勉強をする*3
  2. プログラマとして就職する
  3. お仕事としてプログラミングする
  4. インターネット世界の構成要素を知る
  5. 世界を変える

以上です。身も蓋もありません! プログラミングを楽しんでね!

*1:プログラミング初心者にとってはSinatraRailsのControllerはどっちも難しいかもしれません

*2:恐ろしいことに、このコツは日々変わります。そのお陰で職業プログラマは食いっぱぐれません

*3:別のプログラミング言語でも、別のフレームワークでもライブラリでも、就職に役に立ちそうであれば、なんでもいいと思います

日本Kindle化計画 その2

APIデザイン的な悩み

「ASIN登録用APIで、即座にKindleの有無をチェックしに行くべきか?」

メリット

即座にフィードバックが得られる

デメリット

APIを公開できない(公開版を別にデザインする必要がある)

  1. Amazon APIに呼び出し制限がある
  2. 並列して実行すると呼び出し数を制御できない

公開版を考えると...

  1. 非同期処理にして、結果をあとで受け取ればできる
  2. 即時性がなくなる

背景

ASIN登録用APIに必ず求めること

  • ASIN(正確にはISBN10)でない文字列を無視する
  • ASINを含むURLからASINを取り出す
  • ASINを検索候補として保存する

実装して試しに幾つかのURLを登録したところ、Kindleの有無チェックが欲しくなりました。

結論

翌日、もう一度使ったらいらなくなりました。 APIの使い方に迷っていただけのようです。

日本kindle化計画 その1

背景

占有体積コストがバカにならないので、漫画を極力Kindleで買うようにしています。 Kindle版は紙の書籍より遅れて登録されます。 紙の書籍を発見されてから、Kindle版が出ているかどうか定期的に確認する必要があります。

既存のKindle化チェックツール

既存のチェックツールがあります。

ざっくり、以下の点が僕の要望とミスマッチです。

通知方法がメール

  • kindlize-itは通知方法がメールです

以下、Kindle Alertのみの話です。

ログインが必要な理由が書いていない

  • ツイッターID確認のためだとは思う
  • 他人のIDを登録しても大した悪さはできない気がする・・・
  • メンション自体は自由に飛ばせる
  • 全く使っていない人はブロックすればいい
  • 使っている人に、自分の好みでないものを勝手に追加されると辛い気はする
  • 削除できないのが問題な気もする

キーワード検索

  • 使う時点で、紙の書籍があることは知っています
  • asinを直接指定したい

検索結果にkindleがあるか載っていない

  • 毎回amazonへのリンクを開くの?
  • kindleがあっても登録できてしまう・・・

自分への通知が登録済みかどうかわからない

  • ストーキングに使える?
  • twilogで検索しても一緒なので、過去に対しては意味がない

どういう通知が来るのかわからない

  • 直近のツイートが表示されていると良さそう

APIがない

  • Chrome拡張から登録できない

その他

  • 検索結果がconfirm?
  • なぜ1アカウントずつツイートなんだろう?他人のアカウントが見えたらまずい?
  • ハッシュタグが入っていればいいのに
  • 既にkindleが出ているものも通知してくる

自作

とりあえずチェック部分だけ作りました。 まだデータ投入は生クエリです。

さっそく、入力データをミスりました。 次は、入力インタフェースを作ろうと思います。

辛さ

AWSTwitterの二つのAPIで6個の秘密情報を管理するのが辛いです。

#TestingFrameworkMeeting に参加しました(1) - テスティングフレームワークの歴史

参加した時のメモです。

t-wadaさん

Testing Framwork Meeting

テスティングフレームワークの歴史

http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。

有史以前

make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。

JUnit

Kent BeckJUnitを書いた。

プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。

テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。

自動テストがあれば、設計して実装してから、実装だけを直せる。 サイクルをもっと短くし、テストファーストリファクタリングを繰り返すテスト駆動開発(TDD)が生まれた。 *1

JUnitの語彙assertEqualsがテストコードを支配した。

JUnit Pocket Guide - O'Reilly Media がテスティングフレームワーク作者ののバイブルになった。

BDD

テストコードが表しているのは、テストではなく仕様であると考える者達が居た。 Dan Northは、それにbehavior driven development(BDD)と名付けた。

RSpecが生まれ、振る舞いを記述するための語彙、should, expect ... 、が増えた。 各プログラミング言語にXSpecが生まれ、語彙が乱れていった。

また、自然言語のように書けテストコードをのように動く仕様で、 お客さんと一緒に仕様を書くことを考える者達が居た。 Fitが生まれ、cucumberが生まれた。

BDD派は、前者がSpec BDD派へ、後者がScenario BDD派へ分派していった。

power-assert

RSpec3が生まれた。テストコードの語彙がさらに増え、いろいろな書き方ができるようになった。 テストコードを書くのに学ぶべきことが増えた。

多くのRuby on Rails使用者は、Rails本体とRSpec、両方の変化の速さについて行くために苦しんだ。

テストが失敗した原因をわかりやすくするために、 語彙を増やす以外にテスティングフレームワークができることはないか考えた者が居た。 Groovyにspockが生まれた。 そこにはPowerAssertと呼ばれる力があった。

Condition not satisfied:

name.size() == length
|    |      |  |
|    6      |  7
Scotty      false
魅惑的(Fascinating)なテスティングフレームワーク Spock - A Memorandum

エラーに失敗した時だけ饒舌なassertが生まれた。 ASTをごにょごにょして、t-wadaさんがJavaScript版のpower-assertを作った。

evolve slowly

テスティングフレームワークは、直接的にプロダクトコードを改善しない。 10年くらいのペースで変わるのが望ましい。

議論

語彙と階層
  • RSpecの語彙の多さは、目的が仕様記述言語を目指しているから。 多くのユーザーは階層化と語彙の多さは分離して欲しいが、わけて使えない。 それで批判に繋がっているのでは?
  • RSpec以降のライブラリは階層と語彙を分けれるようになっている。(例えば)mochaは階層化だけを提供していて、assertライブラリは別に組み合わせて使う。
学習コスト
  • RSpecのシェアが大きすぎるので、学習コストの批判が目立っているのでは?
  • 政治的な理由でRSpecを選択していることもある。それで批判されやすいのかもしれない。
日本語でシナリオBDD
  • cucumberは正規表現で実装されている。日本語で使える可能性や価値はあるのか?
  • 過去に、「なでしこUnit」を作った。日本語の語順と制御の順が合わないので、そんなに嬉しくなかった。
テストコードのレイヤーが増えること
  • (プロダクトコードと異なるプログラミング言語で描かれている)cucumberを使った、テストは落ちたときに原因を探すレイヤーが増えて辛かった。
  • JavaのテストコードをGroovyで書く人たちがいる。テストコードを書く効率はあがる。
Reads like as spoken language
  • RSpecには読みやすさを提供する目的があったのでは?
  • JUnit4でisが入って読みやすくなった。覚えるコストは増えた。これは二律背反、当分解消できそうにない。
Expamleとしてのテストコード
  • Expamleとしてのテストコードを考えると、TDDではプロダクトコードに近く例としてわかりやすい。 BDDで仕様記述に近いと、例として使えなくなっていく。
  • Exampleとしてのテストコードは一部なので分けて考えた方がよさそう。 Haskellにはdoctestという、公開するAPIにExampleとしてのテストコードをつける文化が生まれている。公開しない部分はhspecで書く。
  • Goでは、Exampleとしてのテストコードを書くツールがある。

simple vs easy

power-assertの設計思想について。

で、衝撃を受けたという話。

  • Simple 客観的
  • Easy 主観的

SimpleとEasyは混同しやすいけど、分けて考えた方が良い。 原則はSimpleを目指し、EasyはEasyを提供する別レイヤーを提供すると良い設計になる。

実際にソフトウェアを作る時は、怠惰・短気・傲慢の怠惰を元に、 簡単さを求めて作り始めて、複数の簡単さの競合に気づいて、「シンプル」と「簡単」に分けるようになることが多い 。

qunit-tapの開発では、当初Easyを求めて「自動的にQUnitを探す」設計にしていた。 多様な環境に対応できなかったので、Simpleな「QUnti引数で受け取る」設計に変えた。 結果、より多くの人に使いやすくなってユーザーが増えた。

リンク

つづき

は、書かないかもしれません。

*1:詳しくはわからないがXP本の1版と2版の間の、どこか

ゴー・ノーゴー課題の原著論文を発見

最近の小学生における高次神経活動の特徴 : go/no-go 実験における誤反応と型判定を基に

計測方法

Pavlov, I. P. 理論(ハ・エス・コシトヤンツ,1955)に基づいて 
Luria, A. R.(1969)により考案された方法

形成実験

「いまから,みなさんの目の前のランプがこの色(赤色)に光ります。この色に光ったら,
すばやくゴム球を握ってください。消えたらパッと離してください」との指示を与え,
10 回の練習を行った後,直ちに 3 ~ 6 秒間隔で,1 回 0.5 ~ 1.5 秒間の光刺激を5 回呈示した

分化実験

次に,「今度はこの色(黄色)に光る時もあります。でも,その時は握ってはいけません。先ほどと同じ,
この色(赤色)の時だけすばやく握ってください」と の指示を与えて,
4 回(go task:2 回,no-go task:2 回)の練習を行った後,直ちに go task と no-go task を
ランダムに呈示した(分化実験)。
この時の光刺激の 呈示間隔と時間は先の形成実験と同様であるが,刺激回数は go task,
no-go task とも 11 回ずつとした

逆転分化実験

最後に,「最後は先ほどと反対です。この色(黄色)の時にすばやく握ってください。この色(赤色)の時
は握らないでください」との指示を与え,4回(go task:2 回,nogo task:2 回)の練習を行った後,
直ちにgo taskと nogo task をランダムに呈示した
この時の光刺激の呈示間隔,時間,回数は,すべて分化実験の場合と同様とした

各型の分類基準

分類型 分化実験 逆転分化実験
不活発型 no-go taskに対する誤反応3個以上かつgo taskに対する誤反応1個以上
興奮型 no-go taskに対する誤反応3個以上かつgo taskに対する誤反応0個
抑制型 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応1個以上
おっとり型 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応0個 no-go taskに対する誤反応3個以上もしくはgo taskに対する誤反応1個以上
活発型 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応0個 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応0個

考察

元来,ヒトは 5 つの型の中でも最も幼稚な型といえる「不活発型」からスタートし,加齢とともに子ども
らしい「興奮型」の時期を経て,次第に成人らしい「活発型」に移行していく(正木・森山,1971;
西條ほか,1981)ものと考えられてきた

これはあまり違和感を感じません。

1998 年調査の結果では,小学校に入学する頃になっても「不活発型」が 5 ~ 6 割にも達しており,
かつその後の推移をみても,男子ではなかなかこのタイプの子どもたちが減っていかない様子から
「学校崩壊」と呼ばれているような事象が起きてしまうのもある程度うなずけるのではないか,
と推察されている(野井,2006)

これはちょっとだけ違和感があります。

感想

go task 11回試行中1ミスで不活発型が興奮型に分類されるのがシビアに思えます。 ですが、結果を見ると、抑制型の出現率は10%前後です。妥当なのかもしれません。

実施環境(明るさ、環境音)によって結果が左右されそうな実験に思えます。 複数の対象群を比較しても意味はないのかもしれません*1

前記事

ledsun.hatenablog.com

*1:ソフトウェア工学でも「異なるソフトウェアを作る異なるスキルのエンジニアで構成されたチームを、同じ計測方法で計測すれば比較できる」と考えてしまうミスが、しばしば起こります