プログラマが好きそうな読み物100
► 2022 (2) ► 10月 (1) ► 2月 (1) ► 2021 (51) ► 11月 (2) ► 10月 (2) ► 9月 (4) ► 8月 (4) ► 7月 (4) ► 6月 (4) ► 5月 (3) ► 4月 (10) ► 3月 (7) ► 2月 (4) ► 1月 (7) ► 2020 (155) ► 12月 (7) ► 11月 (10) ► 10月 (8) ► 9月 (8) ► 8月 (11) ► 7月 (21) ► 6月 (19) ► 5月 (14) ► 4月 (20) ► 3月 (13) ► 2月 (10) ► 1月 (14) ► 2019 (293) ► 12月 (11) ► 11月 (12) ► 10月 (24) ► 9月 (29) ► 8月 (27) ► 7月 (36) ► 6月 (40) ► 5月 (24) ► 4月 (35) ► 3月 (42) ► 2月 (6
ネットサーフィン（死語）をしていて、プログラマなら誰でも楽しく読めるハズ！ と思ったサイトや記事を紹介して行きます。 とりあえず、Vol.1ッ！ ハッカーになろう (How To Become A Hacker） 実は、この5つすべて（Python, Java, C/C++, Perl, LISP）を勉強しておくのがいちばんいいのです。 これらはもっとも重要なハッキング用言語だというだけでなく、 それぞれプログラミングに対してまったく違ったアプローチをしているので、どれも非常に有益な勉強となるでしょう。 Rubyは？（´・ω・｀）ｼｮﾎﾞﾝ Fine Software Writings 特に僕が好きな記事を！ ホワイの(感動的)Rubyガイド (why the lucky stiff) どうしてプログラマに・・・プログラムが書けないのか? (Jeff Atwood) ソフトウェア開発者のた
最近，WebアプリケーションやWindowsソフトの取材で，“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフトや趣味のソフトではなく，会社が商品として提供し，不特定多数のユーザーが使っているアプリケーションを一人で作って，一人でメンテナンスしているという点に興味を覚えた。 先週都内で開催された開発者向けイベント「ITpro Challenge!」でも，ドワンゴの戀塚昭彦氏がニコニコ動画を一人で（しかも3日間で）作ったと語っていた（関連記事）。よく考えてみれば，ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても，企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。 アプリケーションの規模や内容，また開発者のスキルにもよるだろうが，おおむね一人で開発するほうが， ・低コ
昨日MIJSのコンソーシアム内での技術発表会があり、理事会の方から「参加ベンダーの技術者が集まるイベントなので、技術者に元気を与えられるような人に講演をお願いしたい」という話があったので、はてな伊藤さんに講演をお願いした。 伊藤さんにお願いしようと思ったのは、伊藤さんなら、エンタープライズの世界にウェブの世界の元気な風を吹き込んでくれるのではないかと思ったからだ。 以下、私なりに講演の内容をまとめてみた。 ■「建物の建て方」 つくる対象がどのようなものかで、作り方は当然変わってくる。これは建物もソフトウェアも同じ。1階建ての格好良い小さなロッジを建てるのと、60階建ての安全で高品質な巨大ビルを建てるのとは方法も道具も異なる。ロッジを建てる時にはノコギリを使うが、巨大ビルを建てるにはクレーンを使う。 よくブログの世界でソフトウェアの開発について、ぜんぜん違うことをやっている人が同じ土俵で議論
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
ハッカー傾向のある人々は、正直あまりビジネス向きではないように思います。しかし、いくらハッカーでも、霞を食べて生きていくわけにはいきません。そこで今回は、ハッカーの仕事生活を紹介しましょう。 ハッカー傾向のある人々は、正直あまりビジネス向きではないように思います。なにしろ彼らの美徳は「不精」「短気」「傲慢」ですし、好きなことにはのめり込むタイプですが、逆に嫌いなことはあまり我慢しないかもしれません。しかし、ビジネスとはそんなに甘いものではないはずです。 ハッカーも人間です。眠たくもなれば、お腹も空きます。いくらハッカーでも、霞（かすみ）を食べて生きていくわけにはいきません。そこで今回は、ハッカーの仕事生活を紹介しましょう。もっともわたしの周辺のごく限られたサンプルからの情報なので、独断と偏見があることはあらかじめご了承ください。 論文や卒業がネック ハッカーが多く見受けられるのは、やはり大
新入生や新社会人として組織に入ったり、他の組織から畑違いの場所に異動すると、ゼロからのスタートになるときがあります。 そのときに、先輩からいかにして技術を「盗む」かが重要な要素になると思われます。 ここでは、自分の養分として吸収するために、先輩から技術を引き出す一手法を紹介したいと思います。 先輩から見て教え易い後輩や、ついつい必要以上に色々教えてしまう後輩などがいます。 今回は、そのような人の特徴を考えたり、過去の私が失敗したと思われる点を思い出しながら書いてみました。 ここで紹介する方法は、あくまで方法の一つであり偏っています。 性格によって向き不向きがあると思います。 また、あまりに露骨にやり過ぎると嫌われてしまう場合もあるのでご注意下さい。 あまり参考にはならないかも知れませんが、まあ、許してください。 やる気を見せる 非常にやる気があって、色々やっている人を見るとついつい応援した
404Error - Page not found ご指定のファイルが見つかりませんでした 30秒後にトップページへ移動します
「直感を信じろ、自分を信じろ、好きを貫け、人を褒めろ、人の粗探ししてる暇があったら自分で何かやれ。」を書いてから二週間。休暇で海外に出ていたのでしばらくこのブログを更新できなかったが、その間の膨大な反応も、帰国してから全部読んだ。 僕の本やブログをずっと読んでくれている人には「言わずもがな」かもしれないけれど、あの短いエントリーを単体で読むだけだと誤解を招くだろう部分が「好きを貫く」ことの難しさ、厳しさだ。 人生の幸福とは「好きを貫いて生涯を送ること」だと僕は思っている。「好きを貫いて生涯を送ること」は素晴らしいことだ。人からどう見えるとか、他人と比較してどうこうという相対的基準に左右されるのではなく、自分を信じ、好きを貫く人生を送ること。本当の幸福とは、そういう心の在り様にこそあると、僕はそう信じているから、若い人達に、そんなに簡単に「好きを貫く」ことを諦めてほしくない。でも「簡単だから
近ごろプログラマーかいわいで、「関数型プログラミング言語」という言葉をよく耳にするようになった。本連載では、プログラミング言語を取り巻く状況をあらためて俯瞰し、プログラミング言語開発の現場で何が起こっているのかを解説する。 はじめに 「ガーベジコレクション」、「リフレクション」、「アスペクト指向」、「クロージャ」、「イテレータ」、「型推論」など、近年、プログラミング言語の世界に新しい概念が続々となだれ込んでいるように見えます。しかし、これら「プログラミング言語の新潮流」の背景には、実はあまり知られていない歴史が隠されているのです。 プログラミング言語のメインストリーム プログラミング言語はお互いに影響を与えながら成長しています。プログラミング言語の歴史において、主要な言語がどのように影響を与えたかを、概略図に示しましょう（図1）。スペースの関係上この図では非常に簡略化しています*が、実際に
週明けコラムです。こんばんは。 少し前までは「PS3 vs Wii」という話題だったゲーム機業界ですが、 今では「取り上げられるWii」と「取り上げられないPS3」という なんともいえない状況に変わってきています。 数の上ではPS3の出荷はどんどん積みあがっています。 Wiiの100万台に対して、PS3は50万台 という出荷数を聞けば「えっ？」と思う方も多いでしょう。 「Wiiの半分『も』出ているの？」と思わず聞き返してしまうほど、 私たちの耳には 「PS3で楽しく遊んだ体験談」 が聞こえてきません。 出荷台数は黙々と積みあがっているものの、エンドユーザの中に於ける WiiとPS3の 「位置付け」 の差は、それ以上に大きなものになっていると 想像しています。iPodとウォークマンのように。DSLiteとPSPのように。 どうして劣勢側が全部Sonyなのだというツッコミはナシの方向で。 こう
ウェブ人間論 梅田 望夫 / 平野 啓一郎 梅田望夫と平野啓一郎の対談集である「ウェブ人間論」を読了した。基本的な感想は、この書籍の元になった新潮に対談が掲載されたときに「新潮６月号の梅田望夫×平野啓一郎の対談を読んで」にもすでに書いたし、ここやここでは平野啓一郎本人が登場するというハプニングがあったことも記憶に新しいところだ。その後に平野はほんとうに公式ブログを開設したりもした。これら一連のできごとは、とても楽しいものだった。 だけど、いやだからこそ、この件を引っ張る形でこれ以上書評を続けると知人友人ばかり持ち上げる内輪やらせブロガー的なダークサイドに堕ちてしまう気がするので、この機会に大きく踏み外してみようと思う。 ぼくが今の今まで注意深く避けてきた、グーグルの技術論について、この機会にとうとう語ってしまおうと思う。 ■「過去7年におけるグーグル成功の最大の要素は『運』だった」（Se
社会生態学者、ピーター・ドラッカー氏が2005年11月11日に亡くなってから早くも1年が経った。この1年の社会の動きは目まぐるしかったが、変化が激しい時こそ、本質をつくドラッカー氏の言葉に耳を傾けるべきではないだろうか。こう考え、ドラッカー氏とのロングインタビューの記録をひもといてみた。 幸いにも、私はこれまで3度、ドラッカー氏にロングインタビューする機会に恵まれた。最初のインタビューは1997年のことだったが、当時のメモを見直してみると、現在に通じる示唆的な発言が満載されていた。1999年の2度目、2003年の3度目のインタビュー内容もまったく古びていなかった。 ドラッカー氏の魅力はたくさんあるが、何と言っても、物事をとらえるスケールにはインタビューのたびに圧倒された。現在起きている事象を読み解く際に、こちらが予想もしていなかった歴史上の逸話を持ち出し、それらを対比して、目からうろこ
「Nine Things Developers Want More Than Money」という記事がありました。 面白かったので要約してみました。 誤訳や勘違いがあるかも知れないので詳細は元記事をご覧下さい。 1. 成功するプロジェクトであること 多くのプロジェクトはそもそも失敗するような計画で行われているという悲しい現実があると書いてありました。 成功の要素として、現実的な納期、安物のツールを使うことを強制されないこと、ろくでもないマネジメント・仕様変更・暗黙の仕様 などを要求する発注先にあたらないなどが重要だそうです。 2. すばらしいマネジメントが行われていること プロジェクトと人の両面ですばらしいマネジメントが行われていることが重要だそうです。 身を挺してチームを守るようなすばらしいマネージャに対してはプログラマはソフトウェアの品質で応えるそうです。 3. 新しいことを学べること
そろそろ実際の会議の現場に入っていきましょう。ただし「では早速──」などと議論に入ってはいけません。会議をスムーズに進めるには、会議冒頭の手順が重要なのです。 前回は、会議のゴール設定とリマインドの仕方を紹介しました。 ちゃんとリマインドをしたことで、会議室には時間通り参加者全員がそろっています。ここで「では早速──」などと言って、いきなり議論を始めてはいけません。誰しも長い会議は嫌なものですよね。長い会議、終盤に迷走する会議を防ぐためには、会議の最初に時間管理をしておくことが重要です。 プラクティス4──時間管理（time management） 時間管理は、会議のファシリテイション（議事進行技術）で最も難しいものの1つです。しかし会議の最初にきちんと手順を踏むことによって劇的に改善します。その手順は以下の5つです。 会議のゴールの確認 会議の終了時刻の確認 ToDoの見直し スケジュー
“議事録ドリブン”を実行する上で、最初のチェックポイントは「会議のゴール」だ。今会議に参加しているあなた、この会議のゴールを知っていますか？ 今回説明するのは、議事録に書かれていなくてはいけない最初のポイント──会議のゴールです。もしあなたの参加する会議で、会議のゴールが何かを誰も最初に聞かないようならば、その会議の半分は失敗することでしょう。 プラクティス2──ゴールの共有（shared goals） まずは私の体験談から。私は、最初に入社したとあるスタートアップの会社で、入社2カ月でいきなりプロダクトマネージャを任されました。プロダクトマネージャは、関係各位との意見交換や調整が仕事のようなものです。開発と営業の双方から、山のような要望が私のところに投げられてきます。しかもまだ製品は発売されていないのです。 そういったテンテコ舞いの状況の中、私は当時の社長と会議をセッティングしました。彼
前回の記事では、「会議が迷走する」「会議が決まらない」「会議で決まったことが実行されない」「会議が長い」の四重苦のスパイラルが、多くの会議が共通に抱えている問題だと分析しました。 なぜ会議の生産性を上げたいのでしょうか。もう一度、胸に手をあてて考え直してください。それは、あなたのプロジェクトが何か素晴らしいことを達成したいからに違いありません。もしそうした気持ちをあなたや、あなたのプロジェクトのメンバーが持っていないのであれば、会議の生産性を上げて短時間で会議が終わっても、結局ほかのところで無駄が発生するだけのことでしょう。経営者や管理者は会議時間が長いことを嘆きますが、問題は本当に会議の時間が長いことなのでしょうか。会議の時間を短くしたくなるほど、社員がその仕事に熱心に取り組んでいないことがより問題なのかもしれません。 会議術によって改善できるのは、何かを達成したいと信じている人たちの気
ほとんどの人が会議が嫌いではないでしょうか。何のための会議か分からない、決まったことが実行されない、そもそも会議時間が長い……。そんな非効率な会議の原因を明らかにするとともに、解決法を探っていきましょう。 長い会議に嫌気がさしたことはないでしょうか。 問題は会議が長いことだけではなかったはずです。明らかに非効率な会議が、不条理に長く続いていることにイライラしたのではないでしょうか。 そもそも「何のためにメンバーが集まったのか」が共有されていないまま会議が始まる。いざ議論が始まると、そもそも何についての議論しているのか誰も分からなくなってしまう。それでも会議が続けられ、予定時間を大幅に過ぎたところで結論があいまいなまま会議が打ち切られる。会議中に決まったToDo（やるべきこと）もいつの間にか忘れられ、次の会議でまた同じToDoが発行される。最終的には、会議がなぜうまくいかないのかを話し合う会
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
