日本のユーザー企業は忍者のようなプログラマーをもっと登用して重用すべきでは - 達人プログラマーを目指して
あの記事から一年、ひがやすを氏が以下のエントリーで、プログラマーとして、新しいサービスを作ることの難しさについて書かれています。 僕と君とSIerの生きる道 - yvsu pron. yas 確かに私自身は、サービスを作る側に回った(まだISIDにいるけど、ベンチャーで働いているようなものです)のですが、身を持って面白いサービスを作る難しさも経験しました。 面白いサービスを作るのはほんとうに難しい。その後、マネタイズにも成功するのはさらに難しい。サービスを作る側に回って成功するのはほんの人握りの人なんです。 もともと一年前におっしゃっていたことは、SIerのビジネスに将来性はないから優秀なプログラマーは自分でサービスを作る側に回らなくてはならないし、単によいコードを作れるだけでなくて、自分からアイデアを考えられるようにならなくてはならないということだったかと思います。一年前この記事を読んだ
ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家（ドメインエキスパート）ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJava、C++、C#、Visual Basicといっ
Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指して
デブサミ2011会場のオライリーのブースで目に入ったため、以下の本を購入しました。 Java: The Good Parts 作者: Jim Waldo,矢野勉,笹井崇司出版社/メーカー: オライリージャパン発売日: 2011/02/24メディア: 大型本購入: 3人 クリック: 148回この商品を含むブログ (37件) を見る180ページほどの薄い本ですし、各章は独立して気軽に読むことができます。早速、気になるいくつかの章から読んでみました。ただし、監訳者のid:t_yano氏も前書きで 本書が、みなさんにとってJava以外の言語についても考えるようになり、みなさんのプログラミングの世界がさらに豊かになることを望みます。 と書かれているように、この本から直接Javaのプログラミングのテクニックや知識を得るというよりも、ベテランの上級者がJavaについて考え直すきっかけ作りとして読むのが良
グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して
共同購入サイトのグルーポンでバードカフェというお店が販売したおせちの話題がネットで大いに盛り上がっています。 痛いニュース(ﾉ∀`) : グルーポンの割引で買ったおせち料理が酷すぎると話題に - ライブドアブログ 痛いニュース(ﾉ∀`) : グルーポンおせち騒動で、「バードカフェ」社長が辞任発表 - ライブドアブログ ネット上のネタとしてだけでなく、最終的にNHKのニュースでも取り上げられたみたいです。 http://www.nhk.or.jp/news/html/20110103/t10013172511000.html 昔なら、こういう事件があっても食中毒事件でも起こさない限りここまで大きな話題になっていなかったかもしれませんが、正月早々、ネットの怖さを思い知らされた感じですね。以前なら消費者もこうした商品を購入してだまされたと思っても泣き寝入りで我慢してしまう人も多かったかもしれませ
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
