Amazon LinuxにPHP(v7.2) + Apache インストール
0. 前提 (ファイアウォールの設定)
Amazon Linux が実行されている Amazon EC2 インスタンスのセキュリティグループの設定で、80番ポートがインスタンスへの到達を許可するルールとして設定されていること。
1. PHP インストールの準備
Amazon Linux が実行されている Amazon EC2 インスタンスに対して EPEL リポジトリを有効にする
Amazon Linux 2 で EPEL rpmパッケージをインストールして有効にする
$ sudo yum install –y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
その他の環境では以下の通り。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-enable-epel/
2. PHP, Apacheのインストール
2.1 Remi リポジトリの追加
Remi で提供されているソフトウェアをインストールするためには EPEL のリポジトリも必須要件のため、先に EPEL のリポジトリの追加を行った後に Remi のリポジトリを追加する。
$ sudo yum -y install epel-release
次に Remi のリポジトリ情報をインストールする。
$ sudo yum -y install http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
2.2 PHP 7.2 & Apache httpd のインストール
Apache httpd と組合せて PHP 7.2 をインストールする。
まずは yum search で httpd と PHP 7.2のパッケージを検索して、リポジトリで提供されていることを確認。
$ sudo yum search httpd php72
存在が確認出来たらインストール。
$ sudo yum -y install httpd php72 php72-php
2.3 インストールの確認
httpdを起動
$ sudo systemctl start httpd.service
/var/www/html/info.php を作成（ドキュメントルートが異なる場合は環境に合わせて）し、下記の内容を記述してインストールされている PHP の情報を表示する。
<?php phpinfo();
info.php にアクセス。
http://<サーバホスト名>/info.php にアクセスし、PHP の情報が表示されればOK！
参考にしました。
https://weblabo.oscasierra.net/centos7-php72-install/
上流工程のいろは
ウォーターフォール開発における上流工程には業務ではほとんど関わったことがありませんが、主に基本設計について勉強する機会があったので記録。
色々な所ですでにまとめられてはいますが、個人的に腑に落ちた言葉でまとめます。
いつものやつ
この図でいう左側について主に。
要件定義
目的
- システムで満たすべき機能や品質を定義する。
- 開発工数を見積れるレベルまで要件を抽出する。
要件定義の作業と成果物
| 作業 | 成果物 |
|---|---|
| ユースケース分析 | ユースケース一覧 |
| ビジネスルール一覧 | |
| ビジネスルール | |
| 概念モデリング | 概念モデル |
| 用語集 | |
| 非機能要件定義 | 非機能要件定義書 |
機能要件と非機能要件
- 機能要件
システムの利用者に対して提供される具体的な価値。利用者の何らかの目的を達成するために使われ、ユースケースで定義されるもの。 - 非機能要件
利用者が機能を利用するために補助的に必要なシステムの特性や性能のこと。
そもそも設計を行う目的
- 要件定義の内容をどのようにシステムで実現するかを検討する。
また以下の理由から、開発プロセスの一部でもあり、より良い開発を行うためにも必須である。
* 関係者間での情報共有
* 品質の向上
* メンテナンスのため
基本設計
目的
- 要件定義で明確になっていない外部仕様を検討し、落とし込む。
- システムのI/Oを明確にする。
- 機能・非機能要件、異常系動作、制約条件をまとめる。
基本設計の作業と成果物
| 作業 | 成果物 |
|---|---|
| 画面設計 | UI設計ポリシー定義書 |
| 画面遷移図 | |
| 画面一覧 | |
| 画面モックアップ | |
| 画面入力チェック仕様 | |
| 画面一覧 | |
| 外部システムI/F設計 | 外部システムI/F仕様書 |
| バッチ設計 | バッチ仕様書 |
| 帳票設計 | 帳票仕様書 |
| DB論理設計 | DB論理設計書 |
| 論理ER図 |
詳細設計
目的
- プログラマが実際のプログラムが作れるレベルまで細かく落とし込む。（プログラム設計）
詳細設計の作業と成果物
| 作業 | 成果物 |
|---|---|
| 画面プログラム設計 | アクション一覧 |
| アクション設計書 | |
| 画面共通部品設計書 | |
| ビジネスロジックプログラム設計 | ビジネスロジックプログラム設計書 |
| データベースプログラム設計 | エンティティクラス図 |
| DAOクラス図 | |
| データベース物理設計 | 物理ER図 |
| テーブル定義書 |
基本設計については別の記事でもう少し詳しくまとめます。
参考にしました
ちょっと古めの本なので例として挙げられている技術がいにしえ感あるのですが、WF開発の根幹となる部分を学習するにはよかったです。
初心者向けです。上流工程に普段から関わられている方にはおそらく物足りない。
PHP5 初級試験 [基本編]
PHP5 初級試験 [PJ0-100] 勉強中なので、基本的な内容について学んだことをつらつらと箇条書きで書いていきます。
書いて忘れないようにする作戦なので、内容にはご期待なさらず。
- 変数名の大文字/小文字を区別する。関数は区別しない。
- ""（ダブルコーテーション）で囲った変数は展開される。''（シングルコーテーション）は展開されない。
- == での値の比較はデータ型を見ない。===は見る。
- 下記の比較を行なった場合、'1abc'の後ろの文字列は削除され、trueになる。
'1abc' == 1
- 変数と配列の違いがあっても同一変数名は使用できない。
- 連想配列も配列の順序は保持される。
- グローバル変数を操作するときは、明示的に指定が必要。
- ヒアドキュメントは改行を含むような長い文字列を表すのに適する。
- 連想配列のキーは整数値 or 文字列に変換される。（booleanのtureも文字列に、07という文字列は7という整数値に、10.5→10、null→空文字列、配列やオブジェクトはキーにできない）
- 7!=7 と7<>7は同意義
- <=>演算子は、左辺が右辺より小さい時には-1, 同じ時には0, 等しい時には1を返却する。
- メモリ・リソースの開放を明示的に行う必要はない。
- スクリプトの実行前・後に自動的に実行するスクリプトをphp.iniで設定できる。
- PHPはシステムを初期化する段階でモジュールを読み込む。
- PHPの文字列型は文字エンコーディング情報を持たないのでバイナリ型として利用できる。
- array_mergeで配列を連結すると添字振り直し。加算演算子で連結すると添字維持。
- 型をチェックしなければ、0, null, false, から文字は全て等しい。
- 配列は加算演算子に対応しているが、減算演算子には対応していない。
- PHPはプラットフォーム間の差異を完全には吸収しない。
- OSによってはサポートされていない関数がある。
- シングルコーテーションを利用した方が速度は速い。ダブルをつかうと、文字列に変数が含まれるかパースが行われるため。
- スコープレゾリューションオペレータ（::）って呼ぶ
- Javaと違い、引数1で定義した関数の呼び出し時に引数をいくつ渡してもエラーは出ない
function say_hello($name） {
echo "こんにちは $name さん！";
}
say_hello('やまだ', 'すずき', 'さとう'）;
- Javaと違い、関数の定義時にデフォルト値を設定できる
- include/require文で関数定義を行うファイルを２回以上読み込むと定義済み関数が再定義されるエラーが発生する。
- require文は読み込むファイルが存在しないと致命的なエラー（E_ERROR）を発生させ、スクリプトの実行が停止する。
増えたりします。
ところでいつかPHP7の試験に切り替わるのではと待っていたのですが、それっぽい動きがないですね。
参考にしました
PlantUML 備忘録
PlantUML
PlantUML はUML図描画のためのDSL(ドメイン特化言語) です。
業務で図形を描画するには一般的に Cacoo や Google図形描画などが使用されることが多いですが、バージョン管理に一苦労することはネックかと思います。
PlantUMLは指定の記述方法を利用することでテキストベースで主要なUML図を作成することができるため、バージョン管理ツールで管理しやすく、記述方法も比較的シンプルで直感的であることが強みです。
PlantUMLが対応するダイアグラム
PlantUMLが対応するダイアグラムは以下の通りです。主要なものはだいたいサポートされているかと思います。
UML以外の図もサポートしてます。
PlantUML Viewer（Chrome拡張機能）
テキストで記述したUML図を確認するのに個人的にオススメなのがChromeウェブストアからDLできる PlantUML Viewer です。
Eclipseプラグインなども存在しますがなんか色々インストールが必要でめんどくさかったり、そもそもEclipse起動するのも面倒だし、お手軽にブラウザで確認できるところが気に入っています。
PlantUML系のまとめを読んでいても案外Chromeに拡張機能があることは記述がないので、布教程度に。
拡張機能の追加後、chrome://extensions/ にアクセスし、下記にチェックを入れることで有効となります。
シーケンス図
まずは業務でも作成したことのあるシーケンス図について、簡単なウェブアプリケーションのログイン機能を想定して作成していきます。
シーケンス図については、この辺り がとても参考になりました。
簡単には、クラスやオブジェクト間のやりとりを時間軸に沿って表現している図のことです。
最終的にはこんな図を作成したいと思います。↓
PlantUMLでシーケンス図
まずはおまじない。お好きな場所にテキストファイル(.txt)を作成し、下記の青字の記述を追加します。
@startuml ここに記述していきます @enduml
ログインするユーザを配置します。
@startuml
actor ユーザ
@enduml
この時点でchromeからシーケンス図を確認すると、ユーザの図が現れているはずです。このようにどんどんテキストでシーケンス図を書いていきます。
先ほどは分類子（棒人間の図）を表現するために actor というキーワードを使用しましたが、ほかにも下記のようなキーワードを使用することで分類子を簡単に表現できます。
- actor
- boundary
- control
- entity
- database
これ以降、デフォルトの分類子（四角）を表現するために participant キーワードを使用していますが、省略もできますので明示的に宣言する必要はありません。
次に、処理の進む方向を -> 、戻る方向を --> もしくは <-- で表現します。
ログイン処理を行うため、ユーザ分類子からログイン分類子に処理を進めます。
@startuml
actor ユーザ
participant ログイン処理
ユーザ -> ログイン処理 : ログイン
@enduml
処理の説明を : で区切った先に記述します。
また、分類子には別名をつけられます。ユーザに user 、ログイン処理に login という別名をつけてみます。シーケンス図の見た目こそ変わりませんが、別名を付与した以降は別名を使用して記述していけますので、大規模なシーケンス図になればなるほどありがたいですよね。
2byte文字を参照せずに済むという利点もあると思います。
@startuml
actor ユーザ as user
participant ログイン処理 as login
user -> login : ログイン
@enduml
次に、ライフラインでイベントが実行中であるということを示すため、 activate、deactivate キーワードを追加していきます。
これを追加することで、ライフライン上にイベント実行中（四角い箱）が表現されます。
@startuml
actor ユーザ as user
participant ログイン処理 as login
activate user
user -> login : ログイン
deactivate user
@enduml
次にログイン処理がユーザの存在を確認しに行くデータベース分類子を定義し、処理を進めます。
@startuml
actor ユーザ as user
participant ログイン処理 as login
activate user
user -> login : ログイン
activate login
database データベース as db
activate db
login -> db : データベース問い合わせ
deactivate db
deactivate login
deactivate user
@enduml
ここまででリクエストの定義は完了です。次のステップからレスポンスを定義していきます。
先ほども少し触れましたが、処理の戻る方向は --> もしくは <-- で表現します。
この二つに表現される内容の違いはありませんが、可読性のためにレスポンスであることがわかりやすいよう <-- の使用が推奨されているようです。
これを各分類子の間に定義していきます。
@startuml
actor ユーザ as user
participant ログイン処理 as login
activate user
user -> login : ログイン
activate login
database データベース
activate データベース
login -> データベース : データベース問い合わせ
login <-- データベース : レスポンス
deactivate データベース
user <-- login : /indexにリダイレクト
deactivate login
deactivate user
@enduml
ログイン成功、失敗によって処理を分けます。分岐処理は一般的なシーケンス図と同様に alt キーワードを使用して記述します。
分岐処理のみでなく、複雑な処理を表現するための複合フラグメントは多種存在します。
分岐処理の構文は下記の通りです。
alt 条件1 処理1 else 条件2 処理2 end
ログイン成功時は/indexにリダイレクト、失敗時はエラーメッセージを表示するといった処理を上記構文で表現すると、このようになります。
@startuml
actor ユーザ as user
activate user
participant ログイン処理 as login
user -> login : ログイン
activate login
database データベース
activate データベース
login -> データベース : データベース問い合わせ
login <-- データベース : レスポンス
deactivate データベース
alt 認証[成功]
login --> user : /indexにリダイレクト
else 認証[失敗]
login --> user :認証失敗のメッセージを表示
end
deactivate login
deactivate user
@enduml
以上で、冒頭のシーケンス図が完成します。
PlantUMLの中でもシーケンス図に絞り、ごくごく簡単で基本的な内容にしか触れていませんが、複雑な処理を簡単に記述することができ、共有しやすく、かつバージョン管理もしやすいことは伝わったかと思います
いつかクラス図にも触れられたら、記事にします。
