Лучше писать код, который подойдёт под потребности бизнеса. Возможно, при ограниченных ресурсах ему будут важнее дополнительный функционал или дешёвая стоимость mvp, чтобы проверить больше идей на рентабельность.
Эмпатия необходима, но такой фокус на ней - тоже крайность и не выход. Если следовать эмпатии, то вы неизбежно погрязнете в субъективности эмоций, и ваша стратегия будет определяться некоторой случайностью текущего настроения людей. Эмпатия больше полезна для внутреннего управления командой. Когда речь идёт про определение глобальной стратегии(product owner), то тут большую ценность несёт понимание текущего состояния рынка. Так что некоторая доля цинизма, возможно, будет более полезна для CEO, чем эмпатия.
А как вы ответите на вопрос: почему spring еще не реализовал эти абстракции у себя, если это такая хорошая идея, и соответствует философии spring по устранению шаблонного кода? Вряд ли, они просто не додумались.
Я думаю ответ как раз в том - что текущий уровень абстракций инструментов оптимальный по соотношению функционал/гибкость.
Ну и для простых crud также spring data rest подойдёт.
Когда я был джуном, мне казалось, что круд на дженериках - хорошая идея.
Сейчас четко вижу, что такой общий код для сеньера станет обременением - если появится какой-то новый кастом(захотим файлы грузить), то вносить изменение в общее ядро станет долго и дорого.
Если же компания нанимает армию джунов, то для их контроля может быть разумным применение таких ограничений общего фраемворка. Но тогда уж лучше пойти по применению какого-нибудь jhipster.
Тоже такое чувство было при чтении статьи. От журнала миграции БД потенциально зависят все компоненты, которые используют данную БД. Добавление лишнего слоя процессинга в миграции не решит эту принципиальную проблему, а только все усложняет.
Нужно просто иметь модульную систему, независимые БД, достаточно малые, чтобы разработчики редко мешали другу другу в изменениях, и просто использовать инструмент для миграций. Ну и интегрироваться на уровне api, а не через базу.
Я работаю над разработкой BI системы, которая выполняет анализ данных по запросу на естественном языке.
Сейчас тестируем агентов на базе langchain. Вы не рассматривали данные решения? Там уже есть готовый агент, который может собрать всю необходимую информацию по схеме и данным в БД.
Если вам нужна строгая согласованность данных, то в случае больших систем по cap теореме вам придется идти на другие уступки.
Поэтому в больших системах сейчас так или иначе используют распределенные хранилища, которые можно строго согласовать только с недопустимыми для больших нагрузок последствиями. Поэтому в редких местах распределенные по разным бд транзакции решают сделать через сообщения, как некоторый компромисс.
Если переходить к DDD, то стратегические паттерны помогают найти в каких местах стоит делать этот компромисс, а тактические предлагают оформить это в виде саг.
Если у вас вся логика работает в рамках одной OLTP БД, то все компоненты этой логики будут потенциально сильно связанны со всей схемой данной БД. В таком случае по DDD вам будет тоже рациональней сделать 1 ограниченный контекст и согласованность данных в нем можно также контролировать с помощью движка БД используя при этом тактические паттерны DDD как обычно.
Но также имеют место быть решения in memory data grid с поддержкой sql, а также распределенные кластеры с архивацией данных на диске, которые могут просканировать весь объем за быстрое время. Такие решения как раз используются, когда данные анализируются на лету, без построения индексов.
Расскажите, пожалуйста, в чем преимущества использования kotlin-специализированной библиотеки dokker перед более популярной jvm библиотекой testcontainers? При использовании последней, на мой взгляд, и так декларируется необходимая для тестов информация максимально простым способом.
Опять таки, подумайте насчёт того, чтобы купить убитый кайт за 5-10к рублей и дошить его. Какой-нибудь бандит 10 летней давности имеет характеристики очень близкие к современным кайтам.
Ещё популярное направление - крафтить гидрофойлы. Можно относительно просто реализовать весьма дорогую штуку, а также его можно использовать с кайтом в неветровых местах и кататься на порядок чаще.
Я разрабатываю BI систему, знаю что они сейчас в топе трендов. Просто конкретно olap спецификации запросов к БД утратили актуальность. Сейчас агрегационые запросы для аналитики выглядят так - ставится какая-нибудь столбовая БД типа cassandra, click house, druid и просто пишутся запросы group by. Провайдер БД представляет различные агрегационые операторы, начиная от расчета квантилей до исполнения касстомного скрипта.
Думаю вы приносите много пользы вашим проектам. На моём опыте, обычно в команде есть продавец, продающий продукт и новые фичи заказчику, и аналитики, которые выполняют роль внутренних системных аналитиков, и на которых ещё навешивают роль тестировщиков для экономии издержек передачи информации. При этом получается, что продавец далёк от системных проблем, а аналитики упускают ценность для заказчика и выдумывают много лишнего функционала, без предварительного понимания реальных проблем. Таким образом вроде бы, очевидно, что не хватает звена бизнес аналитика, но в реальности наблюдал такие проблемы во многих компаниях.
low coupling and high cohesion
Лучше писать код, который подойдёт под потребности бизнеса. Возможно, при ограниченных ресурсах ему будут важнее дополнительный функционал или дешёвая стоимость mvp, чтобы проверить больше идей на рентабельность.
Подскажите, пожалуйста, если используется строгое ограниченное декодирование, то зачем задавать LLM схему ответа внутри промпта на естественном языке?
Это либо хорошая постирония, либо уже какая-то шизофрения
Эмпатия необходима, но такой фокус на ней - тоже крайность и не выход. Если следовать эмпатии, то вы неизбежно погрязнете в субъективности эмоций, и ваша стратегия будет определяться некоторой случайностью текущего настроения людей. Эмпатия больше полезна для внутреннего управления командой. Когда речь идёт про определение глобальной стратегии(product owner), то тут большую ценность несёт понимание текущего состояния рынка. Так что некоторая доля цинизма, возможно, будет более полезна для CEO, чем эмпатия.
Именно так реальность будет расходиться со сказкой из статьи на каждом шагу
А как вы ответите на вопрос: почему spring еще не реализовал эти абстракции у себя, если это такая хорошая идея, и соответствует философии spring по устранению шаблонного кода? Вряд ли, они просто не додумались.
Я думаю ответ как раз в том - что текущий уровень абстракций инструментов оптимальный по соотношению функционал/гибкость.
Ну и для простых crud также spring data rest подойдёт.
Когда я был джуном, мне казалось, что круд на дженериках - хорошая идея.
Сейчас четко вижу, что такой общий код для сеньера станет обременением - если появится какой-то новый кастом(захотим файлы грузить), то вносить изменение в общее ядро станет долго и дорого.
Если же компания нанимает армию джунов, то для их контроля может быть разумным применение таких ограничений общего фраемворка. Но тогда уж лучше пойти по применению какого-нибудь jhipster.
Тоже такое чувство было при чтении статьи. От журнала миграции БД потенциально зависят все компоненты, которые используют данную БД. Добавление лишнего слоя процессинга в миграции не решит эту принципиальную проблему, а только все усложняет.
Нужно просто иметь модульную систему, независимые БД, достаточно малые, чтобы разработчики редко мешали другу другу в изменениях, и просто использовать инструмент для миграций. Ну и интегрироваться на уровне api, а не через базу.
Я работаю над разработкой BI системы, которая выполняет анализ данных по запросу на естественном языке.
Сейчас тестируем агентов на базе langchain. Вы не рассматривали данные решения? Там уже есть готовый агент, который может собрать всю необходимую информацию по схеме и данным в БД.
Если вам нужна строгая согласованность данных, то в случае больших систем по cap теореме вам придется идти на другие уступки.
Поэтому в больших системах сейчас так или иначе используют распределенные хранилища, которые можно строго согласовать только с недопустимыми для больших нагрузок последствиями. Поэтому в редких местах распределенные по разным бд транзакции решают сделать через сообщения, как некоторый компромисс.
Если переходить к DDD, то стратегические паттерны помогают найти в каких местах стоит делать этот компромисс, а тактические предлагают оформить это в виде саг.
Если у вас вся логика работает в рамках одной OLTP БД, то все компоненты этой логики будут потенциально сильно связанны со всей схемой данной БД. В таком случае по DDD вам будет тоже рациональней сделать 1 ограниченный контекст и согласованность данных в нем можно также контролировать с помощью движка БД используя при этом тактические паттерны DDD как обычно.
Но также имеют место быть решения in memory data grid с поддержкой sql, а также распределенные кластеры с архивацией данных на диске, которые могут просканировать весь объем за быстрое время. Такие решения как раз используются, когда данные анализируются на лету, без построения индексов.
Стоит добавить пару слов про dependency inversion
И кнопке "сделай игру про караваны"
Расскажите, пожалуйста, в чем преимущества использования kotlin-специализированной библиотеки dokker перед более популярной jvm библиотекой testcontainers? При использовании последней, на мой взгляд, и так декларируется необходимая для тестов информация максимально простым способом.
Опять таки, подумайте насчёт того, чтобы купить убитый кайт за 5-10к рублей и дошить его. Какой-нибудь бандит 10 летней давности имеет характеристики очень близкие к современным кайтам.
Ещё популярное направление - крафтить гидрофойлы. Можно относительно просто реализовать весьма дорогую штуку, а также его можно использовать с кайтом в неветровых местах и кататься на порядок чаще.
Я разрабатываю BI систему, знаю что они сейчас в топе трендов. Просто конкретно olap спецификации запросов к БД утратили актуальность. Сейчас агрегационые запросы для аналитики выглядят так - ставится какая-нибудь столбовая БД типа cassandra, click house, druid и просто пишутся запросы group by. Провайдер БД представляет различные агрегационые операторы, начиная от расчета квантилей до исполнения касстомного скрипта.
Думаю вы приносите много пользы вашим проектам. На моём опыте, обычно в команде есть продавец, продающий продукт и новые фичи заказчику, и аналитики, которые выполняют роль внутренних системных аналитиков, и на которых ещё навешивают роль тестировщиков для экономии издержек передачи информации. При этом получается, что продавец далёк от системных проблем, а аналитики упускают ценность для заказчика и выдумывают много лишнего функционала, без предварительного понимания реальных проблем. Таким образом вроде бы, очевидно, что не хватает звена бизнес аналитика, но в реальности наблюдал такие проблемы во многих компаниях.