一から自分でコードをバリバリ書くという幻想 #21
友人からこんなコメントをもらった。「最近 bk ノートが、何か困ると同僚に聞きに行くキャラになりつつありますよ。もっと上から目線で書かないと。するとカコイイ！ とか言ってくれる人が出てきますよ」 そんなことを言われても、困ったら助けてもらうというのは事実なんだからしょうがない。そもそも、自分の弱さを認めるが強さの始まりというものだ、うんぬん。こんなことを書けば上から目線っぽい？。。が、やっぱりやめておこう。 話を変える。既存のコードをちまちまリファクタリングして、少しだけ新しいコードを追加して、デバッグして、なんてことを年がら年中やっていると、一から自分でコードをバリバリ書けたらどんなに楽しいだろう、なんてことを考えることがある。大きなプロジェクトの中で何かをやっていると、そういう機会は滅多にない。ぶつぶつ言いながら既存のコードをいじくりまわしていることの方が多いのだ。 が、あるとき、ひと
いやなブログ - 文字列操作の比較表: Ruby, Python, JavaScript, P...
文字列操作の比較表: Ruby, Python, JavaScript, Perl, C++ Ruby, Python, JavaScript, Perl, C++ の文字列操作の比較表を作りました。配列操作の比較表の続編です。間違いなどがあったらご指摘いただけると助かります。 Ruby (String) Python (str) JavaScript (String) Perl C++ (std::string)
自転車置場の議論 - bkブログ
自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの
横着プログラミング 第3回: 履歴マニア
最終更新日: 2002-05-18 (公開日: 2002-05-18) Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿です。 コンピュータの方がうまくできることに人間を使うな。 -- Tom Duff *1 私の見る限り、プログラマという人種は決まって事務作業が嫌いな ようである。同じような書類を何枚も書かされたり、1つ誤字があ るから書き直せと言われたりすると、異常にストレスがたまる。 同様に、計算機を使っていても、同じような作業を何度も繰り返し たり、ちょっとでも間違えたら最初からやり直し、というのは耐え られない。そこで、今回は履歴を活用して作業の再利用をするノウ ハウを取り上げる。 シェルの履歴 Unixを使い始めて間もない初心者が作業しているところを見ると、 打ち間違えたコマンドを律儀に最初から打ち直しているのに気づく
yak shaving で人生の問題の80%が説明できる問題 - bkブログ
yak shaving で人生の問題の80%が説明できる問題 つい最近、 yak shaving （ヤクの毛を刈る）、という言葉を知りました (原典)。これは「一見無関係に見えるけど、真の問題を解くのに必要な問題を解くのに必要な（これが何段階も続く）問題を解くのに必要な活動」という意味の言葉です。 yak shaving は、ようするに「ある問題を解こうと思ったら別の問題が出てきて、それを解こうと思ったらさらに別の問題が出てきて…」ということが延々と続く状況を表しています。ちなみに、ヤクとは毛が長い、牛の一種です。 yak shaving は、以前に覚えた bikeshed と同じくらい便利そうな表現です。というもの、プログラムを書いていると yak shaving 的な状況がすぐに発生するためです。 たとえば、「Amazon のほしい物リストを CSV 形式に変換して Excel で読み
ソフトウェアの肥大化について - bkブログ
ソフトウェアの肥大化について 肥大化したソフトウェアというとリソース食いでメンテナンスがしづらい厄介ものというイメージがあります。しかし、広く使われているソフトウェアは多かれ少なかれ肥大化しているように思えます。ソフトウェアの肥大化はよくないことなのでしょうか。 結論からいえば、必ずしも悪いことではありません。この話題は Joel Spolsky 氏がストラテジー･レターIV：ブロートウェアと80/20の神話で書いています。私が付け加えられることはあまりありませんが、最近、知人との間で話題になったので、少し書いてみたいと思います。 数年前、 Alan Kay 氏の Squaek についての講演を聞きにいったとき、途中でコードのサイズが話題になり、Squeak のコードはこんなに小さい（具体的な数字は忘れました）といって、何千万行もある Windows NT を引き合いに出して、Squaek
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
