Дело даже не в умении кодить, а в том что нужно заранее знать решение. И по шагам его расписать. Короче если там не однотипный бойлерплейт быстрее самому сделать. А обычно в работе время уходит на решение задачи, а не на бойлерплейт.
Мой никому ненужный опыт вайбкодинга такой. Это хороший инструмент для поиска причины ошибки, написания тестов и документации, написания фрагментов кода примера работы новой технологии, написания утильных методов. Но. Для написания кода необходимо самому знать что и как писать и двигать агента по шагам. Самостоятельно агент код писать не умеет.
Подскажите есть ли вариант это исправить? У меня слабое железо и раз в день зависает оконный менеджер и клавиатура. То есть даже терминал не переключить.
Ubuntu, Fedora. И не врут, действительно Федора сломалась после апгрейда. А как ролинг релиз может апгрейдиться он же на то и ролинг релиз что все пакеты последней версии как и сама система?
Нет, индекс накатывается локально и на текущий срез данных, а представление строится удалённо и по всей истории. Плюс индекс работает на множество запросов, а представление на сложную выборку нужно отдельное. Так что индекс строится гораздо быстрее, плюс мне не требуется индекс на каждый запрос...
Сколько будет строится представление в масштабах какого-нибудь твиттера? А на реальном проекте таких представлений нужно несколько в день. Лог компакшн будет только мешать, т.к. представление обрабатывает бизнес события, которые будут потеряны.
И это только часть проблемы. Как часто в реальном проекте меняется структура бд? Почти каждый день. А как изменять события? Вводить версионирование и поддерживать в каждом агрегате и представлении все предыдущие версии? Это же в какой ад превратится код, чего данные практики призваны избегать.
Вы как примените снапшоты к стороне чтения? У нее совсем другая структура чем у снапшотов. Если надо поддерживать уже существующее представление вопросов нет. Я спрашивал про новые.
А для новых представлений нужно накатывать всю историю сообщений? Сколько это займет времени, неделю? На проектах такие представления могут возникать по несколько раз в день в виде sql запросов.
Не увидел в статье про аналитическую часть. Рассматриваются СУБД безотносительно к шаблонам и практикам типа cqrs и делается вывод о превосходстве acid это непонятно.
Что значит не вся read такая? Я пишу как масштабировать мы при помощи base стандартный подход в использовании eventual read.
Дело не в if else, а в условиях состоящих из непонятных вычислений. И их много. Обернуть бы каждое условие в одну или несколько функций и читателю было бы понятно что за этими вычислениями кроется.
Названия переменных - fix, extra, current. Не выделены действия в функции с говорящими названиями. Просто адовое тернарное выражение на несколько строк. Можно было бы подробное ревью провести, но не тот формат.
Дело даже не в умении кодить, а в том что нужно заранее знать решение. И по шагам его расписать. Короче если там не однотипный бойлерплейт быстрее самому сделать. А обычно в работе время уходит на решение задачи, а не на бойлерплейт.
Мой никому ненужный опыт вайбкодинга такой. Это хороший инструмент для поиска причины ошибки, написания тестов и документации, написания фрагментов кода примера работы новой технологии, написания утильных методов. Но. Для написания кода необходимо самому знать что и как писать и двигать агента по шагам. Самостоятельно агент код писать не умеет.
Я просто деграднул tls до 1.2 и ech из рукопожатия исчез. Но сайт из России все равно не заработал.
А через интерфейс тоже можно. Но от ркн это не спасает, заблочен клаудфлэар полностью.
Попробовал разрекламированный claude 4.5. Код пишет правильно, но в лоб. Получается быдлокод.
И сколько собирается ваш монолит?
Подскажите есть ли вариант это исправить? У меня слабое железо и раз в день зависает оконный менеджер и клавиатура. То есть даже терминал не переключить.
Ubuntu, Fedora. И не врут, действительно Федора сломалась после апгрейда. А как ролинг релиз может апгрейдиться он же на то и ролинг релиз что все пакеты последней версии как и сама система?
Тот самый Линукс который перед апгрейдом рекомендует сделать полный бекан данных?
Короче, чем минио заменить?
Нет, индекс накатывается локально и на текущий срез данных, а представление строится удалённо и по всей истории. Плюс индекс работает на множество запросов, а представление на сложную выборку нужно отдельное. Так что индекс строится гораздо быстрее, плюс мне не требуется индекс на каждый запрос...
Сколько будет строится представление в масштабах какого-нибудь твиттера? А на реальном проекте таких представлений нужно несколько в день. Лог компакшн будет только мешать, т.к. представление обрабатывает бизнес события, которые будут потеряны.
И это только часть проблемы. Как часто в реальном проекте меняется структура бд? Почти каждый день. А как изменять события? Вводить версионирование и поддерживать в каждом агрегате и представлении все предыдущие версии? Это же в какой ад превратится код, чего данные практики призваны избегать.
Вы видимо совсем не в теме.
Вы как примените снапшоты к стороне чтения? У нее совсем другая структура чем у снапшотов. Если надо поддерживать уже существующее представление вопросов нет. Я спрашивал про новые.
А для новых представлений нужно накатывать всю историю сообщений? Сколько это займет времени, неделю? На проектах такие представления могут возникать по несколько раз в день в виде sql запросов.
Вода
Не увидел в статье про аналитическую часть. Рассматриваются СУБД безотносительно к шаблонам и практикам типа cqrs и делается вывод о превосходстве acid это непонятно.
Что значит не вся read такая? Я пишу как масштабировать мы при помощи base стандартный подход в использовании eventual read.
Обычно write сторону делают согласованной, а read делают eventual. И не будет ситуации когда один заказ уходит двум людям.
Хотелось бы увидеть не только рекламу курса, но и объяснения, решения.
Дело не в if else, а в условиях состоящих из непонятных вычислений. И их много. Обернуть бы каждое условие в одну или несколько функций и читателю было бы понятно что за этими вычислениями кроется.
Названия переменных - fix, extra, current. Не выделены действия в функции с говорящими названиями. Просто адовое тернарное выражение на несколько строк. Можно было бы подробное ревью провести, но не тот формат.