IPA セキュア・プログラミング講座IPA 独立行政法人 情報処理推進機構 セキュリティセンターによるセキュア・プログラミング講座：Webアプリケーション編 & C / C++言語編
過去10年間のComputer Science系論文で被引用数トップ10を作ってみた - 情報科学屋さんを目指す人のメモ（FC2ブログ版）
何かのやり方や、問題の解決方法をどんどんメモするブログ。そんな大学院生の活動「キャッシュ」に誰かがヒットしてくれることを祈って。 2000年以降の論文に限定して、 CS系論文の被引用数ランキングを作って分析してみた。 この作業を通じて予想以上に得るものがあった。 ランキングの作り方 CiteSeerXが公開している「Most Cited Computer Science Articles (2010/9/14)」を元データに採用した。 ここから2000年以降の文章に限定した後、ハンドブックや雑誌記事などを取り除いて論文だけのランキングを作成した。 被引用数は時間が経つほど増える一方なので、2000年・2001年あたりの論文が有利であることに注意する必要がある。 ただし、このことがかえって得るものを増やしてくれた。 アブストラクトをチェック 良い機会であるので、 各論文の概要や結論をチェック
ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側）
どうも、鈴木です。 さて、前回は vim の使用法というじつに低レベルレイヤの出身者的な記事を書きましたが、 今回も懲りずに低レベルのお話しをしたいと思います。 というのも、先日「ブログ書くのめんどくさいよぅ」と駄々をこねていたところ、あまりにレガシーすぎる HTML/CSS/JavaScript 仕様や Flash や Silverlight といったプロプライエタリなリッチコンテンツ用プラグインに日々苦しめられている気弱く善良な一介の WEB プログラマにすぎない我々の希望の星であり、そして同時に新たな巨大クソレガシーの萌芽でもある HTML5 が、いかにイケてないのではなくイケているのであるかを盛んに啓蒙するサイトである HTML5 Rocks (http://www.html5rocks.com/) に、"How Browsers Work" というとても楽しい記事があるのを、我が
メンテナンスに必要な設計書を、出来上がったシステムから考えてみる。 - レベルエンター山本大のブログ
かなり前のひがさんのブログを引用 仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 さて、メンテナンスに必要な設計書ってどんなだろうか。 出来上がったシステムを見ながら考えてみる。 機能概要は必須 機能の概要がわかるものが欲しいけど、 ”機能”の一覧よりは、”要件”の一覧が良い。 例えば、「商品マスタデータのメンテナンス機能」だとしたら、 登録ボタンを押したら、画面の入力に従って商品データが登録される その際に、商品テーブルと価格テーブルと価格履歴テーブルにデータが登録される
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
Excelの表（QA表, 不具合表... etc）を、すごく検索しやすくするツールを作りました。 - 地平線に行く
最近、仕事でやたらExcelを使うようになったので、こういうツールを作ってみました。 Excelインクリメンタルサーチ Excelの表を、すごく検索しやすくするツールです。 （QA表, 不具合表... etc） サンプルはこちら！ このツールを使うと、Excelの表をブラウザ上で素早く、わかりやすく検索できます。 データの自動変換スクリプトがついているので手間はほとんどかかりません。 また、複数のファイルにまたがるような場合でも、簡単に検索できるようになります。 日頃、Excelでバリバリ仕事をこなさなきゃいけないSIerの方にうってつけのツールです。 ぜひ、ご利用ください！ ダウンロード：ダウンロード - 地平線に行く 紹介ページ：Excelインクリメンタルサーチ - 地平線に行く 経緯 お客様とのやり取りは、どうしてもExcelで情報をやりとりしなくてはいけません。 しかし、Excel
そのシステムの常識をサンプルコードに語らせろ - レベルエンター山本大のブログ
システムの仕様について、常識として通用してしまっている部分があると 新規参入者は非常に困るということを実感した。 こういうときに、メンテナンスされているかどうかわからない設計書はあまり役にも立たないし、 その人が常識だと思っていることまでは設計書に書いてくれないから 実装のサンプルコードを残しておいてくれたら良いのにと思う。 以下に、少し脚色して例示する。*1 あるシステムでは、”当年”といえば”日付マスタ”の”当年度”の値だった。 これはよくある仕様だが、初心者だと知らずに new Date(); をする人もいる。 こういう共通処理は、どうせ共通処理クラスがある。 サンプルとして、以下のように残しておいてくれたら読んで分かる。 int year = jp.co.exmple.DateUtil().getCurrentYear(); 設計書はシグネチャが変わったときとか、メンテが面倒だけど
コーディング規約を考える前に - rabbit2goのブログ
開発プロジェクトのコーディング規約をどうすべきか相談を受けることがある。コーディング規約なんて探せばいろいろ出回っているし、自分たちでゼロから作っても良いとは思うけど、この数年はいつも下記のように答えることにしている。 「Code Completeを読め。この内容を全て実践してもまだ問題が残るのなら、改めて相談に乗る」 この本にはコーディング規約だけではなく、基本的な設計手法、適切な関数の行数、変数の命名規則、複雑化するソフトへの対処、バグを出さないための考え方など豊富な指針が大変細かく記載されており、ソフトウェア開発者のバイブルと言っても良い本だ。ソフトウェア開発者ならこの本に書かれている程度の事は理解していて欲しいし、理解しておくべきだと思う。上下巻に載っている情報量は膨大なものがあるけど、開発者にとっては全て重要なガイドラインであり、不可欠の内容と言っても過言ではない。 使用する開発
仕様書をSubversionとTracで管理する - rabbit2goのブログ
議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、WordやExcelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。 仕様変更の確実な履歴管理 Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い（誰かが変更箇所を承認してしまった等）ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。 ソー
全ての仕様にURLを付けたらどうか？ - rabbit2goのブログ
tracの障害チケットに目を通していたら、該当する仕様としてこんな記載が載っていた。 ○×仕様書の□ページの上から△行目に記載されている〜について... 大きな偏見だと思うけど、Word等で記載されたダラダラとした文章が並ぶ仕様書を見ると「これは要注意」という黄色いランプが点滅してしまう。複数のセンテンスから成る文章全体で一つの仕様が構成されるという趣旨は分かるけれど、そもそも「どこからどこまでが一つの完結した仕様」なのか分からないし、他の資料との紐付けがやりにくい。例えば、上記のような書き方では、資料に追記・削除が行われたらレイアウトが崩れ、意味を成さない記述になってしまうので、後から見た人は関連する箇所を辿れないことになる。 仕様書は小説でもエッセイでもないのだから凝った表現は不要であり、もっと形式的な書き方に力を注ぐべきではないかと思う。だから仕様書の記載では章立てを確実に行い、個々
設計書が必要な理由 - rabbit2goのブログ
「ソースコードが設計書。だから別の設計資料なんか要らない」と言っている人がいた。Webでも同じような見解を見ることがあるし、こんな運用ルールで事足りる開発現場も有るのだろう。確かにこれはこれで一理あると思う。私だって個人的に作っているソフトに、必ずしも設計書を作っているわけではない。 しかし、100万行単位のレベルで組織的にソフトウェア開発を行っている現場（うちのことだ）では、こんなやり方は通用しない。理由は下記の通り。 ある機能が100万行のソースコードの何処に入っているか分からない。 そもそも、ある機能が100万行のコードの中に含まれているのか分からない。 機能追加・変更・修正に伴う影響範囲が、100万行のコードの何処まで及ぶのか分からない。 例えば、開発現場に入ってきたばかりの協力会社の人に応援を頼む場合、100万行というコードの海を直ぐに泳げと言うのは、無理な相談だろう。そこで作業
Redmine導入はERP導入に似ている #tidd - プログラマの思索
Redmine導入はERP導入に似ているなと思ったのでメモ書き。 【元ネタ】 Twitter / @akipii: @naitoh Redmineを導入しても、ガントチャートのPDFや課題一覧のExcelを綺麗に出したい要望はPM層に多いです。Redmine導入はERP導入に似てますね。顧客と同様、PMも帳票(紙)にこだわっている。#redmine Twitter / @akipii: @naitoh 僕もはまりました。でもRedmine XLS Export pluginは苦労してインストールする価値があります。チケットの属性を選んでExcel出力できるので、課題一覧が欲しいPMにうってつけです。#redmine Twitter / @akipii: Redmineを導入して使いづらいと言う人達は、アンチパターンの罠にはまっている時が多い。この辺りの事例をまとめてみたい。チケット駆動開発
sphinx + blockdiag で始めるドキュメント生活 2011/05 yokohama.pm
2016年7月のささみの会で発表した内容です。 当たりさわりの無い Sphinx についての紹介をしています。
「それ、どうやってテストするの？」（続） - masayang's diary
http://d.hatena.ne.jp/JavaBlack/20070808/p1 ほとんどのまともなプログラマーなら，無意識のうちにそういうテスト可能／デバッグ可能なコードを書くことを心がけている．テスト／デバッグ不可能なコードを書く人というのは，まともなプログラマとは思えない． JavaBlackさんは「自分で何を作るか考えてコードを書く人」について語っているとみた。完成像を理解しているプログラマなら、「コードのあるべき姿」もわかっているからテスト機械化のハードルも低いだろう。 問題なのは下記のような分業状況。 何を作るかは考えるけどコードは書かない人（別名：設計担当） 何を作るか考えることは許されず、言われたとおりにコードを書く人（別名：開発担当） 設計担当はコードを書くことはない。書くのは設計書なる文書だけ。「その設計書、どうやってテストするの？」と聞いてみるがよい。答えに窮す
細かいところまで指定する設計書は実在する。 - プログラマーm-matsuokaの生存記録
http://d.hatena.ne.jp/masayang/20070808/1186636298 「設計書」を書く人はコードの細かいところまでは考えていないから 詳細設計書と称して、日本語で1行ずつ処理を記述して、その1行ごとに対応するようにソースを書かせる。 で、その詳細設計書とソースを1行ずつ照らし合わせて、詳細設計書のとおりにソースが書かれていないと作り直しさせられる。という地獄のようなプロジェクトがありました。 詳細設計書で処理が100行で記述してあれば、ソースも100行でなくては駄目だという…。複数の詳細設計書に同一の10数行程度のチェック処理がコピペで書いてあれば、ソースにも同じチェック処理がコピペで並ぶ。 プロジェクトの統率者がホストあがりで、ホスト開発で実行していた開発手順をStrutsでのWEBアプリ開発に無理矢理当てはめた結果らしい。 新卒という未経験者を3ヶ月の研
■ - ( ・ω・)ノ＜しすてむ開発。
「誰が書いても同じコード」は大事なことなのか http://d.hatena.ne.jp/higayasuo/20080325/1206421786 言葉だけの意味ならボクは「大事なことだ」と答える。 大手SIerにそれが実現できないのは方法がマズイから。 そこで出てきたのが、「誰が書いても同じコード」になることが重要で、 それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。 大手SIerは、大体同じことを考えていると思います。 見てきた中でこれ同意。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。 だからこれも同意。 「設計」の範囲がどーのこーのと論議のタネになることは多いけれど、 プログラム作り大好きニンゲンの1人として言えることがある。 (,,ﾟДﾟ)＜ドキュメントで何とかしようとしているのはみんな要求定義の一部だ。 システム開発
仕様書やプログラムを書く大変さ - GeekFactory
大御所のブログを引用するのはおそれ多いのですが、それでも元請けの視点で書きたいことがあります。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 http://d.hatena.ne.jp/higayasuo/20080414/1208155494 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラムをいきなりかけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
詳細設計書を残す意味は？ - T-1000の日記
詳細設計書について思うこと - ここにはいないボクへの伝言
ドキュメントを作りたくなってしまう魔法のツールSphinx
