Использование микросервисной архитектуры для построения корпоративных приложений взамен традиционной монолитной — популярный тренд в веб-разработке.

Первая проблема, которую вам предстоит решить, столкнувшись на практике с задачей написать микросервис на Python — выбор подходящего фреймворка.

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

Результатом моих раздумий стала небольшая библиотека CleanAPI, представляющая собой оболочку над Tornado, позволяющую повысить удобство разработки и снизить порог вхождения для новичков.

Моя дебютная статья – набор всяческих мыслей, которые местами связаны друг с другом, местами не очень. Все они навеяны моим личным опытом и довольно субъективны. Успел поработать я только в продуктовых ИТ-компаниях, для других областей многое наверняка будет мимо.

Частый вопрос на собеседованиях – с какими самыми сложными задачами вы сталкивались на работе? И откровенно говоря, ни с какими – трудности ведь вовсе не в самих задачах, самые сложные из которых заканчиваются в институте или придумываются самостоятельно и без особой нужды. На работе они могут быть небольшими, а могут быть очень масштабными. При этом у среднестатистического разработчика, обывателя типа меня, они почти всегда простые, если не сказать рутинные. Трудность состоит не в том, чтобы их решить, а в том как. Как сейчас принять такие решения, о которых не придётся жалеть в будущем? Спойлер: среди них в любом случае будут плохие, независимо от того, как устроен процесс разработки, сколько времени уделяется на проектирование, сколько людей там задействовано и т. д.

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

Руководитель технической дирекции ЯRUS, Дмитрий Илюхин

Сегодня мы поговорим о внутренней кухне рекомендательных систем на примере приложения ЯRUS. Разработчики предлагают ярусный контент – новости, видео, события, музыку и многое другое. Однако цель команды ЯRUS – не только собирать разнообразный контент на одной площадке, но и правильно показывать его пользователям, за что и отвечает рекомендательная система. Что же такое рекомендательные системы и как они работают, расскажет руководитель технической дирекции ЯRUS Дмитрий Илюхин.

— Привет, как ты долго занимаешься проектом?

— В ЯRUS я с самого его основания, с июля 2020 года. Многое, что вы можете увидеть сейчас, – итог наших общих трудов с командой.

— Расскажи чуть подробнее, как связаны приложение и рекомендательная система?

— Наше приложение выступает не только как социальная платформа, но и как агрегатор. Основная задача проекта – это собрать контент: аудио, видео, текст и изображения для пользователя так, чтобы он ему был максимально интересен. Для этого и используются рекомендательные системы. 

Есть два типа подходов. Первые основаны на том, что смотрит группа пользователей; вторые – на предпочтении конкретного человека. Мы учитываем всё.

Например, к нам в систему ежедневно подтягивается около 56 000 новостей от 10 000 источников СМИ. Все они проходят внутреннюю чистку: на качество, язык и прочие параметры. Оставляем только литературные тексты.

После этого идет формирование новостного сюжета. При выборе главной новости используются разные веса: новизна и объем новости. Это и станет той базой, что мы будем рекомендовать пользователям, используя различные алгоритмы ранжирования.

C интересом прочитал статью о впечатляющих показателях  процессора Эльбрус  на алгоритме шифрования  Кузнечик.  В этой же статье приведена ссылка на проект  с реализацией указанного алгоритма.    Вот мне и захотелось   посмотреть, как пойдет  реализация этого алгоритма шифрования на сигнальном процессоре  К1967ВН44(28) , с которым мне часто приходится работать.  

Шаг за шагом

DSP   серии  К1967ВНхх  имеют собственную среду разработки CM-LYNX , компилятор С и С++ на базе Clang.   Этого набора достаточно чтобы попробовать  сделать оценку производительности процессора  на указанной выше реализации алгоритма . В архиве проекта   два файла: в одном 8-битная версия   алгоритма, а в другом 128-битная версия, т.е. вариант для процессоров поддерживающих операции со  128-разрядными числами.  

Для полноты эксперимента, начинаю с 8-битной версии. После компиляции и запуска на отладочной плате К1967ВН44, при максимально возможном уровне оптимизации  –О2,  получаю результат

Self-test OK!

kuz_encrypt_block(): 54.804 kB/s (n=200kB,t=3.649s)

kuz_decrypt_block(): 52.435 kB/s (n=200kB,t=3.814s) 

Программа    информирует , что тест самопроверки  прошел успешно , а затем производит замер скорости шифрования-дешифрования. По умолчанию, в инструментальном софте для платы К1967ВН44 используется определение  частоты процессора 250 МГц. Для этой частоты и произведены вычисления.            

Чтобы понять, что это за уровень скорости  54.804 kB/s, приведу аналогичный показатель последовательной обработки для процессора Эльбрус(8СВ) -  150 мегабайт в секунду на одном ядре. До Эльбруса  нужно еще ускориться где-то в 3 000 раз.  

Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето:
- 20% времени мы пишем новый код.
- 80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).

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

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

Изучая тему мобильной разработки обнаружил, что руководство компании Apple по дизайну и разработке приложений Human Interface Guidelines не переведено на русский язык.

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

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

Если увидите, что в каких-то местах текст переведен некорректно или плохо, и у вас есть идея о более правильном варианте, прошу написать на почту [email protected], указав в теме письма "HIG - перевод".

Перевод размещен здесь: Human Interface Guidelines for iOS.

Недавно я в очередной раз столкнулся с типичной проблемой: для создания нового функционала фронтенд и бэкенд нужно было реализовывать параллельно. Но как делать фронт, не имея 100% рабочих эндпойнтов на бэкенде? Сегодня я расскажу о том, какие подходы применял, и разберу их плюсы и минусы.

Столкнулся с проблемой нормальной реализации коллекций в PHP. Доктриновские коллекции мутабельны и инвариантны. PSL коллекции инвариантны. Нигде не видел непустых коллекций. Везде меня что-то не устраивало и было принято решение написать свою open source реализацию иммутабельных коллекций с ковариантными темплейт-параметрами и выстроенной иерархией пустых и непустых коллекций. В качестве статического анализатора был выбран Psalm.