はてなブックマーク

• あとで読む

  『インデントについて考える　後編』

  3 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 タブが表現する幅は、環境によって違う。プログラマはそのことをよく認識し、タブの幅（桁数の設定）が変わっても、なるべくインデントが崩れないようにソースコードを書くべきである。それがソースコードの「読者」に対するマナーだろう。 といっても、それほど難しいことではない。一部の例外を除き、基本的にはスペースとタブを混在させないようにすればよい。 例えば、インデントが４桁の行はスペース、８桁の行はタブを使うといったことはよくない。タブが８桁（程度）であることを「読者」に強要するからである。 また、１行のインデントの中にタブとスペースを混在させるのもよくない。幅が固定のものと可変のものを

  • テクノロジー
  • 2012/04/13 23:36

  • programming
• あとで読む

  『質問の答えを書く』

  8 users

  ameblo.jp/argv

  ビジネスによくあるシーン。 1. ドキュメントを作る 2. 誰かに見せる 3. 質問される 4. 質問に答える 5. 納得してもらう 例えば、報告書の類とか、我々の仕事なら設計書のレビューなどもそうだ。また、ソースコードのレビューも同じである（以下、「ドキュメント」にはソースコードも含むものとする）。 さて、上記の流れの後でそのまま終わってしまう人も多いのだが、それはよくない。 単純に考えると、質問された内容というのは、「作成したドキュメントから読み取れなかったこと」である。しかも、少なくとも聞き手が質問せずにはおられない程度に「重要なこと」なのである。 そのため、今後、別の人（たとえば上司のそのまた上司）がこのドキュメントを読んだら、同じ質問をしてくる可能性が高い。質問の機会がなければ誤解されてしまうかもしれない。また、説明を受けた人ですら、後になってその内容が思い出せなくなって、違う解

  • テクノロジー
  • 2010/12/05 11:43

  • 開発
  • システム
  • IT
  • ブログ
• あとで読む

  むやみに頑張らないこと｜悪態のプログラマ

  26 users

  ameblo.jp/argv

  誰かに仕事をお願いするときに、「頑張ります」という返事をされるのは好きではない。頑張らないとできないのかと思うと、不安だからだ。できれば、頑張らずに涼しい顔で遂行してくれる人を探したい。 頑張るための余力は何かトラブルがあったときなど、いざという時にとっておいて欲しいのである。もし、依頼した「100 の仕事」に対して、110、120 の結果を出すために頑張ってくれるというのなら嬉しいが、それなら黙って頑張って欲しい。 「頑張ります」という言葉を使うとしたら、「100 の仕事は無理ですが、なるべく 100 に近づけるように頑張ります」といった文脈になるだろう。「95 までの完了は約束しますが、98 を目標に頑張ります」など、具体的な達成内容まで明確にできれば理想的だ。 ★ 「あいつはいつも頑張っている」という言葉は、「100以上」を目指して頑張っているのなら褒め言葉である（「仲間の仕事まで手

  • テクノロジー
  • 2010/04/12 02:02

  • 考え方
  • 仕事
  • work
  • ブログ
• あとで読む

  『あなたにもできること』

  5 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 私はいつも「読みやすいコードを書け」と言っている。そのためにできることは、決して難しいことばかりではない。 例えば、次のようなソースコードをみると、いつも思うのだ。 private static final String DATA[][][] = { {"ringo","gorira","rajio","ondanka","kaimenjoushou"}, {"5","5","4","7","12"}, {"K100","J1","U200","X203","W9800"} }; どうして、こんな風に揃えて書かないのだろうか？ private static final Str

  • 暮らし
  • 2010/03/05 17:20

  • Programming
  • プログラム
  • Life
• あとで読む

  『低レベルなプログラミング』

  10 users

  ameblo.jp/argv

  「低レベルなプログラミング」と聞いて、どういうものをイメージするだろうか。プログラマとそうでない人では、答えが違ってくるのではないだろうか。 一般の人には、「誰でもできそうな簡単なプログラミング」、あるいは「質の悪いプログラミング」といった意味にとられるかもしれない。 しかし、プログラミングについての文脈で「低レベル」といわれる場合は、通常は「ハードウェアに近い」という意味である。つまり、「低レベルなプログラミング」とは、「ハードウェアが理解する言葉」に近い（たとえばアセンブラのような）言語を使ったプログラミングだとか、直接ハードウェアに命令を送って制御するようなプログラミングのことである。 このハードウェアとの「近さ」は測定できる類のものではないが、プログラマ（あるいはその周辺の業界人）は、なんとなく了解していると思う。このブログの「スキルアップのためにラップを剥がしてみる」というエント

  • テクノロジー
  • 2009/05/05 01:53

  • プログラミング
• あとで読む

  『サンプルコードで語る難しさ』

  6 users

  ameblo.jp/argv

  プログラミング入門者のための教材として、「カレンダーを表示するプログラムを作れ」という課題がある。この課題に対して「カレンダーなんて OS に付属しているのに、なんでそんなもの作るんですか？」という人がいる。なんという的外れな意見だろう。言うまでもなく、勉強のために作るのであって、使いたいから作るわけではない。 これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「本来の意図が伝わっていないな」と思うことは日常茶飯事である。 ★ CodeZine の「コーディングスタイルの常識をぶち壊せ」という記事のコメントや「はてブ」のコメントを読んでいて、改めて感じた。 この記事の２つ目のサンプルソースについて、「こんな用途に switch は使うべきでない」とか、「配列を使ったほうがよい」などというのは野暮である。「常識」的に考えて、この記事の著者も他の読者もそんなこと

  • おもしろ
  • 2008/11/25 13:40

  • programming
  • プログラム
  • プログラミング
  • neta
• あとで読む

  『できること、できないこと』

  14 users

  ameblo.jp/argv

  「こういうことができるか？」といった質問を受けることがある。質問する方は簡単なのだが、答えるのは難しい。何かが「できる」ためには、いろんな要因があるからだ。 ・理論的にできる／できない ・技術的にできる／できない ・時間的にできる／できない ・費用的にできる／できない ・感情的にできる／できない など。 ソフトウェア開発者の中には、理論的・技術的な可能性にしか注目しない人がいる。例えば、「既存のシステムにこんな機能を追加したいが、可能か？」という質問があったとする。それが、システムの仕様として矛盾がなく、実装方法が頭に浮かぶようなら、「できます」と答えてしまう。 しかし、ほとんどの仕事には「いつまでに（納期）」「いくらで（予算）」など、他の条件があるはずだ。質問者と回答者の間で、そうしたことが全く話題にならなかったとしたら、誤解が生じている可能性がある。回答者は多忙で寝る時間もない状態なの

  • 暮らし
  • 2008/10/27 01:37

  • *
  • work
  • 開発
  • programming
  • 仕事
• あとで読む

  『コピー指向プログラミング』

  99 users

  ameblo.jp/argv

  以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。 そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。 アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想

  • 暮らし
  • 2008/09/28 07:28

  • programming
  • プログラミング
  • development
  • 開発
  • it
  • tips
  • プログラム
• あとで読む

  『Ｖモデル』

  5 users

  ameblo.jp/argv

  受託開発プロジェクトの終盤、ユーザーテスト（受け入れテスト）などと呼ばれる検証が始まると、当初の要件を覆すような「仕様変更」が発生するものだ。 システムの要件定義（要求分析）は依頼者（顧客）と開発者が共同で行うものであり、漏れがあったとしても、どちらが悪いとも言い難い場合も多い。例えば、開発者の考慮不足とも言えるが、顧客側の情報提供が不足とも言えるというようなことだ。しかし、顧客は「金を払って依頼している」という意識が強いためか、開発会社の責任で修正させようすることも多い。 開発会社もある程度は折り込み済で、「手戻り」の時間を確保しているものだ。しかし、なにしろリリースまでの時間が残り少ない時のことである。「手戻り」の規模によっては間に合わないケースも多く、顧客との関係が悪化することもある。 開発者が「しかし、当初のお話では・・・」などと反論しようものなら、「こっちは客だぞてめえ」ぐらいの

  • テクノロジー
  • 2008/08/18 23:13

  • プログラム
  • software
  • development
  • 仕事
• あとで読む

  『紐付く』

  8 users

  ameblo.jp/argv

  中学生の頃だったろうか、「サボる」という言葉を漢字で書こうとして辞書を引き、はじめて「サボタージュする」の略だということに気がついた。ずっと純粋な日本語だと思っていたので驚いた記憶がある。日常的に使っている言葉は、昔からあったかのように思ってしまうものだが、意外に新しいということがある。 ★ この業界では「ひもつく」という言葉がよく使われる。個人的には「ひもづく」と言う方が多いのだが、同じものだろう。データ構造に関する文脈などで、「繋がっている」、「関連している」といった意味でよく使う。たとえば、「従業員のデータは部門コードで部署マスターにひもづいている」という具合である。 しかし、この言葉、メールに書こうとすると漢字変換できない。辞書で調べても出てこない。実は、最近生まれたいわゆる「オトナ語」なのである。仕方がないので「繋がっている」とか「リンクしている」などに置き換えてみるが、文脈によ

  • 学び
  • 2008/07/07 08:22

  • 言葉
  • word
  • 気になる
  • 日本語
  • communication
  • business
• あとで読む

  ブログ記事一覧｜悪態のプログラマ

  3 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。

  • テクノロジー
  • 2008/06/18 01:06
• あとで読む

  ToDo リスト | 悪態のプログラマ

  4 users

  ameblo.jp/argv

  ちょっとした仕事（タスク）を忘れてしまう人が意外に多い。ToDo リストのようなものを作って、管理すればいいだけのことなのだが。 上司から ToDoリストを作るように言われ、数日の間、「今日のタスクは ToDo リストを作ることであります」などと言っていたが、結局できなかったという人もいた。やるべきことが発生したら追加するというだけのもののはずなのに、このように気合いを入れて作ろうとするのもおかしな話である（最初に作る時は、抱えているタスクを列挙するのに時間が必要かもしれないが、それでも何日もかからないだろう・・・）。 ★ ToDo リストを作るといっても、色々な方法がある。この業界では、PC や携帯端末など電子的なツールを使う人も多いかもしれないが、私の場合は「紙とペン」である（しかも、今のお気に入りはルーズリーフと万年筆という懐かしい組み合わせだ）。 基本的には普通に「やるべきタスク」

  • テクノロジー
  • 2008/06/09 13:00

  • !GTD 資料(いつか読む)
  • programming
• あとで読む

  悪態のプログラマ | 通のツール

  4 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 私がパソコンを使う際には、マウスではなくポインティング・スティック（トラックポイント）を愛用している。会社のデスクトップ・パソコンにも、それが付属したキーボードを個人的に購入して繋いでいるくらいである。しかし、ポインティングスティックを搭載したノート・パソコンは種類が少なく、残念な限りである。 ポインティング・スティックがその機能性の割に普及しないのはなぜか。製造コストの問題もあるが、それよりも「とっつきにくい」ということのほうが重大なように思う。トラックポイントの開発担当者は「10分も使えばなれる」と言うが、店頭で10分も触る人がいるとは思えない。ThinkPad を購入し

  • テクノロジー
  • 2008/05/07 09:26

  • pc
• あとで読む

  『感情の行き違い』

  3 users

  ameblo.jp/argv

  技術者同士でシステムの設計方針などについて話していると、白熱してしまうことがある。お互い、声も大きくなってしまっているのだろう。傍から見ていると、喧嘩でもしているかのように見えるらしい。後から「あの人とやりあってましたね」などと言われるが、なんのことか分からない。本人たちは議論を楽しんでいるくらいなのだ。 会議の議事録でも、そういう誤解が起こりやすい。終始和やかな雰囲気の会議だったはずなのに、後から議事録を読むと、言い争いをしていたかのような印象を受けることがある。会議中、相手に気を使って、わざわざ婉曲な表現で話したのに、断定的な文章になって残されてしまったりする。 会議に出席している人が読むだけなら、大きな問題はないのだが、出席していない人に誤解され、いらぬ心配をさせたりすることもある。 議事録を書く人の力量にもよるが、ビジネス文書の形で、会議の雰囲気まで伝えることは容易ではない。 もっ

  • 暮らし
  • 2008/04/14 01:51
• あとで読む

  『ドキュメント内のリテラルにも注意』

  15 users

  ameblo.jp/argv

  というように、決まった値を持つようなもの（名義尺度や順序尺度 ）である。 プログラミングでこうした値を扱う場合は、数値やコード値をそのまま（リテラル ）では記述せず、定数を定義して、それを使う。あるいは、「列挙型 」を扱える言語であれば、そちらを使う。 ソースコードが読みやすくなるのはもちろん、数字と「意味」の対応が変わった時に、定義だけを変えれば対応できるからだ。例えば、途中に新しいステータスが挿入されて後ろの数字がずれたとしても、既存のソースコードには影響しない（もちろん、挿入したステータスを使う必要がある箇所は別だし、新しいステータスの追加により「意味」が微妙に変わったりすると、修正が必要にはなるが）。 これはプログラマにとっては基本的なテクニックであり、初心者の書いたコードでもそうなっていることがほとんどだろう。

  • テクノロジー
  • 2008/03/10 09:42

  • ドキュメント
  • 開発
  • *
  • 本
  • あとで読む
• あとで読む

  『車輪を発明しようとする前に』

  8 users

  ameblo.jp/argv

  プログラミングをしていて、何か機能が必要になったとき、「こういう機能は既に誰かが作っているのではないか」と考えてみることは重要である。そういう発想がないと「車輪の再発明」をしてしまう。何でも自作しないと気がすまない人もいるが、既に安定して動くコードやライブラリがあるのなら、それを流用した方が効率がよいことは言うまでもない（プログラミング自体の勉強が目的なら別だが）。 もちろん、事前に、既存のコードやライブラリを探す場合と自作する場合とで、どちらが時間が掛かりそうかを判断する必要がある。 そのためには、自分のプログラミング能力と、調査能力を把握しておかなければならない。調査能力については、ネットの「検索力」も重要だが、周囲の人や掲示板等への「質問力」なども影響する。 そして、もっと重要なのは、探そうとしている処理のニーズ（一般性と言ってもいい）を見極めることだ。多くの人が必要としそうな処理な

  • テクノロジー
  • 2008/02/03 00:19

  • 開発
  • プログラミング
  • 仕事
  • プログラム
  • programming
• あとで読む

  『スキルアップのためにラップを剥がしてみる』

  9 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 仕事で会計関連のバッチ処理を設計しているところなのだが、機能のほとんどが数値を操作するだけのいわゆる業務ロジック（ビジネスロジック）なので、ちっとも面白くない。そういえば、WEB+DB PRESS Vol.38 の特集に、「"業務ロジックしか書きたくない人" のための書かない技術」というタイトルを見て、違和感を感じた記憶がある。 もちろん、このタイトルの意味は理解している。「業務ロジック」というのは、ユーザーの業務に特化した処理である。そのため、それぞれのシステムによって処理内容が違い、その都度新しく処理を「書く」必要がある。一方、業務ロジック以外の部分は、どのシステムでも似

  • テクノロジー
  • 2008/01/07 00:46

  • programmer
• あとで読む

  『書き込まれる資料作り』

  11 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 このところ、私が仕事中に一番よく使うペンは「フリクションボール 」だろう。パイロットの「消せるボールペン」である。鉛筆代わりに気軽に使え、色も８色あるのがいい。昔から消しゴムで消せるタイプのボールペンはあったが、フリクションは摩擦熱で消えるので、消しカスも出ない。 ちょっとした打合せをするときにこのペンを使えば、普通の紙がホワイトボードのように使えて便利だ。そんなとき、私が書いた字を消すのを見て驚く人も多い。テレビ CM も流れていたし、この業界でも ITmedia Biz.ID で紹介されたりしているのだが、まだそれほど認知されていないのだろうか（ちなみに消せるラインマーカ

  • 暮らし
  • 2007/11/05 12:02

  • 文具
  • あとで買う
  • モノ
  • lifehack
  • 消せるボールペン
• あとで読む

  『マクロのすすめ』

  5 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 一般的なアプリケーションの機能として、いわゆる「マクロの記録」というものがある。Microsoft Office（Word や Excel）にも付いているので、ご存知の方も多いだろう。商用アプリだけでなく、フリーソフト（テキストエディタなど）でも、同等の機能が付いていることがある。これは、アプリケーションに対する一連の操作を「記録」し、後で同じ操作をしたい場合に「再生」するというものだ。一連の操作を何度も繰り返し行いたいときには便利な機能である。 ここで、「マクロの記録」機能で記録された一連の処理は、どのような形で「記録」されているのだろうか？　記録したマクロを編集機能（ある

  • テクノロジー
  • 2007/10/15 06:30

  • programming
• あとで読む

  『議事録係』

  5 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 自分が参加した会議の議事録を書いたり読んだりする機会は多い。最近は、誰かに書いてもらった議事録の内容をチェックすることがよくあるのだが、一度でＯＫが出せることはあまりない。 一般的にも、「議事録係」は若手に任されることが多いのではないかと思う。しかし、実は、議事録を書くのはそれほど簡単ではない。 よくある問題のひとつは、情報の抜け漏れである。といっても、メモを取っていなくて重要な内容が抜けてしまうようなのは論外である。問題は、会話を要約するときに、必要な内容を削ってしまうことだ。議事録といえども、全ての会話を全て残すわけにもいかない。しかし、重要な発言だけを適切にピックアップ

  • 政治と経済
  • 2007/09/26 16:16

  • work
  • 仕事術
• あとで読む

  『非可逆圧縮に注意』

  3 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 データ圧縮形式の分類方法として、可逆圧縮・非可逆圧縮という分け方がある。可逆圧縮されたデータは、復元（解凍）すると、圧縮前と 100% 同じものに戻すことができるが、非可逆圧縮だとそうはいかない。一般に、非可逆圧縮とは、人間がデータを利用する際に不都合がない程度に、情報を割愛することだからだ。 非可逆圧縮は、通常は画像や音声、動画の圧縮形式について使われる言葉だが、他の種類のデータも同様の考え方で圧縮できることがある。 例えば、シフトJIS などの文字コードでは、半角の数字やアルファベットは１バイトで表現できるが、全角だと２バイトが必要となる。人間が単に文章として読むだけなら

  • 暮らし
  • 2007/09/03 00:33

  • 読み物
  • IT
• あとで読む

  『ちょっとしたプログラム』

  3 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 「ちょんプロ」という言葉がある。プログラマが自分自身の作業を楽にするために作る簡単なプログラムのことである。私がこの言葉を初めて聞いたのは、おそらく職場だったろう。ネットで検索しても出てくるが、それほど頻繁に使われているわけでもなさそうである。語源は不明だが、おそらく「ちょっとしたプログラム」の略だろう。 「ちょっとした」というのは面白い言葉である。大辞林（goo辞書 ）によると、ひとつには、「わずかな」「ささいな」といった意味がある。「ちょっとした風邪」、「ちょっとした感情の行き違い」といった使い方だ。一方で、「大層立派とはいえないまでも相当の」「かなりの」という意味もある

  • 暮らし
  • 2007/08/20 07:38
• あとで読む

  この文書は誰が読むのか｜悪態のプログラマ

  13 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 自称職業プログラマの私だが、最近はプログラミングをしている時間はどんどん少なくなってきた。遂には顧客向けにシステム導入の提案書を書いている始末である。 技術者が提案書を作ると、システムの機能面を強調しがちだ。特に、事前に客先の担当者と打合せをし、システムの要件がある程度決まっているような場合には、いわゆる「能書き」の部分は「当り前のこと」として省略してしまう。「能書き」とは「そもそもそのシステムを導入することによるメリットは何であるか」といった、根本的なところの説明である。 確かに、顧客の担当者が読むだけなら「能書き」は必要ないだろう。しかし、彼がその提案書を上司に読ませたら

  • 暮らし
  • 2007/08/05 22:37

  • documentation
  • development
  • 仕事術
  • ビジネス
• あとで読む

  『異常系とは何であるか考えよう』

  15 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 システムのテストを行う際、テストの内容を「正常系」と「異常系」に分類することがある。それぞれのテスト項目数や不具合の発生数などを数えて、テストの妥当性や品質の判断に使ったりするのである。 この正常系、異常系という言葉はよく耳にするのだが、その意味は曖昧であることが多い。人によって解釈が違うのである。 例えば、「ユーザーが入力ミスをしたケース」について、「正常な値が入力されていないのだから異常系だ」という人もいれば、「開発者がミスを想定していて、プログラムで入力チェックをしてメッセージを出すなどの処理をしていれば正常系だ」という人もいる。 これは、異常系のテストを、「エラー・ハ

  • テクノロジー
  • 2007/06/24 22:55

  • test
  • programming
  • *
• あとで読む

  『プログラミングを始めようとして何度も挫折した人へ』

  51 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 少し前になるが、はてな匿名ダイアリーで「プログラミングを始めようとして何度も挫折した」という人の投稿を読んだ（yasuhoの隠れ家さん経由）。色々な意味で考えさせられる話である。 才能以前なんだろうな。必死さが足りないって言われた。でも必死になるってどういう事なのか全然判らない。 元記事のトラックバックでも指摘されているが、この人は「プログラミングをしたい」とは思っているようだが、「プログラムを作りたい」と思っているようには見えない。例えば、「日常の単純作業を自動化するためのプログラムを作りたい」とか、「ゲームを作って友達に見せたい」とか、そういった動機がなければ、プログラミ

  • 暮らし
  • 2007/06/12 02:00

  • programming
  • プログラミング
  • 開発
  • 考え方
• あとで読む

  『やってみなきゃわからないという現実』

  4 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 システム開発の見積金額を提出して、「どうせ言い値でしょう？」といわれたことはないだろうか？ もちろん否定するだろう。ビジネストークとして。しかし、言い値といわれても仕方がないのが実情でもある。 システム開発の見積は、全くでたらめというわけではないにせよ、全く正確でもない。KKD（勘と経験と度胸）による主観的な見積はもちろん、COCOMO やファンクション・ポイント法といった客観的な見積手法を使っても、100% 正確な見積は不可能だ（※１）。 開発工数の見積は天気予報に似ているが、おそらくもっと難しいだろう。「ひまわり」や「アメダス」に相当するものがないからだ。開発の進捗に影響

  • 世の中
  • 2007/05/30 18:22

  • 仕事
• あとで読む

  『見かけの進捗』

  5 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 顧客や上司への進捗報告を行う際、進捗が遅れていても「予定通り」と報告する人がいる。遅れを責められるのが嫌なのだろう。しかし、最後までそういうことを続けていると、遂には納期に納品できなかったり、テストを省略 してボロボロのシステムを納品してしまったりして、もっと責められることになる。 私は、進捗報告は「控えめ」にすることにしている。予定より進んでいる場合は「予定通り」、本当に予定通りの場合は「少し遅れている」と報告するのである。実際、進んでいると思っていても「手戻り」が潜在していることがあるから、そのくらいの方がよい（もちろん、顧客や上司を心配させない程度に）。 そういえば、昔

  • 学び
  • 2007/05/20 23:36

  • management
  • development
  • tips
• あとで読む

  『ITエンジニアの年収』

  6 users

  ameblo.jp/argv

  悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 連休中、溜まっていたフィードの「未読」を片付けていると、ITエンジニアの年収に関する情報がいくつかあった。考えてみれば、このブログでは、収入に関する記事はあまり書いていなかった（筆者が惨めな気持ちになるからだろう）。しかし、「これからプログラマを目指す人たちへ」などと銘打っているからには、少しは触れておいたほうがいいかもしれない。 まず目を引いた情報は、「＠IT年収MAP 」というサービスだ。自分の年齢と年収（適当でも良い）を入力して検索すると、年齢×年収のグラフに、２万人のITエンジニアのデータがプロットされる。会員登録すれば、スキルなどの条件でより細かく絞り込むことができ

  • テクノロジー
  • 2007/05/07 09:41

  • money
  • it
  • business

次のページ