どういうわけか日本では一切話題に上がっていないのですが、Pythonの開発者コミュニティでなんか問題が起きているようです。 どうも話が様々なスレッドにとっ散らかっているうえに半分はDiscordや非公開のところで動いているみたいなので、読み取れていないところが色々あるかもしれません。 誰かが補足してくれるはず。 Proposed bylaws changes to improve our membership experience 最初のきっかけはこのスレッドです。 これは規約の一部を変更する提案であり、その中でも3番目の提案であるAdds provision to remove Members by vote of the Board of Directorsという変更が注目を浴びました。 Python財団にはフェローという制度があり、これはPythonエコシステムやコミュニティに優れた

PHP8.0でJITがサポートされました。 その威力は絶大であり、単純な計算問題であればJITを有効にするだけで1分の処理が8秒になるほどの高速化でした。 そんなJITですが、次のバージョンでさらにブラッシュアップされることになりました。 (PHP8.4としていますが、もしかしたらPHP9.0かも) 以下は該当のRFC、A new JIT implementation based on IR Frameworkの紹介です。 なおCPUとかIRとかさっぱりわからないので、誤りや認識不足が多々含まれています。 誰かがPRで修正してくれるはず。 PHP RFC: A new JIT implementation based on IR Framework Introduction PHP用JITの最初のバージョンはPHP8.0でリリースされました。 その際、我々は最も単純なアプローチを採用しまし

1000000インスタンス生成に8秒強かかっていたのが0.1秒になりました。 なんだこれ。 timelib performance fix Dmitry Stogov へいDerick、https://github.com/derickr/timelib/pull/99のプルリクについて意見を聞かせてくれないか？ この修正でnew DateTimeZone()を170倍改善したよ。 結果、幾つかの現実的なアプリでも目に見える高速化があったよ。 たとえばSymfonyのデモではcallgrindが7%改善した。 この修正は半年以上前に送ったやつなんだけど、PHP8.1に入れてくれたらありがたい。 Derick Rethans 当時のプルリクでは修正必須のステータスだったと思うんだけど、今見てみたらPOSIXの仕様にちゃんと従ってますね。 PHPのmasterに、他のバグフィックスと共にマージ

MLにAutomatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4という投稿があったので紹介してみます。 https://externals.io/message/116323 kocsismate90 最近PHP用の自動ベンチマークフレームワークを作ってるんだけど、その宣伝に来たよ。 最初はis_literalのRFCの性能評価に使ったんだけど、その後多くの問題を修正して新機能も追加したよ。 昔インテルが行った自動ベンチマークを覚えてる人もいるかもしれない。 私はこのプロジェクトに刺激を受け、そして今同じようなことをやっているけど、さすがに彼らほど高度なことはできなさそう。 今作っているphp-version-benchmarksは、 ・完全自動で定期的に実行してくれる。 ・Dockerでローカル実行可能。

Web Audio APIというAPIがあります。 RFC / 日本語訳 ざっくり言うと、ブラウザで音を作ったり出したりできるAPIです。 RFCの時点でフィンガープリントの懸念が大量に書かれてるという有様ですが、実際に実用レベルでブラウザフィンガープリントしている例が存在しました。 FingerprintJSという、そのまんまな名前のライブラリです。 以下は同ライブラリのブログより、How the Web Audio API is used for browser fingerprintingという記事のざっくり紹介です。 How the Web Audio API is used for browser fingerprinting Cookieを使うこともなく、許可を求めることもなく、Webブラウザを識別できることを知っていますか？ この技術はブラウザフィンガープリントと呼ばれていて

Original article:https://medium.com/@bfrancis/the-story-of-firefox-os-cb5bf796e8fb written by Ben Francis. モバイル市場は長らくAndroidとiOSの独擅場ですが、その牙城を崩すために、数多くの企業やコミュニティが挑戦を繰り返してきました。 Windows Phone、BlackBerry OS、Sailfish OS、Harmony OS、Tizen、etcetc… 中でも特に注目されていたモバイルOSのひとつが、Mozillaが開発していたFirefox OSです。 以下は、その始まりから終わりまでの一部始終を描いた物語、The Story of Firefox OSの日本語訳です。 著者のBen Francis( Twitter / GitHub / Medium / Link

Firefox / Safari MozillaはMozilla Specification Positionsというリストを公開しています。 IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。 あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。 Mozilla's Positions Mozillaはどのように評価しているかの分類。 under consideration 評価の検討中。 important 優れた概念であり、Mozillaにとっても重要である。 worth prototyping 優れた概念であるが、プロトタイプを作成し、フィードバックを得て磨きをかける必要がある。 non-harmful 有害ではないが、良いアプローチではなく、取り組む価値

Evercookieは、ブラウザに究極的に永続的なCookieを生成するJavaScript APIです。 その目的は、標準的なCookie、Flash Cookieなどを削除した後でもクライアントを識別し続けることです。 これは、可能なかぎり多くのストレージにCookieデータを保存することで達成します。 いずれかのストレージからCookieが削除されたとしても、ひとつでも残っている限り、Evercookieは残ったデータからCookieデータを復旧します。 Flash LSO、SilverlightもしくはJavaが有効な場合、Evercookieはブラウザを超えて同じクライアント上の別のブラウザにCookieを伝播することすら可能です。 本リポジトリは、Samy Kamkarおよび多くのコントリビュータによって作られています。 Browser Storage Mechanisms E

交差型は何かって一言で言うと型のANDです。 PHP8.0で型のORことUNION型が導入されましたが、これに続いてPHP8.1で交差型が導入されることになりました。 これでPHPでも型パズルマウント取れるようになりますね。 ということで以下はPure intersection typesの紹介です。 PHP RFC: Pure intersection types Introduction 交差型とは、型がひとつの制約ではなく、複数の制約を同時に満たすことを必要とする型です。 交差型は、現在のところ言語ネイティブには対応していません。 かわりにphpdocアノテーションを使用したり、型付きプロパティを濫用したりしています。 class Test { private ?Traversable $traversable = null; private ?Countable $countabl

Don't offer a Free Planという非常に力強い主張があったので紹介してみます。 著者はGuido( Twitter / GitHub / Webサイト )です。 Don't offer a Free Plan もしあなたがSaaSプロダクトを提供しているのであれば、無料プランを提供することに意味はないかもしれません。 無料プランはホスティングコストだけではなく、リアルのコストがかかります。 本サイトでは、これらの検討事項について解説し、そして無料プランにかわる手段について提案します。 The costs of a free plan 無料プランは、ユーザにプロダクトを知ってもらい、そして後に有料プランにアップグレードしてもらうことを期待します。 プロダクトにもよりますが、無料プランのユーザが増えてもサーバ代にはほとんど変化がありません。 しかし、実際には大きなコストがかか

PHPは長きにわたり同期的、すなわち、あらゆる処理を上から順に実行していくというスタイルを取ってきました。 しかしたとえば、複数のURLからデータを取ってきて結果をまとめたいといった場合、時間のかかるHTTPリクエストは同時に投げたいですよね。 この用途にはGuzzleというライブラリが存在し、これを使えば同時にリクエストを投げられます。 しかし、ではHTTPアクセスとDBアクセスを同時にやりたい場合は？ 時間のかかる計算を裏でやりたい場合は？ などと考え始めると、こういった個別のライブラリでは対処しきれません。 ということで汎用的な非同期処理をPHPで書けるようにするRFCが提出されました。 PHP RFC: Fibers Introduction 人類史上ほぼ全ての期間において、人々はPHPを同期的なコードとしてのみ書いてきました。 同期的に実行されるコードのみが存在し、そしてそれを同

Linuxカーネル開発の初期の議論は複数のMLでなされていたので、1997年以前の議論については断片的にしか存在していない。 集められた一部についてはhttp://lkml.iu.edu/hypermail/linux/で公開されているが、これにも抜けがあるので、当時のログを持っている人がいたら提供してほしい。 翻って5.8のMAINTAINERSは19033行もあり、そして1501人のメンテナがリストされている。 THE REST M: Linus Torvalds <torvalds@linux-foundation.org> L: linux-kernel@vger.kernel.org S: Buried alive in reporters Q: http://patchwork.kernel.org/project/LKML/list/ T: git git://git.ker

結果は順にtrue、true、falseです。 これがPHP7までの非厳密な比較(等価)演算子だったわけですが、まあおかしいよねってことで、この挙動がPHP8.0で変更になることになりました。 よもや今さら基本中の基本である比較演算子の動作を弄ってくるとは思わなかったぞ。 以下はSaner string to number comparisonsの日本語訳です。 PHP RFC: Saner string to number comparisons Introduction ==やその他の非厳密な比較演算子を用いた文字列と数値の比較は、現在は、文字列を数値にキャストし、その後整数か浮動小数の比較を行っています。 この結果、多数の不可解な結果が得られますが、中でも注目すべきは0 == "foobar"がtrueになることです。 このRFCでは、文字列が実際に数値型文字列である場合にのみ数値型

$user = null; echo $user->address->country ?? ''; PHPのプロパティは元よりnull安全なので、存在しないプロパティだろうがnullだろうがプリミティブ型だろうがいきなりプロパティを取り出せます。 取れない場合はE_NOTICEが発生しますが、??を使えば黙殺できます。 しかしメソッドはだめです。 echo $user->getAddress()->getCountry() ?? ''; // Fatal error: Call to a member function getAddress() // 1 if (method_exists($user, 'getAddress')) { if (method_exists($user->getAddress(), 'getCountry')) { echo $user->getAddres

2018/11/22にPHP7.3.0 RC6がリリースされました。 計画ではこれが最後のRCで、次は2018/12/06にPHP7.3.0正式版がリリースされる予定です。 そのRC6のパフォーマンスを測定してる記事を見つけました。 以下はPHP 7.3 Performance Benchmarks Are Looking Good Days Ahead Of Its Releaseの日本語訳です。 PHP 7.3 Performance Benchmarks Are Looking Good Days Ahead Of Its Release PHP7.3 RC6は、12月6日に正式リリースが予定されているPHP7.3の最終RC版です。 RC6での変更点はこちらに概略があります。 先日、PHP 5.5.38、PHP 5.6.38、PHP 7.0.32、PHP 7.1.24、PHP 7.2

2020/06/26追記：アルファ版がリリースされたので実際に試してみた JITのRFCが2019/03/21に投票開始されました。 締切は2019/03/28ですが、2019/03/27時点で賛成48反対2でほぼ導入確定です。 JITとは JIT is 何？ PHPは現在は、アクセスが来るたびにソースコードを全部読み取って、opcodeに変換して、順番に逐次実行して、実行が終了したら全てのコードを破棄するというインタプリタ型のプログラミング言語で、処理速度は遅いです。 遅いと言っても、やってる内容からすれば異常なまでに早いんですけどね。 opcodeはCPUやOSなどの実行環境によらず同一のコードが生成されます。 逐次実行するときはさらに実行環境ごとのネイティブコードに変換して実行されます。 OPcacheは、この変換後のopcodeをメモリに保存しておいて、次のリクエストでも使い回すと

// $x*2を返す関数 $mul2 = fn($x) => $x * 2; // 使い方 $mul2(3); // 6 が、なんかV2として復活してました。 しかも今回は提案者として重鎮Nikitaが参戦しています。 NikitaはPHPのコア開発者のひとりで、記憶に新しいところではプロパティ型指定を作った人です。 既にコードもできていてプルリクが出されています。 しかしRFCの提出が2019/03/12で、投票は2019/04/17開始・2019/05/01終了です。 なんでそんなスケジュールきつきつなのだ。 RFC Arrow Functions 2.0 Introduction PHPの無名関数は、単純なことしか行わない場合でもやたら冗長になる場合があります。 使用する変数を毎回手動でインポートしなければならないなど、構文に定型句が多いためです。 このせいで、簡単なクロージャですら

PHP7.4 / PHP7.4その1 / PHP7.4その2 2019/06/13、PHP7.4.0α1がリリースされました。 今後はベータ、RCと完成度を高めていき、7.4.0のリリースは2019/11/28が予定されています。 なお仕様フィックスは2019/07/13で、それ以降は大きな変更は入らないようになります。 逆に言うとそれまでは追加が入る可能性はあるのですが、既にα1も出たことですし、さすがにこれからのタイミングでプロパティ型指定やらアロー関数レベルの大改修が入ることはないでしょう。 ということで前回以降入った新機能や変更点を見てみることにします。 RFC Arrow functions 2.0 賛成51、反対8で受理。 アロー関数です。 // 新構文 $fn = fn($x) => $x + $y; // ↓と同じ $fn = function ($x) use ($y)

PHPはHTTPリクエストが来るたびに全てのPHPコードをバイトコードに変換し、そして実行しています。 毎回そんなことやってるのにあれだけ速度が出るのは驚異的ですが、それでもやはりコンパイルにかかる時間だけどうしても遅くなってしまいます。 そこで、もっと高速化するためにOPcacheのような仕組みが存在します。 これはバイトコードをメモリ上に保持し、リクエストを超えて使い回すことでコンパイルの手間を省略し、高速化を実現するというものです。 効果はというと、単純なものでもターンアラウンドタイムが2/3、大きなフレームワークでは半分以下と、お手軽かつ強力な効果があります。 とはいえOPcacheには、元のPHPファイルに変更があるかどうかを監視したりといった僅かなコストが残っています。 特にバイトコードはファイル単位でしかキャッシュできないらしく、extendsなどで別のファイルを参照している

2019/01/22(JST)にImplement ??= operatorという謎のマージがありました。 RFC RFCは賛成37、反対4の圧倒的多数で可決されています。 なお投票開始は2016/03/24で、終了が2016/04/02です。 つまり、それ以来3年弱ほったらかされていたということです。 ??=ってなに？ RFCでは『Null Coalescing Assignment Operator』と呼ばれています。 どうも適切な日本語がないみたいなのですが、NULL合体演算子(Null Coalescing Operator)から類推すると『NULL合体代入演算子』とかになるんですかね？ 名前のとおり、NULL合体演算子と代入演算子を合わせたような演算子です。 使い方 // NULL合体代入演算子 $id ??= getId(); // これと同じ $id = $id ?? get