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

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Если вам случалось писать большие приложения, вы, вероятно, использовали такие виртуальные машины, как VMWare, Virtual PC или что-то иное. Но задавались ли вы вопросом: как они работают? Эти удивительные, можно сказать, магические технологии увлекали меня довольно долгое время. Чтобы развенчать «магию» и разобраться в деталях, я написал «с нуля» собственную систему виртуализации – «песочницу». Решение этой задачи было довольно сложным делом. Реализация подобного продукта ставит множество вопросов, ответы на которые вы не найдете в Google, поэтому я хочу поделиться своим опытом с сообществом.

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

Смотрю на форумах рунета, люди начинают писать на C++&Qt Quick и используют наследников от QObject, для так называемых типов значений(Value Type). Мартин Фаулер их называет Value Object. Хотя есть макрос Q_GADGET позволяющий использовать QMetaObject c некоторыми ограничениями, но без наследования от QObject. Все что будет описано ниже результат экспериментов с Qt Quick. Буду рад узнать что-то новое из комментариев.

Пример таких типов QPoint, QGeoCoordinate и т.д. Наследоваться от QObject и использовать макрос Q_OBJECT неудобно для таких типов:

• QObject защищен от копирования;
• нужно возвращать значение по указателю. Приходится задумываться о CppOwnership/JavaScriptOwnership из перечисления QQmlEngine::ObjectOwnership.

Q_GADGET позволяет нам использовать:

• Q_ENUM;
• Q_PROPERTY;
• Q_INVOKABLE.

Ограничение:

• Отсутствие поддержки сигналов и слотов.

В жизни любого развивающегося проекта рано или поздно (и лучше рано) наступает момент, когда эксплуатация многозначительно смотрит на разработку и предлагает оформить отношения. Дальнейшее развитие событий, как водится, зависит от обеих сторон. О плохом сегодня не будем, рассмотрим сразу случай, когда разработка готова использовать нехитрый инструментарий сборки пакетов, подготовленный для нее эксплуатацией (шаблоны debian/rules и debian/control, команды fakeroot, debuild, и так далее). Осталась самая малость: поднять для собранных пакетов собственный репозиторий.

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

Василий Иванов — молодой, талантливый и предприимчивый технический специалист — решил открыть свой бизнес, так как придумал мега-продукт. На старте бизнеса он уволился с работы, зарегистрировал ООО с 10 тыс. уставного капитала, вложил немного своих денег, взял небольшой кредит, нанял на работу 5-ых технических специалистов. Работа пошла, но через полгода оказалось, что у продукта нет будущего, деньги закончились, кредит не погашен, перед сотрудниками задолженность по зарплате за 2 месяца на сумму 400 тыс. рублей чистыми и перед бюджетом на сумму 204 тыс. рублей (примерно +51% от суммы задолженности перед сотрудниками, т.к. тут 13% НДФЛ, 31% ПФР + ФОМС и по мелочи). В общем, дела плохи, пора закрываться и возвращаться к работе «на дядю».

Вопрос: что делать Василию с долгами и ООО?

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

Введение

Последнее время я занимаюсь разработкой настольного Rest API клиента. Довольно большая часть работы состоит во взаимодействии с сервером. Для оптимизации обработки запросов был написан класс Requester, обладающий следующими особенностями:

• возможность отправлять как https, так и http запросы
• использование одной функции для всех типов запросов
• возможность получить все данные по запросу с сервера, а не одну страницу(n записей)

Увидел сегодня в ленте статью и вспомнил, что хотел ведь про свой проект пару строк на Хабр написать.

В общем, некоторое время я работал техлидом с программистами iOS/Android, которые много использовали в своем коде API на Django/Yii2/проприетарщине. И посмотрев со стороны на инструменты, имеющиеся у них для работы с REST API, я решил нечто подобное добавить и в Qt, т.к. нормальных средств по работе с REST с использованием Qt моделей не существовало.

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

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

Разработчики вирусного ПО и просто разработчики, не желающие, чтобы их программу пытались реверсить, на этапе запуска или установки проводят проверки на виртуальную машину, и в случае её обнаружения отказываются работать, а то и вовсе самоликвидируются. Под катом описан способ, как можно попробовать решить эту проблему.

В чем проблема текстовых форматов обмена данными? Они медленные. И не просто медленные, а чудовищно медленные. Да, они избыточны, по сравнению с бинарными протоколами и, по идее, текстовый сериализатор должен быть медленнее примерно на столько же, на сколько он избыточен. Но на практике получается, что текстовые сериализаторы иной раз на порядки уступают бинарным аналогам.

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

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

Нудное вступление с Qt 4.8

Недавно коллега по работе спросил об опыте использования построения отчетов под Qt (начинаем потихоньку внедрять SCADA, написанную на Qt) — в силу поставленной задачи очень нужная вещь. Генераторами никто не пользовался (на данной платформе), но отчеты мы я каким-то образом делали без использования FastReport и таскания лишних приложений.

Покопавшись в проектах, нашел приложение с отчетами, виджетами для предпросмотра (QLabel, QTableView....). Вид отчета «preview»:

Поскольку основное предназначение QML — это создание интерфейсов, то в соответствии с шаблоном MVC, на нем реализуются представление и контроль. Для реализации же модели, совершенно логично напрашивается C++. Здесь у нас будет гораздо меньше ограничений и мы сможем реализовать модель любой сложности. Кроме того, если значительная часть программы написана на C++ и данные поступают именно оттуда, то лучше всего там же поместить и модель.

От использования такой модели может отпугнуть кажущаяся сложность реализации. Я не стану спорить с тем, что C++ не самый простой язык. Он посложнее QML и требует больше осторожности, чтобы не выстрелить себе в ногу, это факт. Несмотря на это, на практике не все так уж и страшно.

Во-первых, не будем забывать, что мы пишем не на чистом С++, а с использованием Qt. Такие вещи как parent-child в QObject, implicit sharing для контейнеров, сигналы и слоты, QVariant и многое другое очень сильно упрощают и автоматизируют работу с памятью, чем избавляют разработчика от массы головной боли и повышают надежность. Иногда даже создается впечатление, что пишешь на динамическом языке программирования. Это же сокращает пропасть между QML и C++, делая переход между ними более-менее плавным.

Во-вторых, все модели QML в конечном итоге приводятся к этим самым C++-моделям, только мы получаем упрощенный вариант и не самое максимальное быстродействие. Если уже есть понимание, как работать с моделями на QML, то с C++-моделями будет справиться проще. Мы просто узнаем в процессе чуть больше низкоуровневой информации, заодно улучшится понимание, как все это работает.

В общем, освоить C++-модели очень даже стоит. В особенности это касается QAbstractItemModel, с которой мы и начнем.

Model-View в QML:

• Model-View в QML. Часть нулевая, вводная
• Model-View в QML. Часть первая: Представления на основе готовых компонентов
• Model-View в QML. Часть вторая: Кастомные представления
• Model-View в QML. Часть третья: Модели в QML и JavaScript
• Model-View в QML. Часть четвертая: C++-модели

Речь пойдет об объектах, используемых в C++ и QML одновременно, верхушкой иерархии наследования которых является QObject. Насколько мне известно, реализации механизма автоматического контроля времени жизни таких объектов на уровне библиотеки не существует. Подобный механизм избавил бы от сложностей, возникающих при ручном контроле времени жизни объектов, а так же от потенциальных багов, утечек памяти и крешей приложения. В этой статье я опишу этапы реализации данного механизма, а так же проблемы, рассмотренные в процессе исследования данной проблемы.

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

По специфике моей работы мне часто приходится записывать и хранить большое количество паролей и другой конфиденциальной информации, поэтому я пользуюсь Keepass2 — менеджером паролей со свободной лицензией. Я не стану рассказывать о его возможностях и преимуществах перед другими, все это и так уже обсуждалось не раз. Если кто хочет познакомиться подробнее, вот несколько ссылок: wiki, обзорная статья, сравнения с другими: 1 2.
Вместо этого я хотел бы рассказать об одной его интересной функции:

Функция называется "URL Overrides", и представляет ссобой возможность запускать ассоциированные с записями программы и передавать им данные для аутентификации прямо из Keepass'а.

Например, вы можете хранить в keepass'е список учеток для подключения к удаленному серверу, а в определенный момент выбрать нужную и простым нажатием Ctrl+U, запустить клиент удаленного подключения, и моментально получить доступ к вашему серверу.
Это очень удобно, так как все логины и пароли не хранятся абы где, а надежно зашифрованны в вашей базе keepass и передаются программе-клиенту только в момент подключения.

Идея состоит в том, что бы использовать Keepass как единую точку входа на все удаленные сервера.

Я люблю Qt. Честно-честно. Я начал изучать его на грузовом пароме из Травемюнде в Хельсинки в компании пьяных дальнобойщиков, их полупьяных подруг, автоперегонщиков и просто забулдыг, которым суточное путешествие по морю позволяет эффективно бороться с суровостью финских антиалкогольных правил. Каюты у меня не было, Интернета тоже, так что к концу поездки я уже довольно бодро тасовал QML-теги и даже необходимость использовать QString не вызывала былой икоты. Нет-нет, я в самом деле люблю Qt.

Но еще сильнее я люблю Turbo Vision. Для меня он — привет из молодости, когда мир был проще, когда люди не таскали туда-сюда могучие фреймворки, задачи на четыре строчки решались четырьмя строчками и никому не приходило в голову рисовать тривиальные картинки с помощью HTML, CSS и джаваскрипта. Когда кнопку можно было поставить в точку X и быть уверенным, что она останется там в любую погоду. Когда задачи не решались методами “скачать” и “установить”, а также “подобрать” и “сконфигурировать”. Когда запрещалось использовать код, у которого “неизвестно, что там внутри”, а любую проблему можно было отладить за конечное число шагов. Когда документация представляла собой книжку, а не распечатку с форума.

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

Рисовать UI для нас — задача непрофильная и всегда решалась по остаточному принципу, не барское это дело — кнопочки по экрану расставлять. Но, раз приперло, надо делать.
Вы понимаете, о чем я? Да, мы написали свой Qt. Вернее, конечно, не его, поскольку нет смысла переписывать уже написанное.

На прошлой неделе, после девяти месяцев разработки, вышла версия 5.6 кроссплатформенного фреймворка Qt.

Qt позволяет разрабатывать приложения при помощи C++ и декларативного языка программирования QML, поддерживает все основные десктопные и мобильные платформы, а также некоторые встраиваемые и имеет открытый исходный код. Существует коммерческая версия Qt, содержащая дополнительные проприетарные модули.

Новый выпуск принес длительный срок поддержки, новые экспериментальные модули (и удаление устаревших), поддержку новых платформ, а также новый тарифный план для стартапов в коммерческой версии Qt.

Всем привет!

Как можно было догадаться из заголовка речь пойдет о парсинге HTML (далее хтмл).

На работе меня попросили сделать сравнительную характеристику нескольких продуктов для создания кроссплатформенных мобильных приложений: Appcelerator Titanium, Kony Platform, Adobe PhoneGap, IBM Worklight, Telerik Platform, Verivo Akula, Xamarin. Потратил немало времени, поэтому решил, что лучше поделиться с хабрасообществом полученными данными, вдруг кому покажется полезным. Сразу скажу, что кроме PhoneGap я до этого не сталкивался и не работал ни с каким из этих фреймворков, поэтому уверен, что что-то упустил, где-то, возможно, не так понял, а в чем-то оказался не прав. Но в комментариях надеюсь услышать ваше мнение и исправить недочеты.

В конце статьи поместил несколько опросов, которые помогут понять популярность и рейтинг этих фреймворков.