Эта порочная практика блокировать вообще все началась, когда разрешили исполнительные документы разрешили получать в суде заочно и сразу отдавать приставам. Им приносят документы на сумму N, те быстро блокировали отправляли в каждый банк запрос о снятии суммы N. В сумме получалось, что они могли забрать (N*количество банков) рублей. В итоге, когда ты начинаешь видеть, что у тебя денег не хватает, выясняется, что постарались приставы. При этом они также накладывают ограничения на регистрацию авто.
Я сбером не пользовался лет 10, наверное. Выпустил новую карту, закидываю 500р, и их нет! Видимо за все это время какой-то из приставов забыл отправить отмену исполнительного листа в сбер.
А на авто у меня висело штук 6 запретов друг за другом, от разных приставов, при суммах копеечных (давно мне транспортный налог не приходил годами, почему-то) Это я выяснил когда открыли возможность посмотреть ограничения онлайн.
Были исследования, когда для Нвидиа создавали виртуальные устройства для использования в контейнерах, и для каждого этого устройства могли ограничивать объем используемой памяти и времени использования. Можно использовать для ии-агентов, например
Там не совсем инкапсуляция, и к ООП он не относится, ну да ладно. Я имею в виду пример с самолётами, он слишком натянутый, при нормальной архитектуре в ООП такого не должно случаться, если уж зависимость так необходима. Да, дедлоки случаются, обычно при добавлении функционала, которого изначально не было предусмотрено, но это лишь причина пересмотреть архитектуру приложения. При работе с бд в примере, вам нужно создать объект типа похожего по функционалу на lockguard для блокировки изменения данных строки в БД. Просто ещё один класс. И он уже будет освобождать строку был в деструкторе. Это один из вариантов решения.
Да откуда дедлокам то взяться? Ресурс один - блокировщик один на чтение и запись, пока не завершится работа с данными. Если нужно, можно сделать парадлельное чтение, но на запись нужен второй блокировщик, который и чтение запретит. И это уже реализовано в БД и не связано с ООП вообще ни как
А вариант примера решения без ооп будет? И как объект "диспетчер" оказался в управляемых объектах? И ооп в этом примере за уши притянут. Согласен, проблемы есть, как и есть способы их решений, но пример на псевдокоде - это вообще не ооп ни разу, обычное процедурное программирование.
Мне кажется тут хвалиться нечем. Был ли какой либо особый функционал? Абсолютно ничего нового, по сравнению с другими магазинами. Даже детский режим очень странный. Просто вот так вот повезло, что санкционные компании выкладывают свои приложения только там.
Вообще, конечно, если сервис не позволяет настраивать секюрность, то так себе сервис. Например добавить правила для тонкой настройки пересылок, если их нет. Правила для получателей в зависимости от прав пользователя. Например обычный юзер не может отправлять письма вне компании, только внутренние и плюс белый список. Менеджер по продажам может всем слать, но автоматическая пересылка наружу запрещена.. ну и т.п. нормально делайте - нормально будет
Да, проблема есть, высшие органы решили, что нефиг поддерживать ИТ в Москве и Питере. Но т.к. компаний зарегистрированных в Подмосковье тоже не очень много, наверное только те, кто в Сколково, то и в условном Одинцово квартиру тоже не купить. По семейной ипотеке лимиты на столько низкие при высоком первоначальном взносе, что не понятно, какой семье нужна эта однушка за мкадом через три года.
Как связан API с UX? UX вообще связан с технической частью очень символически. UX - это скорее про логику взаимодействия с пользователем, тестирование, ближе к психологии, чем к разработке или дизайну. UI ещё понятно, но это просто интерфейс, который лежит сверху на фронтенде.
То есть предполагается, что я на свой сервер, допустим, должен ходить только через ssh? И светить 22 портом на весь мир
Ну потомучто в мухосранске он, возможно, получил таки профильное образование, а не прочниста. 😀
И на курсах тоже только и делают, что теребят эго, делают всё, чтобы человек принес денег и получил удовольствие от этого процесса.
Одно дело когда ты закончил "прикладная математика и информатика" в МГУ, а другое, когда "программная инженерия" в МГТУ
Эта порочная практика блокировать вообще все началась, когда разрешили исполнительные документы разрешили получать в суде заочно и сразу отдавать приставам. Им приносят документы на сумму N, те быстро блокировали отправляли в каждый банк запрос о снятии суммы N. В сумме получалось, что они могли забрать (N*количество банков) рублей. В итоге, когда ты начинаешь видеть, что у тебя денег не хватает, выясняется, что постарались приставы. При этом они также накладывают ограничения на регистрацию авто.
Я сбером не пользовался лет 10, наверное. Выпустил новую карту, закидываю 500р, и их нет! Видимо за все это время какой-то из приставов забыл отправить отмену исполнительного листа в сбер.
А на авто у меня висело штук 6 запретов друг за другом, от разных приставов, при суммах копеечных (давно мне транспортный налог не приходил годами, почему-то) Это я выяснил когда открыли возможность посмотреть ограничения онлайн.
Были исследования, когда для Нвидиа создавали виртуальные устройства для использования в контейнерах, и для каждого этого устройства могли ограничивать объем используемой памяти и времени использования. Можно использовать для ии-агентов, например
И связи поломаются
А помните, в дотелефонную эру появлялись родственники из африканской республики, которые оставили вам наследство... И это все было письмами
А оператор не настраивает переадресацию вызовов, чтобы это все работало?
Там не совсем инкапсуляция, и к ООП он не относится, ну да ладно. Я имею в виду пример с самолётами, он слишком натянутый, при нормальной архитектуре в ООП такого не должно случаться, если уж зависимость так необходима. Да, дедлоки случаются, обычно при добавлении функционала, которого изначально не было предусмотрено, но это лишь причина пересмотреть архитектуру приложения. При работе с бд в примере, вам нужно создать объект типа похожего по функционалу на lockguard для блокировки изменения данных строки в БД. Просто ещё один класс. И он уже будет освобождать строку был в деструкторе. Это один из вариантов решения.
Да откуда дедлокам то взяться? Ресурс один - блокировщик один на чтение и запись, пока не завершится работа с данными. Если нужно, можно сделать парадлельное чтение, но на запись нужен второй блокировщик, который и чтение запретит. И это уже реализовано в БД и не связано с ООП вообще ни как
А вариант примера решения без ооп будет? И как объект "диспетчер" оказался в управляемых объектах? И ооп в этом примере за уши притянут. Согласен, проблемы есть, как и есть способы их решений, но пример на псевдокоде - это вообще не ооп ни разу, обычное процедурное программирование.
Мне кажется тут хвалиться нечем. Был ли какой либо особый функционал? Абсолютно ничего нового, по сравнению с другими магазинами. Даже детский режим очень странный. Просто вот так вот повезло, что санкционные компании выкладывают свои приложения только там.
Вообще, конечно, если сервис не позволяет настраивать секюрность, то так себе сервис. Например добавить правила для тонкой настройки пересылок, если их нет. Правила для получателей в зависимости от прав пользователя. Например обычный юзер не может отправлять письма вне компании, только внутренние и плюс белый список. Менеджер по продажам может всем слать, но автоматическая пересылка наружу запрещена.. ну и т.п. нормально делайте - нормально будет
Да, проблема есть, высшие органы решили, что нефиг поддерживать ИТ в Москве и Питере. Но т.к. компаний зарегистрированных в Подмосковье тоже не очень много, наверное только те, кто в Сколково, то и в условном Одинцово квартиру тоже не купить. По семейной ипотеке лимиты на столько низкие при высоком первоначальном взносе, что не понятно, какой семье нужна эта однушка за мкадом через три года.
Как связан API с UX? UX вообще связан с технической частью очень символически. UX - это скорее про логику взаимодействия с пользователем, тестирование, ближе к психологии, чем к разработке или дизайну. UI ещё понятно, но это просто интерфейс, который лежит сверху на фронтенде.
Если менеджер напрямую взаимодействует с членами команды разработки минуя тимлида - это очень плохой подход.
Зато будете алгоритмы знать 😁
Если корабль будет штормит, пусть попробуют потыкать в экран
Ожидал увидеть статью про ФП, но увидел в основном процедурное. разочаровался :(