One space between each sentence, they said. Science just proved them wrong.
In the beginning, the rules of the space bar were simple. Two spaces after each period. Every time. Easy. That made sense in the age of the typewriter. Letters of uniform width looked cramped without extra space after the period. Typists learned not to do it. But then, at the end of the 20th century, the typewriter gave way to the word processor, and the computer, and modern variable-width fon
Lightweight Architecture Decision Records | Technology Radar | Thoughtworks
This blip is not on the current edition of the Radar. If it was on one of the last few editions, it is likely that it is still relevant. If the blip is older, it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the Radar. Understand more Adopt ? We feel strongly that the
GitHub - RichardLitt/standard-readme: A standard style for README files
Standard Readme started with the issue originally posed by @maxogden over at feross/standard in this issue, about whether or not a tool to standardize readmes would be useful. A lot of that discussion ended up in zcei's standard-readme repository. While working on maintaining the IPFS repositories, I needed a way to standardize Readmes across that organization. This specification started as a resu
RFP/SLA見本 - ITコーディネータ協会（ITCA）
ＩＴコーディネータ協会（以下ＩＴＣＡ）では、情報化資源調達フェーズ、情報システム開発・テスト・導入フェーズ、 運用サービス・デリバリーフェーズで作成する、 ＲＦＰ（Ｒequest Ｆor Ｐroposal ： 提案依頼書）、 および、ＳＬＡ（Ｓervice Ｌevel Ａgreement ： サービス品質合意書）の見本を開発し、提供いたします。 本ドキュメント見本は、ＩＴコーディネータ、ＩＴコーディネータ補の方々やＩＴ化を推進する経営者が、 ベンダーへ提案を依頼する場合に発行するＲＦＰ（提案書）および、ベンダーと契約を締結する際に発行するＳＬＡ（サービスレベル合意書）の、 記載見本の一例を提供するものです。見本としての記載内容をできる限り詳細にしましたが、 実際の使用に当たっては当見本にとらわれることなく開発規模等により割愛や簡易化をしていただいてくことを想定しております。 ＩＴコーディネ
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。 IT技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載「プロジェクト成功確率向上の近道とは？」では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。 連載1回の「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」、第2回の「サンプル例に見る
ドキュメントシステムはこれを使え2015年版
Sphinx Con JP 2015での発表 目的からドキュメントシステムを選べるYes/Noチャートは33ページにあります。 （当初アップロードしたものはこのページにミスがあったので差し替えています。高橋さんありがとうございます。）Read less
Design Driven API Development
This document discusses design-driven API development using API description languages like Swagger and RAML. It recommends generating documentation and code from a single API schema to avoid inconsistencies. This approach allows server code and related resources like SDKs and tests to be generated from the schema rather than developed separately. The document provides an example using Swagger-Node
My Future Sight for Past: 初心者にとってのLaTeXの問題点とLyXの紹介
この記事はTeX & LaTeX Advent Calendar 2013における、4日目の記事です。3日目はdoraTeXさんの「TeXによる化学組版」でした。5日目はCardinalXaroさんの「1つのTeXファイルから2つのPDFファイルを作る」です。 LaTeXは非常に多機能でおそらく最も高機能な組版処理ソフト（ワープロ）だと思う。特に、近年登場してきたTikZやPythonTeXは単なるワープロの限界を超える機能を提供してくれる。しかし、その難解さ・とっつきにくさからそこまで多くは普及していないのが現実だろう。 この記事ではそうしたLaTeXの問題点や、LaTeX初心者が不便に思う点を、2年前の2011年に初めて使い始めたときに感じた私の視点から指摘する。そして、こうしたLaTeXの問題点を緩和し、LaTeXの機能をマウスやキー、メニューから選択することで直感的に実現可能なGU
LyX | LyX – 文書プロセッサ
LyXは、文書の外見（WYSIWYG）に頼った物書きではなく、文書の「構造」（WYSIWYM）に基づいた執筆手法を支援する文書プロセッサです。 LyXは、強力で柔軟性のあるTeX/LaTeXに、操作しやすいグラフィカルインタフェースを付け加えます。TeXを背後に使うことによって、（完全に統合された数式エディタを通じた）数学的文書の作成や、学術的文書や論文、書籍などの構造化された文書作成において、世界第一級の支援を提供することが可能となっているのです。くわえて、科学的文書作成に欠かせない文献一覧や目次作成も標準装備されています。その一方で、LyXには、既成のうまくデザインされた膨大な文書レイアウトが組み込まれているため，手紙や小説を書いたり、演劇や映画の脚本を書いたりすることにも使用することができます。 LyXは、執筆したものを即座に最高の品質で得たい方にお薦めです。文書の細かな書式を延々と
礼儀正しさ重要（Good Manners Matter 日本語訳）
以下の文章は、Rich Bowen による Good Manners Matter（Open Advice に収録）の日本語訳である。 Rich Bowen は、約15年もの間フリー／オープンソースソフトウェアに携わってきた。その時間の大半は Apache HTTP Server に費やしてきたが、Perl や PHP やいろんなウェブアプリケーションにも取り組んできた。彼は『Apache Cookbook』や『The Definitive Guide to Apache mod_rewrite』他いろんな本の著者であり、様々な技術カンファレンスに頻繁に参加している。 僕は2000年の9月に Apache HTTP Server のドキュメンテーションプロジェクトに携わり出した。少なくとも、僕が初めてドキュメントをコミットしたのはそのときだった。それ以前は電子メールでいくつかパッチを登録し
どうして開発者がドキュメントを書くべきか - 2011-10-27 - ククログ
オフィス文書形式が要求されるようなドキュメントではなくて、自分が開発したライブラリのドキュメント（リファレンスマニュアルやチュートリアルなどライブラリのユーザーが読むためのドキュメント）の話です。以下の「ドキュメント」もそのような意味で使っています。 使いやすいライブラリを開発したかったらプログラムだけではなくドキュメントも書くべきです。 なぜドキュメントを書くか ドキュメントを書く習慣があるかどうかは開発者によってあったりなかったりです。使っているプログラミング言語に相関がある気もしますし、リリースするかどうかに相関がある気もします。理由はいろいろあるでしょうが、ドキュメントを書く習慣のない開発者の方が多いでしょう。 書かない理由はこんな感じでしょうか。 面倒。 自分しか使わないからいらない。 どのように書けばよいかわからない。（どのツールを使えばよいかわからない。） 一方、書く理由はこ
http://oalp.org/doc/writing/
For full functionality of this site it is necessary to enable JavaScript. Here are the instructions how to enable JavaScript in your web browser.
クラウド時代に求められる 「実行可能な仕様書」とは？
Excel方眼紙の問題 業務システム開発の世界には「Excel方眼紙」と多少軽蔑的に呼ばれるものがある。行間と列間を細かく設定したExcelシートのことで、さまざまなドキュメントの汎用様式とされる（図1）。特にソフトウェアの「仕様書」を書くために多用されている。 表計算ソフトはもともと表形式の数値計算や、これに付随する文字列操作に特化したソフトウェアだ。にもかかわらず、日本においては文書作成や仕様書を書くためのツールの“デファクトスタンダード”と言っても良いほどに「Excel方眼紙」は普及している。罫線へのこだわりと同様に、これはどうも日本だけでの現象らしいことから、一部では、日本の「格子偏愛文化」が生んだものではないかとも推測されているようだ。 Excel方眼紙上で仕様書を作成するのは面倒ではあるが、セル結合やフォント指定を駆使すれば思った通りにまとめられるし、印刷してもそれなりにキレイ
overlasting.net
overlasting.net 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
Writing Great Documentation - Jacob Kaplan-Moss
Series: Writing Great DocumentationA series of articles laying out the tools, tips, and techniques I’ve learned over the years I’ve spent helping to write Django’s docs. Writing Great Documentation: You need an editor November 12th, 2009I’m supposed to be this expert on writing, right? So how come my previous articles have had so many errors? Simple: my blog doesn’t have an editor. That’s typical
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
RFP(提案依頼書)とは？意味を理解してらくらく作成！[サンプルあり]／第3回 | 中小企業のための失敗しないWebシステム発注・開発![RFP(提案依頼書)とは？意味を理解してらくらく作成！[サンプルあり]／第3回 | 中小企業のための失敗しないWebシステム発注・開発](https://cdn-ak-scissors.b.st-hatena.com/image/square/106457a9c03b6bf69d2da3eac528d13d8477d26c/height=288;version=1;width=512/https%3A%2F%2Fwebtan.impress.co.jp%2Fsites%2Fdefault%2Ffiles%2Fstyles%2F1200x630%2Fpublic%2Fimages%2Farticle2013%2Fhachu%2Fhachu_icon.jpg%3Fitok%3DWiSTgxVT){kind=icon}
GitHub - kobo/gaiden: Gaiden is a tool that makes it easy to create documentation with Markdown.