タグ

ブックマーク / kazuhooku.hatenadiary.org (10)

  • 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のエイリアスに。 永遠に

    git branch の結果を時間順にソート - kazuhoのメモ置き場
    kazuph1986
    kazuph1986 2017/02/16
    便利。
  • オレオレ認証局の適切な運用とName Constraints - kazuhoのメモ置き場

    オレオレ認証局が忌避されるべきものとされてきた理由は、X.509 PKIが保証する安全性は、最も信頼性が低い認証局(trusted root)のそれに等しいからです。 しかし、X.509 v3以降ではName Constraintsが導入され、「特定のドメインに対してのみ証明書を発行可能な認証局」を定義できるようになっており、同constraintをcritical key usage extension*1として宣言したルート証明書を安全な経路で配布、インストールすることができれば、上記のようなX.509 PKIの系全体に対する影響は発生しないことになります*2。 ここで問題になるのは、どの程度のウェブブラウザがName Constraintsに対応しているのか、という点になりますがhttps://news.ycombinator.com/item?id=5194103によると、Chro

    オレオレ認証局の適切な運用とName Constraints - kazuhoのメモ置き場
  • テストファーストなGitワークフローについて - kazuhoのメモ置き場

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

    テストファーストなGitワークフローについて - kazuhoのメモ置き場
  • mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場

    @ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった? 高速化に効くシステムコール (1/2):知ってトクするシステムコール(3) - @IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも

    mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
  • 30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場

    「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので3分で書く。 オープンソースライセンスは、以下の3種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い(そしてどちらを選んでも問題ない)。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ: ライセンスの解釈については、

    30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
  • MySQL用にランキング専用ストレージエンジンを作る話 - kazuhoのメモ置き場

    前提: ゲームに限らずランキング機能が必要になるケースは多い つまり需要はある だが、MySQLで高速なランキング表示は難しい 具体的に言うと、以下の要件を満たすのが不可能 1行の更新コストが要素数Nに対して O(log N) 以下 任意のランキング位置周辺のSELECTコストが O(log N) 以下 ならば、専用のストレージエンジンを作ればいいのではないか いつやるか? 今でしょ! 以下理由 MySQL 5.5以降?だとストレージエンジンをまたぐトランザクションがまともになってるはず*1 ランキング専用でいいから、テーブル構造とか固定でいい(つまり実装が簡単!) ランキング専用だから、テーブル・ロックで十分(つまり実装が簡単!) 更新すると順位がずれる(つまりテーブルの大部分に影響がある)ので行ロック実装するメリットが小さい*2 ランキング専用でいいから、全データをメモリにもっても問題

    MySQL用にランキング専用ストレージエンジンを作る話 - kazuhoのメモ置き場
  • Monoceros雑感 - kazuhoのメモ置き場

    Monoceros は @kazeburo さんが開発してる Plack 用ウェブサーバ。prefork型だけど、待機中の接続をイベントドリブンのマネージャで管理することで、同時接続10,000とか行ける(ソケットの受け渡しは SCM_RIGHTS とか使う)。 で、雑感 大好き!!! Starletより遅い問題は、以下のようにすれば解決できると思う listen するソケットに TCP_DEFER_ACCEPT つけて、accept(2) は worker でのみ実行する worker は HTTP レスポンス送信後に read(2) してみて、後続のリクエストが来てない場合にのみ、マネージャプロセスにソケットを返還する (追記) 「返還」ではなく、マネージャプロセスが管理しているソケットのいずれかにデータがきている場合のみ、そのソケットとworkerのソケットを「交換」する、とすれば

    Monoceros雑感 - kazuhoのメモ置き場
  • なぜ動的型付けの言語が流行ったのか (Re 静的型付けと動的型付けのどちらが優れているかという話) - kazuhoのメモ置き場

    静的型付けと動的型付けのどっちが優れているか。どのようなプログラムを書いているかによって答えはかわるんじゃないの? たとえば、自社で開発・運用しているウェブサービスなら「問題が出たら修正」すればいいんだし、バグがないことを保証するよりも迅速に開発できるプログラミング言語(つまり動的型付けの言語)がいい。 逆に、客先への納品が発生するソフトウェア製品なら「バグがない形で出荷する(様々な状況・環境下でちゃんと動作する)」ことが重要だから、静的型付けの言語を使うことで品質を高めるというのは合理的な選択*1。 細かな論点はいろいろあるだろうけど、基的には、このようなソフトウェア開発に対するスタンスの違いで決まる話だと思います。 別の言い方をすると、動的型付けの言語は流行ったのは、ウェブには前者のアプローチが適していたからだし、スマホアプリには静的型付けの言語がむいていると言えるのでしょうね。それ

    なぜ動的型付けの言語が流行ったのか (Re 静的型付けと動的型付けのどちらが優れているかという話) - kazuhoのメモ置き場
  • Xcode を使わずに iOS 向けのコードをコンパイルする方法 - kazuhoのメモ置き場

    # armv7 clang -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk -c mattn.c ar mattn-armv7.a mattn.o ranlib mattn-armv7.a # i386 clang -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk -c mattn.c ar mattn-i386.a mattn.o ranlib mattn-i386.a

    Xcode を使わずに iOS 向けのコードをコンパイルする方法 - kazuhoのメモ置き場
  • それでも私が Perl を使いつづける理由 - kazuhoのメモ置き場

    元ネタ: http://d.hatena.ne.jp/tokuhirom/20100120/1263958061 なぜ俺が $@%* を使いつづけるのか。* とか良く分かってないけど。 システムプログラミングができる 例えば低水準I/Oが標準で用意されているとか。 gccがない環境にも入っている gccがない環境にも入っている。XenServerのDom0とかにも入ってる。確かLSB 3.2で必須になったらしいので、普及度が上がることはあっても下がる可能性は低い。 インタプリタである Un*x系なら大抵どこでも動く 豊富で(かなり)安定したライブラリ群 CPANのライブラリの量はすごい。それにAPIを無闇に変更したりするとDISる文化が定着してるっぽいので、比較的安心して使える。 まとめ ウェブアプリとか管理ツールとか C/C++ じゃなくてもいいケースで生産性を上げるために使ってる。それ

    それでも私が Perl を使いつづける理由 - kazuhoのメモ置き場
  • 1