Простые текстовые форматы данных — прекрасная штука. Нет, без шуток. Возьмём, например, банальные txt-файлы. Ну красота же! В любом утюге есть текстовый редактор, можно открыть файл, почитать, записать. Любой уважающий себя язык программирования из коробки даст вам средства работы с текстовыми файлами. Или вот ранние сетевые протоколы — SMTP, POP3, HTTP 1.0. Это вообще такое блаженство, что слёзы на глаза наворачиваются. Можно взять telnet, приконнектиться к серверу, отдавать команды и читать ответы! Писать клиенты, серверы, снифферы, прокси — одно удовольствие.

Но время не стоит на месте и удобство работы программиста, к сожалению (или к счастью!), давно перестало быть главным критерием выбора технологий. В прекрасные текстовые файлы понадобилось вдруг добавлять графики, картинки и ссылки — и вот у нас есть форматы pdf и doc. С сетевыми протоколами вообще беда — людям зачем-то понадобились сжатие трафика, шифрование, мультиплексирование и другие страшные вещи. И вот уже у нас есть HTTP/2, с которым телнетом не очень-то поработаешь. Даже всем красивый REST разные негодяи типа Google нет-нет, да и пытаются заменить на какой-нибудь gRPC. И это я ещё не начал рассуждать о том, что мало что нынче сохраняется текстовые файлы — все почему-то используют какие-то базы данных, совершенно нечитабельные при открытии их текстовым редактором, но какой-то магией позволяющие информацию структурировать, индексировать, эффективно искать и т.д.

И вот здесь мы подходим к теме того, что я хотел бы обсудить. Как видите, все форматы хранения данных, протоколы и прочие штуки прошли длинный путь в поисках своего оптимального вида. Однако мы, программисты, продолжаем писать код наших программ в текстовых файлах, как делали это наши дедушки лет 50 назад (или уже больше?). Какую бы ОС мы ни использовали, какой бы модный язык ни выбрали, как бы ни была крутой наша IDE — результатом написания кода будут буквы в текстовом файле. Что, согласитесь, в теории совершенно не обязательно, ибо наши буквы компьютеру нужны как зайцу стоп-сигнал. Ему нужны машинные команды для выполнения, это просто нам удобнее описывать их какими-то там буквами. А на самом деле ведь «цикл» или «функция» будут тем, чем они являются, как ты их не назови и где ты их не храни. «Роза пахнет розой, хоть розой назови её, хоть нет».

Да, мы привыкли писать код в текстовые файлы. Вы открываете файл — ну и вроде бы видите код своей программы. Какую-то его часть, вернее. Как-то видите. Понимаете. Ну или думаете, что понимаете. Но вот пост на Facebook вы тоже открываете, видите и понимаете — а ведь Facebook точно этот пост не в текстовом файле хранил.

Давайте же посмотрим, какие проблемы нам создаёт хранение кода в виде набора текстовых строк.

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

1. Вдумчивое чтение — чтение фундаментальных книг, структурированных и информативных. Это требует длительной концентрации, причём нельзя читать в состоянии усталости, поскольку вы попросту уснёте и ничего не запомните. Если у вас ещё нет электронной читалки — обязательно купите.
2. Лёгкое чтение — чтение менее серьёзной литературы вроде книг о мотивации, продуктивности, Soft Skills. Всё это зря недооценивается некоторыми программистами. Эти книги не требуют большой концентрации внимания. Да, это совершенно не о языке С++, но это о том, как вообще что-то делать и всё-таки сделать. Хорошо читается перед сном.
3. Подкасты — хорошо идут, когда нужно переключиться с чего-то одного на другое, или во время шоппинга. Помогают взглянуть на что-то неожиданное. Тренируют умение слушать и понимать услышанное, что может быть полезным умением (например, для участия в совещаниях). Если английский язык для вас не родной — вы можете услышать как произносятся термины и имена. Я рекомендую послушать CppCast или Software Engineering Radio — я был приятно удивлён широким охватом их тем. Первый эпизод вышел в 2006-ом году, подкаст наполовину состоит из истории программной инженерии и наполовину из теории (паттерны, проблемы, решения и т.д.)
4. Видео и лекции — CppCon, CppNow, Meeting C++, ACCU Conference для начала. Там просто ошеломляющее количество интересных докладов. В отличии от подкастов это требует визуального внимания и концентрации, но и выучить в результате можно больше. Я думаю просмотр 2-5 видео в неделю вполне достижимо.
   Совет: увеличивайте скорость аудио/видео — мозг быстро привыкает к этой скорости и вы сможете услышать больше за меньшее время.
5. Обсуждения, форумы, твиттер — этот канал обмена информацией требует меньше всего концентрации. Вы можете быстренько просмотреть дискуссии, ленту твиттера в поисках чего-то интересного — просто убивая время. Если что-то нашлось — можно добавить это в список для чтения позже. Чем это всё полезно — огромным разнообразием людей, мнений, подходов, задач и решений. Хороший способ разогнать свой мозг весьма случайной информацией.
   
   Вот, например, мой список Core C++ чтобы следить за значимыми в мире С++ разработчиками. А ещё есть несколько страниц и групп в Facebook и неплохие обзоры от Jens Weller.
   
   Для дискуссий о С++ есть раздел на Реддите (прим. переводчика: а ещё есть хаб на Хабрахабре). Ну и, конечно, группы комитета по стандартизации C++
6. Блоги и статьи — обычно занимает 5-10 минут чтобы прочитать среднюю статью. Если встречается более глубокая статья — можно пометить её для чтения «когда я буду сконцентрирован». По моим наблюдениям выходит 5-10 хороших статей в неделю и не так сложно прочесть их все.

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



Клиент шлёт минимально необходимое количество данных, чтобы описать свой запрос, а сервер отдаёт ему минимально необходимое количество данных для отображения страницы и всё это происходит за минимально возможное количество раундов связи. Лишние данные, пересылаемые на сервер или получаемые с сервера, означают увеличение времени загрузки и повышение шансов потери пакетов, перегруженность канала связи. Лишние циклы отправки\приёма данных из-за «болтливости» протокола и задержки (особенно в мобильных сетях, где 100ms — лучшее возможное время отклика) тоже ухудшают ситуацию.

Итак, если мы описали идеальный случай — соответствует ли ему протокол HTTP? И можем ли мы ещё как-нибудь улучшить его?

Современный мир ПО очень черно-бело разделён на два лагеря: либо ты opensource-приложение, либо закрытое проприетарное. Нет, есть, конечно, и разные лицензии в открытых проектах и какие-то подвижки закрытых продуктов выкладывать в опенсорс свои части (привет, Google, Facebook, Microsoft). Но всё это не меняет сути дела в принципе — если ты берёшь открытый продукт, то видишь всё, что у него внутри, можешь это оценить и решить, стоит связываться или нет. Если ты хочешь приобрести закрытое ПО, то всё, что остаётся — верить заливающимся соловьями продажникам фирмы-производителя, как у них там всё внутри классно, надёжно, быстро и современно. Ну, вы наверняка были на какой-нибудь такой конференции или презентации, где выходил человек в костюме и час втирал о том, как же всё стало лучше в версии 18.1.1 их продукта и почему его нужно покупать прямо сейчас. Ещё часто можно недельку погонять ограниченный trial-режим, что даст ответ ровно на 1 вопрос: «как работает ограниченный trial-режим в течение недели?». Покупатель всегда остаётся один-на-один с решением «взять и рискнуть» или «не связываться». Объективных данных для принятия решения мало. При этом их, казалось бы, больше и не станет — производитель закрытого продукта не выложит исходники, поскольку именно они составляют коммерческую ценность.

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

Прим. переводчика: в синтаксисе C++ напрочь отсутствуют несколько ограниченны средства построения предметно-ориентированных языков. В итоге их мало кто на С++ пытается использовать, а попытки всё же это сделать вызывают интерес, тем более, когда в итоге получается нечто стройно выглядящее и практически полезное. Одним из таких открытий для меня стал фреймворк Silicon, пытающаяся средствами современного С++ дать возможность быстро и гибко реализовать WebAPI в своём проекте. Давайте посмотрим, насколько просто это выглядит.

Hello World на Silicon — программа, которая на HTTP-запрос к

http://host/hello/world

ответит кодом 200 с текстом «hello world»:

auto my_api = http_api(GET / _hello / _world  = [] () { return "hello world";});
mhd_json_serve(my_api, 80);

Неплохо, правда? my_api здесь это описание нашего API, а mhd_json_serve — это бекэнд фреймворка Silicon, реализующий данный API с использованием встроенного вебсервера (на выбор microhttpd или LWAN).

Давайте посмотрим, что ещё умеет Silicon.

5-го марта 2016-го года в городе Джэксонвилл закончился очередной съезд комитета ISO C++. Люди собирались предварительно-окончательно решать, что же войдёт, а что не войдёт в стандарт С++17. Конечно, ещё не 2017-ый год и кое-что ещё, возможно, переиграется. Тем не менее, есть мнение, что именно данное мероприятие очертило С++17 в его будущем виде.

Я не буду тут тянуть кота за хвост и искать толерантные выражения: нас ждёт катастрофа. Стандарты С++11/14 были очень значительным скачком вперёд, но на этом всё закончилось. С++17, обещанный когда-то «мажорным» релизом, по факту не несёт в себе ничего существенного. Немного синтаксического сахара, пару мелочей в стандартную библиотеку — и на этом всё. Отголоски данной трагедии уже звучали некоторым эхо на Хабре, но я всё-таки решил обобщить информацию и понять, куда мы катимся.

Как-то так получилось, что я написал на Хабре уже несколько статей о библиотеках для хуков. Первая была об общих принципах и реализации на базе Detours, вторая — о более дешевой (но не менее функциональной) библиотеке madCodeHook. Сегодня я расскажу об ещё одном варианте — библиотеке Deviare от компании Nektra. «Ещё одна точно такая же библиотека для хуков?» — спросите вы. «Такая же, да не такая» — отвечу я. У Deviare есть несколько особенностей, отличающих её и от Detours и от madCodeHook и делающей её в некоторых случаях намного более полезной.

Под конец прошлого года компания Amazon выпустила (наконец-то!) C++ SDK для своей платформы AWS. Непонятно, почему так долго тянули — есть масса приложений, написанных на С++, из которых давно хотелось удобно пользоваться AWS. Не джавой же единой, в самом деле.

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

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

Большую часть моей жизни я проработал разработчиком программного обеспечения. Но однажды, уже под конец моего четвёртого десятка, я попался на удочку предпринимательской наживы. Я тогда поверил, что создавать собственные компании — это круто. Я нашел немного венчурного капитала и организовал пару небольших стартапов для реализации собственных идей. И вот я стал, как мне казалось, нормальным CEO и не таким уж плохим менеджером. И, хотя я уже не писал код лично, я мог нанимать хороших программистов, управлять качеством проектов и внедрением инноваций.

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Возможно, я скажу банальную вещь, но прошедший год был хорошим годом для С++!

Просто факты:

• Вышла Visual Studio 2015 с отличной поддержкой возможностей С++14/17 и даже нескольких экспериментальных вещей
• Вышел долгожданный GCC 5.0
• С++ набрал серьёзную популярность. Где-то с июля — третье место в Tiobe Ranking
• На конференции CppCon 2015 было сделано несколько важных анонсов

А теперь об этом и другом немного подробнее

Есть у нас одно .NET-приложение, которое умеет загружать и использовать плагины. Плагины — дело хорошее. Можно функционал расширять, можно оперативненько обновлять их со своего сайта, можно даже юзерам дать SDK и позволить писать свои плагины. Мы всё это и делали. Наши плагины представляли собой обычные .NET-сборки, которые нужно было подкинуть в определённую папку, откуда основное приложения их загружало и использовало. Ну, вы, наверное представляете как — Assembly.Load(), дальше ищем класс, реализующий необходимый интерфейс, создаём объект этого класса и т.д. Всё это работало давно, стабильно и ничто не предвещало беды. Но вдруг в какой-то момент появилась необходимость создать плагин, состоящий из нескольких файлов. В связи с этим было решено считать плагином не просто .NET-сборку (1 файл), а zip-архив, в котором может быть как одна сборка, так и несколько файлов. В связи с этим пришлось научить билд-сервер паковать плагины в архивы, а основное приложение — разархивировать их в нужное место. В общем-то задача на 10 строк кода. Ничто не предвещало беды. И вот скачиваю я с билд-сервера собранный архив с плагином, разархивирую его в нужную папку, запускаю приложение, и… не работает! Стоп, как не работает? Это ведь тот же плагин!

Дальше — больше. Прошу проделать ту же самую процедуру моего коллегу, на его компьютере. Он пробует — и у него всё работает! Но как же так? Одна версия приложения, один и тот же файл с билд-сервера. Какая-то разница в окружении? Сажусь за компьютер коллеги, пробую ещё раз — не работает! Он в этом время пробует на моём — работает! То есть получается, что файл «помнит», кто его разархивировал! Зовём третьего коллегу понаблюдать этот цирк. Последовательно, на одном и том же компьютере, по очереди делаем одни и те же действия: скачиваем архив с плагином, разархивируем в нужную папку, запускаем приложение. Когда это делаю я — программа не видит плагин, когда это делает коллега — всё работает. На третьем круге этих интересных экспериментов вдруг замечаем разницу в действиях: я разархивировал плагин стандартными средствами Windows, а мой коллега — с помощью 7-Zip. И то и другое вызывалось нами из контекстного меню архива, так что разницу в клик по не тому пункту вначале никто не замечал. Ну ок. Получается, файл, извлечённый из zip-архива с помощью 7-zip, отличается от того же файла из того же архива, извлечённого с помощью стандартного архиватора Windows?

Кстати, пока вы не открыли статью под катом, ответьте-ка сами для себя на вопрос, может ли такое быть, что содержимое файлов валидного zip-архива при разархивации 7-zip и через проводник Windows будет разным?

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

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

Новый проект на стороне инструментарий WebAssembly, о котором я хочу сегодня рассказать, называется Binaryen. Binaryen это библиотека для поддержки WebAssembly в компиляторах, написанная на С++. Если вы лично не работаете над компилятором WebAssembly, то вам, вероятно, не нужно напрямую знать что-либо о Binaryen. Если вы используете какой-нибудь компилятор WebAssembly, то он, возможно, под капотом использует Binaryen — мы рассмотрим примеры ниже.

Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.

Похрустев немного жестким диском, красивый инсталятор показал мне совершенно некрасивое сообщение об ошибке. Вот такое:


Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

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

Ну что же, пора включать голову, брать в руки инструменты и разбираться. Поехали.

Несколько последних месяцев я программирую преимущественно на Scala (по работе) и на Haskell (для души). На этой неделе я, правда, ещё немного пописал на Ruby (по работе) и Clojure (для души).

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

Но вот что касается моего новенького, с иголочки, проекта-любимца на Clojure… О, Clojure! Глоток свежего воздуха! Благодатная земля хорошо скомпонованных функций, иммутабельных структур данных и всего такого. Как прекрасен твой синтаксис и как мудра твоя чувствительность! Вся твоя суть в функциях, принимающих мэпы и возвращающих мэпы. И твой SQL-генератор, и слой доступа к БД, и HTML-парсер, и URL-роутер являют собой одну и ту же завораживающую картину мэпов, гоняемых туда-сюда тактами процессора, прекрасную с своём ритме хорошо собранных швейцарских часов.

Вернуться к Clojure после долгого времени это всё равно, что почувствовать себя дома. Это просто окрыляет программиста. Но почему-то в этот раз я ощутил и ещё одно, неожиданное для себя чувство: неопределённость.

Здравствуйте, меня зовут Владимир и я анонимный разработчик десктопных приложений под Windows. В этом месте все должны сказать «Здравствуй, Владимир!», а кто-то может быть добавит «Молодец, что осознал!». А потом все похлопают. Нет, правда, иногда от чтения Хабра у меня возникают именно такое ощущение, что нормально, нет, даже не «нормально», а допустимо и одобряемо сегодня писать только микросервисы для каких-то стартапов, которые будут по какому-то REST API отдавать данные какому-нибудь фронтенду на Ангуляре, который и будет, наконец, показывать пользователю что-то невероятно полезное, вроде таблицы с аггрегированными отзывами о стрижках пуделей с возможностью посмотреть на гуглокартах где бы в вашем городе можно было сделать именно такую стрижку вашему пуделю (несуществующему). А никаких других программ писать уже нет-нет, никак нельзя! Что за чушь?!

Да, многое сегодня происходит в вебе и на мобильных устройствах, но, знаете ли, далеко не всё. Значительная часть приложений по-прежнему является десктопным софтом. И даже (о, ужас!) не под Mac Os или Linux, а под тот самый богомерзкий Windows. И, знаете ли, софт этот живёт, развивается, поддерживается и является ежедневным рабочим инструментом миллионов людей. И никуда он мигрировать не собирается, потому что есть причины, по которым иногда именно десктопное приложение является лучшим вариантом.

Microsoft добавит поддержку компилятора Clang в ноябрськом обновлении Visual Studio 2015 — об этом было заявлено на конференции CPPCon 2015, проходящей сейчас в городе Белвью, США.

Clang это компилятор кода на С, С++ и Objective-C, который в связке с LLVM позволяет собирать программы под различные платформы. Visual Studio 2015 уже поддерживает Clang для разработки Android и iOS-приложений. При разработке под Android можно выбирать между GCC и Clang, а для iOS приходится использовать внешний Mac в качестве билд-сервера.

Планируемое обновление принесёт поддержку Clang на качественно новом уровне — теперь им можно будет собирать обычные Windows-приложения.

На конференции CppCon, которая проходит прямо сейчас, команда разработчиков компилятора Visual C++ заявила, что в следующем обновлении (Visual Studio 2015 Update 1) в компилятор С++ от Microsoft будет добавлена экспериментальная возможность из нового (ещё не утверждённого) стандарта С++ — поддержка модулей!



Для тех, кто не в курсе в чём эпохальность данного события: так уж сложилось, что механизм использовани компонентов в программах на С++ придумывался где-то лет 35 назад. Его нельзя назвать удобным: если вы хотите создать библиотеку — вам нужно сделать заголовочный файл и распространять с ним либо код, либо скомпилированную версию библиотеки. При этом возникает куча проблем:

• Заголовочный файл и библиотека — отдельные файлы, один из них может потеряться, либо они случайно могут рассинхронизироваться.
• Заголовочный файл включается в код директивой препроцессора #include, что во-первых, замедляет компиляцию, а во-вторых добавляет влияние всего, что написано в заголовочных файлах друг на друга и на конечный код. Нередки случаи, когда заголовочные файлы нужно включать в определенном порядке или определять некоторые макросы чтобы код нормально собрался.

В итоге в инфраструктуре С++ отсутствуют понятия «сборок» или «пакетов» и, в отличии от С# или Python, где установка компонентов тривиальна, в С++ подключение каждой новой библиотеки может нести свои неожиданности. Предлагаемый механизм модулей в С++ призван убрать данную проблему, отказаться от директивы препроцессора #include и ссылаться на компоненты, как на некоторую сущность, состоящую из кода и метаданных, целостную и легко подключаемую. В итоге мы вскоре можем получить существенное ускорение внедрения новых компонентов в проект, появления полноценных менеджеров пакетов, установка новой библиотеки сведется к выполнению одной строки или нескольким кликам мышью. Это ли не счастье!

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

На днях исполняется 10 лет с тех пор, как я получил самую странную свою работу.

Шел 2005-ый год. Мой интерес к разработке системы управления контентом на Java для компании, недавно купившей наш стартап, неуклонно улетучивался, в то время как моей настоящей страстью была разработка компиляторов и инструментов языковой инфраструктуры (в основном для SBCL). Как-то раз я заметил открытую вакансию как-раз по этому направлению, что вообще-то было достаточно редким явлением. Я быстро прошел интервью — настолько быстро, что даже не задал нужных вопросов и проигнорировал несколько тревожных звоночков.

Меня ожидало захватывающее путешествие в мир ретрокомпьютинга.

В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «14 стандартов» — чего только тут ни напридумано: древние DCOM и Corba, странные SOAP и .NET Remoting, современные REST и AMQP (да, я знаю, что кое-что из этого формально не RPC, для того чтобы обсудить терминологию даже вот специальный топик недавно создали, тем ни менее всё это используется как RPC, а если что-то выглядит, как утка и плавает, как утка — ну, вы в курсе).

И конечно же, в полном соответствии со сценарием комикса, на рынок пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC. Google можно понять — продолжать в 21-ом веке гонять петабайты данных по старому и неэффективному HTTP+REST, теряя на каждом байте деньги — просто глупо. В то же время взять чужой стандарт и сказать «мы не смогли придумать ничего лучше» — совершенно не в их стиле.

Поэтому, встречайте, gRPC, что расшифровывается как «gRPC Remote Procedure Calls» — новый фреймворк для удалённого вызова процедур от Google. В этой статье мы поговорим о том, почему же он, в отличии от предыдущих «14 стандартов» всё-таки захватит мир (ну или хотя бы его часть), попробуем собрать билд gRPC под Windows + Visual Studio (и даже не говорите мне, что инструкция не нужна — в официальной документации упущено штук 5 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.

Долгие годы С++ программисты, пишущие под Linux язвительно пеняли разработчикам на С++ под Windows отсутствием в Visual Studio нормального профилировщика памяти. Вот в Линуксе, дескать, есть Valgrind, который решает все проблемы, а в студии что: расставляй какие-то макросы, анализируй какие-то логи — мрак. Клевета! Хотя и правда. Вернее, это было правдой до выхода Visual Studio 2015, в которой наконец-то (ура 3 раза!) присутствует нормальный профилировщик памяти, позволяющий ловить утечки памяти с закрытыми глазами, одной левой и даже не просыпаясь!

В этой статье мы посмотрим, что он умеет и как им пользоваться.