2016年2月9日火曜日

PHPDocumentorでInterface 'PHPParser_NodeVisitor' not foundが発生する。


原因はPHPDocumentorの依存するPHPParserがメジャーアップデートしている事が原因。

composer.jsonを以下のように追加する。

    "require-dev": {
        ......
        "phpdocumentor/phpdocumentor": "2.*",
        "nikic/php-parser": "1.*",
        ....
    },



これで解決。と思ったら新たな問題が。
1.x系ではエラーは出なくなったが上手くパッケージを読み込んでくれない。
正常動作しているケースのライブラリを調べると入っているのは0.9.5。

では0.9.*でやるかと思ったら、今度はLaravel5.2側が1.0以上を要求。。。

うーん、あっさりapiGenに切り替えよう。

http://www.apigen.org/

phpDocumentorは開発が止まっているし、apigenかな。


と思ったらまたいろいろと。
動くことは動いた。pharバージョンなら。。。

composerでインストールするとエラーの嵐。ネットで調べるとコンポーネントの衝突等のissueが出るわ出るわ。
4.x系になってから迷走が続いているようで。

まぁ、Laravelのパッケージ開発やると自ずとvendorディレクトリの中に山程パッケージがインストールされる。それらの整合性が問題を引き起こすわけで、なかなか難しいというか時間がかけれない。

自前のパッケージも増えたことだし、パッケージビルドはphpcsやphpunit, coverage等で止めて、ドキュメント生成用のブロジェクトを別途作って、まとめて自動生成するというのが正解かもしれない。







2014年5月22日木曜日

fuelphpのユニットテストでNo tests found in class "Fuel\Core\TestCase"が発生する。


fuelphpでユニットテストを実行すると、No tests found in class "Fuel\Core\TestCase"のwarningが発生する。

原因はphpunit.xmlの中でテストケースを指定する際にワイルドカード(*)を使用している場合(デフォルトでそう)、phpunitがPHPUnit_Framework_TestCaseを継承しているクラスを検索するため、この警告が発生する。

いろいろ調べたが解決策は以下の2つ。

1) ファイル名と中のクラス名を完全に一致させる(大文字小文字も含め)

これはないでしょう。ほとんどの場合ファイル名は小文字で統一しているはず(かな)。

2) 直接PHPUnit_Framework_TestCaseを継承する。

Fuel/Core/TestCaseの中身を見てみよう。

namespace Fuel\Core;

/**
 * A Fuel Specific extension of the PHPUnit TestCase.  This will
 * be used for custom functionality in the future.
 */

class TestCase extends \PHPUnit_Framework_TestCase { }

ただの空のクラスだ。

下手にクラスの継承元をFuel\Core\TestCaseにすると、そのクラスがphpunitの検索に引っかかり警告が出るというわけ。

根本的な解決としてはこのFuel\Core\TestCaseをabstractにするのが正しいんだが。一応Fuelの開発チームにIssueであげときました。

2014/07/15 追記
* fuelphp 1.7.2でFuel\Core\TestCaseクラスが抽象クラスになるよう修正が行われました。

2013年11月21日木曜日

XCode5でiOS6を動作させる

XCode5ではiOSのSDKが7.0以上に指定されているため、iOS6等のアプリを生成しようとする場合にこれらのSDKが選択できなくなっている。

これはXCode5がiOS7以外をサポートしていないのではなく、バンドルされているiOSのSDKにiOS7以外が含まれていないためだ。
要はSDKを追加でインストールすればいいのだが、アップルはSDKのみの配布は行っていない。(2013/11)

そこでどうすればよいかというと、以前のバージョンのXCodeからバンドルしているSDKを抜き出してインストールすればいい。ここに辿り着いた方なら検索でいろいろと調べていると思うが、いずれもコマンドラインなどを使っていろいろと作業が必要となる。

他のサイトなどでは旧バージョンのXCodeをインストールし、そこから旧SDKをコピーして新しいXCodeを入れる、等の方法が多いが、いかに紹介する方法であれば旧XCodeを「インストールせず」に取り出すことができる。

1)旧バージョンのXCodeをiOS Devからダウンロード。
URL:  https://developer.apple.com/downloads/index.action?name=Xcode
(要デベロッパーアカウント認証)

ちなみに入っているSDKとXCodeのバージョンは以下のとおり。
XCode4.6x => iOS SDK 6.1
XCode4.5.x => iOS SDK 6.0

2) ダウンロードしたdmgファイルをクリック(マウント)する。
その後、表示されているXCodeのアイコン上でControl+Clickしてメニューを表示。
メニューから「パッケージの内容を表示する」を選択する。



Findeが開き、中のディレクトリが表示される。

3)SDKファイルを開く。SDKのパスは以下のとおり。

/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/


4) 別のFinderを表示し、アプリケーションフォルダに移動、XCodeのアイコンの上でControl + Clickを行いサブメニューを表示する。
同じように「パッケージの内容を表示」を選択して内容を表示する。


開いたFinderのパスをたどってSDKの場所を開く。
パスは先ほどと同じで以下のとおり。
/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/

4) dmgファイルのSDKを現在のSDKのFinderにコピーする。
(システム領域へのコピーのため、パスワードが聞かれる)

おしまい。

めでたく起動したXCode5でSDKが選択できるようになっています。









2013年2月18日月曜日

ApacheのWebDAVのPHPファイルで失敗する場合

Apache2.x系からはWebDAVもすんなり使えるようになっている。
設定方法などはWebにたくさん掲載されているのでそちらにゆずるが、意外なところではまったのでメモ。

WebDAVでアクセスしている場合に、PHPファイルのアップに失敗が続くというケースに見舞われた。
この場合はDAVを提供しているApacheにPHPがロードされている場合に起こる現象で、DAVのLocation等でRemoveHandlerを使って、PHPを無効化させることで対応できる。
(.cgiも同じく)



  DavLockDB /home/dav/lock/davlock
  Alias /dav "/home/dav/public"
  <Location /dav>
    DAV On
    RemoveHandler .cgi
    RemoveHandler .php

    AddDefaultCharset UTF-8
    Options +Indexes
    IndexOptions FancyIndexing FoldersFirst TrackModified XHTML Charset=UTF-8

    .....
  </Location>

2013年1月25日金曜日

バックアップツールとしてのjenkins

今やCI(Continuous Integration)の定番ツールとなりつつあるjenkins。構築、テスト、デプロイ等を自動化で安定させることで生産性を大幅に上げてくれる。
弊社でも様々なプロジェクトで使用しており、もはや必須のツールとなった。

Jenkinsの柔軟性が高く、Maven、AntだけでなくPhing等のビルドツールだけでなくシェルスクリプトも使える。(もちろんUNIXベースだが)


  • シェルスクリプトが使える。
  • それぞれのジョブの作業場所(ワークスペース)が使える。
  • ジョブの成功・失敗の判定処理が行える。
  • 失敗時のアラート処理
  • ジョブの成果物を管理できる。

これらの機能を考えるとJenkinsはバックアップツールとしても非常に有用である。

実際、稼動しているサーバーのバックアップに以下のシナリオを適用している。

前提

  • 対象となるホストはバックアップ用のアカウントで鍵認証によるSSH接続。
  • バックアップのスクリプトはSubversionで管理。


シナリオ

  1. ジョブでスクリプトをSubversionからワークスペースに展開
  2. ジョブのタスクにスクリプトの実行を設定
  3. スクリプト内でrsyncで対象ホストからバックアップの対象となるファイルをワークスペースにコピー。
  4. tarコマンドで1つのアーカイブに圧縮。
  5. ジョブのビルド後のタスクに、作成したアーカイブを成果物として指定
  6. 失敗時はアラートでメールを送信

生成したアーカイブをジョブの成果物として登録することでローテートと同じ機能を実現できる。Jenkinsではジョブの設定でビルド数(または成果物)の保存日数またはその個数を指定することができる。また、成果物をJenkinsの画面からすぐにダウンロードできることも便利だ。

データベースのバックアップ等、当該ホストで処理が必要なバックアップはJenkinsからscpを使って当該ホストへバックアップ用のスクリプトを送信した後、ssh経由で実行させ出来上がったファイルをワークスペースにコピーしている。
これにより当該ホストでの処理とジョブの処理を同期させることが可能となる。

また、スクリプトを使う場合、Jenkins側で以下のような有用な環境変数が自動的に設定される。



BUILD_NUMBER
当該ビルドの番号。例 "153"
BUILD_ID
当該ビルドID。例 "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss)
JOB_NAME
ビルドのプロジェクト名。例 "foo"
BUILD_TAG
文字列 "jenkins-${JOB_NAME}-${BUILD_NUMBER}"。簡易な識別子として、リソースファイルやjarファイルなどに付与するのに便利です。
EXECUTOR_NUMBER
このビルドを実行している現在のエグゼキューターを識別する(同一マシンの中で)ユニークな番号。"ビルド実行状態"に表示されている数字ですが、1ではなく0から始まる数字です。
NODE_NAME
ビルドが実行されるスレーブの名称。マスターで実行される場合は"master"。
NODE_LABELS
ノードに設定されたラベルのリスト(スペース区切り)。
WORKSPACE
ワークスペースの絶対パス。
JENKINS_HOME
The absolute path of the directory assigned on the master node for Jenkins to store data.
JENKINS_URL
JenkinsのURL。例 http://server:port/jenkins/
BUILD_URL
このビルドのURL。 例 http://server:port/jenkins/job/foo/15/
JOB_URL
このジョブのURL。 例 http://server:port/jenkins/job/foo/
SVN_REVISION
Subversion revision number that's currently checked out to the workspace, such as "12345"
SVN_URL
Subversion URL that's currently checked out to the workspace.



Jenkinsは使い方次第で様々な用途に使える。優秀なバックアップツールとしてもぜひ活用してみてはどうだろうか?






2013年1月23日水曜日

daemontoolsのインストール


daemontoolsとは

daemontoolsとはD.J.Bernstein氏が開発したUNIX向けのsupervise monitorツール。要は特定のプログラムをデーモン化させるツール。
今となってはいささか古いが、シンプルかつ軽量で根強い人気を誇る。

パッケージの入手

場所はどこでもいいが、今回は/usr/local/src配下でインストール。まず以下のコマンドでパッケージを入手。その後tarコマンドで展開。
$PACKAGE_HOME=/usr/local/src
# cd $PACKAGE_HOME
# wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
# tar zxvf daemontools-0.76.tar.gz

パッチの適用

glibc-2.3.2以降ではコンパイル時にエラーが出るので以下のパッチを作成・適用
$PACKAGE_HOME/admin/daemontools-0.76/daemontools-0.76.errno.patch
diff -ur daemontools-0.76.old/src/error.h daemontools-0.76/src/error.h
--- daemontools-0.76.old/src/error.h 2001-07-12 11:49:49.000000000 -0500
+++ daemontools-0.76/src/error.h 2003-01-09 21:52:01.000000000 -0600
@@ -3,7 +3,7 @@
 #ifndef ERROR_H
 #define ERROR_H
 
-extern int errno;
+#include 
 
 extern int error_intr;
 extern int error_nomem;
以下のコマンドでパッチを適用
# cd $PACKAGE_HOME/admin/daemontools-0.76
# patch -p1 < ./daemontools-0.76.errno.patch

インストール

$PACKAGE_HOME/admin/daemontools-0.76で以下のコマンドを実行。
# package/install

CentOS6.xでの修正

OSのレイアウトも変わりデフォルトのままでは正しく自動起動が行われない。
正しく動作させるため、以下のファイルの内容をコメントアウトする。
/etc/inittab
# SV:123456:respawn:/command/svscanboot
以下のファイルを作成
/etc/init/svscan.conf
initctl reload-configuration
initctl start svscan
OSの再起動後、自動起動が行われるようになる。

2013年1月22日火曜日

Wordpressを全てSSL化する

リバースプロキシ(Pound)の背後に内部向けのCMSを配備する必要があったので、WordPressをSSL化する必要があった。
管理者サイトだけ、もしく入力フォームだけというような部分的なSSLの方法はネットにいろいろ情報があったが、今回はリバースプロキシから当該サーバーまではIPで縛ったHTTP通信のため、URL判定ではなく強制的にSSL化する必要がある。

最も簡単な方法は以下のとおり。

$WP_HOME/wp-include/function.php

function is_ssl() {
        return true;
//        if ( isset($_SERVER['HTTPS']) ) {
//                if ( 'on' == strtolower($_SERVER['HTTPS']) )
//                        return true;
//                if ( '1' == $_SERVER['HTTPS'] )
//                        return true;
//        } elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
//                return true;
//        }
//        return false;
}

is_sslの関数の内容を全てコメントアウトし、return true;で強制的にSSLとして判定させる。