Ось це ще одна віха крутого контенту. Не привʼязаний до мови, архітектурно направлений, актуальний. Дякую!
@alexbozhko72
2 күн бұрын
Маэстро, Вы нас вообще ни в хр... ни в грош не ставите! Конечно же мы думаем о Concurrency на этапе проектирования. Просто потом забиваем на это на этапе разработки.
@NemchinskyLive
Күн бұрын
Ахаха, ну как на меня это ещё хуже)
@sanioksasha3338
2 күн бұрын
А как зовут автора, куда пропал Сергей Немчинский?
@ИмяФамилия-э4ф7в
2 күн бұрын
1:03 - это что, для тебя, какая-то шутка?
@ivanvint
Күн бұрын
Это он перед сменой пола оставляет след в истории 😂😂😂
@user-Leonidovich
15 сағат бұрын
Да что вы беспокоитесь, он же не Вася, который уехал в Таиланд
@muksaflash
2 күн бұрын
Круто сделано в гугл документах. Там в реальном времени видны исправления другого пользователя, и если он афк, его вроде выкидывает оттуда.
@MrCri5py
Күн бұрын
Но как это называется?
@otvertka7070
Күн бұрын
@@MrCri5py Real-time веб-приложение, по идее. Оно обычно работает на веб-сокетах
@kitten-free
Күн бұрын
@@MrCri5py онлайн-редактирование?
@Alexvilg
Күн бұрын
Вебсокеты
@megaman13able
23 сағат бұрын
@@MrCri5py CRDT это называется)
@jgkdmdevienjjgg8866
Күн бұрын
Можно при первых изменениях пессимистично блочить кст. Чтобы просмотр не блочил. Ну или по кнопке режим редактирования. Также можно на вебсокеты подвязать и валидировать захват блокировки. Если поля перестаются меняться и пользователь заснул - снимать лок по таймауту с запросом о продлении юзеру. Я таких систем не делал, просто предполагаю.
@Feell70
14 сағат бұрын
Со стороны пользователя ПО скажу почему 1. Локакть - может бытьплохо 2. Локать - не выход. 1. Например в CRM менеджер зашёл в карточку клиента, переписывается с ним неспеша, а потом вообще не закрывает её... переписывает в блокнот цифры 20 минут. А руководителю отдела или администратору системы нужно что-то поправить в полях клиента - неа, не смогут, даже будучи админами. А чтобы так не было - нужно 10 костылей, которые будут сбоить. 2. Директ.Коммандер в Яндекс.Директе. Можно угандошить десятки часов работы над рекламной кампанией, если скачать её в первый день публикации, а потом через год не обновив с сервера данные например... изменить бюджет на 10%... Эти долбоящеры уже минимум 10 лет не могут сделать, чтобы как у Гугла в Эдвордсе передавались только изменённые поля, а не затиралось вообще всё, ещё и выдав ошибку и не передав нужное изменение... Тупо локи на мой взгляд мало где полезны, чаще нужно думать, как выстроить работу пользователей, чтобы не допускать конфликты.
@jgkdmdevienjjgg8866
13 сағат бұрын
@@Feell70 думаю тут речь о том что лучше уж плохой лок (оптимистичный), чем нежданчик с затиранием часовой работы. А так, если есть время, конечно делать более сложные решения, настроенные на конкретную ситуацию лучше. Но это делать дороже и риск допустить ошибку выше чем в топорных простых решениях.
@ukrainetoday960
Күн бұрын
Самое оптимальное - это лог чейнджей или же ревизия контента - нажал пользователь на редактирование - оповестил всех кто уже редактирует этот контент, сохранил поля - изменения отобразились у других пользователей - с пометкой у поля кто его сделал - во всплывашке, нажал пользователь на поле для редактирования - у всех отобразилось во всплывашке кто редачит поле. Плюс у каждого поля должна быть кнопка сравнения значений и отката к какому либо предыдущему Если делать с локами то лучше так, редактирование - это запрос на анлок, пользователь нажал кнопку редактировать - у всех кто уже редактирует появилась кнопка отмены с таймером, не нажали на кнопку - сохранился их недописанный вариант - синхронизировались чейнджи - у пользователя кто запросил анлок - появилась возможность редактировать
@ИмяФамилия-э4ф7в
Күн бұрын
Смешно. Не, оно то может и удобно, но такая куча работы, запросов/перезапросов, да и хранить это все нужно, изменения там, текущие редакторы... И ради чего? Хорошее решение - это не то, которое даёт все и сразу. Хорошее решение - это то, которое даёт нужный результат за приемлемое время и бюджет. Ведь все эти "приколюхи" отнюдь не бесплатные. И если оно прямо надо для какого-то приложения - то да. А если "чтобы было" - то нет 😢
@kitten-free
Күн бұрын
"оптимальное" - это с точки зрения удобства пользования. но не пользователь решает а владелец. а для владельца оптимальное - это приносящее больше денег. т.е лучшее за свои деньги. обычно оптимальное - это вообще без управления параллелизмом - молчаливая перезапись
@ukrainetoday960
19 сағат бұрын
@@ИмяФамилия-э4ф7в то что кажется что здесь куча работы - лишь следствие непрофессионализма, такая архитектура решается в юи всего лишь двумя паттернами. Нет ничего страшного в том что нужно хранить чейнджи если этой о требует бизнес, экономия на спичках тут может обойтись дороже
@ukrainetoday960
19 сағат бұрын
@@ИмяФамилия-э4ф7в ради чего? Ради требований заказчика, хорошая архитектура это не когда тяп ляп сделал, авось потом переделают, а так чтобы у заказчика бизнес работал как швейцарские часики
@ukrainetoday960
19 сағат бұрын
@@kitten-free оптимально с точки зрения архитектуры, если тебе такое удобство заказал заказчик, если заказчику не нужно, то разумеется и архитектура такая не нужна.
@user-ffffffff
10 сағат бұрын
В некоторых кейсах может помочь паттерн event sourcing. Очень хорошее решение когда много изменений от разных пользователей у сложного объекта. В придачу получаем лог изменений этого объекта. Но его прям с осторожностью нужно использовать. А так чаще всего обычного круда без блокировок заглаза.
@pizdatyeTanci
18 сағат бұрын
"Offline" здесь относится к способу, которым транзакции обрабатываются без немедленного обращения к серверу. Это означает, что информация об изменениях блокируется или обновляется локально, а затем синхронизируется с сервером позже. Представьте себе, если бы у вас был блокнот, куда вы вносили все изменения, а затем передавали его серверу для подтверждения, когда появляется интернет. Это полезно в условиях, где постоянное соединение с сервером невозможно. Does that make sense?
@andreychiglintcew5024
2 күн бұрын
❤ это прям реальность. У вас больше одного ядра? У вас есть асинхронность и конкурентность тоже)
@pasha5760
Күн бұрын
Можливо в назві говориться, що це "офлайн" блокування тому що колієнт має скачати і вести зміни у себе на локальній машині, а на сервері сам об'єкт який піддається змінам не може знаходиться (бо там знаходться тільки вже збережені обєкти) і сама мітка блокування об'єкту (а це вже трози інше)
@antikarch
Күн бұрын
Решал описанную проблему с помощью вычисления диффов. Десять лет назад самому пришлось писать, а сейчас javers есть, кажется, с его помощью можно сделать дифф и накатить его на сущность. По итогу оптимистик или пессимистик лока нет, есть просто блокировка на работу с диффми и запись, чтоб гонки не было.
@germanmalinovsky1719
2 күн бұрын
offline означает что блокировка происходит не в реальном времени, а локально на стороне клиента (клиент захватил блокировку и продолжает дальше работать без постоянного подключения), типа как при работе с git (децентрализировано) в противовес к svn (централизировано).
@NemchinskyLive
Күн бұрын
Это версия или официальная трактовка? В любом случае мне нравится
@kitten-free
Күн бұрын
гит не блокирует. оптимистичная - не блокировка. оптимистичное -управление параллелизмом. редактирование бывает офлайн и онлайн(как в гугл-доках). офлайн может быть с управлением параллельных правок либо без. без - это молчаливая перезапись. с управлением - бывает оптимистичное управление и бывает пессимистичное. оптимистичное не блокирует, редактирование происходит без блокировки. если кто-то успел вперёд тебя - ты получишь предупреждение. так работает в гите. пессимистичное управление параллелизмом - это монопольная блокировка.
@germanmalinovsky1719
Күн бұрын
@@kitten-free Cпасибо за дополнение. Да, гит не блокирует физически. Я думаю тут проблема в разбежности названия механизма с его идеей и уже конкретной реализации когда используется слово locking. Возможно выбрана плохая аналогия, но очень уж тот же процесс push ветки напоминает оптимистичную блокировку.
@antonyurchenco1668
Күн бұрын
@@NemchinskyLive imho и "не официальная трактовка" stateless приложение, которыми являются большенство web apps, раздают пользователям формы для редактирования и не следят за процессом на стороне клиента
@БорисОстроумов-т7к
Күн бұрын
Я делаю иначе, я просто логирую все изменения и записываю, кто их внес, потом быстро можно откатить миграцию к конкретным изменениям конкретного пользователя. Либо смержить, как в гите. Самое простое, это лочить при использовании, типа над документом работают, но это путь слабых кодеров. Хардкор, это дать работу сотне пользователей над одним документом и научиться с этим работать
@EwwwGeN
2 күн бұрын
Хотелось бы послушать про всякие событийные паттерны, которые как раз-таки и нацелены на то, чтобы предотвращать проблемы с одновременной записью, а так же помогать работе распределенных систем
@alexblack43
Күн бұрын
Так тут даже у одного пользователя могут быть проблемы. Открыл несколько страниц разных товаров инет-магаза в разных вкладках, подобавлял их в корзину и уже будет рассинхрон между той корзиной, которая была на самой старой вкладке, и той, которая на самой новой.
@oleksandrsova4803
21 сағат бұрын
Ви найголовнішого не розповіли - як тепер замовника переконати в тому, що йому це потрібно? Скоро вже чотири роки буде як я все намагаюсь підібрати кейси і уламати замовника на додачу обробки ETag та If-Modified - замовник прямо каже що йому те не потрібно. Тож я далеко не згоден з тейком про те, що ніхто про локи не думає і ще більше не згоден з тим, що така поведінка системи - це вина розробника.
@nikolaiii3
23 сағат бұрын
В ТортойзСВН случай когда двое копаются в одном файле очень неплохо разруливался при попытке коммита. Последний должен был всё порешать, правильно расположить изменения.
@kitten-free
Күн бұрын
офлайн называется потому что позволяет редактировать офлайн. т.е скачал, ушёл в офлайн, правишь, вернулся в онлайн, сохранил. если же есть возможность оставаться онлайн то можно отображать правки онлайн мгновенно по мере их внесения всеми участниками как это сделано например в гугл доках
@gnidkoav
Күн бұрын
Очень важная тема! к сожалению приходил к этому сам... )
@kitten-free
Күн бұрын
звучит так как будто заказчик должен заранее решить какой тип лока ему нужен. но можно предложить такое решение пользователю: т.е пользователь может нажать кнопку "захватить" ресурс в монопольное пользование а может не нажимать и оптимистично редактировать в надежде что успеет сохранить первым. помимо этого есть ещё и онлайн-редактирование, в противоположность этим вашим офлайн-локам - это когда правки других пользователей мгновенно становятся видны каждому пользователю и каждый видит работу каждого в онлайн режиме (если они работают над одним файлом, причём видят кто именно делает что. в гугл-доках например именно так и сделали. но все эти решения стоят денег, скорее всего вашему заказчику они не нужны и ему подойдёт слепая перезапись а пользователи как-нибудь сами договорятся чтобы друг другу не мешать - обычно это оптимальное и самое дешёвое решение, экономное, то что нужно для бизнеса. можно ещё сделать журнал редактирования чтобы они могли видеть кто когда вносил правки и что поменялось
@pavelvasianovych4030
Күн бұрын
Можно в пессимистической блокировке определить таймаут на случай уезда Васи в Тайланд. Кстати по поводу вебинара и тренинга интересует лимит желающих и стоимость.
@ZingeR325
2 күн бұрын
Оффлайн лок - полагаю, это связано с разрывом связи между базой и юзером (его интерфейсом и выборкой данных в него)
@oleksandrivashchenko7916
2 күн бұрын
Недавно столкнулся с проблемой конкурентной записи у себя на проекте. Мы решили через версионирование. Каждый раз когда клиент пытается сделать запись, он дополнительно отправляет версию на основании которой он делал изменения, и если эта версия не совпадает с текущей, мы ему сообщаем об этом и не даем сделать запись. Данный подход предупреждает перетерание данных, но он не дает никаких инструментов по решению конфликтов, справедливости ради, мы сознательно отказались от этого, решили что система решения конфликтов нам не нужна, достаточно будет детекции. Судя по всему это оптимистик лок
@the_huge_knight
2 күн бұрын
Optimistic OFFLINE Lock
@kitten-free
Күн бұрын
это вообще не лок - вы ничего не лочите. вы оптимистично управляете конкурентностью. это optimistic concurrency control.
@kitten-free
Күн бұрын
Optimistic concurrency control (OCC), also known as optimistic locking, is a non-locking concurrency control method
@MasterSergius
Күн бұрын
Конкьюренси... Можно попросить Вас прочитать bicycle и vehicle? Как раз подтягиваю английский, думаю, научусь и тут чему-нибудь...
@alexandernaumochkin
Күн бұрын
Тут тебе получится подтянуть только рунглиш :)))
@kitten-free
Күн бұрын
оптимистичная - не блокировка. оптимистичное - управление параллелизмом. редактирование бывает офлайн и онлайн(как в гугл-доках). офлайн может быть с управлением параллельных правок либо без. без - это молчаливая перезапись. с управлением - бывает оптимистичное управление и бывает пессимистичное. оптимистичное не блокирует, редактирование происходит без блокировки. если кто-то успел вперёд тебя - ты получишь предупреждение. так работает в гите. пессимистичное управление параллелизмом - это монопольная блокировка.
@kitten-free
Күн бұрын
Optimistic concurrency control (OCC), also known as optimistic locking, is a non-locking concurrency control method
@alexandr3036
Күн бұрын
круто а где про Архитектурное решение?
@VitaliyParhomenko-w5b
Күн бұрын
У нас вариант, когда песимистик лок удаляется автоматически через какое-то время, которого более чем хватает что бы отредактировать документ
@shishlinsv
Күн бұрын
О, мы как раз писимистик лок переделывали на оптимистик. А у них названия есть)
@postoronny
Күн бұрын
Мне скоро предстоит этим заниматься... Пока народ говорит: "вапще не надо, будем редактировать с одного места"... (предполагаемые конкуренты рядом за соседними компами) Причём, говорит это тот, кому и предстоит редактировать, хоть у него работы там и так по горло и, строго говоря, редактирование - это не его основная работа на этом месте. Мож сталкивался уже?..
@sergeibatiuk3468
Күн бұрын
Я начал о нем думать - и понеслось: Scala, Akka, Functional Programming, Cats Effect, Haskell, Project Reactor, Go routines
@ekari
17 сағат бұрын
Ну я не знаю. Для Васи уехавшего в Тайланд достаточно установить разумные сроки времени редактирования. и никакая админка не нужна!
@fillfacks5986
2 күн бұрын
Фух, вы всё ещё Сергей Немчинский😅🎉
@STimothy
Күн бұрын
А почему не сделать как в гугл докс, что изменения внесённые одним пользователем сразу отображаются у всех?
@ИмяФамилия-э4ф7в
Күн бұрын
9:50 ну я пока не вижу проблем с таким решением: за основу берем песимистик лок, но тот, кто второй открывает на редактирование, может снять этот лок просто в диалоговом меню. Ну и логгировать это дело. Тогда если будут перетирать друг другу, то это их проблемы. Тебе писали, что ресурс занят? Писали. Ну вот и нахрена ты тыкал "снять лок" и запартачил запись другому человеку? Или себе.
@NemchinskyLive
Күн бұрын
Не стоит так делать, не каждый бизнес одобрит такое
@ИмяФамилия-э4ф7в
Күн бұрын
@@NemchinskyLive очевидно, что решение нужно согласовывать с заказчиком. Это было бы мое первое предложение по реализации, и далее я бы ждал согласия или замечаний. Ведь доп. админка - удовольствие не бесплатное. Но если заказчик (или менеджер) скажет: "шед ап, анд тейк май мани", то кто я такой, чтобы ему отказывать?
@kitten-free
Күн бұрын
можно решение отдавать на откуп пользователю. например кнопка "залочить". не нажал её - значит правишь в надежде что успеешь сохранить первым. не хочешь рисковать - жмёшь её. другой может и может снятжь а может и не может. можно и права выдавать на снятие лока, можно вводить систему прав кто чей лок может снимать итд итп - усложнять можно до бесконечности. но - зачем? чаще всего вообще никакого управления параллельным доступом не требуется - тупая молчаливая перезапись
@Mr43046721
Күн бұрын
Сегодня какой-то день блокировок. Часа 2 назад выступал с докладом про Постгрес, блокировки и транзакции вот это всё. Решил отвлечься в ютубчик - и тут про блокировки)))
@TheAcekon
2 күн бұрын
А в чому проблема при Pessimistic Offline Lock не робити обмеження часу або якщо людина кілька годин не активна завершати його сеанс і знімати всі блокування.
@kozakA8
Күн бұрын
а если работа будет делаться 2 часа? Есть не только 2 варианта. До часу или уехал в Тайланд. Есть вариант 3 часовой работы например. Или дать человеку полдня на выполнение работы. Остальных предупредить что бы полдня занимались другим. Например работа с 10-14. Второй человек захотел зайти в 13:50(а вдруг уже первый всё сделал) И наткнулся та лок. В твоём предоложении лучше сменить час времени, на отрезок времени которое назначит админ
@TheAcekon
Күн бұрын
@@kozakA8 я про те що блок ставиться поки активний сеанс користувача і знімается розлогіном з системи.
@komputersh4ik546
Күн бұрын
@@kozakA8ну можно сделать если человек например 1 час не вносит каких-то изменений, то выдавать сообщение на продолжение сессии этому человеку, если человек не подтверждает, то блокировка снимается автоматически
@oneway2ba
2 күн бұрын
что такое версия? это просто счетчик условный который плюсуется при каждом редактировании или что-то более глобальное?
@kitten-free
Күн бұрын
да, в самом простом варианте - просто счётчик. при чтении он читается и отдаётся клиенту. при записи клиент сообщает какое у него число было - если на момент записи число поменялось - значит опоздал. в sql можно писать: update foo set bar=$bar, version:=$version+1 where id=$id and version=$version и если количество обновлённых строк=0 значит версия изменилась
@WadeChannal
2 күн бұрын
Забавно, что я как раз на своем проекте сейчас решаю этот вопрос
@АлексейН-р3т
2 күн бұрын
Когда спрашивать решили не человека, а программиста, я понял, что ничего не пойму. Внимательно посмотрел ролик и действительно ничего не понял.
@vatakiller
19 сағат бұрын
Честно говоря ничего нового для себя не подчеркнул. Как правило, более-менее опытный бэкендер это знает
@shod76
Күн бұрын
Можно сделать и без админки. Просто джоба сама будет снимать локи после определенного периода времени при отсутствии активности.
@ИмяФамилия-э4ф7в
Күн бұрын
@@shod76 не годится. Допустим, ты установил это время равным часу. Ок, Петя взял документ на редактирование, подправить две цифры, и у него сломался комп. Документ нужен через пол часа на совещание. Но подправить его можно через час. Удобно 👍
@shod76
Күн бұрын
@@ИмяФамилия-э4ф7в в админке только время блокировки сделать изменяемым для различных типов объектов. В данном редком случае зашел в админку поменял время блокировки на 1 мин и все ) потом вернул обратно. Но , соглашусь, с админкой лучше
@jonkarmok1840
Күн бұрын
А можно просто сохранять только то что пользователь поменял, не перетирать всю запись, а поменять только конкретные измененные поля тогда никакой проблемы не будет
@kitten-free
Күн бұрын
будет, просто гранулярность снизится. теперь затёртыми окажутся только конкретные поля целиком. а что если у вас в блоге запись - это блогпост. у блогпоста есть поля: автор, название, дата создания, обновления, содержимое поста. вот два автора поменяют запись - поменялись 3 поля: автор, дата, содержимое поста - почти вся запись затёрлась. потом вы решите вносить только конкретные строки внутри поля и ситуация повторится уже со строками. короче в конце вы изобретёте гит.
@jonkarmok1840
Күн бұрын
@@kitten-free ладно согласен, но есть еще вариант, когда редачим берем хеш записи, когда сохраняем, сервак проверяет, актуальная версия сходится с той которую мы начали редачить и если нет, сообщаем юзеру при сохраеении, и просим перенести правки в новую версию, это сильно проще гита, и сильно удобнее блокировок
@sergeibatiuk3468
2 күн бұрын
Такое ощущение, что у него есть некоторое immutable property
@velsah5763
2 күн бұрын
В 1С эта проблема решена просто. Если кто-то открыл документ на редактирование- остальным он открывается ТОЛЬКО на просмотр. Но осталась проблема с отчетами. Есть отчеты , которые моут формироваться несколько часов- а за это время инфа может изменится. Вылезет бред (но обычно не критично)
@indarelloivanov2180
2 күн бұрын
Ну так ситуация когда первый открыл документ на редактирование и пошел пить кофе, проблема как была так и осталась. При чем здесь открытие на чтение?
@the_huge_knight
2 күн бұрын
фу 1С, там одни проблемы
@0imax
2 күн бұрын
@@indarelloivanov2180почему бы не пинать афк-шника через х минут?)
@Андрей-к3ъ9е
2 күн бұрын
Если программистам нужно объяснять что такое блокировка,... то я понимаю, почему про программистов 1С говорят что они умнее прочих и почему программисты "правильных" языков так агрятся на 1С. Касательно отчетов на "несколько часов", если это системное, то у вас что-то не так работает.
@velsah5763
Күн бұрын
@@Андрей-к3ъ9е это не системное, но иногда случается. И если спросить у программиста в реальном бизнес-секторе, то он вам скажет, что иногда лучше сделать сейчас и рабочее решение, чем пару недель потратить на оптимизацию
@nahigor
Күн бұрын
КонкАренсу, нет такого слова конкЮренсу.
@sergeibatiuk3468
2 күн бұрын
Конкьюренси!
@MasterSergius
Күн бұрын
А-а-рон (Key and Peele - Substitute teacher)
@narimz
2 күн бұрын
Лук топ 😎
@0imax
2 күн бұрын
По сути, это мердж конфликт, и решать можно подобным же способом.
@ИмяФамилия-э4ф7в
Күн бұрын
@@0imax ага, прямо вижу как бухгалтеры резольвят конфликты в документах 😏
@0imax
Күн бұрын
@@ИмяФамилия-э4ф7в Примерно так в своё время придумали 1С 😂
@AmirLT-x6y
Күн бұрын
Intresting❤
@ukrainetoday960
Күн бұрын
5:07 блокировки это не самое лучшее решение
@qwertymangames1800
17 сағат бұрын
Это всё ещё Сергей Немчинский?
@_dzen_tv_
Күн бұрын
Учим новое слово - вылогонить
@alexandernaumochkin
Күн бұрын
Отлогонить. И по самые помидоры.
@nrmncr37
Күн бұрын
что, так плохо с подписчиками, что надо выкладывать кликбейтное дерьмо?
@ZingeR325
2 күн бұрын
И ещё одна похожая шляпа: рассинхронизация текущей выборки на экране у клиента реальному состоянию данных в базе. Рефрешить нонстоп нельзя, и потому юзер видит то, что было в базе на момент, когда он открыл форму. И вот он с чувством, с толком, с расстановкой выбирает себе запись для работы, открывает её, а она в этот момент УЖЕ изменена/удалена/невалидна. А узнает он об этом в лучшем случае (это если про "конкуренси" позаботились) - уже когда захочет сохранить свою стену текста, которую 40 минут вносил в документ 🤪 з.ы. Это отдельный случай, не описанный в сценарии "пессимистик лок". Речь о случае, когда документ никто не правит прямо сейчас - он его уже исправил, но мы этого не знаем, мы из базы прочитали старую версию.
@ИмяФамилия-э4ф7в
Күн бұрын
@@ZingeR325 если настроен пессимистик оффлайн лок, то такой ситуации не возникнет. Если я взял документ в работу, то в базе он лочится. Как его кто-то другой возьмёт в работу пока я не отпущу? И, соответственно, я не смогу взять в работу, если его кто-то залочил.
@YuriyStakhniak
2 күн бұрын
КонкАренсі😊
@muksaflash
2 күн бұрын
А гугл переводчик там скорее у говорит, чем а 🤔
@СлаваВолошин-ы3с
2 күн бұрын
@@muksaflash нет, с спецом его переслушал, там А
@muksaflash
2 күн бұрын
@@СлаваВолошин-ы3с это зависит от диалекта, скорее всего. У меня на компьютере более похоже на «А», а на телефоне на «У» 😂.
@КолёКолё-ю2щ
Күн бұрын
@@muksaflash😅🔥
@eduardvad
13 сағат бұрын
Немчинский, чому не на мовi? Тебя в окопах ждут давно
@omen9748
Күн бұрын
Привет Наш Дорогой! Открой школу для русских! Это принцип? Если хочешь учи, преподавай! Спасибо! Вещаешь русским языком, странный ты. Открой школу. Если проблемы, с русскими не вещай на русском языке. Достал правда!
@lexxkrt
Күн бұрын
автор почему не в окопе? или ты настолько лживый патриот?
Пікірлер: 111