Новая модель:
— контекст длиннее. 128K токенов (365 страниц обычной книги)
— модель более аккуратна при работе с длинным текстом, не теряет то, что было в серединке
— фича для разрабов: можно заставить модель писать ответы в JSON-формате
— можно вызывать несколько функций за раз
— можно указать seed генерации, чтобы получать воспроизводимость
— скоро добавят logprobs в API
— Retrieval прямо из коробки, можно загружать документы на платформу и они будут подтягиватсья (F стартапам chatWithPDF)
— Теперь модель знает события не до сентября 2021го, а апреля 2023го
— Эта новая модель принимает картинки на вход через API

— DALLE-3 + text-to-speech (6 голосов) сегодня появятся в API
— Для GPT-4 появится файнтюнинг сегодня (но на узкую выборку пользователей)
— Custom Models: программа плотной работыт инженеров OpenAI с вашей компанией, чтобы помочь адаптировать тренировку под ваши проблемы

ЦЕНА НА GPT-4-TURBO (Sam говорит, что эта модель ещё и умнее GPT-4) уменьшена в 3 раза для промпта и в 2 раза для генерации!

Обещают скоро ещё больше ускорить GPT-4 Turbo

GraphQL и тесты

Будучи разработчиком, я не любил GraphQL с самого его появления — из-за ноды, привязки к Apollo, отсутствия APM (если не покупать подписку у Apollo) и сложного, вложенного языка запросов. В принципе до сих пор ничего изменилось, но в этом посте я хочу отдельнло поговорить о своей любимой теме – тестировании.

GraphQL замечательно умеет делать одну вещь: вытаскивать данные с сервера в произвольном формате, удобном в каждый конкретный момент. «Выгрузи мне все книги — название, количество страниц, пару интересных цитат и автора, а у каждого автора покажи ФИО, фотографию и список популярных произведений» — это типичный запрос для GraphQL, с которым он справляется идеально. В REST для такой специфичной выборки пришлось бы писать отдельный эндпоинт, следить за ним и поддерживать. А тут даже кода писать не надо — один раз описал схему данных, и всё работает из коробки.

Минус в том, что вместо понятного набора эндпоинтов с заранее определённым поведением, мы получаем один эндпоинт на все наши данные. Тестировать такой эндпоинт очень больно. Первая проблема –  контракт между бекендом и фронтендом: раньше мы могли написать батарею юнит-тестов, которые проверяют все возможные запросы, аутентификацию и авторизацию, а затем копипастить их для разных эндпоинтов, добавляя локальную специфику. Тесты для GraphQL так не могут — мы же не знаем, что у нас запросят в каждый конкретный момент, а значит не можем написать тесты, которые отражают реальность. Остаётся только делать тесты для типичных запросов, и надеяться, что когда фронт или бек что-то поменяет, программисты сами договорятся и друг-другу ничего не сломают.

Сложно тестировать не только контракты, но и прозводительность. Раньше мы для каждого эндпоинта могли предсказать количество тяжёлых запросов с джоинами, и даже ограничить их количество в тестах или в рантайме (по ссылкам питон, в вашем стеке будут другие инструменты). Теперь мы каждый раз не знаем, что у нас запросят, а значит можно выгрузить хоть всю базу за один запрос.

Конечно, есть бизнесы, которые выигрывают от умения отдавать по 20 сущностей на один запрос, и делают это своей core-ценностью — к примеру облачные BaaS или высокоуровневые headless CMS вроде Sanity. Но если вам надо просто отдавать на фронт десяток известных сущностей, даже если вы планируете добавить в будущем ещё пару десятков — скорее всего GraphQL обойдётся вам намного дороже чем обычный REST, потому что с самого старта вам придётся тратить намного больше сил на тесты.

Разработка REST Api кажется простым делом - перекладывай json-чики с места на место и все дела. Но когда ты сталкиваешься с плохо спроектированными Api-шками и начинаешь задумываться о том, как спроектировать хорошо, тут то и открывается бездна. Особенно интересно то, что каждый знает "как правильно проектировать Api" и часто даже в небольшой команде начинаются жаркие споры и каждый тянет одеяло на себя.

Вот еще одна из миллиона статей на тему "как делать правильно", которая мне понравилась взвешенным подходом и подробной аргументацией к каждому пункту. Если вы работаете на проектах, где нет внутреннего стандарта на Api, то рекомендую почитать https://github.com/stickfigure/blog/wiki/How-to-(and-how-not-to)-design-REST-APIs

rce через sqli выходят на новый уровень...

https://blogs.oracle.com/mysql/post/introducing-javascript-support-in-mysql

mp3. Как мы научились сжимать музыку - Запуск завтра
30 лет назад, чтобы послушать любимую песню, нужно было пойти в магазин, отстоять очередь и купить дорогой диск, на который умещалось всего девять композиций. Всё изменил один немецкий ученый, который придумал революционную технологию сжатия звука. Благодаря ей диски стали не нужны - теперь всю музыку мира можно было бесплатно слушать с компьютера,

https://music.yandex.ru/track/121031035

GitLab 10/10

The most critical security issue GitLab patched has the maximum severity score (10 out of 10) and is being tracked as CVE-2023-7028. Successful exploitation does not require any interaction.

https://www.bleepingcomputer.com/news/security/gitlab-warns-of-critical-zero-click-account-hijacking-vulnerability/

Learning how qr works
Интересная статья про энкодинг и запись qr кодов

https://qr.blinry.org/

Промпт chatgpt 4 - https://www.reddit.com/r/ChatGPTJailbreak/comments/1an7tp4/sooo_did_chatgpt_just_leak_the_instructions/

машинный перевод

Gil is no more

https://github.com/python/cpython/pull/116338

Куча успешных хакерских атак на российский хостинг, если кто-то не заметил. За последнюю неделю пострадали:
— CloudMTS
— 1Gb.ru
— 1cloud
— в свободном доступе куча дампов SQL-баз клиентов Reg.ru

Кроме того — очень много успешных атак на проекты, основанные на 1С-Битрикс.

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

https://www.openwall.com/lists/oss-security/2024/03/29/4

tldr update any rolling release machine, which could caught xz version 5.6.0-1 or 5.6.1-1 (latest - xz-5.6.1-2).

REST API guidelines

https://github.com/team-monite/api-style-guide/blob/main/Guidelines.md

https://habr.com/ru/articles/832678/

TLDR: YouTube в России замедляют, используя метод анализа незашифрованного SNI в TLS-соединениях, что позволяет определить и ограничить трафик. Ограничение можно обойти с помощью манипуляции SNI или использования специальных программ, таких как GoodbyeDPI и zapret, которые изменяют структуру пакетов, чтобы избежать блокировки.