compassが遅い件 vol.2
「compassが遅い件 vol.1」の続きです!
今回は、image-width/image-heightの高速化手法を記載します!
(ディレクトリ構成等々は、vol.1と同様です。
はじめに
前回はconfig.rbに追記していきましたが、今回もそうなります。この調子で追記しまくっていったら、煩雑になってしまいます。。
そこで、カスタマイズしてる部分を分離しましょう!
カスタマイズしてる部分を分離する
簡単です。$ cp -ip config.rb _config.rb⇒ 前回追記したところを全部消して、下記を追記する
$ vim config.rb
$ vim _config.rb⇒ 前回追記したところのみにする
以上です。量が増えたら、機能ごとにファイル分けてもいいかも。
image-width/image-heightの高速化 事前準備
測定のために、準備していきたいと思います。1. 適当な画像を配置する
$ mkdir images⇒ このディレクトリの中に、「200px.png」を入れておく。(画像なら何でも良いです
2. scssファイルを作っておく
$ vim sass/test.scss
3. コンパイルしてみる
$ compass compile --time --force⇒ おっそい...
identical stylesheets/ie.css (0.0s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.024s)
identical stylesheets/test.css (13.207s)
Compilation took 13.235s
※ 毎回全部コンパイルしたいとき。
スプライトも含めて全部コンパイルし直したい
→ compassの--forceオプション
cssファイルのみ全部コンパイルし直したい
→ config.rbの更新日付を新しくすると走ります。(touchしてみるとかで)
image-width/image-heightの高速化1
当たりをつけたのは、この辺り。https://github.com/Compass/compass/blob/stable/lib/compass/sass_extensions/functions/image_size.rb#L47-L51
毎回画像のサイズ測ってるんじゃない?ということで、一回測ったらメモリに格納しておくようにしてみます。
(もしかしたら、.sass-cacheディレクトリでいい感じキャッシュ持ってるのかもしれませんが。筆者はそこまでわかりません!
こんな感じの修正になりました。これを_config.rbに追記します。
実行してみる
$ compass compile --time --force→ 5秒も短縮!
identical stylesheets/ie.css (0.001s)
identical stylesheets/print.css (0.001s)
identical stylesheets/screen.css (0.03s)
identical stylesheets/test.css (7.889s)
Compilation took 7.93s
しかしこの修正には問題が、、
watchオプションのときを考慮しておりません。
理想はcompileオプションのときだけにしたいけど、これもzoocompassにオプション追加して使いたい時だけ発動するようにします。
image-width/image-heightの高速化2
_config.rbの修正bin/zoocompassのcustom_optionsを修正(追記)
実行してみる
$ ./bin/zoocompass compile --time --force --enable-dimensions true
identical stylesheets/ie.css (0.0s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.026s)
identical stylesheets/test.css (7.758s)
Compilation took 7.787s
$ ./bin/zoocompass compile --time --force --enable-dimensions false
identical stylesheets/ie.css (0.001s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.028s)
identical stylesheets/test.css (13.401s)
Compilation took 13.433s
$ ./bin/zoocompass compile --time --forceうん、正しい!!
identical stylesheets/ie.css (0.0s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.029s)
identical stylesheets/test.css (12.895s)
Compilation took 12.928s
終わりに
今回は極端な例ですが、地味に効果があると思います。高速化対応したgem作りたいなあ。。
以上です!
compassが遅い件 vol.1
以前、compassのコンパイルが遅い…と記載しましたが、「遅い」に対していくつか対策したのでその手法を記事にしました。
(色々手法があるので、今回はvol. 1として書きます!
はじめに
compassはRubyで書かれており、モンキーパッチングが出来る。ということで、compassのconfigファイル(config.rb)でcompassの処理を上書きすることができます。
今回は、どうやって変更を加えるのかを実験した後に
「コンパイルする対象を正規表現で絞り込むカスタマイズ」をしたいと思います。
実質的にコンパイル速度が早くなるという修正ではないです。
任意のグループでコンパイルを走らせることができるようになりました。ぐらいの変更です。
(これだけでも筆者の案件状況ではかなり効果的でした。詳しくは書かないですが、同一ソースで複数サービスが動くという状況。
最終的には、このグループでのコンパイルをforkさせ、複数のグループを並列にコンパイルさせるとこまでやりました。
今回は、それをするための前準備になります。
・compassのソースはこちら(GitHub)
https://github.com/Compass/compass
・macだと、このあたりにソースがあります
/Library/Ruby/Gems/1.8/gems/compass-0.12.2/
・筆者のcompassのバージョン
$ compass -v
Compass 0.12.2 (Alnilam)
実験する環境をつくる
まずはじめに、コンパイルできる環境を作ります。
1. コンパイル環境をつくる
任意のディレクトリに移動し、下記コマンドを実行すると、コンパイルに必要なファイル/フォルダが生成されます。
config.rb
sass
stylesheets
2. とりあえずコンパイルしてみる
※ --timeオプションでコンパイルにかかった時間が表示されるので、今回は毎回このオプションをつけて実行する
1. コンパイル環境をつくる
任意のディレクトリに移動し、下記コマンドを実行すると、コンパイルに必要なファイル/フォルダが生成されます。
$ compass init↓が生成される。
config.rb
sass
stylesheets
2. とりあえずコンパイルしてみる
$ compass compile --time⇒ すると、コンパイルが走っていることが確認できます。
※ --timeオプションでコンパイルにかかった時間が表示されるので、今回は毎回このオプションをつけて実行する
実験する
compassのconfigファイル(config.rb)でcompassの処理を上書きすることができると記述しましたが、
本当に上書きできてるの?ってことを実験したいと思います。
compassでコンパイルする対象を取得するメソッドはこのような実装
config.rbに対して下記のような修正を加える(筆者はconfig.rbの下部に書いている)
⇒ この処理は、既存のメソッドをそのままコピーし、間に「p "here!!"」と1行追加しました。
※ 上書きすることができているならば、「compass compile」時に、「here!!」とログが流れ、正常にコンパイルが通っているはず。
$ compass compile --time
"here!"
"here!"
remove .sass-cache/
remove stylesheets/ie.css
remove stylesheets/print.css
remove stylesheets/screen.css
"here!"
create stylesheets/ie.css (0.002s)
create stylesheets/print.css (0.001s)
create stylesheets/screen.css (0.104s)
Compilation took 0.141s
うん、正しい!
コンパイルする対象を正規表現で絞り込むカスタマイズ
では、上記のことを利用して、コンパイル対象を正規表現で絞り込むカスタマイズをしたいと思います。config.rbに対して下記のような修正を加える。
これは何の修正なのか?
sassファイル名が「^.*ie.*$」にマッチするファイルをコンパイルするように修正しています。
(SASS_FILE_PATTERNSのIEを指定しているためです。
コンパイルしてみる
$ compass compile --time
remove .sass-cache/
remove stylesheets/ie.css
create stylesheets/ie.css (0.002s)
Compilation took 0.003s
絞り込めてる!正しい!
ちなみに、DEFAULT_TARGET_PATTERNを「PRINT」にすることで、下記のみコンパイルされることも確認。
stylesheets/print.css
コンパイル対象を変える際に、いちいちconfig.rbを書き換えるのも面倒くさい…
きっと、↑のようなことになると思うので、オプションで指定したいですよね。config.rbでオプション追加できるかなーと思って処理を追ってみましたが、
config.rbを読み込む前にcompassコマンドのオプション解析を済ませておりました‥
(compassのcオプションでconfig.rbを指定できるので、今思うと当たり前。
http://kanapple.net/study/archives/16
ということで、コマンドをラップするしかありません。
compassをrequireしてコマンドを新たに作ろうかなーとも思ったので、面倒なので↓にしてみました。
$ mkdir bin
$ touch bin/zoocompass
$ chmod 755 bin/zoocompass
$ vim bin/zoocompass
合わせて、config.rbのTARGET_PATTERN部分を下記に修正する(ENVでパラメータを受け取る
compassをラップした「bin/zoocompass」を使うと、オプションで指定したパラメータをconfig.rbで参照できるようになります。
(それ以外はcompassと何も変わりません。
何も変わってないか、試してみる
$ ./bin/zoocompass compile --time
remove .sass-cache/
remove stylesheets/ie.css
create stylesheets/ie.css (0.003s)
Compilation took 0.005s
うん、変わってない。
追加したオプションで試してみる
$ ./bin/zoocompass compile --time --target IE
unchanged sass/ie.scss
Compilation took 0.001s
うん、よい。
$ ./bin/zoocompass compile --time --target PRINT
remove .sass-cache/
remove stylesheets/print.css
create stylesheets/print.css (0.003s)
Compilation took 0.004s
うん、指定できてるぽい。
できた!!
注意事項!
compassのバージョンを上げる場合は、元のソース(compass側のソース)に変更がないか要確認。案件内でやる場合には、みんなに周知しないと。
終わりに
次回以降、これを使って並列実行させた記事も書いていきたいと思います。やったことを少しずつ記事にしてきますー。
以上!
JavaScriptのテストにKarmaを使ってみた
JavaScriptのテストにKarmaを使う機会があったので紹介したいと思います。
今回はKarmaを動かすところまでです。
Karmaってなに?
KarmaとはJavaScript用テストランチャーです。
このツールはJasmineやMochaなどのテストフレームワークを使ってテストを行います。
元々、AngularJS用のテストフレームワークとして開発されていたそうです。
GoogleがJavaScriptテストランナー「Testacular」をオープンソース化し、途中でプロジェクト名をKarmaに変えて今に至ります。
Karma、Mocha、Chai、SinonJSを使ってテストを行います。
では実行環境を構築していきましょう。
環境構築
筆者の動作環境です。
- MacOS X:10.9.4
- NodeJS:0.10.29
- npm:1.4.21
プロジェクトルートに下記package.jsonを置いて
$ npm install
を行うと必要なパッケージが揃います。
Karmaの設定
Karmaを設定しましょう。
プロジェクトルートに下記karma.conf.jsを置いて終了です。
Karmaに用意されているinitコマンドを使用して対話形式で初期設定することも出来ます。
$ ./node_modules/karma/bin/karma init
をして、質問に答えていくとkarma.conf.jsが生成されます。
これでKarmaの設定は完了です。
テストを書いてみる
実際にテストを書いてみましょう。
テストフレームワークにはMocha、アサーションにはChaiを使います。
Mochaとは
ブラウザやNode上で動くJavaScriptのテストフレームワークです。
TDDでもBDDでもかけます。
アサーションなどは別途ライブラリが必要です。
http://visionmedia.github.io/mocha/
BDD
テストフレームワークにはMocha、アサーションにはChaiを使います。
Mochaとは
ブラウザやNode上で動くJavaScriptのテストフレームワークです。
TDDでもBDDでもかけます。
アサーションなどは別途ライブラリが必要です。
http://visionmedia.github.io/mocha/
BDD
- descride
- ネスト管理可能な階層
- it
- 検証内容を書く
- before/beforeEach
- 前処理
- after/afterEach
- 後処理
Chaiとは
アサーションライブラリです。
should形式/expect形式/assert形式から選べます。
http://chaijs.com/
実際の手順です。
まずはテスト対象から作っていきましょう。
`karma init`時に指定するかkarma.conf.jsに追記しましょう。
テスト対象コード
次にテストコードを書きます。
こちらもテスト対象コードと同じく対象ディレクトリ配下にする必要があります。
テストコード
これで準備完了です。
実行してみましょう。
karmaへパスを通しておくといいと思います。
テストが通りました。
ちなみにブラウザからも見れます。
http://localhost:9876/
はい、簡単ですね。
今回はKarmaの実行までを紹介していきました。
もう少し詳しいテストの書き方は、また別の記事で書きたいと思います。
SinonJSの使い方もどこかで書きますよー。
should形式/expect形式/assert形式から選べます。
http://chaijs.com/
実際の手順です。
まずはテスト対象から作っていきましょう。
1.テスト対象のファイルを作る
テスト対象のファイルはkarma.conf.jsのfilesで管理されている必要があります。`karma init`時に指定するかkarma.conf.jsに追記しましょう。
テスト対象コード
次にテストコードを書きます。
2.テストファイルを作る
テストコードを作りましょう。こちらもテスト対象コードと同じく対象ディレクトリ配下にする必要があります。
テストコード
これで準備完了です。
実行してみましょう。
テスト実行
プロジェクトルートで下記を実行します。
$ ./node_modules/karma/bin/karma start
実行結果
INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
INFO [launcher]: Starting browser PhantomJS
INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket bNVYNYiUg7LDT85UO_-u with id 78213263
PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.009 secs / 0.001 secs)
テストが通りました。
ちなみにブラウザからも見れます。
http://localhost:9876/
はい、簡単ですね。
まとめ
もう少し詳しいテストの書き方は、また別の記事で書きたいと思います。
SinonJSの使い方もどこかで書きますよー。
Skia DebuggerによるCSSプロパティの重み測定 〜測定編〜
今回はSkia Debuggerの測定編ということで、install編の続きを書いていきたいと思います。今回もまた、
(筆者がMacなので、Macのインストール談です。。Windowsのひと、ごめんなさいごめんなさい。
「.skp」ファイルを取得する
1. オプション付きでCanaryを起動$ /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-impl-side-painting --enable-skia-benchmarking
2. tracingへアクセス
・Canaryで下記URLへアクセス
chrome://tracing/
図1. tracing |
3. 「.skp」ファイルを取得する
・レコーディング状態にする
左上の「Record」ボタンを押す
「Settings preset: Web developer」となっている。
図2. tracing record |
「Settings preset: Manually select settings」にすると表示が変わる。
図3. tracing record2 |
「Record Categories」のccをチェック
「Disabled By Default Categories」のcc.debugをチェック
右下の「Record」ボタンを押す。(すると、Recording状態になる。
・レコーディング〜レコーディングを停止する
新たなタブを開き、チェックしたWebサイトへ遷移して、計測したいページを開き、描画が変わるようなことをする。
(今回の場合、http://localhost/test/skia/
その後、元のタブ(chrome://tracing/)へ戻り、「Stop」ボタンを押してレコーディングを停止する
・レコーディング結果から「.skp」ファイルをexportする
アコーディオンがいくつかあるので、「Renderer (pid xxxxx): Index of /test/skia」を開き、
リストの見出しにある「cc::Picture」の右側の丸ポチを押す。
(すると、そのタブで開いた画面遷移が閲覧でき、遷移の流れを確認できる(右左ボタンでも切り替わるよ)
取得したい状態の.skpファイルを取得するには、画面左側の「Skia Picture」下部のskpicture.skp「Export」ボタンを押す。
図4. tracing record3 |
「.skp」ファイルを開く
1. Skia Debuggerを起動
install編でビルドした階層で、下記コマンドを実行する
$ open out/Debug/debugger.app
2. 「.skp」ファイルを開く
メニューにある「File」⇒Openボタンを押し、ファイルを開く
図5. Skia Debugger |
(期待してた、Total Timeが表示されてない…ので、調べます…。前は表示されてたのに。。
それを元に、CSSプロパティの重みを測定しようと思ってました。
※ 筆者がハマった!
現象:
Canaryで吐き出した.skpファイルが開けない
解決:
Canaryのバージョンと、Skia Debuggerのバージョンが違うと(?)「Couldn't read file, sorry」というダイアログが表示され、.skpファイルが開けないぽい。
その場合は、Skiaの最新ソースをgit pullしてから、Skia Debuggerをビルドし直すと、Canaryで吐き出した.skpファイルが開けるようになりました。
次回は、色々測っていきたいと思います。
以上!
Skia DebuggerによるCSSプロパティの重み測定 〜install編〜
CSSプロパティの重みが測れる…ということを知ったので、どうやってやるの?ってこと書きたいと思います。
インストールで筆者がつまづいてしまったので、まずはインストール編です。
(筆者がMacなので、Macのインストール談です。。Windowsのひと、ごめんなさいごめんなさい。
下記を参考にしてます!
http://havelog.ayumusato.com/develop/performance/e560-css_rendering_with_skia_debugger.html
はじめに
Skia Debuggerを入れなくても、レンダリング時のペイントの重みは知る手段があります。
※ペイントってなんぞ!?って方はこちら↓
http://tokkono.cute.coocan.jp/blog/slow/index.php/web-technology/reflow-and-repaint-in-browser/
1. Google ChromeのDeveloper Tools 「Timeline」
Google ChromeのDeveloper Toolsで「Timeline」のタブを選択し、
左上の「●」ボタンを押すことで現在のTimelineを測定することができます。
Timelineで表示されている棒グラフの色で、このようなことが分かります。
(このページはjavascriptの実行割合が多い。
Loading(青): 読み込みなど、ネットワークに関する処理
Scripting(黄): javascriptの実行に関する処理
Rendering(紫): レンダリングに関する処理
Painting(緑): 表示に関する処理←この処理が長くなってないか?多くないか?で描画に時間がかかっているかを判断することができます。
Developer Toolsの説明は、こちら詳しいです↓
http://www.slideshare.net/yoshikawa_t/chrome-devtoolsnext?ref=http://www.studio-kingdom.com/backbone-js/743
2. Google ChromeのDeveloper Tools 「Enable continuous page repainting」
Google ChromeのDeveloper Toolsで「画面を強制的に再描画し続けるモード」があり、
図1の「Enable continuous page repainting」チェックボックスをチェックすることでモードが切り替わります。
※ペイントってなんぞ!?って方はこちら↓
http://tokkono.cute.coocan.jp/blog/slow/index.php/web-technology/reflow-and-repaint-in-browser/
1. Google ChromeのDeveloper Tools 「Timeline」
Google ChromeのDeveloper Toolsで「Timeline」のタブを選択し、
左上の「●」ボタンを押すことで現在のTimelineを測定することができます。
図 Deveroper Tools Timeline |
Timelineで表示されている棒グラフの色で、このようなことが分かります。
(このページはjavascriptの実行割合が多い。
Loading(青): 読み込みなど、ネットワークに関する処理
Scripting(黄): javascriptの実行に関する処理
Rendering(紫): レンダリングに関する処理
Painting(緑): 表示に関する処理←この処理が長くなってないか?多くないか?で描画に時間がかかっているかを判断することができます。
Developer Toolsの説明は、こちら詳しいです↓
http://www.slideshare.net/yoshikawa_t/chrome-devtoolsnext?ref=http://www.studio-kingdom.com/backbone-js/743
2. Google ChromeのDeveloper Tools 「Enable continuous page repainting」
Google ChromeのDeveloper Toolsで「画面を強制的に再描画し続けるモード」があり、
図1の「Enable continuous page repainting」チェックボックスをチェックすることでモードが切り替わります。
すると、
画面右上に緑色のボックス(描画の処理時間を表すメーター)が出てきます。
このボックスをを表示した上で、
CSSプロパティの有効・無効を切り替えることで描画コストを高くしている原因を探ることができます。(メーターが上下するので。
画面右上に緑色のボックス(描画の処理時間を表すメーター)が出てきます。
図2. 画面を強制的に再描画し続けるモード |
このボックスをを表示した上で、
CSSプロパティの有効・無効を切り替えることで描画コストを高くしている原因を探ることができます。(メーターが上下するので。
Skia Debuggerって?
Skiaとは、Googleが開発しているグラフィックスライブラリで、Google Chromeでも使われいます。
そのSkiaのデバッグツールがSkia Debuggerで、このツールを使うとCSSプロパティの重みが測れます。
インストールするもの
XCODE
Google Chrome Canary
Qt
depot_tools
Skia Debugger
インストール手順
記述の順番通りインストール作業してもらえれば、たぶんスムーズに入るはず…
1. XCODEのインストール
1. XCODEのインストール
https://itunes.apple.com/jp/app/xcode/id497799835?mt=12
App Storeからインストールする
App Storeからインストールする
2. Google Chrome Canaryのインストール
http://www.google.co.jp/intl/ja/chrome/browser/canary.html
上記サイトからダウンロードし、インストールする
3. Qtのインストール
http://qt-project.org/downloads
上記サイトからQt 4.8をダウンロードし、インストールする
最新バージョンを入れるとSkia Debuggerがインストールできなかったので要注意
4. depot_toolsのインストール
http://www.chromium.org/developers/how-tos/install-depot-tools
・depot_toolsをcloneする
$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git・depot_toolsディレクトリにパスを通す(~/.bash_profileでもパスを通すように記述する
$ export PATH=`pwd`/depot_tools:"$PATH"⇒ 後述するgclientコマンドを叩けるようにする
5. Skia Debuggerのインストール
https://sites.google.com/site/skiadocs/developer-documentation/contributing-code/downloading
・Skiaをcloneする
$ mkdir skia・ビルドしてアプリを出力
$ cd skia/
$ gclient config --name . --unmanaged https://skia.googlesource.com/skia.git
$ gclient sync
$ GYP_GENERATORS="ninja,xcode"⇒ すると、「out/Debug/debugger.app」にSkia Debuggerが出力される!
$ GYP_DEFINES="skia_os=mac skia_arch_width=64" make debugger
・起動
$ open out/Debug/debugger.appなどでdebugger.appを起動させると、↓のような画面が表示されます。
図3. Skia Debugger起動 |
という方は、画面左上の「+」で画面を最大サイズにしてみてください。
Macbook Airだと画面の縦幅が足りないようで、「+」を押さないと表示されませんでした。(筆者もハマりました。
とまあ、install編はこんな感じです。
測定編では、
Google Chrome CanaryとSkia Debuggerを使ってCSSプロパティの重みを測定していきたいと思います。
以上!
Webフロントエンドの開発環境
以前、筆者が担当している案件ではcompassを使用している。と記述しましたが、他にはどんな開発環境だったのかを紹介したいと思います。
なんの開発をしている?
webviewを使ったスマートフォン向けのアプリ開発。
どんな役割の開発者がいる?
サーバーサイドエンジニア
フロントサイドエンジニア←筆者ここ
フロントエンドの開発環境
<javascript>
フレームワーク:knockout.js
altjsは未使用。
xhrの制御や、独自に必要なものは自前で書く。
書き方はある程度、型にハメてたので煩雑にはならずでした。
この桁数ぐらいの規模。。xhrの制御や、独自に必要なものは自前で書く。
書き方はある程度、型にハメてたので煩雑にはならずでした。
$ find . -name "*.js" | xargs wc -l
…
…
6xxxxx total
<css>
プリプロセッサ:sass
フレームワーク:compass
コンパイルが遅いので、ちょっとカスタマイズして使ってる。
(いずれ、Bourbonと速度比較した記事書きたいなー
<html>
PHPで記述し、共通部分はincludeして使っている。
問題は、PHPを通してるのでレスポンスが若干遅くなってしまう。。
⇒ 今後、デプロイ時にPHPファイルをパースしてHTMLを生成するような仕組みを入れたい。
PHPでの注意点としては、apacheで動的コンテンツもキャッシュされてしまうケースもある。
キャッシュは要注意。
http://www.softel.co.jp/blogs/tech/archives/3459
静的リソースも下記などでキャッシュさせている場合は、取り扱い要注意。
http://httpd.apache.org/docs/2.2/ja/mod/mod_expires.html
<その他>
SenchaAnimator
⇒ 演出部分はSenchaAnimatorで吐き出したものを使用。
uglifyjs
⇒ デプロイ時に実行し、javascriptファイルの圧縮を行う。
GitHub
⇒ マスターブランチでタグをうってリリースを管理。
jenkins
⇒ GitHubと連動し、自動デプロイする。
⇒ 特定のディレクトリにcssが排出される
2. 外部のjsライブラリ(knockout.js)などを結合してminifyするスクリプトを実行(滅多に更新なし)
⇒ 特定のディレクトリに~~~.min.jsが排出される
3. 自前で作成したjsライブラリをファイル結合してminifyするスクリプトを実行
⇒ 特定のディレクトリに~~~.min.jsが排出される
4. 特定の環境へアップロード
⇒ rsyncにてアップロードする
⇒ リモートのWEBサーバで動作確認するので、軽め。
vim
⇒ sublimeとかwebstormとか使ってみたけど、結局はvim。
grunt
⇒ タスクランナー。便利。
karma(mocha + chai + Sinon.JS)
⇒ テストランナー。便利。
Google Chrome Canary
⇒ 開発用chrome拡張機能とか作っていたので、chromeを使うのは案件で強制的。
(http://www.mamoida.com/2013/05/frontend-preprocessor/
なんか人気なAngularJSとか別のフレームワークを使う。
altjsで書く。
メモリ管理大変そうだけど、シングルページでつくる。
以上!
キャッシュは要注意。
http://www.softel.co.jp/blogs/tech/archives/3459
静的リソースも下記などでキャッシュさせている場合は、取り扱い要注意。
http://httpd.apache.org/docs/2.2/ja/mod/mod_expires.html
<その他>
SenchaAnimator
⇒ 演出部分はSenchaAnimatorで吐き出したものを使用。
uglifyjs
⇒ デプロイ時に実行し、javascriptファイルの圧縮を行う。
GitHub
⇒ マスターブランチでタグをうってリリースを管理。
jenkins
⇒ GitHubと連動し、自動デプロイする。
どんなフローでデプロイするの?
1. compass実行⇒ 特定のディレクトリにcssが排出される
2. 外部のjsライブラリ(knockout.js)などを結合してminifyするスクリプトを実行(滅多に更新なし)
⇒ 特定のディレクトリに~~~.min.jsが排出される
3. 自前で作成したjsライブラリをファイル結合してminifyするスクリプトを実行
⇒ 特定のディレクトリに~~~.min.jsが排出される
4. 特定の環境へアップロード
⇒ rsyncにてアップロードする
筆者の開発環境
Macbook Air + ちっさいモニター⇒ リモートのWEBサーバで動作確認するので、軽め。
vim
⇒ sublimeとかwebstormとか使ってみたけど、結局はvim。
grunt
⇒ タスクランナー。便利。
karma(mocha + chai + Sinon.JS)
⇒ テストランナー。便利。
Google Chrome Canary
⇒ 開発用chrome拡張機能とか作っていたので、chromeを使うのは案件で強制的。
次やるんだったら...
htmlもHamlやJadeで生成するなど、テンプレートを使ってみたい。(http://www.mamoida.com/2013/05/frontend-preprocessor/
なんか人気なAngularJSとか別のフレームワークを使う。
altjsで書く。
メモリ管理大変そうだけど、シングルページでつくる。
以上!
compassで運用しての感想。
現在筆者が担当している案件ではcompassを使って運用していて、
数千行レベルのcssを300ファイル・スプライト画像を300個ぐらい生成しています。
異常に規模が大きい。
今回は、使ってみての感想を大雑把に書いていきます。
のちのち掘り下げて書いていこうかなーと思います。
http://liginc.co.jp/designer/archives/11623
Sass を使うなら、Compass も使うと便利 http://wp.graphact.com/2012/01/13/sass-compass
ソース整理が楽っていうのは下記の存在がデカイ。 これはプログラマがソースの管理してるからっていうのがあるかも。 @import
⇒ scssファイル共通のモジュールとか作れる。
(各機能共通のcssはモジュールに書くといい)
@include
⇒ 共通の関数を作って読み込める。
@extend
⇒ 特定のセレクタに指定したスタイルを継承することができる。
%name{style}でスタイルを指定して@extend %name;で呼び込めるプレースホルダみたいな機能もある。
2. 画像関連の処理までしてくれるし楽!
画像のサイズを確認して指定することもなくなるし、スプライト画像も作ってくれる。 mixin作るなどして、共通処理をかませていたら書くのはスゴく楽になる。 image-width / image-height
⇒ 画像の縦横のサイズも自動で測ってくれる
sprite-map
⇒ スプライト画像も作ってくれる
3. ファイルの命名規則やコーディングルール決めしないと、いろいろ複雑になる…
下記などを参考にして命名規則をつけるなどして案件ルールを作らないと、 すごく複雑なcssが生成されたりして運用中に後悔する。
(運用中に大幅変更することになるかも。 SMACSS http://chroma.hatenablog.com/entry/2013/07/22/120818
BEM
http://howtohp.com/2013/12/27/sass-bem/
4. コンパイル遅い…
コンパイルは遅い。 数百行程のcssを10ファイルくらい生成するとかであれば全然遅くはないですが、 数千行レベルのcssを300ファイル・スプライト画像を300個ぐらい生成するような案件になると、 コンパイル時間が30分程度かかってしまいます。。つらい。
とまあ、
cssを生で書くより、はるかに良いです。
これだけじゃザックリしすぎて何が言いたいのか分かんない!と思うので、
今後具体的に書いていきたいと思います。
それと、ちょっとcompassをカスタマイズした部分もあるので後に記事にします。
以上!
compassとは
cssを生成するメタ言語であるsassをサポートするツールのこと。ざっくり言うと。 くわしくは、この辺り読むとわかるかも。 CSSの常識が変わる!「Compass」、基礎から応用まで!http://liginc.co.jp/designer/archives/11623
Sass を使うなら、Compass も使うと便利 http://wp.graphact.com/2012/01/13/sass-compass
運用しての感想
1. ソースの整理が楽!ソース整理が楽っていうのは下記の存在がデカイ。 これはプログラマがソースの管理してるからっていうのがあるかも。 @import
⇒ scssファイル共通のモジュールとか作れる。
(各機能共通のcssはモジュールに書くといい)
@include
⇒ 共通の関数を作って読み込める。
@extend
⇒ 特定のセレクタに指定したスタイルを継承することができる。
%name{style}でスタイルを指定して@extend %name;で呼び込めるプレースホルダみたいな機能もある。
2. 画像関連の処理までしてくれるし楽!
画像のサイズを確認して指定することもなくなるし、スプライト画像も作ってくれる。 mixin作るなどして、共通処理をかませていたら書くのはスゴく楽になる。 image-width / image-height
⇒ 画像の縦横のサイズも自動で測ってくれる
sprite-map
⇒ スプライト画像も作ってくれる
3. ファイルの命名規則やコーディングルール決めしないと、いろいろ複雑になる…
下記などを参考にして命名規則をつけるなどして案件ルールを作らないと、 すごく複雑なcssが生成されたりして運用中に後悔する。
(運用中に大幅変更することになるかも。 SMACSS http://chroma.hatenablog.com/entry/2013/07/22/120818
BEM
http://howtohp.com/2013/12/27/sass-bem/
4. コンパイル遅い…
コンパイルは遅い。 数百行程のcssを10ファイルくらい生成するとかであれば全然遅くはないですが、 数千行レベルのcssを300ファイル・スプライト画像を300個ぐらい生成するような案件になると、 コンパイル時間が30分程度かかってしまいます。。つらい。
とまあ、
cssを生で書くより、はるかに良いです。
これだけじゃザックリしすぎて何が言いたいのか分かんない!と思うので、
今後具体的に書いていきたいと思います。
それと、ちょっとcompassをカスタマイズした部分もあるので後に記事にします。
以上!
登録:
投稿
(
Atom
)
0 件のコメント :
コメントを投稿