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

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

Паттерн (CQRS — Command and Query Responsibility Segregation) разделяющей в своей основе команды по чтению данных от команд по их модификации или добавлению. Это позволяет достичь максимальную производительность, масштабируемость и безопасность, а также позволяет увеличить гибкость системы к модификациям с течением времени и снизить количество ошибок при усложнении логики системы, причиной которых обычно является обработка данных на доменном уровне.

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.

Если использовать БД временных рядов (timeseries db, wiki) как основное хранилище для сайта со статистикой, то вместо решения задачи можно получить много головной боли. Я работаю над проектом, где используется такая база, и иногда InfluxDB, о которой пойдет речь, преподносила вообще неожиданные сюрпризы.

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

Видеосвязь — основной способ общения преподавателя и студента на платформе Vimbox. Мы давно отказались от Skype, перепробовали несколько сторонних решений и в итоге остановились на связке WebRTC — Janus-gateway. Некоторое время нас все устраивало, но все же некоторые негативные моменты продолжали вылезать. В итоге было создано отдельное направление по видео.

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

Технология GraphQL за последние несколько лет, после того, как компания Facebook перевела её в разряд опенсорсных, стала весьма популярной. Автор материала, перевод которого мы сегодня публикуем, говорит, что попробовал работать с GraphQL в среде Node.js и на собственном опыте убедился в том, что эта технология, благодаря её замечательным возможностям и простоте, неслучайно привлекает к себе столько внимания. Недавно он, занимаясь новым проектом, перешёл с Node.js на Golang. Тогда он и решил испытать совместную работу Golang и GraphQL.

Для тех, кто администрирует серверы и/или веб-проекты остро стоит вопрос информированности о том, что же происходит с их «подопечными». На рынке существует масса решений об оповещении о сбоях, состоянии соединения и прочих параметрах, в том числе и с помощью СМС. Речь о MRTG, Twilio, F-Droid, сервисах Google и многих-многих других. Вот только проблема в том, что большинство из этих решений весьма узко специализированы, а повлиять на их функции не представляется возможным. MRTG отдаст информацию о трафике и соединении, Google пришлет СМС. Кое-какую свободу дает Twilio в плане написания скриптов на JavaScript под свои нужды, но простите, это же коммерческий проект. То есть «давай, плати бабло или проваливай».

Так вот, в этом семействе инструментов у нас есть open source пополнение: Gotify — простой клиент-серверный проект для получения и отправки пуш-уведомлений и команд, в том числе и через Android-приложение. И о нем определенно стоит рассказать чуть подробнее, думаю, это пригодится для тех, кто искал нечто похожее и при этом бесплатное, но в итоге завел собственный pet-project. Вполне возможно, эта публикация сэкономит пару сотен часов вашего времени.

Учимся дебажить с perf — целых 18 страниц про основные подкоманды, фичи и устройство инструмента. Джулия рекомендует; “Я даже использовала его несколько раз для профилирования Ruby программ!”

Уровень сложности — для суперпродвинутого администратора.

Когда нужно отыскать причину сбоя, не имея доступа к исходным кодам. Все логи уже просмотрены, все debug и verbose-ключи включены, а причина проблем так и не обнаружена — используйте perf. Потребуется навык кодинга на языках типа Си.

Эту четырёхминутную короткометражку сделал студент из Нью-Йорка

Анимационные фильмы, созданные при помощи шлема VR, не являются особой новинкой. Но большинство из них – это отдельные сцены, зацикленные в повторяющуюся петлю типа анимированного GIF. Возможно, там двигается камера, выхватывает какие-то детали, но как таковой истории там нет. Но мультфильм Wired – это дело другое. Это один из первых анимационных фильмов, созданных в VR, содержащий несколько сцен и выраженную историю. Эта прекрасная короткометражка показывает жизнь мальчика, изучающего мир без беспроводных технологий. Он падает с кабеля, натянутого над огромными небоскрёбами, что заставляет местных жителей взглянуть вверх и насладиться небом.

Перевод статьи опубликован с разрешения автора.

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

Asterisk — потрясающий конструктор. Хотите построить небольшую АТС для бизнеса? Берем Raspberry PI, накатываем готовый образ на флешку, 10 минут, и вы уже вбиваете логин с паролем на ваш SIP телефон и делаете первый звонок.

Хотите нечто большее? Ставим бесплатный и навороченный FreePBX Distro, заводим пользователей, добавляем нужные модули, и получается тоже вполне себе рабочий вариант.

А если у вашей компании есть деньги, вы можете выбрать для себя одну из многих платных коммерческих разработок на Asterisk: Welltime, Switchvox, Askozia или аппаратную АТС компаний Grandstream, Yeastar, Zycoo и так далее.

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

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

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

В статье рассматриваются различных технологии, которые использует Discord для аудио/видеочатов.

Для ясности всю группу пользователей и каналов мы будем называть «группа» (guild) — в клиенте они называются «серверами». Вместо этого здесь термин «сервер» относится к нашей серверной инфраструктуре.

Добро пожаловать на презентацию «Практический шпионаж с помощью сотового телефона». Прежде чем мы начнем, сделаю пару замечаний по поводу конфиденциальности. В-первых, звонок по сотовому телефону может быть записан прямо во время разговора. Сюрприз! Так что если вы не хотите, чтобы ваш звонок был записан, выключите свой телефон. Если вы пользуетесь услугами сотовых операторов Sprint или Verizon, вы не находитесь в сетях GSM, и моя система вообще не сможет говорить с вашими телефонами, так что вам не о чем беспокоиться.



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

Конференция DEFCON 18. Практический шпионаж с помощью мобильного телефона. Часть1

Мы хотим применить определённые методы, чтобы ускорить захват телефонов фальшивой сетью. На данный момент у нас есть простой перехватчик IMSI, вы можете попробовать позвонить и услышать записанное мною предупреждение. Вижу, что несколько человек подняли руки. Я имею в виду, что вы, ребята, подключаетесь к моей сети, и я перехватываю весь ваш трафик.
Во-первых, я теперь знаю все ваши IMSI и могу их отфильтровать, оставив только IMSI конкретного человека, который является моей целью. То же самое я могу проделать с фильтрованием IMEI, которые представляют собой идентификаторы телефонов. Например, я могу разрешить подсоединяться к сети только телефонам марки «Нокия» или только «Айфонам». Я могу сделать так, что только этот конкретный IMEI будет в моей сети и никого больше. Я могу ограничить доступ с помощью самых разных параметров.



Как я уже упоминал, для миграции людей из официальной сети в мою сеть требуется время, и мы можем сделать это быстрее, я расскажу об этом через секунду. Одно из главных ограничений этой системы то, что она принимает только исходящие звонки. Когда вы подключаетесь к моей сети, независимо от того, будет ли это Т-Mobile или AT&Т, ваш телефон отключается, потому что реально вы не подключены ни к одной из легальных вышек сотовой связи. Таким образом, как только приходит звонок, он поступает прямо в вашу голосовую почту. Это проблема разрешаема, позже я покажу вам, что исходящие звонки тоже могут быть записаны.

В последнее время GraphQL набирает всё большую популярность. Изящный синтаксис запросов, типизация и подписки.

Кажется: "вот оно — мы нашли идеальный язык обмена данными!"...

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

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

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

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

Одним тёплым холодным зимним вечером, хотелось согреться в офисе и проверить теорию одного коллеги, что C++ vector мог бы быстрее справиться с задачей, чем CPython list.

В компании мы разрабатываем продукты на базе Django и случилось так, что нужно было обработать один большой массив словарей. Коллега предположил, что реализация на C++ была бы гораздо быстрее, а меня не покидало чувство, что Гвидо и сообщество наверное немного круче нас в Си и возможно уже решили и обошли все подводные камни, реализовав всё гораздо быстрее.

Для проверки теории, я решил написать небольшой тестовый файл, в котором решил прогнать в цикле вставку 1М словарей одинакового содержания в массив и в vector 100 раз подряд.

Результаты хоть и были ожидаемые, но так же и внезапные.

В 2014 году я выступил на открытии конференции GopherCon с докладом под названием «Go: Best Practices for Production Environments». В SoundCloud мы были одними из первых пользователей Go и к тому времени уже два года писали на нём и поддерживали Go в бою в той или иной форме. За это время мы кое-чему научились, и я попытался поделиться частью этого опыта.

С тех пор я продолжал программировать на Go в течение всего рабочего дня, сначала в командах SoundCloud, отвечающих за операционную деятельность и инфраструктуру, а теперь работаю в компании Weaveworks над Weave Scope и Weave Mesh. Также я усердно трудился над Go kit, набором инструментов для микросервисов с открытым исходным кодом. И всё это время я принимал активное участие в развитии сообщества Go-программистов, встречался со многими разработчиками на митапах и конференциях по всей Европе и в США, коллекционируя их истории успехов и провалов.

В ноябре 2015-го, на шестую годовщину релиза Go, я вспоминал то своё первое выступление. Какие из лучших практик прошли проверку временем? Какие из них устарели или стали неэффективными? Появились ли какие-то новые методики? В марте мне представилась возможность выступить на конференции QCon London, где я рассказал о лучших практиках 2014 года и дальнейшем развитии Go до 2016 года. В этом посте представлена выжимка из моего выступления.

Ключевые положения я выделил в тексте в виде Top Tips — лучших советов.

А вот и cодержание:

1. Среда разработки
2. Структура репозитория
3. Форматирование и стиль
4. Конфигурация
5. Разработка программы
6. Логирование и метрики
7. Тестирование
8. Управление зависимостями
9. Сборка и развёртывание
10. Заключение

Основная идея Pub-Sub довольно простая: "publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead characterize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are." В свободном переводе это может звучать так: "Издатель-подписчик (англ. publisher-subscriber или англ. pub/sub) — поведенческий шаблон проектирования передачи сообщений, в котором отправители сообщений, именуемые издателями (англ. publishers), напрямую не привязаны программным кодом отправки сообщений к подписчикам (англ. subscribers). Вместо этого сообщения делятся на классы и не содержат сведений о своих подписчиках, если таковые есть. Аналогичным образом подписчики имеют дело с одним или несколькими классами сообщений, абстрагируясь от конкретных издателей."