インデントはタブかスペースか 宗教戦争

 インデントの文字コードをタブにするかスペースにするか、好みが別れると思います。
半数以上の人はスペースを好むと思いますが、有名オープンソースでもタブの所は結構あります。
感覚としては、日本ではスペース派が圧倒的でしょうか。

私は最初から長年スペースを利用していました。
当時はそうしなければならない理由があったためです。

■スペースが圧倒的な支持を受けた理由

人によって開発環境がバラバラであり、エディッタの動作設定項目が無いのが当たり前な時代でした。
そしてエディッタによってタブ幅が異なり、変更できません。
見た目、タブなのかスペースなのか区別する機能のあるエディッタなんかありません。
タブではなくうっかりスペースを使う人が続出します。初心者に多い。
自分のエディッタのタブ幅に合わせてスペースを打つことになります。

カオスです

そんな事故が多いため、環境に左右されないスペースによるインデントが広まっていきました。

■そして今

伝統的にスペースを使っている人が多い状態です。
今はただのテキストエディッタを使うような人ではなければ、どちらでも問題ない時代です。

私は長年スペース派でしたが、環境の高性能化により、タブ派に転身しました。
タブのが何かと扱いが楽なのです。スペース時代のストレスが一気に無くなり快適にコーディングできるようになりました。
なので、私のプロジェクトではタブがルールになっています。

■タブ派になった理由

・今の開発はPHPのみ ※phpのプログラミングでは　phpstormを使うのが常識レベルになった。
・スペースとタブを可視化してるのだが、スペースだと見た目が汚くてみにくい。
・スペースで入れ子だと、区切りが分かりにくい場合がある
・スペースだとカーソルキーでの移動がつらい。
・スペースだと連打で入力する人がいる。個数違う。オープンソースで多い。
・タブなら、好みのインデント幅で表示できて便利。
・文字先頭からコピーする時、タブなら適当でもしっかり先頭からコピーできる。スペースがあると狙い定めるの面倒。

他にも色々あると思いますが、ぱっと思い出せたのはこのぐらいです。

もちろんタブは万能ではありません。
スペースのが好ましい場面もあります。
あくまで私の仕事では、わざわざスペースにする必要性を全く感じないというだけです。

■タブの限界

タブが使えるのは、タブをしっかりサポートしている環境だけです。
例えばssh接続してコンソール上から書き換える物なんかは、タブが使えません。
ブラウザのtexarea要素を使って書き換える場合も、標準ではタブをサポートしていません。
私の場合はJavaScriptでタブ入力を可能にしましたが。
他にも、タブが使えなかったり、不便だったりするケースがあると思います。

■結論

少人数特定の人のみで開発を行い、全員タブがまともに扱える環境ならば、タブ。
初心者が多かったり開発環境がバラバラすぎた場合、どんな環境でも耐えられるスペースが無難って感じがします。

str_replace はマルチバイト対応関数です

初心者がよく勘違いする関数に、 str_replace があります。

str_replace はマルチバイトに対応していないと思い込み、 mb_str_replace を自作したり、他の関数で代替する人がいます。

文字化けする理由は簡単です。
文字コードが正常に設定されていない状態ですので、正しく設定してください。
これについては、公式のドキュメントにもユーザーコメントがあります。

https://www.php.net/manual/ja/ref.mbstring.php

たとえば、PHPのデフォルトエンコードがUTF-8に設定されているのに、ソースファイルをEUCにするとマルチバイトの扱いが大変になり文字化けの原因となります。不慣れな初心者がやりがちです。

文字化けだけならいいですが、文字コードが正しく扱えていないと脆弱性が発生する可能性があります。

文字コードは正しく扱いましょう。

メールがスパム判定されないよう設定

設定の前に、IPアドレスがクリーンかどうかはチェックするべきです。

ブラックリストはIPアドレス単位で行われます。　ドメイン単位ではありません。

AWSのEC2からメールを送信する場合、固定IPにしてドメインを割り当てる必要があります。

SPFを設定します。

広く使われており、送り先によっては必須です。

DKIMはあると良いですが。無くても今はまだ大丈夫だと思います。

heloネームにサーバードメインを指定する必要があります。

sendmailなどの設定にあります。

デフォルトはローカル名なので、ほぼスパム判定されます。

送信元や返信先につかうメアドのドメインは、DNSにmxレコードが無いと偽装なのでスパム判定されます。

あとは実運用で人間がスパムだと報告すればブラックリスト入りするので、スパムと思われない運用が必要です。

Amazon Pay実装の感想

他の国産決済と違って、仕様書が存在しないのが一番大きいです。海外ではこういうのが普通なのですかね。オープンソースと同じ感じなのかな。
リファレンスとか一部機能紹介みたいなガイドは存在しますけど、結構間違っているので、自分で調査が必要でした。

任意項目となってても、必須だったり。
デフォルト値が違っていたり。

ま、さわってればすぐわかりますけど。
あと最近追加されたFAQページはまともっぽいです。

SDKを使うには、SDKのソースを見る必要があります。
主な使い方はSDKのページに書かれていますけど、書かれていない事もあります。

実装時に注意が必要だと思ったのは、

・ログインウィジェット。
ログインしたら次のページに進みたい～って処理をするとき。
onSignInを使います。これはログインが完了した後に実行されます。
authorizationは、認証処理が終了したときに実行されます。すなわちキャンセルしてログインしなくても実行されます。

・定期購入で配送先が空？
InheritShippingAddressパラーメータを追加する必要があります。
デフォルトではtrueと書かれてますが嘘です、デフォルトはfalseになっています。
今はFAQにも書かれていますね。
任意項目ですが、実質必須項目です。

・住所ウィジェットを２つ同時に使いたい
オーダーリファレンスIDは特定条件下で同時に２つ扱えます。
リファレンスIDを新規作成可能なのは、ログインウィジェットと住所選択ウィジェットです。
これを利用して、住所ウィジェットを２つ同時に扱うことが可能です。
間違っても同じIDで住所ウィジェット２つという力業はしないことです。

・アメリカ版と日本版で住所ウィジェットの仕様が微妙に違う
管理画面からテストアカウントの住所を入れるときはアメリカ版仕様なので注意でした。
アメリカ仕様：市町村項目がある
日本仕様：会社名項目がある
両者は項目名が違うだけでなく、項目そのものが別物です。
違う仕様で保存すると、無い項目のデータは消滅し引き継がれません。

こんな感じでした。

愛用のphpstormにやっかいな不具合・・・クリーンアップはオフ必須

デフォルト設定だと、コミット前にソースをクリーンアップするようになっています。

クリーンアップとは、ソース上の問題点を見つけて、自動的に勝手にソースを修正する機能です。

かってに無通知でやっちゃいます。　修正に気が付くことはありません。
これ、自動修正が正しく働かないと、ソースが破壊されます。

はい、破壊されました。

無通知の自動修正なんて使うもんじゃありません。
通知されないので、すぐに原因がわからなくて困りました。

誤動作しやすいのは、テンプレート内のjavascriptですね。
phpの変数を織り交ぜてスクリプトを書くと、正しく認識してくれなくて、破壊されることがあるようです。

chromeに神アップデートが来ていた

今や誰もが使っている人気ブラウザ chrome。
私がはるか昔にchromeを選んだ理由は、唯一マルチモニターでまともに動作するラウザだったから。
そもそも何をするにも快適でストレスが無いのは、chromeだけだったから。
直前はfirefoxを使っていたが、firefoxの問題点が全てchromeで解決できたから乗り換えた。

そのchromeも、開発者にとっては非常にストレスとなる問題点が1つあった。

アドレスバーのドメインのみをコピペしたくても、かならず https:// がついてくる。

これは本当に毎回ｲﾗｲﾗする仕様であった。

しかし最近のアップデートでchromeのデザインが色々変更され、ドメインのみのコピーが可能になった！

神すぎるアップデートだ。 
よくドメイン部コピーを行う私にとっては、やっと解放されたのであった。

upstream sent too big header while reading response header from upstream

ある程度大きなアプリを動かしていると、nginxが502エラーを発生させることがあります。

upstream sent too big header while reading response header from upstream......と長い一行がログに記録されます。

upstreamが大きすぎるヘッダーを送信しているというエラーです。
バッファーの容量を超えているということです。

原因の大抵はクッキー多すぎだと思います。
設定は、どのアップストリームで上限に引っかかっているかで少しかわります。

エラーにupstreamがどれか書かれていなければ、nginxのリバースプロキシである可能性があります。
その場合、プロキシのバッファーを増やしてあげれば解決します。

proxy_buffer_size 128k;  

proxy_buffers 4 256k; 

proxy_busy_buffers_size 256k;

他にも、原因であるクッキーの量を減らすというのもあります。
たとえばRailsならば、セッションデータをクッキーではなくActiveRecordに変更することで解決します。

php-fpmを使っている場合は、エラーの中に
upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:"
と書かれているかもしれません。
この場合は、fastcgiのバッファーを増やす必要があります。

fastcgi_buffers 8 16k; 

fastcgi_buffer_size 32k;

fastcgiのバッファーを増やしたら、リバースプロキシ―のバッファーが足りなくなるということもあるので
両方使っている場合は、両方あげないと動かないこともあります。
２つの設定を合わせると以下になります。

fastcgi_buffers 8 16k; 

fastcgi_buffer_size 32k; 

proxy_buffer_size   128k; 

proxy_buffers   4 256k;  

proxy_busy_buffers_size   256k;