Groovy + Spring Boot + SWT でクライアントアプリケーションをつくる

G* Advent Calendar 2015 9日目です!

昨日は saba1024 さん「[Groovy] MongoDBを簡単に扱えるイケてる言語Groovy -Groovyの応用編-」でした!


 

職場などで業務改善的なツールをつくりたくなる場合がありますが、案外みんなの PC にスクリプト言語を動かす環境がなかったりします。そんな時は Groovy ! Java の現場であればそのままつくった jar を渡せますし、そうでなくても launch4j などで JRE ごと渡すことができます。

今回は「Groovy + Spring Boot + SWT」という組み合わせで、手軽に高速に GUI Groovy アプリケーションをつくる骨格を紹介してみたいと思います。

珍しい組み合わせかと思いますが、Spring Boot のオートコンフィグレーションと、後述する spring-loaded によるホットデプロイ(GUI 再起動無しで処理を変更できる)と Groovy によるプログラミングの組み合わせは、かなり高速に開発を進めることができると思います。

プロジェクトの構成は以下のような感じになります。

groovy-swt-02

まずは、build.gradle で Spring Boot と SWT を定義してあげます。

build.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.3.0.RELEASE'
    }
}

apply plugin: 'groovy'
apply plugin: 'spring-boot'

repositories {
    mavenCentral()
    maven { url 'http://maven-eclipse.github.io/maven' }
}

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.5'
    compile 'org.springframework.boot:spring-boot-starter'
    compile "org.eclipse.swt:org.eclipse.swt.win32.win32.x86:4.5.1"
}

springBoot {
    mainClass = 'sample.Application'
}

SWT は Windows x86 のものを選択していますが、他の環境の定義は次の通りです。

    // The Standard Widget Toolkit(SWT)
    // System.getProperty('os.name').toLowerCase().split()[0]
    // System.getProperty("os.arch")
    // 
    // Windows x86
    // compile "org.eclipse.swt:org.eclipse.swt.win32.win32.x86:4.5.1"
    // Windows x64
    // compile 'org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:4.5.1'
    // Linux GTK+ x86
    // compile 'org.eclipse.swt:org.eclipse.swt.gtk.linux.x86:4.5.1'
    // Linux GTK+ x64
    // compile 'org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:4.5.1'
    // OS X Cocoa x64
    // compile 'org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:4.5.1'

次に Spring Boot の規約に従って(必要なら)ロガー(logback-spring.xml)と Application.yml を定義します。

src/main/resources/logback-spring.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <logger name="sample" level="DEBUG"/>
</configuration>

src/main/resources/Application.yml

setting:
    defaultPath: C:\Users

Application.yml は Spring Boot の設定も記述できますが、作成するアプリケーションで外だししたい設定なども書けます。これを読むための、ApplicationSetting は次のようになります。

src/main/groovy/ApplicationSetting.groovy

package sample;

import org.springframework.boot.context.properties.ConfigurationProperties
import org.springframework.stereotype.Component

@Component
@ConfigurationProperties(prefix = "setting")
public class ApplicationSetting {
    String defaultPath
}

Java でかくと Setter/Getter が必要ですが、Groovy ならこれだけです。.yml のキーと変数名を合わせれば勝手に Spring Boot がバインドしてくれます。

プログラムの起動点となる Application は次のようになります。

src/main/groovy/Application.groovy

package sample

import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.SpringApplication
import sample.gui.Controller

@SpringBootApplication
class Application {

    @Autowired
    Controller controller

    static void main(args) {
        SpringApplication.run(Application.class, args).withCloseable {
            it.getBean(Application.class).controller.start()
        }
    }
}

通常の Java アプリケーションと同様に main を起動してあげると、Spring Boot が main があるパッケージ配下のコンポーネントを自動でスキャンしてクラスロードしてくれます。 @Autowired で GUI の Controller をインジェクションして main から呼び出しました。

呼び出される gui.Controller は次のようなものです。

src/main/groovy/gui/Controller.groovy

package sample.gui

import org.slf4j.*
import org.eclipse.swt.*
import org.eclipse.swt.events.SelectionListener
import org.eclipse.swt.graphics.*
import org.eclipse.swt.layout.*
import org.eclipse.swt.widgets.*
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.stereotype.Component
import sample.ApplicationSetting
import sample.service.Convert

@Component
class Controller {

    static final logger = LoggerFactory.getLogger(Controller.class);

    @Autowired
    Convert convert

    @Autowired
    ApplicationSetting setting

    Display display
    Shell shell
    ToolItem open
    Table list

    def private init() {
        // Window Setting
        display = new Display()
        shell = new Shell(
            display, SWT.TITLE | SWT.RESIZE | SWT.MIN | SWT.MAX | SWT.CLOSE)
        shell.setSize(640, 480)
        shell.setText("Sample Application")
        shell.setLayout(new GridLayout())
        // Application Icon
        shell.setImage(new Image(display, this.getClass().getResourceAsStream(
            "/images/icon/calculator.32x32.png")))

        // Toolbar
        def toolbar = new ToolBar(shell, SWT.FLAT | SWT.RIGHT)
        // Open
        open = new ToolItem(toolbar, SWT.PUSH)
        open.setText('Open')
        open.setImage(new Image(display, this.getClass().getResourceAsStream(
            "/images/icon/start.32x32.png")))
        // Toolbar Size
        toolbar.pack()

        // List Table
        list = new Table(shell, SWT.FULL_SELECTION | SWT.BORDER)
        list.setHeaderVisible(true)
        list.setLayoutData(new GridData(GridData.FILL_BOTH))
        list.setFocus()

        // Event Listener
        open.addSelectionListener([
            widgetSelected : {  e ->
                def f = new FileDialog(shell, SWT.OPEN)
                f.setFilterPath(setting.defaultPath);
                f.setFilterExtensions(["*.csv"] as String[])
                def login = f.open()
                def message = convert.input(login);
                def box = new MessageBox(shell, SWT.OK | SWT.OK)
                box.setMessage(message)
                box.open()
            }
        ] as SelectionListener)
 
        shell.open()
    }

    public void loop() {
        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) {
                display.sleep();
            }
        }
        display.dispose()
    }

    def start() {
        try {
            init()
            loop()
        } catch(Exception e) {
            e.printStackTrace()
            def box = new MessageBox(shell, SWT.OK | SWT.ABORT)
            box.setMessage("例外が発生しました。\n" + e.message)
            box.open()
        }
    }
}

SWT の GUI 作成とメインイベントループがあります。

ソース先頭で、サービスクラスにあたる service.Convert と先ほど Application.yml を読むためにつくった ApplicationSetting を DI しています。

    @Autowired
    Convert convert

    @Autowired
    ApplicationSetting setting

ボタンを押したときのイベントでこれらを利用しています。

        // Event Listener
        open.addSelectionListener([
            widgetSelected : {  e ->
                def f = new FileDialog(shell, SWT.OPEN)
                f.setFilterPath(setting.defaultPath);
                f.setFilterExtensions(["*.csv"] as String[])
                def login = f.open()
                def message = convert.input(login);
                def box = new MessageBox(shell, SWT.OK | SWT.OK)
                box.setMessage(message)
                box.open()
            }
        ] as SelectionListener)

サービスクラスはとりあえず。

src/main/groovy/service/Convert.groovy

package sample.service;

import java.io.File;

import org.springframework.stereotype.Component;

@Component
public class Convert {
    def input(file) {
        return "converted!" 
    }
}

というわけで、Application.groovy を IDE から実行するか、./gradlew bootRun するとアプリケーションが起動します。

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v1.3.0.RELEASE)

2015-12-09 00:25:31.353  INFO 6560 --- [           main] sample.Application 

groovy-swt-01

さて、ここで大技です。 spring-loaded を実行時に javaagent で読み込むことで、実行中に修正したクラスをリロードできるようになります。 プロジェクトサイトから jar をダウンロードし、アプリケーション実行時の JVM 引数に以下を加えます。

-javaagent:${project_loc:template-springboot-swt}/lib/springloaded-1.2.5.RELEASE.jar -noverify

“${project_loc:template-springboot-swt}” は Eclipse 的なプロジェクトホームの指定ですので、適宜変更してください。

groovy-swt-04

なお、Eclipse で実行する場合は Application.groovy から Run してください。./gradle bootRun だとリロードされません。これは、Eclipse の場合、自動コンパイルの .class ファイルを置く先が bin/ ディレクトリ配下となり、bootRun した場合は build/ 配下の class ファイルで実行され、ファイルの更新がされないためです。

というわけで、spring-loaded ですが、やってみると異常に快適です。 GUI をつくる場合、対象の処理にたどり着くまでの操作が長くかかることがありますが、spring-loaded を入れておくとリトライが簡単で、なんだか世界が変わります。 🙂

その他、Spring Boot 上であると、H2 の組み込み DB や、JPA や GORM などの O/R マッパーも、gradle の定義だけでオートコンフィグレーションされてすぐ使えるようになりますので、非常に便利です。

今回のサンプルでは、サービスクラスで CSV を H2 に読んで GORM で抽出をかけたかったのですが、出張先にて機材トラブルにより間に合いませんでした。ごめんなさい。。

以上、あまり手間をかけず、ゆるいフレームワーク規約で自由気ままにツールなどの GUI をつくりたいなんて時に、良ければお試しください。

最後に、Apache Groovy おめでとうございます! 今年も Groovy にずいぶん助けてもらいました。 🙂

Keep on Groovy-ing!

Eclipse EGit の使い方(2/2)

前回に続き、EGit の使い方です。

目次

  1. 導入
  2. ローカルリポジトリの作成
  3. ファイル操作
  4. リモートリポジトリに接続
  5. ローカルブランチの作成
  6. リベースインタラクティブ
  7. ブランチからのマージ1
  8. ブランチからのマージ2
  9. コンフリクトの解消
  10. リベース
  11. コミットコメント修正
  12. コミットリセット
  13. リバートコミット

このページでは、7〜13までを記載しています。

ブランチからのマージ1

develp ローカルブランチのコミットを origin/master に接続している master ブランチにマージしてプッシュする操作です。この操作では、devel に行ったコミット操作が master に統合されます。

develp ローカルブランチは次のようになっています。

egit-rebasei05

1. master ブランチにスイッチします。

egit-margea01

2. プロジェクト右クリックから、Team -> Marge を選択します。

egit-margea02

3. devel ブランチを指定し Merge ボタンを押下すると、master ブランチに devel ブランチのコミットがマージされます。devel と master でコンフリクトがなく、Fast forward option で、If a fast-foward, only update the branch pointer を選択しているため、master のおしりに devel のコミットが結合されます。

egit-margea03

egit-margea04

4. リモートリポジトリにプッシュされていないコミットがあると↑印で分かります。 Team -> Push to Upstream でプッシュします。( devel ブランチで行った rebase -i で修正したコミットはプッシュされていないのが分かります)

egit-margea05

egit-margea07

egit-margea08

b03

5. 不要になったローカルブランチは、Git Repository View から右クリック Delete Branch で削除できます。

egit-margea09

ブランチからのマージ2

develp ローカルブランチのコミットを origin/master に接続している master ブランチにSquash マージしてプッシュする操作です。この操作では、devel ブランチに行ったコミット全てをひとつにまとめて master にコミットできます。

1. Team -> Swicth To -> New Branch から devel2 ローカルブランチを作成します。

egit-margeb01

2. devel2 で作業を行い、(恥ずかしい)コミットをいれます。

egit-margeb02

3. Team -> Swich To -> master から master ブランチに切り替えます。

egit-margea03

4. Team -> Merge を選択します。

egit-margeb03

5. devel2 ブランチを選択し、Merge options で Squash を選択し、Merge ボタンを押下すると、ソースコードがマージされます。(コミットはされません)

egit-margeb04

egit-margeb05

egit-margeb06

6. マージされたソースを master ブランチにコミットすると、devel2 の修正が新しいコミットとして作成できます。なお、Commit Changes ダイアログでは Commit and Push を押下すると、コミット後自動的にリモートブランチにプッシュが行えます。

egit-margeb07

egit-margeb08

b04

コンフリクトの解消

マージやプル操作などで、ソースに衝突が発生した場合は、次の手順でマージを行います。

master からブランチした devel3 ローカルブランチで作業中に、起点とした master に別な修正がかかりコンフリクトした例です。

egit-confrict01

master にスイッチして devel3 をマージしたところ衝突が起きました。該当のモジュールに赤印がつき、プロジェクトのマーカーに Conficts がつきます。

egit-confrict02

egit-confrict03

1. 衝突したモジュールを右クリックし、Maege Tool を選択します。

egit-confrict04

2. Select a Merge Mode で Use HEAD を選択します。

egit-confrict05

3. Merge Tool でソースコードのマージを解消します。

egit-confrict06

4. マージして赤くなっているモジュールを右クリックから、Team -> Add to Index を選択し、インデックスに戻してあげると、プロジェクトのマーカーが Merged に変わります。

egit-confrict07

egit-confrict08

5. コミットを行います。(マージコミットが作成されます)

egit-confrict09

egit-confrict10

b05

リベース

ローカルブランチで作業中に、ブランチの起点となったコミットを動かし、なるべくマージ(コミット)しないようにリベースする手順です。

master からブランチしたローカルブランチの devel4 をリベースし、最新の master を起点に追従します。

1. devel4 で作業中の master にリベースしたいタイミングで、Team -> Rebase を選択します。

egit-rebase01

2. master ブランチを選択し、Rebase を押下します。

egit-rebase02

3. rebase 時に不運にもソースコードにコンフリクトが起きた場合は、Start Merge Tool to resolve conflicts を選択し OK ボタンを押下します。

egit-rebase03

4. コンフリクトを解消するとマージ印がつきます。プロジェクトのマーカーは Rebase interractive になっており、まだ rebase 操作中であることが分かります。

egit-rebase04

5. Team -> Rebase -> Continue Rebase を選択し、全ての衝突を解消すると、リベースが完了します。

egit-rebase05

egit-rebase06

コミットコメント修正

コミットした直前のコミットコメントは修正できます。

egit-amend01

1. モジュールに修正をかけない状態で、再びコミットを行おうとすると、No files to commit ダイアログが表示されるので、はいを押下します。

egit-amend02

2. コミットダイアログが表示されるので、コミットコメントを修正し、Commit を押下すると直前のコミットコメントが修正されます。

egit-amend03

egit-amend04

コミットリセット

プッシュ前であれば、コミットを取り消す(HEADを移動させる)ことができます。

egit-reset01

1. ヒストリービューからいらないコミットの前(HEADにしたい)のコミットにカーソルを合わせて、Reset -> Mixed を選択すると、そこまでのコミットがなかったことになります。(Mixed を選択した場合、ワーキングディレクトリのファイルの内容はそのままになります。ファイルの内容も抹消したい場合は Hard を選択します)

egit-reset02

egit-reset03

egit-reset04

リバートコミット

プッシュしてしまったコミットを取り消すには、打ち消しのコミットを入れてプッシュします。

機能G追加のコミットが不要でしたが、リモートリポジトリにプッシュしてしまったので取り消します。

b06

egit-revert01

1. ヒストリービューから、取り消したいコミットを右クリックして Revert Commit を選択すると、取り消しとなるリバートコミットが行われます。

egit-revert02

egit-revert03

3. リバーとコミットをプッシュします。

egit-revert04

b07

以上、Egit の操作系の紹介でした。(実はプルを書き忘れていたりしますがそのうちなおしておきます…)

EGit ではその他にも、stash とかタグうちとか、ブランチ同士の比較なども同じような操作でできますので試してがってん。3.3.1 にて自分がやりそうな操作はひと通りできるようになっているようです。(3.4 も後少しで Eclipse Luna とともにリリースされるハズです)

気になっているのが JGit のコマンドラインインターフェースがあるような雰囲気なのですが、どうやって使うんでしょうか。

…てなわけで、オチがないので滝にうたれてきます。

Eclipse EGit の使い方(1/2)

Eclipse から Git 操作を行う、EGit の使い方についてまとめてみました。

この記事は 2014/3/25 にリリースされた EGit 3.3.1 を使い、Ubuntu もしくは Windows で操作しています。(たぶん Mac でも大丈夫です)

リポジトリを破壊したり、ファイルが多くあると遅くなっていたりしていたお騒がせな EGit でしたが、現在の所、通常の操作では問題なくなったように思います。

目次

  1. 導入
  2. ローカルリポジトリの作成
  3. ファイル操作
  4. リモートリポジトリに接続
  5. ローカルブランチの作成
  6. リベースインタラクティブ
  7. ブランチからのマージ1
  8. ブランチからのマージ2
  9. コンフリクトの解消
  10. リベース
  11. コミットコメント修正
  12. コミットリセット
  13. リバートコミット

このページでは、1〜6までを記載しています。(続きは力尽きたので次回…

導入

EGit は Eclipse 用の Git プラグインです。

JavaEE 版の Eclipse Kepler であれば、初期状態でバージョン 3.2 が導入されていますが、不具合の修正も多数ありますので、以下のアップデートサイトを登録し 3.3.1 の最新版をいれたほうが良いでしょう。

EGit – Download

To install via one of the update site URLs listed below, copy and paste it into the “Help > Install new software” dialog.

EGit can be installed in the following ways:

Main Update Site: http://download.eclipse.org/egit/updates (Recommended)

ヘルプ->新規ソフトウェアのインストールに、アップデートサイトを登録し、Eclipse Git Team Provider と JGit を導入します。

egit-install01

なお、EGit は Java の Git 実装である JGit を使って動きますので、別途 Git のコマンドラインツールなどを入れる必要はないです。

導入が完了すると、以下のビューが使えるようになります。

egit-install02

Git Repositories からリポジトリを操作するので出しておくと便利でしょう。

ローカルリポジトリの作成

新規プロジェクトを作成し、そのモジュールを Git のローカルリポジトリで管理するまでの手順です。既存のプロジェクトでも 2. 以降の手順で Git 管理下におくことができます。

1. Eclipse のプロジェクトを作成します。

egit-init01

2. プロジェクトを右クリックし、Team からプロジェクトの共有を選択します。

egit-init02

3. Git を選択します。

egit-init03

4. Use or create repositoru in parent folder of project にチェックを入れ、Create Repository をクリックします。

# Creation of reoisitories  in parent folder the Eclipse workspace は非推奨。ワークスペース上に Git のファイルがあると Eclipse が遅くなるのでということのようです。(が、特に問題無さそうなので自分はこちらを使っています)

egit-init04

5. ワークスペースと同じフォルダに .git リポジトリが作成されるので、完了をクリックします。

egit-init05

6. プロジェクト右クリックから、Team -> Commit をクリックします。

egit-init06

7. コミットダイアログが表示されます。 が、コミットの必要がない Eclipse の設定ファイルなどがあるので、いったんキャンセルします。

egit-init07

9. Eclipse 標準のフィルターだと隠しファイルが見えないため、見えるようにビューを一度カスタマイズします。

egit-init08

10. フィルターから .* リソースのチェックを外します。

egit-init09

11. 隠しファイルが見えるようになったので、コミットが不要なファイルを右クリックし、Team -> Ignore を指定し、Git の管理下から外します。(.gitignore が編集されます)

egit-init10

egit-init11

12. 管理するファイルが決まったので、再び Team -> Commit を選択します。

egit-init12

13. コミットダイアログで、コミット(インデックス)するファイルにチェックをつけ、コミットボタンを押下します。ヒストリービューからコミットの履歴を見ることができます。

egit-init13

egit-init14

ファイル操作

コミット後に修正を行ったファイルには > 印がつきます。

egit-edit01

コミット(HEAD)に戻したい(上書きしたい)時は、ファイル右クリック->置換->HEAD Revision を選択します。

egit-edit02

HEAD と比較したい場合は、比較-> HEAD Revision を選択します。(このへんの操作は Subclipse などと同様です)

egit-edit03

egit-edit04

ファイルの追加や削除は、Eclipse の右クリックの操作から行なってください。(OS からファイル操作をすると Git のインデックスがおかしなことになります)

ファイルの移動もドラッグアンドドロップを使うことで、Git が追従してきます。

egit-edit05

egit-edit06

リモートリポジトリへの接続

作成したローカルリポジトリを、リモートリポジトリに接続します。(ここでは Bitbucket のプライベートリポジトリに接続します)

1. ベアリポジトリを作成します。(Bitbucket 上に egit-test を作成しました)

b01

2. Git Repository ビューから、ローカルリポジトリの Remotes 指定し、Create Remote を押下します。

egit-remote01

3. Remote name を origin とし、Configure fetch を指定して OK ボタンを押下します。

egit-remote02

5. リモートリポジトリに 1. で作成したベアリポジトリを指定すると、Remotes が作成されます。

egit-remote03

egit-remote04

6. master ブランチをリモートと同期するために、ローカルブランチの master を選択し、Configure Branch を押下します。

egit-remote05

7. Remote に origin を、Upstream Branch を refs/heads/master とし、リモートリポジトリを追跡ブランチとして指定すると、Remote Traking が作成されます。

egit-remote06

egit-remote07

8. プロジェクトを右クリックし、Team -> Push to Upstream を押下し、リモートリポジトリにローカルリポジトリをプッシュします。

egit-remote08

b02

ローカルブランチの作成

Git の利点の一つは、ローカルブランチを手軽に作成でき、自分のタイミングで好きなようにコミット操作ができることです。それはドラクエのセーブに似ています。保存域は3箇所と言わず無限に(←真面目さがなくなってきた…

EGit でのローカルブランチの作成操作は次のようになります。

1. プロジェクト右クリックから Team -> Swicth To -> New Branch を選択します。

egit-branch01

2. Brach name を指定します。(ここでは devel ブランチにしました) master からブランチを作成したので、ヒストリーをみると、devel、master、origin/master の位置が一致しているのが分かります。

egit-branch02

egit-branch03

3. ワーキングディレクトリがdevel ローカルブランチにスイッチしたので、好きなように(恥ずかしい)コミットを入れながら、作業をしていきます。

egit-branch04

コミットを改変する場合

ふと次の日見た devel のコミットは、やっぱりあんまりだったので、コミットを改変して正しいものにするなどの手順です(?)。(rebase -i)

1. ヒストリーから親にするコミットを右クリックし、Rebase Interactive を押下します。プロジェクトのマーカーが Rebase Interactive に変わります。

egit-rebasei01

egit-rebasei02

2. Git Interractive Rebase ビューを開き、編集したいコミットに対してそれぞれの操作を指定して Start を押下します。(ここでは、2つのコミットを SQUASH 指定し、コミットをひとつにまとめています)

egit-rebasei03

3. 本コミットのメッセージを指定し、OK ボタンを押下すると、コミットが指定通りに改変されます。

egit-rebasei04

egit-rebasei05

というわけで次回は、できあがった devel を master にマージしてリモートリポジトリにプッシュする「ブランチからのマージ1」から書きます。

続く…

Ubuntu 13.04 リリース!

半年に一度のお楽しみ、Unbutu の 13.04 がリリースされました。 😀

日本語 Remix を待ちきれずに、早速愛機 ThinkPad T420s にインストールしてみました。 もともと Ubuntu 12.10 がのっていた機械ですが、アップグレードせずに、クリーンインストールしております。

インストールプロセスでは特に困ったこともなく、いつも通りそのままブートされ、無線LAN などやトラックポインタなどのデバイスもそのまま使えるようになりました。

ubuntu1304-01

利用を開始して最初に気がついたのが、Super(Win) + S のワークスペーススイッチャーが効かないこと。

どうやらデフォルトで仮想デスクトップが無効になったようです。システム設定->外観から「ワークスペースを有効にする」にチェックをつけてあげます。

ubuntu1304-02

とりゃ。でてきよった。 🙂

ubuntu1304-03

ワークスペース切り替え Win + S と Alt + Tab のタスクスイッチャーの切り替えはいつもながらかなり強力です。 🙂

ちなみに、このようなショートカットは Super(Win) キー長押しで知ることができます。(これは前のバージョンからの機能)

ubuntu1304-04

便利すなぁ。

デフォルトインストールから追加したのは、次の開発系と flash などのサードパーティー製品です。

sudo apt-get install build-essential
sudo apt-get install ubuntu-restricted-extras
sudo apt-get install openjdk-7-jdk

最近は、Oracle のではなく OpenJDK7 を利用中。 Eclipse や JVM 系開発用。

で、その Eclipse でちょっと困ったのが、Internal Browser が使えなかったこと。

ubuntu1304-05

この画面は既に設定済みなので、Use Internal web Browser(内部ブラウザを使う)が有効になっていますが、デフォルトインストール直後は非活性でした。

この事象、いつもだったか、 Ubuntu を設定しているうちにそのうち入って動いていたのか、いままで気にしたことがなかったのですが、理由は Eclipse の SWT が webkit の 1系を要求するためで、入ってないと enable にできません。 13.04 のデフォルト webkit は 3系でした。

てなわけで、1 系をインストールすれば使えるようになります。

sudo apt-get install libwebkitgtk-1.0-0

これにより、いつも使っている Eclipse Mylyn Doc textile 編集でプレビューができるようになりました。(下のプレビュータグがでてきます)

ubuntu1304-06

さて、WebKit 関係ありませんが、先日購入しました WireframeSketcher もうまく動作しました。

SWT Spy 恐るべしの図(既存の SWT 画面を吸い取ってスケッチ化できるっ)

ubuntu1304-07

やはり Linux はソフトウェアをつくる環境として便利で、ほとんど何もしなくても好みの動きをしてくれるのが良いところです。

インターネットの場合、開発時の接続先のサーバも Linux であることが多いので、ワークステーションとの親和性の高さもポイントですね。 🙂

OS の群雄割拠を見るような自分の机。 Linux 勢優勢。

20130425_215355

てなわけで、奥のディスプレイはこの部屋に新星のように現れた Windows 8。 ようやく入れましたぞ!

(次のブログは Windows 8 ネタという前フリらしい)

WireframeSketcher でワイヤーフレームドキュメント作成

以前、サイトを眺めてすごいなぁと思っていたものの、有料($99)だったため試さなかった、WireframeSketcher を本日購入してみました。

用意された部品や操作系を元に、アプリケーション開発時のワイヤーフレームやモックアップなどのドキュメント作成を支援するソフトウェアです。 SI の世界だと、エクセル方眼紙でやっちゃうような、外設の画面設計書をつくるの、で通じるでしょうか(笑)

WireframeSketcher

WireframeSketcher is a wireframing tool that helps designers, developers and product managers quickly create wireframes, mockups and prototypes for desktop, web and mobile applications. It’s a desktop app and a plug-in for any Eclipse IDE.

デザイナー、開発者、プロダクトマネージャさん向け。

Eclipse GEF/EMF ベースでつくられており、Windows、Mac、Linux 対応。ダウンロードしすぐ実行できるオールインワンのスタンドアローン版の他、Eclipse プラグイン版も用意されています。

130422-0007

下のような、描くのも変更するのも大変そうなイラストが、

wp_tree_f

次のテキスト入力だけで作成できてしまう。。

wp-content
-plugins
--otenki
---otenki.php
-themes
--[v] twentyeleven
--[v] twentytwelve

なんてことだ...

このことだけで、なんでもっと早く試さなかったのだろうと後悔です。。15日のお試し期間中の 1 日目で購入してしまいました。

以下、これまたどう考えても描くの面倒だろうJK、と言われそうな一覧表とフォームの組み合わせも、

130422-0019

こんな感じのテキストでサクッとつくることができます。

130422-0020

あっという間。。 🙂

試しに、このサイト hiromasa.another のモックアップを作成してみました。

130422-0011

出力を手書き風味にできるのがポイントで、(お客さんなどに)まだデザインとかはイメージですよ、というようなことを表現できるとのことです。

ちなみに Screen のプロパティーを Sketch から Clear に設定することで、びしっとすることもできます。

130422-0002

びし。まっすぐ。

130422-0010

WireframeSketcher の操作はパレットビューより部品を選択し、ぺたぺた貼り付け、それぞれの個別属性を指定していく感じです。

部品は PC 用、モバイル、Android、iOS、Web フォームなどなど沢山。 これらは一般的な .svg 形式で、フォーマットに従えば自分で描いた絵も部品に取り込むことができるようです。

130422-0021

ブログのコメントフォームを描いてみたの図。

130422-0022

ドローアプリとしての操作感は、利用開始当初、レイヤー機能がないため若干厳しい部分あるかなと思いましたが、アウトラインビューなどからのZオーダ設定、グルーピング系と、そのグループへの突入(?)、またプロパティーからの位置ロック操作をうまく使えば、問題なく描くことができると感じました。

130422-0023

画面上、オブジェクトの単一選択と矩形選択の切り替えの UI がぱっと分かりませんが、(Fn + ) F3/F4 でそれぞれに切り替わります。クリック to ドラッグの範囲選択において、カーソル位置のオブジェクトを引っ張りたくないケースでは F4 を押すといいと思います。

さて、WireframeSketcher の良いところのひとつは保存形式に XML のテキスト形式が用いられていることで、さらに画像となる .svg ベクターデータと、骨組みとなる .screen データは完全に分離されています。

このため、骨組みの .screen の変更履歴をみると、どの部分が修正されたかが分かります。

130422-0016

スクリーンショットは新旧ファイル差分を出した図。–File Three が増えてその下のアイテムの y 座標が増えたことが分かります。

このように、WireframeSketcher はテキストファイルベースのデータ形式を採っているため、ローカルヒストリーの利用や Subversion、Git などバージョン管理との統合も得意です。

Eclipse マーケットから EGit や Subclipse などを追加することで Git や SVN が使えるようになるハズです。(スタンドアローン版 は Eclipse Juno ベース。自分は Eclipse Juno for JavaEE に WireframeSketcher をプラグインの形で入れました)

さて、ぼくは普段からドキュメントの作成に Eclipse Mylyn の .textile サポートを使っていましたので、今回ワイヤーフレーム作成に WireframeSketche という心強い見方が統合されたことになります。

ワイヤーフレームはもちろん、ちょっと億劫だなと思っていた図形の描画もできるようになってとても嬉しいです。 🙂

130422-0018

ブログ”徹底解析”シリーズを Eclipse で書いているの図。

日本に一人しかいないんじゃないかと思うくらいの Eclipse の利用法ですが、ソースコード見ながら記事を書くことが多いので、この使い方はすごく便利です。(ちなみに 300ページの原稿に耐えてます)

上記スクリーンショット下部は、PlantUML。これもテキストベース図形描画 & Eclipse プラグインあり。 UML を描くツールですが、これがまた色々な用途に使えるのです。

PlantUML についてはプログラマーズ雑記帳さんが非常に参考になります。(とても助かりました!)

PlantUML の使い方 | プログラマーズ雑記帳

テキストから UML を生成する PlantUML についての解説記事を書いてみました。

PlantUML の Eclipse プラグインについては、そのうちまた。 🙂

JavaScript デバッグ環境の用意(JSDT + Firebug + Crossfire)

前回に引き続きまして JavaScript の開発環境構築です。 今回は、少し大きなプログラムを作り始めるとなくてはならないデバッガを設定してみます。

JavaScript のデバッグ環境は、IE の開発者ツールや Firefox の FIrebug などでも準備できますが、ここでは Eclipse WTP/JSDT の環境のビューから直接ブレイクやウォッチをする方法をかいてみます。

WTP/JSDT についてはこちらです。

JavaScript 開発環境の用意(Eclipse WTP/JSDT) | hiromasa.another :o)

Eclipse に含まれる Web Tool Platform(WTP)には、JavaScript Development Tools(JSDT)が含まれており、おそらくみなさんがインストールしているであろう、Eclipse for  JavaEE Developer に最初から含まれています。

JSDT からブラウザの JavaScript にリモートアタッチしてデバッグする方法はいくつかあるようですが、JSDT の標準インストールで FIrebug / Crossfire プロトコルに接続して行うパッケージが入っていますので、こちらを用いてみました。

JSDT/Debug/Crossfire – Eclipsepedia

Support for remote Firebug using the Crossfire protocol is available in the JSDT development bundles and is provided to allow remote debugging of JavaScript using Firebug via Crossfire.

まず、Firebug / Crossfire を使うために Firefox に Firebug と Crossfire アドインをインストールします。 Crossfire の .xpi についてはこちらです。(下の方に .xpi へのリンクあり)

mrennie/crossfire · GitHub

Crossfire is a Firebug extension which implements a JSON protocol to allow remote clients (like an IDE or code editor) to connect to Firebug.

Firefox にアドインがインストールできたら、Eclipse から接続する準備を行います。Crossfire アドインのスタートがちょっとわかりにくいのですが、FIrefox の表示 -> ツールバー -> アドオンバーを表示して、右下のアイコンからスタートします。

130322-0001

アタッチポートを聞かれてくるので、ここではそのまま 5000 で起動します。

130322-0002

でもって、FIrefox でデバッグしたいサイトを開いて Firebug で一度「スクリプト読み込み」しておきます(これが重要)。ここでは Eclipse の jstest プロジェクトに配置された、http://127.0.0.1/jstest/index.html を開きました)

130322-0003

次に Eclipse 側のデバッグ構成をします。 デバッグ構成からリモート JavaScript に jstest 構成を追加します。 コネクターは Crossfire – Remote “Attach” を選択し、ソースからソースコードをマッピングします。

130322-0004

130322-0005

このステップで準備完了です。 そのまま右下デバッグボタンを押下すると、Firebug に接続され、先のアイコンが接続状態になり、Eclipse のデバッグプロセスも起動します。

130322-0007

何かデバッガの挙動がおかしいなと思ったらここから再起動してあげてください。なおります。(ブラウザとの通信状態によってブレイクポイントの位置などが不整合することがあるようです)

130322-0006

あとは通常の Eclipse のデバッグ操作です。 ソースコードにブレイクポイントをはってみます。 F6, F7, F8 キーなどでステップ実行やウォッチが可能です。

130322-0008

ブレイク中のウォッチはカーソルあてればホバーしてきます。

ふむ。

130322-0009

ほう。

130322-0010

ほほう。

130322-0011

変数ビューを使えば、Firebug から送られてくる生のブラウザの状態もみれます。

130322-0012

これを見ているだけでもブラウザの内部動作の理解ができますね。

この手順で Eclipse から Firebug にいったん接続すれば、あとはそっとしておいて大丈夫です。作業開始時にでもつないでおくといいでしょう。

機能的には Firebug でも当然同じことが出来ますが、Eclipse からであればそのまま見やすいソース表示でデバッグブレイクでき、変数ウォッチなどもビューを使って操作しやすいかなと思いました。 🙂

プログラムのなぞの挙動は、考えるよりデバッガひっかけたほうが解決簡単。論より run が座右の銘のひろましゃでありました。がってんがってん。(←調子が悪いとオチが弱くなるらしい・・・

JavaScript 開発環境の用意(Eclipse WTP/JSDT)

いわゆる業務系アプリをつくっている現場でも徐々にモダンな JavaScript の開発が導入されるようになってきました。もちろん今までもバリデーションやコントロールの制御に使われてきましたが、なんというかノリっていうか、Java プログラマーがその知識だけで、それとなく動くものをつくってきたように思います。

そのような昔ながらの JavaScript しかみていないと、jQuery などで使われている近代的な JavaScript 記述方法はもはや別の言語にも見えてしまいます(笑)

てなかんじで、そろそろちゃんと JavaScript を勉強しないといけないねって感じも含めて去年末にプログラムをかいたのが「バッタになりたい魔法使い」でした。

Web絵本|バッタになりたい魔法使い

wizard_ogp

内容の詳細はこちらを。:)

canvas と Web 仕掛け絵本 | hiromasa.another :o)

実際の実装ですが、絵本のコマに対して canvas タグを対応させ、CSS では canvas を display: block; してブラウザの描画領域を全て埋め、横幅、余白を含め全ての描画制御を JavaScript から行っています。たとえば、背景画像横幅が足りなければ CSS で真ん中にもっていくのではなく、”白”を画像の左右に描画しているイメージです。

さて、JavaScript は特に Java のような静的型付け言語しか知らない場合、非常に特異な言語に見えるかもしれません。プロトタイプベースのオブジェクト指向や、コンテキストの考え方など、一般的なプログラミング言語の常識が通用しない部分が多々あります。

またブラウザという実行環境についても知識が必要で、HTML/CSS の操作や、そもそもどこから言語の機能で、どこからブラウザの実装なのか分からなかったり、なかなか難儀なものです。

専門の人が現場にいればいいのですが、お客さんによってはそもそもこういったジャンルの仕事があると思っていない場合もあり、小技を持っている専門外プログラマーの英知をもって、ひどいものができるという惨状を目の当たりにし、ぼくはついに立ち上がった、、かどうかは分かりませんが、よくある Java の現場で JavaScript をかかねばいけなくなった時の環境の用意の仕方や、ちょっとしたテクニックを書いてみたいと思います。 🙂

良い仕事には良い環境から。

よくある Java の現場ってことで Eclipse を用いていますが、「バッタになりたい〜」でも Eclipse 使っています。この方法は普通に JS かく場合にも便利ですのでお試しを。

Eclipse に含まれる Web Tool Platform(WTP)には、JavaScript Development Tools(JSDT)が含まれており、おそらくみなさんがインストールしているであろう、Eclipse for  JavaEE Developer に最初から含まれています。

Eclipse から JS サポートをうけるには、使っているプロジェクトを「JavaScript プロジェクトに変換」してあげます。変換といっても、機能追加みたいなイメージなので、その他は現状通りです。

ここでは新規にプロジェクトをつくって変換しています。「JavaScript プロジェクト」を新規に作成することも出来るのですが、一般的によくやるワークスペース外の htdocs の下にプロジェクトを配置する操作を行うと、JavaScript リソースの設定がおかしくなるようなので、いったん別のプロジェクトから変換するというやり方をとっています。

130320-0001

jstest をプロジェクト名としました。

130320-0002

サンプル的にファイルを配置してみました。ここでは js フォルダの下にソースを置くとします。

130320-0003

プロジェクトを右クリックして、「構成 -> JavaScript プロジェクトへ変換」します。既存プロジェクトがある場合はここからの操作です。

130320-0004

この後、ソースファイルの配置などを決めるダイアログがでますが、そのままOKしてください。(どうもこの段階で設定などをすると JavaScript リソースがおかしくなるようです)

これでプロジェクトが次のようになると思います。

130320-0008

JavaScript リソースが追加され「ECMAScript ビルトイン・ライブラリー」と「ECMA 3 ブラウザー・サポート」が入れば成功です。補完などが効かなくなったら、この二つが正しく入っているかを確認します。(ここで書いている手順以外だと、ビルトインライブラリーが入らないパターンがあるようです。。)

このままだとJavaScript リソースがプロジェクト配下の全てのファイルを対象としてしまうので(特に問題はないですが)、ソースファイルの位置をプロジェクトの右クリック -> プロパティー -> JavaScript -> ソース -> フォルダの追加から指定します。(jstest/js にしました)

130320-0005

さて、これで準備完了です。ようこそ、JavaScript の世界へ。 🙂

統合環境はプログラム言語の勉強のよき先生です。特に、静的型付け言語の場合は、コンテンツアシストやインテリセンスといった補完機能やリアルタイムエラー出力などの IDE の強力な機能が、いろいろな手助けをしてくれます。

オブジェクト指向なんか統合環境ぽちぽちいじって、コード補完駆使してフレームワークのライブラリ呼んでるうちに覚えるもんじゃなかろうか、なんて思ったりしますがどうでしょうか。ぼくはそうでした(笑)

JavaScript の場合動的型付け言語なので、IDE は少し貧弱な先生になりさがってしまいますが、それでもあるとないのとではだいぶ違います。

まずは、プロジェクトに追加された JavaScript リソースを眺めるところから。これはコンテンツアシスト用の JSDoc になっています。

ECMAScript ビルトインライブラリー。これが JavaScript の言語としての実態になります。これで全部ですがほとんどなんもありません。

130320-0009

ECMA 3 ブラウザサポート。見たような名前が並んできましたが、これは全部表示しきれていません。まだまだあります。これらはブラウザが言語につっこんできているオブジェクトとなります。

130320-0010

この中で、Window オブジェクトを選択して JSDoc をみると次のような記載があるのが分かります。

/**
 * Object Window()
 * @super Global
 * @constructor
 * @since Common Usage, no standard
*/
function Window(){};
Window.prototype = new Global();
Window.prototype.self = new Window();
Window.prototype.window = new Window();
..略..
Window.prototype.document= new HTMLDocument();

Global は JavaScript 側のオブジェクトですが、これをプロトタイプにして Window オブジェクトが生成されています。こんな感じで ECMAScript とブラウザは、グローバルを介してつながっている感じです。ちなみに「@since Common Usage, no standard」の記述がもの悲しい・・・。

こんなのを眺めていれば、alert() や document.getElementById() なんかがなぜその記述で動くのかが分かるようになりますね。

ちなみに Eclipse がこれらの JavaScript リソースを使ってコード補完ができるのは、次の設定によります。「プロジェクト -> プロパティ -> JavaScript -> インクルードパス -> グローバルスーパータイプ」

なんだかちょっとバグっているのですが「フィールドおよびメソッドを継承する元の SuperType」のところがブラウザと同様「Window()」になっているのが分かります。”null 中の”ってなんだって感じですが(笑)

130320-0014

というわけで、コード補完をやってみます。

グローバルスコープ。

130320-0027

window。

130320-0011

String オブジェクト1。

130320-0012

String オブジェクト2。static のように。

130320-0013

Math。あれ。。。(バグ?)

130320-0022

という感じで、JSDoc みたり、補完に出てくる候補を見たり実際にブラウザでグローバル this の中身を表示していたりすると、JavaScript についての理解が進むのではないかと思います。

なおあんまり関係ありませんが、JSDT jQuery を導入すると jQuery の補完もできるようになります。

130320-0015

130320-0016

次の変数名の補完はなんかちょっと微妙です。this がからむと厳しいですね。 JSDoc の @memberOf は効くようなのですが、、@this タグが使えるとなんとかなるのかもしれませんが、この辺は動的型付けの難しさ。

ほほう!

130320-0019

無念。。

130320-0021

最後に、リファクタリングを。 あらかじめお断りしておきますと、ローカル変数名変更以外のリファクタリングはうまく動かない感じです。でも、これだけでもだいぶ違います。

適当すぎるローカル変数名リファクタ用サンプルコード。

130320-0023

とりゃ。 hoge -> moge 変更。

130320-0024

パチパチ。

130320-0025

その他、リアルタイムエラー申告も役立つことでしょう。

未使用変数申告と、セミコロン忘れ。どっちもやりがちで、プログラムは動いちゃうパターンです(8行目、10行目)。こういうのは IDE にお任せです。だいぶ助けられます。

130320-0018

というわけで、いろいろ見始めると深みにはまっていく JavaScript の世界。ついブラウザのソースコードまでダウンロードし始めてしまいましたが、、そろそろやめておきましょう。。

とりあえず、現場で JavaScript かかなければいけなかったりしたときに思い出していただければ!

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 ですがちょっとヘビーで使ってない方もいるかもしれません。

別に必要ない時は使わなければいい!

ってわけで、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!

Mac での開発環境構築

MacBook を買いまして少しの時間が経ちました。 ぼくはいままでは Linux メインで使っていましたので、どこまで Mac OS X で同じことができるかってところを試しつつ使っています。

メインで使っている Linux / Ubuntu / ThinkPad では主に以下のようなことをしていますです。

  • Groovy とか Java とかのプログラミング
  • WordPress とかいじったり(Apache + PHP)
  • インターネット上の Web サーバとか VPS に対する操作

てなわけで、Mac にもいろいろアプリ・設定入れてみました。

Groovy とか Java とかのプログラミング

これはいつもの Eclipse。 Mac OS X 版をいれるだけで完了です。 Java は OS が勝手に入れてくれる模様。

メニューとかショートカットが Mac になっているくらいであとは同じです。 control キーに emacs アサインできるのは有利かも。:)

Eclipse mac01

Mac 版は、若干ビューのデフォルトフォントが小さくなってしまうという問題があるようなので、起動シェルを修正します。 eclipse.ini から smallFonts の記述を2つ削除。(なぜオプション値きかないんだろう)

hiromasa-no-MacBook-Pro:MacOS hiromasa$ pwd /Applications/eclipse-jee-juno-macosx-cocoa-x86_64/Eclipse.app/Contents/MacOS
hiromasa-no-MacBook-Pro:MacOS hiromasa$ diff eclipse.ini eclipse.ini.org
18a19 &gt; -Dorg.eclipse.swt.internal.carbon.smallFonts 23a25
&gt; -Dorg.eclipse.swt.internal.carbon.smallFonts

あとは不思議なことに、ワークスペースのデフォルトエンコーディングが SJIS になっているので UTF-8 に変更しています。

WordPress とかいじったり(Apache + PHP)

ローカルの Apache と PHP。 MAMP を使っている方が多いようですが、とりあえず慣れている XAMPP にて。XAMPP はポータブルなのでファイルうつせば環境移行できるのが便利ですね。

ターミナルから、

sudo /Applications/XAMPP/xamppfiles/xampp start 

control + space, term, enter, control + r, start, enter, enter, password, enter くらいで素早く起動できます。(Spotlight からターミナル起動して、sudo から xampp 起動です)

PHP の編集は、Eclipse の PDT で。 3.1.1 がでてだいぶバグがとれたような感じです。スクリーンショットありで面白いので以下のリンクを。 🙂

PDT 3.1.1 Release Notes

PDT 3.1.1 released on September 28th, 2012 contains nearly 100 bug fixes for issues reported over last three months, since the release of Eclipse Juno. Beside bug fixes, there are several new features added to make PDT Content-Assist smarter, to better support PHP 5.4 traits and other new language additions.

間接参照や返りオブジェクのオートコンプリートなど、PHPDoc を参考にしつつ動作するようになったようです。 WordPress はソースコードに PHPDoc 入っていますのでうまく動くハズです。

言語構文解析によるリアルタイムシンタックスチェック、ファイル・関数・メソッド定義ジャンプ、バージョンコントロール統合、diff など各種ツールが使い込まれたスペックで動くのでやはり Eclipse は手放せません。

インターネット上の Web サーバとか VPS に対する操作

インターネット上のサーバと親和性が高いのは、UNIX 系 OS をワークステーションで使う一番の利点かもしれません。 Windows だと実現できないことや、設定が大変なことも Linux や Mac だとあっさりです。まずターミナルエミュレータいれなくていい 😀

Linux でリモートサーバをいじるのに便利なのが SSH をつかったファイルシステムのマウント。ディレクトリにリモートサーバのファイルシステムがマッピングできますので、SFTP などのクライアントを使うことなく、ファイル操作や編集が通常のアプリ操作で可能になります。

Ubuntu の場合 GNOME Nautilus からぽちぽち設定するだけでできますが、Mac OS X でも FUSE for OS X + SSHFS 入れるとできるようです。

What is FUSE for OS X?

FUSE for OS X allows you to extend OS X’s native file handling capabilities via third-party file systems. OSXFUSE is a successor to MacFUSE, which has been used as a software building block by dozens of products, but is no longer being maintained.

Macfution というフロントエンドがあるので、説明に従って設定すると SSH でリモートサーバが FInder でみれるようになります。(ただし Linux の fuse にくらべて若干処理が遅い)

Macfusion01

SSH の秘密鍵の設定は、Advance オプションから -oldentityFile オプションで鍵を指定すると効くようです。

Macfusion02

じゃじゃん。 Finder からこのブログの入っているリモートサーバをみているの図。 あとは普通のファイル操作が可能です。

Mac fuse01

ちょっと処理が遅いので、Eclipse から別系で SSH マウントする方法もあります。リモートファイルエクスプローラからサーバを追加。

Eclipse ssh01

こんな感じで見れますので、右クリックしてリモートプロジェクトの作成をおせば、サーバ上のファイルも直接いつも通り Eclipse からの操作できるようになります。

FUSE for Mac OS X はまだまだ使い込んでいないので、不具合あるかもしれません。 Eclipse のほうはいつもやっているので問題ないと思います。(ちなみに、リモートプロジェクトを削除するときは「コンテンツの削除」にチェックいれちゃうと、当たり前ですがサーバからファイルがずっぽり消えるので注意のこと)

その他、Mac でも rsync や ssh などのコマンドが使えリモートサーバのメンテナンスに活躍してくれるでしょう。

ssh-copy-id コマンドとかしぶめのコマンドは標準では入っていないようですが、何かしらいれると GNU のコマンド群もインストールできるのかもしれません。(まだやってない…)

以上てなわけで、Mac でもいろいろできるようになったというお話でした。:)

おちが弱い・・・。貝になります・・・。

MacBook Pro 購入

CSS Nite などにいくと、OS のシェアが逆転したんじゃないかと錯覚するほど MacBook を使われている方が多いことに気がつきます。WordPress ハンズオンなどでも MacBook を持ってこられる方が多く、貸してもらって操作をするたびに Mac OS X におびえているのです(笑)

WordPress入門ハンズオン1巻にてハムさん。:)

てなわけで、そろそろ覚えておかないといかんのじゃないの?ということで、買いましたぞ MacBook Pro。:)

15インチの安い方に、非光沢 1680×1050 解像度のパネルに替えて 16万なにがしでした。(ぼくは圧倒的にソースコードみる時間が長いので液晶は非光沢にしているのです)

とりあえず、アプリは Eclipse さえ入っていればなんとかなるので一番最初にインストール。 cocoa-swt もきれいに動きますね。:)

Mac で便利なのは control キーの存在。ぼくは Linux とかも CapsLock に CTRL あてていますが、これはあくまで CTRL キー。 control として別キーにアサインできるのが良い感じです。 というわけで、Eclipse にも emacs キーアサインできるです。いつも忘れるので書いておきます。

Previous Column ^B
Next Column ^F
Line Up ^P
Line Start ^A
Line End ^E
Line Down ^N
Delete Previous ^H

ほかにもたくさんありますが、とりあえず。:)

Firefox は何もしなくてもこのキーアサインききました。Adobe さんのアプリはきかなかったような?

Eclipse は先日でました最新版 4.2 な Juno を使っています。 せっかくなので入れているプラグインのアップデートサイトも書いておきましょう。

Groovy Update Site – http://dist.springsource.org/release/GRECLIPSE/e4.2/
https://svn.codespot.com/a/eclipselabs.org/jsdt-jquery/updatesite
org.eclipse.php.repository – http://download.eclipse.org/tools/pdt/updates/3.1.1/nightly
Subclipse 1.8.x Update Site – http://subclipse.tigris.org/update_1.8.x

PHP Developer Tool のバージョンが Juno の標準リポジトリでは 3.0  のままになっています。SP1 あたりで 3.1 が入りそうな雰囲気ですが、とりあえず nightly をいれています。まだちょっとバグっぽい動作するようですがなんとか。

Java 系で、cocoa な SWT と LWJGL で OpenGL を動作させたの図。

いい感じに動きます!

ただ、ぼくの MacBook Pro では OpenGL 動かしたり、でかいプログラムコンパイルしたりするとあっという間にパームトップが熱くなってしまうのがいたい。長時間の開発は厳しいくらい熱せられるので、外部キーボード使うか、マシンの下にすのこたんとかファンをおくとかしないといけなそうです。ここは継続調査で。

てなかんじで、届いたのは水曜日くらいで Mac の操作をちょっと覚えましたら、土曜日の WordPress ハンズオンで早速役立ってくれました。よかった 🙂

8/25 のWordPress入門ハンズオン2巻もがんばりますので、よろしくお願いいたします!