ブランチが大量にあるので整理したい、けど大人数で開発しているから誰がどのブランチいじってるか分からない、 ということがあったので、出し方のメモ。
githubのbranch一覧も見ればいいじゃん！っていう意見もあると思うんだけど、 「自分のbranch一覧」は見れるんですが「特定のだれかのbranch一覧」が見れない・・・。
git-for-each-refを使うと各ブランチに対していろいろ操作できるようです。 各ブランチの最後にコミットした人一覧を出すには以下のコマンド。
git for-each-ref --format='%(authordate:short) %(authorname) %(refname)' --sort=-committerdate refs/remotes/origin/ formatは自由にいじれるのでいろいろ遊べます。 例えば、ブランチをたくさん抱え込んでいる人の一覧を表示する例。
git for-each-ref --format="%(authorname)" refs/remotes/origin/ | sort | uniq -c | sort -nr 参考 git-for-each-ref - Output information on each ref リモートブランチも含め更新日時が新しい順番にソートする ブランチ一覧を更新時刻つきで表示したい場合、gitのfor-each-refが使える。
ぴっぴ先輩が「Go言語で発行したクエリを確認したい」って言ってて、 「MySQL使っているならGeneral Logを吐けばよいのでは？」と返したんだけども、 もっと汎用的な方法はないものかと考えてみました。
Golangの database/sql はどんなDBでも対応できるよう、ドライバを自由に入れ替えることができます。 ドライバは単にdatabase/sql/driverにあるインターフェースを満たしている何かなので、 ユーザが自由に作ることができるし、interfaceを経由して直接呼び出すことも可能です。 この仕組を使って、別のドライバにそのまま渡すプロキシを作れば、ログを吐けるのでは？ということでやってみました。
go-sql-proxy 使い方 まず最初にgo-sql-proxyをドライバとして登録します。
hooks := &proxy.Hooks{ // Hook functions here(Open, Exec, Query, etc.) } sql.Register("new-proxy-name", proxy.NewProxy(&another.Driver{}, hooks)) あとは登録したドライバと使って新しいDBハンドラを開くだけです。
db, err := sql.Open("new-proxy-name", dataSourceName) このハンドラを使ってクエリ実行を行うと、Hooksで登録した関数が呼び出されます。 元のドライバを直接使った場合と同じように振る舞うので、既存のコードを一切変えること無くHookを差し込めて便利！
トレーサの例 簡単なトレーサを書いてみるとこんな感じ。 発行したSQLのクエリをログに吐き出します。
package proxy import ( "database/sql" "database/sql/driver" "log" "github.com/mattn/go-sqlite3" "github.com/shogo82148/txmanager" ) func main() { sql.Register("sqlite3-proxy", NewProxy(&sqlite3.SQLiteDriver{}, &Hooks{ Open: func(conn *Conn) error { log.Println("Open") return nil }, Exec: func(stmt *Stmt, args []driver.Value, result driver.Result) error { log.
Golangのdatabase/sqlはBeginとCommitでトランザクションの制御を行うことができます。 クエリの実行が確実に成功するのであれば難しくは無いのですが、 トランザクション内でエラーが発生場合、確実にトランザクションを終了させるのは少し面倒です。 また、ネストができないので、「トランザクションの中から呼び出しても外から呼び出しても、関数の中はトランザクション内」みたいなことができません。 PerlにはDBIx-TransactionManagerというものがあるのですが、 このGolang版が欲しくなったので作ってみました。
txmanager 簡単な使い方 sql.DB をラップした txmanager.DB を使います。 Begin, Commit する代わりに TxBegin, TxCommit を使ってトランザクションを開始・終了すると txmanagerの管理下になります。 確実にトランザクションが終了させるために、トランザクションを開始したらdefer tx.TxFinish()を忘れないように。
import ( "database/sql" "github.com/shogo82148/txmanager" ) func Example(db *sql.DB) { dbm := txmanager.NewDB(db) // トランザクション開始 tx, _ := dbm.TxBegin() defer tx.TxFinish() // INSERTはトランザクションの中で実行される _, err := tx.Exec("INSERT INTO t1 (id) VALUES(1)") if err != nil { tx.TxRollback() } tx.TxCommit() } 実際にはこれに加えてエラー処理も必要です。 txmanager.Do を使うと、トランザクションの開始処理・終了をtxmangerがやってくれるので少し楽になります。
import ( "database/sql" "github.com/shogo82148/txmanager" ) func Example(db *sql.
とあるHTTPサーバをGolangで立てようって話になったんだけど、 止まると困るので無停止でサーバ再起動をしたい。 PerlにはServer::Starterという有名モジュールがあるんだけど、 Golangはどうなってるの？ってことで調べてみました。
2017-01-22追記: Go1.8以降でGraceful Shutdownがbuild-inになるので、この記事で紹介したライブラリは不要となりました。 詳しくはGo1.8のGraceful Shutdownとgo-gracedownの対応を参照。
gracefulじゃないバージョン Golangの標準ライブラリを使ってHTTPサーバを立ててみる例。 レスポンスが一瞬で終わってしまうとよくわからないので、sleepするhandlerを追加しておきます。
package main import ( "fmt" "log" "net/http" "os" "time" ) var now = time.Now() func main() { log.Printf("start pid %d\n", os.Getpid()) s := &http.Server{Addr: ":8080", Handler: newHandler()} s.ListenAndServe() } // https://github.com/facebookgo/grace/blob/master/gracedemo/demo.go から一部拝借 func newHandler() http.Handler { mux := http.NewServeMux() mux.HandleFunc("/sleep/", func(w http.ResponseWriter, r *http.Request) { duration, err := time.ParseDuration(r.FormValue("duration")) if err != nil { http.Error(w, err.Error(), 400) return } time.
ちょっとGIFアニメを作りたくなって、最近Go触ってるしGoでやってみよう！とやってみたメモ。 ImageMagikでいいじゃん説もあるけど、最終的にツールとして配布したいなってことでGoです。
主に減色まわりについて。
2021-12-07修正
昨今のアレコレ(LOSING LENA)の関係で記事中の Lenna さんの画像をマンドリルに置き換えました。
何はともあれ実装してみる 以前、「ターミナル操作の記録(ttyrec)からGIFアニメを生成するツールを作った」という記事を見たので、 これを参考に実装してみる。
package main import ( "image" "image/color/palette" "image/gif" _ "image/png" "os" ) func main() { reader, err := os.Open("Mandrill.png") if err != nil { return } defer reader.Close() img, _, err := image.Decode(reader) if err != nil { return } paletted := image.NewPaletted(img.Bounds(), palette.WebSafe) for y := img.Bounds().Min.Y; y < img.Bounds().Max.Y; y++ { for x := img.Bounds().Min.X; x < img.Bounds().Max.X; x++ { paletted.
Fisher-Yates shuffleを使ってシャッフルライブラリ作ってみました。
https://github.com/shogo82148/go-shuffle 標準ライブラリのsortと似たような感じで使えます。 デフォルトでintとfloat64とstringのシャッフルに対応していて、 他の型をシャッフルしたい場合はインターフェースを実装してね、って感じです。 実装が簡単なので、インターフェース定義する手間とシャッフルのアルゴリズム自前で書く手間ほとんど一緒ではという気もするけど、 まあライブラリ作成の練習ってことで。
で、ここからが本題。 Fisher-Yates shuffleの名前は以前から知ってたけど、 この前某プロジェクトで以下のようなshuffleの実装を発見。
package main import "math/rand" func shuffle(a []int) { for i := range a { j := rand.Intn(i + 1) a[i], a[j] = a[j], a[i] } } Fisher-Yates shuffleと似ているけど、なにかが違う。 ちゃんとシャッフルされているのか気になったので検証してみました。
検証 n個の数列をシャッフルすることを考えます。 シャッフルの後i番目の要素がj番目に移動する確率を $P_n(i, j)$ と定義します(golangのコードにあわせて0-originで考えます)。
完全にランダムにシャッフルされていれば、 元の数列のどの要素も0からn-1の範囲に一様分布するはずです。 つまり、以下の式がなりたてば「シャッフルされている」と言えそうです。
$$ P_n(i, j) = \frac{1}{n} (i, j = 0, \dots, n - 1) $$
n=1の場合 n=1の場合は、必ず0番目と0番目の入れ替え(つまり順番変わらない)になります。 上で定義した確率を計算すると$P_1(0, 0) = 1/1$となるので、シャッフルされていると言えます。
木曜日の社内ISUCONにチームぽわわ3.5として参加してきました。 (今年のISUCON本番に4にアップデート予定) さきに結果だけ書いておくと、 1位はfujiwaraさんとacidlemonさんのチーム、 2位はチームぽわわ3.5、 3位はぴっぴ先輩率いるチーム例の青い紐でした。
オムライスと紐を倒したので僕は満足です。 簡単にやったことを書いておきます。
課題内容 Twitterみたいな短文投稿サイトです。 トップページにアクセスすると全ユーザの発言最新100件がみれて、 ログインすると発言したり自分の投稿履歴を確認したりできます。 僕が新卒で入ってきたときはPerlでしたが、今年の参考実装はGolang製です。 (Rubyもあったらしいけど使った人いたのかな)
やったこと 僕自身は、相方になったたいがさんに「こんなことしてみては〜」と言ってみる係をやってました。 具体的な対応としては以下の通りです。
nginxにレスポンス吐かせる Nginxのレスポンスタイムをパーセンタイル値で計測するMunin plugin とかを参考にしてもらって、レスポンスタイムを吐くようにしてもらいました。
ログをテキトウスクリプトで集計したとろこ、トップページの全ユーザの発言最新100件みれるページが重いみたい。 高速化の第一ターゲットをトップページにしぼりました。
MySQLにSlowQuery吐かせる トップページが重いっぽいというのはわかったものの、 どのクエリが重いかまでは分からない(もちろんコード読んでたので検討はついてたけど)ので、 処理に0.1秒以上かかっているクエリを吐くようにしました。
インデックスの追加 既存のコードに触れずにお手軽ってことで、まずはDBにインデックスを張るところから。 workload10で、99583から101033にスコアアップ！ まあ、他のボトルネックを潰していない段階だとこんなもんでしょうね・・・。
ループクエリ・無駄クエリの削除 明らかに無駄クエリっぽいところがあったのでそこを修正しました。
投稿100件取得したあとに、100回ユーザ名の取得処理をしている JOINを使って書き換えました 実行計画が狂って逆に遅くなるという事態に陥ったので、IGNORE INDEXとかして頑張った ユーザの投稿を全取得してるのに、最新1件の情報しか使ってないところ LIMITをつけて制限 全投稿をCOUNTしているところ せっかくGolang使ってるんだから楽しようと、グローバル変数に突っ込んでcount++してみた 「グローバル変数に突っ込んでみた」対策みたいに、下手にアプリサーバで情報を保持すると DBとアプリサーバに差ができてしまうので、実運用では避けるべきテクニックですね。 あとになって考えると、ベンチ回す前にアプリサーバの再起動忘れてたのにベンチ通ってたので、 投稿数数えなくてもよかったのでは・・・。
nginxによる静的ファイルの配信 cssとかjsをGolangでかえしていたので、nginxで返すようにしました。 これで724338から802905(workload:100)にScoreアップ！
画像の縮小 Twitterらしく投稿には100x100程度のサイズのアイコンが表示されるんですが、 元画像が1000x1000程度だったので縮小しました。 ただ、ベンチが画像にアクセスしにこないので、まったくの効果なし。 最終計測では結局元画像に戻しました。 実運用では確かに効果があると思うんですが、まずはログを見て判断しろという教訓ですね。
まとめ あとはworkloadの調整とかやって最終スコアは935519でした。 2位にはなったものの、インデックス追加とかループクエリの削除とか最低限のことが何とか出来たって感じです。 もっと精進します。
tech kayac へのポストまだかな〜
Perlで特定の文字列の出現回数を調べたくなって、調べてみたメモ。
ググるとすぐに見つかった。 perlで指定文字列の出現回数を取得する(正規表現)
指定文字列の出現回数は正規表現を使って
$count++ while($str =~ m/$pattern/g);
もしくは
$count = (() = $str =~ m/$pattern/g);
が、一瞬何をやっているのか把握できない・・・。 こういう意味なのかなーって予想はしてみたけど、あってるか一応調査。
whileを使った方法 //g をスカラーコンテキストの中でマッチさせると、 前回マッチした場所を覚えておいてくれて、次のマッチでその場所から検索を再開してくれるらしい。 (Using regular expressions in Perl - perlretut) マッチした場所は pos で取得可能。
my $str = "hoge fuga foo bar"; while ($str =~ m/[a-z]+/g) { say pos $str; } whileを後置にして、ループの回数を数えるようにすれば、最初の方法になる。
ループを使わない方法 これが一番謎だった。
//g をリストコンテキストで評価すると、マッチした文字列がリストになって帰ってくるらしい。 (Quote-Like Operators - perlop)
複数の変数に一括して代入するときに ($foo, $bar) = (1, 2) みたいな書き方をするけど、 () = ... の部分はこれの代入先の変数が一個もないケース。 要するに「リストコンテキストで評価してね」という意味のイディオムみたい。
まとめると、以下のような処理を簡略化して一行にしたのがループを使わない方法みたいです。
オーバーロードの優先順位付けが少しおかしくて、 名前付き引数とオプション引数と一緒に使うと死ぬ場合があるというお話。 ぴーちんが昨日言ってたやつ。 いんたーねっつにも乗っけておく。
問題となるのは以下のようなコード。
class MainClass { void Foo (int fuga) { } void Foo (string hoge, int fuga = 10) { } void Bar() { Foo (fuga: 20); } } このコードは以下のような例外を吐いて死ぬ。
Internal compiler error. See the console log for more information. output was: Unhandled Exception: Mono.CSharp.InternalErrorException: Internal error at Mono.CSharp.MethodGroupExpr.IsApplicable (Mono.CSharp.ResolveContext ec, Mono.CSharp.Arguments& arguments, Int32 arg_count, System.Reflection.MethodBase& method, System.Boolean& params_expanded_form) [0x00000] in <filename unknown>:0 at Mono.CSharp.MethodGroupExpr.OverloadResolve (Mono.CSharp.ResolveContext ec, Mono.
いつもテスト実行でお世話になっているtravisさんがC#をサポートしていました。
以前から C#をサポートして欲しいという要望はあったのですが、 2014年12月あたりからついに使えるようになってたみたいです。
以前はC言語のフリをして、設定ファルで頑張ってmonoをインストールする必要があったのですが、
## Travis CI Integration language: c install: - sudo apt-get install mono-devel mono-gmcs script: - xbuild hogehoge.sln 今はlanguageにcsharpを設定して、solutionを指定するだけです。
## Travis CI Integration language: csharp solution: hogehoge.sln MiniMeggagePack もこちらの設定を使うようにしてみました。
nunitを使ってテストする場合は結局sudo apt-get install nunit-consoleする必要があるみたいですが、 複数バージョンのmonoでテストできたりしていい感じです。 ただ、ドキュメントにはmono2.10.8もサポートしているとあるのにmonoのインストールが404で失敗したり、 他のバージョンでも時たまmonoのインストールにコケたり、 3.8.0でnunitのテストが上手く動かなかったり、不安定な感じがしてます。 徐々に改善していくといいなー。
参考 Building a C#, F#, or Visual Basic Project