Cross Join - канал о разработке

Поворот не туда

Если вы посмотрите доклады на конференциях и обучающие материалы, то заметите болезненную фиксацию на инструментах, подходах, методах и способах что-то сделать.

Очевидно, авторам кажется, что от решения проблем слушателей отделяет ящик с инструментами.

Не будь у Шишкина кисти, откуда взяться «Утру в сосновом лесу»? Холст, масло и инструкция к ним.

Разговоры об инструментах — это поворот не туда. Форма не воспроизводит содержание. Иначе каждый, кто обладает необходимыми инструментами, кто взял фреймворк или изучил методологию, тут же достигал феноменальных результатов. Так не происходит.

Содержание порождает форму. Инструментов завались. Все они рождены обстоятельствами, нуждой и определённым пониманием проблемы.

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

Но инструмент не даст вам ничего, если вы не вполне понимаете, что происходит и к чему вы стремитесь.

Инструменты важны, но вторичны. Хорошо, что у Шишкина была кисть. Но важнее то, что у кисти был Шишкин.

Многие знают, что было довольно много попыток оценивать эффективность работы программиста. Пытались считать строки кода, жопочасы, количество выполненных задач и т.д.

Ничего, естественно, не работает.

Однако с появлением ИИ это может заиграть новыми красками. Допустим (чисто теоретически!) скидываешь в ИИху весь код, который наваял чел за месяц, все описания задач, все расшифровки митов и т.д. А ИИ потом выдаёт оценку, типа value, которое принёс разраб от 1 до 100.

Это была бы бомба.

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

Если же будет "сколько value принёс, столько и заработал", то по настоящему эффективные ребята бы разбогатели, а те, кто научился только отмазываться и на митах делать умное лицо, ели бы доширак. А некоторые бы вообще в минус ушли.

Понятно, что сейчас это невозможно, но помечтать-то можно. Сейчас даже оценка одного PR на кодревью через claude code мягко говоря вызывает множество вопросов. А что будет, если контекст будет по-настоящему огромный? Ничего хорошего.

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

🫥 Cross Join - канал о разработке
⠀

Вопрос к гоферам. Вы вендорите зависимости?

Если раньше я ощущал это как 100% отличное решение, билд быстрый, надежный и не развалится даже через 10 лет (бесит правда, что vendor видно в MR/PR), но всё больше замечаю, что с годами зависимости Go становятся всё жирнее и жирнее.

А когда добавляешь инструменты (всякие линтеры и генераторы) как go get -tool, то вообще капец.

Понятно, что до npm и пакетов типа leftpad еще далеко, но в целом Go постепенно идёт примерно в эту сторону.

Aws сегодня полёживает, интересно, почему.... )

ChatGPT прошёл Тест Тьюринга и убил все(!) профессии, а вы и не заметили.

Я прочитал его последний ответ и восхитился.

Если раньше малыш просто делал фигню и обещал переделать, то теперь он вышел на принципиально новый уровень — обещал вернуться и ничего делать не стал.

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

Не хватает только отмазок про отключение электричества, срочный проект или поликлинику.

Вообще, считаю, что линтеры должны работать в режиме подсказок, не блокировать ci. Ну, можно блокировать только самые злые security проблемы. Остальное - пустая трата времени.

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

А что это даёт? увеличение читабельности кода на 0.000001%. И то, надо наткнуться еще на такую проблему, когда ретроградный меркурий не в той фазе луны, и программист пришел пьяный на работу и запутался в трёх пакетах команды apk add. Т.е., никогда.

Если уж нужен блокирующий линтер по каким-то религиозным соображениям, то оттуда надо выкидывать всё, что де факто никогда не создавало проблем. Т.е. не "порядок нужон", а "решаем конкретные реальные проблемы".

Вообще, сонар говнище ещё то. Особенно доставляют правила "дублирование кода не более x". Чисто механическое, без понимания специфики.

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

Не, ну какие контрол-фрики эти правила придумывают

Может, еще пробелы по штангенциркулю подравнять?

В Южной Корее парализована цифровая инфраструктура всего государства из-за пожара в дата-центре.

Сам пожар случился в Национальной службе Информационных Ресурсов (NIRS). В нём хостятся гос-сервисы, базы данных, облачные системы. Это буквально ИТ-инфраструктура всего государства.

Причина по предварительным данным: возгорание литий-ионной батареи во время работ по её замене. Огонь перекинулся на соседние батареи и стойки.

Всего пострадало 647 государственных сервисов, а физически уничтожено 96. Среди пострадавших:
— местный аналог госyслуг;
— система удостоверения личности;
— G-Drive (государственное облако хранения документов). C 2018 года там находились миллионы официальных документов. Теперь данные утрачены или заблокированы;
— госэлектронная почта;
— образовательные базы;
— финансовые и административные сервисы.

Из-за пожара в G-Drive было уничтожено 858 терабайт данных. Самое абсурдное, что бэкапы были, но они хранились на соседнем сервере, который стоял в том же здании, куда также добрался пожар. Так что бэкапов нет — сгорели и основные, и резервные данные.

Теперь всё это восстанавливают из локально сохранённых документов на ПК сотрудников, архивов электронной почты и т.д.

Также сообщается, что высокопоставленный правительственный чиновник, курировавший восстановительные работы... покончил жизнь самоубийством.

r/#technology

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

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

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

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

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

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

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

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

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

Сегодня я узнал, что есть расширение для посгреса pg_cron. Прикольно, только, мне кажется, всё равно удобнее такие вещи делать через приложение: удобно смотреть логи, дебажить скорость и т.д

-- удалять старые данные по субботам 3:30
SELECT cron.schedule('30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$);
 schedule
----------
       42

-- Vacuum каждый день в 10:00
SELECT cron.schedule('nightly-vacuum', '0 10 * * *', 'VACUUM');
 schedule
----------
       43

-- Поменять время вакуума на 3:00
SELECT cron.schedule('nightly-vacuum', '0 3 * * *', 'VACUUM');
 schedule
----------
       43

-- Убрать 
SELECT cron.unschedule('nightly-vacuum' );
 unschedule 
------------
 t

-- убрать по id
SELECT cron.unschedule(42);
 unschedule
------------
          t

-- Запустить кронджобу на другой базе
SELECT cron.schedule_in_database('weekly-vacuum', '0 4 * * 0', 'VACUUM', 'some_other_database');
 schedule
----------
       44

-- Запускать процедуру каждые 5 сек
SELECT cron.schedule('process-updates', '5 seconds', 'CALL process_updates()');

🫥 Cross Join - канал о разработке
⠀

Вышла новая версия спецификации 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

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) Javascript-овые 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 могут изменить прототипы и вызвать уязвимость.

Опасные места в 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 и аналогичные безопасные методы в других языках.

Ну кстати если говорить про chatgpt то такая eagerness у него зашита прям в системный промпт.

You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.
- Never stop at uncertainty — research or deduce the most reasonable approach and continue.
- Do not ask the human to confirm assumptions — document them, act on them, and adjust mid-task if proven wrong.

gpt-5 prompting guide

Он проинструктирован не спрашивать уточнений и сначала ответить хоть что-то если задача сложная или время затратная.

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

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

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

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

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

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

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

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

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

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

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

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

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