Сорян, пока только нейроревью. Бегло потыкал, вроде так и есть. Глазами только завтра успею.
Ban IP mask (wildcard)
--------------------
Беру IP-баны: там есть все три слоя (данные, поведение, намерение) и README заявляет их восстановленными с тремя ссылками. Сделаю археологию полностью, как демонстрацию метода. Собрал кейс целиком. Вот как выглядит полная археология одного шрама против того, что сделал LLM.
Эталон, слой данных (admin_bans.php)
Один бан это строка с тремя осями: username, email, ip. Поле ip содержит несколько адресов через пробел, причём частичных: “192.168.1” валидно, валидация разрешает до 4 октетов. IPv6 тоже, с частичными группами. Ведущие нули нормализуются при записи. Вайлдкарды запрещены явно: октет с не-цифрой отклоняется валидатором. Email-бан бывает двух видов: точный адрес или голый домен (“mail.ru” банит весь домен). Проверка дублей при добавлении считает email и его домен пересекающимися, а при редактировании сознательно нет, и в коде комментарий объясняет почему: иначе нельзя было бы править существующий email-бан, если позже добавили доменный. Это окаменевшее намерение прямо в комментарии. Нельзя банить админа, модератора, гостя.
Эталон, слой поведения (check_bans в functions.php)
Матч по IP префиксный, и вот он, шрам, записанный комментарием в коде: к адресу дописывается точка, чтобы бан “192.168.0.5” не матчил “192.168.0.50”. Expired-баны удаляются лениво прямо из функции проверки, с регенерацией кэша, то есть чтение имеет побочный эффект записи. Админы и модераторы освобождены. И главное для нашей темы: email здесь не проверяется вообще. На запросе проверяются username и ip, а email-бан срабатывает в другом месте, при регистрации. Контракт одной сущности распределён по разным точкам системы, из одного файла его не видно.
Эталон, слой намерений (трекер)
Три PR (#151, #154, #164) за тикетом #1037: запретить бан localhost, потому что админы регулярно блокируют сами себя. Ни один не смержен, мейнтейнеры так и не решились. #219 (единственный из процитированных в README, который реально про баны) это фикс сортировки списка банов по IP, не про маски. Итог слоя намерений: известная открытая проблема (self-lockout), по которой сообщество не приняло решение за 6 лет.
Что сделал fluxbb-next
IpMask вводит вайлдкарды *, которые оригинал запрещает на входе, и требует ровно 4 октета. Docblock утверждает: “Domain scar recovered from admin_bans.php: IP mask wildcard support”. Это фабрикация уже на уровне комментария в коде: восстановлена фича, которой никогда не было, с указанием источника, который её опровергает.
Частичные адреса, IPv6, мульти-IP в одном бане: не поддержаны. Легаси-строка “192.168.1 10.0.0” (валидная в оригинале) не пройдёт конструктор. А мигратор копирует таблицу bans.
Доменные email-баны исчезли тихо: matches() сравнивает email только точно. Мигрированный бан “mail.ru” станет мёртвой строкой, которая никогда не сматчится, и никто не узнает.
Распределённый контракт (email на регистрации, ip/username на запросе) не восстановлен и не осмыслен.
Открытая проблема self-lockout, шесть лет истории, три PR, не получила ни решения, ни даже упоминания.
Вердикт по кейсу
Ноль из трёх слоёв. Данные: контракт сломан, миграция производит мёртвые или падающие записи. Поведение: семантика заменена на выдуманную. Намерения: трекер не прочитан, ссылки декоративные.
Как выглядело бы правильное восстановление
По твоей Фазе 0: именованная сущность IpPrefix (не mask, термин важен, потому что семантика префиксная), инвариант про дописанную точку перенесён из комментария в тест (“192.168.0.5 не матчит 192.168.0.50”), email-ось как два отдельных типа (ExactEmail, Domain), карта точек применения (запрос: ip+username, регистрация: email) как явная таблица, и отдельно decision records: “вайлдкарды не восстановлены, это новая фича, отложена”, “self-lockout: открытая проблема апстрима, решаем так-то или осознанно не решаем”. Каждое отклонение от оригинала должно быть подписано, а не растворено в коде.
По времени: мне этот кейс занял четыре чтения файлов и два запроса к API трекера. То есть цена ручной археологии одного шва измерима в часах, и LLM её не сэкономил, а замаскировал несделанную работу под сделанную.
типичный конфликт бизнеса и разработки, когда бизнесу надо что бы работало вчера, а разработчику еще бы и написать поддерживаемый код, на что тратится дополнительное время
Что бизнесу нужно ASAP и каждый день он теряет деньги не противоречит тому что он же в итоге оплатит технический долг. И конфликта тут между бизнесом и ИТ нет. Конфликт тут между правым и левым полушарием мозга заказчика, между тактическими и стратегическими целями.
Управление ожиданиями заказчика, балансировка его противоречивых требований это задача исполнителя.
Сам много раз проходил собесы где буквально на 15ой секунды в тебя швыряли задачей с литкода(условно)
Не знаю ситуацию на рынке труда, вообще не ходил на собеседования года 4. Но я бы вероятно молча ушёл. Leetcode значит ищут вчерашнего студента, преимущества перед студентом в таких задачах у меня нет, да и не нужна мне такая работа значит. Архитектору задавать такие вопросы глупо, значит я просто теряю время на встрече. Про вычислительную сложность алгоритмов я конечно помню, но не напишу ни один из алгоритмов сортировки кроме пузырьковой.
когда стрелял сервис который был гораааздо хуже того который стрельнул на полгода позже
Обратите внимание на то где он стрелял. В США, где много богатых кастомеров с FOMO. В других странах, особенно у нас этот опыт бесполезен. У нас это так не работает
Реальную эксплуатацию документировать обязательно! Желательно в коде или комментарии к коммиту. Прямо полностью issue. Так удобнее потом анализировать историю
Один в один всё равно не переписать. А как доказать, что ничего не сломалось?
Ну и смысл переписывания или рефакторинга в том что будущие изменения или исправления будут легче, а вероятность ошибок меньше. Но если продукт меняться не будет то и рефакторинг без толку
Скорее изменилась одна величина — горизонт планирования. Насколько далеко вперед можно планировать, прежде чем реальность обнулит план. До прода он измерялся месяцами. А после запуска парой задач.
Надо смотреть статистику. Но обычно на внеплановые просто фиксированный резерв при котором по статистике плановые задачи редко вытесняются. Задача оптимизации на основе статистики.
Обратите внимание: если наши системы классификации безопасности помечают ваши разговоры как содержащие вредоносный контент, они все равно могут быть использованы для улучшения наших внутренних моделей доверия и безопасности, выявления вредоносного контента, обеспечения соблюдения наших правил или продвижения наших исследований в области безопасности
Пусть для начала СНВ-III продолжат
Будто ядерное оружие безопасней
Уверены? А хотите поискать сколько несовместимых версий / расширений md формата?
Сорян, пока только нейроревью. Бегло потыкал, вроде так и есть. Глазами только завтра успею.
Ban IP mask (wildcard)
--------------------
Беру IP-баны: там есть все три слоя (данные, поведение, намерение) и README заявляет их восстановленными с тремя ссылками. Сделаю археологию полностью, как демонстрацию метода. Собрал кейс целиком. Вот как выглядит полная археология одного шрама против того, что сделал LLM.
Эталон, слой данных (admin_bans.php)
Один бан это строка с тремя осями: username, email, ip. Поле ip содержит несколько адресов через пробел, причём частичных: “192.168.1” валидно, валидация разрешает до 4 октетов. IPv6 тоже, с частичными группами. Ведущие нули нормализуются при записи. Вайлдкарды запрещены явно: октет с не-цифрой отклоняется валидатором. Email-бан бывает двух видов: точный адрес или голый домен (“mail.ru” банит весь домен). Проверка дублей при добавлении считает email и его домен пересекающимися, а при редактировании сознательно нет, и в коде комментарий объясняет почему: иначе нельзя было бы править существующий email-бан, если позже добавили доменный. Это окаменевшее намерение прямо в комментарии. Нельзя банить админа, модератора, гостя.
Эталон, слой поведения (check_bans в functions.php)
Матч по IP префиксный, и вот он, шрам, записанный комментарием в коде: к адресу дописывается точка, чтобы бан “192.168.0.5” не матчил “192.168.0.50”. Expired-баны удаляются лениво прямо из функции проверки, с регенерацией кэша, то есть чтение имеет побочный эффект записи. Админы и модераторы освобождены. И главное для нашей темы: email здесь не проверяется вообще. На запросе проверяются username и ip, а email-бан срабатывает в другом месте, при регистрации. Контракт одной сущности распределён по разным точкам системы, из одного файла его не видно.
Эталон, слой намерений (трекер)
Три PR (#151, #154, #164) за тикетом #1037: запретить бан localhost, потому что админы регулярно блокируют сами себя. Ни один не смержен, мейнтейнеры так и не решились. #219 (единственный из процитированных в README, который реально про баны) это фикс сортировки списка банов по IP, не про маски. Итог слоя намерений: известная открытая проблема (self-lockout), по которой сообщество не приняло решение за 6 лет.
Что сделал fluxbb-next
IpMaskвводит вайлдкарды*, которые оригинал запрещает на входе, и требует ровно 4 октета. Docblock утверждает: “Domain scar recovered from admin_bans.php: IP mask wildcard support”. Это фабрикация уже на уровне комментария в коде: восстановлена фича, которой никогда не было, с указанием источника, который её опровергает.Частичные адреса, IPv6, мульти-IP в одном бане: не поддержаны. Легаси-строка “192.168.1 10.0.0” (валидная в оригинале) не пройдёт конструктор. А мигратор копирует таблицу bans.
Доменные email-баны исчезли тихо:
matches()сравнивает email только точно. Мигрированный бан “mail.ru” станет мёртвой строкой, которая никогда не сматчится, и никто не узнает.Распределённый контракт (email на регистрации, ip/username на запросе) не восстановлен и не осмыслен.
Открытая проблема self-lockout, шесть лет истории, три PR, не получила ни решения, ни даже упоминания.
Вердикт по кейсу
Ноль из трёх слоёв. Данные: контракт сломан, миграция производит мёртвые или падающие записи. Поведение: семантика заменена на выдуманную. Намерения: трекер не прочитан, ссылки декоративные.
Как выглядело бы правильное восстановление
По твоей Фазе 0: именованная сущность
IpPrefix(не mask, термин важен, потому что семантика префиксная), инвариант про дописанную точку перенесён из комментария в тест (“192.168.0.5 не матчит 192.168.0.50”), email-ось как два отдельных типа (ExactEmail, Domain), карта точек применения (запрос: ip+username, регистрация: email) как явная таблица, и отдельно decision records: “вайлдкарды не восстановлены, это новая фича, отложена”, “self-lockout: открытая проблема апстрима, решаем так-то или осознанно не решаем”. Каждое отклонение от оригинала должно быть подписано, а не растворено в коде.По времени: мне этот кейс занял четыре чтения файлов и два запроса к API трекера. То есть цена ручной археологии одного шва измерима в часах, и LLM её не сэкономил, а замаскировал несделанную работу под сделанную.
А, спасибо. Посмотрю. Особенно на issues.
Что бизнесу нужно ASAP и каждый день он теряет деньги не противоречит тому что он же в итоге оплатит технический долг. И конфликта тут между бизнесом и ИТ нет. Конфликт тут между правым и левым полушарием мозга заказчика, между тактическими и стратегическими целями.
Управление ожиданиями заказчика, балансировка его противоречивых требований это задача исполнителя.
Не знаю ситуацию на рынке труда, вообще не ходил на собеседования года 4. Но я бы вероятно молча ушёл. Leetcode значит ищут вчерашнего студента, преимущества перед студентом в таких задачах у меня нет, да и не нужна мне такая работа значит. Архитектору задавать такие вопросы глупо, значит я просто теряю время на встрече. Про вычислительную сложность алгоритмов я конечно помню, но не напишу ни один из алгоритмов сортировки кроме пузырьковой.
Целых чисел арифметической прогрессии с шагом 1. А то мало ли)
Самолёты никогда не делали одиночки без денег. Автомобили возможно, но очень давно
Обратите внимание на то где он стрелял. В США, где много богатых кастомеров с FOMO. В других странах, особенно у нас этот опыт бесполезен. У нас это так не работает
Китайцы давят
Реальную эксплуатацию документировать обязательно! Желательно в коде или комментарии к коммиту. Прямо полностью issue. Так удобнее потом анализировать историю
И то и другое, что наступит раньше.
Для длинных задач модель пишет handover, я иногда читаю, потом сжимаю контекст когда завершен пункт или хотя бы подпункт плана.
Держу объём контекста между 150 и 500 тыщ в зависимости от длины рассуждений и длины жизни контекста.
А длина сессии бесконечная, на всю жизнь проекта. Ухудшения не заметил.
Да это вроде общепринятая практика. Антропик так и рекомендует
Ну да, розовый для девочек)
Один в один всё равно не переписать. А как доказать, что ничего не сломалось?
Ну и смысл переписывания или рефакторинга в том что будущие изменения или исправления будут легче, а вероятность ошибок меньше. Но если продукт меняться не будет то и рефакторинг без толку
Надо смотреть статистику. Но обычно на внеплановые просто фиксированный резерв при котором по статистике плановые задачи редко вытесняются. Задача оптимизации на основе статистики.
Вы просто не в той культуре и не заражены FOMO
Длинный контекст плох не только ценой: качество ответа деградирует
И оптимальный размер кеша далеко от предлагаемого миллиона. Я сбрасываю гораздо раньше когда задача кончается
Ой, чотаржу! Отключил?
https://privacy.claude.com/en/articles/12109829-how-do-i-change-my-model-improvement-privacy-settings
Без конкуренции так и будет.
Надо официально вернуть в Россию иностранные сервисы типа LinkedIn, Indeed
Видимо, это потолок