PHP: fgetcsvでもSJISのCSVをUTF-8として《安全》に読む方法(ストリームフィルタ使用) - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
PHPの正規表現で^$より\A\zがいい理由 - Qiita
正規表現のメタ文字とエスケープシーケンスについておさらい。 メタ文字 ^: (ハット記号) 検索対象（複数行モードでは行）の始まりを言明 メタ文字 $: (ドル記号) 検索対象の終わりあるいは終端の改行文字の前（複数行モードでは行の終わり）を言明 エスケープシーケンス \A: 検索対象文字列の始端（複数行モードとは独立） エスケープシーケンス \z: 検索対象文字列の終端（複数行モードとは独立） 言明 \A, \Z, \z は、（アンカー で説明する）ハット記号やドル記号とは 異なり、オプション設定によらず、文字列の始端または終端だけに マッチします。これらの言明は、PCRE_MULTILINE および PCRE_DOLLAR_ENDONLY オプションの影響を受けません。 \Z と \z との違いは、 \Z は文字列の末尾の改行の前の位置および文字列の 終端にマッチするのに対し、\z は
PHP:文字列が整数かの検証にはis_numeric, ctype_digit, filter_varどれが適切か？ - Qiita
ユーザ入力の文字列が整数かどうかを検証するにあたって、is_numericやctype_digitは適切ではなく、アプリケーションの仕様によってはfilter_varも妥当でない場合がある。CakePHP3のバリデーションライブラリについても問題点があることが明らかになった。なお、Symfonyはis_intやis_numeric、ctype_digitなどに移譲される実装になっており、Laravelはfilter_varに依存しているため事情は同様である。 結論としては、filter_varがアプリケーションの仕様と合致する場合はそれを使い、そうでない場合は正規表現で検証するか組み合わせるほうが良い。CakePHP3のバリデーションライブラリを使うときも同様である。ちなみに、文字列に対してis_intやintvalをかけることは何の検証にもならないので注意されたし。 参考までにis_nu
Doctrine2のBatch ProcessingのdetachをCallbackFilterIteratorでカプセル化してみた - Qiita
大量のデータをあつかう処理のために、Doctrine2にはBatch Processingがあります。このBatch Processingは、findBy() とは違って結果をメモリに溜め込まみません。foreach のループ1回ごとに結果を逐次生成するため、メモリにやさしいのです。CSV出力など全データを参照するような場合は、このBatch Processingを使うほういいです。データが増えた時にもメモリ不足を回避できるからです。 しかし、Batch Processingは自分でメモリ管理をする必要があります。Doctrineは一意マッピング(Identity Map)をしているため、一度生成されたEntityはDoctrine側で参照を持っています。そのため、下記の例の(1)のように、ループごとに EntityManager::detach() をコールして Entity を開放しな
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
わたしたちがDDDを実践するに当たってDoctrineをやめようと決断した動機 - Qiita
断り書き:自分たちがやりたいDDDにDoctrineが必ずしも向いていないという判断をしたものです。Doctrineには非常にお世話になっており、批判するものではありません。どのツールにも適材適所があると思います。 機械的なORMでエレガントに表現できないものがあった（ValueObjectなど） Entityが1テーブルに固く対応していて、さらにその知識がインフラストラクチャレイヤからドメインレイヤに漏れ出していて、密結合が発生していた Doctrineロックから脱出したい。Domain ServiceはRepositoryに依存しており、RepositoryはDoctrineに依存している。Doctrineが破滅への道を歩めば、アプリの心臓であるDomainも道連れとなる。 ストレージロックを脱出したい。ドメインレイヤがある具体的なRepositoryに依存していると、簡単にストレージ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPのハマりポイントのリンク集 - Qiita
