読者です 読者をやめる 読者になる 読者になる

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利用する際にはモデルを作るだけでおk

もちろん、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

設立当初

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

2005

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

2010 git スタート

git移行のハマりどころ

git-dailyを利用している


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

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

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

マジカルsvnとは?

ブランチ戦略

理想のフローとは?

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

チケット駆動開発

svn tiddを妨げてくる

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

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

メリット

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

tiddをやりやすい

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

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

フロントエンドの選定

web UI

管理が出来る

メンテナンス

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

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

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

github-flowが理想

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

継続的に運用する

gitoliteのミラーリング


CROOZ株式会社 梅田 昌太

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

技術的負債

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

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

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があるので 色んなことが出来るみたいです。 私も何かに繋ぎこんでみたいですねw

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

下記のようなパターンがあれば 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さん、ご情報ありがとうございます。