benjaminramey/ObsidianJournal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2024-08-14 10:36:36

Browse Source
This commit is contained in:
Benjamin Ramey
2024-08-14 10:36:36 -05:00
parent 44656afd24
commit aa98e33d5f
165 changed files with 51 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
Work/Daily Log/2024-08-13 (Tuesday).md
View File

@@ -0,0 +1,9 @@
Update Celigo flow to create/update address from Logos to BigCommerce with a lot of error checking and additional validation against [BC's geography API]([Geography | BigCommerce Dev Center](https://developer.bigcommerce.com/docs/rest-management/geography)) to make sure the Logos address' country and state are present in BC's data sets too.
## Kyle 1:1
Talked about Kyle's desire to start migrating BusinessDesk to React and getting lots of pushback from Bradley Grainger. He's very emotionally mature and, while frustrated, understands that there may be more things at play (like burns from past react projects) that Bradley is reacting to.
## Hugo 1:1
Justin has agreed to be the new tech lead for the BEN team. Hugo will do 1:1s and project management, which Justin does not enjoy at all. I'm glad for this and surprised. I think it will be a good chance for Justin to grow.
Ricardo wants me to manage the "platform readiness" for launch. Ugh. Nate Merritt did this before and I have no experience doing it. I guess there's a first time for everything.

0
Work/Daily Log/2024-08-14 (Wednesday).md Normal file
View File

17
Work/New Platform Alerting.md Normal file
View File

@@ -0,0 +1,17 @@
With the replatform work, we have several new systems for which the Business Solutions Group on-call rotation will need to eventually be responsible.
## New Systems with Alerting Needs
Alerting should probably happen for:
1. The new.logos.com site hosted by Vercel
2. Celigo data flows when integration fails
3. BigCommerce order and payment processing failures
## Ideas
Nate suggested a couple of things I agree with.
### Only low-priority at first
Only low-priority alerting at first for all replatforming things. Justification: the initial rollout will be pretty minimal and won't serve a lot of customers or orders. It shouldn't alert anyone off-hours to fix anything.
### Separate on-call rotation at first
Have a separate on-call rotation for only replatforming things at first. They can:
1. Refine alerting before we turn on any high-priority alerts
2. Train the rest of the rotation before we merge the two rotations on replatform things