Новая модель:
— контекст длиннее. 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

Мессенджер Signal начал тестировать ники — сейчас завести аккаунт в нём можно, только указав номер телефона, который в результате виден собеседникам. Имя пользователя, по аналогии с телеграмом, позволит вести переписку, не раскрывая номер телефона.

"After rounds of internal testing, we have hit the point where we think the community that powers these forums can help us test even further before public launch,” says Signal VP of Engineering Jim O’Leary.

Фича появилась в очередной бета-версии. Судя по скриншотам, имя пользователя будет связано с уникальным QR-кодом и ссылкой, которой можно поделиться для начала общения, а номер телефона скрыть в настройках мессенджера.

https://www.pcmag.com/news/no-more-phone-number-swaps-signal-messaging-app-now-testing-usernames

GraphQL и тесты

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

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

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

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

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

Вышел The State of Developer Ecosystem 2023, в котором в этом году особенно уделили внимание влиянию AI на процесс разработки.

Языки
По классике, на первом месте JS, на втором Python, бурный рост TS и Rust, падение php и objective-c. Так же из интересного некоторые(~10%) разработчики хотят изучить Rust и Go в ближайший год, а разработчики на Scala и Rust наоборот в большинстве не хотят изучать другие языки.

Жизнь
Из интересного 30% разработчиков находят работу через знакомства, что доказывает что лучше вкладываться в удобные рабочие часы и высокую ЗП, которую большинство разработчиков считают самым важным. Еще из забавного 75% разработчиков не окончили различные курсы, которые они проходили. Из грустного 50% разработчиков не следят за своим психическим здоровьем и 75% испытывали выгорание.

Those who have experienced burnout feel tired more often.

70% разработчиков пишут код на выходных и только 19% не работают.
У большинства разработчиков 16 GB – 32 GB оперативы, хотя не удивительно, ведь опрос проводил JetBrains.

AI
84% разработчиков знают какой-либо из AI tools, большинство из них сомневаются в надежности этих сервисов в плане хранения данных. 60% уверены, что AI полностью изменит процесс разработки и будет сам писать код. 77% используют ChatGPT, 46% Copilot. Чаще всего их применяют для того, чтобы писать код и обрабатывать natural language, реже для документации и прочей работы с текстом. Половина разработчиков с радостью переложат написание кода и тестов на AI, но та же половина не захочет передавать написание кода ИИ.

AI assistants are most commonly used to help developers perform routine tasks, like writing documentation, code comments, and commit messages, as well as searching. However, developers prefer to do their own coding, including understanding the code and recent code changes, debugging, and of course, writing code, even though 79% of the respondents mentioned that writing code is their most time-consuming activity.

DB
Из грустного 64% разработчиков до сих пор используют MySQL и только половина использует Postgres. MySQL чаще всего используют в связке с MariaDB, что не удивительно, из-за их совместимой апи. Так же наблюдается значительное падение использование oracle в снг, думаю понятно почему.

DevOps and Cloud
54% на докере, 39% без ничего, 13% на кубере. Странно, что большинство разработчиков не знакомы с docker-compose, при том, что большая часть использует докер. 60% на aws, далее azure и гугл, но в этом году появляется Alibaba, которые предоставляют быстрый хостинг на территории Азии. В этом опросе только 10% разработчиков используют, однако на территории Китая около трети сайтов крутятся на Alibaba Cloud, а их главный конкурент - Huawei.

Development
Большинство(60%) разработчиков используют windows, на linux и на маке сидят одинаковое кол-во - по 40%. 41% разработчиков контрибутят в open-source, половина из них делает это постоянно. Еще из интересного в кросс-платформенной разработке 2 место после винды занимает linux, как target для разработчиков, обгоняя макось.

62% of developers follow the Secure Software Development Life Cycle (SSDLC).

34% разработчиков пишут микросервисы, из их большинство используют различные протоколы поверх http.

Python
бОльшая часть разработчиков используют последнюю LTS - 3.11. Половина до сих пор на МЛ и аналитике, 40% на вебе. Django обогнал Flask как основной фреймворк, однако FastAPI понемногу догоняет его. Большинство разработчиков, около трети, пишут на vs code, несмотря на удобства в pycharm-а

Отчет очень информативный и красивый, с большим кол-вом смежной аналитики. Рекомендую изучить самостоятельно, например статистику по другим яп:
C C# C++ Go Java JavaScript Kotlin PHP Python R Ruby Rust Scala Swift and Objective-C

https://www.jetbrains.com/lp/devecosystem-2023/

Разработка 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

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, которые изменяют структуру пакетов, чтобы избежать блокировки.

https://gekk.info/articles/traceroute.htm

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

Разбираемся в дефолтных и откладываемых (деферрабельных) констрейнах в PostgreSQL

В постгре по умолчанию все констрейны проверяются немедленно, сразу после каждой операции(NOT DEFERRABLE INITIALLY IMMEDIATE). Это означает, что уникальные ограничения и внешние ключи всегда валидируются мгновенно, как только происходит изменение данных. Такой подход гарантирует целостность данных, но иногда это создает проблемы. Например, если вы пытаетесь изменить значения в столбце с уникальным индексом, сдвинув их все на единицу, то получите ошибку:

UPDATE numbers SET number = number + 1;
-- Ошибка: Duplicate key value violates unique constraint

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

Отложенные ограничения можно настроить двумя способами. Первый — DEFERRABLE INITIALLY IMMEDIATE — позволяет отложить проверку ограничений вручную, изменив поведение внутри транзакции с помощью команды SET CONSTRAINTS <constraint_name> DEFERRED. Второй вариант — DEFERRABLE INITIALLY DEFERRED — изначально предполагает, что проверка всегда будет происходить в конце транзакции, что особенно полезно в случаях, когда временное нарушение ограничений не критично и будет исправлено до завершения транзакции.

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

Также стоит учитывать, что отложенные проверки нельзя использовать для ограничений типа NOT NULL и CHECK. Эти типы ограничений всегда проверяются немедленно, что ограничивает применение деферрабельных настроек.

больше примеров использование деферрабельных констрейнов можно посмотреть тут:
https://emmer.dev/blog/deferrable-constraints-in-postgresql/