Меня зовут Александр Донсков и я архитектор в компании REG.RU. Сегодня я расскажу о том, что такое Event Storming и что будет, если запереть 10 человек в одной комнате (в том числе виртуальной). Цель статьи не столько в том, чтобы рассказать, как это работает, сколько показать действенность подхода на реальных кейсах.

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

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

DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.

Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.

Как писать модульные тесты в проекте с TypeScript'ом? В этой статье я постараюсь ответить на этот вопрос а также покажу как создать среду модульного тестирования под проекты использующие TypeScript.

Не секрет, что Python является одним из самых широко используемых языков для анализа, обработки и визуализации данных, поэтому было логично реализовать функции Data Science в PyCharm. В прошлом году мы собрали много отзывов, и они помогли нам понять, как значительно улучшить поддержку Data Science в IDE. Но при этом стало очевидно, что у специалистов по работе с данными и разработчиков разные сценарии использования и ожидания от своих инструментов.

В итоге мы решили создать на платформе PyCharm совершенно новую IDE, которая заточена исключительно под задачи Data Science. Сегодня мы с удовольствием расскажем подробнее об этой IDE, а также приглашаем вас ее попробовать.

Рабочее название новой IDE — JetBrains DataSpell (но на момент релиза оно может измениться). JetBrains DataSpell — это удобная среда разработки для специалистов по Data Science, которые активно занимаются разведочным анализом данных (Exploratory Data Analysis) и прототипированием моделей машинного обучения.

Чтобы принять участие в EAP, подайте заявку на официальной странице. Учтите, пожалуйста, что мы будем рассылать приглашения поэтапно, а не всем одновременно. И не переживайте: если вы отправили заявку, то в любом случае получите приглашение.

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

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

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

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

В пике на нашей образовательной платформе проходит до 4 тысяч уроков в час. Основной инструмент общения преподавателя и студента — видеосвязь, потому что для обучения важно видеть и слышать друг друга. В самом начале мы использовали Skype, но его нельзя было интегрировать в платформу и логировать уроки. Потом мы перешли на SaaS-решения, но это оказалось очень дорого. Мы начали искать альтернативы и 2016 году отказались от покупных решений в пользу WebRTC и Janus. Теперь дорабатываем видеоконференции под образовательную платформу силами собственной команды. Да, пришлось копнуть глубже и потоптаться по граблям чужой технологии.
Рассказываем, как мы выкручивались и улучшали видеосвязь, чтобы она не попадала в топ жалоб от клиентов.

Уже третий день у всех на слуху слова Meltdown и Spectre, свеженькие уязвимости в процессорах. К сожалению, сходу найти что либо про то, как именно работают данные уязвимости (для начала я сосредоточился на Meldown, она попроще), у меня не удалось, пришлось изучать оригинальные публикации и статьи: оригинальная статья, блок Google Project Zero, статья аж из лета 2017. Несмотря на то, что на хабре уже есть перевод введения из оригинальной публикации, хочется поделиться тем, что мне удалось прочитать и понять.

Привет, хабраюзер. Поскольку, судя по всему, мы уже живем в будущем, то недавно я плотно засел за изучение новых фич ES6, ES7 и новых идей, предлагаемых React и Redux. И написал для своих коллег статью, в которой изложил сублимацию этих своих изысканий. Статья неожиданно получилась довольно объемной, и я решил опубликовать её. Заранее извиняюсь за некоторую непоследовательность изложения и отсылки к проприетарному коду из наших проектов — но думаю, что это всё же может помочь некоторым из нас лучше понять то, куда движется мир JavaScript, и почему не стоит игнорировать происходящее в нём.

Я расскажу про свои мысли о компонентых моделях, классах, декораторах, миксинах, реактивности, чистой функциональности, иммутабельных структурах данных и ключевой идее React. Сразу скажу — я не являюсь пользователем React, и все изложенное это результат чтения его документации и технических статей, объясняющих его архитектуру. То есть, некоторое идеализированное преставление, которое безусловно лишь упрощенная модель того, как оно всё на самом деле обстоит.