カテゴリー別アーカイブ: ソフトウェア・開発

ZabbixでRDBにMariaDB 10.2 10.3 10.4 を使う場合の注意点

2019年11月時点でのZabbixのLTS(長期サポート版)は 4.0 系が最新バージョンとなっていますが、Zabbix 4.0 (や 4.2)をMySQLではなくMariaDB 10.2 ~ 10.4で導入する場合には現状注意点(というか不具合)に近いものが有るので要注意です。

詳細は以下のURLをご確認ください
https://support.zabbix.com/browse/ZBX-16757
https://support.zabbix.com/browse/ZBX-16465
https://support.zabbix.com/browse/ZBX-16465

もともとMariaDB 10.1等を使っている環境から移行した場合に特に問題なく動いているように見えても、DBのフルダンプを使って復元しようと思った際に踏んでDBのインポートに失敗したりします(しました)。

この問題が修正されているのはZabbix 4.4 以降になるため、4.0 LTSを使う場合はMySQLなど他のRDBMSを使った方が無難です(MariaDB 10.1 は2020年中にサポートが終了します)。


Twig 3系に備えてTwig 1.x系を2系に更新しておこう

タイトルで完結しているかつ詳細も次のリンクで全てなのですが、利用者がそれなりに多そうな話題を見かけなかったので。

Preparing your Applications for Twig 3

Symfonyやそれ以外の環境でもよく使われているPHP向けテンプレートエンジン Twig の バージョン 3系が2019年末頃にリリースとなります。Twigは古いバージョンのPHPにも対応する1.x系とある程度新しいバージョンにのみ対応する2.x系が有りどちらもメンテナンスが続いていますが、3系のリリースに備えて1.xユーザーの方は2系に移行するようアナウンスされています。

移行のために

まずPHPの対応バージョンは以下のようになっています。いずれも composer.json で指定されている値です。

Twig 1.x : PHP 5.5.0 以上
Twig 2.x : PHP 7.0 以上
Twig 3.x : PHP 7.2.9 以上

1.x から 2.xは基本的には入れ替えるだけでそのまま動きます。ただし2.x で depricated (廃止予定)となったものや internal (内部的に使う関数であり直接の使用が非推奨)となっているものが 3.xで実際に廃止となりますので、まずは 2.x に移行した状態でその部分の対処を行う事で 3.x に備える事が出来ます。

該当のクラスや関数にはPHPDocのコメントが入りPhpStormなどのIDE環境においては対象箇所が視覚的に分かるようになっています。2.xで名前空間の整理が進み呼び出すクラスが変わる部分がいくつか有りますが、呼び出すクラスを変えるだけでほぼそのまま動く事が多いと思います。

2019年11月16日追記
Twig 3.0.0 がリリースされたようです
https://github.com/twigphp/Twig/releases/tag/v3.0.0


CodeIgniter 4 RC1 インプレッション

Webアプリケーションフレームワーク Laravel 6 LTSの正式版が2019年9月3日にリリースされましたが、その数日前にCodeIgniter 4.0 もついにRC1となりました。beta1が今年の3月でしたので最初のベータ版からおおよそ6カ月でのRCリリースとなりました。(Larabel 6に関しては記事を書く方が大勢居ると思うので……)まだ本格的なアプリを作っていない状態ではありますがCodeIgniter 4 RC1のパッと見た感じを記事にしたいと思います。個人的にトピックな点に触れていくので細かな違いはドキュメントを参照してみてください。

CodeIgniter公式
https://codeigniter.com/

Composerへの本格対応や名前空間への対応

CodeIgniter 3でもComposer(PHPのパッケージ管理ツール兼オートローダー)で導入されたライブラリや独自定義のクラスをComposerのオートロードで読み込んだり、名前空間の定義されたクラスをアプリ内に含めたりnewしたりする事は出来ていたのですが、CodeIgniter自体をComposerで導入したり、CodeIgniter自体や作っていくコントローラやモデルなどで名前空間を使っていくようになりました。

なおComposerでの導入は必須ではなく、これまで通り圧縮アーカイブでダウンロードして配置して動かす事も出来ます。この辺りの選択肢を残しておくのはCodeIgniterらしくていいですね。また、Composerで導入する場合についても –no-devオプションを付けた場合(= PHPUnitを入れない場合)は数パッケージしか依存関係が有りません。一桁です。少なければ良いという訳ではないですが、フレームワークの全ての機能がそれぞれパッケージのようなSymfonyやLaravelに慣れていると方向性の違いを感じますね。

#導入
composer create-project codeigniter4/appstarter <任意のプロジェクト名> -s rc
# 内臓Webサーバでの実行
cd <今作られた任意のプロジェクト名のディレクトリ>
php spark serve
# →Webブラウザで http://localhost:8080 にアクセスすると仮のTOPページが見られる

JSON/XML形式でのレスポンス返却機能

ビュー(フロントエンド側)とのやりとりをJSONを返すAPIでやり取りする事が多くなった昨今ですが、CodeIgniter 4でもJSON/XML形式でのレスポンス返却が簡単になりました。例としてコントローラ内で

$data = [
    'status' => 'ok',
    'message' => 'json responsed'
]; 
 $this->respond($data, 200); 

と書いてやれば $data をJSONフォーマット化したレスポンスをHTTP 200で返してくれます。渡すのがarrayで良いってのはCodeIgniterっぽいですね。

respondはコンテンツネゴシエーション機能が文脈によってJSONではなくXMLを返したりします(WebブラウザでアクセスするとXML形式で表示されます)。この辺りは常にJSONを返したりなど設定変更可能です。また、他の形式での返却も追加できるようです。
https://codeigniter4.github.io/userguide/outgoing/api_responses.html

ORM的機能の追加

使う場面・使わない場面有るとは思いますが、簡易?ORMが追加されました(ドキュメント上ではORMとはよばれずModel、Entityと記載)。もちろんほぼこれまで通りの直書きSQL+変数の自動エスケープ有りバインディングであったり扱いやすいクエリビルダも利用可能です。

まだ触ってはいないのですが、ドキュメントを読む限りテーブル名やプライマリキー名は手動指定できるタイプ、シンプルなCRUD機能を提供、論理削除対応、バリデーション対応、変更できないプロパティの指定に対応、JSON←→Arrayの自動変換などある程度の機能が揃っているようです。でもテーブル間のJOINやそれに関連する遅延ロード・Eagerロードは見当たらない? どの程度まで使い込めるのかは触っていないので正直まだ分からないのです。

基本は変わらないコントローラ

ルーティング方法がシンプルだからCodeIgniterが好きと言う人は結構いるんじゃないでしょうか(想像)。 クラス名やメソッド名がそのままルーティングになったりディレクトリ階層でパスを分けたりといったあの感覚はCodeIgniter 4でもそのまま利用できます。

Controllerクラスを継承する必要が有ったり、渡された値はInputクラスではなくIncomingRequestから取得するようになっていたりなど差は有るのでその辺は新しい作法にのっとっていく形になります。あとはアプリケーションのエラーを返す際にshow_error関数を呼ぶのではなくコントローラ内で例外をスローするようになっていたりするのも最近のフレームワークっぽいですね。

あとは使いたい人だけ使う形で良いと思いますが、Laravelにも有るようなReutfulなルーティングをまとめて用意する機能が追加されていたりします。APIを数作っていく場合は楽になるかもしれませんね。

神クラスCi_controllerからDI風味へ

CodeIgniter 3まではコントローラ(というかCI_controller)がサービスロケータとして機能しており、更にそれがあらゆる場所から利用できていましたがこれは無くなりました。CodeIgniter 4では代わりに Service という仕組みにより newされたインスタンスを取得するようになります。

基本的にはコントローラ内で必要なインスタンスをServiceとして取得、あとはコンストラクタインジェクションやメソッドインジェクションで注入という方向性のようです。Symfony 4.xほど強力なDIの仕組みではない(Symfony 4.xのDIは本当に強力)ですが、CodeIgniter 3の CI_loaderっぽさも残っていてシンプルなので移行はしやすそうですね。
https://codeigniter4.github.io/userguide/concepts/services.html

/Config/Services.php にクラスの生成を定義。これがサービスプロバイダ的な感じですね。ここでオブジェクトを生成して返します。

上記で生成される仮で作ったライブラリです。

コントローラ内からオブジェクトを取得して利用します。

.envでの設定に対応

.env形式のファイルでフレームワークの設定値を上書きするような事が可能になります。Symfonyなど他のフレームワークで見かける様な物と同様に、環境ごとに変更したい設定が有る場合は.envファイルを用意する事で変更が可能です。

PSR-3準拠のロギング

ログを残す際のレベルがPSR-3に準拠するロガーで見かける様な物(RFC 5424)になりました。引き続きこれまで通りのlog_message関数が利用可能ですが内部的にはPSR-3準拠の関数群を持ったloggerサービスの log() を呼び出しています。DEBUGとERRORの間のレベルが欲しいと思う事が多かったので地味に助かるポイントです。他のPSR-3を実装するロガーへの入れ替えも可能なようです。

所感

CodeIgniter 3との細かい違いはそれなりに有ります。基本的にCodeIgniter 3のコントローラやモデルのコードはそのままでは動作しません。ただ、私がCodeIgniterの方向性だと(個人的に勝手に)思っている「薄く必要最低限で過剰に何かせずに分かりやすい感じ」はそのまま引き継がれているんじゃないかなという印象です。CodeIgniter 3のその部分が好きだったけど流石にもう設計の古さを感じるなという部分(名前空間非対応で有ったり)がアップデートされているので、悪くはない選択肢の一つになれればいいなぁという感想です。

追記 – 2019年9月26日(現地時刻)にCodeIgniter 4.0.0 RC 2が公開されました
https://forum.codeigniter.com/thread-74463.html