【杉山】serverside_challenge_2: 電気料金のシミュレーションを実装 #78
Conversation
開発環境の最低限のセットアップ
…page 電気料金計算ページのUIとAPI連携処理を実装
本番環境のビルドで失敗するので、設定ファイルのファイル読み込みの箇所を修正
…tion apiの本番環境にcorsの設定を追加
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
追記(10月30日)ER図とアーキテクチャ構成図を作成させていただきましたので追記いたします。 ER図erDiagram
Provider {
int id PK
string name
string code UK
}
Plan {
int id PK
int provider_id FK
string name
string code UK "※ provider_id + code の複合ユニーク制約"
}
BasicCharge {
int id PK
int plan_id FK
int ampere "※ plan_id + ampere の複合ユニーク制約"
decimal amount
}
UsageCharge {
int id PK
int plan_id FK
int from_kwh "※ plan_id + from_kwh の複合ユニーク制約"
int to_kwh
decimal unit_price
}
Provider ||--o{ Plan : "has many"
Plan ||--o{ BasicCharge : "has many"
Plan ||--o{ UsageCharge : "has many"
アーキテクチャ構成図
|
|
お忙しい中チャレンジの提出ありがとうございました。 |
| # Uncomment if you wish to allow Action Cable access from any origin. | ||
| # config.action_cable.disable_request_forgery_protection = true | ||
|
|
||
| config.middleware.insert_before 0, Rack::Cors do |
There was a problem hiding this comment.
Q
本番環境と共通化できそうですが環境ごとに指定している意図はありますでしょうか。
There was a problem hiding this comment.
開発環境で設定した内容がそのまま本番環境に反映されることを避けるため、
段階的にdevelopment/ productionで設定を分けて行いましたが
最終的に共通化するのを失念していました。
内容的に共通化可能なため、initializers/cors.rbにまとめる形で修正したいと考えております。
| from_kwh: 使用量(kwh)の下限 | ||
| to_kwh: 使用量(kwh)の上限 | ||
| unit_price: 単価 | ||
| date: |
There was a problem hiding this comment.
Q
今回の実装で日付関係の要素はなかったかと思いますが、local定義をしている意図があれば教えていただけますでしょうか。
There was a problem hiding this comment.
date等のlocale定義につきましては、rails-i18nのja.ymlをベースファイルとして使用したため、
今回の実装では使用していませんが、そのまま残しております。
理由:
- 将来的に日付フォーマットが必要になった際にすぐ使える
- Railsの標準的なlocaleファイル構成を維持できる
今回の実装で必要だったわけではありませんが、ベースファイルの構成を崩さない方が良いと判断しました。
ただ、使用していない定義を残していると複雑性が増すとも考えられますので、削除させていただきたく考えております。
| @@ -0,0 +1,5 @@ | |||
| provider_id,name,code | |||
| 1,従量電灯B,juuryouB | |||
There was a problem hiding this comment.
NITS
いくつかのcsvでprovider_idやplan_idが参照されていますが運用上の管理を考えますと、idでの管理は難しいと感じます。
具体的には
plan.csvでまだ登録されていないproviderのidを予想して指定している点が難しく感じました。
DBの自動採番はDBの再起動などで現在値が飛ぶ場合もあるので、マスターが壊れてしまう原因になりうると思いました。
There was a problem hiding this comment.
ご指摘ありがとうございます。
こちらのCSV登録機能に関しましてはrails db:migrate:reset db:seed前提で考えてしまっておりましたので
関連する要素のidを指定して登録するようにしておりました。
ただ、運用上の管理を考えると仰られるとおり、マスターが壊れてしまう原因になりうると考えられるため
idを予想して指定するのではなく一意のcodeを指定するように修正させていただきます。
|
Q CloudSqlの方がCloudRunからの接続が容易だと思いますが |
仰られる通り、
|
|
@ksugiura-ene 頂いたコメントに対してご回答させていただいておりますので |
|
お忙しい中ご回答ありがとうございます。 |
|
@ksugiura-ene |
2 participants
概要
お世話になっております。杉山です。
チャレンジ課題「serverside_challenge_2」電気料金のシミュレーションの実装をさせていただきました。
課題内容: https://github.com/enechange/coding-challenge/blob/master/serverside_challenge_2/README.md
詳細情報: README
実施内容
Ruby on RailsとNext.jsを用いて、電気料金シミュレーションAPIおよびフロントエンドを実装しました。
本番環境
使い方
環境構築手順
動作確認手順
フロント・APIの動作確認ですが、長くなってしまうため大変お手数をお掛けしてしまいますが
各実装時のPRをご参照頂けますと助かります。
フロント: 電気料金計算ページのUIとAPI連携処理を実装 chanchan-co/coding-challenge#9
API: 複数プランの電気料金を計算するAPI機能を作成 chanchan-co/coding-challenge#6
備考
ご確認よろしくお願いいたします。