Рубрика «Анализ и проектирование систем» - 79

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

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

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

«Хочешь быть системным архитектором? Там только свет и чистота…» - 1

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

— Рома, я задолбался быть инженером. Всё, ухожу!
Он ласково улыбнулся и сказал:
— Хорошо. Будешь системным архитектором. Там только свет и чистота. Выспись и приходи, расскажу, что будешь делать.

Я был молодым и наивным. Выспался и пришёл. Тогда начал постепенно становиться архитектором (сейчас стал), и могу смело сказать: света и чистоты тут столько же, сколько в буднях инженера. А вот ответственности больше. Поэтому — нет, не надо быть архитектором, если вы не понимаете, на что идёте.

Но! Если понимаете — это будет очень увлекательное приключение.
Читать полностью »

Тесты в предыдущей статье убедительно показали высокую эффективность «автоматной» реализации примера «Дисплей» по сравнению с условно названной «неавтоматной» версией. Вкратце итог: обе реализации автоматные, но разница в эффективности многократна и глубинная причина видится в том, что вариант А1 («автоматный») изначально проектировался как автомат, а вариант А2 («неавтоматный») нет. Не столько автоматная реализация, сколько автоматное проектирование является основой высокой эффективности. Для простых алгоритмов автоматные реализации получаются сами собой. Есть смысл говорить о том, что автоматное программирование, это не столько реализация программы в виде конечного автомата, сколько автоматное проектирование, фундаментом которого является конструктивная декомпозиция. Я несколько раз касался темы автоматного проектирования и конструктивной декомпозиции, но чтобы раскрыть эту тему нужны практические примеры. В этой и следующих нескольких статьях я проведу практикум, покажу процесс автоматного проектирования, пытаясь по возможности приводить ход рассуждений присущих автоматному проектированию.
Читать полностью »

Отчет c мини-конференции Использование визуальных моделей в ИТ. Проверено опытом - 1

1 ноября на площадке Райффайзенбанка прошла мини-конференция «Использование визуальных моделей в ИТ. Проверено опытом.»

О том, как это было и что обсуждали, читайте под катом.
Читать полностью »

Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine - 1

Привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в Одноклассниках. Основные сферы моей компетенции — Zabbix, CFEngine и оптимизация Linux. У нас более 8 тыс. серверов и 200 приложений, которые в различной конфигурации формируют 700 различных кластеров. Тема этой статьи исчерпывающе описана в заголовке.

Сразу хочу оговориться:

  • Я буду предвзят, потому что участвовал во внедрении CFEngine в Одноклассниках.
  • Я пользовался CFEngine только версий 3.3—3.4.
  • Я не питаю никаких иллюзий по поводу CFEngine, это значимый игрок, но не лидер рынка и не его аутсайдер. В статье не будет сравнений работы CFEngine с другими системами.
  • Из систем конфигурации у меня есть опыт использования только CFEngine и Ansible.

Читать полностью »

Здравствуйте!

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

В википедии автоколебания объясняют так [2]:

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

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

В предыдущих двух статьях речь шла о диаграмме состояний и переходов, используемой для описания динамических процессов в автоматном стиле, и о том, что диаграмма состояний и переходов даёт наилучшее понимание таких процессов. Также были рассмотрены базовые методы реализации автоматов, заданных диаграммой состояний, и были очерчены артефакты автоматной схемотехники, доставшиеся от неё автоматному программированию. Но, до сих пор совершенно не затронут вопрос: насколько эффективны автоматно-реализованные программы?
Я бы сформулировал вопрос иначе: насколько эффективны автоматно-спроектированные программы? Такая формулировка вопроса намекает, что автоматное проектирование — источник высокой эффективности программ. Я ещё практически не касался столь важной темы как эффективность, и пример «Дисплей» идеально подходит для иллюстрации эффективности автоматного проектирования. В первой статье я познакомил читателей с «лабораторной» версией этого модуля, но тестировать я буду «боевой» вариант, процесс проектирования которого я приведу в следующей статье. Исследование эффективности будет выполнено для платформ msp430 и CortexM3.
Чтобы не быть субъективным, оценивая эффективность, нужно с чем-то сравнивать результаты. Поэтому я проведу тот же комплекс испытаний для неавтоматной реализации примера «Дисплей» любезно предоставленной michael_vostrikov, за что ему огромная благодарность и плюсы в карму.

Читать полностью »

Микросервисы: деплой, координация и согласованность данных - 1

Про микросервисы не рассказывал только ленивый. Вот и мы не ленивые. Решили поговорить о микросервисах. Но только не ещё раз о том, что это такое, а о том, как мы их сервируем в 2ГИС. Например, наши бекенды держат 15 млн пользователей в месяц. На встрече поговорим о деплое, координации и согласованности данных.
Читать полностью »

Сервис-ориентированная архитектура (SOA) - 1

Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:

  • Сочетаемость приложений, ориентированных на пользователей.
  • Многократное использование бизнес-сервисов.
  • Независимость от набора технологий.
  • Автономность (независимые эволюция, масштабируемость и развёртываемость).

SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.

Читать полностью »

Как быть тимлидом — моя версия - 1

Я был абсолютно двинутый на компьютерах и геймерствовал безбожно. В юности хотел пойти писать игрушки и даже некоторое время писал. Рос, рос, рос. Был в разное время разработчиком, тимлидом, проект-менеджером. Выяснилось, что в проекте надо не только кодить, но и предлагать какие-то решения сходу, обосновывать их, договариваться, быстро переключаться между разнородными задачами. Лично для меня это серьезная нагрузка на мозг. Перейти из режима «кодить» и «говорить ртом» — отнимает много сил.

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

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

Самое интересное — это собирать команду под себя на новый проект.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js