omuronの備忘録

個人的な備忘録

『MixLeap Live LT #33 - 特別編「LTのはじめかた」』アーカイブ受講メモ #mixleap

yahoo-osaka.connpass.com

2020/11/5 に行われたイベントの ライブ配信のアーカイブ が公開されたので視聴しました。
内容が素晴らしかったので、アーカイブから引用してメモしておきたいと思います。

LT のはじめかた

スピーカー:中嶋 道太郎

LT とは?

  • 短時間(約5分)のプレゼンのこと
  • ターゲット:LT に興味があるけどやったことない人
  • ゴール:LT をやらない理由が全て解決されること
    • やらない理由?
      • メリットがわからない
      • 話すネタがない
      • 資料を作るのが苦手
      • 死ぬほど緊張しそう

LT をやることのメリット

  • 伝えたい情報を聞く人がいて理解を得る行為は全てプレゼン
    • 商品の宣伝、自己紹介・面接、告白とか
      • 生きていく上で持っていると活用できるスキル
  • プレゼン力
    • 色々な能力が一気にあがる
      • 発想力、想像力、文章力、構成力、トーク力、度胸、デザイン力
  • アウトプットは楽しい!!

LT で話すネタの作りかた

  • 「話すネタがない」はない
    • 「話すネタがない」というネタがある
  • 「テーマ〇〇〇」について、やったことがない場合
    • 初めて〇〇〇をやった話が話せる
  • 料理が苦手 → 簡単な料理を初めてやったネタが作れる
  • 旅行が嫌い → 好きなことに置き換える
    • ゲームが好きなので「旅行している感があるゲーム」の話をする
  • 低レベルの話しかできない → 未経験者や超初心者向けの話をする
    • 発送を逆転させる
  • テーマは好きだけど面白く話せない
    • 「面白い話」がテーマじゃなければ別に好きに話せばいい
  • レベルの高い話、役に立つ話、面白い話などができなくても
    • 全く気にしなくて大丈夫!!
      • 自分が楽しめれば OK
      • 開催側は発表者がいるだけで嬉しい

良い感じの LT 資料の作りかた

  • 素敵な資料が作れない、しょぼい資料は恥ずかしい
    • まったく気にしなくて大丈夫!!
      • 「素敵なプレゼン資料」がテーマでなければ問題ない
    • LT 資料は好きに作って OK !!
  • 文字は少なく大きくする
  • 絵や写真はたくさん使う

おすすめフリー素材サイト

イラスト
写真

良い感じのタイトル

  • 適当な背景画像
  • 黒の長方形、透明度60%
  • 白のタイトル文字

f:id:omron:20201124091028p:plain

良い感じのページ構成

  • 薄いグレーの背景 (#F2F2F2)
  • 好きな色の長方形
  • 白の見出し文字
  • 濃いグレーの本文文字 (#333333)
  • 良い感じのイラスト

f:id:omron:20201124091012p:plain

良い感じの見出しスライド

  • 好きな色の背景
  • 大きめの白文字

f:id:omron:20201124090956p:plain

まったく緊張しない方法

  • そんなものはない
  • 誰でも絶対に緊張はする!!
    • 和らげる方法はある
      • 準備と経験
  • 不安は準備で打ち消せる
    • 資料作り、台本、壁打ち
  • 経験はやればやるほど慣れる、楽しくなる
    • 1回やってみる

まとめ

  • メリットが分からない
    • 人生の役に立つ、能力上がる、楽しい
  • 話すネタがない
    • どんなことでもネタになる!レベルも気にしなくて OK
  • 資料を作るのが苦手
    • 好きに作る!良い感じの資料の作り方も割と簡単
  • 死ぬほど緊張しそう
    • 誰でも緊張するので気にしない!準備と経験で軽減

所感

プレゼンなれしたデザイナーさんがまとめた素晴らしい資料とプレゼンです!!
自分のプレゼンは写真を使うことはなかったので、今後写真も交えたプレゼンを考えてみたいと思います。

「JAWS-UG朝会 #15」 #jawsug_asa 受講メモ

jawsug-asa.connpass.com

テレワークが続く限り参加できる朝会の日です。

セッション① AWS Organaizationと一緒にはじめるアカウント分離

講師:株式会社スナックミー 多田 貞剛さん

speakerdeck.com

  • 会社紹介
    • snaq.me
    • 新しいおやつ体験を想像し、おやつ時間の価値をあげる
  • AWS アカウント管理の課題
    • AWS 1アカウントのみ
      • ステージ、開発も同一アカウント
      • 開発中に本番触る事故
    • AWS リソースが手で作ったり、コード化されてたり管理バラバラ
    • ローカル Docker だと動くけど本番で動かない
      • Docker on Mac は動作するのに ECS だと動かないとか
      • インスタンスタイプが問題だった
    • 本番システム構成を変えづらい
    • AWS 管理が CTO のみ
      • 開発メンバー全体の習熟度アップ
  • AWS Organizations 使って解決したい!
    • Landing Zone の考え方を参考に進めている
      • Landing Zone はベストプラクティスに基づいたマルチアカウント環境のセットアップをサポートする仕組み
    • ステージングとサンドボックスに分割
    • リソース管理は IaC 化して対応
    • 利用料は redash で可視化
    • CloudTrail, Config, GuardDuty 設定
  • 今後やりたいこと
    • SSO 利用
      • GSuite を IdP にした SAML 認証
    • ログ集約アカウント
    • Organizations 活用したアカウント管理

セッション② AWSのこんなイケてないモノ

講師:運用設計ラボ合同会社 波田野 裕一さん

サービス名は Tweet 禁止とのことなのでまとめもできず。
資料なし、通勤中にも聞いたりできるようにラジオ風のセッションでした。

LT① JAWS DAYS 2021 開催のお知らせ

講師:榎本 航介さん

www.slideshare.net

  • JAWS DAYS 2021 を 2021/3/20 10:00 - 18:00(仮)で開催します
  • オンライン+α
  • 12月にイベントサイト公開
  • JAWS SONIC 振り返り note も公開中

LT② Organizations周りの機能 2

講師:株式会社ターンアンドフロンティア 富松 広太さん

www.slideshare.net

  • 前回の朝会の続き
  • Organizations と連携可能なサービスを普通に利用するのと何が違うのか?
  • AWS Health
    • 単体で使う場合は Personal Health DashBoard で通知してくれる
    • 通常は EventBridge を子アカウントで設定して親アカウントへ通知が必要
    • 利用すると API で親から子アカウントに HealthEvent を一括設定可能になる
    • 子アカウントの HealthEvent を親アカウントから一括して取得できるようになる
  • AWS SSO
    • SSO 無しなら、親アカウントに IAM ログインして子アカウントに SwitchRole
    • SSO 有りなら、親アカウントへ SSO でログイン

所感

テレワークが続く限り参加しやすい時間なので朝会は助かります。
ただ、登壇する費とは大変だと思いますね...いつもありがとうございます。
終わったあとの雑談タイムも非常に楽しいので参加してみると面白い会だと思います。

「JAWS-UG CLI専門支部 #171R S3基礎 通知 (Lambdaの自動実行)」受講時の Cloud9 事前準備不足について調べた #jawsug_cli

jawsug-cli.connpass.com

過去、JAWS-UG CLI専門支部のハンズオンは、最後までオンタイムで完走することができていました。
今回は量が多いこともあり、途中でうまく行かないとついていけなくなり、最後までオンタイムで進めきることができませんでした。
なぜ失敗したかを探りたいと思います。

過去のハンズオン作業環境

今まで受けてきた CLI 専門支部のハンズオンは、macOS のターミナルで処理をしていました。
aws コマンドは 公式資料を参考に Docker 上で起動して利用しております。

aliase aws='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

多少苦労する点はありましたが、だいたい時間内に完走はできておりました。
CLI 専門支部のハンズオンで推奨されている Cloud9 環境との違いをまとめます。

aws cli version の違い

CLI のバージョンは新しいほうがいいだろう」ということで、ローカル環境では v2 を利用しております。

$ aws --version
aws-cli/2.0.43 Python/3.7.3 Linux/5.4.39-linuxkit docker/x86_64.amzn.2

一方、CLI 専門支部は v1 での動作保証をしている状況です。
バージョンは違いますが、ここが問題になることは過去ありませんでした。

BSDGNU の違い

macOS 標準のターミナルのコマンドは、基本 BSDsedawk です。
一方、CLI 専門支部のコマンドは Amazon Linux2 になるため GNU のコマンドです。
それぞれのコマンドオプションなど違う場合があり、BSD 版に読み替えて書き直す必要がありました。
ハンズオンでは、遅れないように急いで書き換えて、なんとかついていくようにしてました。

今回のハンズオン作業環境

Cloud9 との出会い

CLI 専門支部では、Cloud9 を利用した環境を前提としております。
別のハンズオンで Cloud9 を利用したことがあり、一度 Cloud9 を使ってみるととても便利でした。

「Cloud9 使えば、今までみたいな苦労はなくなり余裕でついていける!」と考えて、今回のハンズオンからは Cloud9 の利用に切り替えました。

事前確認

私は aws コマンドが正しく動くかの確認をいつも aws s3 ls で行っております。
S3 バケットを見ればどの AWS 契約につないでいるかわかるため、事故を起こさないために必ず最初にこのコマンドを叩きます。
ハンズオン環境で利用しているバケットが見えたので、接続先は問題ないと確認できました。

また、ハンズオンで利用しているユーザーは Admin 権限で作っております。
Admin であれば Role 設定をいちいちしなくても困らないだろうと考えました。

問題が発生した

IAM 権限がない

Cloud9 上で作業を進めていると以下のエラーが発生しました。

$ aws iam create-group \
>   --group-name ${IAM_GROUP_NAME}
An error occurred (InvalidClientTokenId) when calling the CreateGroup operation: The security token included in the request is invalid

「あれ? IAM の作成権限が足りてない?」ということで、ローカルからコマンドを叩いて乗り切りました。

S3 バケットへアップロードができない

今回作業に使うユーザーは、ローカルからコマンドを叩いて API キーを取得しました。
この情報を Cloud9 上に配置しました。
新たに作成したユーザー権限で動作するから、これ以降は問題出ないだろうと思いました。

しかしながら、S3 へのアップロードでエラーが発生してしまいました。

$ ${FILE_SCRIPT}   ${ARGUMENT_1} ${ARGUMENT_2}
upload failed: local-handson-cli-s3/handson-cli-s3-notification.txt to s3://handson-cli-s3-notification-686609377265/sample/0.tmp An error occurred (InvalidAccessKeyId) when calling the PutObject operation: The AWS Access Key Id you provided does not exist in our records.

今回作成したユーザーには権限が足りているはずですが、S3 へのアップロードができません。

API キーの書き換えができない

では、ローカルでも利用している Admin 権限のキーを .aws に配置すれば何でもできるだろうと思い配置してみました。
しかしながら、ワーニングが発生したので強制的に書き換えることはやめました。

f:id:omron:20201114171527p:plain

何が原因だったか?

Cloud9 環境の作り方が問題だったんだろうと考えました。
再度 Cloud9 を作り直して権限を増やそうとしましたが、デフォルトで設定されているロールから変更することはできません。

f:id:omron:20201114171842p:plain

CLI 専門支部のハンズオンの Cloud9 と何が違うのか調べることにしました。

AWS CLI利用環境(Cloud9)の構築・利用・破棄(簡易版)

prototype-handson-cli.s3-website-ap-northeast-1.amazonaws.com

「『GUI は中学生まで』の波多野さんの資料なのに GUI のキャプチャーが大量にある! 」
ということにびっくりしながら、これにならい Cloud9 環境を構築していきました。

「Cloud9 を起動している EC2 のロール権限が無い!」

1.2. EC2インスタンスへのIAMロールのアタッチ (handson-cloud9-env)

順に進めていき、この項目に来たときに気が付きました...
Cloud9 を起動している EC2 から cli を叩くときは、EC2 自身の IAM ロールにも影響を受けます。
EC2 に IAM ロールが足りていなかったため、Cloud9 環境から叩けるコマンドに制限があったようでした。

まとめ

  • Cloud9 も EC2 で動いているのでアタッチされているロールに依存する
    • 権限がある API キーを利用しても制限を受けてしまう
  • ハンズオン環は手順に沿えば全く問題はない
    • 違う環境でやるのは自己責任
      • 勉強になるので違う環境も基本は楽しい
      • しかし、ハンズオンの量が多いときには辛い

理由がわかれば単純なことでした。
Cloud9 自体はとても便利なので今後も活用したいと思います。

(小ネタ) AWS RDS エンジンのスケジューリングアップデート

AWS RDS のエンジンは、スケジューリングしてアップグレードすることができます。
メンテナンスの動作については、以下の3種類のボタンがあります。

f:id:omron:20201113082951p:plain

それぞれ何が起きるか理解しておかないと事故が起きてしまうので確認を行ないました。

  • 却下
    • アップグレードを実施しない
  • スケジュール
    • 次のメンテナンス期間に適用する
  • 今すぐ申し込む
    • すぐに適用する

という動作をするようです。
ボタンだけ見ると「今すぐ申し込む」が表記されたスケジュールでの実行で、「スケジュール」がスケジュールの変更かと勘違いしていました。

では、スケジュールを変更したい場合はどうするかというと、以下のドキュメントに記載があります。
Amazon AuroraDB クラスターのメンテナンス - Amazon Aurora

DB クラスターの適切なメンテナンスウィンドウを調整するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
  2. ナビゲーションペインで、[データベース] を選択します。
  3. メンテナンスウィンドウを変更する DB クラスターを選択します。
  4. [Modify] を選択します。
  5. [メンテナンス] セクションで、メンテナンスウィンドウを更新します。
  6. [Continue] を選択します。 確認ページで、変更内容を確認します。
  7. 変更をメンテナンスウィンドウにすぐに適用するには、[変更のスケジューリング] セクションで [今すぐ] を選択します。
  8. [クラスターの変更] を選択して、変更を保存します。 または、[Back] を選択して変更を編集するか、[Cancel] を選択して変更をキャンセルします。

ドキュメント記載の通り RDS クラスターの(ドキュメントだと [Modify] だけど、日本語コンソールの場合)[変更] から、スケジュール時間を変更して対応することができます。

f:id:omron:20201113085249p:plain

Aurora クラスターの更新には概ね 20〜30 秒のダウンタイムが発生する ので、メンテンナンス計画をちゃんとして対応しましょう。

「JAWS-UG 初心者支部 #33 大分支部コラボ!! amplify +AWS LT大会!! 」受講メモ #jawsug_bgnr

jawsug-bgnr.connpass.com

Amplify 勉強中...聞くより触るほうが早いなーと思いながらも、まだそれほど使いこなせてません。

①20分 セッション & QA10分:Amplifyサービス概要と始め方

講師:AWSJ 亀田 治伸さん

大分出張の楽しみは このラーメン屋さん とのこと。
さっしーの親戚がやってるらしいけど、それと関係なく美味しいと。

  • Amplify = 増幅する、アンプと同じ語源
  • 今どきのWebアプリ
    • ユーザー間のチャット
    • プッシュ、レコメンド
  • アプリ開発者がやりたいことに集中できるように
  • Amplify は CI/CD も兼ねる
  • Cypress による E2E テストが統合済み
  • ホスティングCDN による配信
  • 独自ドメインSSL 証明書の設定
  • Amplify DataStore
    • GraphQL 経由で自動的にアプリとバックエンドのデータを同期
    • AWS AppSync と連携してデータを同期、コンフリクト解決
  • Amplify Console

Amplify の参考ハンズオンは こちら

②10分 LT & QA5分:多分みんなが思ってるよりAmplifyはずっとすごい

~ぼくとAmplifyの18ヶ月~

講師:浜松支部 松井 英俊さん

  • Amplify のことを発信してたら
  • Amplify 活用事例
  • Amplify いいところ
    • フロントエンドを爆速でデプロイできる
    • 認証がすごい楽
  • Amplify の勘所
    • ビルド設定( Next.js 初期設定だと動かなかったり)
    • SPA でのリダイレクト設定
  • Apmlify とは
    • 爆速デプロイでいち早くアイデアを具現化して運命を変えるツール

③10分 LT & QA5分:AWSへ移行する!

〜だから勉強してねと言われた全国初学者の皆様に〜

講師:shiro-kujiraさん

  • 元公務員、工場、製造、重機好き
  • これから AWS を導入するらしい
    • すごいサービスなのはわかるけど
    • オンプレミスでもよくない?
    • モチベーションどうしよう
  • AWS の導入事例をみて成功イメージを
    • 大阪の金属加工業で導入事例を参考
    • 中小企業も導入している
  • 現在は社内にオンプレ10台
    • 5年に一度 1000万かけて入れ替え
    • IT 管理は課長一人
  • AWS 導入まで
    • 経営者セミナーきっかけ、5年かけて対応
  • 結果運用金額は AWS のほうが高い
    • 空調や場所は削減
    • 管理業務削減、管理維持コストは大幅減
  • この事例をみて会社の未来を想像して AWS 学習 !

④5分 LT:IAMのロールで本番環境を守る!

講師:齋藤玄さん

  • スマホアプリの開発
    • 一人で作っている
  • 本番環境を間違えて変更したトラブル発生
    • IAM ロールで管理して対策
  • 普段は開発環境しか見えない
    • ロール切り替えで本番が見えるように
  • ポイント
    • ロール設定を厳しくすると開発しづらい
    • いい塩梅が必要、先輩に聞く
    • リリース前にやるべきだった
  • 開発環境の整えは地味だが派手なミスを防げる!

⑤5分 LT:Amplify CLIが作成するバックエンド

講師:初心者支部 山原 崇史さん

speakerdeck.com

  • Amplify って何なん?
    • Amplify での構築イメージがつかめない
  • Amplify のチュートリアルにトライ
  • Amplify とは?
    • フロントからインフラとデプロイまで1人でできる人は少ない
    • 分業となるとコミュニケーションコストのオーバーヘッドもある
    • これらをフロントエンドエンジニア1人で完結できる Amplify は強力
      • 高速で MVP を作れる

所感

できることが多い上、コンソールやら CLI やらなんやら種類も多いから余計に混乱しがちなサービスです。

という認識です。
インフラエンジニアとしては、CLI やコンソールを使って楽にバックエンドを構築できるサービスと思っています。
こんな理解であってるんかな。もっと使いこなさないと。

(小ネタ) HHKB Pro の Option と Cmmand キー入れ替え

公式 からドライバーを入れて、本体の設定モードを macOS ように変更した上で、
[システム環境設定] → [キーボード] → [修飾キー] から変更する。

f:id:omron:20201110083103p:plain

Pro の打鍵感は素晴らしいんだけど、HHKB Lite のキー配列のほうが素直に使える気がする。

「Front-End Study #1「Cloud Native時代のフロントエンド」 」資料メモ #FEStudy

forkwell.connpass.com

フロントエンドなんもわからんので資料メモ...
アーカイブこちら

基調講演「『フロントエンド領域』を再定義する」

講師:株式会社PLAID フロントエンドエンジニア mizchi氏

zenn.dev

「フロントエンド開発者も知っておきたい AWS Lambda とサーバーレス」

Manager, Specialist Solutions Architect Amazon Web Service Japan K.K. 西谷 圭介氏

speakerdeck.com

サーバーレスアンチパターン今昔物語で話してきた内容をフロントエンド向けに再編集した感じでした。
Serverless Next.js Component については、次回の今昔物語で取りあえげてくれるので楽しみです。

serverless-newworld.connpass.com

「STUDIOのデザインツールとホスティングの仕組み」

講師:STUDIO Inc. CPO / Founder 甲斐 啓真氏

モリサワ Web フォントも使える STUDIO の裏側の話。
HEAD (タグ?)だけ SSR しているとのこと。
バックエンドは GCP だったんですね。

次回

forkwell.connpass.com

所感

フロントエンドなんもわからん...