HOME > 開発者向けBLOG > Sencha Blog >  Sencha Cmd 5 で開発プロセスを最適化

Technology Note 開発者向けBLOG

Sencha Blog

Sencha Cmd 5 で開発プロセスを最適化

こんにちは、ゼノフィnakamuraです。

この記事は、US Sencha社ブログ Optimizing The Development Process With Sencha Cmd 5 を翻訳したものです。

Optimizing The Development Process With Sencha Cmd 5 Sencha Cmd は Sencha フレームワーク ( Ext JSSencha Cmd ) を使用したアプリケーションの生成やビルドに必要なツール一式を提供しています。こういった開発プロセスの最初と最後の部分だけでなく、Sencha Cmd は日々の開発に役立つツールも提供しています。管理機能を組み込んだ内蔵 Web サーバーを始め、Sencha Cmd は多くの日常的なタスクの自動化を手伝ってくれます。この記事では、これらがどういったことなのかを解説し、新しいカスタムコンポーネントでテストします。

In a 過去の記事では、Sencha Cmd でアプリケーションを生成しビルドするために使う基本的なコマンドを解説し、いかに既存のシステムやデプロイプロセスとスムーズに統合できるかをデモンストレーションしました。この記事では、Ext JS 5 と Sencha Cmd 5 の具体的なアップデートに着目したいと思います。

Sencha アプリケーション

Sencha アプリケーションを作成する場合にお勧めする方法は、Sencha クラスシステムの各クラス毎に 1つのソースファイルを作成することです。Java での開発に馴染みがある人は、この規則を受け入れられるできるでしょう。大きな固まりのコードを読みやすく、そして管理しやすくまとめるにはこの方法が一番です。また、ダイナミックローダーを使用している時に、各ファイルが独立してロードされるので簡単にデバッグすることもできます。

小さいアプリケーションでは、このアプローチと “ext-all.js” ファイル (Ext JS フレームワークが全て入っています) を合わせることで製品として実行可能かもしれません。しかし、実際のアプリケーションでは、これと同じ構造では全てのクラスをロードするための HTTP リクエストが多くなりすぎてしまうため、製品には向いていません。また、こういったリクエストはより遅いネットワークを通ってくることになるので、各ファイルをロードするためのコストは予想以上のものになってしまいます。

Sencha Cmd を使えば、Sencha アプリケーションの理想的な開発環境を最小化し、最適化し、圧縮し、すぐにでも製品となれる形にします。

  • 最小化 – 必要なクラスだけが含まれます。
  • 最適化 – コードの高レベルな構築により、より効率のよい形式に置き換えます。
  • 圧縮 – よく「ミニファイ」と言われます、説明的な変数名をを単一の文字に置き換え、すべての参照を一致するように更新します

始めましょう

このプロセスをより簡単にするため、Sencha Cmd はカスタマイズ可能なビルドスクリプトをスターターアプリケーションの一部として提供しています。すでにアプリケーションを持ってても心配はいりません、足りない部分は既存のアプリケーション上で生成することができます。

Sencha Cmd がインストールされていれば適切なフォルダーに行き、次のコマンドを実行すれば Ext JS 5.0.1 アプリケーションが生成され、すぐに始めることができます。

    sencha generate app -ext MyApp myapp

“myapp” フォルダー内に “MyApp”という Ext JS アプリケーションを見つけることができます。このマシンで初めてこのコマンドを実行すると、Sencha Cmd はExt JS 5.0.1 パッケージをダウンロードします。一旦ローカルにキャッシュされれば、Sencha Cmd は必要なピースだけを抽出し、アプリケーションを生成します。

この新しいアプリケーションは、次のようにすれば瞬時にビルドすることができ、(そこまで期待できようなものではないかもしれませんが) 製品版として出荷できます。

    cd myapp
    sencha app build
    scp -r build/production/* user@prod:/var/www

開発ワークフロー

この 2つのエンドポイントがどんなに重要なものであっても、開発者の 1日のうち、これに割り当てられる時間はほんの少しです。 多くの開発者は JavaScript や Sass(または CSS) に時間をさきます。ここで一番頻繁にするのは、ファイルを書き換え、ブラウザーのページをリロードして結果を見ることです。

Sencha アプリケーションで「開発モード」を有効にするためには、二つの基本的なことがあります。必要なSass を CSS にビルドすることと、”bootstrap” と呼ばれるダイナミックローダーを適切に構成することです。

app watch を使う

Sencha Cmd 以前では、これらのプロセスは 手動で Compass を使い、Ext.Loader コールしていました。Sencha Cmd アプリケーションでは、こういった手順はビルドプロセスに含まれていて、以下のコマンドで完全に自動化することができます。

    sencha app watch

watch コマンドは実行すると特別に短縮されたビルド (Sass と bootstrapの) を行い、 Web サーバーを立ち上げ、アプリケーション内での変更をモニターします。

    C:\Temp\myapp> sencha app watch
    ...
    [INF] Loading app json manifest...
    ...
    [INF] Mapping http://localhost:1841/ to C:\Temp\myapp...
    [INF] ------------------------------------------------------------------
    [INF] Starting web server at : http://localhost:1841
    [INF] ------------------------------------------------------------------
    [INF] Waiting for changes...

変更が発声すると、Sencha Cmd はbootstrap と CSS をアップデートし、全てを同期します。エディタでファイルを保存するとすぐに以下のように表示されます。

    [INF] Starting web server at : http://localhost:1841
    [INF] ------------------------------------------------------------------
    [INF] Waiting for changes...
    [INF] -----------------------
    [INF] Writing content to C:\Temp\myapp/bootstrap.js
    [INF] Writing content to C:\Temp\myapp/bootstrap.json
    ...
    [INF] executing compass using system installed ruby runtime
    unchanged MyApp-all.scss
    [INF] Refresh complete in 3 sec. at 06:52:25 PM
    [INF] -----------------------
    [INF] Waiting for changes...

“Waiting for changes” が表示されると、アプリケーションがブラウザー内でリロードされる準備ができたということです。

watch コマンドは Sass を使って作業をしている時に理想的です。なぜなら、CSSの全ての変化に即座に対応してくれるからです。 Theme Guide で解説されているように、Sass ファイルの順番は、対応する JacaScript ファイルの順番によってきめられます。つまり、JacaScript をリファクタリングすると、Sass ファイルの順番も影響を受けます。しかし、心配はいりません、これらの細かい所は app watch が管理しています。

パッケージを使用しているなら、app watch は、必要とするパッケージでの変更も拾い上げてくれます。JavaScript、Sass に変更を加えたり、リソースを足したり変更した場合でも app watch はこういった部分が全てアップデートされることを保証します。app.json 内でパッケージ要件を変えるだけでも必要なアップデートをトリガーします。

Watch の改良点

もし以前にリリースされた Sencha Cmd のウォッチを使用したことがあれば、最近のリリースで幾つか改良された点があることをお伝えしたいと思います。

具体的に言うと、Mac OS X において、内部のファイルシステムモニターを改善して、CPU オーバーヘッドを大幅に減らしました。 また、モニターのトラッキングも改善し、”.git” などのフォルダーを無視するようにしました。

sencha app watch の実際

app watch がどういった動きをするかを見るために、生成したアプリケーションの app.json に新しいパッケージ “ext-ux-colorpick” への requires を、加えてみます。

    "requires": [
        "ext-ux-colorpick"
    ]

Main.js ビュー内にインスタンスを作ります:

    items: [{
        ...
    },{
        region: 'center',
        xtype: 'tabpanel',
        items:[{
            title: 'Tab 1',
            items: [{
                xtype: 'colorfield',
                fieldLabel: 'Color'
            }]
        }]
    }]

“Save All” を押して、App Watch の出力を見ます:

    [INF] Waiting for changes...
    [INF] BuildEnvironment config change detected : C:\Temp\myapp\app.json
    [INF] Source File : http://cdn.sencha.com/.../ext-ux-colorpick.pkg
    [INF] Downloading : ....................
    [INF] Extracting  : ....................
    [INF] -----------------------
    [INF] Loading app json manifest...
    [INF] Writing content to C:\Temp\myapp/bootstrap.js
    [INF] Writing content to C:\Temp\myapp/bootstrap.json
    ...
    [INF] executing compass using system installed ruby runtime
    overwrite MyApp-all.css
    [INF] Refresh complete in 10 sec. at 08:49:37 PM
    [INF] -----------------------
    [INF] Waiting for changes...

これでページをリロードしてカラーピッカーをみることができます:

App Watch を使わなくても、もちろん ext-ux-colorpick は使うことができます。この Ext JS 5 コンポーネントがどう組合わせられているかを見るには、GitHub の CmdPackages リポジトリのソースコード を確認してください。 Readme ファイルにも情報があります。

app watch のかわりに手動で

App Watch はものすごく便利ですが、どうしても違うやり方が必要になる場合もあります。例えば、めったに Sass を変える事がなかったり、使える RAM があまりなかったりもするでしょう。もしくは、app watch が Java 7 を必要とするため、使える環境にない場合もあるかもしれません。そんな場合には、以下のような高レベルなビルディングブロックを調べて、どのようなコマンドがあって、いつ使えるかを確認する必要があります。

App Watchを使用していない時に頻繁に利用されるコマンドが3つあります。それらは:

    sencha app build development
    sencha app refresh
    sencha ant sass
    sencha ant resources

それらがどういった状況で必要になるかを一つずつ見て行きましょう。

全てのベースをカバー

何が変更されようと、development build は必要なピースがリビルドされることを保証します。

    sencha app build development

このコマンドは全てを含んでしまうので、それなりに時間はかかりますが、どんな変更点も拾い上げてくれます。新しい development ビルドと Cmd が最初にリリースされた時から存在している testing ビルドとの違いはなんでしょうか? testing ビルドは、production ビルドと同様に動作し、アプリケーションをデバッグできる機能も少し持っています。testingビルドでは最適化と圧縮はできませんが、限りなく production ビルドと近い結果が得られます。development ビルドでは、ソースからリロードするためのピースだけが実行sされます。つまり、development ビルドは JavaScriptの連結や、完全な CSS ビルドを生成 (CSS をリビルドすることを最小限にするため) することを飛ばしたりします。

記:Sencha Cmd 5 は、Cordova と PhoneGap ビルドをより良く管理するため、ビルド環境のリストを少し変更しました。”native” や ”package” 環境 (Sencha Touch 独自のもの) の代わりに、上記で使われている “development” を加えました。この環境は開発目的で必要になる最小限のビルドです。native と package は、今は “packager” config でハンドルされています (詳しくはこちらから) 。

テーマやパッケージ要件への変更

パッケージ要件やテーマを app.json 内で変更した場合、development ビルドを実行する必要があります。

    sencha app build development

これは全てのSass とリソースがパッケージ要件と同期していることを保証し、 新しいパッケージから JavaScript ソースについての情報で bootstrap をアップデートします。

Sassへの変更

app watch を使っていない場合、Cmd を使う1番多くの理由は Sass を変更することにあります。.scss ファイルのコンテンツを変えているだけの場合、Sass だけを最速でリビルドするには、次のコマンドを実行します。

    sencha ant sass

これは、パッケージ要件やテーマの Sass への変更点を拾い上げてくれます。この場合、”sencha app build development” を実行する必要がありません。

リソースへの変更

新しいイメージを resources フォルダ、もしくは参照するパッケージ (もしくはテーマ) の resources フォルダーに加えた場合、次の様にビルドのリソースをアップデートできます。

    sencha ant resources

これはアプリとテーマのリソースを直接 “resources” フォルダに入れます。テーマパッケージではないリソース “foo” は ”resources/foo” に入ります。

JavaScriptへの変更

JavaScript での変更点の多くはコマンドを実行する必要がありません。フォルダやファイルの名前が標準の命名規則を守っていれば、Ext.Loader はクラスネームを URL に変更してくれ、bootstrap をアップデードする必要はあまりありません。もちろんこれはいいことです。

bootstrap をアップデートするコマンドは次のものです。

    sencha app refresh

では、「JavaScript 内でどういった変更点が bootstrap を無効にするのだろう」と疑問に思う事でしょう。

この疑問に応えるには、リフレッシュによって作られた bootstrap の内容を理解する必要があります。

  • The relative paths to your “app” folder and “src” folders of all required packages (and themes). 全てのパッケージ要件 (テーマも) の “app” フォルダーと “src” フォルダーへの相対パス。
  • 全てのクラスの名前 (app 内と必要なパッケージ内) 。
  • 全てのクラスの alternateClassNames。
  • 全てのクラスの aliase。

この情報がアプリケーション内の次の規則を有効化します:

  • クラスを alias で要求する。
  • クラスを alternateClassName で要求する。
  • 複数のクラスをワイルドカード (例:”MyApp.model.*” “)で要求する。
  • ファイルの名付け規則に対応しない名前のクラスを要求する。
  • “requires” にリストされていない alias、alternateClassName (または、適合しないファイル名) を使ってインスタンスを作成する。

アプリケーションでこれらの機能を利用できるようにするには、JavaScript の変更がbootstrap の内容に影響するので、refresh が必要になります。その他の変更点は一切のコマンドを必要としていません。

もう一つの上記のリストの見方は、app watch を使っておらず、bootstrap をいつリフレッシュさせるのかという心配をしたくない場合に、それを避けることができます。

要約

app watch を使っていないのであれば、日常的な開発の中でコマンドを実行する手間は、推奨する規約と使用するクラスの requires 設定を守れば問題ありません。この場合、Sass での変更またはパッケージ要件のセットだけがビルドを要求します。

より詳しい Sencha Cmd ビルドプロセスはこちらから。

まとめ

日常のワークフローにおいては、app watch は非常に価値あるツールだと思っています。もし違う方法が必要であれば、Sencha Cmd がどうやって細かい事を管理しているかを理解できれば日常のプロセスを合理化できます。どう思ったか是非フィードバックが欲しいです。また、新しい color picker component をお楽しみください。

追伸、color picker は、こちらから試せます。

PAGETOP