2014年6月26日木曜日

MeCabで形態素分析してTwitter Cloudをつくってみる

PHP、JavaScriptでやってみます。
環境はMac。

使ったもの

  • XAMPP
    PHPのall in one開発環境
  • MeCab
    形態素分析ライブラリ
  • php-mecab
    PHPでMeCabを使うためのライブラリ
  • jqcloud
    タグクラウドをjavascriptでつくるためのライブラリ
  • twitteroauth
    twitterの認証ライブラリ

準備

参考にしたURL:
http://www.aoharu-b.com/cgi/sk/2013/09/vpsmecabphpcentos64php533542.html
※準備はこっちを見たほうが丁寧です。。。

XAMPPをインストール

インストールは省略。
macの場合、デフォルトでPHPが入ってて、XAMPPのPHPと混ざってちょっと困る。
なんで、XAMPPのPHPを使うように、以下の設定をしておく。

1. 自分のホームディレクトリの .bash_profile ファイルに以下を追記(ファイルがなければつくる)。

export PATH="/Applications/XAMPP/bin/:$PATH"

2. macのデフォルトのphpを退避

sudo mv /usr/bin/php /usr/bin/php_org

3. ターミナルを再起動

which php

=> /Applications/XAMPP/bin//php

4. apacheを再起動

mecabのインストール

cd
wget https://mecab.googlecode.com/files/mecab-0.996.tar.gz
tar zxfv mecab-0.996.tar.gz cd mecab-0.996
./configure --enable-utf8-only
make
make install

辞書のインストール

wget http://sourceforge.net/projects/mecab/files/mecab-ipadic/2.7.0-20070801/mecab-ipadic-2.7.0-20070801.tar.gz
tar zxvf mecab-ipadic-2.7.0-20070801.tar.gz
cd mecab-ipadic-2.7.0-20070801
./configure --with-mecab-config=/usr/local/bin/mecab-config --prefix=/usr/local/ --with-charset=utf8
make
make install

autoconfのインストール(php-mecabのインストールに必要)

cd
wget http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz
tar xfvz autoconf-latest.tar.gz
cd autoconf-2.69
./configure
make
make install

php-mecabのインストール

cd
wget https://github.com/downloads/rsky/php-mecab/php-mecab-0.5.0.tgz
tar xzvf php-mecab-0.5.0.tgz
cd php-mecab-0.5.0
phpize
./configure --with-php-config=
/Applications/XAMPP/bin/php-config --with-mecab=/usr/local/bin/mecab-config
make
sudo make install

設定ファイルの修正

vim /Applications/XAMPP/etc/php.ini

以下を追記
extension=mecab.so

twitter apiのアカウント作成

以下にアクセスしてログインする。

[Create New App]する。
API KEYSタブで次の作業をする。
  • [Cange App Permissions]
  • [Create my access token]

で、以下をメモ。
  • API key
  • API secret
  • Access token
  • Access token secret

プログラム

以下をXAMPPのhtdocs配下に置く。
https://github.com/itagakishintaro/twitter-cloud

TwitterAPIHandler.phpを開いて、apps.twitter.comでメモした部分をコピペ。
XAMPPマネージャからApacheを起動。
ブラウザから以下を開く。
http://localhost/twitter-cloud/index.html

おしまい。

2014年5月27日火曜日

クロスプラットフォーム、クロスブラウザのテストを仮想環境で簡単に

仕事でIE8のテストをしなければならなくて、そんな端末ねーよ!って思ってたら、仮想環境で簡単にテストできたのでメモ。
いやー、時代が変わったなぁ。。。

以下の手順の6と8は日本語対応のため。
XPのCDがあれば、以下の手順でOSレベルで日本語対応できるみたい。
コントロールパネル
->Regional and Language Options
->Languageタブ
->Install files for East Asian languagesにチェック
->Apply

あと、XP以外であれば、他にも方法があるらしい。

1.VirtualBoxのインストール

https://www.virtualbox.org/wiki/Downloads

2.仮想イメージのダウンロード

以下から、Windows, Virtual Box(Windows上)を選択し、IE8-XPのファイルを全てダウンロード
http://modern.ie/ja-jp/virtualization-tools#downloads


3.ダウンロードしたexeファイルを実行する



4.作成されたovaファイルをダブルクリックする



5.VirtualBoxマネージャーの設定から以下を実施

共有フォルダー
->画面右上の追加アイコンをクリック
->任意のフォルダを追加(読み込み専用、自動マウントの両方にチェック)


6.フォントをコピー

C:¥Windows¥Fonts 配下のMSゴシック、MS明朝を共有したフォルダーにコピー


7.仮想環境を起動



8.仮想環境でフォントをコピー

共有したフォルダーのフォントをC:¥Windows¥Fonts配下にコピー


9.Lets's TEST!!!

OSは英語でもブラウザでは日本語がみれる!

2014年5月25日日曜日

PI Study #2 「ペアワイズ法を使ったテスティングワークショップ」

@東京都豊島区東池袋3丁目4番3号池袋イースト10F テラインターナショナル株式会社
http://pistudy.doorkeeper.jp/events/11043

仲間とはじめた勉強会の2回目。
1回目はSTARの良質なコンテンツを使ったので、余裕だったけど、今回は1からつくったので、なかなか大変でした。
で、一人KPT。

KEEP


  • 講義を聞くだけではなく、実際に手を動かす
  • モクモクとやるのではなく、チームで話しながらやる
  • 講師は気負わず、知ってる範囲で知ってることを伝え、共に学び合う
  • みなさん熱中してくれた(休憩もとらずにやってた)
  • 「他の勉強会も色々でてるけど、平均より良い勉強会ですよ」と言ってくれた
  • 永井くんが「Gebを勉強して今度は僕がやります!」と言ってくれた

PROBLEM


  • ペアワイズ法と銘打ったにも関わらず、ペアワイズ法を深堀りしなかった
  • 2因子網羅の部分の説明が足りず、理解してもらえなかった人がいた
  • DevNomiテスト編で、計算が複雑すぎてそこで無駄な時間を食ってしまった
  • チームに発表してもらったときに、気の利いたコメントが言えなかったし、チーム間でディスカッションするファシリテーションができなかった
  • 若手向けを意識したけど、若手は勉強会にはあまり来ない

TRY


  • 絶対に持ち帰って欲しいものを1つ決めて、そこはきちんと深堀りして準備する
  • ディスカッションの時間をきちんととり、準備したうえでファシリテーションする

2014年5月17日土曜日

DevLOVE「オブジェクト設計とリーン開発、その実践」に参加しました


@名古屋市中区錦1-15-8 アミティエ錦第一ビル 4F Coworking Space A+LIVE セミナールーム

正しいものを正しくつくる
ギルドワークス創業おめでとうございます!
増田さんのプロジェクトで増田さんに叱られながら仕事してみたいなぁ。

第一部 オブジェクト設計エクササイズ [13:10〜14:00] 増田亨氏



設計とは、変更コストを下げるためにコードを整理整頓する実践的な工夫

プロセスやツールよりも設計

コードを整理、整頓する。
それは、変更コストを下げたいから。
(作って終わりならいらないけどね。)

実践的ってなんだろう?

いくつかの観点で、対岸を行ったり動きながらバランスを取る。
(全体<->部分、長期<->短期・・・)

具体的にどうやるの?

変更コストの原因を知る。
変更コストの最大の敵は「重複したコード」。

重複したコードのいやな臭い(Martin Fowler "Refactoring")


  • 長いメソッド
  • 大きなクラス
  • たくさんの引数


マスダ流重複の臭い判定基準


  • クラス:50行(100行)
  • メソッド:3行(5行)
  • 引数:0(1)

これを超えたら警戒警報!
(カッコの中はチーム用に緩めた数字)

コード整理の基本パターン


  • Value Object
  • 振る舞いを持った区分
  • ファーストクラスコレクション


Value Object

immutableがポイント。
例)Stringクラス
内部の値を変えずに、新しいObjectを返している。

getメソッドをつくらない。
getをつくるとロジックが散らばる。
データのある場所にロジックを寄せる。
setメソッドもつくらない。
setをつくると状態管理のコードが散らばる。
=> immutable(不変オブジェクト)

プリミティブなクラスは使わず、業務(ドメイン)固有のクラスを作る。
例)
String, StringBuilder, List<String> => ProductName, Remarks
BigDecimal, Integer => Money, Quantity, Unit
Calendar, Date => InitialDate, DueDate, ValidTerm

振る舞いを持った区分

enumにメソッドを持たせる。
定数も、関連するロジックはそこに閉じ込める。

ファーストクラスコレクション

privateなコレクション、publicな振る舞い。
コレクションをgetして操作するとあちこちにコードが登場する。
例)
Customers, OrderLines, UsageHistory, ToDoList・・・

コードの整理 アンチパターン


  • Smart UI(画面単位で設計)
  • トランザクションスクリプト(機能単位で設計)
  • Active Record(テーブル単位で設計)

=> 必ずコードが重複する。

Smart UI => 画面間で重複が発生する。トランザクションスクリプト => 機能間で重複が発生する。
Active Record => テーブル間で重複が発生する。

コードの整理 グッドパターン


  • 3層+ドメインモデル
  • 業務の関心事(業務知識)に基づき設計する

=> 変更が簡単

  • 仕様変更は業務から発生する
  • 業務の関心事の依存関係がクラスの依存関係になっている
  • 変更の対象箇所以外でわけのわからない副作用がおきない


第二部 リーン開発の現場 [14:10〜15:00] 市谷聡啓氏


理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ!

誰かが正解を持っている訳ではない


開発の命運を握る2つのレバー


  • 期待
  • リスク


期待

関係者が互いに持っているプロダクト/プロジェクト/チームへの暗黙的な望み

期待マネジメント

期待を明らかにして適切に調整しつづける。役割と時間を超えて。

チーム => プロジェクト => プロダクト => ビジネス => 組織

レイヤーごとに目的と期待がある。
レイヤーを超え、役割を超えた理解が必要。

Moving Management Target

期待とリスクのバランスは時間とともに変わっていく。
時間を超えた理解が必要。

インセプションデッキ

期待マネジメントのツールの1つ。
大事なのは、アウトプットではなく、その過程でお互いに理解しあうこと。

仮説検証型と最短距離型

目的実現のための選択肢がいろいろある。
=> 何を選ぶか決めるために試行し検証する。
=> 検証から何をどう作るか徐々に決められる
=> 手段と対象がわかれば、最短距離でつくる

スコープが決まってないのに期限だけ決まってる
=> 超危険
=> 仮説検証時は期間契約、スコープが決まれば請負契約

大事なのは、フェーズによって戦い方が変わるということ。

仮説検証型のPlan

リーンキャンバス(仮説)
=> エクスペリエンスマップ(検証)
=> ユーザーストーリーマッピング(仮説)
=> インセプションデッキ(検証)

参考)
「開発戦略は「意思決定」を遅らせろ!」(稲垣 公夫)

最短距離型のPlan

CCPM
パーキンソンの法則:バッファを使いきってしまう。
=> バッファをプロジェクト全体で管理する。

荒ぶる計画を飼い慣らす

  • 要求レベルをMust, Want, Tryで可視化する
  • プロジェクトの8-9割でMustを実現できる見込みを立てる
  • 残った工数でWantを開発する


仮説検証型のDo

なんのための反復?
何を検証するのか?

カンバン(仮説検証型、最短距離型)

仮説検証型:タスク、課題解決の可視化 => タスクボード
最短距離型:全体フローの見える化 => カンバンボード

仮説検証型と最短距離型の見極め

=> インセプションデッキ

ソフトウェアを創り上げるもの

誰が、誰と、誰のために
どういうルールで、何を作るか

リーン開発の現場 P.109

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ!

第三部 Q&A [15:10〜16:00]


  • DDDをどれくらいかけて覚えれば?
    => 2008年からはじめてわかりはじめたのが2012年。現場で続けるのが一番。
  • フレームワークを使っている場合(コード自動生成)の折り合いは?
    => 大嫌いだから使ってない。折り合いの付け方もノウハウ。
  • クラスが多くなったときのまとめ方は?
    => 業務にあわせてパッケージを構成している。
  • お客様に丸投げされたときにどうすれば?
  • バッファと見積の合意方法は?
    => QCDSのトレードオフスライダーを使ったりする。
  • そもそもドメインって何?
    => まあ、気にしないほうがいい(^^)。カタカナは日本語にするとよい。
  • インフラからプログラマになるとき何を学べば?
    => 今はインフラもコードで自動化する時代。そこからはじめては。
  • 設計の価値をどう伝えれば?
    => 相手が開発者であれば、変更が大変だったネタを思い出して盛り上がる。そこからスタートすると伝わりやすい。設計とは何かとか良い設計とはとかのアプローチは必ず失敗する。ただ、人がつくったコードで痛い目あってる体験共有からだとうまくいかない。
  • 期待をどうマネジメント?どうまとめる?
    => インセプションデッキを使う。困ったらぜひギルドワークスへ(^^)。インセプションデッキの期待が高くなり過ぎないようにしれっとね。
  • 設計の考え方をどう共有するか?
    => 経験がないのでわからない。若い頃は意地になって相手を潰すぐらい勉強した。
  • カンバンをどう広めるか?
    => いきなり実プロジェクトでやるのはリスクが高い。カンバンだったら、まずは、自分でやれる範囲でやるとか。失敗できるところでやってから。
  • どんなドキュメント管理してる?
    => クラス図やドキュメントを全部作ってない。ドメイン知識が増えれば、ドキュメントがなくてもわかる。新しいメンバーにはドキュメントではなく、業務を覚えてもらう。業務がわかれば、ソースが読める構造になっている。
    => IDEが優秀だから。IntelliJ IDEAがオススメ。すぐ乗り換えよう。
  • どんな工程?
    => 全部網羅的に設計せずに、重要な部分だけ抜き出して設計してる。
  • 開発スピードが落ちない?
  • マスダ流は厳しすぎない?
    => 実践でいきなりやるのは難しいかもしれないが、実際にやって、まずは体験してみて。
  • なんのロジックも持たなくて、単純な置き換えでもクラス化する?
    => する。名前がほしいから。

2014年5月13日火曜日

SeleniumとGebとCasperJSの比較

STARの教材を使って、SeleniumとGebとCasperJSを比較してみました。
どれも詳しくなく、軽く触っただけですが。

比較結果

個人的には、Geb(+spock)が好きです。
ただ、Web系でJavaScriptバリバリの人が多いなら、CasperJSは有力でしょう。
コマンド一発でインストールできて、テキストエディタ一本で開発できちゃうし、動作もサクサク。
この軽量さは好感が持てます。
クロスブラウザができないという弱みはありますが、結局、クロスブラウザって目視確認しないと微妙な崩れとかわからないので、実はそんなに弱みではない場合も多いと思います。

操作性

操作性はGebが圧倒的です。
JQueryライクに要素をとれたり、すべてのhtmlコントロールでメソッドが大体同じだったり、シンプルにコードが書けたり、とにかく気が利いています。
CasperJSもJQueryライクに要素がとれて便利ですが、メソッドを揃えるような工夫はあまりないです。
あと、JavaScript全般に言えることですが、入れ子が多くなって私は嫌いです。
Selenium(Java)は、とにかく長たらしく書かなければならないので面倒です。

Selenium:☓
Geb:○
CasperJS:△

環境整備の容易さ

Seleniumを普通とすると、Gebは少し面倒でした。
groovyとspockのバージョンの整合性ではまったり。。。

比較ということでGebを☓にしましたが、SeleniumとGebはそんなに変わらなく、CasperJSが圧倒的に簡単です。
コマンド一発で環境整備できちゃいます。
(「WEB+DB PRESS vol.80」がとてもわかり易いです。)

Selenium:△
Geb:☓
CasperJS:○

クロスブラウザ

CasperJSはPhantomJSで動かすものなので、そもそもクロスブラウザという概念がありません。
SeleniumとGebはクロスブラウザ対応しています。

Selenium:○
Geb:○
CasperJS:☓

コード

GebとCasperJSは私が書いたので、あまりキレイではないかもしれませんが、コードを比較してみてみるとおもしろいです。

Selenium

STARリポジトリ のanswer参照。

Geb


CasperJS

https://github.com/itagakishintaro/STARHandsOnCasperJS

2014年4月5日土曜日

「UX、デザイン思考、リーンスタートアップのためのインタビュー入門」に参加しました

UXD/HCD ワイワイCAFE「UX、デザイン思考、リーンスタートアップのためのインタビュー入門」@株式会社アイ・エム・ジェイ 本社 青葉台カフェ

UI/UXに限らず、業務システムの業務ヒアリングなどでも使えるとてもよいワークショップでした。

v=f(x):「ユーザーの声を聞くべからず」

ユーザーインタビューなのに、ユーザーの声を聞いてはならない。
それはなぜ?
ユーザーの声は、ユーザーの体験をユーザーが分析したものだから。
v=f(x)のvはボイスで、xはUX。
UXを素人であるユーザーが分析した結果であるユーザーの声を聞いてはならない。
ユーザーの体験そのものを理解し、我々が分析しなければならない。

弟子入りゲーム

アンケートもグループインタビューもユーザーの声を聞く手法。
では、どうやって、ユーザーの体験そのものを知るのか。
その答えが「弟子入り」。
ユーザーを師匠と見立て、弟子になったつもりで聞く。

基本

基本は次のとおり。
  • クローズド質問(Yes/Noで答えられる)ではなくオープン質問(体験を自由に語ってもらう)
  • 文脈をクリック(気になるところがあったら、そこを掘り下げる)
  • 意見や判断を聞かない
  • 仮説検証(こうだったらどうします?)はダメ、体験を聞く

ゲーム1回目(5分で3センテンス正解)

師匠(ユーザー)と弟子(インタビュアー)に分かれます。
師匠は、ユーザー体験がA4で4ページくらい書かれたスクリプトを読んで、ユーザーになりきる。
弟子は、インタビューをして、師匠の体験をインタビューして書き取る。
さて、どのくらい聞き取れるでしょうか?
私はボロボロで3センテンスしか正しく聞き取れませんでした。

ゲーム2回目(10分で15センテンス正解)

インタビューの仕方を少し教わります。
コツは次のとおり。

  • 占い法はダメ(当てに行かない)
  • 次は何をします?と聞いていく
  • ある程度いったら、戻って、その前は何をします?と聞いていく
  • 知ったつもりにならない

これを聞いた後、やり直したら、びっくりするくらい正しく、多くスクリプトを読み取れました。
1回目の後だし、時間も倍になっているので当たり前ではありますが、コツを意識するだけで、圧倒的にやりやすくなりました。
(1回目はアンチパターンの「占い法」でいってしまっていました。。。)

インタビュー設計

KJ法


聞きたいことリストをKJ法で整理します。
KJ法はおなじみですが、少し誤解があるそう。

  • 似たものを近くにするとき、今、貼られているカードの中での相対的な距離で考える
  • トップダウン的思考になるので見出しを先につけてはダメ、あくまでボトムアップ思考
  • 縦横整列させず、空間をめいっぱい使う

写真は私のチームの成果物です。

シーケンス+質問を考える


次に、インタビューのシーケンスを考え、見出しと聞きたいことを一列に並べます。
その後、質問を考えます。
質問は、弟子入りゲームで学んだことを活かして考えます。
写真は私のチームの成果物です。
※見出しのカードの字体が素敵でしょ。チームにたまたま不思議書体女子がいました(^^)

懇親会

懇親会が熱かった!

リアルタイムドキュメンテーション


リアルタイムにドキュメンテーションする方法らしいです。
1チームが実験台になって、スタッフに観察+リアルタイムドキュメンテーションされ、これを使ってふりかえりが行われました。
カードの分類は以下のとおり。
  • 黄色カード:事実の記録
  • 黄色カードに赤い枠:講師の言葉
  • 青カード:観察者の主観(気になったコト)
  • 青ミニ付箋:残念な点
  • 赤ミニ付箋:よかった点
これを観察者が説明して、観察されたチームが反論するというもの。
はじめてみたのですが、とても面白かったです。
でも、やるのはちょっと難しそう。。。

アプリデモ

UI/UXの賞をとったIMJさんの子供向けアプリ。
本当に、UI/UXが考えられたおもしろいアプリでした。

メンタルモデル

書籍「メンタルモデル」の訳者の1人、羽山祥樹さんによるメンタルモデルの解説。
その解説に、今回の講師の樽本さんが割り込んでディスカッション。
熱かった!
ちなみに、メンタルモデルは「ユーザーが期待、想像するもの」的なメンタルモデルとは別。
行動観察ではなく、インタビューから読み取るものなのでメンタルモデルと名付けられたそう。
混同するからよくないよね。

2014年4月4日金曜日

PI勉強会#1「Selenium勉強会」


@テラインターナショナル

記念すべき第1回は、2013年12月1日に大盛況のもと行われた、システムテスト自動化カンファレンス2013 ハンズオン「実践で学ぶ、効率的な自動テストスクリプトのメンテナンス」のコピーです。

こんな良質なコンテンツをフリーで公開しちゃうなんて、STARありがとう!
コンテンツ作者のTRIDENT伊藤さん、ありがとう!

以下、オリジナルコンテンツに対して、私なりにちょい足しした内容をメモしておきます。

メソッドチェーン

SHIFTの玉川さんに教えてもらいました。ありがとうございます。

模範解答では、以下のようになっています。

pageObject.method1(foo);
pageObject.mothod2(bar);
・・・

これより、次のようにメソッドチェーンで書いた方が美しいコードになります。

pageObject.method1(foo)
               .mothod2(bar)
                ・・・

SpockとGebの紹介

※Gebはきょんさんに紹介してもらいました。ありがとうございます。

ハンズオンはJUnitですが、Spockの方が書きやすい。
Groovy, BDDとか言うと、何だか難しそうに思えるけど、実はSpockを使った方が簡単ということを伝えました。
口頭だけなので、どこまで伝わったかわかりませんが。。。
JUnit実践入門もとってもおすすめしたので、どっちやねん!って感じだったかも。。。)

Gebは、JQueryライクに要素をとれてスッキリ楽々なことと、値の入力、取得がほとんどのコントロールで同一なので、むしろSeleniumより覚えること少なくて楽だということを伝えました。
こちらも伝わっていればよいのですが。。。

データ駆動とキーワード駆動の紹介

※もし、間違ってたら、誰かやさしくコメントください。



キーワード駆動(もどき)のデモ

※あくまで、もどきです。

これは結構ウケました。
えー、こんな簡単に、こんなことまでできちゃうのー的な(^^)


pages配下:テスト対象のコード
src/test配下:テストコード
(KDTcore.groovyがコアのコード)

※Groovyの環境設定はREADME.mdを参照してください。