ばったログ

3回に１回くらいはやったことをアウトプットしていく

件名が異なるメールが同一スレッドにまとめられているのをなんとかする

Tips

概要

稼働中のシステムから送信され、Gmailのアドレスで受信したメール。
異なる件名であるが同一スレッドにまとめられてしまっている。

件名の例)
[Aシステム]バッチ処理を終了
[Bシステム]バッチ処理を終了

上記２つのメールが、意図せず同一スレッド表示されてしまう。

原因

タイトルの最初に[]で囲まれた部分があると この部分も無視して後ろの部分が同じであれば同一スレッドと判断されます。

例えば、あるサーバーからのメッセージを管理していて、

[INFO] From example server
[ERROR] From example server
と言った様に、エラーメッセージ等を送る際、そのメッセージレベルを[]で囲い、 その後ろは単純な形で同じ内容であると同一スレッドにまとめられます。

対策/解決方法

件名に使っている記号を[]から【】に変更　　

感想

挙動さえわかれば、日毎のメールをスレッド別にまとめるなど便利に使えそう。

Elastic Beanstalkのeb create時にCreating load balancer failed Reason: At least two subnets in two different Availability Zones must be specified で怒られた時の対処法

AWS Tips

前提

  • EB CLI導入済み

現象

eb createコマンド実行後の対話実行中、ロードバランサーの選択後ににエラーが発生する。

eb create

(中略)

Select a load balancer type
1) classic
2) application
3) network
(default is 2): 2 // アプリケーションロードバランサーを選択
Creating application version archive "app-885e-190925_224850".
Uploading elastic-beanstalk/app-885e-190925_224850.zip to S3. This may take a while.
Upload Complete.
Environment details for: elastic-beanstalk-dev
  Application name: elastic-beanstalk
  Region: ap-northeast-1
  Deployed Version: app-885e-190925_224850
  Environment ID: e-xsgzypm6xc
  Platform: arn:aws:elasticbeanstalk:ap-northeast-1::platform/PHP 7.2 running on 64bit Amazon Linux/2.8.15
  Tier: WebServer-Standard-1.0
  CNAME: elastic-beanstalk-dev.ap-northeast-1.elasticbeanstalk.com
  Updated: 2019-09-25 13:48:54.541000+00:00
Printing Status:
2019-09-25 13:48:52    INFO    createEnvironment is starting.
2019-09-25 13:48:54    INFO    Using elasticbeanstalk-ap-northeast-1-369347037906 as Amazon S3 storage bucket for environment data.
2019-09-25 13:49:16    INFO    Created target group named: arn:aws:elasticloadbalancing:ap-northeast-1:369347037906:targetgroup/awseb-AWSEB-1CMBZGU29V9B4/493ad61810a2f151
2019-09-25 13:49:16    INFO    Created security group named: sg-0d3a5ce3ba89653ad
2019-09-25 13:49:32    ERROR   Stack named 'awseb-e-xsgzypm6xc-stack' aborted operation. Current state: 'CREATE_FAILED'  Reason: The following resource(s) failed to create: [AWSEBV2LoadBalancer, AWSEBSecurityGroup].
2019-09-25 13:49:32    ERROR   Creating load balancer failed Reason: At least two subnets in two different Availability Zones must be specified (Service: AmazonElasticLoadBalancingV2; Status Code: 400; Error Code: ValidationError; Request ID: dc2450c6-8e73-438c-b8ce-15bde8766595)
2019-09-25 13:49:32    ERROR   Creating security group named: awseb-e-xsgzypm6xc-stack-AWSEBSecurityGroup-1CMTPYPR86GNF failed Reason: Resource creation cancelled
2019-09-25 13:49:35    INFO    Launched environment: elastic-beanstalk-dev. However, there were issues during launch. See event log for details.

原因

デフォルトのVPCやサブネットに問題がある
エラーコメントからだいたい推測できる

Creating load balancer failed Reason: At least two subnets in two different Availability Zones must be specified (Service: AmazonElasticLoadBalancingV2; Status Code: 400; Error Code: ValidationError; Request ID: dc2450c6-8e73-438c-b8ce-15bde8766595)
  • ロードバランサーを作ろうとしたけどサブネットがマルチAZになっていないぞ
    • そもそもデフォルトでは デフォルトVPCにAZごとにごとにサブネットが作成されている
      • 日本だと３つのデフォルトサブネットが作成されているはず
    • 何らかの原因、例えばハンズオン終了後に環境をクリーンにするためにサブネットを削除しまくったら、知らぬ間にデフォルトサブネットを削除してしまっていたなどの理由でデフォルトのサブネットが１つしかないといった状態に陥っている

対処法

方法1 デフォルトVPCの再作成

デフォルトVPCを削除後、再度作成することでデフォルトサブネットがAZ毎に存在する状態に戻る。
こちらの方法を試したところ、残り１つとなっていたデフォルトのサブネットが無事３つになり eb createも実行できた。
ただし、色々と利用されているかもしれないのでデフォルトVPCの削除はくれぐれも慎重に。

方法2 eb create時に使用するvpcを明示的に指定する

オプション指定(--vpc.id)により、デフォルトのVPCではなく既存のvpcを指定することができる

参考

感想

お金がかかるのが怖いからといって、考えなしに何でもかんでも削除するのは気をつけよう。
でも、こういう罠に早めに引っかかって置くのが大事だと思ってたり。
(そもそもデフォルトVPCとかデフォルトサブネットが削除できちゃうのが怖いんですが)

Laravelをもう一度

環境構築

Laravelを近々お仕事で触りそうなので復習しようと思ったら
以前試した開発環境が起動せず、コードがそのまま動かせない＼(^o^)／

ということで、最近はどんな感じで環境構築するのか調べたら
Laravelの開発環境をDockerを使って構築する - Qiita
こちらの記事が大変参考になったので、もう一度環境構築からやり直す。

開発環境比較

前回 今回
Laravelのバージョン 5.5 5.8
開発環境 Virtualbox(Homestead)を利用 Dockerを利用
教材 絶対に挫折させないアプリ開発　はじめてのLarval

準備

コンテナの準備

上記参照記事のハンズオンにだいたい書いてある通り
環境構築の準備で使ったコマンドは

$ git clone https://github.com/ucan-lab/docker-laravel.git
$ cd docker-laravel
$ docker-compose up -d --build

これで一通り必要なものが揃うので、あとはLaravelの準備

appコンテナへの接続

以下の２つ方法を利用してみた
どちらにせよ、コンテナ内からartisanコマンドを叩いてます

Kitematicを利用して接続

execボタンを利用 f:id:madades_k:20190923211750p:plain

VSCode からの接続

(要:VSCodeのDocker拡張 ) 状態:runningのコンテナに Attach f:id:madades_k:20190923211811p:plain

感想

Homesteadはhostsの設定とかSSLで色々大変だった覚えがあるので、今回すんなり環境が準備できてよかった。
前回の記事でのGrowiの構築時も実感したが、環境設定済docker-compose ファイルさえあれば手軽に試せるのでありがたい。
ただ、仕組みを深く理解せずに使っちゃってるので(今は特に永続化周りが心配)その辺は必要に迫られた時に改めてキャッチアップしておきたい。

参考リンク

絶対に挫折させないアプリ開発　はじめてのLaravelの元ネタでもある Laravelのチュートリアル、「基本のタスクリスト」のLaravel6.0用の捕捉入り。
Laravelの開発環境をDockerを使って構築する - Qiitaと同じ@ucan-labさんの記事。そのうち試す。

GROWIでどんなwikiが作れるのか確認したいなら、まずは開発者wikiを見てみよう

カイゼン Tips

社内ナレッジ蓄積のためにwikiの導入を検討中。GROWIがかなり良さそうだったので調べた記録。

GROWIとは

Crowi派生の最強のWiki
最強のWiki「Crowi」のフォーク、「GROWI(旧crowi-plus)」を公開した話 - Qiita
最近ではSaaS型wikiとしての提供も始まっている
GROWI.cloud - 情報共有をもっと身近に、もっと手軽に
オープンβ中とはいえ、ライトプランだと324円/月で
３０ユーザーまで利用可能ってのはすごい(これも選定した理由の一つ)

GROWIでこんなwikiが作れる

今回の本題
GROWIには自由に記事投稿ができるデモサイトがあり、記事の入力方法は確認できたがイマイチwikiの活用イメージができなかった。
そこで、GROWIを利用したwikiがどこかに公開されていないか探して見たところ、GROWI Developers Wiki(開発者wiki)がとても参考になった。
/ - GROWI Developers Wiki

  • TOPページの構成がそのまま参考にできそう。
  • 記事も具体的に作成されているので、活用イメージができる。

あと、このTOPページ見て特にいいなぁと思ったのがこれ 各階層の投稿記事を一覧化できるやつ、こんな書き方すれば表示可能。 f:id:madades_k:20190916233152p:plain

これはpukiwikiにもあった任意のページの下の階層のツリー表示を行う事ができるプラグインを移植したらしい。
Qiitaの記事でも言及している)だけあって、こだわりポイントの様子。実施、便利そう。

感想

Markdownで書けることと、できれば料金お安いところでwikiをいろいろ探していましたが
その中でも、かなり使いやすそうな印象。まずは自分で使い込んでから、広めていく予定。
今回wiki本体の機能には触れていませんが、googleOAuth2 認証でのログインとかテーマ切り替え機能など
なかなかにいじりがいがありそうな機能が豊富でした。
布教活動に専念するためにも、自力構築ではなくでできればGROWI.cloudが使いたい
(そのためには稟議とか通さないとダメそうなのが心配ですが)

参考リンク

Amazon Linux 2 でもwinexeが使いたい

Tips

Amazon Linux 2 でもwinexeが使いたい

AWSのLinux機(Amazon Linux 2)からWindows Server機向けバッチを叩く必要があったので、色々試した時の記録

winexeについて

Linux から Windows 上のコマンドを実行することができるツール

この記事について

取り扱うこと

取り扱わないこと

1.VagrantでAmazon Linux2を動かす

全く触ったことのなかった Amzon Linux 2 をいじってみたいけど、EC2のインスタンスをぽんぽん立てる権限は持っていない
そんな自分がローカル環境で色々試すために使っていたのが Vagrant の Amzon Linux 2 のBoxイメージ
Vagrantの説明も省いてコマンドだけ載せときます。

vagrant init bento/amazonlinux-2
vagrant up 
vagrant ssh

bentoのboxはchef社のプロジェクトということで野良Boxよりは安心だと思いますが、
正式な導入方法はAmazonでもアナウンスされているので、そっちの方がより安心な様子。
* Amazon Linux 2 を仮想マシンとしてオンプレミスで実行する - Amazon Elastic Compute Cloud * VagrantでAmazon Linux 2を実行する ｜ DevelopersIO

2.AWS上のAmazon Linux 2 でのwinexeの準備

ローカル環境下のAmazon Linux 2 で試行錯誤の後、
EC2上のAmazon Linux 2 に実際に打ったコマンドを載せていきます。
(root権限で実行しています。ログは省略)

パッケージの追加

amazon-linux-extras install -y epel
yum update -y 
yum install -y gcc \
  perl \
  mingw-binutils-generic \
  mingw-filesystem-base \
  mingw32-binutils \
  mingw32-cpp \
  mingw32-crt \
  mingw32-filesystem \
  mingw32-gcc \
  mingw32-headers \
  mingw64-binutils \
  mingw64-cpp \
  mingw64-crt \
  mingw64-filesystem \
  mingw64-gcc \
  mingw64-headers \
  libcom_err-devel \
  popt-devel \
  zlib-devel \
  zlib-static \
  glibc-devel \
  glibc-static \
  python-devel \
  gnutls-devel \
  libacl-devel \
  openldap-devel \
  jansson-devel \
  lmdb-devel \
  gpgme-devel \
  libarchive-devel \
  pam-devel \
  gdb

sambaのソースコード取得とconfigureまで

mkdir -p /usr/local/src/samba
cd /usr/local/src/samba
wget https://download.samba.org/pub/samba/samba-latest.tar.gz
mkdir samba-latest 
tar zxvf samba-latest.tar.gz -C samba-latest --strip-components 1
cd /usr/local/src/samba/samba-latest
PYTHON=python2 ./configure

winexeに必要なパッケージ(mingw32,64系)がインストールされているかを確認

cat /usr/local/src/samba/samba-latest/bin/config.log | grep HAVE_WINEXE_CC_WIN

出力結果でこのような表示が出ていればOK

#define HAVE_WINEXE_CC_WIN32 1
#define HAVE_WINEXE_CC_WIN64 1

最後にビルドとインストール

PYTHON=python2 make
PYTHON=python2 make install

winexeバージョン確認

/usr/local/samba/bin/winexe --version

出力結果

winexe version 4.10
This program may be freely redistributed under the terms of the GNU GPLv3

感想

Amazon Linux 2 はCent OS7互換だからその辺を参考にすればいけるかと思ったら、思いの外大変だった。
EC2の標準のAMIにCent OSがないので(Red Hatはあるけど) Amazon 的には こっちを推してきたいのだなというのは伝わった。
なお、導入したwinexeはその後問題なく利用できているが、バッチで使うとき id pass を平文で置いているので(一応権限設定はしているが)、この辺をなんとかしたい。

参考リンク

新しくなったwinexe - Qiita

この記事を参考に、以下の変更を加えています。
* epel-release の部分をAmazon Linux 2 用に変更 * sambaのソースコードをgit cloneから直接wgetで最新版を取得する方法に変更 * 初期導入済みのPython2.7系で実行できるように環境変数設定

AmazonLinux2 に最新の Samba4.10.5 をドメインコントローラとしてインストールする - らくがきちょう

Amazon Linux 2 にsamba導入記事
この記事で紹介されている導入パッケージ群にmingwXX系を加えることで
winexe も 使えるようになります。

tar(1) でアーカイブ前の名前ではなく新たな名前のディレクトリで展開したいときのメモ - Qiita

tar 解凍時のフォルダ名を指定することでsambaのバージョンが変わっても対応できる(はず)

[読書メモ][技術書典5]『絶対に挫折させないアプリ開発　はじめてのLaravel』を挫折せずに読んだメモ

Books Tips

最近PHPを勉強し始めたのですが、一緒にフレームワークも勉強してしまおう!と思っていたところに良さそうな本があったのでその読書メモ

【ダウンロード版】絶対に挫折させないアプリ開発　はじめてのLaravel - plumsa - BOOTH a0ec82c4-cfcc-4827-a937-40583dee6339_base_resized.jpg

対象の読者

  • Progateやドットインストール、入門書等でPHPの基礎を習得している人
  • Laravel を始めてみたが、公式チュートリアルをはじめとするネットの情報源がよく理解できない人
  • 公式サイトなどの説明をみて開発環境を自力で構築できる人
    • 環境構築の参考になるサイトの紹介はありますが、「XXXからインストーラーをダウンロードして...」といった手取り足取りな説明はない
    • (私はHomesteadで環境を作り、設定ファイルなどは適宜読み替えて写経などを行いました)

目次

第 1 章 はじめに
第 2 章 Laravel とは何か
第 3 章 アプリ開発のフローを考える
第 4 章 PHP 開発の準備をする
第 5 章 はじめての PHP 開発 〜TODO アプリを作ろう〜
第 6 章 Laravel 開発の準備をする
第 7 章 はじめての Laravel 開発 〜もう一度 TODO アプリを作ろう〜
第 8 章 2 度目の Laravel 開発 〜さらにもう一度 TODO アプリを作ろう〜
第 9 章 本書を読み終えた後に広がる世界

よかったところ

Laravelチュートリアルが詳しい解説付きで学べる

TODOアプリを３回作ることでコードや実装の比較ができる

  • 5章と7章では素PHPとLaravelを利用した場合の実装の比較
  • 7章と8章ではルーティング部分に偏った処理を「役割分担」を念頭に置いてリファクタリング
  • 設計についても意識でき、Laravel をより実践的に活用しようと思ったときの土台となる

勉強や開発を行う際の情報源が紹介されている

  • 手取り足取りは教えないが道は示す、というスタンス
  • 公式サイトや参考サイト、コミュニティが多数紹介されている

次にやること

  • PHP７系の文法の習得
  • Laravelチュートリアルの続き
  • 『体系的に学ぶ 安全なWebアプリケーションの作り方』
    • そもそもこの本のサンプルコードがPHPで書かれていたのも、学習のきっかけ

紹介されていたサイトなど(一部抜粋)

公式サイト

参考サイト

コミュニ二ティ

TDD+モブプログラミングでワイワイする会 その16に参加してきました

Event

TDD+モブプログラミングでワイワイする会 その16 - connpass

Agile Japan 2018の基調講演(沖繩サテライトに参加していました)を聴いてモブプログラミングに興味を持ったので、参加した時のメモ。

外では琉大祭でガヤガヤの中、こちらのイベントには14人も集まってワイワイしてました。
ちなみに近くでポケモンGO研究会?の出し物をやっていました。

(↓当日のスライドではないが、内容はほぼ同じようだったのでなので引用)

このサイクルでドライバーを交代するルール
テンポよく交代できるし、TDDのお作法に乗っ取って"筋トレ"してほしいとのこと。

モブプログラミング1回目

  • 言語はRuby/RSPec お題はFizzBuzz
  • いきなり実装ではなくFizzBuzzに必要なことをTODOリストにまとめる(これがテストケースの元となる)
  • だいたい以下の流れでドライバーを交代して、ワイワイとモブプログラミングを行った
    • ①Red→Green:テストが通った!と皆で拍手して称え合う
    • ②Green→リファクタリング:ナビゲーター同士で相談。テストを通るためだけに書かれたコードからイケてる感じになるようにコードをリファクタリング
    • ③テスト追加→Red:皆で(大げさに)がっかりする。急いでGreenにしなきゃとドライバー交代。①に戻る
  • 実装はだいたいわかっているだけに、なかなかテストケースを書けなかったのがもどかしかった
  • テストのコメント部分についてはどんなことを書けばいいのかナビゲーター役の時に色々検索した
  • 参考：【Ruby on Rails】RSpecのdescribe/context/itの意味を理解した件

1回目終了後はコードレビューしたり、RSpecのテストコメントには何を書くべきかというプチ講座が開催されていました。

モブプログラミング2回目

  • 人生初のHaskell お題はFizzBuzzPlus(31 など 3が含まれている場合にも Fizz になる)
  • Haskelが使える方がいたので、途中からHaskell講座が始まり、関数型プログラミングがちょっとわかった(ような気がした)

2回目も、知っているお題 x 知らない言語 だといい感じに盛り上がりました。

わかったこと

  • モブプログラミング面白い
    • ドライバーは「有機キーボード」
    • ナビゲーターは「司令塔」。意見を出し合ったり、手が空いてる人が先回りして文法を調べたりしながらコードをより良いものにしていく
  • テスト駆動 は テスト手法 じゃない 開発手法 だ！
    • 分析技法であり、設計技法であり、実際には開発のすべてのアクティビティを構造化する技法
  • ボブおじさん(Robert C Martin)ってすげー！
  • TDDでテストを書く筋トレしよう
    • まずはテストファースト書きで習慣を身につける
    • 業務に取り入れる場合はまずは、コード実装後で良いのでテスト書くようにする
      • テストの無いコードはレガシーコード

次にやること

  • 『テスト駆動開発』(新訳)を読む
    • スライドにも登場しており、お勧めされていた
    • 「付録C」にはTDDをとりまくここ 20 年の動きについてよくまとまっている(らしい)

でもまずはIPAの試験が控えてるので、そっちを頑張る。