Amazon EC2 と Groovy と QuartzScheduler と commons-daemon

2012/11/11 のポッキーの日に「AWSで動かすWordPressとその高速化」セミナーに伺いまして、Amazon Web Service を堪能して参りました。 🙂

AWSで動かすWordPressとその高速化

アマゾン ウェブ サービス(AWS) にはウェブデザイナーにとっても魅力的なサービスがたくさんあります!
今回はAmazon Web Servicesのテクニカルエバンジェリストである堀内さんをお招きし、すぐにでも使えるサービスを実際に体験しながら(ハンズオンで学びならが)その魅力たっぷりのサービスについてを学びます。

また、AWS上でWordPressを使えるようにし、さらに高速化する方法について、 株式会社デジタルキューブ の小賀さんをお招きし、実際に体験しながらその方法についてを学びます!

tenpura さんや小賀さんにも久しぶりにお会いできまして楽しいひとときでした。

仕事柄、仮想化基盤には慣れてはいるものの、超高速チューンされた WordPress である「AMI 網元」がほとんどワンクリックでデプロイされる様子や、ストレージのスナップショットバックアップはやはり魅力的なフューチャーでした。

WordPress AMI – 超高速 WordPress AMI 網元

EC2のMicro Instance(無償枠あり)を利用すれば、圧倒的にハイパフォーマンスなWordPress環境をコンパネ操作のみで誰でも簡単に構築できます。WordPressの高速化対策、スマートフォン対策に効果的です。

現在のクラウドと呼ばれるサービスの根幹をなしているのは間違いなく仮想化技術です。 そして WordPress を実用的にクラウドにのせる試みはすごく面白いものでした。:)

AMI 綱元も使える Amazon EC2 のマイクロインスタンス(アカウント登録から1年無料とのこと)。

EC2 は root がもらえる IaaS。

[tegaki]むふふ..(←脱線したようだ[/tegaki]

というわけで、Groovy と QuartzSchedulercommons-daemon を使って怪しい(?)デーモンを動かしてみることにしました。 😛

デーモンは処理(スレッド)の途中終了をつくるのが結構大変だったりしますが、QuartzScheduler にそのへんを任せると定期実行する常駐ものが簡単につくれます。

以下の例は 20秒おきにログをはくデーモンです。実際には CronScheduleBuilder.cronSchedule で時間を決め、QuartzJob::execute() に好きな処理を実装します。

QuartzDaemon.groovy

package net.maple4ever.daemon

import org.apache.commons.daemon.*
import org.quartz.*
import org.quartz.impl.*
import org.apache.log4j.Logger

class QuartzDaemon implements Daemon {

    def static logger = Logger.getLogger(QuartzDaemon.class)
    def static daemon = new QuartzDaemon()
    def static sched = (new StdSchedulerFactory()).getScheduler();

    @Override
    public void init(DaemonContext arg0)
        throws DaemonInitException, Exception {
        // every 20 seconds
        def job = JobBuilder.newJob(QuartzJob.class)
            .withIdentity("job1", "group1")
            .build();
        def trigger = TriggerBuilder.newTrigger()
            .withIdentity("trigger1", "group1")
            .withSchedule(
                CronScheduleBuilder.cronSchedule("0/20 * * * * ?"))
            .build();
        sched.scheduleJob(job, trigger);
    }

    @Override
    public void start() throws Exception {
        logger.info("START QuartzDaemon")
        sched.start()
    }

    @Override
    public void stop() throws Exception {
        logger.info("STOP QuartzDaemon")
        sched.shutdown(true)
    }

    @Override
    public void destroy() {
        logger.info("DESTROY QuartzDaemon")
    }

    static main(args) {
        daemon.init(null)
        daemon.start()
        System.in.withReader {
            print  'Hit any key to exit.'
            println it.readLine()
        }
        daemon.stop()
    }
}

class QuartzJob implements Job {

    def static logger = Logger.getLogger(QuartzJob.class)

    def QuartzJob() {
    }

    @Override
    public void execute(JobExecutionContext context)
        throws JobExecutionException {
        // execute job
        JobKey jobKey = context.getJobDetail().getKey()
        logger.info("QuartzJob says: " + jobKey + " executing at " + new Date())
    }
}

commons-daemon のインターフェースに従ってクラスを定義して、init で QuartzScheduler のジョブ定義。 commons-daemon からのの start、stop をそのままQuartzSchedulerにパスしてあげればOKです。

また、この例のように static main メソッドをつくっておくとデバッグ時にデーモンではなくそのまま実行できるので便利です。

できたら groovyc でコンパイルしたクラスファイルを、commons-daemon の jsvc を次のようなシェルから起動してあげます。

setenv.sh

#!/bin/sh

SCRIPT_HOME=/opt/daemon
JSVC_USER=hiromasa

JAVA_HOME=/usr/lib/jvm/java

GROOVY_LIB=/opt/groovy-2.0.5/embeddable/*
LIB_HOME=$SCRIPT_HOME/lib
LIB_PATH=$GROOVY_LIB:$LIB_HOME/commons-daemon/*:$LIB_HOME/log4j/*:$LIB_HOME/quartz/*
LIB_PATH=$LIB_PATH:$SCRIPT_HOME/script
LIB_PATH=$LIB_PATH:$LIB_HOME/twitter4j/*:$LIB_HOME/javamail/*

#for command line(ex. $GG Foo.groovy)
export GG="java -cp $LIB_PATH groovy.ui.GroovyMain"

# twitter4j とか javamail とかは必要ありません。(ぼくの別デーモンで使われています 🙂

export している $GG はスクリプト作成時の実行用で、シェルから . ./setenv.sh などとして環境をもってきた後に、$GG QuartzDaemon.groovy とするとコンパイルせずに static main から実行できるようなっています。(UNIX 上の vi などで直接 .groovy をかくときに便利です)

ディレクトリ構成と lib は以下のような感じです。

[hiromasa@]$ ls -laF
合計 28
drwxr-xr-x 7 hiromasa hiromasa 4096 11月 18 08:57 2012 ./
drwxr-xr-x 5 root     root     4096 11月 18 09:38 2012 ../
drwxrwxr-x 2 hiromasa hiromasa 4096 11月 18 09:45 2012 bin/
drwxrwxr-x 7 hiromasa hiromasa 4096 11月 18 01:53 2012 lib/
drwxrwxr-x 2 hiromasa hiromasa 4096 11月 18 09:48 2012 log/
drwxrwxr-x 4 hiromasa hiromasa 4096 11月 18 10:56 2012 script/
drwxrwxr-x 2 hiromasa hiromasa 4096 11月 18 09:48 2012 tmp/
[hiromasa@]$ ls -laF lib/*
lib/commons-daemon:
合計 32
drwxrwxr-x 2 hiromasa hiromasa  4096 11月 17 11:43 2012 ./
drwxrwxr-x 7 hiromasa hiromasa  4096 11月 18 01:53 2012 ../
-rw-rw-r-- 1 hiromasa hiromasa 24242  2月 23 23:22 2012 commons-daemon-1.0.10.jar

lib/log4j:
合計 488
drwxrwxr-x 2 hiromasa hiromasa   4096 11月 17 12:01 2012 ./
drwxrwxr-x 7 hiromasa hiromasa   4096 11月 18 01:53 2012 ../
-rw-rw-r-- 1 hiromasa hiromasa 489883  5月  6 11:01 2012 log4j-1.2.17.jar

lib/quartz:
合計 1212
drwxrwxr-x 2 hiromasa hiromasa   4096 11月 18 07:15 2012 ./
drwxrwxr-x 7 hiromasa hiromasa   4096 11月 18 01:53 2012 ../
-rw-r--r-- 1 hiromasa hiromasa 608376  5月 20 11:12 2011 c3p0-0.9.1.1.jar
-rw-rw-r-- 1 hiromasa hiromasa 578548  8月  6 13:28 2012 quartz-all-2.1.6.jar
-rw-r--r-- 1 hiromasa hiromasa  25496  5月 19 20:22 2011 slf4j-api-1.6.1.jar
-rw-r--r-- 1 hiromasa hiromasa   9753  5月 19 21:02 2011 slf4j-log4j12-1.6.1.jar

quartz.sh

#/bin/sh

# setup
. /opt/daemon/bin/setenv.sh

RUN=net.maple4ever.daemon.QuartzDaemon

# check args
if [ $# -ne 1 ]
then
	echo "usage: quartz.sh [start|stop]"
	exit 1
fi

ret=9
case $1 in
	start )
		echo "starting daemon..."
		$SCRIPT_HOME/bin/jsvc \
			-pidfile $SCRIPT_HOME/tmp/$RUN.pid \
			-user $JSVC_USER \
			-home $JAVA_HOME \
			-cp $LIB_PATH \
			$RUN
		ret=$?
		;;
	stop )
		echo "stoping daemon..."
		$SCRIPT_HOME/bin/jsvc \
			-stop \
			-pidfile $SCRIPT_HOME/tmp/$RUN.pid \
			$RUN
		ret=$?
		;;
esac

exit $ret

手抜きシェルですが、./quartz.sh start|stop でデーモンの常駐制御ができます。

hiromasa 24923     1  0 09:48 ?        00:00:00 jsvc.exec -pidfile /opt/daemon/tmp/net.maple4ever.daemon.QuartzDaemon.pid -user hiromasa -home /usr/lib/jvm/java -cp /opt/groovy-2.0.5/embeddable/*:/opt/daemon/lib/commons-daemon/*:/opt/daemon/lib/log4j/*:/opt/daemon/lib/quartz/*:/opt/daemon/script:/opt/daemon/lib/twitter4j/*:/opt/daemon/lib/javamail/* net.maple4ever.daemon.QuartzDaemon
hiromasa 24924 24923  0 09:48 ?        00:00:06 jsvc.exec -pidfile /opt/daemon/tmp/net.maple4ever.daemon.QuartzDaemon.pid -user hiromasa -home /usr/lib/jvm/java -cp /opt/groovy-2.0.5/embeddable/*:/opt/daemon/lib/commons-daemon/*:/opt/daemon/lib/log4j/*:/opt/daemon/lib/quartz/*:/opt/daemon/script:/opt/daemon/lib/twitter4j/*:/opt/daemon/lib/javamail/* net.maple4ever.daemon.QuartzDaemon

このように jsvc プロセスが 2つできれば成功です。 🙂

commons-daemon と QuartzScheduler を使えば、cron などを使うのと違って簡単に無理なく状態遷移を制御できますので良いのではないかと思います。

さぁ、Amazon EC2 のマイクロインスタンスでどんなデーモン動かしましょう。 いろいろアイディアがでてきますが、ネットワークの中で生き続けるプログラムってやっぱり面白いですね。 😀

WordPress 徹底解析(カスタマイズとフィルターとアクション編)

週一回で始まった、WordPress 徹底解析シリーズ。 いきなり1週お休みをいただくというさすがぼく的な展開を見せていますが(ちょっと忙しかったのです・・・)、なんとかがんばって続けていきましょう。 🙂

前回まではこちら。

WordPress 徹底解析(PHP Development Tools インストール編)

また、テーマ制作中に WordPress 本体のソースを追うことも容易です。WordPress 本体のソースは WordPress のテクニックや考え方の宝庫です。

WordPress のコア(本体)ファイルを見ながら、WordPress で使えるテクニックと、おまけに PHP も面白く理解していこうというのが本シリーズの意図です。前回は準備としてコアのファイルが簡単にみれる環境を構築してみました。

WordPress のようなプログラマブルなアプリケーションを使いこなすには、そのコアのソースコードをみるのが、早く、はまらず、実装の間違えも少なくなると経験的に思います。 ソースコードを見るのは素早く作業を進めるための手段です。そのために、極力その手間を減らすために開発環境を構築しました。

あとは”とっかかり”が分かれば、、ということで今回は WordPress のカスタマイズを構成する要素について解説していきます。

WordPress のカスタマイズとは

まずは、このシリーズでいうところの “WordPress のカスタマイズ”について定義しましょう。

  1. 既存のテンプレートタグの動作や出力を変更する。(HTML の class 名追加や、出力条件、項目、表現の変更等)
  2. 管理画面に新しい機能を追加する、何かしらのタイミングで自分で記述した新しい処理を追加する。(投稿画面に新しい入力項目を追加し保存する、ポストしたタイミングで twitter に URL を投稿する等)
  3. ショートコードやウィジェットの追加。
  4. WordPress が標準で行う処理をまったく違うものに置き換えてしまう。(ログイン認証をユーザパスワード認証から OpenID や LDAP に変更する等)
  5. DB接続エラー画面の制御やメンテナンス中の画面、カスタマイズされた DB アクセスやキャッシュ制御を追加する。

ここでは上記を WordPress のコア(本体)ファイルを書き換えずに実現することをカスタマイズと呼ぶことにします。 WordPress では、そのためにいくつかの API や仕組みが用意されています。

  • フィルター
  • アクション
  • ショートコード、ウィジェットAPI
  • オーバーライドできる関数の上書き
  • ドロップインファイルの配置

今回から、それぞれの特徴と、その後にどこにどのように記述すれば動き出すかという部分を解説をしていきたいと思います。まずは、フィルター・アクションの紹介よりいってみましょう。

なお上記以外にも、テーマテンプレートファイル内で既存のテンプレートタグ(関数)を組み合わせて標準ではできない表現をすることなどもカスタマイズに入ると思います。 こちらについても大切な要素ですので PHP の知識とともに、追々フォローしていきたいと思います。

フィルターとアクション

フィルターとアクションとは、WordPress の動作を、事前に定義しておいたタイミングで処理の変更・追加を行うための仕組みの名称です。このことをフックと呼びます。フィルターフック、アクションフック、です。

フィルターフックは WordPress から入力されてくる値の変更を行い、アクションフックはそのタイミングにおける処理の追加を行います。 これらは、ぼくたちが利用するだけでなく、WordPress の内部処理においても積極的に使われているものです。

フィルターがコアで使われている代表例は、記事内に書いた顔文字変換  :D ←これとか、改行を二つ入れると <p> タグに変換されるフォーマット変換などです。 これらは入力されてきた記事の内容を出力時に値の変更を行っているイメージです。もちろん、変更できる対象は記事の内容にとどまらず、タイトルや HTML タグの属性まで多岐にわたります。

アクションの代表例はテンプレートファイルに記述する wp_head() や wp_footer() です。 これらを記述した部分にコアやプラグインから必要な HTML などが出力されているのはアクションフックの力です。 wp_head や wp_footer が動作したタイミングに合わせて、それぞれの処理が HTML タグを出力しています。

フィルター・アクションの仕組みはぼくたちにも開放されていますので、同様の動作をテーマやプラグインから追加できます。また、コアの定義で不必要なフックは削除することもできます。

気になるのは WordPress ではどんなタイミングのフックが配置されているかという部分・・・。先に申しますと、だいたい考え得るありとあらゆるところにあります。 なので、こんなことできたらいいなが代表例のような値の変更や処理の追加だった場合がフィルター・アクションの出番と覚えて差し支えないでしょう。 次回以降、その探し方を解説していきます。

さて、よくフィルターとアクションの差がよく分からないという声を聞きます。実はそれもその通り。 アクションを定義するコアの add_action 関数のコードを見てみると・・・

wp-includes/plugin.php

function add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1) {
    return add_filter($tag, $function_to_add, $priority, $accepted_args);
}

add_action はさらにフィルターを定義する add_filter で実装されていたりします。タイミングに対する処理という意味ではどちらも同じものなので内部的にはフィルターを使っているわけです。 違いは値の変更をするか、処理の追加をするかということになります。

それぞれに定義されたフックを呼び出すコアのコードは次のようなものです。

フィルター。 wp-includes/plugin.php::apply_filters 関数抜粋。

do {
    foreach( (array) current($wp_filter[$tag]) as $the_ )
        if ( !is_null($the_['function']) ){
            $args[1] = $value;
            $value = call_user_func_array($the_['function'], array_slice($args, 1, (int) $the_['accepted_args']));
        }
    }
} while ( next($wp_filter[$tag]) !== false );

アクション。 wp-includes/plugin.php::do_action 関数抜粋。

do {
    foreach ( (array) current($wp_filter[$tag]) as $the_ )
        if ( !is_null($the_['function']) )
            call_user_func_array($the_['function'], array_slice($args, 0, (int) $the_['accepted_args']));
} while ( next($wp_filter[$tag]) !== false );

フィルター・アクションともに $wp_”filter” 変数を使うほとんど同じコードになっています。

異なるのはフィルターのほうには $value があり、なんとなくループで同じフィルター処理に対して数珠つなぎで $value が渡っていくのが見て取れます。 これが、たとえばコアで設定されている記事出力に対するフィルターに、顔文字フィルター、HTML フォーマットフィルターなどと複数の設定が可能で、最終的に合成された結果を返す秘密です。

さて、いくつかプログラムのソースコードと関係する関数名がでてきました。 add_filter、apply_filter と add_action、do_action。前から、フィルターの登録・適応とアクションの登録・適応するための関数になります。次回はこの名前をヒントに、フィルター・アクションの実際やそのタイミングの探し方を見ていくことにしましょう。

このシリーズはブログ記事なので、いきなり新しい言葉がでてきてちょっとよく分からなかった方もいるかもしれません。

ぼくも共著させていただいている書籍のほうでは、WordPress サイト制作の基本から応用まで言葉も含めて解説しておりますので良ければ手にとっていただければと思います。

さて、昔話になりますが、ぼくが小学生くらいだったときは、ソースコードとその考え方をおもしろく筆者の思考の流れとともに解説する月刊誌や技術書が沢山ありました。 きっと、同年代の方ではそのような雑誌で育った方も多いかと思います。

もしかすると、ぼくが書くブログや書籍はそんなみんなが忘れかけた、知らない方には新しい(?)表現が垣間見られてるんじゃないかな、、と最近思います。

いまだに大切にしている 1991 年の技術書があります。やっぱり今読んでも面白いのです。

ぼくはコンピュータにさわり始めたのが早いので、マイコン世代の方より少し若輩者ではありますが、本来楽しいはずであるソフトウェアの世界をお伝えすべく、、次回もお楽しみに。 🙂

WordPress 徹底解析(PHP Development Tools インストール編)

WordPress のテーマなど PHP を記述するアプリケーションを使う場合は、Eclipse などの IDE を使うと非常に便利です。

特に PHP と近い位置でテーマの制作をする WordPress では IDE が持つ PHP の解析機能の助けを借りると、テンプレートファイルへのテンプレートタグの記述や、エラーチェック、不具合が起きたときの解析、functions.php やプラグインの記述が非常に楽になります。

また、テーマ制作中に WordPress 本体のソースを追うことも容易です。WordPress 本体のソースは WordPress のテクニックや考え方の宝庫です。

WordPress デザインワークブック」でもいくつか WordPress コアのソースを紹介しています。た とえばカスタム分類の解説では、

“「投稿」や「固定ページ」も、本体でカスタム投稿と同様に register_post_type 関数で登録されている”

なんてことをコアのコードとともに紹介しています。じゃーもしかしてカテゴリやタグもカスタム分類と同じ register_taxnomy ? …正解です。

WordPress デザインワークブックもまた、 IDE で各テンプレートタグなどをコアから追いながら執筆しています。考え方ベースで手順も優しく書いていて面白い本と思いますので、よければ手に取って見てください。 🙂

さてというわけで、IDE はこういったソースコードの調査や記述を強力に支援してくれます。

IDE とは

IDE(統合開発環境)はテキストエディタと異なり、記述されたプログラム言語を常に解析しながら動きます。常にプロジェクト配下のソース構文木を意識しているため、シンタックスエラーチェックはもちろん、辞書を必要としないコード補完や、適切な関数への定義ジャンプ、リファクタリングと呼ばれる関数・変数名の変更などが行えます。

たまに横にファイルツリーがあるテキストエディタが統合開発環境として紹介されていますが、完全な言語解析機を持たないテキストエディタと IDE は本質的に異なるソフトウェアです。

たとえば、Eclipse の PHP Development Tools では次のような機能を持ちます。 NetBeans などでも同様のことが可能でしょう。

構文エラーチェック。

リアルタイムに構文エラーや変数初期化に関するワーニングなどが出力されます。 ちなみに、Eclipse では PHP のような動的型付けスクリプト言語の解析に、DLTK(Dynamic Language Tool Kit)という仕組みが用いられています。

コード補完機能。

事前生成タグやスニペット的なものを使っているわけではないので、常にプロジェクトのファイルの最新を追いかけて補完できます。

定義の関数がどこにあるか IDE は知っているので、その場に PHPDoc などが出力できます。

さらに、関数の上で F3 (Fn + F3) などとするとそこの関数にすっとんで関数を読んで解析ができます。ぼくはこれができないと始まりません 🙂

その他、変数間接参照からの定義ジャンプができるなど、動的型付け言語の上でもさすがと思わせる機能がたくさんついています。(動的型付け言語はプログラムの形が実行時に変わるためこういった処理がなかなか難しい)

てなかんじで、便利そうな IDE ですがちょっとヘビーで使ってない方もいるかもしれません。

[tegaki]別に必要ない時は使わなければいい![/tegaki]

ってわけで、Eclipse PHP Development Tools(PDT) は必要な時だけ使うようにもできています。普段は Dreamweaver やテキストエディタで制作を進めることもできます。

Eclipse ではファイルのかたまりをプロジェクトという単位で管理しますが、PDT ではプロジェクトの位置を任意の場所で指定できます。 つまり、製作中のファイル群に対して、必要になったときだけ Eclipse を起動して使うことができます。

ではそんな Eclipse のインストール方法を紹介します。 なんと Mac、Linux、Windows 対応のインストール手順。 Windows は若干手抜きで。 Solaris、AIX、HP-UX も入れますか?(笑)

Java の導入

Eclipse は Java プラットフォーム上で動作するアプリケーションです。 Java を入れる必要がありますが、Mac OS X (Lion / Mountain Lion)では Java はのちほど Eclipse 起動時に自動的に入るようにアナウンスされるので操作不要です。

Linux の方は Sun(Oracle) Java か OpenJDK かを入れてください。 Ubuntu の場合は端末から以下のようになります。

$ sudo apt-get install openjdk-7-jdk

Windows の方は適当にいれてください(笑)←すぐ分かりそうなので、、

ちなみに、Java は Web で使われる(使われてない気もする)アプレットでたまに脆弱性がでるので、ランタイムと一緒に導入されるブラウザのプラグインは切っておいた方がいいかもしれません。

Eclipse の導入

Eclipse はポータブルにできていますので、導入はファイルをダウンロードして適当な場所に展開すれば終わりです。 Mac でのスクリーンショットを元に紹介します。

まずは以下から Eclipse をダウンロードします。 実は PHP を扱う Eclipse ディストリビューションは用意されていませんので、最初から便利なプラグインがいろいろ入っている Eclipse IDE for Java EE Developers を選択し、後から PDT をプラグインの形でインストールします。

Eclipse Downloads

Eclipse IDE for Java EE Developers

Mac OS Xの場合は Cocoa 64bitを、Linux の場合は GTK 版お使いのカーネルビルドを、Windows の場合も同様に 32/64bit を選択します。上記の URL はブラウザのエージェントみているようですので、各 OS に合わせたダウンロードサイトがでてきます。

ちなみに、Eclipse は Java のアプリケーションですが、NetBeans などと異なり各 OS のネイティブで動作する SWT というライブラリの上で動作するため、プラットフォームツールキット(GUI)との親和性が高い綺麗な画面が表示されます。

ダウンロードしたアーカイブファイルを任意の場所で展開します。 展開後は「eclipse 」というフォルダが作成されますが、フォルダ名をアーカイブファイルと同じバージョン表記がある名前にしておくと便利です。 Eclipse は手軽にいくつでもインストールすることができます。

展開したフォルダを OS のアプリケーションフォルダなどに格納します。

Eclipse には1つのアプリケーションファイルをマルチユーザで使い、ユーザによりプラグインをわけるようなモードもあるのですが、プラグインによってはうまく動作しないこともあるようです。

とりあえずぼくは、Mac の場合は /Application 下に、Linux の場合は /opt に置きたいところですが ~/apps などの下に置いています。Windows も \Develop などを作成して、その下に置くといいでしょう。 レジストリなどに設定をかくはありませんので、そのままコピーすれば別環境にもっていくことができます。

Mac の /Application(アプリケーション)の下に、フォルダ「eclipse-jee-juno-SR1-macosx-cocoa-x86_64」を置いたの図。

Linux の ~/apps の下などに配置します。

次に、日本語ランゲージパックを導入します。 英語のままで良い方はとばしてOKです。

Eclipse 日本語化言語パック (サードパーティ版)

Eclipse IDE for Java EE Developers

NLpackja-eclipse-jee-juno-blancofw20120628.zip

上記からダウンロードして展開したファイルを、先ほどの Eclipse フォルダの下にある「dropins」以下に「nlpack」というフォルダを作成して配置します。

配置は dropins/nlpack/eclpse/plugins… のようになります。

これでインストールはおしまいです。

Eclipse の起動はフォルダの下にある、eclipse 実行ファイルを起動すればOKです。 Mac の場合は Eclipse.app、Linux は eclipse、Windows は eclipse.exe をダブルクリックしましょう。

Mac 及び Windows の場合は、許可のない実行ファイルということで警告がでます。

Windows の場合はダイアログから許可を行い、Mac の場合は control(command ではない)を押しながら右クリック「開く」します。

これで起動です。 🙂

最初にワークスペースの位置をきいてきますので、(実は PDT ではほとんど使わないのですが)そのまま OKします。「この選択をデフォルト~」にチェックいれておくと便利です。

Mac 版。 ようこそをばってんで閉じます。

Windows 版。(ばってんした後)

Linux 版。(既に動作中のスクリーンショット)

それぞれ OS ネイティブで画面が描かれているのが分かります。 これが SWT の威力! 😀

Eclipse の設定と PDT の導入

起動したらとりあえずフォントとエンコードの設定をします。

Mac の場合はメニューの Eclipse -> 環境設定。 Linux / Windows の場合は、ウインドウ->設定より各種設定ができます。Eclipse は設定が多いので検索がきくようになっています。

Windows と Mac はなぜかデフォルト文字エンコードが Sfhit_JIS になるので検索窓に encode といれて「テキストファイルのエンコード」を「UTF-8」に。

フォント設定は font と入れるとでてくる画面でいろいろ設定できます。

BASIC ツリーの下のテキストフォント、テキスト選択フォントを変更するとテキストエディタ部分に関しては、そこがデフォルトして使われ全体的に変わります。

次に PHP Development Tools プラグインの追加を行います。これを導入することにより、Eclipse で PHP が扱えるようになります。といってもメニューからできるので簡単です。

ここからは各 OS 共通です。 メニューのヘルプ->新規ソフトウェアのインストールを選択します。

作業対象をドロップダウンから「http://download.eclipse.org/releases/juno」とし、その下のテキストボックスに「PHP」と入力してエンターしてください。しばらくすると選択がでてきますので、PHP Development Tools(PDT) SDK Feature を選択して、あとは次へ次へで完了です。

このように Eclipse はネットワークを介してプラグインなどのパッケージを導入することができます。

同様に、ヘルプ->Eclipse マーケットプレースからサードパーティーのパッケージをインストールすることができます。 たとえば、Git(EGit)や Subversion(Subclipse)、JS/jQuery(JSDT jQuery)サポートなどなどいろいろあります。:)

PDT が入ったら、ウインドウ->パースペクティブを開く->その他から「PHP」を選択してください。 PHP の作業する上で便利な画面構成になります。 Eclipse では、画面上の各ペインをビューとよび、ビューの配置状況をパースペクティブとなり、いくつも記憶することができます。 PHP パースペクティブは、事前に PHP に便利なビューを集めたものになります。

PDT に PHP プロジェクトを追加する

Eclipse では、製作しているアプリケーションのファイル群をプロジェクトという単位で扱います。 ここでは、既に制作中の WordPress サイトがあるものとして、それを PDT のプロジェクトにする方法を紹介します。 この使い方をすることで、必要な時だけ Eclipse でファイルを操作することができます。

まず、PHP パースペクティブ左に配置された PHP Explorer ビューを右クリックして、New -> プロジェクトを選択します。

プロジェクト作成ウイザードが現れますので、PHP で検索して「PHP Project」を選択します。

ここからがキモです。

Project name: に任意の名前をつけて、Contents を「Create project at existing location (from existing source)」として「Browse…」で WordPress の置かれたフォルダを指定してあげます。 既にあるソースからプロジェクト作成、ですね。

おめでとうございます。制作中のソースがプロジェクトになりました。  🙂

Eclipse は賢いので起動しながら別のテキストエディタなどでファイルをいじっても、適切に追従してきます。

PHP Explorer ビューからは編集するファイルを選択ができ、問題ビューにはエラー表示がでます。

各ビューに配置されたボタンをいろいろいじってみるとだいたい分かると思います。また、PHP Explorer のファイル右クリックから様々なファイル操作ができます。ちょっと古いですが以下も見てみてください。各種、使い方を書いています。

Eclipse PDT + XAMPP で WordPress の開発環境をつくる (3)

ここからは通常のテキストエディタにない統合環境特有の編集機能をみていきます。 難しい操作はありませんので、ぜひ手になじませてください。

ソースの中へ

インストール後ぜひ、ご自分のつくったテンプレートファイルで使われているテンプレートタグ(PHP の関数)の上で、F3 を押してみてください。(Mac 標準や最近の PC ではファンクションキーがマルチ側にあたっている場合があるので、その場合は Fn + F3) 定義部分にとべます。

これを使うことでプログラムの中を自由にどんどん追っていけるのが分かると思います。

WordPress などの CMS のテーマファイルをつくる場合は、コアのプログラムがよめると圧倒的に有利で不具合解決も早いです。IDE は定義ジャンプや複雑な条件がつけられる検索機能などが、これらの手助けをしてくれます。

さて、WordPress でなにかの実現の仕方が分からなかった場合、さらっと似たようなテンプレートタグのソースをみてみましょう。操作はそのテンプレートタグの上で F3 を押すだけ。きっと答えはそこにあります。コアたってただの PHP。そして何も難しいことかいてません。 😀

というわけで、このブログで週に一回「WordPress 徹底解析」シリーズ開始します。WordPress や PHP の考え方を知り、何にでも対応できるようにできるようになりましょうぞ。

まずは、Eclipse でも NetBeans でも Sublime Text2 の ctag でもソースの中を「飛べる」ようにしておいていただければ。 必要なのです。 🙂

Happy Hacking!