@@Farisey то есть что бы сделать FTP сервер для всех (то есть для тех кто сидит с другой сети) нужно сначало его делать на локальный айпи (в данном случае - 192.168.1.144), а потом уже коверкать чтобы я смог с другой сети и с другого компа зайти на свой сервер?
дуже відчувається, що ви пане, в свій час не знаходили якісного контенту по QA, і вирішили це виправити , але на жаль , ще не вдалось ... розповідаючи про навантажувальне тестування за допомогою Jmeter, потрібно спочатку самому зрозуміти що таке Number of threds , Ramp-up period , loop count..... тоді ви не будете очікувати різних результатів , проганяючи два теста з однаковим навантаженням по запит/секунда ...... і ще ("сто паділіть на п'ять ... ета десять юзерав в секунду .......") повторюється в 2 відео, не робіть так більше ))) Краще попрацюйте над своїми помилками , а не над критикою інших, (хоч і справедливою) щоб ви мали якісний контент. Нехай щастить!
Як девелопер трошки кину камінь в мікросервісну архітектуру, а саме в слова, що мікросервісна архітектура допомагає зробити надійніший код без багів, або ж баги будуть зачіпати тільки певну область - все це не завжди так і того ж можна добитись і в монолітній архітектурі, якщо нормально задизайнити код і повідділяти наприклад модулі, які відповідають за каталог товарів від модулів, які відповідають за корзину. Проблема моноліту саме в дизайні коду. Моноліт дозволяє зробити з коду спагетті, коли зміна в одному кінці коду потягне зміну в іншому і програмісти на це спокушаються. Приведення моноліту до нормального код дизайну, який допоможе відділити один функціональний модуль від іншого по складності точно таке же, а деколи трошки простіше(бо не треба зайобуватись з шарами, які відповідають за зв'язок одного мікросервісу з іншим) ніж переписати це все на мікросервісну архітектуру. Зробивши код моноліту достатньо модульним теж доб'ємось того, що зміна наприклад в сортуванні товарів каталогу ніяк не зможе впливати на корзину чи замовлення. Тейк про те що, якщо у тебе падає якась частина функціоналу у мікросервісах, то система все ще буде працювати, а от моноліт ні - це теж лукавство, бо все впирається в обробку помилок. На моноліті так теж можна зробити - наприклад модуль коду, який відповідає за замовлення не може повернути юзеру його активні замовлення, бо там щось падає - можна зробити обробник помилок, який в такому випадку просто буде ігнорити відправку даних стосовно замовлень, відправляючи все інше і не крашити моноліт і все - от тобі і поведінка як з мікросервісами. Коли в тебе система складається з 10ти процесів, то вірогідність, шо якийсь з них наєбнеться(шось з хостом, шось з інетом, десь девопси наплужили) набагато вища, ніж шо наєбнеться твій 1. Також мікросервіси мають спілкуватись між собою(як правило це HTTP або GRPC) і цей факт додає просто тотальні зайоби під час розробки - треба підтримувати контракт взаємодії кожного з них, а це додатковий леєр в самих мікросервісах і помилку в ньому часто знаходять тоді, коли воно прилітає прямо в обличчя. Сюди ж і тейк, шо різні мікросервіси можуть паралельно різними командами розроблятись і все буде заєбісь - воно то так, але не зовсім, бо контракт між мікросервісами під час активної фази розробки моментально узгодити не виходить НІКОЛИ і він постійно міняється, а це проблема. Те саме і з даними які туди-сюди пересилаються - вони теж активно змінюються і один мікросервіс депендить на дані з іншого, а це означає, шо команди мають щільно комунікувати під час розробки. Це приколи з дебагом де тобі треба відкривати 5 вікон ІДЕєшки, шоб відслідковувати як там запити між собою обробляються і рухаються від одного до іншого мікросервісу, шоб знайти де шось стається не так. Те саме і з деплоєм - моноліт деплойнути простіше. Короче, до чого я веду - з мікросервісами наплужити і зробити шось неправильно набагато легше, ніж з монолітом. Мікросервіси АБСОЛЮТНО непотрібні для малих і середніх за розміром систем. І не зовсім там все так класно з живучістю системи як часто про це кажуть. Якшо розробка ведеться на статичнотипізованій мові, наприклад C# то краще починати з моноліту і його триматись. Якшо це якийсь динамічний JS то там тримати код в порядку дійсно важче і мікросервіси мають сенс(думаю саме через JS вони так популяризовались останні років 10). Якшо система величезна, то так, краще мікросервіси(але швидше за все ви не гугл і вас це не стосується). Якшо є якась частина функціоналу, яка дуже тупить і вимагає масштабування, то мікросервіси забезпечать ту гнучкість, навідміну від моноліту, за допомогою якої це можна буде масштабувати конкретно цю частину. Тому все тут доволі складно
а чому ти не розказуєш глядачам, що також існує і кеш сервера і для чого і що зберігається там?) А то по твоїй відповіді на перше питання, всі новачки не будуть знати, що сказати, коли їх запитають про кеш сервера
@@Farisey я б не сказав, що глибоко) я коли співбесідую і питаю про кеш, всі відповідають про кеш клієнта, і наступне питання аж проситься запитати - а кеш сервера знаєте що таке?)) і все, більшість сипеться)
Мене (QA джуна) якраз на одній співбесіді питали, що таке монолітна і мікросервісна архітектура. Я і слів таких не знала, уже після співбесіди досліджувала, тому так, це корисне відео і цікаві питання, дякую!
Ты кодишь или своими просраными мозгами ципсошник ебучий плачишся сидиш? Ты хули еще не в черном мешке. Хотя видосу год, возможно уже черви сожрали. Промыли вам мозги. Дебилы. Море они черное выкопали.
Не подобається ваше відношення та відповіді на коментарі і речі які ви говорите не співпадають з іншими відео лекціями інших тестувальників тому в мене виникає недовіра до вашої інформації. Також з того що мені відомо з інших відео це все пишеться англійською мовою. Коментувати можна звичайно українською але яка мені користь з таблиць де купа тексту українською якщо реально це все на роботі потрібно робити англійською 😕🤨🧐 крім того завжди розетка та «експерименти» логін пароль а як щодо інших перевірок? Дуже однотипно та дубліковано як на інших каналах.
@@Farisey обгрунтуйте чому? Чи я на роботі буду 24/7 перевіряти логін пароль і все? Чи будуть очевидно інші тести про які немає жодної чіткої інформації у відеоуроках на ютуб у вас теж не бачу 🤔
@@i.f.7386 бери платні курси / уроки і там тобі все покажуть і розкажуть , це перше ) Друге , це те що ми даємо лише приклади , куди рухатись а не те що ти будеш прямо на роботі робити Третє , якщо будеш працювати на міжнародну фірму то пиши тест кейси англійською а так і цього достатньо , та і перекласти тобі що важко ? Інші перевірки ? - якщо ти не можеш придумати звичайні функціональні перевірки то який з тебе тестувальник ? По пʼяте, лекції інших тестувальників … я хз що там у них , відповідаю лише за себе , я пройшов 3 компанії за 2 роки і став лідом в міжнародній компанії , я ділюсь своїм досвідом … якщо тобі цього мало то я хз
коли ти наводиш курсор на розділ "Fetch/XHR", то ти говориш слово "АЯК", що це значить? мені це слово чується, але може я плутаю і ти інше слово говориш 🙏
Врубати музику в тон голосів - це геніально! Я б таких тестувальників (забеспечувальників ЯКОСТІ) гнав в шию з роботи вже за це! Я не знаю хто там додав це ноу хау, але якщо це інтервьюєр, то Шо він там може співбесідувати і тестити, якщо він сам елементарних речей не розуміє?
