Дорогие товарищи инженеры, сообщество Метархия представляет вашему вниманию современный курс по Node.js, который включает глубокий разбор всех возможностей и аспектов платформы. Основной упор делается на то, как создавать надежные высоконагруженные сервера приложений и API без привязки к конкретному фреймворку и даже протоколу, т.е. абстрагировать бизнес-логику в отдельный слой. К лекциям прикреплено множество примеров кода, демонстрирующих гибкую структуру приложений и архитектурные приемы, в том числе работу с СУБД через слой доступа к данным, создание интерактивных приложений на вебсокетах, обеспечение безопасности, Graceful shutdown, межпроцессовое взаимодействие, предотвращение утечек памяти, масштабирование и кластеризацию при помощи процессов и потоков. На текущий момент в курсе 38 лекций (около 35 и ½ часов видео), 37 репозиториев с примерами кода, 4 PDF со слайдами. Перед основной частью курса по Node.js нужно сначала освоить хоть частично курс по асинхронному программированию.

Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.


Схема взята из другого обзора стратегий выката, сделанного в Container Solutions

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

Более короткие и частые развертывания имеют следующие преимущества:

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

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

Отказоустойчивость и высокая доступность — большие темы, так что посвятим RabbitMQ и Kafka отдельные статьи. Данная статья о RabbitMQ, а следующая — о Kafka, в сравнении с RabbitMQ. Статья длинная, так что устраивайтесь поудобнее.

Рассмотрим стратегии отказоустойчивости, согласованности и высокой доступности (HA), а также компромиссы, на которые приходится идти в каждой стратегии. RabbitMQ может работать на кластере узлов — и тогда классифицируется как распределенная система. Когда речь заходит о распределенных системах, мы часто говорим о согласованности и доступности.

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

В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.

Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.

TL;DR. Некоторые люди смотрят на мир иначе. Софтверная компания из Нью-Йорка решила использовать это как конкурентное преимущество. Её штат на 75% состоит из тестировщиков с расстройствами аутистического спектра. Удивительно, но необходимые аутистам вещи оказались полезными для всех: гибкий график, удалённая работа, общение в Slack (вместо личных встреч), чёткая повестка каждого совещания, отказ от открытых офисов, отмена собеседований, карьерная альтернатива повышению до менеджера и т. д.

Раджеш Анандан основал компанию Ultranauts (бывшая Ultra Testing) с соседом по комнате общежития в Массачусетском технологическом институте Артом Шектманом с одной целью: доказать, что нейрологическое разнообразие (neurodiversity) и аутизм сотрудников — это конкурентное преимущество в бизнесе.

«В аутистическом спектре невероятное количество людей, чьи таланты игнорируют по самым разным причинам,  — говорит Анандан.  — Им не дают честного шанса добиться успеха на работе из-за атмосферы, рабочего процесса и ”привычных” деловых практик, которые не слишком эффективны в принципе, а для людей с таким мышлением особенно вредны».

Всем привет! Несколько месяцев назад мы запустили в продакшн наш новый open-source проект — Grafana-плагин для мониторинга kubernetes, который назвали DevOpsProdigy KubeGraf. Исходный код плагина доступен в публичном репозитории на GitHub. А в этой статье мы хотим поделиться с вами историей о том, как мы создавали плагин, какие инструменты использовали и с какими подводными камнями столкнулись в процессе разработки. Погнали!

Всем привет! Скоро стартуют занятия в первой группе курса «Разработчик игр на Unity». В преддверии начала курса прошел открытый урок по созданию зомби-шутера на Unity. Вебинар провёл Николай Запольнов, Senior Game Developer из Rovio Entertainment Corporation. Он также написал подробную статью, которую мы и предлагаем вашему вниманию.



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

---

Дисклеймер №1: данная статья рассчитана на новичков. Если вы собаку съели в Unity, то она может показаться вам скучной.

Дисклеймер №2: для прочтения этой статьи вам потребуется хотя-бы базовое знание программирования. Как минимум, слова «класс» и «метод» не должны вас пугать.

Осторожно, под катом трафик!

Прим. перев.: В этом замечательном материале компании Okta просто и наглядно рассказывается о принципах работы OAuth и OIDC (OpenID Connect). Эти знания будут полезны разработчикам, системным администраторам и даже «обычным пользователям» популярных веб-приложений, которые скорее всего тоже обмениваются конфиденциальными данными с другими сервисами.

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


«Предоставьте свою банковскую учётку». — «Обещаем, что с паролем и деньгами все будет в порядке. Вот прям честно-пречестно!» *хи-хи*

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

Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню? Ну и ладно!).

С чего всё началось

Начнём с постановки проблемы. Дано: один ноутбук. Новый ноутбук, геймерский. С RGB-подсветкой. Вот такой примерно ноутбук:


Картинка взята с lenovo.com

Есть ещё программа к этому ноутбуку. Программа как раз этой подсветкой и управляет.

Одна только проблема – программа под Windows, а хочется чтоб в любимом линуксе всё работало. И лампочки чтоб светились, и чтоб цвета красивые мелькали. Да вот только как это сделать, чтоб без реверс-инжиниринга и без написания своих драйверов? Простой ответ пришёл быстро – никак. Ну что ж, пошли писать драйвер.

Захотев перейти на Linux дома или на работе, люди обычно ставят Ubuntu, Mint, Fedora, порой даже Debian. И очень зря не пробуют Manjaro Linux — на мой взгляд, этот дистрибутив удобнее Убунты (которая уже де-факто — Default Linux), и даже удобнее Минта.

Manjaro — производная от Arch Linux (так же как Ubuntu — производная от Debian), пилится европейской командой Manjaro Team. У Манжары почти такая же структура системы, как у Арча, но с некоторыми особенностями, которые делают его на 146% юзерфрендли.

Краткая суть ситуации: наш соотечественник fafhrd91 на протяжении 3 лет практически самостоятельно (см. кдпв) писал actix-web — один из популярнейших крейтов в инфраструктуре раста, лидер в большинстве различных бенчмарков, и за это время подвергался как минимум трём волнам гонений за "неправильное использование раста". После последнего раза автор психанул, и перенес репозиторий к себе в аккаунт с пометкой "Планирую скрыть репозиторий". Конечно, куча людей сразу наделало зеркал и бекапов, но на мой взгляд это не сильно исправляет ситуацию.

На месте репозитория автор оставил единственный postmortem, который я ниже и цитирую целиком:

Я стар и уже глуп, а у вас всё впереди, уважаемый программист. Но позвольте дать вам один совет, который наверняка поможет в вашей карьере – если, конечно, вы планируете остаться программистом.

Советы типа «писать красивый код», «хорошо комментировать свои доработки», «изучать современные фреймворки» — очень полезные, но, увы, второстепенные. Они идут прицепом к главному качеству программиста, которое надо в себе развивать.

Вот это главное качество: пытливый ум.

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

Как известно, учиться на чужом опыте дешевле, а посему — пусть эти истории помогут быть готовыми к возможным неожиданностям. Кстати, большая и регулярно обновляемая подборка ссылок на такие «failure stories» публикуется на этом сайте (по данным из этого Git-репозитория).

_{Яна Харлан с макетом двигателя (1:1)}

В 2017 году российские ученые из команды Avant Space занялись разработкой уникального геликонного сеточного двигателя для космических спутников. С ним бы они могли поддерживать орбиту и выполнять межорбитальные переходы.

«Это простое на первый взгляд устройство повелевает воистину сложными плазменными процессами и позволяет разгонять рабочее тело двигателя до скоростей в десятки километров в секунду. Базовая схема не нова — мы лишь постарались сделать максимально эффективным сам плазменный разряд с помощью возбуждения геликонных волн», — говорит со-основательница и гендиректор проекта Avant Space Яна Харлан.

Этот пост – продолжение истории о начинке торговых автоматов простой и доступной электроникой на базе Arduino. И действительно – возможности платформы просто безграничны! И так, второй автомат – снековый автомат по продаже чипсов/воды/шоколадок/etc.

Прим. перев.: service mesh — явление, которое ещё не имеет устойчивого перевода на русский язык (более 2 лет назад мы предлагали вариант «сетка для сервисов» или «сервисная сетка», а чуть позже некоторые коллеги стали продвигать сочетание «сервисное сито»). Постоянные разговоры об этой технологии привели к ситуации, в которой слишком тесно переплелись маркетинговая и техническая составляющие. Этот замечательный материал от одного из авторов оригинального термина призван внести ясность для инженеров и не только.


Комикс от Sebastian Caceres

Введение

Если вы инженер-программист, работающий где-то в районе бэкенд-систем, термин «service mesh», вероятно, уже прочно закрепился в вашем сознании за последние пару лет. Благодаря странному стечению обстоятельств, это словосочетание захватывает отрасль все сильнее, а хайп и связанные с ним рекламные предложения нарастают словно снежный ком, летящий вниз по склону и не подающий никаких признаков замедления.

Service mesh зародилась в мутных, тенденциозных водах экосистемы cloud native. К сожалению, это означает, что значительная часть связанной с ней полемики варьируется от «низкокалорийной болтовни» до — если воспользоваться техническим термином — откровенной чуши. Но если отсеять весь шум, можно обнаружить, что у service mesh есть вполне реальная, определенная и важная функция.

В этой публикации я попытаюсь проделать именно это: представить честное, глубокое, ориентированное на инженеров руководство по сервисным сеткам. Я собираюсь ответить не только на вопрос: «Что это такое?», — но и «Зачем?», а также «Почему именно сейчас?». Наконец, попытаюсь обрисовать, почему (по моему мнению) конкретно эта технология вызвала такой сумасшедший ажиотаж, что само по себе интересная история.

Прим. перев.: Эта практическая заметка от создателя LayerCI — отличная иллюстрация так называемых tips & tricks для Kubernetes (и не только). Предлагаемое здесь решение — лишь одно из немногих и, пожалуй, не самое очевидное (для некоторых случаев может подойти уже упомянутый в комментариях «родной» для K8s kubectl port-forward). Однако оно позволяет как минимум посмотреть на проблему с позиции применения классических утилит и их дальнейшего комбинирования — одновременно простого, гибкого и мощного (см. «другие идеи» в конце для вдохновения).



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

Прим. перев.: Эта статья, ставшая хитом на Medium, — обзор ключевых (за 2010-2019 годы) изменений в мире языков программирования и связанной с ними экосистемы технологий (особое внимание уделяется Docker и Kubernetes). Её оригинальным автором является Cindy Sridharan, которая специализируется на инструментах для разработчиков и распределённых системах — в частности, она написала книгу «Distributed Systems Observability» — и достаточно популярна в интернет-пространстве среди IT-специалистов, особенно интересующихся темой cloud native.



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

Хочу сразу оговориться, что в этой статье я не охватываю изменения в таких областях, как наука о данных (data science), искусственный интеллект, frontend engineering и т.п., поскольку лично у меня отсутствует достаточный опыт в них.

Некоторое время назад на Хабре вышла статья замечательной девушки fur_habr о проблемах безопасности, приватности и конфиденциальности мобильных коммуникаций и о путях решения этих проблем на платформе Android.

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

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