# #4 Weekly Tech Talk

### **発言は自由です！割り込み発言大歓迎です！一緒に議論しましょーーー**

## 顔合わせ

- 中村拓実
- 今のEngine代表（仮）
- デーサイ4年 戸田ゼミ (LLM + 検索クエリ)
- フリーランスでwebエンジニアしてるよ
- 最近はここ https://lifeprompt.net/
- 誰繋がりか気になった
- ↑Offersだよーー 気合いで入った
- GitHub: https://github.com/nyatinte
- 「にゃちんて」

- YutaUra(浦 優太)
- 社会人二年目
- スタサプの開発をしています
- 主に Web frontend の開発を行っています。
- 昔 Engine をたちあげました
- ボスだ！！
- JavaScriptが得意です

- 平山さん
- デーサイ1年
- 元社会人
- 学びにきた！
- 会計士
- えぐい!
- 最近の趣味はAtcoder
- 元文系（経済学部）
- 会計データ分析や不正検知などに興味
-

- 岡田拓也
- デーサイ 大学4年生
- 研究：LLM × 行動変容
- データサイエンス倶楽部 元代表
- 主に Flutter エンジニアとして仕事してます
- あとは色々インターンしてる
- 松丸さん先日DMさせていただいた岡田です！よろしくお願いします

- 松丸豪志
-　デーサイ2年から休学してます。2020年に入学しました
-　マツダで働いていて大学に入学しました
-　🚗 :car:
-　ベテランだ
-　NewsPicksのAndroidアプリ開発しています（7月からiOS開発やります
- 聞いたことある
- モバイルごりごり
　　(T.hirayama) 前職はDSやIT関連の業務だったのですか？

- 長野悠歩
- データサイエンス学部2年
- Python メインで使ってますが、Web開発もしたことあります
- フロント: Next.js (TypeSctipt)
- (takumi) Next.js v15の気配
- バック: Django (Python)
- Django いいよね
- 最近は機械学習と競プロメインで勉強してます
- (T.hirayama)競プロの師匠と崇めたいです

- 佐藤慶太
- ↑Q. なんて呼ばれることが多い？
- さとけい
- DS学部 3年
- Web系の開発をしてます！
- 最近作ったもの:
- https://timetable.opstid.com/
- GitHub: https://github.com/OPSTID
- ↑すごいな (takumi)
- すごい！！
- 正直、データサイエンスはよくわかんないです💦
- Vue.js はだいたいできます！React 勉強中です！
- 部活: アカペラ、ピアノ（部長してます！）

時間割...?不穏な空気が流れる....
↑学務とばちばちだ

BBQ誘われてないよ

## テーマ

中村拓実
- LTで賞もらったよ
- 外部のコミュニティに参加するのも面白いよ
- 同学の人とはジャンルが違う
- 知見の交換
- 初心者の人もいる、全員誰でもwelcomeな雰囲気
- yutaura)
- いい話だ！
- どんな話したのか気になる
- https://speakerdeck.com/nyatinte/llmwoxing-an-quan-nishi-utips
- 何か景品とかもらったりした？
- Tシャツもらったらしい
- https://ycu-engine.slack.com/files/U03J2N8UFGC/F074HP1CJ2Z/img_1584.jpeg
- T.hirayama
- LTってなんですか？
- Lightning Talk の略
- 5~15分くらいでちょっとした話をするようなやつ！

- LTをやることのメリット
- 自分の学習
- 自信を持てる
- ポートフォリオの充実

長野くん
- nbdev
- https://nbdev.fast.ai/ を使ってみた
- jupyter notebookをgit管理しやすくする
- .ipynb → .py
- jupyterはjsonだし、、
- 実行順の違いも差分になる
- 似てるかも https://typedoc.org/

拓也
- 型安全なエラーハンドリングについて
- めっちゃ準備してるじゃん ← それな（takumi）
- try-catchのハンドリング辛いよね
- catch忘れ
- 呼び出し側からはthroableかどうかわからない

例外を1つに集約したときってエラーをmatchしてハンドリングできるの？

Sealed Class, Enum Class

松丸さん）ApiClientExceptionとかは作ってなくて、Exceptionをそのまま返したりしてた
岡田）Error Responseとか受け取る時とかも型あると楽でないか
松丸さん）型自体はあった方がいいとは思う。
松丸さん）catch 逃すかもが課題だったから Exception でキャッチしておけば拾えはする。
松丸さん）Exceptionでキャッチしてから型チェックして処理するとか。

うらさん）極論全部のenum要素に対して処理するのを強制しないと、処理する側で知らなかったとか発生する。この問題はどこまでやるのかむずい。エラーを返すということは処理して欲しい。アプリが投げるエラーとライブラリが投げるエラーは違う。例えば、認証エラーなら

これだけ作ってもクライアント側では捌ききれない、アプリケーションならここまではいらない。このエラーはどういう処理をして欲しいのかをエラーに込める。例えば、認証エラーって返してもいいけど、再度認証してくださいっていうエラーにするとか。そういうのがないならただのエラーにする。特にできることないなら分ける必要はない。そうすると数が減ってくる

→ そうすると網羅生の静的検査が重要になる

- 言語的に相性悪い可能性はある
- Rustみたいに言語として対応してるものもある
- JavaScriptはlintで強制できる

観点

* エラーってそもそもなんだっけ
* 網羅性

たくみ）エラーだし分ける理由はフロントに出し分けるため。ネットワークの通信が悪いとか、内部でなんかあっても、再リロードしてとかしかお願いできない。ユーザーが対処できるエラーは少ないんじゃないかな？

エラー分けるメリット

- 監視系のツールを仕込むとき（ロギング）　岡田）たしかに

---

# わからないことリスト
- リント？ってなんですか？
-