2011/12/01(木)[Perl5] 騙されたなぁorz

Perlにて UNIXドメインソケットを使う際の話。 どうやるんだっけかな? ということで、すぐに思い出せないので、 Perl CookBook 第一版 に掲載されているものを、「こうだっけかな~」と思いつつ参考に。
use IO::Socket;

unlink "/tmp/mysock";
$server = IO::Socket::UNIX->new(LocalAddr => "/tmp/mysock",
                                Type      => SOCK_DGRAM,
                                Listen    => 5 )
    or die $@;

$client = IO::Socket::UNIX->new(PeerAddr  => "/tmp/mysock",
                                Type      => SOCK_DGRAM,
                                Timeout   => 10 )
    or die $@;
しかし、はっきり言って騙されました。 見かけ上は起動するけれど、実際はソケットファイルが作成されないです。 これが、現行で正しい例:
use IO::Socket

my $socket_path = '/tmp/wibble';
unlink($socket_path);
my $server = IO::Socket::UNIX->new( Type => SOCK_STREAM,
                                    Local => $socket_path,
                                    Listen => 5 )
   or die("Can't create server socket: $!\n");

my $sock    = $server->accept() or die("Can't accept connection: $!\n");

my $client  = IO::Socket::UNIX->new( Type => SOCK_STREAM,
                                     Peer => $socket_path, )
   or die("Can't connect to server: $!\n");
LocalAddr ではなく Local 、 PeerAddr ではなく、Peer です。

今更ながら気付いたのですが、Perl CookBook 第一版 は、2001年刊行の本でした。
Perl 4 から Perl 5 に移行して間もない頃で、確かにハッシュパラメータ名などは違っていたかも・・・です。

2011/10/02(日)PDFJ は perl5.12 では動作しない模様

今まで、当方では、PDF を perl で出力する際のモジュールとして、 PDFJ を使っております。
日本人による日本語の解説などあって重宝 ← 英語判らない者にとって重要

していた訳だが、perl 5.10 用にパッチあてても駄目ぽい。
どこかで無限ループになっているようで、いつまでたっても処理が終わりません。

世の中は PDFJ よりは、PDF::API2 を使わせたいらしいが、どれも定型フォーマットを別途PDF にて作成し、それに差し込みする形態の事例ばかりで、適用したいシステムでは全く参考にできない。。

項目数にあわせて罫線を動的に引く形ですが、定型フォーマット方式では、これが出来ないというわけです。

かといって、日本語の説明があまり無くて、結局使い方がよく判らずという状況。
ぢゃあ、PDFJ を改造すれば? という話になるのでしょうが、そういう時間取れないというわけで。。orz

どうにかしたいですが、どうしようも出来ないので、PDF 出力できないのを我慢してもらうしか・・・

〔追記 2012/02/02〕
 このあとすぐに気づいて、無限ループに対処する内容として、 「Safe に対するパッチ」というものを入れましたが、これは Safe 2.27 に対するもので、最新は 2.29 になっており 、このバージョンにおいては、対処されており、パッチは必要ないです。

 ですが、無限ループしなくなっただけで、今度は、不明なエラーを吐かれる状況。
 原因を追いかける時間は全く取れないので、ほったらかし状態になっていますorz

2011/09/27(火)perl CPAN ExtUtils-MakeMaker のインストール時ハングアップ

perl の拡張モジュールをインストールする際、CPAN ( http://www.cpan.org/ ) のお世話になっている方々は非常に多いと思いますが、これは 数ヶ月前から悩んでいる内容。

同じ環境による同じ現象のバグ報告(#70232)が上がってはいます。
https://rt.cpan.org/Public/Bug/Display.html?id=70232

英語がダメダメなσ(^^) はこういう場に出れないのだが。。orz

 --- ここから
Manifying blib/man3/ExtUtils::MM_Any.3
  MSTROUT/ExtUtils-MakeMaker-6.59.tar.gz
  /usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl "-Iblib/arch" "-Iblib/lib"
"-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib','blib/arch')" t/*.t
t/00compile.t ............. ok     
t/arch_check.t ............ ok   
t/backwards.t ............. ok   
t/basic.t ................. ok       
t/build_man.t ............. ok   
t/cd.t .................... ok   
t/config.t ................ ok   
t/dir_target.t ............ ok   
t/FIRST_MAKEFILE.t ........ ok   
t/fix_libs.t .............. ok   
t/fixin.t ................. ok   
t/hints.t ................. ok   
t/INST.t .................. ok    
t/INST_PREFIX.t ........... ok    
t/INSTALL_BASE.t .......... 1/20 
 --- ここまで

t/INSTALL_BASE.t のところで、こんな感じでハングアップし、crtl+C でテストを中断する羽目になります。
このモジュールが 6.58 になったときからの現象で、perl のバージョンは 5.12 でも 5.14 でもこの現象は発生。現在の公開バージョンは 6.59 ですが、一向に解決されていません。

とりあえず、当方は、 force install ... で凌いでいます。

2011/09/12(月)携帯向け音声ストリーミングファイルの形式

自分メモ。

docomo
3gpファイル
AAC LC モノラル ビットレート=22kbps サンプルレート=16kbps
ファイルの最大サイズ 10Mbyte

au
3g2ファイル
AAC LC モノラル ビットレート=22kbps サンプルレート=16kbps
ファイルの最大サイズ 2Mbyte

softbank
3gpファイル
AMR-NB モノラル ビットレート= 8kbps サンプルレート=8kbps
ファイルの最大サイズ 300kbyte

上記でないと、どうも上手く再生できないことが多い。
一番制限が厳しいのはソフトバンクで、このパラメータ以外では再生がまともに出来ない。
音質も極限まで落とす形になります。

特にファイルサイズが致命的で、約4分以上の音声ストリーミングは不可能です。
その点、docomo は 10Mbyte で AAR LC であれば、ステレオで 128kbps でも再生できます。但し、10MByte の制限に注意が必要です。

2011/01/17(月)CGI に使う言語

いわゆる、ここではプログラム言語に何を使うか? という話。

日本では、
PHP , Java というのがもてはやされている模様。
ですが、これはちょっとガラパゴス化している可能性が最近出てきた感ありです。
元々当方は、メンテナンスの点で PHP は否定的、 Java は無駄に高性能なハードウェアを要求する点で否定的。

当方的に推奨できるのは Perl です。あと、ruby。C言語や C++,C# もありです。
こう書くと、嘲笑の対象なんですな、、しかしです。嘲笑するような奴らは、はっきり言ってITゼネコンに洗脳されています。

Java は、ITゼネコンのひとつである、富士通が主に推進し、ごり押ししました。
それが実体。資金力に任せてAPIを提供してきたので、そこそこ使えるのでしょう。
しかし、無駄にハードウェアを高性能化することを要求されるため、ハードウェアの売り上げに繋がる、という商業的な理由があります。
だから、当方はそういうのは承服できないのです。

PHP は、バージョンアップの度に、過去の互換性検証を強要されます。
これだけでもうメンテナンス性がダメダメです。
作りっぱなしなら問題ないけれど、ここでも「互換性検証」という名目で売り上げ増や維持に繋がる、という商業的理由があります。
PHP もITゼネコンが半ばごり押しした言語。

一方で、Perl は10年前に作成したものであっても、セキュリティ問題等さえなければ、何の問題もなく、さくっと動作するのです。こういうのを「後方互換性が優れている」と評価します。Windows で言えば、 Windows 95 の時代に作ったアプリケーションが、Windows 7 や Windows XP でも何の問題もなく、さくっと動作するという感じです。

ruby 、C++、C# なんかも、そんな傾向です。
perl であれば、商業的なことで、無駄なことしなくて済むのです。
だから、米国やインドなどの日本以外の国では、Perl や ruby が見直されてきています。

だが、商業的には都合が悪いかもしれません。
日本のITゼネコン達は Perl や ruby を使うことは否定的です。

若干話題から脱線しますが、「フレームワーク」というプログラム制作上の枠組みを設けることが、均質で質のよいプログラムを作る礎と思い込んでいる勘違いマネージャーもおり、ますます日本のソフトウェア産業 の未来は懐疑的です。

無駄削減を従業員に強要する企業が、顧客に無駄を強要しているのです。
システム開発は、ウチのような中小の方がいい仕事できます。
ただ、ITゼネコンの下請け会社のようなところは避けましょう。

弊社は、ITゼネコンの下請けはしていません。下請けになれば、技術者は育たない。それが体感として判っているからです。
だから、最初からプロジェクトを任された場合に限るのですが、ある程度の能力的自信はあります。

2010/12/20(月)原因は M$社なのに、、、

12/16 頃から IE7/IE8 で文字化けするとの連絡が、、
当初、原因判らず、挙句の果てには、当方が同時期に提供したシステム更新のせいでは?

との話しもあったが、原因は、Windows Update によって、IEでiso-2022-jp (JISコード) な文字コードが判別出来なくなったもの。
参考資料→ [MS10-090] Internet Explorer 用の累積的なセキュリティ更新プログラム

なので、 12/15 以降公開の Windows Update を行い、IE にて iso-2022-jp なサイトを閲覧しようとしたときのみ文字化けが発生するわけです。
弊社サイトは、この条件で見事に文字化けするようになりました、、
Firefox や Chrome では、この問題は起きません。

本来、サーバサイドにて対応すべき問題ではありません。
しかし、IE ユーザ層は自力解決困難なユーザ層が大半なので、完全に無視するわけにもいきません。

結局、兼ねてから予定していた弊社サイトの UTF-8 化を前倒しでやってしまいました。
損害賠償をM$社からもらえるわけではありません。
しかし、損害を被っています。

尖閣諸島近海で、中国籍の漁船が海上保安庁の巡視船に意図的体当たりして明らかな「公務執行妨害」なのに無罪放免され、その様子を撮影した動画を政府の意図に反して公開した公務員が罪に問われるということに 似ています。

ユーザサイドに立てばかなり大きな問題ですが、殆ど騒がれませんでした。
ここからして、思考回路の何かが変だ。

権力か覇権あれば、何やっても許されるんですか。おかしな社会だ。

2010/11/25(木)javascript なクロスフェード表示

表示が切り替わるときに、新旧の内容が交差するような感じでゆっくりと切り替わるようなものを「クロスフェード表示」といいます。
音楽でも曲が入れ替わる時に使う常套手法です。

散々既出ですが、メモ代わりということで、、
提供時期は少し古いですが、最新のIE8,Firefox 3.6,Chrome で動作確認しました。

先ず、クロスフェード Javascript をダウンロード し、Webサーバにアップロード。

次に、対象がある HTML ファイルに以下の一文を <head> - </head> の間に追記。
<script type="text/javascript" src="bsn.Crossfader.js"></script>


次に、実際にクロスフェードさせたい内容を記述。
<span id="disp1">文字列1</span>
<span id="disp2">文字列2</span>
<span id="disp3">文字列3</span>

<div> 要素を使う説明が多いらしいですが、id 属性が付与できる要素であれば、何でもいいようです。
最後に、上記記述を行った直後の位置に、以下のような記述を行います。
<script type="text/javascript">
var cf = new Crossfader( new Array('disp1' , 'disp2' , 'disp3'), 1800, 4500 );
</script>


外部ファイルにしても良いです。
最後の2つの数値はフェードエフェクトの時間と、要素の表示時間の設定です。
この例だと、
* フェードエフェクトの時間 : 1800ms
* 各要素の表示時間 : 4500ms

のようになります。
まぁ、特定の要素だけ長く表示するようなことは、スクリプト改造でもしないと出来ません。あとはお好みで。

2010/10/13(水)SoftBank 3G携帯はある意味デリケート

某携帯サイト制作で、気づいたこと。
UTF-8 いわゆるUnicode で制作する場合に特に注意すべきこと。
<meta content="text/html; charset=utf-8" http-equiv="content-type">
と、最初記述していました。
これだと、シミュレータ上では、きちんと表示されるのに、いざ実機確認すると、文字化けしたり、全く表示されなくなったりするのです。
すなわち、この <meta> タグは無視されます。

ページのコードが Shift_JIS の場合は、特に問題起きません。
保証はしていないようですが、多くの SoftBank 携帯は、ページの文字コードは、デフォルトで Shift_JIS であると決め打ちする挙動のようです。

文字コードを指定する <meta> タグは以下のとおりに記述しないと、正しく認識されないようです。
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
パラメータの順番・値はこの通りにしないと駄目です。

このことについて携帯キャリアに質問しても『仕様です』と突っぱねられる(少なくとも Vodafone時代は そんな対応だった)ので、時間の無駄です。

なぜ Unicode で制作しているか。
それは、比較的近い将来に多言語共存環境が予測できる為です。
ということで参考にどーぞ。

2010/04/20(火)Javascript での画像情報取得

久々かと思ったら、また Javascript の話。
    function check_image(uri) {
    imgobj = new Image() ;
    imgobj.src = uri ;
    var iwidth  = imgobj.width ;
    var iheight = imgobj.height ;
    var sparam  = 'width=' + iwidth + ',height=' + iheight + ',toolbar=0,menubar=0,scrollbars=0' ;
    subimg = open(uri, "imgdisp", sparam) ;
  }
上記のように記述したら、子ウィンドウがパラメータ uri で指定する画像のサイズに合わせて開く計算だったのだが、1回目に所定より小さいサイズの子ウィンドウが開き、そのウィンドウを閉じた上でもう一度実行させると、やりたいことが出来るという現象。

uri に指定するのは、画像のURLを指定するようにしていますが、これがフォームでアップロードさせた画像ファイルなせいか、適切な拡張子をつけないせいか、どうにも上手くいきません。

結局、CGI 側にて、アップロードした画像ファイルのサイズを抽出し、上記の Javascript にそのサイズを指定するようにすることで回避しました。こんな感じ。
  function check_image(uri,iwidth,iheight) {
    var sparam  = 'width=' + iwidth + ',height=' + iheight + ',toolbar=0,menubar=0,scrollbars=0' ;
    subimg = open(uri, "imgdisp", sparam) ;
  }

2010/03/19(金)最新版のChrome でJavascriptの不具合?

現象の確認に何時間も填まったのでorz
先ず、提起のJavascript
  function rateing_submit() {
    var formElem = document.getElementById('form1') ;
    formElem.submit() ;

    window.opener.location.reload() ;
    self.close() ;
  }

続いて HTML側
<form name="form1" id="form1" action="/cgi-bin/request.cgi" method="POST">
  <input type="hidden" name="mode"  value="addrate">
  <input type="hidden" name="lisid" value="21">
  評価する曲 :ベートーベン - 第9<br>
  現在の評価 :3.0 (3 人の平均)<br>
  評価をどうぞ :
  <select name="addrate">
    <option value="1">1</option>
    <option value="2">2</option>
    <option value="3" selected>3</option>
    <option value="4">4</option>
    <option value="5">5</option>
  </select><br>
  <input type="button" name="action" value="評価登録"onClick="javascript:rateing_submit()">
嫌い→気に入った<br>  1・・・・5<br>
</form>
こうすると、Chrome では、Javascript の formElem.submit() が全く機能しません。
サーバにPOSTデータが行かないのです。HTML側で method を GET に変更しても現象は同じ。
これは、Chrome 固有で、手元のFirefox 3.6、IE8 では問題なく機能します。
別の関数などあるのかどうかも調べがつきませんでした。
おそらく、Chrome のJavascript で単純にバグがあるものと考えています。