Жизнеспособность Ruby для кроссплатформенной разработки с нативными инструментами? - PullRequest
3 голосов
/ 19 ноября 2009

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

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

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

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

Ответы [ 3 ]

2 голосов
/ 19 ноября 2009

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

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

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

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

Есть еще несколько дискуссий (включая Python, который является другой альтернативой) в этом вопросе SO

2 голосов
/ 29 декабря 2009

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

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

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

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

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

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

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

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

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

2 голосов
/ 19 ноября 2009

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

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

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

...