2016-09-03

株はじめました

あるスマホゲームの出来に感動し、株を買おうと思い立ちました。

株デビューです。

先々週にネットの証券口座（楽天証券）を開き、

その会社の銘柄（…自分で使うととても新鮮な響き）を買いました。

貯金すべてを突っ込むのは怖すぎるので、少額からためしてみることに。

株を買う行為に対して、

・うさんくさい金儲けの手段：トレーダーが不正や仕手をしまくっていて素人には無理！

・ギャンブル：芸能人が破産！

のイメージを持ったりしている人もいますが、

会社を応援するという意味で買ってみるのもいいんじゃないかなーとも思ったりします（なのでFXには興味がないです）。

それで生活をしていくんだと思わない限りは、

趣味の範囲で留められるようにした方がいいと思います。

ハマると怖いイメージ…。あくまで、あまったお金の範囲で。

ついでに、日本経済とかに少しは詳しくなれたらいいなと期待してます。

2016-06-07

PHPのメソッド（コンストラクタ）引数のタイプヒンティングから型情報（クラス）を取得する（ボツ案）

PHP

DIコンテナを使用するプロジェクトについて、以下のような場合について考えてみる。

①リポジトリ：DBのテーブルと１対１で結びつき、CRUDを提供する

②サービス：ビジネスロジックを記述する。内部でリポジトリを使用し、コンストラクタから注入されるものとする

ざっくり以下のようなコードになる。

<?php

class PostRepository {
  public function create() { ~ }
  // 略
}


class PostService {
  protected $postRepository;

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

  public function publish() {
    // 何かする
  }
}

$container['postRepository'] = $container->factory(function ($c) {
  return new PostRepository();
});

$container['postService'] = $container->factory(function ($c) {
  return new PostService($c['postRepository']);
});

このとき、PostServiceがPostRepositoryに加え、UserRepositoryも必要になったする。

その場合、コンストラクタの引数に追加する必要がある。

class PostService {
  protected $postRepository;
  protected $userRepository; # 追加

  public function __construct($postRepository, $userRepository) { 
    $this->postRepository = $postRepository;
    $this->userRepository = $userRepository;
  }

// 略

$container['postService'] = $container->factory(function ($c) {
  return new PostService($c['postRepository'], $c['userRepository']);
});

このとき、リポジトリを追加するのがとてもメンドーなのでやめたい。

これを回避する方法がないか考えてみたところ、

コンストラクタの引数にタイプヒンティングを書いておき、型情報からコンテナを取得できれば、対応するクラスをDIコンテナから引っ張って自動でセットできないだろうか、と考えた。

例えば、DIの生成部分で以下のように書いておき、

$container['postService'] = $container->factory(function ($c) {
  $service = new PostService();

   // コンストラクタの引数のタイプヒンティングを解析し、postRepositoryとuserRepositoryを自動でコンテナから取得＆セット
  $service->inject($c);

  return $service;
});

コンストラクタでは、デフォルトでnullにしておく。あとから注入する。

class PostService {
  
  public function __construct(PostRepository $postRepository, UserRepository $userRepository) { 
    $this->postRepository = $postRepository;
    $this->userRepository = $userRepository;
  }

  public function inject( $container )
    {
        $ref_class = new ReflectionClass($this);
        $ref_constructor = $ref_class->getMethod('__construct');

        foreach ($ref_constructor->getParameters() as $regl_param) {

            // 引数（typehint）の型（クラス名）
            $refl_args_class = $regl_param->getClass();

            // typehint未指定
            if (!$refl_args_class) {
                echo "typehintが未指定です。";
                continue;
            }

            // クラス名
            $class_name = $refl_args_class->getName();

            // セット先のプロパティ
            $property_name = $regl_param->getName();

            if (!property_exists($this, $property_name)) {
                echo "プロパティが見つかりませんでした。";
                continue;
            }

            if (!isset($container[$class_name])) {
                echo "コンテナにインスタンスが入ってないよ。";
                continue;
            }

            // セットぅ！
            $this->$property_name = $container[$class_name];
        }
    }
}

勢いでやってみたものの、以下の懸念が…。

懸念１　タイプヒンティングに実装クラス書いてるけど、普通はインタフェースを書かないとだよね… 懸念２　クラス名でコンテナセットしたら同じクラスのインスタンスを複数セットできないのては…

上記の案はボツになりました。他にいい方法があったら教えてくださいませ。

2014-09-21

RubyKaigi 2014に行ってきた

Ruby

こういったイベントに参加するのが初めてだったので、とても楽しかったです。

会場が家から近いこともあって、朝起きるのにそれほど苦労はしませんでした。

嘘です。入場がギリな日もありました。

以下、備忘録。

１日目

Symbol GC

2.2からSymbolが、すべてではないがGCされるようになる。

Rails 5はこの機能が欲しいがために2.2以降をサポートするらしい（ほんと？）。

nariさんの発表はおもしろく、わかりやすかった。

「がんばらないないことをがんばる」を体現した、すばらしい発表でした。

パターンマッチの話

パターンマッチにegisonなるプログラミング言語を作ったので、そのパターンマッチ機能をgemとして移植したという話。

パターンマッチはプログラミング言語の”目玉機能”として紹介されることが多く、言語を使用するひとつの理由となる機能です。

今後Rubyがどういうアプローチ（言語やgem等）でパターンマッチ的なことを実現するのか、それともしないのかが気になりました。

Hypermediaの話

WebAPIをどういう風に設計するかという、REST厨の方の話。

API変更時にクライアント側のコード修正が必要になるのは大変よろしくない。

クライアントに影響しないようにAPIを変更できりょうにするためには、どういう設計をしたらよいだろうか。

クライアント側のコードに、URLやパラメータをベタで書くような設計だとよくない。

APIの状態遷移を考えるとよい。

HTMLの画面遷移と同じように”遷移”に注目して考える。

HTMLではリンクやフォームが次の処理を導いている。

ページの内容が変わっても、ブラウザやHTMLのコードを変更する必要がない。

APIのレスポンスに遷移情報を含めることで、クライアント側のコードを変えることなく、APIの変更ができる。

（※ここらへん正しいか自信ない）

今週のGemなるコーナーを社内でやっている話

社内にプライベートなgemサーバーを置くのいいと思いました。

別のセッションでもプライベートなgemサーバーをおいているという話が出てきたので、業務で使っているところは結構あるのかな？

気軽なプライベートgemサーバーで、gemをつくる＆公開の敷居を下げるのはよいと思います。

共通化大事ですし、うちも置こうと思いました。

Rubyコミッターの話

コミッター、めっちゃ参加してた。すごい会議だ！

パーティー

お寿司たべた。

どんなお仕事をしているのか、普段どんな風にRubyを使ってるのか、という話を参加者の方とチョットしました。

弁当

おいしかった！

最近一人暮らしをはじめて、栄養が偏っていたので、とてもありがたかったです。