amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

寒くてもアイスコーヒーのすすめ

目次

はじめに

この記事は、Coffee Advent Carendar 2021 第5日目の記事です。

adventar.org

先週から急に寒くなってきましたが、いかがお過ごしでしょうか?

今日は、寒くてもアイスコーヒーを勧めたい!という、季節感まったくない記事を書きます。

寒くてもアイスコーヒーの理由

手軽にコーヒーを飲める

コロナ禍の在宅勤務で、休憩時間中にコーヒー豆を挽いて飲む方も増えたかと思います。 とはいえ、毎日コーヒー豆を挽くのも大変、豆を挽く時間がないという時もきっとあると思います。

そんな時は冷蔵庫にアイスコーヒーを入れておきましょう!!

忙しくても、冷蔵庫に行ってさっと取り出せて、グラスに注げばすぐにコーヒーを味わえるます。

最近、在宅勤務でコーヒーを飲む時間が取れない日も出てくるようになり、コーヒーを飲む時間の確保方法を色々考えていましたが、

アイスコーヒー作っておけば忙しくてもすぐ飲める!!!

と思い、寒くてもアイスコーヒーを作っておき、いつでも飲めるようにしました。これで、忙しくてもコーヒーを飲みたくなった時は、アイスコーヒーを注いで飲んで、すぐに仕事に取り掛かれます。

暖かい部屋で飲むと格別!!

寒くてもアイスコーヒーを飲むようになり、気づいたことです。

暖房器具を使うと部屋も乾燥するし、頭もボーっとすることが増えます。そんな暖かい部屋で冷たいアイスコーヒーを飲むと、シャキッとします! ホットコーヒーよりも喉が潤う感じもしますので、良いと思います。

暖かい部屋やコタツで飲むアイスコーヒーの時間は、至福の時です!!

電気代喰って家計を逼迫しない程度でやってみてくださいw

最後に

コーヒーを柔軟に飲めるようになって、在宅勤務できることに本当に感謝しています。その分、仕事のアウトプットの早さと質は上げなければなと思いました。その在宅勤務をきっかけに、改めてアイスコーヒーの手軽さとありがたさ、楽しみ方を再確認することができました。

今後は、アイスコーヒーとは年中付き合っていくことになりそうです!!

コーヒー豆の名前からコーヒーを選んでみよう

目次

はじめに

この記事は、Coffee Advent Carendar 2021 第1日目の記事です。

というわけで、今年もCoffee Advent Carendarがはじまりました。 初日は言い出しっぺの私amarelo(アマレロ)が書いていきます。

スペシャルティコーヒーには、生産国だけでも様々な豆が存在し、様々な味わいがあります。 たくさんあって迷う人もいらっしゃるかもしれません。そんなときは、好みの味の傾向と豆の名称で選んでみるのはいかがでしょうか? 今回は、これからコーヒーを豆で買って家で抽出してみたいという方向けに、おススメの豆を紹介します。 まずは、中煎りの豆から2つ、深煎りの豆から1つご紹介します。

中煎り(シティロースト)の豆

中煎りの豆では、私はブラジルの豆が大好きで、「おススメの豆は?」と聞かれたら一番最初に勧めるくらい大好きです。 ブラジルの豆は、苦味と酸味のバランスが良く、上手く焙煎できた時に感じる甘味が最高だと思っています。 なので、酸味がいいか苦味がいいか迷ったら、まずはブラジルの中煎り豆を選んでみてください。そこから自分の好みがどちらか見つけることができると思います。 コーヒー豆購入の一歩を踏み出しやすくしてくれる豆だと考えています。

また、甘さを感じさせるネーミングが多く馴染みやすいので、そこもおススメです。その中から2つ紹介します。

ブラジル さくらブルボン

過去にもこのブログで紹介したことがあります。

amarelo24.hatenablog.com

日本人の大半が好きであろう花「さくら」。日本人の心に寄り添うような豆で大好きです。 さわやかな酸味と軽めの苦味、すっきりとした甘味が特徴です。 私はこの豆を春になるとかならず焙煎します。生豆の出来が年によって微妙に異なるので、毎年違った味わいを見せます。 毎年3月ごろから出回りますので、次は3か月くらい後になりますが、今から焙煎するのが楽しみです!!

これから寒くなりますが、少しずつ温かくなって頃にお店で見つけたらぜひお試しください!! 桜の花をのんびりと眺めながら飲んでみるのも良いものですよ♪

ブラジル サントアントニオ プレミアムショコラ

ほどよい苦味と甘味が心地よい豆です。 「ショコラ」という名の通り、チョコレートのような風味を想像させてくれます。 さくらブルボンとは違って通年手に入りやすい豆なので、時期を問わず贈り物にもおススメの豆です。 チョコレートやケーキをお供に飲むのも良いと思います♪

usfoods.co.jp

ちなみに、同じブラジルの豆で似た名前の「クイーンショコラ」という豆を最近焙煎しました。 プレミアムショコラの写真がなかったので、参考までにクイーンショコラの焙煎後の写真を載せておきます。 プレミアムショコラも近い感じに仕上がり、こちらもほどよい苦味と甘味を感じました。 休日の午後のひと時に良さそうなネーミングなのも良いです。

f:id:amarelo-n24:20211201065750p:plain

深煎り(フレンチロースト)の豆

深煎りはコロンビアの豆がおススメです。 自分はコロンビアの豆は深煎りがベストと考えています。苦味の中に感じる甘味が大好きです。 たくさんあって選ぶの迷いましたが、最近焙煎した豆を紹介します。

コロンビア ウィラ グランスイート

苦味の中に上品な甘さを感じることができて、仕事の眠気覚まし、のんびりとした午後のコーヒータイム、どちらにもおススメできる豆です。 アイスコーヒーにしても、エスプレッソにしても美味しく仕上がります。

深煎りにするとこんな感じに仕上がります。苦味が強そうに見えますが、それでも甘味も十分に感じられます。 余談ですが、深煎りには洋菓子だけでなく、最中やどら焼きのような和菓子もよく合います。一度試してみてください!

f:id:amarelo-n24:20211201001948p:plain

最後に

他にも紹介したい豆はありますが、今回は3つで終わりにしておこうと思います。 また別の機会に3つほどピックアップして書こうかなと思います。

自分は「甘味」を感じさせてくれる言葉に強く惹かれる傾向が強いため、ここから入ることをおススメしましたが、 インパクトを感じる言葉の傾向、好みの味は人それぞれです。 「カッコいい」「かわいい」と感じた名前からコーヒー豆を選んでみても良いと思います。

まずは第一印象で感じた豆を買ってみて、いろいろな豆を試してみてくださいね♪

redmine.tokyo 第21回勉強会 参加レポート

11/27(土) 「redmine.tokyo 第21回勉強会」に参加しました。

もう自分の中では恒例となった半年に一度のredmine.tokyo の勉強会、今回も様々な事例、Redmineを使い推進していく心構えを学ぶことができました。

今回も参加レポートを書いていきます。

目次

イベントページ

redmine.tokyo

YouTube

www.youtube.com

講演・LT(前半)

講演1:RedMica 2.0 新機能解説資料 @g_maedaさん

  • テキスト形式のフィルタで複数キーワードによるAND検索
    • スペースで区切るとAND検索
    • ""で区切るとこれまで通り単純なテキスト検索になる。
    • SQLワイルドカード(%_)をフィルタで使えなくなった。
  • ファイルの説明欄がフィルタに指定できるようになった。
    • 説明欄の検索も可能になった。
  • チケットのデフォルトクエリ
    • チケット一覧で特定のカスタムクエリをデフォルトで適用できるようになった。
    • Redmine Default Custom Query プラグイン相当の機能
  • グループごとに二要素認証必須設定
  • admin権限がないユーザでもグループメンバが表示可能に。
  • CommonMark Markdown の試験的サポート
    • HTMLタグが使える。
    • テーブルのセル内で改行や結合など、複雑なテーブルを書けるようになった。
  • Mermaid.jsによる作図
    • RedMica UI Extension プラグインがMermaid.jsによる作図に対応。

資料

www.slideshare.net

LT:ある工場の Redmine 2021" @netazoneさん

  • 添付したPDFの表示が面倒。ダウンロードなしでプレビューしたい。

    • view customizeで「BigPicture.js」組み込み
      • 画面遷移発生無しにプレビューを表示。
  • 通知メールがうざい

  • UIが古い

    • Purple Mine2
      • 右ペインが左に
    • 有料テーマ
      • 1年更新40-60ドル程度
        • Boostmine
          • かなりいじってありスタイリッシュ
        • Zenmine
          • Boostmineと同じ会社が作成
          • 標準に近い感じ
        • Abacusmine
          • これも標準に近い
    • 評価
      • 見た目をモダン化するには十分
      • 細かい作り込みはやや甘い
      • バージョンアップ追随される
  • まとめ

    • Redmineはカスタムするともっといいぞ!

資料

www.slideshare.net

LT:Redmine に必要なのは Confluence?" 齋藤 誠 さん

  • Redmineはシンプル、Jiraは多機能で何でもできる感あるが、少々分かりにくい。
  • Jiraはスクラムもカンバンも対応、Redmineは各種プラグインで。
  • ドキュメント管理について、Redmineは文書のリンクとWiki、JiraはConfluence。

  • Confluence

    • 表を簡単に作れる。
    • パワポで出来ることは大体できる。
    • 設計をしている間はほとんどConfluenceを使っている。
    • 仕様の変更履歴を確認・追跡できる。
  • スクラムのチケット運用

    • スプリント入れた段階ですべて二週間後に終わらせる。
    • 締切は一つしかない。消化方法は個人で考える。
    • スプリントの遅れが明確
  • 最後に

    • Confluenceは便利
    • 10名までならばSaaS版が無料。
    • Redmineでチケット切ってConfluenceでまとめるのもあり。

LT:アンガーマネジメント on RedMica"資料" @ryouma_nagare さん

  • 自分のタイプを知る(反するものに怒りを感じる)
    • アンガーマネジメント診断で検索
  • すべきという価値観を捨てる
  • 6秒間がまんする
  • 怒りを記録する

  • 転職はアンガーマネジメントの結果

    • 会社に貢献すべきという価値観を捨てた
    • もしこのスカウトをacceptしたら?と考えた
  • Redmicaでアンガーマネジメント

    • 怒りのチケットを起票
    • 不要なフィールドがあるとイライラするので非表示
    • 怒りを記録するのに非常に適している。
    • チケットの書き方を意識するので、6秒間がまんする、もし●●だったらと考えると自然と守れる。
    • 会社のRedmineには入れない方がいい。
    • それでも怒りを抑えられなかったら「DeathNote」プロジェクト

資料

www.slideshare.net

LT:RedMica Bridgeの紹介"資料" Fukuda Keiko さん

  • RedMica Bridgeとは
    • WebベースのRedmica
    • Redmineを気軽に利用してもらえるように
    • Redmineを個人のタスク管理ツールに
      • チケット機能に絞る
  • 機能
    • プロジェクトごとのチケット一覧
    • チケット作成・編集・コメント追加
  • 利用方法
    • RedMicaのサイトからアカウントとRedmine APIキーを登録

パネルディスカッション <Redmineとわたしたち> 

パネラー:みけねこさん、Tomokoさん、Ryokoさん、Mikaさん

Redmineのすきなところ、いまいちなところ

すきなところ

  • 記録に残しやすい
  • 記録を残せると、自分が欲しい情報を振り返ることができる。
  • 次の業務への抜け漏れを防ぐことができる。
  • 権限管理をフレキシブルに出来る。
  • カスタマイズがおもしろい。

いまいちなところ

  • ITエンジニア以外は使いづらい
  • 説明文が作文になってしまう。
  • UIがイマイチ
  • チケット入力までの導線がわかりづらい。
  • 自由過ぎるがそれが難しい。

Redmine利用のハードル

  • 初心者のハードル、とっかかりをどうにかできないか。
    • 利用する人のことを考えて作らないとならない。
  • ワークフローを設計しないとRedmineは使えないのでは?
  • テンプレートを用意
    • ユーザに選択させない。
    • URLにパラメータ埋め込んでテンプレート表示させる。
  • トロール
  • Redmineを使う業務を決めてフロー図見せることで納得してもらう。
    • 情報の集約場所、過去の情報もわかる。

伴走者

  • 使いづらいところを管理者に伝えて改善してもらっている。
    • 日々の使いやすさと改善の声を上げる立場。
  • 利用者が伝えてくれる要望を実現しようとしている。
  • ユーザが必要としているものを精査する。
  • 使ってもらってなんぼ。どうやったら使ってもらえるかを考える。
    • 日々のことからも相談しやすい雰囲気を創る。
    • みんなが幸せになることを分かってもらえるように。

人を大事にする

  • 敵対せずに使うためにはどうすればよいか?
    • 何事においても、つながる先には人がいることを常に頭に入れること。
    • 相手が分かりやすいように書くことが、人を大事にすることにつながるのではないか。
    • Redmineは説明を豊かにすることができる。
    • 文章の書き方に気をつける。
    • ツールを使うことにとらわれ過ぎない。
    • みんなが幸せになることを伝え続ける。

柔軟性

  • 新しいもの、新しい情報を受け入れて、自分の頭を柔らかくすること。
  • 人と話すこと。
  • 詳しいということにあぐらをかかずに、様々な意見を取り入れる。
  • 否定から入らない。
  • 小さなことでも始められるところは、まずやってみる。
    • 小さな改善を繰り返していくことでいい方向に向かっていく。
      • 小さな失敗と改善を繰り返すことをしやすいのがRedmine

講演・LT(後半)

講演2:林業におけるRedmine活用 田畑さん

  • 課題

    • 工程の全容がつかみづらい。
    • 情報格差が激しい。
    • 知っている人に作業が集中する。
  • 具体的手法

    • 作業手順は社内Wiki
    • 作業状況確認はRedmine + GTT plugin
    • プロジェクト=現場
    • バージョン=設計監督
    • トラッカー=設計、実施、監査
  • 導入で大変だったこと

    • 起票ができない。
    • 知っている人の時間を確保
    • 仕事の羅列
      • 知っている人の暇がない。
  • きこりのジレンマからの脱却

    • トップダウンで実施
    • 作業が進まなくても組織が死なない安心ができる状況を作る
  • よかったこと

    • 手戻りが減り各担当者が主体的に活動
    • 知っている人知らない人の差が圧倒的に縮小
    • 作業量の平準化
    • 作業の見通しがつきやすくなった。
  • 今やっていること

    • 何をするにしてもまずはチケットを確認・記述
    • 書いていくと安心という雰囲気の醸成
    • 見える化や情報文字化の推進

資料

speakerdeck.com

LT:Redmineで徒労を減らす" @MadoWindahead さん

  • さくせんのための武器防具仲間魔法

    • 武器防具
      • ありたい姿にたどり着く
      • 自分たちを守っていく
    • 仲間
      • こういうやつらがいればうまくいく
    • 回復魔法・攻撃魔法
      • こういう結果が出るから、さらに利用しやすくなる。
  • 徒労を減らす(トヘロス)ために

    • 自分より弱い敵と出会わない。ある程度強くなる。
      • 対応できそうな・成長が見込み目そうなメンバを揃える。
      • 必要な技術、前提条件をWikiやニュースに埋め込む。
    • 無駄を減らす・効率化する
      • 事実の把握における負荷やコストを減らす
        • Redmineがあれば不要なもの
          • 日報、月報
          • トラブル報告
          • 「今何やってるのか」という質問
        • 事実の把握から先手を打つことも可能
          • 予定のチェックからミスを事前に防ぐ
  • 強い敵とはたたかう。

    • プロジェクトにおける重要な内容はちゃんとやる。
    • そうなってるプロジェクトはあまりない。

資料

docs.google.com

LT:Redmine(SHERPA)の通知をMatterMost(チャット)に連携 iwsk さん

  • Redmineの標準通知メール通知したのをチャットで伝える手間を何とかできない。

    • SHERPAのコマンド通知機能を使って、メールと一緒にチャットに通知する。
  • 工夫したところ

    • オオカミ少年防止のため、必要なプロジェクトの特定のステータスだった場合にチャット通知。

LT:Redmine屋から見たMS Planner" @akipii さん

  • Plannerとは

    • Office365に付いているToDo管理ツール
  • 管理者や担当者が期待すること

    • 管理者は進捗状況が見たい。
    • 担当者は、報告作業を簡単にしたい。
  • 問題発生

    • タスクの更新が面倒
      • チェックリスト項目が多くて更新が手間過ぎる
    • 予定のタスクが多すぎる
    • 日次・週次の実績がわからない。
  • 原因

    • チェックリストやバケットは、作業状況のステータス管理に向かない
  • Redmineならばどうする?

    • トラッカーごとにワークフロー管理
    • ステータスは作業状態ごとに作成する
    • 親子チケットに分割する
    • Excel報告については、クエリで管理する
  • 業務フローを事前に洗い出そう

    • どんなワークフローでどんなステータス管理をするのか?
  • 誰のためのタスク管理ツールなのか?
  • できる作業者にマイクロマネジメント不要。

資料

www.slideshare.net

LT:Unofficial Redmine Cookingと直近のRedmineカスタマイズ事例の紹介" @y503unavailable さん

資料

speakerdeck.com

LT:Redmine パッチ会やってます! @juno_nishizaki さん

  • パッチ会に参加して良かったこと。

    • 参加しているうちにできることが増えていった。
    • できることが増えると嬉しい!
    • 大事なのは、やってみようという気持ち。
  • みなさんもいかがですか?

    • プログラミングのことがわからなくてもRedmineの改善に思いがあれば楽しめるはず。
    • オープンソースの開発に興味があるだけでもおススメ!
  • 次回のRedmineパッチ会

redmine-patch.connpass.com

資料

docs.google.com

LT:Redmine Japan Vol.2 開催します" @agilekawabata さん

  • 2022年2月25日(金)開催決定!
  • 「明日の仕事を変えるために必要なモノ」

感想

Redmineは良いものだけど、使う人のこと、組織のことを十分に考えて導入や推進するものだ」と改めて思いました。

自分の職場での進捗管理などはExcel管理なのですが、redmine.tokyoに参加して良い事例を学ぶことで、 自分の職場にも導入できないかとずっと思っていました。 これまでredmine.tokyoには何度も参加してきましたが、実は現時点でもほぼ未経験状態です。憧れの人をずっと遠くから見ているような気持ちで参加していました。

今年ようやくRedmineの導入を自分が進めることができるようになったものの、なかなか良さが伝わらずにいました。 さらに悶々としていたところで、今回の勉強会に参加して目が覚めました。 自分のために導入するのではなく、チームや会社の業務効率化、課題解決に使うものなのだから、足を引っ張ることになっては意味がない。 もう一度、

  • 目的(何のためのRedmineなのか)
  • 導入してどうしたいのか?どうありたいのか?
  • 関係者に手間をかけてしまうところは何か?

を見直し、関係者と共有するところからやり直そうと思いました。 結果的に導入を断念、失敗に終わるかもしれませんが、明日から改めてチャレンジしたいと思いました。 都合でディスカッションと懇親会には参加できませんでしたが、今回も多くの気づきと学びをいただけました。

一方、個人的にはRedmineを使って、コーヒーの焙煎記録を残せないかなどのチャレンジもしています。 そちらは完全に自分のためだけですが、将来的に誰かに見せる場合のこと、使いやすさ見やすさを考えて実現できればなぁと考えています。 Pranioで実現しようとしていましたが、いろいろカスタマイズした方が良さそうな気がして、サーバ建ててそちらでやろうかと思ってます。

感想長くなりましたが、先週までの仕事のモヤモヤが晴れた気がしました。 次回以降のどこかで実現できたことを登壇で発表できるよう、明日からも頑張ろうと思います!!

今回もありがとうございました!!!

JAWS-UG朝会 #27 参加レポート

11/8 JAWS-UG朝会 #27 に参加しましたので、レポートを書きます。

目次

イベントページ

jawsug-asa.connpass.com

登壇内容

セッション① ノンプログラマーAmazon Honeycodeでアプリを作ってみた emiさん

資料

speakerdeck.com

HoneyCodyとは

  • ノーコードアプリケーション開発できるフルマネージドサービス
    • 現時点でベータ版
  • AWSアカウントとは別にHoneyCodeアカウントを作成する必要がある。
    • メールアドレスのみ。クレカは不要。

HoneyCode主要概念

  • Table
    • 構造型データストア
  • builder
  • Automations
    • Tableのデータに対する変更やアプリ上の操作を起点に処理を実行
  • Workbook
    • 上記3つを包括する枠組み
    • 開発者や利用者に対し、Workbookやアプリケーションに権限付与

AWS認定取得状況アプリを作ってみた

  • 取得認定資格の選択
  • 新しい認定資格の追加

外部連携と制約

  • APIをたたいてTableデータのCreate,Read,Update,Deleteができる
  • 利用可能なリージョンが、オレゴンのみ。
  • AWS SSO連携する場合はオレゴンリージョンでセットアップが必要

まとめ

  • BuilderからGUIアプリを作成するのは結構大変
  • 目的に近いサンプルからアプリを展開してmodifyしていくのが良さそう
  • 日本語の情報がまだ少ない
  • 内部利用でアプリ作成するには良さそう

セッション② (仮)マルチアカウントでhealth情報を集約した 富松 広太さん

AWSからのメール

  • 24時間以内に対応するよう依頼が来た
  • Abuse(不正利用関連)の通知があるらしい
  • 緊急度の高いものはpush的に通知したく、AWS Healthを利用した。

AWS Health

  • Personal Health DashbordでAWSからの通知を確認できる。
  • Health + Organizationで全アカウントのHealthイベントを一括取得
    • Health APIを定期実行
    • 子アカウントでリソースを作成しなくて良い
    • 発生時間を指定してイベント取得を可能
  • Health + Organization API
    • 全eventを取得
    • eventに関するAWS AccountやAWS Resourceを取得

Tipsと失敗から学んだこと

  • 通知分類はリージョンとEventTypeCodeで考えると便利
  • 緊急度を2段階で分けると便利
    • メンテナンス系はチケット発行
    • Abuse系は人間に即時通知
  • 緊急度を高めておくと良さそうなEventTypeCode
    • AWS_ABUSE_XXXX:不正利用関連
    • AWS_CLOUDWATCH_XXXX:監視の機能不全
    • AWS_SES_XXXX:SES止める予告関連
    • 緊急のNWメンテ
    • AWSサービス名OPERATIONAL_ISSUE:サービス障害
  • Statusでフィルタしない方が良い
  • Ticket管理システムと連携する時

LT① QuickSIghtでCUR分析 アイディーエス 小寺 加奈子さん

AWSのコストと使用状況レポート(CUR)とは

  • コストと使用状況を包括的なデータとして確認できるレポート
    • 月次、日次、毎時間のレポートをS3に出力可能

可視化するには

  • Cost & Usage Report からS3バケットを出力設定
  • QuickSightのデータソースとしてS3を選択

可視化されると便利なこと

  • EC2インスタンスが何に使われていたのか
  • どのサービスにどのくらい課金されているか
  • 過去のデータとの比較ができるようになる
  • リソース変更時などのコストの確認が簡単になる

まとめ

  • コストと使用状況レポートを可視化できる。
  • CURレポートは請求金額が確定するまで日々の利用状況の積み重ねをすべてバージョン管理してS3に保管する。
    • 最新のレポートは、S3に出力される「マニフェストファイル」から確認する。
  • レポート更新は1日3回でリアルタイムではない。
    • QuickSightのデータセット取り込みもスケジュール化しておく。

LT② Control TowerとSIEM on OSSであっちこっちした件 小林 未来さん

資料

www.slideshare.net

すべてのはじまり

  • AWS上のログを追っていくのは大変だけど、セキュリティとは向き合いたい。
    • まとめて直感的に見れるよう、SIEM on OSS

SIEM on OSSとは

  • AWSオープンソースで公開している脅威検知の可視化ツール
  • LambdaでETL処理をしてCloudTrailのログを可視化してくれる

あっちこっちした流れ

  • 最初はシングルアカウントで構成したが、後々マルチアカウント構成に変更
  • Control Tower構成
  • 通知系はSecurityアカウントに集約
    • LogArchiveとの使い分け
      • 役割を決めなおした
  • マルチアカウント環境でのログ集約には高度なデプロイが必要
    • 事前にReadmeを読んでおくこと

まとめ

  • アカウント設計はちゃんとする
  • 手順書やReadmeはちゃんと読む
  • SIEM on OSSはおすすめ

LT③ AWS SSOでもアカウントエイリアスを表示したい!に応えるChrome拡張を作りました 小笠原 寛明さん

資料

docs.google.com

  • AWS SSOで生成されたアカウント名が画面に表示されない(最大61文字)
  • AWS SSOってスイッチロールみたいに色が変わるわけじゃない。
  • 既存chrome拡張だと設定が柔軟でなく、色の設定方法に不満があるため自作を決意した。

最後に

気になるサービス、不便に思うことは、触ってみたり作ってみたりを柔軟に考えたいと思わせられた朝会でした。不便に慣れるより、学んで得たことを活用して改善する。SOAの勉強をしながらいろいろ触って考えてみようと思いました。

来月か再来月にまた登壇したいなぁ。

JAWS-UG朝会 #26 参加レポート

10/28 JAWS-UG朝会 #26 に参加しました。 昨日、#27が行われましたが、#26のレポートを書いておいて公開していませんでした(汗) 今更ですいませんが、公開します。

目次

イベントページ

jawsug-asa.connpass.com

セッション① AWSソリューションのCFnで学ぶNaC NTTデータ 山本 泰士さん

  • TransitVPCとは?

    • 中継デバイスを経由し、VPCやオンプレミス間を中継するHubネットワーク
    • SpokeVPCのVGWにタグを追加するだけで、自動的にTransitVPC~SpokeVPC間のIPsecトンネルを確立・接続する。
      • 手動作業はVGWに特定のタグを付与するところのみ。
    • TransitGatewayやAutoScalingなどのサービスを組み合わせたり、vSRXやFortiGate、CISCO以外の機器を組み合わせることもできる。
      • AutoScalingと組み合わせた場合は、トラフィックに応じてSCR自動増減。スケーラビリティ向上。
  • TransitVPCのCloudFormation

    • Parametersセクション
      • スタック作成時に自由にパラメータ設定可能(デフォルト値もある)
        • 既存スタック・リソースのパラメータとの重複などは十分なケアが必要。
    • Resourceセクション
  • カスタムリソースとは?

    • 所定の書式でリソースを定義することで、関連付けられたLambdaを呼び出し、自由度の高いロジックを実装することが可能。
      • 呼び出し先はLambda、SNSも可能
  • TransitVPCのカスタムリソース

    • S3イベント作成の流れ(CloudFormationでタイプ指定できない例)
      • S3バケットにパラメータが格納されたことをトリガとしてLambda送信するように、S3にイベント通知を設定
    • RSAキー作成の流れ(CloudFormationテンプレートだけで実装できない一例)
      • 秘密鍵・公開鍵・フィンガープリントを生成・格納・設定し、Configurator関数がCSR1000vにアクセスできるよう設定
  • コード理解の不足による失敗談

    • 意図しないTransitVPC~SpokeVPC間の接続
      • 別のTransitVPCと同じタグを設定し、別のTransitVPC~SpokeVPC間で接続した。
    • AMI ID差異によるプロビジョニング失敗
      • MarketPlace内のAMIは更新していたが、CloudFormationテンプレートが更新されておらず、本番環境でプロビジョニング失敗した。
  • まとめ

    • CloudFormationとLambdaの組み合わせで詳細な設定が可能
    • なんでもかんでもLambdaに書くと可読性と保守性の良さが無くなる。
      • CFnとLambdaのバランスが重要
    • CFnとLambdaの内容を理解することで、有事の際の対応が楽になる。

セッション② AWS IoTのスゴいところご紹介 アイレット株式会社 本間 崇平さん

AWS IoT について

  • AWS IoTの仕組み

    • モノとなるデバイスへ制御を伝送したり、物の情報(テレメトリー)をAWS IoTを経由してアプリへ伝送することが可能となる。
  • AWS IoT Coreについて

    • インターネットに接続されたデバイスから、クラウドアプリケーションやその他のデバイスに簡単かつ安全に通信するためのマネージド型クラウドサービス
    • 数十億個のデバイスと数兆のメッセージをサポートしている。
  • バイス通信プロトコルメッセージブローカー

    • MQTT
      • 制約のあるデバイスように設計され、軽量で広く採用されているメッセージングプロトコル
    • MQTT over WSS
    • HTTPS
    • LoRaWAN
  • メッセージブローカー

  • モノの管理

    • IoTの物とは、クラウド内部の物理デバイスの表現と記録
    • 物理デバイスAWS IoTと連携するには、物の記録が必要
      • 物の名前をMQTTクライアントIDとして使用することがAWSで推奨されている。

AWS IoT のすごいところ

  • 証明書とポリシ

    • ポリシを作成して認可アクションのセットを定義できる。
    • 一つ以上のリソースのアクションを承認可能
  • ルールアクション

    • ルールがトリガされた時に動作を指定する。
    • 機能に応じて最適なリソースを選択できる
    • ログ保存と出力
  • FleetProvisioning

    • 動的に証明書払い出して解決してくれる。
  • DeviceShadow

    • 電源状態をシャドウに保存していれば、シャドウ参照で電源ONOFFが分かる。

まとめ

  • IoTのサービスは豊富にあるためすべて網羅はできていない
  • 要件次第ではIoTのマネージメントサービスを上手く活用することがベストプラクティスな手法となる。

LT① 辛くない CloudFormation 株式会社モリサワ 小室 貴史さん

資料

speakerdeck.com

辛いCloudFormation

  • 巨大なテンプレートで読むのが大変
    • ちょっとした変更のデプロイが困難
  • そのまま投入できない物
    • 初回のみ音対応が必要でコメントアウトとか
    • テンプレート内にリソースが追加されて依存関係が発生
      • CFn内では並行してリソースが作成される。
  • クロススタック参照の多用
    • 参照元のスタックの削除変更ができなくなって運用時に困る。

辛くないCloudFormation

  • 程よい大きさのテンプレートにする。
    • リソースのライフサイクルで分ける。
  • スタック作成順は残す。
    • クロススタック参照で困らないようにする。
    • Gitにテンプレとともに保存する。
  • すべてをCFnでムリにやらない。CLIも活用する。

LT② Quick Sight Qを使ってみよう アイディーエス 小寺 加奈子さん

  • QuickSight Qとは?
    • 機械学習を利用した自然言語クエリ機能
    • 利用にはEnterPriseエディションの利用が必要
    • 現時点では日本のリージョンでは未サポート

自分のLT

speakerdeck.com

資料にも書いて発表時にも話しましたが、ハンズオンは可能な限りGUICLI両方でやった方がいいなぁと改めて思いました。 これまでもCLI専門支部で感じてきたことですが、様々なハンズオンをやるたびに気づきやつまずきがたくさんあって、 何度も何度も思い知らされます!

最後に

自分の登壇の時に画面共有に手間取ってしまったのは痛恨の極みです。。。 3か月ぶりの登壇で少し緊張していたり、新しいモニターを買ってから初めての登壇だった・・・など、色々重なっていたと思います。 でも言い訳ですね(汗)環境変更後は余裕を持った行動をしないとなと思いました。

JAWS-UG CLI専門支部 #231R AWS CLI入門 参加レポート

10/14(木)JAWS-UG CLI専門支部 #231R AWS CLI入門 に参加しました。 CLI専門支部にはずっと参加していましたが、復習ブログはしばらく書いていませんでした。 久々になってしまいましたが、ブログ書いていきます。 今回はいつもと違い、座学多めでハンズオン少なめでしたが、 波田野さんのAWS CLIへの熱量がいつもより強くて濃い内容でした。 この記事では座学パートとLTについてを参加レポートとして書いていこうと思います。 ハンズオンの方は別記事に書きました。

zenn.dev

目次

イベントページ

jawsug-cli.connpass.com

AWS CLIについて

AWS CLIの概要

  • AWS公式コマンドラインインタフェース
    • 以前からあった個別プロダクトを統一したもの
  • Pythonの Boto coreライブラリをバックエンドで利用している
  • 約280サービスに対応
    • 基本的には1サービス1コマンド
    • S3のみハイレベルコマンドがある(s3,s3api)

AWS CLIの特徴

  • AWSサービスはAPIの集合体
    • AWSを真に理解するとはAWS APIの働きを理解すること
  • AWS CLIは基本的にサービスAPIのラッパー
    • 公開されているAWS APIのほぼすべてを操作できる。
    • AWS CLIを理解することでAWS APIの働きを理解できる。
  • 最新機能への対応が早い
    • バージョン1の方が積極的に更新されている(ほぼ週5回)
      • バージョン2は週2回(水・金)
  • ブラウザ(Cloud9、CloudShell)・Linuxなど多様な実行環境

AWSの変更作業にCLIを使う

  • マネコンだと何となく理解していればつつがなく作業完了してしまう。
  • AWS CLIだと過去の資産を使える。
  • マネコンだと処理が隠蔽化されているので、Undoできない。
  • CLIだと変更差異が確実にわかるので、Undoできる。

なぜGUIを使う人が多いのか?

  • GUIは楽
  • 直感的に操作できるから
  • グラフィカルな表示は分かりやすいから

それは本当か?

  • 突然UI改訂が起こる。
  • 手順書修正が追い付かず混乱する。
  • 直感に依存することで、論理だったコンピューティングを利用しなくなった可能性がある。
  • 情報過剰になりやすく、論理構造が把握しづらい。本質的な理解を妨げる側面もある。

  • 何となく、たぶんで接するコンピューティングは「IT」なのか?
  • 理解があやふやなまま本質をとらえる機会が得られずにコンピューティングしている「つもり」になりがち。
  • 過剰な情報から適切な取捨選択や推論ができないコンピューティングは「IT」なのか?

手順書の工数と品質

  • GUI作成手順はCLI手順の3倍手間、1/3の品質

AWSとどうつきあいたいのか?

それぞれの特徴

  • GUI
    • メリット:柔軟性がある。
    • デメリット:反復、再現性がない。
  • CLI
    • メリット:柔軟性、反復再現性がある。
    • デメリット:学習コストは高い。
  • SDK
    • メリット:反復、再現性
    • デメリット:柔軟性がない、陳腐化が早い。学習コストは高い。

付き合い方

  • AWSで手作業したいときは、GUICLI
  • 自動化したいときは、CLISDK
  • 両方に対応できるのはCLI
  • CLIを軸にSDKGUIに展開していくのが良い。
  • コストをかけないで良いところをCLIでやるのが良い。

AWS CLIの導入と更新

  • バージョン1
    • デフォルトブランチ
    • 週5回リリース
    • Cloud9、Amazon Linux2標準
    • パッケージ管理:pip3
    • シンプル
  • バージョン2

    • 週2回リリース
    • CloudShell標準
    • パッケージ管理:tar
    • 多機能・肥大
  • ハンズオンはバージョン1を利用

  • バージョン1の導入

    • Amazon Linux2では導入済
    • PIPでインストール
      • sudo pip install awscli==1.20.1(バージョン指定する必要があるならば、==<バージョン数>が必要)
    • aws --versionでバージョン確認

AWS CLIの構成要素

  • AWSの権限

    • IAMユーザ(マネコン)
      • MFA設定していないと悪用される恐れがある。
    • IAMユーザ(IAMアクセスキー)
      • アクセスキーが漏洩すると悪用される恐れがある
    • インスタンスプロファイル(IAMロール)
      • EC2インスタンス上では、インスタンスプロファイルに紐づいたIAMロールの権限で動作する。
      • AWSの認証情報をユーザが扱わない。認証情報が漏洩しないため安全。
        • Cloud9の場合はSSH接続できないのでさらに安全
  • AWSコマンド

  • jp.pyコマンド

    • AWS CLIに付属しているフィルタスクリプト
    • 標準出力やファイルに出力されたJSONをJMESPathでパース出来る

AWS CLIの利用方法

  • ハイレベルコマンド(UNIXライクな出力)
    • 引数指定
      • UNIXライクな入力
      • S3のみ対応(バージョン1)
  • APIコマンド(JSON出力)
    • パラメータ指定
      • UNIXライクな入力
    • JSON指定
      • JSONによる入力
        • --generate-cli-skeleton オプションでテンプレートが生成される

AWS CLIの入力

  • 書式

    aws s3api list-objects --bucket hoge

    • aws ではじまり、左からコマンド(s3api)、サブコマンド(list-object)、パラメータ(--bucket)、オプション

    • APIエンドポイント名とCLIコマンド名は、原則同じ

      • iam,route53,ec2,s3/s3api,lambda
    • APIエンドポイント

      • グローバルサービス https://iam.amazonaws.com
      • リージョナルサービス https://ec2.{リージョン}.amazonaws.com
    • APIアクションとCLIサブコマンド名は原則同じ パスカルケース チェイン(ケバブ)ケース

    • パラメータ

      • APIパラメータ名とCLIパラメータ名は原則同じ
        • InstanceType(パスカルケース) = --instance-type(チェインケース)
    • オプション

      • --query
        • JMESPath記法を利用
      • --output
        • defaultはJSON形式
        • テキストやテーブル形式での出力も可能
      • --debug

AWS CLIの出力

  • サーバサイドフィルタ
    • filterパラメータ
      • describe系コマンドは、filterパラメータが定義されている。
      • 定義されていないものはフィルタリングできない。
  • クライアントサイドフィルタ
    • queryオプション
      • すべてのJSONを処理できる。
      • APIの出力情報をすべて出力して転送するためパフォーマンスは良くない。データ転送量も多い。
      • 出力結果から特定のノードを取り出すことができる。
      • 「存在しない」を条件にすることは出来ない。
        • その場合は、jq.pyを使う必要がある。

AWS学習の中長期戦略

  • 早めにAWSと付き合う
  • 公式ドキュメントと付き合う
    • AWSが積極的に技術的なトピックやノウハウを公開している。
    • すべて読み込んで手を動かせば、誰でも国内有数のAWSエンジニアになれる。
      • すべて読み込むのは不可能(数十万ページ)
  • ビジネスで使ってみる
    • ビジネスで使えそうなプロダクトをつまみ食いする。
    • すべてのプロダクトを使うのは非現実的
    • 特徴ある使い方出来る人が強い。
    • 芋づる式に関連プロダクトに手を出していくと、その領域では数少ないAWSプロフェッショナルになれる

LT

バージョニング有効なS3バケットのオブジェクト一括削除(JQコマンド) emiさん

※資料が公開されたことを確認出来たら、追記します。

  • バージョニング有効なS3バケットの削除は、オブジェクト(過去バージョン含む)と削除マーカーすべての削除が必要
  • バージョニング有効なS3オブジェクトをたくさん消すのは大変
    • JQコマンドが使える
      • Cloud9環境にはないのでsudo yum -yu install jqでインストールが必要
      • CloudShellにはインストールされている
  • list-object-versionとjqコマンドでバージョンIDを一括取得
    • 削除マーカーなしのオブジェクトIDをすべてを取得できる。
    • 削除マーカーを指定してオブジェクトID取得もできる。
      • フォルダの削除マーカーはマネコンからは見えない。
  • オブジェクトの一括削除
    • バージョンIDを取得してオブジェクト削除をwhile文で繰り返す。
      • 削除マーカー以外のオブジェクトは削除できた。
    • 削除マーカーしか入っていないバケットの削除はできない。
      • 削除マーカーのオブジェクトIDを取得して一括削除できた。
      • その後バケットも削除することができた。

最後に

応用情報の受験も終わり、AWS SysOps Administrator Associateの勉強に重点を戻したところで今回のハンズオンに参加できた良かったです。 改めてAWS CLIを勉強することのメリットを見直すことができて、またAWSの勉強へのやる気が出てきました。 AWSの勉強の際は、GUIからだけでなくAWS CLIもできる限り取り組もうと思いました。

あとはやはりアウトプットは大事。CLI専門支部の復習ブログもまた出来る限り書いていきたいと思いました!!

JBUG Autumn 2021参加レポート

10/7(木)JBUG Autumn 2021に参加しましたので、レポートを書いていきます。

目次

イベントページ

jbug.connpass.com

セッション・LT内容

セッション1 私がマネージャーになって1番最初にやったこと 株式会社スノーピークビジネスソリューションズ 松井 勇樹 さん

課題

  • 案件進捗を各人からの報告に頼っている。
  • スケジュールが綿密に練られていない。
  • 予定に対する進捗が可視化されていない。

backlogの導入をしてみた。

  • 導入後1年、スケジュールとやることが明確になった。進捗が予定通りか正確に把握できるようになった。
  • backlogを導入してから、売り上げの目標値を達成で切るようになった。現在も更新中。

なぜうまくいったのか?

  • backlogはシンプルでわかりやすい。
  • メンバにメリットをもたらした。

プロジェクトが定着し組織が活性化する時の鉄則

  • プロセスの共有
  • WHYの合意形成
  • 全員参加型でスモールスタート
  • 良好な人間関係

  • 組織の成功循環モデル

    • 関係の質
    • 思考の質
    • 行動の質
    • 結果の質

まとめ

  • 良好な人間関係を構築しメンバにもメリットを感じてもらえるように。

セッション2 合言葉は「Backlog感出しますか」 株式会社ジーティーアイ 佐藤 毅

Backlog感を出すとは?

  • BacklogをBacklog然とした使い方をするだけ!
  • JBUGで見たかっこいいプロジェクトをマネするだけ!

その1:課題は最小単位のタスクで数多く

  • タスクを細分化して登録する
  • タスクを全部出し切るつもりで登録する。

その2:担当者をその都度変更する

  • 課題が終わったら、確認者を担当者に変更する。
  • タスクに責任の所在を明確にして優先して取り組めるように!
  • 相手が受け取りやすいように工夫すること。

その3:ステータスをどんどん進める

  • 進捗をこなすとどんどんタスクをこなしたくなる。
  • カンバンボード上でステータス変更して気分を盛り上げる。
  • ステータスの変更ルールは最初に決めておこう。

まとめ

  • Backlogでプロジェクトをスムーズにいくとは限らないけど、プロジェクトをより楽しく進めることができる。
  • 組織にあったBacklog感を出して、その内容をJBUGで登壇してみよう。

LT1 グラレコで猛攻撃に遭った後、救われた話 安積 津友香 さん

  • グラレコとは?

    • 話しの本質だけを見抜いて描く。
  • グラレコで議事録を書いていたが、チームリーダから攻撃を受けてやめていた。

  • プロマネからグラレコを褒められて救われた。
  • 別の部署のデザイナーさんから勉強会の依頼が来た。
  • 人と人とのつながりを創るためにグラレコを続けたい。

LT2 WikiFigmaを活用したら全員ちょっと幸せになった話 恩田 淳子さん

チームのこれまで

  • 資料、課題、デザインデータがとっ散らかっていた。
  • 職人たちの勘と経験、そして気合で乗り切る。
  • 情報が適切に連携されておらず、属人的・非効率
  • 品質管理が難しい。

取り組んだこと

  • BacklogのWikiFigmaに情報をまとめる。
    • プロジェクトに関わる主要な情報すべてWikiに記入。
    • ビジュアルに関わる要件をFigmaに記録。
    • WikiFigmaを見て開発、検品をした。
  • 申し送りミーティング

成果

  • 小さな変化だけど、全員ちょっとだけ幸せになった。
  • 各自やるからチームでやるマインドへ
  • 情報探しが大幅に減った。
  • 検品工数が20%減った。

まとめ

  • あなたの困ったはチームの困ったかもしれない。
  • 情報はまとめよう。

LT3 システムエンジニアとして過ごした2年間の振り返り Kazuhiro.Yoshida さん

  • SEとPMの兼任
  • SEとしての悩み
    • 知識不足
    • エンジニアへの仕様の伝え方
      • backlogとチャットを使ってコミュニケーション
  • PMとしての悩み
    • プロジェクトが終わらない。
    • 人の管理

パネルセッション 〜JBUGのプロマネに聞いてみたい、あんなことやこんなこと〜

今と昔のプロジェクトマネジメントで変わったと思うこと

  • プロジェクト管理ツールの発展で見える化しやすくなった。
  • チャットツールでコミュニケーションしやすくなった。
  • プロジェクトのマネジメントとプロジェクトのマネジメントの違いが出てきた。

  • PMの権限が変わってきている。

    • 無理やりにでも働かせるかより、メンバに気持ちよく働いてもらうことを考える必要がある。
      • 少ない時間で多くのアウトプットを出せるようにムダなことを無くす。
      • 「四の五の言わずにやれ!」はもう通用しない。
      • 優しいだけでなく、背景や時代に合わせた「喝」を入れることは必要。

プロジェクト管理ツール、チャット、通話、リアルでの会話どう使い分けしている。

  • オンラインとオフラインの切り分けは模索中。
  • 込み入った話の場合は通話、エンジニアとの話は書いて示すなど、その場その場でよいツールを使っていく。

45歳定年説について。プロジェクトマネージャーのターニングポイント。

  • NeedsとWantsがあれば年齢がいくつでもやれると思う。働き盛りの年齢でもそれがなければやらない方が良い。
    • 良くないプロマネの下につくメンバが不幸になる。
  • 身体的な変化、環境の変化に合わせながらアップデートしていく必要がある。
  • ビジネスに旬なセンスを持っている人が不確実性のある決断をしていくのが良いと思う。
  • 45以上の人が活躍できるような場面はあって良いと思うが、自己研鑽する意欲がある人に任せる仕事だと思う。
  • 経験と勘がものを言う領域は増えていくと思う。腹をくくって経験と勘を基に判断を見せられる人は続けられると思う。

メンバのレベルを上げながらプロジェクトを完遂できるようなコツ?

  • 人によって接し方を変える。
    • 熟練者には抽象的な話し方、そうでない人には細かな指示を。
    • きめ細やかにコミュニケーション
  • 全体の底上げ
    • 能力差が出ないようなレベル上げ
    • 人によってやり方を組み合わせながら、全体のレベルを上げていく。

プロジェクトが殺伐としたときはどうする?

  • リーダーがユーモアを出して緊張感を緩めていく力が必要。
  • 殺伐とする予兆があるときにつぶしていく。

仕事の可視化を嫌がる人への対応

  • その人は成果を出してくれればよい。
  • 手がかかる方に手をかける。
  • 仕事に前向きになれないなど、別の要因があると思われる。その問題にアプローチした方が良いか考える。

全メンバでの定例ミーティングはどれくらいでやっている?

  • 基本は週一。
  • 規模とゴールまでの期間による。
  • 最初決めたやり方に固執しすぎず、状況見ながら見直していけるスキルが大事。
  • プロジェクトマネージャーが聞きたいタイミング。

感想

自分が推し進めたいことのメリット、困りごとを改善した後の景色を理解してもらえるように伝えなければならないし、 それ以前に信用してもらえるだけの人間関係を作り維持していきたいと思いました。

ユーモアは良好な人間関係作るのに必要だなと思いました。 オンラインだとそれが発揮しづらいところだけど、そこはツールをうまく使うことでカバーできると思います。 雰囲気的にやりづらいところはあるけど、もっと肩の力抜いてコミュニケーションしてみようと思いました。

安積さんのグラレコで人と人のつながりを創ったお話は、人間関係と和やかな雰囲気を創ってとても素敵だなぁ思いました。 絵を描くの得意ではないですが、自分も描いてみました!グラレコ一度挑戦してみようかな?

今回も仕事への取り組み方に参考になる話を聞けて多くの気づきをいただけました。 登壇者の皆様、運営の皆様、遅くまでありがとうございました。