プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
ソフトウェア工業化と職人化が待ち受ける世界 - GeekFactory
生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。Ruby の開発でいえば、まつもとさんやささだ先生にサポートスタッフ (あるいは秘書とか内弟子とか) をつけて、極力彼らが雑用をせずに Ruby 開発に専念できるような環境を整えるべきではなかったか。 http://d.hatena.ne.jp/kwatch/20090204/1233769288 基本に立ち返って、ソフトウェア工学の目的とはなんだろう。それは「ソフトウェア開発が産業として安定成立する事」だろう。そこでこれを、大目的とする。 では、さらに考えて「産業として安定成立」するにはどうしたらいいだろうか。 大目的を成立させる為の、最低限の条件として考えられるのが、 ・条件１：成果物の品質安定 ・条件２：関連人材の安定
日本のホワイトカラーの生産性を上げるには２ - SQLer 生島勘富 のブログ
日本のホワイトカラーの生産性を上げるには、データベース設計をプログラミングの後に行うべき、そのためにはビジネスロジックをストアドプロシージャに入れる必要がある。ということを前回書きました。 今回は、具体的にどうしてストアドプロシージャが効率が良いかということを書きたいと思います。 オブジェクト指向言語に限りませんが、一般的な開発は以下の図1の様になります。 図1 オブジェクト指向での開発 私のいうストアドプロシージャでの開発は以下の図2の様になります。 図2 ストアドプロシージャでの開発 オブジェクト指向言語で処理する場合、図1の「４．」の繰り返しが多ければ多いほどパフォーマンスが悪くなります。 ですから、よくパフォーマンスが悪ければ「４．」繰り返しを減らすように図1の「１．３．４．」の処理を修正すればよい、つまり、パフォーマンスが悪いときSQLで処理する部分を増やす。という主張を耳にする
Webを支える技術 -HTTP、URI、HTML、そしてREST - kagamihogeの日記
俺がはじめて Web アプリケーションに出会ったのは Java Servlet だった。その当時はまだゼンゼン Web というものを意識することはなくて、直前に Java Applet をさわっていたため、Servlet は appletviewer 使わなくても動く Java なのかーなんていうマヌケな理解をしていた。なので、テキストサイトを見るのも google で検索するのもゆいちゃっとで時間潰すのも本質的には何も変わらない、ということを知るまでには結構な時間がかかったのを良く覚えている。 Web の存在を強く意識し始めるようになったのは、Struts で Web アプリを作る仕事をするようになってからだったように思う。何故かというと、本格的に Web アプリを手掛けると様々な問題に直面するから。その問題というのは、純粋にプログラミング上の問題なときもあれば、HTTP の仕様がそうな
「作る」から「使う」への転換〜「アプリを作らない」ノンコーディング開発基盤Nintex - 組織を進化に導くIT羅針盤
■アプリを「作る」ことは価値を生まない 日本の生産性は悪化の一途をたどりOECD加盟30カ国中第20位まで落ち込んだ。その原因の一つはナレッジワーカーの業務非効率にある。優秀な社員が手間をかけて素晴らしい業務をしているが、それは本来手間をかけるべきではない非戦略領域である事が多い。ITの面でそれが如実に現れているのが乱立するアプリケーションである。 例えば、ある大手企業Ａ社の例を見てみよう。 大手企業Ａ社は10年前からNotesを利用し始めた。現場のニーズに合わせたアプリを容易に作ることができるためEUCが進展、現場発で次々とアプリが作られ、最終的にDB数が2,000DB近くまで達した。 10年間でIT化は大きく進んだが、その反面DB数の多さがメンテ・サポートコストに跳ね返ってきた。また、バージョンアップや移行をしようとしても、DB数が多すぎて身動きがとれなくなった。ユーザーからみてもイン
COBOL入門 ひよこグミ
サルでもわかるCOBOL入門 サル並みの知能しかない私でも覚えることができました 笑いながら楽しくCOBOLを習得しましょう！ リンクフリー ※フレーム分割画面表示 検索などで辿り着いた場合は、クリックして下さい 【更新履歴】 2007/05/22 >COBOL記述時の注意点の中で誤字がありましたので修正。PERFROMになってますた。。 2007/03/09 >How to ダウンロードのCOBOL85ダウンロード先がいつの間にか移転してたためURLを変更 2007/02/07 【テーブル操作】検索3用データ配信を追加 【近況報告】 2007/05/22 ４月の残業が２３０時間を超えました。よく倒れずに頑張ったと思います。 【サイト紹介】 2003/08/19 大先輩であるvokさんのサイト 何で今更構造化プログラム 監督職の方々は必見！ 初めてのお客様へ 【COBOLとは？】 COBO
IT業界の00年代を振り返る - プログラマーの脳みそ
00年代のIT業界というと、2000年問題に始まった。西暦を数字2桁で管理していたがために桁あふれするだなんて、今になって思えばなんとメモリをケチッていた時代だろうと思うところだが、当時のマシンスペックを思えば仕方無くもある。 2000年初頭のマシンスペック 2000年2月17日に発売されたWindows2000の要求スペックは、Pentium 133MHz以上、メモリ 32MB以上、ハードディスク 850 MB以上の空き容量であった。 1996年にリリースされたJavaは2000年5月8日をもってJ2SE 1.3がリリースされ、かなりこなれてきていたし、Java VMのパフォーマンスもほどほどだった。当時の19200kbpsほどのモデムではJavaAppletのダウンロードには時間がかかったし、当時のJREの起動の遅さもあってJavaといえば遅い、というステレオタイプが根づいていたが、ビ
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
安全策が後手後手を生む - レベルエンター山本大のブログ
場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と 影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、 僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 ここで場当たり対応を選んでしまうことは、 「現実をみた大人の意見」のように思えるかもしれないが、 僕からすると、大事の前の小事にこだわるという、本末転倒の考え方にしか見えない。 保守で、既存プログラムの修正をやろうという後輩から相談を受けた。 既存プログラムのSQLの一箇所が違うだけのメソッドを作る必要があるとのことだ。 メソッドをコピーして重複したコードを書くことに後輩は納得がいかず、うまい方法は無いものかと僕に相談をしてくれた。 僕は、このメソッドの引数を追加して条件分岐できるようにし、元のシグネチャオーバーロードとして別途定義する案を上げた。 後輩は、我が意を得た
プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
ソフトウエア開発って日銭商売？
1960 年生まれ，独身フリー・プログラマの生態とは？ 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から，現在に至るまでの生活を振り返って，週1回のペースで公開していく予定です。プログラミングに興味がある人もない人も，フリー・プログラマを目指している人もそうでない人も，“華麗”とはほど遠い，フリー・プログラマの生活をちょっと覗いてみませんか。 ※ 記事は執筆時の情報に基づいており，現在では異なる場合があります。 世の中には，たった一人で仕上げるシステムもあれば，大勢のスタッフがよってたかって開発するシステムもある。だから，すべてを一緒くたにして論じるわけにはいかないと前置きしたうえでのお話である。 “はるか20年”ほど前，プログラム（あるいはシステム）は，大量生産の工業製品のように，「マニュアル通りに組み立てさえ
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
RoRのmigrationで思ったこと - masayang's diary
最近、それなりに本格的なシステムをRailsで開発しているのだけど、ActiveRecord::Migrationに衝撃を受けた。これはすごい。 昔話 20年ほど前、ソフトウェア開発の生産性が目に見えて向上した時期がある。ここで話しているのはビジネスソフトウェアのことね。 自分が入社した87年は、こんな感じで開発する文化がまだ残っていた。おそらく最後の頃だと思うけど。 ロジックの設計をするSEがいる それをもとにコードを「紙に手書きする」プログラマがいる。専用の用紙があったのだ。 その紙を元にコードを入力するコーダ→コードは80桁のカードに入力 プログラマはカードの束をカードリーダに突っ込む バッチ処理でコンパイルされて、結果がリストに出力される コンパイルが通らない場合はプログラマが原因を突き止めて、修正したコード入力をコーダに依頼する 以下繰り返し[*1] 要するにプログラマはコーダへ
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C++の話（本当にあった怖い話）