日々の破片
| 著作一覧 |
2007-01-20
_ Linux-X64でFlash9
nspluginをダウンロードする。
とか、スラドを見ながら作業。
と、rpmなのか、と手が止まる。
フランス人のページが見付かったので真似してみる。
$ sudo apt-get install alien linux32 $ wget http://gwenole.beauchesne.info/projects/nspluginwrapper/files/nspluginwrapper-0.9.91.2-1.x86_64.rpm $ wget http://gwenole.beauchesne.info/projects/nspluginwrapper/files/nspluginwrapper-i386-0.9.91.2-1.x86_64.rpm $ sudo alien -d nspluginwrapper*.rpm $ sudo dpkg- i nspluginwapper*.deb
alienってrpmをdebに変換するツールなのか。
$ sudo dpkg -i nspluginwrapper*.deb 未選択パッケージ nspluginwrapper-i386 を選択しています。 (データベースを読み込んでいます ... 現在 114936 個のファイルとディレクトリがインストールされています。) (nspluginwrapper-i386_0.9.91.2-2_amd64.deb から) nspluginwrapper-i386 を展開しています... 未選択パッケージ nspluginwrapper を選択しています。 (nspluginwrapper_0.9.91.2-2_amd64.deb から) nspluginwrapper を展開しています... nspluginwrapper-i386 (0.9.91.2-2) を設定しています ... nspluginwrapper (0.9.91.2-2) を設定しています ...ここまではあっさりできたみたいな気がする。で、Flash9を入れてみれば本当にうまくいってるのかわかるはず。
$ sudo alien -d flash-plugin-9.0.31.0-release.i386.rpm
Warning: Skipping conversion of scripts in package flash-plugin: postinst prerm
Warning: Use the --scripts parameter to include the scripts.
hostname: Unknown host
hostname: Unknown host
Package build failed. Here's the log:
dh_testdir
dh_testdir
dh_testroot
dh_clean -k -d
dh_installdirs
dh_installdocs
dh_installchangelogs
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
xargs -0 -r -i cp -a {} debian/flash-plugin
dh_compress
dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dpkg-gencontrol: error: current build architecture amd64 does not appear in package's list (i386)
dh_gencontrol: command returned error code 65280
make: *** [binary-arch] エラー 1
find: flash-plugin-9.0.31.0: No such file or directory
つい味をしめてalienを使ってみようと思ったら、なるほどアーキテクチャを見ているのか。当り前か。で、素直にtar.gzを展開してテンポラリなディレクトリにコピーしてから、
$ sudo nspluginwrapper -i /usr/lib/plugin-web32/libflashplayer.so /usr/lib/nspluginwrapper/i386/linux/npviewer.bin: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory /usr/lib/nspluginwrapper/i386/linux/npviewer.bin: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory nspluginwrapper: /usr/lib/plugin-web32/libflashplayer.so is not a valid NPAPI pluginなぜだ？ libgtk-x11-2.0.so.0は当然のように入っているのだが。
$ ldd /usr/lib/plugin-web32/libflashplayer.so
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib32/libdl.so.2 (0xf77f8000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf77e5000)
libX11.so.6 => not found
libXext.so.6 => not found
libXt.so.6 => not found
libfreetype.so.6 => not found
libfontconfig.so.1 => not found
libgtk-x11-2.0.so.0 => not found
...
あ、32ビット版のライブラリが必要なのか。面倒になってきたので、また今度にしよう。
と思ったけど、Synapticを見たらia32-libs-gtkというのを発見したのでインストール。
$ sudo nspluginwrapper -i /usr/lib/plugin-web32/libflashplayer.so
あっさりと入った。
$ sudo ln -sf /usr/lib/mozilla/plugins/npwrapper.libflashplayer.so /usr/lib/firefox/plugins
おお、youtubeが見える。でも音が出ない。というところまで。
寝る前に思い付いて（というか気づかないほうがどうかしてる気もするが）32ビットALSAライブラリ(lib32asound2)をインストールして完了。快適な環境だ。
_ どっこい生きてる、蚊帳の中
見本誌をいただいたので読む。
COMPUTERWORLD (コンピュータワールド) 2007年 03月号 [雑誌](-)
米国版の翻訳記事だが、向こうのCOBOL事情というのもすごいな。マイクロフォーカスのCOBOLは.NETなんでVisual Studioで動くのか（富士通だか日立もそういえば出してたのを思い出す）。
というか開発言語の利用状況（複数回答あり）のComputerworldサーベイだと1位のVB（67%）に次ぐ62%の堂々の2位で、3位のJava（61%）を引き離しているありさま。社内アプリケーションの占有率が60%以上の企業が43%、新規開発での利用状況が58%、以前、生越さんが軽く書いてた通り以上の状況になっている。ただ、アメリカ事情かな、と思うのがプログラマの平均年齢が高くて、日本の企業プログラマではちょっとありえないかな、という気もするところ（45〜55歳が52%で過半数越え）。日本の企業のキャリアのあり方だとこの年齢層のプログラマというのはほとんどいないんじゃないかな。おれはそうだけど、特殊といえば特殊な気はするし。なんというか、層の作り方がへたくそで、いつも薄い層しかないような気がしている美しい国（美国のほうじゃなくて）だったり。ミルクレープのような。食べれば甘いがそれだけだ。
#バッチを考えてみろ、現在も標準化が進行中（XMLとかOOコレクションとかIEEEの浮動小数点とか。最後のが現在標準化案策定中というところが、この言語の特色みたいな）とか、メリットから見た論考も入っているので状況はわかりやすい。
あと、以前も思ったんだが、巻末のほうの佐々木、江島、栗原3氏の1ページコラムが、Web上のとはまた違った味わいで読みやすく、おもしろいんだけど（2.0と付けるってのは1998年のBusiness 2.0という雑誌が嚆矢だとか）。エディトリアル（というカタカナ）が強い雑誌という印象はそのへんからも受けてるみたいかも（レイアウトとかページデザインが好きなのが最初に来るわけだが、コンポジションを眺める雑誌というわけではないからだろう）。
#コンピューティングはコンピューティングで土俵は同じなんだよね。
_ 島国っていいね
70年代後半から80年代前半にかけてのUKチャートって不思議だった（カラクリがわからなかったからだ）。Pistolsの大ヒットだの、ブームタウンラッツのラットトリップがチャート席捲だの、トム・ロビンソンの2468モーターウェイだの。
Power in the Darkness (CCCD) [Bonus Tracks](Robinson, Tom)
その後もギャリーヌーマンがカーズで1位とか。
でも、USチャートって、どうでも良いパチンコ屋のBGMにもならないような音楽ばかり。日本のチャートもオフコース（嫌いなのの代表のひとつ）だし。
そのあたりの知識から、チャートのトップってことは、みんながそれを聴いているってことだと想像するわけだから、するとイギリスではコーダ伯爵も森番の老人も子供も大人もみんなトムロビンソンを聴いて拳を振り上げたりしてるのか？ と疑問に思うわけであった。
後になって、そうではなくて、英国は単に音楽マーケットが小さいから、ちょっとある層の人達が買うとそれだけでチャートの上位に入るということがわかったので、納得したわけだった。
プログラミング言語マーケットというのもそんな感じのマーケットだ。
オフコースを好きな連中はオフコースオフコースもちろんオフコースと連呼してるかも知れないが、演歌（しか名前知らないのでいい加減）とかのほうがヒットしてたりして。ましてアメリカじゃ、片方でMTVチャートがあったりしてもやっぱり売れてるのはC&Wだったり。
だから、意味ある調査って、層分けしなきゃだめかも知れないな。
Eコマース系、Webサービス系、企業情報系、企業勘定系、教育関係、研究系（これはさらにどの方面の研究かとかで細かく分類しないとさらに無意味かも）、といった具合にだ。で、それぞれの割合に各系ごとの市場規模を乗じて割合を出す。うむ、COBOLが強いんだろう。でも、企業の時価総額を市場規模の算出に含めると、Pythonがすごく強かったりするかも。
でも、そう分類すると実は意味なんかなくなっちゃうような気がするのだった。
というのは、プログミング言語で肝要なのは、
−種別1
・プログラマが気持ちよく仕事できる
−種別2
・設計者の設計通りにプログラマがメイキング（という妙な言葉をこないだ耳にした）できる
・したがって方眼紙で進捗管理ができる
−種別3
・発注者（多分勘違いしているか騙されている）が、同業者の集まりで「うちは今度〜でシステムを刷新するんですぞ」と自慢できるほど満足を高められる
−種別4
・設計者＝プログラマが、要求に応じてシステムを構築できる／要求者＝プログラマが、必要な結果を出力できる
といった、実際の顧客満足度にどれだけマッチしているか、だからだ。
（実際には何を使っても動くものは作れるのだから、何に着目するかに過ぎない。別の切り口にはパフォーマンスという観点があるが、これは本当に有意な計測が難しいので結局は選択しないのと同じことになってしまう）
おれだったら、上のとりあえず挙げてみた4種別に対して、それぞれ1つのプログラミング言語をマッピングするとすると、どうするだろうか？
1は今のところRubyか、C#か、Javaだな。
2だったら、設計の粒度を方眼紙の升目に合わせるわけだからCにするかも。現実的にはJava、プログラマがいればCOBOLも悪くはない。C#はちょっとインタラクションが入りすぎるので方眼紙には合わなそうだ。
3だったら、社会通念に照らし合わせてJavaだろうな。
4だったら、おれの要求する出力なんだから、Ruby、速度重視かつOffice系ならVBA、あとはJDKかCLRか使いたいクラスの有無でJavaかC#というところ。
#顧客満足度という観点では、COBOLは安心感という点から高めを狙えるのかな？ （そこで将来的な不安感を煽って顧客満足度を低めて別口を売り込むという手口を使っている人たちも居るだろう）
_ そこにあるIPv6
Kazzzさんが恐ろしいエントリーを上げているけど、どの場合にそうなるんだろうか？
僕のVista環境ではまだWebアプリケーションを動かせるようにはなっていないので、以下の簡単なプログラムを試した。
import java.net.InetAddress;
public class HostAddr {
public static void main(String[] args) throws Exception {
System.out.println(InetAddress.getByName("localhost"));
}
}
これをXP SP2と、Vista RTMで実行するとどちらも出力は
localhost/127.0.0.1となる。
using System.Net;
public class Host
{
public static void Main()
{
System.Console.WriteLine(IPAddress.Loopback);
}
}
/*
* 追記： このプログラムは間抜けでした。
* System.Console.WriteLine(IPAddress.IPv6Loopback);
* というのが書けるわけで
* でも、XPSP2だと0000:0000:0000:0000:0000:0000:0.0.0.1
* Vistaだと::1
* となって出力が異なるのはもしかしてすごく嫌な気がするんだが。
* IPAddress.Loopback = IPv4アドレスなんだから当然の結果。
*/
こっちの場合は、どちらも
127.0.0.1
だ。この結果を見ると、VistaだからといってIPv6アドレスが返るようには見えないのだが。
でも確かにVistaでping localhostを実行すると、Kazzzさんのところと同様に::1が表示される。
ジェズイットを見習え |
45〜55歳で過半数っていうのは、アメリカでもありえないでしょう。<br>もしそれが正しいなら、過去20年間、アメリカでは、プログラマーへの就業が極めて速い速度で減少を続けてきたことになります。過去5年間ならともかく、それ以前でアメリカのプログラマーが急速に減ってきたとは、とても考えられません。<br>調査の母集団が相当に偏っているのでは？
それは誤読です（僕の書き方がおおざっぱ過ぎるからですね）。<br>COBOLプログラマの年齢構成の話ですよ。
ちなみに、COBOLプログラマの枯渇問題を相当意識している結果が出ています。（オフショアへアウトソースできなそうだとか、いろいろ）
ああ、なるほど。そういうことですか。<br>ただ IDC による調査 (2000年の時点で COBOL は 4位で Visual Basic の半数未満。http://www.csg.is.titech.ac.jp/~chiba/notes/oosympo02.pdf) や、Dain Rauscher Wessels のレポート (2003年の時点で COBOL は同じく 4位で、割合はさらに少なく Visual Basic の 2割未満。https://www.rbccmresearch.com/drw1.0.4/pdf/0,,6402,00.pdf) と大きく結果が異なっているのがやはり気になります。<br>これだけ違うとすると、その記事の元になった調査と、IDC や Dain Rauscher Wessels の調査とで、標本として用いた集団の種類が大きく異なるということはやはり確かだと思います。実数に近いのはどちらの調査でしょう？<br>Visual BASIC 開発者の裾野の広さから考えて、私には IDC および Dain Rauscher Wessels の調査の方が、実数に近い結果のように思えますが…
Computerworld（というよりIDG）は、詳細は不明ですが（読者調査ではないかと予想しますが）ITマネージャ職にある350人ほどに対する調査ということなので、当然、学術/研究系は含まないでしょう。またITマネージャ職ということから想像するにIT部門を持つ企業と考えられるので、それなりの企業規模の会社でかつアウトソーシングしていない企業を対象にしていると思います（事例として具体名が出てくる企業からもそれが伺えます）。だから、企業コンピューティングという観点からは、実態を反映していると僕は判断していますが。（日経コンピュータ誌の調査と日経コミュニケーション誌の調査では結果が異なる−−前者だとメインフレームが多く、後者だと組み込みが多いというように−−見れば良いと思います）。IDC調査の元のZDNETは期限切れ、Dain Rau……は現在オフライン状態なので調査対象がわからないですが。
> 企業コンピューティングという観点からは、実態を反映していると僕は判断<br>> していますが。<br><br>単に企業というよりは、大企業ですよね。IT専任のエンジニアもいるけど数名で、主に Excel の VBA で事務処理しているなんていうのは、はなから引っかからない。<br>そういう対象であれば、特に驚くような結果ではないと思います。以前に書いた電算機関連労働組合協議会の調査結果も似たような内容でしたし。<br><br>なお、ZDNET は和訳なら以下でまだ読めます (エンコーディングを Shift_JIS と指定する必要があるかもしれません)。ただし和訳では COBOL は数字が少ないためか載ってませんが…<br>http://web.archive.org/web/20031012131906/http://www.zdnet.co.jp/news/0203/27/e_java.html<br>Dain Rauscher Wessels の調査の方も引用元として IDC とあるので、同じようなソースなのかもしれません。もしも必要でしたら、メールもできますが… (yahoo の artonx で届くのでしょうか？)
お、それはありがたいです。お願いします。<br>>特に驚くような結果ではないと思います。<br>そうですか？ 僕ははるかにJavaやVBが進出しているのだと思っていました。というか、新規に作られるCOBOLのプラットフォームに.NET Frameworkが利用される——言語の変換を伴わないというのが現実の話だというのがびっくりです。<br>#記事を読むと、興味深いアクセンチュアのエピソードとかもあったりして、傾向としてはCOBOLが多いというのは数字として意外だったみたいですよ。
メールしました。<br>たしかに新規開発で COBOL を使うのは、エンジニアの立場からすると判断を誤ってるとしか思えませんね。<br>具体的に、新規開発のうちどれくらいが COBOL だとあったのでしょうか。<br>特に驚かなかったのは、既に、電算機関連労働組合協議会の調査や下記の資料を見たことがあったからです。<br>http://www.juas.or.jp/project/survey/it06/2006press.pdf<br>これは日本の2006年のものですが、やはり大企業の割合が多い調査です。<br>この資料の48ページ目によると、ソフトウェアを再構築する場合でも、まだ COBOL は 22% で Visiau Basic に次いで 2位です。(Java はそれに次ぐ 3位で 16.5%)<br>ただ、再構築前だと COBOL は 69% で圧倒的首位、Java は 1% 未満という状況だったので、それまでの慣性が大きいんだと思います。見出しにも COBOL は激減、Visual Basic と Java が急増とありますし。<br>汎用機とかオフコンを利用しておらず、コンピュータの利用をオープン系のシステムから始めた企業だと、これとは全く異なる結果になるのではないでしょうか。
どうもありがとうございます。<br>この調査では新規開発に「ない」が41%、「ある」が58%です。さすがに、本文では新規開発に100% COBOLというのは無いとなっています。<br>事例で意外だったのは20年前にDOS上にCOBOLでシステムを構築して、Windowsへの移行時には.NET用のCOBOLを利用して移植した例（650種 130万行とか書いてある）が出てますから、オープン系、しかもPCを利用したシステムでも、それほど傾向は変わらないのではないかな、とも思います。<br>USの場合、特に以前はパッケージを購入するか自社開発するか（ISVは利用しないがコンサルタントは利用する）なので、コンサルタントがCOBOLを積極的に勧めればオープン系でもCOBOLで構築となるのではないか、という感じですね。
20年前だと1987年ですよね。それなら現在よりもむしろありうる話なんじゃないでしょうか。<br>当時はまだ汎用機の方が速く、ダウンサイジングの流れも始まってなかったので、COBOLのエンジニアも減少し始めてなかったでしょうし。<br>言語の選択についても、汎用の事務処理用途だと、当時は COBOL, QuickBASIC, Pascal の三択ぐらいですよね (C は Pascal と比べても危ない言語なので)。Web はまだ存在もせず GUI でもなく CUI アプリケーションでしょうし、手元に COBOL ができるエンジニアを多く抱えているところなら、それなりにリーズナブルな選択だったのではないかと思います。<br>オープンシステムという言葉が生まれ、ダウンサイジングの流れが決定的になったのは、1990年前後ではないでしょうか。PC が性能的に十分になったのは 1990年代中盤、Web アプリケーションや Java が広まり、PC がシングルスレッドの整数演算性能で汎用機や UNIX 機を追い越したのが 1990年代終りですよね。<br>1987年の PC では 130万行のシステムは動作しなった筈なので、こつこと拡張してきたんでしょうけど… 途中で他の言語に乗り換えたくなっても、データベースが ISAM で乗り換えできなかったというパターンですかね。<br>今から新規開発するならユーザインターフェース側は Web か GUI になると思いますが、そういうアプリケーションで COBOL を勧めるコンサルタントっているんでしょうか。バックエンド側についても COBOL で書くよりは SQL を使った方が遥かに生産性が高いですし。
最後のところはちょっと認識不足のように思います。<br>COBOLでSQLを利用する（JavaでJDBCを使う、.NETでADO.NETを使う、と同様に考えれば良いと思います。SQLを使うといってもホストするアプリケーションは必要です。僕が知っているミドルェアはPro*COBOLくらいですがきっと他のベンダーも持っていると思います）ということでしょう。
Pro*COBOL の存在は知ってました。<br>ただ、RDB を用いる場合、COBOL を選ぶ必然性がないと思うんですが。せいぜい既存の COBOL エンジニアを生かせるということぐらいなんじゃないでしょうか。<br>バッチ処理程度なら PL/SQL ぐらいの機能があれば十分ですし、帳票出力も、適当なライブラリなりパッケージなりを使えば、COBOL 以外の言語でもまあ十分ですよね。
なんていうか、前提が変わってませんか？<br>まず、調査はUSの話です。帳票といっても全角、半角の区別があるわけでもないですし、罫線が必要なわけでもありません。したがって、Displayへの埋め込みだけで出力できるCOBOLを使えば、ライブラリもパッケージも不要だし、簡単ですよ（COBOLは帳票DSLですからね）。<br>それに大企業のシステムのバッチって一端は知ってますが、PL*SQLでどうこうというレベルじゃないです。A-AUTOみたいなパッケージを使ってがちがちに構築していくイメージです（SOA的だとさえ言えるなぁ。BPELみたいなのがすんなり出てくる所以ですね）から、個々のバッチはビルディングブロック化されている必要があります。<br>#実は、この特集を読んでて、COBOLのサブシステムも（全体はあり得ないけど）悪くないな、と感じ始めてたりしてるんですけどね。逆に僕のところでは、今更あり得ないなとは思うけど。
いや、CUI とラインプリンタ・固定幅フォントの時代には、COBOL にもアドバンテージがあったと思うんですよ。でも、ユーザインターフェースが GUI ないし Web で、紙への出力はプロポーショナルフォントを使ってページプリンタに出す時代に、COBOL のやり方にアドバンテージがありますかね？<br>バッチについては、データを加工して(必要なら)イベントをスケジュールするところまでの処理と、スケジュールされたイベントを実際にキックする処理の2種類があると思います。前者については PL/SQL で十分だし (*1)、リレーショナルモデルという非常に強力なデータ操作の仕組みからはみ出て、COBOL のような手続き的な処理で記述するのは、損でしかないと思います。後者の、実際のイベント処理については、当然 PL/SQL では不可能なわけですが、そういう処理は COBOL が得意な分野でもないわけで、敢えて COBOL を選ぶ意味はないですよね。前のコメントのバッチ処理という言葉は、この前者の部分を指してました。誤解を招く表現で済みません。<br>A-AUTO や BPEL は、この後者の範疇ですよね。また、COBOL の利用を継続する理由として挙げているわけですはないですよね？<br><br>*1 ただし後者と組み合わせて一つのジョブとして作り込む場合には、PL/SQL ではなく、他の言語＋埋め込み SQL なりを使うことになります。<br><br>> 実は、この特集を読んでて、COBOLのサブシステムも（全体はあり得ないけ<br>> ど）悪くないな、と感じ始めてたりしてるんですけどね。<br><br>具体的に、どのような処理を担当させるのに向いているんでしょう？
まさに、そのバッチの前者の部分です。引き合いにしたA-AUTOが後者というのはその通りです。想定しているのは、Pro*COBOL（など）を利用した埋め込みSQLを使うCOBOLプログラムで、RDBの処理とレポート処理を含みます。<br>これは単純にミドルウェアの軽さの問題だと思いますが、本誌で指摘されている通りのことを実測で知っているからですが、Java＋JDBC＋Oracleでバッチを組むと、確かにCOBOL＋Pro*COBOL ＋ Oracleより遅いです。特に全件を嘗め回すような処理では(当たり前ですが）JDBCのオーバーヘッドが大きいと想像しています（文字の変換あたりと睨んでいるんですけどね）。<br>もっとも、運用的な時間の余裕があったのと（5時間かかっても大丈夫とかいうようなレベルの話です）開発言語の統一の都合でJavaで押し切ったわけですが、より柔軟な言語の選択が可能なら（Pro*C ＋ ANSI Cというのはこの場合考慮外です）COBOLのほうが確かに良かったな、ということです。<br>それからWebは良いですが、出力先は必ずしもブラウザーとは限りませんよ。そういう場合にはCOBOLのほうが楽でしょう（というのも、COBOLと同様な埋め込み方式でレポートを作るOCXだのクラスライブラリだのを散々作ってきた経験からですが、あれは直観的です）。
要するに、お金の印字は、固定ピッチフォントの利用が必須ということです。
> より柔軟な言語の選択が可能ならCOBOLのほうが確かに良かったな、ということです。<br><br>これは、言語の善し悪しではなく、ソフトウェアの実装 (JDBC vs Pro*COBOL) の善し悪しの話ですね。<br>まあ確かに、それは現実には非常に重要な選択理由となるわけですが。<br><br>COBOLの帳票DSLとしての側面に、まだ有効な応用分野が残っているという方は納得しました。<br>コメント欄で長々おつきあいいただき、ありがとうございました。
僕もいろいろ考えることができておもしろかったです。<br>また、お願いします。