Google Documentを「ページ分けなし」にするとメモに便利
タイトルがすべてなのですが意外と知られていないのでご紹介します。 Google Documentをメモとして使う時は、メニューの「ファイル」→「ページ設定」から「ページ分けなし」を選択すると便利です。 Google Deocumentをメモに使ってる人は多いんじゃないかと思います。Chromeだけで使えるし、複数人での編集もできるし、ミーティングの議事録作成なんかにすごくいいツールですよね。 議事録のような「印刷を前提にしない用途」であれば、メニューの「ファイル」→「ページ設定」で「ページ分けなし」を選択してみましょう。 デフォルト設定デフォルトでは「ページ分けあり」かつ表示モードが「印刷レイアウトを表示」になっているため、ページの区切りと余白が表示されています。 「印刷レイアウトを表示」しないこのチェック「表示」メニューからオフにすると、ページ区切りの余白が消え、連続したドキュメントとし
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
Overview — Sphinx v1.0 (hg) documentation
ダウンロード このドキュメントはバージョン1.0 (hg)のためのものです。まだリリースされていません。 Mercurialリポジトリのコードを利用するか、Python Package Indexにあるリリースバージョンを探してください。 疑問? 意見? Googleグループへの参加: もしくは、FreeNodeの#python-docsチャンネルへどうぞ 何か気づいたことがあれば、issue trackerを使用して通知することもできます。 Sphinxは知的で美しいドキュメントを簡単に作れるようにするツールです。Georg Brandlによって開発され、BSDライセンスのもとで公開されています。 このツールはもともと、新しいPythonのドキュメントの変換のために作られました。そして、今までに数々のPythonや、他の言語で開発されているプロジェクトに対して、すばらしいドキュメンテーシ
［データ設計］マスター系と更新系を明確に分ける
福士有二 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 データ設計の肝になるのは，データの最小単位であるデータ項目と，データ項目のまとまりと関連を示した論理データ・モデルである。画面設計や業務プロセス設計より先に設計作業を進め，追加や変更がある場合は速やかに対処することが肝心である。 図6に示したのが，データ設計で作成する設計書とその関係である。大きく分けて「(1)設計基準作成」「(2)データ項目設計」「(3)データベース論理設計」という三つのステップがあり，全部で8種類の設計書を作成する。要件定義で作成した「業務用語集」「概念データ・モデル」「データフロー図（DFD）」を用意しておこう。図7と照らし合わせて読んでほしい。
［業務プロセス設計］シナリオにボタン名やタブ名を書かない
後藤卓司 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 業務プロセス設計では，システムの動き（振る舞い）を明確にする。ここでは「(1)業務フロー設計」と「(2)ユースケース分析」というステップを踏み，5種類の設計書を作成する（図4）。要件定義で作成した「業務流れ図」「業務機能階層図」「業務用語集」「アプリケーション機能一覧」を用意しておこう。図5と照らし合わせて読んでほしい。 (1)業務フロー設計では，業務機能がどのような組織，手段，手順で処理されるのかを記述した「業務流れ図」と，業務全体を大機能，中機能，小機能に構造化した「業務機能階層図」を作成する。 要件定義でも業務流れ図や業務機能階層図を作成しているが，これらはユーザー側の視点で記述されているものだ。業務フロー設計ではこれを，開発者側の視点で書き直すことになる。その際，次の3点に注意する。 一つ目は，それぞれ
ウノウラボ Unoh Labs: テスト計画書のテンプレート
こんにちは！やまもと＠テスト番長です。 巷ではインフルエンザが流行っているようですが、皆さんお元気にお過ごしでしょうか。 さて、プロジェクトが立ち上がったとき、（特に受託案件の場合） テストのドキュメントはどうしようか？という話が出ると思います。 適当にやる訳にも行かないけれどIEEE829をベースにしたものだと重かったり、割と迷う部分です。 英語ですがテスト計画のテンプレートを配布しているサイトがあったので、ご紹介してみます。 Pragmatic Software http://www.pragmaticsw.com/ Software Development Templates http://www.PragmaticSW.com/Templates.asp テスト計画書 Test Design - http://www.pragmaticsw.com/Template_Te
Software Planner: Award winning Application Lifecycle Management (ALM) tool
Software Planner: Award winning Application Lifecycle Management (ALM) tool If you have problems viewing this area please check if you have a flash player installed on your computer. You can get the latest version of flash player here: http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&promoid=BIOW If the flash player is installed your browser might be not support
仕様書をExcelで書くんじゃねぇ:アルファルファモザイク
>>3 ていうかエクセルで印刷するのはキツイ。txtのほうがまし。 平均１０ページ×３０シート×５０ファイルなんて泣きたくなるぞ。 そのうえ印刷するとあちこちのセルが欠けるもんだから、徹夜で直したことがある。 個人の資料ぐらいならいいけど、人に渡すつもりならホント止めてほしい。
知っ得納得Webフレームワーク#01 - よねのはてな
フルネスさんの会場をお借りして、Webフレームワークのセミナーを開催しました。 私はTeedaを担当したのですが、TeedaよりもJSFの話し中心でソースコードを見ながら進めました。 JSFのjspやfaces-config.xmlの記述は、新鮮だったのではないでしょうか。 S2Flex2は盟友のid:c9katayamaが担当しました。 資料はslideshareにあげてあります。 TeedaView SlideShare presentation or Upload your own. (tags: java teeda) S2Flex2View SlideShare presentation or Upload your own. (tags: flex seasar) 今後、2回3回と開催されますので、皆さん奮って参加下さい。 懇親会では、id:kaisehさんと毎回熱い話しで盛り
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
ツールを使ったドキュメント作成技法（前編） － ＠IT
特集：ツールを使ったドキュメント作成技法（前編） 価値のある開発ドキュメントを効率的に作成するには？ アバナード株式会社 市川 龍太（Microsoft MVP 2008 for XML） 2008/05/20 システム開発の現場では、さまざまなドキュメントを作成する必要がある。しかし昨今では開発の短期化に拍車がかかっており、ドキュメントを作成するための工数を十分に取れないことが多くなってきている。そこで本稿では、限られた工数の中で価値のある開発ドキュメントを効率的に作成するための技法について解説していく。 本題に入る前に、まずウォーターフォール型開発の各フェイズにおいて、一般的にどれだけのドキュメントを作成する必要があるのかについて以下の表にまとめてみた。
[Think IT] 第2回：「どんなシステムを作るのか」をJavadocで表現する (1/3)
Javadocの機能は、ソースコード中の「/**」と「*/」で囲まれたドキュメンテーションコメントから、リファレンスドキュメントを生成することでした。ソースコードとドキュメンテーションコメントが一体になっているため、開発者は設計を考えながらソースコードを書き、その設計内容をドキュメンテーションコメントとして残すといった一連の流れをソースコード上で行うことができます。 Javadocは、標準クラスライブラリのリファレンスドキュメントを見れば、クラスやメソッドの使い方を理解するのにとても役に立つことはわかります。しかし、システム開発現場のドキュメントとしては、それだけでは不十分です。 Javadocに足りないのは「ソースコードが正しいか」ということを表現できないことです。正しさを確認するには2つの視点があります。1つは「どんなシステムを作るのか」という視点。もう1つは「どのように検証するのか」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Payara Documentation
オープンソースソフトウェアの育て方
ほんのすこし書き方に注意すれば、あなたのドキュメントはさらに分かりやすくなる！
［画面設計］画面の構造は物理的・論理的に示す
ドキュメント作成に役立つ「日本語スタイルガイド」の紹介