Многим людям рано или поздно приходит в голову мысль, что стандартный менеджер процессов Windows весьма слаб по функционалу. Начинаются поиски альтернативы, которые в основном тут же и заканчиваются при обнаружении Process Explorer от Марка Руссиновича. Вот и Хабр даже советует эту программу.

Что тут можно сказать? Конечно, Process Explorer — это хорошая программа. Однако, не идеал. Именно в пику её неидеальности существует не только бесплатная, но и свободная альтернатива — Process Hacker. А теперь мы детально и по пунктам рассмотрим, почему Process Hacker не просто «чуть-чуть лучше», а лучше на порядок, лучше на столько, что переводит программу для продвинутого пользователя в класс инструмента системного программиста или администратора.

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

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

Вы, возможно, помните как несколько лет назад стремительно стали набирать популярность NoSQL-базы данных (MongoDB, DynamoDB и другие). Многие пророчили смерть классических реляционных баз данных, торжество новых парадигм и всеобщее счастье в мире. И вы, возможно, в курсе того, как в последний год (или около того) наблюдается откат этой эйфории — выходят статьи типа «Broken by Design: MongoDB Fault Tolerance» и Why You Should Never Use MongoDB. Народ на Хабре на Тостере интересуется — «А почему же Монгу критикуют?», на что получает ответы «перерекламировали», «серебрянной пули нет», «надо выбирать базу данных по задачам».

Все 3 очевидных варианта — «Использовать реляционную БД», «Использовать NoSQL-БД», «Выбирать БД по задачам проекта» мне не нравятся по причине, высказанной в заголовке статьи.

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

Но для Modern-приложений всё иначе. Давайте возьмём, к примеру, приложение «Погода» из стандартного набора Windows8. Допустим, мы открыли его в боковой панели и хотим как-то узнать из нашего обычного (Desktop) приложения, а какую же оно показывает температуру. Если посмотреть на окно «Погоды» с помощью Spy++ мы увидим родительское окно типа Windows.UI.Core.CoreWindow и вложенное в него окно Web Platform Embedding. А значит перед нами Modern-приложение написанное на HTML\Js и живущее внутри встроенного компонента браузера. То есть вышеописанные манипуляции с Windows-контролами не имеют смысла — их в этом окне попросту нет, поскольку всё его содержимое рендерится целиком.

Но давайте же всё-таки попробуем вытащить из него текущую температуру.

В какое прекрасное время мы живём! Вот пишешь ты программу и понадобилась тебе библиотека для чего-нибудь — она точно найдется! Многие библиотеки лежат в opensource и даже распространяются по приятным лицензиям типа LGPL, взял — и решил проблему. Делов-то: способ подключения описан в readme, библиотека предоставляет красивые интерфейсы, демка есть (она даже компилируется и работает). Вообще ООП со всеми его идеями абстракций, интерфейсов, инкапсуляции внутренних данных — мощнейшая штука (тут без иронии).

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


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

Для написания статей на Хабр я пользуюсь текстовым редактором Sublime Text. Почему это хороший редактор на Хабре уже много раз писали (например тут). Есть, однако, при написании статьи момент, когда её нужно переносить для публикации на Хабр, ну, знаете: Хабр->Добавить пост->Название, хабы, текст (Ctrl+C/Ctrl+V), метки, предпосмотр. В этот момент оказывается, что как-то текст с картинками сверстался на Хабре некрасиво, начинаются правки. Править в браузере? Неудобно и небезопасно. Править в Sublime и постоянно копипастить? Неудобно и надоедает.

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

Под катом мы научимся писать плагины к Sublime и разберёмся как из питоновского кода взаимодействовать с Хромом, используя его протокол удалённой отладки. Полный код плагина на GitHub прилагается.

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

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

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

Что же делать?

К сожалению, в стандартной библиотеке языка С++ нет никаких средств для работы с протоколом HTTP. Возможно, в будущем появятся, но на данный момент каждый раз при необходимости дёрнуть какой-нибудь REST-сервис, пропарсить веб-страничку, написать простенького бота или краулера приходится задаваться вопросами «А какую же библиотеку взять, так чтобы побыстрее и попроще?». Иногда проект уже использует какой-то фреймворк (а иногда даже несколько) и тогда приходится вспоминать «А как же сделать HTTP-запрос имеющимися средствами?». Чтобы не путаться я решил написать для себя шпаргалку с примерами HTTP-запросов на С++ с применением разных библиотек. А самое удобное место для хранения подобных шпаргалок — Хабр: и сам не потеряешь, и другим может пригодиться.

Будут рассмотрены:

• WinInet
• WinHttp
• Casablanca
• Qt
• POCO
• wxWidgets
• Boost.Asio
• libcurl
• neon
• .NET (С++/CLI)
• IXMLHTTPRequest
• HappyHttp
• cpp-netlib

Эта статья — краткий пересказ невероятно интересного доклада Скотта Майерса для тех, у кого нет 70 минут на весь доклад, но есть 7 минут на основные тезисы.

Некоторые люди, которые не пишут на С++, а лишь слышали об этом языке, задаются вопросом: «Почему вообще кто-то пишет на C++?». Но есть люди, которые используют С++ каждый день, и вот эти люди задаются вопросом: «А действительно, почему я пишу на этом языке?».

Но ведь действительно, должна быть какая-то причина, по которой люди пишут программы на С++. Давайте вернемся в начало 90-ых, когда проходила стандартизация С++. Была предложена масса идей. Предложений было столько и они были настолько разные, что мне запомнилась цитата Джима Вальдо, который тогда работал в комитете по стандартизации: «Каждый, предлагающий добавить что-то в С++ должен приложить к заявке свою почку. Тогда никто не предложит больше двух идей, а к выбору этих двух он подойдёт невероятно ответственно.»

Язык, который был бы получен в результате принятия всех предложений, выходил слишком сложным и тогда Бьёрн Страуструп сказал «А помните Ваза?». Никто, кроме людей из Швеции, не понял о чём речь. Ваза был огромным боевым кораблём, построенным в Швеции в 1625 году. Основным принципом постройки корабля было «А почему бы нам не добавить сюда ещё и вот такую фичу?». Многие из идей исходили непосредственно от короля, в частности он лично утверждал размеры корабля. Также на Ваза по указаниям свыше требовалось нацепить огромное количество элементов украшения, резьбы, большое количество пушек и т.д. А королю ведь не откажешь. Итог был закономерным — из-за ошибок в конструировании Ваза затонул в первом же рейсе, едва выйдя из бухты.

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

Нормальным развитием любого кода является устаревание отдельных его частей (функций, классов и т.д.) и планомерное удаление их из проекта для снижения сложности и повышения безопасности кода. Просто убрать что-то обычно является плохой идеей — это может резко сломать какой-нибудь компонент, использующий удаляемую сущность. Хорошей практикой является пометка устаревшего кода каким-либо способом, который даст возможность использующим его программистам узнать о том, что он запланирован к удалению. (Прим. переводчика — Microsoft для этого изобрела свой велосипед, а ещё люди иногда пользовались #pragma message).

Новый стандарт С++14 вводит атрибут deprecated для пометки устаревших сущностей, планируемых к удалению в дальнейшем. Компилятор может выводить предупреждения при любой попытке их использования. Синтаксис принципиально новый для С++: атрибуты предполагается писать в виде списка через запятую, внутри двойных квадратных скобок. Вот так выглядит функция, помеченная как deprecated:

[[deprecated]]
void foo() {}

int main() {
	foo(); // в этом месте компилятор выведет предупреждение
}

Как вы, возможно, знаете в мире Windows для рисования графики часто используется DirectX. В последних версиях (10, 11.x) библиотека серьёзно шагнула вперёд и именно на них построены движки многих современных игр. Кроме того, DirectX используется не только в играх — сам интерфейс ОС Windows тоже с непомню-какой версии (Vista?) рисуется через него, да и казалось-бы не сильно связанные с графикой программы, желая увеличить производительность и плавность зума\скрола переходят на последние версии DirectX. Так некоторое время назад на DirectX11 перешел рендер Google Chrome (вроде бы с версии 36).

Когда-то во времена Windows 95 и Pentium II была такая шутка, что чем медленнее компьютер — тем лучше можно понять работу операционной системы — невооруженным глазом видно в каком порядке прорисовываются элементы окон, обрабатываются события. Сегодня для подобных целей относительно DirectX есть отдельные инструменты — графические отладчики, позволяющие понять, как именно рисуется каждый пиксель каждого кадра, какие операции выполняет движок DirectX, какие ресурсы он использует, насколько быстро и правильно всё работает. Один из таких инструментов — RenderDoc от компании Crytek мы сегодня и рассмотрим. А в качестве примера разберём уже упомянутый выше новый рендер Google Chrome.

Folly — это открытая С++ библиотека, разрабатываемая Facebook и используемая им во внутренних проектах. С целью оптимизации расходов памяти и процессорных ресурсов библиотека включает собственные реализации некоторых стандартных контейнеров и алгоритмов. Одной из них является folly::fbvector — замена стандартного вектора (std::vector). Реализация от Facebook полностью совместима с оригинальным интерфейсом std::vector, изменения всегда не-негативны, почти всегда измеримы, часто — существенно, а иногда даже грандиозно влияют на производительность и\или расход памяти. Просто включите заголовочный файл folly/FBVector.h и замените std::vector на folly::fbvector для использования его в своём коде.

Пример

folly::fbvector<int> numbers({0, 1, 2, 3});
numbers.reserve(10);
for (int i = 4; i < 10; i++) {
  numbers.push_back(i * 2);
}
assert(numbers[6] == 12);

Мотивация

std::vector — устоявшаяся абстракция, которую многие используют для динамически-аллоцируемых массивов в С++. Также это самый известный и самый часто используемый контейнер. Тем большим сюрпризом оказывается то, что его стандартная реализация оставляет достаточно много возможностей по улучшению эффективности использования вектора. Этот документ объясняет, как реализация folly::fbvector улучшает некоторые аспекты std::vector. Вы можете воспользоваться тестами из folly/test/FBVectorTest.cpp чтобы сравнить производительность std::vector и folly::fbvector.

Наверное, многие C++-программисты слышали про мультиметоды и знают о том, что по сей день нет для этого языка приемлемой реализации: ни языковой поддержки, ни внешних библиотек. Есть кодогенераторы, выкрутасы через виртуальные методы, частный случай двойной диспетчеризации aka паттерн Посетитель (Visitor). Но ведь хочется просто реализовать несколько функций и указать: этот набор функций — есть мультиметод и точка.

О мультиметодах и некоторых подходах к их библиотечной реализации давно писали Мейерс и Александреску. Почти 20 лет эти идеи обсуждаются в различной литературе по C++, но до сих пор так и не были развиты до законченного решения, которое можно было бы удобно использовать в реальных проектах…

Я решил попытать счастья, дерзнуть, предложить свое видение этой проблемы и способ ее решения. Получилась шаблонная библиотека на одних только заголовочниках.
Это реализация под стандарт C++03, на чистом C++: без каких-либо кодогенераторов и дополнений. Цель — библиотека с простым и понятным интерфейсом для реализации возможности перегружать функций по типу (и даже по значению) во время выполнения (это была программа минимум, в конечном итоге получилось еще много вкусностей).

Несколько дней назад Бьёрн Страуструп опубликовал предложение N4174 комитету по стандартизации С++ названное "Call syntax: x.f(y) vs. f(x,y)". Вот вкратце его суть: объявить выражение x.f(y) (вызов для объекта х метода f с аргументом y) эквивалентным выражению f(x,y) (вызов функции f с аргументами x и y). Т.е.

x.f(y) означает:

1. Попробовать вызвать x.f(y): если класс объекта х содержит метод f, который может принять аргумент y — используем этот метод.
2. Если пункт №1 не удался — проверяем, существует ли функция f, которая может принять аргументы x и y. Если это так — используем её.
3. Если не найдено ни того, ни другого — генерируем ошибку.

f(x,y) означает ровно то же самое:

1. Попробовать вызвать x.f(y): если класс объекта х содержит метод f, который может принять аргумент y — используем этот метод.
2. Если пункт №1 не удался — проверяем, существует ли функция f, которая может принять аргументы x и y. Если это так — используем её.
3. Если не найдено ни того, ни другого — генерируем ошибку.

Таким образом мы получаем возможность писать методы расширения, о которых мечтали многие С++ программисты. Я считаю это предложение одним из самых важных в эволюции языка С++.

Proxygen — это коллекция библиотек для использования протокола HTTP на С++, включающая в числе прочего очень простой в использовании HTTP-сервер. Кроме классического HTTP/1.1 фреймворк Proxygen поддерживает SPDY/3 и SPDY/3.1. Вскоре также будет полностью поддерживаться HTTP/2.

Proxygen не задумывался как замена Apache или nginx — эти проекты сфокусированы на создании достаточно гибких и конфигурируемых веб-серверов, позволяющих благодаря тонкой настройке добиться максимальной производительности. Задачей Proxygen является работать достаточно хорошо на дефолтных настройках, давая программисту простые в использовании веб-сервер и веб-клиент, легко интегрирующиеся в уже существующие проекты. Мы хотим помочь людям строить веб-сервисы на С++ с меньшими затратами и мы верим, что Proxygen — отличный фреймворк для этого. Вы можете почитать документацию по нему и подключиться к разработке на Github.

Hello C++ World!

В прошлую пятницу вышел релиз Visual Studio 2015 Preview, в котором были представлены новые возможности увеличения продуктивности разработки, в том числе рефакторинг кода на С++. В значительной мере на реализацию этого функционала повлияли отзывы комьюнити, которые были получены в ходе тестирования Visual Studio «14» CTPs, так что спасибо всем поучаствовавшим.

В этой статье мы рассмотрим такие возможности Visual Studio 2015 Preview по работе над С++ кодом, как:

• Переименование (Rename)
• Извлечение функции (Extract Function)
• Генерация заглушек чисто виртуальных методов (Implement Pure Virtuals)
• Генерация объявлений/заглушек методов (Create Declaration/Definition)
• Перемещение объявлений функций (Move Function Definition)
• Преобразование в Raw-String (Convert to Raw-String Literal)

«Не звони нам. Мы позвоним тебе сами.» — принцип Голливуда

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

Итак, ещё раз плюсы:

• Уменьшает связность компонент (отделяет бизнес-логику от создания объекта)
• Позволяет писать более поддерживаемый код (в одни и те же объекты мы легко можем внедрять разные зависимости)
• Позволяет писать более тестируемый код (мы можем легче использовать стабы и моки)

Без внедрения зависимости	С внедрением зависимости
class example { public: example() : logic_(new logic{}) , logger_( logger_factory::create() ) { } int run() const; private: shared_ptr<ilogic> logic_; shared_ptr<ilogger> logger_; };	class example { public: example(shared_ptr<ilogic> logic , shared_ptr<ilogger> logger) : logic_(logic), logger_(logger) { } int run() const; private: shared_ptr<ilogic> logic_; shared_ptr<ilogger> logger_; };

На Хабре уже неоднократно рассказывали о таком мощном и удобном средстве мониторинга HTTP-трафика, как Fiddler. Все имеющиеся статьи, однако, рассказывают о встроенных фичах программы, не акцентируя внимания на возможностях её расширения, которых существует целых две: с помощью встроенного языка FiddlerScript и с помощью написания .NET-плагинов. В этой статье мы рассмотрим и то, и другое, а чтобы было интереснее — используем их для решения вполне практической задачи, о которой я писал в своей прошлой статье (подмене битых ссылок на картинки в статьях на Хабре на рабочие).

Итак, давайте вспомним для начала, чем закончилась прошлая статья: мы получили список нерабочих ссылок на картинки и соответствующих им рабочих ссылок на веб-архиве. Теперь нужно отдать их браузеру и для этого мы напишем расширения к Fiddler (одно на FiddlerScript и одно на .NET). Обратите внимание на удобства полученного решения: да, нам нужно будет запустить Fiddler, но зато битые ссылки будут подменяться на рабочие независимо от домена статьи (хабр, гиктаймс или мегамозг), независимо от используемого браузера (лишь бы имел поддержку прокси) и даже мобильные устройства можно будет настроить на использование установленного на компьютере Fiddler в качестве прокси.

Некоторое время назад решил я освежить знания и почитать что-нибудь о графах. «Ну конечно же, на Хабре должны быть хорошие статьи!» — подумал я, и оказался прав. Статьи есть и их много. Но выглядит они преимущественно вот так: раз, два, три. Откройте и догадайтесь с одной попытки почему что-то понять из этих статей совершенно невозможно, хотя написано вполне понятным языком. Нет картинок! Ну а как изучать графы без картинок? Никак.

Новичок на Хабре недоуменно спросит: «Как так — нет картинок? Есть же habrastorage.org!». Да, есть. Но был он не всегда, а автоматически на него перезаливаться картинки и вовсе стали только в июле 2013-го. А до этого картинки хостились где-попало — на всяких радикалах, имейджхаках, даже на дропбокс, бывало, люди наивно пытались что-то выкладывать. В итоге мы имеем на Хабре кучу статей 2006-2013 года с отсутствующими картинками.

Давайте это пофиксим!