Comments 24
IronRuby, Rake, Albacore и существенные затраты ресурсов на изучение возможностей сих инструментов просто ради того, чтобы отказаться от XML? Мы же не придумываем колесо с целью его придумывания?… Да, возможно XML действительно не наилучшая из альтернатив, но лично я никаких преимуществ в описанном выше способе для себя не разглядел.
Пару выходных- это по-вашему значительные? Там все просто.
Да, но ради чего все это? Простота — относительное понятие: кому-то проще описать архитектуру билда с помощью XML.
А Вы, как я вижу, апологет описанного метода. Так какие же значительные плюсы видите лично Вы?
А Вы, как я вижу, апологет описанного метода. Так какие же значительные плюсы видите лично Вы?
Как вы и написали: каждому свое. Архитектору проще мыслить структурами, а кодеру алгоритмами. Лично мне прочитать чужой скрипт куда проще, чем объемный XML перелопатать. И все-таки на мой взгляд освоить локаничный синтаксис скриптового фреймворка проще кодера. Со скриптом кодер решает задачу сборки также, кок он реализовывал подобные действия для разрабатываемого приложения.
Структуры и алгоритмы — это две стороны одной медали. Как бы ни пафосно это звучало, вы так и останетесь «кодером», пока этого не поймете.
Замечание о том, что из за XML мы, видите ли, лишаемся отладчика меня вообще убило, чего там отлаживать-то?
И, в завершение, конструктивная критика: мне не думается, что достаточно большому обьему IT-специалистов покажется проще, что даже структура их проекта имеет control flow. Давайте теперь вместо написания программы будем писать скрипты для ее сборки и интерпритаторы, которые будут по ним генерить view (это намек на MVC, ведь структура проекта — это же просто папка с файлами, классическое model).
Замечание о том, что из за XML мы, видите ли, лишаемся отладчика меня вообще убило, чего там отлаживать-то?
И, в завершение, конструктивная критика: мне не думается, что достаточно большому обьему IT-специалистов покажется проще, что даже структура их проекта имеет control flow. Давайте теперь вместо написания программы будем писать скрипты для ее сборки и интерпритаторы, которые будут по ним генерить view (это намек на MVC, ведь структура проекта — это же просто папка с файлами, классическое model).
Как-то мысль не завершена получилась. Давайте возьмем как пример MSVS, которое имеет как язык для файлов проектов что-то такое декларативное. Откроем проект, и увидим в соответствующей вкладке структуру проекта: дерево папок и так далее. А теперь представим, что язык не декларативный: скрипт же еще и интерпритировать надо! А если там будут побочные эффекты? Не получится ленивой инициализации, придется постоянно перепроверять, не изменилось ли чего. Да что там, даже сама сборка потенциально может что-то изменить!
Лишнее это все, я не стою, конечно, горой за XML, но мне видится декларативный язык идеальным для описания структуры проекта.
Лишнее это все, я не стою, конечно, горой за XML, но мне видится декларативный язык идеальным для описания структуры проекта.
Ну это вы уже утрируете. Я тоже могу ответить, что опечатавшись в XML, ошибку я найду с бОльшим трудом, нежели выполнив скрипт. Интерпретатор мне сразу выведет номер строки, где я налажал. Этот аргумент для вас не будет существенным, полагаю.
> Замечание о том, что из за XML мы, видите ли, лишаемся отладчика меня вообще убило
Я тоже не считаю, что в билд-скрипте будет что отлаживать с точки зрения классического дебага, когда надо по текущему состоянию филдов прогуляться и прочее. Но ведь отлаживать можно и сам флоу сборки.
К этому же и следующее
> А если там будут побочные эффекты? Не получится ленивой инициализации, придется постоянно перепроверять, не изменилось ли чего.
Тоже притянуто. В скрипте сборки, в том виде как его описывал автор, просто нет мест для сайд-эффектов и прочих серьезных вещей типа потокобезопасности, локов и т.д.
> мне видится декларативный язык идеальным для описания структуры проекта.
Так ведь XML-описатель структуры проекта никуда не девается. Скриптом описывается именно процедура сборки. Та, в свою очередь, как раз и представляет собой некий «FLOW».
> Замечание о том, что из за XML мы, видите ли, лишаемся отладчика меня вообще убило
Я тоже не считаю, что в билд-скрипте будет что отлаживать с точки зрения классического дебага, когда надо по текущему состоянию филдов прогуляться и прочее. Но ведь отлаживать можно и сам флоу сборки.
К этому же и следующее
> А если там будут побочные эффекты? Не получится ленивой инициализации, придется постоянно перепроверять, не изменилось ли чего.
Тоже притянуто. В скрипте сборки, в том виде как его описывал автор, просто нет мест для сайд-эффектов и прочих серьезных вещей типа потокобезопасности, локов и т.д.
> мне видится декларативный язык идеальным для описания структуры проекта.
Так ведь XML-описатель структуры проекта никуда не девается. Скриптом описывается именно процедура сборки. Та, в свою очередь, как раз и представляет собой некий «FLOW».
Вы как-то забываете, что перед XML-сборщиками был make, который в принципе тоже описывает flow.
Да и если эволюцию xml-сборки проследить, то например у той же MSVS раньше проекты были чисто декларативными, т.е. набор свойств и набор файлов и все. А вот уже у последней студии это именно описание flow сборки.
Да и если эволюцию xml-сборки проследить, то например у той же MSVS раньше проекты были чисто декларативными, т.е. набор свойств и набор файлов и все. А вот уже у последней студии это именно описание flow сборки.
У сборщиков на XML ограниченный набор готовых рецептов. Шаг в сторону — и иди пиши свой плагин, ваяй дополнительный скрипт или т.п. Т.е. удобно до тех пор, пока не упрешься в то, что не так просто реализовать на стандартных XML тасках.
А тут полная сила целого языка общего назначения прямо из коробки. Мне лично такой вариант кажется более удобным.
А тут полная сила целого языка общего назначения прямо из коробки. Мне лично такой вариант кажется более удобным.
Весомый аргумент. Только как часто воспроизводится описанный Вами случай? Я, к примеру, неоднократно сталкивался с проблемой недостаточности средств, предоставляемых Ant/Maven, пока не уяснил назначение утилит для сборки проектов. Я, все-таки, твердо уверен в том, что функционал утилиты должен соответствовать заданию, которое она призвана решать.
Ну я, например, пытался добавить ресурс с версией программы, содержащий номер ревизии из которой была осуществлена сборка. Программы на C++ под Windows, если ресурса VERSION_INFO нет, то его необходимо добавить. Если есть, то обновить номер версии.
Чтобы это реализовать на NAnt, пришлось писать отдельный скрипт на другом языке и выполнять его из NAnt. Скажите не сборочная задача?
Чтобы это реализовать на NAnt, пришлось писать отдельный скрипт на другом языке и выполнять его из NAnt. Скажите не сборочная задача?
XML хорош, но в меру. Он избыточен, поэтому сложно читать объемные конфиги — тупо потому, что там многабукаф.
JSON, YAML читаются намного легче за счет визуальной разгрузки читаемой области (лесенки читать комфортней, чем «прямоугольники» текста)
pro: А возможность расширить конфигу ЯПом — при грамотном подходе эффективность повышается.
contra: Впрочем, «многие знания преумножают многие печали» — если тот же XML жестко ограничен своей схемой, то одна и та же DSL конфига может быть написана как хорошо, так и еще хуже.
JSON, YAML читаются намного легче за счет визуальной разгрузки читаемой области (лесенки читать комфортней, чем «прямоугольники» текста)
pro: А возможность расширить конфигу ЯПом — при грамотном подходе эффективность повышается.
contra: Впрочем, «многие знания преумножают многие печали» — если тот же XML жестко ограничен своей схемой, то одна и та же DSL конфига может быть написана как хорошо, так и еще хуже.
> кому-то проще описать с помощью XML.
/sarcasm on
С трепетом вспоминаю плагины для первого мавена, написанные на теплом ламповом XML (язык Jelly).
Вот пример простого плагина: svn.apache.org/viewvc/maven/maven-1/plugins/trunk/clover/plugin.jelly?view=markup
/sarcasm on
С трепетом вспоминаю плагины для первого мавена, написанные на теплом ламповом XML (язык Jelly).
Вот пример простого плагина: svn.apache.org/viewvc/maven/maven-1/plugins/trunk/clover/plugin.jelly?view=markup
На вкус и цвет. Универсальной серебрянной пули нет, поэтому в каждой конкретной ситуации удобны определенные инструмента. Тот же ant на xml, например, интегрируется в билд-системы, или в IDE.
Как раз собирался перейти с Nant (собираю C++, как ни странно) на rake, правда нативный, а не IronRuby. И тут статья в тему. Спасибо.
Если Ruby заменить на Groovy получится Gradle, здесь про него писали.
Если на Python, получится SCons
Или Waf, у него со скоростью на крупных проектах получше, а вот с комьюнити пока похуже.
Waf < — клик :)
Gradle хорош тем, что конфиги на Groovy являются DSL :)
В итоге имеем более краткую (по сравнению с избыточностью этого семейства языков — я про SGML-XML-HTML и др.) запись того же XML, сдобренную гибкостью самого ЯП.
Я только приветствую движение в сторону динамических языков типа JS (XML->JSON),Lua,Ruby,Groovy и Python, а также такого рода DSL-конфигов :)
Ну и, к слову, CSS->Less.
В итоге имеем более краткую (по сравнению с избыточностью этого семейства языков — я про SGML-XML-HTML и др.) запись того же XML, сдобренную гибкостью самого ЯП.
Я только приветствую движение в сторону динамических языков типа JS (XML->JSON),Lua,Ruby,Groovy и Python, а также такого рода DSL-конфигов :)
Ну и, к слову, CSS->Less.
А вообще, подумалось, какие анекдотичные могут быть ситуации:
«Хелп, у меня проект не собирается — конфига ушла в вечный цикл \ переполнение стека! Помогите найти ошибку!» — т.е. до сборки еще и дело не дошло, а уже IT-проблемы :)
«Хелп, у меня проект не собирается — конфига ушла в вечный цикл \ переполнение стека! Помогите найти ошибку!» — т.е. до сборки еще и дело не дошло, а уже IT-проблемы :)
А мой Maven-проект любой программист нашей фирмы просто открывает в IDE и начинает с ним работу. Все модули, зависимости и прочее — уже подхвачены. Потому что Maven универсален. Вот вы свои таски назвали по своему, другой — по своему. И сиди потом, втыкай в просто написанный код, что там надо вызвать и как.
Я по этой причине даже с ant-а ушёл, тбо интеграция с IDE подкупает.
А вот Rake — приходилось как то в SocialQuantum работать, у них всё rake-ом собиралось… Одно рабочее место настраивалось дня 3-4, и дикие по объёму мануалы по установке всего этого дела.
Всё, что не решается легко через Maven-плагины — делаю через antrun или groovy, пока что все счастливы:)
Я по этой причине даже с ant-а ушёл, тбо интеграция с IDE подкупает.
А вот Rake — приходилось как то в SocialQuantum работать, у них всё rake-ом собиралось… Одно рабочее место настраивалось дня 3-4, и дикие по объёму мануалы по установке всего этого дела.
Всё, что не решается легко через Maven-плагины — делаю через antrun или groovy, пока что все счастливы:)
Рекомендую посмотреть на утилиту psake. Написана на Powershell, очень похожа на Rake. И все же ближе к .NET.
Sign up to leave a comment.
Прощай XML-build… Здравствуй Rake!