CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. Подход сформулировал Грег Янг на основе принципа CQS, предложенного Бертраном Мейером. Чаще всего (но не всегда) CQRS реализуется в ограниченных контекстах (bounded context) приложений, проектируемых на основе DDD. Одна из естественных причин развития CQRS — не симметричное распределение нагрузки и сложности бизнес-логики на read и write — подсистемы Большинство бизнес-правил и сложных проверок находится во write — подсистеме. При этом читают данные зачастую в разы чаще, чем изменяют.

Не смотря на простоту концепции, детали реализации CQRS могут значительно отличаться. И это именно тот случай, когда дьявол кроется в деталях.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Code your own blockchain in less than 200 lines of Go!".

Данный урок является хорошо адаптированным постом про простое написание blockchain на Javascript. Мы портировали его на Go и добавили дополнительных фич, таких как просмотр цепочек в браузере.

Мы продолжаем разбор докладов с конференции Highload++ на предмет эффективности выступлений. О том, что именно мы анализируем и зачем это нужно, я подробно рассказывал в первой публикации.

В прошлый раз мы разбирали выступление Артема Данилова. Сегодня посмотрим на доклад Евгения Россинского (ivi).



Но начнем не с самого доклада — а с мебели.

Привет, хабрапользователь! Сегодня я попробую представить тебе очередную статью о докере. Зачем я это делаю, если таких статей уже множество? Ответов здесь несколько. Во-первых не все они описывают то, что мне самому бы очень пригодилось в самом начале моего пути изучения докера. Во-вторых хотелось бы дать людям к теории немного практики прямо по этой теории. Одна из немаловажных причин — уложить весь накопленный за этот недолгий период изучения докера опыт (я работаю с ним чуть более полугода) в какой-то сформированный формат, до конца разложив для себя все по-полочкам. Ну и в конце-концов излить душу, описывая некоторые грабли на которые я уже наступил (дать советы о них) и вилы, решение которых в докере просто не предусмотрено из коробки и о проблемах которых стоило бы задуматься на этапе когда вас распирает от острого желания перевести весь мир вокруг себя в контейнеры до осознавания что не для всех вещей эта технология годна.

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

Предлагаю читателям «Хабрахабра» перевод публикации «Why Senior Devs Write Dumb Code and How to Spot a Junior From A Mile Away» за авторством Scott Shipp.

---

Одна из моих любимых цитат на все времена — Брайана Гетца (Brian Goetz), умнейшего чувака из мира Java, одного из авторов «Java Concurrency in Practice», кроме всего прочего. Цитата взята из интервью, опубликованного на сайте Oracle под заголовком «Пишите тупой код» («Write Dumb Code»). Гетца спросили, как писать хорошо работающий код.

Данная статья является продолжением инструментальной темы, затронутой в прошлой публикации. Сегодня мы постараемся разобраться со сборкой релизов Golang приложений в виде единого исполняемого файла, включающего ресурсные зависимости, и вопросом оптимизации размера итоговой сборки. Также рассмотрим процесс построения рабочего окружения отвечающего следующим требованиям:

1. Переносимость. Окружение должно быть легко воспроизводимо на различных машинах.
2. Изолированность. Окружение не должно влиять на версии установленных библиотек и программ на машине разработчика.
3. Гибкость. Окружение должно позволять собирать релизы для различных версий Golang и Linux (разные версии дистрибутивов и glibc).
4. Повторяемость. Не должно быть магии и тайных знаний, то есть все шаги сборки проекта и зависимостей должны быть описаны кодом.

В прошлом году мы рассказывали, как устроен фронтенд в Программе «Единая фронтальная система», о библиотеке элементов и нашем подходе к переиспользованию UI компонентов. Сегодня предлагаем сравнить несколько подходов к разработке React-компонентов, спасибо Cory House за отличный материал!

Если вдруг вся эта история прошла мимо вас, Let's Encrypt — центр сертификации от некоммерческой организации ISRG, существующий при поддержке EFF и многих компаний, взявшей на себя миссию дать людям бесплатные SSL/TLS сертификаты для сайтов и серверов. Сертификаты от Let's Encrypt уже используются на более чем 10 миллионах доменов.

Кроме очевидной бесплатности у сертификатов от Let's Encrypt есть особое, отсутствующее у любых других коммерческих сертификационных центров, достоинство: если вы однажды получили сертификат от Let's Encrypt, то, при прочих равных, это навсегда. Не нужно раз в год-два вручную обновлять сертификаты. Не нужно вообще вспоминать что сертификаты где-то есть. Получил, настроил и забыл!

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

Организации автоматического обновления сертификатов в статье уделено пристальное внимание, с тем чтобы вы могли в полной мере оценить это принципиальное преимущество Let's Encrypt.

В компании, где я работаю — большинство сервисов запускаются и работают в docker-контейнерах.

В связи с этим, у моих коллег-новичков-в-докере часто возникает вопрос — а как писать код и запускать его в этом чёртовом контейнере???

Для человека, написавшего около сотни docker-образов и запускающего их несколько раз в день — такой вопрос уже не стоит, но когда я разбирался с докером в давние времена — мысль "Как же писать код в докере? Это же сверхнеудобно!" долго была актуальной.

В статье я опишу свои практики работы с образами docker, которые позволяют писать код "как у себя в home", и даже лучше.

Язык php часто ругают, обычно необоснованно. Особенно удивляет, что javascript ругают меньше. Зачастую это делают люди, которые писали на нем 10+ лет назад, когда язык был действительно чертовски плох, да и разработчики в те времена не задумывались над качеством кода. Посмотрите хотя бы на код wordpress, который до сих пор вызывает шок.

Ругают необоснованно, но проблемы у языка, конечно же, есть, и они серьёзные. Разуметеся, если сравнить последние релизы php7 (с нормальным ООП и строгим тайпхинтингом) и php4, то разница будет колоссальная. Однако и в последних версиях языка не всё гладко, и до java/c# пока что очень далеко. Более того, берусь утверждать, что будущее php тоже довольно сомнительно (с точки зрения типов).

Другими словами, давайте рассмотрим предметно, что хорошо и что плохо в php с точки зрения типизации.

В TypeScript версии 2.2 был введён новый тип object. Он описывает любой непримитивный тип.
Следующие типы принято считать примитивными в JavaScript:

• boolean
• number
• string
• symbol
• null
• undefined

Все остальные типы принято считать непримитивными.

История началась с того, что нам понадобился доступ к HR-системе для чат-бота. Чтобы последний мог искать контакты сотрудников по запросу вроде: «Найди того, кто может починить пиканиску». В корпоративной инфраструктуре это выглядит так: мы идём в отдел автоматизации и говорим, что нам нужны данные из HRMS. И получаем закономерный ответ:
— Пишите ТЗ, предоставим API и сервер интеграции через 6 месяцев.
— Парни, вы чего? Нам бы побыстрее!
— Тогда пишите ТЗ и письмо руководителю, сможем СРОЧНО уложиться за 3 месяца.

А нам надо было за 3 дня. Поэтому мы пошли другим путём: попросили кадровиков завести нам бота в список сотрудников и дать ему доступ к системе. Дальше он уже делал то, что на его месте мог бы делать человек.

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

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

Но выяснилось, что смотреть такие уроки невыносимо тяжело, час, полтора времени у экрана, постоянное повторение одного и того же, выискивание изюма знаний из длинных «нудных» реплик автора, а зачастую и с эхом в записи, по причине плохого микрофона или медленного интернета, это очень тяжело. Но тем не менее, большой процент разработчиков, опираясь на наши еженедельные сессии парного программирования, изучили новый для себя React и успешно выполняют сложные задачи больших проектов. Но смотреть их скучно. Что делать?

Так появились шортики. Я собрал весь изюм из прошлых уроков, часто задаваемых вопросов на практике и дыр у новичков в собеседованиях и превратил их в 3х-4х минутные ролики. Принцип шортиков: пример кода, не больше 5 минут, заранее набранный код, не банальный контент, подтверждение вопроса практикой.

Криптография — сложная штука для понимания. Она состоит математических теорем, доказательств, что повышает порог входа. Но даже если вы используете её в своём проекте, не обязательно вникать в эти алгоритмы, главное понимать принципы работы.

Этот пост — перевод статьи.

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

У студентов начала XXI века была излюбленная отмазка: «У меня жёсткий диск полетел, а на нём как раз осталась дописанная курсовая». Пожалуй, это была одна из немногих проходивших причин. Но за этим враньём скрывается очень важный синдром современного общества — валить вину на технику. ДТП — электрика заглючила, отчёт не сдан — компьютер завис, проект не завершён — что-то всё тормозит, письмо забыли отправить — что-то с почтой, прозвонили по дублям — CRM тупит и т.д. Никакой культуры использования технологий. А какая она вообще должна быть, эта культура и как она соотносится с корпоративной культурой в бизнесе? Давайте поспорим — это огромный простор для дискуссии.


Когда рабочий софт не оставляет равнодушным

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

Инструмент командной строки netstat был одним из тех средств, которыми часто пользовались системные администраторы. Однако команда netstat была признана устаревшей и на смену ей пришла более быстрая и удобная в использовании команда ss.



Сегодня мы поговорим о том, как применять ss для того, чтобы узнавать о том, что происходит с сетью на компьютере, работающем под управлением Linux.

Перед вами перевод пятой части руководства по разработке веб-решений на базе Node.js, Vue.js и MongoDB. В первой, второй, третьей и четвёртой частях мы рассказывали о поэтапном создании клиентской и серверной частей приложения Budget Manager. Те, кому не терпится увидеть в действии то, что в итоге получилось у автора этого материала, могут заглянуть сюда. Кроме того, вот GitHub-репозиторий проекта. Если вы — из тех, кто ценит строгую типизацию, то здесь и здесь находятся результаты переноса Budget Manager на TypeScript.



Сегодня работа над этим учебным проектом завершится. А именно, в данном материале пойдёт речь о разработке страниц по добавлению в систему записей о новых клиентах и финансовых документах, а также о создании механизмов для редактирования этих данных. Здесь же мы рассмотрим некоторые улучшения API и доведём Budget Manager до рабочего состояния.

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

В Age of Empires эпичным было практически всё.

За последние 20 лет, в «Эпохах Империй» успели появиться 50 цивилизаций, суммарные продажи серии превысили 20 миллионов копий, и армия из сотен тысяч поклонников провела за игрой бесчисленные часы, причём многие из них играли в неё чуть ли не каждую неделю. Age of Empires является одной из самых влиятельных стратегий всех времен и народов. И сегодня вместо того, чтобы отправиться на свалку истории (что обычно рано или поздно случается со всеми старыми играми), «Империя» наконец-то приходит в сознание и возвращается к своим поклонникам.

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

Arstechnica пообщалась с создателями оригинальной Age of Empires о том, как проходила разработка знаменитой игры, и они откровенно рассказали о своих успехах и неудачах. Вашему вниманию предлагается краткий пересказ того, что нам удалось узнать; речь пойдет в первую очередь про первые части Age of Empires, которые заложили основу серии, но мы вспомним и более поздние игры Ensemble Studios.

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

Сеть подов в кластере – аккуратный материал, но сам по себе он недостаточен для создания долгосрочных систем, поскольку поды в Kubernetes эфемерны. В качестве конечной точки можно использовать IP-адрес пода, но нет гарантии, что при следующем воссоздании пода адрес останется прежним. Его смена может произойти по любой причине.