Как стать автором
Обновить

Комментарии 76

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
О - ну что Вы коллега, несмотря на то, что jRuby 1.0 действительно почти полностью совместим с Ruby 1.8.6 и может работать почти со всеми Руби приложениями - JRuby ужасно медленный, медленнее раза в 2 чем стандартный Ruby.
НЛО прилетело и опубликовало эту надпись здесь
А - тогда О.К. - вполне возможно.
Но без включения JIT - я сам пробовал, и тесты говорят - сильно JRuby проигрывает.
Посмотрим что будет когда выйдет 1.9
НЛО прилетело и опубликовало эту надпись здесь
Странно - действительно оказывается JIT включен по умолчанию - ничего дополнительно делать не надо. Тоже jruby 1.0 - и заметно медленнее :(
НЛО прилетело и опубликовало эту надпись здесь
В декабре 2007 выйдет версия 1.9 с переписанным ядром. Альфа версия доступна уже сейчас - и на некоторых тестах есть увеличение производительности в 3-4 раза.
А можно ссылки на тесты 1.9 версии.
НЛО прилетело и опубликовало эту надпись здесь
Вот - вот. Еще чуть подождать - и будет интересно :)
А в 2008 выйдет 2.0 - говорят будет совсем хорошо.
НЛО прилетело и опубликовало эту надпись здесь
Не согласен с тем, что если за языком или технологией не стоит гигантской корпорации, то в ней нет уверенности.

Я бы сказал наоборот: очень опасно использовать подконтрольные кому-то технологии.

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

В случае же с подконтрольными технологиями, на примере .Net, всё может обернуться очень мрачно, если с Microsoft что-то случится, либо они захотят поменять лицензию своего продукта, либо примут какое-то техническое решение, которое пойдёт в разрез с мнением большинства программистов, которым придётся мириться с любыми прихотями «хозяина» своей технологии.

Я считаю, что тратить своё время и усилия на коммерческие, подконтрольные технологии бессмысленное и опасное занятие.

В случае же, если Ruby on Rails заглохнет и перестанет развиваться, это будет означать что технология перестала быть актуальной или же появилась более лучшая альтернатива. Мне кажется это вполне естественная смерть и не стоит ей противиться.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
У самого Ruby есть так же немело минусов: отсутствие garbage collection, threads, IO и спецификации.


Чего-чего??? 0_о Автоматический сборщик мусора, IO, независимая от платформы реализация многопоточности - все есть.

Вот нынче есть уже наверное с десяток реализаций, не совместимых с друг другом.


Не десяток, а только 3 - о которых вообще стоит говорить. И все 3 один реализуют один и тот же стандарт языка - и Руби приложения работают одинаково на всех трех.
НЛО прилетело и опубликовало эту надпись здесь
И чем же 1.8.6, YARV, JRuby допустим друг с другом не совместимы?
Спецификации нет - это конечно не совсем хорошо, но чем лично Вам (для примера) это мешает?

Как говорить - нормальная/не нормальная реализация многопоточности? Сейчас в Руби вообще другая модель реализации многопоточности - у которой есть как свои минусы, так и плюсы. Откуда Вы взяли "кучу проблем"? Причем в 1.9 будет и классическая модель многопоточности- на выбор.

А на счет
Именно из-за отсутствия нормальной многопоточности вы запускаете N-монгрелей, а не один и памяти он жрёт ого-го.

Жрет он может быть и ого-го - но все равно меньше чем Апач+FastCGI - так что тут вопрос - сравнивая работу этих двух серверов - какая реализация многопоточности лучше.
НЛО прилетело и опубликовало эту надпись здесь
Ну как минимум Limitations раздел на сайте jruby, а как максимум - неизвестно) спецификации то с тест-сьютом нет)

Ага - а вот некоторые С/С++ компиляторы тоже не на 100% друг с другом совместимы - как же ими пользоваться, в продакшене то? :)))
Если серьезно - спецификации нет - кому что то нужно - читает исходники на С как спецификацию. Остальные как то живут без этого.

Но сейчас проблемы общеизвестные есть, и это факт.

Еще раз - перечисление реальных общеизвестных проблем можно? Кроме "монгрель должен выглядить как томкат" :))

Реализация и та, и другая не очень - ждём монгрель2)


Вам не угодишь :) У Монгреля - плохая многопоточность, у Апача - еще хуже - но "другой многопоточности у нас для Вас нет"(с) :)

Вообще очередной(уже серьёзный) бум должен быть после Ruby 2, Rails 2 & JRuby/IronRuby(быстрые и совместимые). А пока что ждём и следим)


Вот тут почти со всем согласен - только не "ждём и следим" - а нормально живем с тем что есть, а с 1.9 заживем еще лучше.
НЛО прилетело и опубликовало эту надпись здесь
Вот вот - или еще для примера - возьмем SQL - тоже стандарт как то не особенно спасает :)

Я Вас видел в ror2ru :) Приветствую на Хабре :)
НЛО прилетело и опубликовало эту надпись здесь
Ну заходите еще :)

И еще можно примеры привести. ТО есть важна не спецификация сама по себе - а наличие единого центра, управляющего развитием языка - и у Руби с этим как раз проблем нет.
С 1.9 мы заживем шустро, но нестабильно. Испытательный полигон, dragons be here :)

http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9
http://www.rubyist.net/~matz/slides/rc2005/mgp00006.html
Да ну - вроде же 1.9 активно тестируют - пока как будто все нормально :)

А изменения - да, будет много интересного :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ох, не уверен я, что это правильная позиция - сокращать функциональность.
Не представляю, как вообще можно работать с вещью, с ограниченной функциональностью - когда собственные руки связаны чьим то мнением.
Неплохо было бы им вновь проанализировать проблематику и хорошенько обдумать - может существующий функционал следует изменить качественно, а не количественно...
Не сокращать функциональность - а повышают модульность :)
В Ruby on Rails приложении реализуется с помощью ядра + плагины.
Было принято решение некоторые функции из ядра переместить в плагины - но ни ни куда не пропадают и так же остаются доступными для разработчиков.
см. пример Firefox
Предпочитаю Python. Хотя бы потому, что интерпретатор быстрее и, в отличии от Ruby, правила не диктуются одним-единственным фреймворком (Rails), а существует конкуренция между несколькими решениями. Например, Django и Pylons. Да и сам Python как язык мне симпатичнее. Хотя это конечно дело вкуса.
Предпочитаю Python. Хотя бы потому, что интерпретатор быстрее и, в отличии от Ruby, правила не диктуются одним-единственным фреймворком (Rails), а существует конкуренция между несколькими решениями.

"Вот так и рождаются нездоровые сенсации" (с) :)))
Кроме Ruby on Rails (который совершенно не виноват что он такой популярный :)
еще есть Ruby web фреймворки
Nitro
Merb
Maveric
и еще несколько - в каких то вещах даже более интересных, чем Rails - как например Merb - который значительно быстрее чем Rails и т.д.
Спасибо. Всегда полезно узнать что-то новое. Тем не менее именно Rails занимает господствующее положение.
З.Ы. Да я и не утверждал, что других фреймворков для Ruby нет (=
Rails занимает господствующее положение - но ни кто ни кому ни каких правил не диктует - все по желанию - хочешь - используешь RoR, хочешь - Merb, а хочешь - пишешь web сайт вообще без фреимворков :)

А Python - замечательный язык. Для промышленных и бизнес приложений - самое то, особенно учитывая умопомрачительное количество питоновских библиотек на все случаи жизни. А на счет Django - не знаю :)
Разумеется никто не диктует правил программисту, но вот разработчики веб-фреймворков оглядываются в сторону Rails. И если не дай бог что-то будет сделано не так "как в Ruby" поднимется жуткая шумиха.
Django кошерно ) Особенно если посмотреть на проекты, её использующие. Недавно Иван Сагалаев в своем блоге http://softwaremaniacs.org рассказал что Django и в Яndex любят )
Разумеется никто не диктует правил программисту, но вот разработчики веб-фреймворков оглядываются в сторону Rails. И если не дай бог что-то будет сделано не так "как в Ruby" поднимется жуткая шумиха.

Вы не совсем правы - как раз все мною перечисленные фреимворки сделаны совершенно подругому, и очень отличаются от Rails.
Другие фреимворки - как например PHP-шные - CakePHP, Symphony, CodeIgniter - их тоже можно понять - они ориентируются на лучшего из племени :) - это вполне понятно и объяснимо.
Django кошерно ) Особенно если посмотреть на проекты, её использующие.

Вот мне не удалось найти больших проектов, использующих Django :(- хотелось бы посмотреть на серьезном примере :(
Недавно Иван Сагалаев в своем блоге http://softwaremaniacs.org рассказал что Django и в Яndex любят )

Ага - читал, смотрел презентацию на RuTUBE - пример как то не убедил :) Совершенно не серьезная разработка - вот написал бы Яндекс свои блоги на Django - это был бы показатель, да :)
Самый известный сейчас, наверное, Pownce.
О - спасибо. Вот такие большие проекты на Django я как раз и хотел посмотреть.
НЛО прилетело и опубликовало эту надпись здесь
:) А меня как то эта учесть миновала :)

В чем граби? API запутанный?
НЛО прилетело и опубликовало эту надпись здесь
Значит мне повезло, что не пришлось туда залазить :)
С другой стороны очень большой плюс- сколько в питоне уже готовых хороших библиотек - к сожалению у Руби даже близко такого нет :( Как пример - нужна была мне библиотека для рисования графиков - у питона есть Matplotlib, Kiva, Chaco - и еще, которые я не смотрел. А что есть у нас? Gruff Graphs - совсем не равноценная альтернатива :(
НЛО прилетело и опубликовало эту надпись здесь
Да это понятно ;) И я тогда эту проблему решил - тем более что перечисленные питоновские графические библиотеки работали как wrapper-ы для С++ библиотек :)
Но скажем так - некоторая скорость разработки была потеряна - и если бы готовое решение уже существовало - было бы намного приятнее работать - в этом отношении есть к чему стремиться.
НЛО прилетело и опубликовало эту надпись здесь
:) Какой то у Вас совсем неудачный опыт работы с питоном - мне больше повезло. То есть - не Руби конечно :) - но то, что мне нужно было - делал.
А вас никто не заставляет писать екстеншены к Python. Просто пишите на самом Python'е )
to North: а начать поиски с главной страницы проекта не пробовали? Там длиииинный список сайтов, построенных на Django или использующих её. http://djangoproject.com
Наверное удивитесь - но не пробовал :) Спасибо - буду смотреть.

А екстеншинами на самом языке к сожалению не всегда удается обойтись - по нескольким причинам - хотя бы из за желания увеличить скорост работы
Я пока не встречал ситуации, когда бы мне не удалось обойтись не то что существующими экстеншенами, но даже встроенными средствами.
И собственно, экстеншены на С/С++ пишутся, так что проблем скорости не существует в принципе.
Camping забыли :)
Я не забыл - честно сказать я именно о нем первом и вспомнил :) но как то не решился :)
:)
Но что же так? Ведь это отличный фреймворк для своих задач. Как и, например, web.py
>Да и сам Python как язык мне симпатичнее
Да нееее, руби намного красивее:
if flag
\t proc
против proc if flag )
не программист, просто некоторым образом имею отношение. хобби что ли ror для меня. ваяю на аптане по книжке шустрое уэб разработка на рельсах (Agile Web Development with Rails -тыреной pdf-ке). Очень не хватает книжек - желательно на русском и желательно бумажных.
что есть: http://xet.ru/rails
Вот вернее - Rails книжки, если тег не сьест
спасибо за ссылку
На русском и бумажных книг по RoR - с этим проблема.
Но вот если Вы работаете с Agile Web Development with Rails - то хочу Вам посоветовать очень хорошую книгу в таком же стиле
Beginning Ruby on Rails E-Commerce
Вот тут она + исходники к ней
http://ruby.rostovlinux.ru/rubylinks.htm…
И еще там же неплохая есть Rails Recipes - тоже неплохая книга.
огромное спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Все так, все так. Согласен. Но не могли бы Вы добавлять комментарии кириллицей, а не транслитом?
Кто-нибудь может внятно объяснить, как и почему AWS съезжает с рельсов в угоду REST'у?

Вебсервисы всегда были удобным срезом между вьюшкоконтроллерами и функционалом.

Не ведут ли рельсы в сторону игрушечной песочницы, отрезанной от всего мира?

(можно в аську: 10 655 643, или даже голосом Skype: Neurosurg)
А Вы не могли бы свою мысль чуть подробнее развернуть? Не совсем понятна мысль :( - AWS как связан с обсуждаемой темой?
А сообразил :) AWS же никуда не девается - ну будет от плагином, а не в ядре - без проблем использовать как и раньше.

А вообще в глобальном споре SOAP vs REST - видимо команда RoR решила встать на сторону REST. На сколько я знаю во 2 версии работу с ресурсами через REST сделают вообще основой RoR - во всяком случае я слышал что то похожее.
И совершенно не "отрезанная от всего мира песочница" - REST модный тренд, который активно поддерживают Google, Yahoo, Amazon - через свои API как раз расчитанные на работу через REST.
И эта тесная интеграция с REST вполне может стать очередной фишкой RoR, которой нет у других фреймворков - так что я не вижу причин расстраиваться :)
странно хабр не сообщил об ответе...

спасибо, понял. никогда не думал, что REST — это что-то большее, чем стилистика оформления URL'ов. и уж совсем не разглядел, что REST может стаять противовесом SOAP... у последнего хотя бы спецификация есть, как я помню. а у REST?

North, там почта на гмейл ушла несколько часов назад.
На счет спецификации не знаю. Но в плане использования в RoR я находил очень хорошие описания работы в некоторых книгах по Rails и есть замечательная публикация O'Reilly - Web Services on Rails - и это кроме достаточно большого количества просто статей.

на счет почты - кто то в Gtalk постучался и я добавил - Вы? :)
Очень хочется поскорее познакомиться с Ruby On Rails 2.0
Презентация доступна
Может быть дадите ссылку для неумеющих гуглить меня?
извините, без проверки понадеялся на оперативное размещение докладов проходящей сейчас конференции на тему развития Ruby


В качестве компенсации см. риколы на http://www.youtube.com/results?search_query=RubyOnRails&search=tag
Не только презентация доступна :) - сам код уже лежит - скачивайте/устанавливайте/знакомьтесь :)
На rubyonrails.com - 1.2.3
на rubyforge.org - тоже
а где rails 2.0 ?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.