« 2010年02月 | メイン | 2010年04月 »
2010年03月31日
プロジェクタの最小投影距離
ふと思い立って、手持ちのプロジェクタで、どこまで小さい映像を投影できるか、を調べてみた。
BenQのLED光源のSVGA解像度のやつで、だいたい横が18cmくらいまで、のようだ。横が800画素なので、画素ピッチは0.22mm程度、ということになる。
普通の液晶モニタとあまり変わらんか・・・残念。
もっと小さく投影できるプロジェクタはないのかな。
例えばXGA解像度で横を3cmぐらいに投影できると、画素ピッチは0.03mm(30um)ということになる。10画素ならべても普通の液晶モニタの画素ぐらい、ということになる。これぐらいの、ないかなあ。
2010年03月29日
つまらんことに腹をたてること
どうも、本業のほうが比較的ヒマなときほど、
些細なことが気になって、
つまらんことに腹をたててしまう。
まわりに迷惑をかけているなあ、と思いつつ、
ふと冷静になって、自己嫌悪になる、というのも、損な性格だなあ、とも思う。
と、考えること自体、自意識過剰なのかもしれないけど。
つまらんことに腹をたてることは、やめようぜ、自分。
ヒビマイシン。
人望というもの
無茶ぶりをしておいて、やりとりの行き違いがあって、
（あまりたいしたことではないとはいえ）問題があって、
冷静に原因をたどってみれば、双方に思い過ごし・思い込みがあったわけで、
別に責めるつもりはないんだけど、もう少し配慮してほしいだけなのに、
そして、手続きが間違っていたあなたが悪い、私の手続きに落ち度はない、という一方的な言い草。
こうして人望は失われる。
私は、この人には、一生ついていかない。
そう、心に誓った。
2010年03月26日
γGTPとか
いつも健康診断でひっかかるγGTPについて、紹介状を書いてもらって肝臓が専門の先生のところへ行ってきた。
γGTPが高い原因は、アルコール、胆のう関係の障害、原発性ナントカ肝炎、マクロエンザイム、あたりが考えられるが、γGTPだけ高く、GOTやGPTが平常値、というのは、アルコールが原因とは考えにくい、らしい。
胆のう関係の障害か原発性ナントカ肝炎は超音波エコーで調べられる（検査前5時間ぐらい前から絶食しないといけないので検査は次回）。原発性ナントカ肝炎か胆のう障害のどっちかは、血液中のミトコンドリアなんちゃら、というマーカーの有無でわかるらしいので、採血してもらう。
次回、血液検査の結果と超音波エコーで、胆のう障害も原発性ナントカ肝炎も大丈夫、となると、マクロエンザイム、ということになるらしい。
これは、γGTPについているオマケのタンパクが、人によっては大きいやつのこともあるそうで、1個あたりのγGTPの分子量が大きいので、見かけ上、γGTPの値が高いように見える、ということらしい。つまり平常。
ただしこれは生まれつきの体質みたいなものなので、過去の健康診断で、1回でも、γGTP値が平常なことがあったのであれば、これが原因ではない、らしい。自分の場合は、学生のときの健康診断ではγGTPがひっかかった記憶はないが、たぶんそもそもγGTPを検査していなかったんじゃないか、とのこと。少なくともγGTPが基準値内にあった、という記憶はないが、γGTPを検査していなかっただけなのかもしれないし、これは今になってはわからない。
というわけで、次回の検査・超音波エコーの結果次第。
桃鉄
桃鉄を、小学校の社会の授業教材として使うのは、意外といい方法なんじゃないだろうか。
日本の地理・地名を覚えられるし、各地方の特徴も（やや強調されているとはいえ）覚えられるし、ボンビーのなすりつけあい、などの駆け引きの経験にもなる。
2010年03月24日
就職活動という行為
自分自身は、ちゃんとやったことがないので、えらそうなことを言うのは、ややはばかられるが、
自分のやってきたこと、やろうとしていること、適性、家族のこと、などなど、自分の半生をふりかえり、あまり先までではないにしても人生の計画をたてることは、有意義のことのように思える。
だから、皆、あれだけ一生懸命にやるわけだ。いいことのように思う。
でも一方で、学生どうしで（なんとなくコソコソ）やっているような雰囲気もないことはなくて、そこが寂しいという気持ちもあるわけだけど。
曲がりなりにも、多少長く生きてきているわけだから、いろいろ相談してくれればいいのに。
雑多なマニュアルの整理方法
雑多なマニュアルを、いままでは、ある程度機器の種類をわけて保存していたんだけど、だいたいそのうち区分があいまいな機器が出てきて、どっちに入れようか迷って、実際に必要になったときにどこにあるかわからなくなる、ということは、よくある話。
そこで、割り切って、一切区分せずに1つの箱に入れておき、必要になったときには、そこから目的のものを探す、という整理方法に切り替えてみた。
どうせ必要になる頻度はかなり少ないわけだし、分類して保存する手間より、必要なときに探す手間のほうが、期待値としては小さいような気がする。
そのほかに、例えばScanした会議資料PDFファイルなども、同じように整理をするようにしようかと思う。
GmailのメールのArchiveという機能も、これに似たような話で、確かにメールの整理方法としては、この方法がすごく便利な気がしてきた。
マニュアルの検索にもGmailみたいな検索があればいいんだけど、まあそこまでは。
WILLCOM03のGoogleSyncのメール同期
どうも、ときどき（再現性なし）、エラーが発生して同期ができなくなることがあって、「エラーコード」を見てもよく原因がわからないのだけど、以前はGoogleSyncのアカウントを削除して再度設定しなおしたりしていたが、どうも、だいたいメールの同期でエラーが発生することが多いようで、手動でPocketOutlookのメールの同期をしたあとであれば、もとどおりGoogleSyncがぜんぶできるようになるようだ。
タクシー運賃のカード払い
昨日の帰りにタクシーを使おうと思ったら、財布の中の現金が乏しかったので、クレジットカード払いのできそうなマークのついているタクシーに乗ろうとして、念のためクレジットカードが使えるかを聞いてみたら、カード会社の発行するタクシーチケットじゃないとだめ、と言われた。
なんじゃそりゃ？と思って調べてみると、「カード払いOK」といってもいろいろあるらしい。
http://oshiete1.watch.impress.co.jp/qa5023584.html
ややこしいね。
2010年03月17日
身の丈にあった生活
ここ1ヶ月ぐらい、いろんな人にあって、いろんな話を聞いたりしたりして、
いろんな刺激をうけて、もっとがんばらないと、と、背伸びをしすぎていたのかもしれない。
なんだか疲れちゃったような気がする。
知らなくてもいいことを、知っていなければ、と強迫観念のように知ろうとしたり、
考えなくてもいいことを、考えなければ、と強迫観念のように考えたり、
やらなくてもいいことを、やらなければ、と強迫観念のようにやろうとしたり。
身の丈にあった生活に戻そう。
というわけで、微妙に身辺と気持ちの整理をしてみる。
ヒビマイシン。
2010年03月16日
計算機の危機？
最近どうも気になってしょうがないこと。
現在の計算機は、本当に決定論的システムなのか？
もちろん決定論的システムなのだが、そのプログラムの設計者が、すべての動作を把握することができているのか？という意味での疑問。
例えば電源が切れた状態で、トレイを開けるボタンを押すと、30秒後にトレイが空くDVDレコーダがある。起動に30秒かかっているわけだが、どう考えても、この時間は非常識なほどに長い。
組み込みシステムの開発者が、この30秒という時間をどう捉えているか（もっと早くしたいのか、しょうがないとあきらめているのか）は、現場の方々に聞いてみないとわからないが、その点は、いまは気にしない。
問題は、電源を入れてPowerOnResetがかかったあと、動作が始まるまでの、ステートマシンとしての計算機の動作が、どの程度まで理解されているのか？ということだ。
もちろん1命令ずつトレースしていけば、トレイが開くところにいきつくはずだが、現実的な組み込みシステムのプログラム開発においては、インスタンスの初期化など、かなり抽象度の高いブラックボックスが多く、プログラム開発者がその中身のすべてをトレースすることは、ほとんど不可能に近い。
組み込みシステムのSW/HW協調設計のCADでは、SW/HW分割の最適化を支援するために、分割時の実行サイクル数の見積もりを行う機能があるそうだが、それが実際の実効サイクル数とどの程度あうか、がCADとしての技術開発のキモらしい。
いや待て。「どの程度あうか」は、果たして決定論的なシステムである計算機においてありうる（あるいは許される）ことなのか？
もちろん1命令ずつ毎回トレースすれば、厳密に実行サイクル数を見積もることができるはずだが、それでは時間がかかりすぎるので、ある程度の近似や予測を混ぜて、実行サイクル数の見積もりの精度をあげる、という努力なので、やはり決定論的なシステムであることには変わりないはず。
しかし、これがツールになってしまうと、それ自体がブラックボックスになってしまい、それを使うシステム開発者は、厳密な実行サイクル数を求める、ということは、ほとんど行わなくなるだろう。
そして時代が流れ、そのツールの中身のことを理解している人がいなくなってしまうと、計算機の実行サイクル数は「およそこれぐらい」というようにみなされ、それを前提に組み込みシステムが構築されていく。はたして、この組み込みシステムは、決定論的なシステムと呼べるのか？
例えば、原子をくみあわせてタンパク質やDNAをつくることは、現在でもできる。しかし、それらを組み合わせて生きた細胞を作ることはできていない。つまり原子から多細胞生物までのつながりにおいて、タンパク質と細胞の間に、越えられないギャップが、少なくとも現在はある。
一方、計算機は、本来は、原子レベルの電子の挙動、半導体・トランジスタ、論理ゲート、ステートマシン、プロセッサ、計算機システム、マシン語、高級言語、OS、コンピュータネットワーク、というつながりは、すべてつながっているはず。
しかし、少なくともすべてを完全に理解している人は、現在の世の中にいるのだろうか？
自分が小学生のころは、トランジスタからマシン語（や、簡単な高級言語）までは、自分の中でつながっていて、相互に移動ができて、遊べた。しかし現在ほど計算機が複雑化すると、トランジスタを組み合わせてWindowsマシンを作ることは非現実的だし、そもそもそんな幅広い分野にまたがる興味を持つこと自体が非常に困難かもしれない。
そして、計算機システムは、階層構造になり、いわゆるハード屋とソフト屋の分業となってきているわけだが、その両者のお互いが、相手のことをブラックボックスとみなさざるを得ない。それほどまでに計算機システムは複雑化している。
うまくシステムが動いているうちはいいが、トラブルがあった場合はどうするか？両者が自分の守備範囲の中で原因をつきとめられないときには、ソフト屋はハードの問題だといい、ハード屋はソフトの問題だという。お互い相手はブラックボックスなのだから、入っていって限界をつきとめようにも、どうしても限度がある。
現在ならば、まだトランジスタから高級言語までつながっている経験をもつ人がいるから、まだなんとかソフトとハードをまたがって原因究明ができるのだろうが、そういう人がいなくなってしまったら、どうなるか？考えるだけで恐ろしい。
非常に高度に発達した計算機システムと、それにもとづく社会において、計算機システムが人類に反乱を起こす、というSF的な世界というのは、必ずしも人工知能のような上のレベルからの反乱だけではなく、下のレベルからくるのもあるのではないだろうか。例えば微細化しすぎて、電流がとまらなくなるMOSトランジスタのように。
・・・さて、このような問題をどうやって解決していくか。
作品集
いまさらながら、気付けばずいぶんたまっていたので、電子工作というかマイコンねたを整理してみた。
2010年03月14日
いつでも どこでも 高度な医療を
縁あって、興味深いお話を聞かせていただく。
医療は、いつでも、どこでも、高度なものを、と求められるが、
それは無茶な話だ、というものの1つの見方。
高度な手術などの高度医療は、ある程度の数をこなさないと
医師の腕がにぶってしまう。
ところが患者の数は限られている。特に症例の少ない病気だと、なおさら。
つまり、人口の少ないところに高度な医療を行う病院を作っても、患者が少ないので、医師が多ければいいわけではない。
ただ単に医師が足りないわけではなく、患者数との兼ね合いもあるわけだ。
したがって、医療に求められる「いつでも」「どこでも」「高度なものを」をすべて満たすのは不可能で、どれか1つをあきらめるとすれば、「どこでも」ではないか、という話。
「いつでも」は、高速道路などである程度カバーできる。
「高度なものを」は、選択的に高度な医療設備・スタッフを整えればよい。
「どこでも」を、高度な医療機関を人口とは無関係にあらゆるところに、というのは無茶なので、医療機関を整備する代わりに、その費用を、そのような高度な医療を求める人に対して、それに応える医療を提供する場所への渡航費や滞在費などにあてるべき、という話。
たしかに、一理ある話だと思うし、単に「医師不足」と報じられている／政策として議論さてている話とは異なる視点だと思う。
2010年03月13日
研究室の留守番電話
よく事務の方や学外の方から、研究室の電話に電話しても留守なので、留守電を入れておいたので聞いてください、ということをメールで連絡をいただくことが、ときどきある。
どう考えても物事の順序が逆のようなきがするんだけど、きっと、メールじゃなくて電話してくれ、という反応の人もいるんだろうなあ。
そこで留守番録音をオフにして、「電話に出られませんので用件はメールしてください」という応答メッセージを返すようにするのが、案外いい方法のような気がしてきた。
2010年03月04日
GoogleSyncの使用ポート
WindowsMobileではActiveSyncを使うので受信：990,999,5678,5721,26675/TCPと送信：5679/UDPをあけないといけhttp://support.microsoft.com/kb/915152/ja
（ここに書いてある118800/TCPは990/TCPの間違い）