Laravel + SQLServerとかやるときのメモ
sudo yum install -y epel-release
sudo yum install -y http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
sudo yum update
# これがないと SQLServer への接続でコケる
sudo yum localinstall https://packages.microsoft.com/rhel/7/prod/msodbcsql17-17.4.1.1-1.x86_64.rpm
# Laravel が起動するのに必要な様々ないろいろ
sudo yum install -y php74 php74-php-common php74-php-cli php74-php-mbstring php74-php-gd php74-php-pear php74-php-pdo php74-php-mcrypt php74-php-xmlrpc php74-php-soap php74-php-devel php74-php-intl php74-php-xml php74-php-sqlsrv
# php で呼べるようにしとく
sudo ln -s /usr/bin/php74 /usr/bin/php
php -r "phpinfo()" > phpinfoするThreadで検索、Thread SafeかUnSafeか調べるphp\extに配置php.iniのDynamic Extensionsセクションに次のような感じで記述# php_と.dllは勝手に補完される
extension=pdo_sqlsrv_74_ts_x64
extension=sqlsrv_74_ts_x64
php -r "phpinfo()" > phpinfoしてsqlsrvが確認できたらOK今時CGIなんて言わない？知らない？そんなこたぁいいんですよ。
ふと思ったんですよ、CGIとCLIアプリって本質的に同じものなんじゃないかなって。
だってPHPってこんなふうに書いてブラウザでアクセスしたらいろはにほへとって出るじゃないですか？
そしてこれをphp index.phpみたいにして叩いてもいろはにほへとって出ますよね？
<?php
echo 'いろはにほへと';
そう、気付いてしまったのです。
実はCGIって本質的にはCLIアプリなのではないかと…。
むしろ何が違うんでしょう？
気になったのでどういう仕組で動いてるのか軽く調べるために、敢えてC言語でCGIを作ってみることに。
今までC言語でCGIとか狂人のやることって印象があったのですが、意外とやってみると大したことはないというか、まぁ大したものを作ってないから当たり前なんですが…。
これが何をしているかというと、環境変数を取ってきて標準出力に吐いてるだけなので、どっからどう見てもCLIアプリです。
#include <stdio.h>
// getenv
#include <stdlib.h>
// strcmp
#include <string.h>
/*
get path for after hostname
*/
char* getPath(void) {
char *path = getenv("REQUEST_URI");
return path;
}
int main(void) {
// put http header
printf("Content-type: text/plain\n\n");
char *path = getPath();
// show current path
printf("Current path: %s\n", path);
// routing, required .htaccess to serve on apache
if (strcmp(path, "/foo") == 0) {
printf("hoge");
} else if (strcmp(path, "/bar") == 0) {
printf("piyo");
} else {
printf("fuga");
}
return 0;
}
恐らくこれは動作環境が重要なのであって、多分CGIとCLIアプリの作りとしては大きな違いはないのではないか？というのが辿り着いた結論です。
いやまぁ引数をargvから取るか環境変数から取るかは結構違う気もしますが、基本的に表示したいものを標準出力に吐く点は同じですし、別にCGIでTCPソケットを触るわけでもないので、同じようなものでは？と思った次第。
これは多分、 HTTPサーバーを通すことで標準出力がHTTPレスポンスに出力され、 Xサーバーを通すなら画面に、プリンタサーバーを通せば紙にといった具合に、どこのサーバーを通して標準出力をするかで出てくるところが変わるのでは？と感じました。（細かいことを言うともっと複雑らしい）
多分ApacheとかのHTTPサーバーはTCPソケットをいい感じにやってくれて、 HTTPヘッダを環境変数に入れてCGIスクリプトを起動といったところをしてくれているのではないかと思ったので、暇な時にTCP通信から始めるHTTPサーバーの実装でもやってみたいところですね…。
取り敢えずPHPのCGIをCLIとして動かせるやつです。
<?php
echo $_SERVER['REQUEST_URI'];
PHPでClassをrequireせずに使えるやつ
Laravelのrequest()とかがどうやって呼ばれてるのかを調べていくうちに辿り着いたのでメモがてら
Classは簡単に読み込めるけど、Functionは一筋縄ではいかなさそう
ついでにClassに好き勝手プロパティ増やせることも発見した
spl_autoload_registerを使う。Laravelはcomposerが上手いことやってくれてるっぽかった
<?
function regist() {
spl_autoload_register(function() {
require './Hoge.php';
require './Piyo.php';
});
}
適当に用意
<?
class Hoge {
public $hoge;
}
<?
class Piyo {
public $piyo;
}
ついでに好き勝手にプロパティも生やす
<?
require './bootstrap.php';
// ここでクラスをautoloadする
regist();
// どこからも呼んでないけど
$h = new Hoge;
// 生やせる
$h->fuga = "aaa";
$h->hogepiyo = "bbb";
// 使える
$p = new Piyo;
$p->fuga = "aaa";
$p->hogepiyo = "bbb";
var_dump($h, $p);
/*
結果
class Hoge#2 (3) {
public $hoge =>
NULL
public $fuga =>
string(3) "aaa"
public $hogepiyo =>
string(3) "bbb"
}
class Piyo#3 (3) {
public $piyo =>
NULL
public $fuga =>
string(3) "aaa"
public $hogepiyo =>
string(3) "bbb"
}
*/
composer initでプロジェクトを作成composer require [パッケージ名]でパッケージを入れるcomposer.jspnに以下のセクションを作成
"autoload": {
"psr-4": {
"App\\": "src/App" // 名前空間と対応するパス
},
"classmap": [
"src/App" // クラスを読み込むディレクトリのルート
]
}
autoloadやclass_aliasなどを設定するbootstrap.phpを適当に作成
bootstrap.phpはエントリポイントからrequire_onceなどで読み込無事で有効化するphpunitを組み込む場合
composer require --dev phpunit/phpunitでインストールcomposer.jsonに以下のセクションを作成 "scripts": {
"test": [
"phpunit --bootstrap bootstrap.php test"
]
}