プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
なぜプログラミングが楽しくなくなったのか・日本的ソフトウエア観（1）»ビジネス-最新ニュース:IT-PLUS
電通、三菱UFJ信託銀行など大手企業が相次ぎ参入を表明する「情報銀行」。ここに挑むベンチャー企業がDataSign（東京・渋谷）だ。同社の太田祐一社長は情報銀行という言葉が生まれる…続き 中部電力が「情報銀行」参入へ 電力データを活用 ［有料会員限定］ 「情報銀行」説明会に２００社 データ流通の枠組み始動
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
The Linux Foundation Japan - 各SIプロセスで使用できるOSSツール
The Linux Foundation Japan リナックスファウンデーション・ジャパン The Linux Foundationは、Linux® の普及、保護、標準化を推進する非営利のコンソーシアムです。 SI Forum いろいろなSIプロセスで使用できるOSSツールの調査 本調査は、2007年4月〜2008年2月の期間、本SI Forumに参加しているベンダ・SIerメンバーの協力によって行われました。 昨年度の｢OSSミドルウェア／ツール調査｣の作業を踏まえて、より多くのOSSドルウェアおよびツールをユーザー様、SIer様に使いやすい形で整理･公開すべく、今年度活動として、以下の３項目を活動目標としました。 参加各社がシステム構築(SI)に使用しているOSSツールを、各SIプロセス毎に整理する OSSツール情報をデータベース化し、必要なツールを簡単に検索できるよ
POLAR BEAR BLOG: Google は社内でどんなツールを使ってるの？
Enterprise 2.0 という言葉が作られるなど、WEB2.0的ツールを企業内で使うことが一般的になっているわけですが、それじゃ Google はどんな社内ツールを使ってるんだろう？という興味を満たしてくれる記事がありました： ■ The Tools Google Uses Internally (Google Blogoscoped) 元ネタはこちらのエントリに掲載されているもの（詳細なPDFファイルはこちら）で、KMWorld Magazine が主催したイベントで発表されたプレゼン内容とのこと。Google 社員の Naveen Viswanatha という方が、いくつかの社内ツールを紹介してくれています。早速どんなものか、というと： < Google Projects > プロジェクトに関係するタスクや資料を一覧表示する、ダッシュボードのようなツール。上の方にあるタブに「My
日本企業はやっぱり違う
今の仕事では、アメリカ・ヨーロッパのプロジェクトもあれば、日本のプロジェクトも関わる。 やはり日本の顧客は特徴的で面白い。 ・要求仕様があいまい ・業務分担があいまい ・契約があいまい ・パートナーといいながら、下請け ・発注主は殿様。下請け間でよきに計らえ である。 私も、前職で海外の企業との取引に関わったことがあるので、両方の言い分がよくわかる。 こちらのエンジニアと話をすると、フラストレーションたまりまくりである。 「なぜ契約書を無視するんだ？」 「なぜ仕様が勝手にころころ変わるのに、いちいち対応しないといけないんだ？請求しろ」 「なぜ彼らのライブラリのデバッグを我々がしないといけないのだ？」 「発注主がなんでちゃんとプロジェクトマネジメントしないんだ？」 という具合である。 一方で日本企業の立場でいると 「なぜプロジェクトが遅れているのに、のんきに休んでやがるんだ。」 「いちいちド
ここギコ！: 外注を叩けない性格だけど
最初の会社やその次の会社（前々社）に居た頃、外国へのオフショア含め、システム開発を外注していたことがある。 その時にどうしても同僚達と共有できなかったのが、外注を「叩く」という感覚。 もっとも、一般的な外注を叩くというレベルがどの程度のものなのかよく判らないし、同僚達が叩いている、というレベルだったのかどうかはよく判らないけれど、少なくとも私は同僚ほど外注にきつく出れなかった。 単に非コミュな性格のせいもあるけど、自分達の方の発注仕様書が、それで満たすべき項目として必要十分なのか、判り易く書けているのか、全く自信ないし、ウォーターフォールで発注したといいつつなんだかんだで仕様変更とか入りまくって、そんな状況での開発を自社でせずに外部で請け負ってもらっているのに、強くなんかでれるわけないやん、と個人的には思ってた。 ウォーターフォールどころか、しょっちゅうコンタクトとって状況確認して、実
【IT Service Forum 2007】プログラミング軽視が使えないシステムを生む----積水化学の寺嶋氏がベンダーに苦言
「今のITベンダーはプログラミングを軽視しすぎている。全員がプログラマでありSEでなければ企業が喜ぶシステムは作れない」。積水化学の寺嶋一郎コーポレート・情報システムグループ長（写真）は、11月27日に開催した「IT Service Forum 2007」の講演「ITベンダーに望むこと」で、ITベンダーにこう苦言を呈した。 「システム開発でどんな技術や開発手法を使うかはアーキテクトが決める。経験上、良いアーキテクトが設計すると、開発と運用のコストを段違いに削減できる。良いアーキテクトとは、業務とプログラミングをよく知っている技術者だ」と寺嶋グループ長は話す。だが、今は「プログラミングを知らないSEが“売らんかな”でツールやパッケージの導入を目的に設計し、オフショア開発などで業務の分からないプログラマが実装している」（同） この状況を改善する策として寺嶋グループ長は「内作型開発モデル」を提唱
特集：組み合わせテストをオールペア法でスピーディに！｜gihyo.jp … 技術評論社
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
社内ライブラリには気をつけろ: ある nakagami の日記
最近、Something Red の日記エントリから目が離せない 昔、僕が味わったような苦汁を（いや、多分それ以上のものを）経験しているんだろう。 micro-8 さん成長しているに違いないよ。うんうん。 http://d.hatena.ne.jp/micro-8/20071116/1195240173 ただ、それが何かのためになるかどうかは知らない。 いや、むしろそういう成長が今後役に立たないようになることを祈る。 大きな会社では、かなりレベルが低いライブラリが「競争力の根源」と信じられ使われていることがある。レベルが低いっていうか、作るより使うほうが難しくて、あってもなくてもどうでもいいライブラリ。 どっかで書いたと思って探したら、この時↓の後半にちょっと書いてた。 http://blog.so-net.ne.jp/nakagami/2005-07-11 この時は、確か RS-232C
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
ソフトの部品化と生産性 - 雑種路線でいこう
ところでSOAでソフトを再利用とか簡単にいってしまうと眉唾というか，すぐプロトコルとかコンポーネント・モデルとかメソトロジに関心がいきがちなのだが，実際のところ再利用できるコンポーネントをつくるには，使い捨てコンポーネントをつくるより費用と期間がかかるのであって，そのコストを正当化できる理由なり仕組みがあるかどうかも重要である．ただ部品化するためにコストが増えるだけでは生産性は却って低くなりかねない． 世にこれだけ，どう儲けるか見当もつかないWeb 2.0ベンチャーが跋扈して，せっせとAPIを公開しているのも，広告バブルもさることながら，うまくするとGoogleやYahoo!が買収してくれるかもねー，というプレミアムが織り込まれていたりする訳だ． ソースを公開すれば誰か勝手に書き直して使ってくれるだろうとか，銀の弾丸的部品化技術が腐ったコードも万能にしてくれるとか，そんな虫のいい話はどこに
Google先生は不要？——ソースコード共有サイト「code*」開設 − ＠IT
2007/08/01 テックスタイルグループのオープンタイプは8月1日、ソースコードやプログラミング情報をユーザー間で共有できるWebサイト「code*」（コードなにがし）を8月2日に開設すると発表した。オープンソースコミュニティなどに利用を呼びかけたり、テックスタイルグループが持つ技術情報1万件を投稿し、Webサイトを育てる。 テックスタイルグループ代表の吉田斉氏は、ソースコードや技術情報の技術者間の共有がないため、「ネットのサービスはほとんどが1からの手作りになっている」と指摘。「Google先生に聞く、またはメーリングリストで質問して『ググれ』と怒られる」状況になっていると説明した。情報共有がないため、開発に時間やコストが多大にかかり、独自性を生み出すその先の開発にリソースを割けない状況になっているという。 code*が目指すのは「ソースコードのWikipedia」。コンテンツは技術
♪ バグは夜更け過ぎに仕様に変わるだろう : 小野和俊のブログ
トラックバック一覧 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
::memolet | Construction Tool Round-up
::memolet Personal Notes Site about programming, software, etc...... GNU makeを使うのは結構面倒。antもいいけどC++のビルドにant使いたくない。 何かいいビルドツールないかと調べてみた。その結果かなりたくさんあるよ うなのだけれど、SCons,Rakeといったツールが有望そう。 build - SWiK ビルドツールがわらわらと列挙されている。いいのが見つかるかも。 steps to phantasien t(2006-09-01) SConsをお使いのようだが、rakeについて調べられている。とは言え、 rakeのソース解析だったりするのだけれど。 Radium Software Development::SCons 上記記事にて参照されている。SConsの紹介。 nDiki: GNU Make Build
Google-perftoolsを使ってCPUプロファイリングをとる - PS3 Linux Information Site / Cell/B.E.のパワーを体験しよう
google-perftoolsとは グーグル株式会社で開発、公開されている高速mallocやCPUプロファイリングと解析などを行うオープンソースのツール群です。 こここではサンプリングベースのCPUプロファイラーである cpu profiler を紹介します。 cpu profilerはアーキテクチャーに依存しないLinux用ソフトウェアなので当然Cellでも使用することが可能です。 ここでプロファイルの測定対象としたソースコードはこれです。 Media:Google-perftools-cpuprofile.tar.gz google-perftoolsのインストール google-perftoolsはこちらからダウンロードできます。http://goog-perftools.sourceforge.net/ バイナリパッケージ(*.rpm)はないのでソースをダウンロードしてコンパ
怠訳 - TDDはもう古い!これからはADDだ! : 404 Blog Not Found
2007年06月21日04:30 カテゴリ翻訳/紹介Art 怠訳 - TDDはもう古い!これからはADDだ! こいつは厄さずにいられない。 scottberkun.com ? Blog Archive - Asshole driven development くそったれ駆動開発 - Asshole Driven development (ADD) チーム一のくそったれが、重要事項を全て決断する開発手法。理も知も技も、くそったれ殿が部屋にお出ましになるやいなやゴミ箱行き。くそったれ殿の詈と痴と偽が職場を支配する。いや、ちっとは知も技も残っているのも知れないが、ク氏の手にかかれば千の風になって飛んで行く。 認知的不協和開発 - Cognitive Dissonance development (CDD) どんな現場においても、ソフトウェアのあるべき姿に関して相反する理想が拮抗しているが、個々の
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> `���U ��'��U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
Joel on Software - ジョエル・テスト
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある？かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った！そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか？ １オペレーションでビルドを行えるか？ 毎日ビルドを行うか？ 障害票データベースを持っているか？ 新
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユーザーの希望とは逆に進む: ある nakagami の日記