カテゴリー別アーカイブ: program

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環境を再構築しないと…

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年くらい前に流行が終ってしまったらしい。

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

Jenkins を MAcBookAirに再インストール

PHPの開発・テスト環境を作るため、
MAcBookAirにも、MBPRl2015と同じCI環境を用意する。

Jenkins のHPでは、こう書いてあるけど。

以前、ユーザー権限で動かすために
jenkins-runner.sh をチョコチョコとイジったのだった。

今回は、brewでサクっとインストールする。
jenkinsは以前は Cask だったけど、今は普通にインストールできる。
brewのメッセージは Cask の頃と違っていて

こんな感じ。
とりあえず、さっそく実行してみる。

あぁ、古いサービスが設定されたままだった。
どっちがどっちか分からないから、両方停止しよう。

ついでなので、古い.jenkins を消して、全部やり直すことにした。
これで Air でも、サッパリと最新版の Jenkins が使える。

ん? jenkins-runner.sh が見当らない。
まぁ良いか。
Airの方はデーモン化しないで、必要に応じて jenkins 直打ちで使うことにする。

ちなみに。
Caskの頃のインストール時のメッセージは、こんな感じだった。

Chrome の右上にIDが、しかも日本語で表示されるのをやめて頂く設定方法

Chrome の右上に日本語で名前が表示されてしまう。

しかも名字ではなく下の名前なので
日本人的に気持悪いと思う。

デザイン的にもどうかと思うし、
IDが一つしかなれば表示する必要でもないので、
さくっと消えて頂きたい。

ところが。
以前は、「新しいアバター メニューを有効にする」を「無効」にすれば良かったのに、
今使っている バージョン 44 のChromeには、設定画面 chrome://flags/ に、
その項目が無くなってしまった。

なんてこったい。

設定画面が無くなったので、
この日本語名の「新しいアバターメニュー」を消すには、
Chromeの起動オプションで –disable-new-avatar-menu というスイッチを指定する必要がある。

タスクバーにピン止めしている人なら、そのショートカットのプロパティで指定できる。
常駐型の拡張機能を使っている人は、全部止めてから再起動する。

Jenkins Visual Studio で自動ビルド その2

やっと今回の趣旨。JenkinsでVisualStudioの自動ビルド。

まず MSBuild Plugin をインストール。

その後「ビルド手順の追加」で
「Build a Visual Studio project or solution using MSBuild」を追加する。

設定画面で、使用する MSBuild.exe を指定する所で注意が必要。

「path:」に、例えば C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe を指定するのだけど、
バグがあるらしく、「フォルダーを指定せよ」的に怒られる。

ここで引き下がって、「C:/Windows/Microsoft.NET/Framework/v4.0.30319/」とかに変えると
実行時に「コマンドが無い」と言って当然動かない。
ひるまずに「C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe」と指定する。

今回はプロジェクトに含まれるデータが多くてcloneに時間がかかるので、
既存の Visual Studio のプロジェクト上で直にビルドすることにした。

ソース自体は、ローカルのgitで管理しているので、
ファイル監視を行うFSTriggerプラグインを使ってgitへのコミットをポーリングする。

Git plugin を使って SCMをポーリング を選ぶと、
コミットのコメントもJenkinsから見えて把握し易いのだけど、
今回は軽量・ご気楽な構成にしておく。

JenkinsでVisualStudioのワーニングをパースする

パースするプラグインは
Warnings Plugin より
Log Parser Plugin の方が
簡易で使い勝手が良い。

パースするための設定は

stackoverflow.com のQA
Good MSbuild log formatter? で、
VisualStudio向けのログの検索式がいくつか紹介されている。

とか

とか。

とりあえず、前者の設定で使っている。

Jenkins Visual Studio で自動ビルド その1

仕事の検証サーバのJenkinsを管理しているのだけど、
自分の開発PCのJenkinsは放置ぎみだった。

検証サーバはLinuxなので色々揃っていて扱い易いんだけど、
開発PCはWindowsなので、サーバ的に運用するのは案外手間がかかる。

一番気楽そうな MicroApache + Jenkins の組み合わせで、
完全に個人用にして使っていた。

だいぶんバージョンが古かったせいか、
プラグインをアップデートしようとしたら、
Jenkinsが動かなくなった… (汗)

以前使っていたプロジェクト類は、もう読み込めないみたいなので
何もかも全部削除して、新規に作り直すことにした。 (涙)

最新の Jenkins.war を壊れたJenkinsから拾ってきて、
とりあえず起動して、ブラウザから確認してみる。

認証つきにしろ、とか言われるけど、ローカルの個人使用だから無視。
会社のネットワークがIPV6に切り替わったので、プロキシーだけ修正した。

新しい Jenkinsって、どこを探しても再起動らしきものがない。
「シャットダウンの準備」を選んでも、いつまで絶っても終了しないし。

再起動画面に直にアクセスしても、
起られるだけど、再起動しない。

何か使い方が違うのか?
毎回強制終了でしのぐことにする。

もう一つハマった事は、git。

個人PCなので、Gitはローカルリポジトリで運用したい。
WindowsスタイルというかDOS形式で指定したり、
URL形式 file://〜 で書いても clone出来なかった。
一旦諦めたのだけど、試しに cygwin形式で書いたら、あっさり動いた。

/cygdrive/d/~ みたいに、cygwin形式でないとダメだった。
cygwinのgitを使ってしまったらしい。

長くなったので、本題の VS自動ビルドは次の記事で。