サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
自身のプライオリティによりますが、いくつか。Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に:Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいならMarkdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png,svg, eps,pdf
ウェブ制作や開発の仕事で文章を扱う機会は多いはず。書き手は不自然に思っていない文章でも、読み手は違和感をもっていることがあります。文章校正テクニックを覚えるだけでおかしな表現は少なくなり、読みやすい文章を書けるようになります。本記事では、ICS MEDIAで実践している文章校正の一例を紹介します。 レベル1、基本的な校正ルールを使う いろんな場面で使える基本的な文章校正テクニックから紹介します。テクノロジー系の名詞は正しく記載しているかテクノロジー系の名詞を間違って使うと、「本当に技術に詳しいの？」と読者からの信頼度が下がります。名詞は大文字小文字、スペース有無含めて正確に記述しましょう。Github →GitHub（Hは大文字）Javascript →JavaScript（Sは大文字）Mac OS X → OS X →macOSiPad OS18 →iPadOS 1
こんにちは丸山@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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめにエンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習し
tag, and before any other scripts. Your first data will appear automatically injust a few seconds. -->
すべてのMicrosoft 製品 GlobalMicrosoft 365 Teams CopilotWindows Surface Xbox ブラック フライデー セール 法人向け サポート ソフトウェアWindows アプリAI OneDriveOutlook Skype から Teams への移行OneNoteMicrosoft TeamsPC とデバイス Xbox を購入する アクセサリ エンタメ Xbox Game Pass Ultimate Xbox とゲームPCゲーム 法人向けMicrosoft CloudMicrosoftSecurity Azure Dynamics 365 一般法人向けMicrosoft 365Microsoft IndustryMicrosoft Power PlatformWindows 365 開発者 &IT M
You have followed a link to documentation for Pacemaker versions that are no longer supported. Most likely, you want the current documentation. Otherwise, you can find older documentation below. Pacemaker 2.0 Clusters FromScratch demonstrates Pacemaker 1.1 (not updated for 2.0) with Corosync 2 Generated on Wed 02 Dec 2020 04:21:45PM EST from version: ba59be712 (HEAD -> 2.0, tag: Pacemaker-2.0.5,
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
注意 このサイトはDocker 公式ドキュメントを有志で日本語に翻訳しています。各ページの情報が古い可能性があるため、最新のドキュメントは https://docs.docker.com/ をご覧ください。 DISCLAIMER: This site is translating the officialDocker documentation intoJapanese by volunteers. As the information on each page may be outdated, please refer to the latest documentation at https://docs.docker.com/ .
Sign in - Google AccountsNot your computer? Use a private browsing window to sign in. Learn more about using Guest mode
職場で隣席の同僚から、Java SEの日本語ドキュメントどこでしたっけ？ と聞かれてとっさに回答できませんでした。 昔はJDKダウンロードサイトのドキュメントのところに英語版と日本語版が並んでいたのですが、現在はU.S.Oracleのサイトではなく、日本オラクルのサイトに置かれています。 Webを検索してもなかなか一発では辿りつけないので、辿る道筋をちょっとメモしておきます。 まず、OTN Japan（OracelTechnologyNetwork）のトップページに行きます（次のURL）。 http://www.oracle.com/technetwork/jp/index.html 次に、このページの割と上にある[Javaテクノロジー]のリンクを辿ります。画面キャプチャを次に示します。 [Javaテクノロジー]リンクを辿ると次のURLとなります。ここは日本オラクルの技術者向けJav
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある．プロジェクト，ツールの使い方，インストール方法プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
本コンテンツは、2014年1月30～31日に筑波大学で開講された「情報システム特別講義D」における講義「Inside PostgreSQL Kernel」の内容を再構成、加筆・修正したものです。 はじめに本コンテンツについて本コンテンツへのフィードバックについて アーキテクチャ概要 PostgreSQLの構成要素 PostgreSQLの基本的なアーキテクチャSQL文の処理される流れ トランザクション管理 トランザクション処理におけるACID特性 各レコードの可視性の管理 Atomicity（原子性）の実装 Consistency（一貫性）の実装 Isolation（分離性）の実装 トランザクション分離レベルの定義 Durability（永続性）の実装 チェックポイント メタデータ管理 pg_controlファイル OID/XID/TID システムカタログ MVCCとストレージ構造 テ
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under theCreative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available onAmazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see anerror or have a s
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のシステムを作って、インストールして、稼働させるまでの流れが書かれています。 なお、後半は systools を使って targetsystem というリリースツールを作るという話になっていますが、現在のErlangの方向性としては、 systools の代替として、 reltools を開発している(ただし、まだ万全ではない)という流れになっているとのこと(V談)。そのため、リリースの流れを知る、という意味あいで読むのが良いと思います。詳しくは reltools のドキュメントを参照してください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
