Жизнеспособность Ruby для кросс-платформенной разработки с помощью собственных наборов инструментов?

Question

Предположим, что я пишу коммерческую коммерческую программу с закрытым исходным кодом, которая должна была быть развернута в следующих ситуациях: приложение для Windows Desktop, встроенное в .Net, элемент управления ActiveX, плагин Windows Netscape, приложение для Mac Desktop, построенное на Cocoa, плагин Mac Netscape , Java-апплет, размещенный в браузере. Было бы жизнеспособным с точки зрения совместного использования кода писать мои модели и классы контроллеров в общих исходных файлах Ruby и использовать MacRuby, IronRuby и JRuby для интеграции в различные промежутки времени? Мои классы классов предположительно будут написаны для использования WPF в Windows, Cocoa на Mac и любого подходящего для Java (SWT?).

С моей точки зрения, самое главное здесь - долгосрочное обслуживание кодовой базы, и похоже, что Ruby близок к тому, чтобы быть языком первого класса на трех платформах, на которые я должен нацеливаться: .Net, Какао и Java, как любой язык. Я ошибаюсь в этом?

Во-вторых, важно избегать любых требований к вирусной лицензии на наш код. Я вижу, где JRuby выпускается под различными лицензиями; могу ли я предположить, что я могу распространять двоичные файлы, а лицензии не применяются к любым файлам Ruby, которые я пишу для собственного приложения (в отличие от модификаций их фреймворка).

Используется ли Ruby в любых известных настольных приложениях? Это было сделано раньше?

Answer 1

Хммм .... если вопрос: «Как создать поддерживаемый продукт с помощью Ruby и сделать его доступным для всех этих конечных точек (веб-сайт, рабочий стол и мобильный Java)?»

Тогда, по моему скромному мнению, использование рубина И три аромата (jRuby, IronRuby и MacRuby) приведут к еще большему количеству проблем с обслуживанием, чем нет. Вам нужно будет понять или хотя бы нанять опытных разработчиков на всех трех платформах, и вы потратили бы много времени на создание действительно абстрактного кода, если только вы не планируете использовать ruby ​​только для доступа к базе данных.

Возможно, вам лучше придерживаться одной из платформ (Java & jRuby - это, пожалуй, самый портативный вариант) и используя различные варианты упаковки для распространения продукта.

Answer 2

Возможно, хотя я бы немного насторожился в отношении подхода, который вы наметили: например, IronRuby еще не 1.0.

Ожидаете ли вы, что OS-специфическая работа выходит за пределы пользовательского интерфейса? Если нет, тогда я начну с рассмотрения WxRuby, который является (довольно тонкой) оберткой кросс-платформенной библиотеки WxWidgets. Не работайте слишком сильно, ища хорошую документацию об упаковке Ruby, btw - болезненный опыт научил меня смотреть пример кода, который на самом деле очень всеобъемлющий.

Другие специфичные для конкретной платформы вещи, вероятно, должны быть абстрагированы/заключены в оболочку за какой-то оберткой/фасадом/api/proxy (выберите свой шаблон).

Вы говорите «закрытый источник» - у вас есть стратегия для этого в контексте Ruby? Хотя есть хотя бы несколько инструментов (ruby2exe и RubyScript2exe), которые я видел, я не знаю, как на самом деле будет скрываться ваш Ruby-код. Должен ли он быть автономным, развернутым исполняемым файлом вообще или может быть основан на браузере? Это позволит решить все кросс-платформенные проблемы (хотя вместо этого вы можете запускать face-first в кросс-браузерные).

Там еще некоторое обсуждение (включая Python, который является еще одной альтернативой) в this SO question

Answer 3

было бы жизнеспособным с точки зрения совместного использования кода , чтобы написать свою модель и контроллер классов в общих рубин исходных файлов и использовать MacRuby, IronRuby и JRuby для интеграции в различных временных рядов?

Вы могли бы разделить код Ruby между тремя различными реализациями; все они очень совместимы с реализацией Ruby. Имейте в виду, что JRuby и IronRuby предназначены для Ruby 1.8.6, JRuby также начинает работать с 1.9 функциями, а MacRuby поддерживает только 1.9.

Вы должны были бы кусочки конкретной платформы, которые не разделяются между тремя реализациями, так как только JRuby может поговорить с SWT, IronRuby в WPF и т.д.

кажется, что Руби как можно ближе к будучи первым языком класса на три платформы, которые я должен предназначаться: .Net, какао и Java, как и любой язык

три реализации Рубин хорошо налаженной, поддерживаемого постоянно растущего сообщества, и при поддержке хорошо зарекомендовавшего себя компаньона эс. Хотя Ruby не является первичным языком на любой из платформ, ни одна из реализаций не имеет серьезных ограничений, которые делают использование Ruby невозможным, хотя для некоторых вещей вам может потребоваться небольшое количество C#/Java/Objective-C ,

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

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

Использовал ли Ruby в любых известных настольных приложениях ? Это было сделано раньше?

Я не знаю ни одного широко используемых приложений для настольных компьютеров, которые используют Ruby, но я знаю пару приложений, использующих IronPython на ОС Windows, таких как Blaze и Resolver One; их методы развертывания будут одинаковыми для IronRuby.