個人的な良い記事のガイドライン = 2ヶ月前の自分が泣いて喜ぶような記事を書く - Qiita
はじめに 昨日、こちらの記事を拝見しました。 良い記事を書くためのガイドライン - Qiita:Support 上の記事は「あなたの知識が他の誰かの役に立つようにするため」のQiita公式のガイドラインです。 これを読んでると「うんうん、なるほど。そうだよねー」と思うところばかりでした。 それにかこつけて、僕もどういうことを考えながらブログやQiita記事を書いているのかを紹介してみようと思います。 何を考えながら書いているのかというと、この記事のタイトルにある通りです。 まあ「2ヶ月前」っていうのは適当で、「昨日」でもいいし、「2年前」でもかまいません。 要するに「2ヶ月前の自分」＝「その知識を知らなかった頃の自分」ということです。 技術記事を書くときは、自分の書いた記事を過去の自分に見せたときに、 「あー、なるほど！最初っからそう説明してくれたらすぐわかったのに！！」 と大喜びしそうな
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
cpprefjp - C++日本語リファレンス
本サイトcpprefjpは、プログラミング言語C++のリファレンスを提供するWebサイトです。 最新C++バージョンのリファレンスを提供していきます。 運営方針 本リファレンスサイトは、C++言語の最新のリファレンスを常に提供し続けることを目標にしています。 各クラス、関数にはそれぞれ1つ以上のサンプルコードを付けていく方針です。 本サイトでは、他サイトおよび規格書の直接的な翻訳ではなく、編集者の調査と考えに基づいた解説を提供していきます。 HTMLデータのダウンロード cpprefjp.github.io-master.zip ローカルで閲覧できるHTMLを用意しています。 スポンサーシップ cpprefjp - Open Collective このプロジェクトは、持続的な活動のため、ユーザーの方々からのご支援をお待ちしております。上記Open Collectiveのプロジェクトでスポン
詳しすぎる詳細設計書 - SiroKuro Page
「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力： 「性別と身長のペア」のリスト 出力： 男性の平均身長」と「女性の平均身長」の差 処理概要： 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を１つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を１増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を１増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
Markdown文法の全訳
Markdownの文法について作者が解説したページを全訳してみました。 まだまだ手を入れ足りないところがありますが暫定公開します。 【更新】2008年12月30日17時45分(ホームページを移動) 【原文】http://daringfireball.net/projects/markdown/syntax.php 【ＨＰ】http://daringfireball.net/projects/markdown/ はじめに 注意 ライセンスは修正BSDライセンスです。原文のライセンスを尊重の上、適当にどうぞ。 意訳していて、原文の意味を損なわない程度に言葉を加えたり省略している部分があります。 訳が間違っている可能性があります。暫時修正はするつもりですが、必ず原文を優先するようにしてください。 意見等につきましては遠くない将来にコメント欄など何らかの連絡方法を保てるようにしたいと考えていま
Markdown - Wikipedia
Markdown（マークダウン）は、文書を記述するための軽量マークアップ言語のひとつである。本来はプレーンテキスト形式で手軽に書いた文書からHTMLを生成するために開発されたものである。しかし、現在[いつ?]ではHTMLのほかPowerPoint形式やLaTeX形式のファイルへ変換するソフトウェア（コンバータ）も開発されている。各コンバータの開発者によって多様な拡張が施されるため、各種の方言が存在する。 オリジナルのMarkdown[編集] 「書きやすくて読みやすいプレーンテキストとして記述した文書を、妥当なXHTML（もしくはHTML）文書へと変換できるフォーマット」として、ジョン・グルーバー（英語版）により作成された。アーロン・スワーツも大きな貢献をしている[4]。Markdownの記法の多くは、電子メールにおいてプレーンテキストを装飾する際の慣習から着想を得ている。 Markdown
Sphinx-Users.jp
Sphinx-Users.jp¶ Sphinx-Users.jp(略称#sphinxjp)は、美しいドキュメントを簡単に生成することができるドキュメンテーションツール、 Sphinx （スフィンクス）の普及を主眼としたコミュニティです。SphinxはPythonの公式ドキュメントだけでなく、このSphinx-Users.jpのサイトも含め多くのマニュアルやサイトで使用されており、詳細を Sphinxの歴史で紹介しています。 Sphinx-Users.jp は日本の Sphinx コミュニティです。 Sphinx-Users.jp では、日本で散らばっているSphinx関連情報を集めて、Webサイト、イベントを通じてSphinx情報を発信します。 slack のコミュニケーションや勉強会の開催などを通じて、ドキュメントをパワーアップしたい人、ドキュメントや翻訳で苦労している人、Sphinxの
Pandoc - index
If you need to convert files from one markup format into another, pandoc is your swiss-army knife. Pandoc can convert between the following formats: (← = conversion from; → = conversion to; ↔︎ = conversion from and to) Lightweight markup formats ↔︎ Markdown (including CommonMark and GitHub-flavored Markdown) ↔︎ reStructuredText → AsciiDoc ↔︎ Emacs Org-Mode ↔︎ Emacs Muse ↔︎ Textile → Markua ← txt2t
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://dag.wiee.rs/home-made/unoconv/