はじめに zstd コマンド(zstdless, zstdcat, unzstd なども)は gzip にも対応しています。特にデコードは拡張子を見て自動で gzip と zstd を切り替えてくれるので、 gzip 圧縮されたログと zstd 圧縮されたログが混在している環境でも透過的に扱うことができます。 なので gzip から zstd への切り替えは次のように段階的に進めることができます。 zstd コマンドツール群のインストール 圧縮されたログを扱うときに zstd を使い始める 圧縮フォーマットを zstd に切り替える 性能比較 Debian 9.3 で gzip 1.6 (aptでインストールしたもの) と zstd (1.4.0) を比べてみます。 対象となるファイルは ltsv でゴチャゴチャとアプリの情報を混ぜた重めの apache のアクセスログです。 (5,367

http.ListenAndServe() を使ったサーバーをプロダクションに投入していたのですが、海外からのアクセスが多くなったころにリソースリークが発覚しました。 ListenAndServeのドキュメント ListenAndServeのソースを見るとこうなっています。 func ListenAndServe(addr string, handler Handler) error { server := &Server{Addr: addr, Handler: handler} return server.ListenAndServe() } addr, handler 以外は http.Server のnil値がそのまま使われている事がわかります。この構造体にはいくつかのタイムアウト値がありまが、nil値で初期化されるとタイムアウトなしの状態になってしまいます。 Server型のドキ

Python はデフォルトで多くの警告を表示しません。これはPython開発者ではないエンドユーザーが警告を見た時に混乱するのを防ぐためです。 デフォルトで ignore される Warning は次のとおりです。 (ref: https://docs.python.org/3/library/warnings.html#default-warning-filters) DeprecationWarning PendingDeprecationWarning ImportWarning BytesWarning ResourceWarning これらの warning を Python 開発者が表示しないと、せっかく使っているライブラリが長期間 Deprecation 期間を設けていてもその Warning に気づかないとかいう事が起きます。 また、 warning システムは同じ場所から

$ pip install -r requirements.txt $ pip install flask Collecting flask Downloading Flask-0.12.2-py2.py3-none-any.whl (83kB) 100% |████████████████████████████████| 92kB 3.7MB/s Collecting Jinja2>=2.4 (from flask) Using cached Jinja2-2.10-py2.py3-none-any.whl Collecting click>=2.0 (from flask) Downloading click-6.7-py2.py3-none-any.whl (71kB) 100% |████████████████████████████████| 71kB 3.8MB/s ...

はじめに 機械学習ブームなどにより、 Python を触り始める Rubyist が増えてきたと思います。その際に問題になりやすいのが環境構築です。Rubyだと rbenv がデファクトスタンダードになっているのに、なぜか Python には pyenv に否定的な意見が多いんですよね。 私は pyenv を使っていますし、便利だと思っています。また、 Ruby は殆ど使わないのですが、RubyとPythonのツールスタックの違いについても調べました。 (参考: gem, bundler と pip, venv の比較) その視点から、 Rubyユーザーが自分でpyenvの使い方を自分で決める上で知っておいた方が良いだろうなと思う Ruby と Python の環境の違いをまとめてみます。 tl;dr 丁寧に解説しても、「Python使うにはこんな長い記事を読まないといけないの」とすぐに否

普段は mac で ja_JP.UTF-8 を使ってるけど、 Linux では予想しない挙動の変化が起きるのを嫌って C locale を使う人、いますよね。僕も常にではないけれど結構 C locale 好きです。 でも、 C locale を使うと、 vim が (set encoding=utf-8 を書いていないと) デフォルトで latin1 になって文字化けしまくったり、 Python が (export PYTHONIOENCODING=utf-8 しておかないと) 標準入出力がasciiになって UnicodeError になったりしてツラい気持ちになることもあります。 そんなときは、 LANG=C, LC_CTYPE=en_US.UTF-8 で LC_ALL は設定しないようにするのがただしい locale の設定方法なんですが、最近のモダンな Linux に搭載されてる

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この記事は Let’s talk about logging の翻訳です。 Nate Finch による Go Forum への投稿で始まったスレッド を見てこの記事を書くことにしました。 この記事は Go を対象にしていますが、あなたのいままでのやり方を振り返ってみたら、同じ考え方がより広く適用できると思います。 なんでこんなに足りないの？ 訳注: "Why no Love?" を、「（愛されてないから）機能が足りない」というニュアンスで解釈しましたが、自信が無いです。 Go の log パッケージ はレベル付きのロギングを提供していません。なので手動で debug, info, warn, error のようなプレフィックスを書く必要があります。 また、 Go はパッケージごとにログの出力レベルを制御する方法も提供していません。 比較対象としてサードパーティーのロギングライブラリを見て

expvar パッケージは手軽にメトリクスを公開するのに使えて便利なのですが、複数の値を公開するための例があまり公開されてなくて分かりにくかったので書いておきます。 expvar.Map を使う mychat というチャットアプリを作ってると仮定して、送受信メッセージ数と、同時接続数を公開してみます。 /debug/vars を見た時に、次のような形でメトリクスを公開します。 ... mychat: { "conns": 42, "msg_recv": 10480, "msg_sent": 88946 }, ... package metrics import ( "expvar" ) var ( Map = expvar.NewMap("mychat") // expvar.NewXxx() は直接公開するメトリクスを作成する。 Conns = new(expvar.Int) // Ma

datetime モジュールは Python の標準ライブラリの中でも、使用頻度が高い割に罠が多かったり使い方が難しかったりする、あまりイケてないモジュールだと個人的に思っています。 そんな datetime モジュールですが、 Python 2 のプロジェクトを Python 3 に移行した時に大分コードを整理できてちょっと感動したので紹介しておきます。 unixtime との相互変換 unixtime から datetime.datetime への変換は、 ローカルタイムなら.fromtimestamp() で、 UTC なら .utcfromtimestamp() 関数で行います。 >>> import time >>> from datetime import datetime >>> now = time.time() >>> now 1415542873.099776 >>>