エンジニアのひよこ_level10

毎日更新してた人。たまに記事書きます。

Laravelでリポジトリを書くメモ【397日目】

注意

メモです。

こんなふうにコード書いていきたい(願望)

慣れたらサイト作って、それをgithubに上げたい(願望)

リポジトリ

class XxxRepository implements XxxRepositoryInterface
{
    
}

リポジトリを呼び出すサービス

class XxxService
{
    private $xxx_repository;

    function __construct(XxxRepositoryInterface $xxx_repository)
    {
        $this->xxx_repository = $xxx_repository;
    }
}

XxxRepositoryInterfaceの実装をbind

XxxServiceProvider.php

    $this->app->bind(
        'App\Repository\XxxRepositoryInterface',
        'App\Repository\XxxRepository'
    );

app.phpにサービスプロバイダを登録するのを忘れずに

忘れそうなよくある質問

Q.バインド?なにこれ?

サービスコンテナ 5.3 Laravel

Q.なんでわざわざインターフェースでやるん?

あとで、インターフェースを使ってテストコードかけるじゃろ。Stub書けるじゃろ。

【プログラミング】コメントで設計してからコーディングする【396日目】

プログラムを書く前に流れをメモ

プログラミングをするとき、どんなふうにコーディングしますか?

とりあえず思いつくコードを書きますか?

コードの流れをメモして、そして流れができたら実際に実装しますか?

私は大まなか流れを書いてからコードを書きます。

こんな感じに書いてるよってのをここで。

コメントで流れを書く

// ユーザーを登録する

// メールを送る

関数名を書く

// ユーザーを登録する
$user = $this->createUser($user_data);

// メールを送る
$this->sendMail($user);

空の関数を書く

// ユーザーを登録する
$user = $this->createUser($user_data);

// メールを送る
$this->sendMail($user);


// 中身はなく、型をあわせるか、0等適当な値を返す
function createUser($user_data)
{
    // ユーザーを作成する

    // 作成したユーザーを返す
    return new User();
}

function sendMail($user)
{
    //メールを送る
}

何が嬉しいの?

これ、このままでも動きます。

常に動作確認が出来る状態です。

まず、土台を作る、そしてそれを少しずつ組み立てていく感じ。

しかも、コメントで内容書いているので、何作るかも迷わない。
出来上がったコードにはコメントがすでにあり、しかも流れがぐっちゃぐちゃになりにくい。

プログラミング慣れてきたら、こんなふうに書くのはわりとおすすめ。

DBでcreateするときに、ControllerとServiceとRepositoryに書く内容【395日目】

注意

リポジトリパターンを学び始めの初心者なので、これが当たり前!って感じではないです!

合ってる!間違っている!等ありましたら教えていただけると嬉しいです!

一旦理想を考える

以下、ServiceとRepositoryで呼び出しの理想形を書いてみる。

Service

function createUser(array $data)
{
    return $this->user_repository->create($data);
}

Repository

function create(array $data)
{
    return $this->user->create($data);
}

どっからデータ呼び出すん?

ということで、$dataを渡すControllerと、呼び出すMethodを用意しよう。

Controller

function post(xxxRequest $request)
{
    $user_repository->createUserFromRequest($request);
}

Service

function createUserFromRequest(Request $request)
{
    return $this->createUser($request->all());
}


function createUser(array $data)
{
    return $this->user_repository->create($data);
}

データの整形したいな

じゃあServiceに整形用のクラスを作ろう

Service

function createUserFromRequest(Request $request)
{
    return $this->createUser($this->getUserDataFromRequest($request));
}


function getUserDataFromRequest(request $request)
{
    return array_merge(
            $request->only('name', 'password'),
            ['is_active' => true]
        );
}

結局何ができた?

こんな感じ

Controller

function post(xxxRequest $request)
{
    $user_repository->createUserFromRequest($request);
}

Service

// リクエストオブジェクトから、ユーザーを作成する
function createUserFromRequest(Request $request)
{
    return $this->createUser($this->getUserDataFromRequest($request));
}

// データ整形
function getUserDataFromRequest(request $request)
{
    return array_merge(
            $request->only('name', 'password'),
            ['is_active' => true]
        );
}

// 配列からユーザーの作成
function createUser(array $data)
{
    return $this->user_repository->create($data);
}

Repository

function create(array $data)
{
    return $this->user->create($data);
}

【一週間振り返り】夢についていっぱい考える一週間でした【394日目】

1.今週一週間の感想(ざっくり)

いっぱい夢について考えた、悩んだ一週間でした。

2.良かったこと

1.夢について、何人かと語って、その夢じゃなくてもよくね?っていういい指摘もらった。

2.開発で、先輩にいっぱい学ばせてもらった。早くブログにせねば。

3.もっとこうしたかったこと

プログラミング、GCP使っていろいろやるつもりだったが・・・

まあ、それ以外に優先度高いやることいっぱいあったから、一旦OK。

4.新しく気づいたこと

夢いっぱいボコボコにされたけど、逆にそれは言語化したおかげなので、良かった。

そして、それを一人でやるのか?複数でやるなら、

5.来週したいこと

自分の考えを整理ー。
私は夢に対して、どういうスタンスでいたいのか、どう行動したいのか整理。

そして可能ならGCEもう少し勉強ー

6.その他

自分の夢に対して、どうしたいのか。

自分は、サポートタイプのようで、勝手に一人で何か始めたりとか、よくわからないときに行動したりするよな・・・

そのために人を巻き込むこともそこそこあるし、本当に私どうしたいんだろー?

いっぱいいっぱい悩みますー!

ControllerとServiceとRepositoryにそれぞれ書くべき内容【393日目】

プログラム書くときに悩むやつ

あれ?これって、サービスに書くべきだっけ?コントローラーに書くべきだっけ?ってなる。

で、とりあえず何が正解かはわからないですが、一旦これからな?ってのを決めて見ようと思います。

対象

Controller

Service

Repository

Controller

サイトを作るときに、日本語でこのサイトはこういうウェブサイトです。って説明するときに使える部分。

あるいは、ページのHTML部分やリクエストの内容の役割の部分はControllerに記述。

例えば、『チェックボックスにチェックがついていたらメールを送る』なら、
チェックボックスにチェックがついていたら、というif文まではControllerに書いてもいい。

if (request('is_checked') === true) { 
    $mail_service->sendMail();
}

じゃないと、Controllerを見たときに、どんな動きで動作をするサイトなのかパット見わからない。
これなら、チェックボックスがtrueなら、メールを送るってのがパット見わかる。

Service

Controllerでサイトをどんな流れで動くかを説明出来たら、具体的にどんな『処理』をするかをここで書く。
ビジネスロジックと呼ばれる部分。

メールを送るときに、ジョブを作って、キューを送るとか。

かなり誤解を生む言い方ですが、エンジニアじゃない人で設計をする人が日本語でかけるようなところまでがControllerで、
プログラマーじゃないとわからないような、仕組みの辺りをServiceで書くイメージ。

Repository

データベースのデータを取得するところ。
クエリとかいい感じにしたりして、データベースから適切なオブジェクトを用意しよう。

ORMとかでいい感じのオブジェクトを返そうとしたら、だいたいRepositoryに書いてる気がする。
出来上がったオブジェクトを『使って○○をする』とかまで来ると、Serviceかな?ログインとか。

ただ、出来上がったオブジェクトを用いて、データベースをいじるってなったら当然Repository。

夢を語ったら、語り合える仲間ができました【392日目】

夢をアウトプットしたら幸せになりました

以前、facebook

『やりたいことをやれる世界』

『一日4時間働けばいい世界』

そのために私は『国を作るのが夢』だ。

そんなことを書いたら、飯行きませんか!って言ってくださった方がいて、その方とさっきまで飯行ってました。

その方の夢の一部

私の理解で書くので、多少ねじ曲がった説明になりますが……

その方の夢で、技術にお金使えない、投資もお金のリターン前提じゃないと投資しにくい、それをどうにかする。

自分も投資をするとか、技術発展が上手く回る世界とか、すっごく面白いですし、私がやりたいことにも近いところがあって、いいお話でした……!

こうやって、近い規模で夢をぶつけ合えるのは本当に稀で、本当にいいこと……!

私の夢へのありがたい指摘

理想の国作るのって、現実的に無理じゃね?
他の方法を考えたほうがいいのでは?

そんな指摘が貰えたのが凄く嬉しい……!アウトプットしたからこそ得られたものだよね。
無理な理由として、

自給自足出来ないと外部要因が多数入り込む。

鎖国して技術の差別化を図ろうとしても、同じことをもっと速いスピードでされる可能性あるよね

とかとか。

となると、生活の自給自足が出来る国が必要なのかな?国を乗っ取る?
みたいな発想が新しくできるので、こういう反論はめっちゃ助かりますね……!

ただ、鎖国していくのはなかなか難しい。
区切りを作ろうとしても、その区切りを破って圧力をかけられるのは避けられない。

島を買っても、経済水域の資源ほしいって外的圧力は来るだろう……他にも外的圧力は来る。

他との関わりを遮断しようとすることは、外部圧力に対抗する必要があるということだ……

んーやっぱりVRに可能性を感じちゃう。資源の複製性。環境の隔離性。ただ、それだけじゃ解決できない話だけどね。

社会と常識って強敵

無駄をなくせば仕事減るんじゃね説は、以前私の友人からいただいた、『それなら200年前から便利になってるのになんで変わらないん?』って言葉で止まりました。

そこから、競争社会だからじゃないか?

そもそも、なんで競争社会生き残ってるん?

競争社会で成功した人達が上にいるよね。

今の社会の常識やルールって、力ある人や都合のいい人が作ってるって話……

目からうろこでした。

地球温暖化は、発展途上国の発展を抑えるために、それっぽい理由として広げた。

そんなパターンが存在するなら……みんなの常識を塗り替える、塗り替えたいと思わせる常識をうまく広げることも、国を作るに代わる、私の新しい手段として考えてもいいのでは?

ただ、今の競争社会で上手く行った人は、その立場を崩す常識には徹底対抗されるだろうし、なかなかこれも難しい……

常識に立ち向かうとおぼろげに思ってたけど、新しい敵がより具体的に見えてきた辺り、かなり大きな進歩だったのでは???

これからの私

  1. 国を作る
  2. 新たな常識の流布

この2軸で夢を模索することを進めていこうと思います!

国を作るはあくまで手段のひとつなので、達成したい目的のためならいくらでも戦います。
でも、どちらも社会の常識と戦うので、やっぱりなかなか難しいけどね!!

でも、今の私はこれをブラッシュアップ出来る、意見を戦わせ合える友人が少しずつ増えてるので、同時に心強い。

がんばるぞー!おー!

はてなブログ等のドメイン変更後に、Googleに新ドメインを認識させる【391日目】

はてなブログProで独自ドメインにしたけど検索結果では・・・

f:id:willow710kut:20181108195045p:plain

Googleの検索結果でのURLは、見ての通り前のドメインのままですね。

これを、新しい今のドメインに変えたい。

ってことで、過去のドメインはもう終わったよ、新しいサイトに移動したよってGoogleに申請しよう。

サーチコンソールで申請

サーチコンソールでは、旧ドメインのまま運用していました。

なので、サーチコンソールを使って新しいドメインを申請しようと思います。

1.サーチコンソールで変更用ページへ

https://www.google.com/webmasters/tools/home?hl=ja

サーチコンソールにログインして、右上の歯車を選択

f:id:willow710kut:20181108195315p:plain

そのメニュー内の『アドレス変更を選択』

f:id:willow710kut:20181108195430p:plain

リストから新しいサイトを選択する、の中身がないので追加しましょう。

2.新しいサイトの追加

f:id:willow710kut:20181108195617p:plain

プロパティを追加を押して、新しいアドレスを貼り付け。

f:id:willow710kut:20181108195733p:plain

おすすめの方法、意外と面倒なので、別の方法を選択。

HTMLタグと書かれているところを選択すると、metaタグをheadに入れてねって言われるので入れよう。
はてなブログとかなら、設定→詳細設定→Headにタグ挿入あるよね。あそこにタグを貼り付けよう。

貼り付けて反映したら、確認ボタンをクリック。

うまく行ったら、所有権確認出来ました的なこと言ってくれる。

3.新しいプロパティの追加

https://www.google.com/webmasters/tools/home?hl=ja

もう一回サーチコンソールのTOPに戻って、プロパティの追加。
新しいサイトで作り直す。

そしたらこんな状態になるよね。

f:id:willow710kut:20181108201355p:plain

4.もう一度2.のページに戻って挑戦

f:id:willow710kut:20181108201600p:plain

戻ってみると、3.にチェックがついていない。

サイトにmetaタグが新旧両方残っていれば、3番目の確認をクリックすると、緑になる。

さあ、リクエストの送信だ。

f:id:willow710kut:20181108201754p:plain

お疲れ様でした!!!

AWSでサーバー環境構築の構成メモ。【390日目】

注意

メモ書きです。

更にいうと、クラウドよくわかってない人のメモです。

ユーザーが80アクセスするとき

ドメイン→Route53とか

Route53で対象とするip→ipではなく、ELB(ロードバランサ)を対象とする

ELB→EC2に80アクセス

もしipを社内等で制限するなら?

EC2→ELBのipだけ許可。sshでデータいじるために、社内ipで22も開放(ssh用に22開放だけど、できればsshのポート番号を変えること)

ELB→社内のipだけ許可

ユーザーが443アクセスするとき

ドメイン→Route53とか

ELBにアクセス→ACMでELBにSSL証明させる

ELBからEC2に80アクセス

このとき、ELBに443アクセスされたことを、EC2のアプリケーション側に渡して判断させることで、
アプリケーション側も443したんだなとわかる

ip制限

EC2→ELBのipだけ許可。このとき80アクセスを許可。sshでデータいじるために、社内ipで22も開放(ssh用に22開放だけど、できればsshのポート番号を変えること)

ELB→社内のipで、443だけ許可。あるいは、80も受け取りつつ、リダイレクトさせて443に飛ばす。

なんでこうするの?

これで、証明書発行、ELBにだけもたせればいいから、各サーバーに置かなくてええじゃろ?