Закон Литтла хорош широтой применений.

Например, одним людям хочется понять, сколько касс поставить в магазине, чтобы очереди были не слишком длинными. Другим людям хочется понять, сколько задач может пролетать по их kanban-доске. Ещё есть люди, которых интересует вопрос "сколько запросов наш веб-сервис должен мочь обратывать конкурентно"?

Такие вещи можно прикинуть с помощью выражения:

L (среднее количество клиентов в системе) = λ (средняя интенсивность поступления клиентов) * W (среднее время пребывания клиента в системе)

Например, мы работаем в салоне цветов и на носу праздник. В наши двери влетает по 2 клиента в минуту. На выбор цветов и упаковку букета нужно 3 минуты. Это значит, что в салоне должно быть место на шесть человек.

Или, например, у нас есть веб-сервис, который обрабатывает запрос в среднем за 0.1 секунды. В сервис будет влетать 100 запросов в секунду. Получается, нужно сделать так, чтобы сервис мог обрабатывать 10 запросов одновременно. Если сервис решает вычислительные задачи, можно поставить CPU на 10 ядер и спать спокойно.

Если сервис совершает операции с диском, нужно думать о производительности диска. Например, HDD на 5400 оборотов в минуту позволяет перемещать считывающую головку 90 раз в секунду (90*60 = 5400). Для 100 запросов в секунду на сервис это уже маловато. Поэтому лучше поставить SSD, они могут делать десятки тысяч операций в секунду.

В нагрузочном тестировании теория очередей (aka теория массового обслуживания) очень важна.

Например, есть популярная система под названием Gatling. Она позволяет писать и исполнять нагрузочные тесты. На первых страницах документации Gatling всё усыпано терминами очередей.
Среди прочего поясняется, что есть открытые и закрытые системы. Нагрузка на них подается и замеряется по-разному. Открытые системы — это когда нагрузочные тесты управляют числом новоприбывающих пользователей. Закрытые системы — это когда нагрузочные тесты управляют числом пользователей, одновременно находящихся в системе. Если не знать разницы, на выходе нагрузочного тестирования можно получить странные цифры.

А ещё при нагрузочном тестировании можно прикольно применять закон Литтла. С помощью него можно проверить, не тормозит ли инструмент нагрузки больше, чем нагружаемая система.

Бывает, потеряешься в своей профессиональной деятельности, совершенно не понимаешь, что дальше. Вроде как и хочешь чего-то другого, но хочется чего-то хорошего, а не чтобы было из разряда "как повезёт, так и будет".

Тогда надо задать себе вопросы

1. Какая в моей области интересов самая важная проблема?
2. Я сейчас делаю какой-то вклад в решение этой проблемы? Если нет, то что нужно сделать, чтобы начать вносить свой вклад?

Не факт, что ответы будет легко найти, но искать их стоит. Ответы помогают увидеть верный путь. "This is the Way", как говорят мандалорцы.

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

Наверное, одна из самых сложных задач в инфобезе — это поднятие security awareness. Смысл в том, что нужно рассказать людям об опасностях мира (особенно цифровой его части). Научить людей не повторять чужие ошибки. Но людям некогда слушать лекции, плюс всё их внимание давно купили рекламные компании. Поэтому нужно быть крайне изобретательным просто для того, чтобы донести до людей добрые мысли.

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

Интересно всё-таки, насколько всё в мире может быть взаимосвязано.

Возьмём, например, мир Дюны. Автор-американец хотел, чтобы у одного из главных злодеев имя звучало "по-советски". Фамилию злодея подбирал по телефонной книге, остановился на "Владимир Харконнен". Звучит круто, но Харконнен — это финская фамилия.
Язык коренных обитателей Дюны (фрименов) называется "чакобса". Слово адыгейское, означает "язык охотников". При этом чакобса не похож на адыгейский, это смесь цыганского, сербохорватского и арабского.

И вот этих условиях нам нужно изображать какой-то domain-driven design и рисовать bounded context-ы :)

​​7 лет назад архитектура ПО стала моим хобби. Поначалу думал, что прочитаю пару книжечек и всё будет ясно. По ощущениям, всего пару белых пятен надо было закрыть, ведь в универе нас этому учили + на работе довелось вносить изменения в десяток очень разных систем. Оказалось, чем больше разбираешься в архитектуре, тем больше возникает конфузящих вопросов.

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

Наверное, начать нужно со слова "архитектура". Корень слова древнегреческий, означает "главный плотник". Мы не будем просматривать пару тысяч лет истории этого слова. В этом канале всё-таки речь про IT, поэтому лучше читать книгу жизни сразу с середины. Середина приходится на 1960-1970 годы. Тогда люди заметили, что программы можно писать примерно так же, как строить дома.

Слово "архитектура" для ПО было метафорой. Например, Есенинское "в саду горит костёр рябины красной" в какой-то мере описывает рябину по осени. Аналогично про архитектуру домов (костёр) и ПО (рябину). Да, костёр не полностью описывает рябину, но метафоры хорошо приживаются. Наверное, более подходящее слово для "архитектуры ПО" мы и не увидим, поэтому параллели со строительством домов всегда будут смущать новичков и тормозить разработку ПО.

В общем, в 80-ые на вопрос "Что такое архитектура ПО?" можно было отвечать: "Это чертежи, по которым будет строиться программное решение. Ну и все активности, которые привели к появлению этих чертежей, разумеется". Пример чертежа на картинке ниже. Кстати, активности по созданию чертежей называются проектирование.

Можно было говорить и что-нибудь другое, всё равно официального определения архитектуры ПО аж до 2007 года не появится.

(В продолжении будет про одного легендарного, но не попсового архитектора из 70-х...)

​​Должности "архитектор ПО" в 70-х не было. Возможно, потому что про архитектуру ПО никто не парился, писали софт как могли. Возможно, потому что называться "архитектором" не имея лицензии в некоторых странах незаконно (Калифорния, Австралия).

Но настоящие архитекторы встречались. Например, Кристофер Александер (да, фамилия Александер). Человек уникальный потому что не только построил несколько сотен зданий, но и обучил целое поколение айтишников. Из его идей возникли шаблоны проектирования ПО и гибкие методологии разработки.

В его The Timeless Way of Building (1979) было два необычных для того времени посыла (это сегодня они понятные и привычные):

1. Если строишь дом на века, нужно пользоваться хорошими шаблонами и избегать плохих. Например, в правильно спроектированном доме должно быть "солнечное место" (шаблон такой). Если солнечного места нет, будет грустно. Солнечное место можно сделать с помощью разных инструментов вроде высоких окон и поворота дома относительно сторон света. Солнечное место отлично сочетается с широкими подоконниками, на которых можно сидеть. В общем, основные шаблоны проектирования зданий, про которые должен знать архитектор, Александер выделил и описал. Если хочется знать, как должна выглядеть лестница или главный вход здания, рекомендую.

2. Если строишь дом на века, нужно вписать его в окружающую природу. Сделать так, чтобы дом стал логичным продолжением его окружения. Эта идея не новая, она бродила в умах архитекторов ещё в 1920-е годы. На картинке ниже пример, называется Дом над водопадом. Можно сказать, идеал архитектуры.

У ранних computer scientist-ов работы Александера были одним из немногих источников вдохновения. Студенты-компьютерщики читали их в обязательном порядке. Два посыла, обозначенных выше, глубоко закрутило в водовороте времени и они вынырнули только к 2000 году. Мы к ним ещё вернёмся.

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

(В продолжении будут интересные особенности постройки домов...)

​​Особенность строительства дома в том, что нужно всё важное спланировать заранее. Важного много, но возьмём что-нибудь одно, например, фундамент.

Тип фундамента зависит от кучи переменных. Если дом планируется возле речки или озера, там высокий уровень грунтовых вод. Поэтому нужен фундамент на сваях. Сваи не смогут удержать тяжёлый кирпичный дом, поэтому кирпичных домов возле рек и озёр нет.
Если фундамент лежит выше уровня промерзания грунта, зимой грунт ниже фундамента замёрзнет и вспучится из-за расширения воды. Это может сломать фундамент, а за ним и дом. Известно, что в Москве грунт может промёрзнуть на 1.7 метра, а в Новосибирске на 2.4 метра. Раз в этих городах фундамент нужно закапывать так глубоко, имеет смысл делать цокольные этажи.

В IT для фундамента частенько используют слово "платформа". Если смотреть глобально, мы живём во времена третьей платформы. Если смотреть локально, каждый IT-продукт с будущим пытается стать платформой. Аналогично фундаментам домов, платформы боятся грунтовых вод (текучки кадров), промерзания грунта (недостатка финансирования) и ещё много чего.

Если нужно построить несколько домов и сделать это красиво, всё становится гораздо сложнее. Например, мы хотим пять домов и фонтан между ними. Архитектору нужно продумать не только важные вещи вроде расположения подъездов, но и всякие мелочи. Например, нужно представить, что будет происходить с фонтаном на Новый год в Сибири.

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

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

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

(В следующем посте попробуем пройти через бурные течения в архитектуре ПО 2003 года...)

Прошу совета мудрого.

На днях сделал в блоге возможность собирать несколько статей в "серию". Под каждой статьёй, помеченной тегом серии внизу рисуется табличка как на картинке (пример на сайте). Давно мечтал так сделать, но вот что-то теперь вопросов много появилось. Вопросы в основном по тому, как нынче принято делать. Не уверен, что всё смогу исправить, но буду рад, если что-то новое про UI/UX узнаем :)

Так вот, вопросы:

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

2. Что делать с заголовком "Эта статья входит в серию"? Странно он выглядит, есть ощущение, что он должен быть частью таблицы ниже. Как отделить текст статьи от автогенеренной вставки про серии?

3. Что делать с "14 марта 2024 г." и тегами? Вроде как логично, что они в самом низу статьи, но всё равно как-то странно, что эти подписи после таблицы про серию. Они всё-таки больше относятся к тексту статьи, а не к серии. Если вставить "14 марта 2024 г." и теги до "Эта статья входит в серию", выглядит совсем не очень. Даже не знаю, по какому такому принципу UI/UX это кажется "не очень", было бы интересно хотя бы узнать его название :)

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

Вместо всех них воткнуть еженедельный слот для универсальной командной встречи на 1-1.5 часа. Лучше всего такое зайдёт для two pizza team, конечно.

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

Но зато всегда что-то новенькое:
• обсуждение чьего-то доклада на предстоящей конфе
• планирование
• ретроспектива
• обсуждение большой фичи и дизайна по ней
• инспекция кода сложного/проблемного модуля
• демо нового инструмента
• совместное обсуждение полезной для работы книжки, которую вы все читаете в фоне
• интервью приглашённого гостя из смежников
• ... и ещё миллион вариантов.

Постепенно можно перейти к продвинутым форматам, например, разговорным поединкам. Это сценки такие. Один человек играет роль разработчика, мечтающего о тестах, а другой играет роль заказчика-китайца, которому эти тесты нафиг не нужны, ему нужен релиз до чёрной пятницы. У них обоих (а также их слушателей) после такого поединка может появиться тонна интересных мыслей.

Главное — чтобы была агенда. No agenda — no attenda.

Финальная статья текущего цикла по архитектуре. Постарался в десяти абзацах и трёх картинках разложить 80% того, что важно понимать современному архитектору.

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

https://neexee.com/ru/posts/architecture-modernity/

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

Для того, чтобы Telegram нарисовал картинку под ссылкой, нужно, чтобы по ссылке открывалась страница со специальной разметкой. Разметка бывает двух стандартов: Twitter Cards и Open Graph.

Вот так выглядит разметка Twitter Cards для предыдущего поста:

<html><head>
<meta name="twitter:card"
  content="summary_large_image"/>
<meta name="twitter:image"
  content="https://neexee.com/modern.jpg"/>
<meta name="twitter:title"
  content="Архитектура: Современность"/>
<meta name="twitter:description"
  content="Ключевые идеи в архитектуре"/>
</head></html>

Для Open Graph разметка аналогичная, вместо twitter:title используется og:title и так далее. Стандарт Open Graph сделал Facebook в 2010 году. Видимо, стандарт был не очень open, плюс костыли принято подбирать под рост человека. Поэтому в 2012 году появились Twitter Cards. Telegram поддержал оба стандарта в 2015 году.

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

Кстати, на превьюшке предыдущего поста план развития самого древнего и самого южного города РФ - Дербента. Миленький город, рекомендую там побывать.

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

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

Допустим, ты научился этими инструментами пользоваться, и что? А то, что теперь ты можешь делать выбор получше, чем был «по умолчанию» в твоей прошивке.

Интересно, какой отпечаток оставляют на людях девизы других университетов? Вот у Гарварда просто слово «Veritas» («правда») 😁

Идеальная работа и благодарность

У Брукса в «Мифическом человеко-месяце» есть коротенькие списки радостей и бед айтишного ремесла. Меня они лет 7 назад так впечатлили, что я их выписал и приклеил на стену. Никогда до этого так не делал, а тут захотелось на них помедитировать.

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

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

Не нужно ждать-надеяться на очную встречу. Можно во время обычного ревью рядом с комментами в духе «это переделать» написать «красота какая, это многое проясняет, спасибо». Можно поставить лайк. А ещё лучше развернуто написать, почему что-то конкретное понравилось. Я тут не про американский стиль, где «awesome» на самом деле легко может значить «ни в коем случае», а про адекватную благодарность, по делу.

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

Как принимать благодарность и похвалу

Слова благодарности — это подарок. Поэтому и относиться к ним нужно как к подарку.

Когда тебе дарят подарок, не нужно судорожно шарить по карманам и отвечать: «подожди-ка, у меня тоже кое-что для тебя есть». Со стороны дарящего это выглядит так, что его не поняли и не приняли.

Странно отказываться от подарка со словами «ой, да не за что». Со стороны дарящего это выглядит как отказ от подарка.

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

Короче, в ответ на добрые слова в свой адрес просто говоришь «спасибо» и всё. Главное — это выслушать дарящего, тогда и «спасибо» будет искренним.

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

Статьи в таком формате тоже можно писать:
https://neexee.com/ru/posts/chinese-tactics/

Опенсорс на ТВ

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

kdenlive одна из таких. Это опенсорсный видеоредактор. Для казуалов вроде меня kdenlive явно не хуже Adobe Premier Pro, это 100%. На софт Adobe я насмотрелся пока работал у журналистов эникеем.

Конечно, без мини-игры в Linux там не обойдётся, но это даже и хорошо. У меня, например, не работала встроенная в редактор запись звука. Хотел сделать voiceover для куска видео, а редактор просто не видел мои аудиоустройства. Как сказали на форуме авторы kdenlive «Угу, мы эту функциональность временно удалили, чтобы упростить переезд с QT5 на QT6, в следующей версии вернём, не переживайте :)». В таких ситуациях два пути, либо компилить нужную версию редактора из исходников, либо писать внешние скрипты, которые будут подкладывать уже готовые записи в редактор. Я пошёл по первому пути.

В общем, очень радует, что есть крутой опенсорсный софт. Чистое искусство, которое ещё и масштабируется.