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
bayashi
April 13, 2023
Programming
0
310
商用アプリケーション開発基本のキ
社内の勉強会で発表した雑な資料です。
bayashi
April 13, 2023
Tweet
Share
More Decks by bayashi
See All by bayashi
複雑さを受け入れるか、拒むか? - 事業成長とともに育ったモノリスを前に私が考えたこと #RSGT2026
murabayashi
1
3.3k
エンジニアに事業やプロダクトを理解してもらうためにやってること
murabayashi
0
380
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
500
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
550
個人事業主型開発からの脱却
murabayashi
14
10k
スクラムフェスを支える配信の仕組み
murabayashi
1
1.2k
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.5k
(新米)エンジニアリングマネージャーのしごと #RSGT2023
murabayashi
11
11k
Active Recordについてわかったことを説明するよ
murabayashi
0
500
Other Decks in Programming
See All in Programming
コーディングルールの鮮度を保ちたい / keep-fresh-go-internal-conventions
handlename
0
220
条件判定に名前、つけてますか? #phperkaigi #c
77web
1
330
Codexに役割を持たせる 他のAIエージェントと組み合わせる実務Tips
o8n
4
1.4k
仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介
orgachem
PRO
6
2.3k
「やめとこ」がなくなった — 1月にZennを始めて22本書いた AI共創開発のリアル
atani14
0
400
AI時代のシステム設計:ドメインモデルで変更しやすさを守る設計戦略
masuda220
PRO
6
1.1k
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
440
20260315 AWSなんもわからん🥲
chiilog
2
160
Takumiから考えるSecurity_Maturity_Model.pdf
gessy0129
1
150
AHC061解説
shun_pi
0
400
メタプログラミングで実現する「コードを仕様にする」仕組み/nikkei-tech-talk43
nikkei_engineer_recruiting
0
200
Symfony + NelmioApiDocBundle を使った スキーマ駆動開発 / Schema Driven Development with NelmioApiDocBundle
okashoi
0
170
Featured
See All Featured
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
From π to Pie charts
rasagy
0
150
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.5k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Accessibility Awareness
sabderemane
0
82
Rails Girls Zürich Keynote
gr2m
96
14k
Mind Mapping
helmedeiros
PRO
1
120
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.6k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.1k
AI: The stuff that nobody shows you
jnunemaker
PRO
3
450
Transcript
商用アプリケーション開発 基本のキ
アプリケーション アプリケーション
アプリケーション アプリケーション みんなとデータ共有したい ...
クライアントとサーバ 通信 クライアント サーバ クライアント クライアント クライアントアプリケーション サーバアプリケーション 専用線 イントラネット
クライアントとサーバ 通信 クライアント サーバ クライアント クライアント クライアントアプリケーション サーバアプリケーション クライアントアプリケーション作るの大変 ...
みんなに配るの大変 ... 専用線 イントラネット
Webシステム(うちだとこんな感じ) 通信 AWS上の EC2とかECS ブラウザ クライアント サーバ インターネット
Webシステム
クライアントでは何でもできる 変なリクエスト送っちゃおー 生年月日0000年00 月00日ですね! はい、言われた通り 動きます!
役割の違い クライアント側の バリデーション(制御)は ユーザの補助のための機能 サーバ側の バリデーション(制御)のみが不正 なデータやリクエストを防ぐことが できる
他にも
ネットワーク通信 ネットワーク通信は色んなところで失敗する 通信障害!!! PCが落ちた!! サーバが壊れた!!
上手く動かない時のことを考える ネットワーク通信は基本的に失敗する可能性がある また他のサービスを使う場合、 失敗する可能性が結構高い確率である (メンテ時間とか)
処理が失敗したときにどう振る舞うか? 考えてみよう slackに投稿してみよう
処理が失敗したときにどう振る舞うか? - リトライ処理をする - 人間に通知をして直してもらう - ログを吐く - 勝手に直るようにする -
何もせず処理を終了する あたりが出た? どれが正解?
処理が失敗したときにどう振る舞うか? - 何もせず処理を終了する - リトライ処理をする - 人間に通知をして直してもらう あたりが出た? どれが正解? 場合による!!
処理を成功させるためにどうすればいいか 確率で失敗する(Flakey)ならリトライ処理をすれば良い 人間が対応する必要があれば通知をする 自動で回復できるなら自動で回復する できることが何もないけど把握しておきたいならログを吐く できることが何もなく把握する必要もないなら何もせず終了する 次の行動を考えて失敗時の処理を考えよう
失敗した時のことについて考える概念(一部) フェイルセーフ フェイルソフト
フェイルセーフ 故障しても大変なことにならないようにしようね → 倒れると止まるストーブ → 踏切の遮断機(故障時は重力で下がる=踏切に立ち入れないようにする)
フェイルセーフじゃない例 調光フィルムを貼ったガラス張りで、利用者がいな いときはフィルムに電気を流すことでガラスが透明 となり、トイレ内に入り鍵を閉めることで電気が流れ なくなりガラスが不透明になる仕組みとなっている。 https://encount.press/archives/394259/
フェイルソフト 故障しても(多少しょぼくなっても)動くようにしようね → エンジンが壊れたら予備エンジンが動く飛行機
テストでも テストの観点にも失敗した時のことを考えよう 正常系 準正常系 異常系
仕様 本を借りるシステム 一回に5冊まで借りれる 借りる際にはアカウント登録が必要 一日1回のみ借りれる
正常系 1冊借りたら借りれる 5冊借りたら借りれる
準正常系 0冊借りたら失敗する。ユーザに借りれない旨をメッセージで伝える 6冊借りたら失敗する。ユーザに1回5冊しか借りれないことをメッセージで伝える 会員じゃなかったら失敗する。 余談: 失敗時のエラーメッセージはユーザの次の行動につながるようにしようね
異常系 アプリケーションが動いているサーバがぶっ壊れたときに - DBへのアクセスができなくなること - 他のサーバが自動的に復旧してくれること - 500画面が正常に表示されること
前職で聞いた格言 正常系が動くようになって、ようやく2割