у меня не большой опыт, но вижу проблему с эво - тут же чистый маркетинг. потрясающий способ внушить потребителю, что у его копия приложения уже устарела, без аргументации в чем именно.
мне пришлось порядком покопаться в легаси, при отсутствии нормального описания зависимостей пактов. четкий semver давал хоть какую-то надежду, что libA:1.4.26b4 о которой нигде не сохранилось какое либо описание функциональности, но которая мне нужна из-за ряда других зависимостей хоть как-то похожа по поведению на libA:1.4.30, для которой есть документация и changelog.
и я понятия не имею сколько бы я еще часов угрохал (в т.ч. с иишкой), если бы мне потребалось проводить серию обновлений среди пакетов, версия которых именовалась поэтичными названиями с датами релиза
а если мне нужно дополнительно настроить окружение, что не делается программно из приложения? например: шрифты, сертификаты, всякие oracle instant client...
сложное.. вы предлагаете избавиться от костылей, и оптимизировать сложную цепочку простых операций сжав ее в конкретные аппаратные специализированные компоненты?
я в этом вижу появление asic, видеокарт как отдельных от проца модулей, компонентов для ускорения вычислений для нейросетей в SoC , или же появление логарифмической линейки.
т.е. либо специализация, либо универсальность. этот вечный треугольник деньги/скорость/качество.
пока будет потребность от одной и той же машины требовать диаметрально противоположных задач и будут эти костыли.
конечно можно уже сейчас что-то упростить и оптимизировать, но как правило это будет означать отказ от чего-то старого в погоне за новым. и сново возврат к эмуляции/имитации старого, потому что это "новое" не смогло решить старую задачу качественно.
занятная заметка. трансформация типов данных между разными частями приложения знатная боль, а тут опыт миграции между специфическими типами разных систем.
у меня не большой опыт. натыкаясь на подобные статьи у меня возникает вопрос: А стоит ли настолько сильно приростать к конкретной СУБД/фреймворку, используя уникальные типы данных или наращивая метаструктуру, снижая поддерживаемость конечного ПО? неужели профит настолько ценнен, чтобы проглатывать горсть синтаксического сахара, а потом потеть на миграциях и конвертациях данных и логики?
никак не пойму как современные "чат-боты" способны полностью заменить человеческий труд. да, нейросеть может дополнить, ответ на какую-то проблему, из своей базы; может набросать примерный путь решения; "внезапно" вытащить нужный осколок знаний. но такие информационные полуфабрикаты не заменяют натурального синтеза знаний. а если есть такие задачи, присутствие в которых бота сводит на нет человеческую деятельность - не значит ли, что деятельность избыточна?
у меня не большой опыт, но вижу проблему с эво - тут же чистый маркетинг. потрясающий способ внушить потребителю, что у его копия приложения уже устарела, без аргументации в чем именно.
мне пришлось порядком покопаться в легаси, при отсутствии нормального описания зависимостей пактов. четкий semver давал хоть какую-то надежду, что libA:1.4.26b4 о которой нигде не сохранилось какое либо описание функциональности, но которая мне нужна из-за ряда других зависимостей хоть как-то похожа по поведению на libA:1.4.30, для которой есть документация и changelog.
и я понятия не имею сколько бы я еще часов угрохал (в т.ч. с иишкой), если бы мне потребалось проводить серию обновлений среди пакетов, версия которых именовалась поэтичными названиями с датами релиза
Очень сомнительно. будет весело, если окажется что сервис уже прощупали на уязвимости и слили инфу
окэ, оно интергируется в этап "сборка исходников"
а если мне нужно дополнительно настроить окружение, что не делается программно из приложения? например: шрифты, сертификаты, всякие oracle instant client...
сложное.. вы предлагаете избавиться от костылей, и оптимизировать сложную цепочку простых операций сжав ее в конкретные аппаратные специализированные компоненты?
я в этом вижу появление asic, видеокарт как отдельных от проца модулей, компонентов для ускорения вычислений для нейросетей в SoC , или же появление логарифмической линейки.
т.е. либо специализация, либо универсальность. этот вечный треугольник деньги/скорость/качество.
пока будет потребность от одной и той же машины требовать диаметрально противоположных задач и будут эти костыли.
конечно можно уже сейчас что-то упростить и оптимизировать, но как правило это будет означать отказ от чего-то старого в погоне за новым. и сново возврат к эмуляции/имитации старого, потому что это "новое" не смогло решить старую задачу качественно.
занятная заметка. трансформация типов данных между разными частями приложения знатная боль, а тут опыт миграции между специфическими типами разных систем.
у меня не большой опыт. натыкаясь на подобные статьи у меня возникает вопрос: А стоит ли настолько сильно приростать к конкретной СУБД/фреймворку, используя уникальные типы данных или наращивая метаструктуру, снижая поддерживаемость конечного ПО? неужели профит настолько ценнен, чтобы проглатывать горсть синтаксического сахара, а потом потеть на миграциях и конвертациях данных и логики?
ну почему же "душнилой" ? мы же здесь за интересностями, а не "сделать как надо". такие факты и ньюансы полезны в раскопках нужного метода-решения
никак не пойму как современные "чат-боты" способны полностью заменить человеческий труд. да, нейросеть может дополнить, ответ на какую-то проблему, из своей базы; может набросать примерный путь решения; "внезапно" вытащить нужный осколок знаний. но такие информационные полуфабрикаты не заменяют натурального синтеза знаний. а если есть такие задачи, присутствие в которых бота сводит на нет человеческую деятельность - не значит ли, что деятельность избыточна?
поддерживаю. Одноплатники стоят столько, что использовать их как "single-use" рука не поднимется