Zenn
Open84

PartsSync開発日誌

masamasa

S3とCloudinaryどっちにしたらいいのかわからないけど、必要要件としては以下の通り。
・画像の自動リサイズ
・CDNで読み込みを早く表示させたい
・ウォーターマークすぐではないけど入れたいかも
・当面は25GB（Cloudinaryの無料枠）以内の利用となりそう

メリット デメリット
Clourinary ・短期中期的に導入工数が少なそう ・月25GBを超える容量の場合は$99/月必要
・その場合は、S3へ移行必要?
S3 ・コストが安そう
（公式計算ツールによると
写真10万枚で1000円以下の見積もり）		 ・各要件満たすために別々に機能の導入が必要

という感じなので、導入しやすさを優先してCloudinaryで実装してみる

https://zenn.dev/atelier_mirai/articles/755c626f04737c

こちらを参考にしながら、手を動かしつつCloudinaryを無事に実装できそうか検証してみる。1-2日かかるかな。

masamasa

大変そうだな。。1週間は沼るかもしれない。初期スコープではそもそも必要ない機能ではあるし、MVPリリースからは外すべき。ざっくりの難易度を把握できただけでも収穫としよう。

使いたいオプションメモ
・プレビュー機能
・複数枚同時アップロード

masamasa

SourceryとDeviseどちらを認証に使うか

→将来的にユーザー権限管理をしたいので、punditと組み合わせの良いdevise一択

masamasa

Rubocupが覚えがないのに入ってて、なぜかと思ったけどRails7系から自動的にgem追加されているらしい。あと、CI用のファイルも自動的に追加。Railsなんて便利なんだ。

masamasa

https://note.com/io_73/n/n4fbaab3526cf
画像遷移図は上記を参考に作成してみることとする。この流れが一番スムーズにいけるかも。

v0で自然言語でフロントモック作成
↓
ローカルでNext.jsプロジェクトの立ち上げ
↓
V0.devから生成したUIをインストール
↓
localhost:3000をhtml.to.designでスクショ
↓
Figmaでhtml.to.designプラグインを使用して、h2dファイルをインポート
↓
微調整

masamasa

ローカルでNext.jsプロジェクトの立ち上げ

こちら挫折したので、代替案としてbolt.newかGPT-Engineerでモックを作成→デプロイだとうまくいった！

masamasa

daisyUIでほしいモーダル無い、、、TailwindUIならあると思ったがdaisyUIのモーダルコンポーネントに別のコンポーネント差し込むことで解決しそう。

daisyUIの良さがあまりわかってなかったが、TailwindUIしかり、Tailwindのユーティリティを詰め込む方式で提供されているUIライブラリもあるらしい。

masamasa

カオスな情報を整理したBefore/Afterの提示のために、スプレッドシートのスクショをモザイクかけて、単月で1000品以上販売されているシートを示せるといいかも。

masamasa

windframeを用いて、tailwindベースの開発にすることにした。それにともない、daisyUIが不要ということで、sprocketsやcssbuilding-rails, jsbuilding-rails等のGem、Node.jsが不要となり、importmap-railsでモジュール管理をして、tailwindcss-railsがあれば開発できることに気づく。

そこで、新しく環境構築からやり直したくなって、rails newしたけどカレントディレクトリに生成されたはずのファイルが表示されなくて、findコマンドとかでも見つからなくて、沼。

結局、新たにディレクトリ作成してそこでdockerfile, docker-compose.yml, gemfile, gemfile.lockを作成して進めたところ無事に解決した。
1から進める際には以下の記事を参考にファイルの中身はコピペした
https://zenn.dev/hs7/articles/2cc4d67650ba69

masamasa

docker compose up時に必要なgemがインストールされていないというエラー発生。

docker compose run web bundle installとしても、docker compose run web bashからbundle installしても改善しない。

↑docker compose buildができていないために起こった現象だった。
その後、database.ymlに追加の記述を行って（理由はわかってない）、docker compose run web rails db:createしてからdocker compose upしたらrailsサーバーが立ち上がった。

default: &default
  adapter: postgresql
  encoding: unicode
  host: db #追記
  # For details on connection pooling, see Rails configuration guide
  # https://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  username: postgres #追記
  password: password #追記
masamasa

windframeの出力するhtmlがクセが有ることがわかってきた。コンポーネント単位をGUIでつなぎ合わせるまでは良いが、コードを出力するときには全体の構成は考慮されておらず、レイアウト崩れが容易に発生するので自分で整えないといけない。

masamasa

deviseは何の苦労もなく導入まではできた。カスタマイズしようとしてGitHub覗きに行き始めたら沼るのかもしれない。けど、それでもCursor使ってるからか、開発速度は使わないのと比べて雲泥の差のような気がする。

ログアウト機能を作成するためにも、ルートのページを売上管理画面（仮）作成して、そこからログアウトフォームを作って、ルーティング、コントローラー、ビューの設定をする。企画初期にUI作成とエディタの選定に力入れたらから開発効率たぶん良くてスムーズで嬉しい。

masamasa

基本的には1テーブルにつき1つが推奨されるようなので、24個もモデル作ることになりそう。何かしらの構造化が必要なのでは？と思わざるを得ない。例）Rails応用カリキュラムにあったポリモーフィックなど。技術面談使おう。

masamasa

deviseのログアウトボタンを設置して、ログアウトしようと思ったらHTTPメゾットがgetでブラウザから送られてしまってルーティングエラーが発生中。原因分析に20分くらい沼っている。

masamasa

どうやらrails-ujsが正しく読み込まれていないっぽいぞ

masamasa

rails-ujsは使えるようになったのに、まだroutingエラーが続く...

masamasa

コントローラーの記述見直したら5秒で治った

masamasa

gpt-o1-miniがGitHubのトークンが外部に漏れてる可能性があるから、今すぐにトークンを更新するように警告してきた。とはいえ、環境変数のファイルはgitignoreに追加済だし、エディタ側のPrivacymodeもonにしてるから問題はなさそう。

masamasa

エディタ内で実装の手引を細かく聞いて、それを基に実装する場合はもうこれは実質issueとして十分な情報量なので、これをGitHubCLIを用いて自動化したい。

AIに細かに聞いた実装手順を要約してマークダウンでチェックボックス化→GitHubCLIにてissue化を自動化したい。

masamasa

ひとまず、GitHubCLIでテスト投稿できるとこまではすぐできたけど、issue化したり、リポジトリに割当て等のオプションがなかなかできない。

masamasa

最初からgh item-createでissue化ができない
↓
gh issue create してから、gh item-addを検討
↓
gh item-addするためにissueのURLが必要だが、URLの取得に詰まる（いまここ）

masamasa
ISSUE_URL=$(gh issue create --title "GitHub CLI チェックリスト" --body-file checklist.md --assignee masaengineer --label "タスク" --json url --jq '.url')

gh project item-add 2 --url "$ISSUE_URL"

これでいけた！

masamasa

できた！シェルを実行すれば指定ファイルにまとまった内容をMarkdown形式で自動でissue化できる

masamasa

まぁ、次回からこの機能使うようにはするけど本来ならコマンド一つ打てば自動でissue用に要約が始まって、Pushするまでやってほしい。現状だと、要約の指示と専用のmdファイルへのコピペは行う必要がある。実現するには、シェルでCursorのAPIを叩く必要がありそう。今の技術力だとちと時間かかりすぎるので、また宿題としよう。

masamasa

GitHubのプロジェクトで「ストーリーポイント」というフィールドに数値を追加するためには、GitHub CLIを使ってGraphQL APIを呼び出す必要があります。以下のように、gh api graphqlコマンドを使用して、指定したフィールドに数値を設定します。

やっぱシェルからissue化しようとしたら、ちょっとまだ自分のスキル感だと自由に扱いづらいな。Reactとバックの通信はGraphQLがよく使われるみたいなので、そのタイミングで再チャレンジするのが学習効率良さそう。

masamasa

なぜGitHubActions公式のCIファイルを使ってるのにエラーが起きるのか。

masamasa

CIファイルの沼から抜け出せない。

ひとまず公式のRubyやgem-pushファイルはRailsプロジェクトには不要ということだけはわかったので削除。

dockerで環境変数を使う辺りで知識不足でAIの提案が何やってるのかわからなくなってコードを補完したり、消したりで沼。一旦飛ばして、時間があるときにUdemyとかで体系的に学習しよう。

masamasa

deviseのconfirmable（新規登録時にメール認証を必須にする）を有効にしたところ、エラーに詰まってしまい2-3時間沼る。

letter_opnerの設定が原因と思われるので以下のデバッグを実行。が、解決しないので一旦confirmableの機能は先送りして別の開発を進める

Devise Confirmableの有効化過程でのエラーと対処方法

エラー1: マイグレーションエラー

エラー内容

add_confirmable_to_usersマイグレーションを実行中にエラーが出た。

対処方法

  • マイグレーションファイルを見直して、confirmableに必要なカラムがちゃんと追加されてるか確認した。
  • db/migrate/20241120080231_add_confirmable_to_users.rbとdb/migrate/20241120080625_add_confirmable_to_users_2.rbの内容をチェックして、重複やミスがないか確認した。

エラー2: メール送信エラー

エラー内容

ユーザー登録時に確認メールが送られない。

対処方法

  • config/initializers/letter_opener.rbを確認して、メール送信の設定が正しいか見た。
  • Gemfileにletter_openerが入ってるか確認して、bundle installを実行した。

エラー3: ルーティングエラー

エラー内容

確認メールのリンクをクリックしたらルーティングエラーが出た。

対処方法

  • config/routes.rbを確認して、devise_for :usersがちゃんと設定されてるか確認した。

エラー4: モデルの設定エラー

エラー内容

Userモデルにconfirmableがちゃんと設定されてない。

対処方法

  • app/models/user.rbにdevise :confirmableが入ってるか確認した。

その他の注意点

  • db/schema.rbが最新の状態か確認して、必要ならrails db:migrateを実行した。
  • Dockerコンテナ内で作業してるなら、docker-compose exec web rails db:migrateとかのコマンドを使うといい。
masamasa

結局、confirmable関係ではなく、recoverbleの実装においても先程のスクショと同じエラーが出る。これ解決できたら、逆にconfirmableもうまくいくかもしれない。

masamasa

config/environments/development.rbに、同じ記述が複数個ある設定がいくつかあったので、これが原因かと思ったが違う様子。

masamasa

解決！エラーの原因は以下の通り

エラーの原因特定

  • エラーメッセージ:

    • NoMethodErrorが出ていて、letter_opener_url=というメソッドが見つからないと表示されている。
    • これは、ActionMailer::Baseにそのメソッドが存在しないことを示している。

  • 設定の不一致:

    • letter_openerやletter_opener_webの公式ドキュメントには、letter_opener_urlという設定は載っていない。
    • だから、誤って追加された設定だと考えられる。

  • 他の設定との整合性:

    • letter_openerやletter_opener_webを使うには、delivery_methodを設定するだけで十分。
    • そのため、letter_opener_urlが不要であることから、エラーの原因と判断した。

解決策

  • config.action_mailer.letter_opener_urlの行を削除する。
  • development.rbの設定を見直して、正しい設定にする。

まとめ

  • letter_openerやletter_opener_webを使うときは、公式ドキュメントを参考にして、不要な設定を避けることが大事。
  • エラーメッセージをよく読み、どの部分が問題かを特定するのがポイント。
masamasa

よし、もともと予定してなかったけどi18n-tasksで国際化されてないロケールを自動的に検出できるようになった！

設定済みの翻訳が未設定と誤検出されるのでもうういいかな、、と一瞬思ったが公式リポジトリを見に行ったら解決した。パスの設定以外にも、専用のファイルをconfigに作らないといけなかったみたい。公式見るのは大事だわ〜

masamasa

知らぬ間にAIのハレーションを信じて、deviseのコントローラーをカスタマイズする方針を採用してしまっていたので、関連のコントローラーすべてとルーティングの設定を標準に戻した。（無事に動作確認OK）

ただし、まだフラッシュメッセージは出てくれないので明日に引き続きデバッグする。

masamasa

そういえば、

#バリデーションエラーの表示
  <%= render "devise/shared/error_messages", resource: resource %>

って入れ込みはあったけど、これはそもそもflashオブジェクトを呼び出しているのか？否。

layout/application.html.erbに以下の記述を入れればflash_messageはブラウザに表示されるようになった。

 <body>
    <main class="relative min-h-screen">
      <p class="notice"><%= notice %></p>
      <p class="alert"><%= alert %></p>
      <%= yield %>
    </main>

参考
https://arc.net/l/quote/ethvxwgk

masamasa

claude曰く、turboとrails-ujsが競合している...? Rails7ではrails-ujsは不要?
rails-ujsがなんだったか忘れていてさっぱりなので、調べまくらないと消して良いのか判断できない

あと、気になる点としてHotwire導入してるのにログにas TurboStreamではなく、as HTMLとなっている。Turboうまく使えてない？

masamasa

あまり良くわかってないけど、rails-ujsおよび関連記述（app/assets/config/manifest.js, config/importmap.rb）を消してみたけど開発環境では特にエラー出なかったからこのままでいこう

しかしながら、依然としてas TurboStreamとはなっていない。

masamasa

サーバー再起動したらTurbo読み込まれるようになった！

masamasa

Deviseでビューファイルがデフォルトでは味気ない素のHTMLのみだったように、フラッシュメッセージに関する記述もカスタマイズして使う必要がある？
↓
公式をみていたところ、DeviseとHotwireを統合するための処理が書かれていたが、これはすでにできていて問題なさそう。
https://arc.net/l/quote/qakyjjru

Railsガイド曰く

flashはセッションの特殊な部分であり、リクエストごとにクリアされます。つまり、flashは「直後のリクエスト」でのみ参照可能になるという特徴があり、エラーメッセージをビューに渡したりするのに便利です。flashにアクセスするにはflashメソッドを使います。flashは、セッションと同様にハッシュで表わされます。

だそうなので、特に設定していないけどdeviseの内部的な処理によってflashオブジェクトにはアクセスできていて、かつビューファイルへは表示できている。

というか、devise関係なしにRails自体のフラッシュメッセージってどうやって設定してたっけ。
↓
app/assets/stylesheets/application.cssにフラッシュメッセージのCSSを記述しよう的な記事をいくつか見つけたけど、tailwind前提でも同じ...?
→tailwindで上記ファイル編集してみたけどフラッシュメッセージは変わらない。

masamasa

検証ツールのコンソールでは上記のエラーがでるが、バリデーションエラーが起きているということなので、意図している動きではある。フラッシュメッセージの装飾とは関係なさそう。

masamasa

そうか、daisyUIみたいなコンポーネントライブラリを使ってないし、RailsはCSSライブラリなしではデザインまではよしなにやってくれないのか。Tailwind単体でやっていく場合は、フラッシュメッセージも自分でstylesheets/application.cssに記述していく必要があるのね。。

これまで最初からBootstrapがあたってるカリキュラムやdaisyUIの自作アプリしか作ってこなかったから勝手にフラッシュメッセージにデザインあたってて学ぶ機会を逃してた。

masamasa

フラッシュメッセージ自動で消えるようにするためにはTurbo（drive, frames, streams）だけでは実装できなくて、Turboで表示させてからStimirusで自動的に消えるようにすることが必要な模様。

masamasa

Seedファイル作成および、コンテナ立ち上げ時に自動的にSeedが実行されるようにdone。

コンテナ2回目以降の立ち上げ時にすでにデータが重複するエラーが出てしまっていたので、seedファイルを見直して、すでにデータがあるかどうかの条件分岐をメゾットfind_or_create_byで加えたらエラー消えた。

似たようなメゾット「first_or_create」もそうだけど、単一のハッシュにしか対応しておらず、複数のハッシュや配列データには対応していないみたいだったので、ちょっと書き方がややこしかった。生成AIない時代にこのデータを手動で書くことを思うと胸焼けがする。

masamasa

一昨日から相変わらずdebug gemが使えなくて困ってる。binding.bをコントローラーに仕込んでもデバッグコンソールがターミナルで開かない。。。

masamasa

少なくともモックアップを作成するという段階では「UIコンポーネントライブラリを使わない素のTailwindCSS＋Windframe」が部分最適だったけど、いざ開発していくと次のような問題が発生

・当初想定しておらず、かつwindframeには存在しないコンポーネントが多々あることに気づいた。例えば、ハンバーガーメニュー/Drawar/アコーディオンとか（要するにJS含む処理がいる系）。

・Tailwindでカスタムクラスを作るのが頭によぎるが、流石にTailwind出現前のネイティブのCSS時代と同じクラスに名前をつける作業発生して本末転倒感...

・そもそも、なぜ素のtailwindのみでの開発に踏み切ったかというとRails+tailwind-rails+importmapでシンプルに開発してみたかったから。しかし、結局カスタムクラス作るんだったらNode.jsいれて開発進めたほうが合理的

まさしく、この人と同じ課題にぶち当たった
https://discuss.rubyonrails.org/t/can-i-use-a-component-library-with-just-tailwindcss-rails-or-do-i-need-node/84664

I love that Rails 7 eliminates the node dependency. It’s a huge simplification! However, after getting my project up and running with just tailwindcss-rails I want to add a tailwind component library to save me time.
I looked at Daisy UI and Flowbite, two popular ones, but I can’t get either of them to work by following their directions. I might not be fully understanding how importmap and tailwind plugins work.

masamasa

やっぱdaisyUIだと情報多いし詰まったときのリカバリーが聞きそうだからこっちにするか...。将来的にNext.jsに切り替えたいときも同じ有料のコンポーネントキット使えばユーザーからは違和感なく乗り換えできるし。しゃあない。

masamasa

https://zenn.dev/yoiyoicho/articles/410a7e3fd892b5
これに沿ってtailwindcssを入れ直して、daisyUIを新たに追加する

やること
・docker関連ファイルを再構築して、node.jsをインストール
・importmap関連を削除し、jsbundling-rails, cssbundling-railsを追加
・bundle exec rails css:install:tailwindでtailwindを追加
・ bundle exec rails javascript:install:esbuildでesbuildをバンドラーに設定
・yarn add daisyuiでインストール
・tailwind.config.jsにdaisyUIの記述を追加

masamasa

上記、エラーに詰まって環境構築できない。。。いっそのこと新しくRails newからしたほうが早い気がする。。

masamasa

売上レポート機能の設計にサービスオブジェクトパターンを導入すべきかどうか。設計の経験が少ないだけに善悪の判断がしづらい。ひとまず導入せずに進めてみて、リファクタリングの段階で同パターンの恩恵を感じてみよう

masamasa

テーブル表示と裏側のロジック一旦できた！うれし！

masamasa

daisyUIの課金版コンポーネントキットがカッコよすぎてテンション上がる。これはイケてるUX提供できる。

masamasa

今日はひたすらSalesReportのビジネスロジックを組みつつ、DBの再整理をしまくった。明日も丸一日くらいかけたら一段落しそう。

masamasa

検討事項
・Productテーブルに保管場所のカラムを追加すべきか
・Orderitemsテーブルの名称がわかりにくいので、OrderSkusはどうか
・Sku_Partnumber_LinksはRails慣例に基づいていない？Sku_Product_Linksがよさそう

修正必須
・Fullfilmentテーブル追加, 自宅倉庫も加える
・海外発送拠点への横持ち費用をProcurementsテーブルに追加

masamasa

ポリモーフィック関連付けをDBに導入した。DB設計の正解パターンやアンチパターンのストックがなくて判断しかねることが多いので、体系的に学びたく技術書5冊くらい買い込んだので読むぞ〜

masamasa

AIに頼んでた"YYYYMMDDHHMMSS_create_contact_informations.rb"って名前のままじゃrails db:migrate もrails db:migrate:statusも実行されないのね。勘違いしたまましばらく進めちゃってててやっと諸悪の根源に気づいた。

masamasa

先方のデータ管理が煩雑なので、まず情報整備から取り組みつつ、分析に使えるデータの抽出方法を実装する必要がある。これがいわゆるデータベースエンジニアってやつなんだろな。

masamasa

メモ
ユーザーが月ごとの間接経費を都度削除したり入力するためには、DBにスキーマレスなJson形式のカラムを用意してあげれば良さそう。

masamasa

基本的な概念聞く程度なら生成AI使ったほうが早いけど、ビジネスのドメイン知識が絡む設計（テーブル数25以上）ではあまり使いこなせてない。運用が始まっちゃうとテーブル変更がしづらくなると思うので初期の設計の重要度高いが、AIの提案の精度を判断できなければ採用できないので、結局自分の知識不足がボトルネックになってる。

ということで、体系的にインプットすべくこの2日で以下の3冊を読了
・データモデル大全
・失敗から学ぶRDBの正しい歩き方
・達人に学ぶDB設計徹底指南書（難しかった...理解度は50%以下）

まだまだパフォーマンスまで意識した設計は先が遠そうだが、ひとまずはActiveRecordの規約に沿ったり、第3正規化までやっていれば、アンチパターンの多くは未然に防げることを知りありがたみを知った。

細かいところはまだどうすればいいか結論でてないので、整理して以下を検討する。

・Buyer, User, Wholesalerの一部はAddressテーブルとして共通化すべきか
・共通化する場合はActiveRecordのポリモーフィック関連付けの導入の是非
・SalesChannnelsテーブルの国内/輸出フラグはアンチパターンかどうか
・売上管理表のビューファイルはどのような技術を用いると効率的に表示できるか。キャッシュ？マテリアライズド・ビュー？

masamasa

最初からビジネス要件を洗い出しして、それをもとにテーブルの詳細設計までやるのが最大公約数的な答えみたいだけど、Railsの場合はいわゆるアジャイル開発と相性が良いと言われるし、開発速度を優先してひとまず使いそうなテーブルだけ残そう。テーブル数25超えているが使われなさそうなテーブルが多くて悩んでいる時間が無駄に思えてきた。（それでも20は超えそう...）

masamasa

削除対象テーブル

・QuatationItems
・QuatationItemChanges
・OrderStatusHistory
・Inventories
・Remarks
・AdvertisingCosts
・SalesChannelFees
・SalesChannels
・WholeSales
・Quatations
・ProductCategories

壮大な計画過ぎたな。。MVPリリースだけならだいぶ考えなければいけないこと減りそう。最低限の機能から始めることの重要性は何度も耳にしているはずだけど、いざ実践となると大きなものを最初から作ろうとしすぎてしまう。

masamasa

表示したい項目から逆算してモデルやテーブルを削ったら随分シンプルになった。
取得予定のCSVファイルとの整合性をとるためにテーブルをもう少し調整せねば

masamasa

https://storerecord.jp/lp/
まさにこれの小規模事業者版を作りたい。今の実力だと複雑な設計ができないので簡易的な意思決定サポートに留まるけど。

masamasa

2日悩んでたエラー解決。

エラー詳細:
https://gist.github.com/masaengineer/96a3236b23de08a499d631d011ad8133

NexusテンプレートのtailwindやdaisyUIのユーティリティが反映されていなかったが、プリコンパイル済みのアセットが配信可能な状態になっていることが原因だった。
https://arc.net/l/quote/fyszwmgo

rails assets:clobber
rails assets:clean
でコンパイル済みのassetsを削除して、ブラウザを再読み込みすれば正しく表示された。

次回からの防止策として、下記の設定を実施
https://arc.net/l/quote/lqugdusl

masamasa

利益率の計算がおかしくてデバッグ沼。おかげで、前回使えなかったRails7標準のdebug gemによるrbdbがある程度使えるようになった。VS CodeのGUIでも同様に使えるぽいので慣れたい。

あまり仮説を立てずに行き当たりばったりで検証することが多く、たぶん生産性が高い人と比べてかなり効率悪いと思う。自覚がある分、修正あるのみ！

masamasa

そういえば細かにデプロイしてない...と思いたって実行したらエラー。ちょっと同様したけどよくエラー読んでたらRender側の設定でmainブランチをデプロイするのではなく、別ブランチを読み取っていたからと判明。良かった。

masamasa

rdbgを用いたデバッグ方法

①binding.break（debugger/binding.b）をデバッグしたい箇所に仕込む
②Webサーバーを起動する
③デバッグモードに入るので、docker exec -it コンテナ名 rdbg -Aでコンテナへ接続

masamasa

CSVうまく取り込むために工夫したことメモ

・FVFや国際手数料がSalesTransactionReportでは負の値で出力される
・ヘッダーの位置が先頭行ではないので調整
・手数料タイプが複数存在するので場合分け
・一つの商品の収支を出すのに、5つのCSVファイルを統合しなければならないが、すべてのシートに共通のキーが存在するわけではないので、関節キーでファイル同士の情報を紐づける必要がある。
・返金の存在

masamasa

続き→report_calculatorをみて、利益額が大きくなってしまう原因を探す
debugのvscodeの使い方を今一度確認

masamasa

先方がorder_numberベースで発注をかけていて、その発注シートに紐づく形でしか仕入れコストを取得できないのが悔やまれる。このため、sku単位での調達コスト等が把握がしづらくなる。

言い方悪いけど元のデータ管理が腐ってると、運用も100%のパフォーマンス出せない。ビジネス構築初期の頃からちゃんとデータ設計をエンジニア目線で管理することの重要性を感じた。

masamasa

同じ期間でebay transactionreportとsalesreportを出しても、salesreportのほうが少ないorder数が出力される問題発見