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

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

Слушал подкаст Подлодка, там было про представление чисел в памяти. Решил загуглить 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 сегодня отдаёт лицензии бесплатно, чтобы завтра иметь преимущество в гонке за ИИ-инструменты.

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

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

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

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

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

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

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

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

r/#technology

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

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

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

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

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

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

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

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

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

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

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

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

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

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