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

2011/01/06(木)HTML5対応状況

2017/10/12 04:15 雑多なトピック
毎年の事だが、虚礼廃止(虚礼省略というべきか・・)ということで、、

これまた毎回の事で散々他サイトで既出だが、自分メモということで。
まだ正式に仕様確定したという話しを聞いておらず、実装先行状態だが、、

http://findmebyip.com/litmus/

数ある HTML5 対応状況紹介サイトの中では、最も客観的なので、多くの紹介がある模様。
やはり目立つのは、IEの対応の低さ。

IE7 まで「俺様ブラウザ」路線で結果的に当方を含め、制作者が駆逐したいブラウザに異口同音に必ず挙がるのが今の Internet Explorer であり、、

数年後、HTML5 でまた悩むのかな。既に HTML5 への移行が制作サイドで起きており、このままの流れだと、IE専用に HTML4 で制作しなければならない時代が来る可能性がやや高い。

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/27(土)真冬並み寒気流入



この時期に0℃前後まで気温が下がるのは、珍しくなく、むしろごく普通の状態だったりしますが、今までが平年よりかなり高めで推移してきたので、ちょっと堪えます。

また、この時期の北海道は空から降ってくるものが、雨になったり、雪になったりで、冬支度のタイミングに悩むのが常。
当方は 11/25 に自動車のタイヤ交換して、冬支度を始めました。

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/11/13(土)ハングル文字(韓国語)の入力方法

2017/10/12 04:11 雑多なトピック
技術調査の過程で必要になったので、ちょっとだけ調査を。

提起の件、WindowsXP SP3 であれば、韓国語 IME を追加インストールするだけで可能です。
ただ、日本で広く普及しているローマ字入力はできません。

日本でいうところの、カナ入力に類似した入力が主流の模様。
母音と子音でキーが割り付けられており、その組み合わせで文字を確定するようです。

それはそれでいいのですが、驚いたことに、どうも統一された規格というものが無いらしい。
韓国ですら3つの規格らしきものがあり、北朝鮮と中国の朝鮮族が使っている規格とあわせて、異なる規格が5つ。

日本人から見ると、ローマ字入力できるのが一番とっつきやすい。
だが、韓国ではローマ字入力はどちらかというと、マイナーな入力方法らしい。

個人的には韓国語IMEなんぞ殆ど使う機会無いので、とりあえず差し迫った課題では無いですが :-)

当方の知人に韓国語のローマ字入力ツール(?)を試験的に作った人がいるので、ご入用の方は当方に問い合わせてください。

2010/10/24(日)postgreSQL にて、initdb時と違う文字コードで DB 生成

2017/10/12 04:10 サーバ運営・管理
最新の postgreSQL は、 9.0。
しかし、当方では検証を終えていないので、8.4.x を使用しています。

UTF-8 なDBを作成しようと、
createdb -U hoge -E utf-8 exampledb

としたところ、
createdb: database creation failed:
ERROR: new encoding (UTF8) is incompatible with the encoding of
the template database (EUC_JP)
HINT: Use the same encoding as in the template database,
or use template0 as template.

※見やすいように適当に改行しています。
 実際の表示体裁は、画面幅一杯で折り返して表示します。

という、横文字エラーメッセージ出て作成できません。
散々既出のようですが、メモ代わりということで。。
横文字は解読が苦手orz だが、いろいろサイトを訪ねあたってみると、どうも、template0 を使って生成しろ、ということらしい。。

当方では、initdb (サーバに初期化データベースをインストール)時に、文字コードを EUC-JP にしました。こんな感じ:
initdb -D /db --encoding=EUC_JP --locale=C

この場合、EUC-JP 以外の文字コードでDBを生成する時はこうしないといけないようです。
createdb -U hoge -E utf-8 -T template0 exampledb

これで何事も無かったかのように UTF-8 なDBが生成できました。
何でこんなことになったのかは、知りません。orz

2010/10/21(木)adiary は、ModPerl::Registry ではまともに動作しない

2017/10/12 04:08 サーバ運営・管理
adiary は、AGPLv3ライセンスで提供される、オープンソースのブログシステムです。
携帯電話閲覧にも対応し、wiki も意識しているようです。
記事保存DBに postgreSQL が利用できます。
利用価値の高いソフトウェアです。
Perl(5.6以上のバージョンが必要)で動作し、Apache2 のWorker MPM、mod_perl2 対応としています。

adiary の場合、このmod_perl2 対応というのが曲者。Apache側の設定を、以下のようにしないと、まともに動作しません:

<Directory "*******">
Options ExecCGI
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +ParseHeaders

Order allow,deny
Allow from all
</Directory>

ModPerl::Registry は、1回目の実行で、コード解析結果をバイナリでメモリ上に保持しておき、高速化を図るモード。それ故、200% - 2000% の高速化になるのです。

ModPerl::PerlRunは、Perl インタプリタをメモリ上に保持し、実行の度にコード解析して実行するモード。このモードでは、数10ms 実行時間が短くなる程度。

ちなみに、mod_perl を無効にしても、勿論、きちんと動作します。
変数の初期化を端折っていると、このような不可解な現象になるのです。
perl では、変数宣言しなくても、勝手に未定義値で初期化する仕組みなので、案外あり得る現象です。

adiary で mod_perl がまともに動作しないという方は、Apache上でのmod_perl 設定を確認してみるとよいでしょう。

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/10/05(火)こんなエンジニアはいらない

2017/10/12 04:06 一行放談
・手が汚れるのを嫌がる奴
 ― 泥遊びくらい出来ないと、例外なく頭でっかちになり、求めている本質に基づく判断ができないのです。

・ハンダ付けができない奴
・得意分野以外の技術を見下す奴
・自分で調べないで、何でも聞く奴
 ― 質問は、自力解決できない時にするもの。

・オームの法則すら判らない奴
・自分が設計した回路や装置に最後まで責任持たない奴