даже -50кк в текущей ситуации ставит под вопрос устойчивость компании. Тут лишь время покажет как оно обстоит на самом деле, ибо масштабов повреждений в открытом доступе всё ещё нет.
1. данных больше нет 2. не торопятся потому что это повлечёт за собой высокоскоростной вывод бабла, которого по факту нет. последствия сами можете предсказать (от уровня самой компании до уровня всей страны).
за консистентность данных отвечают БД, тут вариантов не слишком много: - данных больше нет - не торопятся потому что это повлечёт за собой высокоскоростной вывод бабла, которого по факту нет. последствия сами можете предсказать (от уровня самой компании до уровня всей страны).
сама связывает логику работу нескольких сложных компонентов, оценивает детали и предлагает решение
всё верно, это всё ещё веса - ллм так и работает.
Я пользуюсь опусом, в основном для фронта - он вполне. Но стоит попробовать в многопоточку на го - сразу возникают проблемки с рэйсами и дедлоками, ибо ллм - не ИИ (с логикой и рефлексией), а машина для выдачи заранее известных результатов по каким-то вводным данным.
ллм, блин, не пишет код. ллм копипастит типовые решения, адаптируя по месту. чтобы это понять - достаточно попытаться решить задачу решения которой нет на первой странице гугла.
нет для ллм и хорошего/плохого кода, есть лишь веса: если где-то кривые решения популярны, модель отдаст предпочтение им.
с ростом открытых проектов созданных более чем полностью с помощью ллм, качество реализаций будет неуклонно падать, это то, что нас ждёт в ближайшем будущем.
основной плюс gitea/gogs в том что они совместимы с github actions пл формату описания джобов, а у гитлаба свои приколы - нужно переписывать если мигрируешь с гитхаба.
нет, не шире - я бы сказал что и типовые решения деградируют со временем, т.к датасет пополняется не взвешенными и проверенными (людьми) решениями со стэковерфлоу, а аналогичной кодогенерацией.
У вас в API-доке было указано поле, доку видели внешние потребители. Как Кирилл может ставить жёпу что это поле никто не юзает? Может Кирилл самодур (тут другое слово). А вы как лид - некомпетентный юнит? Придумали правил леса, а придумать здравый смысл забыли? Это имхо больше похоже на правду.
API меняется только через версионирование, как только схема ушла во вне - ничего нельзя менять в ней (ну на край можно добавить полей если прям горит). Удалять, переименовывать - бан.
Percona Backup for MongoDB - умеет PITR, догоняется с оплога, умеет бэкапить шардед-кластера (конфиг сервера в т.ч), писать в S3 да ещё и консистентность транзакций поддерживает.
mongodump - только на мелких базах будет работать адекватно.
Используй compact или пересоздание коллекций.
это в каких-то совсем крайних случаях, монга сама перезапишет фрагментированные куски.
Проверка наличия отсутствия данных тоже требует запуска внутренней логики БД, в т.ч работу с диском. Поэтому, правда, попробуйте tmpfs сделать все базы и сравните результаты - удивитесь.
даже -50кк в текущей ситуации ставит под вопрос устойчивость компании. Тут лишь время покажет как оно обстоит на самом деле, ибо масштабов повреждений в открытом доступе всё ещё нет.
на Бога надейся, а сам не плошай.
1. у меня всё ещё глухо
3. ожидайте заморозки вывода денег
4. я бы не был так уверен в текущей ситуации, у них есть план на этот счёт.
называйте вещи своими именами: ускорена не разработка, а кодогенерация - это лишь малая часть разработки и, пожалуй, самая простая.
астрологи объявили месяц роста цен на раму и железо
1. данных больше нет
2. не торопятся потому что это повлечёт за собой высокоскоростной вывод бабла, которого по факту нет. последствия сами можете предсказать (от уровня самой компании до уровня всей страны).
за консистентность данных отвечают БД, тут вариантов не слишком много:
- данных больше нет
- не торопятся потому что это повлечёт за собой высокоскоростной вывод бабла, которого по факту нет. последствия сами можете предсказать (от уровня самой компании до уровня всей страны).
знаете что..? да ничего.. удачи вам в этом диком мире!)
Скрытый текст
в 18 лет люди в основном палкой крапиву только перестают бить и хотят стать космонавтами когда вырастут..
всё верно, это всё ещё веса - ллм так и работает.
Я пользуюсь опусом, в основном для фронта - он вполне. Но стоит попробовать в многопоточку на го - сразу возникают проблемки с рэйсами и дедлоками, ибо ллм - не ИИ (с логикой и рефлексией), а машина для выдачи заранее известных результатов по каким-то вводным данным.
ллм, блин, не пишет код. ллм копипастит типовые решения, адаптируя по месту. чтобы это понять - достаточно попытаться решить задачу решения которой нет на первой странице гугла.
нет для ллм и хорошего/плохого кода, есть лишь веса: если где-то кривые решения популярны, модель отдаст предпочтение им.
с ростом открытых проектов созданных более чем полностью с помощью ллм, качество реализаций будет неуклонно падать, это то, что нас ждёт в ближайшем будущем.
это коуч, всё впорядке.
основной плюс gitea/gogs в том что они совместимы с github actions пл формату описания джобов, а у гитлаба свои приколы - нужно переписывать если мигрируешь с гитхаба.
tldr:
выяснили, что
heap— это далеко не вся память Java-процесса;правильно настроили размер heap (
InitialRAMPercentage,MaxRAMPercentage), CPU, GC и другие JVM-параметры;обнаружили, что много маленьких Java-подов менее эффективно, чем меньшее число более жирных — из-за overhead каждой JVM;
попробовали
jemallocвместо стандартного allocatorдаа.. поисписался хабр раз для такого надо 10 страниц текста.. да еще и от тинька..
нет, не шире - я бы сказал что и типовые решения деградируют со временем, т.к датасет пополняется не взвешенными и проверенными (людьми) решениями со стэковерфлоу, а аналогичной кодогенерацией.
а если это просто get на rest? может с graphql это и сработало бы..
У вас в API-доке было указано поле, доку видели внешние потребители. Как Кирилл может ставить жёпу что это поле никто не юзает? Может Кирилл самодур (тут другое слово). А вы как лид - некомпетентный юнит? Придумали правил леса, а придумать здравый смысл забыли? Это имхо больше похоже на правду.
API меняется только через версионирование, как только схема ушла во вне - ничего нельзя менять в ней (ну на край можно добавить полей если прям горит). Удалять, переименовывать - бан.
а приведите пожалуйста ссылку на тесты где постгрес быстрее монги в контексте неструктурированных данных (JSONB vs BJSON).
Percona Backup for MongoDB - умеет PITR, догоняется с оплога, умеет бэкапить шардед-кластера (конфиг сервера в т.ч), писать в S3 да ещё и консистентность транзакций поддерживает.
mongodump - только на мелких базах будет работать адекватно.
это в каких-то совсем крайних случаях, монга сама перезапишет фрагментированные куски.
как скажете)
Проверка наличия отсутствия данных тоже требует запуска внутренней логики БД, в т.ч работу с диском. Поэтому, правда, попробуйте tmpfs сделать все базы и сравните результаты - удивитесь.