ためすう

目的

個人の git リポジトリをチームで使うリポジトリへ移すことが必要になりました。

方法

$ git clone --mirror <SOURCE_REPOSITORY_URL>
$ cd <REPOSITORY>
$ git push --mirror <DESTINATION_REPOSITORY_URL>

ちょっと補足

$ git clone --help

>   --mirror
>       Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the
>       source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec
>       configuration such that all these refs are overwritten by a git remote update in the target repository.

$ git push --help

>   --mirror
>       Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/,
>       refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end,
>       locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the
>       default if the configuration option remote.<remote>.mirror is set.

参考URL

• Gitレポジトリを移行する方法 - Qiita

目的

bower を使って、 c3 のインストールを行いました。

bower とは

フロントエンド用パッケージ管理ツールであり、依存関係も管理してくれるものです。

c3 とは

d3 を元にグラフを扱いやすくしたものです。

インストール手順

$ bower install c3

bower_components 以下に d3、c3 がインストールされました。

今後

bower_components 以下のファイルをそのまま呼び出しても使えますが

gulp などのビルド自動化ツールを使って、bower_components を呼び出すようにしてみたいと思います。

参考

• 今時、bower、使ってます。 - Qiita

• C3.js | D3-based reusable chart library

目的

python でファイルを実行するときに、module の場所を見つける必要がありました。

解決策

#### 確認環境

$ python himejima$ python –version Python 3.6.2 :: Anaconda custom (64-bit)

test.py

import datetime import json

print(datetime.file) print(json.file)

出力結果

/anaconda3/lib/python3.6/datetime.py /anaconda3/lib/python3.6/json/init.py ```

※ 環境により異なります。

参考

• Python Tips：ライブラリ・モジュールの場所を調べたい - Life with Python

本記事の範囲

本記事では、サービスロケータ を記事の範囲とします。 DI 、DI コンテナについては別記事で書いています。

サービスロケータとは

「サービスロケータ」とは、サービス（オブジェクト）の取得を抽象化するデザインパターンです。

サービスロケータの例

<?php

require_once './vendor/autoload.php';

use Pimple\Container;

class Client
{
    private $container;

    public function __construct(Container $container)
    {
        $this->container = $container;
    }

    public function log($messgae)
    {
        $this->container['service_interface']->log();
    }
}

interface ServiceInterface
{
    public function log();
}

class Service implements ServiceInterface
{
    public function log($message)
    {
		echo $message . "\n";
    }
}

// Client呼び出し

$container = new Container();

$container['service_interface'] = function ($container) {
    $service = new Service();
    return $service;
};

$container['client'] = function ($container) {
    $client = new Client($container);
    return $client;
};

$client = $container['client'];
$client->log('ssssss');

ここでは、$container がサービスロケータとなります。

依存するものが DIとサービスロケータで異なります。

DIの場合

• ServiceInterface を実装しているオブジェクト

サービスロケータの場合

• DIコンテナ (Pimple)
• $this->container['service_interface']

これによって、Client クラスが DIコンテナ (Pimple)の依存が強くなり、Client を利用するときは DIコンテナも必要とされるようになってしまいました。

DIコンテナについてまず知っておくべきなのは、DIコンテナを使ってさえいれば「依存性の注入」ができるわけではないってことだ。 DIコンテナは、依存性の注入を実現するための便利な道具として使える。 でも、使い方をミスって、サービスロケーションというアンチパターンを作ってしまっていることも多い。 DIコンテナをサービスロケーターとしてクラスに組み込んでしまうと、 依存関係を別の場所に移そうとしていたはずなのに、よりきつい依存関係を作り込むことになる。 おまけにそのコードはわかりにくくなってしまうし、テストもしづらくなる。

結局のところ、サービスロケータはアンチパターンのようです。

参考

• やはりあなた方のDependency Injectionはまちがっている。 — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something
• PHP: The Right Way

本記事の範囲

本記事では、DI コンテナについて書きます。 サービスロケータは別記事で。

DI コンテナとは

DIを楽にしたり、オブジェクト生成のコードをまとめるための便利なツール

DI コンテナ の例

Main.php ( 1 ファイルに全部まとめました)

<?php

require_once './vendor/autoload.php';

use Pimple\Container;

class Service
{
    public function log($message)
    {
        echo $message . "\n";
    }
}

class Client
{
    private $service;

    public function __construct(Service $service)
    {
        $this->service = $service;
    }

    public function log($message)
    {
        $this->service->log($message);
    }
}

$container = new Container();

$container['service_interface'] = function ($container) {
    $service = new Service();
    return $service;
};

$container['client'] = function ($container) {
    $client = new Client($container['service_interface']);
    return $client;
};

$client = $container['client'];
$client->log('ssssss');

今回は Pimple を使用して、依存性について定義しました。

これによって、呼び出し元で依存性の注入を直接記述しなくても良くなりました。

（Client に渡すクラスが インターフェースになったら、一工夫が必要そうです。）

参考

• 依存性の注入 - Wikipedia
• やはりあなた方のDependency Injectionはまちがっている。 — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something

本記事の範囲

本記事では、DI までを記事の範囲とします。 DI コンテナ、サービスロケータは別記事で書きます。

DI とは

依存性の注入（いそんせいのちゅうにゅう、英: Dependency injection）とは、コンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである。英語の頭文字からDIと略される。

依存性の注入の方法

注入の方法は下記のような手法がある。

• インタフェース注入
• setter注入
• コンストラクタ注入

DI の例

Main.php

<?php

require_once './LoggerInterface.php';
require_once './ExampleLogger.php';
require_once './DummyLogger.php';
require_once './Application.php';

// $logger = new ExampleLogger();
$logger = new DummyLogger();
$app = new Application($logger);
$app->error('エラーが発生');

Application.php

<?php

class Application
{
    protected $logger;

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;
    }

    public function error($message)
    {
        $this->logger->log($message);
    }
}

LoggerInterface.php

<?php
interface LoggerInterface
{
    public function log($log);
}

ExampleLogger.php

<?php

class ExampleLogger implements LoggerInterface
{
    public function log($log)
    {
        echo $log . "\n";
        return $this;
    }
}

DummyLogger.php

<?php

class DummyLogger implements LoggerInterface
{
    public function log($log)
    {
        return $this;
    }
}

DI の特徴

1. オブジェクトの生成と使用が分離されている
2. クライアントがサービスを呼ぶのではなく、サービスが外部からクライアントに注入される。つまり、制御が反転している

また、この例では、 - ExampleLogger、DummyLogger の実装が完了していなくても、Application の実装ができます。 - LoggerInterface を実装した新しいクラスに切り替えるとき、呼び出し元の変更だけでokです。

参考

• 依存性の注入 - Wikipedia
• PHPで作って覚えるDI Container - その1 - DI is 何 - Qiita
• やはりあなた方のDependency Injectionはまちがっている。 — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something

本記事の概要

参考URLに良いまとめがあったので、自分用のメモとして抜粋させて頂きました。

オブジェクト指向の特徴

• 継承
• カプセル化
• ポリモーフィズム (多態性)

継承

• 継承の本質はインターフェイスです。

• 継承は機能を受け継ぐためのものではありません。継承の本質は、犬や猫を「動物」という抽象概念としてまとめ上げられるインターフェイスなのです。

• 継承は親クラスの機能を受け継ぎますが、これは開発効率を上げるための優しさ的仕様であり、継承の本質はインターフェイスなのです。

継承を親クラスの機能を受け継ぐ目的で使って、失敗した記憶があります。

継承をインターフェースとして捉えて、抽象概念の抽出という目的で使うのが大切なようです。

カプセル化

• カプセル化は、外から見てそのものが複雑でない状態を作るということ

• クラスの役割は一つにする

これはクラスの利用者とクラスとの接点で、意識するべきところを理解しやすくするためかなと考えています。

ポリモーフィズム (多態性)

• ポリモーフィズムはそのインターフェイス（抽象）に対してプログラムするということです

• ここで衝撃的な事実をお伝えしましょう！実は「new」は具象です！ですから、ポリモーフィズムを意識する上でnewの扱いには最大限の注意を払う必要があります。

ポリモーフィズムは自分の中でしっくり来ていなかったのですが、腑に落ちた気がします。

デザインパターンでオブジェクトの生成と利用を分けているものがある理由もそこにあるのかもしれません。

（Factory Method パターンとか）

まとめ

自信を持って、クラス設計がしていけるように上記を頭に入れてやっていきたいと思います。

参考

• オブジェクト指向と10年戦ってわかったこと - Qiita

目的

Pimple という DIコンテナ（Dependency Injection Container）を使いたかったため、

手元の Mac にて composer 経由でインストールします。

解決策

1. composer をインストール

$ curl -sS https://getcomposer.org/installer | php

2. path の設定

$ mv composer.phar /usr/local/bin/composer

3. Pimple を composer 経由でインストール

$ composer require pimple/pimple ~3.0

4. ライブラリを autoload する

例えば Pimple を利用したい場合は、下記のようにして autoload します。

<?php
require_once './vendor/autoload.php';

use Pimple\Container;

$container = new Container();

参考URL

• https://qiita.com/kakijin/items/02364adacf36410f449e
• https://pimple.symfony.com/

目的

php で date関数を使用するときに少し嵌るところがあったので、

メモとして残しておきます。

日付の計算で1ヶ月後の末日を求めるときに 2ヶ月後の末日を求めてしまうという問題に遭遇しました。

解決策

事象の確認

sample.php

<?php

date_default_timezone_set('Asia/Tokyo');
$time = '2017/10/31';

echo date('Y-m-t', strtotime('+1 month ' . $time)) . "\n";

下記を実行する

$ php sample.php

結果

2017-12-01 00:00:00

解決策

月の1日から末日を計算する

<?php

date_default_timezone_set('Asia/Tokyo');
$time = '2017/10/01';

echo date('Y-m-t', strtotime('+1 month ' . $time)) . "\n";

結果

2017-11-30

目的

日本語ファイルを git で管理しているのですが、

ステータスを確認したときに、日本語がきちんと表示されていなくてファイルが判別できなかったので、

日本語で表示する方法がないかを調べました。

解決策

$ git config --local core.quotepath false

おまけ

.git/config と ~/.gitconfig の読み込み順番

1. ~/.gitconfig
2. .git/config (リポジトリの中)

参考

• http://qiita.com/kozo/items/08dc2b86ae3ba3f282c3
• http://dev.classmethod.jp/tool/git/git-avoid-illegal-charactor-tips/