便乗5冊企画: スーパーエンジニアへの道、他 - bkブログ最初の一冊はワインバーグの「スーパーエンジニアへの道」にしました。 この本は コンサルタントの秘密―技術アドバイスの人間学と相補的な内容となっています。スーパーエンジニアの方は主に自分が学ぶするための方法、コンサルタントの方は人に影響を与えるための方法について書かれています。以前に、コンサルタントの秘密を読んで改心した話を書いていますが、結局のところ、基本的にはあまり変わっていないような気もします。
横着プログラミング
このページでは Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿を公開しています。 目次 第1回: Unixのメモ技術 (2002年 1月号) 第2回: Migemo: 日本語のインクリメンタル検索 (2002年 2月号) 第3回: 履歴マニア (2002年 3月号) 第4回: ttyrec: 端末を録画再生するツール (2002年 4月号) 第5回: QuickML: 超お手軽なメーリングリスト (2002年 5月号) 第6回: chatty: 小うるさい端末 (2002年 7月号) 第7回: zphoto: ズーミングするオンラインアルバムを作るツール (2002年 8月号) 第8回: pdumpfs: 毎日のスナップショットを保存する (2002年 9月号) 第9回: Sary: Suffix Array のライブラリとツー
複雑なソフトウェアのコードリーディング #3
先日、HTML5 の File API が Chrome の中でどのように実装されているか調べた。JavaScript の中から readAsText() でファイルを読んだときにブラウザの中では一体なにが起きるのだろうか？ そんなの fread() を呼んで終わり、だったら楽なのだが、 Chromeではそうはいかない。そもそもページを描画したりJavaScriptを実行したりしているレンダラーはサンドボックスされたプロセスの中で実行されているので、ファイルアクセスが一切できない。ではどうやるかというと、ブラウザ本体のプロセスに「このファイルを読んでください」というリクエストを投げる。プロセス間通信、IPC である。 で、このリクエストはブラウザ本体ではIPC用のスレッドが受け取るのだが、このスレッドでは同期的なファイルアクセスができない。同期的なファイルアクセスをこのスレッドでやってしま
横着プログラミング 第1回: Unixのメモ技術
最終更新日: 2002-03-18 (公開日: 2002-03-18) Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿です。 横着プログラミングとは 私は必要が発明の母だとは思わない。私の意見では、発明とは怠惰 から、おそらくはまた、まさに無精から生じるものである。面倒を 省くために。 -- アガサ・クリスティ この言葉によると、どうも発明とは横着したいがために生まれるも のらしい。そう考えてみると確かに、私がプログラミングをする動 機は、横着するためのソフトウェアを作るため、という要素が大き い。突然、「うげー、面倒くせー」と叫んでプログラムを書き始め るのである。 そんなわけで、横着するためにプログラミングすることを私は勝手 に「横着プログラミング」と呼んでいる。本連載では横着プログラ ミングをテーマに、横着のコツや私が作っ
プログラミングの光景 - 日常的な学習について
最終更新日: 2007-07-27 WEB+DB PRESS Vol. 40 に向けて書いた記事の元の原稿です。 日常的な学習はプログラマにとって不可欠な活動です。ソフトウェアの世界には次々と新しい流行が登場しますし、基礎的な事柄だけでもマスターしておきたいことは山ほどあります。今回は日常的な学習の方法について私のパターンに照らし合わせて考察してみたいと思います。 ブログ ブログは学習というよりは情報収集に適したメディアです。ブログの記事は、だいたい小粒で、ひとつの記事で内容が完結しています。他の人がどんなことに興味をもっているかわかるのも、流行を知るといった点でプラスです。とはいうものの、ブログで得られる情報の大半は、断片的な雑多なノウハウであるため、長期的に役立つような知識のかたまりはほとんど残りません。 雑誌 プログラムを書いている最中に「今すぐ知りたい」といった類いのピンポイントの
man読め！という強迫観念 #13
「man読め！」「過去ログを調べてから質問しろ！」「レスって何ですか！」[1] みたいな昔のネット文化に浸かってコンピュータに関するもろもろを学んだ私は、わからないことは自分で調べるのが大原則であり、人に質問するのは最終手段だと思っていた。迂闊にくだらない質問でもしようものなら、この恥知らずの、ど素人めが！という勢いで罵倒されてしまうのだ。 今思えば、これは一種の強迫観念のようなものであった。こういった文化に触れたおかげで自分で調べ物をするのが苦ではなくなった、という点ではよかったのだが、「man読め！」のような偏狭なスタイルに毒されて、自分もそういう態度をとるようになってしまった、というのは反省すべき点である。 それはさておき、自分で調べるのが基本というのは今でも大体そう思っている。が、チームで本格的に開発するようになって学んだのは、自分で調べることに時間を費やしすぎてはいけない、という
bkノート
Google+に書いていたエッセイのアーカイブです。 すぐ置き換わるから大丈夫 #62 TeXの思い出 #61 Welcome to the industry! #60 ビルドという名のトンネル #59 キーボードを替えた話 #58 テストを実行するとログインシェルから追い出される問題 #57 シークレットストーリー #56 ドットコムバブルの思い出 #55 コミュニケーション能力とは何ぞや #54 メールで時間を無駄にしない方法 #53 パッチの数え方 #52 zipファイル中毒 #51 はじめてのIPv6 #50 最近の毛刈り #49 練習してもっと速くやるべし！ #48 忍耐力指向プログラミング (Patience Oriented Programming) #47 VPNの謎 #46 ウェブプログラマへの道 #45 プログラムの見通しをよくする方法 #44 パイプがなぜか詰まってし
一から自分でコードをバリバリ書くという幻想 #21
友人からこんなコメントをもらった。「最近 bk ノートが、何か困ると同僚に聞きに行くキャラになりつつありますよ。もっと上から目線で書かないと。するとカコイイ！ とか言ってくれる人が出てきますよ」 そんなことを言われても、困ったら助けてもらうというのは事実なんだからしょうがない。そもそも、自分の弱さを認めるが強さの始まりというものだ、うんぬん。こんなことを書けば上から目線っぽい？。。が、やっぱりやめておこう。 話を変える。既存のコードをちまちまリファクタリングして、少しだけ新しいコードを追加して、デバッグして、なんてことを年がら年中やっていると、一から自分でコードをバリバリ書けたらどんなに楽しいだろう、なんてことを考えることがある。大きなプロジェクトの中で何かをやっていると、そういう機会は滅多にない。ぶつぶつ言いながら既存のコードをいじくりまわしていることの方が多いのだ。 が、あるとき、ひと
いやな法則
思いついたいやな法則を集めています。 生産性 何もやらないよりはだらだらやった方がまし せっぱつまらないとやらない。せっぱつまってからではできない やらなければできない。やってもできない やらなくていいことはできる やらなければいけないことは楽しくない やらなくていいことをやっている人はいきいきしている 横着をするための労力を惜しんではいけない 横着をするための労力を惜しんではいけない、という口実で現実逃避してしまう 現実逃避の方が生産性が高い いやな仕事は、もっといやな仕事があるとき、いやではなくなる 決断 正しいことはすぐに中断し、間違ったことには頑固にしがみつく どちらかじゃなくて両方欲しい アイディア 考えて出てくるアイディアにろくなものはない アイディアを探してもアイディアは出てこない すぐにでも実行したいアイディアは嫌な仕事をしているときに思いつく よいと説明しないとわからない
作れる、作る、作った - bkブログ
作れる、作る、作った たまに「Namazu を作ったなんてすごいですね」と言われる。そう言われると、いつも違和感を感じる。同等のソフトウェアを作れる人ならざらにいるからだ。作れることは自体は全然すごくない。 では本当は何が評価されているのかというと、何かを作って公開し、それが比較的広く使われたことだ。作れる人はざらにいるし、同じようなものを作ってみようと考える人もそこそこいるけど、実際に作ってくれる人はなかなかいない。だから、作った人が登場するとありがたがられる。それが広く使われれば、より評価される。案外、自分ではたいしたことないと思っているものでも好評を博したりする。 文章でも同じことが言える。誰でもうすうす分かっていて、誰かが日頃から考えているようなことでも、それを書いてくれる人はなかなかいない。だから、書いた人が登場するとやっぱりみんな喜ぶ。それが広く読まれれば、より評価が高まる。読
自転車置場の議論 - bkブログ
自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの
プログラミングの光景 - プログラマについて
最終更新日: 2008-01-26 WEB+DB PRESS Vol. 43 に向けて書いた記事の元の原稿です。 「プログラミングに関する雑多な事柄」がテーマの本連載、最終回の今回はプログラマについて取り上げてみたいと思います。 生産的なプログラマとは? 生産的なプログラマは平均的なプログラマの何倍もの仕事をする、という話をよく耳にします。確かに経験に照らし合わせても、できるプログラマの生産性には目を見張るものがあります。 ここでは私がこれまでに関わった中で、生産的なプログラマにどんな特徴が見られたか紹介したいと思います。 レスポンスが早い チームでの開発では、他のメンバーから質問があったり、何かを依頼されたときに、できるだけ早くレスポンスすることが大切です。 たとえば、ちょっとした質問への返事が遅いだけで、誰かの進行が止まってしまうことがあります。レスポンスの早いプログラマと一緒に仕事を
yak shaving で人生の問題の80%が説明できる問題 - bkブログ
yak shaving で人生の問題の80%が説明できる問題 つい最近、 yak shaving （ヤクの毛を刈る）、という言葉を知りました (原典)。これは「一見無関係に見えるけど、真の問題を解くのに必要な問題を解くのに必要な（これが何段階も続く）問題を解くのに必要な活動」という意味の言葉です。 yak shaving は、ようするに「ある問題を解こうと思ったら別の問題が出てきて、それを解こうと思ったらさらに別の問題が出てきて…」ということが延々と続く状況を表しています。ちなみに、ヤクとは毛が長い、牛の一種です。 yak shaving は、以前に覚えた bikeshed と同じくらい便利そうな表現です。というもの、プログラムを書いていると yak shaving 的な状況がすぐに発生するためです。 たとえば、「Amazon のほしい物リストを CSV 形式に変換して Excel で読み
いやなブログ: 配列操作の比較表: Ruby, Python, JavaScript, Perl, C++
配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)
ソフトウェアの肥大化について - bkブログ
ソフトウェアの肥大化について 肥大化したソフトウェアというとリソース食いでメンテナンスがしづらい厄介ものというイメージがあります。しかし、広く使われているソフトウェアは多かれ少なかれ肥大化しているように思えます。ソフトウェアの肥大化はよくないことなのでしょうか。 結論からいえば、必ずしも悪いことではありません。この話題は Joel Spolsky 氏がストラテジー･レターIV：ブロートウェアと80/20の神話で書いています。私が付け加えられることはあまりありませんが、最近、知人との間で話題になったので、少し書いてみたいと思います。 数年前、 Alan Kay 氏の Squaek についての講演を聞きにいったとき、途中でコードのサイズが話題になり、Squeak のコードはこんなに小さい（具体的な数字は忘れました）といって、何千万行もある Windows NT を引き合いに出して、Squaek
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
