reactをまだマスターしていなかった件

「え？こんな書き方あるのか、知らなかったわ〜」と思ったのでメモる笑

まあまずはこれですな・・・

---

ループ処理

配列のループ処理！意識していなかったわけではないんですけどね、、反省。。

forEach

連想配列(object)だと使えないんですけどね、ただ指定のarrayを回すときに使う

[1, 2, 3].forEach( (element, index, array) => {
  console.log(index + ":" + element);
});

indexとarrayは省略可能ですー！

map

新しい配列を作成したいときに使う感じですな

const elementSquareArray = [1, 2, 3].map( (element, index, array) => {
  return element * element;
});

 こちらもindexとarrayは省略可能でっす！returnで返してあげましょ！

filter

条件にあうものだけを抽出したいときに使います

const evenNumberArray = [1, 2, 3].filter( (element, index, array) => {
  return (element % 2 === 0);
});

reduce

処理をして1つの値を取得。
previousValueは前の値というより、それまでの結果と考えるとわかりやすいかもです

const total = [1,2,3].reduce( (previousValue, currentValue, index, array) => {
  return previousValue+currentValue; 
}); 


### total=6になる

every、some 

これ使ったことないですけど・・・

everyは条件を全ての値が満たすか、someは条件を満たすものがあるかの判定。
結果はbooleanで返ってくるらしいです 

const everyEvenFlag = [2, 4, 6].every( (element, index, array) => {
  return (element % 2 === 0);
});

const someEvenFlag = [1, 2, 3].some( (element, index, array) => {
  return (element % 2 === 0);
});

---

render

なにを返すのか問題ですね、返す型はそろえましょ！

はい、すみません。僕は適当にやってました・・・

何も描画したくないときにnullまたはfalseを返すことでそれを実現することができます。実際には裏で<noscript>タグを描画します。 なんでそういうときは

return <noscript/>

とするとよいかもですね

---

JSXのif文

jsx内のrender部分でif文書くとき即時間数を使って書くことが多いと思いますが、いかんせん括弧が多くて見にくくなってしまいます。

{(() => {
  if (this.props.count >= 3) {
  return  (componentとかviewを返す);
  }
})()}

こんなときに使える書き方があります、それがrenderのときの理論です。falseやnullのときはなにも表示されないのでそれを使うと以下になります。

{(this.props.count >= 3) && (
  return (
    componentとかviewを返す
  )
)}

見やすい！！

わかると思いますが、最初のif文でtrueのときの処理しか使えません。なので最初からif~elseで分けるものに対しては即時間数で書くしかありません。

react使って3ヶ月くらいですが、まだまだ知らないことがありそうなので詰めていきたいものです。

終わり。

railsとrubyの相性

rubyとrailsのバージョンを上げることになったが、一つ疑問に思いました。

適当にどっちも手間なくあげれるとこまで上げれば良いのかな・・・？？

ビルド時にどのくらい速度に差があるのか気になったので調べてみました。

準備

ruby 2.2.0、2.3.0、2.4.0をrbenvでインストールしておく

コード

RUBY=("2.2.0" "2.3.0" "2.4.0") 
for ruby in ${RUBY[@]}; do
  export PATH=$RBENV_ROOT/shims:$PATH
  rbenv global $ruby >/dev/null 2>&1

  RAILS_VER=("4.0.13" "4.2.8") 
  for rails_ver in ${RAILS_VER[@]}; do
    gem install rails -v $rails_ver >/dev/null 2>&1
    if test $rails_ver = '4.0.13' ; then
      gem uninstall rails -v "4.2.8" >/dev/null 2>&1
      gem uninstall railties -v "4.2.8" >/dev/null 2>&1
    else 
      gem uninstall rails -v "4.0.13" >/dev/null 2>&1
      gem uninstall railties -v "4.0.13" >/dev/null 2>&1 
    fi
    rbenv rehash
    ruby -v
    rails -v
    rails new rails_${rails_ver}_speedtest -d mysql >/dev/null 2>&1
    echo "gem 'spring'" >> ./rails_${rails_ver}_speedtest/Gemfile
    cd ./rails_${rails_ver}_speedtest
    bundle install --path vendor/bundle >/dev/null 2>&1
    bundle exec spring rails g scaffold blog title:string description:string >/dev/null 2>&1

    echo spring
    for i in {1..10};do
      bundle exec time spring rake routes | grep real
    done 2> routes.txt
    awk -f ../ave.awk routes.txt
    cd ..
    rm -rf ./rails_${rails_ver}_speedtest
  done
done

結果

何度もやってもこのくらいに落ち着くのでやはりビルドに差があると言ってもいいのではないでしょうか。。。ちょっと今回はしょりすぎてrake routeでやったのがセンスなかったですね笑

あと追加でrails5もやったっていうのがruby2.2.0を使っているところからバレバレですねw

まとめ

rubyとrailsのバージョンの相性はありそう。

ただ今回rake routeでやってしまったので差があまり明確にならず。

またバージョンのどこに差があるのかというところまで調べていない。

DBの本を読み終わった後、ここについてもう一度追加調査していたいと思います。

終わり。

実装工数の見積もりの精度を高めるために

最近、長期間にわたる実装が多く、そのときに工数を見積もるの結構大変だったなと思ったのでそのときの振り返りも兼ねて書きます。

そもそも実装段階〜リリースするまでにやらなくはならないことは以下だと思います。

雑ですね・・笑。。。。まあ、いいか。

まずこのことは押さえておかないといけないなと思いました。

え？と思った方もいると思いますが、結構認識ずれます。

特にシステムに関与していない他のチーム、例えばセールスチームに共有するときなどはどこまでのフローのことを話しているのかというのをまず共有すべきだなと思います。

一旦定義を確定しておこうかなと思います。

個人的には

・見積もり・・・全タスクとその工数を洗い出すこと → 全体感、規模感を算出

・スケジュール・・・そのタスクにかかる時間を算出する

というイメージです。

ここから個人的に良かったなと思った進め方についてです。

• 見えていない部分はおいといて見えている部分でまずタスク分解する

やることは主に2つ。

・作るべきものをタスクに分解する

・次にタスクの工数を算出する

これができれば良いのですが、全然先が見えなかったりするものもあります。

そのときはこれをざっくりやります。今見えている部分だけでもよいのでやるイメージです。

例えば、Aという機能を実装するときに「Aを完了するには全体としてやることはa、b、cがあるんだけど、bに関してよくわからない部分が多くそれもa次第なんだよなー」となったときはとりあえずaだけは細かくタスク分解していきます。b、cに関してはざっくり今考えられることとしてこれくらいありますくらいでよいかなと思います。そして肌感で工数をふればよいかな程度です。

• 中間地点もしくは期間で区切って再度、見積もり直す期間をつくる

そして実際に行動に移していくのですがここでポイントがあります。それは見積もりをもう一度見直すタイミングを作ることです。

例であげたとおりb、cに関してざっくりとしか見積もってないので必然的にやることにはなるのですがそのタイミングはaのタスクを消化している途中です。一旦手を止めてでもやるべきだと思っています。

重要なのは「見えているor見える可能性があるならそこまで考えて、タスク分解してから手を動かしましょう」ということです。

仕事である以上、何をどのくらいの期間でやろうと思っているのかというのはすべてのチームへ説明する責任はあるのでそういった意味を含めてもやらないといけません！

• ターニングポイントを意識する

あとは最後にスケジュールを作成するときに、スケジュールがどのくらい幅ができそうなのかとその幅のターニングポイントとなる場所を算出しておきましょ。 スケジュールの幅というのは最短期間と最長期間との差のことです。そしてそのターニングポイントとはある意味でボトルネックといってもよいかもしれません。タスク分解すると「これらをこの期日までに最低やってないと間に合わなくない？ってことは今週はここまでがmustだよね、ってことはこれが延びた時点で見直したほうがよさそうなよね」という”これが”の部分です。

• 個人的感想

個人的にはこうやってやることでやるたびに精度を高められるし、共有も楽だしおそらく聞いている人たちも状況が伝わりやすいのではと思っています。

実際のリリースまで持っていくので一番難しいのはスピードと質のバランスを取ることです。良いものを最短で出せれば良いのですが、毎回そういうわけにもいかないときがあります。そういうときはどう判断するのかは結構難しいところではありますが、そういった議論が発生することを踏まえて見積もりできると良いですね。

終わり。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

データーベース入門①

さて、宣言通り技術についてアウトプットしていこうかなと思います。

題材は「DBについて」です！

Webアプリケーションをずっと作ってきたのでアプリケーション周りは結構強いのですが、DB周りについてはまだまだ穴があるので今回はそこについて「理論から学ぶデーターベース実践入門」を読んで抑えていきたい思います。

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

まずは第一回ということでそもそものところから書いていこうと思います。

• データベースとは

ここからやらなくてもいいんじゃない？と思いますが、一応やっておきます笑。

wikipediaさんに聞いてみると

データベース（英: database, DB）とは、検索や蓄積が容易にできるよう整理された情報の集まり。 通常はコンピュータによって実現されたものを指すが、紙の住所録などをデータベースと呼ぶ場合もある。 狭義には、データベース管理システム (Database Management System, DBMS) またはそれが扱う対象のことをいう。

つまり特定のテーマに沿ったデータを集めて効率的に管理し、使いやすくしたものと考えてもらって良いと思います。ちなみにもう少し調べてみたら実は・・・・

データベースという名称は米軍からきているらしいです。第二次大戦後の米軍が、そこにアクセスすればすべての情報が得られるように、点在していた膨大な量の資料をひとつの基地に集約して効率化を図ったらしいです。この際にデータベースという言葉が誕生したと言われているらしい・・

そしてそんなデータベースですが種類があります！大きく分けると以下４つに分けることができます。

「階層型」「ネットワーク型」「関係型」「NoSQL」

一つずつ説明していってもよいのですが、ちょっとそれをしちゃうと肝心の話まで届かないで終わってしまう気がするので割愛します笑

参考リンクを貼っておきますので興味のある方はこちらをどうぞ！！

ざっくり説明が書いてあります↓

programming-study.com

図がわかりやすいかもです↓

www.techscore.com

NoSQLについての説明あります↓

www.sejuku.net

業務ではSQLを使用しているのでRDBについて書いていきますー　

( ´ ▽ ` )ﾉ　あっ「関係型」のことです。

• SQLとは

SQLとは、リレーショナルデータベース(以下RDB)に対して問い合わせを行うための言語のことです。そしてSQL はリレーショナルモデルをベース設計されておりリレーショナルモデルに沿った演算が得意です。なのでSQLを理解するにはRDBについて理解しなければならないということになります。逆にいうとRDBを理解しないとSQLについて理解できたとは言えずそれは単になんとなく書けるというレベルでしかありません。

• リレーショナルモデル

現実世界のデータを「リレーション」と呼ばれる概念を用いて表現するデータモデルのこと。ここで注意したいのがあくまでも、リレーショナルモデルが表すデータモデルは 設計という意味ではなく、データをどのように表現するか、という概念の話だということ。「○○という概念を使ってデータを表現してください」という決まりごとがデータモデルであり、リレーショナルモデルはその中の一つにすぎないということになります！

• リレーションとは

最もよくある間違いとしてあげられていたのが、「テ ーブル同士の関係」というものです。概念にすぎないという説明をしたと思うので理解されていると思いますが、テーブル同士の関係を(ER 図などを使って)デザインするのはリレーショナルモデルではありません。SQLにおいてリレーションに相当するものは、テーブルです！

言葉だとだとわけわからないと思うのでずを載せておきます。

                        

説明書きとしては以下でした。

リレーショナルモデルにおけるリレーションの定義は次のようなもので す。リレーションは見出し(Heading)と本体(Body)のペアで構成されます。 見出しは、0でないn 個 の属性(Attribute)の集合です。この属性は、名前とデー タ型のペアになっています。本体は、属性値の集合である組、あるいは英 語で言うとタプル(tuple)の集合です。

タプルに含まれる属性値は、名称とデータ型が見出しで指定されたものと、それぞれ一致していなければなりません。

見出しで定義されていない属性が存在したり、逆に見出しに含まれる属性がタプルに存在していない場合は、ルール違反です。

つまりリレーションとはタプ ルの集合であり、タプルはすべて同じ n 個の属性値の集合という同じデー タ構造を持っています。図 1.1 は、リレーションをイメージ化したもの。

今回はここまでにしておこうかな・・・ここまで理解するとわかりますが、結局集合体でしかありません。だからもっと理解を深めるにはその集合体の話を知っておく必要があります。なので次はそこから始めれればなと思います。

終わり。

目標の立て方

気がつくと全く技術のこと書いていないので次回から技術の話をする！とまず最初に宣言しておきまする！

で、今日はTedで「死の直前に人がとる行動は3パターンに分かれる」というなんとも面白そうなテーマがあったのでそのことについて少し思ったことを書きます。

www.youtube.com

• 3パターンの行動とは

1. 宗教や文化的背景に関係なく、許しを請う
2. 記憶への願望
3. 魂に触れる

どれもドラマとかで結構見かけるシーンだなと思いますが、順に説明していきます。

・許しを請うというのは「自分の時間を自分勝手に使わずに、子どもたちや孫たちともったたくさんの時間を過ごせばよかった」というような後悔を含んだ感情のことを指します。

・記憶への願望というのは、「私を覚えていてくれる？」「「私を忘れないで」と人の心のなか、頭の中で永遠でありたいという感情のことを指します。

・魂に触れるというのは、自分の人生に意味があったのだと思いたい感情のことを指します。自分の人生を意味のないことのために無駄に費やしはしなかったということでこれは許しを請うに似て非なる感情です。

個人的にこういう視点からも物事を考えられると異なるものの見方ができて良いなと思いました。前回「大きな目標を持とう」と書きましたが、みんながみんな初めからそのような考えかたができるとは思いません。そもそも僕も持てないタイプだったので・・

僕はどちらかというと「ボトムを決める」という考え方が先行していました。「いついつまでにこれができなかったらクソだな」「〜年目でこういう扱いだったらへぼいな、かっこ悪いな」という感じです。そこからその要素を逆転させ「こういう人にならないためには何をするべきなのか」と考え、それを目標にしてました。

まあ何が言いたいのかというと、人は「ポジティブに未来を描いてそれを為すために行動する」と「ネガティブに未来を描いてそれにならないために行動する」の2パターンの目標の立て方のアプローチがあるのではないかということです。目標を決めることは何をおいても大事なことなのでもしまだ持ててない人、よく分からないという人は「最低ラインを決めてそれを逆転させて目標にする」というアプローチをしてみてはいかがでしょうか。

最後に「好きはものの上手なれ」ということわざがあるようにどうしても「興味がある、楽しい」と思って行動している人には勝てないのでだんだんポジティブな目標設定ができるようになると良いですね。

終わり。

壮大な良い目標をもつことが結構大事

sao-movie.net

SAO(ソードアートオンライン)の映画、オーディナル・スケールなるものを見に行ってきました。しかも無駄にMX4Dです笑。

MX4Dはアメリカのロサンゼルスで1991年に発足したMediaMation社によるもので2012年頃から色々な劇場で使われ始めたようです。日本では、2015年4月10日にオープンしたTOHOシネマズ ららぽーと富士見での展開が初となりました。

MX4DはTOHOシネマズ独自の「TOHO 4D PROJECT」のもと展開される、TOHOシネマズだけの映像アトラクションシステムとなりますので、限定された劇場だけでしか体感することができません。

また、以下が体験できます。

・シートの突き上げ　・首元への感触　・背中への感触　・香り　・風　・水しぶき　・足元への感触　
・地響き　・突風　・霧　・ストロボ

いやー、やはりあの世界に夢を持ちますよね〜〜〜、、、とまあ今日からの3連休を早速夜更かしからスタートしている訳ですが、そんな中「最強のNo.2」という本を読んだのでそれのアウトプットでもしようかなと思います。

最強のNo.2 (U25 SURVIVAL MANUAL SERIES)

この本は2013年に出たものでサイバーエージェント取締役の曽山さんの著書。ここでいいう「最強のNo.2」というのは以下であると冒頭で定義してくれている。

「最強のNo.2」を言い換えれば、誰かにとって「必要不可欠な存在になる」ということだ。メンバー、上司、経営者、つまり会社にとって必要な人になれば、それは社会にとって必要な人となる。

大きなことを成し遂げようとすると一人ではできない、だからこそ仲間が必要だしその仲間たち自身が”組織”を強くしていく必要がある。こうすることで会社は成長し、意味ある価値を世の中の人たちにより多く与えることができる。そのためには全員が組織に目を向ける必要があるし、その組織・その会社で必要不可欠な人間になることができれば社会にとっても必要な存在になることができる。では、そのためには何をすればよいのでしょうか？その答えに近づける考え方が紹介されている本といっても過言ではない内容だと思います。

そこまで内容が長くないので全て紹介してもよいのですが、文章にすると長くなりそうな気がするので心に残ったことをピックアップしたいと思います。姿勢・マインド・やりかたの３つにわけて記述できればと思います

姿勢

この本では以下3つを紹介しています。

• 自分の中に問いを持つ
• 『ANDの才能』で考える
• とことん素直でいる

この中でも『ANDの才能』で考えるは当たり前ではあるのですが改めて「なるほどな〜」と感じました。これどういうことか「会社AND自分」になるように思考し、実行していくということです。会社への貢献を通じて自分のやりたいことをやるというまさにどちらかひとつではなくどちらも手に入れてしまおうという発想です。逆にORで考えるというのは、会社に所属していたら自分のやりたいことができないといった発想のことです。「これがやりたいんだ！！」という人はそれが会社の貢献になるようにつじつまを合わせれば良いだけである。逆にそういったやりたいことがない人はどうするのか、これに関しては会社がこれからどうなっていくのか、そのためにどういうことをしていくべきなのかといった事業戦略的なことから落とし込んで興味ありそうなもの、取り組むべきものというのを洗い出すのも手かもしれません。

というか個人的には後者の発想でしたww「なんか技術力つけたいんだけどやることわかんねーな」という感じだったのでこれから事業がどうなっていくから今これしとくかというほうが成果出せるのと新しいことやれるしで良いことづくめでした！

マインド

どの視座から物事を常に考えるのかということです。この本の中では特にその考え方をするための「習慣づくり」という括りになっています。以下3つを紹介しています。

• 決断経験
• 意思表明
• 大きな志

この中ではタイトルでも述べた通り「大きな志」について記述していきます。個人的にはこれが一番目から鱗でした。

何をするにも大きなビジョンや志を持っているのと持っていないとではあとあと大きな差になると思っています。なぜならそういったものを持っている場合、そこに向かうために自分がなにをすればよいのかと考えるようになり、そのために日々行動することができるはずです。なので持つことは大切なのですが、この本の中では「人を動かすにはビジョンや志が必要」とあります。ただそんなもん理解しているけど持てねーよという方がいらっしゃると思います。そのときには「もし自分が世界史に残るとしたらどう書かれたいか」ということを考えてみてください。そしてそれを書き出してみて自分が一番ワクワクするものを志にするとよいかと思います！

やりかた

この本のなかで具体的な行動も書かれています。「目標を設定しましょう、評価をしっかりしましょう」と。そんななかで僕が大事だなと思ったのは以下です。

• 環境力

成果を出せるような風土や仕組みを自ら作っていきましょうという話です。個人的にはこれはすごく大事だと思っています。あくまでも個人的な意見ですが、人はなにをするにも「その行動を促すきっかけ」で行動していると考えています。つまり三日坊主になってしまうのは、そうなるきっかけとなる行動をしているからで意思とは関係ないということです。なるほどなーと思うのでこちらの本も読んでみるとよいかもしれません。

新版「続ける」技術 (Forest2545Shinsyo 41) (フォレスト2545新書)

 で、そこで大事になってくるのが環境作りです。良いと思っている行動をするときのきっかけを常に与えられるような環境をつくり、逆に悪い行動をするときのきっかけは起こらないように環境を作り変える。環境次第で日々の生活のなかで行動できることが決まってくると思っています。まずはなにを良いと定義するのか、その行動をするきっかけはなんなのか、行動をハックしていきましょう！

まとめ

定期的に自分がこの一生で成し遂げたいことがなんなのかというのを見直す時間というのは月1くらいで必要なのかもしれません。その度に変わってもいいと思います。過去どういうことを目指していて、現時点ではどうなのかログをつどつど残していきましょう。おそらくそのログを見直すときに毎月似たような考えが出ているならおそらくそれが本当にやりたいことだと思います。

一度しかない人生、自分で制限を設けることなくフラットに楽しんでいきましょう！！

終わり。

サーバー移行時のざっくりとした手順と考えるべきこと

ちょっとした記憶の整理。

2016年の10月くらいから2ヶ月間かけて事業の全サーバーをGMOクラウドからAWSへサーバーを移行したのでそのときの手順。本当は終わった直後に書けば記憶が鮮明なので詳細に書けたのに・・・それを言っても仕方ないのでとりあえず思い出せるだけ思い出します。

と話に入るまえにこういった大きなことをするときのポイントを述べておきます。それは

既存の環境(GMOクラウドの環境)をなるべくそのまま新規の環境へ（AWS）へ移す

これ結構大事です！移行しようとして色々調べたりすると「あれ？これいらなくね？」とか「え？これこのバージョンなの？あげたほうがよくね？」といったものが結構多く出てきます。しかしここはぐっとこらえて一旦、目を閉じましょう。もしリファクタリングみたいなことを同時にしてしまうとエラーになったときに、問題の原因特定が極めて困難になります。

ちなみに僕はアプリケーション側のサーバー設定のときに設定ファイル含めリファクタリングしながらやってしまい、結構困りました。エラーになったとき「新規のサーバーの設定ミスなのか？それともリファクタリングしたときのミスなのか？」と原因推測の範囲が分散してしまいわけわからなくなりました。もしこれをリファクタリングしないで進めていたとすると、既存の環境では動いていたのは事実なのでサーバーの設定ミスっぽいなと、ある程度明確に当たりをつけられます。もし古いものを新しくするときはこのことを覚えておくと結構早く物事を進められるかもしれません。

話を戻して以下が手順です。

• 既存のネットワーク、サーバー構成の確認

新規で0→1のサービスを作るならこんなこと考えなくて調べて洗い出してみたいなことをやらなくていいし、やるとしてもおそらく今だとgithubとかでどういう設計にしたのかを残しておくと思うのですが。。うちの事業は10年くらい前からやっていてそのときの記録が一切ないので現状を把握することから始めました。

• 既存で使われているライブラリやツールの確認

うちはnginx→unicornでサーバーが構成されていました。各々のサーバーでどんなミドルウェアが使われいるのかを確認します。

 ＊＊ここまでが現状の理解になります＊＊

• 新規のネットワーク・サーバー構成の考案

ここは全体設計の話なのでかなり楽しかった記憶があります笑。サーバーの移行なんてそうそう行うものではないので「自分の考えた構成が残っていくのかぁぁぁ」と深く感動したものです。ただこの頃インフラなんて触ったことなかったので設計と言われてもなにがなんだか・・という感じでした。

なのでキャッチアップしながら進めました。以下が流れです。

１：とりあえず「サーバー移行」と適当にググったりインフラの本読んだりする。

Amazon Web Services 基礎からのネットワーク&サーバー構築

２：それらを見て・読んでなんとなくの全体像を把握。名前すら知らなかったのもあったのでここでは本当に「こんな感じなのかー」という感覚をつかむ程度。 

３：（自分の環境を作ってまずは遊んでみるのもあり）

４：設計の本を読んだり、他社さんのを参考にしたりする。以下を読みましたね。あとはAWSのブログとか見てたような気がします。

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版（日経BP Next ICT選書）

aws.typepad.com

５：4まででなんとなく設計に必要そうな技術がわかるのでとりあえずそれらを知っておく、また似たようなことができるのもあるのでそれらの違いを理解する。僕の中では「elastic beanstalk / opsworks / cloudformation」の違いがよくわからなかったのでそれを結構調べましたww

６：以上のことを踏まえて設計を考える。真似でも良いと思います。その候補が上がったら、各々の候補同士でメリットデメリットを考える

７：デメリットを考えるときは「一番最悪のことが起こったときどう対処できるのか」という基準を持つとすっきりします。

全体の話に戻します。この先は言わずもがなですね。

• 実際に構築

実際に作る前に部分部分で小さく作って問題ないのかの検証して、できなさそうならもう一度考えて作って検証するというのの繰り返しをやって「できる！」となった時点で実際の全体構築に入りました。

• 全体のテスト

アクセステストやらDBがちゃんと動いているのかといったテストをしました。

• 本番環境にする

というのが僕がやった時の流れです。実際に作るときには、「これできるのか？」みたいな検証に時間がかかってたような気がします。そんな時はAWSのサポートに問い合わせてみると答えが返ってくるかもしれません。最終こんな感じになりました。

こだわったポイントは以下ですかね笑

・この図だとわかりませんがcapistrano deployからblue green deploy方式に変えた

・この図だとわからないかもしれませんが、セキュリティ面強化のためにweb機をpublicにapplication機をprivateにおいた

・AMIを主体にcloudformaiton一発でこの環境ができるようにした

最後に・・・・

最近は、そろそろGCPを触る時が来たかなと思っているのでAWSからGCPに移行してみたというのもやってみようと思っています。

www.publickey1.jp

終わり。