compassが遅い件 vol.2

itinao 22:00 , , , 0 件のコメント

「compassが遅い件 vol.1」の続きです！

今回は、image-width/image-heightの高速化手法を記載します！
（ディレクトリ構成等々は、vol.1と同様です。

はじめに

前回はconfig.rbに追記していきましたが、今回もそうなります。

この調子で追記しまくっていったら、煩雑になってしまいます。。
そこで、カスタマイズしてる部分を分離しましょう！

カスタマイズしてる部分を分離する

簡単です。
$ cp -ip config.rb _config.rb
$ vim config.rb
⇒ 前回追記したところを全部消して、下記を追記する
# ロードパスにカレントディレクトリを追加
$:.unshift File.dirname(__FILE__)
# 独自設定の読み込み
require ('_config.rb')
view raw 2compass1.rb hosted with ❤ by GitHub

$ vim _config.rb
⇒ 前回追記したところのみにする

以上です。量が増えたら、機能ごとにファイル分けてもいいかも。

image-width/image-heightの高速化 事前準備

測定のために、準備していきたいと思います。

1. 適当な画像を配置する
$ mkdir images
⇒ このディレクトリの中に、「200px.png」を入れておく。（画像なら何でも良いです

2. scssファイルを作っておく
$ vim sass/test.scss
@for $i from 1 through 10000 {
.test#{$i} {
width: image-width("200px.png");
height: image-height("200px.png");
}
}
view raw 2compass2.sass hosted with ❤ by GitHub

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に追記します。
module ::Compass::SassExtensions::Functions::ImageSize
@@dimensions_cached = {}
def image_dimensions(image_file)
if @@dimensions_cached[image_file.value].nil?
options[:compass] ||= {}
options[:compass][:image_dimensions] ||= {}
options[:compass][:image_dimensions][image_file.value] = ImageProperties.new(image_path_for_size(image_file.value)).size
@@dimensions_cached[image_file.value] = options[:compass][:image_dimensions][image_file.value]
end
@@dimensions_cached[image_file.value]
end
end
view raw 2compass3.rb hosted with ❤ by GitHub

実行してみる
$ compass compile --time --force
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
→ 5秒も短縮！

しかしこの修正には問題が、、
watchオプションのときを考慮しておりません。

理想はcompileオプションのときだけにしたいけど、これもzoocompassにオプション追加して使いたい時だけ発動するようにします。

image-width/image-heightの高速化2

_config.rbの修正
# 画像生成のサイズをメモリにキャッシュさせる
DEFAULT_DIMENSIONS_CACHE = false
if ENV['DIMENSIONS_CACHE'] === "true"
DIMENSIONS_CACHE = true
elsif ENV['DIMENSIONS_CACHE'] === "false"
DIMENSIONS_CACHE = false
else
DIMENSIONS_CACHE = DEFAULT_DIMENSIONS_CACHE
end
# image-width/image-heightの高速化
if DIMENSIONS_CACHE
module ::Compass::SassExtensions::Functions::ImageSize
@@dimensions_cached = {}
def image_dimensions(image_file)
if @@dimensions_cached[image_file.value].nil?
options[:compass] ||= {}
options[:compass][:image_dimensions] ||= {}
options[:compass][:image_dimensions][image_file.value] = ImageProperties.new(image_path_for_size(image_file.value)).size
@@dimensions_cached[image_file.value] = options[:compass][:image_dimensions][image_file.value]
end
@@dimensions_cached[image_file.value]
end
end
end
view raw 2compass4.rb hosted with ❤ by GitHub

bin/zoocompassのcustom_optionsを修正(追記)
custom_options = {
'compile_target' => {
'env' => 'TARGET_PATTERN',
'opt' => '--target',
},
'dimensions_cache' => {
'env' => 'DIMENSIONS_CACHE',
'opt' => '--enable-dimensions',
}
}
view raw 2compass5.rb hosted with ❤ by GitHub

実行してみる
$ ./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作りたいなあ。。

以上です！

0 件のコメント :

コメントを投稿

compassが遅い件 vol.1

itinao 10:00 , , , 0 件のコメント
以前、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. コンパイル環境をつくる
任意のディレクトリに移動し、下記コマンドを実行すると、コンパイルに必要なファイル/フォルダが生成されます。
$ compass init
↓が生成される。
config.rb
sass
stylesheets

2. とりあえずコンパイルしてみる
$ compass compile --time
⇒ すると、コンパイルが走っていることが確認できます。
※ --timeオプションでコンパイルにかかった時間が表示されるので、今回は毎回このオプションをつけて実行する

実験する

compassのconfigファイル(config.rb)でcompassの処理を上書きすることができると記述しましたが、
本当に上書きできてるの？ってことを実験したいと思います。

compassでコンパイルする対象を取得するメソッドはこのような実装

config.rbに対して下記のような修正を加える(筆者はconfig.rbの下部に書いている)
module ::Compass
class Compiler
# 元のソース
def sass_files(options = {})
p "here!!"
exclude_partials = options.fetch(:exclude_partials, true)
@sass_files = self.options[:sass_files] || Dir.glob(separate("#{from}/**/#{'[^_]' if exclude_partials}*.s[ac]ss"))
end
end
end
view raw compass1.rb hosted with ❤ by GitHub

⇒ この処理は、既存のメソッドをそのままコピーし、間に「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に対して下記のような修正を加える。
### コンパイル対象を絞り込みするオプション
# 指定がない場合のコンパイル対象
DEFAULT_TARGET_PATTERN = "IE"
# 値にマッチするscssファイルをコンパイル対象として絞り込む
SASS_FILE_PATTERNS = {
"IE" => "^.*ie.*$",
"PRINT" => "^.*print.*$",
}
TARGET_PATTERN = DEFAULT_TARGET_PATTERN
### コンパイル対象を絞り込む対応
module ::Compass
class Compiler
def sass_files(options = {})
exclude_partials = options.fetch(:exclude_partials, true)
opt_sass_files = self.options[:sass_files]
# ファイル指定あり
if opt_sass_files
return opt_sass_files
end
# ファイル指定なし
sass_files = Dir.glob(separate("#{from}/**/#{'[^_]' if exclude_partials}*.s[ac]ss"))
##### 取得したsass_filesを操作することで、コンパイル対象を変更することができる
target_pattern = SASS_FILE_PATTERNS[TARGET_PATTERN]
# 指定がないので絞り込ままい
if target_pattern.nil? || target_pattern.empty?
return sass_files
end
# 指定があるので正規表現で絞り込み
target_regexp = Regexp.new(target_pattern)
_sass_files = []
sass_files.each do |file|
_file = File.basename(file)
if target_regexp =~ _file
_sass_files.push(file)
end
end
return _sass_files
#####
end
end
end
view raw compass2.rb hosted with ❤ by GitHub

これは何の修正なのか？
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
#!/usr/bin/ruby
command_options = ARGV
# config.rbに渡すパラメータを定義
# 'key' => { // zoocompassで処理を分岐する場合に使うキー(今回は必要ないけど
# 'env' => '', // config.rbで使う環境変数名
# 'opt' => '', // zoocompass実行時に指定するオプション名
# }
#
custom_options = {
'compile_target' => {
'env' => 'TARGET_PATTERN',
'opt' => '--target',
}
}
# custom_optionsのオプションを指定していた場合は、オプションから削除＋環境変数へセットする
custom_options.each do |o,v|
index = command_options.index(v['opt'])
if !index.nil?
# 環境変数へセット
option = command_options.values_at(index + 1)[0]
ENV[v['env']] = option
# オプションから削除
command_options.delete_at(index + 1)
command_options.delete_at(index)
end
end
# compassを実行する
compass_options = command_options.join(' ')
compass_command = 'compass ' + compass_options
system(compass_command)
view raw compass3.rb hosted with ❤ by GitHub

合わせて、config.rbのTARGET_PATTERN部分を下記に修正する（ENVでパラメータを受け取る
TARGET_PATTERN = ENV['TARGET_PATTERN'] || DEFAULT_TARGET_PATTERN
view raw compass4.rb hosted with ❤ by GitHub

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側のソース)に変更がないか要確認。
案件内でやる場合には、みんなに周知しないと。

終わりに

次回以降、これを使って並列実行させた記事も書いていきたいと思います。
やったことを少しずつ記事にしてきますー。

以上！

0 件のコメント :

コメントを投稿

JavaScriptのテストにKarmaを使ってみた

Unknown 17:09 , 0 件のコメント
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を置いて

{
"name": "test",
"version": "0.0.0",
"description": "test",
"dependencies": {},
"devDependencies": {
"karma": "^0.12.17",
"karma-mocha": "^0.1.4",
"karma-chai": "^0.1.0",
"karma-phantomjs-launcher": "^0.1.4"
}
}
view raw package.json hosted with ❤ by GitHub
$ npm install

を行うと必要なパッケージが揃います。


Karmaの設定


Karmaを設定しましょう。 
プロジェクトルートに下記karma.conf.jsを置いて終了です。

module.exports = function(config) {
config.set({
basePath: '',
frameworks: ['mocha', 'sinon-chai'],
files: [
'js/*.js',
'spec/**/*.js'
],
exclude: [
],
preprocessors: {
},
reporters: ['progress'],
port: 9876,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: true,
browsers: ['PhantomJS'],
singleRun: false
});
};
view raw karma.conf.js hosted with ❤ by GitHub

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
describe('Array', function(){
before(function(){
// ...
});
describe('#indexOf()', function(){
it('should return -1 when not present', function(){
[1,2,3].indexOf(4).should.equal(-1);
});
});
});
view raw sample.js hosted with ❤ by GitHub


  • descride
    • ネスト管理可能な階層
  • it
    • 検証内容を書く
  • before/beforeEach
    • 前処理
  • after/afterEach
    • 後処理


Chaiとは
アサーションライブラリです。
should形式/expect形式/assert形式から選べます。
http://chaijs.com/

// Should形式
chai.should();
foo.should.be.a('string');
// Expect形式
var expect = chai.expect;
expect(foo).to.be.a('string');
// Assert形式
var assert = chai.assert;
assert.typeOf(foo, 'string');
view raw sample.js hosted with ❤ by GitHub


実際の手順です。
まずはテスト対象から作っていきましょう。


1.テスト対象のファイルを作る

テスト対象のファイルはkarma.conf.jsのfilesで管理されている必要があります。
`karma init`時に指定するかkarma.conf.jsに追記しましょう。

テスト対象コード
// webroot/js/view_models/hage/hoge.js
function fuga(val) {
return val + ' fuga';
}
view raw hoge.js hosted with ❤ by GitHub



次にテストコードを書きます。

2.テストファイルを作る

テストコードを作りましょう。
こちらもテスト対象コードと同じく対象ディレクトリ配下にする必要があります。

テストコード
// test/spec/hoge_test.js
describe("fugaは", function() {
it("引数にfugaが付きます", function() {
expect(fuga('hoge')).to.equal("hoge fuga");
});
});
view raw hoge_test.js hosted with ❤ by GitHub


これで準備完了です。
実行してみましょう。


テスト実行


プロジェクトルートで下記を実行します。

$ ./node_modules/karma/bin/karma start

karmaへパスを通しておくといいと思います。


実行結果

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/


はい、簡単ですね。

まとめ


今回はKarmaの実行までを紹介していきました。
もう少し詳しいテストの書き方は、また別の記事で書きたいと思います。
SinonJSの使い方もどこかで書きますよー。


0 件のコメント :

コメントを投稿

Skia DebuggerによるCSSプロパティの重み測定 〜測定編〜

itinao 10:00 , 0 件のコメント
今回は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ファイルが開けるようになりました。


次回は、色々測っていきたいと思います。

以上！


0 件のコメント :

コメントを投稿

Skia DebuggerによるCSSプロパティの重み測定 〜install編〜

itinao 1:30 , 0 件のコメント
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を測定することができます。
図 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」チェックボックスをチェックすることでモードが切り替わります。
図1. Enable continuous page repainting

すると、
画面右上に緑色のボックス(描画の処理時間を表すメーター)が出てきます。
図2. 画面を強制的に再描画し続けるモード

このボックスをを表示した上で、
CSSプロパティの有効・無効を切り替えることで描画コストを高くしている原因を探ることができます。（メーターが上下するので。

Skia Debuggerって？

Skiaとは、Googleが開発しているグラフィックスライブラリで、Google Chromeでも使われいます。

そのSkiaのデバッグツールがSkia Debuggerで、このツールを使うとCSSプロパティの重みが測れます。

インストールするもの

XCODE
Google Chrome Canary
Qt
depot_tools
Skia Debugger

インストール手順

記述の順番通りインストール作業してもらえれば、たぶんスムーズに入るはず…

1. XCODEのインストール
https://itunes.apple.com/jp/app/xcode/id497799835?mt=12
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"
$ GYP_DEFINES="skia_os=mac skia_arch_width=64" make debugger
⇒ すると、「out/Debug/debugger.app」にSkia Debuggerが出力される！

・起動
$ open out/Debug/debugger.app
などでdebugger.appを起動させると、↓のような画面が表示されます。

図3. Skia Debugger起動
画面中央下部の、Overviewのタブとかが表示されねえ…
という方は、画面左上の「+」で画面を最大サイズにしてみてください。

Macbook Airだと画面の縦幅が足りないようで、「+」を押さないと表示されませんでした。（筆者もハマりました。


とまあ、install編はこんな感じです。

測定編では、
Google Chrome CanaryとSkia Debuggerを使ってCSSプロパティの重みを測定していきたいと思います。

以上！

0 件のコメント :

コメントを投稿

Webフロントエンドの開発環境

itinao 22:55 , , , 0 件のコメント
以前、筆者が担当している案件ではcompassを使用している。と記述しましたが、

他にはどんな開発環境だったのかを紹介したいと思います。

なんの開発をしている？

webviewを使ったスマートフォン向けのアプリ開発。

どんな役割の開発者がいる？

サーバーサイドエンジニア
フロントサイドエンジニア←筆者ここ

フロントエンドの開発環境

<javascript>
フレームワーク：knockout.js
altjsは未使用。
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と連動し、自動デプロイする。

どんなフローでデプロイするの？

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で書く。
メモリ管理大変そうだけど、シングルページでつくる。

以上！

0 件のコメント :

コメントを投稿

compassで運用しての感想。

itinao 20:25 , 0 件のコメント
現在筆者が担当している案件ではcompassを使って運用していて、 数千行レベルのcssを300ファイル・スプライト画像を300個ぐらい生成しています。 異常に規模が大きい。 今回は、使ってみての感想を大雑把に書いていきます。 のちのち掘り下げて書いていこうかなーと思います。

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をカスタマイズした部分もあるので後に記事にします。
以上！

0 件のコメント :

コメントを投稿

登録: 投稿 ( Atom )