限定コンテンツについて考える②
おはようございます、佐伯です。そろそろ年末調整の季節ですね。
私はこの時期になると新卒で入社した会社は本決算11月だったなあ…と思います。
さて今回はちょっと伸ばし伸ばしにしていた限定コンテンツの進化版…進化版？むしろこっちの方が主流というかポピュラーかな。【会員登録してからログインして限定コンテンツを表示する】の話。
前回のやつはこれ
今回は取り敢えず【下準備】をやりたい。
いつも通りのアレだけど、もっといい方法は多分あるしこれは正しい手法ではあるけれど大正解ではないということだけ頭の片隅に置いてください。
弊社ちゃんのカッチョが『プログラミングは方法であって結果ではない』という名言を言っていたのでまあ極論結果だけ合ってればええんや
用意したもの
- Visual Studio Code（エディタ。以下vscode）
- xampp
この最低限でこの二点。下は内訳。
エディタに関しては正味なんでもいいです。自分の使いやすいものを使って下さい。エディタは宗教。
ただemmetとかLintとかLive Viewとかようするに拡張機能的なところで
下準備編
環境構築
XAMPPの設定については後日。
phpMyAdminのパスワードとかの設定がうんたらかんたらあります。
取り敢えずディレクトリ（フォルダ）構成は
の構成にしました。
modelとviewに同じ名前のファイルがありますが違うファイルなので、もしも分かりにくい場合は適宜ファイル名を変更して使って下さい。
あと本来であればここにCSSのフォルダとかも必要になってきちゃったりします。
まあ参考程度に私はいつも大体こんな感じ！！MVCのこと意識するまではページとか全部ごった煮でした。ﾍﾍ
SCSSってなーに？についてもまあ…後日ね…。気が向いた時にね…。
なんか取り敢えずCSSファイルだと思ってくれたらいいです！そこは！！今は！！！
XAMPPを起動して
の二つを動かしておきます。
xamppはcontroll.exeっていうのを起動するとコンパネが開くのでそこから起動してください。
絶対バツで閉じるなよ！！！！！！！Quitボタンで閉じてください。
データベースを作る
前に！！！！！！！
まずどういうデータベースが必要なのかを決めておきます。
必要な情報って人それぞれだからね…。
決めなければならないのは
- データベース名
- テーブル名
- テーブルの中身
の三つ。データベースにはテーブルを複数作れるので他のデータを入れたい時は同じデータベースを使ってオッケーです。
データベースを本、テーブルを章分けだと思うのが分かりやすいかな？
章はいくつでも入るけど本が変わったら変えたいよね～～ってかんじで。
ちなみに今回のデータベースは会員登録をしたユーザーのデータを保持するのに使います。
データベース名：main
テーブル名：userdata
内容
| 名前 | 内容 | |
|---|---|---|
| 1 | ID | 通し番号 |
| 2 | userID | ログインID |
| 3 | password | パスワード |
こんな感じで準備したいと思います。
SQLはこちら。
phpMyAdminで画面上から作ってもどっちでも良いですよ～
こんなの書きましたけど私はいつもphpMyAdminからやっちゃってます。
もっと情報量の多い大きいデータベースとかだとこうやってSQL文書いた方が楽だったりするんですけど、その辺は適宜ってことで。
CREATE DATABASE main; USE main; CREATE TABLE userdata ( ID int(5) NOT NULL AUTO_INCREMENT , userID VARCHAR(20) NOT NULL, password VARCHAR(255) NOT NULL, PRIMARY KEY (ID), UNIQUE(userID) );
AUTO_INCREMENTは自動採番の機能があるのでIDにつけてます。
つまり何もせずとも何番目に登録した人かが分かるわけだ、便利だね。
登録する情報が少ないと丸被りしちゃう可能性も否めないからPRIMARY KEYをID、UNIQUEをuserIDに設定しておきます。
どっちも取り敢えず重複を禁止しているということだけ覚えて下さい。PRIMARYは大体自動採番のとこにつけといたらええんちゃうか…みたいな気持ちでつけてます。
難しいことはあとからでも良いと思う。
とりあえずこれでデータベースの下準備は完了
define と fanction を作る
次にデータベースに接続するための下地を作っておきます。
ファイル：class/define.php
define('DB_HOST','locallhost');
define('DB_USER','root');
define('DB_PASS','hogehoge');
define('DB_NAME','main');
define('TB_user','userdata');
// define('表記名','実際の表記')
defineファイルは固定数の設定場所なので正直作っても作らなくてもどっちでも良いんですけど、何回も書いたり長いものを書いたりするのが面倒なので予め設定しておきます。
他にも繰り返し使う単語があるなら設定しておいても楽かも～～！！
まあ、私はdefineで設定するのはこの辺のデータベース関連だけですけどね。
ファイル：class/function.php
function PDOconnect()
{
try {
$dbh = new PDO('mysql:host=' . DB_HOST . ';dbname=' . DB_NAME . ';charset=utf8', DB_USER, DB_PASS);
} catch (PDOException $e) {
var_dump($e);
exit;
}
return $dbh;
}
function.phpにデータベースの接続用のプログラムを予め書いておきます。
このfunctionから始まるやつをメソッドと呼びます。
メソッドは～～なんか～～繰り返し使える定型文の設定だと思って下さい。
何回も使いまわしする処理はこうしてメソッド化しちゃいます。
なんでかというと
- いちいち書かなくて済むから
- 修正するときに直すところが一か所でいいから
の二点！何事も使いまわしが大事。お洋服みたいなものですね。
取り合えずここまで ちょっと長くなっちゃいましたけど次回からは中身を作っていこうと思います～！
セッションについて考える。
おはようございます。絶妙にやる気のない佐伯です。
本日の佐伯は昼から本気を出すと思う。
今回はセッションについて考えたいと思います。
セッションというとオタクにとっても、オタクじゃない人にとっても結構馴染み深いワードなんじゃないでしょうか。
バンドとかで合わせるのもセッションだし、TRPGで卓を回すのもセッションって言いますもんね。
正しい意味としては『〔公的機関の〕委員会、総会、議会、法廷』という意味らしいんですけど。まあようするに人が集まってなんかやるくらいのニュアンスなんですかね、日本だと。
このセッションというやつはプログラムでもよく出て来るワードなので、自己理解も併せて紐解きたいと思います。
いうて先に結論
プログラミングにおけるセッションとは『ページを跨って値を保持すること』を言います。
『セッションを渡す』『セッションを保持する』なんてワードがちらほら飛び出してきます。
前述の意味を考えると集まったものを解散せずにそのまま…？みたいなイメージになりますね。
基本的には設定した値はそのページ限りのものです。
まあそりゃそうよね、WEBサイトも元はHTMLファイルなんだもの。HTMLファイルでどっかの数字をインポートとかなかなか出来ないですよね。
ただし自分でサイトを作ったことがある人はご存知のはず。
メールフォームだったり拍手機能だったり、入力したものを送信するシステムがあるじゃないですか？
あれが『セッションを渡している』という状況なわけです。
じゃあ『セッションの保持って？』となるかもしれません。
皆さんamazonやら楽天やら通販サイトは使ったことがあるかと思います。
あれって注文するのに会員登録とログインが必要ですよね。
で、ログインしたあと何処にいっても右上辺りに『〇〇さん』とか自分が設定した名前が表示されているんじゃないですか？
それがログインの保持です。違った、『セッションの保持』というやつです。
なんでセッションの話？
フォロワーに名前変換小説書いてる女が多いからです。
あれも、ページが変わっても設定した名前が反映され続けますよね。
つまるところ『セッションの保持が行われている』わけです。
ところがどっこい、ちょいとお待ちよ！
そもそも、セッションの保持ってどこで行われてるんでしょう。
プログラム内という答えは半分正解半分外れです。
何故ならばプログラムは随時書き換えを行うわけではなく、出来上がったものを使います。
つまり『ここに入力される言葉を保持』はという指示は出来ても『入力された〇〇という言葉を保持』ということは出来ないわけですよね。プログラムを作る時には何が入力されるかなんてわかんないわけですから。はい目から鱗一枚ぽろり～！！
ここで原点に戻ると『じゃあどうやって値の受け渡しをしているのか』という話になります。
もったいぶらずに正解を言うと『URLで受け渡しをしている』です。
.htaccessで表示しないようにしてる可能性もあるので具体的にこうこうとは言えませんが凡そ『（URL～）?hoge=foobar』みたいなことが書いてあったら？以降の部分が受け渡してるセッションです。
因みにURLはUTF-8で出来ているのでセッションの中身が日本語とかだとなんじゃこれ！？！？みたいな文字の羅列になっていたりなどします。
どうやって渡してどうやって受け取る
こういう時に画像を作るのがベストなのは重々承知ですけど面＆倒なので文字だけ書くと
渡す 受け取る
ページ －－－－－＞ サーバー －－－－－＞ ページ
と一回サーバーを介すわけです。ページ⇒ページというのは当然出来ません。
まあこの辺はちょっと説明が怠いので後日需要があればというアレで。
取り敢えず一回サーバーを介さなければならないと。
そしてサーバー内で通じるのはまた別の言葉なんですよね。サーバー内部は外国。
終わり
プログラムやり始めて気付いたことは当たり前のことでも案外面倒なことが多かったりすること。
「こういうのしてよ～！簡単でしょ～？」と言われても全然簡単じゃないことって多々ある。
わたしはjsにわかだからjsで書いてあることをPHPで出来るなら全部PHPでやりたい。
けど流石に食わず嫌いでどうこういうのはなんか違うと思いますので夢小説変換スクリプトのDreamMakerを見てみようと思います。
リンク貼ろうと思ったけど応援リンクみたいなんあってやべえや！！となったので気になる人は調べてくれ。
そんで見たら使い方とメリデメリちゃんまとめると思うけど、はよして欲しい人いたら連絡下さい。
ていうか絶妙に寒いからマジで眠気に抗うのに必死なんですが。
MVCについて考える
おはようございます。
昨日まで取り掛かっていた業務内で制作部長にやんわりと全ボツを貰った佐伯です。
仕事にはしていますがまだまだペーペーのひよっこなのでこういうことはまあ、正直稀によくあるんですが採用になったのはデザインだけでシステム面ではほぼ全改修みたいなことになってしまいました。
今回ネックになったのは『MVCで構築出来ていない』という部分なのですが、お恥ずかしい限りですがわたくしMVCという概念を初めて聞きました。こういう部分が独学で、資料も無くグーグル先生に頼り切った場合に起こる弊害かなと思います。
ということで、今回は自分のためのメモを含めてMVCという構成について書き留めます。
MVCとは
M(Model)
V(View)
C(Controller)
に分けて構築を行う形態です。
例えばですが「TOPページ」を作るのに「Index.php（コントローラー）」「top.php（ビュー）」「topFunction.php（モデル）」の三ファイルに分けて構築します。
更に言えばここに「header.php」「footer.php」も分けて構築するので何も考えずに全部突っ込んで作るのに比べるとファイル数が結構増えてしまったりなどします。
まあこれだけ言うと「ファイル多くなるなら管理大変やんけ！！！！」という話になりますが、まあぶっちゃけ結構面倒ではある。
ただこれがベスト、そしてポピュラーに使われている（らしい）というのは、その面倒な感じを差し置いても余りあるメリットがあるからこそです。（多分）
MVCの役割分担
結論から先に言ってしまうとMVCというのは役割分担のことです。
Model（処理を書く）、View(外見を書く)の二つをController（コネクター）で繋ぐ、みたいなイメージなんですかね。この辺私もよく分かっていない。
まあでも要するに「処理系（プログラム）」と「画面表示（ＨＴＭＬ）」を別で書く、という話だけ分かっていれば大体問題ない（と思う）（実運用する時はだめです）。
これは弊部署のカッチョが出してくれた具体例ですが、WEBデザイナーとコーダーは必ずしも同一人物ではないし、プログラマとコーダーが別の人間であるという可能性も無きにしもあらず。
そういう時に同時進行で作業を進めるためにも、MVCという概念で分離しておく必要があるのだそうで。ホワーーーンなるほどね！？と思いましたね。
確かに、プログラマが必ずＨＴＭＬ書けるわけでもないしコーダーがプログラム書けるわけでもないもんね。確かに私もそうだった。
MVCのメリット/デメリット
そしてここにくるわけです。
私がMVCという概念に揉まれてみて、ごった煮ファイルとの違いを見たときに「これは確かにええぞなもし！！」と思った点を箇条書きで恐らく将来面倒臭がる自分に宛てて。これは戒め。
メリット
- ソースの可読性が高い
- 言語混在が最低限なので見やすい。
- ファイルを小分けにするので全体的に短くなる。（ただし増える）
- 使いまわしが利く
- メソッド化をめっちゃするので同じ処理を繰り返し書かなくていいし後から「この処理使えたやんけ！！メソッドにしとけばよかった！！」みたいなの大分少ない。
- 修正が簡単
- メソッド以下略なのでプログラム修正は一か所とかで済む。
- 共通化ファイルが多いのでやっぱり一か所で済む。
- 小分けにしているが故にどこに何があるか分かりやすいので、いちいち探さなくていい。
- 機能追加が簡単
- そもそも最初から別立てしているので、新機能での影響範囲が狭い。
結論
組む時に混乱してても見返した時とかに大分楽なので、今後はこれを順守して構成していきたいなと思いました。（作文かな？）
正味メソッドという方法が頭からすっぽ抜けててめちゃくちゃ適当に書いてしまってる部分が多々あったりするので、取り敢えず念頭に置きながらの改修に精を出していこうと思う。
半年前に書いたソースもう何書いてあるかも分からんし自分が何を思ってこんなこと書いてるのかさっぱり分からんけど、これ以上どうしていいのかも分かってないです正直言うて。
自分宛のメモ書き
<?php //functionの書き方 function hoge($foo){ //ここに処理 return $return } function getRequest($key){ if (isset($_REQUEST[$key])) { // リクエストパータを返す return $_REQUEST[$key]; } } //Controller session_start(); require_once(dirname(__FILE__) . "/parts/header.php"); require_once(dirname(__FILE__) . "/parts/footer.php"); $mode = ''; $mode = getRequest('mode'); getHeader(); switch ($mode){ case 'case1': require_once('parts/pages/case1.php'); break; case 'case2': require_once('parts/model/case2.php'); require_once('parts/pages/case2.php'); break; default: require_once('parts/pages/top.php'); //専用JSをフッター前に挿入 require_once("class/script.php"); break; } getFooter();
