現在、あなたがお使いのブラウザは、Cookie(クッキー)をブロックする設定になっています。 リクナビNEXTでは、個人情報保護と利便性の観点からクッキーの使用をお願いしています(個人情報収集等の目的では使用しておりません)。お手数ですが、ブラウザの設定を変更してください。
現在、あなたがお使いのブラウザは、Cookie(クッキー)をブロックする設定になっています。 リクナビNEXTでは、個人情報保護と利便性の観点からクッキーの使用をお願いしています(個人情報収集等の目的では使用しておりません)。お手数ですが、ブラウザの設定を変更してください。
タイラー・コーエンがMarginal Revolutionの12/23エントリで引用している文章が興味深い。以下がその引用部。 Software output cannot be measured as easily as dollars or bricks. The best programmers do not write 10x as many lines of code and they certainly do not work 10x longer hours. Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the clien
最強最速アルゴリズマー養成講座: そのアルゴリズム、貪欲につき――貪欲法のススメ アルゴリズムの世界において、欲張りであることはときに有利に働くことがあります。今回は、貪欲法と呼ばれるアルゴリズムを紹介しながら、ハードな問題に挑戦してみましょう。このアルゴリズムが使えるかどうかの見極めができるようになれば、あなたの論理的思考力はかなりのレベルなのです。(2010/9/4) 最強最速アルゴリズマー養成講座: 病みつきになる「動的計画法」、その深淵に迫る 数回にわたって動的計画法・メモ化再帰について解説してきましたが、今回は実践編として、ナップサック問題への挑戦を足がかりに、その長所と短所の紹介、理解度チェックシートなどを用意しました。特に、動的計画法について深く掘り下げ、皆さんを動的計画法マスターの道にご案内します。(2010/5/15) 最強最速アルゴリズマー養成講座: アルゴリズマーの登
[edit] カリフォルニア 2007年10月5日 [edit] FogBugz On Demand 2007年7月9日 [edit] マネジメントの本 2007年6月29日 [edit] 記憶に残るようなカスタマサービスへの7ステップ 2007年2月19日 [edit] ファウンダーズ アット ワーク 2007年1月30日 [edit] Copilot 2.0リリース! 2007年1月26日 [edit] ビッグピクチャー 2007年1月21日 [edit] 新年の抱負: もっといい仕事につくこと! 2006年12月20日 [edit] 50万件のバグ! 2006年12月20日 [edit] 新作! 2006年12月18日 [edit] エレガンス 2006年12月15日 人々がソフトウェアをいじるのは、多くの場合、それで遊びたくてそうしているわけではない。彼らがソフトウェアを使うの
以下の文章は、Peter Norvig による Teach Yourself Programming in Ten Years の日本語訳である。 本翻訳文書については、以下の方々にご教示を頂きました。ありがとうございました。 Shiro Kawai さん:誤訳の訂正 三好博之さん:誤訳の訂正 竹中明夫さん:2001年7月改版分の訳、誤訳の訂正(共訳者にクレジット) Toshihiko Ono さん:誤訳の訂正 アクビさん:訳注3に関する情報 どうしてみんなそんなに急ぐの? どの本屋に足を運んでも、『7日で学ぶ Java』といったハウツー本を見かけるし、そのそばには Visual Basic や Windows やインターネットなどについて、同じように数日や数時間で学べると売りこむ本が無限のバリエーションで並んでいる。Amazon.com で以下の条件で検索してみたところ、 pubdate
ポール・グレアムのエッセイと和訳一覧 (originally maintained by naoya_t) Paul Grahamのエッセイ(原文)と、公開されている日本語訳のリストです。 見つけたら or 訳したら、自由に追加して下さい。複数の訳が存在する場合は全て追加してください。 Writes and Write-Nots 書く者と書かざる者 (spinute) Founder Mode 創業者モード (spinute) The Reddits Reddit の創業者たち (spinute) What You (Want to)* Want あなたが(望むことを)*望むこと (spinute) Alien Truth エイリアンの真実 (spinute) How to Start Google Googleのはじめ方 (yomoyomo) How to Get New Ideas 新
どのくらいの人がこのブログを読んでいるか分かりませんが、 もし、勉強が出来ない人が周りにいたら、このブログを紹介してあげてください。 ふと 勉強が出来ない人は、プログラマになったほうがいいと思った。 僕はというと 自分でも驚くくらい勉強というものが出来ない。ものごとを知らない。 はっきり言ってバカなのである。 たとえば、 大学行ってない。 株式公開と上場の違いを知らなくて、一同ぽかーん。 つい最近まで、サイバーエージェントを知らなかった。(技術者には必要ない) 英語が一切読めない。 宮崎料理「冷や汁」を「冷や飯」だと思ってた。 基本的に会議とかでよく出る英語、「さじぇっしょん」とか、「あさいん」とか、「ぶらんでぃんぐ」とか、「うぇぶつーぽいんとおー」とか、よく分からん。 人力(じんりき)検索を入力(にゅうりょく)検索だと思っていた たぶん、まだまだあるけど、自分がバカだから気がつかないんだ
Steve Yegge / 青木靖 訳 2004年9月 これは駆け足の言語案内だ — Amazon Developers Journalのために今月書いていたのだが、どうもこれを見苦しくないようにする方法を見つけられなかった・・・。 ひとつには、私はどうも粗野で口汚くなりがちで、オフィシャルな趣のあるAmazonの出版物に載せるのは不適切に思えた。それでかわりに誰も読まない自分のブログに押し込めてしまうことにした。読んでるのはあなたくらいのものだよ。どうも! もうひとつ言うと、これは本当に書きかけのものであり、そこかしこの断片を集めたものでしかない。全然磨き上げられていない。これもブログエントリにする理由になっている。ブログなら別に良質である必要も完全である必要もない。単に私が今日考えたことというだけのものだ。ではお楽しみを! この駆け足の案内では、C、C++、Lisp、Java、Perl
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 by chazmatazz 「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか?」という質問を受けたので、「はて?どうしているだろうか?」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。あ、Pythonに限定してますが、他の言語でも似たようなものはあると思いますので、脳内変換をお願いします。 事前の設計はしません 「こういう処理が必要」「こういう計算しなきゃね」みたいなロジックや「要件はこうかな?」ということは事前に考えたりするけど、クラス構造とかは基本的に考えないで手をつけます。そして、ある程度規模が大きくなって「あ、ちょっとこの関数大きすぎて理解しにくいなぁ」と
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 taken by Manuel_Marin なんとなく書いたら、アクセス数が10000件超えたソースコードをきれいに書くための方法の記事。r-westさんの「きれいなソースコードを書くために必要な、たったひとつの単純な事」と、uwiさんの「誰がためのきれいさ?」と、フォローのトラックバックまで頂きました。僕のも含めてそれぞれスタンスが違いますが、どれが正しいとか、どれが一番いいかというのはないと思っています。人によってどっちがいいかは別れるはずです。人によっていちばん苦労がなくて、モチベーションがあがる方法がそれぞれの人にとっての正解である、というのが僕の考えです。 モチベーションマネージメントというのがよく言われるけど、「モチベーションを上げろ」と言われて上がる人なんていませ
2009年04月24日12:00 カテゴリArt プロが独り立ちするためのたった一つの条件 というわけで、期待にお答え。 新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く はてなブックマーク - 新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く s/プログラマー/プロ/g しても使えます。 天才!:成功する人々の法則 Malcolm Gladwell / 勝間和代訳 [原著:OUTLIERS] 一万時間続けよ なんと簡単で、なんと難しい条件。 これを指摘しているのが、Gladwell の"OUTLIER"。邦訳は5月13日発売なので、詳評はもう少し後に上げる予定なのだけど、あえて一言でまとめると、「才能は、授かるものではなく培うものだ」ということ。そして、その「天才」が独り立ちできる
普通のやつらの上を行け ---Beating the Averages--- 著者:Paul Graham Copyright 2001 by Paul Graham これは、Paul Graham: Beating the Averages を、原著者の許可を得て翻訳・公開するものです。 プロジェクト杉田玄白正式参加テキスト。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2001 by Paul Graham 原文: http://www.paulgraham.com/avg.html 日本語訳:Shiro Kawai (shiro @ acm.org) <版権表示終り> 文中、Eric Raymondの "How to bec
mumurik 氏に指摘による、ひげぽんがプログラマとして最低限身につけるべき知識シリーズ。 データベースの内部構造 Database Management Systems 参考:index nested loop joinのコスト計算くらいプログラマは出来るべきだ。 ブラウザ 3DのGPU Real-Time Rendering ストライプやファンとかrendering pipelineみたいなの WPF Windows Presentation Foundation WCF Windows Communication Foundation 最近のIDEの機能 モデリング 最近の並列の話 本なら並列Java .NETならCCRとかPPLとかか? あとはトランザクショナルメモリとか。 まぁ今は並列Javaあたりだけ読んどいて2〜3年後にキャッチアップでいいかも トランザクション周り 月並み
この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく
プログラミングを勉強するときに、本とかドキュメントを読んで一ページ目から順に勉強する人が多い。 たしかに、これもいい勉強方法の一つだとは思う。 でも、僕はこれが苦手だ。 楽しくない。 だから、僕は目的を分割して必要な部分だけ飛び飛びに学んでいる。 ジグゾーパズルを作るみたいな感じ。 ジグゾーパズルを作るときに左上から一個ずつ探していたら時間がかかってしょうがない。 必要なところから評価(具現化)するというところは、遅延評価的なのかなとか思った 厨二病だな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く