Try T.M Engineer Blog

多摩市で生息するエンジニアが「アウトプットする事は大事だ」と思って始めたブログ

Advent Calendar 2019で記事を書いた事の(ちょっとした)余談

もうすぐ12月が終わりますね。
今年も「あっ」という間でしたね。
なんか、1年前も同じことを言っていたような気がします。(笑)

さて、昨年に引き続き、今年もAdvent Calendarに記事を書かせていただきました。

qiita.com

今回は、WordPressWysiWygエディターの話です。

WordPressを使って開発をしている方々は、エディターってどうしているんでしょうか・・・
このあたりって調べてもあんまり情報が出てこないんですよねぇ(==;;

なので、今回は自分の実践している方法を書いてみることにしました。
こういった「調べても情報が少ない」「情報が出てこない」記事は貴重だと思うので、気になる方は是非参考にしてみてください。

とはいえ、Advent Calendarの記事でも少し触れていますが、現在のWordPressには、Gutenberg(グーテンベルグ)と呼ばれるBlockエディターがデフォルトになっています。
今後は、Blockエディターが主流になってくるので、タイトルに「今更」というコメントを付けました。

私自身Blockエディターをあまり使った事がないので、勉強した上で、どこかのタイミングでBlockエディターについても記事にしてみたいと思います。(ただ、このBlockエディター、VueじゃなくてReactで実装されてるのでReactを学ばねばならんのが辛い・・・)

あと、個人的に面白かったAdvent Calendarですが、以下ですね。

qiita.com

こういった本番でやらかしてしまった事って、恥ずかしかったり、黒歴史だったりして案外表に出ないんですよね。

これはこれで貴重だなぁ・・・なんて思ったりしていました。
Advent Calendarについては以上です。
続いて、過去に私が書いたQiita記事を少し紹介します。

qiita.com

qiita.com

この2つの記事は、実はセットなんです。
記事には書いていませんが、AWS SAMを使ってLambdaをのコードを書く時にこの2つはとても便利です。

VCRは、HTTP RequestのMockができるし、MotoはAWSのServiceをMockできます。そのため、この2つをAWS SAMのLambdaのコードを書く時に使えば、なんとAWSの内と外のMockができるようになるので、個人的にオススメです!!
気になる方は是非参考にしてみてください。

さて、次回は2019年の振り返り記事でも書こうかな。

【ネタ回】スキマスイッチの『私はロボットではありません』をRekognitionを使って当ててみた話

今回はネタ話です。

ちょっと昔の話ですが、Twitterスキマスイッチの『私はロボットではありません』の難易度が高すぎるwことが話題になりました。 詳細は、以下のTogetterに纏まっていました。

togetter.com

たしかに・・・難しい・・・

難しい・・・

わからんーーーーー!!

助けてーAmazon Rekognitionーーー!!

Amazon Rekognition

AIによる画像認識および画像分析を行うAWSのサービス。(雑っ)

検証開始

というわけで、Rekognitionさんならなんとかしてくれると思い、画像比較のデモを使ってスキマスイッチの『私はロボットではありません』が見破れるかを試してみました。

f:id:special-moucom:20191210000738p:plain

こんな感じで、左に参照画像。右に比較対象をセットします。
左の参照画像ですが、スキマスイッチの画像をネットで探していたら、BESTアルバムの画像が比較対象の2行目の一番端に該当したので、これをそのまま使いました。

Amazon Rekognitionの結果

こんな感じで、比較結果が出ました。

f:id:special-moucom:20191210001406p:plain
f:id:special-moucom:20191210001429p:plain
f:id:special-moucom:20191210001442p:plain
f:id:special-moucom:20191210001456p:plain
f:id:special-moucom:20191210001508p:plain

すごいっ、ちゃんとスキマスイッチを認識しているっ!!!
私自身、初めてRekognitionを使いましたが、これほどちゃんと顔認識するなんて驚きです。

というわけで、まとめ

Amazon Rekognitionがスキマスイッチと認めたのは以下の赤丸です。 f:id:special-moucom:20191210001657p:plain

Togetterによれば、正解の模様。
いやぁ、ネタでやってみたけどAmazon Rekognitionの凄さが垣間見れました。

近況

最後に近況でも・・・興味がない方は飛ばしてOK。
現在、AWS認定資格を取得すべく勉強中です。
2年前にも取得した資格ですが、2年前とはサービス内容が変わっており、ほとんど覚え直しです。(トホホッ)
2年前とは違い、子供もいてなかなか勉強時間が取れずに辛い状況が続いています。
とはいえ、2年前と比べて情報も増えてきたし、Udemyという動画教材もあるわけで・・・やりようはいくらでもあるはずっ!!
めげずに頑張りたいと思います。

という、自分に言い聞かせる近況でした。おしまい!

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

はじめに

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

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

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

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

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

河内瞬さんは普段、エッセイ漫画を書かれる事が多いのですが、今回出された本は漫画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. 認証の標準的な方法は分かった。では認可はどう管理するんだい?(都元ダイスケ)

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のネットワークとボリュームもキレイになりました。(めでたし、めでたし)