プログラマの壁 - あどけない話
プログラマに向いている人と向いていない人がいるそうです。 Jeff Atwood さんの「どうしてプログラマに・・・プログラムが書けないのか?」： プログラムを書ける者とプログラムを書けない者の間にある大きな溝についてはよく知られているが、プログラマの職に応募してくる人間は、すでにこの溝を飛び越えているものだとばかり思っていた。明らかにこれは妥当な仮定ではないらしい。プログラムを書けないプログラマの面接で時間を無駄にしないために、FizzBuzzスタイルのふるい分けが必要ということだ。 どんなことでも向き不向きはあるでしょうから、これには納得いきます。しかし、プログラマになれる人の中にも、溝があるようです。 Joel Spolsk さんの「Javaスクールの危険」： 私のささやかな経験から言わせてもらうと、伝統的に大学のコンピュータサイエンスのカリキュラムで教えられているもので、多くの人が
「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan
あるサイトで連載の話を進めていて、そのコンテンツを考えていた。目次を書き出しているときにふと「プログラマ35歳定年説」なるものを思い出した。 プログラマ35歳定年説とは、「プログラマは年齢を重ねて行って、35歳ぐらいになったらSEなりマネジメントなり、次に行かないとオマンマ食べられないよ」というものだ。 「そういえば、自分もそう言われてきたっけ・・・。若いころは「俺たちがシステム作ってんだ！実力があれば絶対に大丈夫。ふざけんな！」と思っていたよなぁ。」 ふと考えれば私は今36歳。その説によれば定年を迎えている年齢だ（笑）。年金はもらえないが・・・。 プログラマ、SE、マネジメント、経営の一通りを経験してきて、その説の私なりの考えを書いてみたくなった。 35歳プログラマ定年説は本当か？・・・私にとって かつては技術力に自信があったし、楽しいプログラマ人生を送ってきた。そんな私だが、今もし誰
CD-ROM に収録したソフトウェア
便宜のために「ライセンス」という項を作りましたが、 ここに書いてあることは信用すべきではありません。 アーカイブやサイトのライセンス原文を読んで自分で確認してください。 ページ内目次 プログラミングツール Windows 用ビルド環境 バージョン管理 プログラム解析ツール 言語処理系 ドキュメント プログラミングツール autoconf バージョン2.54 作者David MacKenzie (original) ライセンスGPL2 サイトhttp://www.gnu.org/software/autoconf/ ファイルautoconf-2.54.tar.gz configure を作るツール。 automake バージョン1.7 作者David Mackenzie, Tom Tromey ライセンスGPL2 サイトhttp://www.gnu.org/software/automake
Geekなぺーじ : プログラマのモチベーションを高める9の事項
「Nine Things Developers Want More Than Money」という記事がありました。 面白かったので要約してみました。 誤訳や勘違いがあるかも知れないので詳細は元記事をご覧下さい。 1. 成功するプロジェクトであること 多くのプロジェクトはそもそも失敗するような計画で行われているという悲しい現実があると書いてありました。 成功の要素として、現実的な納期、安物のツールを使うことを強制されないこと、ろくでもないマネジメント・仕様変更・暗黙の仕様 などを要求する発注先にあたらないなどが重要だそうです。 2. すばらしいマネジメントが行われていること プロジェクトと人の両面ですばらしいマネジメントが行われていることが重要だそうです。 身を挺してチームを守るようなすばらしいマネージャに対してはプログラマはソフトウェアの品質で応えるそうです。 3. 新しいことを学べること
ウノウラボ Unoh Labs: 女性に愛されるプログラマーの7つの要素
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
#1 プログラマーの三大美徳その1「怠慢」
小飼弾です。ご機嫌はいかがでしょうか。 前回の記事では、私がタイトルを決めない理由についてお話しましたが、そうは言っても「プログラマー」というのは立派な肩書(title)の一つでもあります。というわけで今回はプログラマーとしての話題を扱います。 プログラマーには、次の美徳が絶対に必要です。この美徳の一つでも欠く人は、プログラマーとなってはいけません。また、これらの美徳を欠いているにも関わらずプログラマーという職業に就いてしまった人は、今すぐ転職を考えましょう。それくらい重要な美徳です。 怠慢(Laziness) 短気(Impatience) 傲慢(Hubris) 「そんな人はプログラマーに限らず仕事ができないはず」と思ったあなたは「怠慢」で「短気」で「傲慢」な素質があるかも知れません。まずは怠慢から解説します。 「ラクダ本」の愛称で親しまれている"Programming Perl"において
イケてるプログラマになるための10の事柄:Geekなぺーじ
「My Top Ten Tips on how to become a Rockstar Programmer」という記事がありました。 面白かったので要約します。 一部意訳しているので、詳細はリンク先を読んでみてください。 大抵は同意。ただ、後半になるほど人によるかも。 #1 早いコンピュータを使って開発をすべし コンパイル時間を短縮したり、実験的に動かすまでにかかる時間を最小にするためには早いコンピュータが必要です。 それらの時間が短い方が作ったアプリケーションを動かして色々試してみる気になります。 ただ、遅いPCも手元に置いておいた方がいいです。 遅いPCで試せば、GUIなどが重くなりすぎて遅いマシンでは動かなくなっている事とかに気付く事ができます。 #2 大きなTFTスクリーンを使うべし 画面が大きい方が一度に見れるコードの量が増えます。 一度に見られる量が多い方がコードの一部分だ
404 Blog Not Found:Stiffと偉大なプログラマー達-登場人物
2006年09月14日15:45 カテゴリBlogosphere Stiffと偉大なプログラマー達-登場人物 はてブと「本の虫 | これは凄い。とにかく凄い。」経由で。 Sztywny Blog - Stiff asks, great programmers answer At some hot, boring afternoon I got an _Idea_. With the help of public accessible e-mail adresses I asked 10 questions to a bunch of programmers that I consider very interesting people and I respect them for variuos things they created. これ、面白いので少しずつ翻訳してみることに。 特に許
ページが見つかりません | 無料ブログ作成サービス JUGEM
//次のことをお試しください ページアドレスが正しいかをご確認ください ブラウザの更新ボタンをクリックし、ページの再読み込みをお試しください
第11回 プログラマが知らない，デザイナーの苦労
今回は，デザイナーとして，世間やプログラマに対して言いたい放題書かせてもらう。どうか怒らずに最後まで読んでもらいたい。デザイナーの皆さんには，大いに賛同していただける内容になっているはずだ。 デザイナーだって，タイヘンなんだ！ まず，デザイナーという仕事は，非常に誤解されやすい。例えば次のような誤解をうけて，暗い気持ちで日々の作業をこなしているデザイナーも少なからずいるはずだ。 1) デザイナーという職種に対する，先入観がある 世間（顧客やエンドユーザー）には，「すべてのデザイナー」＝「技術に無知」だという先入観がある。「デザイナー」とは「Webページの配色とレイアウトをする人」だから技術を知らなくて当然，むしろ知らなくてよいとする傾向すらある。開発ツールが完全分業に向けて進化しているのだから，デザイナーはビジュアル・デザインのことだけ考えていればいいという意見を持っている人もいるだろう。
プログラマーの格言（盗作多し）
プログラマーの格言（盗作多し） 頼む、９６になるまで盗作を続けさせてくれ プログラマーの格言（盗作多し） 一日は２４時間ある。 今日中という意味は明日の朝までという意味である。 プログラマーの格言２（盗作多し） プログラムは思った通りに動かない。書いた通りに動く。 プログラマーの格言３（盗作多し） 要求仕様はプログラム完成後に完結する。 基本仕様は完成品を顧客が見てから決定される。 詳細仕様は使用者がプログラムを動かしてから固まる。 プログラマーの格言４（盗作多し） 私は、ソフトウェア設計には 二つの方法があるという結論に達した。 一つは、欠陥がないことが明らかなほど単純にする方法である。 もう一つは、明らかな欠陥がないほど複雑にする方法である。 C.A.R.Hoare プログラマーの格言５（盗作多し） コードは開発現場で書くんじゃない！ 納品先で書くんだ！ デバグは納期前にするんじゃない
悪態のプログラマ
ビジネスによくあるシーン。 1. ドキュメントを作る 2. 誰かに見せる 3. 質問される 4. 質問に答える 5. 納得してもらう 例えば、報告書の類とか、我々の仕事なら設計書のレビューなどもそうだ。また、ソースコードのレビューも同じである（以下、「ドキュメント」にはソースコードも含むものとする）。 さて、上記の流れの後でそのまま終わってしまう人も多いのだが、それはよくない。 単純に考えると、質問された内容というのは、「作成したドキュメントから読み取れなかったこと」である。しかも、少なくとも聞き手が質問せずにはおられない程度に「重要なこと」なのである。 そのため、今後、別の人（たとえば上司のそのまた上司）がこのドキュメントを読んだら、同じ質問をしてくる可能性が高い。質問の機会がなければ誤解されてしまうかもしれない。また、説明を受けた人ですら、後になってその内容が思い出せなくなって、違う解
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そんなプログラマは必要ない！優秀なプログラマの8つの条件*ホームページを作る人のネタ帳
http://www.wshito.com/comp/java/index.php?itemid=58