残念なThinkpadのキーボードたち Check

この1ヶ月でx61のキーボードを2回も交換して、全部で残念な気持ちになった。大人になったものだ。

最初はFRU 42T3556(Chicony)。オークションで1400円だったので買ってみた。

• きっちり収まらない。上下の爪のサイズが大きめ
• 無理やり収めた結果ESCが浮く（いちを打鍵は可能)
• 「g」キーがキートップを揺らすだけで反応する
• キートップの右側(J,K,L)と左側(S,D,F)で間隔が違う。S,Dあたりは隣のキートップを擦ってる！

これは偽物をつかまされたような気持ちになった。しかし、問題ないキーについては、打鍵の時のストロークの重さとか、音とかは良い感じだった。

キーボードがダメだと、やる気がなくなる症候群が発動し、「安いからだめなのか、Chiconyだからダメなのか」と反省した結果、NMB製のすこし高いのを買ってみることにした。

次は$46のx60s用のFRU 39T7265(NMB)を買った。出だしは好調、ちゃんと収まるし、キートップのサイズや間隔はばっちり。しかし、不満な点は残った。

• ペラペラした打鍵感
• マウスのクリックが時々反応しない
• マウスの中ボタンが沈んだまま

中古ならでわの展開になった。3つ目は、古いやつからゴムをとりはずして修理した。打鍵感が悪いのは残念だなぁ。

x200系はどうなんだろう。今の時代の男の堅いノートパソコンの選択ってなんだろう。不安は募りばかりである。

Peano Arithmetic Check

昨日は、John McCarthyという人が亡くなったというニュースが流れた。 85歳だそうです。Lispという言語を作った偉大な人です。

フラリとyoutubeでSICPのMIT講義ビデオを見た。Schemeをつかって、計算機がどうやって計算するかを議論する講義だ。懐かしくてつい人に説明したくなった。SICPの最初の最初に出てくるやつだ。

足し算を定義したい。-1, +1というプリミティブが存在すると過程する。 ifとプリミティブを使って定義できる。

(define (+ x y)
  (if (= x 0)
      y
     (+ (-1 x ) (+1 y))))

たとえばこう計算される。簡単な方法で式を置き換えてみる。

(+ 3 4)
=> (+ 2 5)
=> (+ 1 6)
=> (+ 0 7)
=> 7

他の+の定義の方法もある。

(define (+ x y)
  (if (= x 0)
      (+1 (+ (-1 x) y))))

これは次のように置き換えられる。

(+ 3 4)
= > (+1 (+ 2 4))
= > (+1 (+1 (+ 1 4)))
= > (+1 (+1 (+1 (+ 0 4))))
= > (+1 (+1 (+1 4)))
= > (+1 (+1 5))
= > (+1 6)
= > 7

計算過程の形が異なる事がわかる。 ステップ数は時間に相当し、幅はメモリに相当する。 前者は時間=O(x), メモリ=O(1)となっていて、同じスペースで繰り返しを行う。 これを反復(Iteration)と呼ぶ。

後者は時間=O(x),メモリ=O(x)となっている。一旦ひろがって、後で計算する。 これを再帰(Recursion)と呼ぶ。

ね、楽しいでしょ？

[本] 原始的本性 Check

Alan Keyのインタビュー記事で「蛙は動くものしか見えない。 獲物をとるために動いている物に飛びついている。現代の人間も似たような感じだ。残念だ」といった内容に同意して、ずっと記憶にあった。

ブラックスワンを読んでて、もっと包括的な概念に出会った。 原始的な環境での「衝撃」の取扱いである。

物を作り、結果も目に見えていた原始的な環境では、衝撃こそが重要な事だった。動く物、大きい音、奇抜な色、高い温度など、五感を使って感じる事で、重要である事を把握していた。大きな音がすると身をすくめ、高温だと反射で手を動かすみたいに。

社会が発展して、人間は五感に比べってもっと高度な情報を取得するようになった。それに伴って、取得した情報が衝撃的である事が、重要という意味ではなく、多くの場合つまらない世界になった。Webの広告バナーは激しく動いて主張してくるし、TVや新聞もつまらない事を衝撃的に報道する。それ以外にも衝撃的なニュースだらけ。いったいどれくらい筋の良い情報があるだろう。

ところが、人間は原始的な環境で適用してきたルール(衝撃=大事)から未だに抜けられていないという話だ。論理や思考という他の動物の違う部分で、覆す事ができる本性なのに。

じゃどうするべきかと著者は主張しているかというと、長くなるので、またいつか。

SL水上 Check

週末に先輩に誘われて、始めてSLに乗車した。乗り物の機構や工夫はすごく気になるタイプだが、別に鉄っちゃんでは無い。

普通のJRの区間を走っているので、特別な路線を走っているわけではない。高崎駅のホームで乗り換える。乗り換え検索して知ったけど、高崎駅って遠いんだな。家から２時間ぐらいかかった。SLは「Steam Locomotiveの略なんだね」とか言いながら+2時間。水上という温泉街に到着する。SLが回転台で回るのを見れる。すこし感動した。観光客サービスなのか同じ方向に２回も回った。そして整備をちょっと見れる。急いで飯と温泉に入ると15:30には帰りのSLに乗る必要がある。　

ただね、SLといっても客車は古めの普通の客車で、乗っている分は別にSLでもなんでもない感じだった。「SLがひっぱっている」っという感覚もさほどない。時々、古い映画で聞いたことあるような汽笛が遠くで聞こえる。あ、窓開けておくと煙とすすが入ってくるのがっぽいかな。 迫力を求めるなら、車で追いかけて路線沿いでカメラ構えた方がいい。

SLの整備を少し観察してたら、一回走ると「回転しーの」「水抜きーの」「灰捨てーの」「石炭たしーの」「水足しーの」「蒸気ためーの」とメンテナンスコストすごいなと思った。鉄道員にとっても電車便利なわけだが、仕事なくなった人も相当いただろうな。

本当は、この日はC61が走るはずだったのだが故障らしくD51になっていた。 C61はJR東日本がどっかの公園に展示されていたSLを分解してレストアしたものだ。7月ぐらいにNHKが密着取材したのを見た。スチームの圧力を回転動力に変換するクランクやピストンの仕組みをCGで説明していてすごくおもしろい。ボイラー部分は一部の部品を作り直していて、熟練の職人が伝統的にも紙に設計図を書いてた。昔ながらのリベット打ちとかね。

工数管理の過大評価 Check

ちょっと友人と話てて思った事を書く。別にプロジェクト管理の専門家じゃないので、ツッコミどころ満載だと思う。

僕は前の会社とかでプロジェクト、案件の工数管理を経験したが、懐で疑問に思っていた事がある。

案件を見積もる時は、要件に合わせた物を作り上げるのに、どの期間にどんなタスクがあって、どんな人がどのくらい動けばいいか計画して見積りの工数を算出する。受注したら案件に関わる稼働は、その案件の見積り工数を消費してくいく。それを管理する事で「お金はそんなにもらってないのに、人と時間だけめちゃくちゃ使って赤字じゃん」ってリスクを回避したいわけだ。

やり方はSI業界では標準的で真っ当だと思う。ただ、ある状況下の会社では、問題になる事がある。ある程度規模が大きくなった後、自社の技術や製品に陰りが見えた時だ。

コアコンピタンスになる技術が空洞化すると、案件の幅が広がる傾向にあって、ベースが無いためにそれぞれハードルが高くなる。社内の知見を応用できなかったり、スクラッチからだったり、社外に委託する必要が出てくるからだ。さらに、経験あるエンジニアが抜けはじめると、正確な工数を算出できなくなり、過大な工数を算出してしまう。

こうなると、営業が「この案件、うちだと赤字になるのでやらない」とか、営業がやりたくても、エンジニアの方が「他プロジェクトで工数足らないから受けない」という話になるという問題が出てきて、余計案件を回せない会社になっていくんじゃないかという推測をしている。

それとは別に、工数管理によってエンジニアが挑戦する余裕がなくなるという問題があると思う。エンジニアが、目の前の案件のために作るのではなく 、次の次ぐらいまで使える汎化した技術基盤にしたいと思っていても工数に含めずらく、その場その場の物作りになり、コアコンピタンスの空洞化を促進すると思う。

そして、案件ないし、工数足らないから、早々にみんな帰宅することになる。良いのか悪いのか。

僕が思う解決策は、客に見せる工数と、社内の工数は別で管理するべきだという事.

[工作] CDプレイヤ Check

あっという間に夏になった。松本工場長の修理日記的なノリになってしまっているので、その線で書いてみよう。

先日、芭蕉さん所有物だったミニコンポのCDプレイヤ部分が壊れた。事情聴取してみると、なにやら中学生時代に親に買ってもらったもので、当時、時代を席巻したSONYの高級ミニコンポなのだという。青春時代の思い出は、このコンポと共にあったぐらいの勢いだそうだ。

現象としては、CDのスロットインの挙動が怪しいのと、入ってもちゃんとトラックを読めない感じ。 分解しながら、CDのスロットインの「からくり」を勉強した。CDをガイドに沿って取り込む動作、 モータへの装着のためのユニットの上下運動を全部１つのモーターとタイミングをとる歯車とカムを駆使している。

一通り掃除して組み立てたがCDをスロットインすらできなくなり、 4,5回分解と組み立てを繰り返しながら、スロットインの動作に 必要な爪やバネのからくりが理解できた。最終的には、 スロットインはばっちり動くのだが、CDを回すモータが回ってない 事に気づき諦めてしまった。粘りが足らんね。 CDは使えなくても、アンプにはなるのでPCの音出すアンプ専用機 として使う事にしよう。

メカニカルデザインを分解によって学び、一部を動作させながら虫とりをした。 ２０年前のエンジニアが作った「からくり」が今まで動作し、それを分解した人に、 その機構が理解できて感心させた。なんだか、恥ずかしいソフトウェアは残せないよな。

はじめてのユーザー車検 Check

車検時の費用が割高になる古い車を所有しているので、経験がてらユーザー車検をやってみた。結果として、車検とう儀式で最低限必要な金額と、手間がわかった。

車検というと、昔ながらの枠組みなので、昔ながらの方法で淡々とやられているのかと思っていた。ところが、なんとWeb予約が必要なのだ。免許更新 ぐらいのつもりで検査場に行ったら後悔する。というかもう一回来る事になる。いろいろと驚いた事を書いてみよう。

ユーザー車検の体験記や、親切な解説ページは無数に存在するので、本当にやりたいと思ったら調べたらだいたいの事はすぐわかった。分からないのは現地での空気感と、動き的なもの。

予備試験という技

まず、ユーザー車検で心配な人は、検査場近くの整備工場がやっている 予備試験を受けるという技がある。僕は横浜の陸運局近くのヨビケンという ところに行ってみた。検査場での検査項目を、そこで一通りできるらしい。 ちょっとだけ悪い所は、いい具合に直してくれる。次回車検時までの自賠責もここで購入した。

申請

そして、検査場へ行った。プロっぽい人が、どこへ向かうでもなくうろうろしている。ヘッドランプをガムテープで張った車が多い。なにかの技だろうか。離れたところに建物が２つあって、よくわからない。順番に説明はいっさいなかった。とりあえず、重量税の印紙とか申請書とか必要だとわかっていたので、ボロい建物(自動車税管理事務所)の適当に人がいるところに並んだら正解だった。次は、どうも陸運局のユーザー車検受付窓口。そして、 車に乗って検査場のレーンへ向かう。

検査レーン

5,6レーンあるって、数台車が並んでいる。最後尾あたりに点検の人が立っている。 こっちを向いている。なにもしなかったら、近寄ってきて「あんた、はじめて？」と 言われる。っで「簡単なレーン」というのに並び直すように言われた。車検で簡単とか 難しいとかあるのかと不思議だったが後でわかった。

そもそも正解のアクションは、車をレーンに並べて、点検の人がこっちを見たら ウィンカーを右、左、ライト点灯、ハイビーム、クラックション、ハザードを バシバシと点検員の目線に合わせて切り替えるのだ。プロたちはなんのコミュニケーション も無しにそれをやってる。 最後にその検査の人が、「排ガスの時はB押して」とアドバイスしてくれた。 だが、はじめてのユーザー車検な僕には何が何だかわからない。 いったいそれいつあるの？Bってどこに？まぁいいやとBとだけ覚えた。

その後のレーンには基本は人がいない。３、４フェーズ分かれていて、ぜんぶ機械式orユーザー手動式だった。僕の並んだ「簡単なレーン」は、ディスプレイと機械音声案内がついているレーンだった。次、何をすればいいか説明してくれるのだ。これが簡単の所以だ。 まぁそれでもかなりのテンポで指示をされる。胃のバリウム検査並だった。 ついでに、検査の人がアドバイスした「B」も気になる存在だった。

40kmでスピードを固定して、ライトを点けて、ハイビームもするという事を１つの フェーズで求められて、かなりテンパる。おかげで、フェーズの途中で機械に検査用紙を 入れて結果を打刻という重要な事を忘れてしまった。 排ガスの試験は、自分でプローブを排気口に入れて試験する。ちゃんとBボタンを押せた。 いつ終わりなのかよくわからないでたじろいでいたら、マイクで「はい、もういいよ」と 遠くからおっさんに言われた。

まとめ

なんだかんだで、試験をパスしたらしい。また陸運局の窓口へいくと、 新しい車検証とシールをくれた。

しかし、普通は一般のユーザーが来ないところだからかもしれないが、なんか よくわからない組織の間をいったりきたりしないといけないフローになっていて 驚いた。下のそれぞれが、何してるかなんて、よくわからないが、それぞれ 行かないとできない事務処理・手続きが存在するようだ。

• 運輸支局(国)
• 自動車税管理事務所(県)
• 自動車会議所(社団法人)
• 軽自動車検査協会(特別民間法人)

クラウンのデジタルメータを修理 Check

爺さんのクラウンを受け継いで、はじめての車検が近づいて来た。このままでは車検に通らない、まずい現象が発生している。スピードメータが表示されないのだ。

車は、1993年のトヨタ クラウン 3.0 ロイヤルサルーンGという景気の良いやつで、なんでも電動で動くようになっている。そして、おそらく当時流行っていたデジタルメータが搭載されているのだ。

現象を詳しく言うと「寒い季節になると走り出して30分ぐらいはメータが表示されない」というもの。最初は１０分ぐらいで復活していたが、 「ポン」と音がなって「充電系統異常」などと表示されて正常に戻るという現象を経て、今はほとんどだんまり状態になった。

とりあえず、車検も近いし、修理したらどれくらいお金かかるか調べてみようと、TOYOTAの販売店へ行ってみた。その結果、40万近い見積りになった。メータ交換は20万ぐらいだそうだ。　挙句の果てに「車検代を頭金に月賦で新車買えますよ」みたいな話をしてくる。

Webで現象を調べると、何人か同じ系統のクラウン(14系というらしい)で修理している人がいた。内部のコンデンサを交換するらしい。交換部品を調べると、この不具合の修理用にYahooオークションで交換部品を売っていた。1000円。コンデンサにしては高すぎるが便利なのでこれで手を打つ。(16v 47uFx6個, 16v 10uFx3個あれば良い) (「メーター不点灯修理　クラウン」こんなキーワードでみつかる。)

部品が送られてきたら、基盤のどこの部品かを示した画像もついていた。クラウンマジェスタの例なんだけど、ほぼ同じだった。部品が１つ違ったぐらい。 最初は簡単だなぁと思ったが、車からメータユニットを外して、ユニットをバラして、裸の基板状態にするまで、なかなか苦労した。

表面実装の部品は部品面側の足を基板表面に半田づけする。部品が加熱されやすいのだが、 壊れちゃうとデジタルメータはユニットごとゴミだ。 慎重になった僕は、精密部品用の22Wの半田コテで部品を外すことにした。 下手がこういう事を考えるのは無駄だった。半田を溶かすのに時間がかかって、 余計に加熱しちゃうし、汚くなった。結局、40Wの普通の半田ごてに持ち替えた。 ちゃっちゃとハズせるようになった。

コンデンサの足に先に薄く半田をつけて、ペーストをつけておくと、短時間で接続面に 固定できる。そもそも無駄な苦労するので、表面実装のコンデンサを買わなくても 良かったなぁと後悔した。

合計9個のコンデンサを交換した。全部組み直して、車へ接続。一発でちゃんと動いた。

参考

<URL:http://www.geocities.jp/toshiki_majesta1/metter3.html>

Thinkpad x61 Check

Linuxなノートパソコンを学生時代はもっていたが、今は初代MBPのMacOS上に動く1VMに成り下がっていた。DesktopはLinuxだけど。

みんなMBP,MBAに移行していく昨今、中古のThinkpad x61を購入した。 オークションで3万1000円。少し傷あるけど、全然平気だ。 どうもLenovoでワイドなx200シリーズは、液晶の縁の無駄なスペース とか、不要なカメラとかが気にくわない。キーボードはどうなんだか知らないが。

思い出したら、これが社会人になって購入したパソコンの１号機だった。 去年DELLのサーバを友人からもらっているが、購入はしていないし、 新しいホスト名を振ってない気がする。名前は学生時代のノートパソコン の名を引き継いでmotifにした。

手持ちのPCは、papyrus(DELL Linux),chimera(MBP MacOS),graft(自 Linux休眠), motif(thinkpad Linux)という面子になりました。

LinuxでEmobile D41HW Check

Emobileの最新機種で使えるか心配だったけど、やってみたら簡単に動いた。

だが、アクセスポイントが「プロトコル制限あり」のNATの配下にしか接続できなくて苦労した。そのままでは、インターネットにpingもsshもできないのだ。

んで、Windows側でEmobileをmodemモードとかにして、シリアルポートキャプチャとかして、モデムへ送っているコマンドなんぞを調べてみた。 いくつか変なのを送っているので、真似してpppのchatスクリプトに書き込んでみるもダメ。やり方が悪いのかなぁと調べていたら、なんか違う電話番号に接続してアクセスポイントを変更している人がいた。やってみたらうまく動いた。番号だけで、追加のATコマンドは不要だった。

Linux:Emobile D41HWの設定

２つのntpdプロセス Check

最近、2軍の運用チームで仕事をしている。 これも何の縁か、NAISTの時と同じように中国人と仕事している。外国人のストレートで合理的な考え方は、流れや空気を読む日本人には刺激が強いんだけど、まぁ僕は好きだな。

それはさておき、コードとは少しも絡まない日々なので、なんか少しでも不思議があるとすごく調べたくなる病気にかかっている。

今日はこんな不思議を紹介しよう。 ntpdを立ち上げたらこうなった。

ntp      11042  0.0  0.8   4508  4504 pts/5    SL+  00:33   0:00 /usr/sbin/ntpd -u ntp:ntp -p /tmp/test.pid -d -g
root     11044  0.0  0.2   4508  1488 pts/5    S+   00:33   0:00 /usr/sbin/ntpd -u ntp:ntp -p /tmp/test.pid -d -g

普通はntpユーザで１つのntpdプロセスがあるべきなのに、ntpdが2つあって、しかも子プロセスはオーナーがrootになっとる。 ntpdは-uでntpユーザーにユーザーをsetuid()しているハズだけど、rootユーザーのプロセスが残っているという事は、setuid()する前にfork()するところがあるんだな。

ntpdのソースを眺めたところ、ntpd/ntp_config.c:L4539 do_resolve_interval()の中でforkしている事がわかった。forkして何をしているかというと、ntp_intres()という関数で設定ファイル読み込み、タイムサーバの名前逆引き, 初期化のための通信を行っている。昔はntpdと対で使うntpresというresolve専用の別プログラムだったみたい。

落ちは残念で仕方ない。そこは動いているでしょってところで 裏切られるタイプなのだ。何故、ntp_intresがforkした後、終わって無いのかというと,単純に名前が引けずに設定にかかれたntpサーバとの通信ができずに待っていたのだった。

さすがに、病でコードを追っている途中で、友人がDNS引けないのが悪いかも って気づいたんだけど、30分ぐらいの楽しい遠回りだった。バグに飢えているのかもなぁ。