辛い開発を色々使って迂回した話

1. 辛い開発を色々使って迂回した話辛い開発を色々使って迂回した話
吉祥寺.pm 14
2018 5/25
佐藤慎一郎@s2otsa

2. 自己紹介自己紹介
一年前までPerlをメインにしていたTypeScriptをよく書きます最近はRailsをよく書いていますClojureとか好きですけど書く場所がないのが悩みSQLとか書いて色々やるのも結構好き

3. 自己紹介2自己紹介2
受託でEC(とか)を請け負う会社両国=> 浅草橋

4. 自己紹介3自己紹介3
楽器の名前で検索したら出てきたので入社した

5. 今回のテーマ今回のテーマ
エンジニアリングで解決したこと､エンジニアリングで解決したこと､
しなかったことしなかったこと

6. 今回話す案件の背景今回話す案件の背景
アパレル系ECサイトを受注！僕のところで実装を始める前にすでに使うプロダクトは決まっていた年末年始とかデザインで揉めたりで期間に余裕がなかった

7. エンジニアリングで解決しなかったこエンジニアリングで解決しなかったこ
とと
僕のところに来るまでに使うプロダクトは決まっていた年末年始とかデザインでもめて期間に余裕がなかった

8. まぁ色々ある。まぁ色々ある。

9. 今回使うことになったプロダクト今回使うことになったプロダクト

10. MAGENTO2とはMAGENTO2とは
PHP製OSS
世界で一番シェアがあるらしい日本でのシェアは一位ではないらしいXMLを書いてDIを回すだけで機能追加が可能View層もXMLを書いて適宜PHPでテンプレートを書くことで拡張可能

11. ここから少し悪口を言いますここから少し悪口を言います

12. PHP7PHP7
(5.3とかの時代に使っていたけど)7はそこまで悪くないネームスペースは気持ち悪いgrepしづらい置換しづらい
namespace MagentoSalesModel;
use MagentoFrameworkModelAbstractModel as FrameworkAbstract

13. PHP7PHP7
ビルドするのに古めのライブラリに依存しててつらいPlackみたいなスタンドアローンサーバがないので少し不便

14. MAGENTO2(プログラム)MAGENTO2(プログラム)
View ModelともにXMLベースのDI
DIの仕様が巨大すぎてわからない入社して半年くらいだけど全然全容がつかめない主観になってしまうが過度に複雑だと言わざるを…
Magento1ではless sassともにサポートされていたのがなぜかlessのみに…

15. MAGENTO2(DB)MAGENTO2(DB)
テーブル定義に一貫性がなかったり辛かったり外部キーが貼ってあったりなかったり…
主キーや外部キーのカラム名がentity_idだったりテーブル名_idだったり…
~optionみたいなテーブルが20件くらいある中、外部キーがoption_idとかになっていると、どのテーブルのIDだ！となる

16. MAGENTO2(DB)MAGENTO2(DB)
巨大なEAVテーブル2万の商品について100万の商品属性など…
EAV系のテーブルのvalueの別のテーブルのIDが入ってたり…
1+n問題が多発して遅いおそらくそれを緩和するために大きなキャッシュ機構がある

17. ここまで悪口ここまで悪口
色々言ってもOSS
本来は文句があればPR出すなり使わないすべきあくまで今回状況がいろいろあった話

18. まぁ色々ある。まぁ色々ある。

19. MAGENTOでなんとMAGENTOでなんと
かするのはナシだかするのはナシだ

20. 実装方針実装方針
ベース部分はMagentoを使う付随する開発は別口でやることにした半年かけてわからなかったものが一月でわかる気がしないDIでできそうにない機能があるため、本体のコードに手を入れざるを得なくなってしまう

21. 今回話す実装した機能について今回話す実装した機能について
1. リッチな画面2. 管理画面のログインアカウントに応じて出す情報を分ける。サーバは同じものを使う。3. CSVによる注文管理など

22. リッチな画面リッチな画面
アパレルECということでデザインは重視している弊社デザイナもECは浅くMagentoを知らない結果上がってきたものはMagento内で作るのは大変

23. リッチな画面リッチな画面
Magento2はREST APIが結構充実していて、結構良いAPIが発行するSQLのクエリは結構素直まとめて取ってこれなくて同種のAPIをたくさん発行することもある

24. リッチな画面:実装方針リッチな画面:実装方針
Magento2のViewは一切使わないReactを使ってフロントのViewを作り、NginxでHTMLとJSを配信する各種必要なデータ、処理類はAPIに任せる沢山発行するクエリはCloudfront、LocalStorageでキャッシュをして高速化する

25. リッチな画面:実装方針リッチな画面:実装方針
解決！解決！

26. 管理画面のログインアカウントに応じ管理画面のログインアカウントに応じ
て出す情報を分けるて出す情報を分ける
アパレル系EC
クライアントは一社だけど、窓口は二つ片方は本社に属するブランド、片方は本社が買収した子会社(がブランドそのもの)
それぞれのブランドECサイトのドメインは異なっている

27. 色々と試行錯誤色々と試行錯誤
出し分けを行うのは、商品、顧客、注文、発送などのテーブルEAVで管理される商品の属性のマスターは同じものを使いたい管理画面ドメインに応じてテーブルの中身が変わるMagetoには手を入れないのでテーブル名は同じものを見る

28. 色々と試行錯誤色々と試行錯誤
管理画面なのでテーブルにたいしてCRUDは発生するフロントは異なるので、入り口によって発行するクエリを変えればよいMagentoは触りたくはないのでちょっと異なるレイヤで始末をつけたい

29. https://dev.mysql.com/doc/refman/5.6/ja/view-
updatability.html

30. MYSQLのVIEWMYSQLのVIEW
条件を満たしていればINSERT/UPDATEが可能(始めて知った)
UNIONとかJOINとかをして単一のテーブルが対象でない場合はNG
単一のテーブルでも自己をJOINとかすると多分NG(試していない)
細かくはリンクを見てください。

31. 対応策対応策
1. 元テーブルの名前を変えて、同名のViewを作る。ViewのSELECT文はMySQL接続ユーザー名を使ってWHERE句を発行する2. アプリケーションサーバを別ポートで二つ立てる3. それぞれでMySQLの接続ユーザー名が異なる4. 使用メモリが倍になる。が売り上げ単価が高くアクセス的にはそこまでではないのであまり問題にならない

32. 管理画面のログインアカウントに応じ管理画面のログインアカウントに応じ
て出す情報を分けるて出す情報を分ける
解決！解決！

33. CSVによる注文管理などCSVによる注文管理など

34. 受注情報出力/発送情報入力受注情報出力/発送情報入力
対象者は倉庫の人達受注CSVを受け取って商品を倉庫から探して発送する発送書を元にCSVを作ってシステムに取り込む配送した旨のメールを顧客に送るお客さんの持っている商品管理と合わせてCSVをつくる必要あり

35. いわゆる普通の管理画面はいらないいわゆる普通の管理画面はいらない

36. 受注情報のCSV出力について受注情報のCSV出力について
毎朝Cronで集計してメールで投げる色々考えると管理画面でやる必要がなかった管理画面ログイン> 画面移動> CSV出力、より格段に楽。

37. 発送情報のCSV入力について発送情報のCSV入力について
割り切ってAmon2で実装色々考えると管理画面でやる必要がなかった

38. 悩み悩み
Perlの会社じゃない。読める人がいない。納期ギリギリで、色々諦めがあった落ち着いたら少しずつ他のメンバーのわかる言語に移植した方が良さそう

39. 受注情報出力/発送情報入力受注情報出力/発送情報入力
解決!解決!

40. まとめまとめ
一つのプロダクト、技術体系にこだわる必要はない基本的にサーバサイドの人だけど何でもやる人になっていると幅を広げやすい引き継ぎづらくはなる動作上オーバーヘッドは増える傾向が当然あるPHP/Magentoに手をつけないで終わった

41. ご静聴ありがとうございましご静聴ありがとうございまし
た。た。