Дело даже не в умении кодить, а в том что нужно заранее знать решение. И по шагам его расписать. Короче если там не однотипный бойлерплейт быстрее самому сделать. А обычно в работе время уходит на решение задачи, а не на бойлерплейт.
Мой никому ненужный опыт вайбкодинга такой. Это хороший инструмент для поиска причины ошибки, написания тестов и документации, написания фрагментов кода примера работы новой технологии, написания утильных методов. Но. Для написания кода необходимо самому знать что и как писать и двигать агента по шагам. Самостоятельно агент код писать не умеет.
Подскажите есть ли вариант это исправить? У меня слабое железо и раз в день зависает оконный менеджер и клавиатура. То есть даже терминал не переключить.
Ubuntu, Fedora. И не врут, действительно Федора сломалась после апгрейда. А как ролинг релиз может апгрейдиться он же на то и ролинг релиз что все пакеты последней версии как и сама система?
Нет, индекс накатывается локально и на текущий срез данных, а представление строится удалённо и по всей истории. Плюс индекс работает на множество запросов, а представление на сложную выборку нужно отдельное. Так что индекс строится гораздо быстрее, плюс мне не требуется индекс на каждый запрос...
Сколько будет строится представление в масштабах какого-нибудь твиттера? А на реальном проекте таких представлений нужно несколько в день. Лог компакшн будет только мешать, т.к. представление обрабатывает бизнес события, которые будут потеряны.
И это только часть проблемы. Как часто в реальном проекте меняется структура бд? Почти каждый день. А как изменять события? Вводить версионирование и поддерживать в каждом агрегате и представлении все предыдущие версии? Это же в какой ад превратится код, чего данные практики призваны избегать.
Вы как примените снапшоты к стороне чтения? У нее совсем другая структура чем у снапшотов. Если надо поддерживать уже существующее представление вопросов нет. Я спрашивал про новые.
А для новых представлений нужно накатывать всю историю сообщений? Сколько это займет времени, неделю? На проектах такие представления могут возникать по несколько раз в день в виде sql запросов.
Воу. Почищу ка я белый список.
Но ведь они с allowed origin?
У меня на компе сокс прокси создает vless. Неужели на Андроиде только через tun работает?
Почему бы не настроить vless на клиенте так чтобы он проксировал только на выбранные сайты?
О качестве кода в Диасофт ходят легенды...
Дело даже не в умении кодить, а в том что нужно заранее знать решение. И по шагам его расписать. Короче если там не однотипный бойлерплейт быстрее самому сделать. А обычно в работе время уходит на решение задачи, а не на бойлерплейт.
Мой никому ненужный опыт вайбкодинга такой. Это хороший инструмент для поиска причины ошибки, написания тестов и документации, написания фрагментов кода примера работы новой технологии, написания утильных методов. Но. Для написания кода необходимо самому знать что и как писать и двигать агента по шагам. Самостоятельно агент код писать не умеет.
Я просто деграднул tls до 1.2 и ech из рукопожатия исчез. Но сайт из России все равно не заработал.
А через интерфейс тоже можно. Но от ркн это не спасает, заблочен клаудфлэар полностью.
Попробовал разрекламированный claude 4.5. Код пишет правильно, но в лоб. Получается быдлокод.
И сколько собирается ваш монолит?
Подскажите есть ли вариант это исправить? У меня слабое железо и раз в день зависает оконный менеджер и клавиатура. То есть даже терминал не переключить.
Ubuntu, Fedora. И не врут, действительно Федора сломалась после апгрейда. А как ролинг релиз может апгрейдиться он же на то и ролинг релиз что все пакеты последней версии как и сама система?
Тот самый Линукс который перед апгрейдом рекомендует сделать полный бекан данных?
Короче, чем минио заменить?
Нет, индекс накатывается локально и на текущий срез данных, а представление строится удалённо и по всей истории. Плюс индекс работает на множество запросов, а представление на сложную выборку нужно отдельное. Так что индекс строится гораздо быстрее, плюс мне не требуется индекс на каждый запрос...
Сколько будет строится представление в масштабах какого-нибудь твиттера? А на реальном проекте таких представлений нужно несколько в день. Лог компакшн будет только мешать, т.к. представление обрабатывает бизнес события, которые будут потеряны.
И это только часть проблемы. Как часто в реальном проекте меняется структура бд? Почти каждый день. А как изменять события? Вводить версионирование и поддерживать в каждом агрегате и представлении все предыдущие версии? Это же в какой ад превратится код, чего данные практики призваны избегать.
Вы видимо совсем не в теме.
Вы как примените снапшоты к стороне чтения? У нее совсем другая структура чем у снапшотов. Если надо поддерживать уже существующее представление вопросов нет. Я спрашивал про новые.
А для новых представлений нужно накатывать всю историю сообщений? Сколько это займет времени, неделю? На проектах такие представления могут возникать по несколько раз в день в виде sql запросов.
Вода