言語が解ることと言語を使いこなすことの違い
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45674 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
バグ予防のDB設計
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45674 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
Yoshioriの日記: だったら Java でも良いじゃないか！！
諸君！！俺は Java が好きだ！！ って書いてみたかった。 言語論争あんまり好きじゃないから あんまりそれらしいこと書いてなかったけど ちょっとだけ書いてみます。 「j」が付かない方の Yoshiori から見た Djangoへの片思い日記 - Struts脳の恐怖とRails ということで♪ いわゆる高級言語というのは 人間が書きやすい＆読みやすいという側面も大きいと思っています。 で、完全に僕の主観ですが Java のソースコードは凄く読みやすいです。 他の言語がメインの人に聞いても 「やっぱり Java は読みやすいよね」 と、言われることもあります。 さて、実際にプログラムを書くときですが、 そのプログラムの稼働期間はどのくらいでしょうか？ 開発期間より稼働期間のほうが長い場合、 保守などでコードを書く時間より 書いたコードを読む時間のほうが多いときがあります。 複数人で書いてい
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
開発スタイルの違い
日本のベンダーとの打ち合わせのときのことだ。 パフォーマンスが出ない件で、それについて議論していた。 ベンダーの開発リーダーと、私とアーキテクトとでのやりとりである。 開発リーダー「...という設計になっています。」 私「ということは、ここがボトルネックになっている可能性がありませんか」 開発リーダー「少々お待ちください」 電話をかけに行く。 暫くして、 開発リーダー「すいません。先ほどの説明は間違っていまして、ｘｘでした。」 アーキテクト「では、なぜここにキューが二つもあるんですか」 開発リーダー「ちょっと待ってください。」 また電話。 開発リーダー「ここは、担当者が換わったので、それぞれでキューを設けてたみたいで」 アーキテクト「なるほど。これは無駄ですよね。」 開発リーダー「そうですね。」 という調子で、説明も二転三転するし、確認の電話が多い。 うーむ。典型的な展開だ。 全体像を把握
デスマーチ撲滅への「飛躍」なるか--大手SI事業者、外部設計書の記述を標準化
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます デスマーチはデスマッチになりやすい――。SI業界でよく言われることだ。しかし、そのデスマーチを撲滅するための即効薬は、いまだ存在しない。そうしたなかで、デスマーチを撲滅するための「小さな一歩だが、大きな飛躍」と関係者から期待されている文書類が公開された。 NTTデータなど大手SI事業者6社が2006年4月から共同で立ち上げた「実践的アプローチに基づく要求仕様の発注者ビュー検討会」（発注者ビュー検討会）の第1弾の成果物がこのほどウェブで公開されたのである。同検討会には、NTTデータのほか、富士通、NEC、日立製作所、構造計画研究所、東芝ソリューションの計6社が参加している。 発注者ビュー検討会は、情報システムの仕様について、ユーザー企業に
はてな伊藤直也氏MIJS講演「プログラマでいること」 : 小野和俊のブログ
昨日MIJSのコンソーシアム内での技術発表会があり、理事会の方から「参加ベンダーの技術者が集まるイベントなので、技術者に元気を与えられるような人に講演をお願いしたい」という話があったので、はてな伊藤さんに講演をお願いした。 伊藤さんにお願いしようと思ったのは、伊藤さんなら、エンタープライズの世界にウェブの世界の元気な風を吹き込んでくれるのではないかと思ったからだ。 以下、私なりに講演の内容をまとめてみた。 ■「建物の建て方」 つくる対象がどのようなものかで、作り方は当然変わってくる。これは建物もソフトウェアも同じ。1階建ての格好良い小さなロッジを建てるのと、60階建ての安全で高品質な巨大ビルを建てるのとは方法も道具も異なる。ロッジを建てる時にはノコギリを使うが、巨大ビルを建てるにはクレーンを使う。 よくブログの世界でソフトウェアの開発について、ぜんぜん違うことをやっている人が同じ土俵で議論
ソフトを一人で作るということ：ITpro
最近，WebアプリケーションやWindowsソフトの取材で，“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフトや趣味のソフトではなく，会社が商品として提供し，不特定多数のユーザーが使っているアプリケーションを一人で作って，一人でメンテナンスしているという点に興味を覚えた。 先週都内で開催された開発者向けイベント「ITpro Challenge!」でも，ドワンゴの戀塚昭彦氏がニコニコ動画を一人で（しかも3日間で）作ったと語っていた（関連記事）。よく考えてみれば，ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても，企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。 アプリケーションの規模や内容，また開発者のスキルにもよるだろうが，おおむね一人で開発するほうが， ・低コ
「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
【XDev】「とりあえず作って，後から作り直せ」，Rubyのまつもと氏が語るエンタープライズ開発：ITpro
写真●「X-over Development Conference 2007」で講演する，まつもとゆきひろ氏 「結局のところ，顧客に何が必要かは，顧客にも開発者にも理解は不可能だ。そうならば，まずアプリケーションを作って，それを使ってもらい，顧客に合うように直すしかない。これからのエンタープライズ開発も，とにかく速く安く作って，直すことが重要になる」－－。プログラム言語「Ruby」の開発者であるまつもとゆきひろ氏は9月7日，ソフト開発をテーマにしたイベント「X-over Development Conference 2007」の講演でこう主張した。 まつもとゆきひろ氏の講演テーマは「Web 2.0時代のエンタープライズ開発」というもの。Web 2.0時代のアプリケーションは，「YouTube」に代表されるように，「仕組みそのものよりも，データがどれだけ集まっているかが生死を分けている」（ま
モデルは世界を表現していない (arclamp.jp アークランプ)
システム開発は情報のモデル化 システム開発とはなにか、と聞かれたら「情報をモデルとして扱うこと」と答えるようにしています。オブジェクト指向としてモデリングを説明すると、たとえば車であれば色や馬力といった属性と、走るや止まるといった振る舞いに分けることができるわけです。ソフトウェアというのは、情報という見えないものをモデリングすることによって扱えるようにする手法というわけです。 最近あらためて感じるのは、あくまでもモデルを扱っているに過ぎないんだなということです。以前は「オブジェクト指向であれば現実世界を表現できる」みたいなことをいっていたのですが実際には不可能なことです。モデルの中の車を”本当に”走らせようとしたらガソリンがエネルギーに変換されるところまでモデリングしないといけなくなります。そんなことはできないので「謎の力」に登場してもらうことでモデリングされた車は走ることができるように
ITmedia エンタープライズ：遅れた日本のソフトウェア開発 その原因はここにあり!?：作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！ (
作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！：遅れた日本のソフトウェア開発 その原因はここにあり!?（1/3 ページ） 米グーグルでは食事がタダに。米マイクロソフトではソフトドリンクが飲み放題。そのほか、米国のIT企業の多くでソフトウェア開発者は全員、個室を与えられている――こんなこと、日本の企業であるだろうか？ 驚愕!? 海外企業における個室の作業スペース 米国のみならず先進諸国においては、ソフトウェアエンジニアの労働環境は総じていい。世界一巨大なソフトウェア会社のマイクロソフト、欧州最大のソフト開発会社として有名なSAPで働いた経験から、そう感じる。どちらの会社も、さまざまな側面において一部から厳しく評されることもあるが、そんな評判とは裏腹に、エンジニアの労働環境は良かった。 ご存知かもしれないが、米マイクロソフト本社のオフィススペースは筆者が勤めていた当時、完全な個室型
「メインフレームにこだわると，技術が伝承されなくなる」——JTBの野々垣氏が警鐘：ITpro
「もし情報システムのオープン化に躊躇している現場があるならこう言いたい。メインフレームにこだわるな。一刻も早くオープン化に取り組めと」――。 JTB情報システムの野々垣典男氏（執行役員 グループIT推進室長，写真）は29日，都内で開かれたセミナーでこのように述べ，メインフレームに固執する企業に対して警鐘を鳴らした。日経SYSTEMS主催の創刊1周年記念セミナー「変化に強いシステム基盤の条件～ITインフラの最適設計を目指して」の基調講演で語ったもの。“脱メインフレーム”の最大の理由を野々垣氏は「システムを再構築するプロジェクトを敢行しなければ，ベテランのノウハウが伝承されない」ことだと強調する。 もちろん再構築の狙いは「技術伝承」だけではない。JTBでは1970年代に構築した旅行予約販売システムの再構築を，2002年から5年計画で進めている。その主な目的は，インターネット販売への対応や，各店
頭の中にプログラムを入れる
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
失われた２０年－ソフト業界は変わったのか？ その５：１９９１年ごろ（１） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第５回目。 今まで、第三次オンが終わったころ（１９８０年代後半）について書いてきたので、今回は、そのちょっとあとの１９９１年ごろについて書きたいと思います。 ■ダウンサイジング→オープンシステム そのころの日経コンピューターが、こんなかんじ 日経コンピューター創刊１０周年記念号 １９９１年１０月７日号の 特集が ダウンサイジング ホストなき世界の到来 ということで、このころ、ダウンサイジングが話題になる。 （アップサイジング、ライトサイジングなどといいだすひともいたけど） この流れが、オープンシ
プロセスこそアーキテクトのもの (arclamp.jp アークランプ)
ちょいとした事情で品質まわりの情報を調べていたのですがISO 9126-1（JIS X 0129-1）というのに初めて目を通しました（不勉強ですみません）。本物は、ＪISの検索ページで、「x0129」と入力するとでてきます。 で、品質とは何かというページがうまくエッセンスを抽出しています。まず品質をモデル化すると次のようにすることができます。 ※上記ページからの直リンク 右側の「利用時の品質特性」というのは特定の状況における利用者が感じる品質です。だから、状況や利用者が違えば変わってきてしまうもの。で、一般的な指標は「外部品質」と「内部品質」で、それぞれソフトウェアの動きと中身の構造のこと。 そして注目すべきは一番左側のプロセス品質でしょう。プロセスとは設計／開発のやり方や手順。さてJISのドキュメントから少し引用してみましょう。 プロセス品質（JISX0160に規定されているすべてのライ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サイボウズ株式会社
http://chikura.fprog.com/index.php?UID=1186645498