Разработка

Почему опытные Python-разработчики редко используют циклы for для обработки данных? Потому что императивный стиль на больших объемах данных ведет к исчерпанию памяти (OOM) и замедлению работы.

Модуль itertools — это стандарт индустрии для создания эффективных конвейеров обработки данных. Он реализует концепцию ленивых вычислений (lazy evaluation), позволяя обрабатывать бесконечные потоки или огромные дампы БД, потребляя константный объем RAM.

Если хотите посмотреть, что нашёл статический анализатор PVS-Studio в исходном коде Intellij платформы, используемой OpenIDE, то добро пожаловать в статью.

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

Я расскажу, как у нас в команде QA-инженеры участвуют в дежурствах на боевом контуре наравне с разработчиками: разбирают инциденты, анализируют причины сбоев и вносят улучшения в продукт и процессы. Поделюсь, какие компетенции для этого нужны, и как такой подход помогает QA не просто проверять, а действительно влиять на качество — не только после релиза, но и задолго до него.

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

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

Жить в США стало лучше, но не веселее. После эмиграции поэт написал больше «холодных» стихов. Установлено математически точно с помощью кода.

Почти каждый разработчик рано или поздно сталкивается с задачей, когда ему нужно спроектировать такое сложное изменение в системе, которое затронет сразу несколько продуктов или команд. Кроме того, понимание архитектуры программного обеспечения ценится на рынке — ведущие IT-компании стремятся сохранять прежде всего тех, кто понимает, как устроены системы и решения, и способен решать сложные инженерные задачи.

На связи команда курса «Архитектура программного обеспечения» в Яндекс Практикуме. В этом материале мы расскажем, как ответили на запрос рынка и разработчиков и стали готовить инженеров в области архитектуры ПО, а также какие изменения внесли в курс совсем недавно.

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

Я покажу, как некоторые подходы из мира программирования (те самые best practices и идеи из Clean Code) помогают рисовать sequence-диаграммы чище и понятнее. 

Привет, Хабр! Некоторые функции DAX из Power BI могут выглядеть интуитивно понятными, но при детальном рассмотрении ведут себя не совсем ожидаемо. Например, SUMMARIZE не агрегирует «сразу», в месте использования, но SUMMARIZE реализуется через «виртуальную», «отложенную» агрегацию за счет сохранения состояния. Для суммы, т.е. SUM, промежуточное состояние и есть сумма и особенности SUMMARIZE не проявляются, но для любой другой агрегации (например, среднего AVERAGE) становится понятно, что в Power BI уже учитывается так называемое состояние для корректного расчета SUMMARIZE, т.е. данные по всем записям сохраняются в состоянии. В других СУБД единственный аналог — только State и Merge комбинаторы из ClickHouse, поэтому для иллюстрации состояний будет рассмотрен пример из ClickHouse, соответствующий DAX с SUMMARIZE и AVERAGE. Интересующимся особенностями SUMMARIZE в Power BI — добро пожаловать под кат :)

Работая над сайтом завода «ЭЛЕКТРОконнект», мы столкнулись с задачей, знакомой всем, кто делает проекты для технического B2B. На первый взгляд, всё просто: обновить сайт, сделать понятнее, удобнее, современнее. Но под этой простотой задачей скрывается целый пласт системных особенностей от отраслевых стандартов до внутренней логики работы с заявками, где каждая форма и таблица это часть производственного процесса.

Представляем наш синтез для языков России и СНГ. В этот раз получилось покрыть 20 языков, всего 95 голосов. От старой демки этот релиз отличается следующим:

Модель поддерживает SSML;

Модель стала быстрее ещё на 20-25% (она и так была супер быстрой);

С живыми дикторами были подписаны договоры на запись их голоса;

Запись велась в максимально высоком из практически доступного качестве;

Для ряда языков опубликованы модели простановки ударений и / или словари с ударениями в рамках silero-stress;

К модели синтеза применены все оптимизации, как к нашей прошлой публичной модели;

Для демки мы брали шумные публичные данные низкого качества. В этот раз всё хорошо - как следствие существенно выросло качество синтеза.

Какие главные проблемы технической документации? Во-первых, ее нет, во-вторых, если она есть, то не актуальна.

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

Существует три класса задач, которые решает техническая документация:

1. Описать наши требования к системе и принятые решения

2. Описать текущее состояние системы

3. Объяснить пользователю, как работать (\разворачивать\эксплуатировать) с системой.

Первый тип документации — наши требования к системе. В эпоху LLM, кодогенерации и декларативного подхода к описанию инфраструктуры, мы будем вести требования так, чтобы система, там где это возможно, сама собиралась из них. Поэтому документация первого типа потребует высокого аудита качества. Ревью изменений, совместная работа, ведение версий, с возможностью отката, автоматическая сборка. Все то, что присуще подходу Docs as Code.

Второй тип документации — описание текущего состояния системы. Так как мы не хотим разрыва между описанием системы и самой системой, мы будем пытаться генерировать человеко-читаемое описание из кода и конфигурации. Назовем этот подход Code as Docs.

Третий тип — различные виды пользовательской документации. Эту форму документации мы постараемся минимизировать, сделав понятным наши интерфейсы и встроив подсказки прямо в процесс работы пользователя с системой. Назовем это подходом No Docs.

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

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

В этой части цикла, посвященного разработке электропривода, мы сосредоточимся на его электронной составляющей. Рассмотрим топологии силовых узлов AC/DC, DC/DC и DC/AC электропривода, подбор электронных компонентов, а также ключевые нормативные стандарты, которых необходимо придерживаться при проектировании. Отдельный раздел будет посвящен выбору вычислительной платформы для управляющей платы — FPGA, DSP, SoC и другие варианты. Кроме того, затронем вопросы функциональной безопасности (safety) в электронике и требования к безопасной работе электропривода.

Авито — это не просто доска объявлений. Это настоящий музей народного творчества, странных ракурсов и загадочных предметов. Мы все видели эти фото: размытый диван в темноте, «селфи» чайника в зеркале или ковер, который видел еще Брежнева.

Но что, если бы эти продавцы имели доступ к технологиям будущего? 🤔

😏 Мы решили провести эксперимент. Взяли самые колоритные (и случайные!) объявления и попросили Искусственный Интеллект переосмыслить их визуал. Никакого сложного фотошопа, только магия нейросетей.

⚠️ Дисклеймер: Всё сделано исключительно ради юмора и науки. Любые совпадения случайны. Ни одно объявление не пострадало.

#вайбмаркетинг

🤖 Как я установил Ollama на Ubuntu 24.04 и начал обучать локальную LLM под свои задачи

В какой-то момент я понял, что хочу иметь свой личный ChatGPT прямо на ноутбуке — локальный, безопасный, работающий без интернета и полностью под моим контролем.

У меня обычная рабочая машина:

Ubuntu 24.04.3 LTS (noble)

x86_64

AMD Radeon Vega (Cezanne)

А значит, классические CUDA-модели мне не подходят — NVIDIA нет, но я всё равно хотел нормальную LLM у себя локально.

Решение — Ollama, движок для запуска локальных LLM-моделей в один клик.
Расскажу, как я его установил, какие модели поставил и как дальше можно обучать её под свои задачи.

Ранее я уже писал здесь о языковой модели Déiwos-Lókwos GPT, способной общаться на праиндоевропейском языке, подсказывать слова из праиндоевропейского лексикона и переводить тексты (особенно стихи) на праиндоевропейский. В прошлой заметке я делал реконструктивный эксперимент с переводом своего стихотворения на праиндоевропейский, «обкатывая модель».

В этот раз я решил эксперимент повторить, но дать модели более сложное стихотворение — тоже моего собственного сочинения, но содержащее более сложную лексику.

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

Xcode ужасен, и об этом много кто говорит. Постоянные ошибки, баги интерфейса, неочевидное поведение и местами плохая документация — всё это мешает спокойно писать код. Вместо работы над проектом приходится искать решения проблем и пытаться починить то, что должно работать из коробки. Ещё одна неприятность на этом пути заключается в том, что Apple не всегда публично рассказывает о багах в Xcode, поэтому надо ещё догадаться, что именно не работает.

В этой статье автор делится ошибками и «особенностями» Xcode, которые больше всего его раздражают. Главный совет: держитесь подальше от этой IDE и всегда ищите альтернативы.

При разработке сложной системы приходится сталкиваться с использованием nginx в качестве reverse proxy: роутинг, список правил, регулирующих путь запроса во внутренние системы или между подсистемами.
Быстро развивающиеся сервисы обрастают правилами, назначение которых не очевидно или имеет недокументированные особенности. Проверенный способ рефакторинга таких систем: зафиксировать и вылечить упростить. Фиксировать будем тестами.

Как проверить корректность вашей конфигурации Nginx'а? Как проверить ее безопасность и нет ли уязвимостей ? Какие есть для этого варианты, их плюсы, минусы, практическая применимость и как эти проверки встроить в CI пайплайн ?
Ответы на эти вопросы под катом. Будет полезно, погнали.

Всем привет. Я Артем Курочкин, frontend разработчик компании DD Planet.

Сегодня я расскажу об одном из ключевых нововведений в React, представленных на React Conf 2025. Прошу любить и жаловать ViewTransition - нативная поддержка view transition api в экосистеме реакта.

Что это значит для React-разработчиков и как нам всем это поможет, мы и разберем в этой статье.