-
WordPressのデバッグにはwp-config.phpの最後にerror_reporting(-1);を入れる
投稿 25 2013年8月 by in 開発日誌 with 0 comments
なんだか体調悪いteruchiです。
WordPressのプラグイン開発時のデバッグに関するメモです。
wp-config.phpの最後の行に
error_reporting(-1);
と加えます。
これでPHPのケアレスミスも表示されます。
私、Arrayの区切りに「,(カンマ)」入れ忘れて、
デバッグに小一時間かかりました(汗あ、wp-settings.phpの読み込みの後に記述するのがポイントです。
wp-settings.phpの中でerror_reportingの指定があるので。 -
Mac OS XでApacheのwwwユーザーで作成したディレクトリに書き込む
投稿 9 2013年8月 by in 開発日誌 with 0 comments
暑くて半分溶けた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 -
Sass (SCSS)を使うべき理由
投稿 28 2013年1月 by in 開発日誌 with 0 comments
CSSが複雑になって来たらSCSSを使いましょう。
利点は以下
・ファイル分割できる
1ページの中で多くのパーツがある場合、パーツ毎にファイルを分ける。
ビルド後は1つのファイルにまとめる。・恥ずかしいコメントが書ける
ビルド後はコメントを書き出さないようにできるので、
恥ずかしいコメントも書ける。・構造的に書ける
DOM構造に沿って階層的に書けるので、
メンテしやすい。・共通化できる
変数が使えるので、ボーダーカラーなどを共通化しやすく、
修正範囲を局所化できる。・セオリーがわかる
Compassのライブラリを使えば、グラデーションやシャドーの書き方に、
セオリー的な書き方ができる。マイナス面
・ビルドが必要
修正してすぐにブラウザを読み込み直しても反映されない。
makeを使ったビルドの仕方はこちら。
CoffeeScriptとSASS(SCSS)をMakefile(makeコマンド)でビルドする・デバッグに一手間増える
DOMインスペクターで修正ポイントを見つけても、
SCSSファイル上の修正ポイントを探すのに一手間。make使えるとかなり気持ちいいですよ。
-
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が苦手なんだよね。。。