トップ «前の日(11-22) 最新 次の日(11-24)» 追記

2005-11-23

_ listupgrade 20051123

めっちゃシンプルになりました orz

改めてこれは何かってことを書いておくと

  1. FreeBSD の ports で、新しいバージョンが出ているものを
  2. オレ的美観で過不足なく美しく出力してくれる*1

そんなツールです。今回のバージョンは、

  • portversion と awk に依存するようになりました*2
  • awk なのに行末に ; がついているのは Emacs の awk-mode の挙動に合わせたからです
  • pkgdb に矛盾がある場合とかはとりあえず考えてません
#! /usr/bin/awk -f
# -*- awk -*-

BEGIN {
  num    = 0;
  maxlen = 0;
  while ( "portversion -v" | getline ) {
    if ( $3 !~ /up-to-date/ ) {
      num++;
      item = $1;
      if ( length( item ) > maxlen ) {
        maxlen = length( item );
      }
      ver = $7;
      sub( /\)$/, "", ver );
      port[num]   = item;
      latest[num] = ver;
    }
  }

  for ( i = 1; i <= num; i++ ) {
    printf( "%-*s --> %s\n", maxlen, port[i], latest[i] );
  }
}

好きにいじって好きに利用してくださいライセンスで。

Tags: Tool

*1 portversion の出力のままだと、いっぱいインストールしてあったときに邪魔くさいし

*2 awk は base に入っているので実質 portversion だけ


2006-11-23

_ PHPUnit って Pear channel ではなくなったのか

PHPUnit 3.0 - Sebastian Bergmann

  • PHPUnit 3 では xdebug を利用した code coverage, selenium を利用したクライアントサイドのテストも統合されているみたい
  • Pear ではなく独自の channel サーバを用意してそっちで全部やるみたい

channel という概念でいろいろ独自に工夫できるようになったのはいいけど、Pear を見ればいいという安心感はなくなってきたな。PHP のライブラリ用の Freshmeat みたいなものがあったらいいのかも。

Tags: PEAR PHP
本日のツッコミ(全1件) [ツッコミを入れる]

_ TrackBack [http://aligach.net/diary/20061207.html#p01 あーありがち Pearifie..]


2007-11-23

_ 自分自身が起動されたかどうかを確認

なんでもかんでもテストしやすいようにということで、夏頃 Perl を書いていて思いついた $0 と __FILE__ が一致したら実行という手法、実は案外ポピュラーだったようで、気をつけて見てみると意外と見かける。

でまぁ、「ちくしょう!すごいこと思いついたと思ったのに!」というのはどうでもいいとして、確認の方法で自分はわざわざフルパスに展開してから比較してたんだけど、実はその必要ないのかな?というのが気になって確認してみた。

Ruby

$0 も __FILE__ も原則同じように取れるってことでいいのかな?

puts '$0       : ' + $0
puts '__FILE__ : ' + __FILE__

こんなのを書いて動かしてみる。フルパスになる場合もならない場合もあるけど、食い違うということはなさそうだ。CLI で起動したときはフルパスになったりならなかったり、ブラウザから CGI で呼び出すとどちらもフルパスを返す。

ということは Ruby において自分自身が起動されたかどうかを確認するためには

$0 == __FILE__

だけを見ればよさげ。

PHP

こんなもので確認*1

print '__FILE__        : '.__FILE__."\n";
print 'SCRIPT_NAME     : '.$_SERVER['SCRIPT_NAME']."\n";
print 'SCRIPT_FILENAME : '.$_SERVER['SCRIPT_FILENAME']."\n";
  • CLI で動かすと __FILE__ だけがフルパス
  • ブラウザからアクセスすると SCRIPT_NAME 以外がファイルシステム上のフルパス
    • SCRIPT_NAME は URI 上の絶対パス

ということは

realpath( $_SERVER['SCRIPT_FILENAME'] ) == __FILE__

を見ればよさげ。

……。

なげぇよ。

他の言語は気が向いたら調べるかもしれませんけど、何か情報がありましたら嬉しいです。

Tags: Ruby PHP

*1 PHP_SELF を使っていいのは小学生まで。


2018-11-23

_ Middleman 4.2.1 + External Pipeline + Parcel 1.12環境を作れた

結構シンプルに作れたと思うので満足してる。

素材

静的サイトジェネレータ再び

Middleman ははるか昔、みんなが話題にする前に触っていたのだけれど、Asset Pipeline なんて許されない、みたいな雰囲気になった v4 からは距離を置いていた。Webpack とか生で触りたくないし。

しかし、いよいよもう一度静的サイトジェネレータを真面目に扱えた方がいいんじゃなかろうかという思うようになって*1、食わず嫌いだった Middleman v4 の External Pipeline をとりあえず使えるようになっておいた方がよさそうだよなーあー面倒くさいなーとか考えていたらふとそういえば2017年末に Parcel を試して*2「production では厳しいけど、お試しならいんじゃね?」という感触を抱いていたことを思い出したので組み合わせて試してみた。

External Pipeline向けassetsはMiddlemanの管轄外に置くべし

いくつか試したみたところ、以下のように Middleman の source/ ディレクトリとは別に置いた方がよさそうだということが分かった。

  • source/ とは別に assets/ を掘る
  • images/, stylesheets/, javascripts/ はその中に
  • これらの中は一切 Ruby で処理しないので erb は置かない

フライング情報も含めてできあがったディレクトリレイアウトはこんな感じ。

.tmp/dist/
source/
  layouts/
assets/
  images/
  javascripts/
  stylesheets/
build/

External Pipelineは外部のコマンドを叩き、結果がどこに生成されるかを指定すること

Middlemanの設定 config.rb としては以下のようになる。

activate :external_pipeline, {
  name:    :parcel,
  command: build? ? 'yarn build' : 'yarn watch',
  source:  '.tmp/dist'
}
..
configure  :build do
  activate :asset_hash
end

build? というのは middleman build コマンドが叩かれたか否かを判別しているらしい。

ここで source というのは middleman 標準の source ディレクトリと同じ意味に扱う場所のことで、呼ぶ出す外部コマンドに対しては

ここで言う source の場所に出力するように設定してあげないといけない。

activate :asset_hash は最後に middleman で source -> build 出力時にファイル名にいい具合に hash を付与しつつ HTML からの呼び出しにもそのファイル名を展開する機能を有効にするもの。要するに cache buster です。

Parcelの準備

  • parcel は zero config のままで ok
  • ただし build 時には HTML からではなく個々の asset の entry point を指定する形(画像は全部でよいと思う)
  • --out-dir をさっきの source と一致させる

コマンドライン引数を全部書くと、

yarn parcel --out-dir .tmp/dist \
            assets/images/**/* \
            assets/javascripts/*.js \
            assets/stylesheets/*.scss

みたいな感じ。

glob の **/* がどの環境でも使えるのかは未確認。とりあえず手元の zsh では動いている。こうしておくと JavaScript の component や Sass の partial などは import や @import からしか読み込まれないで済むようになる。

HTML から build させると parcel が自前でファイル名に hash を埋め込んでしまうので middleman から扱いにくくなるのと、そもそも middleman が処理する前の html.erb を parcel が処理できないため、あくまで個々の JavaScript や Sass の依存性解決とトランスパイルに利用するようにしてある。

※ あと、Middleman 標準だと *.css.scss が Sass ファイルの拡張子になるんだけど、Parcel では *.scss が拡張子になるなどの細かい違いはある。他にもありそう。

External Pipelineの考え方自体はすでに自分も昔からやってたものだと気づいた

分かる人にしか分からないが、この External Pipeline の考え方は Rails の Asset Pipeline 環境で precompile 設定を使うのに似ている。

例えば何かで build 済みの外部のライブラリを app/assets/ 以下に置く場合や、自分で Asset Pipeline の外に Babel などの環境を作っておいてその成果物を app/assets/ 以下に生成し、precompile で指定しておいて Asset Pipeline の世界に取り込む、みたいな感じ。

あくまで最終的な成果物を build して serve するのは Middleman であり Rails だが、その前の source は場所さえ分かっていれば出自は知らなくてよい、という扱い方。なんだ、External Pipeline はかつての自分が考えたことをもっと賢くしただけ*3だった。

できたリポジトリ

wtnabe/middleman-v4-example-with-ep-and-parcel

に置いた。

package.json に sass が追加されているけど、これは parcel の autoinstall で入ったもので、Sass 使わないなら不要。とは言え Web サイトをこさえる際に JavaScript だけ書ければあとは不要ということはまぁあり得ないので、動作確認を兼ねて入れてある。

参考

*1 理由は Decoupled すべきだと思うから

*2 その時の日記はなかった。Kanazawa.rb でライブで喋っただけでスライドもない。その後 production では Nuxt の方に突っ込むことになる。

*3 そこがポイントなんだけど