Во-первых написать генератор такой формочки из единого стандарта дизайн системы - это очень простая задача - именно так сделано у нас (наш стандарт фронта это vue+js, если что).
А во-вторых, у KeyCloak отличное апи, и если уж приспичило сделать из мухи слона - то все можно сверстать на своём стэке и просто дёргать апи. Те сделать свою форму авторизации, а не городить огород.
По прошествии нескольких месяцев вся эта анимация будет выключена (ибо зае) и останется только обычный свет, скорее всего желтый или белый. Вопрос - а надо ли было городить огород?
Из того что делали "фо фан" - поставиили два лазерных дальномера (крошечная микруха, полно на али) внизу лестницы и сверху, и в момент начала движения оно мерило расстояние до идущего и подсвечивала область ступеней под ним другим цветом - смотрится круто, точно также нафиг не нужно.
У меня как раз и был вопрос - в рантайме в раст будет ли паника при уменьшении uint32 ниже нуля, как я понял из ответа - паника будет. Если не будет - тогда зачем все это делать ).
В Си ничего не будет - просто будет число = макисмальное число от типа переменной - ( то что вычли - 1 ).
Можно так. Но опять-же это лишь перекладывание сложности.
В приведенном вами случае, вы переложили ее в типы, если сделать класс "Корзина" - то сложность уйдет в нее.
Что до меня - я выберу последнее, так как в жизни корзина куда сложнее устроена (скидки, акции, товары бандлом, огрничение на товарные позиции не больше/не меньше, товарная позиция, которая идет только бандлом с дургим товаром и тд). ИМХО класс в этом случае будет куда более удобным.
Типы, естественно, никто не отменяет, но их я бы сделал просто наиболее универсальными и с ограничением только по edge-случаям.
Попытаюсь переформулировать все мной сказанное - засовывать сильные ограничения в типы и потом с ними танцевать куда сложнее, чем делать проверку при нормальном подходе к ООП.
Но да, в случае с типами будет доп. проверка на уровне компилятора - это плюс. Однако тесты все равно писать)
Сейчас крайности в томже TSe - народ пытается все в типы запихать, везде юзать дженерики - это приводит к такой жести при поддержке потом, что это целая тема для отдельной статьи - не надо так.
Я не силен в Rust, подскажите насчет баланса - вот если оно беззнаковое uin32 и = 0, что будет, если его уменьшить на, например, 5? Ибо в C это приведет просто к переполнению, что будет еще хуже, чем отрицательный баланс (там хоть понятно будет, на сколько ушло).
Ну и проверка типов тоже сомнительна - вы переложили валидацию в тип - окей, можно было, как было сказано выше, поставить валидацию в саму функцию - и это тоже не проблема (не надо вот только про лишние проверки, можно подумать что с типом их не будет на этапе парсинга). Но суть проблемы здесь - отсуствие класса user, где все это должно быть инкапсулировано, те это архитектурная, а не синтаксическая проблема, ИМХО.
Спрашивается, зачем они вообще нужны? Есть озон, вб, все инструменты, онлайнтрейд, днс и али где можно найти дешевле и практически весь объем нужных товаров. Разве что пвз только от маркета есть и все. Обычно на нем на 10-15 процентов дороже.
Они давным-давно неимоверными силами управленцев убили некогда отличный сервис.
Вот и сейчас - хотите вы эти 20р заложить в заказ ну и заложите ее через продавца, зачем говорить об этом своим прлтзователям? Ещё больше от сервиса из оттолкнуть? Кто у них принимает такие решения? Почему эти кадры элементарную психологию они знают? Я хз. Впрочем, что мертво, умереть уже не может.
Причём часто сравниваю цены товаров и там и там и по статистике 90% распределяется от самой дешёвой цены к самой дорогой так (для не хайтек товаров):
wb
ozon
ali
market
megamarket
Для хайтека и инструментов по-другому и яндекс там в самом хвосте.
Все эти кустарные амбилайты плохи тем, что для них необходимо что-то, что ими управляет.
В правильном амбилайте стоит только hdmi-splitter для захвата экрана и все (ну +питание ещё).
Поэтому, если реально хочется нормальной и безпрблемной подсветки - не берите эти поделки. Берите с HDMI разъёмом, пусть и дороже, но куда универсальней и стабильней.
Знаете, результат получился имхо - ужасный и не продающий, а вот те 3 баночки справа на первом рисунке как раз офигенны по дизайну и привлекательности, имхо опять же. И будет нормально смотреться даже на белой бутылке.
Грубо, если есть 3 подсайта - их, в отличии от монолита, можно разнести по 3 слабым компьютерам, или по 2. Это раз, во-вторых по производительности (но не по ресурсам) 3 подсайта будут работать быстрее, чем один монолит.
Естественно, при такой сложности, будет и дешевле и проще управляемей и проще обновляемей и безопасней. Недаром народ монолиты на микросервисы расколачивает (хотя, естественно и те и те имеют право на жизнь).
Пример - ваши программисты доьавляют код с уязвимостью на портал-монолит - этим компромитируют ВСЕ сервисы целиком, другой пример - добавляют его на корппортал на котором нет особо чувствительных данных - проблема есть но гораздо менее катострофичная. Другой пример - вам надо добавить новый функционал в какую либо часть монолита - требуется согласование и проверка на совместимость со всеми вашими системами и сервисами на монолите, или вдля одной системы - что проще?
Вы мешаете корппортал и совсем другие бизнес сервисы, которые должны быть отдельными системами (но да, можео сделать для них быстрые линки на портале).
Их все нужно делать отдельными системами, хотя-бы потому что функционал разнится очень сильно + предотвращение утечек, минимизация возможности взлома и диверсификация отказоустойчивости.
Корппотал - это то, что доступно ЛЮБОМУ сотруднику корпорации, независимо от должности или чего-то еще.
Никаких ЛК на корппоратле быть не должно. Именно из-за стремления свести все что только можно в него, он и превращается в неюзабельную помойку.
Во-первых написать генератор такой формочки из единого стандарта дизайн системы - это очень простая задача - именно так сделано у нас (наш стандарт фронта это vue+js, если что).
А во-вторых, у KeyCloak отличное апи, и если уж приспичило сделать из мухи слона - то все можно сверстать на своём стэке и просто дёргать апи. Те сделать свою форму авторизации, а не городить огород.
Я правильно понимаю, что для странички ввода логина и пароля и сообщений о неудачном входе народ и вы в частности используете vue/react и ts?
Можете обьяснить зачем?
По прошествии нескольких месяцев вся эта анимация будет выключена (ибо зае) и останется только обычный свет, скорее всего желтый или белый. Вопрос - а надо ли было городить огород?
Из того что делали "фо фан" - поставиили два лазерных дальномера (крошечная микруха, полно на али) внизу лестницы и сверху, и в момент начала движения оно мерило расстояние до идущего и подсвечивала область ступеней под ним другим цветом - смотрится круто, точно также нафиг не нужно.
У меня как раз и был вопрос - в рантайме в раст будет ли паника при уменьшении uint32 ниже нуля, как я понял из ответа - паника будет. Если не будет - тогда зачем все это делать ).
В Си ничего не будет - просто будет число = макисмальное число от типа переменной - ( то что вычли - 1 ).
Можно так. Но опять-же это лишь перекладывание сложности.
В приведенном вами случае, вы переложили ее в типы, если сделать класс "Корзина" - то сложность уйдет в нее.
Что до меня - я выберу последнее, так как в жизни корзина куда сложнее устроена (скидки, акции, товары бандлом, огрничение на товарные позиции не больше/не меньше, товарная позиция, которая идет только бандлом с дургим товаром и тд). ИМХО класс в этом случае будет куда более удобным.
Типы, естественно, никто не отменяет, но их я бы сделал просто наиболее универсальными и с ограничением только по edge-случаям.
Попытаюсь переформулировать все мной сказанное - засовывать сильные ограничения в типы и потом с ними танцевать куда сложнее, чем делать проверку при нормальном подходе к ООП.
Но да, в случае с типами будет доп. проверка на уровне компилятора - это плюс. Однако тесты все равно писать)
Сейчас крайности в томже TSe - народ пытается все в типы запихать, везде юзать дженерики - это приводит к такой жести при поддержке потом, что это целая тема для отдельной статьи - не надо так.
Естественно, но сути архитектурной проблемы с моей точки зрения это не меняет.
Я не силен в Rust, подскажите насчет баланса - вот если оно беззнаковое uin32 и = 0, что будет, если его уменьшить на, например, 5? Ибо в C это приведет просто к переполнению, что будет еще хуже, чем отрицательный баланс (там хоть понятно будет, на сколько ушло).
Ну и проверка типов тоже сомнительна - вы переложили валидацию в тип - окей, можно было, как было сказано выше, поставить валидацию в саму функцию - и это тоже не проблема (не надо вот только про лишние проверки, можно подумать что с типом их не будет на этапе парсинга). Но суть проблемы здесь - отсуствие класса user, где все это должно быть инкапсулировано, те это архитектурная, а не синтаксическая проблема, ИМХО.
Не надо сберегать тьму... (:
Дак у вас большинство сервисов в таком режиме спят, работает текущее окно ну и фоновое чуток (WinAmp).
А теперь возьмите и запустите архивацию чего-нибудь большого, штук 5 - сразу будет другая картина, характерная для серверной загрузки.
Да, вначале такое было часто, сейчас все реже и реже.
Спрашивается, зачем они вообще нужны? Есть озон, вб, все инструменты, онлайнтрейд, днс и али где можно найти дешевле и практически весь объем нужных товаров. Разве что пвз только от маркета есть и все. Обычно на нем на 10-15 процентов дороже.
Они давным-давно неимоверными силами управленцев убили некогда отличный сервис.
Вот и сейчас - хотите вы эти 20р заложить в заказ ну и заложите ее через продавца, зачем говорить об этом своим прлтзователям? Ещё больше от сервиса из оттолкнуть? Кто у них принимает такие решения? Почему эти кадры элементарную психологию они знают? Я хз. Впрочем, что мертво, умереть уже не может.
Причём часто сравниваю цены товаров и там и там и по статистике 90% распределяется от самой дешёвой цены к самой дорогой так (для не хайтек товаров):
wb
ozon
ali
market
megamarket
Для хайтека и инструментов по-другому и яндекс там в самом хвосте.
Понты ради понтов. Ну грифоны обязывают, понятно дело)
Я уж молчу что будет если зашел ты и сосед - куда поедет лифт вообще загадка.
А по-сути все это - чтобы хоть как-то оправдать и впарить метраж в этих золотых строениях.
Такая автоматизация обычно работает абсолютно не так как задумываось и только раздражает, ну и кончается это ее полным отключением.
Естественно, к приложению это не относится - вот это как раз нормально, что есть работа из него.
Кто опять очередной макаке микрофон дал?
С HDCP не встречал, для того, чтобы обойти это, можно поставить перед обычный сплиттер с hdcp, который отключает его на выходе
На вскидку первое что нашёл https://aliexpress.ru/item/1005006261227736.html
Сам не проверял - сразу скажу, но по виду похоже на то, что у меня работает.
Все эти кустарные амбилайты плохи тем, что для них необходимо что-то, что ими управляет.
В правильном амбилайте стоит только hdmi-splitter для захвата экрана и все (ну +питание ещё).
Поэтому, если реально хочется нормальной и безпрблемной подсветки - не берите эти поделки. Берите с HDMI разъёмом, пусть и дороже, но куда универсальней и стабильней.
Знаете, результат получился имхо - ужасный и не продающий, а вот те 3 баночки справа на первом рисунке как раз офигенны по дизайну и привлекательности, имхо опять же. И будет нормально смотреться даже на белой бутылке.
Грубо, если есть 3 подсайта - их, в отличии от монолита, можно разнести по 3 слабым компьютерам, или по 2. Это раз, во-вторых по производительности (но не по ресурсам) 3 подсайта будут работать быстрее, чем один монолит.
Поэтому ответ - да, помогут.
Естественно, при такой сложности, будет и дешевле и проще управляемей и проще обновляемей и безопасней. Недаром народ монолиты на микросервисы расколачивает (хотя, естественно и те и те имеют право на жизнь).
Пример - ваши программисты доьавляют код с уязвимостью на портал-монолит - этим компромитируют ВСЕ сервисы целиком, другой пример - добавляют его на корппортал на котором нет особо чувствительных данных - проблема есть но гораздо менее катострофичная. Другой пример - вам надо добавить новый функционал в какую либо часть монолита - требуется согласование и проверка на совместимость со всеми вашими системами и сервисами на монолите, или вдля одной системы - что проще?
Вы мешаете корппортал и совсем другие бизнес сервисы, которые должны быть отдельными системами (но да, можео сделать для них быстрые линки на портале).
Их все нужно делать отдельными системами, хотя-бы потому что функционал разнится очень сильно + предотвращение утечек, минимизация возможности взлома и диверсификация отказоустойчивости.
Корппотал - это то, что доступно ЛЮБОМУ сотруднику корпорации, независимо от должности или чего-то еще.
Никаких ЛК на корппоратле быть не должно. Именно из-за стремления свести все что только можно в него, он и превращается в неюзабельную помойку.