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;

正しく動作するプログラムには正しいデータが必須とは限らない

「正しいデータが必須条件」がプログラムの動作原理に基づく条件としている方がおりますが、それは間違っています。

仕様上あり得ない入力を受け入れる必要性があることもあります。
ソフトウェアは様々な物が存在し、そう単純ではないのです。
これが卓上の論争をしている人と、現場の人の意見の違いだと思います。

また別のある人は、「入力値検証では値の変更をすべきではありません。」とも書いています。
「全角数字が入っていたから半角にするなど、一見親切っぽい動作ですが、はっきりいって邪魔です。」と言っています。

まぁたしかに、プログラムを組むだけの人から見れば、余計な脆弱性を組み込む原因となるかもしれないから嫌だと思うかもしれません。
しかし実際は、業務上それが必要になることもあります。
全角入力でいちいちエラーになるより、自動半角で通した方がスムーズなのは明白ですからね。
特に一般ユーザーに入力させる場合、これをやるかどうかで売り上げに結構響きます。
そもそも全角半角って何？ですから。

またよくあるのは、1行のテキストボックス。
仕様上改行を入れることはできない、と普通は思います。
しかしコピー＆ペーストを使うことで改行を含ませることができます。
そして、エクセルからのコピーでは改行が含まれます。
業務内容によっては、不正な改行を取り除いて正常なデータとして扱うという処理が必要になります。

こういった例は他にも色々あります。
いくらセキュリティーが高くても、目的を達成できなければ本末転倒なのです。
よって、入力の種類は4種類になります。

・正しい入力
・入力ミス
・不正な入力だが、ホワイトリストにより変換して正常に扱える入力
・完全に不正な入力


何を目的とするプログラムか。　それが一番大切です。
何事も、手段が目的にならないようにする必要があります。

Coinhiveは 仮想通貨発掘マルウェアだよ

近年登場して問題となっているマルウェアに、仮想通貨発掘マルウェアがあります。
感染したパソコン上で発掘するという悪質なソフトウェアです。

そしてさらに発展させて素人でも手軽に行えるマルウェアが登場しました。
それが coinhive です。

次々と逮捕されてますので、絶対に使わないようにしましょう。
少し考えれば、悪い事だってぐらいわかるはずです。たとえ違法じゃなかったとしてもやりすぎだ。
おそらく、バレないだろうと思って使うのでしょうけど、バレますんで使っちゃダメです。

あと、ある有名なセキュリティ専門家が反社会的なとんでも理論で正当化しようとしていたのは、とても残念に感じた。テロリストと同じ思考だということに気づいていないのだろうか。

coinhiveは簡単にブロックできますので、各ブラウザの拡張機能/プラグインを使ってブロックしておきましょう。no coinとか。
ウイルススキャナーを入れていれば、大抵はブロックしてくれると思います。
今時のブラウザの仕組み上、ブラウザを閉じても裏で発掘させることができますので、ブロックは必須に近い状態です。

合法的にcoinhiveを使いたければ、サイトのプッシュ通知の許可と同じことをすればいいんじゃないだろうか。
そうすれば、利用者の意思で動かしているので問題ない。いちいちポップアップするのでうっざいですけど。


coinhiveがどう悪いか、適当に書いてみると、

・サイトの片隅に表示される広告とはまったく別です。
広告は訪問者側にも利益がある場合があります。無ければ広告を表示する意味が無いわけですし。広告をクリックして商品購入をするってことは、その広告が訪問者の役に立ったということです。需要と供給なのです。ただリンクを置いているだけですし。
coinhiveはどうですが？訪問者に無断で敷地内で商売(採掘)をはじめるんですよ。
もはや泥棒と同じですよね。※リソースを泥棒して売り払う犯罪行為

・今やどのサイトもjavascriptが走っていてCPUに負荷がかかっていて、coinhiveもその中の一つですって？
おいおい、目的がまったく違うでしょう。すなわち許容を超えてるってこと。
coinhiveはサイトとは関係ないでしょ。　利益でサイト運営だから広告と同じだって？　それじゃ上の説明に戻ってね。

・ブラウザのタブを10個20個開く人は結構多い。勝手に踏み台にされちゃたまったもんじゃない。


ようは、訪問者が認識することなく訪問者の財産を一方的に利用(踏み台に)して金儲けしているということが一番の問題なのです。
こんなの禁止の方向へ進むのが当然でしょう。

MySQLとVIEWとオプティマイザと速度

MySQLでは、VIEWを使うと重いと言う人が多いと思います。
ざっとブログを検索した印象ですけど。

結論から言うと、別にVIEWが重いわけではありません。
使おうが使いまいが、INDEXがちゃんと使われていなければ重い、ただそれだけです。

ようするに、使う側の問題です。
知識なしに使えば重くなる場合もあるという事です。

MySQLでは、2種類のVIEWが存在します。
マージ方式と、テンポラリテーブル方式です。
前者は、ただのクエリエイリアスであり、実行する際にクエリを展開します。
後者は事前にテーブルを作成して使います。後者はあまり使うことは無いので省略します。

前者はVIEWを使っても速くならないと思っている人も少なくない感じがします。
同じか少し重いという記事をいくつか目にしました。
しかし実際は、劇的に速くなることもあれば、劇的に重くなることもあります。
全ては使い方次第です。

クエリが同じはずなのに何故速度が異なるのかは、オプティマイザの働き方が若干違う場合があるということだと思います。

EXPLAIN をしてみれば、何が違うのか一目でわかります。
なので、速い方と同じ順番になるよう強制してあげれば、同じ速度になります。

連結順序が違う場合は、STRAIGHT_JOIN を使って、順序を強制しましょう。

macOSとiOSでajaxが使えないバグ・・・いまだに修正されず

参照：https://stackoverflow.com/questions/49614091/safari-11-1-ajax-xhr-form-submission-fails-when-inputtype-file-is-empty

Safari 11.1から現最新版まで発生しているバグで、input type=file が空だと ajax通信で 400エラーになるバグがあります。

めんどくさいので、早く直してほしいものです。
ajaxが主流となっている今、結構はまる人多いと思います。

EC-CUBE 2系のDB速度問題

今更すぎますが、まだ3系よりも2系の方がメジャーなようなので、2系ネタです。

EC-CUBE2系のDBは、postgresqlとmysqlの２つから選べますが、postgresqlが圧倒的に早いです。
これを勘違いして、mysqlよりpostgresqlが優秀と信じている人が居ます。
EC-CUBE上での実行速度比較をしたりしてね。

EC-CUBE2系でpostgresqlが速いのはあたりまえです。
postgresqlでのみ高速に動くようにチューニングされています。
postgresql専用のクエリを使っています。

mysqlにした場合、簡易的なクエリ変換を行って実行しています。
遅くてあたりまえです。一切のチューニングが行われていません。

致命的なのは、postgresqlはビューを使って高速化しているのに対し、mysqlでは使っていません。
mysqlでもビューを使う事で、同じ速度になります。


そもそも、この程度の物にビューに使わないと重くなるってこと自体がおかしいです。
クエリ内容を見直すことで、数百倍から数万倍以上の高速化が可能です。※実話です。
ほぼすべてのクエリに問題があるので、どことは言えません。言うならば、全ての箇所です。
重いと思ったらクエリを最適化してください。天と地の差が出ます。

・意味のない処理をしていないか。※仕様変更等での消し忘れが意外とある
・インデックスを適切に使っているか。　※インデックスがまともに無い・・・
・無駄にフルスキャンする状態になってないか

ビューと使うとカスタマイズが面倒な事になるので、避けた方が良いです。

最新版Edgeでpopstateに問題発生

最近Edgeがアップデートされ、popstateの動作が変わりました。
他ブラウザとの互換性が無くなりました。

まぁ、バグでしょう。　バグで直る事をお祈りします。

初回アクセス時に実行させないよう

if(!event.originalEvent.state) return;

は、もはやスニペット入りしていると思います。
しかし、このif文がfalseになることはありません。
nullになりません。
オブジェクトが入ってしまうようになりました。

※もちろん、if文が不要な状況下は話は別ですし、そういう議論ではないので書きません。


pushstateして,formのsubmitによるページリロードが行われた時、popstateが発火します。
このとき、originalEvent.stateがnullとならず、submit前にpushstateで登録してあるオブジェクトが入っているのです。

このため、オブジェクトが現在のページの物であるかの判定を追加する必要がでてきました。
URLが同一かの判定が楽だと思います。

MySQLのAUTO_INCREMENT 設定・確認・変更

■既存のテーブルへ設定

前提条件として、ユニーク制約のあるカラムであること。

ALTER TABLE テーブル名 CHANGE カラム名 カラム名 INT( 11 ) AUTO_INCREMENT;

また、既存テーブルにカラム追加と同時に AUTO_INCREMENT を設定したい場合は、「,」で繋げて行うと良い。

ALTER TABLE テーブル名 ADD COLUMN カラム名 INT NOT NULL AUTO_INCREMENT, ADD PRIMARY KEY (テーブル名);

■確認

SHOW TABLE STATUS LIKE 'テーブル名';

■変更

現在の値より少ない数字にはできない。

alter table cc_customer_attribute_name auto_increment=数字;

■注意点

AUTO_INCREMENTの値はファイルに保存されず、実行しているMySQLプログラムの変数内に格納されるだけである。　すなわちメモリ上に存在する。
当然MySQLを再起動すれば値は失われる。
起動後、AUTO_INCREMENTの値は、そのカラムの最大値となる。

AUTO_INCREMENTを操作している場合、再起動でおかしくならないようにする必要がある。

了解しました。ご苦労様です。

ネットが一般化すると共に、言葉狩りが横行するようになりました。
この２つも例外無くネットで拡散され刈られた言葉となります。

■御苦労様
普通に考えて、本来は文字通り目上の人に使うために生まれたれた言葉です。
「御」は目上の人に使う古い言葉になります。
現に最近までは、目上の人に使うなと言う人は誰も居ませんでした。
昔の映画やドラマ、漫画なんかは、目上の人に言ってます。※今は知りません。
私のイメージではTVの影響で、目上の人に使う固い言葉となっています。

実際は、部下へ使う人が増えたため、その世代が上司になった時に部下から言われるとむかつくって人が新しいマナーを決め、ここ数年で一気に広まりました。

上司へは「お疲れ様です」を使うようにとするマナーがここ数年で登場しましたが、さっそくこれもマナー違反と言い出す人も出てきている状態です。

お疲れは丁寧語で、これにご苦労様と同じように様を付けてお疲れ様とした比較的新しい言葉だと思います。
なのでこちらは本来(ほんの最近まで)、上下関係なく使う言葉として広まっていました。

■了解しました
元々は「了解いたしました」という、目上の人に使う言葉です。
これが少し砕けて、「了解しました」となったのでしょう。
上下関係なく使えていた言葉です。

傾向として、上下関係なく使っていた言葉を上に使うをやめさせる動きがあります。
ほんと、面倒な時代になったものです。

発言力のある人が言い出すと、それがツイッターやブログで拡散して常識が一気に変化するという、現代社会が抱えている問題だと感じます。
発言力のある人が自分好みに社会を変化させるという、情報操作でもあります。
また、素人研究で勘違いした記事を書き、それが拡散したりもします。
日本語がどんどん減って表現しにくくなっていっているのが、なんか悲しいですね。

まぁ、ネットをあまりやっていない人/業種にとっては、なんのこっちゃいかもしれませんが。