amadou/SecondBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-09-11 10:47:36

Browse Source
This commit is contained in:
amadou
2026-09-11 10:47:36 -04:00
parent 207da48c92
commit 1ea0f3eac2
3 changed files with 1468 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
meetmic/Daily Meeting TFO vs Zemind.md
+32
View File
@@ -0,0 +1,32 @@
**[0:00 - 0:00]** I try to get back to you with the position of maybe other questions, I don't know yet, but it's only to let you know that.
Okay. Good to see everybody.
I think we are all here.
Yeah, we've got Karina as well. I guess, do you want me to start?
Yeah, sure.
Cool. So I have a few notes. I guess the first one is data migration. We have our team doing another, the fix is in, we're doing another pass through to see if we make sure there isn't any problems. We are aiming to send you a build by end of day, as soon as our QA has finished going over it. There will be other fixes in this, but I don't think we'll consider this like a full UAT build. It'll just be for testing data migration, and you'll get the full build at end of day tomorrow with the full long list of both this build and the next build's changes, if that's okay with you.
So basically you'll get kind of like a work in progress for one bit of narrow testing, so they have a chance to test tomorrow, and then a bigger block with much more testing done from our side, which is essentially also going to be the release candidate by end of day tomorrow.
Cool. Okay, so on the items that we've been trading back and forth questions about, last activity fallback, one thing we can do that's pretty easy is if the network call to track fails going out of the app, we can, instead of waiting an hour until we try again, we can try again in a matter of like seconds. So essentially there'll be a retry system. That is something we can put in a matter of minutes. So I guess you'll be discussing this afterwards, but that would be a quick fallback.
The Firebase auth lockout, this is the idea of once somebody has logged in and migrated, we lock their Firebase auth account across the board. We were discussing that. This is a backend only change, so we could put this in even after we've submitted the apps because the apps don't need to change, so we've got a little bit more time on that particular item. Obviously we'd need it before go live. I would also mark that down as like, we're 95% sure we can pull this one off. Both Andrew and I did some research on it, but we have not dived in 100%, so we would consider this one a 95% certain. What we do have is we have the last, the migrated at timestamp, so we can use that when somebody logs in for the first time. We can check if that's happened within the last minute and show them a message that says, hey, you've just migrated to Bukili 3.0.1, please update all of your devices. That is something we can put in relatively quickly as well. And the last one was on Contentful. It looks like there is a version control system in the existing system. I'm not sure if the existing system actually works, so there's not really a way for us to test it, but it would be, again, relatively easy for us to add a new field and have the new apps respect a field that says basically if version less than 3.0.1, only show if less than 3.0.1.
I will note, however, we only have a day, well, a day and a half left, so we need decisions relatively quickly, and it will take one of our developers and one of our QAs the better part of the day to get all of these done, tested, and confirmed. So we might not be able to get to some other P3 or P4 bugs to get these in, but I do think we can get these accomplished if you decide to make that happen.
**[5:48 - 5:48]** I guess that covers my side of the four items that we were talking about. Emadu, did you have a question? Yeah, I just had a question. If the users log in and they get the message saying that they have to update the other devices, and it just so happened that the other devices is a school device that they can't update themselves, how would that work? That's my first question. Let's start with that first question first. So how that, what would happen there would depend on whether or not we're using the Firebase lockout system. If it is the lockout, then their account would not work on the unupdated device. If lockout isn't present, they could still use the device, but their progress wouldn't be synced. So it's either they're locked out or progress spots. One of those two. Okay. You also mentioned that we have a few decisions to make quickly. Could you, just for my sake, give me a list of all the decisions that we need to take so that after the meeting, the team and I can talk about it and just go through them, please. Yes, absolutely. The four items that we've been trading emails back and forth, but I will send that through. That's relatively straightforward. So I guess we only have one other thing from our side. We'd like to check with your team about the web build that you have up on preview. We just want to make sure that that's being pulled from the right source, that it's not a staging build, that it's actually production. So I guess that's something whoever would be responsible for that, if you'll stick around, we can chat that through. It should be pretty quick. I guess the last item on my list is not something that we need to discuss today, but is optional, which is once the apps are submitted, how we want to handle the actual go live afterwards. I don't think that's a decision we need to make today, but it is something that we should discuss. Probably won't take very long to decide, but let's pencil that in if you don't want to talk about it today. That's cool. Cool. I guess any questions from your side?
**[8:56 - 8:56]** Yes, Abdullah. Jacob, I just want to cycle back. So the Firebase app lockout will only lock the app when the user authenticates on Superbase for the first time? Yes, first time, with that approach, the first time they authenticate with Superbase when we do the migration, the last step in the migration flow would be to turn off the Firebase authentication. Okay, thank you. I just wanted to clarify. Okay. So we'd migrate them first, and we've been doing that already, and it takes two, three seconds for a migration with the accounts we have.
**[9:53 - 9:53]** I guess if you have no other questions, can we keep your tech people around for a couple minutes and we'll discuss web? And then I guess I'll send emails with the specific items to be discussed and give us a call one way or another by end of day so we can build them tomorrow. Yes, it's okay. What kind of expertise do you need for the next meeting? Well, we're handling the web app, the production web app. That's I guess AWS. Okay. Got it. Cool. Otherwise, I think we are good. Okay. Okay, thank you. Thank you. Have a good day. Thank you. Have a good day. Okay, so what is the question? This is just me being paranoid. Did we push a production build to you or did you upgrade the staging? I created. So you worked on the staging and I created another environment, production one. Okay. And I duplicate. What I could duplicate, I recreate the schema, I deploy the bookie, the Docker image. And that's it. And we talked at the beginning of the project, if you remember, there is a bucket, a delivery bucket, S3, with two repositories, staging and production. Yeah. And at one point, you were supposed to deliver a zip file on the production. Yes. And from my side, there will be automation and the automation will deploy the S4 files into the distribution, the preview distribution. Yeah. And once it's okay, validated or I don't know, it will be switched to production. This is the workflow I create from my side. So I guess. That sounds correct. And again, I think this is mostly just me being paranoid. We'll want to push a new production build soon so we can test reset the password. So we'll just make sure that is set. Yeah, it should work. So what will happen is as soon as you deploy the file, so I should just to make sure everything is the same thing. So in the delivery bucket, as soon as you put a zip file inside, I will deploy the file into the preview environment associated with the preview, the distribution, the same configuration as the staging, same function, everything should be the same. Okay. And on the other hand is the production one. I mean, of course, and it should work. Yeah, it sounds exactly right. We'll just make sure that we push to production before the end of day so that we can, I just want to check that box off and make sure that we've seen production build go live. Yeah. Okay. Thank you very much. Thank you for your patience and putting up with me being paranoid. No, no, because from the beginning, we would like to make sure that this environment is okay because I recreated from scratch. I could forget some stuff. I tried not, but we never know. So I will appreciate if you can deploy a zip file on the production to make sure that the workflow is working correctly and that the preview distribution is okay as well. Should we just try that immediately or like? It's up to you. It should work right now. Yeah, well, let's do that right after the meeting. And if there's no problem, we'll message you one way or another. I mean, I will monitor as well. So I will let others know if I deploy correctly or not. If I see it as an issue or not. I set up the pipeline to put the zip file there. I never actually tried it because we didn't have a good solution. So yeah, it works. It should work, but as it's a different repository. Well, then, Andrew, are you good to give that a spin? Yeah, I believe it's triggered when you deploy it, when you merge the main branch in our web request to Burner. Well, then I can do that right after this meeting. I'll send a message about the added items and then I'll push one to main and we'll see. I'll just check the pipeline to make sure it's configured that way, but I believe that's what it is. Okay, you confirm and I'll push. Cool. Thank you very much. We'll get this tested. Okay, perfect. Thank you. Thank you. I guess that's everything. So unless there's anything last items from you. Okay. Yes, absolutely. I just sent you an email on Jacob and Andrew. If you can please add me in the Firebase app distribution so that I can test it on right. Absolutely. In that case, certainly we'll have messages to go back and forth, but we'll talk tomorrow as well. Perfect. Thank you. Bye. Thank you. Thank you. Thank you. Bye.
**[16:49 - 16:49]** No čo už.
**[0:00 - 0:00]** try to get back to you with a position or maybe other questions. I don't know yet, but it's only to let you know that. Okay. Good to see everybody. I think we are all here. Yeah, we've got Karina as well. I guess, do you want me to start? Yeah, sure. Cool. So I have a few notes. I guess the first one is data migration. We have our team doing another, the fix is in. We're doing another pass through to make sure there isn't any problems. We are aiming to send you a build by end of day as soon as our QA has finished going over it. There will be other fixes in this, but I don't think we'll give, we won't consider this like a full UAT build. This will just be for testing data migration, and you'll get the full build end of day tomorrow with the full long list of both this build and the next build's changes, if that's okay with you. So basically, you'll get kind of like work in progress for one bit of narrow testing, so they have a chance to test tomorrow, and then a bigger block with much more testing done from our side, which is essentially also going to be the release candidate by end of day tomorrow. Cool. Okay, so on the items that we've been trading back and forth with questions about, last activity fallback, one thing we can do that's pretty easy is if the network call to track fails going out of the app, we can, instead of waiting an hour until we try again, we can try again in a matter of like seconds. So essentially, there will be a retry system. That is something we can put in in a matter of minutes. So I guess you'll be discussing this afterwards, but that would be a quick fallback. The Firebase auth lockout, so this is the idea of once somebody has logged in and migrated, we lock their Firebase auth account across the board. We were discussing that. This is a backend-only change, so we could put this in even after we've submitted the apps because the apps don't need to change, so we have a little bit more time on that particular item, but obviously we'd need it before go live. I would also mark that down as like we're 95% sure we can pull this one off. Both Andrew and I did some research on it, but we have not dived in 100%, so we would consider this one a 95% certain. What we do have is we have the migrated at timestamp, so we can use that when somebody logs in for the first time. We can check if that's happened in the last minute and show them a message that says, hey, you've just migrated to Bookili 3.0.1. Please update all of your devices. That is something we can put in relatively quickly as well. The last one was on Contentful. It looks like there is a version control system added in on the existing system. Oh, Amadou? You can finish. Oh, yeah. But I'm not sure if the existing system actually works, so there's not really a way for us to test it, but it would be, again, relatively easy for us to add a new field and have the new apps respect a field that says basically if version less than 3.0.1, only show if less than 3.0.1. I will note, however, we only have a day, well, a day and a half left, so we need decisions relatively quickly, and it will take one of our developers and one of our QAs the better part of the day to get all of these done, tested, and confirmed, so we might not be able to get to some other P3 or P4 bugs to get these in, but I do think we can get these accomplished if you decide to make that happen. I guess that covers my side of the four items that we were talking about. Amadou, did you have a question?
**[6:19 - 6:19]** So what would happen there would depend on whether or not we're using the Firebase auth lockout system. If it is the lockout, then their account would not work on the unupdated device. If lockout isn't present, they could still use the device, but their progress wouldn't be synced. So it's either they're locked out or progress not synced.
**[7:09 - 7:09]** Yes, absolutely. The four items that we've been trading emails back and forth about, I will send that through. That's relatively straightforward. I guess we only have one other thing from our side. We'd like to check with your team about the web build that you have up on preview. We just want to make sure that's being pulled from the right source, that it's not a staging build, that it's actually production. So I guess that's something, whoever would be responsible for that, if you'll stick around, we can chat that through. It should be pretty quick. I guess the only, I guess the last item on my list is not something that we need to discuss today, but is optional, which is once the apps are submitted, there's how we want to handle the actual go live afterwards. I don't think that's a decision we need to make today, but it is something that we should discuss. Probably won't take very long to decide, but let's pencil that in if you don't want to talk about it today.
**[8:45 - 8:45]** I guess any questions from your side?
**[9:48 - 9:48]** I guess if you have no other questions, can we keep your tech people around for a couple minutes? And we'll discuss web and then I guess we'll meet. I'll send the email through with the specific items to be discussed and give us a call one way or another by end of day so we can build them tomorrow. Yes, it's okay. What kind of expertise do you need for the next meeting? Whoever is handling the web app on your side, the production web app, that's I guess your AWS person. Okay, I'm staying. Cool. Otherwise, I think we are good. Okay. Thank you. Thank you. Have a good day. Thank you. Have a good day. Okay, so what is the question? This is just me being paranoid. Did we push a production build to you or did you upgrade a staging build? I create. So you worked on the staging for how long? And I create another environment, production one. Okay. And I duplicate what I could duplicate. I recreate the schema. I deploy the bookie Docker image. And that's it. And we talked at the beginning of the project. If you remember, there is a delivery bucket, S3, with two repository staging on production. Yeah. And at one point, you are supposed to deliver a zip file on the production. Yes. And from my side, there will be automation and the automation will deploy the extra files to the distribution, the preview distribution. Yeah. And once it's okay, validated or I don't know, it will be switched to production. This is a workflow I create from my side. So I guess. That sounds correct. And again, I think this is mostly just me being paranoid. We'll want to push a new production build soon so we can test reset password. So we'll just make sure that that's set. Yeah, it should work. So what will happen if as soon as you deploy a zip file, so I share my screen just to make sure we're talking the same thing. So on the delivery bucket, as soon as you put a zip file inside, I will deploy the file to the preview environment associated with the preview environment. There is a distribution cloud front, same configuration, same function, everything should be the same. Okay. On the back end is a production one. I mean, of course, and it should be okay. It sounds exactly right. We'll just make sure that we push to production before the end of day so that we can, I just want to check that box off and make sure that we've seen production build go live. Yeah. Thank you very much. Thank you for your patience and putting up with me being paranoid. No, no, but because from the beginning, we would like to make sure that this environment is okay because I recreate it from scratch. I could forget some stuff. I tried not, but we never know. So I will appreciate if you can deploy a zip file on the production to make sure that my workflow is working correctly and that the preview distribution is okay as well. Should we just try that like immediately or like later? It's up to you. It should work right now. Yeah, let's do that right after the meeting and if there's no problem, we'll message you one way or another. I will monitor as well. So I will let Andrew know. I mean, it deployed correctly or not. If I see an issue or not. Yeah, I set up the pipeline to put the zip file there. I never actually tried it because we didn't have a production build. So yeah, it works. It should work, but as it's a different repository. Yeah. Well then, Andrew, are you good to give that a spin? Yeah, I believe it's triggered when you deploy, when you merge to main branch in our web repository. Well then, I can do that right after this meeting. I'll send the messages about the added items and then I'll push them to main and we'll see. Well, I'll just take a look at the pipeline to make sure it's configured that way, but I believe that's what I did. Okay, you confirm, then I'll push. Cool, thank you very much. We'll get this tested. Okay, perfect. Thank you. Thank you. I guess that's everything, so unless there's any last items from you. Oh, yes, Abdullah? I mean, it's not maybe related. I just sent you an email, Jacob and Andrew, which is an Android email. If you can please add me in the Firebase app distribution so that I can test on Android. Next build. Yes, absolutely. In that case, I'm certain we'll have messages go back and forth, but we'll talk tomorrow as well. Perfect. Thank you, Jacob. Bye-bye. Thank you, Andrew. Bye. Thank you.
**[8:51 - 8:51]** Yes, Abdullah. Thank you, Jacob. I just want to circle back. So the Firebase app lookouts will only, I mean, you will only log the app when the user authenticates on Superbase for the first time? Yes, first time with that approach, the first time they authenticate with Superbase when we do the migration, the last step in the migration flow would be to turn off the Firebase authentication. Okay, thank you. I just wanted to clarify that. Okay. Yep. So we migrate them first, and we've been doing that already, and it takes two, three seconds for migration right at the moment with the accounts we have.
**[16:58 - 16:58]** Wat galt raschpar?