1次審査を突破して、ヒアリングへ。 東京出張。なんだか久しぶり。
前夜徹夜までして資料を用意してくれた面々のおかげで、 プレゼンテーションはそれなりにできたのではないだろうか。 前回よりも準備しただけあって、やはりあわてることなく質疑に対応できた気がする。
びっくりしたこと: g新部さんが向かいに座っていたこと。世間は狭すぎ。
IPAの担当者によると、応募は５０件ほどだったそうだ。 あまり多いと競争が激しくなるので、気持ちは微妙だが、 正直なところもっとたくさん応募があってよいと思う。 せっかくのチャンスなんだし。
今年は秋にも公募があるので、 チャレンジしてみてはどうだろうか。
その後、秋葉原によって、前田くんとおなじく HDD外付けケースを購入。でも、うまくいかないところまでおんなじだったりする。
今までジャンクでもたいていうまく動いていたのだが、初の惨敗か。
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と名乗る「ハッカー」を見かけない。
「ハッカー」は用量・用法を守って正しく使いましょう。
「An On-the-fly Reference Counting Garbage Collector for Java」 などというタイムリーな論文が掲載されている。
ので、読む。が、読んでいるうちに寝てしまった。 難しいぞ。
結局は、直接Reference Countを更新する代わりにスレッドごとのキューに記録しておいて、 後でまとめて更新するということらしい。 それはあんまりReference Countの良さを活かせないんではないだろうか。 ハンドシェークも多いし(4回)。
論文を読むかぎりは通常のマーク・スイープに対して性能が向上しているとあるけれど。 実際のところはどうなのかなあ。
ところで、どうもこの論文、読んだことがあるような気がしてきたんだけど。 前に(それもだいぶ前に)OOPSLAあたりに概要が載ってたんじゃないかなあ。
で、このアルゴリズムのRubyへの適用を考えると、 スレッドの扱いなどで複雑すぎるような気がする。 それとSlidingViewバッファなどで使われるメモリ消費も気になるし。
むしろ、IoやLuaのコードを読むべきかなあ。
B00008B240
中国でバッテリーの保ちに悩まされたのと、 大阪のラディカル・ベースで 妙に安かったので、衝動買い。
さすがにバッテリーが長持ちする。体感だと倍くらい？
気がついたこと
先日の挑発的なエントリは、ざっくりまとめると
ということであった。
しかし、その中で安易に「転職を考えた方がよい」と 書いたのは間違いであった。なぜならば、 会社とWin-Win関係が構築できていない場合、 その原因の大半はあなたの側にあり、 それを解消しない限り、 転職しても同じことの繰り返しになる可能性が高いからだ。
まず、最初にWin-Win関係とはなにか、についてまとめておこう。
スティーブン・コヴィーの『4906638066』によれば、 利害関係のある二者間での関係は、
の三通りがある。当然Win-Win関係が理想だが、現実にはなかなかそうもいかない。 しばしば、Win-Lose関係や、Lose-Lose関係に陥ってしまう。
経営者とプログラマの関係は、 仕事をしてもらって給料を払うという観点からは双方が得をする Win-Win関係と捉えることもできるが、 仕事と報酬がバランスしていない場合には、 簡単にWin-Lose関係になってしまう。
ここで重要なのは一方がWinしているかどうかという基準は 多分に主観的であるということである。 つまり、給料が安くても仕事内容が充実しているために満足している場合もあり、 逆に給料が高くても精神的なストレスなどのため仕事に不満があるケースも珍しくない。
このことを考えると、あなたが仕事上、正しく扱われていないという不満を持っていても、 それは必ずしも上司があなたから搾取しようと考えているわけではない。 彼らは、おそらく以下のいずれかである。
満足が主観的なものである以上、口を開かないで理解してもらえることは まったく期待できない。
この状態で不満を内に持ちつづけることは非常に生産的ではない。 もちろん、予算が無限にあるわけではない以上、 報酬など待遇にも一定の限度があるわけだが、 少なくとも交渉する余地はあるはずだ。 コミュニケーションは重要だ。
あなたの不満は伝わっているだろうか。 あるいは上司はそもそも聞く耳がないのだろうか。
十分なコミュニケーションを行っても、なおなんらかの事情で 妥協する余地が見いだせない場合には、はじめて転職が有効な選択肢として登場するだろう。 いきなり辞めるのでは、それこそLose-Loseの関係である。
いつのまにそんな話が。
いや、IT関連企業の誘致のために家賃補助というのは、 過去にも似たようなことをしているわけだし(たとえば松江市には電気代補助制度がある)、 そんなに珍しいわけではないのだけれど、 「まつもとと交流」なんてのが「魅力」として登場するというのは 予想の範囲を越えている。
まあ、みなさまの「地域資源」ですから、よしなに活用してくださいませ。
「Common Lispはいい言語だけど、ダメなところもあるよね」という話。
具体的には
とか。些細なことだといえば、その通りだが、 それが気になるくらい他の部分が良いといえば、前向きだろうか。
角谷さんから献本していただいた。
これは良い本だ。おおむね以下のような本だと言えよう。
だから、もっとも重要な点は「Rubyについて」ではない。 あらゆる新しい技術に応用可能だ。
個人的には、私が趣味としてはじめたRubyについて こんなに真面目に「仕事として使う」ことを考えてくれる人がいる ということだけで、胸が一杯になった。
あと、角谷さんが正誤表を含むサポートページを開設している。