Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
新着ニュースを毎朝メール通知する仕組みを作ってみた
Search
ryu-ki
April 21, 2025
2
380
新着ニュースを毎朝メール通知する仕組みを作ってみた
ryu-ki
April 21, 2025
Tweet
Share
More Decks by ryu-ki
See All by ryu-ki
Amazon Nova モデルの比較してみる
ryuki0947
0
55
Strands Agents の基本を学ぶ~AWS調査エージェントを添えて~
ryuki0947
3
170
Amazon S3 Vectors とハイブリット検索を実現してみる
ryuki0947
12
2.3k
Strands AgentsでAWS調査エージェントをサクッと構築してみた
ryuki0947
1
150
AWSとゼロから始めるデジタル名刺生活~CI/CD GitHub Actions編~
ryuki0947
1
140
AWSでなにか作ってみませんか?
ryuki0947
2
620
AWSとゼロから始めるデジタル名刺生活~S3+CloudFront 編~
ryuki0947
2
280
宇宙最速!?Kiroについて簡単に紹介
ryuki0947
2
140
ローカルLLMを用いた簡単なLLMアプリを作ってみた / Building a Simple LLM App with Local LLM
ryuki0947
0
78
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
How GitHub (no longer) Works
holman
315
140k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Building Adaptive Systems
keathley
43
2.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Optimizing for Happiness
mojombo
379
70k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
What's in a price? How to price your products and services
michaelherold
246
12k
Code Reviewing Like a Champion
maltzj
525
40k
Transcript
新着ニュースを毎朝メール通知する 仕組みを作ってみた 2025/04/22(火) JAWS-UG初心者支部#64 ハンズオン<勉強会!
自己紹介 ┃所属:TIS株式会社 ‐ 年次:2年目(24卒) ‐ 担当業務:社内サービス(AWS/Terraform/React) ┃趣味:国内旅行・競馬 ┃片思いのAWSサービス:Amazon Bedrock 2
井町 瑠貴 (umitsu) 昨年末からQiitaへの記事投稿を 始めました!(AWS・生成AIなど) クォータ制限を引き上げてもらえません!
はじめに ┃本日お話しすること ‐ 構築した仕組みの概要 ‐ 構築する上で実現できなかったこと・気づき ┃お話ししないこと ‐ 構築した仕組みの詳細な構築方法 3
システム構築の背景 ┃日々技術が進歩し、新しい技術・ツールなどに 関する情報が次々と登場 ┃このような情報を日常的にキャッチアップしたい ‐ が、自分で取りに行くのは少し大変… 4
システム構築の背景 ┃日々技術が進歩し、新しい技術・ツールなどに 関する情報が次々と登場 ┃このような情報を日常的にキャッチアップしたい ‐ が、自分で取りに行くのは少し大変… 5 情報を取りに行ってくれる仕組みを作ろう!
当初の構成 6
当初の構成 7
実現した構成 8
実現できなかったこと ┃ウェブスクレイピングの壁(記事本文の取得) ‐ いろいろ試したものの、なぜか取得結果が空の状態 ┃Bedrockのクォータ制限(記事レコメンド) ‐ 制限緩和の問い合わせをしたものの、すくなくとも 今は緩和することができないとの返事 ┃マルチソース対応の複雑さ ‐
サイトによってRSSの形式が異なるため、ソースを Qiitaに限定 9
実現できなかったこと ┃ウェブスクレイピングの壁(記事本文の取得) ‐ とりあえず、タイトルが分かれば概要はつかめそう ┃Bedrockのクォータ制限(記事レコメンド) ‐ 制限緩和の問い合わせをしたものの、すくなくとも 今は緩和することができないとの返事 ┃マルチソース対応の複雑さ ‐
サイトによってRSSの形式が異なるため、ソースを Qiitaに限定 10
実現できなかったこと ┃ウェブスクレイピングの壁(記事本文の取得) ‐ とりあえず、タイトルが分かれば概要はつかめそう ┃Bedrockのクォータ制限(記事レコメンド) ‐ いったん世間で注目されている情報が分かればよい ┃マルチソース対応の複雑さ ‐ サイトによってRSSの形式が異なるため、ソースを
Qiitaに限定 11
実現できなかったこと ┃ウェブスクレイピングの壁(記事本文の取得) ‐ とりあえず、タイトルが分かれば概要はつかめそう ┃Bedrockのクォータ制限(記事レコメンド) ‐ いったん世間で注目されている情報が分かればよい ┃マルチソース対応の複雑さ ‐ Qiitaを見れば、ひとまずはいろいろな情報を得られそう
12
実現できなかったこと ┃ウェブスクレイピングの壁(記事本文の取得) ‐ とりあえず、タイトルが分かれば概要はつかめそう ┃Bedrockのクォータ制限(記事レコメンド) ‐ いったん世間で注目されている情報が分かればよい ┃マルチソース対応の複雑さ ‐ Qiitaを見れば、ひとまずはいろいろな情報を得られそう
13 実現できていないけどひとまずOK!
現状通知される情報 14
気づき 15 ┃MVPの重要性 ‐ 目的を達成するための最小限の機能で動くものを作り、 段階的に機能追加する方が現実的 ┃事前調査の重要性 ‐ クォータ制限などは事前に把握しておくことが望ましい ┃シンプルな設計の価値
‐ 結果的に、シンプルなシステムでも、ある程度目的を 達成することができることを実感
まとめ 16 ┃最新情報キャッチアップのために、ニュース情報 通知システムを構築 ┃その際、技術的な要因により実現できない機能もあった ┃そこに悩みすぎず、まずは動くものをつくってみる ことが大事だと感じた