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
450
コードを書いたら負けなのか?
北海道LT大会で話した資料です
Masatoshi Itoh
April 15, 2023
Tweet
Share
More Decks by Masatoshi Itoh
See All by Masatoshi Itoh
Hello - 本を書く- World !!
masatoshiitoh
0
79
TPI NEXTを読みました
masatoshiitoh
0
170
非同期ツールキット「Vert.x」のご紹介
masatoshiitoh
0
330
サーバーサイド開発にありがたい GitHub Copilot / ChatGPT
masatoshiitoh
1
990
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.8k
Other Decks in Programming
See All in Programming
Goで作る、開発・CI環境
sin392
0
200
Hypervel - A Coroutine Framework for Laravel Artisans
albertcht
1
110
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
320
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
740
ISUCON研修おかわり会 講義スライド
arfes0e2b3c
1
390
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
3
410
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
59
16k
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
270
RailsGirls IZUMO スポンサーLT
16bitidol
0
160
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
230
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
740
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Thoughts on Productivity
jonyablonski
69
4.7k
A designer walks into a library…
pauljervisheath
207
24k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
A Modern Web Designer's Workflow
chriscoyier
694
190k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Automating Front-end Workflow
addyosmani
1370
200k
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 •セガ札幌スタジオ 中途採用、で検索!