Technotext

Мы в компании Lavritech разрабатываем устройства и контроллеры автоматизации. Также разработали программную экосистему, которая может работать с разными интерфейсами, в том числе и Modbus.

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

В прошлом году узнали о появлении Быстрого Modbus, который должен был устранить большие задержки протокола. Идея понравилась, решили добавить в свои устройства. В статье расскажем о том, какой путь мы прошли и что получили в итоге.

Всем привет! Меня зовут Дима, я тимлид команды Яндекс Диска. Сегодня расскажу, как обрабатывать сотни терабайт загружаемого контента в день и быстро доставлять его в ленту со всеми фотографиями пользователя. Лента выглядит как локальная галерея на телефоне, но может содержать в себе сотни тысяч фотографий, хранящихся в облаке, и быстро переходить к любой точке среди огромного количества контента. 

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

Привет, меня зовут Вера, я Android‑разработчик в Яндекс Диске. Мы в Диске сейчас активно работаем над переездом на Compose с использованием дизайн‑системы. Про стабильность в Compose есть немало статей, однако ошибки продолжают cовершаться, поэтому решила поделиться своим опытом в формате ликбез‑статьи.

По моему опыту, многие кто начинают писать на Compose, делают это интуитивно. Почему? Чтобы привыкнуть, понять, осознать подход к декларативному UI — нужно много времени, и поэтому к пониманию стабильности приходят, как правило, сильно позже. Однако это важно, ведь правильно организованная стабильность уменьшает количество рекомпозиций, что улучшает производительность и плавность работы приложения.

Привет! Меня зовут Иван, я разработчик из Яндекс 360. Делаю Телемост — сервис для видеозвонков.

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

Всем привет! Я Виктор Брыксин, руковожу разработкой Яндекс Телемоста. В статье поговорим про декомпозицию задач в проекте и как можно получить реальные сроки его выполнения.

Спойлер: вы все равно ошибетесь, прогнозируя сроки. Но что можно сделать? Минимизировать шанс на ошибки и сделать их менее фатальными. Я расскажу про рабочие инструменты, которые помогли мне в свое время, — брать их на вооружение или нет, решайте сами. Если вы не знаете, как подступиться к декомпозиции сложного проекта и с чего начать, — эта статья вам в помощь.

Во время работы над проектом на Django Rest Framework (DRF) я столкнулся с необходимостью писать тесты для API, которые возвращали неотсортированные данные. Сортировка данных в API не требовалась, и делать её только ради тестов казалось нелогичным. Использовать для решения этой задачи множества оказалось невозможным, так как элементы множества должны быть хэшируемыми, коими словари не являются. Я искал встроенный способ сравнивать неотсортированные данные в pytest, но таких средств не нашёл. Зато наткнулся на обсуждение в сообществе pytest, где пользователи просили реализовать такую возможность, а разработчики pytest предлагали сделать это кому-то другому в виде плагина. Так родилась идея создания pytest-unordered.

Последние несколько лет мы в Postgres Professional активно занимаемся разработкой своего решения для горизонтального масштабирования PostgreSQL. Пользователям нужен был простой способ увеличить производительность путем добавления узлов. Традиционно для веба в таких случаях просто брали NoSQL базы или шардировали вручную, позже появились распределенные SQL-решения с поддержкой ACID-транзакций. Тем не менее терялась часть возможностей и достоинств PostgreSQL. Корпоративный рынок тяжелых вертикальных решений также сильно ограничен как ценой, так и доступностью. Поэтому исследованиями в области распределенных СУБД в компании занимались еще с 2017 года, а в 2020 началась работа над коммерческим продуктом. 

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

Привет, Хабр! Недавно мы делали доклад на конференции HighLoad 2023 — «Мифы и реалии Мультимастера в архитектуре СУБД PostgreSQL». Мы — это Павел Конотопов (@kakoka) и Михаил Жилин (@mizhka), сотрудники компании Postgres Professional. Павел занимается архитектурой построения отказоустойчивых кластеров, а Михаил — анализом производительности СУБД. У каждого за плечами более десяти лет опыта в своей области.

Порассуждаем о том, как развивалась технология «Мультимастер» в экосистеме PostgreSQL, остановимся на том, что она из себя представляет, на каких внутренних механизмах PostgreSQL основана и как её можно использовать.

Мы также поговорим о том, существует ли «Честный Мультимастер» (само понятие «Честный Мультимастер» достаточно специфично и в основном употребляется в кругу разработчиков), какие реализации у него есть и как его следует применять.

Много лет в комьюнити PostgreSQL никто не верил что эта СУБД в принципе может использоваться в системах с большой транзакционной нагрузкой. То есть, какие-то тестовые лаборатории, бэкенд веб-приложений средней руки и так далее — вот его типичные задачи. А когда нужна серьёзная нагрузка, это уже надо брать СУБД за много денег и не сомневаться. Ну и раз никто не верил, то и не развивал особенно его в эту сторону, оставляя всё больше повисших в воздухе вопросов.

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

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

Под катом мы подготовили практический шаблон, который поможет вам в этом.

Вы не стали чаще слышать о таком трендовом явлении, как Server Driven UI? Если вы ещё с ним не сталкивались, то в будущем обязательно столкнётесь. Я, как инженер, познакомилась с таким подходом чуть больше года назад, перейдя в другой проект в Альфа-Банке.

И если вы, как и я тогда, задаёте себе вопрос: «Что же это такое творится-то?», то рекомендую прочитать эту статью, где я на примере нашего нового функционала в приложении для физических лиц расскажу, что это есть на самом деле и как лёгким взмахом волшебной палочки backend-разработчик становится отчасти frontend’ером, реализуя на стороне серверной части не только логику, но и вёрстку всех экранов приложения.

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

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

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

Моя основная деятельность — конфиденциальная обработка данных. Это такая развивающаяся область науки и техники, в которой часто возникает что-то новое, поэтому терминология ещё не устоялась. То, чем я занимаюсь, по-английски называется Secure Multi-Party Computation, а на русский переводят как совместные или многосторонние вычисления. Однажды я видел перевод: «многопартийные вычисления», – но, надеюсь, это единичный случай. Лично мне нравится вариант: «конфиденциальные вычисления», который использует википедия. Его буду использовать и я.

Представьте, вы собрали какие-то ценные данные, зашифровали их и сохранили на диске. Таким образом, вы защищаете данные во время хранения (data-at-rest). Далее, предположим, вам нужно передать данные по сети с одного сервера на другой. Серверы устанавливают защищённое соединение и обмениваются данными – снова зашифрованными. Так серверы защищают данные во время передачи (data-in-transit). Пока всё знакомо и понятно. Далее вы собираетесь делать то, ради чего вы эти данные собирали, хранили и передавали: использовать их. Что-нибудь посчитать, агрегат какой-нибудь, статистику или даже модельку обучить. Анализировать зашифрованные данные —, затруднительно, поэтому вы их расшифровываете и… делате беззащитными.

Во-первых, это странно: вы старательно защищали данные, когда хранили и передавали, и вдруг почему-то перестали. Во-вторых, это опасно: атаки, утечки, несанкционированный доступ, всё, что угодно может случиться, когда данные уязвимы. Ну, и в-третьих, расшифровывать не обязательно: существуют методы, защищающие данные, когда они используются (data-in-use). Совместные конфиденциальные вычисления – один из них.

Фаззинг — очень популярная методика тестирования программного обеспечения случайными входными данными. В сети огромное количество материалов о том, как находить дефекты ПО с его помощью. При этом в публичном пространстве почти нет статей и выступлений о том, как искать уязвимости с помощью фаззинга. Возможно, исследователи безопасности не хотят делиться своими секретами. Тем интереснее рассмотреть эту тему в данной статье.

Предыстория

В сфере АСУ ТП инженерам по работе приходится не только писать ПО, но и использовать готовое ПО от производителей оборудования. В связи с санкциями, многие поставщики покинули РФ, а оборудование и ПО необходимо продолжать эксплуатировать дальше.

В данной статье будет расмотрена WinFXNet - программа производителя Schneider Electric (ESMI) для конфигурирования станций пожарной сигнализации серии Esmi FX. К сожалению, из-за санкций, ключ USB Esmi FX FFS00393016 приобрести нельзя, а он, в свою очередь, имеет встроенный таймер, который настроен на 4-летний период. У многих данный ключ по времени уже закончился, плюс скоро закончится и лицензия на само ПО (файл формата lic). Поэтому достаем дизассемблеры и посмотрим, можно ли обойти данную защиту.

Disclaimer: Данная заметка написана в ознакомительных целях и не является руководством к действиям. Хотя, понимая всю безвыходность данной ситуации, как временное решение имеет право на жизнь, но решать только вам. Статья написана как туториал, поэтому постараюсь детально описать все шаги поиска нужных мест в программе.

А сколько у вас в компании во внутренних системах используется наименований одного и того же поля в API? А сколько способов назвать поле, которое перечисляет список id?

Я часто сталкиваюсь с тем, что при проектировании и разработке HTTP REST API команды (чаще неосознанно) собирают целый семантический и лексический зоопарк наименований. Потом бывает сложно разобраться, что нужно записать в определенное поле, или какое название поля выбрать для перечисления списка ID из уже существующих.

Поэтому я однажды собрала для себя и коллег гайд–чек-лист под названием “Приглаживаем названия в API” и теперь публикую его для широкой аудитории. Уверена, что он кому-то да пригодится.

Всем привет, меня зовут Алексей Саетов. Я руководитель отдела НИОКР ООО «Турков». Ранее работал на инженерных должностях в НПО Энергомаш, и конструкторском центре «Boeing» в Москве. Сейчас наша команда работает над созданием жидкостного ракетного двигателя под легкую РН в условиях частного финансирования.

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

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

Готовые LLM для русского языка часто показывают низкую точность и ограниченные возможности. Проблемы конфиденциальности также вынуждают компании выбирать локальные модели.

Наша компания давно занимается искусственным интеллектом и стала часто получать подобные запросы от клиентов — создание ИИ-решения с локальной обработкой данных. Мы задались вопросом, какие LLM хороши для таких решений, что мы можем предложить заказчику? Всё это вылилось в большой рисеч разных языковых моделей.

В статье рассмотрим, какие LLM подходят для задач на русском языке, протестируем их по разным параметрам и выявим лидеров. Мы оценили генерацию текста, ответы на вопросы, исправление ошибок и другие функции.

Александр Кушнеров
10.01.2025

 Аннотация – Дизайн замкнутых комбинационных схем основан на законах поглощения конъюнкций и дизъюнкций. Если в такой схеме используется только один выход, то её транзисторная реализация будет избыточной, а граф этой реализации будет содержать ложные циклы. Значения на выходах комбинационной схемы, в том числе и замкнутой, можно считать правильными лишь через какое-то время, необходимое для завершения всех переходных процессов. В статье показано как дополнить замкнутую схему индикатором завершения переходных процессов, т.е. сделать её асинхронной.

1. Введение

Замыкание выхода комбинационной схемы на один или несколько её входов может дать новую комбинационную схему. Поскольку данные обрабатываются от входов к выходам, обратную связь можно представить как направленную петлю на графе. С другой стороны, графы, которые задают контактные мостиковые схемы, содержат не направленные петли (циклы). Именно из-за петель такие схемы часто являются минимальными. Преобразование графа мостиковой схемы в последовательно-параллельный соответствует схеме на логических элементах. Это преобразование размыкает все петли и называется декомпозиция в базисе И/ИЛИ. Мы будем рассматривать декомпозицию, которая даёт минимальное количество логических элементов. Чтобы корректно замкнуть полученные схемы нужно выполнить определённые условия. В качестве этих условий мы используем известную замкнутую схему.

В инженерной практике релейно-контактные мостиковые схемы начали использоваться по крайней мере со второй половины 1890-х годов [1]. Однако, привлечение булевой алгебры для их анализа и синтеза состоялось лишь во второй половине 1930-х годов [2]. Рассмотрим простейшую мостиковую схему из пяти замыкающих ключей (контактов), назовём её K5. Каждый ключ в этой схеме управляется своей переменной. Присвоить переменные можно например так, как показано в Табл. 1. Последовательное соединение ключей записывается как произведение переменных, а параллельное – как сумма. Таким образом, чтобы записать булеву функцию схемы в дизъюнктивной нормальной форме (ДНФ), нужно найти все возможные пути от входа к выходу.