Node.js это кроссплатформенная среда выполнения JavaScript с открытым исходным кодом для выполнения JavaScript вне браузера. Он поддерживается движком Google V8, что делает его чрезвычайно производительным.

Асинхронная среда выполнения, управляемая событиями

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

Технически, тот факт, что Node.js использует один поток не на 100% верно. Node.js на самом деле использует много потоков, но цикл событий (Event Loop - о котором мы упомянем позже), и пользовательский код выполняются в одном потоке. Если мы ознакомимся с документацией, то увидим, что Node.js использует управляемым событиями неблокирующую модель ввода-вывода (event-driven, non-blocking I/O model), которая делает его легким и эффективным.

Что такое управляемая событиями неблокирующая модель ввода-вывода?

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

Давайте сначала посмотрим синхронную версию:

В приведённом ниже коде происходит следующее: во-первых, нужно подключить модуль FS. Во второй строке вызывается метод readFileSync, и результат сохраняется в переменной data. Основной поток Node.js блокирует эту строку до тех пор, пока не будет прочитано все содержимое файла. Затем содержимое выводиться в консоль, и, в самом конце будет выведено в консоль “Done”.

С помощью микросервисной архитектуры можно построить масштабируемое и гибкое приложение. Однако, если команда бессистемно использует этот подход в своей работе, то скоро столкнется с разочарованием и неконтролируемой сложностью. Избежать этого поможет DDD (Domain-Driven Design, предметно ориентированное проектирование). Не так давно я ничего не знал про этот подход, но сейчас я постоянно натыкаюсь на эту тему.

Представляю вам перевод статьи "How to Implement Domain-Driven Design (DDD) in Golang". Повествование буду вести от лица автора, иногда прерывая собственными мыслями в таком же формате, как и это отступление. Приятного чтения.

HTTP является протоколом без статических данных, что означает, что он не может различать два последовательных запроса, исходящих от одного и того же компьютера, сети или пользователя. Это было основной проблемой. Из-за этого пользователь не мог поддерживать свою сессию, и если бы мы продолжили в том же духе, интернет стал бы таким же, каким он был десять лет назад, состоящим только из кучи статичных html-страниц. Никаких учетных записей пользователей, никакой настройки и т.д., а если и есть какие-то учетные записи, то для доступа к каждой странице нужно снова и снова входить в систему.

Чтобы решить эту проблему, HTTP нужно было сделать с сохранением состояния. Ответом стал файл cookie. В отличие от cookie, которые вы получаете, это небольшие файлы, создаваемые веб-сайтом, который вы посещаете. Они генерируются веб-приложениями и хранятся в вашем браузере в виде пар ключ-значение.

Примером может служить PHPSESSID: xyjaez1081lze23, lang: en.

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

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

Даже самый простой SQL запрос можно выполнить по-разному. Но из всех вариантов СУБД нужно выбрать оптимальный, как же это сделать? Неужели придётся перебрать все возможные варианты? Давайте разбираться.

Что такое OPA?

Это проект, стартовавший в 2016 году, направленный на унификацию применения политик в различных технологиях и системах. Сегодня OPA используется гигантскими игроками в технологической индустрии. Например, Netflix использует OPA для управления доступом к своим внутренним ресурсам API. Chef использует его для предоставления возможностей IAM в своих продуктах для конечных пользователей. Кроме того, многие другие компании, такие как Cloudflare, Pinterest и другие, используют OPA для обеспечения соблюдения политик на своих платформах (например, кластеры Kubernetes). В настоящее время OPA является частью CNCF в качестве инкубационного проекта.

Когда речь заходит про права доступа в приложении, то из этой ситуации появляется два результата:

Либо в коде приложения появляются привязки к неким ролям/scope’ам;

Либо разработчик обрастает бородой и начинает сыпать фразами вроде abaс, xacml и матрица доступа; 

Если вам интересно как можно из подручных средств собрать RBAC на любой сервис соблюдающий REST, то добро пожаловать.

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

Каждый разработчик "кровавого" enterprise в своей работе использует СУБД (SQL/NoSQL) и меня всегда искренне интересовало как они устроены в самом сердце, на самом низком уровне. Почитав документацию и исходный код SQLite и MongoDB, про используемые в индексах и интерпретаторах запросов алгоритмы, осознал, что несмотря на широкую распространенность и некую привычность, системы управления базами данных (СУБД) - это сложные программные продукты, реализация которых не всем под силу. Отлично - как раз то, что мне надо. С мотивацией разобрались, перейдем к делу.

Итак, для начала хорошо бы сформулировать высокоуровневую спецификацию требований. Boson - это легкая, встраиваемая документоориентированная база данных на С/С++

Вам приходилось ходить на встречи, на которых 10 или более человек никак не могли договориться? Такое может быть и с архитектурными, и дизайн-решениями, и  процессами. Нам в Dodo приходилось. Это может быть мучительно больно и выматывающе, поэтому хочу поднять тему решительности или «куража», как это называется в экстремальном программировании.

Почему я? Когда-то давно, когда я ещё не была техлидом, я заметила, что у нас есть проблема с глобальными процессами. От этого страдали все, и я в том числе. В конце концов страдать мне надоело, поэтому я решилась изменить что-то хотя бы в собственной команде. И мне это удалось. Хочу поделиться опытом и рассказать о одном принципе, который помог мне тогда и помогает по сей день.

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

Вам знакома ситуация, когда вы погреблены под валом задач? Едва закрываете одну — на её место сваливается еще две. И, главное, все задачи действительно важные и срочные. Гора дел растет, вы впадаете в отчаяние и тихо выгораете. Никто, разумеется, этого не замечает и не ценит. Вот необходимый и достаточной набор практик, которые спасают в таких ситуациях.

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Всем привет! В этой статье хочу поделиться опытом построения системы доменных событий (domain events) в нашем модульном монолите и микросервисах, рассказать о том, как мы гарантируем их доставку, следим за консистентностью в рамках транзакций, используя transactional outbox, чем доменные события отличаются от интеграционных и всё это в рамках multi tenant приложения. Подробнее под катом.

Навеяно мыслями после прочтение замечательной статьи "Гори это ИТ синим пламенем".

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

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

Поднялся вопрос стандартизации коммитов в команде. До этого были такие правила, мы пишем номер задачи и через тире описание того, что было сделано кратко. Номер задачи берется из номера issue. Например: #1 - реализован функционал сборки прода. Но, это надоело и стало как-то неудобно, когда у нас есть четкое деление задач на фиксы, фичи и так далее.

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

В нашей команде принято по максимуму IDE и его возможности. То есть, коммиты мы делаем не через консоль, а через встроенные утилиты. Поэтому, сразу пошли искать плагины, которые есть в PHPStorm и нашли вот эти 2 важных плагина: Conventional Commit и Git Commit Template. После их установки видим новые кнопки в окне коммита:

В прошлой статье "Пример использования диапазонного типа данных" я на реальном примере рассмотрел, чем может быть полезен специальный тип для хранения диапазонов которые существует в PostgreSQL. В комментариях поступило предложение пойти дальше и воспользоваться типом box. Т.е. сохранить диапазон в виде объекта геометрии. Немного непривычно. Но сказано - сделано! Плюсы и минусы хранения КВС ОСАГО в виде box рассмотрю в заметке. Публикация является дополнением к указанной статье. Так же я подготовил все 4 вариант схем внутри демки с docker, поэтому примеры можно позапускать у себя. Кому ближе видео версия, то в конце заметки есть ссылка на полное видео данных публикаций на Youtube.

❓Что делать если команда не хочет проводить Ретро?

Это один из самых частых вопросов Скрам-Мастеров.

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

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

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

Меня зовут Анна Шестакова, я HRD в IT-компании ITECH. В этой сфере уже более 11 лет. Работала начинающим и ведущим специалистом, тимлидом, руководителем подразделений. Я проходила адаптацию сама или адаптировала других, прошла все «круги онбординга» с обеих сторон — начиная с экскурсии по офису, и заканчивая задачами автоматизации. Поэтому хорошо представляю, с какими проблемами могут столкнуться участники на разных этапах. Расскажу про самые распространённые из них, и о том, как их решить.

OpenAPI стал одним из стандартов для описания API с большим числом сопутствующих инструментов и сервисов. По сути, OpenAPI — это спецификация на составление спецификаций, поэтому она описывает множество вариантов взаимодействия. Но как лучше всего проектировать API, используя OpenAPI? У команды Sape есть многолетний опыт в этой сфере, о котором я сейчас расскажу.

В алгоритмических задачах на графах мы часто используем четыре известных алгоритма: Поиск в ширину или глубину, алгоритмы Дейкстры и А*. Разбираемся, почему на деле это один и тот же алгоритм.