Простите за сарказм.
Я лишь искренне не понимаю, зачем вы так бездарно расходуете свой талант.
Ваша программа открывает такие возможности, а вы хотите раздавать её, тем более бесплатно, всяким бездельнкам? Заработайте сами с её помощью миллионы, и после этого, если есть желание помогать другим, спонсируйте детские дома, школы, университеты, больницы, обустройте прилегающий к вашему дому район — вариантов так много…
А бесплатная брошюрка на тему «как заработать свой первый милилон на форексе?» к вашей программе не прилагается? Или, что ещё лучше, видеокурс скачать онлайн бесплатно без регистрации и смс?
> Перегрузка метода
Имхо тут проблема не в самом руби, а том, что вы хотите программировать на нём, как на си/яве/шарпе.
Уврен, этого никогда не сделают, и не только потому, что в руби2 обещают ввести именованные аргументы фукцииям, но и потому, что ваш пример использования перегрузки сам по себе является примером дурного кода.
if arg.is_a? String
'string version ' + arg.to_s
elsif args.is_a? Array
'array version ' + arg.to_s
elsif args.is_a? Numeric
'numeric version ' + arg.to_s
end
Вернее конечно в совсем тривиальных случаях, с логикой в одну-две строчки, подобный подход имет право на жизнь, но во всех остальных ситуациях следует доработать иерархию классов и использовать полиморфизм. (кстати, не рекомендуют использовать is_a?, а вместо применять kind_of?)
Ещё одна причина в том, что логика работы самого руби проста как доска, и для любого идентификатора действуют лишь два правила:
1. Это локальная переменная
2. Если это не локальная переменная, то это вызов фунции из self.
Ну а при вызове ф-ии, ф-ия ищется в синглетон классе, в текущем классе, а затем по всем ancestors, после чего идёт вызов method_missing.
И усложнять эту логику ради ситуаций, нарушающих принцип «не спрашивай меня, кто я, а говори мне, что делать»… зачем?
> Отобразить хэш и получить из него другой хэш, а не массив
Вот тут соглашусь, inject не всегда удобно использовать.
> Преобразовать экземпляр класса в экземпляр его же собственного подкласса
Мне кажется, всё дело опять в коде, нарушающем принцип «не спрашивай меня, кто я, а говори мне, что делать».
Ведь и сейчас рабочих вариантов для подобной ситуации достаточно.
Можно не наследовать Bird от Animal, а делегировать.
Можно нужный функционал Bird вынести в модуль и полученное от Animal.get_flying_animal расширить этим модулем.
Можно манкипатчнуть сам Animal, чтобы он возвращал сразу нужное.
Или писать код так, чтобы ему всё равно было, что там Animal или Bird или что-то другое.
Вариант с заменой x.class при попытке реализации в язык, весьма вероятно, вызовет очень много побочных эффектов, которые сходу даже предположить сложно.
> Метод Object#in?(collection)
В активсуппорте много всяких вкусностей, и всем нравятся разные. Тогда уж сразу весь гем в стандартную библиотеку, чтобы никому не было обидно.
Хотя опять зачем? Можно просто подключить этот гем в ваш проект :)
> Отрицательная форма вопросительных методов
if !arr.empty? -> if arr.any? -> unless arr.empty?
if !a.nil? -> if a -> unless a.nil?
Плюс .blank? ещё в активсуппорте
> Отрезаем расширения файлов
По-моему это тоже есть, толи какой-то класс, толи метод в одном классов. Не помню, кажется где-то видел и даже использовал.
Хороший пример. К чёрту вендор префиксы и откат на яваскрипт для всех, у кого не работает.
30% пользователей оперы, 5% эксплорера и 2% старого фаерфокса сами виноваты, что не пользуются браузером верстальщика.
Есть потрясающий(для меня точно) доклад от Yehuda Katz «Why ruby isn't python» с конференции RuPy blip.tv/rupy-strongly-dynamic-conference/yehuda-katz-tradeoffs-and-choices-why-ruby-isn-t-python-5726460
где он рассказывает о некоторых принципах, лежащих в основе ruby, почему оно всё работает именно так как есть, сравнивая с аналогичными вещами в python, и почему некоторые концепции в других языках с точки зрения рубиста 'сломаны'
> Т.е. в руби вы в строку впихиваете ещё и исполняемый код? Как-то мне это смешение не очень нравится.
Есть два вида синтаксиса.
Можно вставлять выражения напрямую в строки: «some text #{some_ruby_expression}»
Можно использовать аналог format: «some text %s» % string_expression или «some text %s %f» % [string_expression, float_expression]
На практике если надо вставить всего одну переменную или какое-то простое выражение, то часто используют первый вариант, в более же сложных ситуациях — второй.
Благодаря наличию удобных фреймворков и различных библиотек тот или иной язык может быть удобен для разработки определённых вещей.
И в области математических задач или написания гуевых приложений руби как раз блистать не будет.
Но если вы возьмёте область веба, то всё будет ровно наоборот.
Про переход ruby на 1.9. Он всё-таки можно сказать уже завершен.
Старые проекты могут ещё крутиться на 1.8.7, но все новые гемы пишут под работу с 1.9, некоторые даже начинают дропать совместимость с 1.8, те же рельсы 4е, да и другие гемы тоже, плюс ree выпуск новых релизов сворачивают в пользу mri 1.9.
Соответственно всё, что вы записываете в минус из-за поддержки только в 1.9 для начинающих новые проекты таковым уже не будет.
Плюс если вы уж сравниваете переходы на новые версии, сравните заодно уже близкую миграцию python на 3.0 Тут всё на порядок или два печальнее.
IE6 сколько уже лет хоронят, а он всё никак до конца не умрёт. XP с IE 8 будет умирать ещё дольше.
Что же до реализации, то с современными темпами развития стоит вебкиту или геко ввести поддержку этого черновика, остальные за скорее всего за месяцы подтяутся.
«Чтобы быстрее разобраться с тем, как работает Grid Layout, давайте сразу же начнем с ...»
Предлагаю начать с того, что у пользователей IE в Windows Vista и Windows XP всё это никогда не будет работать, и на этом, собственно, можно закончить статью.
Для интересующихся темой ещё можно почитать книгу на английском Programming Collective Intelligence, там одна из глав посвящена составлению рекомендаций — Collaborative Filtering.
Никто и не утверждает, что возможность запустить рельсы под виндовсами это плохо. Это наоборот прекрасно и полезно для комьюнити, что пользователи windows сейчас имеют возможность в пару кликов развернуть у себя часть rails стека.
Вам лишь говорят, что ваше заявление о пригодности windows для серьезной работы с rails мягко говоря спорно.
Давайте немного прикинем какие могут возникнуть проблемы:
Часть гемов не будут работать вообще или лишь в определённых ситуациях. Ну и ладно, дурацкие гемы, кому они сдались?
Вимом мы не пользуемся, а если и пользуемся, то обходимся базовым функционалом — плагины, работающие лишь в линуксе с маком, все равно бесполезны.
Guard для тестов… хотя погуглил, за последний год похоже починили.
Цветное оформление логов, рспека и прочего в консольке будет? От сплошного одноцветного текста в глазах рябит.
Наверняка с картинками придётся иметь дело, RMagick и ему подобные в windows нормально и стабильно работают? (с учётом того, что оно и в линуксах порой валится)
rvm? хотя для виндовса есть какая-то другая тулза.
Прощай капистрано — нынче деплоят руками или самописными тулзами.
Мониторинг работоспособности? newrelic говорят о «limited support of Windows XP & Vista».
Выполнять таски через интервалы времени нам не понадобится, так что без whenever вполне обойдёмся, ну или на крайний случай в дефолтный виндовсовский планировщик всё руками засунем.
Delayed_job, пишут, тоже прекрасно работает — нам не трудно запустить несколько консолей и стартануть в них по воркеру.
Для базы данных(или MSSQL будет?), nginx, мемкеша/редиса на продакшене отдельный сервер с линуксом найдём.
Ну и пожалуй ещё миллион всяких мелочей и неприятностей, о которых даже и не догадаешься, пока с ними не столкнёшься.
А так, да, windows — вполне удобная и зрелая платформа для rails.
Сам руби может быть и будет работать с сопоставимой скоростью, но скорость работы и потребление памяти, это как раз то, за что уже очень долго критикуют руби с рельсами, а они продолжают набирать популярность вопреки этому.
Есть другая, не менее важная составляющая, как выразились выше, экосистема. И надеюсь вы шутите, говоря, что виндовс — хорошая платформа для RoR. Просто не счесть сколько всего у вас работать не будет вообще или будет работать «не совсем и чуть-чуть не так, как в линуксе».
Основная на мой взгляд пробелма с ExtJS состоит в его идеологии, а именно в попытке дать инструмент создания полноценных десктопных приложений, но в броузере. Нам дают мощный инструмент, используя который по определённым правилам мы можем быстро и легко программировать сложные интерфейсы(даже в специальных полувизуальных редакторах) и логику к ним. Вот только вся соль в 'определённых правилах'.
Рано или поздно ваши потребности начинают превышать возможности фреймворка и тогда приходит Беда. С большой буквы. Чтобы сделать что-то, не предусмотренное фреймворком, нужны либо костыли, либо громоздкие настройки над существующими компонентами, причём на создание их времени в любом случае уйдёт в разы больше, чем если бы вы вообще не использовали Ext.
Затем кастомизация. Хотите подружить Ext с вашим красивым сайтом? Пожалуйста, вот вам дефолтная синяя тема, вот вам серая тема, и вот ещё несколько каких-то других. Хотите больше изменений, другую вёрстку, другие палитры или ещё чего-то — легко, делайте сами, но помните про Беду.
Далее, периодически выходят новые версии. Иногда они ничего не ломают, и обновление проходит глано, но чаще ломают, и чем больше у вас кода на Ext, тем больше придётся переделывать и допиливать при апгрейде.
Так же есть баги. Они есть в текущей версии. Просто в текущей, не важно какая там сейчас. Многие из багов заботливо изложены на форуме и превратились почти что в фичи, хоть некоторые из них могут и пофиксить быстро, но некоторые будут висеть(точнее не будут, а уже висят) годами. Придётся фиксить самим, но в исходники лезть — нини. Тронете — забудьте об обновлениях. Тогда следуем совету из данного топика, наш выбор — копипастить компоненты в кастомные со всеми потрохами. Которые с каким-нибудь релизом обязательно изменятся и всё опять поломается.
Про мдленную работу Ext и упоминать не буду — это извечная тема, о которой только ленивый не писал.
Впрочем, если вы не планируете обновляться и пишете только CRM, да ERP, с которыми никто, кроме ваших коллег или сотрудников заказчика, работать не будут, а так же если вы готовы инвестировать своё время в изучение технологий, которые для других вещей в вебе подходят не очень, то почему бы и нет — работать Ext будет и будет достаточно хорошо. Находясь в рамках заданных правил программировать на нём можно достаточно быстро.
По сути оба проекта делают одно и тоже и фундаментальных различий не имеют.
Самый главный аргумент в сторону LESS — парсинг стилей яваскриптом непосредственно в броузере пользователя, имхо вещь весьма сомнительная — ведь мало кто захочет замедлять скорость отклика страницы пользователя ради вещей, которые можно получить и другим путём.
А вот больший функционал SASS аргумент более весомый, и пусть что-то из этого функционала вам сейчас не нужно, но потенциально вы сможете с SASS сделать больше. Плюс на выбор синтаксис со скобками или синтаксис с отступами — очень серьёзный довод для тех, кто используют питон или пишут шаблоны на HAML/Slim.
И самый последний аргумент — Rails 3.1 с SASS по дефолту. Имхо это для многих не определивщихся, или только желающих попробовать, положит конец эпопеи LESS vs SASS.
Удачи вам, хотя и не знаю на кого рассчитан ваш проект. У гитхаба для маленьких команд цены на закрытые репозитории более чем приемлимые, а сэкономить несколько $ и лишиться всех гитхабовских плюшек… тогда уж лучше пойти на unfuddle, там дают 1 закрытый репо бесплатно.
Я лишь искренне не понимаю, зачем вы так бездарно расходуете свой талант.
Ваша программа открывает такие возможности, а вы хотите раздавать её, тем более бесплатно, всяким бездельнкам? Заработайте сами с её помощью миллионы, и после этого, если есть желание помогать другим, спонсируйте детские дома, школы, университеты, больницы, обустройте прилегающий к вашему дому район — вариантов так много…
Имхо тут проблема не в самом руби, а том, что вы хотите программировать на нём, как на си/яве/шарпе.
Уврен, этого никогда не сделают, и не только потому, что в руби2 обещают ввести именованные аргументы фукцииям, но и потому, что ваш пример использования перегрузки сам по себе является примером дурного кода.
if arg.is_a? String
'string version ' + arg.to_s
elsif args.is_a? Array
'array version ' + arg.to_s
elsif args.is_a? Numeric
'numeric version ' + arg.to_s
end
Вернее конечно в совсем тривиальных случаях, с логикой в одну-две строчки, подобный подход имет право на жизнь, но во всех остальных ситуациях следует доработать иерархию классов и использовать полиморфизм. (кстати, не рекомендуют использовать is_a?, а вместо применять kind_of?)
Ещё одна причина в том, что логика работы самого руби проста как доска, и для любого идентификатора действуют лишь два правила:
1. Это локальная переменная
2. Если это не локальная переменная, то это вызов фунции из self.
Ну а при вызове ф-ии, ф-ия ищется в синглетон классе, в текущем классе, а затем по всем ancestors, после чего идёт вызов method_missing.
И усложнять эту логику ради ситуаций, нарушающих принцип «не спрашивай меня, кто я, а говори мне, что делать»… зачем?
> Отобразить хэш и получить из него другой хэш, а не массив
Вот тут соглашусь, inject не всегда удобно использовать.
> Преобразовать экземпляр класса в экземпляр его же собственного подкласса
Мне кажется, всё дело опять в коде, нарушающем принцип «не спрашивай меня, кто я, а говори мне, что делать».
Ведь и сейчас рабочих вариантов для подобной ситуации достаточно.
Можно не наследовать Bird от Animal, а делегировать.
Можно нужный функционал Bird вынести в модуль и полученное от Animal.get_flying_animal расширить этим модулем.
Можно манкипатчнуть сам Animal, чтобы он возвращал сразу нужное.
Или писать код так, чтобы ему всё равно было, что там Animal или Bird или что-то другое.
Вариант с заменой x.class при попытке реализации в язык, весьма вероятно, вызовет очень много побочных эффектов, которые сходу даже предположить сложно.
> Метод Object#in?(collection)
В активсуппорте много всяких вкусностей, и всем нравятся разные. Тогда уж сразу весь гем в стандартную библиотеку, чтобы никому не было обидно.
Хотя опять зачем? Можно просто подключить этот гем в ваш проект :)
> Отрицательная форма вопросительных методов
if !arr.empty? -> if arr.any? -> unless arr.empty?
if !a.nil? -> if a -> unless a.nil?
Плюс .blank? ещё в активсуппорте
> Отрезаем расширения файлов
По-моему это тоже есть, толи какой-то класс, толи метод в одном классов. Не помню, кажется где-то видел и даже использовал.
30% пользователей оперы, 5% эксплорера и 2% старого фаерфокса сами виноваты, что не пользуются браузером верстальщика.
blip.tv/rupy-strongly-dynamic-conference/yehuda-katz-tradeoffs-and-choices-why-ruby-isn-t-python-5726460
где он рассказывает о некоторых принципах, лежащих в основе ruby, почему оно всё работает именно так как есть, сравнивая с аналогичными вещами в python, и почему некоторые концепции в других языках с точки зрения рубиста 'сломаны'
Есть два вида синтаксиса.
Можно вставлять выражения напрямую в строки: «some text #{some_ruby_expression}»
Можно использовать аналог format: «some text %s» % string_expression или «some text %s %f» % [string_expression, float_expression]
На практике если надо вставить всего одну переменную или какое-то простое выражение, то часто используют первый вариант, в более же сложных ситуациях — второй.
И в области математических задач или написания гуевых приложений руби как раз блистать не будет.
Но если вы возьмёте область веба, то всё будет ровно наоборот.
Старые проекты могут ещё крутиться на 1.8.7, но все новые гемы пишут под работу с 1.9, некоторые даже начинают дропать совместимость с 1.8, те же рельсы 4е, да и другие гемы тоже, плюс ree выпуск новых релизов сворачивают в пользу mri 1.9.
Соответственно всё, что вы записываете в минус из-за поддержки только в 1.9 для начинающих новые проекты таковым уже не будет.
Плюс если вы уж сравниваете переходы на новые версии, сравните заодно уже близкую миграцию python на 3.0 Тут всё на порядок или два печальнее.
Что же до реализации, то с современными темпами развития стоит вебкиту или геко ввести поддержку этого черновика, остальные за скорее всего за месяцы подтяутся.
Предлагаю начать с того, что у пользователей IE в Windows Vista и Windows XP всё это никогда не будет работать, и на этом, собственно, можно закончить статью.
Вам лишь говорят, что ваше заявление о пригодности windows для серьезной работы с rails мягко говоря спорно.
Давайте немного прикинем какие могут возникнуть проблемы:
Часть гемов не будут работать вообще или лишь в определённых ситуациях. Ну и ладно, дурацкие гемы, кому они сдались?
Вимом мы не пользуемся, а если и пользуемся, то обходимся базовым функционалом — плагины, работающие лишь в линуксе с маком, все равно бесполезны.
Guard для тестов… хотя погуглил, за последний год похоже починили.
Цветное оформление логов, рспека и прочего в консольке будет? От сплошного одноцветного текста в глазах рябит.
Наверняка с картинками придётся иметь дело, RMagick и ему подобные в windows нормально и стабильно работают? (с учётом того, что оно и в линуксах порой валится)
rvm? хотя для виндовса есть какая-то другая тулза.
Прощай капистрано — нынче деплоят руками или самописными тулзами.
Мониторинг работоспособности? newrelic говорят о «limited support of Windows XP & Vista».
Выполнять таски через интервалы времени нам не понадобится, так что без whenever вполне обойдёмся, ну или на крайний случай в дефолтный виндовсовский планировщик всё руками засунем.
Delayed_job, пишут, тоже прекрасно работает — нам не трудно запустить несколько консолей и стартануть в них по воркеру.
Для базы данных(или MSSQL будет?), nginx, мемкеша/редиса на продакшене отдельный сервер с линуксом найдём.
Ну и пожалуй ещё миллион всяких мелочей и неприятностей, о которых даже и не догадаешься, пока с ними не столкнёшься.
А так, да, windows — вполне удобная и зрелая платформа для rails.
Есть другая, не менее важная составляющая, как выразились выше, экосистема. И надеюсь вы шутите, говоря, что виндовс — хорошая платформа для RoR. Просто не счесть сколько всего у вас работать не будет вообще или будет работать «не совсем и чуть-чуть не так, как в линуксе».
Рано или поздно ваши потребности начинают превышать возможности фреймворка и тогда приходит Беда. С большой буквы. Чтобы сделать что-то, не предусмотренное фреймворком, нужны либо костыли, либо громоздкие настройки над существующими компонентами, причём на создание их времени в любом случае уйдёт в разы больше, чем если бы вы вообще не использовали Ext.
Затем кастомизация. Хотите подружить Ext с вашим красивым сайтом? Пожалуйста, вот вам дефолтная синяя тема, вот вам серая тема, и вот ещё несколько каких-то других. Хотите больше изменений, другую вёрстку, другие палитры или ещё чего-то — легко, делайте сами, но помните про Беду.
Далее, периодически выходят новые версии. Иногда они ничего не ломают, и обновление проходит глано, но чаще ломают, и чем больше у вас кода на Ext, тем больше придётся переделывать и допиливать при апгрейде.
Так же есть баги. Они есть в текущей версии. Просто в текущей, не важно какая там сейчас. Многие из багов заботливо изложены на форуме и превратились почти что в фичи, хоть некоторые из них могут и пофиксить быстро, но некоторые будут висеть(точнее не будут, а уже висят) годами. Придётся фиксить самим, но в исходники лезть — нини. Тронете — забудьте об обновлениях. Тогда следуем совету из данного топика, наш выбор — копипастить компоненты в кастомные со всеми потрохами. Которые с каким-нибудь релизом обязательно изменятся и всё опять поломается.
Про мдленную работу Ext и упоминать не буду — это извечная тема, о которой только ленивый не писал.
Впрочем, если вы не планируете обновляться и пишете только CRM, да ERP, с которыми никто, кроме ваших коллег или сотрудников заказчика, работать не будут, а так же если вы готовы инвестировать своё время в изучение технологий, которые для других вещей в вебе подходят не очень, то почему бы и нет — работать Ext будет и будет достаточно хорошо. Находясь в рамках заданных правил программировать на нём можно достаточно быстро.
Самый главный аргумент в сторону LESS — парсинг стилей яваскриптом непосредственно в броузере пользователя, имхо вещь весьма сомнительная — ведь мало кто захочет замедлять скорость отклика страницы пользователя ради вещей, которые можно получить и другим путём.
А вот больший функционал SASS аргумент более весомый, и пусть что-то из этого функционала вам сейчас не нужно, но потенциально вы сможете с SASS сделать больше. Плюс на выбор синтаксис со скобками или синтаксис с отступами — очень серьёзный довод для тех, кто используют питон или пишут шаблоны на HAML/Slim.
И самый последний аргумент — Rails 3.1 с SASS по дефолту. Имхо это для многих не определивщихся, или только желающих попробовать, положит конец эпопеи LESS vs SASS.