Hatena::ブログ(Diary)

hnwの日記 このページをアンテナに追加 RSSフィード

[プロフィール]
 

2014年10月16日(木) GitHub ユーザーの ID 900万件を公開しました このエントリーを含むブックマーク このエントリーのブックマークコメント

https://github.com/hnw/github-login-idsで、GitHubユーザー/オーガナイゼーションのID約900万件を含んだCSVファイルを公開しました。


これはGitHub APIを使えば誰でも入手できる情報ですが、全部取得しようと思うと丸一日かかるので*1、公開しておくことは一定意味があるかなと考えています。


これによれば、2014/10/16現在github.comには約850万ユーザーと約40万オーガナイゼーションが作られていることがわかります。また、サービス初期には「-」から始まるログインIDが許されていたこともわかります。(例:https://github.com/-/


他に面白い使い方を思いついた方は教えてくださいませ。

*1GitHub APIは1ユーザーあたり1時間に5000リクエストまでに制限されているため

トラックバック - http://d.hatena.ne.jp/hnw/20141016

2014年10月12日(日) PHPカンファレンス2014でPHPNGのLT発表をしてきました このエントリーを含むブックマーク このエントリーのブックマークコメント

10月11日に開催されたPHPカンファレンス2014でLT発表してきました。以下が発表資料です。



5分では喋りきれない題材を選んでしまった感もありましたが、まだ未確定の情報を多く含んでいる状況ですからLTで良かったと思っています。プレゼン中の下線部は参考URLへのリンクになっているので、興味がある方はリンク先も見てみてください。


PHP7のリリース時期についてはまだまだ流動的だと思いますが、今のところdmitry, laruence, nikicを中心にノリノリで作業しているようなので、1年後リリースを目指して頑張って欲しいですね。


さらに深掘りしたい方のために

今回のプレゼンでは伝えきれませんでしたが、PHP7からは内部的な変数型の扱いとして、immutable(不変)という概念が導入されました。ざっくり言うとboolean, integer, floatがimmutableです。このimmutableな型については今までの参照カウンタを増減してポインタ渡しする形をやめ、即値をコピー渡しするようになりました。つまり、これまでPHPの特徴だったコピーオンライトが一部の変数型については即時コピーになるということになります。


この変更により、速度でもメモリ消費でもメリットがあるということのようです。しかし、今まで64bitポインタを受け渡していたのが128bitの構造体をコピーすることになるので、メモリ消費量の観点では損をする可能性もありそうですよね…。このあたりは僕もわかっていないので、今後調べていきたいと考えています。


詳しくは「PHPNG Implementation Details」などをご確認ください。


他のセッションの感想など

「HHVM + Hack == PHP++」は面白かったですね。JITコンパイルしているHHVMはmicrobenchmarkやマンデルブロー集合の計算などでは圧倒的に有利なわけですが、「microbenchmarkで速くても意味がない、実アプリで速いかどうかが大事だ」ということを言っていたのは非常に好感を持ちました。


他のセッションも楽しいものが多く、LTも非常に盛り上がりました。見られなかった講演も面白そうなものが多かったので、今から動画を見たいと思っています。


懇親会は相変わらず時間足りない印象で、あの人にも声かけとくんだったわー、なんて後から思ったりします。アイコンだけは見たことがある人の実体(?)を見ると何となく安心したような気持ちになるので、一言でも会話しておきたいと思うんですが、僕だけなんでしょうか。


何にせよ今年も楽しいカンファレンスでした。運営スタッフの皆様、今年も本当にお疲れさまでした。

トラックバック - http://d.hatena.ne.jp/hnw/20141012

2014年9月26日(金) PHPでAPC/APCuのCAS機能を使うときの注意点 このエントリーを含むブックマーク このエントリーのブックマークコメント

PHPAPC/APCuエクステンションをKVSとして使うときの話題です。


APC/APCuにはCAS(楽観ロックに基づくアトミックな値の書き換え)の関数として次の3つが用意されています。


  • apc_cas ― 古い値を新しい値に更新する
  • apc_inc ― 保存した数値を増やす
  • apc_dec ― 保存した数値を減らす

memcachedにも同様の機能があるので一見すると悩まず使えそうですが、実は罠があります。APC/APCu自体は全ての型の変数値をストアできるのですが、これらの関数については整数しか扱えないため、この機能を使う場合に限っては最初にストアする値を整数型にしておく必要があります。整数型以外の値がストアされていた場合、型エラーとして扱われて失敗します。


これの何が罠かというと、これらの関数がfalseを返したときに、ロック競合だったのか型エラーだったのかの区別が付かないという点です。ロック競合は一時的なエラーなのでリトライする必要がありますが、型エラーは永続的なエラーですのでリトライしても無意味です。エラーへの対応が異なるにもかかわらず、その区別がつかないインターフェースなので、かなり使いにくいと感じます。


楽観ロックと悲観ロック

用語の説明もしておきます。ロック方式の分類として、楽観ロックと悲観ロックという2種類があります。悲観ロックは、要するにRDBで使われるロック方式です。トランザクション処理を行う場合に明示的・暗黙的にロックを取得し、同時に同じロックを取ろうとするとブロックされて待たされます。


一方、楽観ロックは概念的にロックを取得しない*1ような方式です。その代わりに、全員が「以前自分が値を取得したときから他の人が値を更新していなければ、この値に更新したい」というリクエストを投げます。他人と同時にこの処理を行うと、一方の処理が成功し、他方はノンブロッキングで失敗が返ってきます。たとえばmemcachedなどではCASと呼ばれる楽観ロックに基づくアトミックなデータ更新機能を提供しています。

続きを読む

*1:実装上はごく短い区間のロックを取ります

トラックバック - http://d.hatena.ne.jp/hnw/20140926

2014年8月24日(日) PHPでHTTPの並行ダウンロードを実現する(Guzzle編) このエントリーを含むブックマーク このエントリーのブックマークコメント

PHPで最近注目のHTTPクライアントライブラリGuzzleがあります。日本での知名度はまだまだという印象ですが、かなり高機能かつ真面目にメンテナンスされている印象で、今後のデファクトスタンダードになりうるライブラリと言えるでしょう。


本稿ではこのGuzzleを使ってWebサーバから並行にダウンロードする方法を紹介します。Webブラウザのように同時に複数コネクションを管理しながらKeep-Aliveでコネクションを使い回しますので、下手なコードで実現するより接続先Webサーバにも優しいはずです。


Guzzleの特徴

まずは、Guzzleについて僕が特徴的だと思う点を紹介します。



欠点は巨大すぎることと、マニュアルの日本語訳がまだ無いことくらいでしょう。


Guzzleのバージョン

Guzzleを使う上で、Guzzleのバージョンには要注意です。GuzzleにはGuzzle 3とGuzzle 4と2つのバージョンがあります。同じ機能でもGuzzle 3とGuzzle 4とでメソッド名が変わっていたりするので、検索で見つけた記事を読むような場合は注意してください。


Guzzle 3とGuzzle 4は異なるネームスペースを利用していますので、どちらを使っているかは一目瞭然です。Guzzle 3の名前空間は「\Guzzle\」から始まり、Guzzle 4は「\GuzzleHttp\」から始まります。


また、Packagistでのパッケージ名もGuzzle 3は「guzzle/guzzle」、Guzzle 4+は「guzzlehttp/guzzle」となっていますので、composer.jsonに書く際も注意が必要です。


Guzzle 4は今年の3月にリリースされたばかりですが、今から使うならこちらを使った方が良いでしょう。本稿でもGuzzle 4を利用しています。


並行ダウンロードするサンプルコード

Guzzleの一般的な使い方は他のページを見て頂くとして、早速並行ダウンロードのサンプルコードを紹介します。このコードはジェネレータを使いたかったのでPHP 5.5以降でしか動作しませんが、Guzzle 4はPHP 5.4以降で動くはずです。

続きを読む

トラックバック - http://d.hatena.ne.jp/hnw/20140824

2014年8月9日(土) PHP 5.4.4から==の挙動が一段と難しくなりました このエントリーを含むブックマーク このエントリーのブックマークコメント

PHPの==は両辺を適当に型キャストしてから比較するような演算子です。この型キャストの規則は難解すぎる上にドキュメントも不十分なため、PHPプログラマでも完璧に理解している人はほとんど居ないくらいの印象です。バグの原因になりかねないため、なるべく==を使わないようにしているPHPプログラマも多いはずです。


ところで、この==演算子の挙動がPHP 5.4.4から変更されていることはあまり知られていません。本稿ではこの内容を紹介します。


Bug #54547 の騒動

まずはこの仕様変更の経緯を紹介します。


2年ほど昔、Hacker News2^63付近の整数に対応する文字列をPHPで比較したときの挙動がおかしいというスレッドが盛り上がったことがありました。具体的には、PHPでは「'9223372036854775807' == '9223372036854775808'」がtrueになるという話題で、PHPの仕様をDISるような流れでした。


僕のように古くからのPHPユーザーにとっては==の挙動がキモいことは常識ですし、この例で浮動小数点数比較されているのも一目瞭然、他の言語の人が叩きに来るのも日本ではよくあることで、海外も周回遅れで同じ流れになってるのかなーというくらいの印象でした。僕からするとこれは仕様ですし、==の実装は複雑すぎて整合性を保ちつつ不満を解消するような仕様変更は不可能だと感じていたため、いくら叩かれようが修正はありえないと思っていました。


ところがPHP中の人がムシャクシャしていたのか何なのかはわかりませんが、これをバグとして修正する流れになりました。そのバグ報告と修正までの流れは「PHP :: Bug #54547 :: wrong equality of string numbers」で確認することができます。これがPHP 5.4.4から取り込まれており、今回紹介する内容ということになります。


PHP 5.4.4での変更内容

PHP 5.4.4からは、上で紹介した'9223372036854775807' == '9223372036854775808'」がfalseを返すようになっています。


この変更の詳細についてマニュアルなどには記述が見当たりませんが、ソースパッケージの./UPGRADINGに次のように書いてあります。


Long numeric strings that do not fit in integer or double (such as

"92233720368547758070") are compared using string comparison if

they could otherwise result in precision loss - since 5.4.4.


翻訳すると次のようになります。


整数浮動小数点数におさまらないような巨大な数値文字列("92233720368547758070"など)を比較する場合に、

文字列比較しないと精度が落ちるような場合には文字列比較が使われます。(PHP5.4.4から)


そもそも言葉足らずなのですが、これは数値文字列同士を比較する場合の話題です。PHP 5.4.3以前では数値文字列同士を比較する場合はかならず整数または浮動小数点数にキャストされてから比較されていました。しかし、キャストで精度が落ちるような数値文字列同士の場合は文字列比較するよ、というのがPHP 5.4.4での変更ということになります。


説明のため、64bit環境のPHP 5.5.11での実行例を示します。

続きを読む

norinori 2014/08/10 14:14 騒ぐ理由が分かりませんね。

hnwhnw 2014/08/10 14:49 特に分かっていただく必要は無いのですが、もし僕がこのコードを業務でコードレビューしたとすれば、何かしらコメントすると思います。普段のお仕事の内容が違うのかもしれませんね。

eighteight 2014/08/10 15:55 ソースコード読んで細かい事にネチネチ言ってるほうがよっぽどキモいと思う
チミが問題だと思うならバグレポなりなんなりして本家に反映させたほうがよっぽど有意義だよ

DSHDSH 2014/08/10 15:57 そもそも精度が怪しい数値をイコールで比較すること自体が間違ってるし、
バージョン上げるためにいちいちソース確認しなきゃなんないような
タイトな設計ならPHPなんて使わずにフルスクラッチで書くってば。

てゆっか、bccomp()でいいんでない?

hnwhnw 2014/08/10 17:33 eightさん:
ソフトウェア技術者にとってソースコードこそ最強の1次情報源だと思いますが、ソースコード読む奴キモいとか言う人が技術者を名乗ってるとしたら楽しい業界ですね。

DSHさん:
確かにサンプルコードのようなコードを書くことはまずありえないでしょう。しかし、==同様の比較はin_array関数やsort関数でも行われるので、同様の処理を書いてしまう可能性はゼロではないはずです。PHPプログラムを読み書きする仕事であれば、==の挙動を把握しておくことは重要だと思います。

また、OSSを採用する上でいざとなったらソースを確認する気概は重要だと僕は思います。そのコストが非現実的だと思うならプロプライエタリ製品を使うべきでしょう。たとえPHPを使わなかったとしても、コンパイラにもOSにもバグはありえます。

eighteight 2014/08/10 18:50 ソース読むことがキモいなんてただの一言も言ってない。
粗探ししてはdisるだけで俺phpソース読んでてかっこいいだろ、ってのが言いたいことなのがキモい。
ソースコード読めるのに日本語が読めないとしたら楽しい世界ですね

hnwhnw 2014/08/10 18:53 eightさん:
一応断っておくと、僕は日本人の中ではかなりPHPのバグレポ書いてる方ですよ。30件くらいですけど。パッチも採用されてる。で、あなたは?

DSHDSH 2014/08/10 23:47 まー、そこらへんは概ね同意。
部下がそんなコード書いてたら小一時間問い詰めるとこなんだけど、
ソフトウェア資産(笑)が地雷抱えてることは多々あるんで。

hnwhnw 2014/08/11 10:40 本体のソースコード読んだりバグレポ書いたりパッチ送ったりだけがcontributionじゃないし、そうしないと使えないなんてことも無いはずですが、本体のソースコードをもっと皆がカジュアルに読んだ方が各個人にとっても世界にとってもプラスになるんじゃないかなーと僕は思ってます。念のため補足でした。

トラックバック - http://d.hatena.ne.jp/hnw/20140809
 
ページビュー
1227491