Некоторое время назад мне понадобилось процитировать известное письмо Дейкстры 1968 года, и я воспользовался случаем, чтобы таки внимательно прочитать его. В наши дни "споры о `goto`" уже неактуальны, поскольку в большинстве современных языков команды `goto` либо нет вообще, либо используется она редко, и стало быть, обсуждать особо нечего. Однако мне была интересна аргументация. В нашей области масса "фольклорного знания", которое на поверку не всегда оказывается точным (что хорошо показано в книге Боссавита), так что оценить логику Дейкстры с позиции сегодняшнего дня не помешает. Надо сказать, что его формулировки не всегда легко понять, поэтому я решил изложить их несколько более простым языком, потратив немного больше места.

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

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

Что еще? Думаю, что надо договорится о подаче материала. Что, если это будет реальная история из моей практики, на мой взгляд, максимально демонстрирует работу Программного архитектора, а также некоторые выводы, которые можно сделать из нее. Постараюсь ответить здесь на следующие вопросы: Кто такой программный архитектор, какими навыками и знаниями должен обладать этот человек? Годиться? 

И последнее, думаю надо представится. Меня зовут Владимир Воловиков. Работаю в ИТ сфере я уже почти 20-ть лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

В архитектуре программного обеспечения существует один малоизвестный паттерн, заслуживающий большего внимания. Архитектура, ориентированная на данные, (data-oriented architecture, DOA) была впервые описана Радживом Джоши в отчете RTI 2007 года, а затем в 2017 году Кристианом Ворхемом и Эрихом Шикутой из Венского университета в статье iiWAS. DOA — это инверсия традиционной дихотомии между монолитным кодом и хранилищем данных (монолитная архитектура) с одной стороны, и небольшими распределенными независимыми компонентами с собственными хранилищами (микросервисы и сервис-ориентированная архитектура) с другой. В архитектуре, ориентированной на данные, монолитное хранилище данных является единственным источником состояния в системе, на которое воздействуют слабосвязанные микросервисы без состояния.

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

Эта статья является переводом материала «Untangling Microservices, or Balancing Complexity in Distributed Systems».

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?

В этом посте я хочу ответить на эти вопросы. Вы узнаете об общих проблемах проектирования, которые превращают микросервисы в распределенные большие комки грязи (distributed big balls of mud), и, конечно же, о том, как их избежать.

Давным-давно наш коллега @novar разместил на Хабре статью с описанием вот такого незатейливого ТЗ, полученного им от потенциального работодателя:

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

Хочу предложить алгоритм, приближающийся к O(1) во всех возможных ситуациях, вместо оригинального O(n). Интересующихся прошу под кат.

Ах да. Если вы тот самый работодатель, вот готовый код под ваше ТЗ. Правда на Java, а не на C#. Но вы же не думали, что всё будет так просто?

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

Первая из них — "История одного фееричного провала тестового задания на C#" — была написана в жанре пространной жалобы соискателя на невежливый ответ (дословно: "отвратительно, халтурно") нанимателя на решение тестового задания, которое автору дали при попытке устройства на работу. В принципе, у меня эта статья особого интереса не вызвала: там было вполне рабочее решение — но без всякого блеска и с явными следами торопливости (похоже, именно они не понравились нанимателю) — не слишком интересной задачи — сделать класс, разбирающий строку расписания в cron-подобном формате и реализующий методы поиска в этом расписании.

Однако через некоторое время на Хабре появилась вторая посвященная этому тестовому заданию статья. Его решение в той статье было с монадами и goto, и оно произвело на меня сильное впечатление. Первая мысль после прочтения у меня была "Круто!" (или, как выразился автор первого же комментария "Шикарно"). В частности, одна из примечательных особенностей решения — использование для разбора строки не своего "велосипеда", а хорошей сторонней библиотеки.

Тем не менее, на второй взгляд все оказалось не так хорошо, на как на первый. Та часть решения, которая представляет собой программу-разборщик строки расписания, могла быть существенно улучшена, с сокращением объема и улучшением понятности, если для этого полнее использовать методы той же самой библиотеки для построения разборщиков (ну, и не забывать, что мы пишем на языке C#). Если вам интересно, как, почему и что может быть сделано — добро пожаловать под кат.

Эта статья является переводом материала «Tackling Complexity in CQRS».

Шаблон CQRS может творить чудеса: он может максимизировать масштабируемость, производительность, безопасность и даже «превзойти» теорему CAP. Тем не менее, например, в своей статье о CQRS Мартин Фаулер утверждает, что шаблон следует применять умеренно и даже осторожно:

«...для большинства систем CQRS добавляет риски»;

«...вы должны быть очень осторожны при использовании CQRS»;

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

С моей точки зрения, сложность, вызванная CQRS, в значительной степени случайна, и поэтому ее можно избежать. Чтобы проиллюстрировать свою точку зрения, я хочу обсудить цель CQRS, а затем проанализировать 3 распространенных источника случайной сложности в системах, использующие CQRS.

Эта статья является переводом материала «Tackling Complexity in the Heart of DDD».

Давайте проведем небольшой эксперимент: попробуем объяснить суть предметно-ориентированного проектирования (DDD) тому, кто понятия об этом не имеет. Это, особенно если делать кратко, непросто. Ограниченные контексты, сущности, события домена, объекты значений, домены, агрегаты, репозитории… с чего начать?

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

В кодинге главное — не кодинг

Всем привет, это Макс Кравец из Holyweb. Знаю много историй, когда начинающего специалиста с первого дня бросают на задачи, за которые никто не берётся, и ждут, пока новый сотрудник сам «выплывет». А перегорит и уйдёт — значит, просто слабак, который не хочет работать.

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

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

Так уж случилось, что я пишу код для разных IoT-железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основным фокусом является не экономия каждого байта и такта процессора, а понятный и надежный код. Поэтому в проекте разрабатывают под Embedded Linux и в качестве основного языка используют C++ в его современном варианте - C++17, активно поглядывая на фичи из стандарта 20-го года и новее.

Иногда запускаются новые проекты на той же платформе, с теми же процессами и с переиспользованием многих уже существующих компонентов, и тогда в эти проекты мы ищем программистов, с учетом вышесказанного - программистов на C++. В embedded, тем не менее, чистый C все еще очень популярен, и нередко собеседоваться на вакансию C++ Developer'а приходят именно сишники. Логика у человека простая: языки, на первый взгляд, довольно близкие, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится.

Откуда вы знаете, что написанный вами код - удобочитаемый?

Недавно в Твиттере развернулась очередная дискуссия о парном и групповом программировании, в которой Дэн Норт отметил:

"Сейчас я говорю об очень каверзной проблеме. Если вы считаете, что умеете писать код, не согласуя и не калибруя его с другими людьми, и при этом он будет понятен другим людям (то есть, что после проверки вашего кода его всегда одобрят) – то вы программируете куда лучше меня."

— Dan North

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

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

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

Разбираем рекомендации по безопасному программированию ПЛК, формируем список своих рекомендаций. Всех неравнодушных прошу под кат.

Обычный, теневой, виртуальный, инкрементальный… Как получилось, что простой программный интерфейс доступа к элементам веб-страниц обзавелся таким количеством «родственников»? Чем современные фреймворки не устраивает стандартная объектная модель документа или просто DOM? Что и как на самом деле отрисовывает браузер в процессе рендера веб-страницы?

Всем привет, это Макс Кравец из Holyweb. Помните сцену из Матрицы, в которой один из юных кандидатов в Избранные наставляет Нео: «Не пытайся согнуть ложку. Первое, что ты должен понять — ложки не существует!»? Давайте переформулирую: «Не пытайся изменить DOM...». А вот о том, что прячется под многоточием, мы сегодня и поговорим.

Держите ПЛК в режиме исполнения. Если ПЛК вышел из режима исполнения, то следует выдать предупреждение оператору.

Разбираем рекомендации по безопасному программироваю ПЛК, формируем список своих рекомендаций. Всех неравнодушных прошу под кат.

Разделите код на модули, рационально используйте программные организационные единицы. Тестируйте модули независимо.

Разбираем рекомендации по безопасному программироваю ПЛК, формируем список своих рекомендаций. Всех неравнодушных прошу под кат.