2 августа 2014 в 23:57

Как мы «дрессировали огненную обезьяну» или наш опыт работы с FMX



Доброго времени суток, уважаемые Хабрапользователи!

Мы — компания «Сфера системс», и сегодня мы открываем корпоративный блог на Хабре, в котором хотим познакомить вас с нашим проектом «Sphere Live». И, хотя наш проект пока находится в стадии бета тестирования, сейчас уже можно с уверенностью говорить о том, что он состоялся.

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

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

Проект «Sphere Live» — это мультиплатформенная система организации видеоконференцсвязи с неограниченным количеством участников в форме симметричных и ассиметричных лекций с интегрированной биллинговой системой, функциями файлообмена и облачного хранилища, а также защитой информации о пользователе (переписка, отправленные и переданные файлы, видео- и аудиообщение).

На данный момент Sphere Live имеет единую кодовую базу для Windows, Mac OS, Android и iOS (последняя пока еще находится в разработке, т.к. требуется оптимизация интерфейса). Сейчас доступна бета-версия для устройств под управлением ОС Windows и альфа-версия для Android, поддержку остальных ОС мы планируем реализовать в течение августа 2014 г.

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

Сразу оговоримся, что мы не имеем никакого отношения к компании Embarcadero и не получаем от них никаких денежных вознаграждений. Более того, продуктами данной компании мы пользуемся на общих основаниях, т.е. покупаем без каких либо скидок. Delphi XE6 (FireMonkey) — это наш объективный, никем не навязанный выбор.

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

Начинали мы с версии Delphi XE2. А что нам оставалось еще делать? Мы прекрасно понимали, что приложение должно быть реализовано с минимальными затратами на разработку и обслуживание, при этом проект очень большой и сложный, значит необходимо было использовать именно тот язык и тот инструмент, который наиболее изучен и имеет серьезный потенциал развития, в отличие, например, от Java. На рынке не было универсальных инструментов для разработки и компиляции, были под каждую ОС свои, их нужно было освоить, а для этого увеличить штат разработчиков и тестеров, и потом управлять процессом перекладывания ответственности за невыполненные в срок задачи.

В итоге ситуация сложилась таким образом, что на тот момент у нас и выбора особого не было, т.к. нашим требованиям отвечал только Delphi XE2 — единый код, единая среда и компилятор для Windows и Mac OS. К настоящему моменту код Sphere Live переведен на Delphi XE6 (FireMonkey). Нам удалось реализовать практически идеальную с точки зрения архитектуры систему, в которой используется единая кодовая база. Более того, нам удалось добиться и схожести интерфейсов, хотя безусловно, отличия имеются.

Да простит нас Embarcadero, но сказать, что все идеально, мы не можем, т.к. в более ранних версиях среды разработки RAD Studio, были и существенные недоработки, и откровенные баги. Очень много пришлось создавать самим и решать проблемы самостоятельно. Были разработаны десятки уникальных компонентов. Однако, мы прекрасно понимали, что рано или поздно они достигнут стадии «правильного» продукта, и мы сможем использовать наш, уже приличный, опыт работы с Firemonkey.

На наш взгляд, большая часть сложностей, с которыми столкнулись или сталкиваются Delphi-программисты (RAD Studio в целом) – это практически полное отсутствие описания архитектуры и механизмов Firemonkey. Все, что присутствует в Интернете, либо не имеет практического применения, либо информация настолько скупа, что не позволит вам выявить элементарные ошибки (причем не только ваши, но и самой Embarcadero).

Мы потратили более года, чтобы разобраться в FMX (Firemonkey). Неоднократно «наступали на одни и те же грабли», не раз переписывали некоторые модули, работающие с GUI, мультимедиа и другие. Часто рассуждали о том — а не зря ли мы выбрали среду разработки RAD Studio, а именно — Delphi?! Периодически у нас опускались руки, как и у тех, кто разрабатывает что-либо на Delphi. Ждали и думали: «Когда же ребята из Embarcadero обратят внимание на обилие глюков и багов в самой среде и FMX?». Мы каждый раз ожидали выхода в свет новой версии “XE...”, разбирались в том, что вышло, пробовали и вновь «фиаско» (для нас), что в этот раз «опять не исправили»…

И, наконец, случилось! Если и не чудо, то почти ожидаемое! Embarcadero выпустила очередную версию RAD Studio XE6.

Мы приобрели версию XE6 сразу, как только о ее выходе объявила Embarcadero, даже на неделю раньше, чем она успела поступить в продажу в России (за что отдельное спасибо Сергею Кожевникову из представительства Embarcadero в России).

В первую очередь мы обратили внимание (буквально за первые сутки работы с ней):
— среда разработки стала намного стабильнее, реально стала работать практически стабильно (не убеждайте нас в том, что не бывает абсолютно стабильного ПО, особенно имеющего такой функционал);
— скорость работы с IDE выросла;
— скорость работы компиляторов под Android существенно выросла;
— устранено множество багов и ошибок в коде;
— существенно увеличилась скорость работы самих приложений, разработанных под FMX;
— появились новые, весьма полезные, функции.
И еще многое другое. Не будем все перечислять, и если кому-либо станет интересно, мы с удовольствием поделимся информацией.

Исходя из всего выше сказанного, у вас наверняка возникнет вполне справедливый вопрос: «А где же «ложка дегтя в этой бочке меда?».

И действительно, Embarcadero не акцентирует внимание на одном очень важном моменте. Технология Firemonkey, в принципе, отличается от работы с VCL только под Windows. Если вы скажете, что достаточно знать Object Pascal, то будете в корне не правы. Не все так просто. Ввиду особенностей работы самой FMX, программисту, впервые начавшему писать кросс-платформенные приложения будет весьма сложно. Он будет часто натыкаться на совершенно необъяснимые баги и глюки, все списывая на «кривизну» Delphi. И отчасти окажется прав, т.к. практически отсутствуют методические пособия и нет достаточного количества примеров для работы с Delphi.

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

Все выше сказанное относится именно к разработке приложений под различные платформы с использованием FMX.

Да, FMX еще имеет некоторые проблемы:
— она пока не столь сильна, как нам с вами хотелось бы;
— она пока не так насыщена компонентами, как VCL.
Однако все это не значит, что используя FMX нельзя создавать хорошие и серьезные проекты.

Можно! И нужно!

У нас гораздо больше причин «обижаться» на FMX и Embarcadero, чем у большинства из вас, но мы не сдавались и в итоге пришли к тому, чего добивались долгим и упорным трудом, а Embarcadero пришла к тому, чего мы все ждали.
Мы надеемся, что все их последующие релизы RAD Studio и Firemonkey, будут такими же, или даже лучше.

Все кому станет интересен наш опыт разработки на Delphi или сам проект, пишите в личку и скачивайте с сайта наше приложение. Будем рады ответить на все ваши вопросы.
Автор: @SphereLive
Сфера системс
рейтинг 14,12
Компания прекратила активность на сайте

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

  • +10
    «необходимо было использовать именно тот язык и тот инструмент, который наиболее изучен и имеет серьезный потенциал развития, в отличие, например, от Java» —
    довольно спорное утверждение, особенно когда именно Delphi противопоставляестя Java.

    Мне показалось, что в начале вы пишете о своем осознанном выборе Delphi, а потом большая часть статьи объясняет, почему этого не надо было делать. Хотя в конце неожиданный вывод, что все правильно. В общем, довольно сумбурное ощущение от материала.
    • 0
      Доброй ночи!
      Это наша первая статья. Опыта в написании статей у нас пока нет, и мы постараемся «извлечь уроки» и учесть все пожелания и замечания.
      Все последующие статьи (предполагаем написать цикл статей), мы постараемся написать более внятно и детально осветить процесс разработки.
  • +9
    Я правильно понимаю: вы из года в год покупали глючный продукт в надежде на то, что разработчики исправят в нем баги?

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

    P.S. По самой статье: очень коротко, такое чувство, что статья обрывается на середине. Мало технической информации (с чем имели сложности, как оно разрабатывать под разные ОС используя FireMonkey и т.д.). Ну и откровенно говоря после прочтения статьи не покидает мысль, что какие-то плюшки за неё от Embarcadero вы получили, уж больно вывод («Можно! И нужно!») сладкий.
    • +2
      Да, у меня тоже легкое маркетинговое послевкусие осталось.
    • 0
      Действительно. Статья обрывается. Как ответил уже выше — постараемся исправиться, и все последующие статьи писать более профессионально. Материал есть и очень большой, начиная с процесса проектирования и заканчивая разработкой собственных компонентов, но взять и опубликовать все разом, просто бессмысленно и более сумбурно, поэтому изучив комментарии и пожелания (ваши в том числе), будет опубликован более ценный материал: нестандартные решения, обход багов, ссылки на наши компоненты, а также опыт управления проектом и всех набитых нами «шишек».
      А теперь по поводу «плюшек». Все версии Delphi куплены нами самостоятельно, без каких-либо преференций в нашу пользу (копии платежей могу приложить). Еще одним доказательством нашей «связи с Embarcadero»
      является «популярность» нашего приложения и «широкое освещение» на ресурсах Embarcadero нашего проекта.
  • 0
    Вы меня извините за оффтопик, но мне кажется, что у вас сильно нагруженный элементами сайт, с попапом без запоминания того, что его закрыли, с вопросами в новостях и с гениальным по своему стилю полем «Подписаться на новости».
    • 0
      Спасибо за ваши комментарии. Мы обязательно учтем их, и в кротчайшие сроки все сделаем как надо.
  • +7
    С сайта:
    Новости компании
    30.09.2013 года

    ????????? ????? ????????? ???? ???????????? ?????? ???????????? Sphere? ?????? ?????? 2013 ???? ?? ????? ??????????.

    Похоже, Delphi использовался не только для продукта…
    • 0
      Это ценное замечание (мы в курсе, что кодировка поехала и устраняем эту проблему), но сайт для нас — это прежде всего ресурс для размещения приложения.
      • +6
        А зря. Люди в том числе и по сайту будут заочно оценивать качество вашего продукта.
        • 0
          Это бесспорное утверждение. В этом направлении тоже работаем (но уже без Delphi )).
    • 0
      Поправили
  • 0
    На КДПВ фоновая вёрстка из жизни? :)
  • +5
    Мыши плакали, кололись, но продолжали жрать кактус…
    • 0
      Опыт разработки на Delphi (это без пафоса) дал нам возможность «есть кактус практически не натыкаясь на иголки», хотя не все так просто, но для смены языка программирования обоснованных причин не было. И потом, если бы мы писали игрушку, софт для железа или для браузера, то нашу работу действительно можно было бы охарактеризовать вашей аллегорией, но у нас нативное приложение с серьезным функционалом и большими базами данных.
  • +10
    Самой большой заслугой своей команды мы считаем то, что все алгоритмы передачи, хранения, шифрования информации разработаны самостоятельно, без использования сторонних технологий.

    То есть главный принцип реализации криптографии успешно нарушен. Насколько ваши разработчики специалисты в этой области? Были ли эти алгоритмы проверены математическим сообществом?
    • 0
      без использования сторонних технологий


      Рискну предположить, что все таки имплементированы, а не разработаны.
      • +6
        К имплементированию «don't roll your own crypto» также относится в полной мере.
    • 0
      Согласен, меня это тоже резануло сначала, но потом забыл прокомментировать.
      И постоянно встают вопросы: зачем? для какой цели? Авторы постоянно противоречат сами себе: «у нас было мало ресурсов и поэтому… мы пошли по пути, требующему наибольших ресурсов и максимального набивания шишек». Зачем??
      • 0
        Код SSL смотрели, анализировали сотни человек не один год и только недавно обнаружили одну серьезную проблему безопасности. А сколько людей и как долго смотрели крипто-код этого проекта? Сколько там не обнаруженных проблем? И главное, зачем?? — если существующие библиотеки полностью открыты вместе с исходниками.
  • +1
    Принципы криптографии не были нарушены. Алгоритмы передачи и хранения разработаны своими силами, но в области шифрования мы действительно не стали изобретать велосипед и использовали стандартные и общеизвестные принципы шифрования с творческим подходом.
    Опыт работы в области шифрования есть, более того в команде есть математик, который и проверяет математически все разработанные алгоритмы. Думаю, что до конца августа мы сможем опубликовать отдельный пост, посвященный теме сжатия и шифрования и результатах наших последних экспериментов (только это не в рамках проекта Sphere Live).
  • 0
    Очень интересно про Firemonkey поподробнее. Производительность, платформы и т.п.

    С другой стороны, сам не раз неаступал на грабли с подходом — «пишем на том, что знаем». Вот с последним проектом решил сделать иначе. Сел писать мобильное приложение под Андроид на родном ADT, хотя ни разу прежде этого не делал. Альтернативой было писать под андроид на Qt который я хорошо знаю.
    Понадобился всего где-то месяц чтобы не лазить за каждым вопросом в мануалы. Через 3 месяца понял что решение писать на Java было верным. Имея многолетний опыть разработки на разных языках, освоить еще один не так уж сложно.
    • 0
      По поддерживаемым платформам Вам все же лучше обратиться к «первоисточнику»
      docwiki.embarcadero.com/RADStudio/XE6/en/FireMonkey_Platform_Prerequisites

      По производительности — последняя версия RAD Studio XE6 существенно отличается от предыдущих и показывает хорошие результаты производительности. Вы можете загрузить наше приложение, «покрутить» его и убедиться, что имея большое количество элементов оно достаточно шустрое в плане работы интерфейса.
      Есть нюансы, но они касаются не самой FMX, а отсутствия реализации некоторых библиотек непосредственно под Firemonkey. Мы занимаемся вопросами расширения Firemonkey в рамках нашего проекта по мере необходимости. Реально писать обертки модулей для достижения нужного результата, тем-более что Вы владеете и Java и так положительно относитесь к изучению всего нового.
      С удовольствием ответим на Ваши вопросы, и возможно что-то сможем порекомендовать для ознакомления.
  • +4
    Слишком маркетинговый пост, ноль контента по теме. Общий фразы, и всем известные проблемы на паблик.
    Все кому станет интересен наш опыт разработки на Delphi или сам проект, пишите в личку
    А для чего вам тогда хаб компании, черт побери?!

    Про то, что FMX имеет массу недостатков, мы читаем уже не первый год. С тех пор, как я впервые укололся FMX и посмотрел на конкурентов (QML, к примеру), ничего особо не изменилось. Мне жаль инструмент, на котором отработал более 10 лет. Delphi безнадежно отстал и «попытки догнать» сейчас выглядят просто глупо, т.к. явно выбрано не то направление и не те проблемы были закрыты в первую очередь. Не мог не высказаться, наболело.
  • 0
    Ссылки на сайт сделаны с той самой целью, чтобы как раз опровергнуть теорию «об отсталом языке программирования Delphi» не сухой информацией и перечислением преимуществ, а реальным продуктом, который написан на этом языке. Чтобы каждый, кому данная тема интересна, мог самостоятельно протестировать то, что мы сделали.
    Нас интересует мнение профессионального разработчика-пользователя о нашей программе, которое мы можем получить здесь. Также мы можем поделиться действительно ценной информацией, т.к. нами написано достаточное количество компонентов, которые в первую очередь могут оказаться полезными для разработчиков на Delpi. В следующих постах будут подробно описаны и компоненты и исправленные баги.
    Хаб компании — само словосочетание несет в себе маркетинговую подоплеку.
    • 0
      Меня как разработчика-пользователя жутко бесит на сайте всплывающее на весь экран огромное окно, которое даже непонятно как закрыть.
      • +1
        Окно то закрыть можно, просто кликнув в пустое место за его пределами — но вернувшись обратно на главную страницу, оно появится вновь. И вновь. И вновь.
        Но ладно это — намного большее отвращение вызывают картинки из бесплатных клипартов со счастливыми лицами людей, не имеющих никакого отношения к тематике сайта (как то — ребенок, подружки, бородатый мужик в бассейне и т.д.) — считаю это просто наплевательством на посетителей сайта и однозначно показывает уровень что сайта, что того, что на нем продается. Я бы не купил, даже после того как все это будет поправлено — просто потому что я знаю, как мыслят те люди, кто так делает.

        • 0
          Мы обязательно учтем все рекомендации. Но согласитесь, оставить голый текст — это тоже не лучший вариант.
          И если вы считаете, что между сайтом и приложением есть линейная зависимость, то, мне кажется, что вы живете в «стране чудес», где абсолютное большинство руководителей IT проектов утверждают, что линейная зависимость есть между количеством разработчиков и сроком реализации, или увеличение бюджета проекта неминуемо приведет к сокращению сроков на его реализацию…
          Покупать ничего не нужно, приложение бесплатно.
          • +1
            Отвечу, дабы меня не поняли не так. Мы в 2014-ом году, конкуренция огромная, пользователи (а тем более, гики) насытились и могут за 100м отличить качественный продукт от поделки. И Продукт начинается (как в той поговоре — «встречают по одежке») с Сайта, с буклета, с е-мейл рассылки и т.д. И если сделать супер-продукт, но прислать письмо с кракозябрами — думаю, вы поняли… Извиняюсь за «я бы не купил», при том что продукт бесплатный — я лишь хотел показать, что такие ляпы отпугивают сильнее, чем баги внутри самого продукта. Я ни в коем случае не хочу занизить вашу работу — прочитал статью с большим интересом, тем более что связан (к сожалению) с продуктами на Дельфи по работе — но любой, кто хоть чуточку был связан в жизни с web'ом, бесплатные картинки «со счастливыми людьми» видит издалека. А это в большинстве случаев означает, что сайт делала не студия (которая включила бы создание уникального графисеского контента в стоимость работ), а кто-то из программеров, взяв за основу Wordpress/Drupal/Bitrix и натянув на него шаблон с Template Monster за 20 EUR… Это не плохо в общем случае, просто подойти к вопросу стоит чуточку ответственнее. Я тут особо не подскажу — лишь выражаю мнение как потребителя/читателя этого сайта, только и всего.
            • 0
              Спасибо за конструктивную критику. К релизу нашего приложения мы готовим обновленную версию сайта, в которой постараемся полностью избавиться от «всех раздражающих и вызывающих отторжение» элементов у пользователя.
              • 0
                На здоровье.
                Я бы вам посоветовал вот что – все что мы тут вам понаписали (я и другие участники треда) – часть проблем, это лишь то, что «задело» каждого из нас. Но потенциально, вопросов намного больше и они охватывают существенно более широкий спектр проблем.
                Соответственно, не пожалейте денег (если, конечно, это возможно в вашей ситуации) – затяните пояса, выбейте бюджет, откажитесь может от каких-то второстепеннвых фич в самом приложении – ради качественного маркетинга. Кто знаает, может эта стратегия отобъет себя, и не раз. Узнать можно только попробовав. Т.е. я прдлагаю вам вложиться чуть больше в сайт, по возможности наняв специализированную компанию. На том же Хабре — достойных команд более чем достаточно, не говоря уже о прочем Рунете.

                В любом случае — успехов вам и спасибо за дискуссию.
    • +1
      Наличие продукта абсолютно ничего не говорит об «отсталости» либо «продвинутости» языка, на котором он написан.
      Можно ли было писать продукты без generics и родной поддержки unicode в элементах интерфейса?
      Можно, хотя отсталость налицо. В C++ и Java всё это было уже тысячу лет назад, а в Delphi появилось где-то в районе 2009, если не ошибаюсь.
      • 0
        Простите, может мы не до конца поняли, но что вы имеете в виду, рассуждая о «generics и родной поддержки unicode» с сылкой на Delphi 2009?
        Разве в нашем продукте вы где-то увидели отсутствие поддержки Unicode? Или вы о Delphi в целом?
        Борьба между «светом» и «тьмой» идет уже довольно давно и в каких-то ситуациях «свет» — это Delphi, а в иных — C++. Все зависит от поставленных задач и предпочтений разработчика. Поэтому развязывать на эту тему очередной спор просто нет смысла.
      • 0
        Простите, я может чего не понял, но каким образом тот факт, что поддержку unicode и generics в язык ввели в 2009-м году может говорить об отсталости его на текущем этапе? С тех времен много воды утекло и ребята из Embarcadero делают многое, что бы вернуть Delphi к жизни.
      • +1
        Напомните заодно в каком году в Java и C++ появились лямбда-выражения, которые в Delphi были «тысячу лет назад».
        Какие-то отдельные фичи не могут характеризовать язык как «отсталый» или «не отсталый». Это детский какой-то подход.
        • 0
          Анонимные функции появились в Delphi 2009, C++11 и Java 7 с лямбдами вышли позже.
          На «тысячу лет», тем не менее, не тянет.
          Какие-то отдельные фичи не могут характеризовать язык как «отсталый» или «не отсталый».
          Предложите свои критерии. Ну не по творчеству придворных мракетологов их сравнивать же.
          • 0
            > На «тысячу лет», тем не менее, не тянет.

            Дженерики тоже на «тысячу лет» не тянут, но вы почему-то возражаете не автору первоначального тезиса, а мне. Напомню, дженерики в Java — это конец 2004го года, а Delphi 2009 вышла в 2008м. Ну да, чуть поже, но на «тысячу лет» не похоже ведь?

            > Предложите свои критерии.

            Так ведь это не я делю языки на отсталые и не очень. Кто делит, те пусть и предлагают критерии.

            По-моему, это сугубо эмоциональный вопрос. Объективных критериев мы не найдем.
          • 0
            Причем непонятно зачем вообще это обсуждать, потому что главное ведь то, что сейчас эти фичи есть. Причем не первый год уже есть. Какой теперь смысл устраивать олимпиаду по истории и вспоминать когда что появилось? :)
  • +2
    … проект очень большой и сложный, значит необходимо было использовать именно тот язык и тот инструмент, который наиболее изучен и имеет серьезный потенциал развития...

    Мы потратили более года, чтобы разобраться в FMX (Firemonkey). Неоднократно «наступали на одни и те же грабли», не раз переписывали некоторые модули, работающие с GUI, мультимедиа и другие

    Мне кажется, что «язык и инструмент хорошо изучены» плохо сочетается с «мы потратили более года, чтобы разобраться». Может я чего-то не уловил при прочтении? Там пока действительно «статья-вступление», т.е., мало конкретики, больше обозначены тезисы.
    • +1
      Вы правильно подметили данное не сочетание.
      Однако мы говорим о языке Object Pascal (Delphi) и технологии Firemonkey. Это все же разные вещи. И когда мы говорили о языке и инструменте, мы имели виду Delphi. А FMX — это всего-лишь библиотека, с которой нам и пришлось разбираться.
      Именно на этом мы заострили внимание, что FMX был плохо документирован.
      Надеюсь — мы более понятно прокомментировали данный вопрос.
      Мы учтем все комментарии и в будущем постараемся более четко и детально излагать материал.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка