プログラム言語「 PHP 」 の 概念とその 有用性

1. プログラム言語「PHP」の概念とその有用性 by 古庄

2. 自己紹介 • 古庄と申します • Webでは「がる」というハンドルでふらついております • 本職は技術者です。現役プログラマーやってます • あわせて設計とかインフラとか教育とか色々やってます • 引っかかりやすいGoogle向けキーワードとしては「古庄道明」「エンジニア 親方」「エンジニア 禅」「がる」あたりでしょうか。 • あちこちのサービスで「gallu」ってIDでふらふらしてます • はてな、twitter、githubなど

3. PHPのメリットってなに？ • PHPを学ぶのに「ほかの言語のほうがよくて、PHPを学んでもあんまり意味がない」と、ちょっと悲しいので • 今「なぜPHPなのか」を再確認してみましょう

4. Web用に作られた言語 • 「Webアプリケーション」を作る上で、このあたりはいろいろと便利だしありがたいですね • 典型的には、スーパーグローバル変数の$_POSTと$_GET、$_COOKIEあたりが顕著です • 使う頻度は少ないですが、$_FILESも便利ですね

5. 学習的に、敷居が低い • いくつか「但し書き」はつきますが(その辺は後述)、入り口が広くて敷居が低いのは、原則、メリットです • 登り続ける必要がある「山脈」であるのはあらゆるプログラミングにおいて共通ですが、敷居が高いと、上る前にへこたれます orz

6. 環境的に、敷居が低い • レンタルサーバで、PHPが「使えない」ところのほうが少ないですね • 自力でサーバを立てるにしても、比較的インストールに手間がかかりません

7. 案件的に、メリットが高い • 案件単価などではJavaのほうが高いことも多いですが、数量的にはPHPが大変に多いです

8. PHPのデメリット？ • 一般的に言われているデメリットを検証してみましょう • 良しと悪しは、双方ともちゃんと向き合うべきものです

9. 重い / 遅い • 比較対象にもよります • 実際に「重い / 遅い」ケース • C言語とかと比較すると圧倒的に重いし遅いですね。なので、PHPで「OSを書く」とか「デバイスドライバを」とか「組み込みが」とか考えるのはやめましょう • 差異がないケース • よく一時期比較されていたPerlだと、さほど大きな差異はないです • それ以外でも。処理が100～200msほど変わるケースは時々見かけますが、それが「本当に意味のある数値であるかどうか」は、状況次第です

10. セキュリティ的に脆弱 • 一時期言われていた「嘘」です。どの言語で書いても、その辺に言語差異はたいしてありません • かつ、現在良書があるので、PHPはむしろ、Webセキュリティ的には「学びやすい環境が整っている」ので、他言語より安全なものが作りやすい学習環境は整っています • ただし、もちろん「学ばずに」プログラムを組めば、見事なほどに脆弱なものができあがります • でもそれって、別に言語によらず… orz

11. HTMLとロジックが分離されてない • たしかにPHPでもありますが、PerlやJavaのWebアプリケーションでも十分に見かけます • テンプレートエンジン、みんな使いましょうね！！(笑

12. 動的型付き言語は危ない • いわゆる「型宣言のない」言語ですね • …実際まぁ、危ないです • でもそれいったら、JavaScriptとかどうするんだろう… • なかなか難しいですが、型はできるだけ意識しておきましょう • よかったら「2a問題」でググってみてくださいませ PHP驚愕の事実 if ('2a' == 2) { 　ここ通る }

13. global変数 / 変数のスコープ • global変数はまぁ「使わないように」しましょう • それはどこでも一緒 • 危なさについては、後で例題を • 変数のスコープは「関数」単位までで、｛} によるブロックスコープは存在しないので気をつけましょう • でもこれも、最近ない言語増えてるし…

14. 「PHPは初心者に優しい」という嘘 • 「導入の敷居が低い」のは事実です • でも、プロとして「一定レベルのコードを書くために必要な経験値と知識と熟練度とレベル」ってのは当然あります • 間違っても「学ばずに書ける」とか「学習量が少ない」とかって意味ではありません。 • この「導入の敷居が低い」と「プロとして要求される品質」の間にある乖離を感じ取ってください • プログラムは「言語」です。「日本語が読み書きできる」と売り物として「詩が書ける / 説明書が書ける / 小説が書ける」は、全然意味が違います。

15. php.iniという存在 • ………実際困りものではあります orz • ここは本当に「デメリット」ですが。知識があれば、その落とし穴へのはまり込みを最小限に食い止めることはできます！！ • 自分にとっての「定型パターン」をあらかじめ作っておくのもよいですね

16. プログラミング初心者の為のTips • まずは「PHPほとんどわからない」人のためのTips • 「これからPHPを始める人」用のTipsですが、いくつかは、その後でも十分に役に立つテクニックだったりはします

17. nameアトリビュート • <input name=“hoge”> • デザイン的に「一番意味のわからない」アトリビュート • ですが、PHP的には「これがないと始まりません」！！ • 「どんな名前か」までを含めて大切なので、PHPエンジニアと協議のうえ、適切な名前でお願いいたします

18. hiddenのお話し • <input type=“hidden” name=“” value=“”> • データの持ち回りなどによく使います • hiddenは「簡単に改ざんできます」！！ • 時々「設定情報をhiddenに入れる」ものを見ますが、厳に慎みましょう

19. formのmethod • <form action=“./hoge.php” method=“post”> • <form action=“./hoge.php” method=“get”> • <form action=“./hoge.php”> • これもPHP的に重要ポイントです。 • formの場合、九分九厘postです • 一応、エンジニアと確認はとっておきましょう

20. checkboxの[] • <input type=“checkbox” name=“hobby”> • これだと「複数のチェックが取得できない！！」 • <input type=“checkbox” name=“hobby[]”> • これが正しい！！ • これは「PHPに固有の書き方」なので、他言語では存在しないので気をつけてください！

21. エラーが出た！ シンタックスエラーの出し方 • 特に共有サーバで多いのですが「エラーが出ない(画面真っ白)」ってのがあります • エラーメッセージはどの言語でも有効ですが、PHPは「割合と丁寧なエラー出力」なので、なおのこと重要です！ • この「エラーメッセージ」のon/offは、php.iniで設定されています

22. 本来的には、以下の記述でエラー出力をonに出来ます本来的には、以下の記述でエラー出力をonに出来ます // ini_set('display_errors', 'on'); error_reporting(E_ALL);

23. E_ALLの中身(の一部) • E_ERROR • 重大な実行時エラー • E_WARNING • 実行時の警告 (致命的なエラーではない) • E_PARSE • コンパイル時のパースエラー • E_NOTICE • 実行時の警告。エラーを発しうる状況に遭遇したことを示す • などなど

24. 例)関数のtypo • php.iniを読み込む(エラー出力：off) • phpファイルを読み込む • phpファイルの中を解析する • 解析したphpファイルを実行する • ini_setでエラー出力がonになる • 関数の行。関数を探しに行く • 関数が見つからない • エラーを出力 • 終了

25. 例)シンタックスエラーの場合 • php.iniを読み込む(エラー出力：off) • phpファイルを読み込む • phpファイルの中を解析する • 解析でエラー • エラーを出力、でも出力がoffなのでなにもしない • 終了 • …いや終了言われても、シンタックスエラー出てこないと困ります orz

26. シンタックスエラーの出し方その１ • 一つは .htaccessに書く php_valuedisplay_errors 1 php_valueerror_reporting32767

27. シンタックスエラーの出し方その２ • もう一つは「別のphpファイルからinclude」 • ファイル名は適当に、たとえばt.phpで用意します • 検査対象のファイル名を「hoge.php」と仮定します <?php ini_set('display_errors', 'on'); error_reporting(E_ALL); include(‘./hoge.php’);

28. エラーが出た！ シンタックスエラーの潰し方 • エラーは出たけど「どこが」間違ってる？ • この調査が早いほど「最終的なプログラムの仕上がり」は早くなりますし、ここで「ドはまり」すると、いくらでも時間は浪費されていきます • ちなみに、有効なメソッドを２つ • 一服、休憩、一寝入り • ベアプログラミング(not ペアプログラミング)

29. シンプルケース • エラーが発生している行か、その上の方でエラー 1 <?php 2 3 $i= 10; 4 $test = 'test' 5 echo $i , $test , "\n"; Parse error: syntax error, unexpected 'echo' (T_ECHO) in /home/furu/t.php on line 5

30. 面倒なケース • 以下のパターン。どこがエラーかわかります？ 1 <?php 2 // 3 $no = 10; 4 for($i = 0; $i < $no; $i ++) { 5 echo $i , "\n"; 6 } 7 // 8 $test = 'test; 9 if ($argv[2] == $test) { 10 echo ('ok'); 11 } Parse error: syntax error, unexpected 'ok' (T_STRING) in /home/furu/t.php on line 10

31. まずは「全体的に」コメントアウト 1 <?php 2 /* 3 $no = 10; 4 for($i = 0; $i < $no; $i ++) { 5 echo $i , "\n"; 6 } 7 // 8 $test = 'test; 9 if ($argv[2] == $test) { 10 echo ('ok'); 11 } 12 */

32. 少しづつコメントアウトから出してみて 1 <?php 2 // 3 $no = 10; 4 /* 5 for($i = 0; $i < $no; $i ++) { 6echo $i , "\n"; 7 } 8 // 9 $test = 'test; 10 if ($argv[2] == $test) { 12 echo ('ok'); 13 } 14 */

33. ifやforは、ブロックの中をコメントアウト 1 <?php 2 // 3 $no = 10; 5 for($i = 0; $i < $no; $i ++) { 6 /* 7 echo $i , "\n"; 8 */ 7 } 8 /* 9 $test = 'test; 10 if ($argv[2] == $test) { echo ('ok'); 13 } 14 */

34. 1 <?php 2 // 3 $no = 10; 4 for($i = 0; $i < $no; $i ++) { 5 echo $i , "\n"; 6 } 7 /* 8 $test = 'test; 9 if ($argv[2] == $test) { 10 echo ('ok'); 11 } 12 */

35. で…見つける！！ 1 <?php 2 // 3 $no = 10; 4 for($i = 0; $i < $no; $i ++) { 5 echo $i , "\n"; 6 } 7 $test = 'test; 8 /* 9 if ($argv[2] == $test) { 10 echo ('ok'); 11 } 12 */

36. デバッグの基本 • 落ち着いてこつこつと、一つづつ丁寧に • 一番使っちゃいけない単語は「出来ているはず」「ちゃんとここは通ってるはず」「この変数には正しいデータが入っているはず」 • できている「はず」なら動く「はず」だよね？ • きちんと、var_dumpなりprintなりで「通っている証拠」を出しましょう。エビデンス、って言い方をします

37. 「技術者と会話が出来る」レベルのTips • 「書けるかは自信がないけど」会話はできる、くらいのレベルは、一つ「目安にする」ところです • これが出来ると「技術者に、お願いと依頼と相談と交渉と締め上げが出来る」ので、大変に重宝がられます

38. includeとrequire • *_onceってのもありますね • 細かい使い分けは以下の通り • includeはファイルがないときにfalseを返し警告が発生します • ｒequireはファイルがないときにE_COMPILE_ERROR レベルの致命的なエラーを出します • _onceが付くと、同じファイルの読み込み重複は無視します • まぁrequireのほうが処理としては安全です • 以降、includeと書いてあったら、特に但し書きがない限り「includeとrequireのどちらにもいえる話」です

39. includeファイルはどこにあるの？ • ./と書いてあったら、実行ファイルと同じディレクトリです • 書いてない場合は、どこを探しにいくのでしょうか？ • 調査用コードと、たとえばの結果 <?php var_dump( get_include_path() ); string(20) " . : /usr/local/lib/php"

40. ほかの場所にファイルを置きたい場合の方法 // $path = 'ファイルを置きたいディレクトリの絶対パス'; set_include_path(get_include_path() . PATH_SEPARATOR . $path);

41. includeしたファイルの?>と改行 • サンプル • ?>の後の改行が、時々悪さをします • 「テンプレート使って、phpファイルにはプログラムしか書いていない」前提で。?>は「書かない」ほうが圧倒的に安全です <?php $i = 10; echo $i , "\n"; ?>

42. 「よそ様のincludeファイル」に ?>と改行があって如何ともしがたい場合の場当たり的回避策 <?php ob_start(); // 回避策 start require_once('他人様のライブラリ.inc'); require_once('他人様のライブラリ2.php'); ob_end_clean(); // 回避策 end // 以下、普通にコードを書く

43. 何かのタイミングで￥が増殖する… • 「addslashes」がonになっていると予想されます orz • 一応先に。addslashesは「百害あって一利なし、何があろうともゼッタイに絶対に使ってはいけない」設定です • 類似品：register_globals • でも、たまにonだったりします orz • その場合、プログラムの先頭でとりあえず回避しておきましょう • 回避用のコードはあちこちで検索できるので、省略

44. ちょっとした修正なら出来そうな人へのTips • 簡単なコードなら書ける、直せる、くらいのレベルの人向けのTipsです • ここらあたりから、場合によっては「初級の技術者」としてのお仕事が選択肢の可能性として存在し得ます

45. コメントについて • 実際「超」が付くほど重要です！！ • 「コメントがなくても理解出来るような、わかりやすい命名と流れるようなロジック」は重要です • でもそれはそれとして「コメントを書く」必要があります • コメントには「こんな事をしたい」という気持ちを書きましょう。その気持ちの「表現方法」として、プログラム言語があります

46. 「日本語で」プログラムを書こう • まずは「日本語で」「箇条書きで」何をやるかを細かく書いてみましょう • その「書かれた日本語」で、何をやるかが明確に理解できますか？ • 理路整然とした「箇条書きの指示」が書けたら、それを「コメント」として残しておいて、そこからプログラムを書いてみましょう • ちゃんとコメントも残せるので一石二鳥です

47. プログラムが「書けない」理由 • プログラムが書けないのは「PHPでどう書くかわからないから」じゃない • 「プログラム的にどう分解したらいいかわからない」から • もうちょっと突っ込むと「何をやるか」が理解しきれてないから • だからこそ、まずは慣れている「日本語」で、箇条書きで「何をするか」を細かく書きましょう

48. インデントについて • 丁寧に入れましょう。バグのいくつかが防げます • ifやforの「 {} の省略」は避けましょう！！ if (条件式) hoge_true_call(); foo_call(); if (条件式) hoge_true_call(); hoge_true_call2(); foo_call();

49. エラー出力とメッセージ • プログラム中にエラーメッセージを入れるのはやめましょう。後々、運用で面倒です。 • テンプレートエンジンは「ロジックとデザインの分離」です。プログラムはロジックだし、エラーメッセージは「デザイン」の仲間です。 • 次のPageで具体例を。

50. エラー出力とメッセージ：駄目な例 $smarty->assign('name_error', '名前は必須です<br>'); {$name_error} 名前： <input type="text" id="form_name" name="name">