GitHub - r7kamura/autodoc: Generate documentation from your rack application & request-spec.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Autodoc - r7kamura blog
闇Advent Calendar 1日目の記事として、最近の開発における心の闇に触れます。 最近開発した Autodoc というツールについて簡単に説明した後、 この手のツールの開発にあたって考えていた、 創作活動の在り方や、社会の斥力、25歳定年説などについて触れようと思います。 Autodocとは Rack applicationで実装されたAPIに対して、RSpecで書かれたテストを元にAPIドキュメントを生成するもの。 テストを実行すると、テスト中に発行したリクエストやレスポンス、そのテストに付けられたメッセージを元に、 良い感じに情報をまとめ、Markdown形式でAPIドキュメントを記したファイルを生成してくれる。 例えばGitHubではMarkdownファイルを適当に描画してくれるので、 下図のようにGitHub上で簡単にドキュメントを閲覧出来るようになる。 テストの書き方
WIPであろうと、情報共有すると何がいいのか？ - ppworks.jp
口頭で話したことを文字に起こすことについての続編のような記事です。 消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。 口頭で相談したことをesaやqiita:teamにまとめる 口頭でコードレビューしたことをgithubやgitlabのコードレビューのコメントにも書き残す 口頭で話したことをチャットにも書き残す チャットで話しかけた後に口頭で済んだ場合、チャットに解決済と流す 情報共有すると何がいいのか？ 何がいいか。 暗黙知を減らすことが出来る 当事者に なろうと思えばなれる なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるという
esa.io 使ってみた - えいのうにっき
おっ、esa.io への申請が approved された...^^— いのうえ (@a_know) 2015, 1月 11 ってことで、使ってみた。 esa.io とは、「小さな開発チームのためのドキュメント共有サービス」。 なぜ esa.io を使ってみようと思ったか 職場では Qiita:Team を使ってる 仕事以外のものでも、markdown をいつでもどこでも読み書きしたくて、Lodge をさくらのクラウド上のサーバに立てて使ってた クーポンを利用してるから、サーバの利用料金自体は今年の夏くらいまで無料なんだけど... esa.io のアイコンがかわいかった(*´ｪ`*) 使ってみて、"おっ" と思ったこととか 基本的な機能はひと通り有してるなー fav / watch / コメント 、ひと通り可能。 もともとある記事のコピーからの作成もできる。 絵文字や他記事のサジェストもして
Re:VIEW導入 & Re:VIEW Live Reload作った - エンジニアをリングする
最近ちょっと書籍形式の文章を書く機会があり、良い機会なのでたびたび耳にしていたRe:VIEWというツールを触ってみました。 Re:VIEWとは 書籍を書くことに特化したマークアップ言語＆ビルドツールという認識。 「れびゅー」と読むそうです。 触る前は何がいいのかあまりよくわかっていなかったのですが、以下の記事を読んで、触ってみたい！と思いました。 TypeScript in Definitelyland 発行 あとRe:VIEWそのものの説明のスライドがこちらにあります。 書籍制作フローを変える。「ReVIEW」という解。〜マークアップと自動組版と、時々、電子書籍〜 確かにテキスト管理はGitでしたいし、専用のソフトウェアがないと開けない、みたいなのは嫌だからこういう方針は素晴らしい。 でもマークダウンのほうがメジャーだし書き慣れてるしマークダウンでいいのでは・・・？という気持ちも。 ただ
jQAPI - Alternative jQuery Documentation Browser
This is a alternative interface to browse the Official jQuery Documentation. It was created to get out of your way of your development work - quickly find what you are looking for, easy on the eyes, and lightning fast. Just start typing and see for yourself! FeaturesContent is the same as in the Official jQuery DocumentationStatically rendered pages powered by Astro, so the initial loading time is
本気でドキュメントを書くときに気をつけている10のこと - Masa / Lino Blog
テクニカルドキュメントを本気で書くときに気をつけていることをまとめてみます。 一応、私は雑誌等に執筆活動もやっています。 書き始める前 1. 目次を洗い出す ここでドキュメントの8割が決まるといっても過言ではないです。 この段階で抜け漏れ、重複を洗い出します。 特に複数人で執筆するときは特に重要です。 2. 書く内容をすべて実践する。 言うまでもないですが、テクニカルドキュメントは手を動かしてみないと書けません。 動かさないで書いてしまうと、嘘だらけのドキュメントが完成するでしょう。 テクニカルドキュメントではない場合は、全体をイメージします。 書いている途中 3. 文章は短く、シンプルに 同じことを伝えられるなら文章は短いほうが理解しやすいです。 ただ、舌足らずになるほど短くはしません。 根底にあるのはKISS(Keep It Simple, Stupid)です。 余談ですが、KISSは
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails/Rubyドキュメントをキレイに生成するYARD、早見表付き！ 
Java SE - Documentation
Subversion によるバージョン管理
『Linux標準教科書』開発プロジェクト - LPI-Japan - エルピーアイジャパン
ドキュメント作成に役立つ「日本語スタイルガイド」の紹介