LT

LTネタ

〈Vox Populi,Vox Dei〉「民の声は神の声」

 

アンケートシステム

  • 多重投稿を防止する
  • 課金リミットをつける
  • DBの操作範囲を意識した設計
  • ケースバイ、ケースによってセキュリティの要件は緩める
    ・どこまで許すか
    ・最悪のケースはどうなるのか

背景

  • インフラエンジニア、セキュリティエンジニア、SIerが多いかと思うので、
    Web系のアプリケーション開発にまつわるネタが面白いかなと。独学で開発系の知識は勉強になるけど、リアル感とか実際はどうなの?って隔たりがあると思う。実際に私がシステムガーディアンにいた時そうだった。
    独学はできるけど、リアリティがない。本当にそうなんだろうか?溢れる知的好奇心。
    自社サービス会社でチーム開発や運用を経験したい。
    今の知識があれば、システムガーディアンを辞めなくても良かったとは思うので、
    今の会社好きなんだけど、自社サービスの開発経験をしたいって考えてる人に、独学では得られない、リアルな知見を共有したい。
    アジャイルで振り返りができることが大事だよって言われるけど、リアルなイメージがつかない、などイメージとリアルの差ってある
  • セキュリティと開発の間には多くの重要な接点がある
  • アプリケーションサイドのセキュリティ
  • 本ではあまりない、アプリケーションエンジニアだったら普通だよなぁ的な、入門書、上級者向けの本の中間を埋めるナレッジを共有したい

 

実務でアプリケーション開発はしていないけど、独学はしてるからあれって何だろう。例えばクリーンアーキテクチャとか。

あまりディープになりすぎず、実務ベースの簡単めな話をしたいなと。

 

ネタ

  • Firebase(mbaaS)を利用したアプリとセキュリティ
    ・ケースバイケースによって

 

  • Clean Archetectureのあの謎の円について説明する
    ・SOLID原則
    ・DIによる依存性注入
    ・DBが変わる
    ・ライブラリの変更

    ・SQLに依存して良い
    ・基本パッケージには依存して良い

 

  • 分割統治によってプログラミングができない人、私の解決方法
    ・分割統治とは
    ・メモリが少ない人の分割統治
    ・計算が早いように見える人、実際は大したこといっていない説
    ・分割統治+時間をかけた方が優秀なことが多い

 

  • DIってなんだろう

 

  • 脳がバグるロールバック対応
    ・VSCodeのBook Markが有能
    ・GitHubのタグ重要

 

 

  • コードレビュー
    https://qiita.com/iganin/items/aee297eade84849cc9cd

 

  • AWSコスト最適化

 

  • 楽観ロック(一括編集機能)

 

  • JOINが遅い…。生成カラムでGO!

 

  • 自社サービスを好きでいつづけないと、自社サービスに居られない
    ・改善は自分の為でもある

 

  • 自社サービス開発エンジニアのタスク消化術
    ・日常ネタ
    ・実際のアジャイルってどんな感じよ
    ・振り返り
    ・改善デー
    ・タスク消化の辛み
    ・スケジュールの開発
    ・バグQA
    ・障害対応
    ・リリース
    ・改善デー

 

  • もう怖くないGit。GitHub, GitLabを利用したチーム開発

 

  • おもしろDB設計 | 親子、孫、ひ孫 …n孫のグループ、カテゴリー、タグといった設計
    ・なぜSQLは難しく感じるのか?
    ・JOINクイズ
    ・LEFT JOINするとどうなる?
    ・難解に見えるSQLを読み解くコツ
    ・実行順序
    ・塊を意識する
    ・DB設計は自由
    ・自由の弊害 | DBアンチパターン
    ・ナイーブツリー
    ・とりあえずジョイン
    ・結局、閉包テーブルで優勝
    https://github.com/yuukanehiro/AlgorithmsDataStructure/tree/main/Theorem/ClosureTable

 

  • どうやってバグ、インシデントを発生することなく開発すれば良いのか?テストコードドリブンな開発
    ・当たり前だけど、開発エンジニアもセキュリティはやる
    ・情報漏洩対策
    ・テストコードのすすめ
    ・既存コードに改修を加える場合 // テストコードがない処理の場合
    ・改修する前に既存処理の関数それぞれのテストコードを追加する
    ・改修を入れる
    → 改修後の結果の副作用があるか、ないか、あった場合に想定通りかをチェックする
    テストコードを書くことで、影響範囲や影響の有無、影響内容をチェックすることができる
    ・ホワイトボックステスト // 実装エンジニアはこっち
    ・ブラックボックステスト // QAエンジニアはこっち
    ・クリーンアーキテクチャによる分割統治
    ・QAチームとの連携
    ・バグ監視
    ・Autify
    ・Datadog

LEFT JOIN, INNER JOIN, GroupByをgateway(Repository), QueryBuilderに対して行う時にありがたみがわかる。

テストコードを書くならば、テストの為に関数が単一の責務になり、
読みやすく、コードレビューがしやすくなる。

読みやすいコードであれば、レビューが機能してセキュリティも高くなる。

 

  • レガシーな自社サービス開発環境にIaCを導入したら奇跡が起きた
    ・レビュー
    ・CI/CD
    ・脆弱性
    ・採用への良い影響

 

  • APIが遅い時にやること | パフォーマンスチューニング術
    ・APIの処理のリファクタリング
    ・N+1
    ・ぐるぐる加工
    ・DB設計の見直し
    ・INDEX
    ・EXPLAINを活用したリファクタリング
    飛び道具
    ・仕様変更
    チート
    ・DBスペックアップ

 

  • APIってなんだろう。RestAPI, GraphQLの違い
    ・それぞれの説明
    ・GraphQL良いぞ

 

 

Amazonおすすめ

iPad 9世代 2021年最新作

iPad 9世代出たから買い替え。安いぞ!🐱 初めてならiPad。Kindleを外で見るならiPad mini。ほとんどの人には通常のiPadをおすすめします><

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)