Force.com, Apex, — как впечатления?
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Кто работал с Force.com и его Apex, — как ваши впечатления? Постоянный источник facepalm’ов или нормальная вменяемая платформа?
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Кто работал с Force.com и его Apex, — как ваши впечатления? Постоянный источник facepalm’ов или нормальная вменяемая платформа?
Мне, как программисту, программировавшему программы в течении 5 лет на таких языках программирования как C#, Java, PHP... Qt, ActionScript (Flex) (это были и Desktop, и мобильные, и веб программы) — очень нравится.
Что мне больше всего нравится — так это простота. Java я не люблю за её многотомные конфиг файлы. Пока все настроишь пройдет пол года. Сам синтаксис Java, как и у C#, мне нравится. Собсна, то, чего мне не хватало у C# и Java есть у Apex — простота системы. Залогинелся, создал пару обектов и логики к ним и у тебя готовое приложение.
Да, она под конкретные нужды — там прямым текстом и говорится, что если вам хранить гигабайты файлов, то вам не к нам. У системы есть свое предназначние, она решает свои задачи с лихвой.
На счет руклиц — нет банального switch ... case. Facepalm? Ну с какой-то стороны да — писать if else if else не всегда красиво. Хотя привыкаешь :-)
Очень простая IDE — плагин под Eclipse. Через раз работающий подсказывальщик возможных методов у объекта или класса. Никакой иерархии классов — ВСЕ классы в ОДНОЙ папке. Все. Досвидос :-)
Морда делается чем-то на подобии JSP. Файлик-разметка, в котором указан файл-класс с переменными и методами.
Есть продакшн, для которого делают песочницу, в которой все и разрабатывается. Песочница делается парой нажатий кнопочек (сам не делал, но мне говорили = ))) ). Ты в песочнице все наколбасил, оттестил и заливаешь обратно на прод. Песня. Никаких скриптов, ни антов/мавенов/шмавенов :-)
Сам язык Apex очень похож на Java.
Спасибо за подробный рассказ.
Никакой иерархии классов — ВСЕ классы в ОДНОЙ папке. Все.
Да, это уже похоже facepalm. Имеются в виду абсолютно любые классы, — и системные, библиотечные, и свои пользовательские классы? Или всё же они хоть как-то сгруппированы, по каким-либо namespace’ам?
Все-все, что ты можешь создать. Namespace есть. Но он предназначен для другого и по нему никак не группируется.
Да, первое время это было очень странно. Приходилось выдумывать специальное именование классов, чтоб это все выглядело более-менее симпатично.
Но это проблема только очень больших и сложных проектов, например, таких, в которые интегрируется другая система посредством API той внешней системы.
Все-все, что ты можешь создать.
А если там много пользователей, разворачивающих свои приложения, и каждый из них именует свои классы в едином пакете, то хотя бы эти наборы классов как-то друг от друга изолированы?
Или там 500 человек решили назвать класс одинаково, и кто первый, тот успел, остальные переименовывайте как хотите? :-)
Кто первый встал — того и тапки = ))
Может я на мелких проектах работал, но больше трех (может четырех) разработчиков я не встречал в одной песочнице.
Ну то есть для каждого account’а песочница своя, и у разные пользователи (команды, партнёры) между собой именами классов не сталкиваются.
А то это реально прошлый век был бы.
Ну то есть для каждого account’а песочница свояНет.
разные пользователи (команды, партнёры) между собой именами классов не сталкиваютсяСталкиваются.
Ну почему же прошлый век? А как трем разрабам пидалировать один и тот же проект. А еще тестеры, например.
Ну, например:
Есть клиент А, который разрабатывает и разворачивает какое-то своё приложение. И тут появляется клиент Б, и у него своё приложение, а там один из классов называется так же, как один из классов в приложении клиента А. Потом приходит клиент Ц со своим приложением, и там тоже какой-нибудь класс имеет совпадающее с чем-то имя. Ведь некоторые функции имеют очевидные имена, а значит, совпадения неизбежны.
Эти классы (разных клиентов, разных приложений) конфликтуют между собой?
Если в пределах одного приложения классы имеют одно единое пространство имён, то это не страшно, но если бы в Apex ВСЁ было глобально, все существующие классы в одном глобальном пакете, то это было бы бред, это уже 40-50-е года прошлого века, когда в мире всего дюжина-другая небольших приложений, и одного глобального пространства имён на ВСЕХ вполне хватало. Это ведь не так?
У каждого клиента свой окружение (environment). Каждый клиент создает песочницу лично для себя (ну или ему создают разработчики). Клиентам не интерестно использовать одно и тоже окружение друг с другом ибо не каждый желает делится своими знаниями и бизнес процессами. Ну и много других причин. И у каждого клиента могут быть классы с одинаковыми именами. И конечно же, они никак не будут пересекаться.
Смотрите на окружение, как на выделенный лично вам (клиенту) виртуальный сервер, на котором уже есть базовый функционал. Который, да, у ВСЕХ одинаков. Базовые классы. Методы работы со строками и так далее. Но надстраивать/расширять каждый волен как ему заблагорассудится.
Даже если такой клиент захочет свое гениально приложение продавать в магазине (AppExchange), то он будет придумывать ему пространство имен, которое уже должно быть уникально (хотя, это лично мои домыслы. Мне не доводилось сталкиваться с магазином).
Нормальная система. Работать можно.
Приватные сообщения приходят в виде писем на почту, указанную в вашем профиле на ДОУ.
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів