オンデマンドセッション店回り感想（Day４）
４日目だよ。だいぶ楽しくなってきたのでこのまま続けて習慣化したい。
１日目と同様、念のため。利害関係はありません。内容を避難するようなものでもありません。
アップするつもりで視聴する。アップするつもりでざっとまとめる。今回の記事の意図としてはそんなところです。
目次
本日のお祭り会場① Developers.IO 2020 connect
Fortinet Fortigate Next-Generation Firewall でサクッと作るリモートアクセス VPN（SSL-VPN）
すごいぶっ飛ばして始まる！本当にサクサクつくっていく！
Fortinet, Fortigateがまずわかんね。ということで。
Fortinet Fortigate 次世代Firrewall
https://www.fortinet.com/jp/products/next-generation-firewall
たんたんとネットワークを作っていくからなんのこっちゃとおもったけど、FortigateがEC2もAMIとして選べるんですね。なるほど。
全部みてようやく何がしたかったのか（目的）がわかったけど。なんだか詳細がいまいちわからんかったけど、帰宅後に２週目みながら手を動かしてたらだいぶ理解できた（つもり）
ハイトラフィック運用 〜スループットの向上を目指して〜
https://youtu.be/smA6RAuCmC4
Webサイトのレスポンス。スループットの向上について。
ボトルネックのとくてい、チューニングの「観点」を紹介してくれている。
通信レイヤーごとの事例紹介のような形。あらゆる問題は問題を定義するところからがスタートだとおもう。
lambda@edgeにはレスポンスサイズに制限がある。なるほど。同時実行数も。
スロークエリの話が出てた
qiita.com
なにこればちくそ楽ちんじゃん・・・ロジックに埋め込んでたりいろいろやってたけど。いい時代になったなぁ。
DB周りのはなし、最終的にはスケールアップ、スケールアウトがでてくるあたりのクラウド感。オンプレじゃそこは基本的にNGだから、
可読性を犠牲にしたり、あれやこれやで凌ぐほうが圧倒的に多い。費用対効果のトレードオフで、とりあえずスケールしとけばいいんじゃね？
の判断が取れる。というのは強いと思う（是非はある。あるけど策がとれるところが大きい）
まとめ
初日に見ていたものと比べてどんどんディープになってきている気がする。
この辺でまだまだ浅いのだろうから、恐ろしい世界だなぁ。
オンデマンドセッション店回り感想（Day３）
3日目でがんす。いぇいいぇい。完全に視聴ペースを振り切りました。観測していなかっただけで、
そもそもそーゆーもんですね。
せっかくのお祭りなので、楽しんでいきます。
１日目と同様、念のため。利害関係はありません。内容を避難するようなものでもありません。
アップするつもりで視聴する。アップするつもりでざっとまとめる。今回の記事の意図としてはそんなところです。
目次
お祭り会場① Developers.IO 2020Connect
AWSのVDI WorkSpacesを使ってテレワーク環境を実装するときの勘所
Workspacesを使ったテレワーク。新型コロナウイルスはいろんなところに影響を与えていますね。ということで
序盤はテレワーク需要の話で、一般的な話ではないかと思う。そこからテレワークのメリットに話が移っていく。
オフィスコスト削減の話ですが、オフィスのあり方を考えるいい機会だと考えます。
今までは「仕事といえば、通勤して同じオフィスで顔を合わして」が基本でした。が、なぜこうしないといけないかは深く考えれていなかった
のではないかと思います。今は「働く場所」という意味では「テレワーク」というものが生まれています。
public class Office
{
}だったわけですが、本当はこうだった？
interface WorkSpace
public class Office : WorkSpace
{
}
public class TellWork : WorkSpace
{
}もっと言えば
public class Office : WorkSpace, Other1, Other2 ... etc
他。どういった機能で「オフィス」があるか。そういったことのように私は捉えています。
セッションはテレワークの話から、テレワーク関連のAWSサービスの説明に移っていきます。
WorkSpacesの導入例は丁寧説明しているので勉強になった。とても具体的だと思う。
「Amazon EKS Best Practices Guide for Security」を読み解く
ドキュメントを読み解く。というのはまた新しい観点だと思った。ベストプラクティスの紹介。というタイトルと読み替えても差し支えないと思う。
アイデンティティとアクセス管理。EKSではAWSと、K8sの両方のアクセス管理を利用している。そしてPodの話に移る。
待っていただきたい。あたかもポッドがなんであるかは自明なように進んでいくが、私にはなんのことかわからない。そもそもk8sの知識がボロボロなのだ。
多分僕はこの動画の視聴対象から外れ気味ではあると思う。前提知識が足りてなさすぎる。ということで、ちょっとだけ調べながら見ることにした。
k8s
https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/
ポッド
kubernetes.io
ローリングアップデート
https://www.designet.co.jp/ossinfo/kubernetes/update/#:~:text=%E3%83%AD%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%A8%E3%81%AF%E3%80%81%E5%90%8C%E3%81%98,%E3%82%92%E8%A1%8C%E3%81%A3%E3%81%A6%E3%81%84%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82
この辺が限界。だめだ。まだ私にはこのセッションを見るパワーはない。露骨にない。
まとめ
だいぶざっくり。３日目になるとだいぶ感想もこなれてきたかもしれない。
まだ１日目も見切れてないのに今日さらに別セッションが追加されてます。まーそんなもんよね。
お祭り会場② Microsoft DE:CODE2020
基調講演K11 Azure DevOps
AWSをさらさらーと触ってる。Azureのリージョン数がいま61。
BlazerWebAssemblyですって？？？メインでC＃を使っている身としては、そのまま利用できる範囲が増えるのは嬉しいです。
リモートコーディングの課題。VisualStdioのブラウザ版というのはこの記事のことですかね。
qiita.com
Azureというか、Microsoftは組み合わせがシンプルなきがするな。ある程度のフレームはがっちり決めてくれる感じ。
そのあたりは「なーんにもわーからん」状態でもすんなり受け入れやすいとこかなーと思う。
基調講演K12 Power of Tech Intensity
やはり時代はローコードの方にすすんでいるのか。まぁ、そうだーよな。
プログラムを書く能力は別に求められていなくて、問題を解決する力こそが必要になってきている。
もしかしたら僕が死ぬまではなんとか今のスタイルでやっていけるかもしれないが。
事例２事例紹介されているが。。。
PowerPlatformはいずれ業務でお会いしそうな匂いすらある。Saleceforceとくいあってる感じかねぇ
市民開発か。。。冗談で総務にいくべか。的な話をしてた時があるけど、総務でも使ってもらえないだろうね。
どこにいくにも勉強of勉強だな
まとめ
基調講演ということもあってかとりあえず頭に入ってきたし、新しい情報も知れたしで満足満足。
明日以降は各セッションで詳しいところが見れていくのか。な。
だいぶ不謹慎かもしれないけど、新型コロナの影響でオンラインセッションが増えて、そのおかけでこうして視聴できるんだから、
何がどう転ぶかってのは本当にわかったもんじゃないなぁ。
オンデマンドセッション店回り感想（Day２）
2日目でがんす。いぇいいぇい。視聴ペースが間に合わないぜ！
今日も楽しいお祭りヒャッハー。DE:CODEも見て回りたかったんだけど、なんか通信の状態わるいようで・・・（Twitter調べ）
１日目と同様、念のため。利害関係はありません。内容を避難するようなものでもありません。
アップするつもりで視聴する。アップするつもりでざっとまとめる。今回の記事の意図としてはそんなところです。
目次
お祭り会場① Developers.IO 2020Connect
知らなくても困らないけど、知ると楽しいVPCの裏側の世界
https://youtu.be/rw45QWG6DOQ
VPCでぃーぷだーいぶぅぅぅ。
たぶんベースはこの記事
dev.classmethod.jp
他のセッションと比べるとちょっと必要としているベースの知識がきついのでは。とおもった。
ネットワークのところから。裏側というか。表側というか。IPAの基本情報、応用情報をベースにネットーワーク、インフラの知識が入っている私としては、
AWS（EC2）のイメージとしてこの説明から入った方がすんなりだったかもしれない。けどなんか誤解して覚えそうでもあるなぁ。
最初はレイヤ２通信、ARP。
EC２同士の通信。レイヤ２通信。ENIによるMACアドレス。
VPCはブロードキャストに対応していない→マッピングサービス
物理的なホストの経由はどうしようか→マッピングサービス
マッピングサービスやるじゃん！みたいな話が前半。
そこから同サブネット通信がわかったので次は別サブネットの通信に話が移ります。
まぁ、またマッピングサービスが無双します。
これらのことを意識しなくていいのが、EC2というかクラウドの利点だとも思うけど。こーゆー知識どうなっていくんだろうなぁ。
今でも実務ではほとんど使ってないけーども
Blackfoot、Hyperplaneノード。非公開情報も解釈含めて図示しているのでわかりやすかった。
初心者だからこそ触りたい、AWS CLI
https://youtu.be/TWIjnlmMHzE
CLI（V2）入門。CUIはなれると楽。そしてどこでも同じように使えるのが強いと思う。
食わず嫌いというか。なんとなく苦手意識がある人がいるのは確かに。とおもった。
そういえばなんでCUI（GUI）がいいんだっけ。それぞれの目指しているところはどこだっけか。となんか明後日の方向に思考が飛んで行ってしまったけど、
揮発材としてよかったなぁ。AWSのCUI（CLI）はクレデンシャルの管理が怖くて使ってない人もいるのんじゃないかなぁ。気のせいかも。私はちょっと怖い。
新卒エンジニアが、入社最終面接に持って行ったポートフォリオWebAPIを、入社後に得た知見で見直してみる ~ サーバーレスのCI/CDやってみた
https://youtu.be/Q-0nm5IcOco
クラスメソッドさんの採用の一端がしれてよいかもしれない。
amazon recognition. 作って遊ぶには楽しそう
入社前後のポートフォリオの変化というのは面白いと思った。
タイトルとは内容はちょっと違っていてDeveloperよりのAWSアーキテクチャというか、そのような内容で勉強になった。
DynamoDBとElasticsearch Serviceを組み合わせて、簡単な全文検索を実装してみた話
サーバレス。DynamoDBの全文検索。
視聴前にこちらをみておさらいしたほうがいいかもしれない。
https://dev.classmethod.jp/articles/conceptual-learning-about-dynamodb-lsi/
ElasticsearchServiceの使用事例がしれた。
Triggerみたいだなー。LambdaだからTriggerで間違ってないんだろうけど。
うーん。なんかぼーっと見てしまってあんまり感想がわかないのは、おそらく話がピンときてないからだろうとおもう。
実際に困りそう、困ったことのほうがどうしても反応が強くでるようで。ちょっと頭の片隅にでも置いておけたらいいかなぁということにしておこう。
ケーススタディで学ぶ企業運営〜クラスメソッドの新型コロナ対応
COVID-19の振り返り。まずはおさらいから。うんうん。大体僕の頭に入ってる認識と同じだ。
クラスメソッドではオフィス、組織の拡大が起こっており・・・
というところで。元々テレワークの準備はできてはいたが、テレワークの推奨宣言がめちゃくちゃ早いと思う。
準備ができていたからともいえると思う。
オフィスについても、しっかりと経営的な判断のもとに動かれていて、さすがだなぁといった感じ。
全体として。しっかりちゃんと「組織」になっているんだよなーと思う。お気持ちの介入がほとんどない。
非常にロジカルだと思う。QAの回答も強い。これ、もう失敗も失敗じゃないような感じがるするのは気のせいだろうか。
これから始めるAWS移行のベストプラクティス
1日目もみたAWSへの移行のはなし。タイトルの通りベストプラクティスなのであまり発表者の意見などはなかったかのように思う。
何のためにAWSに移行するの？大事なことだと思った。以降のさいにKPI等定量評価はいいと思う。数字に振り回されないようにコントロールは必要かと思いますが。
以降計画の６Ｒは出現二度目なので、要確認なのかなぁ。
「移行」をキーワードに全体像を丁寧に説明してくれていました。カバーしている範囲がめちゃくちゃ広くて、がっちり視聴する必要があるかな。
「ＡＷＳ」全然わからん。状態から視聴しても何とでもなりそう。素晴らしい。「移行」とはいっているけど。ＡＷＳ入門動画としても機能しそうなボリューム。
途中から意識が学習モードにうつってしまた・・・もう１、２週して落とし込んでいかないと感想がでてこないな。
まとめ
昨日も思ったけど、全体的に「難しい言葉を減らす」意識がしっかりできている気がする。と感じた。
資料上は用語はでてくるけど。内容としてはちゃんと別の言葉に置き換わっている。丁寧である。
あとつい見入ってしまって感想書くの忘れてしまう。「ほげー。まじかよー」みたいになって書けなくなる。
オンデマンドセッション店回り感想（Day１）
こんばんみ。なぜだか知りませんが各所で祭りが始まっているので、出店を見て回った感想。
６月はなんかそーいうあれなんですかね。
目次
- １日目。全部版URL
- ALL AWS Certifications EngineerによるAWS認定全制覇への道
- クラウド移行の前に考えること
- CloudGoat で AWS セキュリティの世界に入門しよう
- はじめてのCloudFormation
- Terraform入門 on AWS
- まとめ
今日見て回ったお祭り会場。Developers.IO 2020Connect
classmethod.jp
念のため言っておきますが利害関係はありません。内容を避難するようなものでもありません。
アップするつもりで視聴する。アップするつもりでざっとまとめる。今回の記事の意図としてはそんなところです。
１日目。全部版URL
https://www.youtube.com/playlist?list=PLL6J8djFsPBVwK3fMDluLlzmqIDZ4_0Qv
※現時点でいつまで動画が残っているか不明です。以降のリンクも含めて削除される可能性があります。
ALL AWS Certifications EngineerによるAWS認定全制覇への道
https://youtu.be/1kK9mrEoboo
AWS認定について（１２種類）全部制覇してるので、どんなもんよ。という話。
詳しい内容はAWSの公式をみればわかるといえばわかるんだろうけど、
難易度なんかは個人の感覚が大きくて、参考になった。
取得のメリット、勉強方法なども独自の見解を解説されているので、見てよかった。
特に認識が改まったかと言われるとそうでもないけども。
いわゆる「筋トレ」というのはいい表現だと思う。
クラウド移行の前に考えること
これまたイイハナシダナー。それじゃぁ感想にならないんですね。
どちらかというと、これからクラウドを導入しようとか。上からのクラウドでどうにかしてくれ。とか
そういったことでこれから使ってみよう。どうしたらいいんだろうか。という人にとってはとてもよい話だったと思う。
例えば
なぜ思ったように進まないのか。
・規定にそわない
・コストが合わない
・以降に時間がかかる
・アプリの回収インパクトが大きすぎる
というような話がでてくる。個人的には以前視聴した
基調講演：https://youtu.be/wZA5rH8yFr4
で言っていた内容をコンパクトにまとめてくれていた形なのかな。と思った。当たり前っちゃ当たり前なんですが、
クラウドを使うのが目的になってしまうと辛いですね。そーゆー理解をしました。
CloudGoat で AWS セキュリティの世界に入門しよう
セキュリティ学習ツール。CloudGoatの話。
以前どこかで記事を見たのをおぼろげに思い出した。多分ご本人の記事だと思う。
CloudGoatのセットアップと環境構築、シナリオの進め方とかその辺の解説があった。
なにやら他のセッションとは動画の雰囲気がちがう。BGMが違う。話し方も穏やか。
淀みがなさすぎて、ガチの導入動画と疑うレベル。（すごく気を使って発音していたのではないかと思う。）
CloudGoatは「攻撃者」側を楽しめる。専門時代に「セキュリティを学ぶ一番の方法は、とりあえず攻撃してみることだね」
みたいなことを言われたのを思い出した。学校だけではなく、企業の研修学習にも使えるんじゃないかなぁ。
内容については特に個別の意見等はなかった。CloudGoatに興味を持たせるには十分な内容だと思う。
はじめてのCloudFormation
CloudFormationはなんとなく理解はしていたのだけれど。もう一歩解像度が上がった気がする。
CloudFormationを使う理由はなんだろう。なにがうれしんだろう。とか。実際に考えてみるとなるほどねぇという感じ。
デモの充実していて、ざっとCloudFormationについて知るのにもよい内容だと思った。ちょっとしたトラブルシュートもある。
トラブルシュート内での大文字小文字に対する対応が「気をつける」というのはつらいなぁ。とIDE頼りの私としては思わなくもなかったです。
気をつけなくてもいい方法があるとうれしいなぁ。
Terraform入門 on AWS
Terraform入門。タイトルに偽りなしといった感じ。というより30分モリモリで実際の動作もアリアリのバッチリ入門だったのでは無いだろうか。
名前は知っていたが。ぜーんぜん知らんかったので、雰囲気をつかめただけでも収穫がありました。
先のセッションにもあったが、AWS構築＝CloudFormationみたいな認識があったが。そうでもなさそう
GCP他でも使えるというのは、学習に対するパフォーマンスがよさそうと感じた。
リソースの参照はこっちの方が直感的で、プログラムを触ったことのある人はCloudFormationよりもとっつきやすいのではないだろうか。
ただ、反対にそれなりに自由にかけそうなので非常に苦しいTerraformのコードが生まれ始めてるんだろうな。という気もする。書けると書いちゃうんだよね。複雑に。
まとめ
他にもセッションはたくさんありましたが、１日で見て回るには限界が。
通してみるとそれはそれで違った趣がありました。
CloudFormation→TerraFormの流れは我ながらにいい順番だったなと。他もなんとなしに順番を意識されているのではないかなぁ。とか、そんなことを感じました。（動画の時間も初めの方は短めで、とっつきやすさをあげてたりするのかなーなんて勝手に想像しています。）
今日はAWS中心でしたが、明日以降はまた別のセッションが公開されます。本日公開分も含めてなるべく見て回りたいなぁといったところです。
明日はMicrosoft DECODEの方も開催されます。どこまで追いきれるかわかりませんが。なるべくなるべく。
こりずにAWS試験を受けて落ちてきた。
ずいぶん久しぶりに更新しました。言い訳的にここ最近ずっとAWSの動画を見ていて、
特に書くことも作れずに日々が過ぎていってました。
その上で、同日２区分受験してみましたが惨敗。言い訳にもなりません。
悲しみを乗り越えて次に進むためにも敗北の記録を残します。
目次
主な学習方法
帰宅後にudemyで動画みてました。あとは各種Blackbeltをみたり、
udemyは２本みたのですが。
https://www.udemy.com/share/101XFiAEIdeFlaQ3oB/
こちらは日本語。すべて目を通せてないんですが、すこしこの講座では足りないかな。といった印象。
https://www.udemy.com/share/101WESAEIdeFlaQ3oB/
こちらは英語です。字幕を追いながらなんとか理解を重ねるように使っているのですが、
私の英語能力もあってやはり表層しか入っていなかった模様。もう一周は見てみようとおもいます。
苦手な分野と課題
全般的に。と言ってしまうとおしまいですが。
私の場合、実業務でAWSを使用しているわけでもないので、圧倒的に経験不足が否めないです。
ソリューションアーキテクトは問題解決なわけで、あれこれサービスを知っていても「課題」に対してベストな選択ができないといけません。
このあたりは学習の仕方に問題があったかな。と反省しています。EC2がどうとか、S3がどうとかではなくて、
「Webサイトを公開したいんだけど、アクセス数がほにゃほにゃでなるべく安めにあげたいんだ。」
とか、そういった問題に対する解決さくとしてサービスを提案できないといけない。知識の導線がミスってました。
デベロッパーに関しても同じようなことが言えると思います。試験が認定する人物、スキルを正確に理解できてなかった。ということになります。
とまぁ、全般的に足りてないのは足りてないんですが、おおよそ以下のような要素で悩みました。
・サービスを利用する際のセッション情報のコントロール（どこにどうやって配置して実現するか）
・最適なストレージの選択（データの種類、アクセス方法に応じた選択）
・VPC間の接続（ネットワークトラフィックのコントロール）
まぁ、弱かったのはこの辺。ここらあたりをサラーっと理解してたせいで突っ込まれて全然わからん。そんな感じでした。
上記の内容を
「デプロイ」とか「静的、動的コンテンツの提供」とか「マイグレーション」とか「ECサイト」とか
そういった実際の問題に絡めて理解していかないとダメでした。
極端に弱かったのは
ECR、Kinesis、APIGatewayとLambda。この辺。
それぞれがどういったものかはおぼろげながらに掴んではいますが、この辺りは他のサービスと連携して
力を発揮するところがあるようで、ベストな構成をほとんど理解できていません。
上にもかいていますが、ストレージの考慮も厄介でした。
キャッシュデータなのか、永続データなのか。同時アクセス数がどう。保存期間がどう。読み取り専用その他もろもろ。
「ははーん。とりあえずS3においとけばいいんじゃね？」の精神でしたがストレージの選択肢はもっと広いようです。学習が足りてませんでした。
反対にUdemyで見てたELBとか前回やらかして厚めに学習していたDynamoDBに関して結構答えられた気がします。
「実際の問題」を想像しながら、UdemyなりBalckbeltなりをもう一度見返してみようと思います。（触れるところは実際に触るのも必要ですね）
次回は８月かなー。
Doxygenをインストールしてつかってみた（Windows）
目次
コードからドキュメントを生成できるのは喜ばしいこと。
ということでDoxygenインストールしてみました。
環境
OS：Windows10
解析対象：NAudio（https://github.com/naudio/NAudio）
セットアップ
www.doxygen.jp
こちらのサイトより取得。サイト右端のダウンロードからWindows用のExeを取得します。
gyazo.com
「doxygen-1.8.18-setup.exe」
gyazo.com
ダウンロード後にウィザードに従いインストールします。（数分）
私はとりあえず全部コンテンツをインストールしました。完了。
パスを通しておく。
インストールフォルダに対してパスを通しておきましょう。
gyazo.com
システム詳細設定から環境変数を選び
gyazo.com
Pathを選択した状態で編集
gyazo.com
Doxygen.exeのある階層を新規に追加します。（私はD～にインストールしたので画像の通りです）
gyazo.com
「doxygen」とコマンドをたたいて下のように出ればOKです。
gyazo.com
※GUIもあるようなのですが、マニュアルがコマンドベースだったのでCUIでいきました。
マニュアルに従って初期設定をしてきます。
マニュアル
http://www.doxygen.jp/starting.html
設定ファイルを生成
生成コマンド
doxygen -g
gyazo.com
gyazo.com
ちゃんとできましたね。
実行
設定ファイルができあがるとすぐに実行できます。
doxygen <config-file>
で実行します。configファイルの名前は省略したので「doxygen Doxyfile」で実行です。
プロンプト画面をみて想像がついているかもしれませんが、作業ディレクトリはソースコードが格納されているルートディレクトリで
作業しています。設定を細かくすることで、任意の場所で操作することが可能のようです。
gyazo.com
出力フォーマットも選べます。私の場合設定がガバガバなので作業ディレクトリの直下にHTML形式で出力されます。
びっくりするほど素早く生成できたとおもいます。
gyazo.com
Index.htmlを開いてみます。
gyazo.com
速いもなにも。なにもありません。なぜでしょう。設定がガバガバだからです。
本文を引用しますと
少しの C/C++ ソースとヘッダーファイルからなる小さなプロジェクトでは、 INPUT タグは空のままにできます。この場合 doxygen はカレントディレクトリのソースを検索します。
ソースディレクトリまたはツリーからなる大きいプロジェクトの場合、 ルートディレクトリまたは複数ディレクトリを INPUT タグに指定し、1つ以上のファイルパターンを FILE_PATTERNS タグに追加します(例えば *.cpp *.h)。 パターンのうち1つとマッチするファイルだけが構文解析されます (パターンが省略された場合、ソース拡張子のリストが使われます)。
多少ならいけるけど、でかいならちゃんとINPUTタグ設定してね。と読み替えて問題ないように思えます。そうしましょう。
C#用にINPUTタグを編集する。
Doxyfileを編集します。エディタは自由にしてください。
このファイルで全動作の設定を行うようなので、デフォルトのままでもなかなかの行数があります。（2000行超え）
gyazo.com
目視で調べるのは得策ではないでしょう。ほしいのはFILE_PATTERNSタグなので、検索すると800行目にありました。
gyazo.com
INPUTはどのように設定するのでしょうか。ここもマニュアルをみてみましょう。
http://www.doxygen.jp/config.html#cfg_input
gyazo.com
さて。ここで問題が発生します。オプションをみても実際に実行してみてもディレクトリを再帰的には検索してくれないようです。
全部スペースで区切ってくっつけろとのことでしょう。大量のディレクトリをいちいち手打ちするのは面倒アンド面倒です。
2020/05/11 追記。 嘘つきました「RECURSIVE」オプションがちゃんとありました。ここをYESにすると再帰的に処理されます。ですよね！！！！
cmdでさくっととりあえず欲しい階層の一覧をゲットしましょう。
@echo off set directory=D:\03_git\NAudio for /d /r %directory% %a in (*) do ( echo %a )
でいけます。derectoryのところはお好みで・・・
echoなのでずらっとでます。本当は半角スペースでcmdだけで一撃でやりたかったのですが、for関連の変数処理が理解できず。
gyazo.com
これをスプレッドシートにコピペして
gyazo.com
こんな感じでゴリッてつくりました。
gyazo.com
ずらーっとね。
最後
とりあえずうごきました。業務の方にももっていけるかもしれない。すでに使われているような可能性も・・・
が、なかなかCoolだと思います。使用感はマニュアルみてみないとですが。
AWS AppFlowをつかってSlackからS3への連携を試してみる。
目標
AppFlowとか言う楽しげなサービスが発表されました。(
Amazon AppFlow は、Salesforce、Marketo、Slack、および ServiceNow などの Software-as-a-Service (SaaS) アプリケーションと、Amazon S3 や Amazon Redshift などの AWS サービスとの間で、たった数回のクリックでデータを安全に転送できるフルマネージド統合サービスです。
[公式より引用-
https://aws.amazon.com/jp/about-aws/whats-new/2020/04/introducing-amazon-appflow/
- ]
いままで、このあたりの連携はAPI GatewayやらLambdaやらでピタゴラしていたのではないでしょうか（やったことないんだけど）
送信元、送信先を指定してサクサクっと連携できます。早速やってみました。
今回はSlack->S3への連携を試してみます。
※Saleceforceから繋いで見たかったのですが、どうにもsalaceforce側からデータが来ず・・・slackでやってみました。
AWS側の操作はコンソールを使用してセットアップしました。
大きく３ステップで完了です。
・送信元（Slack）の準備
・S3の準備
・AppFlowのセットアップ
です。
送信元（Slack)を準備する
・連携用のSlackアプリを準備する。
・準備したSlackアプリをワークスペースにインストールする。
の２ステップが必要になります。
連携用のSlackアプリを準備する。
slack側の操作になりますが。
gyazo.com
右上のビルドを選択
gyazo.com
Your AppsからCreateを選択。
gyazo.com
連携したいワークスペースを選んで作成
gyazo.com
まずはCredentialsから情報を保存控えておきます。
必要な情報は
・Client IDとClient Secretの二つです。
gyazo.com
OAuth＆Permissionを選択して、権限周りの設定をします。
gyazo.com
Add AuthScopeで、必要なスコープを放り込みます。
AWS Documentsより、必要なScopeは以下
channels:history
channels:read
groups:history
groups:read
im:history
im:read
mpim:history
mpim:read
gyazo.com
Redirect URLを設定します。こちらもドキュメントの同じ場所に書かれている
https://console.aws.amazon.com/appflow/oauth
をセットします。
※ us-east-1 リージョンに固定されるので、別リージョンを使用する場合は
https://region.console.aws.amazon.com/appflow/oauth
でregionのところを任意のリージョンに差し替えてみてください。us-west-1につなぐ場合は https://us-west-1.console.aws.amazon.com/appflow/oauth となります。
gyazo.com
S3の準備。
APPFlowからアクセスされるため、任意のS3バケットを用意してください。AppFlowを作成するリージョンと一致させる必要があります。
AppFlowのセットアップ
前準備は整っているので、ウィザードに従う形で進めれば大体OKです！
作成を開始します。
gyazo.com
フローの基本情報を設定します。デフォルトで暗号化は行われていますので特に設定も必要がないと思います。
gyazo.com
送信元を選びます。コンボボックスからSlackを選択して、接続ボタンを押すことで接続情報の入力画面が表示されます。
準備しておいたSlackの情報をつかって、うめていきます。
gyazo.com
リダイレクトURLの設定をさぼっていると、以下のようなエラーがでます。リージョンの設定が適切かどうかなど、確認してみてください。
gyazo.com
成功すると以下のような許可画面にうつります。確認して進めてください。
gyazo.com
オブジェクト、チャンネルを設定すると以下のような形になります。
gyazo.com
送信先のS3を設定します。
gyazo.com
フローの実行タイミングについては
開始日、終了日、実行のタイミングを指定することもできますが、
今回はデフォルトのオンデマンドですすめます。
gyazo.com
あとはマッピングは任意の項目を。フィルターも必要であれば設定してそのまま進めると完成です。
試しに実行してみると以下のようにAppFlowの名前でフォルダが切られ、なかにJson形式で出力されていました。
gyazo.com
gyazo.com
いい感じですね。送信元のサービスの設定にてこずってしまいましたが、AWS側の設定ほんの１、2分でいけました。素晴らしい。
今のところSlack To Slackとか、S3 To Slack のように、送信先にSlackは選べませんでしたが、送信元は結構な数のサービスがサポートされていました。
気になるサービスがあればつかってみるのもよいのでは。以上です。
・Amazon S3
・Amazon Redshift
・Amplitude
・Datadog
・Dynatrace
・Google Analytics
・Infor Nexus
・Marketo
・Salesforce
・ServiceNow
・Singular
・Slack
・Snowflake
・Trend Micro
・Veeva
・Zendesk
