PHPでDATETIME型のBETWEEN用の範囲（境界値を含む）を作る例

$start_range = '2019-02-01 00:00:00';
$datetime = new DateTimeImmutable($start_range);

// 月
// "2019-02-28 23:59:59"
$end_range = $datetime->add(new DateInterval('P1M'))->sub(new DateInterval('PT1S'))->format('Y-m-d H:i:s');
// 年
// "2020-01-31 23:59:59"
$end_range = $datetime->add(new DateInterval('P1Y'))->sub(new DateInterval('PT1S'))->format('Y-m-d H:i:s');

本稿ではPHPの静的メソッドが何のためにあるかを考えるものである。

クラスとインスタンスの概念的な関係性

静的メソッドを理解するには、クラスとインスタンスの関係性を理解していなければならない。

クラスとインスタンスの関係は何だろうか？

一言で言えば、クラスは、複数のインスタンスの集合である。概念的な集合であって、インスタンスの配列という意味ではない。例えば、$user1のオブジェクトと$user2のオブジェクトを総じて、Userと呼べるのは、Userが$user1と$user2の集合だからだ。

User = { $user1, $user2 }

以上の集合論的な観点を踏まえると、静的メソッドは何のためにあるかといえば、集合に含まれるすべてのオブジェクトに共通した処理(公理ともいう)を記述するためにあると言える。

逆を言えば、集合の一要素にすぎない$user1にのみ関係する処理は静的メソッドにはならない。Userクラス(ここまで読んだみなさんなら、もうこの一言で$user1と$user2と...$userNすべてのことを指していることは上の説明でお気づきだろう)に関係する処理はUserクラスの静的メソッドになりうる。

もしも静的メソッドが無かったら

例として、3つの商品の金額の合計を求めるケースを考えて見よう。

もしも、静的メソッドがない言語だったら、合計金額を求めるメソッドは、商品インスタンスのメソッドとして定義することになるかもしれない。

class Product
{
    // ...コンストラクタなど略...

    public function calculateTotalPrice(
        Product $otherProduct1, 
        Product $otherProduct2
    ): int {
        return $this->price + $otherProduct1->price + $otherProduct2->price;
    }
}

このcalculateTotalPriceメソッドを使おうとするとこうなる:

$product1 = new Product(100); // 100は100円ということ
$product2 = new Product(100);
$product3 = new Product(100);
$totalPrice = $product1->calculateTotalPrice($product2, $product3);

ここでは$product1が主軸となって合計金額が計算されたが、主軸となるのは$product2でもいいはずだ。3つの商品を対等に扱えていないため、calculateTotalPriceメソッドの置き場としてはあまり心地の良いものとは言い難い。これは1つ目の問題だ。

では、$totalPriceCalculatorというオブジェクトを作って、そいつに計算させてはどうか？

class TotalPriceCalculator
{
    public function calculateTotalPrice(
        Product $product1,
        Product $product2,
        Product $product3
    ): int {
        return $product1->price + $product2->price + $product3->price;
    }
}

$totalPriceCalculator = new TotalPriceCalculator();
$totalPrice = $totalPriceCalculator->calculateTotalPrice(
    $product1, 
    $product2, 
    $product3
);

確かにこうすれば、どの商品も主軸になっていおらず、対等に扱われているため、最初の実装のような気持ち悪さはない。さっきよりは良い実装になったと思う。

しかし、今度は、TotalPriceCalculatorがProductを知りすぎてしまっている。Productのprice属性が何なのか知っているがために、例えばprice属性がintからCurrencyクラスに変更されたとしたら、TotalPriceCalculatorの実装も変更を余儀なくされる。つまり、別クラスが知りすぎてしまうと変更が面倒な構造になるだけでなく、変更対応の漏れが発生しやすく、バグを呼び寄せやすい構造になってしまう。オブジェクト指向では大事なカプセル化を毀損しているとも言える。これは2つ目の問題だ。

静的メソッド

ここで一旦出てきた問題を整理しよう。

静的メソッドが使えないとなると2つの問題が引き起こされる:

1. 複数のインスタンスにまたがった処理の置き場として、インスタンスメソッドは常にいい場所ではない。
2. かといって、意味的に関係していないオブジェクトにその処理を置くとカプセル化が毀損される。

以上の問題を解決するには、Productの静的メソッドとしてcalculateTotalPriceを生やすといい。

class Product
{
    // ...コンストラクタなど略...

    public static function calculateTotalPrice(
        Product $product1,
        Product $product2,
        Product $product3
    ): int {
        return $product1->price + $product2->price + $product3->price;
    }
}

$totalPrice = Product::calculateTotalPrice($product1, $product2, $product3);

Productが$product1から$product3(そして今後作られるProductインスタンス)の集合であるという概念的な背景があるが、自身の集合から3つ要素を選び、その合計金額を計算するのは、集合の機能としては妥当ではないだろうか？ これで1つ目の問題(インスタンスメソッドだと居心地がわるい問題)は解決だ。

2つ目の問題であったカプセル化毀損問題も同時に解決できる。もしも、priceがint型からCurrencyクラスになったとしても、その変更はProductクラスのコードだけで済むようになる。(もちろん、Product以外の他のインスタンスがpriceを使っていれば、そこにも変更が及ぶが、最大限変更の影響範囲をProductに留めることができる)

まとめ

• クラスはインスタンスの概念的な集合。
• 集合(クラス)に関する処理は静的メソッドが実装するにあたって良い場所である場合がある。

今後の話題

今回は触れなかったが、今後機会があれば触れたいこと:

• とはいえ、静的メソッドはできるだけ避けたほうがいい話。
• 静的メソッドの具体的なユースケースの話。

今日は fileinfo で tm 構造体を取得する関数について *_r() 版を使うようにする修正があった！

2019-03-09

weltling: Fixed bug #77576 pull the libmagic implementation of gmtime_r

• https://github.com/php/php-src/commit/65ffdc2adff1751d085288ca5df14625a69bd7f2
• [7.3~]
• ext/fileinfo で、tm 構造体を取得する関数について *_r() 版を使うよう修正
• PR:3749 の流れ
• *_r() 版は全環境で使えるものではないので敢えて上流に同期してない部分だったが、php-src で libmagic での代替実装を引っ張ってこれる仕組みがすでにあったので、そっちを使う形に調整して上流の実装に合わせた

Fabien Villepinte: Fix typo in libmagic version

• https://github.com/php/php-src/commit/d9a3cb0b365cf460239ce3b3f9fc6e59c541a5b0
• [7.3~]
• ext/fileinfo で、コメント内の libmagic のバージョン表記間違いを修正

weltling: Update libmagic.patch [skip ci]

• https://github.com/php/php-src/commit/3e92365fa2204ec73a24734b2e83153d9c04e919
• [7.3~]
• ext/fileinfo で、libmagic のパッチの更新

やったこと

vagrant
　起動
　停止
　破棄
　ファイル共有の確認

Linux
基礎操作
　webサーバー構築
　PHPサーバー構築（https://learning.courage.engineer/contents/?p=608）

　SQLインストール

PHPで作成した個人または家族で使える自宅用のWebポータルシステム「MyHome Portal」をオープンソース/フリーソフトとして公開しています。
2008年から2016年にかけて、こつこつとバージョンアップを繰り返して作成したものです。
中級プログラマの作品ですので、ソースコードはあまりきれいとは言えません。バージョンアップを繰り返したことでコードがきたなくなってしまっている部分もあります。モジュールの構造を複雑にしすぎたかもしれません。
2016/08/02以降、バージョンアップしていません。Webサービスを利用している機能など一部は、Webサービスの停止等の理由により動作しなくなっています。

公開ページ

https://ok2nd.github.io/myportal/

ブログ

最近、更新はほとんどありません。
中級プログラマの自宅でPHP ブログ

コンセプト

• 自宅でポータルとして使えるシステム。(家庭内グループウェア)
• データはインターネット上ではなく、ローカルPCまたはローカルサーバに保管。
• 初級、中級プログラマにも理解可能なシステム。
• PHP、SQL、JavaScript、HTML、CSSの知識だけで理解可能なシステム。
• PHPの良さを生かしたHTMLインラインコーディング。(なるべくprint文を使わない。)
• ブラックボックスの少ないシステム。
• オブジェクト指向型プログラミングを使わない。手続き型(関数型)プログラミングを採用。
• MVCを使わない。
• フレームワークに頼らないシステム。
• テキストエディタ以外の開発ツールを必要としない。

対象者

• 自分または家族専用のWebポータルサイトが作りたい。
• Webポータルサイトをインターネット上ではなく、ローカルPCまたは自宅サーバーで立ち上げたい。
• 日常的に良く使う機能が、個々のアプリケーションを起動せずに、ブラウザの中で出来たらうれしい。
• スケジュールその他自分の個人情報をインターネット上に置きたくない。
• パスワードなどのID情報をインターネット上に置きたくない。
• Webプログラム開発初心者。
• プログラミングを仕事でなく、趣味でやりたい。
  • オブジェクト指向が苦手。
  • MVCは面倒。
  • システム全体を把握したい。(ブラックボックスは少ない方が良い。)
  • フレームワークを使いたくない。(PHP、SQL、JavaScriptだけで開発したい。)

機能一覧

• ホームページインデックス(ブックマーク)＆検索
  • ブログパーツ貼り付け
• 付箋
• カレンダー(スケジューラ)
  • 天気出現率表示
• 旅行記
• ToDo
• 掲示板
• RSSリーダー
• メモ
• フォトアルバム
  • スライドショー
  • 動画サムネイル
  • FLV,MP4,WMV,MPG,MOV,M2TS(AVCHD)動画再生
• 学習
• 住所録
  • PDF葉書宛名書き
• メール(一括受信)
• SVGお絵かき
• ペン画
• チャット(Chat)
• ID・パスワード管理
• GPSログ(GPX)ビューワ
• 預貯金管理
• 縦計だけの表計算
• HTML URL抽出&ファイルダウンロード
• テキスト縦書き表示
• Excel to グラフ
• ソースコード表示&編集＋ファイルマネージャー
• MySQL管理ツール
• ファイル暗号化/復号化
• タイマーアラート

特徴・補足

• 自宅で個人や家族で使えるシステムを目指して作りました。家庭内LANでの利用を想定しています。
• 少人数の会社のイントラでの利用も可能かもしれません。 セキュリティは万全ではないので、スケジュール共有など機能を限定して利用願います。
• ユーザー登録など、インターネット上での利用を想定した機能も付けています。ただし、セキュリティ等保障はできませんので、インターネット上での実利用は、自己責任にてお願いいたします。あくまで、LAN内またはPC単体での利用を想定しています。
• 簡単なユーザー管理機能もあります。
• 認証機能もあります。
• ユーザー単位で他のユーザーに対して参照・書込の権限設定ができます。
• レコード単位での非公開の設定もできます。
• ただし、システム管理者はデータベースを直接見ることで全ての情報を参照ができてしまいますので、悪用しないように。
• ID管理では、二重の認証が必要なしくみにしています。
• ID管理では、パスワードを独自の方式で暗号化しています。ID情報は、２つのテーブルに分割して保存します。 暗号化のキーと２つのテーブルを別々にバックアップすれば、ID情報の復元はしづらい(?)と思います。
• 簡単なログ機能も付けています。
• 簡単なシステム管理者機能も付けています。
• コンテンツを追加しやすい構造にしています。
• ページ分割有りの一覧形式のページを簡単に作れる共有ライブラリを用意しています。一覧形式での編集もできます。 /myhome/common_/include-common-mp-list.php 各コンテンツのlist.php、category.phpを参考にしてください。
• 一覧形式の表示部分のみを、独自のphpソースに置き換えられます。($mp_list_arg['template_view'])

開発環境

• （Ver.3.27以降）XAMPP 1.7.1 (Windows)

  • Apache 2.2.11
  • MySQL 5.1.33 (Community Server)
  • PHP 5.2.9 + PEA

• （Ver.3.26以前）XAMPP 1.6.6a (Windows)

  • Apache 2.2.8
  • MySQL 5.0.51a
  • PHP 5.2.5

前回記事：① ConoHa VPS でWebサーバーとDBサーバーを分離する

この記事でやること

今回やることは下記です

• 前回作ったConoha VPSをWebサーバーとして動くようにする
• そこにPHPの簡単なスクリプトを設置
• スクリプトから前回作成したDBサーバーのデータベースに接続して情報を取得
• フロントに表示
• 2つ目のWebサーバーを作る

前回作ったConoha VPSをWebサーバーとして動くようにする

必要なものをyumでざっと入れてしまいます。

まずApacheを入れ、firewallでhttpアクセスを受け付けるようにします。

# yum install httpd -y
# firewall-cmd --permanent --zone=public --add-service=http

この段階でApacheを起動してfirewallを再起動してみます。

# systemctl start httpd
# systemctl restart firewalld

そしてブラウザでhttp://133.130.118.38/にアクセスしてみると、Apacheのデフォルトの画面が表示されます。

PHPのスクリプトから前回作成したDBサーバーのデータベースに接続して情報を取得してフロントに表示

Apacheを入れると、/var/wwwというディレクトリが作成されます。この中のhtmlフォルダにphpのファイルを配置していきます。

まずこのフォルダに移動します。

# cd /var/www/html

今回簡易的にphpファイルでデータベース接続を行うので、phpと周辺で必要なツールをインストールします。

# yum install php -y
# yum install --enablerepo=remi,remi-php70 php-mysqlnd -y

ここで、私の環境だとブラウザからアクセスしたときにphpが動かなかったので、httpd.confに一部追記をしました。

# vi /etc/httpd/conf/httpd.conf 

httpd.conf

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

phpファイルを作成します。

# vi index.php

index.php

<!DOCTYPE html>
<html>
<body>
<h1>Web Server:1</h1>
<?php
  define('DB_DATABASE','3vptj_test');
  define('DB_USERNAME','3vptj_test');
  define('DB_PASSWORD','Password1234');
  define('PDO_DSN','mysql:host=private.3vptj.tyo1.database-hosting.conoha.io;dbname=' . DB_DATABASE);

  try{
    //DB接続
    $db = new PDO(PDO_DSN,DB_USERNAME,DB_PASSWORD);
    $stmt = $db->query("SELECT * FROM fruit");
    $result = $stmt->fetch(PDO::FETCH_NUM);
    print($result[0]);
    //エラーをスロー
    $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

  } catch(PDOException $e){
    echo $e->getMessage();
    exit;
  }
 ?>
</body>
</html>

あまり詳しくこのコードの説明はしませんが、PDOとデータベースへの接続情報を使ってDBサーバー内のデータベースに接続、前回登録したfruitテーブルのappleを表示しているという感じです。

http://133.130.118.38に接続すると、Web Server:1という文字の下に先程fruitテーブルに登録したappleが表示されます。

ちゃんとDBサーバーのデータベースから情報も引っ張ってこれています。

2つ目のWebサーバーを作る

それでは、これまで作ったものと同じ構成のWebサーバーを作成します。
同じ構成のVPSを作る必要があるので、Conohaに戻り、イメージを保存。そしてそのイメージを用いてVPSのコピーを作成します。

先程のVPS詳細画面に戻り、サーバーをシャットダウンして、イメージ保存ボタンをクリックします。

続いてサーバー追加メニューから、作成したイメージをもとにVPSの作成を行います。（イメージが利用可能になるまで数分かかります）

今回はネームタグをtestVPS2としました。

また、IPアドレスは133.130.110.112が割り振られました。

新しく作ったVPSとDBサーバーとの接続は再度行わないといけないようです。前回の記事と同じ内容なので省略しますが、適宜行ってください。

あと、Apacheをサーバーの起動時に自動的に起動する設定にしていないのでsystemctl start httpdも必要なはずです。

このあとロードバランサを入れて振り分け処理が行われていることを視覚的に判断するために、index.phpを少し変えておきましょう。

index.php

// <h1>Web Server:1</h1> これを
<h1>Web Server:2</h1> // こう書き換え

さっそくこのVPSに発行されたIPアドレスhttp://133.130.110.112/にアクセスしてみると、下記のような画面が表示されます。

ここでもちゃんとDBサーバーのデータベースから情報も引っ張ってこれています。これでロードバランサを入れる実験の素地ができました。

次回記事：③ ConoHa VPS ロードバランサーを導入して複数Webサーバーの割り振り

Laravel5.4のバリデーションについて記載

1.Routeにフォームの送信先を記述

Route::post('/formurl/','ServiceController@validateRequest');

2.Controllerにvalidateを行う項目と内容を記述

public function validateRequest(Request $request){
    $this->validate($request, [
        //処理内容の指定（useridは必須、最大4文字）
            'userid' => 'required|max:4',
        ],

        //エラー文言の指定
        [
           'userid.required' => ':attributeは必須です。',
           'userid.max'  => ':attributeは４文字を超えています。',
        ], 

        //attributeに表示される表示名称の指定
        [
            'userid' => 'ユーザーID',
        ]);
}

3.続いてエラー処理の記述
エラーメッセージ、入力内容をリダイレクト先に付与

     if($validator->fails()){
         return redirect('/formurl')
             ->withErrors($validator)
             ->withInput();
     } else {

     }

4.失敗時にリダイレクト先でエラーメッセージの取得
index.blade.phpでの取得

     @foreach ($errors->all() as $error)
                        <li>{{ $error }}</li>
                    @endforeach

Controllerや、view composerで取得したい場合

     //エラーメッセージ
     $_session = session()->all();
     $_error_msg = $_session['errors']->default;

     //前回の入力内容
     $_session = session()->all();
     $_old_input = $_session['_old_input'];

以上

今回教材やサンプルの丸写しとかそういうの無しで自分の契約しているレンタルサーバーで使用することを想定したブログシステムを作ろうと思います。

日記形式で（なぜ

アウトプットはGitコミットのURLを貼っつけときます（近々貼ります）。

脱 コピペプログラマ╭( ･ㅂ･)و ̑̑

概要

レンタルサーバーで公開する前にローカル環境を構築し、一通りのシステムを実装し次第、レンタルサーバーにデプロイをする。

Qiita記事 : ビルドとデプロイって結局なんやねん！？！？！？？？みたいな記事

• Windows10 Pro
• XAMPP [Compiled: Nov 12th 2015]
  • PHP 7.2.2
• Composer version 1.7.2
• Node.js version 10.15.0
  ※nodist version 0.8.8
• TortoiseGit version 2.7.0.0
• Visual Studio Code version 1.26.0

たまたまこんな環境が整ってた。
きっと妖精さんが準備してくれたんだろう……

妖精さんが用意してくれたものでは不足しているのが出てきたら、都度追加しよう。

1日目

フレームワーク選定

とりあえず、フレームワークの選定から始めた。

フルスクラッチも考えたけど、破綻する未来が見えてきたのと、車輪の再開発？というのでしょうか……

すでに良いものがあって、それを使いこなせそう&規模感がちょうどよければそれを使うというスタンスで進めることに。

てことで、当方以前から目をつけていたSlimフレームワーク（Slim3）で開発を進めることにした。

えっ「Laravelちゃん使わないの？」だって？

規模でかくなるし、SSH接続できないレンタルサーバーにLaravelちゃんを使うのは怖い（実際現在使用しているレンタルサーバーではエラーでまくって萎えた、Slim3では動くのを確認済み）。

どうにか導入することもできるんだろうけど、ここであまり時間をかけたくなかったので。

shell

composer create-project slim/slim-skeleton oreoreTsuyotsuyoBlog

oreoreTsuyotsuyoBlogは適当な名前で

自分で適当なディレクトリを作成し、そこで

shell

composer require slim/slim "^3.0"

でも良かったのだが、今回はslim/slim-skeletonを採用。

理由としては前述の通り、程よい大きさで使いやすそうな車輪はつかうということと、必要な設定がすでに済まされていること（ひな形がパッケージインストール時に合わせて用意してくれる）、後々絶対使うと思われるものがしっかり入っていたため。

実際何がインストールされたか確認

composer.json

//前略
"require": {
    "php": ">=5.5.0", //いうまでもない
    "slim/slim": "^3.1", //Slimフレームワーク本体
    "slim/php-view": "^2.0", //テンプレートエンジン
    "monolog/monolog": "^1.17" //ロギング（使用経験なし
},
"require-dev": {
    "phpunit/phpunit": ">=4.8 < 6.0" //テスト（使用経験なし
},
//後略

monologは前々から使ってみようと思っていたので。
phpunitは余裕があればといった感じです。

XAMPPでバーチャルホストの設定（publicディレクトリをドキュメントルートに）と、hostsの設定を行い、表示確認ができたところで1日目終了。

おやすみなさい。

2日目

とりあえず、Slim3でMVCの概念を取り入れようと思います。

Qiita記事 : Slim Framework 3 MVC Skeleton Application

こちらを利用することも考えましたが、ちょっと自分で考えながらMVCの分割を考えることに。

まずは、Composerのautoload機能をこれから自作していくクラスもautoloadしてくれるようにしましょう。

composer.json

{
    //前略
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/",
            "Kato83\\Controller\\": "src/controller/",
            "Kato83\\Model\\": "src/model/",
            "Kato83\\Library\\": "src/library/"
        }
    },
    //後略

ModelとControllerを配置するパスとnamespaceを決めたら

composer dump-autoload

これでいちいちrequireとかincludeを書く必要が省けます。

今までもautoloadは書いてきてたけど、composerのautoload（psr-4）の機能使うのは初めてでした、めちゃ楽。

次、slim-skeletonを導入した時点でViewは分割できているので、ModelとControllerの分割。

Slimにpdoのパス情報を持たせて

src/settings.php

<?php
return [
        //前略
        // SQLite3 settings
        "pdo" => [
            "path" => __DIR__ . "/../oreoreTsuyoTsuyoBlog.db"
        ]
    ],
];

いわゆるDIコンテナにDBに接続情報を持たせて置きます。
……DIコンテナって何？
Qiita記事 : DIとDIコンテナを3分で理解する

src/dependencies.php

<?php
// DIC configuration
//中略
// SQLite3
$container["pdo"] = function ($c) {
    $settings = $c->get("settings")["pdo"];
    $pdo = new PDO("sqlite:".$settings["path"]);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
    return $pdo;
};

これで、ControllerからModelに処理を投げる際に、Slimのインスタンスを渡せばいい状態になった、はず。

src/controller/Hoge.php

<?php
namespace Kato83\Controller;

use Kato83\Model;
use Kato83\Library;

class Hoge{

    protected $app;

    final public function __construct($app){
        // Slim\\Appオブジェクトをセット
        $this->app = $app;
    }

    public function process($request, $response, $args){
        //Modelを呼び出している（インスタンス生成時にSlimのインスタンスも渡す
        $modelUser = new Model\User($this->app);
        $result = $modelUser->find("admin", "admin");
        var_dump($result); //SQLの結果が入っていれば良し
        return $response;
    }
}

んで、Model側

src/model/User.php

<?php
namespace Kato83\Model;

class User{

    /**
     * コンストラクタ
     */
    final public function __construct($app){
        // Slim\Appオブジェクトをセット
        $this->app = $app;
    }

    public function find($userId, $password){
        $pdo = $this->app->pdo;
        $stmt = $pdo->prepare("select * from user where userId = ? and password = ?");
        $stmt->execute([$userId, $password]);
        $result = $stmt->fetchAll();
        return $result;
    }
}

この調子で

• ブログシステムのログイン画面（ユーザー認証できたらダッシュボードへ）
• ダッシュボード（各メニューのナビだけ）

を作成しました。

MVCの概念取り入れとcomposerのautoload、namespaceとuseの使い方の学習でちょっと手間取っちゃいました、あまり進ままなかった。

おやすみなさい。

かなりレガシーなPHPのフレームワーク
ZendFrameworkで"Hello world"を表示するまでの備忘録
（今の時代はLaravelだろ！！って声がありますが、仕方がないんです！
だって次に関わるアプリがZendで作られているから）

Zendをするにあたっての一番の壁は、何と言っても
有力なドキュメントが少ない！！！！

ここまで有力なドキュメントがないフレームワークも珍しい。。。

という事で、Hello worldを表示するまでを書いていきます！
（間違っていたらご指摘をお願いします。。。。）

かなり参考にした記事（これがないと上手くいかなかった気がする）
https://codezine.jp/article/detail/1824
https://ameblo.jp/mingw/entry-11125339748.html

PHPの強力な味方XAMPP
XAMPPのページでインストールして下さい

ZendFrameworkのデータをダウンロード
ZendFramework公式

今回は、ver1でやります（なぜなら、自分が関わる案件がver1のため 笑）
ZendFramework アーカイブ

ZendFrameworkのファイルをダウンロードしたら
libraryの配下にある「Zend」フォルダだけXAMPPのhtdocsに入れます

「Zend」フォルダ

「XAMPPのhtdocsにZendフォルダを格納」

htdocs/Zendにindex.phpを作成し、下記のcodeを入力

<?php

// 必要なクラス定義を読み込む
require_once 'Zend/Controller/Front.php';

// アクションコントローラへ丸投げ
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory('application/controllers');
$front->dispatch();

?>

htdocs/Zend/Applicationに以下のフォルダを作成
controllers/
models/
views/
　└ scripts/
　　└ index/
　　　└ index.phtml

htdocs/Zend/Application/controllersに「IndexController.php」を作成し、下記のcodeを入力

<?php

require_once 'Zend/Controller/Action.php';

class IndexController extends Zend_Controller_Action
{
  public function indexAction() 
  {

  }
}

?>

htdocs/Zend/Application/views/scripts/index/index.phtmlに下記のcodeを入力

<html>
  <body>
    Hello world!
  </body>
</html>

これで、Hello worldと出力される。。。
この設定が出来るまでに7時間はかかった気がする。。
Laravelより本当に難しい。。。