結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
エンジニアのための、いますぐ使える文章校正テクニック - ICS MEDIA
ウェブ制作や開発の仕事で文章を扱う機会は多いはず。書き手は不自然に思っていない文章でも、読み手は違和感をもっていることがあります。文章校正テクニックを覚えるだけでおかしな表現は少なくなり、読みやすい文章を書けるようになります。 本記事では、ICS MEDIAで実践している文章校正の一例を紹介します。 レベル1、基本的な校正ルールを使う いろんな場面で使える基本的な文章校正テクニックから紹介します。 テクノロジー系の名詞は正しく記載しているか テクノロジー系の名詞を間違って使うと、「本当に技術に詳しいの？」と読者からの信頼度が下がります。名詞は大文字小文字、スペース有無含めて正確に記述しましょう。 Github → GitHub（Hは大文字） Javascript → JavaScript（Sは大文字） After Effect → After Effects（複数形の「s」を忘れてはいけな
ARCHITECTURE.mdというものを書いてみた - maru source
こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru
Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
Docker ドキュメント日本語化プロジェクト — Docker-docs-ja 24.0 ドキュメント
注意 このサイトは Docker 公式ドキュメントを有志で日本語に翻訳しています。各ページの情報が古い可能性があるため、最新のドキュメントは https://docs.docker.com/ をご覧ください。 DISCLAIMER: This site is translating the official Docker documentation into Japanese by volunteers. As the information on each page may be outdated, please refer to the latest documentation at https://docs.docker.com/ . 注意 Docker v24.0.x (current) 向けにドキュメントの改訂作業中です(2023年7月現在)。一部古い場合がありますので、ご注意く
ドキュメントのレガシー化、忘れていませんか？ APIマニュアルWEB化までの経緯
こんにちは。kzhirata@QAです。連休が近づいてきましたね。 今年の2月から部署移動したせいか、今年は暦通り休めそうな気がします。 （何か最近、ブログ書いているのQAの人が多い気がする...） 今回はテストに関する話ではありません。 今までGoogleDocsからPDFを作成していたAPIドキュメントをGithub Pages上にWEB化したことについてお話しします。現在、まだ完成していないので実際のWEBページのURLはお見せできませんが、下記キャプチャでイメージを掴んでいただければと思います。 現在、APIドキュメントは400ページ近くとなり、1つのGoogleDocsファイルにまとめきれなず、GoogleDocsのファイル数が10個以上となっています。 いわゆる「コードがレガシー」ならぬ「ドキュメントがレガシー」と化しています。 そんな状況で以前からAPIドキュメントをWEB化
Java SE 日本語ドキュメントの置き場所 - torutkのブログ
職場で隣席の同僚から、Java SEの日本語ドキュメントどこでしたっけ？ と聞かれてとっさに回答できませんでした。 昔はJDKダウンロードサイトのドキュメントのところに英語版と日本語版が並んでいたのですが、現在はU.S. Oracleのサイトではなく、日本オラクルのサイトに置かれています。 Webを検索してもなかなか一発では辿りつけないので、辿る道筋をちょっとメモしておきます。 まず、OTN Japan（Oracel Technology Network）のトップページに行きます（次のURL）。 http://www.oracle.com/technetwork/jp/index.html 次に、このページの割と上にある[Javaテクノロジー]のリンクを辿ります。画面キャプチャを次に示します。 [Javaテクノロジー]リンクを辿ると次のURLとなります。ここは日本オラクルの技術者向けJav
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
PostgreSQL Internals
本コンテンツは、2014年1月30～31日に筑波大学で開講された「情報システム特別講義D」における講義「Inside PostgreSQL Kernel」の内容を再構成、加筆・修正したものです。 はじめに 本コンテンツについて 本コンテンツへのフィードバックについて アーキテクチャ概要 PostgreSQLの構成要素 PostgreSQLの基本的なアーキテクチャ SQL文の処理される流れ トランザクション管理 トランザクション処理におけるACID特性 各レコードの可視性の管理 Atomicity（原子性）の実装 Consistency（一貫性）の実装 Isolation（分離性）の実装 トランザクション分離レベルの定義 Durability（永続性）の実装 チェックポイント メタデータ管理 pg_controlファイル OID/XID/TID システムカタログ MVCCとストレージ構造 テ
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
OpenStack 情報をどこから得ているの？ - ishikawa84g's blog
2013-12-02 OpenStack 情報をどこから得ているの？ OpenStack OpenStack Advent Calendar 2013 JP : ATND 2日目、23時38分現在今日が終わってしまう！間に合わなそう！ということで2秒で考えて20分で書き上げます。@代打 毎日OpenStackだけをやっている私ですが、どこから情報を得ているのかをまとめてみます。間に合え。 公式情報 Home » OpenStack Open Source Cloud Computing Software いわずと知れた本家です。ここからはじめましょう。 OpenStack Wiki OpenStack wiki ここに仕様だったり使い方だったりがあります。たまに議論の途中経過が書かれていたりしてどれが本当かわからないこともあります。 open OpenStack Docs: current
Erlangユーザーズガイド — Erlang User's Guide v5.8.1 documentation
システム原則¶ Erlangのシステムを作って、インストールして、稼働させるまでの流れが書かれています。 なお、後半は systools を使って targetsystem というリリースツールを作るという話になっていますが、現在のErlangの方向性としては、 systools の代替として、 reltools を開発している(ただし、まだ万全ではない)という流れになっているとのこと(V談)。そのため、リリースの流れを知る、という意味あいで読むのが良いと思います。詳しくは reltools のドキュメントを参照してください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft AI Cloud Partner Program - Microsoft Partner blog
Download Microsoft Azure 自習書一式 from Official Microsoft Download Center
Clusters from Scratch
High Availability Add-On の管理 Red Hat Enterprise Linux 7 | Red Hat Customer Portal
High Availability Add-On リファレンス Red Hat Enterprise Linux 7 | Red Hat Customer Portal
サクサク引ける Rubyリファレンスマニュアル
http://blog.inouetakuya.info/entry/2013/10/20/132928
