Skip to content

Instantly share code, notes, and snippets.

View zsy715's full-sized avatar

Shengyang zsy715

View GitHub Profile
@zsy715
zsy715 / requirements.txt
Last active September 20, 2021 15:59
Giant requirements.txt
Markdown==2.0.3
# different versions of MySQL-python
# erp_integration
MySQL-python==1.2.3
# email_integration
MySQL-python=1.2.2
# iotop==0.4

Before we start thinking about rebilling, we need to roughly know the architecture of subscription. Open questions would be

  • Do we need a database?
  • What can we get from Shopify subscription endpoint?
  • What would be the most basic requirements?

Scenarios

  • Customers purchase subscription -> Shopify triggers initial billing, generates orders and new subscription contracts
  • Birchbox requests billing attempts -> Shopify bills customers and creates new orders
  • Birchbox ships orders -> Shopify creates fulfillments

What to track?

  • subscription history(from Customer)

create plan with product


curl -X POST http://localhost:3000/graphql_extension -H "authorization: #{token}" -d 'query=
mutation {
  sellingPlanGroupCreate(
    input: {
      name: "Bill monthly"
      merchantCode: "bill-monthly"
      options: ["Delivery every"]

magento servers

magento staging app7, web9

magento prod uk: web0, web2, web11, app1, app2

magento prod es: web0, web2, web11, app1, app2

magento prod us: web0, web2, web7, web11, app1, app2

@zsy715
zsy715 / erp_investigation.md
Last active September 23, 2020 16:56
erp scrips investigation

Outbound files

JDE -> OHL ✅:

  • */15 1,3,11,13,15,17,19,21,23 * * * cd $ERP_BASEDIR ; python jde_get.py
  • send purchase order to warehouse.
  • cron job is set up on app2/stu
  • cron job triggers jde_get.py: get csv files(with prefix 943) from smb server PD910/outbound
  • call etl_pass.py: persists data into ohl_resp database, triggers 943.py
  • call 943.py: convert original csv to tsv(with prefix BBXITPO), post files to ohl ftp
  • files(BBXITPO) would potentially get lost if ftp upload fails(archive happens after ftp upload). See https://github.com/birchbox/erp_integration/blob/develop/ETL/943.py#L131-L134

We have 3 versions of shipping method/shipping preferences/carrier code

  1. orders from magento: it's called shipping preference. eg. ups_twodayair, ups_ground
  2. orders in BBOP-SHIPMENTS: it's also called shipping method(mapped with shipping preference). eg. 02, 03C
  3. CSH from warehoue: it's called carrier_code

For order 130342984

  • magento order with shipping_preference ups_ground
  • BBOP translates it to shipping_method 03C exported to warehouse
  • warehouse returned carrier_code 03C in CSH

Keybase proof

I hereby claim:

  • I am zsy715 on github.
  • I am shengyang (https://keybase.io/shengyang) on keybase.
  • I have a public key ASDbWNnSSAS8j6My2YFbjibNaTsARFFMa68M_FYGeRzOdQo

To claim this, I am signing this object:

@zsy715
zsy715 / zsh_shell_config.md
Last active February 10, 2020 22:03
zsh shell config
  • conda env list to get python3 path
  • in bbop-orders, some logs shows no shipping method. In the code, if no shipping method, order won't be forwarded to bbop-shipments
15:36:41.060 [pool-2-thread-151] WARN  ?.(:): Order complete with included items but no shipping method: 129665819
15:37:49.335 [pool-2-thread-54] WARN  ?.(:): Order complete with included items but no shipping method: 129665835
15:38:06.454 [pool-2-thread-127] WARN  ?.(:): Order complete with included items but no shipping method: 129665837
15:41:40.352 [pool-2-thread-110] WARN  ?.(:): Order complete with included items but no shipping method: 129665871
15:42:25.285 [pool-2-thread-139] WARN  ?.(:): Order complete with included items but no shipping method: 129665879
15:43:05.041 [pool-2-thread-104] WARN  ?.(:): Order complete with included items but no shipping method: 129665886
15:43:20.865 [pool-2-thread-36] WARN  ?.(:): Order complete with included items but no shipping method: 129665889
15:45:33.296 [pool-2-thread-169] WARN  ?.(:): Order complete with included items but

The result of my investigation:

  • the update/create method in the backend is pretty straight forward. Since a product is associated with multiple attributes, every time in order to create/update product, all the attributes need to be created/updated which take some reasonable time(4s-5s). I think the issue is after update the product, page would be redirected to /pim/products page. This is the page where we could do some optimization. In my dev, to load this page would cause 6s
  • another thing could be improved is edit/new product page loading time. Currently, without eager loading attributes, the page takes 7.5+s to load. With some eager load tweaks, the time could drop to 4.5s. The page load could be cut off 3s.