35歳プログラマ定年説はもう時代遅れ。職業プログラマは32歳定年説を推します - 会長@腹部日記(2011-10-07)
_ 35歳プログラマ定年説はもう時代遅れ。職業プログラマは32歳定年説を推します 今冬のチーム体制を議論する季節になってきました。とうとう私はプログラマとして招へいされることが無くなりました。 ジョジョの奇妙な冒険第二部風に現状を説明すると以下です。 tamoot は・・・二度と Ruby on Rails を使った開発のお仕事には戻れなかった・・・ サポートのようなお仕事と、バグ調査・パッチ作成のお仕事との中間の生命体となり永遠に会社をさまようのだ そして開発のお仕事をしたいと思っても招へいされないので・・・・ -- そのうち tamoot は考えるのをやめた 私をプログラム開発業務へまわすデメリット 客観的に見て以下です。弊社ならやはり定年として扱われても仕方ありません。 時間単価が高い 偉い人はプログラミングごとき下流の作業は単価の安いやつにやらせるという方針です。 明らかに間違って
『コピー指向プログラミング』
以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。 そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。 アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想
Effective なんとかを読めば良いというものではない - 神様なんて信じない僕らのために
何となく思ったこと。 なんとか、の話になったとき、 Effective なんとかを読まずになんとかは語れないとか、 やったとは言えないとか、まずは読むべき、とか色々と耳にしたりする。 かくいう自分も C++の本で何が良いと言ったら、 プログラムの経験がある人なら、Effective C++は勧める本の中に入ると思う。 ただ、この本を読んだからといって、 見違えるようにC++が書けるようになるわけでもない。 かといって、読まなくても良いかというとそうでもない。 そんなこといったら 「Exceptional C++」も読むべきだし、 「Exceptional C++ Style」だって読んで欲しいですよ、ですし、 「C++ Coding Standards」だって、ねえ。スタイルがさー。 いやいや、「Effective STL」は外せないでしょう、STL使わないってありえないし、 とか、ならな
Martin Fowler's Bliki in Japanese - 設計力
http://martinfowler.com/bliki/PreferDesignSkills.html 2008/1/18 雇用について考えてみよう。 応募者が2人。どちらも経験が数年間。 青コーナーの人には、あなたが好きな設計スタイルの広範な設計力が備わっている（私の場合だと、DRY、分別のあるパターンの使用、TDD、伝わるようなコード、なんかが挙げられるけど、自分の好きなやつでいいよ）。ただし、彼女には、あなたが使っているプラットフォーム技術についての知識がない。 赤コーナーの人には、そういった設計の知識は（それに興味も）ないが、プラットフォーム技術についての知識はめちゃくちゃある。言語には詳しいし、どのライブラリが使えるかはよく知ってるし、ツールも流暢に使いこなす。 これ以外のことについては（こうした思考実験以外については）、2人ともまったく一緒だとしよう。 また、あなたのチーム
PythonでSchemeを作りました - 西尾泰和のはてなダイアリー
1000人スピーカカンファレンスの二次会の飲み会会場を追い出された後、なぜかサイボウズラボに戻って三次会。 なぜかyukobaがSchemeを作り始め、amachangも「作る」と言い出した！「どうせだからハッカソンにしよう」って話が！いや、そんなことしだしたら帰れないし！ああっ！でも今書かなければ一生書かないかもしれないっ！ というわけで書いたのがこちら。 どう書く？org 5414 にしお: 飲み会の後5時間で作ったものなのでかなり...(Schemeもどきの実装) - 投稿の詳細 残りの二人の書いたものはこちら。 Scheme on JavaScript 作りました - yukobaの日記 わーい ＼（＾o＾）／ Scheme もどきを JS で書いたよー！ - IT戦記 - せっかくなのでハッカソンの雰囲気を少しでも伝えられるように書いてみる↓ 以下オフラインの発言は「」、Ling
『スキルアップのためにラップを剥がしてみる』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 仕事で会計関連のバッチ処理を設計しているところなのだが、機能のほとんどが数値を操作するだけのいわゆる業務ロジック（ビジネスロジック）なので、ちっとも面白くない。そういえば、WEB+DB PRESS Vol.38 の特集に、「"業務ロジックしか書きたくない人" のための書かない技術」というタイトルを見て、違和感を感じた記憶がある。 もちろん、このタイトルの意味は理解している。「業務ロジック」というのは、ユーザーの業務に特化した処理である。そのため、それぞれのシステムによって処理内容が違い、その都度新しく処理を「書く」必要がある。一方、業務ロジック以外の部分は、どのシステムでも似
「問題がない状態」=「普通の状態」って判断されることが、システムの悲劇の様な気がしたあの日。: 不倒城
タイトルで完結。 大至急速くしなくてはいけないSQLが一個あった。朝から久々にクエリチューニングに時間をつぎ込み、他人が作ったねじくれSQLを徹底的に分解して、まあまあ満足のいくパフォーマンスが出た辺りで、別件でユーザー側と連絡をとった。 そのついでに、速くしたクエリを使っているシステムについて、挙動の様子を聞いてみた。ふふーん今回は自信作だぞ、とか思っていたら。 「ああ、そういえば今は普通に動いてますね」 おいこら、応答速度で200倍くらいになってる筈だぞ。普通って何だ、普通って。俺涙目。 ああ、何と言うことか。彼らには、「問題がないこと」と「凄く順調であること」の区別がつかないのだ。応答速度に3秒かかれば大騒ぎをするのに、それが0.01秒になっても気付きもしないのだ。後者にどれだけのコストがつぎ込まれているのか、想像が出来ないのだ。 アラン・チューリングよ、彼らを許し給え。 思うに、我
♪ バグは夜更け過ぎに仕様に変わるだろう : 小野和俊のブログ
トラックバック一覧 1. バグはいつか仕様に変わる？ [地方で活動するweb制作者の日々を綴るblog] 2007年07月18日 14:25 「バグは夜更け過ぎに仕様に変わるだろう」 というのは、IT屋さんの中では有名な格言らしいのですが（私は知りませんでしたが）、その全文版を公開したそうです。 業界の人なら受けること間違いなし。 そして、現実と照らし合わせてぞっとすることも間違いなし。 IT 業... 2. 2007年7月18日 1907年はこんな時代 [神戸の三代目] 2007年07月18日 20:04 またヤフー株が米国につられて下げてる・・。誰かアナリスト、ちゃんと指摘してよー。ネタ加藤一二三九段伝説 前も書いた気もするけど、加藤一二三が凄い（というか面白い）。 一芸に秀でている人はぶっ飛んでいる人が多 3. [研究室][雑記] [Gabari] 2007年07月18日 20:22
ベストよりもベターを選べ - アルゴリズムマニア2.0
自分に言い聞かせてることの一つに「ベストよりもベターを選べ」というのがある。 例えば、プログラマーというのは大勢で一つのプログラムを開発する。大勢のプログラマーが集まれば技術差はもちろんのこと、そもそも仕事に対する姿勢もてんでバラバラだ。ある人は最高の製品を作りたいと考えてる。その一方である人は全力で手抜きをして給料泥棒したいと考えている。そういう集団の中で技術的にベストな方法が、本当にベストであることはまずない。例えば、C++を使うのが技術的に最良だったとしても、VBを使う方がトラブルが減り全体で見るとベターになるかもしれない。 馬鹿プログラマは仕事でプログラムするなhttp://d.hatena.ne.jp/Isoparametric/20071104/1194128512をチラっと見て、私のプログラマーバイト時代の苦労を思い出した（私も愚痴をいっぱい言ったもんだなぁ、と）。まじめで勤
ベターよりベストを目指せ - 神様なんて信じない僕らのために
こんなタイトルにすると反論、という感じにとられてしまうかもしれないのですが、 身にしみる想いがしたので書いてみます。 反論ではなく想いのつもりで書いています。 自分に言い聞かせてることの一つに「ベストよりもベターを選べ」というのがある。 アルゴリズムマニア2.0 確かにhigotakayuki2さんの言われるように、 常にベストな選択肢が選ばれる訳じゃない、 特に慣れている事に関してそれよりも良い選択肢があったとしても、 その新しい選択肢を選ぶ事をする人は少ないでしょう。 例えばCをずっと使ってきた人はC++に移りたがらなかったりもします。 憶えるのが面倒というのもあるのでしょうが、 Cで出来ているからいいじゃん、という考えが支配的です。 これをVBに置き換えてもそうなのでしょう。 そして、我が儘を承知で言うなら、 俺はこんな考えは大嫌いです。 目の前の仕事を手元にある技術で片付けていくだ
上司に認めてもらえないエンジニアは“社内”を捨てOSSで行こう
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 比嘉康雄氏といえば、Javaのための「依存性の注入（Dependency Injection：DI）」と「アスペクト指向プログラミング（Aspect Oriented Programming：AOP）」をサポートした、フレームワーク「Seasar2」のチーフコミッターであり、日本のオープンソースソフトウェア（OSS）の世界でも有名人と言えるだろう。そうした比嘉氏がOSSに出会ったのは、「社内での評価に対する不満」がきっかけだという。 電通国際情報サービス（ISID）に勤務している比嘉氏は先頃開催された情報処理推進機構（IPA）のイベント「IPAフォーラム2007」の中で、「開発を夢のある仕事にするには」と題する講演を行った。同氏は、20
「人月のワナ」のワナ | おごちゃんの雑文
吉岡さんのblogの、 ソフトウェアの作り方を考える より。 私のバックボーンからすれば、 多くの人が指摘しているようにソフトウェアの価値をかかった工数（人月）で評価するというのはまるっきりナンセンスである。熟練者が一ヶ月で作成できるものを初心者が6ヶ月かかったとすると、後者に6倍お金が払われるか、それだけの価値があるか。もちろんない。 この主張は全てがナンセンスに見える。 多くの人々が、人月見積りを否定しようとする。これについては以前、 悪いのは「人月」じゃないだろ というエントリを書いている。また、同じような趣旨で仙石氏のエントリ、 なぜ人月見積もりが優れているのか というのもある。要約すれば、「人月」というのは単なる工数モデリングの手法に過ぎないわけだから、運用さえ間違えなければ比較的robustな方法でそうそう悪いものではないということ。 「人月」はあくまでもモデルであるから、その
人月を超えるとプログラムしている暇が減る : 404 Blog Not Found
2007年09月26日16:15 カテゴリArtMoney 人月を超えるとプログラムしている暇が減る 人月が銀の弾(たま)ではないことが知られて久しいのに、「人月伝説」が衰えないのは、誰が悪いのだろうか? 矢野勉のはてな日記 - プログラマなら人月なんかさっさと超えろ 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 実は、プログラマー自身なのではないだろうか。 実は人月というのは、発注者側だけではなく、プログラマーにとっても楽なのだ。人月見積において、プログラマーが考えなければならないことは、「それを作るのにどれくらいの時間がかかるか」ということだけだ。「それを完了するのに何と何と何が必要で、それぞれこれくらいの手間がかかる
ProgrammerProverb - MoriMoin
プログラマ格言 PHPを笑うものはPHPに泣く 意味: 「PHPなんてまともなプログラミング言語じゃないよ」と笑っていたら仕事でPHPを触るはめになってしかも既存のソースが汚かったりして泣く。 教訓: 好き嫌いを通せるようにえらくなれ。 ソースが知れる 意味: 変な挙動をするソフトをさわっていると、動き方から間違ってるパターンと作った人のレベルがなんとなく透けて見える。 教訓: どうやったらうまく動くか探すのも仕事のうちらしい。 ひいきのwiki倒し 意味: 「wikiはすばらしいツールですよ！」 と、とにかくwikiを導入してメンテ不良のページを大量につくってしまう。 教訓: 情報共有ツールは使う人のメンテナンス能力が一番のネック。 ライブラリからボタ餅 意味: 延々ぐぐってみつからなかった情報がライブラリのソースであっさりみつかった。 教訓: ライブラリのソースは
どうしてプログラマに・・・プログラムが書けないのか?
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
パラサイト・プログラミング steps to phantasien t(2007-04-16)
2007-04-16 近況 最近の私はもっぱらサンプルからのコピペが仕事. コピペといっても Ctrl+C, Ctrl+V より少しだけインテリジェントだけれど, ライブラリが強力な上に文書の出来が良いから, 多くはサンプルの改変で済んでしまう. 面白くはないが生産性は高い. コピペ・ハイウェイの渋滞にぶつかり, サンプルのないパターンに出会うこともある. そういう時は自分でコードを書く. でもだいたい動かない. Getting Started や入門書はざっと読んである. それでもわからない. 文書化されていない不具合や common pitfall だったりする. (間抜けな間違いもあるけれど...) こんなとき Google はあまり役にたたない. 使っているライブラリやフレームワークがよほどメジャーでない限り, 解決方法はなかなかみつらない. せいぜい自分と同じところで悩んでいる人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラマと付き合う
『われわれは100倍、速く書けない - やねうらおブログ(移転しました)』へのコメント
「現在のインスタンスを参照するthisキーワード、付ける？ or 付けない？」（1） Insider.NET － ＠IT
はてなブログ | 無料ブログを作成しよう
