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
Masatoshi Itoh
April 15, 2023
Programming
0
460
コードを書いたら負けなのか?
北海道LT大会で話した資料です
Masatoshi Itoh
April 15, 2023
Tweet
Share
More Decks by Masatoshi Itoh
See All by Masatoshi Itoh
Hello - 本を書く- World !!
masatoshiitoh
0
83
TPI NEXTを読みました
masatoshiitoh
0
200
非同期ツールキット「Vert.x」のご紹介
masatoshiitoh
0
360
サーバーサイド開発にありがたい GitHub Copilot / ChatGPT
masatoshiitoh
1
1k
1999年 最新バックアップ事情
masatoshiitoh
0
210
Google I/O 報告 (Google Assistant)
masatoshiitoh
0
490
GDC報告会資料 海外に見る「生産性改善」動向
masatoshiitoh
0
1.3k
イケメンシリーズでのORMとスロークエリ対策について
masatoshiitoh
0
2.7k
Erlangご紹介 websocket編
masatoshiitoh
0
2.9k
Other Decks in Programming
See All in Programming
Ruby Parser progress report 2025
yui_knk
1
440
プロパティベーステストによるUIテスト: LLMによるプロパティ定義生成でエッジケースを捉える
tetta_pdnt
0
330
テストカバレッジ100%を10年続けて得られた学びと品質
mottyzzz
2
600
アセットのコンパイルについて
ojun9
0
130
はじめてのMaterial3 Expressive
ym223
2
440
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
4
1.4k
Ruby×iOSアプリ開発 ~共に歩んだエコシステムの物語~
temoki
0
320
250830 IaCの選定~AWS SAMのLambdaをECSに乗り換えたときの備忘録~
east_takumi
0
390
ぬるぬる動かせ! Riveでアニメーション実装🐾
kno3a87
1
220
複雑なフォームに立ち向かう Next.js の技術選定
macchiitaka
2
120
Putting The Genie in the Bottle - A Crash Course on running LLMs on Android
iurysza
0
140
Compose Multiplatform × AI で作る、次世代アプリ開発支援ツールの設計と実装
thagikura
0
160
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Bash Introduction
62gerente
615
210k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
KATA
mclloyd
32
14k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Optimizing for Happiness
mojombo
379
70k
Facilitating Awesome Meetings
lara
55
6.5k
Visualization
eitanlees
148
16k
Raft: Consensus for Rubyists
vanstee
140
7.1k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Transcript
コードを書いたら負け なのか? 2023/4/15 北海道LT大会 いとうまさとし Twitter : masatoshiitoh
コードを書いたら負け なのか? • コードを書かなきゃバグは増えない、というのは理解しつつも、 このポリシーもそれはそれでツライよねという話をします • ちなみに最後まで進んでもオチはないです • この発表では、「コードを書いたら負け」は、既存の枯れた OSSフレームワークや外部サービスをうまく使って、できる限
り核心になるロジックだけに集中したいですよね、という意図 で使っています
今日のもくもく • Vert.xのEventBusのコーデックをいろいろ試してました
自己紹介(一瞬) • いとうまさとし(Twitter: masatoshiitoh) • 株式会社セガ札幌スタジオ • セガサミーグループ歴10か月 • 今回のLTはセガサミーグループの技術スタックや開発・運営中
のタイトルとは全く関係ありません(為念 • 過去作品 • Speed.rbbtoday.com(IRI-CT、現イード在籍当時に開発) • 最近のGist • Camel から Camel Vert.x component 経由でVert.xクラスタのイベントバスを読み書きする • とにかくApache Camelを動かしてみるための最初の手順
何か作るときに必要な機能は多様 • 「コードを書いたら負け」で立ち向かうとしたら、さまざまな OSSフレームワークやOSSライブラリ、SaaSの連携をするこ とになるわけですが、、、 • フロント(アプリ、Web) • APIサーバー •
キャッシュ • 認証・認可 • バッチ処理(集計とか) • 管理画面 • CSVとかによる一括設定 • 外部システム連携
連携対象の「お作法」が全部違う • みんなちがって、みんないい
連携対象の「お作法」が全部違う • みんなちがって、みんないい ・・んなわけない
連携対象の「お作法」が全部違う • みんなちがって、みんないい ・・んなわけない それぞれに合った使い方をしないと、そもそも作れない、まとも に動かせない
連携対象の「お作法」が全部違う • SaaSはまだいい。WebAPI等、使い方が固まっている
連携対象の「お作法」が全部違う • SaaSはまだいい。WebAPI等、使い方が固まっている • ライブラリはドキュメントが不足していたり、更新も数年止 まってたりしがちだけど、だいたいの場合、動くなら問題なし。 そのバージョンで固定してしまえばいい…あとで困りがちです が。
連携対象の「お作法」が全部違う • SaaSはまだいい。WebAPI等、使い方が固まっている • ライブラリはドキュメントが不足していたり、更新も数年止 まってたりしがちだけど、だいたいの場合、動くなら問題なし。 そのバージョンで固定してしまえばいい…あとで困りがちです が。 • フレームワーク類は、それぞれに合った使い方、書き方、動か
し方を把握するだけでもハードルが高い
連携対象の「お作法」が全部違う • フレームワーク!
SpringBoot • Javaでウェブサービス作るときの定番(たぶん) • アノテーションの嵐だが、コーディングしやすさ感は高い • Initializrサイトで始めやすい • 書籍やウェブサイト上の情報が多くて人気 •
バッチ処理機能とかも持っている。何でも作れそう感に満ちて る
Jakarta EE (Eclipse foundation) • (このへんからオーバーキル) • 何か大きめのアプリケーション作るときの定番(たぶん) • 昔のJava
EE • 今から飛び込むには壁が高い(昔から飛び込みにくい • コンテナって何?アプリケーションサーバーって何? • DBアクセスするWebアプリを書いて動かしてみよう、ってい うだけでも大仕事になりがち。設定をアプリケーションサー バー側に寄せられるので、コードには処理だけ書けばいい、と いう構成になっているが、初学者には準備多すぎてツラい
Eclipse Vert.x • Java用の非同期フレームワーク • Quarkusの非同期処理のベースとしても採用されるなど、実績強い • Starterサイトがあって始めやすい • 何でもコールバック
• Vert.xでは自分のコードでIO待ち等のブロッキング処理を書くのは基本厳禁 • ブロッキング処理が必要なのでWorker Threadを自前で作って管理する、というの は負けパターン • Vert.xが提供する非同期クライアントライブラリ(DB/Redis/HTTP)の使いこなしが 正道 • DB、Redis、設定読み込み、、、何をするにもコールバック • 随所でコールバックヘルが爆誕
Apache Camel • Enterprise Service Busのオープンソース実装 • よさそうなんだけど情報少ない、調査つらい • とはいえさすがに標準で含まれているコンポーネントは「動作する」
• 動かない時は「使い方」「呼び方」が間違ってる • 接続や変換はDSLスタイルで定義。よい。 • from~~to~~でデータの流れを表現 • 多様なコンポーネント • 各コンポーネントについての情報量の差が大きい • たとえば、ActiveMQは割と充実しているっぽい • 一方、Vert.xコンポーネントはかなり少ない
Apache Kafka • ストリーム基盤 • PubSubとかメッセージルーティングとかが強い • 永続化とかもしてくれる • 開発用にちょっと触るだけなら、Bitnamiのdocker
compose 定義を使うのが一番簡単。PC1台で動くし。 • プロダクション運用に載せるのがすごとい大変そうに見える • 小規模で動かしてる分には、それほどでもないのかな、、、? • ChatworkのCQRS+ESの基盤に使われていると聞いて、「す ごそうだなー 便利そうだなー」レベルの理解でしかありませ ん、ちゃんと使ったことないです
つなぐ方法も悩ましい • Kafka、MQ、ESB、HULFT、gRPC、Web API • ファイル渡し、DB渡し、Redis渡し • FTP、S3 • あとからどうとでもなる部分(毎週月曜朝にDBからCSV作っ
て実績レポートにするとか)を考慮外にしても、割と大変 • 考慮外にした部分が牙をむいてくることも、たまに、、、
他にもいろいろ悩ましい • XMLとJSONとCSVと、、、 • 同期、非同期 • 1 to 1、PubSub •
at lease once / at most once / exactly once • タイマー起動、イベント起動 • 定期的なデータ削除 • サーキットブレーカー、メンテナンスモード • メンテ時、ウェブサイトは止めていいけどAPIサーバーは止めちゃダメ、み たいな案件もありました。どっちも同じサーバーで動いてるんだけど、的な • インフラレベルで考慮してないとどうにもならない
可用性上げる方法が悩ましい • スケールアウトさせる場合も、結局どこかがパフォーマンス上 の律速段階になりがち(多くの場合はDBかネットワーク帯域 ですよね?) • ネットワークって信用しきれないですよね • リカバリは? •
そのバッチ、リランして問題起きない? • 障害検知は? • ログは?
どうせ負けるなら、いっそモノリスに… • ツールの調査をする時間で作れるなら、作った方がいい? • データの流れはコードの流れで表現できるよね • 同一プロセス内ならデータの受け渡し速度がネットワーク経由の比 じゃない • フォーマット変換は「外との界面」でだけ発生させれば、、、
• リカバリはそれでも問題になりがち • そもそもモノリスだと影響範囲確認が大変になりがち • 金融系でおこなわれているという「コピペしてきて不具合箇所を修正 (その修正されたコードはその処理フローでしか使われないことを担 保)」という方法が魅力的に見えてくる • 修正新規とか、コピー新規とか言われるらしいですね
「する」と「なる」は違う(余談) • 何も考えずに外注すると、モノリス(というか泥団子)になり がちじゃないですか? • 外注業者がどこかの案件で作ったと思われるコードをベースに 作られた「何か」が納品されてきて、運用や改修で苦しんだり してませんか? • これは「モノリスにする」を選んだことにはならないよ?
• 余談なのでオチはありませんよ?
みなさん今ってどう設計してますか? • 今だとAmazon AWSのアイコンを並べてフローを検討して、 それを念頭にいい感じに開発すれば、だいたい動く?? • API GatewayとLambda、SQS、DynamoDB、S3あたりで 組めれば、だいたい問題ない気もするんですよね •
クラウド系のサービスは「単体でドキュメントどおりに動く」 ことがほぼ確実で、環境構築がポチポチで済むのはありがたい • (これもオチはありません)
We are hiring • ここまでの話は所属会社とは関係ありません • 過去に携わったシステムの経験をもとに「どうやったらよかっ たのか」「ほんとに書いたら負けなのか?」を振り返る感じ • いろいろ書きましたが自分自身は「書いたら負け」派です。自
分がこれから書くプログラムが、長年生き延びてるコードより 安定してるとか思えませんので • あと、セガ札幌スタジオはWe are Hiringしてます
We are hiring(大事なことなので再掲) •We are Hiring •セガ札幌スタジオ 中途採用、で検索!