測る - PHP編

必要に迫られて『ソフトウェア見積り』を読み始めている。チケットの時間なんかもそういうネタなんだけど、この本を読んで、数えられるものをとにかく数えるということから始めている。

で、手元の PHP のコードをどうにか数えないとなと思ってハタと困った。

  1. PHP にはコメントを取り除いたプレーンな PHP コードだけを取り出す簡単な方法がない
  2. もともとが HTML への埋め込み言語であり、混在しているコードがそこかしこにある。これはどう数えるのが妥当なのか?

php -w はホワイトスペースがなくなって行数が分かんない

上の 1 については

php -w script

によってコメントを取り除いたコードが取り出せるんだけど、こいつは

ホワイトスペースも取り除いてしまうので wc に掛けても行数はカウントできない

という致命的な問題を抱えている。仕方ないので

Twitter / wtnabe: ざっくりPHPの行数を数える。; までを1行として。 …

こんなことをしてみた。

; までを1行として。

 for i in PHPファイルのリスト;
 do
   php -w $i | perl -p -e "s/;/;\n/g" | wc -l
 done | awk '
 {
   sum += $1
 }
 END {
   print sum
 }'

sed が分かんなくて Perl で ; の後ろになくなった改行コードを加えている。本当は自分の書き方だと { の後ろにも改行があった方がいいような気がするんだけどとりあえずざっくりでいいので。

自分の書いたコードに限ると

ちなみに自分のコメントの書き方は phpdoc 用のコメントがほとんどで、書き方としては

/**
 *
 */
class Klass {
  ...
  /**
   *
   */
  function funktion {
    ...
  }
}

みたいな感じ。基本的にRubyコーディング規約をベースにしている。また以前ざっと数えたときに

コード : コメント = 1 : 1

の比率になっていたので、そのまま wc -l して 2 で割るとだいたい正確な数字が出る。これは狙って 1 : 1 にしているわけじゃないんだけど、クラスの説明やらやりとりされるデータ構造なんかを書いていると自然とそれくらいに落ち着くことが多い。ただし時間に余裕がないとこの部分のコメントが真っ先に削られてしまう。1

混在スクリプトはそのまま wc -l でもいいかも?

数え始めて

HTML と PHP の混在スクリプトはどうするのがよいか?

という疑問が出てきた。こうした混在スクリプトには

  1. HTML の比重の大きいタイプ
  2. PHP の比重の大きいタイプ

に大別できるが、いずれも多くのケースで Controller, View 相当のコードは

一直線に上から下へ書くシーケンシャルなコード

となりやすい。?>HTML<?php による HTML 出力はそのコードが実行されたタイミングで問答無用で行われるので、V, C 相当の部分で凝ったテクニックは使えない。従って HTML, PHP 混在スクリプトは

メンテナンス性? なにそれおいしいの?

な状態であることが多い。つまり

とにかく大変な状態

なので、

丸ごと行数を規模としてカウントしちゃうことにした。

ほんとに大変なんだよ、こういうコードのメンテは。恐ろしく生産性低いんだ。やったら長くなるしものすごく繊細なんだ。

  1. 基本的にTDDなのでテストはなくならない。ただし乱暴な確認だけでどんどん進んでしまっている場合もある。 

一区切り

ネタでもなんでもなく。

区切りがついた。あー別に転職したとかでもないです。

ただただ普通に区切りがついたぞと。

そんだけ。

とりあえずしばらく起業はたぶんしないと思うけど

普段はどちらのサイトの記事もスルー力を発揮しまくってるんだけど、今回はどちらもそれなりに真実を含んでいてふんふん、と思った。

そんでもって両者の違いはプロダクトをゼロから作れるかどうか、なのかなぁという気がした。これは Dan の中の人がプロダクトという言葉を使っているからそのまま拝借させてもらっているんだけど、Dan の中の人はプロダクト、GIGAZINE の中の人はサービスを作ろうとしているのかなという感じ。

GIGAZINE というサイトを見れば分かるようにこれは継続して自分のリソースを割き続けなければ成り立たない構造をしている。対して恐らく Dan の中の人の作るプロダクトはそれ自身が価値を生む構造になるのだろうなという気がしている。まぁたぶんにプログラマ的な発想というなんと言うか。最近はソフトウェア産業もオープンソースでサービスとしてサポート業務を付加、というパターンが多くなってるんでしょうけど、プログラムを作るという行程は一つのプログラムに同量のエネルギーを注ぎ続けなければいけないものではない。ガッとやる時期と抜く時期が交互にくるような感じだ1。対してサービス、特に人間相手のサービスというのはそこまでメリハリはつけられない。手の掛かるケース掛からないケースはあるだろうし、ある程度はサービス提供者のスキルによって負荷は増減するが、例えば「しばらく何にもしなくていい時期」なんてものはまず生まれない。

こうした背景があるから GIGAZINE の中の人は続業的な発想に、Dan の中の人は非続業的な発想になるのではなかろうか。

しまった。エイプリルフールなんだから「起業しますた。」にしておけば少しは注目してもらえたかもしれないのに。

  1. というかそもそも Dan の中の人は日本有数のハッカー。同じことを頑張り続けるなんて発想で業を起こすとは思えない。 

今さら MochiKit とか他のライブラリも見てみる

prototype.js しか知らなくて prototype.js すげーって言ってるってことがバレるとちょっとかっこ悪いので1、他のライブラリも調べてみる。と言ってもまずは先人の記録をトレースするところから。

MochiKit は examples にある interpreter.js がすごい。(デモムービーで見ることができる。)あと、Logging や Test があらかじめ考えられているところがとても作りやすそう。単純なライブラリではなく環境に近づきつつあるという意味では Rails 的な気もしなくもない。

が、中身は Python にインスパイアされた関数型プログラミングで、ちょっと今の自分には読みにくい。コメントの入れ方など見た目の部分も今の自分は prototype.js の方が美しく感じる。あと茶々になってしまうし十分に多機能なのでしょうがないけど、どこが Lightweight なんだ?と思わなくもない。

名前空間の使い方は MochiKit の方がいいなーと思う。

Rico とか Dojo とかまだちゃんと見てねっす。ぱっと見たところ、ツールキットって言ってるだけあっって Dojo はブラウザ別の処理とか作り込みやすそう。マニュアルが JotSpot 使っててかっこいい2

  1. ちょっとなのか? 

  2. ミーハーな視点もお忘れなく 

新生 ZDNet Japan オープンとニュースの RSS

http://japan.zdnet.com/

CNET にあった記事がいくつか移転してる。RSS を見るとニュースと blog は CNET で、コラム、連載などのボリュームのあるものやレビュー系が ZDNet って感じなのかな? でも ZDNet にもいっぱいニュース出てるな。というか小分けに RSS を吐いてくれる分、ZDNet の方が扱いやすいな。レビューも RSS で出してくれればいいのに。しばらく見続けてみないとよく分からん。

ニュースの RSS は CNET.com のものが扱いやすくて好きだ。MYCOM PCWEB や asahi.com のものは item の名前しか書かれてなくてイマイチ。@IT も簡単な記述がついてるけど、あれはニュースじゃなくてフォーラムの記事でボリュームもあるので、あの短さではそんなに役に立たない。ということでバランスがいいのは CNET.com のものかなと。

ルビま!

なんと「ルビま」が休刊だそうです。

今回のポイントは満を持しての sixamo 氏の登場と Python の協力を得たことでしょう。素晴らしい。これからもまた違った形での皆さんのご活躍を期待しております。

WEB+DB PRESS 特別総集編

WEB+DB PRESS 特別総集編

基本が Java っぽいので個人的にはあまり嬉しくないんだけど、細かいコラムとか拾っていくとなかなか面白そうな感じ。(まだ目次眺めただけだけど。) 全文検索ツールがあるのは Windows だけなんだけど、OS X の Preview からテキストをコピペできた、pdftotext で取り出せるんじゃないかな。試してないけど。それができれば落ち穂拾いには便利に使えるだろう。けど、pdftotext 3.00 ではダメでしたorz どうしよ、これ。

この総集編、入門記事がいっぱい書いてあるんだけど、これ要らないなぁ。もっと安くしてくれればなおよかったのに。まぁ今でも安いし、ある程度厚さがないと CD を添付しにくいとかいろいろあるんだと思うけど。

BSD Hacks

BSD Hacks

CTM についての記述を発見しただけで即決。面白いなぁ、この本。日本のよくある本では抜けているところがたくさん書いてある。

思いついた!

練習として携帯端末情報 DB を作ろうかな? PostgreSQL でもいいし LDAP でも作れるだろう。

エイプリルフール

スラドでのエイプリルフールネタと他のサイトへのリンクを楽しみにするようになって2年ほど経つが、毎年思うに、この面白さはどのようにネタを考えたのか想像するところにもあるように思う。

言葉遊びかもしれないが、笑いは受動的なものではないと思う。今のテレビはハプニング的な笑いばかりだが、本来笑いってのは共有できる文化や背景がなければ成り立たない、高度なコミュニケーションである。文字ベースの、タレコミドリブンなニュースサイトの笑いであれば、当然テレビのような笑いは期待できない。なんというかそこには知の駆け引きのようなものが必要だ。

それをまったく考慮せずに今年のネタもつまらない、などと文句を垂れるのは無粋の極みではないか。てめえが面白いネタを送ったのでないなら黙っていればよい。スラドにお客様は必要ない。コミュニティサイトなのだから。

だから?

子どもの33%が家族と食事中にメール送信 ネット調査 @asahi.com

ハンバーガーの話なんかこれっぽっちも出てこないし。”ついでに”「現代社会は病んでいる」的な話にしたいのがミエミエすぎ。もっと頭使ってほしい。

この話は携帯だけに簡単に注目しちゃダメでしょ。従来だって電話が団欒を遮ることはあったんだから、それとの違いに注目しないと意味がない。問題は団欒の遮られ方と、メールあるいは電話後の、団欒への復帰のプロセスでしょ。そもそも遮られたり復帰したりっていう団欒がないんだったら携帯以前の問題だし。携帯があろうがなかろうが、団欒はある家庭にはあるし、ない家庭にはない。その事実を踏まえたうえでの設問じゃなきゃ。

単に携帯のおかげで家庭崩壊みたいなバカタレな理屈をこねたいだけな人がどっかにおるんでしょうかね。

まぁ、調査会社がインターネット調査会社だし、母数も小さいので調査そのものもなんだかなですが。

「正直しんどい」

ジャニーズ祭りのはずが剛と翼、あるいは剛と岡田のツーショットのみ、ってどういうことよ。すげー面白かったわ。

あと数時間

http://www.aprilfool.jp/

この辺を参考に楽しみましょう。

About

例によって個人のなんちゃらです