2.29.2008

バグ取り&改造。

検索さんこと、正式名称「C#からインデックスサービスを利用して、普通より高速にファイルを検索するプログラム」。
インデックスサービスについて調べているうちに、余りに短い文字列だと、検索ではじかれてしまう問題点を 発見。
そんなわけで、その修正と、タスクトレイにアイコンを表示して、そこから終了操作ができるものにしてみましたよ。

ダウンロードはこちらから

インクリメンタルサーチは、インデックスサービスの検索スピードから考えても無理そうなので、実装はなし。Vistaの検索サービス程度のスピードで動いてくれれば問題ないかなぁと思っています。

そうそう、前回書いたクエリの実行速度が遅いってやつだけど、これもインデックスサービスのパフォーマンスを調整すると早くなりました。
インデックスを作成するパフォーマンスとクエリのパフォーマンスが別々に調整できるとは・・・。
でも、インデックスがきちんと作成されていないと、使い物にならないプログラムでもあるんだよな(笑)

TODOとか、今後の開発方針なんかは特に決めていないので、これでラストリリースになるかもしれないし、そうでもないかもしれない。
あるいは、他のことに興味が移れば、そちらの開発をはじめてしまうかもしれない。

そんな検索さん。ご利用は自己責任で。

2.28.2008

coLinux: MD5 sumのチェック方法。

何度か失敗したので、ここにメモとして残しておく。

1.coLinux本体をダウンロード

2.ダウンロードサイトにあるmd5sum値(ハッシュ値)をコピーし、テキストファイルに貼り付ける

3.[ハッシュ値]_*[ダウンロードしたファイル名](_は半角スペース)
となるように、ハッシュ値のファイルを修正。

4.ハッシュ値を、適当な名前でダウンロードしたcoLinux本体と同じディレクトリに保存

5.コマンドラインでcoLinux本体のあるディレクトリに移動し
md5sum -c [ハッシュ値を保存したファイルの名前]
をうち、FAILEDしなければ(OKならば)、ファイルは破損していない。

coLinux。またまたアップデート。

20日、24日、26日。
細かいバグフィックスだけど、結構続けてdevelがリリースされてる。
今回のリリースでの修正点は、cofsに関するところがほとんど。
私は普段cofsを使ってWindowsとLinuxの連携を図っているから、案外重要なリリースだ。

それから、vimのFsync failedに関する問題点も修正されているから、devel版でvim使う人は更新しておいたほうが無難かも。


2.27.2008

coLinuxをアップデート。

24日にやったと思ったら、その日にエクスプロイドコードに対処した新版が出ていたとはw
笑うしかないww

というわけで、先日に倣ってアップデート。

そういえば、私はまだ詳しく調べていないけれど、covideoやcoaudioの状態はどんなものなんだろう?
とってもおもしろそうで、今から興味津々なのだが。

2.24.2008

coLinuxをアップデート。

snapshotに2月20日版が出ていたのでアップデート。
いつもどおり、上書きだと怖いので一旦削除してから。

まずはサービスとして稼動しているcoLinuxにログインして、shutdownコマンドを使って止める。
次にコマンドプロンプトで colinux-daemon.exe --remove-service をする。
ここのところ一ヶ月ペースでリリースされていて、私もそのたびにアップデートしてるから、もう慣れたものだ(笑)

で、面倒だからそのままUninstall.exeをコマンドラインから走らせる。
削除できたら、今度は落としてきたdevel版を実行する。
今回使うのは devel-coLinux-20080220.exe
一応、md5をチェックしておく。おすすめはwMD5sumというツール。GUIなので使いやすい。
余談だが、コマンドラインが好きな人は、こっちのツール群を導入しておくと幸せになれると思う。

ハッシュがチェックできたらインストール。アップデートだから、ルートファイルシステムのダウンロードのチェックをはずす。
私は利便性の関係上、C:\ドライブ直下にcoLinuxというディレクトリを作ってそこに入れている。
あとはざざっとインストールを行ってFinish。Show Readmeは一応しておく。
でも、前回の.confファイルでの一件よろしく、重要な変更点は書かれていないんだよなぁ;

というわけで、今回も一応.confファイルを覗いてみる。
今回は私の設定に係わる大きな変更点はなさそう。
なんか、知らないうちにcoLinux起動時に好きなソフトを同時起動できるようになってる。
日々進化してるんだなぁ。

一通り確認したら、今度はネットワークの設定。
私はノートPCから無線でつないでいるのだが、slirpじゃなく、昔ながらのネットワーク共有によってcoLinuxのゲートウェイであるTAPにネットワークを共有してあげるスタイルでネットワーク接続をしている。
だから、毎回この設定が居る。でも、そんなに手間のかかることじゃないし、苦じゃない。

というわけで、新しく増えたローカル接続の名前をTAPにして、無線の共有設定をリセット。
すると、TAPサイドのIPが変わるから、いつもの図にあわせてこちらも再設定。

ここまでしたら起動テスト。
colinux-daemon.exe @configfilename.conf
で起動。
起動したら、rootでログイン→# uname -a してアップデートされた居ることを確認したら、
# ifconfig -a でインターフェイスのチェック。
今回は前回と違って、うまく動いてた。良かった。

んで、適当にpingを飛ばしてネットワークコネクションが確立されていることを確認したらshutdownする。
あとはコマンドプロンプトに戻って colinux-daemon.exe @configfilename.conf --install-service
でサービスとしてインストールする。

サービスのスタートアップの種類を自動にして、開始すれば完了。
このメモ書きながらで30分ほどの作業だった。

変更点はここに書くと大変な量になるから、素直にChangelogをどうぞ。

2.23.2008

インデックスサービスを使って、高速にファイルを検索する

そんなソフトを作ろうっていうのは、ここのところずっと言っているとおり。

C#でこの手のプログラムを作る手順としては、




・プロバイダをMSIDXS,データソースを検索したいカタログとした、string型のコネクションリクエストを用意

・そのコネクションを引数にして、OleDbConnection型のオブジェクトを作成

・作成したOleDbConnection型のオブジェクトをOpen

・検索クエリ(SQL)文字列を作成

・Selectの対象となるテーブルはScope()。検索するレコードは、ファイルオブジェクトの持つプロパティ。アスタリスク(*)は使えない

・where句の検索条件として、検索したい文字列を引数に与えたFREETEXT関数を用いる

・作成したクエリ文字列とOpenしたOleDbConnection型のオブジェクトを引数にして、OleDataAdapter型のオブジェクトを作成

・DataSetオブジェクトを作成

・OleDataAdapter型のオブジェクトのFillメソッドに、DataSet型オブジェクトと"SearchResults"という文字列を渡す

・DataSetオブジェクトに検索結果が入るので、データグリッドなどで表示する




というステップを踏めばいけるみたい。(サンプルソースを見ながら考えただけだから、もっと短い手順でOKとか、実はこういう手順を踏むべきだとかいうのがあるかもしれない)

で、今回は前回までに出来たものをちょこっと改良した奴を公開。



ダウンロードはこちらから



ざっとReadMe的なものを書いておくと、

・利用には.NETFramework2.0+が必要。

・バグだらけでも泣かない

・開発環境はVC#2008+WinXP(pro)

といったところ。

当然ですが、インデックスサービスが止まっていると動きませんよ。



さて、このインデックスサービスによる検索、前回はすごく速い!と思ったけど、いろいろいじっているうちにそうでもないような気がしてきた(笑)

もしかして、インデックスのパフォーマンスに関係があるのかなぁ・・・?

ここで終わりにするか、もう少し研究してみるかは、今後のやる気次第。

常駐→すぐに検索ぐらいまでにはするかな。

2.20.2008

C#を使ってインデックスサービスを活用してみる。

以前から書いてるインデックスサービスを使ったファイル検索について。

C#を使うとすぐに接続→検索できるっていうのは以前に書いたとおり。

で、下図がその画面。




















Macぽい画面なのは、私が単にそういうテーマにしているだけで、きちんとC#で書いているし、.NETFramework3.xで動いている。(開発環境はVC#2008)



検索する文字列にもよるけれど、おおむね2秒前後で検索結果が返ってくる。

スタートメニューから呼び出すファイル検索とは偉い違いだ。

それでいて、ある程度満足いく検索結果が出てきているので、もう少し応用したらいろいろ使えそう。

個人的には、MacのSpotlightやGoogle Desktop Searchみたく、インクリメンタルなサーチができると良いなと思っているけど、中ではSQL文を投げているわけだから、そんなに良い性能を得られるとは考えていない。

というわけで、検索文字列を入力→検索ボタンで検索→検索結果が一覧表示っていう、locateコマンドのGUI版みたいなつくりになりそうだ。



ただ、使っているOledbconnectionとかそのあたりのオブジェクトは別にGUIに依存しているわけではないので、CUI版にも応用できれば、Windows版locateコマンドが作れてうれしいかななんて思っていたりもする。でも、このへんにチャレンジするのはもう少しいじってみてから。



それから、インデックスサービスがCPUの能力を喰うためにインデックスサービスを止めているから、この手のソフトを利用できないって人は、インデックスサービスのタスクから、パフォーマンスの調整をして、少しインデックスの作成に関するパフォーマンスを落としてみればいいと思う。

まぁ、パフォーマンスを落とせば、この手のソフトの動きも悪くなるわけだけれども、検索結果として導出されるものは、さほど気にならない程度の変化だと思う。

逆に、CPUのパワーを喰わなくなるので、この手のソフトとの共存を考えている人にはいいかもしれない。



それにしても、C++でやっていたのが実にバカらしい。

(なんて思いつつも、少し悔しかったりするんだよね。HelperAPIに関してはPlatformSDKにサンプルが付いているようだから、気力が持てばそっちの解析もやってみたいな。)

携帯電話をD704iに変えました。

これまで、N504iというヒジョーに古い機種を長いこと利用していましたが、このたびようやくD704iという機種に携帯電話をチェンジしました。
ということで、せっかくなのでいくつか使用感を。
見やすいように、良かったところを赤文字、不満を緑文字で書きました。
まぁ、これから携帯電話を購入する人は、こんな型落ち機種の使い心地なんて知っても仕方ないんでしょうけど(笑)

・機種変更にいたる背景
まずは機種変更にいたる背景など。ここを書いておかないと、何を求めていて、何を中心に使い心地を判断したのか分からないでしょうから。
私は、携帯電話をメール→通話→その他(ゲームやネット閲覧など)という頻度で活用しています。
ですが最近
 i.電池の持ちが悪くなった
 ii.部屋の中で通話が良く切れる
 iii.画面に表示されるアンテナの本数が、2本では発信に失敗しやすい

という症状に見舞われるようになりました。
i.は、リチウムイオンバッテリーの寿命であることはすぐに分かりますので、i.の症状だけならば携帯電話を変えるまでには至らなかったと思うのですが、ii.およびiii.が深刻な問題で、多くの場面で困ることが増えてきたので、今回機種を変更するに至りました。

ですから、新しい携帯電話に求めたことは
 1.メールができること
 2.通話がきちんと出来ること
 3.カメラが付いていること

という3条件でした。逆に言えば、これ以上の余計な機能はいらないと考えたのです。

さて、これまで使っていたN504iという機種には、カメラが付いていませんでした。
ですから、ちょっと考えると3.の条件は要らないように思えます。
しかし、様々な場合にちょっとした資料を写真で残しておきたい時などに不便で、3.の条件をつけることにしました。

・機種を選択する
機種の選択は後々後悔しない様に、慎重に選択する人が多いと思いますが、私は上記の3条件を店員に伝えて、とにかく安いのを出してくれと頼みました。
するとLG電子製のSimpureというシリーズに属する携帯電話か、今回購入したD704iかの二択とされたので、連続待ち受け時間の長さから三菱のD704iをチョイスしました。
ワンセグやミュージックプレイヤーなどの余計な機能こそ付いていましたが、一応条件は満たしているので、高くつくなと思いながらも機種変更に踏み切りました。

・良い点
まず使っていて良いと感じたのは、M+フォントに似た識字しやすいフォントが、メールなどの文字として採用されている点です。
くわえて画面の明るさもよく、非常に見やすいスクリーンを提供してくれています。
また、着信したメールに対して、本体をスライドさせて開くことですぐさま返信を書けるモードになることも良い機能だと思いました。
この返信の際には定型文も表示してくれるので、さっとしたやり取りが出来てありがたいです。
私は通話に関して、通話料金を気にするほうなので、細かいところですが累積通話料金の自動リセット機能はありがたいものだと感じました。

これに付随して、これまでN504iでは4桁だったセキュリティコードが8桁になったこと、PIN1/PIN2という、暗証番号以外に重要な場所に適用できるセキュリティコードが別途設定できるようになったこが、良い点であると思います。

日本語入力周りに関して言うと、言葉→絵文字の変換や、充実した顔文字辞書が便利だと感じました。
また、ステーショナリーとして英和・和英・国語の3辞書が標準で入っていることも便利な点です。

ワンセグ視聴時や他の作業を携帯電話でしている時に、テロップを画面上にながして、誰から、どのようなタイトルでメールが来たかを知らせてくれる機能も、個人的には重宝しています。
特にタイトルが表示されるので、緊急に返信しなければならないものか、あるいは資料を整えてから返信知るべきものか、または放置しても大丈夫なものかの判断がすぐにできて良いです。

通話に関して言えば、とにかくキレづらくなったのはうれしい点です。
これはmova→FOMAという電波方式の違いが最も大きなものだと思うのですが、通話品質低下アラームがなった後も、すぐに切れたり相手に音声が伝わらなくなってしまうということがなく、きちんと通話→終話できたことが、なによりうれしい部分でした。

・不満
まず、カメラのレンズ部分の保護機能がなにも無いことが不満です。
外にむき出しになっているにも係わらず、AppleのiPhoneのように、カギなどと一緒にポケットに入れても大丈夫な強化部品が使われているわけでもなさそうですし、すぐに傷がつきそうな印象です。

次に不満なのがキーの押しにくさです。閉じた状態の画面下部に、6つ以上のキーが配置されているのに、画面が大きく取られているため、ボタン一つ一つのサイズが小さくなってしまい、大人の男性の手では押しにくい印象を受けました。
また、本体をオープンすることであらわになる数字キーに関しても同様で、キーが小さく、押しにくい印象があります。
特に1,2,3ボタンに関しては開いた上面部分との境界に近く、親指で押すのは慣れが必要だと思いました。
くわえて5ボタンにある中央をしめす突起した部分もそれほど隆起しておらず、さっと中央部分を探すことが困難であることも、メールや番号の入力速度が落ちるので残念なところです。
そのほか、キー同士の感覚が近く、一緒に他のキーも押してしまって入力がめちゃめちゃになるという場面にも多数遭遇しています。
細かいところではキー配列がこれまでと少々異なっていることも不満ですが、それはおそらくこの機種に特有なことではないと思うので、一言だけにしておきます。

日本語入力周りで不満が出たのが、変換途中に文節を区切るのが面倒であるということです。
また、変換中の文字と入力済みの文字が別画面に表示されるため、画面が3分割されてしまうのも残念です。

また、メニューの項目が多く、目的の機能にすばやくたどり着くのに苦労するのも不満です。
カスタムメニューを作ればよいのでしょうが、その作業が面倒です。
せっかく閉じた状態でスピードメニューボタンを利用できるのですから、この部分にメニューの使用頻度に応じて、ワンボタンに割り当てられていない、よく使うメニューを表示するような機能を搭載して欲しかったと思います。

カメラに関しては、それほどスペックを要求していないのであまり不満を書くのは良くないと思いますが、撮影した時に白とその周辺が飛んでしまうのは残念だと思います。

そのほか、画面に表示されているアンテナの本数が少ないときに、発信に失敗するのはあまり改善されていないようなのでそこが不満ですが、少なくとも2本ならばこれまでよりも発信に成功する確率が増えました。

・そのほか
まだあまり使っていないワンセグ、ICカード機能、iアプリ、ネット、iチャンネルといったものに関してはあまり言及できませんが、最新のニュースや占いをテロップ表示するだけのiチャンネルに関しては、実用性の低い機能であると思います。
それほど携帯電話を見つめる必要のある人が、どれほどいるのでしょうか?
個人的な感想ですが、電話としての立場をわきまえて欲しいと思ってしまいました。

・今後発売される機種への期待
今後発売される機種に関しては
 ・ネットワーク経由で必要な機能を追加できるモジュール機能
 ・キーストロークや日本語変換予測機能の改善
 ・メールの簡単返信に最初から表示されたり、メールの定型文として示されるテンプレートのセンス向上
 ・電波の弱いところでも、通話品質を保った通話。あるいは発信。
 ・高いビルの合間でも通話できる電波を副電波として活用するような、デュアル電波方式の採用

といったことを望みます。
最初のものに関しては、今回余計な機能が付きすぎているため、目的の機能にすばやくアクセスできないのが不満でしたから、根本的に標準搭載の機能を減らし、オプションで好きな時に好きな機能を追加・削除できるようにしてくれたら便利だと思うからです。

・まとめ
と、こんな感じで新しい携帯電話と付き合い始めましたが、点数としては及第点だと思います。
最後になりましたが、携帯電話業界全体への不満として
 ・端末代金が高いこと
 ・古い世代(3~4世代前)の携帯電話を店頭で販売してないこと

を挙げておきたいと思います。

端末代金に関しては、端末によらずすべての携帯電話会社で使えるような端末であれば文句はありませんが、自社の電波しか使えず、自社の認証カードしか認証できない端末なのにあの価格を取るのはぼったくりだと思います。

古い世代の携帯電話に関しては、売れないというのもあるのでしょうけれど、私のように低機能でかまわないから使える携帯をくれ!とか、ライフラインの一部として使うんだから、枯れた製品の方が安心できる!というユーザもいることを忘れないで欲しいという重いからです。

さぁ、この携帯とあと何年付き合うことやら…。


2.19.2008

C#ってすごいね。

VC++からIndex Serviceにアクセスしようと悪戦苦闘すること早数日。
ふとしたことからC#で接続を試みたところ、5分で成功。

なんだこの手軽さは!!!

ということで、素直にC#で書くことにしましたよ。
でも、接続→単純なクエリで取り出しはすぐに出来たけれど、発展したものを作ると面倒なのかな?とも思うんだよね。

2.17.2008

インデックスサービスプログラムに関するメモ。

MSDN ライブラリ(本家)やら手元のサンプルやらをいろいろ読んでいて、インデックスサービスには様々な利用法があることがわかった。以下、そのメモ。

・C++から接続するにはOLE DBを介する
・ADOからも接続をかけられるので、.NET系言語から接続をかけるならこちらを使う
・VBScriptやJScriptなどのWSH系スクリプト言語からも、手軽に接続がかけられる

これだけ便利そうで、私が使った限り非常に高速な応答を示してくれるインデックスサービスが、それほど使われていないように見える背景には

・資料が少ない。特に日本語リソースが少なく感じる
・インデックスサービスが常駐していると、これでもかとCPUパワーを喰うのでうざい

という2点があるように思える。この辺りが改善されると、もっと便利なソフトがたくさん出てくると思うんだけどなぁ。

ちなみに私は、とりあえずコンソールで動くものを、サンプルを参考にしながら実装してます。
ただ、OLE DBがやたらめんどくさいから、C#+ADOとかから接続したほうが楽だっただろうかとちょっとばかし後悔してます。

ソフトウェアって、アップデートしだすと気になるよね。

Maximaを5.1.4にアップデート
と言っても、そんなに頻繁に・・・いや、使ってるな。
こういう道具を使って問題を解決しようとするあたり、計算工学屋だなぁと。
(そういえば、先日計算物理工学なのか、計算工学なのかで議論になったけど、結局おもしろいならどっちでもいいやって、私は思ってました。)

機能追加や仕様変更に関しては、
* Maxima strings are now Lisp strings (not Lisp symbols)


ぐらいが気になるだけで、あとはうれしいバグフィックスがもりだくさんのリリースのようで一安心。
でも、こうしてアップデートするのは自宅のマイPCだけなんだろうなw
そういう「動いているものに触るな」根性が出てしまうあたり、やっぱり工学屋なのかもね。

2.16.2008

Androidにお別れ。

Googleが旗振りを務めて推進している次世代携帯電話ソフトウェアプラットフォーム(こう書くとなんかすごそうだよね。)Androidの新バージョンが公開された。

で、さっそくアップデート。

Eclipseに導入したADT(Android Developer Plugin?)も、新しいバージョンになっていたので、そっちもアップデート。



なんだか色々新しくなったらしく、以前に書いたAndroidソースがビルドできないような問題にもブチ当たったので、もう一度手順を追ってHelloWorldからスタートしてみることに。

(というか、その程度のアプリケーションしか書いてないんだけどw)



実行結果が下図なんだけど、ここで気づいたことがひとつ。






遅い。

ものすごく遅い。いや、重たいというべきか。

以前のバージョンも重たかったけど、今回のはそれの比じゃない。



どの程度かといえば、ビルド→エミュレータの起動は、もはや私のPCのスペックでは耐え切れないらしく、Eclipseの窓には通信がタイムアウトした旨のエラーがむなしく表示されるといった程度だ。

こういう症状は以前のバージョンでも何度か遭遇していたのだが、今回はほぼ毎回実行できなかった旨のエラーが表示されてしまう。



そんなわけで以前からの対処法としてよく知られている、エミュレータを事前に立ち上げておいてからビルドするという操作をするわけだけれども、たかだか実行ダイアログを開いてビルドさせたいだけなのに、フリーズしたかと思うほどの重たさが襲い掛かる。



こりゃイカン。開発する時、私が何より大敵だと思っている「ストレス」がそこに発生しているからだ。

こんな環境じゃ、とてもじゃないけど楽しいソフトウェアの開発とか、ユーザに喜んでもらえるソフトウェアの開発なんてできたもんじゃない。



ということで、Hello Worldを動かして以後、Androidにはサヨナラすることになりましたとさ。

めでたしめでたし。

2.12.2008

SICP読んでみる。

休みに入った学生というのは、こたつの中で成績発表までガクブルしながらすごすしかないわけで。
やっぱり時間が空くと、ついついゲームとかそんなものに手が伸びてしまうわけです。
(最近のお気に入りは ょすみん。です。時間を忘れて遊んでしまうので、クリックする時はご注意を。
そして、全く、実に、本当にどうでもいいことなんですが、niftyに設置してあるょすみん。は、自分がtext/htmlだと言って来るんです。
まぁ、ソースの中ほどで頑張ってるembedタグ周辺が問題なんでしょうけど。少なくとも、我が家のFirefoxではプレイすることが出来ません。天下のniftyがここまでとはねぇ・・・)

おいとき。

そんなふうに時間をつぶしても仕方が無いので、図書館からStructure and Interpetation of Computer Programming.(スペルあってる?)通称SICPの原著と訳書を借りてきました。
原著を借りてきたのは、訳書の訳が酷いなんて話を聞いたからですが、今のところ、カタカナ語でよさそうな用語をそのまま用いず、律儀に訳してたり、平方根はこう求まる!的な部分の訳が不自然と感じる意外はそれなりに読めてます。
もっと読むとあらが目立ってくるのかなぁ。とも思いますが、思っていたほど酷くなくて一安心です。

そんなわけで、読書日記をつけてみることにしました。
といっても、読書記録は日々ログ(要するにローカルな日記)に保存してあるので、こちらはその焼き直しということになるのですが。

で、現在は演習問題1.7を解いたところ。私の解はこちら。

;; SICP 問題1.7
;; guessと直前のguessの差を使って計算するプログラム
(define (sqrt-iter pre-guess guess x)
(if (good-enough? pre-guess guess)
guess
(sqrt-iter guess (improve guess x)
x)))

(define (improve guess x)
(average guess (/ x guess)))

(define (average x y)
(/ (+ x y) 2))

; 直前の予測値(pre-guess)と、今の予測値(guess)との差が十分に小さければ#t
(define (good-enough? pre-guess guess)
(< (abs (- pre-guess guess)) 0.001))

(define (abs v)
(if (< v 0)
(- v)
v))

(define (my-sqrt x)
(sqrt-iter 0.0 1.0 x))

はてなだと勝手に色付けとかしてくれるオプションが存在するらしいけど、bloggerじゃ無いだろうなw
スクリプトでも書いて作ったら便利かなぁ?でも、書くに至らないっていうのは、自分でそれほど必要としてないだろうからだな。

1.6の解答がいまいちよく分からないのだけれども、
「スペシャルフォームなifじゃないから、その引数は渡される時点で評価されるために、思ったとおりに実行されない」
でいいのかなぁ?どなたか詳しい解答をご存知でしたら教えてプリーズです。

さて、この読書、休み終了までに終わるか否か。
一応SICPタグを付けて日々の日記と分けていくつもりですので、もし皆さんの中でSICPにチャレンジしている方がいらっしゃれば、いっしょに頑張りましょう。

2.10.2008

国の無駄遣い。

海自が先の情報漏えいに関連して、Sunのシンクライアントを3万台導入するという話。
これとは別に、防衛庁が私有PCいっそうを図る名目で以前に導入させたはずのPCが、海自+空自で1万台だそうだから、海自に導入されたのはその半分として、5,000台ぐらいあるだろう。
今回のニュースでは海自のPCをすべて入れ替えるっていうことだから、一台6万円程度と見ても5,000x60,000=30,000,000円ものお金が無駄遣いだったんじゃないだろうかと思えるような使い方をされたわけだ。(まぁ、2010年になったら、2005年導入の製品なんて使い物にならないって言われればそれまでなんだけども。)

んで、今回導入するSunのシンクライアントシステム(おそらくRayのことだろうと思うけど)は、端末だけで3万台だそうだから、Rayのだいたいの価格(Ray 170で11万、2Nで16万だから、13万ぐらい?)からみると、クライアントだけで130,000x30,000=3,900,000,000円の導入費用がかかるわけだ。
そして、私の記憶が正しければ、SunのRayは
・クライアント
・クライアントの管理や、ユーザ管理をするサーバ
・環境を提供するサーバ
の3段構成だったと思うから、どんなに少なく見積もっても4,000,000,000円より多い導入費用がかかるなぁなんて計算できる。(長い目で見た管理費は、いくらか安くなるんだろうケド。)

で、重要なのが、これだけ金をかけて、本当に情報漏洩がなくなるのか?っていうトコロ。
私はそうは思わない。

何より大事なのは、漏洩させない体質というんだろうか?
そういう組織作りや、個々の人間への教育だと思うんだよね。
こんなこといくらやって、国民の税金をガンガン使ったって、使う人の頭がパーなまんまじゃ、結局無駄遣いや無意味な対策とされてしまうだろうし。
そんなわけで、目に見える情報漏洩対策ができてから、こういうことを言って欲しいものだと感じたのでした。

2.09.2008

2.08.2008

nano techのチケットとどいた!

携帯電話にカメラがついていないので,チケット画像をアップできないのが残念(´・ω・`)ショボーン.
はやく携帯買い換えよう・・・.

とりあえず言いたいことは,ナノバイオExpoとnano tech2008に行きたくて両方申し込みをしたんだけれども,

一枚で両方いけるなら,最初からでっかくどこかにそう書いて置いてください!

ってこと.あと,パンフをみるだけで一週間後が楽しみでならないってこと.
ナノバイオのチケット2枚,nano techのチケット1枚という構成で送られてきたのが気になるけれども,2枚あるうちの一枚のナノバイオのチケットで入場→他のは記念にとっておくいっていう使い方か,誰かにあげるって使い方か・・・.

そんな無駄なことに頭を使えるくらい,余裕のある今日この頃です.

2.06.2008

早くも難航・・・

インデックスサービスに関して調べ始めたんですが,どうにもこうにも,英語の技術文献ばかりが出てきます:
日本ではマイナーなんでしょうかね・・・。

2.04.2008

Index Serviceって、実はすごい気がする。

最近,coLinux上でもWindows上でも,ファイルを検索して探しだす機会が多くなった.
というのも,(プログラムのソースを含む)テキストドキュメントが山のように増えてしまい,そこから目的のものを探し出すのに最適な方法が検索であったからなのだ.

で,Linuxではlocateコマンドを使って手軽かつ高速にファイル検索が行えるのだが,Windowsでは[スタート]→[検索]などとして検索するためのキーワードを窓に打ち込んだ後,とっても遅い検索時間を,コーヒーの一杯でも飲みながらまったり待たなくてはいけないという,とても耐え難い苦痛を味わわなければならないのだ.

以前から私は,これはどうもおかしなことじゃないかと思っていた.
だって,私のコンピューターではIndex Serviceと名乗る,自称「ファイル検索を高速にする」サービスが常時稼動し,CPUがヒマそうにしていれば,やれインデックスを作れとはやしたてているのに,こんなに検索が遅いわけが無いと思ったのである.

こうして困った時に頼りになるのもまた検索.
そんなわけで,Index Serviceに関して色々調べてみた.
すると,やはり私と同じ不満を持っている人がたくさん居るようだ.
そのうち多くの人は,CPUを喰うという理由でIndex Serviceを停止し,GoogleDesktopに乗り換えたという.

けれども私はGoogleDesktopというのが嫌いだ.
いかにもハイスペックなマシンの余剰エネルギーをバリバリ使って検索しようなんて,贅沢企業の思惑が見え隠れする気がするからだ.
貧乏性の私としては,なんとしてもIndex Service――つまり,OS標準の検索機構――にがんばってもらいたいと思うのだ.

そもそも,これまで多くのCPU時間を食いつぶしたコイツに代わって,さっさとGoogleDesktopを導入するようじゃ負けた気がする.
そんなのは絶対に許されない.


と,前置きが長くなったが,その後の調べで管理ツールからたどる,各インデックスの持つ,カタログのクエリというのによる検索が,ものすごく高速であることが判明した.

これだ.これこそ,Index Serviceが私の非力マシンの尻をバシバシ叩きながら作成したインデックスの産物であろう!その検索スピードは,これまで使っていた検索などとは天と地ほどの差.まさに月とすっぽんとも言うべきものであった.

そんなわけでとても手堅い検索手段を見つけたのだが,いかんせんこの強力な検索手段,検索を行うまでに至る道のりが長い.管理ツール→インデックスサービス→該当インデックス→カタログのクエリとたどらないといけないのだ.
良く使うのだから,たとえばタスクトレイにアイコンを常駐させて,クリックイッパツで検索窓が出,出力結果をまとめてくれる――まさにGoogleDesktopが私のコンピューターでやろうとした仕事――ぐらいのことをしてくれても良いんじゃないだろうかと思えてきた.

で,インデックスサービスを自作プログラムから活用できないかと探して見ると,どうやらできるらしい.

新しい研究課題が見つかった.
インデックスサービスを,もう少し追いかけてみたいと思う.

2.01.2008

一晩たってようやく解決.

昨日書いたcoLinuxのNICが云々っていう話.
いろいろ調べた結果,ここにズバリその問題の解法があった.
要するに,
$ sudo nano /etc/udev/rules.d/z25_persistent-net.rules

とかしてルールファイルを開いて,当該項目を編集すればいいだけ.
原因はおそらく,coLinuxの.cfgファイルでMACアドレスを指定するような仕様になったおかげで,MACを変更するたびに新しいNICがささったと思われてたから.
というわけで,我が家ではeth0にeth4のMACを振って,eth0以外を削除→/etc/networks/interfacesのeth4をeth0に,それから.cfgファイルもeth0に直すという方法で解決.
ひとつのNICしか搭載していないマシンなのに,そのひとつのNICのMACアドレスを様々に変更できることから起こる弊害なんだろうと予想.

coLinux-devel-20080120以降でまたつまづくかもしれないので,メモとして残しておく.