ISUCON 8 予選の Go 初期実装に見る初心者コード - methaneのブログ
会社のBlogにも書いたのですが、ISUCON 8 予選で負けてきました。 さて、 ISUCON の初期実装の定番として、初心者が書いたようなSQLやコードになっている点が挙げられます。 今回の Go の初期実装もその定番にもれず、初心者がやりがちな、Goの良さを殺してしまうコードがありました。 今回負けた反省点の一つとして、アプリの書き換えを二人でやっていたのでコンフリクトを恐れてそのリファクタリングを怠ったというのもあります。 Goで本戦に参加されるチームの方にはぜひこれを克服してもらいたいと思います。 アンチパターン: 長い無名関数 例: https://github.com/isucon/isucon8-qualify/blob/9d7890f5433bdaf2cec75b4cdf1ebd0d9a531281/webapp/go/src/torb/app.go#L404-L492
RHEL 7.5 で Python 2.7 が deprecated になりました - methaneのブログ
Red Hat Enterprise Linux 7.5 がリリースされ、そのリリースノートで "Python 2 has been deprecated" とアナウンスされました。 Chapter 54. Deprecated Functionality - Red Hat Customer Portal Python 2 has been deprecated Python 2 will be replaced with Python 3 in the next Red Hat Enterprise Linux (RHEL) major release. 次のメジャーバージョンでは Python 2 が Python 3 に置き換えられるから、 RHEL 7.5 から Python 2.7 が deprecated 扱いになるということです。 Ubuntu 18.04 LTS では m
Go が for ループをやめるために足りないもの - methaneのブログ
ジェネリクスの話題になると常に出てくるのが、 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) }
Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ
なんども繰り返される話でうんざりなんだけど、繰り返されるたびに反論するのもアレなので、URL貼れるように記事にしておく。 Goが頑なにジェネリクスいらないというだけ他の言語勢から失笑買ってるというのは自覚して— {{alert()}} (@mizchi) 2017年9月19日 頑なに要らないと言ってる人が具体的にどの発言のことを差してるのか分からないけど、コア開発者たちはツールチェインやランタイムの進化を優先していただけで頑なに拒否してたりはしません。今はツールチェインやランタイムが大分進化したから、Goの適用範囲を広げるためにジェネリクスを含めて機能追加も検討し始めようかっていうフェーズです。 あとどの言語にもちょっと公平的な見方ができなくなった痛いファンはいるもので、そういった人たちをいちいちあげつらってこういう言い方で失笑するのは、別に止めはしないけど自分の格を下げるだけだと思う。
Windows では2020年を待たずに Python 2.7 が使い物にならなくなっていく - methaneのブログ
昨日 mysqlclient 1.3.10 をリリースしました。 今までは Windows 版の wheel は Python 2.7 だけに提供していたのですが、 1.3.10 からは 3.5 と 3.6 だけに提供して 2.7 はドロップしました。 そもそも今まで Python 3 に wheel を提供できてなかったのは、 MySQL Connector/C の VC14 (VS2015) に対応したライブラリが提供されておらず、 Python 3.5, 3.6 は VC14 でビルドされていて VC12 用のライブラリにリンクすると大量のエラーでるわ自分で手順読みながら頑張って MySQL をソースからビルドしてもなんか動かないわで諦めてたからです。 それが、2年待て、よーーーやく MySQL Connector/C 6.1.9 から VC14 のライブラリが同梱される用になりまし
manylinux1 wheel を作ってみる - methaneのブログ
先日の記事 で紹介した、 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
Wheel が Linux でもバイナリパッケージに対応しました - methaneのブログ
PEP 0513 -- A Platform Tag for Portable Linux Built Distributions | Python.org 今まで Windows と Mac では、ビルド済みのバイナリ形式の拡張モジュールを wheel にして配布することができました。 WindowsやMacに比べてLinuxは環境の差が激しいのでバイナリ wheel に対応していなかったのですが、有名なディストリであればだいたい動くようにするためにどうすればいいか (glibc の古いAPIしか使わないなど) を勧告としてまとめて、十分実用的だと判断されたようです。（ただしこれは勧告であって、実際に pip や PyPI でこのルールに則っているかチェックされるわけではないようです） manylinux1 policy 性質上、何らかのライブラリのバインディングを提供する拡張モジュール
CPython の Core Developer になりました - methaneのブログ
Python 3.6 に取り込まれた dict の新実装などでコアコミッターに興味を持ってもらい、 Core Developer (要するにコミッター) に推薦しようか？という提案をもらいました。 最初はコミッターとか面倒そうだし、コミットメッセージとかNEWSエントリー（通常パッチをコミットするときにコミッターが書く）とかを英語で書くのも英語が得意な人がやったほうがいいだろうし、とりあえず github に移行するまでは様子見しておこうと思ってたのですが、 dict 関係のパッチがいくつもレビュー待ちでなかなかコミットされないのを見て「やっぱりアクティブなコミッターが全然足りてない」と考え直し、志願することに。 で、先月末にコミット権をもらった（というか push できる権限を持った hg アカウントに ssh 鍵を登録してもらった）のですが、新米コミッターは簡単なパッチでも他のコアコミ
Python 3.6 の（個人的に）注目の変更点 - methaneのブログ
Python 3.6b1 がリリースされましたね。（フライング） beta1 ということで、 3.6 に向けた新機能の追加は (provisional package を除いて) 終了です。ただし、仕様が確定したと言うわけではなくて、beta版に対するフィードバックを元に新機能を修正したり、最悪 revert して 3.7 に持ち越しにされる可能性もあります。 なお、 3.6b1 が出る前の1週間が core dev sprint があり、そこでめちゃくちゃ大量に大きめの変更が入りました。なので、常用環境には全くオススメできませんが、OSS開発者だったら .travis.yml に python: "nightly" を追加してリグレッションの発見に貢献したり（←これめっちゃ有り難いです）、それ以外の人も 3.6 を試してみて早めにフィードバックをしてもらえると、年末の 3.6 がより完成
prompt_toolkit がアツい - methaneのブログ
とりあえず mycli と aws-shell のスクリーンキャストを見てください。 prompt_toolkit はこのようなリッチコンソールアプリを作るためのライブラリです。 Windows でも動きます。 Jupyter (ipython notebook) を切り離した、コンソール版の ipython も次のメジャーバージョンでは readline ベースから prompt_toolkit ベースに作りなおされています。 ipython 以外にも ptpython というシェルもあり、 ipython の各種 magic が不要な場合はこちらで十分でしょう。 https://github.com/jonathanslenders/python-prompt-toolkit#projects-using-prompt-toolkit には、他にも prompt_toolkit を採用
Python を速くする取り組み - methaneのブログ
速い Python 実装といえば PyPy が有名ですが、 Python 3 へのキャッチアップが遅い、 CPython が持っている Python/C API のサポートがまだ弱く遅い、などの欠点があります。 また、 Google の1年プロジェクトだった Unladen Swallow もありました。これは CPython をフォークして LLVM で JIT を実装するものでした。この fork 実装は終わりましたが、この時期まだ不安定だったLLVMへの貢献は大きく、（ちゃんとおってないので憶測ですが）現代LLVMを利用したJITを実装しているプロジェクトは全部間接的に Unladen Swallow の成果の上に成り立っていると言えるかもしれません。 終了した JIT プロジェクトといえば、 psyco もありました。これはベタに CPython の JIT を実装していましたが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
