本当は理解できていないのに、自分をだまして分かったふりをする事。そのまま読み進め最後までたどり着き、自分はこの本を読んだと勘違いしてしまう事。 分からないなら分かるまであきらめずに何度も読む。もしくは「分からなかった」と心の中に留めておく事が大事だと思う。 そのままにしておくと、読んだ時間が無駄になる。本を読んで勉強したのに手応えもないし成長した気がしない。という状態になってしまう。 最近ようやくこのことに気付いた。
Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this, and they have a plan, and their plan sucks too. It's incredible how stupid these people are. They've been looking at wrong problems all the time. Branching is not the issue. Merging is. この部分は確かにその通り。 Subversionは、マージのサポートがなさすぎてひどい。 追記 どこからどこまでがマージされたのか?というメタ情報がSubversionにはないのですよね。 なので、「以前どのブランチをどこの revisio
オープンソースマガジン2007年1月号に向けて書いた記事の元の原稿です。 前回のアルファギーク舘野君から、バトンを渡されたひげぽんです。 Mona OSというオープンソースOSを開発しています。 僕はハッカーと呼ばれるには実力不足ですが、知り合いのスゴ腕ハッカーに少しでも追いつこうと日々実践していることをいくつか紹介します。 ハッカーに学ぶ オンラインでもオフラインでも構いません、自分よりも優れているハッカーを探してお手本とすることから始めましょう。 彼(または彼女)が何を勉強し、発言し、考えているかを観察することで多くのことを学べるはずです。 周りにハッカーがいなければ、勉強会・カンファレンスに参加したり、ブログを利用してコミュニケーションをとるのもひとつの方法です。 「ハッカーに交わればハッカーになる」とまではうまくいきませんが、周りは自分より優秀な人ばかりであるという環境を作り上げる
今日も良い天気! memcached in mixi by kazeburoさん 自分も使ったことがあるので mixi のような大規模使用例の話は楽しみ。 すみません。以下にはいくつかメモ漏れがあります。 memcached って何? さまざまな言語でクライアント API memached の「分散」 クライアントに実装された分散アルゴリズムで分散 get / get_multi get_multi は非常に高速 delete 上書き禁止の秒数指定できる→知らなかった mixi での利用事例 Pentium4 / Pentium D memory 4GB Linux 2.6.x x86_64 ちょっと古めのマシン 専用マシン 100台以上 1台につき 3GB の容量で起動 cache Hit率 94%(安定している値) メモリ使用量 88%(安定している値) memcached のレポート
良い天気だしキャンパスが気持ちよい。 miyagawa さんの英語が流暢。 Larry Wall ktkr お茶目だな。 Continuous Testing Test::Continuous ソースが変更されたら自動テスト ポップアップで知らせる これいいね。 Log::Dispatch らしい Log::Dispath::MacGrowl すべてのテストを実行するのは重いよね .pm -> .t の依存関係 すべての依存関係を検知するのはむり(yamlとか) Perl as a Second Language by 弾さん なぜ外国語を学ぶべきか? 何かやるには1つ以上の方法がある 言語毎にどんなことにより注意を払っているか?の違いがある 英語・日本語・中国語における「いとこ」の例 Perl と他の言語が似ている例 print "Hello, World!"; # python, ru
ここ数日時間をかけているわりにはインタプリタのパフォーマンスチューニングが進まない。 しかもうまく進む気がしないもやもやする。これは良くない兆候だ。 Mさんに言わせればこれは知識や経験やどこまでやりこんだことがあるかといったものが足りないことに起因するようだ。 すぐそこに速くなるはずのものがあるのにもどかしい。 なので自分が知っていることやったこと悩んでいることを書いてみようと思う。 パフォーマンスチューニングとは? パフォーマンスチューニングは以下の要素と手順からなると思う。 目標 チューニングのための動機。 要求される速度が出ていないとか。 1秒以内にレスポンスを返すようにとか。 調査 ボトルネックとなる場所を特定する。 チューニング 問題となるコードに手を加えて速くする。 再計測 目標を達成しているか? 上記をくり返す。 これをベースに考えよう。 目標 大きな目標は Gauche 以
ダシにして申し訳ないが、典型的なLisperからみたかつてのid:higeponや、現在のid:amachangの「知力」は高いとはとても言えない。例えば遅延評価のことは、SICPを読めばちゃんと書いてある。そしてこれはまともなComputer Scienceがある大学なら、一番最初に使う教科書の一つなのだ。「まとも」に教育を受けた人なら、「遅延評価童貞が許されるのは、小学生までだよねー」とか言うかもしれない。 しかし、彼らの知的生産力は10倍どころでなく高い。その過程を逐次晒しているからだ。その過程で「知力」豊かな人々の助言も得られるし、彼らの「失敗」を通して彼ら自身だけではなく、彼らのblogの読者もそこから学ぶことができる。もし読者の知的生産力の向上も彼らの知的生産力の方にカウントしたら、知的生産力の差は十倍どころか数千倍、いや数万倍のオーダーだろう。これを繰り返しているうちに、今度
明日から社会人復帰なので、退職してから今日までの79日を振り返る。 背景 もしも仕事を辞めることがあったら試したいことがあった。自分の人生から「仕事」が無くなったときに 自分は何をするのか? 自分は Mona のコードを今までどおりに書き続けるのか? 自分はどこまで本気コーディングを続けられるのか? 自分の能力のリミットは? などを知ること。 これらを早い段階できちんと知っておかないと、今後の人生の分岐点で核心を持って正しいと思える判断ができない。 自分に甘い楽観的な予測であれば立てられるが、それが合っている保証はない。試してみるほかない。 例えば、最悪想定の悲観的なシナリオでは 仕事の反動や課外活動としてしか Mona をやれない 気づけば毎日ダラダラしているだけ 自分は自分が失望するほど能力がない という可能性があるわけ。 結果 概ね満足できる結果だった。 Mona のコードを書きつづ
金曜日に退職し、すぐに働き始める訳ではないので、年金・保険証・住民税の手続きをやってきました。 忘れたり先延ばしにすると色々と面倒なのですぐにやってしまうのが良いです。 年金 会社に所属している間は厚生年金に加入していて「厚生年金保険」という項目で給与から年金の積立(?)が行われていました。 退職したので自分で払わなければいけません。 用意するもの以下の通り。 年金手帳(自分と妻の両方) 退職証明書(勤め先が発行してくれたもの) これを持って区役所の年金コーナーへ。 係の人に事情を説明すると 夫婦揃ってこれからは国民年金に加入 手続き時点では厚生年金が加入中の扱いだったので退職証明書のコピーをとって手続きしてもらう 後日、年金の納付書が送付されるので支払いをすれば OK。 再就職した場合は 夫婦の年金手帳を次の職場に提出し手続きをしてもらう 夫は厚生年金に加入 妻は3号被保険者に変更 保険
本日*1をもちましてはてなを退職することになりました。 お世話になったみなさん本当にありがとうございました。 僕は、はてなRSSや Rimo などまとまった大きなサービスから、ダイアリーのメール投稿機能など小さな機能まで、はてなのいろいろな部分に関わらせていただきました。 その過程で 実際にサービスを使ってくれるユーザーのみなさん はてなアイデアを通じてアイデア投稿や不具合報告をしてくれるみなさん 告知日記のブックマークコメントで喜んでくれるみなさん 日記で感想や要望を書いてくれるみなさん など、本当に多くのユーザーの方といろいろな形でコミュニケーションをとらせていただきました。 そのみなさんとのやりとりが、より良いサービスを作りたいというモチベーションになったり、日々の僕自身の楽しみやはげみになったりと、たくさんの力をいただきました。(本当はユーザー id を挙げてお礼が言いたかったので
多重継承に限らないけど、仮想関数テーブル(へのポインタ変数)のせいで、キャストによってポインタのアドレスが変わることがある。 なのでガベージコレクタ(GC)を併用しているときに死ぬ。 GC は、new が返したアドレスが参照されているかどうか?で mark and sweep するのだけど、キャストでアドレスが変わってしまうと、どこからも参照されないと勘違いしてしまう。 つまり生きているポインタを sweep してしまう。 そして処理系はしばらく生き続け、あるとき突然死を迎える。 というのが今回の -O3 で処理系が死ぬ原因だった。 そもそも出来心で多重継承を使っていた僕が悪いのだけど、これは中々気づきづらいバグだよなあ。 細かくデバッグしてやっと気づいたけど、これは気づけたが自分を褒めてあげたい。 これをうまく防ぐ方法あるかな。(g++のオプションとか?)
マシン語を知らない子ども達 完全に乗り遅れたけどなんとなく。 いちおうLLと呼ばれる上の方からOSの下の方までコードを書いたことがあるけど、マシン語を特別扱いはせず ソートのアルゴリズムを知っている PHPでWebアプリが書ける と同列くらいの選択肢のひとつとして見る、くらいで良いのではないだろうか。 知らなくて損することはもちろんあるかもしれないが必須というほどでもない感じ。 まあそうは言っても、マシン語や簡単な回路を理解するとまだ浅いコンピュータの歴史の中で人類がいろいろと工夫を積み重ねてきたものが見えて面白いので、興味のある人はCPUの創りかたをあたりをとっかかりに読むと良いかも。 あとは以前よく2chでインテルのマニュアルを嫁とか言われたのですが、今ならその価値が分かる。 はじめて読む486あたりを読んだら次は、インテルのマニュアルを印刷して暇なとき眺めると吉。 日本語だしインテル
タイピングが苦手な人はこちらをどうぞ。 同僚のid:onishiとid:mizuno_takaakiと昼食を食べているときに、タイピングの速さの話になりました。 プログラマ同士でなかなか比べることがないと思いますが、たとえばid:naoyaんはかなりタイピングが速いです。(Emacsやシェルの操作をいろいろ知っているのもあると思いますが)。 というわけでプログラマの皆さん、タイピング速度をトラックバックやコメント欄で教えてください。 http://www.e-typing.ne.jp/の「腕試しチェック」で計測できます。 ちなみに僕はこんな感じで、全国ランキングを見る限りではぜんぜん速くないようです(涙 個人的にはid:yaneuraoさんや、arinoさん、id:mjtさん、id:ryoko_komachiさん、id:softetherさんあたりのタイピング速度にはとても興味があります。
Google Code Searchはとても便利ですが、自分の公開しているあのコードが検索に引っかからない!ということを経験しました。 調べたところGoogle Code Search - Help Google Code Search find your codeのページから tar.gz,zipなどのArchiveファイルのURL CVSリポジトリ Subversionリポジトリ を登録すればクロールしてくれるようです。 Please note that we do not add all submitted code to our index, and we cannot make any predictions or guarantees about when or if it will appear. と書いてあるので全部クロールされるとは限らないですが、やってみる価値はあるので
最近Monaプロジェクトで議論をする際に 自分の言いたい事が伝わっていない 相手の言いたい事が分からない 議論の本筋と違う所へと話がそれてしまう などがあって力のなさを感じていました。 議論の方法論でも学ぼうかといろいろ聞いてみたところ id:naoya が教えてくれたうちの1冊を読んでみました。 読みながらメモとしてChangeLogに残したものは以下の通り。 初対面ので相手との会話で信頼を得るには? 相手の言うことをきちんと理解できていて、期待されている形で返事が出来ているか 人が書いたものを読むということを疎かにしない 相手の問いを共有する。問いを間違えない 恐れを動機としてものをかかない 相手のいっていることを要約すると力が付く 意見=相手がもっとも言いたいことは 論拠=その理由は? 問い=どういう問いに基づいているか? 自分の期限を入れてみよう 今日から実践してみます。 あなたの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く