作成者別アーカイブ: somof

wordpress PHP 正しいプラグインを作る作法;コードスタイル編

乱立していたスタイルを整理してくれたという方々に敬意を表して、
コードスタイルなどは、基本的には PSR に従うことにする。

だけども。
WordPress に必要な固有のルールもあるので、まとめておく。

# まず、PSRからの抜粋。

## 名前空間とクラス名の記構造

\<ベンダー名>\(<名前空間>\)*<クラス名>

区切り文字にバックスラッシュを使って良いらしい。
アンスコ”_”に、意味はないとか。

#+BEGIN_SRC php
// PHP 5.3 以降:
namespace Somof\WPPlugin;

class Org2Html
{
const VERSION = ‘0.1’;
const DATE_APPROVED = ‘2015-08-22’;
}
#+END_SRC

## ソースファイルの分割
クラス、関数、定数などを宣言するためのファイルと、
副作用のある処理を行うためのファイルは、分けるべき。

出力の生成部分はもちろん、
初期化ファイル(ini設定)の変更も副作用と考える。

## 命名規則
– クラス名は、StudlyCaps(単語の先頭文字を大文字で表記する記法)記法
– クラス定数は全て大文字とし、区切り文字にはアンスコを用いる
– メソッド名はcamelCase記法

## アクセス修飾子
– アクセス修飾子を、全てのプロパティ、メソッドに定義する
– abstractとfinalはアクセス修飾子の前に定義する
– staticはアクセス修飾子の後に定義する
– public : クラス内、クラス外のどこからでもアクセス可能
– private : 同じクラス内からのみアクセス可能
– protected : 同じクラス、及び子クラスからアクセス可能
– final : 拡張による変更禁止 (クラスとメソッドのみ)

# WordPress に必要なルール

以下、 [[http://wpdocs.osdn.jp/WordPress_%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E5%9F%BA%E6%BA%96][WordPress コーディング基準]] からの抜粋。

## シングルクォートとダブルクォート
シングルクォートとダブルクォートを適切に使い分ける。

– 文字列で何も評価しない場合は、シングルクォートを使う。
– セキュリティ上、HTML出力ではダブルクォートを使うべき
– 文字列で HTML クォートをエスケープする必要はほとんどない
– 例外は JavaScript
– ダブルまたはシングルクォートのどちらかを強制されるときがある

## WordPress の Data Validation について

## インデントとブレース、スペースの使い方
スペースではなく、本物のタブを使う。
むむむ。 これは守らないかも。

## include_once 対 require_once
include_once と require_once を適切に使い分ける。

「これら2つの構文は、 エラーの扱い方を除けば全く同様に振舞います。
 エラーが発生するとどちらも Warning を出力しますが、
 require() を使用している場合は Fatal Error となります」

## 正規表現
Perl 互換の正規表現 (PCRE, preg_ 関数) を使うこと。
POSIX 互換関数よりも好ましい。

## PHP ショートタグは禁止
PHP のショートタグ (<? … ?> や <?=$var?>)は使わない。
常に、完全な PHP タグ (<?php … ?>) を使う。

## 変数、関数、ファイル名と演算子
変数名、関数名はアルファベット小文字を使い、
単語の区切りはアンダースコア (_) を使う。
キャメルケースのような形式) は不可です。

ファイル名は動作を説明できるアルファベット小文字の名前とし、
単語の区切りにはハイフン (-) を使う。

1回しか使わない変数を作ってはいけない。

比較演算の時には、定数を左に、変数を右側に置く。

関数の引数のフラグは、意味の分かる値にしてください。
true/falseではなく、呼び出す側が読める文字列で渡す。

# さて、どんなルールにするか。

違和感のあるのは以下のルール。

– インデントにスペース禁止
– ファイル名のハイフン
– 命名規則で camelCase禁止
– 一度しか使用しない一時変数の使用禁止

手元にある、人の書いたプラグインを見ると、
camelCase禁止以外は、あまり守られていないみたいだ。

WordPressで公開する訳でなし、PHPの勉強の意味で長い目で見れば、
PSRに従っておいた方が良さそう。

PHP 開発ツールでテスト: 簡単CI testrunner

# testrunnerを用意する

とりあえず、最小限のものだけ composer でインストール。

#+BEGIN_SRC
{
“require-dev”: {
“phpunit/phpunit”: “4.*”,
“piece/stagehand-testrunner”: “4.1.0”
}
}
#+END_SRC

プロジェクト個別にインストールしたくなかったので、
global に testrunner をインストールできないものか試行錯誤したけど、
結局断念して、プロジェクトのフォルダに composer.json を作った。

なので、ここでは testrunner に最小限必要な phpunit だけを指定している。

#+BEGIN_SRC
$
$ composer.phar update
$
#+END_SRC

# testrunnerの実行

インストールしたら、あとは testrunner の実行。

#+BEGIN_SRC
$
$ ./vendor/bin/testrunner compile -p ./vendor/autoload.php
$ ./vendor/bin/testrunner phpunit -p ./vendor/autoload.php -a tests
$
#+END_SRC

これで、ファイルを更新する毎に、勝手にテストを実行してくれる。
これは便利。

ソース側の更新も監視したければ、こんな感じ。

#+BEGIN_SRC
$
$ ./vendor/bin/testrunner phpunit -p ./vendor/autoload.php -a tests -w src
$
#+END_SRC

他には、こんなオプションがある。

#+BEGIN_SRC
$ ./vendor/bin/testrunner phpunit –help
Usage:
phpunit [options] [–] []…

Arguments:
test_directory_or_file The directory or file that contains tests to be run (default: The working directory at testrunner startup)

Options:
-p, –preload-script=PRELOAD-SCRIPT The PHP script to be loaded before running a command
-c, –config=CONFIG The YAML-based configuration file for Stagehand_TestRunner
-R, –recursive Recursively runs tests in the specified directories.
-a, –autotest Monitors for changes in the specified directories and run tests when changes are detected.
-w, –watch-dir=WATCH-DIR The directory to be monitored for changes (default: The directories specified by the arguments) (multiple values allowed)
-m, –notify Notifies test results by using the growlnotify command in Mac OS X and Windows or the notify-send command in Linux.
-d, –detailed-progress Prints detailed progress report.
-s, –stop-on-failure Stops the test run when the first failure or error is raised.
–log-junit=LOG-JUNIT Logs test results into the specified file in the JUnit XML format.
–log-junit-realtime Logs test results in real-time into the specified file in the JUnit XML format.
–test-file-pattern=TEST-FILE-PATTERN The regular expression pattern for test files (default: Test(?:Case)?\.php$)
–test-method=TEST-METHOD The test method to be run (multiple values allowed)
–test-class=TEST-CLASS The test class to be run (multiple values allowed)
–phpunit-config=PHPUNIT-CONFIG The PHPUnit XML configuration file
-h, –help Prints help and exit.
-V, –version Prints version information and exit.
–ansi Enables ANSI output.
–no-ansi Disables ANSI output.

Help:
The phpunit command runs tests with PHPUnit:

testrunner phpunit …
#+END_SRC

開発初期なんかは、Jenkinsにやらせるより数段小回りが効いて良いかも。

WordPressのプラグイン開発。PHPのツールとJenkinsプラグインの用意

PHP関係のパケージの管理は、 composer を使う。

# まずは、composer のダウンロード。

$
$ curl -sS https://getcomposer.org/installer | php
$

composer には、他に以下のようなコマンドもある。

$ composer.phar install # 先に composer.json にパッケジを書いておく
$ composer.phar update
$ composer.phar remove # composer.json を編集して update の方が分り易い

# PUPUnitのインストールのお試し
PHPは趣味にしか使わないから、インストール先は global にしておく。

$
$ composer.phar global require “phpunit/phpunit=4.0.*”
$

これで ~/.composer に phpunit がインストールされる。
(この後直ぐにアンインストールしたけど)

この段階で “phpunit/phpunit=4.8.*” だと、依存関係を解決できなくて
実際にはインストールできない。

# PHP ビルドツール Phing をインストールする

~/.composer/composer.json を編集して、
phing だけ追加して composer.phar update してみると、
いろいろお勧めされる。

phing/phing suggests installing phpdocumentor/phpdocumentor (Documentation Generator for PHP)
phing/phing suggests installing sebastian/phpcpd (Copy/Paste Detector (CPD) for PHP code)
phing/phing suggests installing phpmd/phpmd (PHP version of PMD tool)
phing/phing suggests installing pdepend/pdepend (PHP version of JDepend)
phing/phing suggests installing phploc/phploc (A tool for quickly measuring the size of a PHP project)
phing/phing suggests installing phpunit/phpunit (The PHP Unit Testing Framework)
phing/phing suggests installing phpunit/php-code-coverage (Library that provides collection, processing, and rendering functionality for PHP code coverage information)
phing/phing suggests installing pear/versioncontrol_svn (A simple OO-style interface for Subversion, the free/open-source version control system)
phing/phing suggests installing pear/versioncontrol_git (A library that provides OO interface to handle Git repository)
phing/phing suggests installing pear/archive_tar (Tar file management class)
phing/phing suggests installing tedivm/jshrink (Javascript Minifier built in PHP)

ドキュメントにはSphinxを使うので phpDocumentor はイイかな。。。
いらない物もあるし、以下の様にして、再度 update。

{
“require-dev”: {
“phing/phing”: “*”,
“phpunit/phpunit”: “4.*”,
“squizlabs/php_codesniffer”: “*”,
“phploc/phploc”: “*”,
“pdepend/pdepend” : “*”,
“phpmd/phpmd” : “*”,
“sebastian/phpcpd”: “*”,
“theseer/phpdox”: “*”
}
}

これで実際にインストールされたのは以下のパッケージ達。

|———————————–+———+—————————————————————-|
| packeage | version | desc. |
|———————————–+———+—————————————————————-|
| doctrine/instantiator | 1.0.5 | A small, lightweight utility to instantiate objects in PHP … |
| nikic/php-parser | v1.3.0 | A PHP parser written in PHP |
| pdepend/pdepend | 2.1.0 | Official version of pdepend to be handled with Composer |
| phing/phing | 2.11.0 | PHing Is Not GNU make; it’s a PHP project build system or b… |
| phpdocumentor/reflection-docblock | 2.0.4 | |
| phploc/phploc | 2.1.4 | A tool for quickly measuring the size of a PHP project. |
| phpmd/phpmd | 2.2.3 | PHPMD is a spin-off project of PHP Depend and aims to be a … |
| phpspec/prophecy | v1.5.0 | Highly opinionated mocking framework for PHP 5.3+ |
| phpunit/php-code-coverage | 2.2.2 | Library that provides collection, processing, and rendering… |
| phpunit/php-file-iterator | 1.4.1 | FilterIterator implementation that filters files based on a… |
| phpunit/php-text-template | 1.2.1 | Simple template engine. |
| phpunit/php-timer | 1.0.7 | Utility class for timing |
| phpunit/php-token-stream | 1.4.6 | Wrapper around PHP’s tokenizer extension. |
| phpunit/phpunit | 4.8.5 | The PHP Unit Testing framework. |
| phpunit/phpunit-mock-objects | 2.3.7 | Mock Object library for PHPUnit |
| sebastian/comparator | 1.2.0 | Provides the functionality to compare PHP values for equality |
| sebastian/diff | 1.3.0 | Diff implementation |
| sebastian/environment | 1.3.2 | Provides functionality to handle HHVM/PHP environments |
| sebastian/exporter | 1.2.1 | Provides the functionality to export PHP variables for visu… |
| sebastian/finder-facade | 1.2.0 | FinderFacade is a convenience wrapper for Symfony’s Finder … |
| sebastian/git | 2.0.1 | Simple wrapper for Git |
| sebastian/global-state | 1.0.0 | Snapshotting of global state |
| sebastian/phpcpd | 2.0.2 | Copy/Paste Detector (CPD) for PHP code. |
| sebastian/recursion-context | 1.0.1 | Provides functionality to recursively process PHP variables |
| sebastian/version | 1.0.6 | Library that helps with managing the version number of Git-… |
| squizlabs/php_codesniffer | 2.3.3 | PHP_CodeSniffer tokenizes PHP, JavaScript and CSS files and… |
| symfony/config | v2.7.3 | Symfony Config Component |
| symfony/console | v2.7.3 | Symfony Console Component |
| symfony/dependency-injection | v2.7.3 | Symfony DependencyInjection Component |
| symfony/filesystem | v2.7.3 | Symfony Filesystem Component |
| symfony/finder | v2.7.3 | Symfony Finder Component |
| symfony/yaml | v2.7.3 | Symfony Yaml Component |
| theseer/directoryscanner | 1.3.1 | A recursive directory scanner and filter |
| theseer/fdomdocument | 1.6.1 | The classes contained within this repository extend the sta… |
| theseer/fxsl | 1.1.1 | An XSL wrapper / extension to the PHP 5.x XSLTProcessor wit… |
| theseer/phpdox | 0.8.1.1 | A fast Documentation generator for PHP Code using standard … |
|———————————–+———+—————————————————————-|

# コード品質を高める、おなじみっぽい名前のツール達
CppUnitが会社の規定に合わないので、xUnit系のテストを触るのは始めてだ。
他に C++でもお世話になった記憶のあるPMDの親戚達もインストールされた。

– PHPUnit: xUnitの親戚。PHPテストコードを実行する
– phpcs (php_codesniffer): コーディング規約チェック
– phpmd: 怪しい実装方法の箇所をチェック
– phpcpd: コードの重複をチェック

# Jenkinsプラグインのインストール
Jenkins のプラグインには、 PHP Plugin と Phing Plugin をインストール。
これだけで依存するパッケージが細々とインストールされる。

あれ? DRY plugin が選べなくななってる。
最近の Jenkins に対応していないらしい。

自動的にインストールされた “Duplicate Code Scanner Plug-in” って言うのが
代わりに使えそうなので、このまま進めよう。

# カバレッジツールが入ってない
PHPUnitからxdebugを呼び出して計測するつもりなのだけど、
xdebugが composerでインストールできていない。

[xdebug](http://xdebug.org/docs/install) を読むと、
自分でビルドする必要がありそう。

brewでも入れられるけど、PHPはせっかくcomposerで管理しているので、
混乱が無いようにしておきたい。

まだ使わないので、おいおいインストールすることにしよう。

#+BEGIN_COMMENT
/etc/php.d/xdebug.ini に以下の設定を追加。
zend_extension=/usr/lib64/php/modules/xdebug.so

http://www.spiceworks.co.jp/blog/?p=4188

http://qiita.com/khironori/items/c145d7e3eed7b2a5a01a
#+END_COMMENT

emacsのorg-mode で WordPress の記事を書きたい

org-mode で書いた記事を、そのまま WordPress に投稿したい。

方法は、大きく分けて二つある。

– org-mode で HTMLに変換してからコピペする
– org-mode の書式を解釈する WordPress のプラグインを新たに作る

org-mode側でHTMLに変換する方法は、
WordPressの記事一覧が酷い事になるのが目に見えている。

いつかは画像も自動で組込みたいし、
後者の、プラグインを新たに作るのが良さそう。

車輪の再発明ぽくてイヤだけど、自分で使う目的だし、
自由が効く方が良いか。

問題はむしろ、PHPの開発経験が全く無いこと。

orgのテーブルを変換するプラグインは小さかったので、
一旦pythonで書いてから、本番サーバ上でPHPに移植する
という、恐しい開発方法だったけど。

今回は、ちゃんとテスト環境をそろえて開発したい。

テーブルプラグインの開発では、
WP-MarkDown の不具合(バグの様な仕様)で、
保存する度に記事を壊されて無駄に時間がかかってしまった。

WP-MarkDown とはオサラバして、スッキリ開発したい。

で。

対応したいタグは、こんなもの。

– 段落タイトル 3段階
– 段落
– コード
– テーブル
– 引用
– 段落
– 強調/イタリック
– リンク
– リスト
– *インライン画像
– (入れ子リスト)
– (番号リスト)

これだけ変換するには、
テーブルプラグインの構造では間に合わないので、
きちんと文章を構文解析する必要がある。

それに、ちゃんとしたテスト環境を作ってから開発したいし
新調した MacBookPro に合わせて、CI環境を再構築しないと…

2015年の8月末までの取引まとめ

# 2015年の8月の成果
とにかくひどい夏枯れ相場から一転、
というか溜ったエネルギーが円高方向に噴出した8月。

USDJPYのループイフダン以外はヒドイ状態で、
スワップでソコソコ助かっている。

アノマリー通り、盆の円高は今年も来た。と言うことか。

# 市況
## 米国
9月利上げで待ったなし、のはずが、
中国のサプライズの連続で抑え込まれそうな雰囲気が続いた8月。。

そんな中、盆開けのブラックマンデー発生で、
またしても利上げが遠退いた。

こうなると、利上げ観測後退で円高に振れるのか、
とりあえず好景気な米国に資産が移動してドル高か。

中長期の見通しが、やや円高に傾いたのは間違いない。
どっちにしても、ヒドイことになる気はしない。

## EUの経済破綻問題
## ギリシャ
大統領辞任などもあったが、たいしてニュースにならなくなった。
世の中ギリシャの我侭に付き合っている場合じゃない。
ユーロというかドイツが何とかするんだろう。という雰囲気。

## トルコ
ISIS空爆と政治空白で泥沼化。
11月に再選挙が濃厚になり、下げる一方。

ここは買い、のハズなのだが、リスクオフムードの方が強い。
いずれ上げるのは間違いないが、もう一回くらいは下げるだろうか。

## 中国
バブルはどう収束するか? と言われながら始まった8月。

8月11日に突然、中国政府が人民元の為替レートを対ドルで2%切り下げた。
輸出で儲けようという腹なんだろうけど、
中国はもう待ったなし、なんだ、というネガティブイメージしかない。

翌12日に、天津で大爆発。(他にも数件爆発)
中国政府の発表に比べ、映像からはシャレにならない規模に見える。
街が吹き飛んで、世界第3位の貿易港が機能停止。国内テロとの噂も。

更に8月24〜25日には、中国・上海発の世界同時株安。(というか中国発株安)
翌日には、中国が金利引下げの金融緩和策を提示した。
今更感はあるけど、これは評価されるだろう。

中国株の下げは、バブル前水準まであと少し。
以外とソフトランディングだった、とも言える。

ブラックマンデーやリーマンショック並の騒動だった割に、
影響は少なかった様で、25日にはかなり戻している。

波を残しつつ収束しそうな雰囲気。

## オセアニア
8月上旬、オージーは下げ止まり。
キューイはTPPで波紋。乳製品の価格下落が止まらない。
そこへ人民元切り下げで、背後から追い討ちをかけられた格好。

中国と共に沈む気でないなら、何か手を打つ頃だと思うけども、
何も対策らしき発表が聞こえて来ない。
オセアニアとしては、通貨安を望んでいるんだろう。
金利もまだ下げて行くのだろう。

## 日本
8月に入って、円安牽制が始まった。124円位が心地良いのだろう。
そんな雰囲気の盆空けに、一時116ドル円の円高。

直ぐに120円まで戻したものの、他国の状況が円高圧力になっているので、
そろそろ黒田サプライズがあっても良い頃合いかもなぁ。

# 裁量取引の成果と課題
上旬は動きが無く、中旬は乱高下が酷かっかので、裁量取引は一旦停止中。

7月までの利益の1/4位を使ってポジションを整理したので、
今月は大幅な赤字。損切りには妙な快感がある事を知った。

# トラリピ/ループイフダン成果
# 今後のトラリピ/ループイフダンの課題
トラリピは下抜けてしまったのだが、
ポジションが膨れ過ぎなので追従はしない。
当分はスワップだけで我慢する。

その代りに、
ループイフダンが良い仕事をしてくれている。

dyerware.com



dyerware.com


dyerware.com



dyerware.com


見て確認できる通り、8月のトラリピは本当に動いていない。
下旬はレンジ離れだけど、上旬は市場が動いていなかったため。

対してループイフダンの方は、特に盆明けの行って来いで良い仕事をしてくれた。

トラリピのスワップとループイフダンで、安定した利益が上ってくるのは助かる。

# 今後の計画
## ループイフダン
高値ポジションを損切りしつつ市場に追従し、
USDJPY_B15_15 一本に整理する。

ループイフダンは儲かるのだが、リスク管理が難しいので、
比率を下げていく。

## トラリピ
下抜けした状況を回復するため、高値ポジションを少しづつ整理する。
特に、増え過ぎてしまった NZDJPY を削減し、TRYJPY に回す。
その後、またしばらく放置。

## 裁量取引
TRYJPYのナンピン&短期利食い継続。

この数ヶ月、トラリピに頼り過ぎていたので、
秋には裁量取引を復活させる。

Bitbucketとローカルのgitを連携する

[Bitbucket](https://bitbucket.org/plans)とローカルのJenkinsを連携させる。

このJenkinsは個人作業用なので、gitとJenkinsの関係が通常とは逆。

1. ローカルのgitリポジトリで作業&コミットする
2. Jenkinsで、ビルド&テストを行なう
3. 成功した場合にBitbucketにpushする

# Bitbucketにリポジトリを作成する
Bitbucketのウィザードに従って作成。
(Webで検索したのとは結構変わってるみたい)

出来たリポジトリは [org2html](https://bitbucket.org/somof/org2html.git)

今作ったリポジトリのページで、
Setting > デプロイ鍵 > 鍵を追加 から
さっき作ったJenkinsユーザの公開鍵をコピペしておく。

# ローカルのgitリポジトリにBitbucketを登録
まず、ローカルのgitリポジトリに、さっき作ったリモートリポジトリを追加。

$
$ git remote add origin https://bitbucket.org/somof/org2html.git
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

Bitbucketの方で、最初から README.* や画像ファイルが入れられていたので

$
$ git pull
$ git rm README.*
などして削除
$ git push

Macの人は、以下のようにパスワードを覚えさせておくと、少し便利。

$
$ git config –global credential.helper osxkeychain

ここまでやってみて気がついたけど。(汗)

Bitbucketって、置いてあるhtmlファイルのプレビュー出来ないんだな…
作業には困らないけど、地味に不便。

てか、今回のワークフローだと、 Bitbucketに転送する意味無くなっちゃったな。

仕事で使っているgitlabだとプレビューできるので、
HTMLドキュメント化した資料を公開するのにも使えて、
GitHubやBitbucketも同じなんだと思ってた。

Sphinxで始める極楽ドキュメント作り その2

pythonのdocstringからのドキュメント作成。

例えば。
pythonソース用のrstファイルを以下のように用意すると、
良い感じにdocstringからドキュメントを作成してくれる。

標準だと init はドキュメント化されない。
special-members で指定しても良いけど、面倒なので
僕は initの引数や変数は class の方に書くようにしている。

各メソッドの引数や変数は、以下の様に書くことが出来る。

Sphinx PHPもpythonみたいにソース中にドキュメントを書きたい

pythonみたいに、PHPもソース中にドキュメントを書きたい!

tk.phpautodoc を使えば出来そう。

pipでインストールできる。

そして、Sphinx の conf.py に次の設定を書き足す。

reSTファイルで

関数直前のコメントに簡単に説明を書ける。

phdoc程便利ではないにしても、無いと有るでは全然違う。
作者に感謝。

Sphinxで始める極楽ドキュメント作り

Sphinx + Jenkins で始めるドキュメントの継続的インテグレーション に感化されて。

ホイホイと brew でインストールして。。。 はいけない。
これは別のSphinx。

たいていの作業が一人プロジェクトとは言え、
コードの量がある程度大きくなって来たら、
記憶はあてにならない。

なので、ドキュメント化は必須。
出来れば作業を軽くしたいし、自動化もしたい。

これまでは org-mode から記事を抜き出して流用していたけど、
org-mode では TODOとメモ的な運用をしているし、
emacsがないと変換できないので、人にあげられない。

人にあげる時には、 org-mode から htmlやpdfに変換していたけど、 この作業が結構煩雑なので、思った通りの綺麗な文章に変換するのは
ちょっと手間だし、ついつい拘って時間をかけてしまう。
人に編集や更新してもらうことも難しい。

本当のTODOとドキュメントが混ざるのも管理しにくいので、
残す資料は、巷で流行りの Sphinx を試してみることにする。

早速、インストール。

ここで要注意。
冒頭の通りbrewに同じ名前の別のアプリがあるので、pipを使うこと。

で、インストールが済んだら、最初のドキュメント作り。

sphinx-quickstart でも雛形を作れるけど
ある程度ドキュメントを作ったことがある人なら、
2portfolio.zipのサンプルを複製する方が分り易いと思う。

他のツールでドキュメントを作ったことがある人なら、
チュートリアルで一つ一つ覚えていくより、
凡そのコマンドとドキュメントの構造が理解し易いはず。

今回の一番のおたのしみはブロック図。

org-modeでは、graphvizとplantUMLを使っていたけど、 やや癖があったり、日本語が不自由だったりするので、 もうちょいお手軽なブロック図作成スクリプトが欲しかった。

Sphinxでは、blockdiagが良く使われている様なので試してみる。

インストールしたのは、以下の作画ツール。

  • ブロック図生成ツール blockdiag
  • シーケンス図生成ツール seqdiag
  • アクティビティ図生成ツール actdiag
  • ネットワーク図生成ツール nwdiag

残念ながら、クラス図などにピッタリと都合が良いものは無さそう。

書式はgraphvizとほぼ同じで、テキスト状態でも内容が見易い。

さっくり日本語が出し、色や背景、各ブロックの説明一覧が簡単に追加できるなど、
とても気が効いている。

PHP 開発に挑戦!せっかくだから振舞駆動開発をやってみる…か?

新しい職場の仕事用に Jenkins を使い始める事にした頃、
題材としてテスト駆動開発(TDD:Test Driven Development)の勉強も始めた。

そして、半年程度の開発期間中に、何度もデグレを発見して、間違いなく助けられた。
テスト駆動開発は正しいのだ。

だけども、今の職場には根付かず、殆ど自己満足に終わった。
事前に設計仕様書や実装仕様書を書くことが無い今の職場では、
テストに説得力がないし、後から出来た仕様書と整合性を取るのは不可能に近かった。

いやいや、これではTDDになってないぞ。

テスト仕様書を元に設計仕様書が提案出来ないものか。。。
そんな事を思った人が多かったらしく。(汗)
TDDから発展した振る舞い駆動開発(BDD:Behavior Driven Development)という考え方が出て来たそうだ。

TDDでは、(仕様書か頭の中にある)仕様に合っているかどうかをテストする。
BDDでは、仕様自体をテストする。

テストコードを書く時点で「どこかにある仕様」が正しい保証がある訳じゃないんだ。

BDDなら、テストコードと(未来の)要求仕様とが直接的に繋がっている。
上手に使えば、テストコードから仕様書を作ったり改善したり出来るはずだ。

早速、PHPの勉強ついでに、BDDを試してみよう。

振舞駆動開発 BDD とは?

Wikipediaのビヘイビア駆動開発 によると。

『これから作成しようとするプログラムに期待される「振る舞い」や「制約条件」、
つまり「要求仕様」に近い形で、自然言語を併記しながらテストコードを記述する』

従って、テストコードの可読性があがるし、テストコードが要求仕様となり得る、ということ。

これだ!欲しかったのは。

そのためには、
いくつか守るべきコンセプトがある。

Executable Specification

実行可能な仕様?
テストするのだから、当然、ひとつひとつが実行可能な範囲でないと。

と言うことかな?

Tests as Documentation

テストコードがそのままドキュメントになり得るよう、
自然言語の文章に近い形式で書く。
テストの可読性が上がり、振る舞いが分り易くなり、
そして、これ自体が詳細仕様書になる。(かも知れない)

Specification by Example

例示を基にして、仕様を見つけていく作業。
作業としては、TDDと違いないかも?

BDDの具体的なテンプレート

  • 「Given xxx. When yyy. Then zzz.」:「xxxであるときに、yyyすると、zzzになる」
  • 「Given」:事前状態を表現する
  • 「When」:刺激や操作を表現する
  • 「Then」:事後状態を表現する
  • 「x should y: テスト自体を「対象(x)がどうである(y)べきか?」と表現する

振る舞い以外を自動テストはするべきではない

内部構造に依存したテストでは、実装したコードの変更にテストが影響されてしまう。

PHPで使える振舞駆動開発フレームワーク

有名どころでは、
PHPUnit + PHPUnit_Story か、PHPSpec 。

なのだけど、どちらも既に開発が止まっている。
3年くらい前に流行が終ってしまったらしい。

ここまで調べておいて何だけど、
乗り遅れてしまったようだ。