「主婦をサラリーマンにたとえたら想像以上にヤバくなった件」を読んで「共感」した話

はじめに

今回は技術ネタの話ではなく、子育ての話です。
先日、「主婦をサラリーマンにたとえたら想像以上にヤバくなった件」という本を購入したので、その感想を書いていきたいと思います。

主婦をサラリーマンにたとえたら想像以上にヤバくなった件

著者は、日々、主夫の大変な日々をブログで書かれている河内瞬さんです。
私は、この方の書くブログ記事に共感することがとても多かったので、本も是非読んでみたいと思い、購入しました。

河内瞬さんはブログ記事で「家事育児の大変さ」を伝えています。
今回は、そのブログ記事が本になって纏まった感じですね。

河内瞬さんは普段、エッセイ漫画を書かれる事が多いのですが、今回出された本は漫画1割、文書9割という感じで文章が多めです。
エッセイ漫画の方が需要があるのは知っているが、エッセイ漫画を書く人は沢山いるし「家事育児の大変さ」を伝えるなら文章で伝えたい・・・ という本人の強い意志あってのことだそうです。

「共感」

私は現在、1歳になる娘と妻の3人で暮らしています。
私と妻は共働きで、朝は私が娘を保育園へ連れていき、夕方は妻が娘を迎えに行くというスタイルで生活しています。
育児は妻と私の2人で協力し合い、家事は妻が料理を担当、私が掃除を担当しています。週末・祝日は、3人で居ることが多く、どちらかが娘の面倒を見て、各自担当作業をこなしている感じです。

というわけで、ほぼすべての家事を担当している著者と比べて、私が担当する作業は少ないですが、それでもこの本からは「共感」の2文字を感じることができました。

著者の伝えたい事（その1）「料理」はとにかく手間が掛かる。 子供を見ながらの「料理」は絶望的だということ

上記にも書きましたが、料理担当は妻です。しかし、私も料理をまったくしない！というわけではないので、著者が言う「料理には多くの工程があり、非常にめんどくさい作業だ！」という主張はとても共感できた。

料理をすると台所が汚れるため、掃除をするという工程が増える。食洗機を導入しても、入り切らない大型調理器具は結局手洗しかなく、やはり「洗う」という工程が残り続けてしまう。
「料理」は作るだけではなく、献立を考えるところから後始末まで、非常に多くの工程があり、非常にめんどくさい。

加えて子供がいると、はやく終わらせたい工程がなかなか進まない。
我が家は、妻が料理をしている時は、私が娘の面倒を見ているのだが、それでも娘は「やっぱりママがいいー」といって台所に向かう。当然、お腹が空いていれば、大泣きもするし非常に大変だ。
もし、料理と子供の面倒を1度でしなければならない事態が発生するのなら、とても大変なのは目に見えている・・・

著者の伝えたい事（その2）子供が可愛いのと子育てが大変なのは別の話だということ

子供は可愛い。私も自分の娘が可愛いと思っている。
娘が産まれる前までは、子供に対して可愛いという感情はあまり感じていなかったかもしれない・・・。でも、自分に娘ができると考えは変わった。

子供は可愛い。
しかし、著者も言っているが「子供が可愛いのと子育てが大変なのは別の話」。

本では「子供は暴れる10Kgの米だ！！」と書いてあるが、まさにそのとおり。
私は娘を抱っこしていて、筋肉痛になったし、妻は指が腱鞘炎になった。それだけ、子供は重い。（というか暴れる）
以前、子育てによる疲労と体調不良（風邪）で、病院内で倒れて点滴を受けて帰る・・・なんて時もあった。それだけ子育ては大変なのです。

大変なのだから、大変だっ！！というのは、何も悪くないと思う。

著者の伝えたい事（その3）名もなき家事をやらない家族にフラストレーションがたまるということ

名もなき家事とは、たとえば箱ティッシュがなくなったら詰め替える、トイレットペーパーが切れたら替える等の名もなき家事のこと。
机が汚れたら拭く！床が汚れたら拭く！も含まれるだろう・・・

妻は、このあたりはとても協力的で、基本的に名もなき家事はやってくれる。
ただ、机が汚れたら拭く！床が汚れたら拭く！の部分は、人によって気になる許容範囲が違うのかもしれない・・・
というのも、妻はあまり汚れを気にしないタイプなのだが、私はすぐ気になってしまうタイプで汚れているとフラストレーションがたまっている（たぶん） そしていつの間にか机や床を拭いていることがある。

半分仕方ないのかな・・・と思う部分もあるが、こういったところから著者の言いたいことが非常に理解できる。

著者の伝えたい事（その4）子連れの買い物は超疲れるということ

子供をベビーカーに乗せて買い物に行くだけ・・・ではない！！
そもそもベビーカーは先頭なのだ！一番前なのだ！
たとえば、曲がり角で一番最初に出てくるのはベビーカーなのだ！

車はもちろん、自転車や歩きスマホしている人への注意が必要であり、それはとても疲れる。
加えて、子供は機嫌が悪かったりツマラナイと泣く。それをなんとかするために子供を（片手で）抱っこして、（片手で）ベビーカーを押したりもする。

子連れの買い物は、超疲れるというのはとても「共感」できる。

なんか私の愚痴みたいになってきた・・・そろそろ纏めに入ろう

著者の伝えたいことは、上記以外にもまだまだたくさんあります。でも、一番伝えたいことは以下だと思います。

• 子供を持つ人は「家事育児の大変さ」をこの本を通してパートナーと共有してほしい。
• 子供を持たない人は、この本を通して「家事育児の大変さ」を少しでも理解してほしい。

正直に言うと、この本は著者の「家事育児の大変さ」がストレートに出ているので、若干引いたり、クドイなぁと感じる部分も多々あると思います。
ですが、他の本に比べて漫画があって読みやすいですし、「家事育児の大変さ」がストレートに伝わると思います。
なので、この本を少しでも気になった方がいらっしゃれば、読んで見る事をオススメします。

Developers.IO 2019 Tokyoへ参加した話

はじめに

先日、Developers.IO 2019 Tokyoに参加してきました！！
いやぁ、なかなか濃い一日でした。
クラスメソッドの皆様、本当にお疲れ様でした。

久しぶりの「参加してみたブログ」を書いていこうと思いますが・・・
その前に、イベント内容についてです。

dev.classmethod.jp

AWSエキスパート集団のクラスメソッドさんのセッションを1日中聞こう〜！！というイベントです。会場はベルサール東京日本橋！ 最近できた建物ですね。（ちなみに、前職の職場の近くだった・・・というのは秘密です。）

セッションのスライドは、随時クラスメソッドさんから公開していくとの事です。(ありがたい・・・)
なので、この「参加してみたブログ」では、私が聞いたセッションの感想を3つほどピックアップして書いてみようと思います。

1. 認証の標準的な方法は分かった。では認可はどう管理するんだい？（都元ダイスケ）

認証の標準的な方法は分かった。では認可はどう管理するんだい？ #cmdevio from 都元ダイスケ Miyamoto

www.slideshare.net

都元ダイスケさんの発表ですね。 個人的には、以下シリーズのブログで大変お世話になりました。（DynamoDBへの理解が深まりました。ありがとうございます。）

dev.classmethod.jp

発表内容は、「認可」の方法についてです。 私が、本発表で学んだことは、「認可」の方法はISOでちゃんと定められている！こと。そして、「認可」の方法は、AWSのIAMのマネをするのが良い！ということ。でした。

発表の流れとして、何がADIとして必要なのか？->順番に考えていく・・・と->あら不思議、結果的にAWSのIAMが参考になるよー。といった感じで、話のもって行き方はとても上手いなぁと感じました。
私はまだ、認証・認可が必要なWebアプリ開発をしたことはありませんが、これはとても勉強になりましたっ！

2. AWSのすべてをコードで管理する方法〜その理想と現実〜（濱田孝治）

dev.classmethod.jp

ハマコーさんの発表ですね。これは、とても共感した話でした。

• CloudFormationでは、create-stack、update-stackとかあるけど、使い辛くない？（共感）
• 結局deployだけ使ってればいいんでは？（共感）
• deployであった怖い話（共感）
• クロススタック参照時のエラー（共感） etc...

と、ほぼ「あぁ・・・わかるぅ〜（共感）」でした。その上で、CloudFormationのテンプレートの分け方やチェンジセットを使用しよう！など、すぐに実践してみたくなる内容だったので、これはとても学びになりました。

是非とも実践してみたい！

3. 最近のAuroraのアップデート使いこなし術 〜 ServerlessやMulti-Masterどんな時に利用する？ 〜（大栗宗）

スライドはまだ未公開っぽい？

以前、AuroraでMulti-Masterというのが話題になっていて、どんなものなのか気になっていました。Multi-Masterという名前からして「ぉ、すごそう・・・」と期待していたのですが・・・・

実際は「うーん・・・」な結果でした。

Multi-Master・・・つまり、書き込みできるインスタンスが2つあるという事なのですが、「インスタンス間で同データを更新すると競合が発生する！」そうです。個人的に、書き込みが2つあって競合が起きない（書き込み速度が2倍になるような）素晴らしい機能だと期待していたのですが、実際は「うーん・・・」でしたね。

使い道としては、以下を想定しているようです。

• シャーディングして利用する　・・・　2つMasterがあるので、それぞれ扱うデータを分けて利用する。
• ヘルスチェックのフェイルオーバーとして利用する ・・・ Auroraは障害時に自動でRead->Witerに昇格できるのですが、それよりも速く復旧できる。

最後に

他にも5つ（合計8つ）のセッションを聞きましたが、どれもとても学びになる事が多いセッションでした。そろそろAWSの資格獲得に向けて本腰を入れなければならない自分としては、色々な話が聞けたのでとても刺激になりました。

（Laravel第7回目）Laradockを使うのを辞めた話

私は、今までLaravelを触る時、開発環境はLaradockを選択していました。

github.com

Laradockはとても便利です。
最初からLaravelの環境構築用のDockerfileやdocker-compose.yamlが用意されており、Dockerの動かし方さえ知っていればすぐにLaravelの環境を構築する事できます。
あまりに便利なので、私はLaravelを触る時は常にLaradockを使用していました。

しかし、あるタイミングで以下2点に不満を感じ始め、Laradockを使うのを辞めて自分自身でDockerfileやdocker-compose.yamlを作ることにしました。

• Laradockのdocker-compose.yamlに対して、少し修正を加えようとするだけで大変。
• Laradockで作られるDockerのネットワークやボリュームが多く、ローカル環境が汚くなるのが嫌。

Laradockは、様々なLaravelの環境構築パターンに対応できる様、Dockerfileとdocker-compose.yamlに多くのアプリケーションが記載されています。
そのため、docker-compose.yamlに対して、ちょっと修正を加えようとするだけで大変だったり、Docker実行時に作られるネットワークやボリュームが多く、あとで見返した時に「あれ？これいつ作ったっけ？」となります。

ちなみにLaradockで作られるボリュームはこんな感じ・・・（うーん、キレイにしたい・・・）

$ docker volume ls
DRIVER              VOLUME NAME
local               laradock_adminer
local               laradock_aerospike
local               laradock_caddy
local               laradock_elasticsearch
local               laradock_mariadb
local               laradock_memcached
local               laradock_minio
local               laradock_mongo
local               laradock_mosquitto
local               laradock_mssql
local               laradock_mysql
local               laradock_neo4j
local               laradock_percona
local               laradock_phpmyadmin
local               laradock_postgres
local               laradock_redis
local               laradock_rethinkdb
local               laradock_sonarqube

というわけで、結局は自分でDockerfileやdocker-compose.yamlを作るのが一番良いのでは？と思い、作ることにしました。
作ったものは以下の通りです。

php-fpm + Nginx + PostgreSQLのシンプルな構成。"/tmp"やPHPとNginxの各種ログを"/logs"で参照できるようにしました。

■ docker-compose.yaml

version: "3.5"
services:
  app:
    build:
      context: .
    container_name: app
    volumes:
      - ./html:/var/www/html
      - ./tmp:/tmp
      - ./logs/php:/var/log/php
      - ./docker/php/php.ini:/usr/local/etc/php/php.ini
    env_file: .env
    networks:
      - bridge-network

  web:
    image: nginx:1.17-alpine
    container_name: httpd
    depends_on:
      - app
    ports:
      - 80:80
    volumes:
      - ./html:/var/www/html
      - ./tmp:/tmp
      - ./logs/nginx:/var/log/nginx
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
    networks:
      - bridge-network

  db:
    image: postgres:9.6
    container_name: db
    volumes:
      - postgres-data-volume:/var/lib/postgresql/data:rw
      - ./postgres_init/:/docker-entrypoint-initdb.d
    ports:
      - 5432:5432
    env_file: .env
    networks:
      - bridge-network

networks:
  default:
    external:
      name: bridge
  bridge-network:
    name: container-link
    driver: bridge

volumes:
  postgres-data-volume:
    name: postgres-data
    driver: local

Dockerfileでは、php-fpmの設定を記載。
alpineベースのDockerイメージを使うとタイムゾーンがデフォルトUTCになっているとのことで、Asia/Tokyoに変更しました。
以下、参考にさせていただきました。

qiita.com

あと、composerとpostgresql-clientのインストールは忘れずに・・・

■ Dockerfile

FROM php:7.3-fpm-alpine

ENV COMPOSER_ALLOW_SUPERUSER 1
ENV COMPOSER_NO_INTERACTION 1

RUN set -eux && \
  apk add --update-cache --no-cache --virtual=.build-dependencies tzdata && \
  cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime && \
  apk del .build-dependencies && \
  apk --no-cache add bash postgresql-dev && \
  docker-php-ext-install pdo pdo_pgsql pgsql mbstring && \
  curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/bin --filename=composer && \
  apk add postgresql-client

.envでは、環境変数を定義。
Laravelの"/storage"フォルダの場所は変更できるようにしておくきました。HerokuやGAE等のPaaSへのデプロイ時に便利です。

■ .env
POSTGRES_DB=laravel
POSTGRES_USER=laravel
POSTGRES_PASSWORD=laravel
POSTGRES_ROOT_PASSWORD=root

APP_STORAGE=/tmp

あとは参考までに、php.iniファイルとNginxのdefault.confをのせておきます。

■ php.ini

error_reporting = E_ERROR | E_WARNING | E_PARSE | E_NOTICE
display_errors = stdout
display_startup_errors = on
log_errors = on
error_log = /var/log/php/php-error.log
upload_max_filesize = -1
memory_limit = -1
post_max_size = 100M
max_execution_time = 900
max_input_vars = 100000
default_charset = UTF-8

[Date]
date.timezone = Asia/Tokyo

[mbstring]
mbstring.language = Japanese

■ default.conf

server {
    listen 80;
    root /var/www/html/public;
    index index.php;
    charset utf-8;
    server_name localhost;

    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;

    location / {
        root /var/www/html/public;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass app:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

シンプルな構成ですが、Laradockを使用していた時よりも動作が軽くなり、Dockerのネットワークとボリュームもキレイになりました。（めでたし、めでたし）

（Laravel第6回目）ファサード（Facade）からサービスコンテナを学ぶ

ファサード（Facade）とは？

前回でも書きましたが、デザインパターンの1つ。
ある処理や機能をClassに纏めておいて、どこからでも呼び出せる状態にしておく方法。これにより、メイン処理で使われるClassの独立性を高めることができます。

これは私が自作したファサード（Facade）ですが、以下のように、どこからもuse宣言されていないのに、HogeクラスのechoFuga()メソッドを呼ぶことができます。

■ welcome.blade.php

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
    <head>
        <meta charset="utf-8">
        <title>HogePage</title>
    </head>
    <body>
        {{ Hoge::echoFuga() }}
    </body>
</html>

では、なぜこんなことができるのか、（自作した）上記ソースを追ってみましょう！

Hogeクラスはクラスではなく、エイリアス！

上記でHogeクラスと書きましたが、実はこれはクラスではなく、エイリアスです。
config/app.configに以下のように定義しています。

■ config/app.conf

    'aliases' => [

        'App' => Illuminate\Support\Facades\App::class,
        ・
        ・
        ・
        'Hoge' => App\Facades\Hoge::class,
    ]

'Hoge'というエイリアス名で、'Hoge'クラスを登録しています。
この'Hoge'クラスにロジックが書かれて・・・いないです。

■ app/Facades/Hoge.php

<?php
namespace App\Facades;

use Illuminate\Support\Facades\Facade;


class Hoge extends Facade
{
  protected static function getFacadeAccessor() {
    return 'fuga';
  }
}

この'Hoge'クラスは、getFacadeAccessorメソッドで'fuga'を返しています。この'fuga'は何なのでしょうか。
ここで出てくるのが、サービスコンテナです。

サービスコンテナとは？

クラスのインスタンスやインスタンスの生成方法を記入しておいて、呼び出しがあった際にインスタンスを作れる状態にしておくことです。
このインスタンスやインスタンスの生成方法を記入しておく場所ですが、Laravelだとサービスプロバイダーになります。

■ app/Providers/TestServiceProvider.php

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class TestServiceProvider extends ServiceProvider
{
    /**
     * Register services.
     *
     * @return void
     */
    public function register()
    {
        $this->app->bind(
            'fuga',
            'App\Http\Components\Fuga'
        );
    }

    /**
     * Bootstrap services.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
}

サービスコンテナにインスタンス生成方法を登録することをbind（バインド）と呼びます。
インスタンスをサービスコンテナから返すことをresolve/resolving（解決する）と呼びます。

bind方法は色々とありますが、単純な方法は上記のようにapp->bindメソッドを使用して、第一引数に文字列（登録名）、第二引数にクロージャ（生成方法）を記入すればbindできます。
今回は、第二引数にクロージャを使用せずにFugaクラスを指定しました。最初に見たechoFuga()メソッドは、FugaクラスにあるechoFuga()メソッドだったのです。

■ app/Http/Components/Fuga.php

<?php
namespace App\Http\Components;

class Fuga
{
  public function echoFuga()
  {
    return 'HOGEと見せかけたFUGA';
  }
}

これで、上記'Hoge'クラスのgetFacadeAccessorメソッドで'fuga'を返している理由がわかりました。
このサービスコンテナの'fuga'を呼んでいたんですね。

あれ？サービスコンテナのインスタンスってどうやって作ってるの？

'Hoge'クラスの継承元のFacadesでインスタンスを作っています。
Facadesクラスには以下__callStatic()と呼ばれるマジックメソッドがあり、アクセス不能メソッドがあった場合にインスタンスを作るようになっています。

__callStatic() は、 アクセス不能メソッドを静的コンテキストで実行したときに起動します。

■以下より引用
https://www.php.net/manual/ja/language.oop5.overloading.php#object.callstatic

■ Illuminate\Support\Facades\Facade.php

    public static function __callStatic($method, $args)
    {
        $instance = static::getFacadeRoot();

        if (! $instance) {
            throw new RuntimeException('A facade root has not been set.');
        }

        return $instance->$method(...$args);
    }

なので、サービスコンテナ内でインスタンスを作るのではなく、サービスコンテナの呼び出し先でインスタンスを作るのが良さそう。

最後に整理

さて、ここまでファサードからサービスコンテナ、エイリアスを学んできました。
最後に図にしてみます。だいたいこんな感じ？

Laravelを学んでいると必ず出てくるファサードとサービスコンテナについて、なんとなくわかった気がしました。うーん、Laravelは奥が深い（= = ;;

Webエンジニアになって1年が経つので振り返ってみた話

はじめに

私は11年間勤めていた会社を辞め、34歳で客先常駐の金融系のSE（システムエンジニア）からWebエンジニアに転職しました。
以下、経緯等はこちらに纏めています。

kodak.hatenablog.com

Webエンジニアになって、1年が経ったので転職後の振り返ってみたいと思います。

転職して良かったの？悪かったの？

良かった。

一番良かったのは、子供を保育園へ送る時間ができたことだ。
転職後は、出社時間が遅くなり、通勤時間が短くなり、加えてフレックス制度があったので子供を保育園へ送る時間が確保できたのは凄く助かった。
また、上司にも3歳の子供がいるため、子供の急な発熱等での帰宅や看護休暇に理解があり、このあたりも大変助かっている。

次に、自身が望んでいたAWS関連の仕事やWeb周りの仕事ができたことだ。
このおかげでAWS周りの知識、Web周りの知識が増えた。
また、AWS関連のイベントにも会社の勤務時間扱いで参加させて貰えたことも凄く嬉しかった。

転職して1年間何してた？

仕事としては、主にAWSやWordPressを使った開発をしていた。
開発環境はDockerを使う事が多く、転職後はAWS、WordPress、Dockerの経験や知識が身についた。

稼働率は（現時点では）それ程高くはなく、空いている時間等でVue.jsやLaravelの勉強もやっていた。
あとは、帰宅後（子供が寝ている間）や隙間時間を使って、ブログや本、Vue.jsやLarabelを触ったりしていた。

こうやって、文字にすると時間に余裕があるように見えるのだが、実際はそれ程時間はなく、いつも身を削って何かやっているのが現実・・・

できたことは？

まず、Webエンジニアになれたこと。その上で、子育てと仕事の両立に成功したこと。
お客さんと話して要件を詰めるといったディレクター的なこと（前職に近い仕事）とコーディングを両立できたこと。

あとは上記でも書いたが、念願のAWSの仕事に関われたことやWordPressやDockerにも触れることができて、経験や知識が増えたことが上げられる。

できなかったことは？

色々と手を付けすぎていて各分野で知識が浅いこと。
勉強会やコミュニティーにあまり参加できなかったことが上げられる。

今後はどうしたい？

１つは、コーディング技術自体は1年前とそれ程上がっていないので、コーディング技術を上げたい。TDDとかしたい・・・
もう1つは、各分野の知識を深めたい・・・のだが、各分野の知識を深めるには歳を取りすぎてしまった気もしている（涙）
そこで何か1つ専門分野を身に付けて、そこから広げていけたらいいなと考えている。

最後に、勉強会やコミュニティの参加を増やしたい・・・という思いもあるのだが、これも引き続き難しいだろうと思うので、ブログでアウトプットするアクションを続けていけたらと思う。

AWSの資格のSAAの有効期限が迫っているので、こちらもなんとかしたい・・・（= = ;;）

おわりに

たまに考えるのが、「もし、転職せずに前職のままだったとしたら・・・」
仕事と子育ての両立なんて無理だったと思います。もしかすると妻と喧嘩して家庭崩壊・・・なんてことも！？

それだけ子供を育てるって大変なんですよね。

というのを、子供が産まれた後に理解しました・・・（もちろん想像はしていましたが、想像以上でした）

仕事と子育てを両立している人って、本当にすごいと思う。もし、これから子供が産まれる！子供を考えている！って方は、今の生活のまま子育てできるのか・・・というのを今一度考えてみるのをオススメします。