Pull to refresh

Comments 41

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Привет, можно ли узнать текущее состояние вашего проекта. Интересует все же техническая сторона, а конкретно использование FMX и отношение к этому фреймворку. Стал лучше/хуже, не разочарованы/разочарованы и т.д.
Можно просто комментарием, можно статьей)

Only those users with full accounts are able to leave comments. Log in, please.