閲覧が無い故に良いメモ帳と化したプログラマーブログ

主にphp関連の技術ブログ。閲覧が無い為、マークダウンが使える良いメモ帳と化している。誤ってアカウントパスワードを書いても大丈夫だ。なぜなら誰も閲覧しないからな。安心のブログシステムである。

Django+PostgresをDockerで爆速で用意する

概要

Djangoのロケット画面までをdockerでサクッと用意する。 大事なのはサービスの為のコーディングであり、環境構築などは本当に無駄な業務だと思ってます。 同じ考えの方は、どうぞ私のブログをコピペして下さい。

Djangoはアプリケーションを切り取ってくっつけることができるので、ローカルで動作確認したベースとなるアプリケーションを持って行ったりします。

公式サイトの日本語訳になります。 Quickstart: Compose and Django

1. 必要なファイルを用意

project/
  - Dockerfile
  - requirements.txt
  - docker-compose.yml

上記3ファイルを同階層に作成します。

Dockerfile

FROM python:3
ENV PYTHONUNBUFFERED 1
RUN mkdir /code
WORKDIR /code
COPY requirements.txt /code/
RUN pip install -r requirements.txt
COPY . /code/

requirements.txt

Django>=2.0,<3.0
psycopg2>=2.7,<3.0

docker-composer.yml

version: '3'

services:
  db:
    image: postgres
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "8000:8000"
    depends_on:
      - db

2.同階層にdjanogプロジェクトを作成する。

sudo docker-compose run web django-admin startproject project_name .

この時点で下記のようになります。

$ ls -l
drwxr-xr-x 2 root   root   project_name
-rw-rw-r-- 1 user   user   docker-compose.yml
-rw-rw-r-- 1 user   user   Dockerfile
-rwxr-xr-x 1 root   root   manage.py
-rw-rw-r-- 1 user   user   requirements.txt

↑のオーナーをrootから変更するおまじない。

sudo chown -R $USER:$USER .

3.作成したプロジェクトのsettings.pyを編集する

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'postgres',
        'USER': 'postgres',
        'HOST': 'db',
        'PORT': 5432,
    }
}

4.docker-compose upで完了

http://localhost:8000でロケットを確認できます。

補足

settings.pyに追加設定が必要なケースもあるようです。

ALLOWED_HOSTS = ['*']

Djangoの環境構築

新しいプロジェクトを始める上でいつもドキュメントを探すことになるので、取り敢えずこの画面までの設定を備忘録として残します。

f:id:Laraveler:20190715182551p:plain
django環境構築

作成する上で必要なpythonやvenvはwindowsmac関係なくどのPCにもデフォルトで入ってます。 PHP等と違って初めから入っているのは有り難い。(※python3が必要ならご自身で...)

手順はこちら!順番にやっていきましょう!

  1. 仮想環境の構築
  2. requirements.txtの作成
  3. 仮想環境へのdjangoのインストール
  4. プロジェクトの作成

まず、作成後のフォルダ構成は下記のようになります。 意識してcdしてくださいね。

project
├───project_name // プロジェクト名
├───requirements.txt // インストールするパッケージ管理用ファイル
└───venv-project-name // このプロジェクト用のvenvを同じ階層に置く

1. 仮想環境の構築

まず始めにvenvという仮想環境を構築します。
説明は省きたい所ですが、簡単にいうとpip によるパッケージの導入状態をプロジェクトごとに独立させるために使います。

$ cd project 
$ python3 -m venv venv-project-name

これだけで仮想環境が出来ました。

2. requirements.txtの作成

次にパッケージ管理用のrequirements.txtを用意します。
仮想環境にインストールするパッケージはここに記録、管理しておきます。 これを参照することで、チームのメンバーが同じ環境を作れますね。

$ vi requirements.txt

// viで必要なパッケージを記載する (今回はdjangoだけ)
Django~=2.0.6 

3. 仮想環境へのdjangoのインストール

それでは仮想環境へrequirements.txtに書いたdjangoをインストールしていきましょう。

$ cd project
$ sourcec venv-project-name/bin/activate // 仮想環境へ入る

(venv-project-name) $ pip install -r requirements.txt // 仮想環境でpip install

はい、これで仮想環境へdjangoをインストール出来ました。

4. プロジェクトの作成

さて後はプロジェクトを作成するだけです。

project
├───project_name // ←あとはここだけ
├───requirements.txt // 完了
└───venv-project-name // 完了

下記コマンドでプロジェクトを作成してください。

(venv-project-name)$ django-admin startproject project_name .

無事プロジェクトの作成が終わったら下記のコマンドで確かめてみましょう。
ブラウザにはhttp://127.0.0.1:8000/を入力です。

(venv-project-name) $ python manage.py runserver

これでロケットの画面だ!

Gitの使い方(更新があったリモートのmasterを作業中のブランチに取り込む)

やりたいこと

ローカルのマスターブランチから派生させたbugfixブランチをpushしたい。しかしpush前にリモートのマスターブランチに更新があった事を知る。push前にローカル環境で最新のマスターブランチとマージを行い、bugfixブランチが現状のマスターに適しているかを確認する。

簡単な確認であれば構成管理の方の負担を減らしてあげましょう。

// ローカルのmasterブランチを最新の状態にする
$ git checkout master
$ git pull

// ローカルのbugfixブランチに最新のmasterブランチの変更を取り込む
$ git checkout bugfix
$ git rebase origin master

特にコンフリクトが無ければpushOKです!

「自助努力を」との金融庁からのお言葉について

先日、金融庁から年金制度の破綻について発表があった。 今を生きる特に若者にしたら、当たり前のことをなぜわざわざ発表したのか、といったところだろうか。 この発表において、どうもしっくりこない部分がありブログを書くことにした。

それは、節約をしろと言う一方で投資で資産を増やせと言っている部分である。 国民がモノを買わない状態で、どうして企業が成長するのか・・・。 正直金融庁様が仰るお言葉の意味が理解できなかった。 増税、年金の減額等で国の消費が下り坂となることが明確である日本の未来に対し、投資をする価値は全く無いと私は考えている。 消費があって、売上が上がって、企業は成長していくものである。

スマホで少額から投資ができたり、税金が優遇されるNISA口座を作ったり、私たちの年金を日本株へブッ混んだりと、 企業を守るために政府は必死で動いているが、もういい加減その行為が無駄であることを気づいて欲しい。 現在の日本企業の株価は、日銀やGPIFが頑張って頑張って買い支えて保たれており、企業そのものの価値を表してはいない。 下手に投資をすると、さらなる貯蓄のマイナス、消費減を加速させるのでは?というのが私の見解だ。

私は純粋な日本人なので、正直悔しい思いで一杯だ。 しかし、不幸な未来にしてしまった人たちが、さらに不幸な未来にしかねないような事を言うと、 どうしてもその間違いを発信してしまいたくなる。

拡散希望です。

LaravelでWEBサービスを立ち上げる為のテンプレートを用意する

概要

Laravelを用いてWebサービスを立ち上げる際の基本的な構成を用意する。 最近リポジトリパターンが流行っているようなので、その構成をテンプレート化しておいてすぐに使えるように用意しておく。 この構成にどんな意味があるかは手を動かしながら理解していってほしい。

1.プロジェクト作成 Laravel-Installerでプロジェクトを作成。

$ laravel new SampleProject

2.ディレクトリを追加する DBへのアクセスを担うRepositoriesと、ビジネスロジックを纏めるServicesを置くディレクトリを作成する。基本的にどこに配置してもいいが、よく見るのはappの配下に置くパターン。

├── app
│   ├── Console
│   ├── Exceptions
│   ├── Http
│   ├── Services // 追加
│   ├── Repositories // 追加
│   └── ...
├── bootstrap
├── config
├── ...
...

3.マイグレーションファイルの作成 今回は既存のUserテーブルに加えCompanyテーブルを用意する。下記のコマンドでモデルとマイグレーションファイルがセットで出来上がる。その後はphp artisan migrateでテーブルの作成を行う。

php artisan make:model CompaniesTable --migration
<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateCompaniesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('companies', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name', 100)->default("");
            $table->string('address', 200)->default("");
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('companies');
    }
}

4.コントローラーの作成 最近はRestApiでの開発がメインになりつつあるので下記でコントローラーを作成する。

php artisan make:controller CompanyController --resource

5.各ファイルの手配 2.で用意したSercices、Repositoriesディレクトリに下記のファイルを用意する。

・CompanyService.php // Servicesディレクトリ内に配置 ・CompanyRepository.php // Repositoriesディレクトリ内に配置 ・CompanyRepositoryInterface.php // Repositoriesディレクトリ内に配置

6.ロジックを組み立てる 下地が整ったので、あとはロジックを組み立てていく。まずはコントローラーにメソッドを記述する。ここでは同時にCompanyServiceを注入している。Companyが不動産関係なら所有物件の有無を確認し...といったビジネスロジックはCompanySrerviceに記述することになるので、コントローラーではCompanyServiceで「何をするか」が分かるように記述する。実際のロジックはCompanyServiceの中で記述すること。

<?php

namespace App\Http\Controllers;

use App\Http\Requests\CompaniesRequest;
use App\Services\CompanyService;

class CompanyController extends Controller
{

    /** @var companyService */
    protected $companyService;

    /**
     * @param CompanyService $companyService
     *
     */
    public function __construct(CompanyService $companyService)
    {
        $this->companyService = $companyService;
    }


    /**
     * Store a newly created resource in storage.
     *
     * @param  CompaniesRequest  $request
     * @return array
     */
    public function store(CompaniesRequest $request)
    {
        $company = $this->companyService->createCompany($request->only(["name", "address"]));

        return response()->json($company, 200);
    }

}

次にCompanyService.phpを作成していく。上で述べたように、ここにコントローラーで使うであろうメソッドを定義していく。上の流れに沿って不動産関係の会社でゴニョゴニョしたいならisEstateCompany()isOwner()など必要なメソッドをコントローラーを意識して用意する。

<?php


namespace App\Services;


use App\Repositories\CompanyRepositoryInterface;

class CompanyService
{
    protected $companyRepository;

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

    public function createCompany($request)
    {
        return $this->companyRepository->createCompany($request);
    }

}

次にInterfaceを用意する。Interfaceはメソッドを保証する目的で作成する。例えばcreateCompanyはDBに会社を新規登録するメソッドである為、このInterfaceを実装するのはCompanyRepositoryになるが、CompanyRepositoryには必ずcreateCompany()が定義されていなければならない。なぜこのような面倒なことをするか、と言うのはこの後説明する。

<?php


namespace App\Repositories;


interface CompanyRepositoryInterface
{
    public function createCompany($request);

}

ここでAppServiceProvider.phpにこのInterfaceとRepositoryの紐付けを行う。Interfaceを使用する意味はここにある。ここではCompanyRepositoryInterfaceとCompanyRepositoryを紐付けているが、このRepositoryは差し替えが可能である。例えば.envがAPP_ENV=localならばCompanyRepositoryでAPP_ENV=productionならばApiCompanyRepositoryを使用するといったDBの切り替えをここで定義することができる。この他にも、例えば会社登録などほぼ固定化され変わることのないメソッドは必ず用意してくれと言う意味でもInterfaceの存在意味は出てくる。

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        $this->app->bind(\App\Repositories\CompanyRepositoryInterface::class, \App\Repositories\CompanyRepository::class);
    }
}

最後にCompanyRepositoryのコーディングを行う。ここではModelのCompany.phpを注入する。Modelにはリレーションやfillableなど基本的な共通事項を定義しておけばRepositoryを複数用意する場合にも便利だろう。

<?php


namespace App\Repositories;


use App\Company;

class CompanyRepository implements CompanyRepositoryInterface
{
    protected $company;

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

    public function createCompany($request)
    {
        return $this->company->create($request);
    }
}

7.まとめ DBへのアクセスロジックはRepositoryへ、ビジネスロジックはServiceへ、コントローラーへは派生先で何が行われるかが見ただけで分かるようにするのが理想である。

GitでPermission denied...が発生した際の解決方法

git pushの際に見られる下記のエラーの解決方法。 鍵の認証ができていない場合に見られるので再設定をすれば大体解決する気がします。

$ git push origin master
Permission denied (publickey). fatal: Could not read from remote repository.  Please make sure you have the correct access rights and the repository exists.

下記の手順で所要時間は5分程度です!

  1. 鍵を生成
  2. 公開鍵をgitに登録

1. 鍵を生成

# 移動して鍵を作成 (メールアドレスはgitアカウントのメールアドレス)
$ cd ~/.ssh
$ ssh-keygen -t rsa -C mail@mail.com

# lessコマンドでid_rsa.pubを開き、中の文字列の ssh-rsaからメールアドレスの手前までをコピーします。
$ less id_rsa.pub

コマンド入力後に出てくるEnter...はそのままエンターキーを押せばOK。(3回出てくるので3回押す)

2. 公開鍵をgitに登録

githubのマイページでこの鍵を登録する。 右上にあるアイコンよりSettings → SSH and GPG keysをクリック。 次に、右上のNew SSH keyをクリックする。

f:id:Laraveler:20190315014604p:plain
New SSH Key

上記画面のkey部分にコピーしたSSHキーを貼り付ける。タイトルは適当でOK。 これで問題なくgit pushが可能となった。

2019年の日本について考えてみた

アベノミクスは成功したのか。日本の景気は良くなっているのか。 皆さんはどう感じていますか?

私は2019年は暴落のはじまりの年だと考えています。 理由は、日本人が日本のことを完全に信用しなくなったからです。

そもそも景気がいいとは何でしょうか。 私は給与の上昇率がインフレ率より高いということだと考えています。(ざっくりですが・・・) 給与が上がらなければ、人はモノを買いません。 人がモノを買うということは、経済のドミノの最初を倒すということ。 そこから売り上げが立ち、儲けで企業は投資をする、そこに可能性を感じた投資家が投資をし、成功してモノが売れる、給与が上がる・・・。 給与の上昇はモノを買う為に必要不可欠と言えます。

しかしなかなか給与は上がりませんね笑。

政府は株高=景気がいいと言います。アベノミクスは成功していると。 多くの人は株高=好景気となんとなく感じてしまうのでしょう。 でもしっかり考えてみてください。 株価とあなたの生活、何か関係はありますか? 加えて言うなら、株価上昇は日銀が日本株を買いまくって上げているだけで、企業の純粋な価値を表してはいません。

景気がいいという政府の言葉は、否定はできないけど、私たちをしっかり納得させるには不十分だと感じます。 こんな曖昧な言葉を積み重ねてきた今が、「信用できない」に繋がっていると感じます。

この信用は、皆さんの財布のひもの固さとも言えます。 将来が不安で、皆さんのお財布のひもは固いままではないですか? 買い物は少しでも安く、貯金もしておきたい。そんな心理を生み出すのです。

2019年はそんな不安が実態となる年だと考えています。 まずは内需中心の企業の株価が下がり始めるでしょう。

長くなったので今日はここまでっす。