Pull to refresh
9
Антон@Ansud

User

2
Subscribers
Send message

При этом сначала деплоится в дев, потом на тест, потом на стейж и когда-то потом на прод. Плюс можно считать “деплоем” не весь набор сервисов а поштучно, каждую реплику.

Вряд ли. Оно пишет странную безвкусную воду, с повторяющимися мыслями и странными оборотами. И вроде как уже все любители рассказать, что ии всех заменит слегка остыли и поняли, что ии это странный инструмент, которым ещё и надо уметь пользоваться.

Писала БЯМ. Очень много оборотов, которые ее выдают )

Openvz это был форк virtuozzo чтобы коммунити помогало переносить их патчи на новую версию ядра и обкатывать новые фишки. Ни единого слова о twoostwo и parallels.

Прикольно, я такого не замечал. Возможно какие-то паттерны в модельке матчатся лучше, на которых обучено было.

Ну так SDD придумали задолго до ИИ истерик. :) Правда оно было сильно более формализовано.

Код написанный опытным разработчиком обычно чуть более избыточен, чем надо. Но при этом сильно более читаем. То есть у тебя нет конструкций типа if (!!(checkup?do_this():do_that()) && (a == 1) && ((b == 10) && (c < other_func()))) {...}, а все расписано через отдельные понятно названные переменные и отдельные проверки.

А можно пояснить про расхождение логик? Не оч понял тейка.

Про специалистов, занимающихся мозгом, есть работа одна https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005268

Суть: что будет если простой микропроцессор исследовать также, как исследуют мозг. Вывод: вы не поймёте как работает процессор. Хотя обнаружите тактовую частоту, взаимосвязи каких-то частей. Но вот принцип работы останется тайной. Плюс будет много странных неправильных выводов.

Ну да, вполне себе сопровождаем. Только чем подробнее будет писаться эта спека, тем более она будет ммм… кодом :)

# Endpoint: Change Email
**Метод:** `POST /user/{uid}/change_email`
## Бизнес-логика и алгоритм
1. **Подготовка:**
   - Канонизировать `new_email` согласно [R001-email.md].
2. **Проверка конфликтов:**
   - Поиск в БД: `SELECT id FROM users WHERE email = {new_email}`.
   - Если найден другой `id` -> `409 Conflict`.
3. **Атомарная транзакция:**
   - Получить `old_email` текущего пользователя.
   - Выполнить `UPDATE users SET email = {new_email} WHERE id = {uid}`.
4. **Управление состоянием кеша (Post-commit):**
   - Удалить основной профиль: `DEL user:profile:{uid}`.
   - Удалить старый индекс почты: `DEL email_to_id:{old_email}`.
   - Обновить новый индекс почты: `SET email_to_id:{new_email} -> {uid}`.
## Обработка ошибок
- При любой ошибке БД транзакция откатывается, кеш не трогаем.

Что-то мне это неуловимо напоминает ))

Для простых проектов без дальнейшего развития получается неплохо. Для своих поделок у меня получается вполне по более-менее простой постановке задачи сгенерировать работающий код. И он даже делает что надо. А вот если заглянуть внутрь, то там много странного: то колонки в таблицах, которые не используются, потому что другая ошибка позволяет это обойти, то шелл скрипты, со встроенным питоном (python3 << EOF..EOF). Если где-то повтроряется требование, то реализаций получается две. Например проверка email на валидность и приведение его в канонический формат дублируется каждый раз. Если перефразировать пословицу: выглядит как код, работает как код, значит код. Но хромой.

Контроль, в принципе, существует. Можно детерменировать выхлоп ИИ через SDD и TDD по спекам. Будет выглядеть как код на естественном языке со всеми плюсами и минусами.

Да, нашло дырки и не только в firefox. Только вот если начать делать “plz fix”, то дырок станет больше. LLM не умеет думать и решает проблему самым простым способом, не рассчитывая на то, что это еще и поддерживать потом надо. Код постоянно дублируется, потом в этих дублях находится ошибка, а фиксится только в части из них. Вынести дубли в отдельную функцию? Выносить куски в отдельные модули? Не, надо все в один файл сложить и норм. Работает же, тесты проходит…

Проверять тоже нейронкой? Она не находит половину косяков. Из разумного решения - языки со строгой типизацией плюс линтеры, сканеры и прочие валидаторы. Но вот проверять логику не умеет. Возможно когда-то научится, да.

Кожаные мешки ревьюят друг друга и работают достаточно медленно, чтобы ревью работало. Плюс после определенного момента кожаные мешки учатся делать как надо. Это вот как раз отличает кожаного мешка от ИИ с правилами, которые он нарушает постоянно.

А почему биткоин актив и растет, а стопятьсот других монеток сколлапсировали в ноль, несмотря на аналогичную технологию?

Он генерится нормально с нуля. После определенного числа правок его уже стоит выкинуть, исправить и понять это становится невозможно. Отсюда попытки в spec driven development.

Через год точно будет. И девелоперы будут не нужны. И все остальные тоже. Главное денег ещё дайте

Это молодые специалисты с высоким самомнением. Интервью по типу “расскажи мне то, что я знаю”. Потом обычно проходит, когда опыт появляется.

Есть такая мобильная игрушка - I love hue, гораздо более залипательная ) Сортируешь цвета по порядку.

Ps: 0.0032 на телефоне.

Калибровка и построение профиля монитора решает подобные проблемы. Ну и умение софта правильно преобразовывать исходное пространство изображения в пространство монитора. Если открыть картинку в Adobe или Pro rgb в простом вьювере, то цвета будут вырвиглазные, потому что никто не заморачивается и считают картинку в пространстве sRGB и конвертируют не то что надо.

Да. Только они везде, то ли как карго культ, то ли лучше ничего не нашлось.

Information

Rating
Does not participate
Location
Белград, Сербия
Registered
Activity

Specialization

Бэкенд разработчик, Системный инженер
Python
Алгоритмы и структуры данных
C++
C
Системы виртуализации