Давным-давно наш коллега @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...». А вот о том, что прячется под многоточием, мы сегодня и поговорим.

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

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

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

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

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

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

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

Привет! Это вторая часть рассказа о том, как мы поддерживали язык Frege в IntelliJ IDEA. Первую часть читайте здесь. Сейчас мы поделимся, как сделали автодополнение, систему сборки, интерпретатор и систему типов. И как все это тестировали.