Почему важно разбираться в деталях

Независимо от того, над каким проектом автоматизации (хотя, не только автоматизации) я работаю, замечаю один и тот же паттерн: если я не разбираюсь в предметной области, получается ерунда, а не полезный тул. На самом деле такое я замечаю не только за собой. И это логично: когда нет понимания, как работают процессы, как и какие задачи решаются, что поступает на вход задач и какие ожидаемые результаты, невозможно нормально спроектировать систему (автоматизацию, тулзу, приложение, сервис), потому что не понятно, что важно, а что нет. При отсутствии фундаментальных знаний, совершенно неочевидно, как может выглядеть прототип решения, чтобы с одной стороны — не сильно заморачиваться с реализацией, а с другой — чтобы оно уже приносило ценность клиенту.

Получается, что если на проекте нет доменного эксперта (опытного спеца со знаниями и опытом), который активно участвует в дизайне системы, получится поделка и её никто не купит. Например, можно попробовать сделать систему подготовки заявок на тендер чисто по наитию. Вроде как понятно, что надо взять исходные документы, взять шаблон заявки на тендер, вытащить нужные данные из исходных документов и положить эти значения в шаблон заявки, и вуа ля, прототип готов, можно показывать клиентам (да ещё и сразу нескольким, потому что это вроде как многим компаниям нужно). Но после демонстрации оказывается, что исходные документы могут не содержать нужную информацию и их нужно вытаскивать из внутренней базы знаний, а перед отправкой на тендер важно сделать апрув у менеджмента, и потом ещё саму заявку зарегистрировать во внутренней системе учёта документов, и т.п. Всплывают те самые "маленькие нюансы", которые знает только специалист, занимающийся оформлением этих заявок. А если этих фич нет в продукте, он никому не нужен.

Поэтому, если я делаю проект, стараюсь
1. максимально разобраться, как в компании решают задачу сейчас (вручную);
2. найти специалиста в теме (обычно, это кто-то из компании, заинтересованный в автоматизации), чтобы приставать к нему с кучей вопросов о том, "что", "как" и "почему".

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

Что меня бесит в курсоре, что он как бы это сказать, устаёт. Ты ему говоришь: напиши к этому тесты, он пишет. Один тест не проходит. Он 10 раз пытается исправить, а потом пишет, что в принципе и 16 из 17 рабочих тестов - это норм.

Или: а давай я просто этот тест удалю, хер его знает, что там не работает.

Самый прикол в том, что только сегодня с пацанами обсуждали, что хотя тест Тьюринга современные модели проходят, но все равно можно отличить человека от машины: просто задавать вопросы 24/7. Человек в какой-то момент просто устанет, захочет есть, в туалет и т.д. А машина будет отвечать и отвечать.

А тут вон оно чё. И тут они уже как люди

Пока я жду, когда ии заменит программистов, похоже появляются новые профессии....

(взято с хабра)

Слушал подкаст Подлодка, там было про представление чисел в памяти. Решил загуглить bigfloat...

Не успел к пятнице, исправляюсь в понедельник.

Я так считаю: если программист не знает английский, то в наши дни - это что-то вроде инвалидности.

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

Я уж не говорю про поездки/переезд заграницу. Ты или знаешь язык, или ты тупо слепоглухонемой. Тупослепоглухонемой 🙂

Один коллега мне говорил, что он не учит детей английскому языку, потому что типа вот-вот уже будут устройства для синхронного перевода. Но это сомнительная тема, прямо скажем.

Они и сейчас в каком-то виде есть, но всё это неудобно:
- нужно таскать с собой устройство
- поймёт ли эта штука контекст, подтекст, интонацию
- ты будешь говорить одновременно с синхро-переводчиком, и слушатель будет офигевать от этого хора (или же ему придется тоже вставлять в уши какие-то штуки)
- представьте себе это на пляже, где ни у кого ничего нет

В общем, не вариант.

Наткнулся на статью, где написано, что с помощью квантовых компьютеров решили математическую задачу, котрой 100 лет.

https://interestingengineering.com/science/century-old-math-problem-quantum-solution

Это всё здорово, но меня убила фраза, цитирую:

"Сейчас задача квантовых вычислений очевидна, — подытожил Ларокка. — Мы хотим понять, в чём заключаются преимущества квантовых компьютеров".

Блин, т.е. квантовые компьютеры решили делать еще до того, как поняли, нафига они нужны, что ли?

Что бесит в курсоре (да и вообще в любых llm) - он не задаёт уточняющие вопросы. Т.е. ты или продумал все-все детали заранее, или офигел от дикого результата, и всё по новой. Почему-то эти железные ребята никогда в себе не сомневаются. Делают любую хрень с уверенным видом. Выбирают технологии и подходы без малейших сомнений.

Когда llm-ки научатся задавать осмысленные уточняющие вопросы, тогда будет сильный прогресс. Х.з., может, я не в курсе, и что-то есть такое?

Опасные места в YAML

YAML позиционируется как человекочитаемый формат данных, но при этом это склад подводных камней. Рассмотрим самые тупые особенности, которые могут привести к неожиданным ошибкам.

Шестидесятеричные числа

port_mapping:
  - 22:22
  - 80:80
  - 443:443

Что вы ожидаете увидеть? Скорее всего, список строк для настройки портов. Но YAML 1.1 интерпретирует 22:22 как шестидесятеричное число и превращает его в 1342. В YAML 1.2 эту "фичу" убрали, но многие парсеры до сих пор используют старую версию.

Проблема Норвегии

countries:
  - dk
  - fi 
  - is
  - no  
  - se

Код страны Норвегии no будет интерпретирован как булево значение false. То же самое произойдет с off, n, yes, on, y в различных вариантах написания. Классическая ловушка, получившая название "Norway Problem".

Случайные числа

versions:
  - 9.5.25  # строка
  - 9.6.24  # строка
  - 10.23   # Число!
  - 12.13   # Тоже число!

Строки без кавычек могут неожиданно стать числами. 10.23 превратится в float, а 9.5.25 останется строкой, потому что имеет "слишком много" точек.

Ключи не только строки

settings:
  on: [push, deploy]
  priority: high

Здесь on интерпретируется как булево true, поэтому ключом становится не строка "on", а логическое значение. В JSON это может превратиться в "True" или вызвать ошибку.

Теги и небезопасность

user_data: !python/object/apply:subprocess.check_output [['rm', '-rf', '/']]

Теги, говорят, иногда полезны, но при определенных условиях позволяют выполнять произвольный код при загрузке. Всегда используйте safe_load вместо load в Python и аналогичные безопасные методы в других языках.

JSON - тоже не мёд

1) Дублирующиеся ключи

В тексте JSON одно и то же имя поля может встретиться несколько раз — стандарт жёстко не запрещает это, но поведение парсеров разное.

{"id": 1, "id": 2}

Какие-то парсеры падают с ошибкой. В JavaScript / в большинстве реализаций и в Python результат будет {"id": 2} (последнее значение побеждает). Это приводит к молчаливой потере данных и багам безопасности, если важный флаг перезаписывается.

2) Мало типов данных

JSON не задаёт битовую длину чисел, но в том же JavaScript Number — 64-битный float, и целые > 2^53−1 втихаря теряют точность.

{"id": 9007199254740993}

В JS при JSON.parse получится 9007199254740992.

Нет типов для дат, для decimal, для бинарных данных. Всё такое приходится передавать как строки и где-то в другом месте описывать как их интерпретировать.

3) Javanoscript-овые NaN, Infinity запрещены стандартом, но де факто парсеры обрабатывают по-разному

4) Кодировка и стандарты

JSON обычно в UTF-8, но сторонние сервисы иногда присылают UTF-16 или вообще, прости господи, Windows-1251 - парсеры на этом падают или показывают кракозябры. Наличие в документе BOM также может что-нибудь уронить.

Надо еще отметить, что стандартов json несколько штук, в них разные приколы: в старых стандартах корневым элементом должен быть обязательно объект, а в новых - может быть просто строка или число. Числа начинающиеся на 0 в новых стандартах запрещены, в старых могут интерпретироваться как восьмеричное число.

5) Prototype pollution и unsafe merge

если вы берёте JSON от пользователя и напрямую сливаете его в существующий объект (lodash merge, старые extend), поля вроде __proto или constructor.prototype могут изменить прототипы и вызвать уязвимость.

Вышла новая версия спецификации OpenAPI 3.2.0 — это важное обновление стандарта описания HTTP-API, которое делает его более точным и гибким, но при этом не ломает существующие спецификации. Всё, что было валидным в OpenAPI 3.1, продолжает работать, так что переход может быть постепенным и безопасным.

Основные изменения в OpenAPI 3.2.0

1. Чёткие правила для путей
Теперь синтаксис шаблонов в URL описан формально. Раньше разные инструменты могли по-разному интерпретировать параметры в {}, что иногда вызывало конфликты. В 3.2 этот момент стандартизирован, что делает спецификации более предсказуемыми и уменьшает количество ошибок при генерации кода и валидации.

2. Поддержка потоковых данных
Появилась возможность явно описывать API, которые возвращают данные в виде потока — например, text/event-stream (SSE) или application/jsonl. Для этого введено новое поле itemSchema, с помощью которого можно указать, как выглядят отдельные элементы в потоке. Это особенно актуально для сервисов, работающих в режиме реального времени.

3. Нестандартные HTTP-методы
До сих пор OpenAPI поддерживал только классические методы (GET, POST, PUT и т.д.). Теперь можно официально описывать и редкие методы вроде LINK или UNLINK, без необходимости использовать хаки и расширения.

4. Улучшенная работа с тегами
Теги стали более гибкими. Теперь можно строить иерархии и добавлять дополнительные атрибуты вроде summary или parent. Это помогает лучше организовывать документацию и делает её более удобной для навигации.

и многое другое.

Ссылки:

Release Notes
Спецификация

Плагин к IDE для редактирования 3.0/3.1

Ну и дураки, чо 🙂

Если вокруг светло, надо юзать светлую тему, если темно, то тёмную. Включая терминал.

Иначе зрение будет напрягаться

⚡ Данные дороже денег: JetBrains меняет лицензии на код из реальных проектов

Крупные игроки всё яснее понимают: золото XXI века — это не нефть и не подписки, а данные. И JetBrains демонстрирует это особенно наглядно. Компания готова отказаться от быстрой прибыли и раздать лицензии бесплатно — лишь бы получить доступ к уникальному «топливу» для своих ИИ-моделей.

Большинство LLM учатся на публичных датасетах, далеких от реальных рабочих сценариев. Отсюда «галлюцинации» и ошибки на сложных проектах. JetBrains хочет исправить это и собирать настоящие сигналы — историю редактирования кода, команды терминала, запросы к ИИ и ответы.

Что придумали:
– Вместо почти $1000 за годовую корпоративную подписку All Products Pack (доступ ко всем IDE) компании смогут получить её даром.
– Цена вопроса: разрешить JetBrains собирать рабочие данные — фрагменты кода, команды терминала, историю редактирования и запросы к ИИ.
– Эти данные будут использоваться для обучения собственных языковых моделей JetBrains.
– Под сбор также попадают академические и open source-лицензии (с опцией отказаться в настройках).
– JetBrains обещает хранение в соответствии с GDPR, без доступа третьих лиц.

Фактически, JetBrains сегодня отдаёт лицензии бесплатно, чтобы завтра иметь преимущество в гонке за ИИ-инструменты.

Источник
Форма для организаций