The pre-class components introduce topics; the in-class components help students integrate and practice those topics. That said, the pre-class work, by itself, provides significant educational value. Google provides all the materials needed to run the in-class sessions at your own organization. If you'd like to facilitate the in-class sessions for your organization, please see Facilitating Technic
ドキュメント文化は健全な組織のスケールのために必要 組織の中でドキュメント/文章を残し活用していくことはとても重要だ。クオリティの高いドキュメントがあることで、組織に情報が流通し、透明性を確保できるようになる。情報を流通させるためにいちいち口頭の説明がいらないから、メンバーの数が増えた時でもスケールしやすくなる。過去の結論にアクセス可能になるので、議論を積み上げていき、意思決定のクオリティを高めることにもつながる。そもそも何かを読むということは何かを聞いて教わるよりも時間あたりの処理量が多いし、非同期に実施できる。良いドキュメントをアセットとして社内に蓄積していくことはスタートアップのみならず、ありとあらゆる組織が成長していく上でとても重要であると言える。 しかしその一方で、良質なドキュメント文化を徹底できている会社は多くないように見える。例えば、社内のドキュメントを蓄積させていく場所とし
業務でドキュメントを作成するケースは多々ある 例:仕様書・設計書・提案書・メール・障害票... ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り(,)を入れない 時間を何でもマイクロ秒・ミリ秒にする(1/100万秒までの精度が必要?体感で分かる?) 桁数が多い=精度が高い=良い文書、ではなく、見る人が必要とする精度に切り上げることが重要(売上で1円単位まで出すことが無いのと同様) 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
wikiとかでドキュメントを書くのが面倒で、良いツールを探していたらiodocsというnode製ツールを見つけた。 これを使うとドキュメント作成が楽になるだけじゃなく、 ドキュメント上のformからAPIリクエストを試せて便利っぽい。 普段APIドキュメントを見つつcurlとかでリクエスト送信して試してたのが、全てドキュメント上で完結して良さげ。 使い方 mashery/iodocsからcloneしてアプリを起動すると、FoursquareやLinkedin APIを叩くサンプルをすぐに試せる。redisが必要なのでserver起動を忘れずに。 ~/ $ git clone http://github.com/mashery/iodocs.git ~/iodocs $ npm install ~/iodocs $ redis-server & ~/iodocs $ npm start {
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く