Transcription
Okay, let's go. Ah, so, in literally 3 minutes, what are we doing here? Ah, I'll very quickly tell you about our training course. If you are at this meeting, you generally already understand everything. Ah, so we'll look at a couple of user stories, if they are available. We'll look at the architecture, we'll look at the first project, and we'll answer any of your questions. Ah, if there are still so few people, ah, 20 people are currently at the meeting, then, ah, well, like, your questions, uh, we can consider them in quite detail. Ah, so, this training course is for those who are interested in real learning, not reading books, but in real learning. Ah, what is business analysis? What is system analysis? What is the application of AI in real products? Not just, ah, well, some fashionable word, but you will actually apply it. What will you get if you actually complete this course? Ah, you will gain skills in business analysis, in system analysis. You will work, I hope you have all done this already, with the latest tools, yes, with the help of generative artificial intelligence. Ah, and ah, when you need to, ah, for your own goals, for yourself, I don't know, for an employer, to show what you have already done, you will have a concrete solution that you made with your own hands. Ah, on this course, we only have practice, right? Ah, all the theory ends with video recordings of your lectures. Ah, the result should be requirements and an agent prototype, right? Ah, the requirements will consist of these points. All questions that arise for you, I hope you already know where to ask them. Ah, you need to ask these questions first to your PM, then to the curator, and then at these meetings, right? And a small teaser. Ah, so, you all know, ah, that we are directly involved now in an open-source project, ah, which allows an analyst or architect to work with generative AI, and ah, we are ready to accept you there for, ah, this open-source project on a gratuitous basis. Ah, if you can already do this, ah, what is written here, if you are not sure, but you really want to, ah, then you can try your hand as follows. Take and make, ah, a landing page. Well, now, to make a landing page, you don't need any competencies. Ah, if you are at school 21, you definitely already have them. Ah, you can try to take on bugs that appear for us and solve them. Ah, well, if it works out, great, if not, no big deal. Ah, and you can help us, ah, with marketing, ah, for example, ah, write some posts, ah, about the product or make videos about the product. Ah, if you have basic knowledge of content production tools and are interested in trying, please let us know. Ah, you can write to me, you can write to Olya. Well, you can also write via QR code. At the current moment, ah, the introductory part is completed. We are ready to look at your artifacts and answer any questions. Let's go. Please ask your questions, raise your hands, write in the chat more boldly.
Okay, Karina, ah, good day. Ah, a question on the topic of architecture. How deeply should a system analyst understand issues of protocols, issues of protocols and network interactions? Since I don't yet have a proper understanding, why in the architecture between the frontend, backend, db, lm blocks do we specify these particular protocols, and is it related to the OSI model?
Okay, I'll answer now. Karina, raise your hand, let's discuss this topic by voice. And please, guys, ask new questions in the chat. Get ready. Ah, Karina. Uh-huh. >> Hello everyone. Hello. >> Hello. >> Hello. Tell me, what is actually bothering you? >> What bothers me is that there is no understanding of why these protocols, and, well, I probably wouldn't have guessed myself that they need to be specified. >> Well, yes, logically. Ah, yes. >> Okay. Are you ready to demonstrate your architecture now? >> I'll answer in more detail. Demonstrate. >> Okay, I haven't done this yet. Literally. >> Let's go. I think you should. I'll make you a co-organizer now, and you'll have all the rights. Exactly. So, it should be visible. >> Everything is visible. Well, tell us. Ah, so, what are you actually interested in? >> Understanding the connections between the blocks. >> Okay. The question is quite broad. Ah, like, how much does an analyst, a system analyst, correctly? >> Yes? >> Ah, need to know, what do you need to know? >> Right now, I think knowledge of protocols, probably. Ah, so, everything else, I'm asking the question this way specifically to understand what actually interests you. So, everything else besides protocols, is it generally clear to you? >> Well, not really. Probably, you need to understand how the blocks themselves work to understand why these protocols are between them. Ah, so, it's unclear why these system components and these protocols were chosen? Correct? >> Yes. >> Excellent question. Ah, so, I'll go from another side now. Ah, well, it's a broad, very broad question. Ah, so, you are designing a system, you are an analyst, right? You are designing a system. How do you expect this system to work when you design it? >> M, uninterruptedly, with minimal. >> That's all for the good against all for the bad. Ah, so, from a technical point of view, if we now go into the role of a system analyst, how should it work? >> Well, look, so, basic questions, right? For a system analyst, it's mandatory to know. So, basic questions. Where should your data be stored? >> M, in a database. >> Why? >> Well, so, so, we are now coming to the point that you know about the concept of a database. Correct? >> Yes. >> Good. Okay. So, we've come to the point that an analyst must know that a database exists. That's 100% they must know that. Now you have component C. Why did you draw it here? We have an internal system. >> Why is it there? For processing information, well, for all good against all bad. >> If, look, so, I'm telling you, future business system analysts, if you want to answer something to say nothing, talk about information, about data, ah, and about abstract processing. Ah, then you will be absolutely right, while saying nothing substantial. What is component C for? >> For communication with the external part, well, with the interface display and with the database. >> Can it be without communication? In any unclear situation, you, as system analysts, should design your system as simply as possible. There is such a principle in software development. It's called Kiss. You can Google it. Ah, keep it simple stupid. Ah, and so, look, if you can remove a component from your system, without sacrificing anything important, you should do it. You have component C here. Why are you drawing it? Well, because it is necessary for the system to work. >> It's hard to argue why. Should an analyst know this? Yes, definitely. An analyst should know this. Why do you have component C? Well, for processing requests. >> What kind? >> Mmm, that come from the user. Well, so, we are now in a live broadcast, from the user, on which component? Frontend. >> Where? >> In the frontend. >> Where? >> In component A. >> In component A. So, we come to the point that your components A and C are not connected. Well, that is, the architecture is invalid, right? No, they are connected, through another component. >> Okay. So, where does the request come from? Telegram servers. >> Ah, okay. Ah, well, look, so, you are here on this training course to learn, ah, you copy-pasted this diagram without understanding it. Well, the question is why, right? Now, how much does a system analyst need to know about these components, not yet about interaction protocols? Very much, you are designing your system. >> Do you need to write specifications? Specifications are, for example, descriptions of algorithms of operation. Do you need to write? >> M, yes. >> What will you write the description on? I don't quite understand the question. Well, okay, please. Ah, so, let's imagine a standard three-tier architecture. It's frontend, backend, database, right? >> Yes. >> It's a standard three-tier architecture. As an analyst, do you have to write a task statement for the web? >> Yes. >> Where does the web go? >> M, backend. Why? >> Okay. So, you have to divide the logic between the frontend and the backend, right? >> Yes. How will you do that if you don't know what the system consists of? >> Okay. And you also have the database, right? In a standard three-tier architecture, right? >> Yes. How will you distribute the responsibility between these two components? Well, that is, what happens in the backend, and what happens in the database? >> Well, processing happens in the backend, and data is stored in the database. >> Well, it's not quite that simple, is it? From the database. What queries do you send to the database? Well, chat history, user data. >> Okay. And if everything is correct, and if it's a bit closer to the ground, what do you use to interact with the database? Well, with the program PostgreSQL. M, >> well, not Postgres. Postgres is a database engine, >> right? Well, that is, ah, Postgres provides the operation, ah, of working with data. And you interact with the database in general, well, if we simplify, using SQL queries, right? >> Yes. >> What does an SQL query do? >> Mmm. Mmm, it shows the data that is requested. >> It doesn't show. Well, "shows" is a bad definition, >> it retrieves data. >> Retrieves. What parameters are included in an SQL query? >> Ah-ah, >> approximately, >> well, first we specify the column, the table itself from which we take the data, well, and sorting, and if necessary. >> Everything is correct. So, you are saying in this way that you are not just taking all the data from the BD in one query, which stores the data. Your BD, the database engine, also selects the data you need according to a certain algorithm, sorts it, and returns it. Correct? >> Yes. Well, in this way, ah, we have now come to the point that your component C performs some logic, and your component D performs some logic, at least selecting the necessary rows, columns, sorting. Correct? >> Well, yes, >> well, yes, definitely correct. And we started with how you will write the task statement in this case for the backend developer, and if necessary, for the database developer, and so on, right? Ah, if you don't understand what is executed on which component, then you can't. The answer is no. Ah, so, you absolutely need to know what your system consists of. And now look, ah, so, you, as an analyst, at least 100%, you will definitely participate in the analysis, ah, of what went wrong. Do you agree with me? >> Yes. >> If something, if your client comes to component A, right? Uh-huh. >> Yes. >> The client, you interact, the client is an individual. Ah, with which component do you interact? >> Well, with the interface. >> Uh-huh. How? Everything is correct. Which component? >> Frontend. >> Frontend. Absolutely correct. On which components can your system break? >> Well, I think, at the beginning. Well, on any. >> Absolutely correct. Absolutely correct. And here, a client comes to you and says: "The function doesn't work, it doesn't work." What will you do in this situation? M, well, you need to understand at what stage, well, what specific function, at what stage for the client, no, for the client there is no >> function from programming, for the client there are business functions. He says: "I can't check my balance in my Sberbank online." Balance inquiry. Okay. Ah, what will you do? Well, you need to understand, like, at what level the error is, on the backend or on the frontend, >> or on the database, >> well, yes, >> or on some integration interactions. And as soon as you have to figure out what went wrong, you will sharply have to delve into what is happening on each component, do you understand? >> Yes. So, in this way, ah, we have now agreed that you need to understand how the logic is divided between the components in this case A, D, and, well, actually, what happens on each. And now the question. Is something not working on your component A? And something broke on component C, or maybe the request from component A is not sent to component C? How to understand? >> Is the question clear? >> Uh-huh. Yes. >> Well, that is, did C break, or did the connection between A and C break? And here, you know, we come to the point that you, at least at a high level, need to understand how connections between components are executed. For example, between components A and C in our imaginary three-tier architecture, you have network interaction. Agree? >> Yes. For what reason can network interaction break? >> Well, hacking, possibly, or incorrectly written >> hacking of what? >> M, the server. >> Then the interaction between A and C works. Agree? Let's, let's do it live. Ah, and you have this picture? >> Well, this, well, yes, in Draw.io. >> No, if it's in Draw.io, oh, it's not a picture. Delete component B. Ah, and now just connect A and C. Ah, with arrow one. Let's go. Ah, for us, from a business perspective, the interaction between A and C doesn't work, right? Ah, what can break? Point with your finger. >> M, frontend, on the frontend, on the backend, on the database, what? No, incorrectly. Incorrectly. We haven't gotten to that yet. We've gotten to the point that we have, ah, something happened between component A and C. Let's stop here for now, okay? >> Uh-huh. >> What did you say correctly? Something can happen on the frontend, something can happen on the backend. Delete D and E, please, so they don't distract us. That's all. The current state of our system is like this. Ah, something can break on component A, something can break on component C. Where else? >> Mmm, well, something with the connection. Well, yes, >> it can break. >> Well, yes, that's right, that's right. And here we come to the point that, ah, you need to understand the logic of A's operation, the logic of C's operation, and at least the high-level logic of arrow one's operation, at least the high-level, do you understand? >> Here's a specific example. Are you using ChatGPT now? >> Yes. >> To use ChatGPT, you need to enable something. What? Network. >> And if you don't enable it, what will happen? >> There will be an error on the page, maybe with the IP address. >> I don't remember exactly. >> Well, it's not that important. What is the essence of the error? >> The page doesn't open. >> Why? >> Mmm. Due to geolocation. Why does it read geolocation? No, >> no. Look, from a business perspective, ah, from the perspective of how it works, ah, from the user's perspective, you are absolutely right, what happens at the technical level? >> Well, an error, well, or a ban. >> An error is a logical entity. From our perspective as users, something is going wrong. What happens from the system's perspective? From the system's perspective, a hint, everything works as planned. What is happening? Guys, any options? Raise your hands, write in the chat. Nikolai writes in the chat: "Server refuses connection to certain IP addresses." Lily writes: "The client's request is checked and something is wrong with it." Rudolf returns an error code 400, approximately, and says the IP address is not liked. So, it's difficult to answer such questions for beginners without theory. It will have to be answered. >> Whoever unmuted, please mute. Yes, already done, without feeling it normally. >> Ah, so. Ah, so, look, it's easy for you in a live broadcast, ah, being, ah, system analysts, it can be very easy to get, ah, such a task for, like, creating documentation. We want that from certain addresses, ah, we don't want IP addresses to work, and you, ah, need to know this. Ah, so. Ah, yes, each of you has written some option in the chat, and each of you, ah, well, five people, ah, each of you has written, ah, an option at the logical level. You wrote that the request block, ah, refuses connection, the client's request is checked and something is wrong. You are absolutely right. However, this will not help you write valid documentation for a developer at all. Not at all. What is needed? Look, what do we need to do on this diagram to ensure that requests from the Russian Federation do not reach component C? What do we need to do from a system perspective? Raise your hands, speak out loud. Maybe IP addresses are specified somewhere in the backend, for which there should be a ban. >> Well, yes, yes. Ah, so, take a dashed line now from the panel on the left. Uh-huh. >> And place it vertically on interaction one. Ah, >> it's lagging a bit now. >> Ah, yes, yes. Delete this background thing. Delete it, it's bothering you. >> Uh-huh. Okay. >> Ah, yes. Ah, let's, look, so, this is a very good lecture, right? I generally like architecture lectures because they very quickly bring you down, ah, to real life. Ah, so, Lily writes: "IP address check." Natalia, process all incoming requests, filter by necessary ones. Name 123, ah, enable the firewall on the server. But perhaps only 123 wrote what to do from a technical perspective, because checking the IP address and processing all incoming requests is again a business statement. What to do from a technical perspective? And now, ah, so, you 123, you can even rename yourself, I'll address you. I've allowed it. Ah, well, let's raise your hand, ah, and say your name. >> Ah, okay, okay, we've agreed. Ah, I ran away, while >> you can say 123. I can't. Okay. Ah, good. Ah, well, look, we're saying that along this dashed line, we need to break the interaction somehow from certain, importantly, yes, not from all, but from certain clients. If you don't know in principle that such an interaction exists, how can you break it? Not at all. I hope I've answered the question sufficiently thoroughly, whether an analyst needs to know about components and interaction protocols at a high level of abstraction. The answer is definitely yes, at least to understand which component is experiencing what. And, ah, well, like, our component broke, or the interaction broke. I hope the answer was exhaustive. I think Karina already regretted asking this question, right? Question. No, >> no, everything is great, thank you. >> You're welcome, was I able to convince you? >> Yes, 100%. >> Okay. And the last comment on this topic. Ask the next questions. The OSI model. Ah, the OSI model is a theoretical concept. Ah, where did you get this abbreviation from in general? >> M, well, I asked acquaintances if anyone understands network protocols, and they suggested this model. >> That's not a bad way to start Googling. Ah, so, it is indeed the most famous theoretical concept, ah, for network interaction. The OSI model. There's one problem with it. It doesn't work that way in real life. That is, in real life, you don't have seven layers as in the OSI model, but four. Ah, this is generally, when you come back in 4 years and say: "I don't fully understand the OSI model." After 4 years of work, it's not your problem, in general, but the OSI model's problem. Understood? >> Yes. >> Okay. Let's have another question. Uh-huh. Ah, Rudolf, let's raise your hand and ask by voice. Is it possible? Okay. No. Let's go. >> Hello. My question is, the agent goes to an API, to an external system. That is, I don't have a specific database. I go to an external system, get JSON, and process it. How, in this case, as a system analyst, should I describe the data model? >> Okay, understood. Can you demonstrate the architecture? >> Yes, now >> let's go >> I'll open it. I sent the question. >> Visible, >> unfortunately. Yes. Okay. Let's >> Yes, good. Let's go. Ah, first of all, look, the first difficulty, you need feedback on the architecture. I will now refer to the components and arrows, and they are not numbered, neither the components nor the arrows. >> Ah, well, please make it like it was, A one, right, and so on. Ah, >> let's now ask the question according to this architecture. Ah, look, I have >> please, with an arrow. Uh-huh, >> do you see the arrow, >> yes? >> Here, this is a request, like, from the AI agent, from the N8N platform, respectively, there is an AI agent, right? >> to White Client. From there I get JSON, respectively, then I get it with the AI agent. And the agent sends it >> okay >> here to the LLM. The LLM processes it, gives me some answer, it goes here and goes back to my bot and to the person. >> Okay. Everything is great, the logic of operation, everything is correct. What is the question? >> The question is, ah, the current homework is to create a data model, >> yes? How do I, regarding the database? I understand that I need to describe, for example, if I had a client database and other data, I would have a client entity with such attributes, an entity called this, with such attributes, and here I get JSON. So, in my case, I need to do the same, but describe in the data model only those fields that I need, that I process with the AI agent, but based on JSON, not a database. >> So, it turns out. >> Okay, normal. Good question. A sufficiently specific good question. Ah, do you have data in the system? >> I don't store it. Agreed. You don't store it permanently? >> Yes, I process it, and that's it, it's gone. >> Ah, I agree with you. Excellent. Ah, and where does your data live in general, when you work in your system? >> Well, it's stored in caches, respectively, until, >> well, a temporary storage. >> What is that? How, how to explain? >> Well, as I understand it, what is a cache? It's when, for example, we something we some, well, not a cache, a temporary storage, right, yes, let's call it that, which >> well, let's call it. What is temporary storage? >> It's where we, ah, add some data until it's requested. As soon as it's requested, it can be deleted from there. Well, depending on the system settings. >> Everything is clear. Everything is clear. Where? >> On the server in N8N. In this engine. >> What is that? How does it work on the server? You're answering your own question now, just. How >> how does it work? >> Yes. Yes. How do you, how? Well, look, you have a client API. >> Uh-huh. And you have a server component, right? >> Yes. >> Does your server work with data? >> Yes. >> So, it has them, >> yes? Because it received them. >> Okay. Where does it work with them? >> So, let me go over the logic again, and maybe I'll come to the answer myself. >> Let's go. My AI agent sends a request to the client, receives JSON, takes it, stores it, sends it to ChatGPT. ChatGPT, based on the prompt, does everything the user asked, >> and returns it to Telegram. The processed response. >> Everything is clear. >> So, my agent stores this information during the request. Where? >> While in itself. >> To whom? >> Well, and look, these questions are not just to, like, mock you, but to show you where the gaps are. Ah, so, we just talked about it, you do have data? Short answer, >> yes? >> Can you create a data model? >> I can create a data model, yes, based on JSON. What's the question? Well, actually, we started with the fact that I understand that people who have a database have certain entities. Yes. >> Yes. >> Entities in the database. Ah, but you don't have a relational database, but you do have entities, >> yes, that I am referring to? >> You have entities, yes, >> regardless of the format. >> Well, yes, yes. Okay. >> You have entities. >> Can you describe these entities? Describe entities. You mean, like, this entity is a client, this entity is this. So, >> attribute composition. If you lecture, >> ah, so, if you haven't watched the lecture, you've been talked to. >> I watched, I'm watching. >> I'm not, I'm saying for others. If you haven't watched the lecture, talking to you now, well, like, unfortunately, there's nothing to talk about, right? Ah, so, attribute composition, can you describe it? >> Yes? >> Everything. Any other questions?
In the given, well, since I choose the data that I will process, which to take from JSON, do I need to describe the attribute composition only of those attributes that I work with, or of the entire JSON. >> Good question. And what do you think? >> I think only those that I work with, because the rest is superfluous. >> I generally agree with you. Uh, if suddenly you have a kilometer-long JSON, well, it has 1,000 attributes, and you work with three attributes, then describing it is probably pointless. >> Well, approximately such, yes, such a ratio. >> Well, yes, yes. That is, if, yes, here's a fork, possibly, if we assumed in the system that your system is planned to be actively refined and your successors will need to work with eight out of, there, I don't know, out of the available ten attributes, and you described only three, >> well, it would probably be correct from the point of view of your interaction with your colleagues to describe everything. If our system is not like that, then yes, it is enough to describe only those, uh, attributes that you work with. Well, entities, attributes. >> Uh-huh. Everything, I understood. >> Well, a good question, yes? Uh, Asia, do you want to comment on your remark verbally? >> Regarding RAM. >> Uh-huh. Well, in N8N, as far as I know, there is a data transfer stream. That is, they come into a node, are transferred to the next node. This is >> a node. What is >> a node? A node is some kind of unit that performs some functionality. >> Okay. So, well, look, we saw the architecture on the screen together, we haven't forgotten it yet. In RAM of what? The server >> N8N, yes, in this case. >> Well, yes, >> well, okay, everything is correct. >> In RAM, after the server shuts down, uh, these data will not be saved. After the client's request to Rudolf is processed, these data will not be saved because they are no longer needed for anything, and the server will clear them from its RAM. Yes. Yes, that's right. >> Yes. >> Can I ask another question? >> Who can forbid you? >> Regarding vector databases and relational ones. If I have them implemented in PostgreSQL, can I specify them as one component? >> Yes, yes, yes. And a good question, uh-huh, and a good solution not to use two different databases, but to use one PostgreSQL. Uh, so, uh, just specify the functions in PostgreSQL that you have there, uh, and, uh, persistent storage of relational entities. Then review the recording if it's unclear. And work with the vector storage. >> Uh-huh. Thank you. >> Uh-huh. Uh, Marina, the floor is yours. Let's go. Show your solution. >> Hello everyone. I'll turn on screen sharing now. So, is it visible? Yes, yes. >> Uh-huh. So, here is the bot itself, a preview. >> The picture is optional for now. It's all >> normal. A good picture. Can we start it from the very beginning or not? Yes. Yes. Here in the right corner is the start button. It's a little different on a laptop. On a phone, everything is standard. Below is the greeting, and the bot asks to choose a goal. Here three clickable buttons open: gain mass, lose weight, maintain shape. Well, let's say, lose weight. Uh, choose gender. I would like to do all this with buttons in the future, so that a person doesn't type text. But for now, we'll do it with text. >> Well, let's, wait, wait, type. Cat. Uh >> so, it goes further, >> despite everything. >> So, >> 500. >> Uh-huh. 500. Uh, 400. We want to lose weight. Uh, no. I don't know. Let's say eight. Beginner. Let's read. >> I've already seen something about paws here. >> So, >> well, it's funny, but I did it. >> Possibly, possibly, this is a feature. We'll figure it out now. >> My temperature is still at maximum. So, it's really creative. >> Okay. Okay. >> Make sure your veterinary clinic. Well, yes, that's a good conclusion. So, uh, so, walking in place, lifting a cat. Interesting. Uh, the cat exercise. Very logical. Very logical. Uh, smooth movement of paws in a circle. Well, I like it very much. Uh, possibly, this is what products are about. >> Got creative. So, got creative. It's interesting, if you change the temperature, it will probably, I think, answer more strictly. I would try >> question. No, temperature is probably the last, um, line of defense that you should work with. >> And the question is, how should your product behave in such a case? >> Generally, I'm thinking of writing down some specifics. Honestly, I don't know how to decipher R correctly. That's exactly what I want to write down the limitations, what requests it should process, what it should strictly not answer, that it's an error, rewrite your request. >> Because now it's quite a creative agent I'm getting. Generally, in the future, I would like it to respond to such requests with something like, "You entered incorrect data," or "I see you are not human." Something like that. I'll have to write all this down, add it so that it responds clearly specifically to training, because further >> what >> it goes, >> what do you want from your product? Is my business case valid or not? It's unclear. My current input, should your product work with my request or not? Well, in theory, I haven't written it yet. It only works with people. Well, you need to decide. What I entered now, is it a bug >> or a feature? And if, собственно, it's a bug, well, you really need to validate the input at each stage, right? >> Okay. >> Uh, so, somehow, if the input that the user entered, or a combination of inputs, for example, I don't know, my weight is 30 kg, and my height is 220 cm, right, that's already a combination. >> Uh-huh. And if it's not valid, your system should somehow process it and show it to Balzac, if you want to, you know, limit this solution. And if it's currently a feature, well, okay, from the point of view of user experience, I would probably think about it. >> I would think about it. That is, it's not a directive, in short, an indication, but about how to give the user one. You are now working with an LLM, it will parse one Balzac response into the necessary components, weight, height, and so on, right? How to give the user the opportunity to answer with a single input so as not to bother them too much. Understood? >> Uh, yes. I understood. Initially, >> I did it precisely so that the user would enter all their physical data in a single message. >> But the LLM didn't quite process it correctly. Well. But I think this is more, of course, my underdevelopment, an error. >> Can we look at the architecture? >> No, I will redo the architecture, because in the process of writing the bot, I realized that I made the template incorrectly. Everything will work a little differently for me. >> It's right that it was done incorrectly. >> I also initially wrote that I would have a server. That is, my architecture consisted of four components. >> Uh-huh. But I came to the conclusion that I will have a second component - Telegram Cloud, because everything runs in one process. Exactly, the frontend user, right, makes a request. Then I have Telegram Cloud, all these processes are processed there together, >> which go into the LLM request. >> What is Telegram Cloud? A function. What function? Well, I deployed my bot in Yandex Cloud and all requests go there. >> Yandex or Telegram? >> Uh, Yandex Cloud. >> Uh-huh. Okay. >> Well, it turns out they synchronize with Telegram, >> process the request and send it to the LLM, and it then gives it to the user. >> If >> if >> and I will also change the database. There is one in Yandex too. >> If you showed the architecture now, I would show you exactly >> what questions you need to answer, right? >> Uh-huh. >> Uh, well, like when you're refining, developing your solution. And to others, we would simply show explicitly how it works. There is definitely no possibility to demonstrate. >> So, I'll check now. I probably still have this file. Well, I'm more careful, you're broadcasting all this to us. >> Uh, yes, I don't have anything like that. >> So. Uh-huh. I'm not sure if I, uh, have these files saved in the history in Drive. Uh-huh. So, and not here either. I'll try to open it in Drive. Well, >> let's, let's. >> Uh, so, and can you extract the history of files made here? >> No. >> No. Yes. >> No. Yes. >> Honestly, I don't remember where I put it. I'll try here again. Ah, here it is, architecture 2. So, which one was the last one? Probably this one. Yes. >> Okay. Uh, so, look, tell me how it works. This is more for your colleagues, not for me. Uh, so, how does your system work? Uh, so now the frontend. Okay, good, everything is clear. I answer the question, what is my height, what is my weight, and so on. Where are the answers processed and where are they stored? Point with your finger. Unclear question. Uh >> bot first, look, this is already a deep story. You will have to make a sequence diagram. This will greatly help for the sequence diagram. >> First, when I open my phone, launch your bot, what happens >> on this architecture? What happens? Uh, well, the welcome interface opens here. Uh, the first opening. Okay. First. >> I don't have your bot. >> Then possibly the user. >> Uh, yes. >> Start starting the interaction. >> And where will these questions about height, weight arise for me? After all, I don't have your bot on my phone in Telegram. >> Unclear question. >> Uh, I'll try to explain now. Uh, I have, uh, how is the integration with users happening now? It identifies a specific Telegram account by its ID and writes it to the corresponding database. So, no, I'm saying it wrong. It writes to the corresponding file, >> in which it collects all the information >> file where >> about the user. Uh, well, I have a structure, I can show it. >> No, no need. >> Where specifically is it collected? >> Here, everything we need to discuss is in front of us, >> where does the information go for Balzac? >> Uh, here >> no. So, then, probably, I don't quite understand the architecture yet. Something is clear, something is still unclear. >> If, if I, look, I close your bot, right? >> And it recommended workouts to me, I log in a second time, does it already know something about me or not? >> Yes, it knows. If you haven't reset your data with the start button, >> after the dialogue, you can either continue in live conversation mode, for example, write to it: "Write me a menu, write me there, limit the time, limit the time." >> Uh, let me ask questions. Uh, does it know something about me? Where? >> This is all saved in a separate file. >> Which one? Uh, well, I have my own name for it, for example, data user ID, some kind of >> and >> and files are still in git, this is the architecture with the folder >> data users. Let's go again. It remembers that my weight is 80 kg. >> Yes. >> Where is this information stored? Where exactly in my project or at the network level, how at the level of the running system. Where is this information stored? >> You have everything in front of you now. Where is it stored? >> Here. >> No. Well, okay, I understood. Uh >> so then no. Then, well, in theory, it will upload all this to the database. I >> just Yes, in theory, definitely, yes. Definitely, yes. But there's a nuance. If you wrote it and it somehow already works, then I have a question: how can you not know? Well, yes. Uh, like you had to write some kind of SQL call yourself, which will save my weight in the database, right? >> Uh, well, that's right. I have a constructor for this, yes, written in my code, which collects all this data into one file, but for now, all this is uploaded to the project on git. >> Consequently, when there are many users, it makes sense for this not to work like this. It just can't work like this. Git stores artifacts that are not live. Not live. It stores the text of your code. >> Uh-huh. And when we work with, well, I don't know, with a bot that interacts with us live, it cannot be stored in git, you understand? Well, that is, it runs on some server. Well, that is, it's obvious that it's a TG server. If you save data about me somewhere, well, you don't have many places. You can do it with certain workarounds on your backend. With certain workarounds, you can. Or you can do it in PostgreSQL. In short, the product is interesting, uh, but now you've done some magic for yourself, you don't know how it works. Well, that is, the main task of this training course is for you to understand step by step where everything is happening. Understood? >> Yes, I think I understood why I messed up with the database, because initially, before I uploaded it to the cloud, it worked when it was running on my computer locally, respectively. And apparently, while the people I asked to test it, all this data was saved on my git. And now all this is being implemented in Yandex Cloud, and everything goes there. >> No, no. You continue to operate with magical concepts. Yandex Cloud. Yandex Cloud is your hoster, understood? Uh-huh. >> And it provides you with some infrastructure. How to operate with this infrastructure, with databases, with running services, and so on, you must understand. You don't understand now. >> Go and figure it out. Uh, Natalia, let's ask a question and we'll finish. Did I understand correctly? You said that the user should enter data preferably in one line. If at this stage the user enters data in several requests, >> it's a matter of taste. I would be pleased as a user, >> if, for example, I could use voice input with an iPhone, not with your system, but with an iPhone, the iPhone allows me to speak and recognizes everything. Or with a single line of text, >> enter everything they want from me. This is my subjective opinion, Balzac. >> Okay. >> Well, just Yes, I understood. I just made many options to avoid errors on the part of the user, because they can write anything. >> Well, as in this case with errors, >> as we saw now, right? >> Well, yes, if we're talking, I'm talking specifically about grammatical or other errors. Well >> grammatical or other errors, your LLM works with them perfectly. >> Well, yes, >> okay, thank you. >> Uh-huh. So. Let's have the last question from Nikolai. What stack are we using? For the web, for the web interface. I have a web application. >> What does "what stack" mean? Well, verbally, please, or write in the chat, what programming language. Nikolai, uh, I want you to interact with each other within the framework of the training project and with me as technical specialists. Well, programming language, what do you mean by that? Well, let's look at the screen now. Uh, here's what programming language. I see some set of entities. You say programming language, stack. What programming language? Nikolai, I >> Uh, yes, yes, what? Uh, well, it's like a question. Uh, well, we have a training course here and it was assumed, yes, it was assumed. I, I, Okay, I need to google, I will google. Uh, just my experience >> Nikolai. >> No, but Marina, please return the architecture. Uh, look, >> so, now Marina will return the architecture. >> So, just a second. It went somewhere else. Uh, I wanted to say, I won't have Telegram, I want a web, well, in a browser. >> Uh-huh. And I have programming experience in C++, creating desktop interfaces, well, desktop applications, not web, just a couple of comments will be enough. I will be grateful. >> Uh, yes, with pleasure. Only why do you think my questions are, uh, right now, when I don't let you finish, you think my questions are to make your life difficult. What if your question doesn't make sense? >> And with my questions, I'm trying to figure out what you really want now. So, look, you say you have a system, it's not a Telegram bot. Okay. >> Yes. >> You won't have a TG server, right? >> Yes. >> Everything else, all other components will remain the same, right? >> Well, yes. >> When you say programming language, to which component are you referring? >> I'm referring to the front. >> Uh, okay. Look, what's the contradiction. So, the question asked. What tech are we using? Programming language. Then you clarified for creating the interface. For creating the interface, what can you choose at the moment? Uh, you have JS, right, well, with corresponding frameworks. You have Python, >> right? >> Uh, well, okay, good. Everything can be done in Python, >> please. >> It's not critical at all. The main task of this course is for you to understand how business system analytics works and to create your solution according to your documentation. Okay? >> Uh, so. >> How the interface will be implemented is not critical. >> But why aren't you asking the question, then, uh, what technology for implementing the server? Because that's no less important. >> Server implementation technology, >> yes? Framework, programming language, what? >> No, well, we decided there, well, not decided, I suspect that the backend will be in Python. Because interacting with the LLM is easiest to organize, well, there's the most documentation, in short, 90% do it in Python. >> Everything is correct. But just look, uh, what's the discrepancy now, right? >> It would be correct to clarify then, if you ask a question about tech, about each component, right, that's tech. That is, you decide what language, what framework to write the frontend in. You decide what language, what framework to write the backend in. You decide what database to use. Right? >> This is what is called tech, >> that is >> uh, well, there are versions, but that's not the point. These are already deep stories. >> Can you call tech just the front? >> No, I didn't call it that. I wrote "web interface." >> Okay. >> Well, then I'll just say JavaScript or Python for the front, for the back - it's, um, the back is on, God, on Python. Uh, and then you can, like, wrap it in Docker and >> PostgreSQL will be on the same server. Well, I don't know much, but then the question is server, database, well, PostgreSQL, should it be wrapped in Docker or not? Well, I understood. Okay. >> Uh, look. >> Uh-huh, okay, thank you, Rudolf. Thank you, Rudolf, the answer is incorrect. >> Rudolf writes: "It will be easier to wrap." But thank you. >> The question is not posed that way. Function, you should ask yourself the following question: what is the function of my backend, backend and agent? What is the function on our current architecture? Uh, well, to process data, but I know that it's unwound. >> What happens if the server shuts down? Nothing will happen, no connection to anything. >> Will the data be lost? >> Uh, the data should not be lost. >> Why? Uh, well, the task of the backend is to take data from the database, put data into the database. >> Uh, yes, absolutely correct. >> And thus, when your server shuts down, for some time you won't be able to interact with the database, right? >> Yes. >> And your database, if you deploy this database on that server, uh, what will happen if the server shuts down, well, yes. Uh, well, yes, it will all be lost. >> Okay. >> So all your data that you collected during the product's lifetime will disappear, >> yes? >> What's the question now? Let's get specific, uh, in short, to your question. Is it worth wrapping the database in a Docker file, well, in a Docker service, whatever it's called, or not? Well, it seems like it doesn't matter, it just needs to be on a separate server. >> Uh, indeed, this question doesn't matter, because you need your data to always be safe. By default, when you wrap something in Docker, by default, it will also disappear when the Docker container shuts down, right? >> Well, yes, that's right. >> Uh, so, in this case, either you need to, uh, pass the storage of this data from the Docker container to the hard drive of your virtual or physical machine, you can do that. That's how it's done. Or you need to install the database, regardless of Docker, on your physical or virtual machine. Right? >> Yes. >> Correct. What will happen if your physical or virtual machine with your database deployed on it shuts down somehow? >> The data will be lost. How do we get away from that now? Uh, well, there should be backups, >> right? >> No, >> everything is correct. Everything is correct. And now, with this long, long answer, we've come to the point that it doesn't matter whether you wrap it in Docker or not. It's absolutely not critical. It's absolutely critical that your data survives after the server shuts down. Okay? >> Uh-huh. >> And if you had watched the previous lecture, it said: "Take database as a service," when external providers provide you with a database as some kind of network interface that you can somehow work with, right, there, well, there, relational entities are stored, SQL queries go there, and so on, but you don't worry about the fact that this database will shut down and the data will be lost. >> Uh-huh, understood, >> understood. But it's interesting, isn't it? >> Well, yes. >> We started with a programming language for the web interface and ended up with databases. Asia, >> yes, I have a small question. At what stage of interaction with the customer do we usually do business requirements? After signing the contract or before, to understand what they need at all? >> What is signing the contract? >> Well, payment, there, fixing obligations of some kind. >> How does this relate to your training project? >> Not at all. >> Well, not to the training project, but in general, I would like to have an understanding of how it happens in real life. >> Okay, I'll answer now. The initial, uh, very rough collection of requirements, >> very rough, at the level of a few user stories, right, some principal interactions, >> before, of course, yes, before, well, starting some work, so that you generally understand what needs to be done. >> But in general, writing detailed business requirements and so on, there, architecture, system requirements - this is also work. Did I answer? >> Yes, thank you very much. >> You're welcome. That's all, thank you, guys. I think it was useful. Uh, yes, just one, one second. Uh, so, is my, yes, slide visible? Is the slide visible? Please tell me. No. Okay. >> Uh, I probably need to turn off the screen now. Yes, >> turn it off, please. Turn it off, please. Now. Thank you for telling me. So, okay. >> If you suddenly feel like working in a team after the current meeting, >> and contributing to the team, >> on these competencies that you see on the slide, then please let me know in any way. Write to me, write via QR code. >> In general, please let me know, it will be painful. Well, it's quite difficult work, >> but it's quite interesting practical experience, so to speak. >> Uh, yes, thank you, >> for coming. The recording, as usual, will appear soon. >> And start writing your solutions. Well, Marina, Rudolf have started writing their solutions. Now you start too. Okay, bye-bye.