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

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

フルスタックエンジニアとは

フルスタックエンジニア。

求人票でよく見る単語である。皆さんはこのワードについてどのような印象をお持ちだろうか。

 

私は現在このポジションで働く方々になんの恨みも無いが、私の中では「安月給で働く中途半端なスキルを持った将来不安な人たち」である。

 

業界の人なら既にこの意味がお分かりだろうが、これから足を踏み入れる未来ある若者の為に説明しておきたい。

 

まずフルスタックエンジニアを募集している企業、これは中小零細企業しかない。例えばメルカリのようなメガベンチャーや大企業は、バックエンド、フロント、インフラなどそれぞれの分野で高いスキルを持った人を募集する。フルスタックエンジニアとバックエンド1本でやってきた人が応募してきた場合、後者が圧倒的に有利なのである。

 

将来不安な人たちとは、この意味である。あとは中小零細企業という点で、安月給は言わずもがなである。

 

ではフルスタックエンジニアは、フロントエンドやインフラ面…とにかくある分野のプロとして見なされないのか、というと、答えは「見なされない」である。

 

残念ながら一人がフルスタックエンジニアとしてカバーできるレベルのアプリしか担当していない…と言う見方になってしまう。

 

つまりある程度の技術や将来性があるサービスならば、しっかり人と技術、お金が投下されるのである。

 

最近の求人を見ると、何かフルスタックエンジニアが凄いかのような記載があるが、決してそうではないし、なろうとしない方がいいと私は思う。

 

自分がどの分野に向いているかを短期間で見極める為に足を踏み入れるのはいいかも知れない。しかし、フルスタックエンジニアの転職先はフルスタックエンジニアなのだから、早めに高みを目指すことをお薦めしたい。

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

Django python 環境構築

概要

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

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

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

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

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

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

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の環境構築

django 環境構築

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

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

作成する上で必要なpythonやvenvはwindows、mac関係なくどの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を作業中のブランチに取り込む)

Git

やりたいこと

ローカルのマスターブランチから派生させた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 リポジトリパターン

概要

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

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が可能となった。