こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい
アマゾンにおけるソフトウェア開発の仕事について感じたこと - 達人プログラマーを目指して
ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。 私自身は、昨年秋にSIerからアマゾンに転職してまだ半年ですが、この機会にアマゾンにおけるソフトウェア開発の文化や考え方について、ブログでご紹介できる範囲でまとめてみたいと思います。 私は、ずっとブログに書いてきたようにSI業界からの転職だったのですが、一般的なSIerにおけるソフトウェア開発の考え方や手法といろいろな面で違っているということは予想していたというか、もともと覚悟の上での転職でした。それでもやはり最初のうちはあまりにも大きな変化に自分の仕事のスタイルを合わせるのにいろいろと苦労しました。基本的には転職したての頃に抱いた感想（転職
日本における初の解説書であるJenkins実践入門を送っていただきました - 達人プログラマーを目指して
先日、技術評論社の傳智之さん（@dentomo）より、Jenkins実践入門を献本していただきました。どうも、ありがとうございました。 Jenkins実践入門 ?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus) 作者: 佐藤聖規,和田貴久,河村雅人,米沢弘樹,山岸啓,川口耕介出版社/メーカー: 技術評論社発売日: 2011/11/11メディア: 単行本（ソフトカバー）購入: 26人 クリック: 496回この商品を含むブログ (64件) を見る既に、Jenkins（Hudson）については、開発プロセスを自動化する継続的インテグレーションに欠かせないツールとして、日本でも非常に人気高いツールとなっており、また、雑誌やインターネットの記事でも今まで時々特集が組まれてきたと思います。WEB+DB PRESS 総集編 [Vol.1?60] 作者: 森田創,cho45
すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して
このたび9月末日をもってオージス総研を退職し、10月よりアマゾンジャパン株式会社に入社しました。今後はSoftware Development Engineerとして、日本をはじめ世界各国のAmazonのモバイルWebアプリケーションの開発を担当することになる予定です。 およそ7年間にわたり、前職のオージス総研ではソフトウェアアーキテクトとして、SOAやEAといった全社的なシステムのアーキテクチャから、上流のモデリング、Java EEを使ったアプリケーションの開発など、技術者として様々な経験を積ませていただきました。私自身はこのブログでも何度も取り上げてきたように、モデリングやオブジェクト指向といった技術を用いて、実際の基幹業務システムの設計などに活用することで、高品質で保守性の高いシステムの構築に貢献したいという思いがありました。そのようなシステムを構築、維持するためには高品質なアーキテ
普通の構造化プログラマーがオブジェクト指向の存在意義を理解するコツ - 達人プログラマーを目指して
オブジェクト指向言語の存在意義を理解するのは難しい？ id:amapetasさんによる、ちょっと興味深い記事がありました。 オブジェクト指向言語が流行した必然性について考える(1) - Programmer’s Log そして、その記事の中で説明されているのですが、やはり、C言語など構造化言語のプログラマーにとってはオブジェクト指向の存在意義を理解するのがなかなか難しいところがあるようですね。 初心者向けの書籍を最近読んでいないので、最近の書籍ではうまく説明されているのかもしれませんが、そんな話を聞いたことがないので、たぶん今でもオブジェクト指向に関する説明の始まり方は 「世界は全部オブジェクトで出来ているんじゃぁぁーーー」 という「オブジェクト至高教への洗脳」から始まっているものと推察しますw テンション高めの説明から入るのでドン引きする人多数な感じがかなりアレですね。オブジェクト指向の
Pulseを使ってEclipseの設定を共有すると便利（ただし、閉鎖環境では使えません） - 達人プログラマーを目指して
Eclipseのワークスペース設定を共有することは難しい EclipseはJavaの開発では最も人気の高いIDEであり、もちろん、私も仕事でも自宅でもずっとメインのIDEとして使ってきました。もちろん、NetBeansやIDEAなど他の優秀なIDEもフリーで利用できる時代なのですが、やはり、入力支援機構やリファクタリング機能の豊富さについては、やはり、Eclipseが他と比べて一歩優れているように思われます。*1 そして、Eclipseの最大の特徴の一つは柔軟なプラグインのアーキテクチャであり、豊富なプラグインの中から選択して好みの機能を拡張することができます。ただし、これはEclipseの最大のメリットでもあるのですが、大量のプラグインを管理して複数の端末で効率的に共有するということは案外大変なことでした。 Pleiadesのオールインワンパッケージを利用したり、また、SpringやJB
SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ
staticおじさんとオブジェクトおじさんはお互いに分かり合えるようになるかもしれません。 - 達人プログラマーを目指して
先日書いたstaticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指してのエントリに、なんと、みながわけんじ氏ご本人よりコメントを頂きました。もともとは一般のstaticおじさん達（英語ではstatic ojisansという感じ）に向けて書いたのですが、思いがけず、元祖staticおじさん（The static ojisanあるいはMister staticといった感じ)ご本人からのご意見をいただき、本当に嬉しく思います。 オブジェクト指向の再利用性と非オブジェクト指向の関数やサブルーチンとの違いを明確に示していないから いろいろ理屈を込めても無駄ではないでしょうか？ 誰かが作ったクラスを継承して再利用したところで、バグが少なくて、メンテナンス性がいいものができるでしょうか？ そんなものをあてにするより、天才が作ったクラスライブ
ConQATを利用してソースコードの品質をチェックする - 達人プログラマーを目指して
ある程度プログラマーとして経験を積めば、ソースコードを読んだときに、そのソースコードの良し悪しというものは、嗅覚を使って直感的に嗅ぎ分けることができるものです。実際、そのように体の感覚を使ってこのコードは不吉だと感じるところは実際大いにあり、コードの臭い（code smell)として知られています。 コードの臭い - リファクタリングの必要性を示す兆候 これはファウラーの名著 リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見るでも紹介されており、こういった不吉な部分を適切に嗅ぎ分け
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指して
Twitterでフォローさせていただいている@chok12jaさんのつぶやき がきっかけで、外国人の視点から日本のSI業界の問題について分析した面白い英文の記事を見つけました。 How the Japanese IT Industry Destroys Talent | Japan -- Business People Technology | www.japaninc.com [ThinkIT] 第2回：なぜ日本のIT業界ではスーパーSEを育てられないのか (1/4)（New 日本語訳が見つかりました。） 2007年に書かれた記事なのでもう４年も前に書かれたものですが、日頃から私が感じてきた業界の問題点について鋭く批評を加えており、非常に共感する内容が書かれていました。本ブログの主な読者の方々にとっても興味深い内容だと思いますので、ここで簡単に内容について紹介させていただきたいと思います
Apache Ivyの紹介と基本的な使い方 - 達人プログラマーを目指して
Apache Ivyについては本ブログでも何回か用語自体は取り上げてきましたが、現状日本語での情報が限られるためか、AntそのものやMavenに比べるとユーザーが少ないように思われます。ここで基本的な使い方やMavenとの違いについて簡単に紹介させていただきたいと思います。 Apache Ivyとは 本家のホームページは以下の通りです。 Home | Apache Ivy ™ もともとはJayasoftという組織で開発されていたツールですが、バージョン2.0以降、Antの関連プロジェクトとしてApacheプロジェクトの元に加わっています。（Apacheというブランド名はツールを組織に導入する際に結構重要ですね。） 上記のホームページでは「アジャイルな依存性管理ツール」として紹介されていますが、Mavenの機能の中からビルド機能やプロジェクト管理機能を無くして、ライブラリーの依存関係の管理に
フレームワークごとの生産性の違いを定量的に計算する方法があったらいいのにな - 達人プログラマーを目指して
アーキテクトの重要な仕事の一つに、フレームワークの選択があります。そこで上流の方から毎回必ずと言っていい程求められるのは、選択肢となるフレームワークごとの生産性の違いがどのくらいあるか「定量的に」教えてほしいというものです。たとえば、Strutsの工数を100とした場合、Spring MVCなら70になるというようなことを事を答えとして求めてくるわけです。今、あるプロジェクトの提案書作成の支援をしているのですが、元請のマネージャーから提案書に生産性比較の定量的な評価を載せたいと言われてしまいました。まあ、いつものことですけれどね。 この業界では理科系の発想のできる人は少ないと言われていますが、なぜか数値化や定量化だけは良いことと信じられており、数字なら信じてしまう、（あるいは数字しか信じない）という人が多いようです。もちろん、性能の見積もりにしても、DBの容量見積もりにしても、定量化できる
上流の壁？ - 達人プログラマーを目指して
達人プログラマーを目指すための素質 - 達人プログラマーを目指してで、PGの社会的地位の低さについて言及したのですが、ステレオタイプな上流コンサルと思われる方から、以下のようなコメントをいただきました。 現在の貨幣経済において、情報システムサービス業(SIer)におけるPGはそこまでの価値なんだと受け止めるべきかと。 実際の話、SIerにおいては優秀なPGが沢山いるより、大型案件を扱えるPMが沢山居る方が、より儲けやすいでしょう。 あと、別にPGだけが頑張って勉強してるわけではないです。 上流コンサルやITアーキテクトと呼ばれる人たちも勉強はしています、平均をとればPGたちよりも勉強はしてるでしょう。 営業だって馬鹿ではありません、刺しつ刺されつの世界でなんとかプロダクトを売っているんです。 貨幣経済において、付加価値の高くないことを勉強しても付加価値は低いままです。 「清掃作業において俺
高い品質のプログラムを作らなくてはならないと考えている職人PGの考えは間違っていた？ - 達人プログラマーを目指して
ソフトウェア工学の教科書やプログラミングに関する技術書は、例外なく「プログラムの品質を（制約の範囲内で）できるだけ高いものにするべき」という前提で書かれています。それがエンジニアリングの目標だし、そもそも、ものづくりの職人として、できるだけ良いものを作りたいという思いがあるのは当然だと思います。 また、よく言われることはプログラムというのは一度書いたら終わりなのではなく、長い年月をかけてメンテナンスされるものであるという考え方です。ですから、単に短い期間で作るということでなくて、長い目で見て保守性、拡張性の高いプログラムを作るということは、こういった専門書では当然良いことであるとされます。ネット上でもプログラムの品質に関するこのような特徴については、いろいろ意見が書かれていますね。 http://blog.miraclelinux.com/yume/2007/10/post_9db7.ht
SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か？ - 達人プログラマーを目指して
以前Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してにて 何でもかんでもとにかく自動生成させたがる。特にExcelなどの表から大量のクラスを自動生成させるなど。たいていそのようにして生成されたクラスはゴミで保守も大変なものになりがちです。 ということを書いたことに対して、会社の忘年会で上司や同僚の間で議論が盛り上がって興味深かったので、ここで自分の考えを再度整理させていただきたいと思います。（忘年会で1次会、2次会の間ずっとこういった話題で話が盛り上がるというのはかなり特殊な部署なのかなとは思います。「SIerのやり方はXXだ」一口に言っても、それは全体的な一般傾向を表しているのであって、実際はさまざまな人々がいることを忘れてはなりません。あくまでもそういう意味で捉えてください。） それで、私の周りにはプログラミング好き、技術好きが多
頭数要員だけでこなせる仕事が今後もずっと取れると考えているSIerの仮説は間違っている - 達人プログラマーを目指して
本来このブログをつける主な目的は、勉強したことのメモとプログラマー向けの技術の共有というところにあって、業界がどうこういうことを書くつもりはなかったのですが、多くの方のさまざまなコメントがいただけることは非常に勉強になるので、この際思っていることを書かせていただきます。（ここではこうあるべきという将来像を主張することが目的ではなくて、現状の問題点について自分が思うことを質問させていただき皆さんに意見をいただきたいと考えています。）自分がまさにSIをやっている会社に所属しているわけですから、できることなら自分の仕事にもっと誇りを持ちたいと思うのですが、多くの方の共通する見解としては、少なくともプログラマーにとってはSIは好ましい仕事ではないという意見が多いように思います。確かに、最適なデータ構造やアーキテクチャを考えるプログラマー的発想で考えると、どうしてもこの業界は無駄が多く美しくないと思
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
