PHPでの可読性について調べてみたらPSRに辿り着いた( ･`ω･´)

コーディング規約 php

PSRとは?

Proposing a Standards Recommendation (標準勧告提案)
PSR-0

オートロードの為のファイル名とクラス名の規約

PSR-1

共有コードの高レベルな連携性を目的にした規約

PSR-2

標準化されたコードを目指すスタイルガイド

に分かれているそうです。

PHP Framework Interop Group が策定したコーディング規約みたいです。

今までは、PEAR , Zend , Symfony , 俺俺
など様々あったようですが
PHP Framework Interop Groupには
それらの有名な(俺俺は除く)メンバーの方々が参加されているようですので
良い感じにまとまってるみたいです。

最近のPHP系のFrameworkのコーディング規約と
同じような感じでしたので
親しみやすいため、率先して参考にしていきたいと思います。

PSR0で名前空間についてふれていますが、
PHPは基本的にグローバルクラスを作成しますので
名前には注意が必要ですね。
しっかり規約を読んできます。

私的に気に入ったポイントは

クラスの開き括弧は次の行に記述しなければなりません。
また閉じ括弧は本文最後の次の行に記述しなければなりません。
class Sample {

}

じゃなくて

class Sample
{

}
メソッドの開き括弧は次の行に記述しなければなりません。
また閉じ括弧は本文最後の次の行に記述しなければなりません。
public function sample() {

}

じゃなくて

punlic function sample()
{

}

でも if文は

if ($a === $b) {
    bar();
} elseif ($a > $b) {
    $foo->bar($arg1);
} else {
    BazClass::bar($arg2, $arg3);
}

と書くようです。

最近はどこかのドキュメントで見た(幻覚かも、、)

if ($a == $b)
{
    bar();
}

みたいな書き方をしてしまっていたので
注意したいと思います。

括弧の前後にスペースを入れないもいいですね。

class ClassName
{
    public function foorBarBaz($arg1, $arg2, $arg3 = [])
    {
    
    }
}

入れたほうが見やすいという意見を見かけますが、
私は無駄に入れたくないです。

Template Metbodを調べてみた( ･`ω･´)

デザインパターン php

Template Metbod とは？

クラスの振る舞いに注目したパターンで、
サブクラスで具体的な振る舞いを
決定させることを目的としているみたいです。

ポイント

継承と似ているようですが、
「処理の一部分をサブクラスで実装する」
ところがポイントのようです。

メリット

共通な処理をまとめることが出来る

共通の処理を親クラスにまとめることで、
変更があった場合にも親クラスの修正だけで済む

サブクラスにより、具体的な処理内容を変えることが出来る

親クラスの抽象メソッドがサブクラスに実装されますので、
共通ではない処理をサブクラスに書き、
処理内容を変更することが出来ます。
親クラスのメソッドを他のサブクラスと共有して利用出来ますね。

AbstractDisplay.php

AbstractDisplayが親クラスファイルであり
abstractクラスで定義しています。

<?php

abstract class AbstractDisplay
{

    private $data;
    
    public function __construct($data)
    {
        if(!is_array($data))
        {
            $data = array($data);
        }
        $this->data = $data;
    }
    
    public function display()
    {
        $this->displayHeader();
        $this->displayBody();
        $this->displayFooter();
    }
    
    public function getData()
    {
        return $this->data;
    }
    
    protected abstract function displayHeader();
    
    protected abstract function displayBody();
    
    protected abstract function displayFooter();
}
?>
ListDisplay.php
<?php
require_once 'AbstractDisplay.php';

class ListDisplay extends AbstractDisplay
{
    protected function displayHeader()
    {
        echo '<dl>';
    }
    
    protected function displayBody()
    {
        foreach ($this->getData() as $key => $value)
        {
            echo '<dt>Item ' . $key . '</dt>';
            echo '<dd>' . $value . '</dd>';
        }
    }
    
    protected function displayFooter()
    {
        echo '</dl>';
    }
}
?>
TableDisplay.php
<?php
require_once 'AbstractDisplay.php';

class TableDisplay extends AbstractDisplay
{
    protected function displayHeader()
    {
        echo '<table border="1" cellpadding="2" cellspacing="2">';
    }
    
    protected function displayBody()
    {
        foreach ($this->getData() as $key => $value)
        {
            echo '<tr>';
            echo '<th>' . $key . '</th>';
            echo '<td>' . $value . '</td>';
            echo '</tr>';
        }
    }
    
    protected function displayFooter()
    {
        echo '</table>';
    }
}
?>
template_method_client.php
<?php
require_once 'ListDisplay.php';
require_once 'TableDisplay.php';

    $data = array('Design Pattern',
                  'Gang of Four',
                  'Template Method 1',
                  'Template Method 2');

    $display1 = new ListDisplay($data);
    $display2 = new TableDisplay($data);

    $display1->display();

    echo '<br>';

    $display2->display();
?>

Template Methodパターンは「継承」を利用しているパターンです。
親クラスでは抽象メソッドとして定義されているため、
サブクラスでは必ず実装を行う必要があります。
つまり、抽象化することでメソッドの実装が保証されることになります。

サブクラスは親クラスを継承してるので、
全て親クラスの型とみることが出来るようです。
つまりPHPは自動で型を判定するので事故防止？
または保証されるということですかね？

リスコフの置換原則という原則で定められているようです。
(親クラスとサブクラスを定義するとき、
サブクラスは親クラスを置き換えることが出来なければならない)
置き換えることにより、サブクラスが利用や変更した際にも
親クラスとサブクラスの型は同義となるようです。

また、Template Methodパターンでは
親クラスがサブクラスのメソッドを呼び出す「制御構造の反転」
という特徴を持つパターンのようです。

DNSの動作確認してみた( ･`ω･´)

DNS

なぜ確認するのか？

登録されているDNSサーバを確認してないために、
かなり痛い目にあったので、
(セカンダリ設定が、、)
確認方法を自分なりにまとめました。

用意するもの

確認する前に、
登録するDNS(プライマリ、セカンダリ)を
書類から探しましょう＼(^o^)／

動作環境

Mac 10.8 ターミナルでやります。

やってみたこと

今回は、nslookup を利用します。

nslookup はDNSの正引き、逆引きチェックで
利用すると思います。

nslookup ドメイン名

上記のコマンドをターミナルで実行しますと

Server:     利用しているDNSサーバ名
Address:    利用しているDNSサーバのipアドレス

Non-authoritative answer:
Name:   www.google.com
Address: 173.194.38.116
Name:   www.google.com
Address: 173.194.38.112
Name:   www.google.com
Address: 173.194.38.114
Name:   www.google.com
Address: 173.194.38.113
Name:   www.google.com
Address: 173.194.38.115

上記は参考に www.google.com で nslookupしてみた結果です。
普通は Non-authoritative answer: の下に一つしか出ないと思います。
(利用している環境によって変わるかと、AWSとかは違うかも)

本題のDNSサーバの確認ですが、

nslookup ドメイン名 確認したいDNSドメイン名

上記のコマンドで
確認したいDNSサーバがちゃんと動作しているか
確認することが出来ます。

正

ドメイン名 canonical name = ドメイン名  
Name:   ドメイン名  
Address: ipアドレス

確認したDNSサーバが正しい動作をしていれば
上記のような結果が得られます。

誤

    ** server can't find ドメイン名.SSG5-Serial: REFUSED

確認したDNSサーバが正しい動作(レコードが登録されていない)など
設定に誤りがあれば上記のようなエラーが表示されます。

教訓

今回の教訓をへて、
当たり前な話かも知れませんが
納品されたサーバで
上記のような確認フローを追加する
もしくは
DNSチェックツール(現在、探してます)
を利用する必要があると思いました。

同時に起こったトラブルについて

別件で利用しているDNSサービスのドメイン名が変更されていて、
ドメイン名の管理は別のサービスを利用していたため、
ドメイン名を管理しているサービスのレジストリを
更新する必要がありました。

新しいDNS情報が浸透するまでに
最大(3日)かかるようで(環境によると思います)
その際にも nslookup で確認すればいいと思います。

nslookup ドメイン名 8.8.8.8

上記の 8.8.8.8 は
googleのpublic DNSサービスです。
そこを指定して確認すれば
結構、浸透してると判断出来るのでは？
(私はそんな確認方法にしてます)

私がよく利用するコマンド

ping ドメイン名 or ipアドレス

パケットを送信して、サーバから返答があるか確認します。 (死活監視)

traceroute ドメイン名 or ipアドレス

コマンドを実行したPCから、ドメイン名までの ネットワークルート経路を教えてくれます。 各ルータが表示され、レスポンスも教えてくれるので 何処がボトルネックか判断材料になります。

未来の私の参考になれ
　　　ﾟﾟ･+。
　　 ｜　　　ﾟ｡
　　｡∩∧∧　　
　 + (･ω･`) +ﾟ
　 ｡ヽ　　つﾟ
　　ﾞ･+｡･ﾟ⊃　+ﾟ
　　 ☆ ∪　 ｡ﾟ
　　　ﾞ･+｡*･ﾟ

MacでLaravel4動かしてみた(｀・ω・´)

Laravel

f:id:greenwakame:20130411124215p:plain

公式URL : http://four.laravel.com/#install-composer

公式からLaravel4をダウンロード

ダウンロードしたフォルダ内に移動

curl -s http://getcomposer.org/installer | php

error message

` Some settings on your machine make Composer unable to work properly.
Make sure that you fix the issues listed below and run this script again

The detect_unicode setting must be disabled.
Add the following to the end of your php.ini
detect_unicode = Off

A php.ini file does not exist. You will have to create one.
If you can not modify the ini file, you can also run php -d option=value to modify ini values on the fly. You can use -d multiple times.`

error message end

上記のエラーは
php.ini ないよ、作成したら、detect_unicode = Off 追記して
ってことみたいです。

sudo cp /etc/php.ini.default /etc/php.ini

sduo chmod 777 /etc/php.ini

sudo vim /etc/php.ini

detect_unicode = Off 追記

curl -s http://getcomposer.org/installer | php
php composer.phar install

これで「Hello World」までいけました。

依存環境は composer.json に記述されているようです。
追加でパッケージなどを composer.phar でダウンロードするには
composer.json に記述すればいいのかな？

アプリケーション単位ではなく
グローバルに composer.phar を使いたい場合は
/usr/local/bin/ に composer.phar を移動させ
PATHを通せばいいと思います。

Laravel 3.2.11 試してみた( ･`ω･´)

Laravel

f:id:greenwakame:20130408112901j:plain

最新バージョンは4系みたいなんですが
触り始めた時が3系だったので
今回は3系のメモ程度に、、

素敵なフレームワークだと思うのですが
日本語の情報が少ないような？

でも、公式ドキュメントを翻訳されていたり

Web職人のためのフレームワーク

大変、参考にさせて頂いているサイト

WinRoad徒然草

もありますので、
問題ないと思います。

もっと日本でも流行るといいなーと
期待を込めて
私的に素敵なポイントなどを書いていきます。

バリデーションが豊富

デフォルトでお問い合わせフォームで利用するであろう バリデーションは揃っていると思います。

EloquentORM利用する際にはモデルを作るだけでおｋ

もちろん、Laravelの規約内だったらのお話です。
それ以外でしたら指定すれば問題ありません。
最初から厳密に記述しろってよりは楽だと思います。

フィルター機能が豊富
laravel/application/routes.php

上記のファイルに色々な指定が出来るので
コントローラーに処理書かなくていいので気に入りました。

このアプリケーションの際は、
このアクセス(get , post など)の際は、
名前などを指定してフィルターも出来るようです。

DBからデータを取得する際に
条件指定(whereなど)をする際にはresults
で戻ってくるのですが
条件指定なしの場合はresultsではなく
オブジェクトで戻ってきました。

メール機能が3系まではデフォルトではないので
Bundle版を利用する必要があります。
4系になりますとデフォルトで用意されているようです。

php5.3以降のフレームワークなので
何かの案件で実装してみたいです＼(^o^)／php5.2以下ばっかだよ、、案件

第5回テックヒルズ　『Go to Git !　～さらばSVN～』に行って来ました＼(^o^)／

勉強会

勉強会あるあるですが、、

すげーwifi、アクセスポイントがありすぎ(；・∀・)

私は会社のイーモバを借りて参加したのですが、
初期設定の人が多数いまして
アクセスポイント名で焦りました＼(^o^)／GP04多すぎ、、

かなり広いスペースだけど、人数(400名以上)も凄いからパンパン

GREE株式会社　大場 光一郎 さん

「本当のレガシーの話をしよう」

SCMの歴史からのGitへの話しがメインみたいです。

sccs がバージョン管理の始まり(初期Unix)
↓
rcs 商用unixに搭載されていた(バイナリをサポートしている)
ロックベースのバージョン管理 アンロックし忘れるなど、プロジェクトには向かないかも？
↓
cvs 複数ファイルのバージョン管理 時間や場所を超えて開発プロジェクトが可能になった
↓
subversion 中央リポジトリ ↓
git 分散リポジトリに変化した ブランチを利用した並行開発が可能になったことが大きい プロジェクト単位ではなく、開発者、単位になったのがいい

グリーのscm

設立当初

社長が分散管理していた！ やっぱり凄い人なんですねｗ

2005

人が最新のソースコードを判断して subversionにコミットしていた。 神業ですねｗ

2010 git スタート

git移行のハマりどころ

git-dailyを利用している

株式会社ドリコム　大仲 能史 さん

「マジカルsvnとキュアgit」

スライド資料を貼らせて頂きます。

マジカルsvnとは？

ブランチ戦略

理想のフローとは？

purll Requestの文化が重要みたいです。

チケット駆動開発

svn tiddを妨げてくる

svnは重い やりたい開発フローに間に合わない。 私はsvn未経験なんですが 動作がもっさりしてるんですかね^^;

ツールが文化を規定する。 これは私も心底、そう思います。 つまり何でも使わない嫌いは良くないですよね。 ちょっと違うかな？ｗ

メリット

十分に早いリポジトリブラウザ やはり日常的に使用するには 速さはじゅうようですよね。

tiddをやりやすい

メンバーの意識改革につながった。

外に出て行くようになる github

フロントエンドの選定

web UI

管理が出来る

メンテナンス

柔軟に移行するための戦略

中央リポジトリだけ用意する

クロスコミットするようにしたそうです。

github-flowが理想

お金がないので gitlab お金は降って湧いてこないですもんね(/_;)

継続的に運用する

gitoliteのミラーリング

CROOZ株式会社　梅田 昌太

「Gitと出会って人生変わった」

技術的負債

svn で開発用と本番用がある 手動diff作業

バージョン管理がないから、ソースコードがコメントだらけ。 つまりバージョン管理されているコードには コメントはないってことなんでしょうか？(私の疑問ですｗ)

yakuがりな日々

rsyncをやめた

CIを導入

gitと出会って人生変わった

リビジョン指定、ワロス

勝手に作る。 ある程度、動くものを作る。 やっぱりエンジニアじゃない人にも 賛同を得るためには 動くものを見せてイメージして貰うことが 重要みたいです。 私も頑張らなくては＼(^o^)／

株式会社モバイルファクトリー　阿部 正浩 さん

「Git移行の3つの山」

動機、実行、その後

Gitを導入する際に一番納得できた理由は 速さ

一人好きな(git)が 社内で導入するために 必要なことを全てこなして下さったそうです。 パワープレイも重要みたいです。

マージが怖くなくなったそうです。

KLab株式会社　於保 俊 さん ＆ 牧内 大輔 さん

「メタにgithubを使う」

metahub for github

blogのURLを貼らせて頂きます。 http://young.blog.jp.klab.com/archives/22604048.html

svn → bazzar → github

リポジトリが分散していて大変だったみたいです。

一ヶ月 20リポジトリ増えてきた。

全案件、ちゃんとレビューしてね、といわれる。

似たりよったりのリポジトリがいっぱい。

pullRequestを監視

gtihubにはAPIがあるので 色んなことが出来るみたいです。 私も何かに繋ぎこんでみたいですねｗ

httpsでアクセスするだけで データを取得出来るみたいです。
素晴らしいｗ

下記のようなパターンがあれば SQLインジェクションされる可能性があるので チェックするなどの監視をしているようです。
例
where の後に 変数

パネルディスカッション

「Git運用の理想のカタチ」

机がない席だっため力尽きました＼(^o^)／主に足が、、

私的にはやはり会社でGitを導入するには
まず自分が導入し
少しずつ仲間？を増やしていくしかないですね(；・∀・)
そもそもバージョン管理すらしてないので
けわしい道程になりそうです＼(^o^)／

とりま、GitLabとRedmineを
こっそり社内サーバに構築(仮想したの)で
私的運用しながら頑張ります(・∀・)

FuelPHPでoilが動かない＼(^o^)／

FuelPHP

全然、oilを利用していなかったのですが(；・∀・)
どう考えても利用したほうが効率がいいので
/usr/bin/が汚れる？
インスコしたる、、あれ？エラー？
メモとして残しておきます／(^o^)＼

エラーメッセージ

Fatal error: Uncaught exception 'Fuel\Core\PhpErrorException' with message 'date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead' in

vim fuel/app/config/config.php

'default_timezone' => 'Asia/Tokyo',

上記を追記する。

エラーメッセージ

This is not a valid Fuel installation so Oil is a bit lost

CHANGELOG.md README.md build.xml fuel public CONTRIBUTING.md TESTING.md docs oil

oilがあるディレクトリで実行すれば動きます。
* createコマンド以外はoilがなければ動作しないようです。
kenji_sさん、ご情報ありがとうございます。