2010年4月30日金曜日

ストリーミング と オンデマンド

オンデマンドとは:
ファイルが必要になったときに始めて、遠隔サーバから取り寄せる。

利用タイミングの話をしています。
分量の話はしてません。

どっちかというと運用&サービス形態の話

ストリーミングとは:
ファイルの任意の一部だけをダウンロードして&しながら、利用する方式。

分量と部分位置の話をしています。
どっちかというと実装方式の話。

映像系サービスで言うと、
ストリーミングは概ねオンデマンドな訳ですが、
逆は必ずしも成り立ちません。

例えば、大手の配布している無料アプリのインストーラで、
インストーラ本体がやたらサイズが小さくて、
起動してみたら、10分も掛かって16MBもダウンロードしてた、
とかそういうのが流行ってるみたいですが。
#iTunesがそうだったっけか。

これは、
「オンデマンド」だけど
「非ストリーミング」である
という言い方は出来ます。

ちなみに

例えば、aviは、マイクロソフトの古い動画形式ですが、
映像部分と音声部分が、ファイルの前後にピッチリ別れてるので、
一部の再生のためでも、ファイル全体が必要です。

つまり、aviではストリーミングには使えません。

言い換えると、ストリーミングのためには、
ファイルの中身のデータの順序も工夫する必要があります。

もちろん、とっくの昔に、「ストリーミング用」
動画フォーマット(厳密には、動画コンテナ。とか言うらしい)が
あります。matroska, ogm, realmedia, quicktime, windowsmedia

Xperia触ってみた

○○○カメラの○○店の店頭で、
Xperiaを触って見ました。

トラックボールが無いのと。
戻るボタンが無いのが
面くらいました。

ハードウエアキーも、クリックがないので
押したかどうだか実に不安です。

液晶パネル表面は、ツルツルのテカテカですね。
最近はこういうのが流行りなんでしょうか。
筆者は、指紋が付きまくって、気になりまくるんですが。

個々の機能の反応は流石に良いです。

ほぼ、選択した瞬間に起動しますね。

ht-03aの、「ん、んー、ん、起動」な
絶望的な待ち時間はありません。
#電話の着信から、30秒後に、
#電話アプリがようやく起動した時は吹いた。

グーグルマップのスクロールも「痛快」です。

ホームスクリーンは、android標準のそれとは違いますが、
使い勝手はもちろん変わってなさそうです。

アプリ一覧を引っ張るツマミが薄くなってました。
正直、掴みにくいと思った。

そのデモ機では、60以上のアプリが入ってたみたいですが、
スルっと出てきました。


レスポンスだけ見ても、使い勝手はかなり良いと思います。
イケネ。日本語入力を試すの忘れてました。

ただの1台で運用しようという向きには、
Xperiaは良いかも知れません。

ht-03aを「本気」で運用している人は、
機種交換を「考慮」しても良さそうです。

筆者は、ht-03aを本気で運用してないので、考慮外です。

「IT業界の実態」

ねた的には、かなり昔からある画像。

IT業界というか、ソリューション稼業の難しさは
筆者も、別エントリで言及してますが。

これで言わんとしていることは、

「顧客は自分の要求を、正確に説明できるとは限らない」
更に
「各フェーズの担当者は、気を効かせたつもり」で

完全に伝言ゲームの様相を呈しちゃってますが。

それを端的に表してる、素晴らしい漫画があります。
(コンテンツの分類は漫画で間違ってはいないと思う)


「ITプロジェクトの実態」として検索すれば色々引っかかります。




顧客が本当に必要だったもの

そしてその検索で引っかかる、ガンダムだのなんだのは全てコレのパロディです。

だって、あっちは元ネタに熟知してないと判りにくいでしょ?
オリジナルは木のやつです。

そして発祥は英語圏っぽい。


各フェーズの担当者は最大限の努力はしてると思います。

リーダ: 片側に吊るすと、枝の強度が足りないから内側に結ぶ。
アナリスト: それじゃあブランコが揺れないから切り抜く。
プログラマ:「判りました。木にブランコを結ぶんですね」

古典的な大規模開発では、
設計と実装は、別人が担当していて、
そのために「仕様書」が必要でした。

ウォーターフォールに準えて、設計は上流工程で高学歴者が、
実装は中学歴者がやったりしてましたが、
それ故、業界には、割と根深く学歴差別があります。

前半程、責任重大、しかも後戻りが出来ないので
ウオーターフォールモデルとか言ったりしますが、
バケツリレーモデルと言った方が正しいでしょう。

高学歴者は頭が良い。それは良いでしょう。
でも勉強が出きるだけじゃ駄目なんですよ。

「そのブランコで、誰が遊ぶんですか?」
を聞かなきゃいけなかったのです。

言い換えると、これは筆者の持論でもありますが

ソリューションとは
顧客が「言う」通りに作るんじゃなくて
顧客の「要望」どおりに作ること。

それじゃいけないらしい。と気がついて
「ITアナリスト」なんて職種が沸いて出ましたが。
アナリストでさえ、あのザマですから。

とは言え、タイヤを括るだけなら、
お父さんでも出来たんじゃね?

2010年4月29日木曜日

xperia と desire と is01

au is01と、softbank desireの発表で、
ようやく国内全キャリア、android端末が出揃いました。

#willcommは、東芝/sharpのWindows機ばっかりなので
#まったく期待はしてません。

ht-03aが、完全に咬ませ犬化してるのは如何ともしがたいですが、
docomoに火炎瓶を投げ込むのは辞めておきます。

docomo xperia x10
http://www.nttdocomo.co.jp/product/foma/smart_phone/so01b/index.html


ブログを検索してみる限りは、
xperia x10も、まだまだ「事情通のスマートフォン」といった感じ。
「グーグルサービスを使いたかった」みたいな人しか居ません。
#言い換えると、androidの説明を必要としない人たち。

iPhoneのシェアを奪うには、まだまだ至らないでしょう。
その証拠に、電車内で見かけるiPhoneユーザが減ってない。
まあ、発売数日じゃ無理か。

例によって、電池もまるで持たないらしい。
androidの宿命みたいな感じに持ち込むのは辞めてほしいです。

サイトを見ても、例によってマルバツ比較してますね。
こんなもんユーザは求めてないと思うのだが。

音楽機能や写真がどうたら、と内蔵機能面で攻めてるのも
どうでしょう。音楽聞きたければ携帯プレーヤ使うんじゃね?
iPhoneを敵視してるのがストレート過ぎる。のか?
攻め手を間違えてる感。

結論として「格好良くなっただけ」感は否めません。
その内触ってはみたいとは思ってますが。

softbank htc desire
http://mb.softbank.jp/mb/product/X/09wi/#x06ht
サイトは意外と、「それっぽい」仕上がりですね。
iPhoneの、というかアップルの手管がこんな感じな気がする。
とは言え、素のandroid 2.1がどこまで受けるかは疑わしい。

素でないandroidのxperiaですら、微妙らしいですから。

ただし、iPhoneを売ってるsoftbankですから、
スマートフォン市場に対して、
何らかの感触は得てるのかも知れません。
「androidでもイケル!」的な何かを。

au is01
http://au-is.jp/products/is01/
日本企業が、日本のためにandroidをイジった製品。
そういう意味では筆者は非常に評価してます。

とは言え、今時の消費者は、
「「メイルに速攻で返信」が友情の証」らしいので、
開閉の面倒臭そうな、本機は、かなり評判が悪いですね。

しかし、それらは元々のターゲットユーザ層とは違う予感がするし、
またケータイテンキー入力の皆伝レベルだと思うので、
キーボードも要らないって言うはず。

割り引いて考えるべきでしょう。

ハンズフリー専用、ってのも思い切ったなあ。とは思います。

しかしながら、そのデザインこそ注目すべき。
android史上始めて、「非ストレート型」。
筆者は、あえて「日本のケータイ」から外した。と解釈しています。

ケータイだと思って買ったユーザは、ケータイの機能しか期待しません。

デカイ!と言ってる連中に、
「「ケータイをポケットに入れる」という発想を捨てろ。」
と言っても無理っぽいですから。

「androidはケータイとは違う」は、
日本ユーザには浸透させる必要がある気がします。

家庭用というか個人用としては微妙ですが、
ビジネス用としてはアリでしょう。
キーボード付きもそこで活きてきます。

端的に言えば、ライバルはiPad。な気がします。
どっちみちケータイといては微妙だって話ですが。

そのiPadも、散々文句言われてたんですが、
結局買ってる人は買ってるらしいですし。
初見は大体文句をいうもんですし。

メガネ君とメガネちゃん

筆者はド近眼です。小学校高学年からなので、筋金入りの。もう30年近くの眼鏡人生です。

当初、眼鏡は、オタクがガリ勉(死語?)の
代名詞だった気がしますが今ではオシャレアイテムとして定着してますね。

筆者の記憶では、「冬のソナタ」の主演「ペ・ヨンジュン」の功績だと記憶しています。
当時も結構、眼鏡男子が流行ったような。

自分の眼鏡受けは気にしませんが、眼鏡女子が増えたのは素直に喜びたい。

「眼鏡はダサイからコンタクト」という風潮は完全に払拭したってことですから。

「アイウエア」等という製品ジャンルまで現れて色違い&デザイン違いで幾つも使い分けよう!などという贅沢まで通用する時代になりました。韓国製で、偉く安く作れるらしい?一昔前までは4万円も掛かりましたが、今ではお蔭さんで、1万円未満で眼鏡が作れます。

筆者が現在運用中の眼鏡も、8000円台で出来ました。しかも1時間掛からなかったんです。時代革新とは恐ろしい。

消費者にとっては良い時代ですが、製造元はどうやって利益を出しているのか??いや、人の心配してる余裕はないのですが。

2010年4月28日水曜日

nilfs2 の運用で要注意

フツーに運用するだけで、
勝手にバックアップ(厳密にはスナップショット)を取ってくれるという
便利この上ないファイルシステム。
linuxでだけ稼働します。まあ役得でしょう。

筆者は、現状 二つのパーティションをnilfs2で運用中ですが、
うち1パーティションを、xfsに移すことにしました。

数百MBオーダのファイルの取扱いが苦手っぽいのと、
パーティションが100%近くなってきたのが理由です。

新しいドライブを買ってきてxfsでフォーマット。
とりあえず機械的に移動開始。

find . -type d -exec mkdir /NEWPARTITION/\{\} \;
find . -type f -exec mv -v \{\} /NEWPARTITION/\{\} \;


その過程で、弱った事態が発生。

nilfs2は、パーティション(の)ルートに、
".nilfs"というファイルがあるのは
使ってる人ならご存知だと思いますが。

  • 消せます。
  • しかし、削除すると、lscp等が動かなくなります。
前述の、別パーティションへのデータの引越し中、
/.nilfsをmvしちゃったから、アラ大変。
どうやら、ガベージコレクションも止まっちゃう模様。

100%に成る前なら、手動で、"/.nilfs"を作成すれば済む話ですが、
成っちゃったら、最後

  • .nilfsを作成できない
  • .nilfsが無いので、ガベージコレクションが稼働しない。
  • ガベージコレクションが稼働しないので100%のまま。

という、それはそれは恐ろしいスパイラル発生。

そんなに大事なら、何らか救済処置が必須だった筈。

  • 削除できないようにしておく
  • mountしなおしたら勝手に復活


仕方がないので、rsyncで、不足ファイルをコピー中。
もう、移転は最後までやり切っちゃうしかありません。
完全に後に引けなくなりました。

結論として、
容量ギリギリまで使っちゃいそうなパーティションには、
nilfsは使っちゃ駄目!ということになっちゃいそうです。

sony ps3 torne 毎月バージョンアップ?

PS3専用のusb地デジチューナtorneと使い勝手が素晴らしい。らしい。

しかし、何度かアップデートしているみたいですね。



5月に何もアップデートがでなければ、
導入を検討してみようか。
とも思います。

2010年4月26日月曜日

app engine で、大量のデータを、あっと言う間に、datastoreに入れる方法

ググる限りは、言及しているページが非常に少ないので、
「知る人ぞ知る」化してるっぽいので、書いておきます。

google.appengine.ext.db.Model.put()
google.appengine.ext.db.Model.delete()

datastoreのレコードを更新するときには、
db.Modelのput/deleteを使う場合がほとんどだと思いますが、
これって遅いですよね?

datastoreとの通信は、xml-rpcっぽいので、
ほとんどはプロトコルのオーバーヘッドだと思います。
たとすれば、通信回数を減らせば良い?

そうです。一括書き込み方法があります。
って言うか、ドキュメントを熟読すれば書いてある話なんだけど。

「一つ以上の」って書いてあります。
ハイ。もう判りましたね。

db.Modelをその場でputしないで、
  • list.appendしておく。
  • まとめて、db.put(list) する。

これだけで劇的に速くなります。
もう劇的です。500レコードが2秒で入ります。

「な!」と言っちゃうぐらいです。

ただしこの場合だと、db.Model.putは通らないので、
独自にputをオーバーライドしてる場合だと、
都合が悪いことがあります。

ちなみに筆者は、まったくの別件の研究で、
SDKのソースを眺めていて、本件を発見しました。

石版??

筆者は、週刊アスキーで始めて知りました。

マイクロソフトがまた変な事を言い出しましたね。

スレートPC

正直、そんなに恰好良いネーミングとは思えないんだど。どうか?

その前に、タブレットPCと何が違うのか?

タブレットも良い名前とは言えないけど。
ちなみに薬の錠剤もタブレット。

そういや、ハンドヘルドって言わなくなりましたね。

とりあえず、スレートを名乗ってるのはマイクロソフトだけなので、
他のメーカは、引き続き「タブレット」を名乗ったらどうでしょう。

マイクロソフトは一人でやってろ。ってことで。

「選択的夫婦別姓」

筆者は行政に疎いので、実は知りませんでした。
#このサイトって、履歴が見られないのね。

正直、よく判りません。

しかし、なぜ反対するのか判らない。
「選択的」ですよね。「強制」じゃない。

何を言ってるのか判らない。煙に巻こうとしている感じ。

離婚が増えるかもしれないとか、
子供が不安を感じるかもしれないとかは、
名字とは直接は関係無いでしょう。

「同姓」の現状だって、
成田離婚はあります。らしい。
子を育てられない母親も増えてる。らしい。
家庭内離婚みたいな夫婦もいます。知り合いに一組。

女性の立場として、
仕事上、名乗りたい。というのは大いに判ります。

筆者が配偶者の姓を名乗らなきゃならないとしたら
悩みますからね。

婚約者の両親に逢いにいく時は何て言うんでしょうね。
旦那の姓に入るからこそ「娘さんをください!」が成り立つ。

しかし、行政処理は複雑化する気はします。

「○○家」単位で処理していたものが、
「○○家の△△さん」になってしまう。

窓口の手間が複雑化する気はします。
住民登録には、現状そういう入力欄は無い気がしますし。
仮に成立したとすると、
住基ネットカードを必ず作らなきゃいけなくなって、
役所の窓口で必ず提出、みたいな事になりそうですね。

とりあえず現状の運用で、どうしても旧姓を使いたければ、
ミドルネーム付きに改名したらどうかとも思います。
確か出来たような。改名。

「山田 田中 純子」、とかね。

しかし、番組の最後に登場した女性。
「無縁仏でもいいから、旦那と同じ墓に入りたくない」は
衝撃でした。しかもそれを71歳の女性が言う。

筆者は独身なので、想像でしかありませんが、
それって旦那はどう思ったか。どエラい寂しい気はします。
「添い遂げません」宣言だよね。と。

それは、現状の「夫婦同姓制度」が追い詰めてるとも言えますが。

筆者の個人的な意見としては、

石橋を叩いて渡る。のは判りますが。
案ずるより産むがやすし。と申しますし。

やってみればいいんじゃね?

やらないで悩むのは終わりがないし、何回でも蒸し返すけど、
やってから反省するのは簡単でしょう。

4億掛けて掘った道路を1億掛けて埋めるとか
金の無駄遣いしている自治体もあるらしいから、
いざとなれば、技術的にはなんとでもするでしょう。

よっぽど生産的な「産業の創出」でしょうよ。

こんな話でスッタモンダしてる一方で、
って言うか「非実在青少年」の話は、
反対意見って出てないのかな。
色々な業界で反対してみりゃいいのかな?

2010年4月25日日曜日

電源ランプぐらいは有っても良かったんじゃね?

つい先日。
バッグに入れて放置したままのiPhone。
電源が入らなくて血の気が引いたことがあります。
ACアダプタ繋いでもウントモスントモ言わないし。
iPhoneには「充電中LED」も無いですね。

この前バックアップ取ったのって何時だっけ?と。

その時にようやく、液晶が消えていたら
電池が切れてるんだか壊れてるんだか、
区別が付かない事に気がつきました。

正直、慌てますね。

2010年4月24日土曜日

「大学生」は「未成年」って事で、いいんじゃね?

筆者は、クローズアップ現代を見てます。
と言うことは、同じ時間枠の、特報首都圏も見てます。


友達が居ないのを見られるのが嫌で、
学食に行けないで、トイレで軽食を済ませる
あるいは
大学に行かなくなる
そういう大学生が増えてるらしい。

はあ?
マジで?
何しに大学行ってるの?

筆者は大学に行ってないのに解りませんが、
イマドキは大学には友達を作る場なんでしょうか?
ちょっと解らない心理。

一方、想像は出来ます。

筆者がまだ若いころは、学歴差別みたいなのが有って、
「俺は大学行ってるから(高卒より)偉いぜー」みたいな風潮が、
少なくとも2ちゃんねるには有りました。(狭っ)

しかしこのご時世。就職できない若者が大量に居ますから、
とっくの昔に、「学歴は自慢にならない」時代です。

で、友人関係というネットワークに依存してしまう。
だろうか?

筆者の学生時代というか義務教育中とくらべて、
今はネットありきの世界に生まれてます。
ネットワークの恐ろしさを何となく解ってる。

「友達が居ないのを目撃されるのが嫌」じゃなくて
本当に嫌なのは、そこから先じゃないでしょうか?

「他人のネットワークで、自分の私生活が暴露される」なのが嫌なんじゃね?

「あー、アイツまた一人で飯食ってるよー」と
ツイッターに書かれたら、筆者だってたまらんです。

いや実際一人ですけどね。立ち食い蕎麦屋でね。

番組中では、「精神年齢的に未熟で、中学生も同然だ」
という意見もありましたが、
そうすると、2ちゃんねる語「厨房」は、「言い得て妙」だったんですね。

成人年齢を30歳にしたらどうかと思いますね。正直。

大学生5人ぐらいを連れてきて、インタビューしてましたが、
携帯電話の電話帳に700件も入っているらしい。

そんなに掛けねえよ!
って言うか、顔を思い出せるのはそのうち何人だよ!
意味あるのかそれ!

しかも、メイルが来たら直ぐ返すのが友情の証。らしい。

いや、書いてて思いましたが、
彼らは「友人」に「営業」してますね。
ケータイメイルだけで結びついている間柄。
毎日ご機嫌伺いは欠かせません。
どう見てもルートセールスです。

イヤイヤ友人ならそんなアピール要らないだろ。と思いますが。

そういや、20年ぐらい前。
携帯電話より以前に、ポケベルというモノがありましたが、
筆者も持ってましたが。

相手先の電話番号をテキトーに入力して、
「トモダチニナッテ」と打ち込む馬鹿が居る様です。
筆者にも、ただの1通だけ届きました。

アンタの顔も知らんのに、トモダチになんか成れるか!
と筆者は思ったものですが、
実際、居るんでしょう。承諾する人が。

当時の女子高生が、今の大学生を育てているのかと思えば、
判らんでもない気はする。知りませんけどね。

「非実在青少年」をどうこうするより、
「地デジ移行」に必死になるより
コッチの方が重要だと思うんですが。

2010年4月23日金曜日

pythonにはnew演算子がない

pythonでは、インスタンスの作成で、new演算子を使いません。
というか、「new演算子」という構文が存在しません。

PHPやJavaやらCやらの経験者からすると、
これはやや気持ち悪い。
具体的には小生がそうでした。

ただし、その方法論が腑に落ちると、「new「演算子」」のある言語が「オブジェクト指向言語」に見えなくなってきます。少なくとも小生はそうです。

順番に行きましょう

pythonでは、普通の言語でいうところの「クラス宣言」は有りません。
しかし、同等の機構はあります。クラスオブジェクトの作成です。

http://www.python.jp/doc/2.4/tut/node11.html#SECTION0011320000000000000000

下記の例で言うと、anyclass変数に、クラスオジェクトが入ります。
 class anyclass(object):  pass
インスタンスの作成はどうするかというと、作って有るはずの、クラスオブジェクトをcallしてるわけです。だからnew演算子を付けちゃいけません。「呼んでる」だけだから。
instance_object = anyclass()
これはpython的には、「class宣言は、type型インスタンスを作ってるだけで、それはcallableである」というところです。フツーの言語が、new演算子を起点にして、「コンパイル時」にやってることを、callableを経由して「実行時」にやってる。ここがpythonの肝です。

もちろんこんな空っぽのクラスは何の役にもたちません。とりあえずメソッドを足します。
class hasmethod(object):
 def method1(self): pass

pythonは、言語としては珍しく、メソッドの引数として「自分インスタンスオブジェクト」を第1引数に書かなければなりません。

インスタンスを作ると、クラスメソッドとインスタンスオブジェクトが結びつきます。
instance1 = hasmethod()
instance1.method1()

ここでのポイントは、

instance1.method1() と、hasmethod.method1() は別物である。

ということです。

  • 前者は、インスタンスに結びついたメソッドオブジェクト
  • 後者は、結び付いてないクラスメソッドオブジェクト。
後者は、「結びついてない」ので、
インスタンスオブジェクトをどうにかして渡す必要があります。

それで第1引数 self の出番というわけです。

前者は、「結びついてる」ので、pythonがselfを勝手に足してくれます。故に、インスタンス関数呼び出しでは、self 以外の引数だけを書くわけです。


instance1 == self
とは言え、この調子だと、普通の言語で言うところの、静的メソッドは?このままでは無理です。しかし方法は有ります。

class statichas(object):
 @staticmethod
 def method1(): pass

@staticmethodデコレータを挟むだけです。

フツーの関数宣言は、selfが必要ですが、今度は逆に、selfを入れると怒られます。pythonは、selfを引数に勝手に加えるのを辞めます。staticmethodは、そういうマーキングをやってるらしい。この状態では、method1を直接呼び出すことができます。 http://docs.python.org/c-api/structures.html#METH_STATIC

statichas.method1()

ただしこれでは問題が無くもありません。関数の中からは、クラスもインスタンスも解らないので、クラス内の他のメソッドも使えません。

#逆に、一人完結してます。というアピールに#@staticmethodを使うのは、筆者はアリだと思います。

前述のクラスメソッド表記で呼び出せなくもありませんが、クラスを継承する状況を想定すると、固定で書くのは避けたいですね。

ハイ。そこで出てくるのは、@classmethodデコレータです。フツーの言語の、静的メソッドに相当するのは、むしろコッチでしょう。
class statichas(object):
 @classmethod
 def method1(cls1):pass
引数に必ず1個入ります。わざわざclassmethodと付けたのは意味がもちろんあって、
「「インスタンスオブジェクト」で無いモノ」を付けてね」という意味です。らしい。http://docs.python.org/c-api/structures.html#METH_CLASS 前述のtype型インスタンスなので、歴史的&一般的にselfとは付けません。世間一般にはclsとだけ付けるっぽいですが、小生は3文字変数に辛い思い出があるので、"cls1"にしてます。
statichas.method1()
表面上は、さっきのstaticmethodと同じ使い心地です。しかし、cls1には、statichasクラスオブジェクトが入ってます。classmethod同士を呼び出す分にはこれで行けますね。

statichas == cls1

しかも継承すれば、継承後のクラスオブジェクトがcls1に入っている。

という寸法です。

面白い発想ですね。

具体的には、app engine python-SDKのgoogle.appengine.ext.db.Model.get がlassmethodです。小生は、この辺りの実装を眺めていて、感動すら覚えました。

class「定義」の構文は、フツーの関数定義を「メソッド呼び出しに変換する」処理であると考えれば、腑に落ちると思います。故に、$thisを暗黙で「渡さない」方が何かと都合が良いわけです。

これを利用して、定義済みクラスじゃなくてtypeオブジェクトに、メソッドを後付けできます。「class定義」がコンパイラの仕事じゃないから出きることですね。真の動的言語の何たるかを見た気がします。

そんな訳ですので、フツーのインスタンスメソッドから、classmethodを使うときにはどうするか?構文を区別する必要があります。
self.__class__.method1()
static::method1とか書くより解りやすい気がすると思うのですが、どうでしょう。ダブルコロンとかバックスラッシュとか要らないわけです。オブジェクトだから。

今まで、インスタンス作成、メソッド呼び出し、と色々述べましたが、

表記上の違いはほとんどありませんし、Python内部でのメカニズムの違いも殆どありません。 他の言語でいうところの「クラス定義」は、「タイプ型オブジェクト」でしかないので、「◯◯オブジェクトのメンバ関数を呼ぶ」という機構は統一できてるわけです。


  • インスタンスメソッドを呼び出す場合
    • instace1インスタンスオブジェクトのmethod1メンバをcallする。
    • 特にmethod1にマークは付いてないので、引数の先頭にinstance1を挿入する
  • staticmethodを呼び出す場合
    • class1タイプオブジェクトのmethod1メンバをcallする。
    • staticmethodマークが付いてるので、引数には何も足さない。
  • classmethodを呼び出す場合
    • class1タイプオブジェクトのmethod1メンバをcallする
    • classmethodマークが付いているので、引数の先頭にclass1を挿入する。



呼び出し可能なオブジェクト(特にcallableと呼ぶ)を、呼んでる(call)だけ。

これに付きます。


これが腑に落ちると、途端に「new演算子のあるオブジェクト指向言語」が駄目言語に見えます。

筆者はここまで徹底したオブジェクト指向を他に知りません。
#ご存知の方は、教えてくれなくてもいいです。長くなりそうなんで。

識者が言うところによると、pythonは、広義には関数型言語らしい。
haskelには気絶しそうになりましたが、大分判りやすくて助かります。

7インチでAndroid

別エントリで、Androidを活かすには7インチは必要と申しましたが、
実際その通りのスペックの製品が、非携帯電話として出ています。

要するに、フォトスタンドもしくはタブレット。

日本国内で買えるものも幾つか出てますね。

smart Q5
¥19800と、抜群に安い
本来はubuntuが入っている製品に、covia社がAndroidに詰め直したもの。
実際買った人の意見を見てみると、チープな出来らしい。
CPUはSamsung S3C6410 667Mhzって話なので、
HT-03aとあまり変わらない性能。故にモッサリな可能性あり。
感圧式タッチパネルらしいので、指の反応が悪いらしい。
スタイラス必須。
実際問題、ニンテンドーDSと同価格帯であるわけですから、
多くを期待するのが無理ってもんでしょう。
解像度そのままで、画面が大きくなったsmartq7もありますが、
正規の日本販売はありません。

Comangi WebStation
¥39800。安くは無いが、目玉飛び出るほどでもない。
CPU Marvell PXA303 624MHz
CPU的には、あんまり速くは無さそう。
ただし、GPS+加速度センサーあり。
基本WiFi専用だが、イーモバイルUSBアダプタが稼働するらしい。
Youtubeの動画を見ると、ホームスクリーンのスクロールに、ややモタつき感あり。

ARCHOS 5 Internet Tablet
日本代理店は、今のところ無いっぽい。
$294 for 16GB SSD, $320 for 160GB HDD
ARM CortexTM-A8, 32 bit, In-order, dual-issue, superscalar core @ 800 MHz
コイツは5だが、7ってのも有るらしい。
ネーミングセンスがsmartqと一緒なんだが。気のせいか?
#”Dual OS"で、一方がAndroid。他方がlinuxってところも一緒。
残念ながら、GPSはなさそう。
加速度センサーもスペック上、それらしい記述はなさそう。
筐体を立てると画面が回るらしいから、加速度センサーは有るはず。
Youtubeの動画を見ると、かなり速い模様。

液晶は同じサイズなので、解像度はいずれも800x600。
後は、スペックと価格と趣味の問題ですね。

2010年4月22日木曜日

android is01が不評な件

知人の話によると、「au IS01が、ネットで不評」だって話なんで、
どう不評なのかと思って、今検索してみたんですが。

ただデカイのが気に要らないらしい。

IS01とIS02が、中身が逆だろ、って言ってる奴が居ますが、
各プラットフォームに対して、先入観が強すぎる。
割り引いて聞くべき。

彼らの意見を総合すると、こういう事らしい。
  • 複数台を所有する、って発想がない
  • ポケットに入れたい?ので、小さい端末マンセー
  • 小さい画面が割と好きらしい
  • キーボードが要らない。
  • 要するに、旧来の「ケータイ」に似たものを期待している
しかしながら
「IS01自体のコンセプトに文句」を言うのは筋違い。
「IS01が、2台目コンセプト」であることに文句を言うなら解る。

そういう意味では、文句を言ってる彼らの方が
「本当の意味でのAUファン」じゃね?

筆者は、IPhoneもHT-03aも所持してますが、
画面が小さすぎると感じています。
縦横それぞれ2倍。面積で4倍は必要。面積も解像度もです。

PCサイトを見たときに文字がつぶれちゃって読めません。

いやもちろん、拡大縮小スクロールさせりゃ見られますよ。
しかしそれは面倒でしょ。
「可能」であることと「現実的」であることは違います。

依然として、「ケータイ(iPhone)向けサイト」を見るしかない。

言い換えると、情報量がケータイから逸脱してません。
ケータイと同じ事をする気なら、ケータイを使えば良い。
ケータイの方が、電池の持ちも長いですしね。

結論として、あの画面サイズでは、OSが泣きます。

Android OSも、iPhone OSも、機能を生かすには、
少なくともPSP並みの大画面は必要です。
まあケータイじゃ無くなるのは確か。

2010年4月21日水曜日

「非実在青少年」

正直、
自称「政治家」の馬鹿さ加減には飽きれた。
というか。

殺人が起ったら、ゲームを糾弾。
性犯罪が起ったら、漫画やアニメを糾弾。

順繰りに「原因っぽい何か」を制限する。
引き算思考&保身に必死、の日本人っぽい発想です。

筆者は、漫画もゲームもやらずには居られませんので
悪者よばわりは聞き捨てなりません。

「間違った情報を与えるっぽい漫画」は見ませんけど
「殺人衝動の原因っぽいゲーム」はやりますから。

っていうか、仮に条例が成立したとして、
それでも青少年のどーたらこーたらが減らなかったら
どうする気なんでしょうね?
何で「減る」前提なんだろ?
減らなくても、誰も責任を取らないよね?

犯罪ってのはそんな簡単な話じゃない。
警察も法律も要らない筈でしょ?

地デジ放送で、
「コピー10」とか馬鹿な制限掛けてるのは、
コンテンツ商売を成立させたいからでしょ。

その一方では、コンテンツのネタを制限する。
いやもちろん、制限対象は、ネタの一部ではあります。

教育界のお偉いさんが言う所の「間違った情報」は、
「ああいうのの事かな」という認識はありますが。

そこまで辿り着けるなら、その青少年は、他の方法を幾らでも探しますよ。
それこそ、日本の政治家が辿り着けない領域で。

#いや、具体的な何か。は知りませんよ。本当よ。

それよか、「自主規制」でグレーゾーンのコンテンツが
ゴッソリ減る方が損でしょう。

日本国内だけの話じゃなくて、
海外からもクレーム殺到するかもしれませんね。
MANGAも、英語圏で通用する単語ですよ。

お偉いさんが「規制」したがってるジャンルについても、
ローマ字英語が存在します。言わないけどね。

まあ、日本の政治&行政がチクハグだってのは、
誰もが知ってることですが。

ここ数ヶ月、世の中は地デジに必死過ぎて、既に呆れてたんですが。
このままだと、日本に誰も居なくなりますよ。

って言うか、筆者は、
老後はヨーロッパかオーストラリアで暮そうかと思ってました。
いやそんな金は無いんだけどね。

appengineで、なんかWarning出た

何気なくログ眺めてたら、

This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.

こんなWarningが出てました。
最近流行りの、スピンアップ問題について。だとは思いますが。

意訳すると
「毎回プロセスを生成してるので、余計な時間が掛かるかも知れません」

知ってるよ!

494msの奴には出てない。
567msの奴は出てる。

500ms以上で、とかそんな感じでしょうか?

オフィシャルブログには何か書いてあるっぽいですが、
とにかくトートツなので、地球上で混乱しているようです。

Very helpful and useful in many ways (code optimization etc.)
Oh ! just a short commend : could it be a little less verbose ? thus not waisting so much valuable space in logs database etc ?

えええ?やっちゃってからアンケート??
有料Quotaもやってるのに、labs発想はどうかと思う。

そうね。「長すぎ」
何時もの様にURL貼るんでよかったんじゃね?

って言うか、その前に、出力条件を言え。と思います。
そして、500msをしきい値にしてるとしたら、「短すぎ」




HT-03aがどうかんがえても噛ませ犬化してる件



Xperiaはドコモが自信を持ってお勧めする端末」

おうおう、山田社長。そりゃねえぜ。
マジレスしてやります。

今までの端末は
  • 自信が無かったのか
  • おすすめ出来なかったのか。
どっち?

あちこっちで反感買ってますね。
まあこの方は料金体系についてですが。
ちなみに筆者は、SIMをOFFって、発信は殆どしません。
基本料金しか払ってないのであんまり気にしません。
メインじゃないから成り立つ手口ですね。

実際に機種変更した人の体験談
参考になります。

Xperiaを実際に店頭で触りまくってみたら、ビミョーだった?
確かになあ。ドコモショップでチョッカイ出してみようか。

HT-03aは非常に遅い端末で、Xperiaはずっと速いのは明らかですが、
ソニーエリクソン独自アプリの数々は、
HT-03aユーザに必要か?って言ったら解らないですね。

雑誌で見る限りは、筆者は「まあ、恰好はいいよね」と生返事。


2010年4月20日火曜日

auのandroid IS01 は「消える魔球」

auは、android端末の発売を明らかにしたらしいですね。
http://au-is.jp/products/

以前のエントリはそれを知らないで買いてしまいました。


  • Xperiaが、オーディオビジュアル面強化で、
  • iPhoneと真っ向勝負だと思えば、
  • IS01は、変化球。魔球レベルと言えるでしょう。


「ニッチに」と言いきってますね。
誰でも打てる訳ではない感じが、まさに魔球。

ワンセグにも対応しているのが素晴らしい。
筆者が利用したいんじゃなくて、
ワンセグチューナのドライバを書いた技術と努力が。

「スマートフォン」と銘打って、ワンセグを受信できた端末は、
筆者の記憶では存在しません。有ったら教えてください。
その意味でも画期的でしょう。

その点では、Xperiaより、日本人向けとは言えるでしょう。

グーグルがやってほしかったのは、
「こういう事だった」と思わせる仕上がり。

横長画面しかもキーボード&トラックボール搭載。

ザウルスシリーズに憧れた身としては
非常に興味深い端末です。
似たような事を考えてる人は多いはず。

もっと早くだしてくれればHT-03a買わなかったのにとか。
危うくauを解約する気だったとか、
auも去年機種変したばっかりなんで(○年縛り残ってるけど)
コレに機種変更したらdocomo解約するかも(2年縛りが残ってるけど)とか
それくらいの勢いです。
短い付き合いだったね>docomo

「日本人向きケータイ」に仕上がったかどうかは
意見の分かれるところですが、
電車の中での有様を見ていると、フルキーボード付きケータイは、
男女問わず、一定のニーズがあるようです。

発売の6月が待ち遠しいです。

ソフトバンクもandroid出すって言ってるらしいですが、
http://gigazine.net/index.php?/news/comments/20100328_sbm_htc_desire_x06ht/
えー、なんなのよー、HTC??
ハードウエア的にはHT-03aとは比べ物にならない感じですが、
素のandroidは日本人受けが悪いのでどうなることやら。

appengineの制限は、グーグルにとっても制限

この記事の内容は既に古く、有料に限り(無料分はありますが、どうせ週$2取られるので)、専用インスタンスを無限に動かせるようになってます。
https://developers.google.com/appengine/docs/python/backends/overview?hl=ja

ただし、小生のスタンスは変わってないので、この記事自体は据え置きます。

基本的には、「30秒も要らねえよ」ってスタンスなので、解決方法は書いてません。それを探しに来たかたは悪しからず。

http://code.google.com/intl/ja/appengine/docs/roadmap.html
appengineのロードマップ的には、taskqueueやcronに限り、30秒ルールを撤廃する可能性があるらしいのですが。筆者はあまり困ってません。「悩まされてるデベロッパー」ってJavaで書いているのんじゃないでしょうか?

筆者はJavaは遅い、と思ってます。JSPの、「あー今コンパイルしてるな」なタメ時間もあり得ません。スピンアップ時間の無駄使い。

「スピンアップ終わったら、速いんだよ」とか言わない事を祈ります。そりゃあ当たり前というか。全部遅かったら目も当てられない。多分アナタも使わないでしょう。

ちなみにpythonの「スピンアップ」は2秒ぐらいっぽい。速いと見るか遅いと見るか。

もしくは、Slim3というフレームワークが速いらしいので
使ってみたらどうかと思います。ひょっとしてそれで済む話かもしれません。

そもそも、appengine は、社内で使ってるクラウドの一部を切り売りしているだけ。の筈。グーグルでも30秒ルールに従ってるのです。

datastoreの実装も、「あーこれならGmail作れるな」というものばかり。ラベルは、StringListProperty使ってるんだろうな。とか。

フツーのRDBMだったらリレーション使うところはReferencePropertyで、かなりやっていけます。またはModelクラスのメソッド実装で引っ張ってくるとかね。発想の転換が大事です。

1回のトランザクションで、データを1000個しか取り出せないのもグーグルにとっても同じです。Gmailや、Readerの件数表示が、1000以上は表示できないでしょう?件数も詳細を出さないで、800件ぐらい、とかサボってます。

と言うわけで、30秒撤廃は、グーグル内部のサーバ運営の根幹に関わるのでそうそう簡単では無いでしょう。想像ですが。

まあグーグル自身がやる、って言ってるんで可能性は0ではありませんが。まあ有料Quotaでしょう。

同じく、MapReduceをサポートするかもしれない!とか喜んでいる人が多いですが、何をするつもりなんでしょう?
#db.Model.count()が遅いから。じゃないですよね。

っていうか、
Support for mapping operations across datasets
って書いてあるんだけど、これってMapReduceなの?
違うんじゃね?

仮に使えるようになったとしても、無料はあり得ない。端的に言えば、MapReduce Quotaという項目が増えます。

30秒ルールとは別の意味で、
想定以上のリソースを食いつぶされる可能性がありますからね。

「ウォーリーを探せ」

スポーツ業界で、「周辺視」やら何やら言い出しましたが、
ゲーム業界では、かなり昔からあります「一点凝視」です。

いずれも、特定一ヶ所に集中させずに、視野全体を認識するものです。

人間の視界には、ものすごい量の情報が詰まっているわけですが、
本人が認識できているのはほんの一部です。

人間はモノを見るときに、脳内で記号に置き換える。らしい。
一種のデータ圧縮、と言って良いでしょう。
置き換えに成功したものしか認識できない。
順番に置き換えるので、分量に制限がある。というわけです。

「ウォーリーを探せ」

一緒にやってみると判るのですが、
3歳未満?の小さいお子さんは、ものすごい勢いで見つけます。
お父さんは、50秒ぐらい掛かります。テキトーに言ってます。

周辺視が出来てる、と言ってよいでしょう。
生物が本来持っている。おそらくそういう話。

じゃあ、なんで大人になると出来ないのか?
出来てないのではなくて、学校教育で封じてしまった。らしい。

小学校の国語の授業で、1文字づつ指で追いかけて音読してましたよね。
筆者はやりました。当然、認識視野も狭くなります。

アレで「1文字づつ」「脳内でも音読」する癖がついちゃってる。らしい。
友人で、本を読むのが遅い人が居たんで、聞いたらそういうことらしい。

少なくとも、人間が「読む」のに、「脳内で音読」する必要は無いんです。
外国語ではその境地はなかなか難しいんですが。
日本人が日本語を読む分には可能な筈。

筆者はそれとは別に、中学生ぐらいのときに、図書館で本を借りてきて
速読の練習をしました。故に今は出来ます。そんなに早くはないですが。

とは言え、ウォーリーを探せ、はまた脳の使い方が違うみたいですね。
もしくは速読レベルが低いせい?

凄い勢いでウォーリーを探すお子さんをお持ちの方は、
その速度を眠らせないようにしましょう。

速読は、「本が早く読める」だけじゃなくて、
「頭の回転数が上がる」気がします。

サンプリングが少ないので判りませんが。

筆者が大企業の採用担当であったとすれば、
「速読が出来る」人は、採用する可能性が高くなります。

と言っても、筆者は、大企業の採用担当じゃないので、
責任はもてません。もちろん。

関数と戻り値と例外

値を返さなくても、「関数」とはこれ如何に?

ソフトウエアでいう「関数」は値を返さない事もあります。

関数が「値を返す」と言っても、その関数を呼んだ側が、変数に入れなければ、返さないのと同義ではあります。ただし、関数の実装としては、返すのと返さないのとはおお違いです。

perlでは、関数の最後の「式」を返します。なんか過激な実装ですが、何かしら値は戻るでしょう。

pythonとPHPは、return文の式の値が戻ります。しかし、returnを書かなくてもインタプリタは怒りません。更に、関数を呼んだ側でもエラーにはなりません。

変数の中身には?null/Noneが入っています。

これは、ハマる場合がままあります。

実装者の趣味次第だとは思いますが、
  1. 配列を渡して
  2. 何らかの処理をさせて
  3. 出来上がった配列を返す
そういう関数を想定してください。しかし、例によって、プログラマは間違えますので、
変なデータ(上の場合には、空の配列とか)をもらった場合には、何かしら「変でしたよ」って言わなきゃなりません。

変だったなりに処理を続けるか、エラーにするかは悩みどころです。

エラーの場合にはnullを返す。のは割とよく考えると思います。あれ筆者だけ?しかし、returnを忘れてもnullが帰ります。


  • エラーだったのか?
  • return忘れだったのか?


デバッグが面倒臭いことになります。

そこで例外の出番です。

「例外処理」を何故「エラー処理」と命名してないかというと、「エラー」とは限らないからです。より上位の処理で、回復できる&代替できる可能性があるからです。ユーザには、「エラー」と言わないケースもあります。

例えば、営業職の人が、顧客に怒られた。しかし、上司が出張ってくれば、オトナの解決法があるかもしれません。これが例外処理です。

顧客からクレーム系は、まあエラーと言っちゃってもいいかも知れませんが、不可抗力やら外的要因やら、色々あります。

当事者の手に余る自体は、「例外」です。上司に連絡しましょう。

入力間違いなんかは、本来は、「処理関数」に入れるまえに処理すべきでしょう。そういう意味では「処理関数」の手には余ります。「処理関数」の立場では、「エラーだ」とも言えません。

Javaは、例外を馬鹿正直に実装した言語の代表と言えましょう。

関数宣言で、自分が出す予定の例外を列挙しなきゃなりません。さもないと、関数内部で、thrawさせてもらえない。しかも、呼び出す方では、必ずcatchしなければならない。

悪い手ではありませんが、面倒臭くなりがちなので、とにかくcatchを書くけど、何もしない、みたいな形骸化する可能性はあります。面倒臭いからnullを返しちまえ。とか。

とは言え、例外補足を要求しない言語だと、そのまま例外が画面表示まで貫通しちゃって、ようやく思い出すので、どっちもどっち。

って言うかね。
appengine pythonだと、return忘れとか、
例外が画面まで出ちゃったりとか。

とりあえず次回は忘れないようにエントリを書いている次第です。

2010年4月19日月曜日

世の中は完全にunicodeですが

昔話です。

今は猫も杓子もUTF-8。VistaもubuntuもUTF-8。

UTF-8は、Unicodeの8ビットエンコーディング方法なので、
Unicodeありきです。

しかし1993年に提唱された時には、アジア圏ではかなり物議を醸しました。
usenetで結構盛り上がったので、筆者もその有様は覚えています。

unicodeは、Apple/IBM/Microsoft等、アメリカ企業が決めたものであって、
ぶっちゃけ、日本語版&中国版&韓国版を
バラバラに作るのが面倒だったんだろうと。

例えば、日本ではJISコードが或るわけですが、
漢字類は概ね、音読み順に並んでいます。

unicodeの何が物議を醸したかというと、
現地に現存する国語コードを完全に無視してるんですね。

あろうことか、文字のカタチで並べてしまった。
しかも、日本語の漢字と、中国語の漢字を、混同してます。


凄い順番でしょう?

何が困るかというと、現地エンコーディング(JIS漢字)とは、
変換表を用意するしかない訳です。

結局、変換表は、アチコチで内蔵しちゃってるんですが。

例えば、「CGI言語」として有名なperl。その漢字モジュールjcode.pm

「WEB言語」として有名なPHP。

漢字コード変換フィルタnkfのunicode対応版
http://sourceforge.jp/cvs/view/nkf/nkf-2/nkf-utf8/utf8tbl.c?view=markup

仕事を増やす仕事に絶望した!

とは言え、
英語圏のプログラムに日本語対応するには、
それ以前ではオープンソースであっても、何某かの改造が必要でした。

今では「UTF-8対応」で作っておいてくれれば、
メッセージは英語のままでもデータは日本語が通っちゃいますし、
後でメッセージデータを揃えれば済んでしまう訳です。

ソフトウエア業界の全体でいえば、楽にはなってるのでしょう。

unicodeは必要悪でもあります。
故に、今更文句を言う人はいません。
10年以上経っちゃったんだなあ。


linuxのファイルシステム

前フリは辞めて、reiserfs jfs xfs の運用経験を述べます。

reiserfs
ライザーさん作。
自分の名前をつけるなんて素晴らしい度胸です。
小さいファイルを扱うのに特化、と言っちゃって良いでしょう。
一方、数百メガ単位のファイル群の大量に扱うディレクトリは、
苦手っぽいです。
大量のファイルが入っているディレクトリを検索するのが苦しそう。
CPUパワーもやや食ってる感じ。
明確な長所は、フォーマット(初期化?構築?)がやたら早いことですね。
500GBのパーティションを30秒で終わります。
#他のファイルシステムは1分以上掛かります。

現在カーネルに入ってるのは、reiserfs3.6だかですが、
4の時に、カーネルパッチ責任者(?)と揉めたりとか、
ライザーさんが逮捕されちゃったりとか。
メンテナンスをしているnamesys社のサイトも
今は存在してません。

色々不遇。

jfs
IBM製。
正式にunicodeサポートをしているので、
euc-jpベースのVinelinux3.6から、utf-8ベースのubuntuへの
ファイル移動に使ったりもしました。
ですが、ファイルシステムエラーが有ると、mountを諦めます。
書き込んだシステムと、読み出すシステムが違うから??
jfsckをやればまあ復活はするんですが
そんなもん勝手に修復してくれよ、と思う。

xfs
シリコングラフィックス社製
現状では一番信用してます。
数百メガ程度のファイル群を大量に扱っても、余裕な感じ。

と言うわけで、
巷のベンチマークテストを見ると、概ねreiserfsの勝利な感じですが、
総合性能で行くと、xfs だろうか。と思う次第です。

安全なファイルシステムとは

筆者が3年間ぐらい考えてるのが、
「安全なファイルシステムとは何か」です。
いや済みません。別に作ったりとかしてないです。
時間と実力は無いので。

期待している「安全」には幾つか「層」があって、

  • ハードウエア故障からの回復
  • ソフトウエア故障からの回復
  • 人的ミスの回復
前二つについては、幾つか方法があるので、
今回は割愛&あるいは別エントリを書きます。

人的ミスとは、つまり「間違って削除しちゃった」です。
人間は間違えます。
コンピュータは、人間が間違えたとおりに実行するだけです。

大抵は、削除しちゃった直後に自分で気がつくので、
「本当に削除する前の執行猶予」があれば
概ね上手くいきそうです。

「ごみ箱」もその手段の一部ですが、
人間に丸投げなので、解決には至りません。
また「「ごみ箱」に移動しない」方法も依然として有るので、
形骸化していると言えます。

その証拠が、ファイル復旧プログラムの存在ですね。

ハードウエア故障の懸念もあるので、
世間一般には「バックアップしようね」って事になってますが、
「間違って消す人間」はほとんどバックアップなんかしません。

ここまで否定的な話が続きましたが、
実は筆者自身が「間違って消す人間」なので、
馬鹿にしてるわけではありません。

やはり、運用上は、極めてフツーに使えて、
「消しちゃった!」時にサラリと復活できるのが理想です。

MacOS では、10.5以降、"time machine"を内蔵しました。
自動バックアップシステムらしい。

商用OSでコレが付くのは珍しいと思います。
復活の操作方法も、流石のMacOS。恰好良いですね。

筆者が常用しているのは、ubuntuです。
ファイルシステムでの解決策が幾つかあります。
zfs_fuse と nilfs2 です。いずれも2ヶ月以上は試してはみました。

zfs そのもので言えば、ストレージプールの発想は
やはりエンタープライズ向きでしょう。
個人ベースでやっても混乱するだけです。

筆者が試したのは2009年夏で、当時の選択肢としては、
他にOpenSolarisとFreeBSD-8が有りましたが、

OpenSolarisは、用意していたサーバ用PCでは
インストーラがまず起動せず断念。

FreeBSD-8は当時はまだリースしてませんでした。
今はリリースしてるけどZFSはno longerでexperimetalですと。
仕事のデータは入れられないなあ。

OpenSolaris版もFreeBSD版も、
zfsそのものの事情は一緒で、
メモリを大量に確保しないと落ちる。らしい。

zfs_fuse特有の欠点として、
fuse上で再現したものなのでnfsサーバ側で使えない上に、
linux上では、マジックナンバーがぶつかるらしく、
xfsと同時には使えません。
2008年で開発が止まっちゃってるのも残念。

nilfs2は、コンセプトは期待通りなのですが、
明確な欠点があり。
ただ巨大なファイルの削除と更新が、恐ろしく遅いです。
リネームも遅かったと思った。
「裏で、なんか色々コピーしてるなー」、と実感できる遅さ。

スナップショットの参照は、マウントオプションで指定するのですが、
デバイス名が本体と一緒なので、本体のマウントを一旦外さないと、
正常にスナップショットの中身が参照できません。

現状、
1TBと500GBの二つのパーティションはnilfs2で据え置きですが、
数百メガ単位のファイルを扱うと、絶望的な遅さです。
心が折れてきて、片方をxfsに移そうかと思っているところ。

2010年4月18日日曜日

「皆伝者」

プログラマは英語と付き合う商売です。
変数やら関数やら、自分で名前をつけなきゃいけない状況は非常に多い。
どんな小さなシステムでも、1個仕上げたら、百は行くでしょう。

作ってるうちはローマ字でも構いませんが、
英語とローマ字が混在してると、
後で読むときに非常に困ります。

筆者は、余程自信がなければ、翻訳サービスで検索してみて、
一応、逆変換で、ちゃんと戻るかどうかも確認しています。

筆者が現在作業中の案件で、
「講師名」を入れるカラムが必要になりました。
調べてみると、普通に teacher で良いらしいです。

一方、teacher には「先生」という和訳もあります。
teacherの動詞形は、教える&授ける&仕込む。
とにかく「教える人」なら teacher ということらしい。
職業の内容からくる呼称ですね。

しかし、「先生」には別の英訳もあります。master です。

master の和訳では、いきなりドッサリ出てきます。
動詞形は、熟練する&極める、等の意味らしいので、
「免許皆伝した者」なら職種は問わない、ということらしい。
言うなれば、本人のレベルに対しての呼称でしょうか。

教育者ともなれば、teacherで当たり前。
もちろんmasterなのは言うまでもない。ということです。

でも日本では「先生」としか呼びません。
逆に役職で呼称を細分化して終わりですね。

日本語ではやたら多くの単語を使い分けているのに
英語では単語1個で済んじゃっている訳です。
#ちゃんと訳せているかどうか心配になる場合がままあります。

その国の言葉は、その国民性をある程度反映しているような気がします。
なかなか興味深いです。

「チョーウケル」と言っても、ちっとも笑ってない件

「ウケル」というのは本来は、極めて客観的な発言で使います。「○○は△△に受けている」と言えば、概ね、好意的な評価を受けている、という意味でしょう。「受けてる」有様を見て言ってるので、多重に客観的です。

本人が言う場合は、「笑える」という意味で、好意的ではありますが、肯定的とは言えません。そーいや最近「ワラエル」って言いませんね。

筆者には20代前半の友人が居ないので判りませんが、最近の若者言葉は、他社を軽蔑するタイプのものが多いです。いやそれは我々の頃でもそうか。

「チョーウケルんだけど」

まず当人の発言であること。そして否定的ニュアンスを感じること。

無理に翻訳するのであれば「下らない」でしょうか。いや意外としっくり来ませんか。

しかも本来「ウケる」だった筈の、評価を表現する時には、別の語彙で代替しているような気がします。

それだけでももう、日本語グチャグチャなのに、「自分が楽しい」という文脈で使う例も存在するらしい。
#筆者は聞いたことはありませんが。

視点というか、支点の意味でも真逆ですね。

言葉の意味が、拡大解釈した上でドリフトしてる感じですね。なんかもう、ボキャブラリが有るんだか無いんだか、よく判りません。

wikipedia無法地帯

wikipediaは筆者も、たまーにお世話になってます。
「インターネットの百科事典です」というコンセプトは素晴らしいが、
書き足している連中が「百科事典」だと思ってないのが難点ですね。

ある時ふと思ったのですが、彼らがやっちゃってるのは、
「ジャーナリズム」、或いは「速報」ですね。
自覚はないと思います。

百科事典と週刊誌は違う。そんなこと誰でも判ってます。
判ってないのは、「誰でもすぐ更新できる」からでしょう。

ノートを見ても、分割の意見はあっても、
削除の意見はほとんど出ません。不思議ですね。

モノによっては、ノートも長文です。
この時点で、傍目には「リミッター解除」済みなんですが、
こいつ止まらなくなってるな。的な。

とりあえず、彼らに対しての、殺し文句を考えました。
これで辞めないなら、もう何を言っても無理でしょう。

wikipediaのコンセプトは百科事典。
オマエラのやっているのは、週刊誌の特集記事。

もう一つの抑止力は、「書いた奴に責任を取らせる」。
そう難しくはありません。
日本人で長文書きまくってるのは、アカウント取得者の方が多い感じです。
記事の横か何処かに、章の最終更新者の名前かIPを出すようにすればいいです。
長文ばかり書いているような駄目ライターは、うちに名前を覚えられます。

ああまたコイツか。
ホントコイツ、日本語が下手だなー。

というツッコミも現状では困難なので。

地球は順調に温暖化

地球温暖化だのエコだの言い出して、
2年ぐらい?経ってますが、

幹線道路の自動車の量と、
連中の吐いてる排気ガスを見るにつけ、
温暖化は順調だな、と思います。

このグラフを見るとビビるんだけど、
左の目盛のとりかたがポイント。

高速道路が被ってるような幹線道路は、
風の抜けが悪いんで、それはもう排気ガス臭いです。

都心部なんかではこの際、条例をブチかまして、
内燃機関エンジンの車は、全面禁止条例とかしちゃったら?
と思わなくもありません。
筆者は使わないので、ノーダメージです。
#バスはたまに使います。渋滞が減ってくれれば言うことなし。

第一、補助金だけで、電気自動車は増えないでしょう。
人間は、「制限」が無いと、幾らでもサボる生物ですから。
筆者がそうです。

ガソリン税の使い道が、まるで不明確なんですが、
もういっそのこと大増税しちゃって、
電気自動車の補助金に回せと思う。


2010年4月17日土曜日

水を打ったように静かな職場

筆者私見を言わせていただければ、
職場はあるていど、雑音があってしかるべきです。
何かしら相談だってありますよね?

私語もある程度は認めても良いでしょう。
人間息抜きが肝心です。
もちろん私語が回りの邪魔になっちゃいけません。
邪魔だとおもったらストレートに文句言えばいいじゃないですか。

その(ストレートに文句)程度のことで遠慮してるなら
他のことでもさぞかしギクシャクしてるでしょうよ。
もっと先にやることがあるだろ、って話ね。

プログラマ稼業、ある程度の集中は必要です。
他の職場でもそうでしょうが。

「五月蝿いと集中できない」という人も居ますが、
ただこれはもう、責任転嫁と言っていいでしょう。
いやむしろ?混ざりたいならそう言え。

もちろんそれは度合いによりけり。
パーティションの向こうで、怒鳴り合ってるなら別ですよ?

しかし大抵は、雑談レベルのことを言っていたりする。
50デシベルとかそんな感じの。いや測ってませんよ。

労働報酬をもらったらプロです。
プロなら、自分なりの「集中方法」があってしかるべき。

プロじゃないって言い張るなら、今から総務に掛け合って、
時給900円にしてもらってください。
当然、お茶くみもやるんですよね?

脱線しました。

人間は、騒音にすら慣れる生物です。
線路脇のアパートに済めば、電車の音に慣れますよね?
筆者はその経験はありませんが。

慣れないのは、「騒音の内容」に、興味を持っちゃうからです。

事務所の「その辺」での会話だと、
どうしたって耳に入っちゃう。

「くっだらねえ話してんじゃねえよ!」
全部聞いちゃってるってことですよね。

繁華街の雑踏を「五月蝿い」という人はあまり居ないでしょう。
個々の会話まで聞き取れないからです。
興味が持てないわけですね。

同様に、ある程度の雑音のある職場なら、
大抵の雑談は、埋もれて気になりません。

水を打ったように静かな職場だと、
部屋の隅で、誰かがゴミ箱蹴っ飛ばしても気になります。

期末テストかよ!

部長が怒鳴ろうものなら、部屋中に響き渡ります。

むしろ集中できなくね?

とは言え、これは、大企業特有のものでしょう。

10人未満の小さな職場であれば、
年がら年中雑談するのは無理でしょう。

筆者の体験では、BGMを流しちゃってる例が多いと思います。

2010年4月16日金曜日

appengineでMapReduce。は無料の間は多分無理

グーグルといえば、appengine。
appengineといえばクラウド。
クラウドといえばMapReduce。

などという、変な3段論法があり、
appengineで頑張ってMapReduce使うぜー、
みたいな風潮がありますが。

正直、判ってねえなあ、としか思えません。
いや承知でやってるなら本人の勝手だけど。

グーグル内部のリソースを消費してもらっちゃ困る訳です。
そうならないような絶妙のサジ加減が、Quotaなのでしょう。
逆に、無料なのは、「勘弁できる負荷」だからでしょうよ。

HTTPで外部を叩くのは多分ありえません。
2秒のタイムアウトがあるので。
しかもこれを撤廃することは無いでしょう

appengineでは、taskqueue経由で、
バックグラウンドプロセスを幾つか動かせますが、
そもそもtaskqueueは「すぐ動く」ことを保証してない上に、
実行した後も、CPUタイム制限があります。DeadlineExceedですね。
実行時間の累積にも制限があります。

Mapはtaskqueueでいいでしょうけど、
Reduceは(taskqueue頼みじゃあ)、何時戻ってくるか判らんでしょう。

Reduceが3秒ぐらいで戻ってくる話なら、タスク1個で良くね?

分散しなくて処理できる分量を、わざわざ分散して、
何が楽しいんだ?的な。

仕事を増やす仕事に絶望した!

サイエンスとしては面白いでしょう。
無料Quotaの範囲内で、ある程度の実装は可能でしょう。
それで、もの凄い処理を動かせるか?っていったら困難。

「可能」と「実用」は違うだろ、って話ね。

筆者は気にしてなかったんですが、
アマゾンでもMapReduceが有るらしいんで、
どうしてもやりたければ、そっちでいいんじゃね?と思う。
http://aws.amazon.com/elasticmapreduce/

USB2.0は、あんまり早くない。USB3.0でもいいけどその前にIEEE1394を使ったらどうか

筆者は、USB(2.0以下)を信用してません。期待してない、と言った方が正しいか。

USBは、本来はキーボート&マウスなど、低速デバイスの接続を意図したものでしたが、
マスストレージクラスに対応してはいても所詮はマウス用。低速もいいとこでした。

USB2.0で大幅高速化。ハードディスクでの接続が実用的になりました。

なのは良いのですが、筆者はこの時期に、強引にWindows98で、USBストレージを使おうとして苦労した経験があり、それが不信感につながっています。

まず、USB1.0と2.0は、上位互換なので、USB2.0デバイスでも、USB1.0でつながってしまう場合がある。何かの間違いで、って事は21世紀ではもうないと思いますが、
「面倒なんで前面の(USB)端子に挿しちゃった」ってのは多いでしょう。

PC筐体の前後にそれぞれUSB端子がありますが、前はキーボード用なのでUSB1.0、
後ろはストレージ用なのでUSB2.0、というオヤクソクがあるらしいのです。

お蔭さんで、USBフラッシュメモリを挿すのが面倒臭いです。いや、前に挿してもいいんですが、遅いでしょう?

ヘビーユーザの方なら、割と早い時期に気づいているでしょう。USB2.0は、ハブを経由すると、スピードがキッチリ半分になります。また、ハブに、USB1.0/2.0を混在すると、USB1.0の巻き添えで、USB2.0機器のスピードが下がります。

筆者はなんとなく気づいてましたが、USB3.0の説明で、理由が判りました。
「(USB2.0の通信は)半二重だから」ですね。

半二重は、通信用語です。

道路工事で、片車線しか通行できない。アレです。往路と復路が、同時に通信できません。

つまり、Aドライブへの書き込み(往路?)と、Bドライブからの読み込み(復路?)が同時には出来ないってことです。更に、ファイルコピーとなると、一旦PCにデータを戻さなきゃいけないので、ハブ〜PCの経路の帯域で、頭打ちになります。繋げば繋ぐほど、速度的に損をします。

Y字路を想像してもらって、Yの右上から左上に行き来したいんだけど、かならず下の根元を経由しなきゃならないんです。しかも根元部分は、片車線通行です。
渋滞するに決まってます。

USBハブに接続した、ハードディスク同士のファイルコピーが遅いのはそういう事ですね。USB2.0の理論的速度は、そうそうは出ません。

一方、筆者がストレージ用として信頼しているのは、IEEE 1394です。

アップル社が、Firewireとして考案?した奴ですが、
ビデオ同士の接続用として、PC以外では割と普及してるかな?

1394ハードディスクは、USB2.0に比べて、1.4倍ぐらい早いです。早さは、繋いだだけで分かると思います。

2年前の比較ですが、グラフにしてくれてる人が居ました。
グラフの形は一緒ですが、メモリの縮尺が違うので注意。

いざ繋ごうとすると、
ノートPCでは、地味に1394端子がある機種も、あります。
最近流行りの、超小型デスクトップでは、USBオンリーだから無理。

しかし、1394外付けハードディスクの値段も1.3倍ぐらい高かったりします。
概ね、同容量のUSB2.0機に対して、+5000円ぐらい。

wikipediaの記述を信じるなら、特許料金の違いらしいです。故に周辺機器がどうしても高くなる。え、5000円もするの?

一方、USB3.0規格が始まったのはいいですが、出始めなので、ドライバが熟れてないかもしれません。Windows98の時のトホホ経験が、走馬灯のように。

今のところ、対応ストレージの価格帯は、IEEE1394b用と同程度ですね。

じゃあ、1394bでいいんじゃね?と思いました。

最近では、SATA/eSATAという選択肢もあります。実際かなり早いのですが。
アレは本質的にIDEの継承者なので、ポート1個から、何台も繋げることを意図していません。端的に言えば、SATAカード1枚につき、4台づつです。
まあ十分っちゃ十分かも知れませんが。

IEEE 1394の場合は、デイジーチェーンと言いまして、PCからハードディスク1台めに繋げる。1台めの開いてるポートから、2台めに繋げる。以下略。と言うことが出来ます。スピードはあまり落ちないと思いました。正確に図っては居ません。

更に、「ハブ」が要りません。「ハブの電源」の心配も要りません。USB機器をお使いの皆さんは、沢山のACアダプタで、コンセント回りが大変なことになってますよね?

「お前がそこまで言うなら、IEEE 1394を使ってみようかな?」と思った貴方。いや知らないけど。ショップ製で1394内蔵のものは稀なので、増設が必要です。

増設カードの中で、USB2.0/IEEE1394/ギガビット、なんて欲張りのも、何種類かありますが、これは、IEEE1394ポート以外は余りスピードが出ません。理由は、内部的にPCIブリッジが入ってるらしいので。なので、それぞれのインターフェース専用カードにしましょう。2000円しません。

2010年4月15日木曜日

XMLは「固い」とお嘆きの貴兄に、YamlとJSON。

ソフトウエア業界で、XMLを知らない人は、
21世紀の現代では居ないでしょう。
15年以上前の、発祥当時は、
知る人ぞ知る的な面が多かったのですが。

XMLは、端的に言えば、HTMLのイトコです。
厳密には、HTMLのXML準拠がXHTMLで?
XMLの複雑版(?)のSGMLが、だったか?

#調べてもらえば済む話なんで、本稿では正確さは目指しません。

不等号によるタグで、囲んだり挟んだりして、
データの階層構造を表します。
HTMLのFONTタグやらAタグやらが、
まさしくそうですよね。

しかし、XMLはエンタープライズ界隈発祥なので、
Javaと同じ業を背負っています。「固い」です。

XMLは、様々なソフトウエアの「定義ファイル」として
使われているので、どこでデモ見つかります。

http://technet.microsoft.com/ja-jp/library/ee909429.aspx


面倒臭そうでしょ?
とにかく文字が多い。ギチギチです。

エンタープライズ界隈で、コレを面倒だと言う人は居ません。
面倒なのはコレだけじゃないので、
麻痺しちゃってるんじゃないでしょうか。
もしくは、Eclipse等で編集します。

まあ、データ交換言語として発祥したので、
プログラムで生成する分には構いません。

手で書かせちゃいかんだろ、って話です。

データの構造を表すのに、何通りか方法が有っちゃうのも
混乱を招く&学習しにくくなる理由でしょう。

「XML技術者認定制度」って欲分からない組織もありますね。
仕 事を増やす仕事に絶望した!

Java業界は、Eclipseを使うしかない、から良いのですが、
pythonやらPHPやらは、Eclipseに依存は無いので、
わざわざxmlの編集だけに使う、って非合理的です。
#実際、流石の使い勝手ではあるのですが。

故に、xml専用の編集ツールも、幾つか存在します。


しかし、別のエントリでも筆者が何度となく申している通り、
手段の為に、別の手段を必要とするのは、回り道ですらありません。
仕事を増やす仕事に絶望した!

結論だけ言っちゃえば、既に別の選択肢が現れています。
データ型を絞り込む事で、記述の簡素化&再構築をしています。

javascriptベースで、サーバと通信するならjson
XMLとの比較も載ってるので、エラくあっさりしたのが判るでしょう。

javascriptやpythonの、静的データ構文に酷似してるので、
プログラマには非常に馴染みやすい形式の筈。

手で書くのも苦にはなりませんが、
javascript以外でも、変換関数が付属してたりします。

更に、手で書いてもラクな(それを目指した)
フォーマットもあります。yaml
サンプルを見ると「そういうことね」と思えるでしょう。

ここまでシンプルになれば、
CSVの代替として現実的でしょう。
見た目はもちろん互換性は無いけど、用途的にね。

CSVだったら、カラム順を合わせなきゃなりませんし、
ダブルクオーテーションを含むカラムの表現がアレだったり
カンマだったり、カラムの途中で改行してくれちゃったり
取り込みはかなり面倒臭いです。

yamlはデータ構造の表現が有るので、心配は要りません。

殆どの言語向けの実装があるので、
とりあえず設定ファイルはyamlにしちゃえ、
と言うのもアリです。

2010年4月14日水曜日

PS3やXBOX360のゲームは、画面は綺麗だけど?

XBOX360/PS3も、ハードウエアは素晴らしいのですが、ゲームも「美麗映像」一辺倒なのが、逆に芸がない。

「両機種同時発売!」みたいなゲームばっかりなのでどっちを買おうか、って完全趣味で選ぶしかないですしね。ちなみに筆者は、両方共買う気はありません。

また、PS3/XBOXのハードウエアが高性能すぎて、溢れたメーカーが、WiiとかPSPに流れてきてる感じもアレですね。依然としてPS2の新作が出てるのも、なんだかなあ、と思う。

別にゲームを美麗画像で仕上げなきゃならないなんて訳じゃないんですけどね。と言うことに気づいているメーカーは、Wii/PSPに流れてしまってるっぽいですが。

と思ってたら、結局出す例もあるようなので、PS3版の開発費がなかっただけなのか?色々勘ぐり。

しかしながら、PS3に限ると、トルネ http://www.jp.playstation.com/ps3/torne/ は、
地デジレコーダとしては画期的な使い勝手らしい。フツーのレコーダは買わないで、コレで行こうかとも思う。

PSP(初代)は所持してるので、ムービーは持ち出せますし。ブルーレイ焼けませんけど、まあいいか。と最近は思う。気が向いたらPS3ゲームも出きるし

Wiiの一人勝ちっぽい

最近、Wiiの「斬撃のレギンレイヴ」ばかりやってます。
もちろん仕事と交互にです。
どんだけメリハリあるんだか。気分転換しすぎて仕事もはかどります。

#PS3やらXBOXやらのユーザも多いとは思うのですが、
Wiiの特徴的なサービスは、「ニンテンドーチャンネル」。
ストリーミングサービスです。
これまた暇つぶしじゃなくて気分転換に非常に良好です。

PS3/XBOX用も、映像配信はありますが、「ダウンロード」が必要ですね。
Wiiのそれは完全ストリーミングです。好きなところから再生も出来ます。

本質的には、Wii/DSソフトの販促サービスなので、
「ショッピングチャネル」にシームレスに飛べます。
上手い手だなと思った。さすがは任天堂。

ニンテンドーチャネルは、筆者も注目のコンテンツが
色々あるんですが。

最近はもう、NewスーパーマリオWiiばっかり。
いや面白いからいいんですけどね。
CMで放送している奴の総集編もあるし、
「自称マリオ芸人」4人を集めて、
特定のテーマに基づいて攻略をさせるという。
苦労してのたうち回る姿が、涙と笑いを誘います。

それ以前の注目は、ゲームセンターCX。有野課長です。
#ってこのページも酷いな

毎回「○○の△△を倒せ」のようなお題を貰うのですが、
いや、アレも上手いですよね。いや有野の技術じゃなくて、手口が。
有野の下手さ加減が絶望的です。
「そんなに難しい?ちょっとコントローラかせ!」って気になりますよ。
逆に、たまに出てくる、助っ人AD君のテクニックが素晴らしい。
いやフツーに上級者ですね。彼らは。

最近では、プロデューサ氏が出演して、売り込む、という手口が画期的です。
ラインナップは、海外原作のゲーム。
そして、プロデューサが、ルイ ラマール氏 http://twitter.com/Louis_Lamarre
いや、この人の話、面白いです。完全に、日本人です。
ムービーの中で「えっと」「しょうがないです」とか言います。
変な日本語を繋いで、真顔でゲームスタート。は、味です。

今のところは、ヨーロッパ圏の製作のものが多いですが、
「美麗画像ありき」に完全に逆行するゲームデザインです。
iPhone用アプリで、似たようなの見たぞ?と思ったのですが
多分気のせいでしょう。

句読点フリーで文章を難読化

最近、ブログやらなにやらで、文章の総量が増えても居るでしょうし、
大量の文書を読むようになったこともあるのかも知れませんが、

句読点フリーな文章が、実に多いんですね。

例えば、こんな文章があります。とある週刊誌の4/27号。
ただ画面が大きい
iPhoneではない。

一瞬、どこで切るのか悩みませんか?改行は原文のままです。
iPhoneの直後に、句読点を入れればそれで解決する話です。
しかし、大きい、で一旦改行しちゃってる。体裁の都合でね。

結構有名なサイトでも、長々と書いちゃってるサイトは多いですね。
たとえばここ。

http://gigazine.net/index.php?/news/comments/20091028_nttdocomo/

このリリースによると、NTTドコモは新設される基本使用料780円の料金プラン「タイプシンプルTM(バリュー)」と月額315円のiモード付加機能使用料月額の合計1095円を毎月支払うだけでドコモだけでなく他社の携帯電話などに対してもメールが送受信し放題となる「メール使いホーダイ」12月1日から開始するそうです。


読みにくくね?
javascriptの難読化が、まさにこんな感じでしょ?

日本語に句読点があるのは、必要だからです。
英語は、英数字しかありません。英単語の区切りは、
空白を入れなければなりません。

一方、日本語は、漢字&ひらがな&カタカナが入り混じっているので、
なくても単語の区別は、不可能ではありません。
しかし、前述の例のとおり、漢字が6文字以上も続いちゃったら、
熟語なんだか、助詞を忘れてるんだか、非常に読みにくくなります。

適切な句読点、あるいは、適切な助詞があったほうが
格段に読みやすくなるはずです。

更にありがちな文章が、その説明も、説明が先で品詞が後で出てくる。
「○○は、△△である」って書けばいいのに
「△△である○○」って書いてしまう。
格好イイ気がするので、使いたくなる気持ちは判るのですが、
実はこの文体は、判りにくいです。

何の説明だったのかが、最後にやっと判るからです。

更に困ったことに、△△の説明の途中で、□□の説明を始めちゃう。
こんな事したら、文章がどんどん長くなるに決まってます。

筆者は個人的には、再帰的説明保留と呼ぶことにします。

上の例では、料金のプラン名の話、サービス内容の話、詰め込み過ぎですね。
パワーポイントで、日夜大量の書類を作ってるアナタ。も、同じ病気です。

階層構造で表現するならこうなります。

  • NTTドコモは
  • 合計1095円を毎月支払うだけで
    • 新設される基本使用料780円の料金プラン「タイプシンプルTM(バリュー)」と
    • 月額315円のiモード付加機能使用料月額
  • 「メール使いホーダイ」
    • ドコモだけでなく
    • 他社の携帯電話などに対しても
    • メールが送受信し放題となる
  • 12月1日から開始するそうです。

合ってる?間違ってても責任取りませんけど。

説明の階層が2段、それが2組あったら、もうこれは読みにくい。
上の文章がその証拠です。

筆者私見では、限界は2段×1組です。
無闇につなげても、判りにくくなるだけってことです。

筆者が添削するとこうです。
  • NTTドコモは、料金プラン「タイプシンプルTM(バリュー)」を新設した。
  • これと従来のiモード付加機能を合わせて、「メール使いホーダイ」ドコモを含む各社携帯電話などに対してもメールが送受信し放題となります。
  • 料金は、タイプシンプルM 780 + iモード付加機能使用料月額315円 = 合わせて1095円の固定
だいぶ読みやすくなったと思うのですが、どうでしょうか。
内容が正しいかどうかは、気にしないことにします。

って言うか、料金プランも判りにくいんで、説明しにくいのは確か。
筆者も、こうやって「解析」してみなけりゃ、何のこっちゃ判りませんでしたから。

読まないで欲しいjavascriptを、難読化するなら判ります。
呼んでほしい筈の文章を、難読化してどうすんのかと。

2010年4月13日火曜日

清書ツール

マイクロソフトオフィスを愛用しちゃってる人は、
日本中にかなりの数に登ると思います。

買ってきたPCの中に入ってりゃ、そりゃ使うでしょうよ。
会社のPCに入ってなけりゃ、
そりゃ家から持ってきて入れるでしょうよ。
#筆者はやったことはありませんが。
それはマイクロソフトが望んだことでしょう?
プロダクトアクティベーションとか今更何をやってるやら。

しかし現実問題、ワードもパワーポイントも、
「画材」としてしか使ってない人が殆どでしょう。

従来まで「紙」でやっていたことを、
そのままワードやらパワーポイントやらで続けようとします。

日本人の場合は「帳票」って奴があるらしく、
キレイに罫線を引いてレイアウトした「帳票」に
ギチギチに文字を書き入れるのが美徳です。
上司の承認印をもらう欄も忘れちゃいけません。

電子化しようとしても、「帳票」からどうしても離れられません。
ワードでは罫線でのレイアウトがやりにくいので、
エクセルを使う人はかなり多いです。

しかしエクセルは、ページの概念が希薄なので、
「ページ」の代わりに「シート」に分けて書きます。
めくるのが面倒くさいんですけど。
それに文字を入れるときは「罫線を避けて」書かなきゃならない。

正直、MS-DOSの「ワープロ」に戻った心境です。
皆さん、よく平気な顔してやってるなと思います。

おっとイケネエ。はみ出しちまった。フォントサイズを縮めて、っと。
これで入った。

貴方が資料を作るために、パワーポイントと向かい合ってる時間の殆どは、
レイアウト調整に明け暮れてることでしょう。

手書き時代より、キレイに仕上がる。それだけです。
手間は、下手すると増えてるかもしれませんね。

強調しておきます。
「資料を作る」のは手段であって、目的ではないはずです。
あくまで、打ち合わせなり、顧客への説明のため、のはず。

でもパワーポイントに向かい合ってるウチに、
ページ数を増やさなきゃいけない気になってくる。
綺麗に作りたくなってくる。

目的脱線、と呼ぶことにしたい。

帳票にこだわってる事自体も、業が深くてアレですが、
清書ツールとして、エクセルやらワードやらを選択するのも間違いです。

ワードは文章を書くためのもの。
例示するなら、小説を書くためのもの、
と言い換えてもいいかもしれません。
小説に罫線は使いません。
故に罫線が使いにくくてあたりまえです。

エクセルは表計算のために使うものです。
セルには、数字あるいは品名を入れるものです。
そこに文章を入れる日本人が悪いのです。

結論として、「清書」ただそれだけのために、
不適切なツールを使って、苦労を増やしている。

手段(書類作成)のための手段(清書ツール)ですからね。あくまで。

仕事を増やす仕事に絶望した!

納品物件としての、設計書類

受注開発稼業、
納品はプログラムだけじゃなくて文書も必要です。

「ドキュメント」という単語は一般名詞ですが、
この業界で言えば、設計書類の事を指す。らしいです。

20年ぐらい前までは、ドキュメントの厚さで、
受注金額が決まるという良く判らない風潮がありました。
作った方からすれば、ある程度の達成感がありますが、
受け取った側はそれを使うかって言ったら使わないです。

ウォーターフォール型の、古典的開発スタイルは、
最初の設計書類と、後期のプログラム実装とでは、必ず乖離があります。
なぜって、修正が面倒臭いから。

故に、納品後で、「別人」が修正しなければならない場合はままあります。
契約方法にもよりますが、ソース付きで納品してしまったら、
それは納品先でも修正できてしまうので、
わざわざ発注するより、自前でやっちまえ、というのは正しいです。

その場合でも、プログラムに付いてきたであろうドキュメントは使いません。
そもそも、大量のドキュメントを受け取っても途方に暮れるだけです。
実際、途方に暮れました(実体験)

仮に読んだとしても何のこっちゃ判りません。
4.5次元の「仕様」を、2次元未満の文書に落とす訳ですから
自分の期待している「次元」でなければ、推理小説読むようなもんです。

有る程度の熟練者なら、プログラムを読んでしまった方が早い。

そして、その別人の修正によって、
さらにドキュメントとプログラムでの乖離が大きくなります。

なぜそんな事が起こるのか?

理由は簡単です。
ドキュメントに細かい事まで書きすぎたからです。。

関数名とか引数の意味ぐらいまでなら、まだ良いのですが、
関数内部のフローチャートとか描いちゃったらもうダメです。
変数名とかの話をせざるを得なくなる。乖離の危険が大幅アップ。

そもそもフローチャートを書こうというのは、
プログラムの修正コストが、非常に高価だった時代の名残り。
ディスプレイもキーボードも無かった時代。

  • パンチカードだの、
  • 紙に書いてパンチャーに渡すだの。
  • 順番待ちだの。

黙って待ってる訳にもいかないので、紙と脳みそでデバッグするしか無かったのです。

昔話です。筆者は伝説でしか知りません。

フローチャートが全面的に要らない。とは言いません。
製作者が、思考を整理するためには非常に有効です。
ただし、納品物件としては、要らないんじゃね?と思う。

20年前ぐらいまではまだ良かった。予算はあったので。

ところが21世紀になってみたら
物件自体が、小規模化&短期化&低予算化してますので、
ドキュメントを書く時間すら惜しかったりします。

本当に細かい話は、ソースを読んでしまった方が確実です。
そして、納品物件としてのドキュメントは、
オヤクソクではなく、目的を考えるなら、
ソースを「補間するモノ」でなければなりません。

要件定義だけはすり合わせる必要がありますが、
クライアントの想像力が豊富でないと、大抵何の話か通じません。
結局、修正せざるを得なくなります。
じゃあもう作ったの見せちゃった方が早くね?

それでも依然として、「COBOLで慣らした」感じの方々は
エクセルで罫線を作り込んだフォーマットを持ってきて
そこに文章を入れたくて仕方ないらしい。
「帳票」って奴ですね。

エクセルやらワードやらを、
結局「清書ツール」としか使ってないので
運用は、「紙文書」を逸脱して居ません。
ということに気づいているのか居ないのか?

それはそれで問題があるのですが、それは別の機会に。

2010年4月12日月曜日

C/C++言語の反省

色々なエントリにバラバラに書いちゃったので
一旦纏めます。

21世紀現在に至っても、
世の中の手続き型プログラミング言語は、
どこかしらC/C++に似た部分があります。

言い換えると、C/C++言語の反省点を踏まえて
言語設計をしていると言えます。

C/C++言語の、筆者の考える反省点は次のとおりです。

  • boolean型が無い。
  • 関数の戻り値として、1個しか返せない。
  • 生ポインタ。
  • 故にメモリ管理が手動
  • (template)
  • プリプロセッサ
  • #include
  • (例外)
  • (名前空間)
  • (多重継承)
そもそもの話、C言語自体設計が古いので、
現状のメモリ事情やら、ソフトウエア技術やらに即して居ません。

象徴的なのが、「きめ細かいメモリ管理」を「人間がやる」ところ。

メモリが狭いって言ったって、携帯電話でもメガの単位はあります。
キロバイト単位を節約して、8ビットCPUを絞り出していた時代とは違います。
その証拠に、イマドキのケータイアプリは、概ねJavaです。

ポインタはC/C++の歴史的魔道と言えます。
メモリ管理方法が極めて少ないので、多重ポインタで実装するしかありませんが。
その中のどこかに構造体ポインタが挟まってたらもう駄目です。
この宣言がどエラい苦労します。
もはや呪いのアイテムです。

Cの時代は、メモリ確保と、その用法が完全に無関係なので、
何バイト確保しようが、それをいくらでも逸脱できます。
故に、バッファオーバーラン等の危険が常に付きまといます。
気をつけます、って言ったって、限界があるでしょうそりゃあ。

C++では、一応class宣言があって、new/deleteが有りますが、
deleteが手動だったりしますし。

プリプロセッサは、
プログラムソースを、コンパイラに入れるまえに書き換える。
コンパイラの機能があまりにも少ない故の、魔道具です。

「構造体宣言の前半の中括弧まで」を展開するマクロとか
ソースとマクロ定義のどっちを見ても、気持ち悪そうな実装が出来ます。

「関数の宣言に、特定のナニかを付け加えるマクロ」なんかは、
オープンソース業界の、軽量言語の実装では今でも散見します。

#includeは、
関数定義を、外部ファイルからサラリと読み込む方法がないので、
ソースプログラムを書いたら、*.c/cppと*.hの一組を書くのが「お約束」で、
「ウチの関数を使いたかったら#includeしてね?」って事になってますが、
その*.hは、利用のためだけじゃなくて、本体の実装のためでもあるので、
あちこち#includeを渡り歩いています。

これがまた面倒くさい。
多重include防止の為の #ifdef とか、もう生活の知恵の極致です。

#includeの向こう側が書き換わっちゃってると、
関数の引数とか、構造体の形が変わっちゃってるかもしれないので、
全てリビルドせざるを得ません。

そのためのmakeやらmakefileやらはもちろん或る訳ですが、
仕事を増やすための仕事に絶望した!

関数の戻り値が、1個しか戻せないのは、結構あちこちでハマリます。
構造体をnewしてreturnするとかは、C++ではあまりやりたくないので
1個だけreturnして、残りは引数に、参照渡しで入れ物を貰う。

C++では、「オブジェクト指向っぽいナニカ」が出きるようになりましたが、
多重継承という呪いのアイテムも付いてきました。

仮想関数やら、オーバーライドやらは、Cの延長線上では、
関数ポインタで実装するしかないわけですが、
ネイティブコンパイラであるが故に、「関数の順番」が非常に重要です。
#コンパイルしちゃった後は、オフセットでしか参照してないらしいので。

マイクロソフトも、MFCやらOLEやらで、七転八倒した形跡があります。
#そして、やっぱり辛くて、C#を産むわけですよ。

とまあ、反省することしきりですが、

筆者がC/C++を使わなくて済んでいるのは、
(例えば)python/PHPの作者がC/C++で実装しているお陰。

ありがたいことです。

2010年4月11日日曜日

Javaは「固い」とお嘆きの貴兄に

Javaは、1990年、C++の反省を踏まえて、
Sunの誰かさんが作りました。


と、言う訳で、
プログラマに「要らん苦労をかけさせる全て」を、
Javaで、解消しようとしたわけです。
実際、前述の問題点は概ね解消してますが。

新しい別の苦労が産まれてしまった、というオチ。

  • 1ファイルにつき、publicクラスは1個づつ。
  • パッケージ名は、同名のディレクトリに置く。

それ故に、深い深いディレクトリに、
細かいファイルがドッサリ出来る事になってしまった。

#大規模&分担開発がやりやすくはなってる。と思うけど。

これはこれで、人間が管理するのは現実的ではないでしょう。

IBM程の企業が「eclipseを開発するしかなかった」のも道理。

一昔前までは、Java至上主義みたいなところがあり
そういう人々は、軽量言語をカス呼ばわり。
「PHPだと遅くて駄目ですね」みたいな論調が多かったのですが、
大事な話が抜けてます。

  • エンタープライズなサーバPCは、そりゃCPUが強いし、メモリも広大。
  • 故に、「重たい」JVMを動かしても、そりゃ早いでしょうよ。
  • 故に、「軽い」PHPなら更に早くなる筈なんだが?
#重い重いと評判のWindows Vistaですが、
#同じPCに、Windows 95を入れると、目の覚めるような早さ。らしい。
#インテルの苦労は、マイクロソフトが全て無にしています。

「楽天がPHPを採用」あたりから風向きが変わってきました。

言語は、所詮は道具なんで、客観視が大事です。
色々使い比べないと、良さも悪さも判りません。

Java VM上で、「Javaでない言語」を動かす試みも結構あります。


いわゆる軽量言語寄りのラインナップが印象的ですね。

全く新しい言語も


そうです。Javaでの開発は、皆も辛かったんです。

「webアプリケーション」は、ネイティブアプリに比べると、色々面倒

情報漏洩やらの懸念から、
企業では、従業員個人単位での単体アプリケーションの運用を辞めて
シン(thin)クライアント化やら、web化やらに進みつつ有ります。
3年ぐらい前から?

web化については、従業員PCに入れるのはブラウザだけで済むので、
「情報管理統括部」としては、大幅に気楽だとは思いますが、
作る方は、むしろ手間が掛かったりします。

#ソリューションの本質は、「苦労」の箇所を「変える」事なので
#開発稼業は、ある程度それを覚悟してやってる訳ではありますが。

例えは、「登録をしたい」と言えば、
基本的に、

  • 追加
  • 検索
  • 修正
  • 削除
  • (終いには)変更履歴、

の4〜5機能の実装を含んでいます。
「アンタ、「登録」としか言わなかったじゃないか!」
とゴネても無駄です。結局作ることになります。

webベースでこれらの実装をするのは、実はかなりコスト(手間)が掛かります。

  • 従業員データは、dbに入れるでしょう。
  • 編集画面は、htmlで書いて、ブラウザに送ります。
  • ブラウザ側で、人間がFORMを埋めて、submitして、サーバに送ります。
  • 空欄チェック、全角半角、英数字、メイルアドレス書式等
  • サーバからチェック結果を戻す。
  • サーバは、dbに格納する。

上記、3段階で、全て、入力項目の管理をしなければなりません。
それ自体は、単体アプリでも必要ですが。

webベースで勝手が違うのは、
ブラウザとサーバの2ヶ所で処理する事です。
しかもその間の通信方法は「HTTPでなければならない」。

入力に不備が有ります、と画面に出すだけで結構苦労します。
サーバ側の実装はPHPだったりJavaだったり、
ブラウザ側はHTMLで、とか言語も違ったりします。

加えて、編集+新規+削除 それぞれで
似て非なる実装を何回か繰り返さなければなりません。

更に、これを「○○管理」全て、繰り返す訳です。

余程の工夫をしないと、工数削減は出来ない、と言うのは
そろそろお解り頂けるでしょうか。

やっつけ仕事で、コピペしても良いのですが、
実装量は確実に増えます。バグりやすくもなります。

筆者が言うまでもなく、
これをどうにかしようという動きも当然ありまして
とっくの昔から、地球規模で進んでいるわけで、
それぞれの言語で、幾つかのフレームワークが産まれています。

しかし「それを持ってくればOK」、で済めばプログラマ要りません。
クライアントの「担当者」がやってみれば良いです。
#本当にそれで済んじゃえば、商売あがったり、な訳ですが。

グーグルが始めた「ajax」は、実はその「どうにか」の一つでもあります。
ブラウザjavascript側に、大部分の処理を移譲することで、
ブラウザとサーバの通信回数をゴッソリ減らせるわけです。

ですので、
ごくたまーに「IE6で、しかもjavascript禁止」だと、
血の気が引きます。ザザーっと。

8年前のテクノロジーに付き合わなければならなくなります。
2010年現在で、改めてIE6互換環境を用意するのにもかなり骨が折れます。
正規で入手する方法は、既にありません。
正直、割増料金が欲しいぐらいです。

マイクロソフト本人が「IE6よりIE7の方が安心」って言ってるんだから
いい加減入れ替えましょうよ。「IT推進部」の皆さん。

自分で「より快適」とか言っちゃだめでしょう。

2010年4月10日土曜日

最大?

とある駐車場の看板にて

1日最大2000円


最高じゃね?

世界初!グーグルOS特別付録ディスク2枚!と謳ってる、

とある雑誌のフリーソフト紹介記事。35ページ。

最大42ヶ国語に翻訳して


最多じゃね?

同じ雑誌の別の記事。17ページ。

他の人に見られたくないファイルを復旧困難な状態で削除できる。



復旧困難な状態まで じゃね?

同じく21ページ。うわこれ酷いな。

USBメモリーをパソコンの鍵をして扱う


「を」?中国の方?

それにしても校正すらしてないのかと。

appengineの真骨頂は、pythonにあり

日本の、エンタープライズ界隈の方々は強情で、
app engineのdatastoreを難解だと感じている様です。+

JavaのJVMによる、他言語実装、例えばrubyもあり、
http://jruby.org/
app engineでrubyを使う人も居るには居るらしい。
http://code.google.com/p/appengine-jruby/

RDBのJava実装がありまして、
OpenOfficeのBaseでも内蔵してる代物なんですが、
http://hsqldb.org/

これをdatastoreのミドルウエアとして使った人も居ます。
http://www.littlesoft.jp/sql4g/

確かに、RDBMを使えれば、リレーション使いまくりですが、
そもそもJavaは、「固い」言語なので、datastoreの柔軟さが活かせません。

って言うか、そこまでpython使いたくないですか?と聞きたい。

pythonのwsgirefとか、webappは、JavaのServletに近い考え方ですね。
どっちが先だか私は知りません。
しかし、app engineの真骨頂はdatastoreにあります。

RDBに、GUIツールが存在するのは、「管理が面倒臭い」の裏返しです。
Java自身のためのEclipseが存在するのと同義です。

しかし、datastoreのORマッピングなら、ソースを修正するだけです。
pythonなら多重継承すらできます。

いやもう、SQLなんか書いてられませんよ。面倒で。

JavaのJDOとやらからでも、比較的簡潔な記述が書けますが、
http://code.google.com/intl/ja/appengine/docs/java/datastore/dataclasses.html

pythonのそれとは簡潔さが比較になりません。
http://code.google.com/intl/ja/appengine/docs/python/datastore/entitiesandmodels.html

記述量は、5倍以上ですね。
筆者は(python版の切り口に対して)「え?これだけでいいの?」と素直に感動しました。

pythonのアレを強引にJavaで例えるなら、
classのstatic変数の初期化で、カラム名&型の定義をしています。
しかもnewすると、同名の変数が、データカラムとして使えるという。
Javaでそんな記述は不可能です。pythonだからこそ可能です。

しかしこれはpython djangoのORマッピング機能上に実装したものらしいので、
http://docs.djangoproject.com/en/dev/ref/models/instances/
python djangoが、もともとイカしていたといった方が良いでしょう。

datastoreが難解なわけじゃなくて、
JDOのアノーテーションが気持ち悪いのです。
見比べでつくづく思いました。

日本の国際力

最近、英語についてグジャグジャ言ってるのかと言えば、クローズアップ現代を見たからですね。

「優秀な留学生」が、就職説明会に行ってみると、日本語力で落とされるという。
http://cgi4.nhk.or.jp/gendai/kiroku/detail.cgi?content_id=2558

いや、日本語力がなぜ重要なのか?ボク英語できません。雇っても指示できません。だから雇いません。そんな理由で落とすって、企業側が恥かくだけでしょう。

とは言え、そんなことを言っている企業が、「グローバル化」と言われてる現代をどこまで存続できるやら?就職しなくて良かったかも知れません。

このご時世、単価を上げる商売は無理でしょう。筆者自身が実感してることでもあります。売る方、買う方、両方で。

しかし、広く浅く、で行くなら、日本市場だけでは限界があります。日本中が貧乏ですからね。

英語が使えれば、地球全体を相手に出来る。母集団の量は比べ物になりません。
#オープンソース業界では常識です。

その一方で、幹部会議を「英語化」してまで、外国人を雇用する企業もあるらしい。いや英断だと思います。

筆者が資本を持っていれば、外国人を雇いたい。正直。しかし自分が暮らすだけで精一杯なので無理です。ごめんなさい。

2010年4月9日金曜日

レシートとは、領収書のこと

コンビニで、レシートを渡さない人は結構居ます。
深夜の、バイト君にこの傾向が強い。
昼間の女性でも、渡さない人は居ますが。

しかし、「レシート」は「領収書」なのです。
領収書は、お客に渡さないと意味がないものです。

某コンビニ系で、何やらクーポン券を付け始めましたが、
件のバイト君だと、レシートをわざわざ抜いて、
クーポン券だけ渡すんですよね。

渡しちゃいけないことになってるのか?
渡さない事に決めてるのか?

レシートを目の前で捨てていく客もかなり居るみたいなので、
最初から渡さなくてイイヤって気持ちは分からんでもないですが。
それは、客の決定であり、販売側が先に決めるのはオカシイ。

たまに、「レシートは?」とか聞くバイト君が居ますが、
聞くくらいなら最初から渡せ、と思う。

和製英語と、英語教育

最近よく聞くんですが、IN STORE NOW 入荷、と言う意味で使ってると思うのですが、
ものすごい違和感を感じます。

英語本来の意味は、「現在の店内(サービス)」とかそういう意味らしい。いや、むしろ、そうだよね。

在庫アリは、IN STOCK です。

IN STORE は「店内」です。

"IN STORE"に"NOW"だと言っているなら、
それは、店舗側が言うべきであって、
配給側が言うのは間違い。

故に、営業時間外に連呼するのは、間違い。

正直、和製英語だろうとしか解釈しようがありません。だって、グーグル翻訳では、どうやったって、期待した日本語に戻りませんもん。

「在庫あります」じゃなくて「店にあります」って言ってるだけよ?行ってみたら、売り物じゃないかもしれないよ?

故に、店舗なら、IN STOCKって書くのが責任です。わざわざ「IN STOREだ」という文脈を使いません。

それをわざわざ英語っぽく並べて、カッコイイ気分に浸るって、そりゃ自己満足ってもんですよ。似たような質疑は何ヶ所か見かけますが


http://kotonoha.cc/no/47470

正直、日本の英語教育はダメだな、と思う次第です。

WEBテストの自動化

受注開発に限らず、ソフトウエア開発のコストの半分以上は、
実は、異常操作への対応(端的に言えば、イタズラ対策)だったりします。

電話番号を入力する欄が有ったとして、
そこに英数字を入れるとどうなるか?
漢字を入れるとどうなるか?とか。
10文字の枠に、12文字入れるとどうなるか?とか。

それくらい対応しとけよ。と言われればその通りです。
しかし作っているのは人間。いつか間違えます。

人間なんて、ただの炭素生物。シリコンウエハーには叶いません。
いや、だって、神経細胞って、信号をアッチからコッチに流すだけですよ?
そのルールがどうやって決まってるのか、未だに判ってない。
アナログの極致です。間違えて当たり前。

そこでテストせざるを得ないわけですが。

入力項目やら入力画面やらが増えてくると、
馬鹿正直にやれば、その組み合わせは天文学的になり兼ねません。

しかしテストするのも人間なので、テスト自体が間違ってました、
なんてメタな問題もあったりとか。もう何が何だかね。

結論として、馬鹿正直にテストする工数も含めるなら、
制作費に含めて、「お見積もり」せざるを得ません。

しかし、このご時世。そうも行きません。
高い、と言われるでしょう。

何で「高い」と言われるのかというと、
自前のスタッフで作ったらどうなるか、という工数感があるからで、
そりゃ自前で作るんなら、バグってもゴメンなさいで済みますから。

でも受注開発ではそうはいかないでしょう。
バグらないのが、責任ですからね。

じゃあ、バグっても
「ゴメンなさい」で済ませてもらえるなら、安くできるのか?

YESです。

#直しません。と言ってるわけじゃないです。
#「バグだらけ」でもキレないでくださいね。と言っています。

「テストは余りやらずに提供しちゃいます」と言いきっちゃう。
テストの工数は大幅に減らせます。
もちろんそれだけじゃ済まないので、
クライアントもしくは中請けがテストしてくれる事が前提ですが。

手動テストは諦めて、自動化するのも手です。
webベースの案件であれば、Seleniumシリーズがいい感じです。

ただこれでも、
すべてのパターンを網羅するのは、依然として手間なので、
「直したと思ったら別の場所がバグった」、みたいな恥ずかしい問題を、
早期発見するためだと思った方が良いでしょう。

結論として、
案件としても、トラブっても一大事にならないような、
要件に落とし込まざるをえません。例えば、金勘定は勘弁。

ただし、金勘定案件は、経営上の都合やら、
色々な要因に振り回されまくるので、
CSVでエクスポートして、エクセルで何とかした方が便利でした、
というオチもあったりします。

発注側としては、中々納得しにくい点だと思いますが、
そういうものです。

2010年4月8日木曜日

Windowsの「ソフトウエアの追加と削除」

WindowsのXP以降は、概ね皆さん、お使いだと思います。筆者の仕事場というか自宅でも、仕方なく、1台稼働しています。

でもWindowsって、年がら年中「重要な更新」来ますよね。

なんかもう、「一生のお願い」を何回も言う人みたいで、笑えませんか。いや、笑えないでしょう。仕事で使ってる人は。

初代のXPは、それはもうセキュリティホールだらけ。らしい。インストールしっぱなしで、ネットに繋いで2時間放置。もうウイルスだらけになるらしい。私は試してません。週刊アスキーの記事で読みました。

網戸が穴だらけ、みたいなものです。蚊が入り放題ですよ?

それだけじゃなくて、地球上のWindows利用者が、ウイルスを培養してるので、無くなりません。って話なんですけどね。

#最近では、P2Pによる、ファイル漏洩の方が問題だったりしますが。
#色々と。

サービスパック2を入れると、だいぶマシになるらしいですが、その前に「サービスパック」じゃねえだろ。何のサービスだよ。善意じゃねえだろ。責任だろ。と思いませんか?

エラッタ(errata)と呼んでみたりとかね。「既知の問題を許容するための仕組み」らしい。オイオイ、誰も許容してねえだろ。
探してみると、フィルタリングを許容と訳しているらしい。
これは日本語訳のセンスの問題でしょうか。

Windows2000 Server辺りを未だに運用してる部署でも、サービスパック毎月入れるのが大変すぎなので、やってない。とかも聞きます。また聞きです。固有名詞は知りません。

「linuxはフリーだからねえ」で懸念するクライアンドは、最近はだいぶ減ってきましたが、逆にWindowsの何を信用しているのかお伺いしたい。

「文句を言う相手が欲しい」
→でもそれでマイクロソフトが何か修正してくれることないですよね。

「(linuxだと)操作が判らない」
→イヤイヤ、Windowsはもっと判らないですよ?

「GUIで設定するしかない」のに、「必要な機能を何処から呼び出すのか判らない」でしょう?#やっぱり、信用してないじゃん。というのは置いといて。Windows95の時に、思いませんでしたか?「プロパティって何?」

「設定の並べ方の、センスが悪い」のもありますね。Office2000辺りから、メニューが勝手に隠れるようになりましたが、あれは本末転倒もいいとこです。「いつも使う機能」は「いつもと同じ場所にあるべき」。マイクロソフトのアイツラ(誰?)は、それが判ってないんです。

Windows95から、ソフト開発のガイドラインを儲けて、「Program Filesに入れてね」なんて話になりましたが、これも実は形骸化しています。

DLL類の一部は、依然としてC:\WINDOWS\SYSTEMに「インストール」しています。

未だに、Windowsのソフトウエア管理は、無法地帯である、という証明だったりするんですが、気づいている人は少ないですね。

「インストーラ」が「インストールする」DLLの一部は、マイクロソフト自身が(開発者に)配布しているものですが、これは単体で配布できない、というライセンスになってます。

試しに、Cドライブで、mfc*.dllがいくつあるか検索してみてください。結構出てくると思います。しかもバイト数が違う。故に中身も若干づつ違う筈です。知らないけどね。

#って筆者が自分で試そうとしたら、ナニコレWindows Searchって。
#何時インストールしたっけ俺?
#「ココをクリックして検索コンパニオンを使用します」
#何を言っているのかお前は

そうであるが故に、ソフトウエアの配布側としては、自分が使ったmfc*.dllを付属させるしかない。訳です。

インストーラのやってるのは、自分に必要なファイルだけを入れること。

アンインストーラは、自分が入れた「筈」のファイルを削除すること。

なんかお役所仕事?

しかも、前述の通り、似て非なるファイルを、C:\WINDOWS以下にいれざるを得ない場合もままあり、こういう時は、アンインストーラは自信なさげに言います。

「このDLLは他のプログラムから使ってないようです。削除しますか?」
お前が入れたんじゃないのか?!お前が判らんでどうするのか?ゆとり世代か?!

コントロールパネルにある「プログラムの追加と削除」では「アンインストーラの管理」をやってるだけです。

アンインストーラに丸投げ。
アンインストーラは、人間に丸投げ。

タイムスクープハンターの音響演出に思う。

手持ちカメラ撮影で、臨場感がウリの、
タイムスクープハンターシリーズですが、

臨場感の正体は「音」だとようやく判りました。
室内で議論しているシーンなんか、
室内で反響している音声をそのまま使ってますね。
アフレコは使ってない。

ハイビジョンやらなにやらで、
映像の解像度がもてはやされてる昨今ですが、
3次元になろうが、ハイビジョンになろうが、
人間の目は前にしかついてませんし、視野は左右せいぜい180度弱。
視界の中で「認識」してる部分はより狭くなります。

後ろも「見える」のは、聴覚だけです。

目の不自由な人よりも、耳の不自由な人の方が、
事故が多い、と友人に聞いたことがあります。

iPodやらiPhoneやらの普及は良いのですが、
音楽を聞きながら歩くのは、客観的にはかなり危険です。

しかもケータイいじりながら、とか、
視覚も聴覚も塞いじゃってるのに、事故に遭わないでいられるのは
奇跡とか運とかじゃなくて。

まわりの人に、避けてもらってるから。

と言うことに気づいてない人が多すぎます。

2010年4月7日水曜日

MySQLはそれほど速くないし、PostgreSQLはそれほど遅くない in 2010

MySQL 5.0時代(2011年後期現在での最新は5.5.17)と、
PostgreSQL 8.0時代(2011年後期現在での最新は9.1.1)の知識で言います。

今では更に事情が変わってる可能性があります。
まあ、昔話と一般論を述べてると思ってもらえれば結構です。

同時期に作成したらしいベンチマークが或るので、貼らせてもらいます。





#大小文字の打ち分けが面倒なので、固有名詞は小文字で圧します。

端的に言えば、mysqlはマニュアル車、postgresqlはオートマチック車です。

mysqlは実は、特定状況下でのみ、高性能を発揮します。らしいです。
特定状況下は、筆者は存じません。

大量のチューニングパラメタが或るのも、特徴でしょう。
これは、悪い特徴です。適当に使うと、まったく性能は出ません。

mysqlの強力なアドバンテージは、レプリケーションの内蔵。
それに「尽き」ます。それだけしか無い。
レプリケーションの設定は、非常に簡単です。
「同期」とは言えませんが、更新のタイムラグは概ね無視できる範囲でしょう。

一方、mysqlは、不可避レベルの「苦手」が幾つかあります。

SQLの文中で、select以外では、テーブルの自己結合が出来ません。
insertの文中で、既存のレコード数を数えて、+1してinsertしたい、
って良くあると思うですが、mysqlのinnodb/myisamではこれは不可能です。

これに限らず、複雑なSQLを投入すると、
不適切なindexを使う、もしくはindexを諦める場合があります。
2段サブクエリ程度で、もう駄目な感触です。
そのための FORCE INDEX なる、SQLの独自構文があります。
#どんだけ手動なのかと

mysqlで、大量のinsert/delete/updateをすると、
性能がゴッソリ落ちます。
大量の、というのは、数十万レコード、程度ですね。

故に、遅延insertなる方言があります。
なんかindexの作成が、下手なのかなあ。という感触です。

ランダム文字列系の、ランダム順insertは、かなり遅い。と思う。
postgresqlで同程度のクエリを流したときの、
数10倍、時間が掛かることがあります。

ちなみに、postgresqlで30分で終わるinsertが、
mysqlのmyisamで3時間、innodbで12時間でした。
信じるも八卦。信じないも八卦。

また、全部deleteする場合は、trancateを使おうね、とか
いや、運用でそんなケースそんなにあるのか?と
逆に聞きたいのですが。
手動でやってるなら、truncate使いますよそりゃあ。

postgresqlの問題点としては、vacuumを懸念している人は多いと思いますが、
実は、mysqlもvacuumをやっているのです。
しかも1レコードづつ。

いや、オフィシャルで「mysqlでvacuumやってます」
なんて記述は一つもないのですが、
遅いなあ、と思ってstraceしてみたら、
ファイルコピーしてやがった事がありました。
いや俺今delete fromしたよね?なんでファイルコピーが必要?みたいなね。

トランザクション量がもの凄い多い場合、begin〜commitが遠い場合は、
これまた性能がゴッソリ落ちます。
数10レコードづつcommitすれば劇的に改善しますが。

あと、myisamテーブルは壊れる可能性があります。
修復コマンドがあるくらいですから。

実は筆者の経験で、innodbが壊れたことも一度ありました。
実験機だったので、テストデータを入れ直しましたが。

mysql自身の苦手、とは違いますが、いや筆者が苦手ってことか。
ユーザ登録をgrant構文でやるのはどうにも気持ち悪いです。

一方、postgresqlは、設定項目が非常に少なく、
起動するだけならすぐです。

しかも、結構複雑な、3段サブクエリを投入しても、
なんとか結果を返します。
適切にindexを貼れば、ちゃんと使ってくれます。
普通に使ってたら、特に「○○が苦手」という感じはありません。

postgresql-8以降、使ってないので判りませんが
(しばらくmysqlの案件が続いたので)
簡易なvacuumをマメにやるようになってるらしいので、
テーブルロックレベルのvacuumは短時間で済むようになってる。らしいです。

とは言え、大量のinsert/updateを続けると、徐々に性能が落ちてくるのは確か。

数千レコードを舐めて再構築するタイプのトリガを、書かざるを得なかった事があり、
いや、仕事で書いてね、って頼まれたんですが、
テストで何度か回しているうちに、あれ?遅くなってきた?みたいな感触はあります。
ただそれでも、2分が5分になるだけです。
倍にはなってるんだけど、元々が「待っていられる」時間です。

最悪、トランザクションスクリプトにvacuum fullを含めちゃうのは手でしょう。

総評としては、

mysqlは、SQLサポートそのものが不完全なので、SQLの記述に手間取る。
結構ありがちな状況で、ゴッソリ性能が落ちやすい感触。

postgresqlは、問題の先送りで、
更新が多いっぽいときは、トランザクションにvacumm fullと書いちまえ。

結論としては、

どうしてもレプリケーションを使いたければmysqlしかない。
その他は、postgresql使っとけ。

もうそんな気持ちです。