ID:66471さん

# プロジェクト概要 ## 目的 社内で使うためのAPIの開発と保守運用 ## 使用した技術や開発環境 AWS・Terraform・BigQuery・Datadog・Docker・Python # やったこと - APIGWやLambdaなどを使ったサーバレスなAPIや、AWS ECSを使ったAPIの作成。 - 設計からLambdaのTerraformの開発、locustを使った性能テスト、運用保守までを担当。 # 苦労したこと - WAFの設定でIPを制限しなければいけない部分を全員許可にしたことがあり、世界中のいたるところからアクセスがあった時は本当に焦ったことがあります、、、。 その時は開発環境でしたので事なきを得ましたが、それ以降は本当に気を付けるようにしています。 - Terraformで複数リソースを作る際に最初はcountを使って実装をしていましたが、後々特定のリソースだけを削除しようとした際に意図していない部分が更新されてしまうことがありました。for_eachを使って実装をしていれば特定のリソースだけを削除しても大丈夫だったのですが、countを使っていたことが良くありませんでした。その時はmoved blockを使ってリファクタリングを進めましたが、以降はベストプラクティスをちゃんと確認してから進めています。 - locustの性能テストはリクエストを送って意図したレスポンスが返ってくることを確認するものでしたが、HTTPリクエスト時にchunkedを使ってリクエストする必要があり、ただヘッダーに指定するだけではうまく動作しませんでした。locustでchunkedを送る方法を調べても事例が出てこないので、自分で実装する必要がありました。そもそもchunkedについてよく知らなかったのでmozillaのHTTPリクエストのページを見て理解をして少しずつ試して、最終的にはchunkedを使ったHTTPリクエストを実装することができました。 - 性能テストをする際に、どのライブラリを使うか調査してくださいというタスクを振られました。 候補としてはJavaのKarateかPythonのlocustが挙げられていて、基準は自分で考えてくださいというタスクでしたので、gitのstar数やライブラリのdownload数、coverage reportは出力できるか、実際に書いた感じはどうかなど様々な基準で調査をした結果、locustに決めました。

# プロジェクト概要 ## 目的 顧客管理システムで使っているフレームワークが有償かつ古いものだったので、最近の技術にリニューアルをしようというプロジェクト。 基盤チームとして参加。 ## 使用した技術や開発環境 AWS・Terraform・BigQuery・Datadog・Docker・Python（FastAPI）、TypeScript（Vue3） # やったこと - プロジェクトを開始するための基盤の準備作業 　- フロントエンドのエラーハンドリングの仕方の実装とドキュメント化 　- redisとのインタフェースの実装 　- DBとの接続部分のサンプル作成 　等々、基盤として準備するべき作業。 - 開発環境の整備 - batchの開発 - フロントエンド、バックエンドのコーディング - AWS CodePipelineを使ったCI/CDの作成 - 論理データモデルの整備 # 苦労したこと ## batchの開発 【概要】 システムがAWS上で動いているので、lambdaで動くbatchを作成した。 【課題・問題点】 簡単なlambdaであれば1ファイルに書いて終わりだが、多くのテーブルにデータを登録更新する必要があり、1ファイルにすると複雑になりそうだった。 【打ち手・使用した技術】 Pythonで書いていたため、dataclassを使いmodelとしてまとめ、DBアクセス部分はserviceとしてまとめることで管理しやすいようにした。また、db connectionをlambdaの中で使いまわしたかった為、postgresクラスとしてシングルトンにすることで複数ファイルに分かれていても参照できるようにした。 ## 開発環境の整備 【課題・問題点】 - front開発にはvue3を使うことだけ決まっていたが、webpackを使っていたり、dockerを使っていた関係で初回ビルド時にとても遅かった。 【打ち手・使用した技術】 - vue3のドキュメントでおすすめされていたviteを使うことを検証し提案することで、buildのスピードなどが上がり開発スピードも上がった。 - 開発環境としてdockerを使っていたが初回ビルドだけとても時間がかかっていた。Windows for Desktopで実行をしていたため、バックエンドをWSL統合にすることでファイル形式を変換する必要がなくなったのでビルドが早くなった。 ## DBとの接続部分のサンプル作成 【課題・問題点】 - 最初はmongoを使う予定だったが、急遽postgreSQLを使うことになった為、急いでDB接続部分のサンプルを作成する必要があった。バックエンドはPython（FastAPI）で動いており、ライブラリから選定する必要があった。 【打ち手・使用した技術】 - Pythonといえば、SQLAlchemyを使う印象だが、FastAPIを使っていた関係で同じ作者が作っているSQLModelを使用した。SQLModelのバージョンはまだ低かったが、SQLAlchemyを継承して作成していることと、FastAPIと組み合わせて使うことでとても簡潔に書けることから採用した。 また業務システムということから、SQLを自動生成するのではなく自分でSQLをすべて書いてから実行をする方式をとっていた。このあたりの情報はドキュメントにはあまり書いていなかったが、ソースコードを見て実行できるようにした。

# プロジェクト概要 ## 目的 社内研修を兼ねた、社内要員評価システムの開発 入社して社外研修を２か月間終えた後に、6月~翌2月まで社内研修を行っていたうちの1プロジェクト ## 使用した技術や開発環境 TypeScript（Angular、NgRx）・バックエンド：C#（.NET）・PostgreSQL・AWS・Docker # やったこと - フロントからバックエンドにかけてのコーディングと単体テストを担当 - データベース設計（メンターと一緒に作業） - 他グループのシステム依頼者から聞いた要件を画面に起こす - batchの作成 - テストシナリオ/パフォーマンステスト # 苦労したこと - メンターからの課題で、テストシナリオやパフォーマンステストを新卒達で考えてくださいというものがあった。必要なデータの洗い出しや、どの段階でどうなっていればよいのかを考えながらドキュメントにまとめた。また、説明するためにも図が必要だったのでフローチャートにまとめたりした。多少の指導はあったものの、当時考えたものが採用された。

# プロジェクト概要 ## 目的 社内研修を兼ねた、社内SNSアプリの保守 入社して社外研修を２か月間終えた後に、6月~翌2月まで社内研修を行っていたうちの1プロジェクト ## 使用した技術や開発環境 TypeScript（Angular、NgRx）・バックエンド：C#（.NET）・PostgreSQL・AWS・Docker # やったこと - フロントからバックエンドにかけてのコーディングと単体テストを担当 - バグ修正や機能追加をメインに作業 # 苦労したこと - TypeScriptやC#、SPAのフレームワーク、状態管理ライブラリなど全てが初めてだった為、早く慣れるために空いた時間で様々なことを自分で調べて学習した。単体テストの非同期処理が曖昧だった為JavaScriptのmicrotaskを勉強したり、Angularについてもっと詳しくなるためにDocumentのAPIをかたっぱしから読んで色々試したりしていた。 その結果同期からは何かあれば頼られるようになった。