タグ

2010年8月7日のブックマーク (11件)

  • ドキュメントレビューをする際の10のポイント | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 重厚長大なドキュメントは、動かなかったり嘘が書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで辛いことが多いのが現状です。 今回とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみます。 なお、個人的には、ドキュメントレビューよりソースレビューの方が重要だと思っています。 とはいえドキュメントレビューで肝心なのは、 ドキュメントレビューをするなら、その投資に見合う何を得るのか?を決めておく必要がある当にそのドキュメントは必要か?をよく考える(会社のルールだから!というのは理由にはなっていない)だと思います。 レビューのポイント1. 体裁をレビューするのではなく、中身をレビューするひどい現場だと、文書のインデントやフォントのサイズ、誤字脱字ばかりを重箱の隅をつつくようにチェッ

    ドキュメントレビューをする際の10のポイント | Ryuzee.com
  • Adobeの有料ソフトを買う前に、代替になる無料ソフトでコツを掴もう・使い方まとめ

    オープンソースデザイン等に一般的に利用されている PhotoshopやDWなどのAdobe製品は 高機能で仕事では必須のツールです。 しかしながら高額で、手軽に購入出来る という訳には行きません。無料で手に 入る代替ソフトがありますので、まずは コツを掴むのにフリーソフトから使って みてはいかがでしょうか。 デザイン等に一般的に利用されているPhotoshopやDWなどのAdobe製品は高機能で仕事では必須のツールです。しかしながら高額で、手軽に購入出来るという訳には行きません。無料で手に入る代替ソフトがありますので、まずはコツを掴むのにフリーソフトから使ってみてはいかがでしょうか。 全く同じとは行きませんが、例えばPhotoshopの代替ソフトとして有名なGIMPはPhotoshop専用の拡張子であるPSDファイルも開く事が出来ますし、GIMPで作ったファイルをPSDに変換する事も可能で

    Adobeの有料ソフトを買う前に、代替になる無料ソフトでコツを掴もう・使い方まとめ
  • 函館に行くんだけどおすすめの観光地とか:ハムスター速報 - ライブドアブログ

    函館に行くんだけどおすすめの観光地とか カテゴリ☆☆☆☆ 1 :名前:以下、名無しにかわりましてVIPがお送りします:2010/05/06(木) 13:08:51.01 ID:uCUXMYE70 べ物とか店教えてくんろ 2 :名前:以下、名無しにかわりましてVIPがお送りします:2010/05/06(木) 13:09:47.97 ID:OIRcPjEW0 そんなものは存在しない 3 :名前:以下、名無しにかわりましてVIPがお送りします:2010/05/06(木) 13:10:48.27 ID:uCUXMYE70 >>2 いや何かあるだろw 11 :名前:以下、名無しにかわりましてVIPがお送りします:2010/05/06(木) 13:19:21.20 ID:OIRcPjEW0 函館にはなんにもないってのが定説 かろうじてセブンイレブンがあるぐらいだ 13 :名前:以

  • SIerはいまさら内製化できるのか? - Sacrificed & Exploited

    若い時にプログラムを書こう、必ず人生の豊かさにつながる | 日経 xTECH(クロステック)より 開発者はどこへ消えた ずっと気になっていたのだが、そもそもNTTデータの社員は開発をしているのか。 非常に危機感を持っていて、現状は何しろ内製率が低い。正直にお話すると全部合わせても3割とか3割5分ぐらい。残りは協力会社の方々に手伝ってもらっている。するとどういうことになるか。自分でコーディングしたり、ドキュメントを書いたりするより、コーディングする人たちを管理する仕事になってしまう。 いっぽう増田では、 日のメーカー終了間近? もう日のメーカーのほとんどに、担当者は居ない。 製品のメイン開発者のほとんどが、社内に居ないのだ。 - 俺はプログラマー。 長年、とある組み込みマシンのメインプログラマーだった。詳細仕様、プログラムの細部、それらは全て資料化されているものの、膨大な量と難易度の為、

    SIerはいまさら内製化できるのか? - Sacrificed & Exploited
  • 設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited

    SIerの常識:「誰が書いても同じソースコードになるように、詳細な実装方法の記述された設計書を書かなければならない」 プログラマの常識:「誰が書いても同じソースコードになるような設計書は書くだけ無駄、誰が書いても同じ振る舞いをするように、詳細に振る舞いを記述した設計書を書かなければならない。」 プログラムを作るうえで設計書や、仕様書の類は欠かすことができない だが、設計書や仕様書をちゃんと作っているプロジェクトでもよくデスマーチに陥っている。 なぜか?「設計書に記載するべき内容が間違っている」からだ。 (設計が間違っている場合も多々あるが。) 間違ったことをまじめにやっても良い結果は得られない。 「誰が書いても同じコード」は大事なことなのか - yvsu pron. yas 昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、そ

    設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited
  • 詳細設計書に何を書くべきか? - Sacrificed & Exploited

    詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと1対1に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容(内部の処理の実装方法)の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、

    詳細設計書に何を書くべきか? - Sacrificed & Exploited
  • 手順書の鉄則 - Sacrificed & Exploited

    ビルド手順書だったり、モジュールの配備手順書だったり、そういった手順書を書くときに気をつけている事を勝手に列挙します。 はじめに 手順書を実施するうえで、最大の敵になるのがヒューマンエラーです。 ヒューマンエラーをなくすには、完全に自動化してしまえばいいんですが、そこまで出来ない場合でも最低限守った方がよい事をのべます。 よくあるパターンが コマンドの入力ミス 手順を飛ばした 配布先を間違えた などです。 1.手順書の実施順序は最初から最後まで一方向に読めるようにしておく たとえば、同じ手順を複数の箇所で実施させる場合、 ここでXXページの○○手順を実施する。 などといった前の手順に戻って実施させるような記述は避けましょう。 途中で手順をさかのぼって実施させると、いまどこの手順を実施しているのか分からなくなり、ある手順がスキップされてしまう確率が上がります。 めんどうですが、コピーペースト

    手順書の鉄則 - Sacrificed & Exploited
  • コードは読めなければならない - idesaku blog

    ストレス発散がてら書いたネガティブな愚痴り記事が思いの他ブクマしていただくことになり驚いている。みなさん苦労されているようですね。コメントなども多数頂戴したので、調子に乗って返答記事などポストしてみる。*1 コードは読めなければならない 自分のスタンスを明確にしておこうと思う。 コードは読めなければならない。*2 UKTKKNSHINFがダメな理由は、それが読めないからである。頑張って慣れれば読めないこともない、というものは話にならない。容易に読めなければならない。 それに規則性があるなら他のプロジェクトにも転用できない?母音抜きルールを。 他に転用できるんだったら、全社的な生産性向上に寄与できるんじゃないの?母音抜きルールで。 UKTKKNSHINFコンバータ作りました、それとUKTKKNSHINFってそんなにひどい? | さくらたんどっとびーず 規則性があればよいのであれば、プログラミ

    コードは読めなければならない - idesaku blog
  • Code Complete第2版—完全なプログラミングを目指して - idesaku blog

    Code Complete第2版〈上〉―完全なプログラミングを目指してSteve McConnell クイープ 日経BPソフトプレス 2005-03 売り上げランキング : 31002 おすすめ平均 プログラマになるつもりなら、まず読もう 初心者に 入門書でありながら奥が深い Amazonで詳しく見る by G-Tools Code Complete第2版〈下〉―完全なプログラミングを目指してSteve McConnell クイープ 日経BPソフトプレス 2005-03 売り上げランキング : 23113 おすすめ平均 必携&必読すべき良書 プログラマ必須の 第1版とは趣が違う感じです Amazonで詳しく見る by G-Tools やっと・・・やっと読み終わった・・・。エンジニアのバイブルの一つ、スティーブ=マコネル渾身の『Code Complete』の第二版、上下巻!分厚かった!濃か

  • ご冗談でしょうSIerさん その4 - Sacrificed & Exploited

    「ソースコードの修正履歴をコメントアウトでのこしてください。」 当に冗談であって欲しかった。一体何のためにCVSとかsubversionを使ってんだよ! 最終的には、なんとかファイルヘッダへの修正履歴の追加になったけれども、これを聞いたときはいまだにこんな管理をしているSIerが存在することに絶望した。 理由を聞いてみたら、「番機で編集するときに、前の修正履歴が参照できないと困る」っていってたと思うけど、「それはないわー」って言いそうになった。 そんなこったから、番機とソースコードレポジトリに入ってるバージョンがずれて、どれが最新なのかわかんなくなってんだよ!!

    ご冗談でしょうSIerさん その4 - Sacrificed & Exploited
    sinsengumi-2
    sinsengumi-2 2010/08/07
    [for:@twitter]ソースコードの修正履歴をコメントアウトでのこしてください。
  • ヒューマンエラーの理論と対策

    ヒューマンエラー・人的過誤の理論と防止