Анализ и проектирование систем *

Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём различные темы из компьютерной науки и раскладываем их по полочкам.

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

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

(Disclaimer!) Данная точка зрения не претендует на роль абсолютной истины и является лишь результатом моего опыта, чтения, наблюдений и размышлений.

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

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

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

На практике такое распределение используется, как правило, довольно узкими специалистами. В основном при математическом моделировании работы радиолокационных станций (РЛС), а также радаров с синтезированной апертурой и то в определенных условиях. Аналитиками данных в повседневной жизни конечно же не используется. Хотя, возможно К-распределение может описывать какие-то процессы, кто знает, эта сторона вопроса требует дополнительного изучения. Предлагаю аналитикам данных над этим подумать, а также всем желающим.

Привет! В этот четверг, 7 октября, в 19:00 мы проведем митап для системных аналитиков.

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

2+ часа, 4 спикера.

Каждому из нас приходилось адаптироваться на новом месте. Многим знакомо то чувство неопределённости и страха, когда перед тобой новая задача, а ты только делаешь первые шаги в профессии. Как быстро находить решение и приступать к задаче? Какой метод выбрать для описания требований? Что первично — макеты интерфейсов или архитектура системы? Какие технологии будут использоваться в разработке?

19:00 — Выживание аналитика в дикой природе, или как не опустить руки, разбираясь с задачей на новой работе

Юлия Капранова, ведущий системный аналитик

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

19:30 — Use case и user story, что лучше использовать и когда.

Алёна Разбежкина, ex-ведущий системный аналитик Альфа-Банка

Разберём, в каких случаях больше подойдёт use case, а в каких — user story. Поделюсь с вами шаблоном use case, который используют аналитики Альфа-Банка.

20:00 — Макеты дизайнера или архитектура? От чего отталкиваться при разработке?

Павел Бондаренко, главный системный аналитик

Может ли аналитик влиять на клиентские сценарии продукта? Как синхронизировать красивые макеты и не всегда красивый back-end? Попытаемся ответить в докладе.

С 2018 года компания KTS проводит курсы для разработчиков и менеджеров. И в этом году мы решили запустить наши курсы на своей собственной платформе для онлайн-обучения (LMS).

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

Российские BIM-технологии: проектирование систем электроснабжения в Model Studio CS

Эта статья цикла, посвященного российским BIM-технологиям, рассказывает об АРМ Электроснабжения. В основу АРМ положен программный продукт Model Studio CS Кабельное хозяйство, который может применяться при разработке разделов электроснабжения, электроосвещения, контрольно-измерительных приборов и автоматизации и предоставляет возможность сформировать трехмерную информационную модель объекта проектирования.

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

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

В статье мы рассмотрим:

- что изменилось в воркфлоу сбора требований;

- в чем для аналитика плюсы и минусы онлайн-коммуникаций;

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

В одном романе для того, чтобы подчеркнуть бесспорную красоту и поразительную сексуальность одной из героинь, автор использовал фразу: "She was a such kind of woman, that every man look at twice". Что в литературном переводе можно понять: "Одна была такой женщиной, что каждый мужчина оборачивался ей в след".

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

И в этом обзоре, я расскажу, почему, по моему мнению, это MUSH HAVE книга для каждого middle+ разработчика.

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

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

Недавно команда AutoFAQ решила сравнить свою технологию с решениями от известных компаний на конкретной практической задаче.

Всем привет! Меня зовут Александра Камзеева, я руководитель направления системного анализа в IT PMO в Lamoda. За полтора года мы выросли с 3 до 22 человек.

Такой стремительный рост и подтолкнул нас на вопрос: «Кто такой системный аналитик и какую роль он выполняет именно в Lamoda?» Мы поняли, что четкий ответ позволил бы нам эффективнее расширять команду, проводить собеседования и онбординг. Благодаря объяснению, кто мы такие, наши коллеги из разработки, QA, бизнеса лучше понимают, с какими вопросами и задачами стоит или не стоит к нам приходить. 

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

Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion. И сегодня я хотел бы рассказать вам про микросервисы.

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

Привет! Мы уже рассказывали в блоге о том, как работаем с данными на Мосбирже. Но задач, связанных с data, равно как и её разновидностей, настолько много, что одной публикацией точно не обойтись. К примеру, мы – Кирилл Хомутов и Дмитрий Польских – в составе команды ИТ-Финансы обрабатываем данные, которые используются для формирования финансовой отчетности. Сегодня поделимся опытом, как мы научились регулярно получать, агрегировать и «приводить к общему знаменателю» миллионы транзакций из различных ИТ-систем компаний Группы «Московская Биржи».

Не все знают, но Московская биржа – это одна из компаний группы, которая занимается организацией торгов разными классами активов, учетом активов, расчетами. В группу также входят Национальная Товарная Биржа (НТБ), Национальный клиринговый центр (НКЦ), Национальный расчетный депозитарий (НРД) и несколько небольших компаний, которые выполняют узкоспециализированные сервисные функции.

Все участники группы находятся под разным регулированием, по-разному ведут бухгалтерский учёт и сдают разную отчетность. Биржи ведут учёт по стандартам для некредитных финансовых организаций (НФО). НКЦ и НРД ведут учёт уже как банки, закрывая операционный день и т.п.. А сервисные компании ведут учёт по РСБУ в соответствии с требованиями Минфина.

Нам нужно было собрать все эти «разношёрстные» учетные данные и свести в единую модель, чтобы сформировать консолидированную внешнюю отчетность по международным стандартам (МСФО). Добывать информацию приходилось из очень разных источников. Как мы это делали — читайте дальше.

Имитационное моделирование в фарминдустрии: кейсы зарубежных фармкомпаний на платформе AnyLogic.

Цифровизация компаний фарминдустрии в России стремительно набирает обороты.  Один из ее основных трендов — имитационное моделирование бизнес-процессов. Западные фармкомпании успешно используют его в своей работе в противовес осторожному отечественному фармацевтическому рынку. Разберемся в причинах и перспективах данного направления. Использование в бизнесе компьютерного моделирования определяется дороговизной или длительностью проведения экспериментов на реальной системе. Имитационное же моделирование отличается от физического, компьютерными технологиями с использованием алгоритмов и уравнений. Имитационная модель позволяет просматривать анимацию в 2D- или 3D- формат, проводить аналитику в динамике, что невозможно в других случаях, например, при использовании Excel или линейного программирования. Для наиболее эффективного анализа работы системы и оперативного решения поставленной задачи пользователь изучает процессы и вносит изменения в имитационную модель непосредственно в ходе работы в удобном режиме, благодаря наглядности, простоте понимания и проверки.

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

В этой публикации я пытаюсь поразмышлять на следующие вопросы: из каких элементов состоит JavaScript-код? каким образом эти элементы взаимодействуют друг с другом? можно ли как-то повысить устойчивость кода к изменениям?

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

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

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

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

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

Произошло действительно страшное: мне предстояло путешествие по удивительному миру legacy-кода в старом корпоративном сервисе.

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

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

Лекции по курсу «Управление Техническими Системами» читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность!

Данные лекции готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется. В предыдущих сериях:

1. Введение в теорию автоматического управления.
2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13.
3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ РЕГУЛИРОВАНИЯ.
3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ.
3.2. Типовые звенья систем автоматического управления регулирования. Классификация типовых звеньев. Простейшие типовые звенья.
3.3. Апериодическое звено 1–го порядка инерционноезвено. На примере входной камеры ядерного реактора. 
3.4. Апериодическое звено 2-го порядка. 
3.5. Колебательное звено. 
3.6. Инерционно-дифференцирующее звено. 
3.7. Форсирующее звено. 
3.8. Инерционно-интегрирующее звено (интегрирующее звено с замедлением).

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

А так же узнаем что такое "астатизм" и почему это не лечится.

В настоящее время уже сложно найти крупную компанию, которая не использовала бы возможности накопления и использования больших данных. Меня зовут Никита Сурков и я работаю в проекте ценообразования "Пятёрочки" X5 Group. Проект является ярким примером использования больших данных, так как Пятёрочка -- это 18000 магазинов по всей стране. Чтобы построить систему ценообразования в такой сети требуется обработка миллиардов строк информации из чеков, данных по остаткам, себестоимостей и многих других данных. Для всего этого преимущественно используется PySpark, как один из популярных инструментов для работы с расперделёнными системами. В данной статье будет представлен один из методов написания кода на PySpark таким образом, чтобы он был более читаем, легко тестируем и поддерживаем. Сразу оговорюсь, что не представляю здесь единственное правильное решение, но оно доказало свою жизнеспособность на примере того проекта, в котором я работал.