Интересно увидеть, как на практике репозиторный слой держит границу транзакции. Выглядит сомнительно.
Вот банальный пример. Допустим, у вас есть юзкейс (в вашей классификации это второй "сервисный" слой). В нём необходимо выполнить регистрацию пользователя. Следовательно, это чтение из БД (проверка существования), затем запись в БД (свежий пользователь), а затем запись события в outbox (отдельная от пользователя таблица) и опционально запись события о регистрации для аудита (также отдельная таблица).
И если у вас транзакция держится на уровне UserRepository, то вам придётся пихать в репозиторий знания о том, что есть outbox и есть аудит. Это очень грязно.
По моему скромному опыту границы транзакций всё-таки определяются на уровне юзкейсов, а не на уровне репозиториев.
Markdown-файлов можно сделать несколько и связать их ссылками.
Безусловно, если хочется изобрести свой велосипед, то никто ни в силах помешать. Но преимущества этого велосипеда высосаны из пальца и не выдерживают критики.
Для IDE семейства IDEA давно существует "pycharm-index" и его близнецы. Решает ту же задачу, но через встроенные инструменты IDE. Найти всех наследников, объявления или использования класса\метода - моментально. Плюс умеет в умное переименование и перемещение, а также забирает результаты диагностики IDE, подхватывая ошибки синтаксиса, дублирование и прочее.
С точностью до наоборот. Вы видели требования к джунам? А количество вакансий?
Порог входа вырос, а не снизился, потому что джуны, работающие на уровне LLM, больше не пользуются спросом.
А если вы под "входом в сферу" подразумеваете то, что теперь любители могут проще сваять для себя поделку, которой кроме этого любителя никто и никогда не воспользуется - так это подмена понятий. Давайте тогда говорить, что мультиварки снизили порог входа в ресторанную сферу, потому что теперь любители могут быстрее и проще готовить для себя шаблонные блюда.
Тема статьи была очень интересна. Но прочитав её до конца, я остался разочарован, так как ответа на вопрос из заголовка в ней нет. Вместо него - поток сознания на смежные темы, пусть и слегка причёсанный перед публикацией.
Не можно. Автор же прямо в первом абзаце описывает сценарий:
Иногда бывает нужно запустить рабочие программы так, чтобы отделить их от ОС (не устанавливать поверх системы, использовать другие библиотеки, сформировать portable пакет и т.д.).
Каждый раз полностью откатывать систему к начальному состоянию - нерационально. Контейнер-песочница куда проще и быстрее.
Какое-то костыльное переизобретение тестов получилось. Вот только тесты детерминированы, а "исполняемую спецификацию" агент может частично проигнорировать, если она сложна.
К тому же тесты можно запустить вручную и\или встроить в пайплайн CI\CD. А "исполняемую спецификацию" - нет.
Получилось изобретение ради изобретения, работающее хуже, чем нативные тесты.
Голимый нейрослоп. Вы в следующий раз сделайте ещё проще: опубликуйте промпт, пусть хабраюзеры сами его в LLM введут, а все плюсики вам поставят за очень полезный труд.
Пробовал подключиться через API (юзаю официальный плагин для PyCharm), но почему-то контекст с первого же запроса раздувается до сотни тысяч токенов, в итоге буквально несколько запросов съедают 1млн+ токенов и работа с моделью становится просто золотой.
При использовании подписки такого не происходит и лимит тратится очень медленно.
Сценарий использования, промпты, кодовая база - всё идентично в обоих случаях. Не сталкивались с таким?
Да, то же самое. Сочи, Dtel. Пока не отправляются реальные запросы, соединение держится. Как только отправляется https-запрос через браузер - тут же разрывается. При этом https-запросы не через браузер не приводят к разрыву соединения.
Именно об этом я и говорю :) Вы шлёпаете простенькие проекты с жизненным циклом 2 недели (!) в то время, как 90% индустрии занимается совершенно другими вещами, ощутимо более сложными. Затем вы экстраполируете свой опыт из микропроектов на всю отрасль и делаете весьма сомнительные выводы. Эти выводы естественно оспариваются теми, кто работает над полноценными проектами, потому что их опыт говорит о полностью противоположном.
Приведу простую аналогию. Допустим, вы строите гаражи. И тут Boston Dynamics выпускает робота, который умеет строить гаражи любых цветов и размеров. Вы пишете статью: "В будущем сопромат будет не нужен, ведь робот уже умеет строить сам!". После чего проектировщики, рассчитывающие сложные металлоконструкции и использующие в работе всякие там ЛИРА и Advance Steel, крутят пальцем у виска, а вы искренне считаете, что они тупые, а вам виднее, ведь вы этих гаражей по 10 штук каждый месяц заказчикам сдаёте без всякого там сопромата и прочей ненужной мути.
Вот только, повторюсь, 90% строительной отрасли не гаражи строит. И такие выводы насчёт сопромата от строителя гаражей их действительно насмешат.
Но ведь изначально вы чётко говорили о бизнесе в целом, а теперь оказывается, что речь уже только про MVP для проверки гипотезы?
Так тут же соотношение хорошо если 1 к 10 (на 1 разраба, пилящего MVP, приходится 10 разрабов, развивающих зрелый продукт). А скорее всего ещё хуже.
Безусловно, если ваша сфера деятельности - штамповать телеграм-ботов для кальянных, то конечно, вайбкодинг рулит, все дела. У заказчика бюджет 30 тысяч и те в рассрочку. А вот давайте мы с вами посмотрим на РЕАЛЬНЫЙ бизнес, в котором вращается 90% всех денег в IT: финтех, ритейл, телеком, промышленность. Там 1 задача может занимать десятки и сотни человекочасов. И что говорите, что для них говнокод - это вообще не проблема, да? :)
Ну то есть придут нам новые правила резервирования товаров на складах, и будем мы вместо 20 часов вносить эти правки 200 часов, потому что у нас сотни тысяч строк разношёрстного говнокода, в котором никто не ориентируется, потому что на этапе написания никто в него не вникал. Зато когда мы пилили MVP, мы его сделали за 1 месяц, а не за 3. Звучит очень выгодно, нужно внедрять в каждый бизнес безотлагательно.
Вот смотрите, я вас попросил показать факты. Вы в ответ выдаёте фантазию, причём ещё и тему пытаетесь в сторону увести. Очевидная логическая ошибка, но похоже, что очевидная не для всех.
Давайте я вам контекст разговора напомню. Хотя он состоит всего из пары сообщений, но вы уже успели его потерять. Я попросил показать конкретные кейсы трудоустройства вайбкодеров на реальную работу за деньги. Потому что среди моих коллег нет ни одного вайбкодера, и мне искренне интересно, неужели хоть какие-то работодатели на полном серьёзе доверяют IT-инфраструктуру бизнеса ллм-обезьянкам, которые просто генерят код без понимания?
А прибыль как считается, не напомните? Я всегда считал, что это доходы минус расходы, а говнокод - это огромные расходы из-за быстрого роста стоимости каждой новой фичи.
Видимо, я очень сильно заблуждаюсь. Расскажите, пожалуйста, как всё устроено на самом деле.
А покажите конкретные примеры трудоустройства вайбкодеров на реальную работу, пожалуйста. А то у меня ни одного коллеги-вайбкодера почему-то нет и даже сама мысль кажется смешной.
Ну и ну. Мало того, что все зависимости будут при каждом билде с нуля выкачиваться из репозитория, так ещё и в композе идёт бессмысленное дублирование части докерфайла.
Вы уверены, что вам не рановато писать туториалы по докеру? Как будто бы стоит сначала самому разобраться, а потом уже пытаться писать обучающие статьи.
Или можно просто использовать loguru, в котором уже давно реализовано всё описанное и ещё куча дополнительных фич вроде авторотации лог-файлов раз в период или по достижению определенного размера.
А собранные данные на корректность проверяли? Год назад WB в таких ситуациях подсовывал фейковые данные. То есть запросы они не блочили, а просто по-тихому наливали трэша в части ответов.
Сколько раз на вашей памяти эти дряхлые обезьяны учитывали реалии, когда выпускали очередной "гениальный" законопроект или сборник рекомендаций?
Интересно увидеть, как на практике репозиторный слой держит границу транзакции. Выглядит сомнительно.
Вот банальный пример. Допустим, у вас есть юзкейс (в вашей классификации это второй "сервисный" слой). В нём необходимо выполнить регистрацию пользователя. Следовательно, это чтение из БД (проверка существования), затем запись в БД (свежий пользователь), а затем запись события в outbox (отдельная от пользователя таблица) и опционально запись события о регистрации для аудита (также отдельная таблица).
И если у вас транзакция держится на уровне UserRepository, то вам придётся пихать в репозиторий знания о том, что есть outbox и есть аудит. Это очень грязно.
По моему скромному опыту границы транзакций всё-таки определяются на уровне юзкейсов, а не на уровне репозиториев.
Markdown-файлов можно сделать несколько и связать их ссылками.
Безусловно, если хочется изобрести свой велосипед, то никто ни в силах помешать. Но преимущества этого велосипеда высосаны из пальца и не выдерживают критики.
Для IDE семейства IDEA давно существует "pycharm-index" и его близнецы. Решает ту же задачу, но через встроенные инструменты IDE. Найти всех наследников, объявления или использования класса\метода - моментально. Плюс умеет в умное переименование и перемещение, а также забирает результаты диагностики IDE, подхватывая ошибки синтаксиса, дублирование и прочее.
Зачем вводить тег, который будет нужен 1 раз в 5 лет?
С точностью до наоборот. Вы видели требования к джунам? А количество вакансий?
Порог входа вырос, а не снизился, потому что джуны, работающие на уровне LLM, больше не пользуются спросом.
А если вы под "входом в сферу" подразумеваете то, что теперь любители могут проще сваять для себя поделку, которой кроме этого любителя никто и никогда не воспользуется - так это подмена понятий. Давайте тогда говорить, что мультиварки снизили порог входа в ресторанную сферу, потому что теперь любители могут быстрее и проще готовить для себя шаблонные блюда.
Тема статьи была очень интересна. Но прочитав её до конца, я остался разочарован, так как ответа на вопрос из заголовка в ней нет. Вместо него - поток сознания на смежные темы, пусть и слегка причёсанный перед публикацией.
Не можно. Автор же прямо в первом абзаце описывает сценарий:
Каждый раз полностью откатывать систему к начальному состоянию - нерационально. Контейнер-песочница куда проще и быстрее.
Какое-то костыльное переизобретение тестов получилось. Вот только тесты детерминированы, а "исполняемую спецификацию" агент может частично проигнорировать, если она сложна.
К тому же тесты можно запустить вручную и\или встроить в пайплайн CI\CD. А "исполняемую спецификацию" - нет.
Получилось изобретение ради изобретения, работающее хуже, чем нативные тесты.
Голимый нейрослоп. Вы в следующий раз сделайте ещё проще: опубликуйте промпт, пусть хабраюзеры сами его в LLM введут, а все плюсики вам поставят за очень полезный труд.
Пробовал подключиться через API (юзаю официальный плагин для PyCharm), но почему-то контекст с первого же запроса раздувается до сотни тысяч токенов, в итоге буквально несколько запросов съедают 1млн+ токенов и работа с моделью становится просто золотой.
При использовании подписки такого не происходит и лимит тратится очень медленно.
Сценарий использования, промпты, кодовая база - всё идентично в обоих случаях. Не сталкивались с таким?
Да, то же самое. Сочи, Dtel. Пока не отправляются реальные запросы, соединение держится. Как только отправляется https-запрос через браузер - тут же разрывается. При этом https-запросы не через браузер не приводят к разрыву соединения.
Именно об этом я и говорю :) Вы шлёпаете простенькие проекты с жизненным циклом 2 недели (!) в то время, как 90% индустрии занимается совершенно другими вещами, ощутимо более сложными. Затем вы экстраполируете свой опыт из микропроектов на всю отрасль и делаете весьма сомнительные выводы. Эти выводы естественно оспариваются теми, кто работает над полноценными проектами, потому что их опыт говорит о полностью противоположном.
Приведу простую аналогию. Допустим, вы строите гаражи. И тут Boston Dynamics выпускает робота, который умеет строить гаражи любых цветов и размеров. Вы пишете статью: "В будущем сопромат будет не нужен, ведь робот уже умеет строить сам!". После чего проектировщики, рассчитывающие сложные металлоконструкции и использующие в работе всякие там ЛИРА и Advance Steel, крутят пальцем у виска, а вы искренне считаете, что они тупые, а вам виднее, ведь вы этих гаражей по 10 штук каждый месяц заказчикам сдаёте без всякого там сопромата и прочей ненужной мути.
Вот только, повторюсь, 90% строительной отрасли не гаражи строит. И такие выводы насчёт сопромата от строителя гаражей их действительно насмешат.
Но ведь изначально вы чётко говорили о бизнесе в целом, а теперь оказывается, что речь уже только про MVP для проверки гипотезы?
Так тут же соотношение хорошо если 1 к 10 (на 1 разраба, пилящего MVP, приходится 10 разрабов, развивающих зрелый продукт). А скорее всего ещё хуже.
Безусловно, если ваша сфера деятельности - штамповать телеграм-ботов для кальянных, то конечно, вайбкодинг рулит, все дела. У заказчика бюджет 30 тысяч и те в рассрочку. А вот давайте мы с вами посмотрим на РЕАЛЬНЫЙ бизнес, в котором вращается 90% всех денег в IT: финтех, ритейл, телеком, промышленность. Там 1 задача может занимать десятки и сотни человекочасов. И что говорите, что для них говнокод - это вообще не проблема, да? :)
Ну то есть придут нам новые правила резервирования товаров на складах, и будем мы вместо 20 часов вносить эти правки 200 часов, потому что у нас сотни тысяч строк разношёрстного говнокода, в котором никто не ориентируется, потому что на этапе написания никто в него не вникал. Зато когда мы пилили MVP, мы его сделали за 1 месяц, а не за 3. Звучит очень выгодно, нужно внедрять в каждый бизнес безотлагательно.
Вот смотрите, я вас попросил показать факты. Вы в ответ выдаёте фантазию, причём ещё и тему пытаетесь в сторону увести. Очевидная логическая ошибка, но похоже, что очевидная не для всех.
Давайте я вам контекст разговора напомню. Хотя он состоит всего из пары сообщений, но вы уже успели его потерять. Я попросил показать конкретные кейсы трудоустройства вайбкодеров на реальную работу за деньги. Потому что среди моих коллег нет ни одного вайбкодера, и мне искренне интересно, неужели хоть какие-то работодатели на полном серьёзе доверяют IT-инфраструктуру бизнеса ллм-обезьянкам, которые просто генерят код без понимания?
А прибыль как считается, не напомните? Я всегда считал, что это доходы минус расходы, а говнокод - это огромные расходы из-за быстрого роста стоимости каждой новой фичи.
Видимо, я очень сильно заблуждаюсь. Расскажите, пожалуйста, как всё устроено на самом деле.
А покажите конкретные примеры трудоустройства вайбкодеров на реальную работу, пожалуйста. А то у меня ни одного коллеги-вайбкодера почему-то нет и даже сама мысль кажется смешной.
Ну и ну. Мало того, что все зависимости будут при каждом билде с нуля выкачиваться из репозитория, так ещё и в композе идёт бессмысленное дублирование части докерфайла.
Вы уверены, что вам не рановато писать туториалы по докеру? Как будто бы стоит сначала самому разобраться, а потом уже пытаться писать обучающие статьи.
Или можно просто использовать loguru, в котором уже давно реализовано всё описанное и ещё куча дополнительных фич вроде авторотации лог-файлов раз в период или по достижению определенного размера.
А собранные данные на корректность проверяли? Год назад WB в таких ситуациях подсовывал фейковые данные. То есть запросы они не блочили, а просто по-тихому наливали трэша в части ответов.