Cloud9とEC2で環境構築

ステイホームとなったので前々からやってみたかったCloud9とEC2の環境構築

参考にしたページ

https://qiita.com/kutarou197/items/f68ce34f636e419bf766

手順メモ

EC2 インスタンス作成

cloud9でcreateする  
Environment settings  
Connect and run in remote server (SSH)  
User:ec2-user  
Host:EC2でコピーしたec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com  
Advanced setting:  
Environment Path: ~/environment  

Cloud9でコピーしたpublic ssh key をはりつけ  

コンソールから、接続を開き、terminalを立ち上げる  
vim ~/.ssh/authorized_keys  
nodejs インストール  
sudo curl -sL https://rpm.nodesource.com/setup_12.x | sudo bash -  

node入れ終わったあとに、cloud9のcreate environmentをすすめる  
cloud9 installer のインストール画面にはいるので、画面にしたがってデフォルトのままnext  
Install Cloud9 IDE と続く  
  
workspaceは以下  
/home/ec2-user/environment  

pemのkeyを600にする  
chmod 600 xxx.pem  
ssh -i ./xxxxxxx.pem ec2-user@ec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com  

symblinkをec2ホームにはる  
sudo ln -s /home/ec2-user/environment /var/www/environment

sudo vim /etc/httpd/conf/httpd.conf をコピーしておいて
DocumentRootを /var/www/environmentにする

symbolinc link の権限がないって言われた
AH00037: Symbolic link not allowed or link target not accessible: /var/www/environment, referer: xxxxxxx

/home/ec2-user
これが、700 だったため発生
apacheユーザでも実行できるように、chmod -R 755 ec2-user にした

でもこれだと、ec2-user のすべてが755になるのでさけたい。 よいものなのか?設定方法については今後調べて対応するので、今日はここまで。

余談だけど、EC2でAmazonLinux2を利用しているので、
amazon-linux-extras install php7.4とか比較的新しめのバージョンをサクッといれられるのは嬉しい

# amazon-linux-extras
つらつらとパッケージが表示される php7.4 enable と書かれているが。。。
[https://forums.aws.amazon.com/thread.jspa?messageID=908568]

# yum install php 
なぜか enable と書かれていた7.4が入った。availableの7.3が入ると思ったのだが。。

# php -v
PHP 7.4.4 (cli) (built: Mar 27 2020 18:05:17) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

一兆ドルコーチを読んだ

気がつけば半年ぶりくらいに書き込むのか。

入院していたり、プロジェクトが忙しかったりとばたついていた。

読んだ本くらいメモしておけばと思うけど、この半年は乱読状態なので、また今度本のタイトルだけでも記載する。本棚欲しい。

 

人に求めるべき最も重要な資質は知性と心だ。
つまり、すばやく学習する能力と厳しい仕事を厭わない姿勢、
誠実さ、グリット、共感力、そしてチームファーストの姿勢

 

メモ
厭わないとは、嫌わない、避けない、構わない


個人的な利益よりもチームの利益を優先させ、会社にとって良いことや正しいことを徹底的に追求するチーム


このまとめが良い
https://www.head-t.com/2020/01/2020-01-11.html

builderscon 2019 へ行ってきた(Day1)

途中抜けだったけど今回もめちゃ楽しくて刺激を受けた。
コンパイルのライブコーディングは一体感があって楽しかった。会場からエンバグを指摘してくれたり。
マイクロサービスも多くの会社からノウハウが出てきている。
自社も一部モノリスからマイクロ化していく流れだし、今後は加速していきたい。
影響を小さくするために切ったプロダクトから派生するプロジェクトをどう管理していくか?という点は気になっていたがWandelyさんのProtocolBufferのセッションでは、結局集約して管理しているという話。

マイクロ化する中でもShcemaのような他プロダクトプロジェクトに影響する部分については、他プロダクトへ簡単に利用できるようなプラットフォーム化は同時に進めて行かないといけない。

Open SKT: メルペイ開発の裏

speakerdeck.com

メルペイでのサービス軍

  • 40以上のマイクロサービスで構成されている
  • メルカリもメルペイの決済基盤を利用

マイクロサービス設計

  • 4層アーキテクチャ
  • Client -> ApiGateway(<->Authority) -> Api Service -> Backend Service
  • Backend Service は無数あり、Api ServiceがClientへのレスポンスに責務を持つ

分散トランザクション

  • エラーを例外として捉えない
  • 共通のエラーモデル
    • 共通モデル
    • リトライと冪等性
  • Try/Confirm/Cancelパターン
    • 状態遷移モデル
    • どの状態まで進んだかを記憶している
    • サーバが落ちても途中から復旧できる
  • リコンサイル

    • データの整合性確認
  • QA

    • なぜTry/Confirm/Cancelとリコンサイルの重複処理を行うか?
    • どちらか一方に不具合がないとは言えないため
    • 中央にいるサービスのデータをマスタとして捉え各サービスのデータをリコンサイルする

トランザクションモニタリング

メルペイでの開発フロー

  • あまり聞かない部分のみ抽出

  • DesignDoc

    • 開発設計まえの開発設計レビューがある
    • ドキュメントを書き、アーキテクト、SRE、セキュリティ、関連チームからのレビュー
    • 目的:今から行う事がどれくらい懸念があるかを知るり、事前にリスクを洗いしチーム間で共有する
  • Ops

    • マイクロサービスの運用はすべて開発チームで行う
    • PRDはSREしか見れない(個人情報、資産があるため)
    • 開発チームがPRDを見れるようにマスキング、参照する仕組みを用意

メルカリとメルペイの開発フローの違い

  • メルカリ
    • 守るべきものは守り 強くチャレンジする
  • メルペイ

    • より高い信頼性 その上で機能がある
  • 最大化したい価値が異なる

  • SLOを高く設定するとチャレンジできる量が減る
  • メルカリはサービスを早いサイクルで回していく
  • メルペイは落ちないという事がシビアに求められる(高いSLO)

業界全体のレベルを上げるためにやっていく

  • メルペイの事例を公開することで
  • 透明性と信頼性の向上
  • 他社が参考にできるように
  • 逆に他社の事例を参考にしたい

用語

  • SLO
  • Postman

コンパイラをつくってみよう

speakerdeck.com

Go->Assembly->標準出力

  • コンパイルを学ぶ事によってプログラムについてちょっと理解する事ができる
  • やりながら学ぶ
  • 根気が必要(これを終わるまで何もしないという制約がモチベーションだったとか)
  • Goのライブコーディングがめちゃ楽しかった。個人的な今日一番おもしろかった。

Web API に秩序を与える Protocol Buffers 活用

  • @south37

speakerdeck.com

  • Protocol Bufferの利用シーン、メリデメを知りたくて参加
  • Go / Ruby .proto から自動生成されたコードをプロジェクトで組み込む(秩序)
  • 共通モジュールをどうやって管理してるか?
  • .proto を集約したGitリポジトリで管理して、そこで吐き出したproto file を各プロジェクトで利用している運用に切り替わってきた

Web Componentsを利用した段階的AngularJS脱出作戦

docs.google.com

  • WebComponentsについて詳しく知らないので、インプットとして良い時間だった
  • 現在のWebComponentsの状況
  • CustomElementでWrapしたAngular / React / Vue の利用方法

今回も運営のみなさん、スピーカーの皆さん、スポンサーのみなさん、ありがとうございました!!!!!

働き方を変えなさい 佐々木恒夫を読んだ

いい習慣は才能を超える

いい習慣とは?どのようなことか?

一歩先の行動をとる

毎日10分の整理整頓

 

礼儀正しさに勝る攻撃力はない

ビジネスにふさわしい服装
きちんと挨拶
相手の目を見て話す
約束を守る
過ちを素直に認める
気遣いを忘れない
欲張らない

 

どうやって使える人材を確保するか?

目の前の人材のポテンシャルを自分の腕でどうやって発揮させるか?にかかる。

 

評価は技術点と芸術点
技術点は
企画力、事務処理能力、マネジメント力
芸術点は
人柄がいい
知性がある
清潔感がある
といった人間的魅力
なぜ芸術点も必要か?
それはいくら能力が高くても利己的だったり品性に欠けていたりすると下の人間がついてこないから。

 

リーダーとは真摯であること。一言で言うと正しい事をする。どうあるべきかを正しくつかむ。事がリーダーに一番の能力。

真摯とは?
嘘をつかない、謙虚である、そして人に対して思いやる。

 

年頭所感は別の本でも触れていたが作成が必要

一年にできることは限られているので欲張らず7-8項目。先頭にこの部署にいる間にこれとこれをやる事を決意した。そのためにやる事、その他にやることを書く。


3年の目標も書く
3年という期限があれば一年ごとに落とし込んで計画も立てられる

 

読んでいて他で話すことも多いが新しい言葉もあった。特に推薦の2冊は読みたい。

論語
ビジネスマンの父より息子への 3 0通の手紙

 

 

アウトプットとして会社のLT大会で習慣について話した

3ヶ月に一度くらいのペースで行われている社内LT大会で最近考えている習慣についてアウトプットした。

 

リンク

https://speakerdeck.com/tobaru/experiment-with-self-change?slide=20

 

実現するためにやる事は、

言語化して

制約を定め、

代償を知り、

記録して、

習慣にする。

この流れを一つずつ行いどこで詰まったかをちょこちょこ改善する。それがとても難しい。自分を使って実験を行なっているというアウトプット。答えは誰にもわからず自分の行動が3ヶ月後に影響を出しているか?アウトプットとして成果になっているか?それに答えはかかっている。

 

毎度開催してくれる同僚や、盛り上げようと参加してくれる皆がいてのイベント。とても感謝しているし、アウトプットの機会を頂いた。次回やりたい事は考えているので、それに向かって進む。

やりぬく人の9つの習慣を読んだ

多くの人は自分の意志力を過大評価している

意志力を試してはいけない

 

本当にその通りで、意思があればできると思い続けてきた。実は意思など関係なく、行動のトリガーが必要という事がわかってきた。何かをやるという事すら考えないようになるまでは反復して練習する。

 

影響を受けると思われる場所には近づかない。

誘惑を受ける時間や場所を記録する。

ここにも記録が出てきた。そしてやると決めるものを絞る。やめるときは一気にやめる。

 

この本の中で一番面白かったのは、if-then-プランニングとシロクマの話。

 

if-thenプランニングとは何か事象が起きた時の行動を用意しておく、習慣にするという事。

その種類は3つあり

1. 代替if-thenプランニング
好ましくない行動をより良い行動にかえる
2. 無視if-thenプランニング
不安や緊張を自分の心から遮断する。感じないようにする。
3. 否定的if-thenプランニング
今後やりたくない行動をやらないとする

何か思ってもしないというプランニング。

 

この3パターンを検証したところ、否定的は他のパターンと比べて効果が小さい。
ある行動を否定すればするほど考えてしまって、行動を強化する事になる。

 

シロクマの事は考えないで下さいと言われたらシロクマの事ばかり考えてしまう。

ある思考をしないように努力すると、逆に頭の中はその思考でいっぱいになるという事の実験。

行動を変えたいならばやめたい事を考えるのではなくやりたい事、やるべき事を考える。

 

自分が望む行動を起こすように代替if-thenプランニングを立てる事を心がける。当たり前のようだが意志力の落ちた状況下でも対応できるように準備するという事が趣旨。

 

やりたい事を以下として

朝早く起きて頭が一番フレッシュな時にインプットアウトプットをしたい。

 

代替

遅い時間に問い合わせがあった。緊急度を判断して次の日に対応する。

否定

遅い時間に問い合わせがあった。緊急度を判断して遅い時間に対応しないようにする。

 

否定では対応の具体性に欠ける。

当たり前のようだが、意志力の弱っているときタイミングでも判断を誤らないためのフレームワークか。

ぼくたちに、もうモノは必要ない。佐々木典士を読んだ

物に執着しない事で迷う、考える、何かアクションを起こす時間を削り、行動して経験する事につながる時間を重要視する。
経験は盗めない。


情報のミニマリズムという言葉が好き。
自分たちの体は5万年前のハードウェア
そんな中で情報過多になるとアイコンぐるぐるだよね。という表現はまさに。


今という瞬間だけが自分でコントロール可能。
今まさにこの瞬間を感謝の気持ちでいっぱいにしないか?今を肯定的に見ることが感謝の本質であり、幸福であると。

 

そのために物を捨て、というより執着せずに過ごす。

自分よりも他人に与えたことに喜びを感じる。毎日、特に今という時間に最大の集中をして、人を知り、愛を伝える。

これが人にとって究極の幸福なのでは?と考えるきっかけになった。