だ。ログ。

開発とかスノボとかやきうとか。

SendGridのAPIのバージョン変更に伴う不達

送信できない

結局なんでもそうなのだが、現状動いていると言う事にかまけていると気が付かなくなる事の方が多い。
今回も前々から告知は出ていたみたいだが、SendGridの古いAPIのバージョンでメールが送信出来なくなる事象が発生した。

原因

どうやら、APIのメジャーな変更点としてそれまで使っていたIDパスワードは色んな意味で危険なのでAPIキーを発行してそれを認証に使ってね。と言う事らしい。
利用しているAPIはV2の物なので、V3とはちょっと違う。

変更点

SendGridのダッシュボードよりAPIキーの発行を行う。ユーザー名は何でも良い。APIキーは1回表示されるとその後再表示はないのでメモ。

それまでPOSTフィールドに入れていた username, passwordフィールドを削除
POSTフィールドにapi_user, api_keyを入れればそれで良し。




と思ったらBadRequestが先方から返ってくる。
リファレンス
docs.sendgrid.com
を参照すると、Bearerで送れとのこと。

Bearerってなヘッダを生成してPOSTする値にオプションとして持たせろと言う事らしい。

        $apikey = "発行したAPIキー";
        $header = array(
            'Authorization: Bearer '.$apikey,
        );

        $session = curl_init($request);
        curl_setopt($session, CURLOPT_HTTPHEADER, $header);

CURLOPT_HTTPHEADERに認証としてBearerでAPIキーを設定します。と言う宣言を入れるとsuccessになった。

兎に角SendGridはドキュメントが英語で使える人が使う
って事のみに特化しているので低価格なのだが、思わぬアクシデントで対応が出来るエンジニアが居ないと結構怖い。

virtualboxがCPUを食いまくってうるさいのを対処する

月曜日くらいから開発用のMacbookのファンが全開で周り続ける。
うるさいので仕事が終わるとPCをシャットダウンして対処していたが開発中もかなーりうるさい。

vagrantVirtualBoxを起動しないとファンが回らない = Virtualboxが何かしら問題ありと切り分けて考察。
アクティビティモニタで見てみると

VBoxHeadlessのCPUが100%を越えたままずーっと負荷をかけ続けている。
調べてみると

qiita.com

上記にかかれていた通り、プラグインのバージョンが古くなっている感じ。
記事の通り

$vagrant plugin install vagrant-vbguest
$vagrant plugin update vagrant-vbguest

上記コマンドを叩くとあら不思議、2%以下で落ち着いた。
あまりこれを放置しておくとCPUやPC機材にまでダメージになりかねないから対処した方がよいかも。

CakePHPのセッション管理

CakePHP2のフォームを作る方向で調査していたのだが、POSTの際には

$this->request->data

で参照出来るのだが、リロードした場合にrequestから全て消滅してしまう。
リロード対策としてPOSTした先でセッションに格納と言う事でなんとか対処しようと

$this->Session->write('hoge',$this->request->data);

と言う形で、POSTされたデータをそのまま変数hogeの中にぶっ込んだ。

のだが、挙動がおかしい。

CakePHPで生成されたセッション変数は保存されるのだが、リロードするとセッションが保存されない。
色々と悩んだが

    function beforeFilter(){
        session_start();      ← コレを追記
        parent::beforeFilter();
    }

明示的にページ内でセッション宣言をする。これだけなのだがCakeの変数自体は保存されているしもっと言えばwriteで格納したデータもvar_dumpで表示すると格納されているのだが
ページを離れた段階で消えてしまう。

普通のフォームの感覚で作ってると本当に面倒な事なる。。

select要素の選択した情報からdata属性を取り出す

<select id="hoge" name="hoge">
     <option value="1" data-year="2018">2018年</option>
     <option value="2" data-year="2019">2019年</option>
     <option value="3" data-year="2020">2020年</option>
     <option value="4" data-year="2021">2021年</option>
     <option value="5" data-year="2022">2022年</option>

select要素では結構ありがちなvalue側には年度IDが入っているが、表示上は年度なのでそのまま値を渡したい場合がある。
プルダウンを選択した状態で、data要素を取りたいと仮定した場合

$("#hoge option:selected").data("year")

hoge要素で選択されているoptionのデータ属性を取れ。
と言う風に明示してあげれば、取れる。


書かなくなるとてんで飽きてしまう。
こういう情勢になってしまった事で色々と世界が変わった事は間違いない。
だからこそ、出来る事から変えていく。そして変わらない部分を見つけていこうと思う。

mysqlのインポートでRow size too largeが出た場合の対処

そもそも基本的なテーブル構成はインポート出来るがデータ内の容量が大きくなってしまっている時に出るエラーで
意図していないが、開発環境でページの確認をする為に長いデータを入れた際の事を考慮せずにダラダラとデータを入れ続けた結果
インポートする際にサイズオーバーしている事で出るエラー。

#1118 - Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

このエラーの通り、データが大きすぎると指摘されている。dumpしたファイル構造を見ると

CREATE TABLE `HOGE` (
  `ID` int(11) NOT NULL COMMENT 'IDだよ',
 ・
 ・
 ・
 ・
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='ホゲ' ROW_FORMAT=DYNAMIC;

一番お尻のROW_FORMATをDYNAMICにして対処したらインポート出来た。

PHP7.2環境でのZIPの展開エラー

前にもLaravelで同じような記事を書いたが

NOT LOAD extension "ZIP"

と言うエラーが出て、環境が復元出来ない事があった。

どうしても古い環境なので、その依存性が高い事自体があまりよくない事だが、CentOS7+PHP7.2の環境でyumを利用したインストールで忘れる事が多い。

yum --enablerepo=remi,remi-php72 install php-pecl-zip

インストールし忘れていたので、復元の際には環境依存部分を先にリストアップする癖をつけよう。。

SSHのポートの変更

既に構築済みのセキュアなネットワークの中に新規にサーバー構築する分には何も問題はないのだが、どうしても裸でのサーバーを構築しなければならない状況がある。
root権渡すから好き勝手にやってくれってなサーバーの構築する際に起動したら即やる事としてはsshのポートの変更をする。

$ sudo /etc/ssh/

# バックアップ
$ cp sshd_config sshd_config_default

$ vi sshd_config

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
# Port 22	# ここをコメントアウトして任意の数値に変更する
  Port 58120
:w :q でvi終了

# sshd_configの反映
$ sudo systemctl reload sshd

# 反映確認
$ sudo netstat -anp | grep sshd
tcp        0      0 0.0.0.0:58120              0.0.0.0:*
# 変更したポートが表示されている事を確認

AWSの場合はセキュリティグループに紐付くINBOUNDの編集で、customtcpに今回設定した58120を設定する。
※ 既存で繋がっているSSHは事故で繋がらなくなる可能性を加味して一旦は接続し続けておいた方が良い。
  → 仕事場のSSHのポートが開放されていないレンジだった場合にSSHを閉じてしまうと、繋がらなくなってしまう。。(と言うかやらかした)