at284kmのブックマーク - はてなブックマーク

git branch の結果を時間順にソート - kazuhoのメモ置き場
ブランチが大量にあると、git branch の結果を最終更新時間でソートして表示したくなりますよね。以下のワンライナーでできます。 (for i in `git branch | colrm 1 2` ; do echo `git log --date=iso8601 -n 1 --pretty="format:[%ai] %h" $i` $i ; done) | sort -r git branch を最終更新の日付でソートするオプションがほしい Kazuho Oku on Twitter: "git branch を最終更新の日付でソートするオプションがほしい" ってツイートしたら、@likk さんに、 @kazuho https://gist.github.com/Likk/9af89b10fd0008df91ad … ワンライナー書いたのでこれをgitのエイリアスに。永遠に靴紐
at284km 2016/06/10
git
リンク
LTSV のもうひとつのメリット、あるいは、プログラムでログを出力する際に気をつけるべきこと - kazuhoのメモ置き場
Labeled Tab-separated Values (LTSV) がブームのようです。 LTSV については、ラベルをつけることで柔軟に拡張できるという点が、その特徴として取り上げられますが、もう一点、タブをセパレータに使うことでログのパースが簡単になった、という点を忘れるべきではないでしょう。特に httpd のログは NCSA httpd という HTTP/0.9 時代のWebサーバのログフォーマットがベースに拡張されてきたため、以下のようにセパレータとして空白、[]、ダブルクォート ("")*1が混在するという、とても処理しづらいものになっていました。どれほど複雑かは「404 Blog Not Found:perl - Apache Combined Log を LTSV に」の実装を見れば明らかでしょう。 127.0.0.1 - - [08/Feb/2012:23:52:4
at284km 2015/10/06
LTSV
リンク
SSD がコモディティになっても状況はかわらない - kazuhoのメモ置き場
脊髄反射。 Oracle や MySQL など近年の RDBMS はインデックスのデータ構造にB木 (の変種) を採用していますが、その理由はここにあります。 SSD がコモディティになると状況は変わる (中略) 二次記憶上での検索用のインデックスにはこれまで B木のようなディスクに最適なデータ構造が必然的に選択されてきましたが、SSD に変わると、現実的に利用可能なデータ構造にも幅が出て、アプリケーションによっては劇的な改善が可能になるというわけです。この先 SSD の普及によって、色々なソフトウェアで、驚くような改善が行われる機会を目にすることが多くなるのではないかと思います。その時、単に SSD に変わったから速くなったと捉えるのではなく、どのようなデータ構造が選択されて、そのデータ構造の特性が SSD とどのようにマッチしたのかという視点で見ていくことが大切ではないかと思います。
at284km 2014/03/28
ssd

algorithm
リンク
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます変更の主題を常に明確にする前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
at284km 2014/03/13
git

workflow
リンク
1