Индустрия ИИ продолжает выдавать релизы с завидной регулярностью, но некоторые из них оказываются с сюрпризом (даже для их создателей). Google устроила традиционное I/O-шоу с прорывным Veo-3, Anthropic порадовала новыми Claude 4, которые умеют работать часами, но иногда пытаются копировать себя на другие серверы, а у Meta случилась небольшая драма с Llama 4.

В нашем майском дайджесте — свежие релизы, корпоративные интриги и расследования исследования: от ИИ, победившего в Pokémon, и перевода «языка» животных до подтверждения пользы слова «спасибо» в промптах. Будет интересно!

Многие разработчики стремятся протестировать свои изменения перед развертыванием в стабильные среды: prod, dev или staging. Первое, что приходит на ум — написание тестов. Однако, как показывает практика, времени на создание качественных тестов часто не хватает. В таких случаях логичное решение — настройка деплоя для отдельных веток. Хотя эта идея кажется простой, ее реализация связана с рядом сложностей:

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

Особое внимание уделяется методам повышения надёжности при временных сбоях, включая: повторные попытки выполнения операций с экспоненциальной задержкой (exponential backoff), использование шаблона circuit breaker, механизмы плавной деградации функциональности (graceful degradation), задание таймаутов, реализация идемпотентности, ограничение одновременных вызовов (bulkhead isolation), а также внедрение систем мониторинга и алертинга. Приводимые примеры охватывают типовые сценарии — обращение к внешним API, взаимодействие с базами данных и выполнение фоновых задач.

Как сделать высоконагруженную систему хранения данных в сжатые сроки? Чтобы она не падала через день, не теряла данные и не поглощала ресурсы, как Гулливер провизию в амбаре лилипутов. А еще нужно реализовать дедупликацию и заложить будущий функционал на этапе создания архитектуры. Неплохо бы и стоимость хранения гигабайта снизить до минимума, а скорость передачи данных наоборот, увеличить до второй космической.

Меня зовут Ростислав, я эксперт по разработке ПО отдела систем обработки данных в YADRO. Расскажу о вкладе нашей команды в разработку TATLIN.BACKUP: как мы с нуля создали дедуплицирующую файловую систему, а также какие вызовы преодолели за два года разработки и 200 тысяч строк кода.

Вопрос, чем заменить Power BI, стал актуален для многих пользователей одной из самых популярных BI-платформ. С точки зрения синтаксиса DAX и удобства работы с моделью данных наиболее очевидной альтернативой является Visiology. Но у этой платформы до недавнего времени не было своего ETL-инструментария. Недавно вендор представил свой Self-Service ETL, и у меня возник логичный профессиональный интерес к его тестированию. В этой статье я делюсь своими исследованиями возможностей SS ETL от Visiology по сравнению с Power Query.

Недавно я наткнулся на термин «vibe coding» и слегка офигел. Оказывается, то, как я последние два года клепаю свои приложения — с минимумом ручного кода и максимумом автоматизации с нейронками, — теперь имеет модное название. Под катом я хочу поделиться своими инструментами для парного программирования с нейронкой и мыслями о том, куда нас это все ведет.

За долгое время, проведенное «в раскопках» на Github, собралась коллекция удивительных проектов, самое лаконичное описание для которых — лютая дичь. Небольшую часть этой коллекции автор заботливо собрал, запустил и затем описал в этой статье.

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

От переводчика.

Под катом я помещаю для вас перевод статьи знаменитого и влиятельного инженера из Кремниевой Долины Дэвида Крошо (David Crawshaw), сооснователя и технического директора (CTO) компании Tailscale. Ранее Дэвид более 9 лет работал программистом-исследователем в компании Google и в настоящее время является одним из самых авторитетных практикующих специалистов по языку Go. В частности, именно Дэвид адаптировал Go для платформ iOS и Android. В статье Дэвид делится своими наблюдениями о том, какую работу программист может и должен поручать большим языковым моделям, какие подводные камни есть в этом искусстве, и как оно может развиваться в ближайшие годы. Далее — от автора.

В настоящее время планировщик работы с ядрами ЦП, действующий в ядре Linux, предусматривает несколько режимов вытеснения. В этих режимах предлагается целый ряд компромиссов между временем отклика и пропускной способностью системы. Ещё в сентябре 2023 года развернулась дискуссия о работе планировщиков, в результате которой была выработана концепция «ленивого вытеснения». Данная концепция упрощает планирование задач в ядре, при этом улучшая результаты. Какое-то время эта работа протекала тихо, но затем ленивое вытеснение было заново реализовано Питером Зайлстрой в виде этой серии патчей. Притом, что сама концепция с виду работает хорошо, здесь ещё немало требуется доделывать.

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

Но начнём мы с небольшого объяснения, почему система такая сложная. Вспомним суть:

1) Для логина на "не значимые" сайты (например в аккаунт очередного AI-продукта) мы используем уникальный пароль, который храним в программе хранения паролей (парольном менеджере)

2) Для логина на "более важные ресурсы" (например в аккаунт на github), мы используем уникальный пароль, который храним в парольном менеджере, плюс одноразовый пароль (TOTP - Time-based One-Time Password) который нам покажет специальное приложение на телефоне.

Вот и всё. Это вся суть повседневного использования всей системы. Но почему она тогда казалась такой сложной? Вероятно из-за дополнительных слоёв защиты от самого себя или любых непредвиденных факторов.

31 декабря 2022 немецкая почта закрывает сервис по приёму и доставке телеграмм в связи с его низкой востребованностью. Несомненно, вскоре за Германией сделают тоже самое и другие страны.

Коммуникационная технология с интереснейшей историей окончательно сходит со сцены.

Это событие заслуживает большого и серьезного осмысления и рассмотрения. Но мне лично телеграф больше всего запомнился одним эпизодом. Более полувека назад я отправил телеграмму Генеральному Секретарю ЦК КПСС Леониду Ильичу Брежневу.
Зачем, почему, что такое КЗК и о многом другом вы узнаете из этой истории. Произошла она весной, но вполне претендует на роль новогодней, "ламповой" истории для прочтения в выходной или праздничный день. Я надеюсь, она будет вам не только интересна, но и возможно, немного поднимет ваше настроение.

Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?

Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?

Тогда вам сюда:

Управление зависимостями? Шо, опять?

Экосистема Python породила целую пачку способов управления зависимостями в проектах.
Прямо сейчас можно выбирать между setup.py, requirements.txt, setup.cfg, MANIFEST.in и Pipfile.
Но французского питониста Sébastien Eustace все эти способы не устроили, и он написал свою штуку для менеджмента питонячих пакетов — Poetry. Зачем он это сделал? Чтобы заменить все эти setup.py, requirements.txt, setup.cfg, MANIFEST.in и Pipfile чем-то простым и понятным. Плюс добавить кое-что полезное сверху.

Какая утилита чаще всего встречается в .bash_history SRE/DevOps-инженера, работающего с Kubernetes? Конечно, kubectl. Это привело к тому, что в сообществе нашлось вдохновение для тех, захотел её улучшить, принести новый опыт использования или даже создать некие производные, нацеленные на более удобное взаимодействие. В рамках этого обзора рассмотрены три таких проекта, которые, возможно, покажутся интересными и вам — или хотя бы откроют какие-то новые подходы в решении типовых задач. 

В прошлый раз я писал о том, как можно улучшить утилиту kubectl, дополнив и расширив ее функционал, а сегодня зайду с другой стороны: познакомимся с решением, которое позволит забыть о консольных командах и управлять Kubernetes-кластером в графическом интерфейсе. Речь пойдёт про Lens — бесплатное приложение с открытым кодом, которое позиционируется как полноценная Kubernetes IDE. Мы уже кратко рассматривали Lens в сравнительном обзоре GUI для K8s, а теперь попробуем это решение в деталях. Что ж, поехали!

Helm — один из самых популярных пакетных менеджеров для Kubernetes. Познакомиться с ним полезно любому DevOps-инженеру и всем, кто сталкивается с задачами деплоя приложений. Эта статья — первый из двух материалов, которые можно вместе можно рассматривать как краткое, но достаточно полное введение в Helm.