azgz のすべての投稿

[ジーズアカデミー Advent Calendar 2015]メンター期間へ向けて

ジーズアカデミー Advent Calendar 2015の8日目です。
前日が空いてるので、誰から引き継いでるんだっけ?

事務局長、児玉さんのジーズアカデミー2016年展望①かなぁ。
それとも、山崎先生のG’sはここから始まった・・・そして・・・かな。

ともあれ、8日目のエントリーです。
なにを書こうかな、と思ったんですが、講師とチューターとして参加した経験から、
メンタリング期間に入る前までにしておいた方が良いなぁ、と思えることをいくつかまとめていきます。

[ジーズアカデミー Advent Calendar 2015]メンター期間へ向けて の続きを読む

コミュニケーションツールについて

暑い日が続きますね。
あついといえば、先日のメンターLT(ライトニングトーク)も、負けず劣らずの熱さでした。

ただ、メンターの皆さんの話に出ていたものの、業界用語でピンときにくい単語が、
いくつか出ていた気がしたので、軽くここで補足します。
主に、コミュニケーションツールについてです。

slack

slack 、スラックです。
多分、エンジニア界隈では、今一番使われているコミュニケーションツールかと思います。
例えると、エンジニア界のLINEでしょうか。
基本的には、「チャンネル」と呼ばれているグループ単位で、
情報やファイルのやり取り、共有を行います。
難点?としては、インターフェイスが全て英語である点。
とはいえ、ざっと使うだけなら、問題ないかと思います。

使い方は、以下のサイトなどが参考になるかと思います。

http://kai-you.hatenablog.com/entry/2014/08/11/154324

チャットワーク

チャットワークも最近よく聞きます。
名前の通り、チャットが出来るツールですが、
ファイルの共有や、タスク管理なども可能です。
グループウェア色が強い気がします。
とはいえ、開発・運営も日本の会社ということもあり、
日本語で使いやすいかと思います。

Backlog

Backlog バックログは、もとはプロジェクト管理ツールです。
バグの管理やグループウェアとしても使われたりもします。
だんだんバージョンアップして、git との連携機能なども、実装されています。
グループでAさんは○日までこれをして、Bさんは○にちまでにこれをして、
といった、ワークフロー管理が得意だったりします。
自分も WordCamp Tokyo 2012 の運営チームで使ってました。
こちらも開発元のヌーラボは福岡の会社で、日本語対応はばっちりです。

GitHub

みんな大好き、GitHub (ギットハブ、ジットハブ)。
ソースコードのホスティングサイトですが、ソーシャルネットワーク機能もあるため、
エンジニアの交流に使われたりもします。
GitHub やその基になっている Git については、近々勉強会? を企画しています。

あとは、、、何かあったっけ。
facebook グループや、facebook メッセンジャー、メールや、Skype など、
コミュニケーションツールはたくさん出てきているので、
なかなか使いこなすのも難しいところですが、まずは試してみて、
自分が使いやすいものを使ってみる、というのが良いかと思います。

授業フィードバック(2015.7.4)

7.4の授業フィードバックです。

universionsに提出されている課題や、当日のチューターリングタイムで、
一番手こずっている気がしたのが、更新処理でした。
中でも、更新するレコードを確定させる id の渡し方で困っている人が、
多かったので、補足します。

別ページにクエリパラメータを送るのは、GET

a.html から、b.html に遷移するときに、データを送るのには、
大きく二つやり方があります。
一つは、クエリパラメータで渡すやりかた。
もう一つは、form タグでデータを渡すやりかた。

まずは、クエリパラメータで渡すやりかたについて、再確認です。
これは、 リンクを b.php?id=10&age=30 という形で記述します。
GitHub 上の自分のソースだと、index.php の18行目が該当します。

<li><a href="update.php?id=' . $id . '">更新</a></li>

更新ページ update.php で更新するためには、id の情報が必要なので、
php でデータベースから取得した id を クエリパラメータにセットしています。

そして、クエリパラメータで渡されたパラメータの取得は GET で行います。
update.php の 3行目

$id = $_GET["id"];

で取得しています。
クエリパラメータで渡されたパラメータの取得は POSTでは行えないので、注意が必要です。

別ページにformデータを送るのは、POST

次にform でデータを送るやりかたを再確認しましょう。
update.php の 36行目から

<form method="post" action="update_execute.php">
<p>お名前:<input type="text" name="name" size="20" value="<?php echo $name ?>"></p>
<p>e-mail:<input type="text" name="mail" size="20" value="<?php echo $email ?>"></p>
<p>年齢:<input type="text" name="age" size="20" value="<?php echo $age ?>"></p>
<p>コメント:<input type="text" name="info" size="20" value="<?php echo $info ?>"></p>
<p><input type="submit" value="更新"></p>
<input type="hidden" name="id" value="<?php echo $id ?>">
</form>

ここでは、データベースから取得した、名前や年齢情報を value=”変数” という形でセットしています。
こうすることで、このページに来た際に、入力フォームにデータベースから取得した値が、
セットされた状態で、更新作業に入ることができます。

また、ポイントとなるのが42行目です。
というものを設定しています。
これは、ブラウザ上には表示しないが、パラメータとして送る際に良く使います。
そこのvalue に $id をセットすることで、次の更新実行ページで、該当する id のレコードだけ、更新可能にしています。

form で送られた値を受け取るのは、
update_execute.php の 3行目から

$id = $_POST["id"];
$name = $_POST["name"];
$mail = $_POST["mail"];
$age  = $_POST["age"];
$info  = $_POST["info"];

こうゆう形で、データの受け渡しを行います。
今回は基本的なデータの受け渡し、GET, POST, form の復習をしました。
データの受け渡しの知識は、これからも必要なので、押さえておいてくださいね。

デバッグ手法(PHP入門編)

今回はデバッグ手法について取り上げます。

ただし、PHPはサーバーサイドのプログラミング言語で、
JavaScript 以上にデバッグが難しい・デバッグ用のツール設定が難しいので、
何度かに分けて、取り上げたいと思います。

大きく分けて、
1. var_dump を使う
2. 統合開発環境を使う
3. ロギングライブラリを使う
となる予定です。(2と3は入れ替わるかもしれません)

なお、昨日の授業でのサポートをした感じだと、
SQL 周りのエラーでプログラムが動作していないことが多い気がしました。
後半、そちらについて記述しています。

何はともあれ、var_dump()

一番お手軽なデバッグ方法が、var_dump関数を使うことです。

<?php
$hoge = array("チーズアカデミー");
var_dump($hoge);
?>

と記述することで、

array (size=1)
  0 => string 'チーズアカデミー' (length=24)

と表示されます。

var_dump の引数に、変数を入れてあげれば、その中身が表示されます。

SQL の内容を確認したい

現在、授業で扱っている PHP とデータベースの接続に、
PDO(PHP Data Objects)を使っています。
これは、データベースを隠蔽してくれるものです。
しかし、データベースを隠匿しているがゆえに、
実際に実行されているSQL がわからなくなっています。

index.php から

<?php
$pdo = new PDO('mysql:dbname=gs_db;host=localhost', 'root', '');
$stmt = $pdo->query('SET NAMES utf8');
$stmt = $pdo->prepare("SELECT * FROM gs_cms_user");
$stmt->execute();
var_dump($stmt);
?>

一覧ページの SQLを実行済みの変数 $stmt を var_dump してみました。

object(PDOStatement)[3]
  public 'queryString' => string 'SELECT * FROM gs_cms_user' (length=25)

この場合は、実行されているのと同じSQL ‘SELECT * FROM gs_cms_user’ が表示されています。
では、次に登録処理を見てみましょう。

regist_execute.php から

<?php
$pdo = new PDO('mysql:dbname=gs_db;host=localhost', 'root', '');
$stmt = $pdo->query('SET NAMES utf8');
$stmt = $pdo->prepare("INSERT INTO gs_cms_user(
		id, name, email, age, info, update_date, create_date) VALUES (
		NULL, :name, :email, :age, :info, sysdate(), sysdate())");

$stmt->bindValue(':name', $name);
$stmt->bindValue(':email', $mail);
$stmt->bindValue(':age', $age);
$stmt->bindValue(':info', $info);
$flag = $stmt->execute();
var_dump($stmt);
?>
object(PDOStatement)[3]
  public 'queryString' => string 'INSERT INTO gs_cms_user(
		id, name, email, age, info, update_date, create_date) VALUES (
		NULL, :name, :email, :age, :info, sysdate(), sysdate())' (length=149)

太字の部分が実行されている SQL です。
ただし、プリペアードステートメントと呼ばれる形になっており、
実際のSQL とは異なる形になっていて、少しわかりにくくなっています。
この SQL が正しかを検証するには、bindValue している箇所に、
実際に値を代入して、 phpMyAdmin などから SQL を実行することで、
SQL に誤りがあるかを確認することが可能です。

例えばこうゆう形です。

INSERT INTO gs_cms_user(
		id, name, email, age, info, update_date, create_date) VALUES (
		NULL, 'あずま', 'example@example.com', '30', 'コメントコメント', sysdate(), sysdate())

なお、実行されているSQL は MySQL のログから確認可能です。
上のSQL はそこから取得したものですが、
デフォルトのXAMPP ではこのログの出力がオフになっているようです。

若干設定に注意が必要なので、授業時 or チュータリング時に、個別に説明できればと思います。
次回は前回の授業で気になった点を取り上げたいと思います。

入力なき出力は、画面に届かない

プログラミングをする際は、常に「入出力を意識する」ことが大事だと思っています。
今回は、更新ページ update.php について取り上げてみます。

入出力、とだけ言われても、何のことやら、という人も多いと思います。
これも考え方は無数にあって、例えば、

1.
index.php に対するリクエスト       → 入力
レスポンスされる php or html ファイル → 出力

2.
関数 getUser(id) の、引数 id    → 入力
戻り値 user (return user;)     → 出力

など、非常に幅広く捉えることが可能です。

「その画面」でどういった「出力(データ)」が必要か、を意識する

闇雲にプログラミングして、出来るときもありますが、
時間がかかるのでおススメできないやりかたです。
常に、「この画面で、どういった出力(データ)が必要か」を意識することが、
プログラミングをスムーズに進める上で、役に立ちます。

今回の update.php についていうと、画面に出力するのに必要なのは、
1ユーザの、名前・e-mail・年齢・コメント
となっています。

ここで、1ユーザというのが 一覧ページ(index.php)との違いです。
意識するべきことは、index.php と違って、全部のレコードを取得・表示ではなく、
ここで必要なのは、1レコードだけなのです。

ただし、一画面だけでは、どのレコードを取得すればいいかはわかりません。
レコードを一つ選択する、キーとなるものが必要になります。
今回の場合は、id がそのキーです。これが入力になります。
前の画面から id 情報を持ってきて、SQL を実行して、
名前・e-mail・年齢・コメントの情報を取得し、表示する、ということになります。

上の書き方に倣うと、

前ページ index.php から渡される id → 入力
そのユーザーの名前等の情報     → 出力

という風になるかと思います。

実は同じような入出力は一覧ページで、ページング(5件づつ表示し、次へ、前へをつける)際にも大事になってきます。
これについては、また後日、取り扱います。

次回は、「PHP でのデバッグ」について予定しています。

シンプルに考える

僕が設計や、実装をする上で心掛けていることに、
「可能な限りシンプルに」ということがあります。

例えば、システム構成。
複数台のサーバーで構築するより、1台で構築した方が、
プログラムの更新を反映するにしても、トラブルの原因を突き止めるのも、やりやすいです。

例えば、テーブル定義。
慣れないうちは、一つのテーブルに様々なカラムを入れてしまいがちですが、
適切なテーブルを、適正な関係で複数のテーブルを作成した方が、
データの登録・更新するには、行いやすいし、パフォーマンスもでます。

例えば、画面遷移。
最近ではSPA(シングルページWebアプリケーション)、
いわゆる1ページで完結しているサイトが、
スマホの普及とともに、どんどん増えてきいます。
ただ、僕はSPAはあまり好きじゃないです。
確かに、ページ遷移がないので、ユーザーはクリックして、
待たされることなく、次のページを見ることができますが、
作る側にとっては一つのページで処理することが増え、
デバッグにも手間がかかるようになります。

先日も、とある映画を見るために、某映画館のサイトを使いましたが、
SPAである場合、リロードする度にそれまでの入力がクリアされるために、
高負荷で繋がりにくくなった場合に、同じ情報を何度も入力する手間が出てきます。
シンプルに 1ページ 1役割にすることで、そうした状況がなくなります。

今回、僕が g’s cms で登録時のフローを考えた際の遷移図が以下になります。

seni1

GitHub上のソースと合わせて見ていただけばと思います。
Topページは index.php で「登録されている一覧を表示」する。
ページ下部に、登録ページ用のリンク regist.php を張り、
「登録情報を入力だけさせる」ページを作成する。
このページで登録した情報は、[登録]ボタンを押すことで、
「登録処理を実行する」 regist_execute.php に遷移。
ただ、登録を実行する URL をユーザーに見せてしまうと、
この URL に対して不正なリクエストをする人が出てきたりするため、
不可視な phpページとして作成し、
処理中にエラーが発生時は、regist.php にリダイレクトし、
成功時は、「登録完了を知らせる」 regist_complete.php に、リダイレクトさせる。

こう作ることで、1ページに 1役割を持たせた画面構成になる上に、
不正な登録を試みるユーザーに対する、若干のけん制にもなります。
(実際は regist.php のソースを見れば、formの先がregist_execute.php であるのは、
この構成では明らかですが、そこはまた別の話)

今回は画面遷移を設計することについてとりあげました。
ただ、「シンプルに考える」というのは、今後、いくつかの場面で、取り上げることになるかと思います。
その際に心の片隅にとどめていただいてもらえればと思います。

次回は、「入出力を意識する」ということについて、取り上げる予定です。

まずは、自己紹介から

メンバーの皆さん、こんにちわ。
講師兼チューターのアズマ、こと、アズマックスです。

このブログでは、g’s の課題についての取り組み方や、
システム設計の話やデバッグ方法、おススメ書籍やサイトなど、
自分のエンジニアとしての経験から、お伝えできればと思います。

まずは、自分の自己紹介を少々。
皇族関係でここ最近話題になっている大学の卒業後、
某通信会社の商品開発部門で1年半ほど働いたあと、
ITベンチャー企業に転職、ここでプログラマーとしてキャリアを積み始め、
最終的にマネージメント(4-5人、3-4ヵ月の規模、数千万規模の案件)まで、
6年ほど働いていました。

ほとんどのプロジェクトでは、Java を使った開発で、
たまに PHP のお仕事という感じでした。
当時としては珍しく、モバイルに特化した会社で、
基本的に携帯向けコンテンツ(いわゆるガラケーサイト)を手掛けていて、
携帯電話向けのコンテンツ変換エンジンの開発も担当していました。
キャリア課金とか、面倒だったなぁ。

その後、現職の会計事務所で、ほぼ会計の仕事をしながら、
たまにSEの仕事を請け負ったり、個人でシステム構築の仕事を受けたりしています。

色々やってきましたが、一番好きなのはバックエンド、特にインフラ周りですね。
サーバーやミドルウェアのセットアップやチューニングといった部分です。
逆にフロントエンド(HTML, CSS, JS)はあんまり得意じゃないので、
作業するときには、パートナーにお願いすることが多いです。

今現在は、AWS, Microsoft Azure, さくらのVPSが3台に、さくらのレンタルサーバー1台、
お名前.com のレンタルサーバーを運用しています。
さくらさん、万歳。

あとは、このブログも WordPress で作られていますが、
2010年ごろから、WordPress コミュニティに関わっていて、
勉強会等の運営や、プラグイン等の翻訳やパッチ作成などもしています。
そういえば、7月25-26日(土・日)に大阪大学で、WordCamp Kansai 2015 もあるので、
都合が合えば参加してください、って授業と被ってますね。。。

WordCamp Kansai 2015 バナー

東京での WordCamp は秋ごろに企画中です。
自分が過去に運営側で参加した WordCamp では、ライトニングトークのスピーカー選定や、
書籍販売ブースなどを担当していました。
WordPress は GPL というライセンス方式を取っていて、
WordCamp でもGPSに伴う制約が色々とあったりしますが、
その辺も「オープンソースとライセンス」というテーマで、
機会があればお話しできればと思います。

と、まぁ軽い自己紹介です。
知りたいことがあれば、個別にお聞きしていただければと思います。
次回から、現在取り組んでいる課題に関するエントリーを書いていけたらと思います。