タグ

ドキュメントに関するk1takeのブックマーク (5)

  • Springのドキュメントの探し方 - 日々常々

    私のね。 三行で Single page HTML でページ内検索する。 Googleでは site:https://docs.spring.io/spring-boot/docs/current/ を検索条件に含める。 GitHubの spring-projects で in this organization で検索する。 蛇足 該当ツイート、発端はbouzuyaさんのクイズ です。 Springのドキュメントは充実していて、欲しい情報はだいたいどこかに書かれています。機能についても使い方についてもどうすればいいのかなども書かれています。なんだけど、できることがたくさんあるうえに一つのことをいろんなやり方でできるため、できることが限定されたものと比べると初見の人が目的のドキュメントにたどり着くのは難しいと思います。 情報はないわけではなく、たいていのものは https://spring

    Springのドキュメントの探し方 - 日々常々
  • チームのScrapbox3000ページくらいを見返して整理した - hitode909の日記

    会社でScrapboxを使っている。チームごとやプロジェクトごと、話題や趣味ごとにプロジェクトを作っていて、うちのチームは1年3ヶ月くらい使って3000ページほどに達している。 どんどん書いていたのだけど、最近、どこに何があるかわからなくなってきていた。同僚に、ここの仕様はどうでしたっけ、って何度も聞いてしまうことがあったので、これはまずいと思ってちょっと整理していた。 表記揺れを直す One Fact in One Placeということで、どんどんページをマージしていった。ページを同名にリネームするとマージボタンが出現して押すだけなので楽。 よくみるとスペースの有無によって同じ話題のページが2ページに分かれていたり、略称と正式名称と、「(正式名称)まとめ」の3つにわかれたりしていた。情報を探しているときにはどんどんマージしたりしないので、今回マージするぞと見返せてよかった。 サポート担当

    チームのScrapbox3000ページくらいを見返して整理した - hitode909の日記
  • スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ|Anno Takahiro

    ドキュメント文化は健全な組織のスケールのために必要 組織の中でドキュメント/文章を残し活用していくことはとても重要だ。クオリティの高いドキュメントがあることで、組織に情報が流通し、透明性を確保できるようになる。情報を流通させるためにいちいち口頭の説明がいらないから、メンバーの数が増えた時でもスケールしやすくなる。過去の結論にアクセス可能になるので、議論を積み上げていき、意思決定のクオリティを高めることにもつながる。そもそも何かを読むということは何かを聞いて教わるよりも時間あたりの処理量が多いし、非同期に実施できる。良いドキュメントをアセットとして社内に蓄積していくことはスタートアップのみならず、ありとあらゆる組織が成長していく上でとても重要であると言える。 しかしその一方で、良質なドキュメント文化を徹底できている会社は多くないように見える。例えば、社内のドキュメントを蓄積させていく場所とし

    スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ|Anno Takahiro
  • ログ設計指針

    概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応

    ログ設計指針
  • 【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO

    はじめに こんにちは植木和樹@上越妙高オフィスです。日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 (この記事を読むのにかかる時間の目安:5分) 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1

    【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
    k1take
    k1take 2016/06/30
    ここ超大事「最初から完璧を求め過ぎると「ドキュメント書きたくない → 書かない → 属人化」の悪循環にはまってしまいます。まずは作業メモレベルで良いのです。」
  • 1