Symfony2を試してみて[一人Web系AC2011]

連続でお送りする、PHPの有名FWお試し＆比較記事シリーズです。

今日は、Symfony2についてです。

まずは、これまでと同じ仕様のサンプルを作成しました。

「同じ仕様って、どんな仕様なんじゃい？」

と言う方は、こちらの記事をどうぞ。最初のほうに書いてあります。

http://faltc.blogspot.com/2011/12/cakephp-20-webac2011.html

内容的にですが、Symfony2もblogチュートリアルがあるので、そちらを参考に一部手を加えました。

ページャ追加したり、formをせっかくだからクラスで作ってみたり、ですね。

そのソースが、こち…ら…。

すんませんまた上げ忘れて手元にありません何やって（ｒｙ

後日上げなおします。

■大体の流れ

前回と同様、Symfony2を読むための流れです。

1. app/config/routing.ymlから、利用するバンドルを調べる
   今回のサンプルの場合、以下のような形になっています。
   

   sample:
       resource: "@MySampleBundle/Resources/config/routing.yml"
       prefix:   /sample

   resourceが挿す先は、バンドルのrouting設定ファイルです。
2. バンドルのrouting.ymlを見て、コントローラと対応するメソッドを調べる。
   バンドル自体はsrcディレクトリの先にあります。
   今回の場合、パスは以下になります。
   src/My/SampleBundle/Resources/config/routing.yml
   patternにURIのパターンと、そのパターンでリクエストが来た場合に呼び出される内容がdefaultsに記載されています。
   

   sample_index:
       pattern: /
       defaults: { _controller: MySampleBundle:Default:index }

   この場合、MySampleBundleのDefaultControllerのindexAction()が呼ばれる事になります。
   {}で囲まれたものがある場合、それはアクションの引数になります。
3. 対応するコントローラの処理を読む
   この辺の内容は、基本的なPHPです。
   MVCでいうMにあたる、DB操作についてはdoctrineを利用します。
   "MySampleBundle:Data"の場合、接続先DBの"Data"テーブルを読むと言う事さえ判れば、なんとなく読めると思います。
   ビューについては、$this->render()にて指定しています。
   最初の引数がテンプレート、次の引数がテンプレートに引き渡す値の配列ですね。
4. テンプレートを読む
   テンプレートは[バンドルルート]/Resources/viewsにあります。
   コントローラ上で
   'MySampleBundle:Default:index.html.twig'
   として呼び出されていた場合、テンプレートのパスは以下になります。
   src/My/SampleBundle/Resources/views/Default/index.html.twig
   Symfonyの場合、テンプレートはTwigと言う物を使っています。
   書式的に難しい物では無いので、見れば大体は判ると思います。
   Twigは継承タイプのテンプレートなので、{% extends %}により他のテンプレートを継承している場合、まずそちらの内容が読み込まれます。

■実装しての感想

• JavaのStruts/SpringFrameworkの組み合わせを思い出した。
  書式自体はぜんぜん違うけど、この、設定ファイルありきの書き方は、本当にソレっぽいなと思います。
  設定ファイルの書式自体は簡単なので、Springほど設定ファイルがゴミゴミすることもありませんが…。
• 癖が強い。
  慣れの問題もあるかとは思うのですが、中々に癖が強いように感じられました。
  doctrineやTwig等、他のFW利用時にはあまり使わないものが多くあるからかもしれません。
• Pagerにあたる機能はコアに無い。
  らしいです。
  今回は、本当に簡単なページャだったので、直接一覧ページのコードに埋め込む形で実装してしまいました。
  実際にサイトを実装する場合は、使い回しが出来るよう、独自バンドルを作ったりするんじゃないかと思います。

今日はここまで。

次回はCodeIgniterで実装してみようと思います。

PHPのボトルネック調査方法[Web系一人AC2011]

昨日は、ツレと布団の取り合いに負けた結果、体調不良で死にました。OMG...。
いい年して何たる失態。すみませんでした。

気を取り直して今日の記事。
今日の記事はSymfony2...ではなく、PHPのボトルネック調査方法について、です。
検証用のコードが一部間に合わなかったため、予定を変更してお送りさせていただきます…。

皆さん、PHPで作ったWebシステムのボトルネックって、どうやって調査してますか？
割と「コレ！」と言う手段を聞かなかったので、ちょっと自分が調査するときのポイントをまとめてみました。
まずは、全体的にざっくりと、どんなツールを使って見ているのか？

それでは、本題に参りましょう。


■どのリソースが重たいのかチェック
ブラウザ上からどのリソースの取得に時間がかかっているのかを調査します。
ここで利用するのが、FireFoxならFireBug、Chromeならデベロッパーツールです。
（デベロッパーツール＝右クリックして「要素を検証」を選ぶと出てくるアレ）
得に、Networkタブを良く利用します。
実際に読み込んだすべてのリソースを、どの順番でどのくらい時間をかけて読み込んだのか？等が見れます。
ここで、実際に読み込みに時間がかかっているリソースを絞り込みます。

■関連するログを追跡
基本ですが…。
サーバ上で取っているログを一通り追います。
とくに、MySQL環境にてマズいSQLが問題になっている場合、slow.logはとても参考になります。
まれに、slow.logにたくさんクエリログが残っているのに放置しているプロジェクトなんてものもあります…。オソロシイ。
SQLに問題がある場合、大抵ログからもはっきりと追えるので、ここで原因がはっきりすれば、DBまわりのチューニングを行い、実際の効果を一度見てみても良いと思います。
時間帯によって重い時間帯がある、と言う場合、munin等リソースをグラフ化して見れるツールを入れておくと役に立ちます。

■試験環境で再現する場合は、本番を想定した負荷をかけながらやる
処理の内容や使っているライブラリによっては、一定以上の負荷があって始めて再現するようなボトルネックも多くあります。
あらかじめ、JMeter等のツールを利用して、本番を想定した負荷をかけながらチューニングしていきます。
※試験環境によっては、JMeterで負荷をかけすぎると同じ回線/サーバの利用者に迷惑がかかる可能性もあるので、気をつけてくださいね。
※くれぐれも、本番稼働中のサイトや他所のサイトに打ち込まないように。

■Xdebugのプロファイラを利用する
PHPスクリプトに対するプロファイラです。
これで、実際のどのメソッドのどのコードで時間がかかっているのか？を調べることができます。
ボトルネックがありそうなコードを見つけたときに、すぐに生のソースを見て重たそうなコードを目視で調べて直す、という行動を取ってしまう人も結構見てきましたが、
実際のボトルネックは目に見えない部分にあるケースもあるので、ちゃんとプロファイラでチェックしたほうが、経験上回り道になりません。
Xdebugが導入済みなのであれば、php.iniのxdebug.profiler_enableをOnにすると利用できます。
※プロファイリングするときは当然、普段以上に負荷がかかるので、本番サイトでONにしないように。
また、プロファイラの吐いたログは、単体では可読性にかけるので、GUIで表示してくれるツールを利用します。
私は、Linux環境だということと、コールグラフ等がグラフィカルに表示されるのがうれしいので、KCachegrindを使っています。



JavaやObjective-c(これはWeb系ではありませんが…)だと、割とボトルネック調査やプロファイラの使い方についての記事が多いのですが、いまいちPHPには無かったので挙げてみました。
自己流の部分が多く、当然これが最善とは言えませんが、参考になれば、と思います。

[CakePHP]Model名’Datum’、テーブル名'data'の罠[Web系一人AC2011]

土日は、YAuth的な理由（僕の場合はDですが。）により、blogを書けないことが判明しました。
と言うわけで、平日のみの更新とさせていただきます…。すいません。

さて。
今回は、前回話をした、CakePHPにてDatumというモデル名（テーブル名はdata）を使うとハマる、と言う件についてです。

■まえがき。
実はこの問題、「CakePHP Datum」というキーワードで検索すると、@uechocoさんのblogがクリティカルヒットします。
http://labs.uechoco.com/blog/2010/12/cakephp-model-lovers.html
こちらの記事です。
しかし、当時の自分は
「CakePHP data テーブル名」
なんて、ノイズが多そうな検索ばっかり試していて、自力で気づくまで延々と悩むと言う恐ろしい失態をしてしまいました。OMG....

せっかく自分でもソースを追ったので、記事にしておきます。

べ、別にネタが無いわけじゃないんだからねっ

■きっかけ

• 最初に作った、ただのPHP版のサンプルでは、テーブル名を「data」にしていた。
• CakePHPは、モデル名とテーブル名の命名に「モデル名は単数形、テーブル名は複数形の英単語」というルールがある。
  このルールを守ることにより、コーディング時に設定ファイルを書かなくても良い。
  モデル名/テーブル名とした場合の例）：Sample/samples, User/users, Woman/women
• 例を見て解るとおり、こちら単純に英単語に「s」をつければ良いわけではなく、ちゃんと英語のルールに沿っている。
  具体的には、以下のソースで判別しているので、詳細が気になるなら参考にするとおｋ
  https://github.com/cakephp/cakephp/blob/master/lib/Cake/Utility/Inflector.php
• 「じゃあ、テーブル名を'datas'に変えないといけないのかな？」と思ったが、「'data'って実は複数形だったらしいよ」と最近話題になっていたのを思い出し、調べる。
• 調べた結果、dataの単数形はdatumであることが判明。
  CakePHPでも問題なく利用できるルールのようだ。
  ちなみに、このサイトで、規約に沿ったワードを調べられます。
  http://www.cpa-lab.com/tech2/inflects/
• よーし、じゃあ、「Datum/data」の組み合わせでやろう！
• 一覧表示、データ登録、削除はうまく動いたぞ、さて後は更新…あれ？FatalErrorが出るよ？あれ？
  Fatal error: Call to a member function getColumnType() on a non-object in /var/www/php_samples/cakephp/lib/Cake/Model/Model.php on line 1258

■原因調査
エラーが発生したコードはこちら。
https://github.com/cakephp/cakephp/blob/master/lib/Cake/Model/Model.php

getColumnType呼び出し時の引数$columnに渡される値は、多くの場合
「モデル名.カラム名」
となっています。
例えばDatum/dataの場合なら
Datum.id
Datum.title
Datum.body
等となります。

しかし、こちら更新時には、更新対象列の絞込みのため
「テーブル名.カラム名」
という値で呼ばれる事があります。
（おそらく、更新以外にも複雑なことをやろうとした場合、同じ呼ばれ方をします。今回発生はしませんでしたが。）
具体的には、プライマリキーのカラムのみそのような呼ばれ方をするので、
data.id
となります。

さて、問題のコードを見てみましょう。
Datum.id や Datum.title にて呼ばれた場合、問題の1257行目のIF文はFalseとなり、
その先の$colsよりカラムの型を取得し、返します。
しかし data.id にて呼ばれた場合、Modelクラスは$dataというメンバ変数を保持しているため、問題のIF文がTRUEとなり、
$this->data->getColumnType($column);
という呼び出しを行おうとします。
しかし、実際にModelが持っている$dataは配列なので、メソッドを呼び出せずFatal Errorとなるわけです。

■解決策
モデル名をSample, テーブル名をsamplesに変更

■まとめ/教訓

• フレームワーク利用時に一般的過ぎる単語を使うときは、注意する。
  というか、実際にサイトを作るときに、dataなんて一般的過ぎる単語は誤用が発生する可能性が高いので、NG。
• 予約語リストがあれば、真っ先に参照するべき。
  CakePHPの場合、僕が探した限りでは見つかりませんでした。
  あったら是非教えてください。
• 予約語リスト等が見つからない場合、関係するクラスのメンバ変数名はチェックしておいたほうが良い、かも。
  頻度的には、問題が起きたら疑うレベルでも良いけど、一度見ておくとそのフレームワークの命名のルールやよく使われる単語が見えてくるので。
• Google先生に聞くときは、なるべくノイズが混じらない検索方法を行う。
• 迷ったら、机上で考える前に一通りソースを舐めろ。デバッガ使え。
  （実は「あれー？おかしいなぁ、あってるはずなのになー。」と、コードと公式ドキュメントを見比べる時間が30分以上あったり…orz）

今回は以上になります。

次回は、予告どおりSymfony2にてサンプルの実装を行ってみます。

CakePHP 2.0 を試してみて。 [Web系一人AC2011]

PHP各種FWとただのPHPの比較シリーズ
開催です。

■前書き
さて、比較と言うからには、条件が必要になります。
シンプルなPHPによるWebサイトってどんなのだろう？と考えた結果、以下のような仕様のサイトとしてみました。

• MySQLと接続し、テスト用のテーブルに対して以下の基本的な操作を行う。
• データの一覧（10行でページング有り)
• データの登録
• データの更新
• データの削除
• レイアウト等の機能外の部分については、基本的にこだわらない。
• バリデーション等も、基本的に無し。
• まずはなるべくシンプルに実装する。早くするための細かいテクニック等はナシ。
• セキュリティについても、最低限のみ考慮する。実際に運用するサイトではないので細かい部分まで調整はしない。
• フレームワークのバージョンについては、最新の安定板を利用する。1系、2系と分かれているものについては、基本的に2系のみ。

まずは、ただのPHPによって比較用の仕様を満たすサイトを作りました。
比較用なので、
「クラスや関数に処理を分けず、一直線に書く」
という縛りを追加して書きました。

そのソースが、こちらです。
https://github.com/FAL/php_samples/tree/master/normal
なんという、前時代のコード！！！
CGIなんて単語が日常的に使われていた時代を思い出しますね！

実は、昨日の記事はこのノーマル版の解説にしようかな？と考えていたのですが、
自分がこんなイケてないコードしか書けないって言っているような気がして悲しかったのでやめました。
動作中のサンプルは出しませんが、ソースコード的にも単純なので、見ていただければ大体の動作はわかるはずです。

■CakePHP2.0版
ようやく本題。
CakePHP2.0にて、同様の仕様のサイトを実装してみました。
それがこちらです。
https://github.com/FAL/php_samples/tree/master/cakephp
…と、やろうと思ったんですが！
リポジトリに反映漏れがあって、ちょっと足りないファイルが多いので、後々あげなおします。

内容ですが、基本的にblogチュートリアルの内容をベースに、
テーブル名を変えて、
画面構成をちょっと変えてページングを実装して、
defaultレイアウトを簡素にしたりしたくらいです。

■大体の流れ
サンプルコードを読む際に、大体こんな感じで追って行けば、7割程度はすぐにわかるよ、という、大体の流れです。
単純なCakePHPのアプリであれば、同様の流れで追えると思います。
コーディングする側が手を入れないような、コアの部分でのデータの流れについては割愛します。

1. /app/config/route.php
   mod_rewriteで飛んできたリクエストの、ルーティングのルールが書いてある。
2. /app/Controller/[コントローラ名]Controller.php
   コントローラ名は、route.phpを参考に。ただし頭は大文字になる。
   最近流行の形式のとおり、"/"はindex()。"/[アクション名]/"は[アクション名]()にマッピングされる。
3. /app/Model/[モデル名].php
   モデル名は、コントローラ名を単数形にしたもの。
   （コントローラクラス内にて$usesで定義してある場合は、そちらも。）
   今回のサンプルの場合、データ入力時のバリデーションルールがここにあります。
4. /app/View/Layouts/default.ctp
   全てのページの基本的なレイアウトが記述されている。
   $content_for_layoutに、後述のビューの内容が展開される。
5. /app/View/[コントローラ名]/[アクション名].ctp
   各アクションに対応したビュー。内容はPHP。

■実装しての感想

最終的な比較まとめは、一通りコードがそろった時点でやります。

まずは、今回CakePHP 2.0で実装していて感じた率直な内容です。

• CakePHP1.x系に比べて、命名規約が感覚的にわかりやすくなった。
  1.x系はかつて触った事があったのですが、ファイル名の命名規約が結構独特な部分が多く、慣れるまで面倒だった記憶があります。
  2系になってから、命名規約が普通っぽく（Javaっぽく？）なったので、あまり戸惑う事なく決めれるようになりました。
  逆に、1.x系の記憶があって「え！？こんな命名でいいの？」とびっくりしたくらい…。
• モデル周りが楽！
  規約に沿った名前付けさえしていれば、何も記述しなくてもデータ取得や更新が出来るのは楽です。
  今メインで使っているフレームワーク（職場伝統の俺俺…）は、単純なデータ取得でもいちいちモデルにメソッドを追加しなくてはいけないので、かなりうらやましいです。
• "data"の罠。
  テーブル名を"data"でやろうとすると、データ更新でFatal errorになります。
  詳細を追った内容を書こうとすると、それだけで1記事になっちゃいますので今は省略します。（後日のネタになりますｗ）
• ちょっとアクが取れた？
  Cake1.x系は、どこか「これがCakeのルールだ！」って感じのルールが多かったように感じたのですが、2系は結構素直に理解できる記述が増えたように思います。
  PHP5.2以降対応となった事で、自然な記述が出来るようになったのかもしれません。
  （単純に、私のコーディングスタイルに合っているだけ、のような気もしますが；）

今日はここまで、です。

まずはCakePHPのインプレッションという形で。

明日はSymfony2…の前に、dataの罠についてちょっとだけ書こうと思います。

Web系一人Advent Calendar 2011

12月になりました。

早速、宣言どおり一人ACが始まります。

今日は正直時間が無かった初日なので、基本的な内容の説明にしておきます。

技術系全般、というゆるーい縛りで行こうと思っていましたが、さすがにソレもどうかな？と思ったので、Web系、という縛りを入れてみました。

Web系といってもひろーくなっていますが、私個人のスキル的なものもありまして、PHPの話題が基本です。

PHP＞MySQL＝Linux＞その他言語いろいろ

という頻度を想定しています。

PHPといってもひろーい範囲になりますが、具体的には

「各種FWと生PHPの比較」

というテーマで進めていこうと思います。

各FWごとの特徴をまとめた記事や、HelloWorldくらいのサイトに対するベンチマークの比較という記事は結構あるのですが、

もうちょっと実用的な範囲での、実装コストやパフォーマンスの比較記事があってもいいんじゃないかな？

というのが発想の元です。

当然、いろいろなFWで同じ機能を実装していく事になるのですが、その中で気づいた話題があれば別途あげていきます。

また、ネタ切れという事態が発生してしまった場合は、PHP以外の言語での比較記事もあげるかもしれません。

----------

さて、ここからはちょっと与太話。

上記の準備のために、今日はただのPHPによる簡単なDB操作ページを作ってみました。

クラス構造を考えたり、データ操作を関数として切り分けたりすると、俺俺FWになってしまいそうなので、「手続き型」っぽい書き方になるよう、気をつけて書きました。

（具体的には、既存のクラスは利用するけど、自分でクラスや関数を作らない、という方針です。）

めんどっくさいですね！ほんと。

ソースは後日Githubあたりに公開しますが…。涙が出そうでした。

出来上がったソースも、「これはいったい何年前のCGIだろう？」という。中々に懐かしさを感じる構成に…。

書こうと思えば、かなりOOPなカッコイイ（？）書き方が出来る一方で、

個人的センスで言えばかなーり「イケてない」書き方でも、ちゃんと動いてしまうあたりが、PHPという言語のカオスさと自由さを表しているように感じました。

だからこそ、人に見られ、参考にされても恥ずかしくない、誇れるようなきれいなソースを書いていく必要がありますね。

面倒だからといって、うっかりイケてないコードを書いて、ソレを後輩が真似して、スパゲッティ、なんて事件の原因にはなりたくないですし。

余裕があれば、OOPの利点を語るための比較なんてのも、やってみよう。

Linux Mint 12 ON VirtualBox

最近流行ってるので、Linux Mint 12をVirtualBox上に入れていろいろ触ってみたので、メモ。
カスタム版Ubuntuと思って作業すると、結構何とかなるので、そんな感じで。

■インストール
　最初に「日本語」を選ぶ。後は特に詰まるところは無し。
　ただし、パッケージのDLが重たい。時間がかかるのでのんびり待つ。

■VirtualBox上の設定
　グラフィックメモリはしっかり割り当てておく。一応、3DアクセラレーションもONにしておく。
　多分この辺しっかりしてないと、デスクトップがMATEで立ち上がらないかも。
　VirtualBox用のGuest Additionのインストールは、Ubuntuと一緒でおｋ

■日本語入力ができない
　デフォルトでInput Methodは入っていないので、
　ibus, anthy, ibus-anthyを入れる。
　変換候補が変な位置に出てくる問題が発生。
　→ibus-gtk3を入れると直った。

■MATEの「メニューの編集」が反応しない。
　alacarteを入れたら出来るようになる

■各種ディレクトリ名を日本語→英語に
　Ubuntuと一緒だけど、一応。以下のコマンドをたたく
　LANG=C; xdg-user-dirs-gtk-update

後は、vimの設定とか諸々をUbuntuから引っ張ってきて、開発に必要なものをインストールして、終わり。

Google+にあげる用に、いくつかSSをとったので、あげてみる。

1.インストール中の画面

2.MATEメニュー

3.壁紙。見事に緑色。G+でもツッコミがあったけど、ミントが無いよね。

4.ターミナルの色。まぶしっ。

メモと俺俺Advent Calendar(仮)について。

実は転職が決定いたしまして。

年明けから、心機一転新しい会社にて働くこととなりました。

あ、転職といってもやっぱりエンジニアですよ？

で、転職のための諸々とか、今の業務がようやくエンジンかかって来たとか、なんやかんやありまして、blogがかなーりおざなりになっておりました。

書きかけで下書き状態の記事はたくさんあるんですが、どれも途中で止まってたりとか、そんなのばっかりです。

後、年明けからは更に忙しくなると思われるので、今のうちに勉強もたくさんしておきたい。

というわけで、今後の予定について、軽く自分用のまとめとしてメモです。

■いい加減しっかり勉強しなおしたい物。

• Hadoop
• Cassandra
• Node.js
• MongoDB
• CakePHP　その他PHPフレームワーク
• インフラ系色々
• Androidアプリ、OpenGL ES、Unity3D
• Python
• Sphinx
• vim
• Fluent
• アルゴリズム基礎やり直し

■完成させたいもの

• ちっこい画像処理Webサービス
• PythonでJPEGデコード
• コードネーム：ちゃがしー

絶対に、年明けまでに終わらない量じゃないですかー！俺のばかー！

ちゃんと会社に行ってないと、自分がダメ人間になる予感しかしなかったので、有給は使わずに28日までしっかりと働くことになってるんですよね。

まぁ、仮に12月1日から1ヶ月仕事が無かったとしても、間違いなく終わる量ではありませんが…。

しかし、リストアップした以上、潰していくことが可能になったと言う事なので、地道に潰していきたいと思います。

はい、そして！

「俺俺Advent Calendar(仮)」についてですが。

せっかくリストアップしたことだし、gihyoDPさんでなにやらこんな企画

http://gihyo.jp/dp/information/operation/201111/2801

があるようなので、

一人Advent Calendarでもやってみようかなと思います。

（あ、完全に個人のAdvent CalendarだとNGだったらどうしよう…。）

内容は技術系のものならなんでも、とりあえず1日1個記事を公開する、ということで。

途中で逃げ出さないための意思表示をしておきます。

さて、12月から本気だすぞー！

WubiでインストールしたUbuntu環境のディスク容量を増やす

自宅の開発環境に入れていたUbuntu11.04を、11.10にアップグレードしようとしたら
「容量足りて無いから出来ないでござる」(要約)
って怒られたので、対処法。

タイトルにも書いたとおり、開発環境はWubiで入れたUbuntu11.04。
開発でしか使わないだろうしってのと、SSDに換装したノートPCで容量にあまり余裕がなかったので、12GBだか13GBだか位の割り当てにしてました。
実際、自身の成果物程度であれば問題ない容量だったのですが、Androidの開発環境が思いのほか容量をとってまして、気づけば95%程度のディスク使用量に…。
本当は、余裕を見て32GBくらいにしたかったのですが、全体の容量にそこまで余裕がなかったので、16GBにディスク容量を増やすことにしました。

1.LVPMのインストール
　URL:http://lubi.sourceforge.net/lvpm.html
　上記公式配布先から、LVPMをDLする。
　併記されているバージョン情報が少し古いけど、問題ない。
　debパッケージなので、普通にインストール。

2.LVPMを起動、仮想ディスクのリサイズを行う。
　Dashに「lvpm」と入れるなりなんなりして、LVPMを起動。
　メニューで「resize」を選択。
　リサイズ後のディスク容量をMB単位で入力。
　今回は16GBなので、16384と入力し、実行。
　仮想ディスクのリサイズが開始される。
　リサイズといっても、実際には新しく16GB分のサイズの仮想ディスクを作成し、そこに現ディスクの内容をコピーしているだけのようなので、結構時間がかかります。
　ので、私は一度ここで放置して一度寝ました…。

3.仮想ディスクファイルをリネーム。
　再起動し、Windowsを起動します。
　Wubiのインストール先（判らなければ「Ubuntu」でファイル検索すれば出ます。たぶん。）の「disks」フォルダ内に、「new.disk」というファイルが出来ているハズ。
　「root.disk」というのが、リサイズ前のディスクなので、こいつをリネームするなりバックアップとって削除するなりしてから、新しく出来た「new.disk」を「root.disk」にリネームする。

4.Ubuntuを起動してみる。
　再び再起動し、Ubuntuを起動。
　正常に起動し、ディスク容量が増えていれば大成功。

この後、無事11.10にアップグレードできました。

Google+と連携しました。

プロフィールをGoogle+のものと連携させました。

ログインしてもバルーンが出てこなかったので、Bloggerログイン後、直接以下のURLにアクセスして対応。
http://draft.blogger.com/switch-profile.g

G+はかなりアクティブに利用しているので、個人的にはすごく便利です。
結構プライベートな話題も多いので、基本的に限定公開（サークルメンバーのみ）ですが…。
サクられたら取りあえずサクり返して、スパム等々の不要なユーザだったらアンサクする、という運用なので、気になる方は遠慮せずサクっちゃってください。

そのうち、気が向いたら自分のG+の使い方でもまとめてみようと思っています。
とりあえず、連携したよーという報告だけ…。

Access-Control-Allow-Origin

　ひっさびさにjQueryを使ってajaxであれこれやってたら、
　他サイトAPIはたたけても、自作したテスト用のサイトのJSONが取得できないという謎に躓いたので、メモ。

　ドメインが異なっている場合、表題のヘッダ（Access-Control-Allow-Origin）を設定していないと、データを読むことが出来ない。
　特定のサイトからのみ読み込みOKとする場合、サイトのアドレスを、全サイトからアクセスOKとする場合、*を指定する。
　とりあえずPHPだったので、以下の1文を追加して、解決。

header("Access-Control-Allow-Origin:https://**********.jp");

　さて、上記ヘッダが正しく設定されていない場合、JSON出力側のサイト（サーバ）はどうなるのかというと
　これ、ヘッダを見て、JSON取得側が表示を拒否っているだけなので、出力側の処理は正常終了扱いになっています。
　PHP等々が動いていて、サーバ上でデータの処理やメール送信を行っている場合、そこまでは正常に動くわけです。
　ブラウザからURLを直でたたいても、正常出力されちゃうわけです。

　ブラウザのエラー出力をしっかり読めばすぐわかる話なのですが（苦笑）結構解決に時間がかかったので、メモ代わりに載せときます。
　

Cassandra Conference in Tokyo 感想

　昨日行ってきた「Cassandra Conference in Tokyo」について、あまりきれいにまとまっていませんが、感想を上げておきます。
　公式サイト：http://ec-cube.ec-orange.jp/lp/cassandra-conference-in-tokyo/
　しっかり文章にまとめられればと思ったのですが、今週は少々忙しく…。文章の精査をやるくらいだったらさっさと内容だけあげちゃえ！という事になりました。
　読みづらい文章が多々出てくるかと思いますので、先に謝っておきます。ごめんなさい！

　最初は時系列順に、各プレゼンの感想。最後に全体の感想デス。
　後半、内容が薄くなっているのは、諸事情により集中力が切れてしまいあまり内容を把握できなかった所為です…orz。体調は万全に！これ大事。

！注意！
　各講演を聴いて、自分がどう感じたか？を主題に書いています。
　スピーカーの方々が実際に伝えたかったことや、プレゼンの主題とは離れた部分に着目している事も多々あります。
　実際の講演の内容そのものが知りたい方は、別途ほかの方々のまとめや、後日スライドがアップされることがあれば、そちらのスライドを参照して補完してください。
　この記事を書いている人(＝私)は、インフラ関係は見習いレベルの、Webサービスのサーバ側をメインに書いているプログラマ、です。

　Cassandra関係のイベント・勉強会に参加するのは、今回が初めてでした。

・基調講演： Cassandra 1.0 and the future of big data
　私が遅刻して最初少し聞けなかった。もったいないorz
　内容としては、Cassandraのこれからについての話、かな？
　近いうちに公開される、1.0の話題も。
　これからは「もっと判りやすく、使いやすいCassandraにしていきたい。」という主旨の発言があったのが印象的。後、ひたすら「リアルタイム」という単語を使ってました。
　それに対して、ほかのスピーカーの方が「そこまでリアルタイムじゃないよね」なんて突っ込みを、後々の講演でしたりすることも…ｗ

・ハイパフォーマンス・スケーラビリティーデータベース Apache Cassandra
　Cassandraの仕組みとか、具体的に運用したときのノード間の通信のイメージとかをわかりやすく紹介。
　特徴的な多次元KVSのデータ構造についても、簡単な例を交えて紹介。
　後、自社で行っているサポートと、コミュニティへの貢献のお話。
　基調講演の次にこのプレゼンが行われたことで、
「Cassandra気になって検討はしてるんだけど、まだ深いところ何も調べてないのよネ」　というレベルの自分でも、以後のプレゼンが判りやすくなりました。

・「Cloudian(クラウディアン）」におけるCassandra
　あー、その、ごめんなさい。
　英語力に自信が無いので、同時通訳を聞きながら見ていたのですが、通訳が…その、ちょっと微妙で。あまり頭に入ってきませんでしたorz
　通訳していただいている以上文句は言えないのですが！えぇ、ほんと、すいません。英語勉強シマス…。
　後日、違う方のまとめを見て、脳内の断片的な情報を補完する、予定。

・スマートフォン×Cassandraによるハイパフォーマンスサービス基盤の構築事例
　GeQuuはげくーじゃなくてじくー。スマホベースのユーザ向け各種ロギングシステムの事、らしい。
　自分が過去にどこ歩いてたかの履歴を地図上でアバターで動かしながら確認するデモがありました。
　コスモルートさんは名古屋の会社なのですが、名古屋ではCassandra等々の経験を持っている企業がほぼ皆無だと。関東方面に偏りすぎなんですかね、やはり。
　GeQuuのシステムとしては、検索関係がどうしても弱いので、最終的に検索用に自作のKVSをかませている、という話もありました。

・Cassandra上でトランザクションを操る”NanaHoshi”とその展開例
　てんとう虫のロゴかわいい！ﾊｧﾊｧﾊｧﾊｧ。
　NanaHoshiの開発にいたるきっかけとして、S-cubismさんが行っているEC CUBEというECサイトに特化したCMSのカスタマイズ版の経験。
　商品数がある一定ラインを超えてくると、MySQLやPostgreSQLでは耐え切れなくなるため、Oracleという選択肢になる。でもOracleはOSSじゃない。お金かかる。
　莫大なデータを扱うことのできるOSSのDBがほしい！→そうだ、Cassandraにトランザクションをつけよう！という流れ。すごく同意できた。
　NanaHoshiについての概要は、前にpyconJP 2011のLTで聞いた内容と似ていたので、二度目だったこともありすんなりと入ってきました。
　また、NanaHoshi自体のコードは、Pythonで書かれている事もありそんなに大きなものではない、との事。
　擬似コードでの、NanaHoshi利用例とかもあって、プログラマである自分にはわかりやすい話でした。

・Webアプリケーションから見たCassandra
　Webmailという、Webアプリケーションのメールシステムを開発・運用してきてのまとめ。
　実際にどれくらいの勢いで、負荷と容量が増えているのか。
　AWSで運用した場合、どれくらい予算が必要なのか。
　運用開始時の規模と、それから1年半運用した結果どれくらいの規模になったのか、等。
　実際の規模感や予算がまとめられているので、とても参考になりました。
　おまけで語られていた、全ノードが落ちたとき、バックアップから読むというのは、目から鱗でしたね。
　後、Cassandra用のORマッパーとかも出てきました。すごく魅力的！
　多言語向けのORマッパーとか出てくると、さらに利用実績が増えたり、するんじゃないかなぁ？

・KVSを活用したログ保管・解析基盤構築の実例
　ログの保管・解析のためのシステムを、HadoopとCassandraを組み合わせて構築した際の、実例と問題点についてでした。
　HadoopにはHBaseがあるのに、なぜCassandraなんだろう？とか。HadoopとCassandraの連携をもう少し詳しく見たかったなー、とか、自分の脳みそでは少々理解できない部分もありました。
　ただ、BigDataの解析の実例・構成が見たい！という人には良い内容だったと思います。

・Cassandra を使った大規模データ保存の事例紹介(Issues and Tips for Big Data on Cassandra)
　楽天さんなので、スライドの内容はすべて英語でした。しゃべる内容は日本語。
　内容的には、とあるシステムをこれまでMySQLでレプリケーション等々でがんばって運用してきたけど、さすがにもうムリだから、Cassandraに移行しようって話。
　Cassandra自体かれていないのと、楽天という大きなモール系ECサイトで扱うような膨大なデータを扱った事例が少ないこともあり、バグを見つけることも何度かあった、との事。
　楽天としてはCassandraのコミュニティに積極的に貢献していくとか。

■全体の感想
　Cassandraはまだまだ若く、伸びしろがたくさんあるのだな、と感じました。まぁ、まだ1.0にもなってないわけだし、当たり前といえば当たり前なんですが。
　でも、基本となる思想やアルゴリズム自体はほぼ完成していて、使いやすさを補助する機能が足りていない。そんな印象です。
　ジョナサンも、もっと使いやすくしていきたいと言ってましたし。
　また、NanaHoshiみたいな、Cassandraを補助するライブラリがもっと充実してくると嬉しいな！と思います。

　これからの進化に伴い、Cassandraがエンジニアにとって身近な存在となってくると、もっともっと小粒のプロダクトでも利用されるようになるのではないでしょうか。
「このシステム、ユーザが増えてくるとDB負荷が厳しい設計だけど…でも、そこまでユーザが増えることって滅多になさそうだし、このままでいっか。」
　なんて理由でRDBを使っているようなシステムが、
「このシステム、ユーザが増えるとDB負荷ヤバいよね。実際にそこまでのアクセスがあるかどうか分かんないけど、先の事を見越してCassandraで実装しとこうかな。」
　という流れにシフトするのも、そう遠くないと感じています。

JINS PC買って使ってみて。

各所で話題になっているJINS PC。http://www.jins-jp.com/functional/pc.html

夏ごろ、発売されるというニュースを見たときから気になっていたので、発売当日に買ってまいりました。

ちなみに、色はパープルです。紫が好きなので。

発売からまだ一週間もたっていませんが、効果を感じる所まで来たので、個人的なレビューを残します。

購入を悩んでいる方、参考にどうぞ。

■はじめに

私の視力や目に関する状況について、はじめに書いておきます。

この前提が無いと、参考にならないと思いますので。

視力は、両方とも1.0以上。最後に計ったときは両方とも1.5でしたが、その後酷使して少し下がったような気がしています。

そのため、生まれてこの方一度も眼鏡をかけたことがありません。JINS PCは度が入っていないとはいえ、人生初眼鏡です。

エンジニア＆PCオタクなので、起きている時間の8割以上、PCモニタと顔をつきあわせています。

ここ数年、目にダメージが溜まってきたのか、PC操作を始めて数時間たつと、目が軽くかすむようになりました。PC操作用の目薬が無いと、正直生きていけません。

このまま何も対策をせず、薬局の目薬でごまかしながらPC操作をしていると、近いうちに視力低下が始まるのではないか、という危機感は常に感じていました。

かといってPCから離れて生きることは、職業的にも趣味的にも不可能なので、どうしようかな～、と悩んでいるところに、JINS PCの存在を知り、購入を決意しました。

仮に効果が感じられなかったとしても、あの値段なら大して損じゃないな、と。

■最初につけてみての感想

この辺は箇条書きで。

• 軽い！とにかく軽い！持ってまずびっくりした。昔遊びでかけた友達の眼鏡はこんなに軽くなかった！！
• モニター上で、白背景に黒の文字を見ると、コントラストが強すぎて文字がぼやけて見えることが多かったが、それが即無くなった。
• 思ったよりも黄色くない。けど、眼鏡をつけたりはずしたりすると確かに黄色い。デザイン系の作業をしない限り気にならないレベル。
• 鼻が痛い。JINS PCは現状フレーム1種で、鼻当ての部分の調整・交換ができません。顔の形によってはこの辺がかなりのネックになると思います。

■暫くつけてみて気づいたこと

目薬が要らなくなりました。

即効結論を書いてしまいましたが……。

ああいう、ドライアイや眼精疲労用の目薬って、目が辛いな～って思ったときにさすじゃないですか。

特に、何時にさす、とか決めずに。

JINS PCをかけながら作業していると、「あー、そろそろ目薬ささないと、辛いな…」って思わないんですよ。

つまり、それだけ目が疲れていないということだと。

プラセボ的な部分も強いんだろうな、と、半信半疑で買ったんで、気づいたときには本当にびっくりしてしまいました。

ちなみに、何処だかで見た記事にあった、「ブルーライトを浴びていると眠気が飛んでしまうが、JINS PCをつけているとブルーライトがカットされるため、眠気が飛ばなくなり、夜普通に眠くなる。」ということは、私はあまり感じませんでした。

まぁ、ゲームやったり何なりしてれば、頭は覚醒してるだろ、って事ですね。

しかし、鼻当ての調整が効かないのが本当にツライ…。

元々眼鏡をかけたことが無く、慣れていないということも原因のひとつだとは思うのですが、本当に鼻が痛いです。

休憩中ははずさないと、痛さと違和感でやっていけません。

フレームの交換が利かない点については、さほど問題ないです。

PC操作中なんて、人に見られることはそこまで意識しないですし。耳部分については、自由にまげて調整ができるので。

■まとめ

JINS PC、イイです。効果はしっかりとあります！

鼻が痛いという欠点はありますが、普段はずしている分には問題がありませんし、一生ものの目を守ると考えれば安いもんです。

何より、値段が安い。お試しで1個買っても問題ないお値段ですので、是非！

人にプログラミングを教えるときのポイント

最近では、人にプログラミングを教えることはほとんど無くなってしまったのですが。
学生時代、情報学科に所属していた頃は、よくクラスメイトや後輩にプログラミングを教える機会がありました。
その頃の経験を元に、人にプログラミングを教えるときのポイントを、まとめてみたいと思います。
実際に人に教えるときの参考にしてみたり。
また、逆の立場になって、プログラミングを教わる(or理解する)ためのポイントのヒントとしてご覧ください。

1.何が解らないのか？は直接聞かない。
「解らない」と言って聞いてくる人に対して、「何が解らないの？」と聞いた場合に「それも良く解らない。とにかく解らない」と返されるケースって良くあると思います。
また、実際に「ここが解らないんだけど」という相手に、その内容を説明してもいまいちピンと来ず、深く聞いてみたらもっと根元の部分の勘違いが原因だったりすることもあります。
「解らない」を具体的にするために、何が解らないのかを直接聞くのではなく、その人が理解しているところを順番に説明してもらう所からはじめてみましょう。
例えば、「C言語の配列が良く解んない」という相手の場合
・配列自体は理解できているけど、for等のループ構文の理解が甘く、配列を利用したコードの多くが理解出来ない。
・配列の添え字が0から始まるという事に慣れておらず、不正な添え字(10個の配列に対して10、とか)を書いてしまい、エラーになってしまう。また、エラー文の読み方も良く判っておらず、エラー文から原因のコードにたどり着けない。
・そもそも変数への代入から理解できていない。
等々、その人それぞれの理解度の違いがあるわけです。
同じ質問でも、各人が求める解答は違っています。
面倒でも、まずは「何処まで理解出来ているのか？」をよく聞きましょう。

2.例え話を過度に行わない。
プログラム言語の初期の頃には、よく、変数を名前のついた箱として教える事があります。
この理解をずーるずると引きずっていると、ポインタやオブジェクト指向のあたりで躓く可能性が高くなります。箱の実際の場所が、なんて言われても良く解らないですよね？
例というものはとても有効です。特に、プログラミングのように現実に形の無いものを表すためには、使わざるを得ない物です。
しかし、使いすぎると、例と実態のマッピングがうまく出来ず、理解出来ないという結果に繋がってしまいます。
「aって箱がこうなって、それで～、箱が～箱が～…がー！！！」なんて言って混乱しているような相手に対しては、一度、解り易くメモリ空間上での変数の扱いを説明してみると、氷が解けるように理解してくれる事があります。
変数以外にも、例で教わり例に固執している所為で、実際の実装が見えずよく理解出来ない事はよくあります。
相手の理解を踏まえつつ、タイミングを見計らって、実際の実装を説明してあげましょう。
もちろん、タイミングを見誤ると、相手の脳内はさらに混乱するので、よく注意してくださいね。

3.「何故」も説明する。
よく解んないけど出来る事を覚えるより、「これを覚えるとこういう事が出来る！」って物を覚えるほうが、理解が早いものです。
オブジェクト指向の説明で、犬クラスがどーのこーのだの、車クラスがどーのこーのだの聞いても、「実際に何が便利になるんだよ。読みづらくなるだけじゃねーか！」なんて不満を覚える人もたくさん居ます。
そういう人のために、「何故この技術が必要か？」「何故この技術が生まれてきたのか？」という何故もしっかり説明してあげましょう。
例えば、Javaのコレクションクラス周りは、利用頻度も高く、クラス設計の説明としても有意義だと思います。
実際にコレクションクラスを使ったコーディングをしながら、継承の利点、インタフェースの重要さを教えてあげると、実際に使える技術として納得してもらえます。
そのままIteratorパターン、更にはその他デザインパターンまで教えることが出来れば最高です！が、大抵の場合、時間と互いの体力がそれを許しませんね……。

4.優良なコードは最高の教科書。
どんな教科書やどんな授業も、優良なコードには適いません。
人に教えるときは、是非、コードベースで教えてあげてください。
コードを読むことを嫌う人は、良いプログラマにはなれませんし、良いコードを知る事は、読みやすさの重要さに気づ、良いコードを書くための第一歩にもなります。
いろいろなコードを例に挙げ、コードを読むコツを教えてあげましょう。
その時に、どれだけ「素晴らしいコード」を提示することが出来るか、というのが、解答者の力の見せ所にもなります。
自分で素晴らしいコードを書くことはもちろん、良いOSSプロダクトやサンプルコードの出所を沢山知っておくことが重要です。

5.答えには良いソースを添えて。
ソースというのは、ソースコードではなく、情報源の事です。
質問に対して答えるだけではなく、自分がその答えとなる知識をどこから学んだのか、プラスして教えるようにします。
例えば
「PHPでカンマ区切りの文字列を配列に分割するのって、どうやって書くんだっけ？」
と聞かれたときに、ただ「explode」と答えるのではなく
「explodeって関数で出来るよ。公式の関数リファレンスみてみ？探し方は……」
と教えるとか。
「MySQL使ってるんだけど、このSQL、もうちょっと早く出来ないかな？毎回処理が重くって……」
と聞かれたときには
「インデックスが綺麗に使えてないんじゃない？MySQLのインデックスはこれこれこうなってて……。……だから、こんな感じで書けると思う。MySQLのチューニングだったら、この書籍がオススメだね」
等、書籍を薦めるとか。
最近であれば、Google Groups等に数多く存在している、優良なコミュニティを教えてあげても良いと思います。
こうする事により、言葉では伝え切れなかった内容を、質問者が自分自身で補完することが出来るようになります。

最後に。
上記にあげた5つのポイントは、すべて、一つの目標のためのポイントになっています。
その目標は
「質問者が、自分自身で解決出来るよう、問題解決能力を身につける事。」

何が解らないのかを自分で理解できるようになれば、答えを調査する事がより容易になります。
例え話と実体へのマッピングが重要だと気づけば、実際の実装への関心がより深まり、誤解も少なくなっていくでしょう。
すべての実装に「何故そうなったのか？」があるという事に気づけば、コード・設計の意図を読む事が重要だと、気づくはずです。
コードリーディングの力がつけば、独学で沢山のコードの知恵を身につける事だって出来ます。
良い情報源に多く触れ、情報源を自分で調べる事ができるようになれば、良い情報、悪い情報の判断だって自分でつけれるようになります。

プログラミングに限らず、エンジニアの知識なんて、すぐに新しいものが必要になります。
自分の周囲の人が誰一人理解していないような事を、自分だけで調査して身につけなくてはいけない。そんな時がいつか必ずやってきます。
そうなったとき、ちゃんと自分の力で解決できなければ、長くプログラマ・エンジニアである事は出来ません。
そのための、独学で学んでいく力こそが、真にプログラマが身に着けるべき力だと思っています。

……何でもかんでも、自分に質問に来られると鬱陶しい。なんていう自分本位な考えも、もちろんありますが(苦笑)

学校ならともかく、業務中に質問を受けたときは、時間リソースの関係で中々しっかりと教えてあげる事は難しいかもしれません。
でも、時間が許すのであれば、相手のため、そしていずれ相手と一緒にコーディングをする事になるかも知れない自分のため、じっくりと教えてあげてみてください。
情けは人のためならず。いつかきっと、良い結果を導いてくれますよ。

zencoding.vim入れてみた

めもめも。

■インストール
http://mattn.github.com/zencoding-vim/
上記参照。
git使ってないよー。オフライン環境だから使えないよーって人は
http://www.vim.org/scripts/script.php?script_id=2981
ここから。

■使い方
基本的には、zen codingの記法に則った省略形を描いて、"<c-y>,"
詳細はやっぱり、上記ドキュメント参照

■設定
<html lang="en">を<html lang="jp">にする、等
Zen Codingの設定類は
~/.vim/autoload/zencoding.vim
の中に書いてあるので、適当に検索して置き換える。

TDDBC 1.7 行ってきた

と、いうわけで。
先日行われたTDDBC 1.7に参加して参りました。
え、もう先日じゃないって？ぅぅ、すいません……。

内容そのもののお話は、ほかの参加者の方々のblogで語りつくされていると思いますので
私は、自分視点の感想等々を書くことにします。
時系列別に、どういう内容だったか知りたい方は、主催の@shishi4twさんの記事をご覧ください。

■前提
参加時点での私のTDDに関する技術レベル（？）は
興味があってPHPUnit（あるいはJUnit）のサンプルソースを動かしたことはあるけど、業務等の実際の開発で使ったことは無い程度、です。
一応、「車窓からのTDD」をPHPで書き直すという予習は、事前にやってました。
ついでに言うと、勉強会自体、片手で数えられるほどしか参加しておらず、これほど少人数の勉強会は初だったのでガッチガチに緊張してました…。

■TDDそのものについて。
最初に基調講演を聴いて感じたのは、TDDにおけるテストコードは、自然言語の仕様と実際のコードの間をつなぐ中間言語なんだな、ということ。
元々、日本語の仕様があって、それを元にプログラマが頭の中で考えてコードに起こしていくのが、旧来のTDDではない開発手法。
で、その仕様書をいかにプログラマにわかりやすくするか？っていうので、たとえばUMLとかが出てきたように思うんですよ。
（UMLにはそれ以外にも色々な意味合いがあるので、一概にUMLの用途を決める発言じゃないです。念のため）
実際、授業でプログラミングを習った際には、一度アルゴリズムを文字で書くための簡易言語っぽいものが利用されてました。

・iに1を足す
■iが10になるまで繰り返す
  ・iを出力する

こんな感じの。
ただ、自然言語や図などの人間が解釈するための仕様だと、プログラムコードに直す際のギャップが激しい。
なんせ、すっごい曖昧じゃないですか。日本語が曖昧って問題もありますが、そもそも自然言語って時点で、白黒はっきりしないことが多い。
一番大切な土台となる仕様が曖昧な状態で開発をしてたわけですね。今までは。泥の上にいきなり家を建てるような感じ。
そこで、いきなり家を建てるのではなくて、基礎やったりコンクリで固めたりして、土台をしっかりさせる作業が、TDDにおけるテストケースを書くって事。
土台がしっかりしてるから、プログラマも安心して作業できるし、完成するものもちょっとやそっとじゃ倒れない。最高です。
さらに言えば、テストケースを書くためには、問題の粒度を細かくする必要がどうしても出てくる。すると、小さな単位から問題を片付けることが出来るようになって、開発の速度と制度もUPする。
良い事尽くめですね。

ただひとつ、問題としては、どうしてもその利点を他者に伝えるのが難しいということ。
特に、よく知らずに「テスト」という単語だけで否定している人も多いんですよねー…。
こればっかりは、自分がしっかりTDDできるようになって、実際の成果を見てもらうほか無いのかな、って感じたり。

■ペアプロについて。
ペアプロという単語をはじめて聞いたのが、よりによってこのページだったんですよねー！
http://www.eclipsewiki.net/eclipse/index.php?%A5%BD%A5%ED%A5%D7%A5%ED%A5%B0%A5%E9%A5%DF%A5%F3%A5%B0%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3
（Javaメインで使ってたころ、Eclipseのプラグインあさってたら見っけた）
Wikiからのリンクは死んでますが、配布元のページの製品とサービスあたりからたどると見れます。バーディ君…。

と、言う訳で、そこまで凄い物って印象はありませんでした。むしろ、割とキワモノなイメージが無意識のうちに…（苦笑）

実際やってみての感想ですが…。
開発中に出てくる小さな悩みの解決は、本当に早いです。
「正規表現のあの記法ってどんなんだったっけ？」「str_lenだっけstrlenだっけ？」等の文法的な話とか
「ここって別メソッドにしたほうがいいかな？そうでもない？」「この変数名何にしよっか？」等リファクタリング的なところまで。
特に、開発初期はこういうしょうもない部分で時間をとられたりするものですが、そういった事が無くサクサク進むのは凄くよかったです。

開発が熟すまでは定期的にペアプロを行うとイイカンジかな、と思いました。

ただ、私自身がすっごいガッチガチだったため、あんまり突っ込んだ話が出来なかったのが非常に申し訳無いです…。

■コードレビュー
1回目が私のペアでした。ただでさえ緊張してたのに…！
コードレビューをして思い出したのは、学生時代の部活動でした 。コンピュータ部だったんですよ。
ただのゲーム部というわけではなく、ちゃんとしたコンテストに参加することを目的とした部だったので
入部試験として、fizzbuzzでは無いものの、難易度的にはそれに近いコーディングのお題が出されるんです。
で、実装したコードを先輩の方々に見てもらって評価してもらう、と。
当時はコードレビューなんて単語も知りませんでしたが、やってることはまさにコードレビューですね。
（このお題の話については、そのうち書いてみようと思ってます。身元バレが怖いケド）

業務でも、たまにコードレビューが行われることがありますが、業務上のレビューは、上司に採点してもらうって形がほとんどなので、「ひとつのコードを叩き台にみんなで論議する」というタイプのコードレビューは本当に懐かしかったです。
また、何か機会があればやってみたいですね。

■ツール
「道具を大切に」「ひとつのツールをカスタマイズして使い込む」
という話が何度もありました。
が。
私自身、それとは対極に居る人間だったので、今回一番びっくりした事です。

学生時代、誰かにヘルプを頼まれそのまま人の環境で作業することが多かった身としては、自分用のカスタマイズされた環境じゃないと作業が出来ない、っていうのは避けたかったんです。
その経験を今になってもずるずる引きずっているため、開発環境はなるべくデフォルトで、ってやってました。

それも悪くは無いとは思うのですが、色々な人の環境(今回はVimが多かったです)に触れるにあたって、自分用の環境を1個持っておくのも悪くないと思いました。
TDDBC直後、職場の開発環境が吹っ飛んだので、これを期にってことでVim入れたりもしてます。
設定ファイルいじったり、小さいスクリプトを書くのには凄く便利です。
ただ、FW等の大きいソースコードを追う時は、どうしてもEclipseやNetBeansのほうが便利なので、そこは使い分けでやってます。

■お題について
最初のお題は、割と素直に解けるお題だったと思います。
TDDとしては、正規表現の確認のために、いちいちテスト用のコードを作って実行して確かめて、なんて手間がかからないのが楽でしたね。
テストケースを書くことによって、お題の中で言及されていない仕様(=の数が左右違う時、とか)に気づくことが多かったのも良い事でした。

2つ目のお題については、お題自体が複雑なのと、書きたいことも多くもう少し時間がほしいので、別にまとめ…る、予定です。

■その他いろいろ
箇条書きで。

• 緊張しまくりでホントすいませんでした。小規模の勉強会への参加が初だったんですよー！っていう言い訳。
• リストバンドほしかったけど、Mサイズがでかすぎて腕にはまらなかった…orz
• PHP関係のいろんな人と知り合えた！良かった。でもSymfonyノータッチノーチェックですいませ…ん…。最近、Symfony2のチュートリアル触り始めました！
• TDDを実務に組み込めるか？は悩ましい所。コーディング担当が自分のみってプロジェクトでは、やれそうだけど、そもそもオブジェクト指向ﾒﾝﾄﾞｸｾって人が居る環境なので、環境全体に浸透させるには壁が分厚いデス。
• 懇親会は予定があったので行けませんでした。楽しかったようなのですごくうらやましいです。次の機会があれば参加したいですね。
• Objective-cのOpenGL ESプログラミングを、一時期やっていたんだけど、さすがにああいう所だとTDDは難しそうだな、とか。
• TDDは、グラフを描くために式を考えるんじゃなくて、先に重要なポイントの点をたくさん取っておいて、近似値のグラフを描いて、そっから式を逆算するようなイメージ。
• キイロイトリの巨大なぬいぐるみ、家にあります（？）

とりとめも無くなってきたので、以上ということで！

Bitbucket利用してみる

ドキュメントがしっかりしてるので、詳しくはこちらを。

http://confluence.atlassian.jp/pages/viewpage.action?pageId=25133116

Bitbucketって何？

→gitでいうgithubの、Mercurial版。

Mercurialって何？

→最近（ってもだいぶ前からだけど）流行の分散型ソース管理システム。

■Mercurialのインストール

python-devが入ってなかったので、追加で入れた。

$ sudo apt-get install python-setuptools
$ sudo apt-get install python-dev
$ sudo easy_install Mercurial

正しく入ったかテスト

$ hg --version
Mercurial Distributed SCM (version 1.9.1)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2011 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ユーザ情報を設定

$ vi .hgrc
$ cat .hgrc
[ui]
username=名前<メルアド>
[web]
cacerts = /etc/ssl/certs/ca-certificates.crt

[web]の項目が無いと、HTTPS経由で作業しようとしたときに警告がたくさん出る。

Ubuntu以外の環境の場合、以下を参考に。

http://mercurial.selenic.com/wiki/JapaneseCACertificates

■Bitbucketに登録

https://bitbucket.org/

bitbucketのサイトにアクセス。"Sign up free>>"という黄色いボタンをクリック。アカウントを作成する。

OpenIDにも対応しているので、Google等のアカウントを使うと楽。

登録時に求められるNameとPasswordが、Mercurialからアクセスするときに必要になる。

また、登録時に入力したメールアドレスに、確認メールが飛んでいるので、URLをクリックしてメールアドレスの確認を完了しておく。

■リポジトリ作成

bitbucketのRepositoriesからcreate repositoryを選択。

必要項目を埋める。Webとかはサイトが無ければ空欄でおｋ。

Nameの横の"Private"にチェックが入っている場合、プライベートなリポジトリとなる。

デフォルトでチェックが入っている。公開しない場合はそのままチェックONでいいと思う。

■一通り試す

以下適当な作業フォルダで。

$ hg clone https://bitbucket.org/ユーザ名/リポジトリ名
$ cd リポジトリ名
$ vi test.txt
$ cat test.txt
test
てすと
$ hg add test.txt
$ hg commit -m "にほんごテスト"
$ hg push

bitbucketのサイト上のリポジトリを確認しに行く。

VirtualBox上のUbuntu11.04にPHP開発環境

tddbc1.7参加にむけて、サブPCのEeePC 1215Nに、PHP開発環境を立てることになったので、作業メモ。

※仮想環境で作業してみた結果、サブPCのスペックでは快適に作業できなかったため、実際にはUbuntu11.04をデュアルブートで利用しています。

NetBeansのインストール以降の作業は、仮想・物理マシン関係なく行えるので、そのまま残しておきます。

■仕様

• VirtualBox上のUbuntu11.04をメインにする。
• Apache、PHPはゲストOS内で動かす。
• ホストOSのブラウザからも、開発中のサイトの確認ができるようにする。
• PHPUnitも動くように。
• IDEはNetBeans7.0を選択。一応、Eclipseも動くようにはしておく。

■前準備

• Ubuntu Japanese Teamのサイトから、日本語版のUbuntu Desktop 11.04のisoをDLしておく。
• VirtualBoxは最新版をDL、インストールしておく。

■VirtualBoxにUbuntu11.04をインストールする。

1. VirtualBoxで新規ボタンを押して、ウィザードにしたがって新規仮想マシンを作成。
2. まずは設定で、
   システム→メインメモリ：1024MB,
   ディスプレイ→ビデオメモリ：128MB, 拡張機能：3D...にチェック,
   ネットワーク→アダプタ2を有効化、割り当てをホストオンリーアダプタに。
3. 仮想マシンを起動。初回起動ウィザードにて、Ubuntu11.04のisoイメージを選択する。
4. Ubuntuのインストールウィザードに従って、インストール。
5. 再起動後、ログイン。クラシックモードでの起動になることを確認。
6. アップデート・マネージャが起動すると思われるので、そのままアップデートを実行。
7. Guest Additionsのインストール。
   VirtualBoxのメニューのデバイスから、Guest Additionsのインストールを選択。
   Ubuntu上でターミナルを起動し、GuestAdditionsインストールスクリプトを実行。
   完了後、再起動。
8. テーマ崩れの調整。
   こちら[http://akira.matrix.jp/?p=393]を参考に、/etc/gdm/Xsessionを修正し、再起動。
9. ccsmを入れて見た目を好みに調整。この辺はお好みで。

■NetBeans7.0.1のインストール

1. NetBeansの公式サイト[http://netbeans.org/]から、インストーラをDLする。
   ダウンロードバンドルは、とりあえず「すべて」にしておく。
2. ダウンロードしたインストールシェルスクリプトを、ターミナルから叩く。sudoつけて。
3. ウィザードに従ってインストール。
   基本的には「Next」でOKだが、JUnitのインストールは行うこと。
4. 文字を滑らかにする。
   /usr/local/netbeans-7.0.1/etc以下にあるnetbeans.confを開き、netbeans_default_optionsの最後に以下を追記。

   -J-Dawt.useSystemAAFontSettings=lcd

5. NetBeansを起動。
   ヘルプ→更新の確認。更新があれば行っておく。今回は無かった。

■Apache+PHPのインストール。

1. ホストOS→ゲストOSにpingが通ることを確認しておく。
   Ubuntu側でifconfigを実行し、eth1のIPアドレスを確認。
   そのIPアドレスにホストOSからpingを打つ。
2. apacheのインストール。

   sudo apt-get install apache2

3. apacheの起動確認。http://ゲストOSのIPアドレス/にアクセス。It works!と表示されればOK。
4. PHPのインストール。

   sudo apt-get install php5

5. 念のため、apacheを再起動。sudo /etc/init.d/apache2 restart
6. ドキュメントルートの/var/wwwのパーミッションを変更。一般ユーザからかけるようにしておく。
7. /var/wwwにphpinfo()を実行するだけのPHPスクリプトを配置し、ブラウザからアクセスする。

■PHPUnitのインストール

PHPUnitのマニュアル[http://www.phpunit.de/manual/current/en/installation.html]を参考にインストールを行う。

1. pearをインストール

   sudo apt-get install php-pear

2. pearのバージョンをあげておく。

   sudo pear upgrade PEAR

3. pear channel-discoverにて、上記マニュアルに記載されている3つのチャンネルを登録する。
4. PHPUnitをインストールしようとすると、いくつか足りないパッケージがあり失敗するので、都度インストールを行う。
   最終的には、以下のようになる。

   sudo sudo pear install channel://pear.php.net/Net_URL2-0.3.1
   
   sudo pear install channel://pear.php.net/HTTP_Request2-2.0.0RC1
   
   sudo pear install phpunit/PHPUnit
   
   

5. phpunit --versionと叩いて、バージョンが表示されることを確認しておく。

■NetbeansとPHPUnitの連携を確認

1. NetBeansを起動。PHPプロジェクトを作成。
2. 適当なクラスを新規作成。
   空で良いのでメソッドを1個追加しておく。
3. 「ツール→PHPUnitテストを作成」を実行。
4. テストフォルダを選べと言われるので、参照ボタンを押してフォルダを選ぶ。
   プロジェクトフォルダと同一だと怒られるので、新規に"test"というディレクトリを作って、選択しておく。
5. プロジェクトをテスト（Alt＋F6）で、テストを実行。１００％通ることを確認。

テスト

てすと。