ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
【翻訳】Gitのコミットメッセージに関する注意点
Tim Popeさんの "A Note About Git Commit Messages" を翻訳しました。 元記事はこちら： http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があればブログコメントやTwitter(@oshow)などで遠慮無くご指摘ください。 Gitのコミットメッセージ に関する注意点 良い形式のコミットメッセージを書くということについて、時間を取って説こうと思う。私が考えるに、コミットメッセージ形式に関するベストプラクティスは、Git を素晴らしくしてくれる小さなディティールの一つだ。rails.git への最初のコミットのいくつかは、（折り返しのない）長文による多様なコミットメッセージを含んでおり、なぜこれがはっきり言ってお粗
われわれは、いかにして変更点を追うか
われわれは、いかにして変更点を追うか ChangeLog/Issueを追う技術 自己紹介 azu @azu_re Web scratch, JSer.info アジェンダ 変更点を ChangeLogで知る Issue/Pull Requestで知る Commitで知る アジェンダ 変更点を Commitに書く Issue/Pull Requestを扱う ChangeLogにまとめる 変更点を追う :mouse: ChangeLogの追い方 ChangeLogを追うにはまずChangeLogの更新に気づく事が必要 GitHubでライブラリのリリースを見ていくためのツールや方法に書いた 更新検知の仕組みや補助ツールについて リポジトリのWatch => azu/github-reader タイムライン => azu/github-reader Star => starseeker GitHu
エンジニアでもターミナル作業ログを残したい!! - 目の前に僕らの道がある
今まで下記のようにexecで標準出力と標準エラー出力を作業ログに残すという事をしてたんですが、実際に打ったコマンドは出力されないので、ちょっと不便だなーと思ってました。 exec > >(tee --append /tmp/$(date +"%Y.%m.%d")_$(id --user).work.log) 2>&1 ちょっと調べて見るとscriptコマンドを使うとコマンドを含めて出力できることを知りました。 これで作業ログを残すのがはかどる! script --append --flush /tmp/$(date +"%Y.%m.%d")_$(id --user).work.log チームメンバーにこのログをtailさせておけば、画面共有も出来たりもします。 (その用途ならホントはwemuxとか使った方が良いんでしょうけどね。。 tail -F /tmp/$(date +"%Y.%m.%
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
