Ну как сказать... Стоит добавить статического контекста, описывающего архитектуру и правила реализации компонентов приложения, то часто код становится сильно чище. А если этот документ ещё и обновлять периодически. То в итоге можно придти к достаточно качественным результатам.
Да и вообще пора бы уже готовить инженеров специализирующихся на реверс-инжиниринге. Там ведь то же свои моменты специфические есть. Анализ материалов только чего стоит.
На самом деле ничего страшного. Для большинства пользователей у них комфортные условия, мне для работы хватает. Ну а если ты сверх активно используешь сервисы, ну значит плати больше. По факту для большинства цены и лимиты на приемлемом уровне
То же читал пару лет назад. Правда очень и очень странно что ребята выбрали Python в качестве языка реализации высоко нагруженного проекта европейского интернет магазина. (Хотя это может и просто легенда)
Mobx лучше всего использовать в режиме классов. В функциональном стиле то еще удовольствие. Но по сути да. Классы это самодокументируемые структуры их можно ипользовать и без интерфейсов. В valtio будет та же проблема что и в функциональном mobx что для стейта вам нужно описать интерфейс а потом реализовать сам стейт. что увеличивает накладные расходы по времени в +-2 раза.
На сколько я знаю "Андрей Карпаты выступая на Международной конференции по компьютерному зрению 2021 (CVPR), объяснил, почему компания не собирается использовать лидары при разработке технологий автономного вождения."
И я с ним согласен. Мир динамический. Карты устаревают. А самое главное опираться на не надёжную информацию путь к ошибкам. Лидарам нужны эти карты.
Кроме того, это количество обрабатываемой информации. У Лидаров это на порядок более большие объемы.
В целом ставка сделана на обучение моделей на огромном массиве исторических данных, которая и должна привести к надёжному определению дорожной обстановки. Это как большие языковые модели. Если так в году 19 все баловались модельками с несколькими миллионами параметров, ну и собственно получали что то сильно глючное. То миллиардные сети уже дают надёжные ответы. Поэтому увеличение корпуса данных для обучения важнее увеличения объема поступающей информации во время инфиренса
"В целом, есть подходы, связанные с фотоникой или, например, нейроморфными вычислениями. Но они сильно отстают по качеству.
К тому же, люди, которые этим занимаются, больше увлечены физикой, а не ML. Поэтому часто эти работы не уходят дальше "ого, это заработало на MNIST'e". Прорыв будет, когда это заработает для LLM. Пока что здесь есть большой gap между разработчиками железа, разработчиками архитектур и бизнесменами.
В short term я бы ставил на диффузионные языковые модели. Пару лет назад они были плохи, а сейчас их научились обучать, и оказалось, что они работают неплохо. Сейчас уже есть настоящая диффузионная LLM – Gemini Diffusion. У нее большой выигрыш на инференсе: она дает сильно больше токенов в секунду. Это серьезный аргумент в пользу конкуренции с трансформером"
И ещё как любит говорить господин Дугин - Симулякр. В компаниях если на тебе не висит реальной ответственности, то это превращается в Симулякр. Поэтому и выходит что так как СЕО это последний из "козлов отпущения", то ему вольно-невольно приходится делать что то ценное.
Не плохо. Как раз есть определенный запрос в моем проекте на что то подобное. Но задача, реализации мультибрендового проекта. Когда у тебя есть специфичные бренду компоненты и они оверврайтят базовые компоненты проекта.
Ну как сказать... Стоит добавить статического контекста, описывающего архитектуру и правила реализации компонентов приложения, то часто код становится сильно чище. А если этот документ ещё и обновлять периодически. То в итоге можно придти к достаточно качественным результатам.
На практике, если команда меняется и нет сильного контроля за PR, то FSD превращается в помойку и не ясно уже где искать widgets, features, e t.c
Да и вообще пора бы уже готовить инженеров специализирующихся на реверс-инжиниринге. Там ведь то же свои моменты специфические есть. Анализ материалов только чего стоит.
На самом деле ничего страшного. Для большинства пользователей у них комфортные условия, мне для работы хватает. Ну а если ты сверх активно используешь сервисы, ну значит плати больше. По факту для большинства цены и лимиты на приемлемом уровне
Надо больше тестостерона сотрудникам предприятия. Им. Макеева
Вы забыли картинку превью отмасштабировать. Вылазит за рамки
Не используйте nginx, используйте caddy. В caddy lets encrypt из коробки.
Не знаю я и фар с трудом осваиваю MC пока что юзаю
То же читал пару лет назад. Правда очень и очень странно что ребята выбрали Python в качестве языка реализации высоко нагруженного проекта европейского интернет магазина. (Хотя это может и просто легенда)
А чё с где Редис? Или я что то упустил
Вы забыли исключить из своего списка "селфхостед облачные". Так или иначе вам нужна отказоустойчивая точка входа.
Mobx лучше всего использовать в режиме классов. В функциональном стиле то еще удовольствие. Но по сути да. Классы это самодокументируемые структуры их можно ипользовать и без интерфейсов. В valtio будет та же проблема что и в функциональном mobx что для стейта вам нужно описать интерфейс а потом реализовать сам стейт. что увеличивает накладные расходы по времени в +-2 раза.
На сколько я знаю "Андрей Карпаты выступая на Международной конференции по компьютерному зрению 2021 (CVPR), объяснил, почему компания не собирается использовать лидары при разработке технологий автономного вождения."
И я с ним согласен. Мир динамический. Карты устаревают. А самое главное опираться на не надёжную информацию путь к ошибкам. Лидарам нужны эти карты.
Кроме того, это количество обрабатываемой информации. У Лидаров это на порядок более большие объемы.
В целом ставка сделана на обучение моделей на огромном массиве исторических данных, которая и должна привести к надёжному определению дорожной обстановки. Это как большие языковые модели. Если так в году 19 все баловались модельками с несколькими миллионами параметров, ну и собственно получали что то сильно глючное. То миллиардные сети уже дают надёжные ответы. Поэтому увеличение корпуса данных для обучения важнее увеличения объема поступающей информации во время инфиренса
"В целом, есть подходы, связанные с фотоникой или, например, нейроморфными вычислениями. Но они сильно отстают по качеству.
К тому же, люди, которые этим занимаются, больше увлечены физикой, а не ML. Поэтому часто эти работы не уходят дальше "ого, это заработало на MNIST'e". Прорыв будет, когда это заработает для LLM. Пока что здесь есть большой gap между разработчиками железа, разработчиками архитектур и бизнесменами.
В short term я бы ставил на диффузионные языковые модели. Пару лет назад они были плохи, а сейчас их научились обучать, и оказалось, что они работают неплохо. Сейчас уже есть настоящая диффузионная LLM – Gemini Diffusion. У нее большой выигрыш на инференсе: она дает сильно больше токенов в секунду. Это серьезный аргумент в пользу конкуренции с трансформером"
"В ближайшем будущем диффузионные текстовые модели могут заменить трансформеры", – Иван Оселедец, гендир AIRI
И ещё как любит говорить господин Дугин - Симулякр. В компаниях если на тебе не висит реальной ответственности, то это превращается в Симулякр. Поэтому и выходит что так как СЕО это последний из "козлов отпущения", то ему вольно-невольно приходится делать что то ценное.
И те кто может разделить успех побед...
Извините но я процетирую себя от 28.02.25 :
"На самом деле это главная новость за последние 8 лет. С момента появления трансформеров"
Не плохо. Как раз есть определенный запрос в моем проекте на что то подобное. Но задача, реализации мультибрендового проекта. Когда у тебя есть специфичные бренду компоненты и они оверврайтят базовые компоненты проекта.
Go уже выбивается. Крупные игроки переходят на Rust. Так как он без сборщика мусора - а значит оверхеда ещё меньше.