404 Blog Not Found:我々全員の知的生産性を10桁上げる方法
2008年02月04日12:15 カテゴリArt 我々全員の知的生産性を10桁上げる方法 池田先生、50点。 あなたの知的生産性を10倍上げる法 - 池田信夫 blog 知的生産性を上げるためにもっとも重要なのは、こういうお手軽なハウツー本やマスコミの通念を信じないで、自分の頭で徹底的に考えることである。 それも筆記試験だとした場合。マークシートのように、答えだけしか書かないものであれば0点。 なぜか。 知的生産力は知力とは異なるからだ。 知力というのは、「人に思いつかない事を思いつける」能力。それに対し、知的生産力は、「人が思わないことを、人に届ける」能力。 だから、徹底的に考え抜くというのは、知的生産においては査定0なのだ。むしろ「とりあえずここまで考えた」というのをさくっと抜いてしまった方が知的生産力は高いといってよい。 ダシにして申し訳ないが、典型的なLisperからみたかつてのi
コーディングや設計で難所に出くわした時にすること - higepon blog
仕事や趣味でコードを書いているとき、設計をしているときに難所に出くわすことがあります。 そんなときに僕が意識的に心がけていることを紹介します。 もっと良い方法があったらぜひ教えてください。→皆様。 難所に出くわす前に「もうすぐ難所だな」と気づいているときは、すでに冷静な状態で心構えができています。 この場合はきちんと対処ができることが多いです。 何度も考えがループしていたり、難しすぎて他の事に逃避しているときは集中力がないか、難所にさしかかっているサインなので、難所の場合は以下の5つを順番に試しています。 絵を描く 人に言葉にして説明する 思考の流れをテキストにする 散歩する 次の日に持ち越す 絵を描く 設計やコーディングに関して、分かっていることを絵や図にあえて描いてみます。 分からないところは箱を描いて中に? とでも書いておけば良いです。 絵を書く過程で、自分がどこが分かっていないかが
ウェブアプリケーションセキュリティとバッドノウハウ、そしてグッドラッパーの関係
ウェブアプリケーションセキュリティとバッドノウハウ、そしてグッドラッパーの関係 by 金床 ---------------------------------- はじめに ---------------------------------- 筆者はウェブアプリケーション開発者であると同時にセキュリティ技術にも興味がある。自身がSeaSurfers MLというウェブアプリケーションセキュリティをテーマとしたメーリングリストを主催しており、またセキュリティコミュニティに多くの知人、友人がいる。しかし彼らとウェブアプリケーションなどのセキュリティ対策について意見を交換すると、違和感をおぼえることが多い。 彼らは脆弱性の原理についてとても詳しいのだが、以下のような会話が頻繁に発生するのである。 「…つまり原理的に考えて、このようにすればXSSは発生しないんだよ」 「な
バッドノウハウからグッドラッパーへ
「有用なものを生み出すけれど複雑怪奇になっているシステム」を見つけたときには、 「バッドノウハウだ」と批判するだけではなく、 バッドノウハウを隠す「グッドラッパー」を作ることを考えよう、というお話。 目次 はじめに 有益なものを生み出さなければ「奥が深い」とも呼ばれない バッドノウハウをグッドラッパーで隠そう 本当によくないシステムとは よびかけ 補足：Perlとバッドノウハウ いろんな方からのコメント 反応リンク 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに 高林哲さんは『バッドノウハウと「奥が深い症候群」』というページで、 「奥が深い症候群」や「バッドノウハウをありがたがることの危険性」について書いています。 これはもっともな指摘なので、それを受けてもう一歩進んだ話を書いてみましょう。 有益なものを生み出さなければ「奥が深い」とも呼ばれない もしも「奥が深い」システムが何
バッドノウハウと「奥が深い症候群」
計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。 バッドノウハウは、ソフトウェアの複雑怪奇な仕様が歴史的に引き ずられ、根本的な改善は行われないまま、そのノウハウが文書によっ て受け継がれることによって蓄積が進行する。Unix 上で広く使わ れているツールとしてはTeX, Emacs, sendmail, bind, perl, gnuplot, procmail などは、役に立つツールであると同時に、その 複雑怪奇な仕様によって長年に渡ってユーザを苦しめ続け、バッド ノウハウの温床として悪名が名高い。こうしたツー
プログラミングの6大10項目リスト
Jeff Atwood / 青木靖 訳 2007年3月22日 以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。 [ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。] ジェラルド・ワインバーグの｢エゴレスプログラミングの十戒｣ 自分が誤りを犯すということを理解し、受け入れること 。 自分と自分のコードは別物である。 どんなに｢空手｣を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 相談せずにコードの書き直 しをしない。 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 世界で唯一変わらないのは変わるということだけ。 唯
ひげぽん OSとか作っちゃうかMona- - ハッカー養成塾:ハッカーへの遠回り
オープンソースマガジン2007年1月号に向けて書いた記事の元の原稿です。 前回のアルファギーク舘野君から、バトンを渡されたひげぽんです。 Mona OSというオープンソースOSを開発しています。 僕はハッカーと呼ばれるには実力不足ですが、知り合いのスゴ腕ハッカーに少しでも追いつこうと日々実践していることをいくつか紹介します。 ハッカーに学ぶ オンラインでもオフラインでも構いません、自分よりも優れているハッカーを探してお手本とすることから始めましょう。 彼（または彼女）が何を勉強し、発言し、考えているかを観察することで多くのことを学べるはずです。 周りにハッカーがいなければ、勉強会・カンファレンスに参加したり、ブログを利用してコミュニケーションをとるのもひとつの方法です。 「ハッカーに交わればハッカーになる」とまではうまくいきませんが、周りは自分より優秀な人ばかりであるという環境を作り上げる
TOYOTAで考えた、見える化の本質 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。 まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。 今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くの本があるかと思いますので、見える化をキーワードにして
ブログはキャズム（ハイテクの落とし穴）を越えてブレイクするのか？：Goodpic
This shop will be powered by Are you the store owner? Log in here
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
馬鹿の見る夢のなかには馬鹿しか出てこない
うちの会社でときどき仕事を外注の人にお願いすることがある。あるいは、うちの会社でしばらく働いてもらうことがある。そうすると、そういう人たちは「ああ、世間の職業プログラマは、こんなレベルで、こんな質の悪いコードを書いてやがるんだな」という局面に出くわすこともあるだろう。 「こんな奴でも食っていけるんだ」とか「世間のレベルとはこんなものなのか」みたいに一般化して認識する。下手すると自分のblogで「こんなコード許されていいのか」だとか「こいつバカス」とか愚痴を書いてやがる。「ほげほげテクノロジーを使いこなすのは、世間の職業プログラマには無理だろう」だとか書いてやがる。そんなの勘違いも甚だしいと思うんですよ。 あのね。仕事というのは、相手の実力の30〜40%で出来るものを与えるのが正しいマネージメントなのです。相手の力の80%〜120%を出さないと達成出来ないような仕事というのは、その人にお願い
はてなに入った技術者の皆さんへ （jkondoの日記より）
最近はてなの社内では新しい技術を勉強したり、フレームワークや言語を移し変えようかという話も出ていたりして活気が出てきています。技術者も10人を超えて、色々な考え方をする人同士が刺激を与え合いながら切磋琢磨していて素晴らしいなあと思います。そういう中で、僕が技術について思う事を少しまとめてみました。 アウトプットを出す 新しい技術を習得したり、時間を掛けて作り上げた結果は、何かのアウトプットとして出さなければほとんど意味がありません。知識や結果を自分の中に残すだけで終わるのは、それを活かしてサービスを作りたくさんの人が使えるようにする事に比べると驚くほどちっぽけな仕事です。 また、3日間で作り上げた素晴らしい仕組みをそのまま1週間寝かせてしまうのは、4日目に他の人が使えるようにしてから1週間を過ごすことに比べると随分見劣りしてしまいます。 当たり前ですが、どれだけ素晴らしい仕組みを作っても、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
