2014-11-05

事業計画書のススメの話

ブログ

おはようございます。

「年の瀬も押し迫り、今年も残すところあと僅かとなってまいりました。」

という言葉のように、いつもより時間の流れを強く感じます。

簡単に言えば、

「ソワソワ」

しています。

新しいサービスをリリースしてから、色々な人に会う機会に恵まれ、その中で「じゃあ、こんなこと一緒にできそうやね」とか「一回、資料見せてよ」なんてことでお仕事に発展しそうなこともあったりなかったりです。

そんな中で、事業計画書を書いたので今日はそんな話を書いていこうと思っています。

/*————————————————————————————————————*/
といことで、今日は「事業計画書のススメ」の話です。

「事業計画書ってナニ??」って人のために、簡単に説明すると、

<a href="https://kotobank.jp/word/%E4%BA%8B%E6%A5%AD%E8%A8%88%E7%94%BB%E6%9B%B8-1465077">事業計画書とは - コトバンク</a>

ざっくり書くと、自分が始めるビジネスについて「5W2H」で書いていく計画書のことです。

起業する時や新サービスをリリースするときなどに作成するんですが、自分は今回初めて作成しました。

今まで作ってこなかった利用としては、特に利用するシーンがなかったからです。

この事業計画書を利用するとすれば、おそらく大半は

「資金需要があるとき」

だと思います。

銀行や投資家から資金を融資（投資）してもらう、企業と提携するなど、こちら側に何らかの資金需要がある時ですね。

「◯◯をやって、△△には利益が出る予定なので、資金をお願いします!!」

という時です。

逆に言えば、お金が必要でなかったり、提携したりする必要がなければ無くても別にやっていけます。
（まだ、成功していない自分がこんなことを書いても説得力に欠けるかもですが。）

なので、特に資金需要の無かった自分は特にきっちりと事業計画書を書いたことがありませんでした。

でも、今回のサービスリリース後に会った先輩から「一回、書いてみてみせてよ」と言われたので作成してみたところ、大きな発見がありました。

どんな発見かというと、

「サービスのメリットの再確認と具体化」

です。

これは「運が良かったと口にする」理論と一緒ですね。

言葉にすることで「あ、こういう意味では運が良かったわ」というように、言葉や文字にすると頭が勝手にどこが運が良かったのか考え始めます。

例えば、

「業務を効率化できます!!」

と書いた後に、

「どんな業務が効率かできるんだろう?」
「効率化したらどうなるんだろう?」
「なんで効率化するんだろう?」

といったことが頭をよぎります。

そうすると、

「コストがカットできます!!」

とかだけじゃなくて、

「つまらない事務作業がなくなったら、作業が楽しくなる」
「もっとクリエイティブなことに集中できる」
「やりたいと思っててたけど、できなかったことをする時間ができる」

とかが浮かんでくると、

「そうそう、俺はこんなことがやりたくてこのサービスを作ったんだった!!」

みたいにテンションがあがって、もっともっと便利にしてやるぞ!!という意欲に燃えます。

そう思いながら作ったサービスはきっと当たると思います。
（今回は当たらなくても、そう思いながら応募し続ければいつかは当たります。）

もちろん他にも、

「応募の一つである」
「数値化する機会」
「考えの世代管理ができる」

などの利点もいっぱいあります。

どうやって書けばいいかわからない場合もあるかも知れませんが、少しググればいっぱいフォーマットが転がっています。
そのフォーマットを埋めるだけで大丈夫です。

きっと、最初は意外と上手く埋められなかったりします。

埋められないということは、そこまで深く思考できていなかったということです。
（自分もそうです）

ここで、「めんどくさっ」とか「別に今必要じゃないし」とか自分に言い訳をつけちゃうと良くないです。

抽象的に考えていたことを、文字や数字に置き換えて裏付けを取りながら書くと、色々な発見があります。

そこに費やすだけのコストに見合ったリターンは期待できると思います。

そして、作るだけでもいいけど、せっかく作ったんだったらそれを「応募」するともっともっと大きな成果があると思う。

早速、今日メールで送りつけてやろうと思っています。
（きっと、ケチョンケチョンに批評されるだろうけど。。。）

そう思うと、今まで自分が作成しなかったのは、「別に今必要じゃない」とかテキトーに自分に理由をつけて逃げてたのかもしれないと反省するところです。

一生懸命作ったのを批評されるのは好きじゃないし、怖いからね。

でも、今回はもっと面白くできるかもっていう好奇心の方が勝ってる感じ。

あとは、この好奇心からくるウキウキを日常に変えて、ベクトルを外に向けれるように練習することやね。

ということで、行き詰まったり、ブレイクスルーしたいときなんかは、イチから事業計画書を書くことも効果的だなと思いました。

煮詰まったり、上手くいかないときは、行動や動作をちょっと変えてみる。

ご一読頂きまして、ありがとうございました。

2014-10-29

PCが壊れてしまったの話

ブログ

おはようございます。

気がつけば、10日以上更新感覚が空いてしまって自省しているところです。

一つ、言い訳をするならば、メインとして使っているPCのDISKが壊れてしまって、てんやわんやな状況でした。

仕事の重要なコード関係は、Bitbucketに保存していたので最悪の事態をさけることができましたが、バックアップをとっていなかったので、全部イチから設定し直して、アプリをインストールして、環境を整えてとリカバリーに奔走していたこの一週間でした。

人生の中で最もバックアップしておくことの重要性を強く感じた期間でした。

このことに限らないのですが、どうして人は、

「痛い目をみないと学習できないのか」

ということを強く感じます。

インプットしたものを本当の意味で、自分の血肉とするのには痛みが必要だったりします。

今回のことでも、バックアップを作ることの重要性は理解していたはずです。

だからこそ、dropboxやEvernote、bitbucketなどを利用してリスクを分散していたのですが、結局は必要なデータが消失してしまうという事態を招いてしまいました。

で、ようやく重い腰をあげて、バックアップ環境を整えることを決断しました。

これも結局、

「データが全部消える」

という、大ダメージを受けたからこそ、バックアップをとっておくことの本当の有り難みや効果を知ることになりました。
（逆に言えば、これがなかったらバックアップの効果を感じることはなかったかもしれません。）

まだまだ短い人生しか歩んでいない自分ですが、

「本当の意味を知る」

とか

「はじめの一歩を踏み出す」

というのは、痛い目をみたことの教訓を得ないとなかなか実現できないんじゃないかと思っています。

もちろん、痛い目を見なくても、「学び」や「気付き」はあります。

でも、手っ取り早く自分のモノとしたい場合は、痛い目を見て、その傷を早く直して、次の機会にもっと上手くやるための教材とする。

「貴方が転んでしまったことに関心は無い。
そこから立ち上がることに関心があるのだ。」
by.エイブラハム・リンカーン

どれだけ早く立ち上がって、ついた泥を払い、次に向かえるかどうか。

そうやって、どんどん前に進んでいくような人間になりたいと強く思っています。

と、自分の凡ミスを正当化してみたけど、きっと夢をかなえるゾウの「運が良いと口に出して言う」という教えは、きっとこうやって、起きた出来事から何かを学んでいこうと姿勢を言っているんだと自分を納得させている今日この頃です。

同じ失敗でも、今回みたいな凡ミスとかじゃなくて、もっとアグレッシブな失敗をしたいと思いました。

ご一読頂きまして、ありがとうございました。

2014-10-17

新しいサービスリリースの話

ブログ

おはようございます。

昨日は新しいWebサービスのリリースやそれにともなって、久しぶりに色んな人に連絡をとったら飲みにいこうという運びになったりしました。
そう思うと、何かやってみる・行動してみると、それに波及する形で色んな風に動いていくんだなと実感することとなりました。

働きかけられるのを待ってても何も起きないけど、自分から働きかけてみたら何か変化をもたらすことができるもんなんだと思っています。

改めて、行動すること・応募することの大事さを感じています。

それに、もう今年も２ヶ月半を切ってしまっていることにびびっちゃいます。

この前、今年はこんな1年にする!!って決意を固めたのに、もう年の瀬も近づいてきます。

そんなことを言ってたら、

「もう、来年オリンピックやん!!」

っていうのもあっという間な気もしています。

話は前後しますが、Webサービスをリリースするときのソワソワ感はなんとも難しい気持ちですね。

「機能はこれで大丈夫か」
「もっと、機能を追加してから出した方がよかったのか」
「本当にニーズを満たしてるのか」

などの不安や焦りもありますが、

「やっとここまでこれた!!」
「ようやく新しい一歩が出せる!!」
「これからスゴいことになるぞ!!」

といった、期待とウキウキが入り交じった不思議な感じですね。

で、この感じって前にも体験したことあったなって思ったら、バスケの公式戦の前のソワソワ感に近いんですよね。

「明日、シュート入らなかったらどうしよう」
っていう不安と、
「俺らが勝ったらすごいことになる!!」
っていうウキウキ。

なんていうか、自分の行動次第で未来が変わるんじゃないかっていうこの感覚は本当に久しぶりで、前の会社で働いていたときには感じなかった感覚だなと思いました。

それは、「自分」という個人の存在が試されているからなのかなと思いました。

会社でも、もちろん担当者として個人の働きが評価されていた部分があると思いますが、どこか「組織」が守ってくれるし、「組織」が評価される部分がありました。

本当の意味で「最前線」で戦っていなかったということなのかなと思います。

自分のプレーでチームを勝たせる　＝　自分のアイデアを形にして成功する

プレッシャーも当然大きいですが、これを成功させられたときには、また違う世界がみえてくるのかなと思いました。

これは一人の人間にとっては小さな一歩だが、人類にとっては偉大な飛躍である。
by:ニール・アームスロトング

社会全体から見ると小さな一歩だけど、自分にとっては大いなる一歩。

そんな風に思いながら、また頑張っていきたいと思っています。

ご一読頂きまして、ありがとうございました。

2014-10-11

【PHP】フロントコントローラとルーティングの話その2

プログラミング

おはようございます。

今日は前回の続きで、「フロントコントローラとルーティング」のパート2です。

ルーティング

前回までで、URLからPATH_INFOを抜き出すRequestクラスについて説明していきました。

この取得したPATH_INFOからコントローラとアクションを特定する処理を「ルーティング」と呼びます。
つまり、アクセスされたURLを自動的に判別して、そのURLから自ら定義したルールに沿ってコントローラとアクションを呼び出すということです。

具体的には、次のような連想配列の形でルーティングを定義していきます

<?php
array(
  '/' => array(
    'controller' => 'home',
    'action' => 'index'
  ),
  '/user/edit' => array(
    'controller' => 'user',
    'action' => 'edit'
  ),
);
?>

ドメイン直下であれば、「home」コントローラ、「index」アクション
http:hogehoge.com/user/editというようなURLだったら、「user」コントローラ、「index」アクションを呼び出すように定義されています。

動的ルーティング

ここまでは結構簡単に理解を進めることができるかと思いますが、次がちょっと難しい正規表現を利用して動的にルーティングを定義していきます。

たとえば、「user?id=1」というURLなどはたびたび利用していると思います。
それを「user/1」といったような形で扱えるように制御していくのが動的なルーティングとなります。

パーフェクトPHPでは「：」（コロン）で始まる文字列を指定すると、その部分を動的なパラメータとして扱えるように規定しています。

<?php
//動的ルーティング
//"/user?id=1"というURLを"/user/1"として扱う・・・①
array(
  '/user/:id' => array(
    'controller' => 'user',
    'action' => 'show'
  ),
);
//動的コントローラ/アクションの指定・・・②
array(
  '/:controller' => array(
    'action' => 'index'
  ),
  '/item/:action' => array(
    'controller' => 'item'
  ),
);
?>

動的ルーティングを実装するために「preg_match()」という関数を用います。
この関数は第3匹数に変数を指定するとキャプチャした値を取得することができます。
【参考URL】
http://php.net/manual/ja/function.preg-match.php

また、②のようにGETパラメータだけでなく、アクションの指定も動的に行うことができます。

<?php
class Router{

  protected $routes;

  public function __construct($definitions){
    $this->routes = $this->compileRoutes($definitions);
  }

  public function compileRoutes($definitions){

    $routes = array();

    foreach($definitions as $url => $params){
      $tokens = explode('/',ltrim($url, '/'));
      foreach($tokens as $i => $token){
        //動的パラメータか判定
        if(0 === strpos($token, ':')){
          $name = substr($token, 1);
          $token = '(?P<'.$name.'>[^/]+)';
        }
        $tokens[$i] = $token;
      }
      $pattern = '/'.implode('/', $tokens);
      $routes[$pattern] = $params;
    }
    return $routes;
  }

  public function resolve($path_info){
    if('/' !== substr($path_info, 0, 1)){
      $path_info = '/'.$path_info;
    }

    foreach($this->routes as $pattern => $params){
      if(preg_match('#^'.$pattern.'$#', $path_info, $matches)){
        //コントローラー・アクション・ルーティングパラメータを合体させる
        $params = array_merge($params, $matches);

        return $params;
      }
    }
    return false;
  }

}
/*Routerをインスタンス化するときに、ルーティングを定義する
 *Router->resolve()にPATH_INFOの値を与えるとマッチングした結果を返す
 *返ってきた結果は、指定した動的パラメータ名で取得できる
 * */
?>

「compileRoutes()」
ルーティング定義配列を変換する関数。
実装には、ルーティング定義配列をコンストラクタのパラメータとして受け取り、変換したものを「routes」プロパティとして設定します。
※URLを「/」で区切って、動的パラメータがあるか判定して、加工後再度「/」でつなげて「routes」に格納する。

「resolve()」
ルーティングのマッチングをする関数。
compileRoutes()で変換したルーティング定義配列を利用して、マッチングを行う。
マッチした場合は、コントローラー・アクション・ルーティングパラメータを合体させて「params」として変数を返しています。

/*————————————————————————————————————*/
この辺りで何度も挫折していたのですが、何度も読み返すのと、返される値をひたすらvar_dump()することで実際の挙動がわかってきました。
（まだまだ、正規表現の部分が苦手ですが。）

「パーフェクトPHP」では動的パラメータを「：」で制御していましたが、他のフレームワークでは違う方法で定義されてるかもしれないです。
このあたりは、もっと他のフレームワークのコードを読んで色んなパターンに触れて知識を深めていきたいですね。

フレームワークは勉強すればするほど、便利な要素が詰まっているので、今まで自己流で書いていたコードの改良する部分がどんどん見えてきますね。

フレームワークの使い方を知るだけじゃなくて、フレームワークの後ろでどんな処理が行われているのかをもっと勉強して、いつか自分もオープンソースプロジェクトに参加できるようになりたいと思っている今日この頃です。

今は「パーフェクトPHP」と「FuelPHP」を目下勉強中!!

ご一読頂きまして、ありがとうございました。

【参考資料】
パーフェクトPHP

パーフェクトPHP (PERFECT SERIES 3)

作者: 小川雄大,柄沢聡太郎,橋口誠
出版社/メーカー: 技術評論社
発売日: 2010/11/12
メディア: 大型本
購入: 32人クリック: 1,065回
この商品を含むブログ (60件) を見る

2014-10-07

不動産ビジネスについての話

ブログ

おはようございます。

どんどんブログの更新期間が伸びてしまっていて、継続して更新することの難しさを勝手にヒシヒシと感じています。

今日は台風一過ということで、「秋の晴天!!」って感じの空模様です。

こんな日は、サーフィンにでも行って海でプカプカしていたいものですね。

/*————————————————————————————————————*/
ということで、今日は「不動産ビジネスについて」です。

今、自分のビジネス軸足として置いているのが「IT」と「不動産」です。
（軸足なのに2つあるというのは日本語的におかしいかもですがここは気にせずに。）

その「不動産」についてちょっと考えてみたいと思います。

「不動産」といってもその業務範囲は、

建物販売、建物建築、用地仕入れ、設計、建物管理、不動産仲介、アパート経営、ファンド組成、改修工事、ファシリティーマネジメント、不動産コンサルティングなどなど

と、非常に多岐に渡っています。

その中で、どちらかと言えばみなさんにも馴染みのある「賃貸仲介」について最近よく考えています。

「賃貸仲介」とは簡単に言えば、部屋探しです。

主な会社でいくと、アパマンショップやミニミニ、ピタットハウス、エイブルがパッと出てくる会社です。
若しくは、SUUMOやHOME’Sなどは部屋探しをしたことがある人であれば、一度であれば利用したことがあるのでは二でしょうか。

で、この「賃貸仲介」のビジネスモデルですが、なんとなく頭打ちになっている印象を感じています。

なぜかというと、この「賃貸仲介」で消費者に対して価値を訴求することはできるのは「価格」しかないのが現状に思えるからです。

「仲介手数料半額!!」
「仲介手数料無料!!」
さらには、
「〇〇円キャッシュバック!!」
のような営業手法を行っている仲介会社も存在します。

なぜ、「価格」つまり、仲介手数料を割り引くことしか価値を訴求できないのか考えてみました。

①全ての業者が同一の商品を扱っている（商品に独自性を付与ことができない）
②購買回数が少ない
③業者と消費者での情報の格差が少ない

まず、①の「全ての業者が同一の商品を扱っている」についてです。

不動産業者は99%がREINSという指定流通機構の会員不動産会社が情報を登録しているデータベースを見て物件を探します。
REINSに登録されていない物件情報も勿論あると考えられますが、宅建業法上、媒介契約を結んで募集している物件はREINSに登録しなければならないと取り決められています。
なので、登録されていない物件というのは本当に個人間での取引に限られると考えられます。

つまり、俗にいう「掘り出し物件」というのは、ほぼほぼ無いに等しいと考えた方がいいと思います。
（どうしても探したいなら、マンションを持っている人に直接交渉するほか無いと思います）

なので、大手業者であろうが、今日から始めた不動産業者であろうが取り扱える物件はほぼ同じです。

同じ商品を扱っていても、小売業であれば自ら値付けして販売することができます。
（同じお菓子でも、コンビニとスーパーで値段が違うように。）

しかし、あくまで「仲介」という立場なので実際にそのマンションの部屋を持っている訳ではありません。
なので、業者が値付けすることもできませんし、独自に部屋を改修するなんてこともできません。

となると、「仲介手数料」で他の業者に差をつける以外、他社との違いを見せることが難しくなってきます。

次に②の「購買回数が少ない」についてです。

同じ価格であれば、「サービス」で価値を提供していかなければ、選んでもらえなくなっていきます。

「賃貸仲介」の特性ですが、一度引越ししてしまえば、次に引っ越しをするのは大体2年後くらいです。

サービス業などであれば、なんども「サービス」を見てもらって評価してもらうことも可能です。

でも、「賃貸仲介」では1発目のサービスで評価してもらわなければなりません。

「最初は気付かなかったけど、実はここのサービスを結構良かった」

というのはありません。

しかも、2年後の引っ越しのときにまた同じ人にお願いしようとしても、不動産業界は出入りがかなり激しいので、店に
行ったときにはもう転職したなんてザラにある話です。

同様の理由からリピーターを獲得するのが非常に難しいという部分もあります。

最後に③の「業者と消費者での情報の格差が少ない」についてです。

今は、非常によく知っているお客さんが増えてきたとよく聞きます。

2-3件の業者を回ってきた人なら、もうこちらから提案する物件はほとんどない状態です。

また、扱える物件は増えたと言っても、その物件についてわかるのはデータベース上に載っている情報のみで行ったことも、部屋に入ったことも無い物件を紹介することも増えてきます。

そうなってくると、紹介する側とされる側でそこまで情報に差がなくなってきます。

これがどういうことかと言えば、例えば、パソコンを買うときを例にとってみましょう。

多くの人が店員さんに、

「〇〇したいんですけど、どのパソコンを買えばいいですか」

といったような質問をされると思います。

その時、自分が知っているレベルしか知らない店員か自分よりも詳しい店員さんから買おうと判断すると思います。
（店員のレベル以外全て同じだとして）

前述したように、インターネットが普及している現在であれば

「営業マンよりお客さんの方が詳しい」

という状態も十分にあり得ます。

そんな状態になってしまったら、もう「価格」でしか他業者と差を提供することはできなくなってしまいます。

/*————————————————————————————————————*/
ここまでのことをまとめると、

①みんなが同じ商品を同じ価格で提供していて、どこで買っても商品に差はない。
②そうなると、「サービス」で勝っていかないと行けないが1発勝負で決めないと行けない。
③「サービス」を提供しないといけないけど、お客さんもよく知っていて自分と情報量に差がない。

→だから、仲介手数料を割り引いて「価格」で価値を訴求する。
（「価格」しか価値を訴求できない。）

という感じだと思っている。

これからのビジネスモデルとしては、

①「入り口」の部分は捨てて、その他で利益を上げる
管理会社兼仲介会社であれば、「仲介手数料」が無くても入居後の「賃料収入」で利益を上げる。
フリーミアム的なビジネスモデル

②談合して、「仲介手数料無料・割引」を禁止する
一番最悪

③入居者になにかツールやソフトを提供してその利用料で利益を上げる
またまた、フリーミアム的なビジネスモデル
プリンタとインク、カミソリと替え刃的なモデル

あまり、いいアイデアが出てきていないのが現実。。。

そんな状態だからこそ、逆に「価格」以外の部分で価値を訴求できれば、他社に勝てるし、業界にイノベーションを起こせるかもしれないと思っている。

ご一読頂きまして、ありがとうございました。

※このブログの内容はあくまで個人的見解ですのでご注意ください。

2014-10-03

【PHP】フロントコントローラとルーティングの話その1

プログラミング

おはようございます。

次は、「フロントコントローラとルーティング」について勉強していきたいと思います。
※【パーフェクトPHP】P.207「フロントコントローラと.htaccess」より

フロントコントローラ

フロントコントローラとは、すべてのリクエストを1つのPHPファイルで受け取るようにするものです。
具体的には、

http://hogehoge.com/index.php/login
http://hogehoge.com/index.php/post
http://hogehoge.com/index.php/edit
http://hogehoge.com/index.php/list

などのURLでのアクセスをまずは一旦1つのPHPファイル（フロントコントローラ）にアクセスをするように指定します。（一般的には「index.php」に指定するのが多いみたいです）
そのフロントコントローラで受けた後、適切なアクションで処理を行います。

これらの制御は「.htaccess」ファイルで設定を行います。

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

ここでは、指定されたファイルが存在する場合はそのファイルを読み込み、存在しなければどんなURLでもすべて「index.php」にアクセスするように制御しています。

例えば、「http://hogehoge.com/login」というURLにアクセスされた場合、「login」というファイルが無ければ「http://hogehoge.com/index.php/login」にアクセスした状態と同じとなります。

ベースURLとPATH_INFO

フレームワーク上でURLを扱う上で、大きく分けて2つの情報「ベースURL」と「PATH_INFO」を制御する方法があります。

ベースURL
ベースURLとは、ホスト部分より後ろから、フロントコントローラまでの値を指します。
（ベースURLは一般的な名称ではなく、パーフェクトPHP内での名称です）

PATH_INFO
PATH_INFOはベースURLより後ろの値となります。
※但しGETパラメータ(foo?bar=)の部分は含みません。

<?php
/*知らなかった関数など
 *strpos::文字列内の部分文字列が最初に現れる場所を見つける
 */
class Request{

  public function getBaseUrl(){

    $script_name = $_SERVER['SCRIPT_NAME'];
    $request_uri = $_SERVER['REQUEST_URI'];

    if(0 === strpos($request_uri, $script_name)){
      //フロントコントローラがURLに含まれる場合
      return $script_name;
    }elseif(0 === strpos($request_uri, dirname($script_name))){
      //フロントコントローラが省略されている場合
      return rtrim(dirname($script_name), '/');
    }
    return '';
  }

  public function getPathInfo(){

    $base_url = $this->getBaseUrl();
    $request_uri = $_SERVER['REQUEST_URI'];

    if(false !== ($pos = strpos($request_uri, '?'))){
      //GETパラメータを削除
      $request_uri = substr($request_uri, 0, $pos);
    }

    //REQUEST_URIからベースURLを取り除く
    $path_info = (string)substr($request_uri, strlen($base_url));

    return $path_info;
  }
}
?>

今日は、「フロントコントローラ」・「ベースURL」・「PATH_INFO」について勉強していきました。
これらによって、どのURLにアクセスされたのかが自動的に判定されます。
次は、「ベースURL」と「PATH_INFO」を利用してルーティングについて定義していきたいと思います。

/*————————————————————————————————————*/
まだ、フレームワークを使った開発の経験は無いですが、この「フロントコントローラ」を利用してアクセスされたURLでルーティングし、対応するコントローラーとアクションメソッドを呼び出すというのが一般的のようです。
※まだ、このパーフェクトPHP内でのフレームワークと勉強中のfuelPHPしか知らない身ですが。。。

おそらく、このルーティングの部分でつまづく人が多いのではないかなと思っています。
（自分がつまづいていた部分であるということもありますが。）

でも、このルーティングの部分を活用すればかなりロジック部とデザイン部の分離ができるし、長々としたURL（http://hogehoge.com/?aid=1&bid=2&cid=3）からも解放されてスッキリ書くことができるようになります。

※http://hogehoge.comは便宜上のテキトーなアドレスですので、アクセス先については全く知らないところですのでご注意ください。

ご一読頂きまして、ありがとうございました。

参考記事
パーフェクトPHP

パーフェクトPHP (PERFECT SERIES 3)

作者: 小川雄大,柄沢聡太郎,橋口誠
出版社/メーカー: 技術評論社
発売日: 2010/11/12
メディア: 大型本
購入: 32人クリック: 1,065回
この商品を含むブログ (60件) を見る

2014-09-30

【PHP】オートロードについての話

プログラミング

おはようございます。

昨日の宣言通り、「パーフェクトPHP】の内容に沿って勉強していきたいと思います。

P.198【フレームワークによる効率的な開発】から始めていきます。

フレームワークを使うにあたって、フレームワークがどんな設計でどんな動きを知ることは非常に大切です。
中身が分からなければ、拡張性もないし、リスクについても把握することができません。
（分からないのはしょうがない部分があると思いますが、分かろうとしないのはスタートライン以前の問題ですね）

/*————————————————————————————————————*/
ということで、今日は「オートロード」についてです。

オートロード

基本的にクラスを使いたいときは、必要に応じて「require_once」などを用いてクラスを記述しているファイルを読み込みを行うと思います。

しかし、毎回毎回読み込み処理を書くのもなかなかめんどくさい部分があります。
また、読み込みを忘れて関数等を使ったときに「未定義の関数です」みたいなエラーが出ることもしばしば。。。

そこで、登場するのがオートロードという仕組みです。

内容としては、

「クラスを呼び出し際にそのクラスがPHP上に読み込まれていない場合、自動的にファイルの読み込みを行うことができるようになる」

というものです。

実装されている機能は、

①PHPにオートローダクラスを登録する
②オートロードが実行された際にクラスファイルを読み込む

という機能が実装されています。

注意点としては、クラスファイルを呼び出す際にクラス名をもとに該当するファイルのパスを特定しなければならないため、ファイルの配置ディレクトリやファイル名について明確なルールを設定しなければなりません。

<?php
/*知らなかった関数など
 *spl_autoload_register()::未定義のクラスやインターフェイスを使おうとすると、自動的に呼び出す（オートローディングする）ようにする組み込み関数
 *is_readable::指定したファイル名が読み込み可能か確認
 */
class ClassLoader{

  protected $dirs;

  //オートローダクラスを登録する処理
  public function register(){
    spl_autoload_register(array($this, 'loadClass'));
  }

  //読み込むディレクトリを登録する処理
  public function registerDir($dir){
    $this->dirs[] = $dir;
  }

  //オートロード時にPHPから自動的に呼び出され、クラスファイルを読み込みを行う処理
  public function loadClass($class){
    foreach($this->dirs as $dir){
      $file = $dir.'/'.$class.'.php';
      if(is_readable($file)){
        require $file;

        return;
      }
    }
  }
}
?>

オートロードクラスを利用するためにはこんな感じでプログラムを書きます。

<?php
$loader = new ClassLoader();
$loader->registerDir(dirname(__FILE__).'/hogehoge');//hogehogeはクラスを置いているディレクトリを指定
$loader->register();//オートロードに登録
?>

「registerDir()」でオートロード先のディレクトリを設定する。（複数ディレクトリ可能）
「register()」でオートロードに登録。

これで、毎回読み込みのコードを書かなくても、自動的にクラスが読み込まれるようになります。

オートロードには「__autoload() 」があるのですが、こちらは1度しか定義できないという問題があります。
そこで、複数の関数を定義できる「spl_autoload_register()」を利用しています。

これで、require_once地獄からおさらばすることができます!!

※このブログではパーフェクトPHPの内容を引用・参考にしています。

【参考記事】
パーフェクトPHP

パーフェクトPHP (PERFECT SERIES 3)

作者: 小川雄大,柄沢聡太郎,橋口誠
出版社/メーカー: 技術評論社
発売日: 2010/11/12
メディア: 大型本
購入: 32人クリック: 1,065回
この商品を含むブログ (60件) を見る

PHPでクラスをspl_autoload_registerを使ってオートロードする - バカンス駆動開発