立川住民としては、いまからすごい期待があるわけで、さっそくPDFのマップを印刷してあちこちの店にチェックしておいた。今週金曜オープン、たぶん開店記念で早いもの勝ちな何かがあるだろうし、会社どうしようかなー、とか。

Wiki小話/Vol.8に参加してきました。@新宿の繁華街。

自分が持っていった質問

• 使われなくなる
  • 構造化されてない、探しづらい (現場の声)
  • 検索もあまり使われてない
  • やっぱExcelで情報共有だよね派閥
• 書きっぱなしになりがち
  • 情報がすぐ古くなる
  • 所有権 (だれだれさんが書いたものだから、私が手を入れるのはちょっと…みたいな声)

塚原さんの話

Enterprise2.0な発表をしてきたのでその報告。Wikiによる見える化は:

• 共有できてよい
• 見えすぎ問題。他部署、関係会社には見せたくないものも多々あるわけで。

といったpros/consがある。これまでは、草の根bottom upで、野良Wikiが社内にぼこぼことある状態だった。これからは、top downで導入し、アクセス管理、誰が変更したかトラッキング、まとまりをもたせたりといったことをしないといけないフェーズ。

感想

top downにしても、アクティブに書く人は変わらなさそう。参加なければ決意なしという言葉がにもあるように。 でも、強制することによって、書き始めることへのtriggerにはなりそう。続くかどうかはまた別の問題だけど。

ふしはらさんの話

IRC重要。Wikiはストックを入れるところである。WikiエンジンはHikiをつかってるけど、いろいろ問題あるし、これからは自作しようと思う。自動的に構造化されて、他のイントラシステムと連動するようなものを目指す、とのこと。

質疑

• IRCつかうとinterruptされて困るという声をよく聞くんですが、だいじょうぶですか?
  • 重大なバグが見つかったとかだと、interruptされないと困る。いまのところ、回ってるよ
• activeに書くひとは限られてる問題にはどうしてますか?
  • 回ってるならいいんじゃないですかね
• InterWikiは使ってますか?
  • No

感想

• wemaの中のひと !
• 自分の周りの状況とも似てると思った。組織の人数と、activeに書く人との間には反比例の関係がありそう。
• 他にもTracとかタスク管理とかのイントラツールを使ってるということ。Wikiは、「その他」の情報をストックするところなのかな。
• 他のストック情報との連携がだいじなんだろうな。InterWikiとか、イントラサーチとか。このへん、もっと開拓されてもよさそう。

etoさんの話

qwik.jpについて。 Wikiはじめのなれそめは、芸大の授業での導入。コミュニケーションが活発になってすごいよかった。 勢いにのって、センセイ同士の交流にも使おうとしたけど、アクセス制御で挫折した。qwikについては略。

感想

qwikもっと使おうと思った。イントラでいちど導入しようとして挫折したんだよな。

全体の感想

• bottom upな野良Wikiを、横断連携/アクセス制御できるようにしていくのが現実的な近道じゃないかな
• InterWiki間を横断して検索できるような仕組みがあったらよさげ
• 探しづらい問題は、未解決なんだな。なんとかしたい
• Wikiで情報共有をうまく盛り上げるには、共有したいと思うことをターゲットにして、書くモチベーションを上げるしかなさそう。やれと言ってできるもんじゃない。
• ルノアール会議室、つかえるなー

---

今回はノートをコーネル式でとってみました。聞いたことと自分が感じたことを別に書くようにするのは、あとから振り返るのになかなか効果的です。とこのまとめエントリを書きながら思う。

あと、右隣がアイドル・マスターというスタンドをもつらしいたださんで、WS004SH(ガンメタリック)とiPod shuffle(オレンジ)という装備が自分のとまったく一緒だった。なんか服装がかっこよかった。

深夜12時スタート。ねむすぐる。

Easy

WhiteCells

チェスの盤をモチーフにした、単純な文字列と配列処理問題。4分で書いてsubmitし、241.10ptsでした。

Medium

ObtainingDigitK

50桁以内の整数の加算問題。たまにあるやつです。

irbで試すと、

>> (2**64).to_s.size
=> 20

となり、64ビットの精度でもってしても20桁がせいぜい、なのでふつうに計算したらいかんだろうと思い、ちょっと考える。

下2桁だけについて考えればいいんじゃ? というアイデアが閃き、さっそくコードに。テストもちゃんとパスしたので、上機嫌でsubmitし、421.68ptsを稼ぎ出しました。

Hard

ProgrammingDevice

DPかなぁと思うんだけど、いまいち使いこなせない。できそうでできないまま時間切れ。

Challenge phase

今回もテストケースを考えられず。でも撃墜されることもなく、過ぎていきました。

System Test

Mediumが撃沈です。

下2桁の計算だけじゃ、ぜんぜんダメだと。もともとあるテストケースにうまいことのせられた感じです。悔しいなぁ。

しかしそれにしても、なんで2桁でいけると思い込んだんだろう。そしてそういう考えに至った人が多かったのはなぜなんだろう。

ちなみに、パスしていた上位陣のコードはJavaで、BigIntegerをつかってほんとに計算するというものでした。適材適所すぎる。

おまけ

Challenge phaseで撃墜されてたひとが、「なんで撃墜されたか分かんないよ」と言っていたので一緒に考えてました。そしたら、まったく同じ間違いをしてたことに二人とも気づいて、うなだれたという。

TopCoderのchatはおもしろいよ。今日の話し相手はパキスタンの学生だったみたい。

まとめ

用意されてるテストケースだけじゃなくて、自分でよりコーナーケースを考え出す習慣をつけないと。Challenge phaseにも使えるし。

Ratingは、885→860と△25でした。深夜にやると下がる傾向にあるかも。

個々がそれぞれにコメントやトラックバックのスパム対策をするなんてナンセンスだ。

コメントに関してはもう、はてブやdel.icio.usみたいなSBMにぜんぶ任せちゃってもいいんじゃないかな。 でもそれはそれで、何度も同じエントリにコメントできなくてまずいか。

トラックバックを移譲できるサービスってないかな…

栗ごはんをつくることになった。

生の栗の皮をむく。 そのままでは硬すぎるから、しばらく熱湯に浸けておく。 そしておもむろに熱湯から栗を1つつまみ出し、神速で包丁を入れ、外壁をとる。運がよければ、このときついでに渋皮までとれる。

んだけど、冷めてしまってたりした場合渋皮がとれない。 しぶしぶ自分の爪と気力で渋皮をむく。これがきつい。 ぜんぜんむけないのだ。こてんぱんに打ちのめされる1時間。

けっきょく20個くらいの栗の渋皮を爪でむいた。 もう爪がぼろぼろで、今日いちにちキーボードが打てる気がしないね。

とかいいながらこんなエントリを書く。

フランクリ・プランナーは、 を実践するための公式第4世代ツール。 どんなものか丸善で見てきたのだけれど、いかにも大きい… とてもウェストポーチに入らないのですね。んー、アメリカン。 ポケットサイズもあるのだけど、店頭にはありませんでした。

僕はほぼ日手帳使いなんだけれど、 フランクリン・プランナーはさすがに7つの習慣を実践するための工夫がそちらこちらになされてて、機能的で使いやすそうです。 システム手帳に回帰したくもあり。バインダーに何でもがっちゃんこと挟めるのが、カスタマイズ好きにはぐっとくるんですよね。

けっきょくは、どういう風に使うかというのをよーく考えてみないと、どれを選んでもしかたないのです。と自分に言い聞かせる。 足りないものがあれば工夫しなきゃな。

最近、MacPortsのMySQLサーバを5.0.33にしたのですが、なにやらmysqldumpがうまくいってませんでした。 で、5分ほどで解決したので自分へのメモ。

mysqldump: Error: Binlogging on server not active

うーむ、どうしたものかとぐぐってみたところ、MySQLのForumにてそれらしき解答が。

log-bin=mysql-bin

をmy.cnfに書けと。

で、/opt/local/etc/mysql5/my.cnf あたりに、

[mysqld]
log-bin=mysql-bin

を足したら、ちゃんとdumpできました。

でした。C3のケーキにろうそくを並べておいてお出迎え。

めがねを観て、 ふらっと通りがかったMARGARET HOWELLでぴぴっと来たパンプスをプレゼントしたあと、近所のKIHACHIでディナー。人生2度目のKIHACHIでした。前菜からデザートに至るまで隙がなさすぎる。特に魚ですよね。かじきとかすずきの味つけがすばらしかった。

いつまでも、こうやって祝っていけたらと思う。ハッピーバースデー。

今日から公開だったを観てきました。かもめ食堂チームによる。 都会の慌しい中にいて、南の島のゆったりした時間を、押しつけがましくない映像で味わうことのできる、素敵な映画でした。

構図の良さや間の雰囲気はかもめ食堂ゆずり。きっと監督の世界のみかたが広くてどっしりとしてるんだろうな。

素敵な時間はいつか終わってしまったり、なくなってしまったりするし、そういうのが過ぎていくのをただ眺めているしかできないこともあるのだけれど、人は繰り返すこともできるし、あらたに始めることもできる。季節というのは、そういうことを教えてくれるんだというメッセージが込められた作品だったと受け取りました。 陽はまた昇るし、明けない夜はないし、冬の次には春が来るのです。

「人生でいちばんのかき氷だった」という描写があって、映像で味を伝えるのは難しいのだなと。見えないし聴こえない。 真夏のギラギラに暑い炎天下でこのシーンを観ていればだいぶ臨場感が違ったのかも、とか思う反面、それでも僕たちは見えない感情というものを映像で伝えることはできているんだな、ひとの表現力は奥深いんだなとか感心したり。

帰り際にパンフレットを買って行った。あの地図が挟んであったり、いろいろと作り込まれててうれしかった。 ちゃんと気持ちが入ったものを手にするというのはよいものです。

きっと、近いうちに誰かがメルシー体操を実演してYoutubeとかにアップすると予言しておく。

関連

• かもめ食堂を観た

TopCoderの問題では、よく文字列をスペースで区切る必要があります。

Javaとかだと、あっさりString#splitがあるのでラクすぎるのですが、C++だとそうもいかない。 でも、Boost String Algorithms Library が使えれば、 splitが用意されているので

string "yey i'll be splitted";
vector  out;
boost::algorithm::split(out, string, boost::algorithm::is_space());

なんてするだけで、スペースで区切った文字列の配列を得ることができて、ちょう便利です。

果たして、TopCoderの環境でも、これが使えるのか試してみました。

Boostのバージョンを確かめる

stringを返すようなProblem StatementをPracticeから探します。 そんで、

include

...
return BOOST_LIB_VERSION;
...

とかして、Compile → Test し、結果を確認。1_32が返されてきました。1.32か。

splitしてみる

なにはともあれ、上で書いたようなsplitのコードを Compile してみます。

/usr/include/boost/config/compiler/gcc.hpp:92:7: warning: #warning “Unknown compiler version – please run the configure tests and report the results”

というwarningがでますが、ちゃんとmakeできた模様。やった。 TopCoderのコンパイルファームにてBoostをビルドした環境 (gcc on ???) が、確認されていないプラットフォームだったのではないでしょうか。

まとめ

TopCoderの環境でも、文字列の分割にBoostがつかえることが分かりました。バージョンは2007.09.21 現在で 1.32でした。

他にも文字列の分割方法はいろいろあるので、あとでまとめておこうと思います。