«前の日(04-19) 最新 次の日(04-21)» 追記

Matzにっき


2004年04月20日

_ [会社]オープンソースソフトウェア活用基盤整備事業ヒアリング

1次審査を突破して、ヒアリングへ。 東京出張。なんだか久しぶり。

前夜徹夜までして資料を用意してくれた面々のおかげで、 プレゼンテーションはそれなりにできたのではないだろうか。 前回よりも準備しただけあって、やはりあわてることなく質疑に対応できた気がする。

びっくりしたこと: g新部さんが向かいに座っていたこと。世間は狭すぎ。

IPAの担当者によると、応募は50件ほどだったそうだ。 あまり多いと競争が激しくなるので、気持ちは微妙だが、 正直なところもっとたくさん応募があってよいと思う。 せっかくのチャンスなんだし。

今年は秋にも公募があるので、 チャレンジしてみてはどうだろうか。

その後、秋葉原によって、前田くんとおなじく HDD外付けケースを購入。でも、うまくいかないところまでおんなじだったりする。

今までジャンクでもたいていうまく動いていたのだが、初の惨敗か。


2005年04月20日

_ [言語] Dynamic Languages Symposium 2005

OOPSLAと共催される「動的言語シンポジウム」。

なぜか私もProgram Committeeに 名を連ねてたりしている。

今年のOOPSLAは、Ruby Conferenceの直後だし、 Wiki Workshopはあるし、Dynamic Languages Symposiumもあるしで盛り沢山かも。

_ ある「ハッカー」の顛末

IRCでトラブルが起きた時に、ある「ハッカー」が気に入らない相手に何をしようとして、 何が起きたか、というお話。ある意味、喜劇、別の意味では悲劇、かも。

原文はドイツ語らしい。雰囲気を伝える超訳。全然正確じゃないんでそのつもりで。

ハッカー(以下「ハ」): なんで俺をbanしたんだ。
攻撃対象(以下「対」): そんなことしてない。

(中略)

ハ: お前(のPC)をハックしてやる。IPアドレスを教えろっ。
対: えーと、127.0.0.1だけど。
ハ: 俺の持ってるツールを使えばお前のPCは一発だ
対: なんと恐ろしいことだ(棒読み)
ハ: バイバイ
! bitchchecker (~java@euirc-61a2169c.dip.t-dialin.net) Quit (Ping timeout#)

数分後

+ bitchchecker (~java@euirc-b5cd558e.dip.t-dialin.net) has joined #stopHipHop
ハ: 運がよかったな。ちょうど俺のPCがクラッシュしたんで助かったな
対: ならもう一度ハックしてみてよ。IPアドレスは127.0.0.1だよ
ハ: 馬鹿が
ハ: バイバイ
! bitchchecker (~java@euirc-b5cd558e.dip.t-dialin.net) Quit (Ping timeout#)

さらに数分後

+ bitchchecker (~java@euirc-9ff3c180.dip.t-dialin.net) has joined #stopHipHop
ハ: お前ずるいぞ。ファイアウォールを使ってるな
対: そうだっけか
ハ: お前のファイアウォールが停止信号を俺のPCに跳ね返したんだ
対: そんなことできるなんて知らなかったよ
第三者: お前いくつだよ
ハ: 26だ
ハ: ファイアウォールを使うなんて男らしくないぞ
ハ: ファイアウォールを使うのは女々しいやつだ
ハ: 男らしくファイアウォールをオフにしてみろ
ハ: 俺のウィルスがお前のPCを破壊してやる
第三者: ファイアウォールをかいくぐるのが「ハック」じゃないのか

対: 分かったよ。同僚にファイアウォールの止め方を聞いた
対: オフにしたからアタックしてみな
ハ: IPアドレスを教えろ
対: 127.0.0.1
ハ: よーし、見てろ

ハ: お前のG:ドライブは削除されたぞ
ハ: 後20秒でF:ドライブも削除だ
ハ: F:ドライブもE:ドライブもおシャカだ
ハ: D:ドライブも削除
ハ: インターネットでIPアドレスを公開するなんて馬鹿なやつだ
ハ: C:ドライブももう30%削除した

手元のPCのディスクには異常はない。 「ハッカー」に、彼が攻撃してるのは違うPCだと教えるべきだろうか。

! bitchchecker (~java@euirc-9ff3c180.dip.t-dialin.net) Quit (Ping timeout#)

遅かったようだ。それ以来、bitchcheckerと名乗る「ハッカー」を見かけない。

「ハッカー」は用量・用法を守って正しく使いましょう。


2006年04月20日

_ [言語] TOPLAS Volume 28 Number 1

「An On-the-fly Reference Counting Garbage Collector for Java」 などというタイムリーな論文が掲載されている。

ので、読む。が、読んでいるうちに寝てしまった。 難しいぞ。

結局は、直接Reference Countを更新する代わりにスレッドごとのキューに記録しておいて、 後でまとめて更新するということらしい。 それはあんまりReference Countの良さを活かせないんではないだろうか。 ハンドシェークも多いし(4回)。

論文を読むかぎりは通常のマーク・スイープに対して性能が向上しているとあるけれど。 実際のところはどうなのかなあ。

ところで、どうもこの論文、読んだことがあるような気がしてきたんだけど。 前に(それもだいぶ前に)OOPSLAあたりに概要が載ってたんじゃないかなあ。

で、このアルゴリズムのRubyへの適用を考えると、 スレッドの扱いなどで複雑すぎるような気がする。 それとSlidingViewバッファなどで使われるメモリ消費も気になるし。

むしろ、IoやLuaのコードを読むべきかなあ。

_ ThinkPad X30シリーズ 拡張用Li-Ion バッテリー・パック

B00008B240

中国でバッテリーの保ちに悩まされたのと、 大阪のラディカル・ベースで 妙に安かったので、衝動買い。

さすがにバッテリーが長持ちする。体感だと倍くらい?

気がついたこと

  • 思ったより大きくて重い。が、妥協できる
  • 付けるとかなり本体がチルトする。好みによるけど、私は妥協できる
  • というか、そもそもスタンド立てないと安定しないデザインってどうよ
  • なぜ標準バッテリー(4400mAh)より大きく、重いのに、 容量が少ない(3600mAh)のか。なぞだ。
  • IBAM(intellegent battery monitor)は 拡張バッテリーによる容量変化に対応できないみたい

2007年04月20日

_ Win-Win関係を築くことについて

先日の挑発的なエントリは、ざっくりまとめると

  • 仕事上の苦労は昇進に直結しない(むしろじゃまになる)
  • 仕事上の苦労が将来報われるということは期待できない
  • Win-Win関係の構築に真剣になるべき

ということであった。

しかし、その中で安易に「転職を考えた方がよい」と 書いたのは間違いであった。なぜならば、 会社とWin-Win関係が構築できていない場合、 その原因の大半はあなたの側にあり、 それを解消しない限り、 転職しても同じことの繰り返しになる可能性が高いからだ。

まず、最初にWin-Win関係とはなにか、についてまとめておこう。

スティーブン・コヴィーの『4906638066』によれば、 利害関係のある二者間での関係は、

  • 双方が得をするWin-Win関係
  • 一方が損をし、他方が得をするWin-Lose関係
  • 双方が損をするLose-Lose関係

の三通りがある。当然Win-Win関係が理想だが、現実にはなかなかそうもいかない。 しばしば、Win-Lose関係や、Lose-Lose関係に陥ってしまう。

経営者とプログラマの関係は、 仕事をしてもらって給料を払うという観点からは双方が得をする Win-Win関係と捉えることもできるが、 仕事と報酬がバランスしていない場合には、 簡単にWin-Lose関係になってしまう。

ここで重要なのは一方がWinしているかどうかという基準は 多分に主観的であるということである。 つまり、給料が安くても仕事内容が充実しているために満足している場合もあり、 逆に給料が高くても精神的なストレスなどのため仕事に不満があるケースも珍しくない。

このことを考えると、あなたが仕事上、正しく扱われていないという不満を持っていても、 それは必ずしも上司があなたから搾取しようと考えているわけではない。 彼らは、おそらく以下のいずれかである。

  • あなたの不満に気づいていない
  • あなたの不満に関心がない
  • Win-Win関係が維持できていると思っている

満足が主観的なものである以上、口を開かないで理解してもらえることは まったく期待できない。

この状態で不満を内に持ちつづけることは非常に生産的ではない。 もちろん、予算が無限にあるわけではない以上、 報酬など待遇にも一定の限度があるわけだが、 少なくとも交渉する余地はあるはずだ。 コミュニケーションは重要だ。

あなたの不満は伝わっているだろうか。 あるいは上司はそもそも聞く耳がないのだろうか。

十分なコミュニケーションを行っても、なおなんらかの事情で 妥協する余地が見いだせない場合には、はじめて転職が有効な選択肢として登場するだろう。 いきなり辞めるのでは、それこそLose-Loseの関係である。

_ [Ruby] 「Ruby開発者との交流も魅力」,松江市が「8年間家賃半額」でIT企業を誘致:ITpro

いつのまにそんな話が。

いや、IT関連企業の誘致のために家賃補助というのは、 過去にも似たようなことをしているわけだし(たとえば松江市には電気代補助制度がある)、 そんなに珍しいわけではないのだけれど、 「まつもとと交流」なんてのが「魅力」として登場するというのは 予想の範囲を越えている。

まあ、みなさまの「地域資源」ですから、よしなに活用してくださいませ。

_ [言語] How Common Lisp sucks - comp.lang.lisp | Google Groups

「Common Lispはいい言語だけど、ダメなところもあるよね」という話。

具体的には

  • 近代的な機能に対する標準APIがない(データベース、他言語インタフェースとか)
  • lisp-2としての性質は変えようがない。DSLとして向かないこともある(ただ、これは無茶な話だと思うけど)
  • いくつかの関数名がダメすぎ。ELTはNTHの機能を包含しているし、引数の順番が逆。集合の差分はSET-DIFFERENCEなのに共通部はINTERSECTIONだったり。

とか。些細なことだといえば、その通りだが、 それが気になるくらい他の部分が良いといえば、前向きだろうか。

_ [Ruby] 『0976694093』

角谷さんから献本していただいた。

これは良い本だ。おおむね以下のような本だと言えよう。

  • 新しい技術を冷静にキャッチアップする技術(手順)
  • マネージャにRubyを紹介するための理論武装
  • 「Rubyの良さ」の再確認

だから、もっとも重要な点は「Rubyについて」ではない。 あらゆる新しい技術に応用可能だ。

個人的には、私が趣味としてはじめたRubyについて こんなに真面目に「仕事として使う」ことを考えてくれる人がいる ということだけで、胸が一杯になった。

あと、角谷さんが正誤表を含むサポートページを開設している。


«前の日(04-19) 最新 次の日(04-21)» 追記