がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

お次はインフラ

インフラ系の入門を、いくつか。

小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

全体を見たい場合に非常によい本かなぁ、と。
初学者向きでもありとても丁寧なのですが、イラストと手書き文字の賛否がわりとキッパリと二分しているので、その辺の好き嫌い次第、ってのは、多少。
ただ、とはいえ「書いてある内容を十全に把握していると言い切れる」初学者はあんまりいないと思うので、ちぃとくらいなら、苦手意識取っ払って読んでみてもよいと思う。

まぁ技術の世界はどこでもそうなのですが、インフラ系も「色々な用語」が飛び交います。
そんな用語をざっくりと幅広く解説してくれる書籍なので。
「通読」するのもよいですが「わからなくなったら開いてみる」のもよいかなぁ、と。
とはいえまぁ、一度は、脳内目次を作るために「通読」しておくと、効率がよいってぇもんです。

ピンクベースで可愛らしい感じの表紙の、とても「初心者フレンドリー」に"見える"本です。
基礎から丁寧に解説してくれる良書………なのですが、後半に、そのなだらかな雰囲気のまま「(C言語で)ネットワークプログラムを書いてみよう!」とか(笑
是非、雰囲気と流れにごまかされて、「これくらいは普通なのかなぁ?」って思いながら実習してみてくださいwww

Modelについて考えてみる

あちこちで「MVC」と言われつつ、なんか気がつくとMVPとかMVVMとか色々出てきて。
一方でじゃぁ「Model、って単語自体はは大体共通認識なのか?」と問うと、これがまた………。

というあたりで。
ちぃとごみごみと混雑しているように思われるので、一端、考察してみたいかなぁ、と。

以前に全く別の所でも書いたのですが。
大雑把に、フレームワーク(WAF)は
・ルーティングに従ってディスパッチして
ビジネスロジック呼んで処理して
・出力
ってな流れが、ものすごく大雑把なあたりで、主だった処理の流れだと思われまして。

んで、この「ビジネスロジック」の所が、実際には
・DBとやりとりをするところ
・データをごにょごにょする所
の2つがあると思うのですだす。

んで。
「Modelってなに?」って聞いたときに、確実に紛糾するのが、あるいは分離するのが、この聞き方。

・「Model ≒ ORM」は、true? false?

この判定式のboolean値によって、以降の内容が決まってくるわけでございます。
端的に「Modelの1インスタンスが、(大体)1テーブルの1レコードを意味している」のであれば、上述はtrueになる感じ。
とはいえ……昨今のフレームワークの多くは「true」なのではないかなぁ、と思うので、そのルートを前提に。

上述が概ねtrueだとすると、次の質問が

・「ビジネスロジック」は、どこに書くの?

というあたり。
これが「コントローラー」になるんなら、まぁ「トップハム・ハット卿*1になる」事は仕方が無いんじゃないかなぁ、と思うですよ基本的には。
勿論「ほかの場所に切り出してコントローラーをスリムにする」のはよいのですが、結局それって「コントローラーが抱え込む脂肪をほかのclassに押しつけている」だけ、なので、ほかのどこかがファットになるだけかなぁ、と。
で「んじゃぁ山盛りでclass作ってどこもスリムにする」と、今度はファイルの全体量とかクラスの数とかメソッドの数とかが半端なくなくなって可読性が落ちるので、個人的にはそっちの方が「よりお好まないかなぁ」と。
なので「必要な流れを必要な程度に書く」のは必要で、それが「特に分割するメリットがない」のであれば、ある程度長くなるのも、状況によっては「やむを得ない」と思うんですよ。

ただまぁ実際には「共通化」とか「テスタビリティ」とかの観点もあるかなぁ、と思うので。
「Model ≒ ORM」なのであれば、ビジネスロジックは「どこかにそれようのディレクトリとか名前空間とか掘って、そこに入れる」とよいんじゃないかなぁ、と。
おいちゃんは「Libs」とかよく使います。

つまり
・Contriollerは、基本的には「Libs」を呼ぶ
・Libsの中で、必要なテーブルに紐付いているModel(群)を呼ぶ
・「ORM使ったりSQL書いたり」は、Modelの中に閉じ込める
ってな感じ。

いやまぁ「ちょっとした処理くらいならControllerに直接書く」でもよいと思うのですが。
さじ加減が出来ない人がいると判断が面倒なので、その辺はチームメンバー(のレベル)とかコードレビューの文化の浸透具合とかと相談しつつ、適宜よしなに。

あと。
「Model ≒ ORM」の場合、Modelの1インスタンスは「1レコード」、1メソッドは「1レコードに対する処理」、1 staticメソッドは「1テーブルに対する処理」的に書いておくと、割と平和でございます。
まぁそうすると「JOINするようなモンはどこに書くのん?」ってなお話になるのですが、主従がはっきりしている関係であれば、主の側に書いておくと割と平和かなぁ、と。

んで。
「Model ≒ ORM がtrue」の時に「ビジネスロジックをModelに実装する」のは、思いっきりお勧めしません。
端的に、例えば「2つとか3つのテーブルを横断的に使うビジネスロジック」があったとして、それ、どのクラスに実装します? ってなお話になるので。
勿論「無理くり実装」は出来ますが、お勧めは、全くできないかなぁ、と思われます。

次。
「Model ≠ ORM」ってフレームワークは、あんまりないと思うのですが*2
その場合は「ビジネスロジックをModelに書く」のがコレクトかと思われまして、どちらかというと「んじゃ、データを扱うORM的な立ち位置をどうするの?」ってなお話になって、それを「Modelとは別のクラスに書いた方がいいんじゃね?」とかいうお話になります*3

あと。ORM自体については https://gallu.hatenadiary.jp/entry/2019/05/08/001034 で書いたので省略(っつかこのために書いたんだしw)。

最後に。
時々「ModelがただのSQL置き場になっている」ような実装を見かけまして、個人的には「一番お好まない」かなぁ、と。
本質的には「Modelの1インスタンスは"何を"表してますか?」ってな質問に、20文字以内で帰ってこないんなら「そのクラス設計、間違えてない?」ってとりあえず質問をしたくなる。
あと、基本的には
・ModelでSQL発行している(Model ≒ ORM)んなら、Modelの1インスタンスは「1レコード」であって欲しい
・基本的なSQLくらいは「基底クラスでメソッドが用意されていて、簡単に1行で記述できる」くらいの実装は欲しい
・「「Model ≠ ORM」なら、そもそも「ModelでSQL発行すんな」って思う
ってのがあるかなぁ、と。

おまけ。
・1つのModelクラスで、全然関係ないいろいろなテーブルへのSQLを渾然一体に発行している
のを見た事が数度ありまして、アレについては、殺意しか覚えませんでしたねぇ(苦笑
なので、番外。

ってなわけで。
いやまぁ「どんな実装しようが個人の自由だよねぇ」は勿論あるのですが。
とはいえ現実的に「メンテが厄介な実装」ってのは「後で、他人様の足を引っ張る」ので、おいちゃんとしては大変に「お好まない」かなぁ、と。

その辺を考えた時に、例えばModelであれば「Modelとはなんなのか? なにを書いて、なにを"書かない*4"クラスなのか?」ってのくらいは、現場毎に違って良いので、せめて「クリアな回答が欲しい」なぁ、とか思うですだす。

んでまぁその一方で「このフレームワークだから、ベースはこんな感じだよねぇ」ってのはあると思うので。
だとするとせめて「ビジネスロジックとORMが渾然一体と混ざり合った「もったりとしてコクがなく*5」な状態のクラスにならなきゃいいなぁ、とか、思ってみたりするです。

*1:「テレビシリーズでの英国版では原作と同様、基本的に「Fat Controller」と呼ばれる」……説明が必要なネタをやるな

*2:MagicWeaponが ≠ でございますちなみに

*3:MagicWeaponだと、data_clumpというクラスが「別のクラス」に相当します

*4:ここ大事

*5: (C)スレイヤーズ

ORMについて考えてみる

ORMで初っぱなボケようとして割とよい感じの「別の意味」が見つからなくてもんどり打ってるおいちゃんでございます*1
まぁボケっぱなしだと話が続かないので、速やかに本題に。

Object-relational mapping、でございます。O/RMって書かれたりORMって書かれたり。
ここでは面倒なんでORMで。

そのORMですが。
評価については、「まんせー」から「Go to Hell」まで、割と激しい幅がある技術なんじゃないかなぁ? とか思ったりするんですがいかがでしょうか?
実は、後ほど「ORMに言及する」別のBlogを書こうとしているので、「現時点での」おいちゃんの見解を書いておきたいなぁ、と。

おいちゃんの見解としては
・軽いものはORMで書くけどやっかいなやつはSQLダイレクトに書いたほうが早い事が多いよねぇ
ってのをベースに
・チーム内に「ORMに長けたメンバーがいて厄介な質問でも回答が帰ってくる」んならORM側に寄せますがそうでなければSQL側に寄せます
って感じかなぁ、と。

んで。
おいちゃんが知っている限り。
……いやまぁ「不勉強で触った事もなくてなんとなく新しい技術は毛嫌いしているからORMヤダ」って人がいないわけではないのですが。
どちらかというと「実際に使ってみて(使いこなしたとは言っていない)、一定量のトラブル経験を経て嫌になった」人のほうが、割合的には多いんじゃないかなぁ? と。

んで。
「一定量のトラブル」については
・そもそもORMという思想では根本的に解決不能な問題(あるのかどうかは知らない:可能性として)
・ORMの実装的に根本的に解決不能な問題(あるのかどうかは知らない:可能性として:これはありそうだなぁ)
・ORMで解決できなくもないが、トリッキーだったり特殊なやり方が必要だったいする(近しいのは見た事があるなぁ)
・ORMで一応解決可能だが、実装が複雑だったり難しかったり知られてなかったり
あたりが割とあるんじゃないかなぁ? とか思ったりするです。

特に後半2つが割と厄介で。
「チーム内にORMに長けたメンバーがいて厄介な質問でも回答が帰ってくる」んならある程度許容範囲かもしれないのですが、「ORMに長けたメンバーがいなくて、ちょいちょいと調べ物が発生したり、ORM自体のソースコードに潜ったりする必要がある」とかって感じになってくると、途端にストレスの上昇カーブが激しくなってくるかなぁ、と。
さりとて、そのORMに深い思い入れがあるわけでなければ「ものすごいコストをかけてそのORMの微に入り細を穿つところまで習得する必要は、あるの?」とかいう疑問が横切った瞬間に「生SQLでよくね?」的なチョイスに向かう事も、少なくないのではなかろうか、と。

んで。
よくORMの例題に出てくるような「シンプルで単純なSQL」なら、そりゃORMのほうが楽でしょうて。
ただ、そういった「シンプルで単純なSQL」以外が、業務では、出てくる可能性が0ではなくて*2
その辺を「どうするか?」ってあたりへの回答が
・無理
・トリッキーなやり方で出来る
・出来るけど情報を探すまでが少し厄介
・普通に出来る
ってあたりで色々グラデーションがあるんじゃないかなぁ? と。

例えばよく言われるあたりが「N+1問題」。
ただまぁ、それ以外にも「なんでこんな変なわかりにくいコードかかないかんねんこれならSQL書いたほうが早いじゃん」的な、etc etc。

その辺を考えると、 https://www.kaitoy.xyz/2015/09/13/orm-is-offensive-anti-pattern/ あたりも、一笑に付す事が、幾分、難しい側面もあるんじゃないかなぁ、とか。

んで。
ちぃと興味深いBlogを見つけたので、少し言及してみたく。
https://qiita.com/niisan-tokyo/items/156eb35c6eeaf07b9b65

1. SQLを書かなくていい!

これが「利点になるかどうか」は、「やりたい事を、SQLとORMのコードで書いて比較」次第なんじゃないかなぁ? とか思ったり。

そこを前提に。

1.1 SQLという「別言語」を混在させずに済む

それをいうと、PHPを書いててもHTMLだのJavaScriptだのと「完全に無縁」とはなかなかいかないような気もしますし。

あと、個人的な所感ですが、SQLの直書きが許されている場合、似たようなSQLが量産される傾向にあるように思います。

については「環境が悪いだけじゃないかなぁ?」とか思うわけです。
あるいは「ORMになったからといって、似たようなコードが量産されないのか?」という疑問があったり。

1.2 「よい」SQLを作ってくれる

「ナニをもってよいとしているんだろう?」と思ったのですが、

これはSQLインジェクションに対する対処としては定石となる手法ですが、手で書こうとすると割と面倒だったりします。

えぇ………… orz
それは、ないと思うなぁ。

2. ゲッター・セッターの仕組みを利用できる

これは別にORM使わなくても出来る。

3. 所有関係を定義できる

「JOIN使えばいいじゃない」と言うべきなのか「FOREIGN KEY使おうよ」と言うべきなのか。

んで。

1.1 SQLを書かない
中略
SQLをバリバリ書ける人にとっては、SQLが勝手に生成されるORMは自由度がないと思うかもしれません。

まぁ、ここだよねぇ、的な。
んなにバリバリ書けるわけではないのですが、それでも割とちょいちょいと「縛りがきついんじゃ*3」と思う瞬間は、割とちょいちょい。

1.2 JOINを使わないかもしれない

……これは「ない」と信じたいなぁ……知らんが。
ちなもし「JOINを使ってない」場合、

これが絶対に悪いかというと、実はそうとも言い切れません。

と書かれてますが、基本的に「がっつりと悪い」です。

2. 嫌ってる人がいる

「なんで嫌ってるのか?」次第だよねぇ、と。

3. N+1問題

言わずもがな。

と言うわけで。

エンジニアにとって、コード量を少なく可読性をよくできることが、ソフトウェアの品質を上げる有効な手段でありますので、ORMで品質が良くなるのであれば、ガンガン導入していきたいです。

については「品質が良くなるのであれば」使う事に抵抗感はないのですが。
「縛りの結果、変な箇所が生まれる」のであれば、その部分の品質が低下してしまうので、そういった部分にまで「むりくりにORM縛りをする」のは、あんまり好まないかなぁ、と。

んで「むしろ、SQLを書いちゃうと、オブジェクト化ができなかったりします。」でデメリットが出るのであれば、選択肢としてはどちらかというと「んじゃ、ORM使わないほうが効率よくない?」って判断になり得るんじゃないかなぁ? とか思う訳です。


あと、もう1つ興味深い、こちらはスライドを。
https://www.slideshare.net/kwatch/how-topreventorm-troubles

しかし ORM は、アプリケーション開発者にとっては便利でも

わりとそうでもない(苦笑

ORMによるトラブルは (たいてい) 解決策がある

「たいてい」ってあたりに、色々と味わいを感じてしまいます(苦笑

なんてちょっと軽いところに茶々を入れながら。

背景:ORMによるトラブルが多発
ORMが生成するSQLがクソ いわゆる「ぐるぐる系SQL
SQLをろくに勉強しないアプリ開発者 そのくせOOPデザインパターンを得意げに語る ;(
開発効率を上げるためのORMなのに話が違う! ある面では効率が上がっても、別の問題を引き起こしている

この辺、色々と闇の深さを感じます………

DBAがORMを知らなすぎる

この辺は「ど~なんだろうなぁ?」的な。
おいちゃんが「(DBAではなく)プログラマ」だから、「ORMはプログラマが把握してDBAに説明すべきもの」なんじゃないかなぁ? って思ってしまうので、「DBAがORMを知らないのはヨクナイ!!」とは、あんまり、考えたことがないかも。

んでまぁ……理想が「アプリ開発者がSQLを勉強してくれる」になっているあたり、が、なんとも(苦笑
いや大事だと思うんですよSQL理解するのは。
ただ、この発言の背景にある「アプリ開発者のSQLの不勉強っぷり」に思いを馳せると、色々と、ねぇ………

Prepared Statementではwhere句への追加 などが行えない

については、ここで書いてあるテンプレートやクエリオブジェクトを使う以外にも、割と色々と手段があるので、ぶっちゃけ「困ったことはない」ですねぇ。

ORMでよくあるトラブル

「クエリ発行箇所が特定できない」は、言われてみれば確かに、ですねぇ。
index付け忘れとかは、論外付近の事象ではなかろうか、と。

開発者からのSQLの相談に乗ってあげる

相談に乗って貰えるんなら、是が非でも、是非とも……

心構えその5:金を積む

大爆笑www
でもまぁ「真理でございます」w

あと。

個人的にお勧めなO/Rマッパーは? ?

のところで

自作!自作マジお勧め! 職人が自分の道具作って何が悪い!車輪の再発明なぞ知らんがな!

とかあるのは、心から爆笑するとともに、深くうなずける一文でございます。

ActiveRecord?あれはあんまり…

そなの?
この辺はよくしらない。

あと、地味に「PHPでお勧めのORMが出てない」のが、なんとも………。


とまぁ、ざっくりまとめると。
おいちゃんの見解としては
・軽いものはORMで書くけどやっかいなやつはSQLダイレクトに書いたほうが早い事が多いよねぇ
ってのをベースに
・チーム内に「ORMに長けたメンバーがいて厄介な質問でも回答が帰ってくる」んならORM側に寄せますがそうでなければSQL側に寄せます
って感じかなぁ、と。

もうちょっと、ORMの裏側の仕組み&コードの書き方がこなれてきたら、もうちょっと印象が変わるような気がするんですけどねぇ。
現状だと「全部ORMのみで、SQLは一切書かない」は、案件にもよるんだけど、ちょっと選択肢としては「難しい事が多い」かなぁ、と。

ただまぁ、つまり「生SQLも比較的容易に飲み込める」タイプのORMであれば、「シンプルなSQLはORMのほうが手っ取り早い」のも事実なので、割と積極的に使いたいところではあるんですよねぇ。
なので、別に「ORM死すべし」とは思ってないあたりが、とてもどっちつかずだなぁ、と(笑

*1:マテ

*2:つまり「一定量存在する」

*3: (C)千鳥 ノブ

プログラムを学ぶための本といえば

どっちも、まだ「プログラムを始めた頃」だと少し難しかったり不思議だったりする内容なのかもしれないんだけど。
とはいえ、一端は頭の中に「なんとなく」でもいいから、インストールしておいたほうがよいんじゃないかなぁ、と思う書籍を2つ。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード、は、結局のところ「保守メンテがしやすいコードの書き方」なので、早めのタイミングでお作法として理解していたほうが、色々と(内外に)トラブルを抑止できます。
コーディングを支える技術、は、言語を「少し俯瞰して」見る事ができるので、プログラマを己の飯の種の1つにするのであれば、読んでいて損のない1冊です。

リーダブルコードは、近い書籍がほかにも数冊出ているので、そういった書籍も一緒に読んでみてもよいんじゃないかなぁ、と思います。

Slimは本当にスリムなのだろうか?

ちょいと気になったり興味があったりしたので、いくつかの「比較的(日本で)ポピュラーと思われる」PHP Web Application Framerowkの、行数とかファイル数とかを調べてみました。
まずインストールですが、本日のタイミングで

composer.phar create-project laravel/laravel laravel
composer.phar create-project cakephp/app cakephp
composer.phar create-project symfony/framework-standard-edition symfony
composer.phar create-project kenjis/codeigniter-composer-installer codeigniter
composer.phar create-project slim/slim-skeleton slim

という感じで一通り入れています。
バージョンとかの細かい違いがあると思うので、その辺は適宜脳内補完をお願いいたします。

また、ファイル数や行数は、基本的には以下のように調べています。

#
find vendor/ -name "*.php" | xargs  wc -l | tail -n 1
find vendor/ -name "*.php" -type f | wc -l
#
find FW本体と思われるディレクトリ -name "*.php" | xargs wc -l | tail -n 1
find FW本体と思われるディレクトリ -name "*.php" -type f | wc -l

ただ、上述だと「ファイル数が多くてうまく合計されない」ものもあるので、その辺は適宜よしなにしております*1

結果。

フレームワーク 全体ファイル数 全体行数 FW本体と思われるディレクト FWファイル数 FW行数
laravel 6161 832270 vendor/laravel/framework/ 857 127125
symfony 6134 739122 vendor/symfony/symfony/ 4055 466309
cakephp 4469 598447 vendor/cakephp/ 872 135415
codeigniter 258 78948 vendor/codeigniter/framework/ 199 68492
slim 1424 145223 vendor/slim/slim/ 47 8564

Laravelが重量級なのは想像通り、cakephpもそれなりに。
symfonyが、思いのほか「フレームワーク本体(と思われる……もしかしたら本体以外が混ざってるのかも)」のファイル数&行数が膨大で、ちょいとびっくり。
codeigniterは「全体としては軽い」んだけど「本体はそこそこの重量」があって。
slimは、「周辺まで含む」と少し行数ファイル数ともあるものの、本体はさすがに貫禄の軽量っぷりw

こうやって見ると、改めて「フレームワーク"を"読む」なら、Slimから、ってのは、割と入門的な位置に行けそうだなぁ、と、改めて感じるところでございます。

*1:findをリダイレクトして「行頭に wc -l」の置換かましたのを実行した結果をリダイレクトたものの0x20をタブに置換してExcelでsum w

この本は外せない

何はなくとも、レベルで必読な書籍

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

書いてある内容は割と平坦で「技術素養が薄くても普通に読める」んだけど、そこにあるエッセンスは「業務を二桁年重ねてきたエンジニアでさえも割と失念しがち」な、本当に大事なことが色々と書かれていると思う。

SlimとSlim-Skeleton のindex.php

公式サイト http://www.slimframework.com/ のサンプルだと、index.php

<?php
use Psr\Http\Message\ServerRequestInterface as Request;
use Psr\Http\Message\ResponseInterface as Response;

require 'vendor/autoload.php';

$app = new \Slim\App;
$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");

    return $response;
});
$app->run();

と書かれている一方で、「実際にプロジェクトを起こす時にベースに使うと便利」とされている、公式から出ているSlim-Skeletonのindex.php では、少しばかり、差異があります。
この辺を少し、読み解いていきましょう。

注意
一時期以降、結構ごっそりと書き方が変わっています。
一端 https://github.com/slimphp/Slim-Skeleton/tree/439b6ec6cb1189d0be7fe31f87af4cbeeb801e53 を前提に記述、後で最新用のフォローアップをします。


さて。
とりあえずまずはルーティングの設定です。

$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");

    return $response;
});

このあたり、ですね。
これを、Pageが増える毎にindex.phpに重ねていくと、index.phpがえらいこと長くなってしまうので、ちょいと切り出してみましょう。
そうですねぇpublicにあるのも些か好ましさに欠けるかと思いますので。
publicディレクトリと同じレベルに、srcというディレクトリを切って、その中に routes.php とかいうファイルを作ってみましょう。

そうすると、まず切り出すので、index.php

<?php
require 'vendor/autoload.php';

$app = new \Slim\App;

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();

こうなり、切り出したroutes.php

<?php
use Psr\Http\Message\ServerRequestInterface as Request;
use Psr\Http\Message\ResponseInterface as Response;
// Routes
$app->get('/[{name}]', function (Request $request, Response $response, array $args) {
    // Sample log message
    $this->logger->info("Slim-Skeleton '/' route");
    // Render index view
    return $this->renderer->render($response, 'index.phtml', $args);
});

こうなります。
use句は、切り出したほうのコードで使ってるので、併せての移動ですね。
ついでに、 Psr\Http\Message\ServerRequestInterface はインタフェース宣言だけなので&Slimは実際にはちゃんとクラスまで切っているので。
implementsしたクラスに、use句を変更しておきましょう。

<?php
use Slim\Http\Request;
use Slim\Http\Response;
// Routes
$app->get('/[{name}]', function (Request $request, Response $response, array $args) {
    // Sample log message
    $this->logger->info("Slim-Skeleton '/' route");
    // Render index view
    return $this->renderer->render($response, 'index.phtml', $args);
});


さて。
index.phpですが。
このままでもよいのですが、実際にアプリケーションを組むのであれば「なにがしかの設定値」は、やはり欲しいところになります。
new \Slim\App でも、コンストラクタに色々と実際には設定を渡す事ができるので。

と言うわけで、設定値をやはり切り出して記載してみましょう。
ファイルは、src/settings.php にしてみます。

index.php

<?php
require 'vendor/autoload.php';

// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();


settings.php

<?php
return [
    'settings' => [
        'displayErrorDetails' => true, // set to false in production
        'addContentLengthHeader' => false, // Allow the web server to send the content-length header
        // Renderer settings
        'renderer' => [
            'template_path' => __DIR__ . '/../templates/',
        ],
        // Monolog settings
        'logger' => [
            'name' => 'slim-app',
            'path' => isset($_ENV['docker']) ? 'php://stdout' : __DIR__ . '/../logs/app.log',
            'level' => \Monolog\Logger::DEBUG,
        ],
    ],
];

これで「settings.phpに設定を書く」と「new \Slim\Appの引数として渡される」ので、色々な設定を入れ込む事ができるようになります。

次に。
diコンテナも少し設定をしておきましょう。
とりあえずざっくりと「view用のクラスとしてPhpRenderer」と、最低限の「logger(ログを出力するクラス)」くらいは追加しておきましょう。
追加用の設定は src/dependencies.php にでもいれておくことにします。

index.php

<?php
require 'vendor/autoload.php';

// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
require __DIR__ . '/../src/dependencies.php';

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();


dependencies.php

<?php
// DIC configuration
$container = $app->getContainer();
// view renderer
$container['renderer'] = function ($c) {
    $settings = $c->get('settings')['renderer'];
    return new Slim\Views\PhpRenderer($settings['template_path']);
};
// monolog
$container['logger'] = function ($c) {
    $settings = $c->get('settings')['logger'];
    $logger = new Monolog\Logger($settings['name']);
    $logger->pushProcessor(new Monolog\Processor\UidProcessor());
    $logger->pushHandler(new Monolog\Handler\StreamHandler($settings['path'], $settings['level']));
    return $logger;
};

これで一段落……したいところなのですが。
ついでに、middleware用の設定をいれる場所を作っておきましょう。
一端「場所だけ」を作る感じで、 src/middleware.php に用意をしておきます。

index.php

<?php
require 'vendor/autoload.php';

// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
require __DIR__ . '/../src/dependencies.php';
// Register middleware
require __DIR__ . '/../src/middleware.php';

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();


middleware.php

<?php
// Application middleware
// e.g: $app->add(new \Slim\Csrf\Guard);

こんなところでしょうか。
ちなみに、サンプルで書かれている「\Slim\Csrf\Guard」は、これそのものではなくてもよいので、なにがしかCSRF対策用のものをいれておくのは、大変に好ましいと思われます。

これで、おおよそ「Slim-Skeletonのindex.php」と同じもの、になります。
実際のSlim-Skeletonのindex.php

<?php
if (PHP_SAPI == 'cli-server') {
    // To help the built-in PHP dev server, check if the request was actually for
    // something which should probably be served as a static file
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}
require __DIR__ . '/../vendor/autoload.php';
session_start();
// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
require __DIR__ . '/../src/dependencies.php';
// Register middleware
require __DIR__ . '/../src/middleware.php';
// Register routes
require __DIR__ . '/../src/routes.php';
// Run app
$app->run();

となっていて。
空改行の箇所をのぞくと
・先頭の9行
・session_start();
くらいの差異、ですね。

先頭の9行は大雑把に
・ビルトインウェブサーバーを使っている時に「staticなURI(実在するファイルのURI)がcallされたら、プログラム的な処理をしない」ためのロジック
になります。

session_start()は、そのまま。
まぁセッションを使うことは「極めて多い」ですからねぇ。


と、このような感じで。plainのSlimのindex.phpから、Slim-Skeletonのindex.phpに移り変わりが行われています。

……という感じだったのですが。6 Nov 2018の
https://github.com/slimphp/Slim-Skeleton/tree/8dd2f8469514a43d4180148466a832f8d1683fe4
のタイミングで、ちょいと諸々、がらっと様変わりをしたようなので、少し覗き直してみましょう。

index.phpですが、こんな風になっています。

<?php
if (PHP_SAPI == 'cli-server') {
    // To help the built-in PHP dev server, check if the request was actually for
    // something which should probably be served as a static file
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}
require __DIR__ . '/../vendor/autoload.php';
session_start();
// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
App\Dependencies::init($app);
// Register middleware
App\Middleware::init($app);
// Register routes
App\Routes::init($app);
// Run app
$app->run();

全体的に「クラス名::init($app)」の方法でのcallに変わっている感じですね。
例えばRoutesを見ると

<?php
namespace App;
use Slim\App;
use Slim\Http\Request;
use Slim\Http\Response;
/**
 * Configures the routes
 * @param App $app
 */
class Routes
{
    /**
     * Configures the routes
     * @param App $app
     */
    public static function init(App $app)
    {
        $container = $app->getContainer();
        $app->get('/[{name}]', function (Request $request, Response $response, array $args) use ($container) {
            // Sample log message
            $container->get('logger')->info("Slim-Skeleton '/' route");
            // Render index view
            return $container->get('renderer')->render($response, 'index.phtml', $args);
        });
    }
}

という感じで、全体的に「クラスの中のstaticなメソッドでの定義」に変わっているようです。

で、その状況が、わずか二週間弱、19 Nov 2018 に
https://github.com/slimphp/Slim-Skeleton/tree/15fc5968d9430e67110d82dff3b1b3a2349c9cf6
で、もう一度変わっています。

<?php
if (PHP_SAPI == 'cli-server') {
    // To help the built-in PHP dev server, check if the request was actually for
    // something which should probably be served as a static file
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}
require __DIR__ . '/../vendor/autoload.php';
session_start();
// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
$dependencies = require __DIR__ . '/../src/dependencies.php';
$dependencies($app);
// Register middleware
$middleware = require __DIR__ . '/../src/middleware.php';
$middleware($app);
// Register routes
$routes = require __DIR__ . '/../src/routes.php';
$routes($app);
// Run app
$app->run();

で、routesが

<?php
use Slim\App;
use Slim\Http\Request;
use Slim\Http\Response;
return function (App $app) {
    $container = $app->getContainer();
    $app->get('/[{name}]', function (Request $request, Response $response, array $args) use ($container) {
        // Sample log message
        $container->get('logger')->info("Slim-Skeleton '/' route");
        // Render index view
        return $container->get('renderer')->render($response, 'index.phtml', $args);
    });
};

前回「staticなクラスメソッド」だったのが、今回は「無名関数」に置き換わっている感じですね。

なんか色々と動きがありそうな感じなので、ちょっと興味深く思いました。