ID:60514さん

## サービス概要 - ECショップの受託・新規開発 - 複数ネットショップの在庫・商品・受注・発注/仕入管理ができる多機能ASPサービス ## 担当業務 - PL(プロジェクトリーダー)兼エンジニアとして参画 - 主にバッチ部分の実装を担当 - 言語は主にRubyを使用、Batch・APIの実装 - 出品機能、在庫連携、注文取り込み機能在庫連携新規実装、調査、検証 ## 使用技術 ・Ruby, Rails, RSpec(TDDでの開発) ・PostgreSQL ・JavaScript, Vue.js(Nuxt.js) ・AWS, circleciCI, GitLab ・開発環境(neovim, vscode, GitLab, circleciCI, Vagrant) ## 課題 → 取り組み - アプリケーションが「フロント」「バックエンド」「batch」で構成されており、batch側の実装だったため、画面を見ながら確認しつつ実装、検証を行うことができなかった。 - Rspecでテストを記述してから、ロジックの実装の実装を行うTDDで実装を行う、テストの内容も充実されることで、実装の質を担保するようにした。 - アプリケーションが大規模且つ、ドメインが複雑だったため、設計を乱雑に行うと技術負債が溜まり追加実装や修正が行いづらくなってします。 - 設計、ディレクトリ構造を一般的なRailsのMVCで行うのでなく、DDDを取り入れドメインモデルを中心して設計を行い、のちの追加、修正に対応できるスケーラブルなアプリケーションにできるようにした。 - 大量のユーザーが使用し、大量のデータを扱うことが想定されていたので、パフォーマンス性を強く意識しなければならない。 - パフォーマンスを意識したコードの記述やN+1考慮したSQLチューニング、常に発行されるSQLをチェックするなどを常に意識した実装をおこなった。 - 機能要件、非機能要件が複雑だったプロジェクトだったので、チームメンバーがチャッチアップに非常に苦労する - 毎日早朝と夕方にコードリーディング会を開催し、チームメンバーがスムーズにチャッチアップできるような仕組みづくりに努めた。 ## 工夫した点 - batch処理での「ネットショップへの出品機能、在庫連携」をネットショップの仕様や提供しているAPIの調査から要件定義、機能の実装、テストコード実装と検証までをすべて行い、機能を完成させた。 - プロジェクトリーダーとして、個人の特性に配慮した適切なタスクの割り振りや積極的にコミュニケーションをとり、詰まっているメンバーの実情の把握に努め、サポート行う等のチームマネジメントを行い、当初の開発スケジュールが停滞することなく、プロジェクト遂行できた。

## サービス概要 - 受託開発（保育士求人・転職サービスの新規開発） - 保育士求人者と保育事業者とのマッチングサービス ## 担当業務 - メール周りの開発(AWS SES, Delayed Job) - API連携部分実装 - Ruby・Ruby on Rails・javascriptにてシステム構築 - Dockerでの開発環境の構築 ## 使用技術 - Ruby, Rails, RSpec - MySQL - JavaScript - AWS(EC2, RDS, S3, CloudFront, WAF, CloudWatch, SES) - 開発環境(neovim, vscode, Docker, GitLab) ## 課題 → 取り組み - メール周りの開発で一度に大量のメールが送られるとサーバー落ちてしまう現象が発生した。 - Delayed Jobを導入しでメール送信処理を非同期化して、順次実装されるようにし、サーバーに負荷がかからないようにした。 - リリース後に外部のアプリケーションからもAPIと通して会員登録できるようにする仕様変更が発生したのだが、外部のアプリケーションで会員登録する際に住所構造が開発していたアプリケーションと違ったため(政令指定都市が別テーブルになっていた)そこに対応しなければならなかった。 - 開発していたアプリケーションで住所市町村テーブルから政令指定都市を住所マスターを作成しつつ、別テーブルに切り分けて作成し対応した。郵便番号を入力すると外部APIを使用し自動で都道府県、政令指定都市が自動で入力される仕様にもなっていたので、外部APIから郵便番号をもとに返ってくるJsonのレスポンスをParseする実装を1から修正することで修正・対応を行った。また、既存のDBに登録されている情報の修正に関しては、リリース後の対応だったため、本番のDBもトランザクションを貼りつつすでに登録されている住所情報の変更を行った。 ## 工夫した点 - メール周りの開発(AWS SES)で、Delayed Jobを活用してメール送信処理を非同期化して、サーバーに極端な負荷がかからないようにした。 - パフォーマンス向上の観点から、負荷がかかりそうなSQLは、常にissueに実際に発行されるSQLを記録しエビデンスを残すようにした。

## サービス概要 - 現在住んでいる住居人(10人ほど)が使っている1台の洗濯機が稼働しているかどうかわかるIoTを活用したサーバーレスなwebシステム qiitaアウトプット内容 [洗濯機が稼働しているかわかるサーバレスなWebシステムを作ってみた【IoT AWS Lambda APIGateway DynamoDB】](https://qiita.com/yuki5664/items/aac81d730187f8cfbc7b) ## 開発内容 - AWS Lambda のロジックの実装 - インフラ構築、アーキテクチャ設計 AWS(Lambda, APIGateway, DynamoDB, S3) - フロント部分の開発 ## 使用技術 - Node.js, Javascript - AWS, Lambda, DynamoDB, APIGateway, S3 - JavaScript - AWS(EC2, RDS, S3, CloudFront, WAF, CloudWatch, SES) - 開発環境(neovim, vscode, Docker, GitLab) ## 課題 → 取り組み - 電流を取得しているIoTデバイスのスマートプラグのAPIの使用しすぎは、APIシステムへの課金がされてしまう - AWSのLambda(Node.js)でIoTデバイスが提供しているAPIは5分に1回だけ取得するようにしデータをAWSのDynamoDBに保存するようし、課金されない範囲でAPIを叩き電流情報を取得するようにした。 - 洗濯機を使っていても、脱水時は電流データが0になるタイミングがある - 保存されたDynamoDBから電流データを取得し、使っているかどうかを判定(最新電流データから過去3回分中、電流仕様が2/3だったら使用中とする)し、APIで返すAPIサーバーをLambdaとAPIGatewayで作成することで、たまに脱水時の情報を取得しても稼働中を判定できるようにした。 ## 工夫した点 - 個人開発で運営費用を0円にしたかったので、AWSのLambdaやAPIGeteway、DynamoDB等でサーバーレスなアーキテクチャを組みました。今の所、1円もかかっていません。 - シェアハウスに住んでいる住民の悩み、声などの課題をシステムで解決したこと