第9回 ログのすすめ | gihyo.jp
今回のテーマはログである。ログと言ってもサーバやアプリケーションのログのことではない。今回取り上げるのは作業ログである。作業ログと言えば、古くはChangeLogメモやhowm、最近ではEvernoteやMarkdown形式でのメモなど、いくつかの流派が存在する。 作業ログを取る目的はさまざまだ。ライフログ、つまり自分の人生のログを取る目的のものもあれば、未来の自分が検索することを見越して書くものもある。今回取り上げるのは、物事を前に進めるための作業ログである。筆者は記憶力が悪い。暗記モノが昔から苦手だ。また、気が散りやすく数分前に何をやっていたかさえ思い出せないこともある。そんな限られた能力で、難しいタスクをこなすためには工夫が必要である。そのための工夫の一つがログを取ることだった。今回はその作業ログについて、できるだけ実例に近いものを取り上げながら説明したい。 難しいタスク 仕事で、あ
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
