【PHP8.4】メソッド引数のデフォルトnullがついに禁止される - Qiita
よく見たら不自然なんだけどこれまで普通に許されていた、この引数デフォルト値がついに禁止されます。 何がおかしいって型がintなのに引数を渡さないことができてしまうので、矛盾してしまうわけですね。 これはPHPが昔からの仕様を残しておいたためであり、いわゆる歴史的経緯というやつです。 以下は該当のRFC、Deprecate implicitly nullable parameter typesの日本語訳です。 PHP RFC: Deprecate implicitly nullable parameter types Introduction PHP7.1で?T構文、さらにPHP8.0でUnion型がサポートされたことにより、PHPはnull許容値型を正しく書くことができます。 歴史的にはPHP5.0でオブジェクト型、PHP5.1でarray、PHP5.4でcallable、PHP7.0でス
【PHP8.2】動的プロパティが禁止される - Qiita
$dt = new DateTime(); $dt->hoge = 1; var_dump($dt->hoge); // 1 PHPでは未定義のプロパティに値を突っ込むと、特に何の抵抗もなくプロパティが生えます。 しかし、他の多くの言語ではこのような動作にならず、未定義プロパティを突っ込もうとするとエラーになります。 ということでこれを禁止しようというRFCが提出されました。 以下はDeprecate dynamic propertiesのRFCの紹介です。 PHP RFC: Deprecate dynamic properties Introduction 宣言されていないプロパティに書き込みを行うと、PHPでは何もエラーが出ずに動的にプロパティが作成されます。 現代のコードにおいて、これが意図的に行われることはほとんどありません。 このRFCでは、動的プロパティを非推奨とし、将来的に削
【PHP8.0】PHP8で警告のエラーレベルが軒並み厳しくなる - Qiita
多くの警告について、PHP8.0でエラーレベルが変更されます。 これはReclassifying engine warningsというRFCで受理されたものです。 提案者はいつものNikita。 影響の大きい未定義変数アクセスについては個別に紹介しましたが、ここではそこで紹介しなかった細かい警告について見ていきます。 これまでE_NOTICEだった警告の一部がE_WARNINGに、これまでE_WARNINGだった警告の一部が例外になります。 E_WARNINGを抑制するような書き方をしている場合、PHP8では動かなくなる可能性が高いので気をつけましょう。 現在E_NOTICE以下であればいきなり動かなくなることはありませんが、そもそも抑制する書き方がよくないので、なるべく修正した方がよいでしょう。 エラーレベルの変更がない警告も並んでいるので、もしかしたら全警告が列挙されてるのか？と思った
【PHP8.1】PHP8.1で削除される機能 - Qiita
Nikitaをはじめとする一部のstrictぺちぱー達は、PHPのレガシー機能の削除に熱心に取り組んでいます。 まあ実際、初期のPHPには特にですが、いったいなんでこんなものをという思い付きのような機能がたくさんありましたからね。 そのあたりはPHP7からPHP8.0にかけてだいぶ綺麗に片付けられてきたのですが、まだまだおかしなものも残っています。 そんなわけで以下は、それらを削除しようというRFC、Deprecations for PHP 8.1の紹介です。 投票期間は2021/06/30から2021/07/14まで、有権者の2/3の賛成で受理されます。 Deprecations for PHP 8.1 このRFCでは、以下の機能をPHP8.1で非推奨とし、PHP9.0で削除することを提案します。 受理された提案 以下の提案は受理されました。 PHP8.1以降では使用しないようにしましょ
StackOverflowからのコピペをやめろ。今すぐにだ。 - Qiita
Original article:https://dev.to/dotnetsafer/rip-copy-and-paste-from-stackoverflow-trojan-source-solution-4p8f その昔コピペできない文章というものがありました。 実際は単にフォントを変えているだけというものですが、人間の目に見える文字と実際の文字が異なることを利用した攻撃の一種と見ることもできます。 さて、最近になって似たような攻撃に関する論文が公開されました。 人間には見えない文字を織り交ぜることによって、一見問題ないコードが実は脆弱になってしまうというものです。 ただ論文は堅苦しいうえに長くて読むのがつらいので、具体的に何がどうなのかよくわかりません。 平易に解説している記事があったので紹介してみます。 以下はDotnetsafer( Twitter / GitHub / Web
CSSを非同期ロードする最も簡単な方法 - Qiita
CSS読み込みの<link rel="stylesheet">は同期なので、レンダリングブロックします。 どういうことかというと、CSSファイルの読み込み・パースが終わるまで画面描写が止まってしまいます。 これに対策する方法としてpreloadというものが策定されましたが、対応状況が微妙です。 2019年7月時点でもブラウザシェアが8割しかなく、Firefoxは当面対応するつもりがないようです。 とはいえ残り2割のためにloadCSSを突っ込んだりとか始めると本末転倒感に溢れます。 全ブラウザ対応のためには、なんにしろ結局JavaScriptをこりこり書くしかない状況でした。 が、なんかすっごい簡単な対処法があったので紹介してみます。 以下はScott Jehlによる記事、The Simplest Way to Load CSS Asynchronouslyの日本語訳です。 ちなみにSco
PHPで優先度つきキュー - Qiita
PHP5.3でSplPriorityQueue、優先度つきキューが実装されました。 取得時、第二引数の値が高いものから順に並べ替えられます。 データの種類によっては、自力でソートする必要が無くなります。 <?php $queue = new SplPriorityQueue(); $queue->insert('低い', 10); $queue->insert('最優先', 100); $queue->insert('にばんめその1', 50); $queue->insert('にばんめその2', 50); $queue->insert('一番低い', 1); // 個数 → 5 print('件数:' . $queue->count()); // 一番目を閲覧。これは使っても無くならない。 print('一番目:' . $queue->top()); // 優先順位の高い順に取り出す f
PHP8.0.0α1がリリースされたのでさっそくJITの威力を体感する(した) - Qiita
本当かよ？？？？？？？？？ まずPHP7.4.7からPHP8にアップデートするだけで処理時間が1割削減されています。 ただでさえ新機能てんこ盛りだってのに、そのうえ速度も上がるとかどうなってるんだPHP8。 次いでopcacheを有効にすると処理時間が半分になります。 最後にJITを有効にしたら、処理時間がopcache有効状態の30%になりました。 30%縮まりました、ではありません。 なんだこれ。 ということで、JITを有効にするだけで、処理時間がPHP8デフォルト設定の13%になりました。 どういうことかというと、元々1分かかっていた処理が8秒で終わるようになります。 足枷を外したとかいうレベルじゃねーぞ。 これ本当に計算してるのか？ 計算結果が固定値だから結果だけどこかに保存してるとかじゃないよな？ しかもこれ、opcacheやJITの設定はほぼ初期値で、とりあえず有効にしただけと
PWAアプリを3つのアプリストアにリリースして学んだこと
以下はI built a Progressive Web App and published it in 3 app stores. Here’s what I learned.の日本語訳です。 I built a Progressive Web App and published it in 3 app stores. Here’s what I learned. 一ヶ月と、数百ドルと、お役所仕事。 先日Chavah Messianic Radioというアプリをリリースしました。 PWAで作られたPandoraのような音楽プレイヤーで、これをGoogle Play、iOS App Store、Windows Storeの3アプリストアに展開しています。 この経験は苦痛に満ちた、そして啓発的なものでした。 ここに私が学んだことを記述します。 Why? まずあなたは、こう思うかもしれません。
JavaScriptの厳密な曖昧な比較 - Qiita
PHP / JavaScript JavaScriptの等価演算子は==と===の2種類です。 ==は値の比較だけ行い、===は値と型の両方を比較する、とよく言われますが、実は正しくありません。 正しくは、===は型と値の比較を行い、==は両方の型を揃えてから===で比較する、です。 この自動型変換、勝手に行われるうえに動作がアバウトでバグの温床だからやめろー==滅ぶべし慈悲はない、とかよく言われますが、実際はアバウトどころか厳密な定義に基づいて正確に動作しています。 きちんと理解して使えば強い味方となってくれるはずです。 詳細な定義がECMA2016の7.2.13 Abstract Equality Comparisonにあったので見てみましょう。 以下は==および===を表す擬似コードです。 ===を使って===を定義してるので正確なものではありませんが、まあイメージと思ってください。
2018年のパスワードハッシュ - Qiita
数年前であれば仕方なかったところですが、2018年の今となっては、パスワードハッシュの手動計算はもはや"悪"です。 まずログイン認証と称してmd5とかsha1とか書いてあるソースはゴミなので投げ捨てましょう。 hashやcryptは上記に比べればずっとマシですが、使い方によっては簡単に脆弱になりえます。 あと『パスワードを暗号化する』って表現してるところも見なくていいです。 PHPには、ハッシュに関わる諸々の落とし穴を一発で解消してくれるpassword_hashという超絶便利関数があるので、これを使います。 というか、これ以外を使ってはいけません。 以下はフレームワークを使わずに実装する際の例示です。 フレームワークを使っている場合は当然その流儀に従っておきましょう。 ハッシュの実装 データベース ユーザ情報を保存するテーブルを作成します。 パスワードカラムの文字数は、システム上のパスワ
PHP5では$thisを書き換えられない - Qiita
<?php class HOGE{ public function change(){ $this = new stdClass; } } Fatal error: Cannot re-assign $this http://thinkit.co.jp/free/marugoto/1/6/1/ 過去の遺物だったようです。 いやあ本当に良かった。 これはコンパイル時にチェックしているようで、HOGEクラスをnewせずともこのエラーが出ます。 ん？コンパイル時にチェック？ つまりはこういうことか？ <?php class HOGE{ public function change($target){ $$target = new stdClass; } } (new HOGE())->change('this'); 可変変数を使って無理矢理$thisを差し替えることに成功しました。 もっとも、あ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
