Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[第3回] Webサービス開発講座

notch_man
August 23, 2023

[第3回] Webサービス開発講座

2023年度の筑波大学enPiTで使用した資料です。全4回+αでWeb開発の基礎を学ぶことが出来ます。

※notion資料は近日公開予定です。

notch_man

August 23, 2023
Tweet

More Decks by notch_man

Other Decks in Education

Transcript

  1. 5 ⾃⼰紹介 クラウドソーシングサービスなどを 開発しています notch_man twitter: @notch_man8600 • 認定スクラムマスター(CSM) •

    ラボのシステム開発の全責任を負う(⾟い) • 学類パンフに載ったけど留年したよ(笑) • 現場で都合良く使われています [概要] • 2020年3⽉ ⾹川⾼専卒業 • 2021年4⽉ 筑波⼤編⼊ • enPiT2021(受講)&2022〜(メンター) [略歴]
  2. 6 この講座のゴールについて 1. シンプルなWebアプリを作れるようになる 2. Webアプリケーションを作る上でのお作法を学ぶ 3. 汎⽤的なスキルとノウハウを知る 4. オレオレFWを作りたくなる気持ちになる

    5. オレオレFWを安易に使うと⽕傷をすることを知る 6. 巷のFWが何故受け⼊れられたのか考えられるようになる 7. おまけ話を聞いて世間を知る ⽬標段階のレベルを定義しました。 これらいずれかを⽬指しましょう!
  3. 7 本⽇の⽬標:シンプルなWebアプリを作れるようになる • コピペしたらフロントとバックエンドが動くコードを作ります ◦ Pythonなので分かりやすい! ◦ クリーンなコードでGPL3だから使いやすい! • それを写経したら何かが作れます

    • ちょっと弄ると⾃分らしさが出せます • 良い感じに弄られるようになると、⾊々なサービスが作れます ◦ ロジックとかで使い回せるようになると⾮常に楽になります
  4. 24 Pythonの可愛らしい点 • ゆるふわな辞書型 ◦ あらゆるデータ構造を扱える • interfaceが無いのが⾟い ◦ 旅をしてしまうクラス

    • そもそも実⾏速度が遅い • 型を安⼼して書けないので⾟い • 静的解析ツールもオレオレしており⾮常に苦しい(あと重い) • ライブラリがブロークンに変わる
  5. 25 可愛らしいdictの例 request = { "data": 1, "user_id": "example-user-id", "password":

    "password", "method": "add", } router = { "/add": lambda a, b: a + b, "/sub": lambda a, b: a - b, } if "method" in request: print(router[request["method"]](request["data"], 2)) try: print(request["1"]) # もしパスワードカラムみたいなものがあったら削除しよう request.pop("password") except Exception as e: pass print(request["user_id"]) ex.) 辞書を使ったルーターの様な物体
  6. 26 可愛らしいdictの例 • key-valueの型が揺れる ◦ 静的解析で追跡しにくい ◦ ⾃由に値を書き換える • 気軽に抽象クラスでエラーを掴んでしまう

    ◦ エラータイプが分からん ◦ passの恐ろしさ • 無い物が⽣まれたり、あるものが無くなったり • ありとあらゆることが⾃由にできる
  7. 27 私がPythonをサービス開発で使いたくない理由 • 静的解析が効きづらい ◦ 後任が苦しむ ◦ バグの温床になる(静的解析はテストの1⼿法) • エラーハンドリングが弱い

    ◦ エラーに型があるため、基底クラスで掴みがち ◦ ゆるふわにpassをするサンプルが多いため死んでしまう • パフォーマンスが遅い ◦ FastAPIとかを使うとある程度は解決できるが... • FWがブロークンに変わる(まあ⾔語も...)
  8. 29 サービス開発の⼿段として抑えて欲しい点 • とりあえず、3年は⽣かしてくれ ◦ 3年は⼤幅には壊れない技術選定 ◦ メンテナンスし続けられる技術選定 ◦ ブロークンに変わる可能性の低い技術選定

    • コードの中と外に頼れるものであるか? • コードの中に頼れるか ◦ コメントアウト、型宣⾔‧型ヒント、docstring • コードの外に頼れるか ◦ テスト、静的解析、フォーマッタ...
  9. 39 本⽇のまとめ • Pythonでサービスを作るのは⾟い ◦ ⾃由が故に⾃由に翻弄され、責任は誰も負わない • サービス開発をする上で⼼得て欲しい点 ◦ 90%の⼈が分かる技術選定である

    ◦ 直し⽅が現実的で傷跡が分かりやすいものである ◦ テストや静的解析など外から傷をフォローできる • 3年は⽣きるコードを書いてくれ!