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

Бегло оглядев задачу, я сказал «давай сделаем это!». В следующий час (с небольшим) было написано несколько скриптов на python, чтобы распарсить сайт и заполнить нужной информацией небольшую SQLite базу. В данном случае это оправданное решение, поскольку каждый раз пробегать по страничкам сайта из просмотрщика долго, а информация по большей части игр не меняется. Новые игры добавляются редко, да и то только те, что вышли недавно.

После того, как скрипты были оттестированы и готовы мы запустили их на выполнение и пошли пить чай (с плюшками). Подождав пару часов и скоротав время за партией в Age of Wonders, у нас в руках оказалась полная база со всей необходимой информацией. Как инженер, на этом этапе я уже был полностью удовлетворен, поскольку если ты располагаешь всеми необходимыми данными, что тебе еще нужно? Однако, брат обратился за просмотрщиком, поэтому мы не стали останавливаться на достигнутом и продолжили работу.

К этому времени я уже достаточно давно занимался разработкой UI на Qt и изучал Qml, поэтому не стал долго размышляя над тем, какой фрэймворк или технологию выбрать для претворения стоящей задачи в жизнь. Я был приятно удивлен, как всего несколькими росчерками пера, буквально за пару минут (менее часа или около того) у нас получился красивый просмотрщик (дизайн понравился жене, а это говорит о многом) с нужным нам набором функционала (фильтрация по годам, по темам, по названиям и т.д., выгрузка информации в отдельный файл и т.д.).

После этой истории я подумал, как хорошо, что в эпоху когда Microsoft и Apple пытаются выжать из своих пользователей каждый доллар существуют такие компании и инструменты как Qt, которые с одной стороны предоставляют «мощные средства по разумной цене» для профессионалов, а с другой те же средства предоставляют каждому желающему для личного пользования, с, в общем то, небольшими ограничениями со стороны лицензии. За это ребятам большой респект и уважуха и низкий поклон. Спасибо.

Код проекта выложен здесь, бинарник для Windows можно скачать здесь.

P.S.: В целом, просмотрщик можно свободно использовать, в том числе с другими объектами и для других целей. Мы с братом будем рады, если кому-то проект будет полезен кроме нас двоих. Не забывайте только при случае ставить ссылку на авторов. Спасибо.

Комментарии (27)


  1. litvinenkow
    06.11.2018 12:21

    просмоТРщик


    1. Reptor Автор
      06.11.2018 12:22

      Поправил. Спасибо. На С++ чуть-чуть научился писать, а вот русский пока не освоил.


  1. pu5her
    06.11.2018 12:25

    Добавьте скриншотов интерфейса. Не все готовы запускать бинарник, чтобы оценить красоту интерфейса. Это особенно трудно если у тебя не windows :)


    1. Reptor Автор
      06.11.2018 12:30

      image


      1. BeardedBeaver
        06.11.2018 14:38

        Интерфейс, надо сказать, достаточно страшненький, с QML можно было сделать намного лучше, нагляднее и без такого количества пустого пространства, с более четким разделением на колонки.


        1. Reptor Автор
          06.11.2018 17:06

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


  1. FenixFly
    06.11.2018 12:27

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


  1. altrus
    06.11.2018 12:36

    Для человека, незнакомого с qml из статьи абсолютно непонятно, чем qml в данной задаче оказался лучше PHP или java
    Типа, «я ходил в такой-то ресторан, было вкусно».
    А если статья о вашем конечном продукте, то смените название.


    1. Reptor Автор
      06.11.2018 12:53

      PHP нет, потому что нужен сервер для его отработки. А Java vs QML — можно использовать то, что нравиться и что больше знаешь, хотя у QML есть свои особые бонусы при разработке. Вот хорошая статья на эту тему.


      1. altrus
        06.11.2018 13:03

        В QML сервер (VM) сразу вшит, оттуда и такой размер


        1. Reptor Автор
          06.11.2018 17:18

          Вне всякого сомнения. Мы говорим про разработку на прикладных языках высокого уровня, поэтому какой бы инструмент мы не взяли будет frontend, backend и т.д., где-то это интерпретатор + скрипт, где то виртуальная машина + код. В случае Java это VM+код на Java, в варианте Qt это код на С + java script, и т.д. Думаю нет смысла искать ответ на эзотерический вопрос «что является лучшим всегда везде и при всех обстоятельствах?», поскольку каждый будет ратовать за свой любимый фраймворк. В данном случае выбор пал на Qt, поскольку мы его хорошо знали и qml, поскольку он предоставляет удобный декларативный интерфейс описания интерфейса. Все всякого сомнения данную задачу можно решить и при помощи других инструментальных и языковых средств. Целью же данной статьи было поделиться радостью и удивлением от того насколько быстро этого удалось достичь, сравнительно небольшим объемом кода.


          1. altrus
            06.11.2018 17:22

            сравнительно небольшим объемом кода.

            На php/css подобную выборку из базы я думаю можно уложиться в 3-4 килобайта текста
            У вас какой объем?

            И что такое «Upload to file»?


            1. Reptor Автор
              06.11.2018 17:48

              Выборка из базы осуществляется в классе MobyGamesItemsModel (260 строк кода). Возможно вы имели ввиду размер exe файла + библиотеки?
              В любом случае, буду рад решению на php (люблю это язык), и читателям, думаю, оно будет полезно.


      1. SerafimArts
        06.11.2018 13:24

        PHP нет, потому что нужен сервер для его отработки.

        Небольшое замечание: Для PHP не нужен сервер. Для него нужен бинарник с интерпретатором, точно так же, как и Java.


        1. Reptor Автор
          06.11.2018 17:19

          Согласен. Оговорился. Имелось ввиду, что в отличии от Java, которая стоит практически на каждом компьютере интерпретатор PHP стоит не везде.


  1. Reptor Автор
    06.11.2018 12:52

    удалено


  1. BeardedBeaver
    06.11.2018 14:47

    Про могущество и простоту в статье ничего не нашел. Слово «брат» в тексте статьи фигурирует 3 раза, слово «qml» один раз. Никаких технических подробностей реализации (кроме скорости разработки, но без сравнения с аналогами) не приведено.

    Подождав пару часов и скоротав время за партией в Age of Wonders, у нас в руках оказалась полная база со всей необходимой информацией.

    Вопиющее несогласование, надо либо «После пары часов за партией ...» или "… мы получили полную базу ...".

    Увидев заголовок, подумал, что будет что-то обстоятельное, с описанием подходов работы со сложно структурированными данными и написанием красивого гуя, а тут
    я ходил в такой-то ресторан, было вкусно


    Низачет


    1. Reptor Автор
      06.11.2018 17:26

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


  1. mefest
    06.11.2018 17:26

    Статья немного кажется неполной. Было бы не плохо добавить скриншотами и фрагментами кода.
    Так же интересно почему выбрали провязку с c++ через setContextProperty а не qmlRegisterType?


    1. Reptor Автор
      06.11.2018 17:41

      Код получился достаточно коротким и простым (если не сказать), поэтому не хотел захламлять место. Все же основная идея статьи то, что при помощи qml можно разрабатывать UI быстро (очень быстро), а если верить QtCompany, то после выхода Qt Design Studio 1.0 практически молниеносно.
      P.S. Спасибо, что посмотрели код. setContextProperty использовали вместо qmlRegisterType по той причине, что модель в нашем случае не является тиражируемой сущностью, а единичным объектом к которому нужно получить доступ из кода на qml. Так что mobyGamesModel это просто связующее звено между моделью на С++ и кодом на java script.


  1. Chaos_Optima
    06.11.2018 18:58
    +1

    Вся статья умещается в одно предложение «Написал просмотрщик для базы данных игр на qml, qml тащит.»
    Почему вы думаете что этой статье место на хабре? (честно говоря из-за подобных статей хабр всё больше и больше становится похожим на помойку. Хабр это не площадка для блога)


    1. SerafimArts
      06.11.2018 19:06
      -1

      Хабр это не площадка для блога)

      Хм… А для чего, если не для блога?


      1. Chaos_Optima
        06.11.2018 19:28

        Для того чтобы делится информацией и опытом, а не для того чтобы писать «Я написал такую-то тулзу, как я это сделал я вам конечно не расскажу, но вам это и не нужно, ибо там всё просто.»


        1. SerafimArts
          06.11.2018 20:08

          Ну да, согласен, блоги вести могут тут только «корпорации». Они так и называются — "корпоративный блог".

          А вообще я намекал на то, что термин «блог» слишком размытый и означает как и полноценные труды, так и сообщения в виде «твиттер-заметок», где второе поощрается крайне редко.


    1. Reptor Автор
      06.11.2018 19:14
      -2

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


      1. Chaos_Optima
        06.11.2018 19:25

        Очевидно что если статья ничему не обучает, или если не даёт никакой информации, то это плохая статья. Нужно чтобы статья отвечала вопросу «Что нового я могу узнать?» ваша статья на этот вопрос не отвечает, если бы вы написали, как пришли к выбору, как вы реализовали это приложение (даже если это пару строчек), с какими проблемами столкнулись или почему приняли те или иные решения при разработке, и продемонстрировали результат (скриншоты хотя бы). Вот это была бы действительно полезная статья. В которой кто-нибудь что-нибудь смог бы для себя найти. А так, это просто мусор.


        1. Reptor Автор
          06.11.2018 23:44
          +1

          Хорошо. Я понял. Никогда не поздно исправиться, поэтому давайте обсудим это сейчас. Вне всякого сомнения, эта заметка подобна короткому сообщению или твиту и смысл её, как отмечено в комментариях "qml позволяет разрабатывать интерфейс очень быстро, qml рулит", поэтому возможно её стоит переименовать в "qml: могущество и простота. Часть 1-ая. Смысловая", а все технические подробности продолжить в статье "qml: могущество и простота. Часть 2-ая. Техническая". Но пока ограничимся этим комментарием.


          1. Почему сделали такой выбор? Одним из наиболее значимых факторов в выборе того или иного инструмента является полнота знания — умение им пользоваться. Особенно важен этот фактор когда мы говорим о скоростных характеристиках разработки. Другой момент, что в qt вшит мощный механизм model/view, который я не знаю как можно было бы реализовать при помощи связки php+html/css/js или что тоже python+html/css/js, о которых говорилось в комментариях выше. Возможно постраничный вывод? Но зачем? В противном случае все перенесется в код на js + jquery (или подобные технологии). Java в этом смысле обладают с qt похожими возможностями, но ввиду того, что с java знаком чуть хуже выбор склонился в сторону qt.
          2. С какими сложностями столкнулись? Ввиду того что задача была понятна, а инструменты хорошо известны трудностей практически не возникло. За исключением пожалуй совета придерживаться более четной нотации в именовании объектов и переменных в коде на qml (js), поскольку неакуратность в этом отношении может приводить к непредсказуемым результатам.
          3. Почему приняли именно такие решения в процессе разработки? Поскольку в качестве источника данных выбрали базу данных, использование model/view было естественным продолжением этого решения, а благодаря мощной поддержке моделей в коде на qml, код отвечающий за интерфейс оказался очень компактным, практически таким же как если бы мы определяли шаблон для генерации html страницы.