Функциональное программирование может отпугивать сложностью и непрактичностью: «Я далек от всех этих монад, пишу на обычном C#, в докладе про функциональщину ничего не пойму. А если даже напрягусь и пойму, где мне потом это применять?»

Но когда объясняет Скотт Влашин, все совершенно не так: его доклад о композиции с конференции DotNext 2019 Moscow — пример того, как можно доносить функциональные идеи простыми словами. Он за час перешел от бананов к монадам так, что второе кажется немногим сложнее первого. А в конце объяснил, почему осмыслить композицию полезно даже тем, кто не собирается покидать мир ООП. Примеры кода в докладе как на F#, так и на C#.

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

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

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

Эта статья является конспектом материала Effective Aggregate Design Part I: Modeling a Single Aggregate.

Объединение сущностей (entities) и объектов значений (value objects) в агрегат с тщательно продуманными границами согласованности может показаться простым, но из всех тактических DDD шаблонов, агрегат является одним из самых сложных.

Для начала будет полезно рассмотреть некоторые общие вопросы. Является ли агрегат просто способом объединения тесно связанных объектов с общим корнем (Aggregate Root)? Если да, то есть ли какое-то ограничение на количество объектов, которые могут находиться в графе? Поскольку один агрегат может ссылаться на другой, можно ли перемещаться по агрегатам с помощью этих связей и менять данные объектов, входящих в определенный агрегат? И чем является инвариант и граница согласованности? Ответ на последний вопрос в значительной степени влияет на остальные ответы.

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

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

Швеция считается самой закрытой страной среди европейских. Спросили инженера, который 2 года назад уехал работать в Spotify, удалось ли ему вписаться в местную культуру, и как это сделать тем, кто только собирается переехать к суровым северянам. Рассказывает Константин Голиков.

«Забудь дедукцию, давай продукцию», —  эту формулу я усвоил сразу после окончания института. Тогда я ещё был финансистом и мир науки и образования меня буквально выкинул в мир бизнеса. Я ждал матриц, проектных структур, менеджмента строго по Мескону и Хедоури, а получил «твою мать, какого х** бюджет не сводится, давай, подрисуй цифирь и отправим это уже главнюкам». Вооот, а это была компания на 120 человек с чистой прибылью в пару сотен миллионов. Это было начало 2008 года, который компания пережила, сократив 23 человека. А вот декабрь 2014-го стал последним месяцем существования всего холдинга. Я, уже большой чувак, понимал, что это всё — результат череды управленческих ошибок. К тому времени я работал сисадмином в ИТ-компании и был уверен, что здесь всё будет круто. Сменив три ИТ-компании, я понял, что айтишники при всей инженерной стройности управляют и развиваются без вектора. И знаете, сейчас меня это тревожит.

Короче, я вам щас про реальный менеджмент затру. Субъективно.

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

При работе с крупномасштабной системой очень важно следить за ключевыми показателями этой системы, работоспособностью приложений и достаточным объемом данных, чтобы иметь возможность быстро отслеживать и устранять проблемы. Пребывание в ОБЛАЧНОЙ среде, такой как AWS, Google Cloud, Azure, еще больше усугубляет проблему и затрудняет обнаружение, устранение и локализацию проблем из-за динамического характера инфраструктуры (вертикальное масштабирование, временные машины, динамические IP-адреса и т. д.).

Нас нередко спрашивают (в статьях о Facebook, Spotify, софт скиллах), как понять, что ты можешь успешно пройти собеседование в Facebook/Amazon/Apple/Netflix/Google. Сейчас это особенно актуально, потому что многие IT-гиганты в США начинают нанимать на удалёнку. Так какие факторы позволяют предсказать успех? А кому на собеседования лучше не ходить, чтобы не тратить время?

Это небольшой мануал/история о том, как создать "идеальный" pypi пакет для python, который каждый желающий сможет установить заветной командой:

pip install my-perfect-package

Ориентирована на новичков, но призываю и профессионалов высказать свое мнение, как можно улучшить "идеальный" пакет. Поэтому прошу под кат.

Разберем как использовать облачный сервис Amazon для создания мессенджера Chatty многопользовательского чат-приложения в реальном времени с одной комнатой с помощью фреймворка Vue и AWS Amplify. Настроим регистрацию пользователей и хранение данных.

Всем привет, меня зовут Максим!

В начале 2020 года я решил сконцентрироваться на проектах по разработке программного обеспечения и перешел на позицию руководителя IT проектов в банк.

В рамках профессионального развития было определены 2 вектора сертификации Scrum и PMP, поскольку в нашем банке проекты в основном реализуются классическим водопадным подходом решил сначала получить PMP.

Явление деления разработчиков на уровни очень распространено. Даже в вакансиях чаще всего пишут не просто "Frontend-разработчик", а более развернуто - "Junior/Middle/Senior/${место для вашей должности} Frontend-разработчик". Для чего? С помощью такого деления легче делегировать задачи в команде. У каждого разработчика своя особая матрица компетенций, свои навыки, которые он оттачивал месяцами, а то и годами. С помощью такого деления процесс разработки ускоряется в разы.

Вообще на рынке (я смотрю на рынок стран СНГ) по состоянию на начало 2021 года среди Frontend-разработчиков имеют место быть такие должности (от низкого уровня, к наивысшему и без привязки к инструментам/библиотекам)

Kafka повсюду. Где есть микросервисы и распределенные вычисления, а они сейчас популярны, там почти наверняка есть и Kafka. В статье я попытаюсь объяснить, как в Kafka работает механизм хранения.

• как жить в мире, в котором среднестатистический инвестор паевого фонда получает доходность хуже рынка (купить рыночный портфель, то есть индекс);
• какие инструменты позволяют купить индексный портфель в один клик (биржевые фонды, они же ETF'ы);
• насколько эффективным может быть рынок, и как быстро новая информация отражается в цене акций (эффективность пугающая: рынок расследует космические катастрофы за несколько минут);
• если не покупать индекс, то можно ли заработать на фондовом рынке по-другому (можно, если вы помогаете остальным преодолевать рыночные трения);
• как автор инвестирует собственные деньги и копит на пенсию (всё скучно: индексные фонды).

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