Рано или поздно системный программист сталкивается с понятием firmware. В данной статье мы коротко рассматриваем, что это, зачем, и как с этим работать.

Disclaimer:
Материал не является сборником best practices и не претендует на фундаментальный труд. Это шпаргалка. Если угодно - application note в свободной форме. Основная задача материала - "сделать короткую статью, которая помогла бы лично мне быстро разобраться, если бы я впервые столкнулся с темой". Если вы знаете что-то лучше - дополнения и замечания по существу приветствуются. Мотивацией для написания послужила недавно встреченная статья, которая как раз объясняла эти аспекты не очень хорошо.

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

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

Так при чем тут "культурный контракт"? Все просто, при приеме каждого сотрудника моя первая беседа с ним была на основе тезисов:

Как выглядят паттерны DDD (Domain Driven Design) в большом проекте? А самое главное, стоит ли их вообще использовать? Рассмотрим, какими инструментами можно реализовать DDD на Go и оценим, насколько это больно.

Меня зовут Илья Сергунин, я backend-сочинитель в Авито: занимаюсь тем, что передаю смартфоны в хорошие руки. В этой статье попытаюсь объяснить, как можно натянуть DDD на Go без синтаксического сахара и магии Java-подобных языков, и без больших крутых ORM c Data mapper, которые также отсутствуют в Go.

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

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

Недавно решил обновить свой домашний MikroTik hAP ax2 до последней версии ROS7. Но столкнулся с проблемами при обновлении о которых поведаю под катом.

Когда я пытаюсь обойтись без *args и **kwargs в сигнатурах функций, это не всегда можно сделать, не вредя удобству использования API. Особенно — когда надо писать функции, которые обращаются к вспомогательным функциям с одинаковыми сигнатурами.

Типизация *args и **kwargs всегда меня расстраивала, так как их нельзя было заблаговременно снабдить точными аннотациями. Например, если и позиционные, и именованные аргументы функции могут содержать лишь значения одинаковых типов, можно было поступить так:

def foo(*args: int, **kwargs: bool) -> None:
    ...

Применение такой конструкции указывает на то, что args — это кортеж, все элементы которого являются целыми числами, а kwargs — это словарь, ключи которого являются строками, а значения имеют логический тип.

Но нельзя было адекватно аннотировать *args и **kwargs в ситуации, когда значения, которые можно передавать в качестве позиционных и именованных аргументов, могут, в разных обстоятельствах, относиться к различным типам. В таких случаях приходилось прибегать к Any, что противоречило цели типизации аргументов функции.

В ноябре 2022 года мы выпустили свою первую диффузионную модель для синтеза изображений по текстовым описаниям Kandinsky 2.0, которая собрала как позитивные, так и отрицательные отклики. Её ключевой особенностью была мультиязычность и использование двойного текстового энкодера на входе сети: XLMR-clip и mT5-small. Рефлексия после релиза подтолкнула нас к перестройке планов по развитию архитектуры и к сильному стремлению получить буст в качестве генераций, чтобы выйти на уровень аналогичных решений, названия которых слишком хорошо известны, чтобы их называть. В то же время мы могли наблюдать за появлением новых генеративных моделей и их файнтюнов, таких как ControlNet, GigaGAN, GLIGEN, Instruct Pix2Pix и др. В этих работах представлены и новые взгляды на генерацию, и новые возможности использования латентного пространства для внесения контролируемых изменений через текстовые промты, а также для смешивания изображений — возможности использования генеративных моделей расширяются постоянно. Бурное развитие прикладных кейсов привело к интенсивно нарастающему числу различных привлекательных для пользователей реализаций этих функций — визуализация городов, изображения известных личностей в нетипичных ситуациях и многие другие.

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

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

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

Решение — подход DDD, Domain Driven Design, было предложено Эриком Эвансом в 2003. Но прежде, чем о нем говорить, необходимо немного углубиться в историю развития разработки софта как такового.

Количество классов в реализации даже небольшой программы на один человеко-месяц исчисляется десятками. В средних программах на несколько человеко-лет счёт идёт уже на тысячи. А человек может одновременно оперировать 7-ю +/- 2 объектами. Поэтому все нетривиальные программы требуют декомпозиции своей реализации на более крупные блоки, чем классы - я буду называть такие блоки пакетами.

Сейчас наиболее распространены два основных подхода к декомпозиции систем: пакетирование по слоям и техническим аспектам (далее просто "по слоям" для краткости) и пакетирование на основе предметной области (представленное группой вариантов: пакетирование по фичам, пакетирование по компонентам, ограниченные контексты и пакетирование по агрегатам из предметно-ориентированного дизайна (DDD))

Однако ни один из этих подходов мне не подошёл в полной мере и я изобрёл…​ объектно-ориентированный подход к декомпозиции систем. Точнее, я изобрёл простую методику выполнения декомпозиции, а потом понял, что на выходе она даёт штуки обладающие свойствами объекта.

Но обо всём по порядку - сначала я рассмотрю критерии оценки подходов, распространённые подходы и почему они мне не подошли. А закончу пост представлением методики выполнения объектно-ориентированной декомпозиции.

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

Тем не менее развернуть лабу из нескольких устройств с множеством сетевых интерфейсов и подключений, к примеру, для проверки BGP, в том числе между устройствами разных производителей, задача нетривиальная.  Можно, конечно, писать плейбуки Ansible для развертывания виртуалок на ESXi и последующей конфигурации устройств, но это само по себе достойная задача. Может быть что-то с vagrant изобразить…

Но недавно я узнал о проекте ContainerLab.dev и весьма впечатлился. Попробовал, оценил, впечатлился еще больше. Полез на Хабр почитать тонкости и хитрости, но, к удивлению, не нашел ни единого поста на эту тему.

Решил исправить. Вдруг кому-то еще облегчит жизнь.

Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что мы не до конца выяснили у заказчика и стейкхолдеров все требования, оставив множество умолчаний.

В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.

Возможно, многие подходы вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

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

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

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

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

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

Адрес TCP/IP поддерживает только 65000 подключений, поэтому придётся назначить этому серверу примерно 30000 IP-адресов.

Существует 65535 номеров TCP-портов, значит ли это, что к TCP-серверу может подключиться не более 65535 клиентов? Можно решить, что это накладывает строгое ограничение на количество клиентов, которые может поддерживать один компьютер/приложение.

Если есть ограничение на количество портов, которые может иметь одна машина, а сокет можно привязать только к неиспользуемому номеру порта, как с этим справляются серверы, имеющие чрезвычайно большое количество запросов (больше, чем максимальное количество портов)? Эта проблема решается распределением системы, то есть кучей серверов на множестве машин?

1. Мессенджер WhatsApp и веб-фреймворк Phoenix, построенный на основе Elixir, уже продемонстрировали миллионы подключений, прослушивающих один порт.
2. Теоретические возможности на основе протокола TCP/IP.
3. Простой эксперимент с Java, который может провести на своей машине любой, если его всё ещё не убедили мои слова.

Я считаю, что именно агрегаты из Domain-Driven Design лежат в основе поддерживаемых информационных систем. Однако эта концепция малоизвестна за пределами DDD-сообщества и довольно сложна для понимания, поэтому я решил написать очередной пост посвящённый агрегатам. В основном для чтобы структурировать собственное понимание агрегатов и создать "методичку" для своих команд, но и широкой общественности, я надеюсь, этот пост тоже может быть полезен.