В эти выходные на меня навалилась ностальгия и захотелось вспомнить самое начало своей карьеры. Расскажу о взрывном росте сотовой связи в начале 2000х и о том, что случилось к 2013му. Спойлер — на улицу выставили половину персонала.

Повествование я буду вести из двух времен:

Давайте сразу вопрос на засыпку: может ли быть так, что клиент подключается, ну, например, к серверу www.python.org (самому настоящему, тому, к которому обращаются еще миллионы клиентов со всего мира), а потом использует его как прокси и гоняет через это подключение трафик до своего VPS для доступа в неподцензурный интернет? Если вы не уверены в ответе на этот вопрос или почему-то ответили "нет", то добро пожаловать в статью.

Я уже не раз рассказывал здесь о технологии XTLS-Reality (1, 2, 3) суть которой в том, что ваш прокси-сервер VPS может очень достоверно маскироваться под какой-нибудь популярный веб-сайт - принимать подключения, которые будут выглядит точно так же, как обращения к настоящему сайту, отвечать на них полностью аутентичным TLS-сертификатом, и в целом вести себя как тот настоящий сайт. Единственная проблема - сам IP-адрес. Немного подозрительно, когда к какому-нибудь якобы www.google.com постоянно обращается только один пользователь, а IP-адрес этого сервера на самом деле даже не относится к автономной сети Google.

Еще я рассказывал о разных вариантах проксировать трафик посредством вебсокетов и простых HTTP-туннелей через различные CDN, такие как Cloudflare и Gcore. Вероятность того, что под блокировку попадет вся CDN гораздо ниже, чем что забанят какой-то один сервер или диапазон хостера, но та схема требовала регистрацию своего домена для работы через CDN.

И наверняка многим в голову приходила идея, а нельзя ли как-нибудь совместить эти два механизма? Проксироваться через CDN, но при этом "прикрываясь" каким-нибудь чужим доменом? Ответ: да, можно, и сейчас мы посмотрим, как именно.

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

Во всём «виноват» terragrunt: каждому модулю terragrunt нужна отдельная джоба в пайплайне на plan и apply, но для каждого модуля они во многом повторяют друг друга. Подобное постоянное написание одинаковых частей CI/CD пайплайна при добавлении новых баз и бакетов навевало тоску.

Рассказываем, как мы создали генератор джоб в Gitlab CI/CD и навсегда забыли о ручном написании пайплайнов для развёртывания элементов инфраструктуры.

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

Нередко на Хабре в темах, посвященных блокировкам ресурсов встречаются забавные заявления, вида "Я настроил TLS-VPN, теперь будут смотреть что хочу и цензоры мой VPN не заблокируют", "Я использую SSH туннель, значит все ок, не забанят же они SSH целиком", и подобное. Что ж, давайте проанализируем опыт других стран и подумаем, как же оно может быть на самом деле.

В этом году на C++ Russia я рассказывал про API дизайн. Эта статья — пересказ и переосмысление моего доклада.

То, что я здесь расскажу, основано на моем личном опыте — про API дизайн я думаю уже лет 15, с того момента как в 2008м начал читать ревью библиотек на входе в boost (кстати, всем рекомендую).

В первой части я сфокусируюсь на базовых вещах, которые применимы практически к любому императивному языку программирования, не только к C++. Будет также часть 2, более приближенная собственно к C++, в которой я расскажу о некоторых фичах языка и стандартной библиотеки, которые помогут вам сделать ваши API еще лучше.

Когда TCP-сокеты отказываются умирать

В поисках причин, почему установленные соединения не разрываются в некоторых случаях, я набрёл на отличную статью в блоге Cloudflare. Которая в итоге помогла найти не только решение моей проблемы, но и помогла лучше понять как работают таймауты TCP соединений в Linux.

Еще совсем недавно многие экономисты предрекали Китаю и китайской экономике большое будущее. Некоторые известные экономисты, такие как Рей Далио, вообще выпускали целые книги, объясняющие, что цикл верховенства США в мире закончен, и теперь пришло время Китаю вырваться вперед.

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

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

FFmpeg — это грандиозный Open Source проект, своего рода мультимедийная энциклопедия. С помощью FFmpeg можно решить огромное число задач компьютерного мультимедиа. Но все-таки иногда возникает необходимость в расширении FFmpeg. Стандартный способ — это внесение изменений в код проекта с последующей компиляцией новой версии. В статье подробно рассмотрено, как добавить новый кодек. Также рассмотрены некоторые возможности для подключения к FFmpeg внешних функций. Если нет необходимости добавлять кодек, то статья может оказаться полезной для лучшего понимания архитектуры кодеков FFmpeg и их настройки. Предполагается, что читатель знаком с архитектурой FFmpeg, процессом компиляции FFmpeg, а также имеет опыт программирования с использованием FFmpeg API. Описание актуально для FFmpeg 4.2 «Ada», август 2019.

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

В стандартную библиотеку C++ входит несколько контейнеров. Кроме этого, в Open Source есть несколько контейнеров, которые покрывают больше юзкейсов. Я опишу устройство интересных контейнеров вне STL и их отличия от классических контейнеров.

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

Если спросить современного С++ разработчика какие примеры type erasure он видел / использовал, то вероятно он ответит что то про std::function и возможно про std::any, но это лишь малая часть всех применений этого замечательного инструмента!

В статье я постараюсь описать все возможные виды type erasure в современном С++, но начать стоит с определения.

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

Начнём с того, что было уже в С и о чём часто забывают говоря об erasure

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

Кстати, насчёт байтов:

std::byte (since C++17) / unsigned char / char так исторически сложилось, что в С все использовали чары для работы с сырыми байтами, поэтому для них в языке С++ исключение и указатель на них можно приводить к указателю на любой другой тип. Это не обходится без последствий и иногда из-за этого строки теряют некоторые оптимизации, поэтому сначала добавили std::byte, а потом начали потихоньку заменять чары (char8_t since C++20), но это уже совсем другая история. В контексте стирания типов нам важно, что мы получили способность читать данные из стёртого типа, а составив массив мы получим ещё и верхнюю границу размера типа, что конечно немного, но с void и так нельзя.

Для начала разберем небольшую задачу. Она поможет читателю получить представление об основах шифрования.

Представим, что у нас есть сундук с важными документами. Мы хотим отправить его из пункта А в пункт Б, но так, чтобы никто не мог открыть его содержимое по пути следования. На сундук можно повесить замок/замки, отправлять сундук несколько раз, принимать обратно, передавать ключ/ключи через посредника. Посредник может скопировать ключ или даже сам сундук, подобно файлам на компьютере. Как же выстроить цепочку передачи, чтобы посредник не получил доступ к закрытым документам при перевозке?

Привет, Хабр! Относительно недавно после пары лет перерыва в айти, потраченных на изучение японского языка, мне пришлось срочно обновлять свои знания на работе. Ну знаете, искать возможности исполнить все хотелки начальника, как и положено эникею. Меня ждало много увлекательных открытий, но при этом, как водится, и немало боли и борьбы с непонятками. Docker, контейнеры, реверс DNS и реверс прокси, получение TLS сертификатов. В какой-то момент я наконец дошёл до удобного решения, которым я теперь хочу поделиться.

В своё время домашний сервер очень облегчил бы мне понимание Docker’а, да и удобство работы с ним неслабо бы повысил. Поэтому возникла идея написать эту статью, после прочтения которой любой человек даже с поверхностными знаниями в информационных технологиях сможет поставить себе постоянно доступный домашний сервер на базе Docker Swarm с удобной веб-мордой, простым получением TLS-сертификатов и Heroku-подобным функционалом (для чего будем использовать PaaS CapRover). 

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

Пишем синхронный сервер

void naive_accept() {
  for (;;) {
    auto new_socket = accept(listener);

    std::thread thrd([socket = std::move(new_socket)] {
      auto data = socket.receive();
      process(data);
      socket.send(data);
    });

    thrd.detach();
  }
}

Привет!

Представляем вашему вниманию дорожную карту для изучения языка программирования C++. Идея дорожной карты возникла после проведения десятков собеседований молодых разработчиков, которые претендовали на роль Junior Developer C++, но обладали довольно слабой подготовкой по различным причинам.

Заинтересовавшихся приглашаем к прочтению статьи, а также ознакомиться с дорожной картой.

Товарищи инженеры, как и было обещано в анонсе, половина лекций (а это 51) уже доступны для просмотра на ютюбе и я продолжу их записывать в 2019 году. Часть из нужно будет перезаписать, потому, что в первых лекциях не самый лучший звук и потому, что очень простые темы у меня пока не очень хорошо получаются. Лучше вышли сложные и актуальные темы, которые мне и самому более интересно рассказывать. Я бы не сказал, что это курс для начинающих, скорее, это курс для тех, кто уже знает синтаксис. За это время поступило множество предложений, как улучшить способ подачи материала: делить на более короткие лекции, подготовить задачи для практического освоения, записывать семинары и ответы на вопросы студентов, добавить в программу разбор целого ряда спорных и холиварных тем. Но не все сразу, я и так посвящаю этому треть жизни.

Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaScript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.