開発日誌 - ジニーフレーム - プロジェクト管理ツール

なんだか体調悪いteruchiです。

WordPressのプラグイン開発時のデバッグに関するメモです。

wp-config.phpの最後の行に

error_reporting(-1);

と加えます。

これでPHPのケアレスミスも表示されます。

私、Arrayの区切りに「,（カンマ）」入れ忘れて、
デバッグに小一時間かかりました（汗

あ、wp-settings.phpの読み込みの後に記述するのがポイントです。
wp-settings.phpの中でerror_reportingの指定があるので。

Top

暑くて半分溶けたteruchiです。

macportsでインストールしたApacheを使ってて、
ディレクトリにftpしようとしたら書き込めなくて嵌りました。

まずはいつものように、

$ chmod g+w hoge

でパーミッション変えて、

$ sudo vim /etc/group

_www:*:??:teruchi

とかやってみる。

だめだ書き込めね。

「osx /etc/group」ってぐぐって思い出しました。
OS XはユーザーとかグループをOpenDirectoryってので管理してるんでした。

で、ここを見て
Mac OS Xのユーザとグループ – ksaitoの日記

$ dscl . read /Groups/www

してみると、なるほど「GroupMembership」って項目があって自分がいない。

$ sudo dscl . append /Groups/www GroupMembership teruchi

とやって、
見事書き込めたのでした。

dseditgroupってコマンドもあるらしい。
How to add a user to a UNIX group – Mac OS X Hints

Top

teruchiです。

CSSが複雑になって来たらSCSSを使いましょう。

利点は以下

・ファイル分割できる

　１ページの中で多くのパーツがある場合、パーツ毎にファイルを分ける。
　ビルド後は１つのファイルにまとめる。

・恥ずかしいコメントが書ける

　ビルド後はコメントを書き出さないようにできるので、
　恥ずかしいコメントも書ける。

・構造的に書ける

　DOM構造に沿って階層的に書けるので、
　メンテしやすい。

・共通化できる

　変数が使えるので、ボーダーカラーなどを共通化しやすく、
　修正範囲を局所化できる。

・セオリーがわかる

　Compassのライブラリを使えば、グラデーションやシャドーの書き方に、
　セオリー的な書き方ができる。

マイナス面

・ビルドが必要

　修正してすぐにブラウザを読み込み直しても反映されない。

　makeを使ったビルドの仕方はこちら。
　CoffeeScriptとSASS（SCSS）をMakefile（makeコマンド）でビルドする

・デバッグに一手間増える

　DOMインスペクターで修正ポイントを見つけても、
　SCSSファイル上の修正ポイントを探すのに一手間。

make使えるとかなり気持ちいいですよ。

Top

teruchiです。
一年ぶりにブログに投稿してみる。

CoffeeScriptとかSASS(SCSS)はコンパイルする必要がある。

gruntを使ってビルドするのがどうも一般的らしい。

例えばgruntファイルはこんな感じ。

module.exports = function(grunt) {

	grunt.initConfig({
		// CoffeeScript
		coffee: {
			'webroot/js/app.js': [
				'web-assets/coffee/app-view.coffee',
				'web-assets/coffee/app-model.coffee'
			],
			'webroot/js/common.js': [
				'web-assets/coffee/common.coffee'
			]
		},

		// SASS
		sass: {
			dist: {
				options: {
					compass: true // Compassライブラリを使用
				},
				files: {
					'webroot/css/default.css': [
						'web-assets/sass/default.scss',
						'web-assets/sass/default-form.scss'
						],
					'webroot/css/dialog.css':
						'web-assets/sass/dialog.scss'
				}
			}
		}
	});
	
	// gruntタスクライブラリを読み込み
	grunt.loadNpmTasks('grunt-contrib');
	grunt.loadNpmTasks('grunt-contrib-sass');

	// デフォルトで実行するタスク
	grunt.registerTask('default', 'coffee sass');
};

しばらくこんな感じで使っていたのだが、
ファイルが増えてくると、
いちいち全てのファイルに対して処理が走るのが邪魔臭くなる。

例えばCoffeeScriptの方は、キャッシュとかで再コンパイルまではしないけど、
coffeeコマンドは全部起動してる
sassの方もキャッシュファイルが作成されるから、フルではコンパイルしてないはずだけど、
やたら時間がかかる。

いろいろ調べてみたのだが、昔よく使ってたmakeコマンドを思い出した。
Pro*Cのプロジェクトとか、UNIXのミドルウェア開発のプロジェクトではお世話になったもんだ。

makeなら、更新されたファイルから、
依存関係をチェックして、必要なファイルだけビルドしてくれるので、
CoffeeScriptとかSASSにはぴったりだ。

いきなりMakefileの説明。

ディレクトリ構成は以下

app
├web-assets
│├sass
│└coffee
│
└webroot
　├css
　└js

SASS用のMakefileはこんな感じ

# コマンド
SASSC = sass -C
COMPASSC = sass --compass -C

# PATH
CSSPATH = ../../webroot/css
SASSPATH = .

# 依存関係とコンパイルコマンド
all: $(CSSPATH)/default.css $(CSSPATH)/dialog.css

$(CSSPATH)/default.css: $(SASSPATH)/default.scss $(SASSPATH)/default-form.scss
	$(COMPASSC) $(SASSPATH)/default.scss > $@
	$(COMPASSC) $(SASSPATH)/default-form.scss >> $@

$(CSSPATH)/dialog.css: $(SASSPATH)/dialog.scss
	$(SASSC) $< > $@

ビルドのコマンドとかはうまく共通化したかったのだが、できなかった。

続いてCoffeeScript用のMakefile

# コマンド
COFFEEC = coffee

# PATH
JSPATH = ../../webroot/js/gf
COFFEEPATH = .

# 依存関係とコンパイルコマンド
all: $(JSPATH)/app.js $(JSPATH)/common.js

$(JSPATH)/app.js: $(COFFEEPATH)/app-view.coffee $(COFFEEPATH)/app-model.coffee
	$(COFFEEC) -j $@ -c $^

$(JSPATH)/common.js: $(COFFEEPATH)/common.coffee
	$(COFFEEC) -j $@ -c $^

こちらもコンパイルコマンドの共通化がうまくいかなかった。
C言語ならもうちょっとうまく出来るのだけど、ビルドの手順が違うから難しい。

2013/01/10追記）
「$^」を使う事で、依存ファイル全てに展開される

appディレクトリ直下に以下の様なMakefileを置いておけば、
一括でビルドできる。

all:
	cd sass;make
	cd coffee;make

うーん。やっぱmakeコマンドは優れものだ。
10年以上Makefileをいじってなかったので、研究し直そう。

antの方がもうちょっとうまい事書けるんだろうけど、
XMLが苦手なんだよね。。。

Top