• Цикл событий
  　Задачи, тики и Web API
  　Очередь задач
  　16,6 миллисекунды на задачу
  　Обработка больших задач
  　Микрозадачи
  　requestAnimationFrame
  　requestIdleCallback
  　Сравнение очередей
  　Цикл событий в Node.js
• Функции обратного вызова
  　Ад обратных вызовов
  　Не выпускайте Залго
  　Жёсткая сцепленность
  　Проблема доверия
• Обещания
  　Цепочки обещаний и проброс отказа
  　Неявное поведение
  　　Возвращение нового обещания
  　　Спрятанный try/catch
  　Thenable-объекты
  　Статические методы
  　　Promise.all
  　　Promise.race
  　　Promise.any
  　　Promise.allSettled
  　Промисификация
  　Обещания или функции обратного вызова?
  　Корутины
• Async/await
  　Верхнеуровневый await и асинхронные модули
  　Обработка ошибок
  　Не все await одинаково полезны
• Заключение

Вы когда-нибудь задумывались как устроен ID видео на YouTube?
Возможно, вы уже знаете/нашли ответ, но, как показали обсуждения на Stack Overflow, многие понимают эту технологию неправильно. Если вам интересно изучить что-то новое, добро пожаловать под кат.

Недавно мы проводили вебинар «Обзор паттернов интеграции микросервисов». На нём энтерпрайз архитектор Пётр Щербаков рассказал, зачем IT-специалистам нужны шаблоны интеграции, и разобрал, для каких задач они подходят, а для каких нет. Для тех, кто пропустил или предпочитает читать, а не смотреть подготовили текстовый обзор интеграционных паттернов: Circuit Breaker, Sidecar, Ambassador, Anti-Corruption Layer и Async Request-Reply.

Привет, Хабр!

В последние несколько лет все больше и больше людей ищут возможность войти в ИТ или поглубже изучить Linux, повысив уровень своей квалификации. Вместе с тем полноценных обзоров с практическом уклоном по типу «все и сразу» написано не так уж и много (особенно на русском языке).

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

Иногда сложно справиться с большим потоком задач и информации, особенно если это касается работы. Поэтому создание персональной базы знаний для своих текущих дел становится весьма актуальным. Но простая фиксация данных не всегда эффективна: легко потеряться в куче заметок. Различные методики помогают правильно организовать процесс. Вместе с тем информация не существует сама по себе, она, как правило, неразрывно связана со всеми нашими проектами, задачами и другими событиями. Если это учитывать, то проще оперировать данными, находить нужные факты. Через задачу легко выйти на связанную с ней информацию или, наоборот, через данные можно найти проект или задачу, в рамках которых они появились. Однако на практике все это будет эффективно работать, если получится создать единую среду для ведения дел и хранения всех связанных с ними данных.

Существующие приложения, как правило, не могут предоставить готовое решение для работы в таком контексте. Приходится придумывать или создавать что-то свое. Самое простое — это начать с каких-то стандартных заметочников, например Evernote или OneNote, и приспособить их под себя. Однако с появлением Roam-подобных программ пришло понимание, что можно создать очень гибкую систему, которую легко настроить под ведение любого вида задач, проектов и хранение различного типа связанной с ними информации. В этой статье познакомимся с примером настройки и практического использования маркдаун-заметочника Obsidian совместно с методологией Getting Things Done (GTD) Дэвида Аллена.

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

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

Привет! На связи Олег Казаков из Spectr.  Мы занимаемся разработкой цифровых сервисов, в том числе высоконагруженных систем с микросервисной архитектурой и большим количеством различных интеграций.

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

Terraform за 15 дней (AWS/Yandex). День 1

Мы от простого к сложному, поднимем небольшую инфраструктуру на aws и Яндекс (актуальность последнего я думаю объяснять не нужно). Так что по итогу вы сможете сказать: “Я изучал terraform от простого к сложному”.

Я постараюсь добавить все необходимые ссылки на документации и доп. источники, так что вы сможете дополнить необходимые знания, но данный курс (если это можно так назвать) скорее рассчитан на тех, кто в общем знаком с облачными технологиями. Это не пособие по terraform. Цель - помочь новичкам в данном вопросе начать изучать IaC и облака в целом. Некий quick start в terraform.

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

Kubernetes объявил Docker устаревшим и планирует прекратить его использование примерно через год, в версии 1.22 или 1.23. Эта новость вызвала много вопросов и непонимания. В блоге Kubernetes появилось целых две статьи, разъясняющих смысл записи в Changelog (раз и два). Если все обобщить, то для разработчиков (те, которые Dev) ничего не меняется — они все так же могут продолжать использовать docker build для сборки своих контейнеров, а вот для инженеров, ответственных за эксплуатацию кластера (Ops), пришла пора разобраться и освоить несколько новых инструментов.

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

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

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