UIEngine だ

農家と大葉と農薬

　世界的な食糧危機が云々という話が最近耳に入るようになった。テレビが無いのでラジオで聞くばかりで本当に耳に入ってくる。日本の食料自給率が40%で、どうするか？という話もある。

　どうも、農家の人に補助金出して、もっと生産効率あげてがしがしつくれや！なんてやってるみたいだが、農薬一杯の野菜がどんどん出てくる気がしてならない。それも、「無農薬です」とラベル貼ったりしてね。食品の偽装問題も困ったものである。渡していた金の額をきくと「そこまで儲かっちゃうの？」と思いあきれることもあるのだが、とにかく困った奴らだ。

　今日は知り合いの農家の方から、夏に最適な料理を教えてもらったので紹介しようと思ったのだが、カメラ貸し出し中で家に無し、日中、炎天下にいて体力消耗して台所に立つのも面倒なので、椅子に座ってビール片手に、のんびりする。

　で、「大葉」をもらったのだが、「大葉なんて食わねぇ方がいいぞ、、、」とか何とか。

　

何しろ、大葉は虫がよくつく。以前、ベランダで育てていた時に完食された記憶がふとよみがえる。虫がついたもの（かじられたものとか）は出荷できないので、とにかく農薬を使うそうである。そんなわけで、「食わねぇ方がいい」そうだ。もらった「大葉」は無農薬で問題無いのだが、スーパーで売っている大葉がなんだか心配になった。食べたから今すぐ死ぬわけじゃないから別にいいかな、と言えば、良いのだが。気持ちの問題かねぇ。

　それで、家に戻ってきて大葉と農薬について少し調べる。

「農薬を使わない健康大葉」ミスト農法
http://www.voxtrading.jp/ooba/mist/mist.html

こんな農法があるらしい。まったくもって、大葉工場である。つくっている人は楽しいのかなぁ？？

【楽天市場】大葉(10枚)：無農薬野菜のミレー
http://item.rakuten.co.jp/millet/50009/

こちらは店の名前は「無農薬野菜のミレー」なのだが、「 【農薬等】特別栽培農産物（減農薬無化学肥料）」と書いてあったり、この大葉は少し農薬使っているということだろうか。

大葉（おおば）、宮崎県、野菜類、[ごちそうナビ]
http://gochi-navi.jp/products/view/100

これなんて見ると、素敵なパッケージである。見た目もそろっていて素晴らしい？のか？と思うが。やっぱりここまでやらないと売れないのかねぇ。

生産情報詳細 [ （農）和郷園 / 大葉（こだわりの大葉） ]
http://trace.coop-sapporo.or.jp/nosan/seisan/018_001.html

↑を読むと、やっぱり普通は農薬使って殺虫、殺菌しないとだめなのかなと思ったり。

大葉とトマトの栽培について
http://botany.cool.ne.jp/log/200307/03070039.html

↑の素人の質問と、それに対する回答見ると、アブラムシ発生して困るなら、あの大葉工場でアブラムシ発生しないのかい？と思ったり。アブラムシにとってあんなハッピーな場所も無いだろうにね。

こんな世界に誰がした。検索エンジンに表示されなければ存在せずと同じ。

　数年前、検索エンジンがそんなに便利じゃなかった頃は、ウェブの入り口はブラウザの「ブックマーク（お気に入り）」だったのだが、最近は検索エンジンがウェブの入り口になった。日本じゃYahooさまさまである。インデックスを削除された日には目もあてられない。ま、Googleさんもね。

　さらに、最近では、表記ゆれもずいぶん修正され「デズニーランド」で検索しても「ディズニーランド」が上位に出るようになった。うっかり、新しいサービス名が大手のサービス名とかぶったり（似ていたり）すると、これも目もあてられないのだ。商標の世界では、類を切って、同じ名称でも異なる類であれば登録できることになっている。たとえば、日産が自動車でX-TRAILとか取っていたとしても、石鹸でX-TRAILは取得できるかもしれない。（あくまで可能性としてできるが、審査官が自動車の名称としてあまりにも一般的に使用されているのでダメ！と言うかもしれないが。）その辺もSEO的に苦しいはず。

　その中で富士通のカーナビ「eclipse」がトップに来るのは、うーむ、どうやっているのだろうか？と思ってしまう。ウェブの世界では開発環境としてのeclipseの方がメジャーな気がするのだが、、、

　話がそれた。結局、どう考えても、どう転んでも、お客さんを誘導する導線がWEBにシフトしつつあるのであれば、検索エンジンは無視できないし、そのためにSEOなるものをがんばらねばならない。SEO業者はうはうはである。

　

で、SEOをがんばってみると、すごく、すごく、むなしくなる。「これをやって何になるの？」「アホ、ちゃうか？」と。もちろん、これをやれば新しいお客さんがきてくれて、ものが売れるかもしれないし、検索結果の上位に表示されれば露出も増えてブランド名を覚えてくれるかもしれない、とか、想像できるのだが、その作業及び成果が「楽しいか？」とか「ださくない？」と問われると、なんか変な気持になる。

　それというのも、誰かの手に踊らされているとか、そんなことじゃなく、新しい何かを見つけたり、生んだりすることとはちょっとかけ離れていて、わくわく感が少ないからなんだが。だからといってSEOをやめるわけじゃないのだが。

　最近は、細かいこと言わずに、とりあえずスタート時にはキーワードをピンポイントしたら、<title>がそれだけのページをトップにしてしまえばそれでいいじゃん、と思ったりもする。

[postgresql] ロードアベレージが高すぎると感じたらどうするか？

　ロードアベレージが3桁になろうとしているのだが、落ち着いてどう対処すべきか考えている時のメモ。とりあえずグーグル先生に聞いてみたところ、

マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
http://d.hatena.ne.jp/naoya/20070518/1179492085

こちらのエントリーが参考になるようなので真面目に読んでみる。

• top や sar がデフォルトで示すCPU使用率はCPU数(コア数)で割り算をしている。各CPUごとに値を保持している。
• ロードアベレージは割り算をしていない。各CPU(ランキュー)ごとに値を保持するのではなく、システム全体で一つ。
• 4CPU ならロードアベレージ 4.00 まで OK、は鵜呑みにしないほうがよさそう。状況によって異なるのでその他の指標も使って細かく統計を分析したほうがよい。
  • nr_running > 1 のときはロードバランスが適切に働く。そのため 4CPU なら 4.00 で割れ、というのは負荷があるときはそれなりに正しい。
• ランキューに溜まってるタスク数が CPU 毎に見れたらいいのだけど、現時点のカーネルの実装では難しい。(全体のは sar -q で見れます。)

途中でまとめがあった↑。どうやら、ロードアベレージが100になっても、CPUコアが100あるなら気にしなくて良いことがわかった^^。CPUコアいくつだったかな。クアッドｘ4だったかしら。だとすると16なのか？

　とまぁ、ロードアベレージのことはここまで。[追記]読み返してみたらロードアベレージが高すぎるときにどうするか？に対する答えをまとめていないことに気づく。しかしまとまってもいないので書きようが無いのだ。やりながらどう対処したのかいつか書きたいものである。それとサーバーはデュアルコアの2CPUだったので4ということに。100だとすると1CPUあたり25である。これは厳しい。

　naoyaのはてなダイアリーを徘徊していたら、

Linux のページキャッシュ - naoyaのはてなダイアリー
http://d.hatena.ne.jp/naoya/20070521/1179754203

なるエントリーもなかなか興味深い。参照のみのテーブルが極めて少ないので、パフォーマンスの向上にはきかないと思う。

　そういえば、なんとなくふと気になったのだが、postgresql8.3で実装されたHOTの仕組み。VACUUMいらずの運用に期待を抱かせるものだが、ORマッパーの実装と相性が悪いのでは？よく、ORマッパーはアップデート処理する際に変更する必要の無いカラム（フィールド）に対してもupdateをかける。

　そうすると、「値が変更されていなくても、DBが上書き処理して、HOTのメリットを活かせない！」と思ったのだが、真相はいかに。

[postgresql] VACUUMのメモ

　ロードアベレージが3桁に突入しそうなシステムが出現したので調査とメモ。まずVACUUMについて。ステークホルダーが複数いると萎える。すぐに調べたい情報が取り出せないとか。「うーん、隠ぺい？」と疑心暗鬼、難しいものです。Postgresqlのバージョンは8.1。

PostgreSQL: Documentation: Manuals: PostgreSQL 8.1: VACUUM
http://www.postgresql.org/docs/8.1/interactive/sql-vacuum.html

削除が全く発生しないDBだったらそもそもVACUUMする意味は無い。それから8.1から自動VACUUMが追加されたという話。それまではcontribで提供されていたものが8.1から本体に組み込まれた。postgers.confでautovacuum=trueとして再起動すると有効になる。

【PostgreSQLウォッチ】第22回 PostgreSQL 8.1，前バージョンから10カ月で早くも正式リリース！：ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20051117/224817/

OSDL DBT-1によるPostgreSQLのVACUUMに関する考察
http://ossipedia.ipa.go.jp/capacity/EV0603300125/

【PostgreSQLウォッチ】第19回 ベータ・リリースを間近に控えたPostgreSQL 8.1：ITpro
http://itpro.nikkeibp.co.jp/members/ITPro/oss/20050722/165140/?ST=oss

稼働中の実機を調べてみるとVACUUMは走っていないようなので、それが問題というわけではなさそうだ。重い統計処理でも走っているのだろうか？引き続き調査である。

[postgresql]d945gclf で postgresqlチューニング shared_buffers の変更

postgresql.confをいじってチューニングしてみる。shared_buffersから。8.3だとデフォルトで32MBになっているので、マニュアルを参考にしつつとりあえずいろいろやってみる。まずは64MBから。（※postgresqlは8.2からconfの設定値の記述方法が変わったので注意。8.1ではshared_buffersはバッファの数で指定していた）

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 258.347305 (including connections establishing)
tps = 261.384115 (excluding connections establishing)

うーむ。何度か測定すると

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 151.754114 (including connections establishing)
tps = 152.797922 (excluding connections establishing)

こういう結果が出たりもする。128MBにしてみるとどうだろうか？再起動直後が最も性能が良い感じ。

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 333.828445 (including connections establishing)
tps = 338.957658 (excluding connections establishing)

何度かやると

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 175.150097 (including connections establishing)
tps = 176.537253 (excluding connections establishing)

といった値も出る。メモリを2Gしか積めないので、1/4の512MBでやってみた。

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 373.316864 (including connections establishing)
tps = 379.637260 (excluding connections establishing)

[postgresql]d945gclfのpgbenchやり直し

　d945gclfのものを取り直したわけではないが、前回scaling factorが間違っていたのでやり直しを含めて再度投稿。

d945gclf:postgresql8.3

メモリ:2GB 533MHzで動作
CPU:Atom230
HDD:250G 7200rpm Hitachi（STATA II）

-bash-3.2$ ./pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 170.997866 (including connections establishing)
tps = 172.326453 (excluding connections establishing)

Dell PowerEdge sc440:postgresql8.3

CPU:Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
メモリ:3,114,508 kB（つまり3Gぐらい）
HDD:SATAII(7,200回転だったかな？)

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 227.489773 (including connections establishing)
tps = 228.651036 (excluding connections establishing)

Dell PowerEdge sc440:postgresql8.1

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 165.544441 (including connections establishing)
tps = 166.139285 (excluding connections establishing)
※他のサービスtomcat等も動いているのであくまで参考データとして。

[postgresql]IntelAtom搭載マザーD945gclf は使えるのか？サーバーとして。

　省エネ。世の中は省エネ。ということで、先月？発売されたIntelAtom搭載マザーボードD945gclfはサーバーとして使えるのかどうかやってみた。というか、やってみている。細かいハードウェアの話はその他のレポートにまかせるとして、とりあえずpostgresを載せてみる。

postgresqlのインストール - ももーい鯖覚書
↑参照で

ちなみに、D945gclfにcentosを入れたのだが、ネットワークカードを認識しないので、その辺は手動で入れる必要がある。先人が解説しているので簡単である。久しぶりにmountというコマンドを使った。

　さて、とりあえず、configureからmakeなのだが、makeが遅い。うーむ非力だからか。。。あるいは気のせいか。

　ちなみにこのマザーボード、メモリスロットは1本で、最大2GBである。tomcat入れて動かすには若干不安が。ネットワークも10/100Mbpsゆえいまいち頼りない。そこがネックにならないものを動かせば良いのだが。すでに２台目を手配しているので真面目に考えないといけない。

　省エネではあるが、CPU含めたマザーからの熱よりも、HDDの熱が気になる感じ。最初にケースファンが動いておらず2時間程使っていたらケースがかなり熱くなっていた。どのケースを採用するのかにもよるのだろうが、密集して使うのには向かないかもしれないなぁ。

メモリ:2GB 533MHzで動作
CPU:Atom230
HDD:250G 7200rpm Hitachi（STATA II）

といった具合。クライアント50、スケーリングファクタを60で実験。以前「scaling factor > number of clients にしないと妥当な結果になりませんよ。」という指摘を頂いていたので感謝。

-bash-3.2$ ./pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 170.997866 (including connections establishing)
tps = 172.326453 (excluding connections establishing)

以前のエントリーで使ったマシンで再度調査

CPU:Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
メモリ:3,114,508 kB（つまり3Gぐらい）
HDD:SATAII(7,200回転だったかな？)

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 227.489773 (including connections establishing)
tps = 228.651036 (excluding connections establishing)

といった具合。以前のデータと全然違いますな。以前のデータが全く使えないということでした。ちなみに、省エネということでノート用のCPUを搭載したものも準備中。来週ぐらいには結果をお知らせできるか。

　来年にかけて電気代も値上げされるだろうし、今から省エネに取り組まないと電気代もしゃれにならないぞと。データセンターの電源容量の制約の話もあるのだが。

[追記] 8.1.11でもテスト。こちらはtomcat等、他のプロセスが動いているので低めに出るのだが、予想通り。

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 50
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 158.763570 (including connections establishing)
tps = 159.305423 (excluding connections establishing)

あれ？scaling factor: 50になってる。60にしなければ、、、やり直そう。

こんな時間に起きているのは

眠い。ただ、それだけだ。UIEngineの楽しい使い方を思いついた。が。時間が無いのだよ。ふと思いついてやってみたが、「uiengine」でY!,Gともに検索結果でこのブログが一番に！UIEngine関連のエントリーはほとんどが古いものなので、過去記事から見て。右のサイドバーのリンクが使えるよ。では。

iPhoneとUIEngineと

Life is beautiful: Googleのandroidは通信事業者にとって本当に正しい答えなのか？
http://satoshi.blogs.com/life/2008/06/uie-japantvgui.html

　最近、Life is beautiful さんのブログに興味深いエントリーが続いているので楽しい。

　つまり、ハードウェアは、Appleのような強いブランド力を持ったメーカーがサービスも含めたすべてのおもてなしを提供してしまうiPhone のような「付加価値の高いデバイス」と、上の「ひかりTV向けのSTD」のように、サービス事業者がUIEngineのようなミドルウェアと通じておもて なしを１００％サーバー側からコントロールするための箱の役割をする「コモディティ化されたデバイス」という二極化である。

　言い換えれば、これはサービスの提供者とハードウェアメーカーの間で、どちらが付加価値の高いポジションをとるか、という主導権争いでもある。通信事業者は「ただの土管」にはなりたくないし、ハードウェアメーカーは「ただの箱」にはなりたくない。

この内容とか「あぁ、深いなぁ」と思ってしまう。UIEngineはエクステンション？だったかな、といった機構を使ってデバイスに特化した機能を追加することができる。つまり、やろうと思えばiPhoneにUIEngineを乗せ、iPhone用のエクステンション？を組み合わせて、より良い「おもてなし」が提供できるわけだ。これはUIEngineが小さいからこそ簡単にできるのだが、ただ、この取り組み自体がUIEngineが望む軽量VMの形から逸脱することになるので気持ち悪い。それに、本当の「高付加価値」を目指すのなら、VMかますのは不利なだけである。つまり可能であれば、いつだってネイティブ最高！最高！。

　結局、すべてのアプリケーションというかソフトウェアがウェブベース（広義のね）になっていくことを考えると、「コモディティ化されたデバイス」でも「付加価値の高いデバイス」でも、意味的には同じではあるものの、「おもてなし」が全く異なるもの（サービス）を提供できるようにしておくのは、通信事業者でもハードウェアメーカーでも無い場合には都合が良い。スティーブ・ジョブズが作り出した現実歪曲空間に中島氏も飲み込まれて楽しい立ち位置に立ったというところだろうか。通信事業者にしてみたらiPhoneが出てくるまでは、「やばい土管になっちゃう！！」なんて本気で焦る必要は無かったように思うが。

　SNSでもブログでもウェブアルバムでも何でも良いのだが、ある特定のサービスがデバイスの力を使ってブランディングできるかも？と考えられるようになったのもiPhoneの異常さのおかげ。そして、今回、中島氏がつくっている直球ど真ん中のSNSも、iPhoneでヒットすれば、他デバイスへの「おもてなし」を抑えた提供も可能である点（UIEngine）も興味深い。だからこそ直球ど真ん中を投げられるのだろうが。iPhoneで大ヒット、、、よっしゃ、他デバイスにも提供だぁ、、、「どうしよう^^;」なんてことにならないわけだ。STBでお茶の間進出も夢では無い。