とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。（口頭で何時？と聞かれたら14時と答えるかもしれないけれど） つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題

構造化ログのプラクティスをあちこちで調べていたら、logfmtを推奨する記事を見つけたので調べてみました。 先に結論を言うと、JSON linesを使っておくのが良さそうです。 logfmt について logfmtとはスペース区切りで key=value を並べたフォーマットです。文字列にはクォートとエスケープによってスペースや改行を含められます。 at=info method=GET path=/ host=mutelight.org fwd="124.133.52.161" dyno=web.2 connect=4ms service=8ms status=200 bytes=1653 (logfmt から引用) あちこちで logfmt のリファレンスとして紹介されているのはこの記事です。 https://brandur.org/logfmt 発明されたのはどこか分かりませんが、流行

qiita.com そもそも fetchall があればパフォーマンスが上がるわけでは無いので。https://t.co/O4u3zZcnYx これを16KiBにしたらパフォーマンス上がるはず。— Inada Naoki (@methane) December 17, 2020 go-sql-driver/mysql のバッファサイズは4KiBで、大きいクエリを送るなり大きいパケットを受信すれば自動的に増えますが、小さいrowを大量に受信する場合は4KiBのバッファを使って何度もReadをしてしまいます。これを大きくすればReadの回数が減って高速化できそうな気がします。 ということで、話題のリポジトリをforkして、DBからselectしてCSVを書き出す部分だけを100回ループしてみました。CSVの書き出しがネックにならないようにbufio.NewWriterSize()を使ってバッフ

ジェネリクスの話題になると常に出てくるのが、 for ループの代わりに関数型スタイルで書きたいという要望です。 for ループで書くのは、可読性が悪く、筋力がいるとまで言う人もいます。 しかし、ジェネリクスが追加されても、このスタイルのプログラミングは実用的にはなりません。ジェネリクス以外にも足りない部分がたくさんあるのです。 例えば、次のようなコードを考えてみましょう。 type PointLog struct { ID int64 UserID int64 Point int32 } // 今の書き方 func UserTotalScore(log []PointLog, userID int64) int64 { var t int64 = 0 for _, p := range log { if p.UserID == userID { t += int64(p.Point) }

なんども繰り返される話でうんざりなんだけど、繰り返されるたびに反論するのもアレなので、URL貼れるように記事にしておく。 Goが頑なにジェネリクスいらないというだけ他の言語勢から失笑買ってるというのは自覚して— {{alert()}} (@mizchi) 2017年9月19日 頑なに要らないと言ってる人が具体的にどの発言のことを差してるのか分からないけど、コア開発者たちはツールチェインやランタイムの進化を優先していただけで頑なに拒否してたりはしません。今はツールチェインやランタイムが大分進化したから、Goの適用範囲を広げるためにジェネリクスを含めて機能追加も検討し始めようかっていうフェーズです。 あとどの言語にもちょっと公平的な見方ができなくなった痛いファンはいるもので、そういった人たちをいちいちあげつらってこういう言い方で失笑するのは、別に止めはしないけど自分の格を下げるだけだと思う。

はじめてのにき(2016-03-10) を見て。 Python の Zen の一つ "There should be one - and preferably only one - obvious way to do it." はよく誤解される。 これはもちろん Perl の TMTOWTDI 「やり方は1つじゃない」に対するものなのだけど、反対の「やり方は１つが良い」という意味では決して無い。 現実的なプログラミング言語でそんなアホな目標を持ってはいない。訳すなら「判りやすいやり方が1つは必要だ -- その1つだけなら最高だね」で、 preferably~ の部分は補助的なものだ。 例えば conditional expresson x if cond else y は、普通の if/else 文と一時変数を使えば良いので、新しいやり方だ。でも、これがない時代は、一部のエキスパートが c

2011 Pythonアドベントカレンダー(Python3) - connpass の3日目を担当します。 Python 3 がリリースされてから、 Python の進化は主に Python 3 で行われ、そこから Python 2 にバックポートできるものがバックポートされています（例: GCのチューニング、辞書の内包表記など）。 しかし、 Python 2 は 2.7 で新規開発を終了しており、 2.7 にバックポートされなかった機能はもう Python 3 に移行しないと利用することができません。今日は、そんな機能のひとつである New GIL を紹介します。 なお、今日紹介する内容のほとんどは UnderstaindingGIL で紹介されている内容を僕なりに要約したものです。（ただし、翻訳ではありません）　著作権の扱いがわからなかったのと、代わりに自分で図を書き起こすのが面倒だっ

先日の記事 で紹介した、 manylinux1 wheel を作ってみます。 manylinux1 docker image ビルド環境を Docker image として公開してくれています。 Github manylinux Docker (amd64) Docker (x86) docker pull quay.io/pypa/manylinux1_x86_64; docker pull quay.io/pypa/manylinux1_i686 しておきましょう。 なお、このイメージは CentOS 5 をベースにビルドスクリプトを実行しているだけなので、 vagrant 等で同じ環境を作るのは簡単そうです。 作業ディレクトリを作って docker 内で bash を起動します。 $ mkdir docker $ docker run --rm -ti -v `pwd`/docker

うーん、structural subtypingとダックタイピングは同じものなんだろうか。— Yukihiro Matsumoto (@yukihiro_matz) 2016年9月8日 https://t.co/5Rv86piThC wikipediaによると似て非なる物のようですね。 https://t.co/VwIg39h5M0— INADA Naoki (@methane) 2016年9月8日 この話題について補足しておきます。なお、僕はTAPL脱落組なのであまり正確性は期待しないでください。 背景 Ruby Kaigi で Matz が Ruby3 に向けて考え中の静的型について話されたようです。 少し前から、 Python でも Guido が Dropbox での大量のコードベースを改善していくために type hinting がほしいということで PEP 484 を始めました

ISUCON は Go で参戦しているんだけど、複数のチームが Python で予選通過したらしいので、応援のために Tips を公開していこうと思う。 目次 CPython の GC について 統計情報を出力する 第一世代GCの間隔を調整する Out of Band GC 循環参照を見つけて対処する CPython の GC について CPython のGCは参照カウント＋循環参照コレクタだ。そして参照カウント方式は(幾つかの欠点はあるものの)Webアプリのボトルネックになったりはしにくい。 なのでGCチューニングの基本は次のようになる。 循環参照を避ける 循環参照コレクタの呼び出しタイミングを制御する 循環参照コレクタは、生きているオブジェクトの数がある程度増えると第一世代が実行され、第一世代が一定回数実行されると第二世代が、第二世代が一定回数実行されると第三世代が実行される。 各世代

10/5 に ISUCON 3 の予選に Go 言語で参戦していました。 とりあえずレポートは会社のブログに書いたので、 Go 言語で go-sql-driver/mysql を使って MySQL を使う時に知っておくと良い点をまとめておきます。 ちなみに MySQL ドライバにはもうひとつ MyMySQL というものがあり、 まだ試していませんが、 MyMySQL の方が落とし穴が少なそうな気がします。 sql.Open() が返す DB オブジェクトはコネクションプールをしてくれる なので、自前で DB オブジェクトを使いまわしてコネクションプールを実装しても意味は無いです。 DB.SetMaxIdleConn() で、使い終わってもクローズしないコネクションの数を設定できます。 デフォルトだと使い終わったコネクションを閉じてしまうので、 DB オブジェクト自体をプールしても コネクシ