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

"Разработчик – это человек, который переводит мысли заказчика на язык машины"
@mikita_du

Идея статьи появилась год назад, думал назвать «Вёрстка в 2021», но как-то затянулось… Весной 2021 года Microsoft объявила, что с 15 июня 2022 года прекращается поддержка IE11 (да, не для всех версий Win 10, но всё же), а значит, к выходу статьи уже останется менее полугода до знаменательного события, когда не придётся верстать под IE.

Для меня же это значит, что можно будет по полной использовать новые стандарты браузеров, в частности – css-variables, grid layout.

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

Привет, меня зовут Андрей, я занимаюсь инфраструктурой поиска в Авито и сегодня расскажу, зачем это вообще нужно — печатать вещественные числа. Какие есть методы (один) решения этой боевой задачи и как это получилось у нас в проекте, в рамках наших очень странных требований. А также, зачем таки подобное, хм, умеренно эзотерическое знание, может когда-то понадобиться и вам. На каком бы вы языке не писали. Read on!

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

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

По Википедии

Проверка кода (code review) — отличный инструмент для повышения качества кода, но он не учитывает один факт: отправляют и просматривают код люди, а они устают, теряют сосредоточенность, ленятся, да и просто испытывают эмоции в самые неожиданные моменты.

Поэтому хочу представить свое видение хороших и плохих практик код ревью с учётом человеческих особенностей.

Переехать в микросервисы можно двумя способами. Можно построить платформу — это надежно, но очень сложно. Или можно поднять Kubernetes и начать в него коммитить новые сервисы. Переезд проходит быстро и легко, но редко получается то, на что вы рассчитываете. Например, вместо микросервисной структуры вы можете обнаружить распределенный монолит.

Многие при этом не задумываются, правильно ли они пилят микросервисы. Как в синдроме утенка: увиденное самым первым становится единственно верным решением.

Меня зовут Олег Федоткин, я Head of PaaS СберМаркет, мы занимаемся той самой платформой, которая помогает разработчикам лучше, удобнее и быстрее писать микросервисы. Мы стандартизируем всю разработку, стараясь снизить Time to Market для новых фич. Но это всё равно очень сложно. Поэтому сегодня я разберу самые распространенные микросервисные проблемы.

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

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

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

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

Меня зовут Кирилл Мокевнин, и я — сооснователь школы программирования Хекслет. За последние пару лет я провел собеседования с более чем 400 человек, потенциальными наставниками по совершенно разным направлениям в разработке. В результате у меня собралась большая выборка наблюдений, которые мы и разберем в этой статье.

Любой программный продукт, будь то веб-сайт или мобильное приложение, основан на коде. Чем согласованнее и целостнее эта база, тем удобнее с ней будет работать, например, при необходимости доработки проекта, передачи на сопровождение другой команде.

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

Некоторое время назад мне понадобилось процитировать известное письмо Дейкстры 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. В конце концов, эта методология предназначена для работы со сложными доменами, не так ли?

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