Комментарии 78
а рельсы уже портанули под эту версию?
Лучше бы юникод доделали, по крайней мере это мои самые большие ожидания от ruby 2.0
Поправте опечатку:
> Такое, впрочем, можно было сделать и в старых версиях, но с дополнительным
библиотечным _кодом_ кодом.
> Такое, впрочем, можно было сделать и в старых версиях, но с дополнительным
библиотечным _кодом_ кодом.
Хм, извинити за мое невежетво..., а что это вообще такое? Первое что на ум приходит очередной Linux, но по ходу дела нет....
Это ещё один язык программирования, имеющий много общего с python и perl, и, по мнению некоторых, решающий многие задачи проще и удобнее
Ну как бы тебе сказать дружище... Раз уж сам признал свое невежество :) То интеллигентно примерно так: вот есть веб сайты, кто-то делает их из "конструкторов" (наз. CMS - joomla, mamba, drupal, и тд), а кто-то пишет сам. Вот писать можно на php, ruby, python, perl, c# и других, это языки программирования. Чтобы писалось быстрее, используют различные фреймворки, например rubyonrails (для руби, ссылка: http://www.rubyonrails.ru/) так вот, язык руби интерпретируемый, то есть выполняется без компиляции (про байткод позже), и когда говорят ruby 1.9 имеют ввиду версию интерпретатора этого языка. Интерпретаторы бывают под линукс, windows и др. Различаются скоростью и производительностью. В данной статье автор передал свои эмоции от новых языковых конструкций появившихся в новой версии интерпретатора. Ну вот, вроде как объяснил что где :)
Про Ruby можно немного почитать тут http://ru.wikipedia.org/wiki/Ruby
Это наше будущее, свет очей моих =)
О! Если рельсоводы зашевелились, то похоже скоро следует ждать и новую версию Джанго :)
Не думаю, что с переходом RoR на Ruby 1.9 стоит ждать изменений в Джанго. Ну прям никак не могу связать эти события :)
я думаю это может стать "пинком".
см. мой пост ниже :)
см. мой пост ниже :)
Да я смотрел, но ведь нужно понимать, что разработчики Джанго руководствуются собственными принципами при доработке фреймворка. Например, я много жду от QuerySet Refactoring, наследование моделей тоже жду с нетерпением. И т.д. и т.п. но это никак не связано с Ruby :). Кстати, не так давно Питон 2.6 отрелизили, вот это может быть отдаленно связано с доработкой Ruby :)
Конкуренция это всегда хорошо для нас, как пользователей.
НЛО прилетело и опубликовало эту надпись здесь
Это фреймворк под Питон :)
Но если подумать - новая версия Руби, под нее выйдет обновление для RoR. А Джанго все таки конкурирующий фреймворк. Хотя-бы оновять 0.96.1 до 1.0, о чем довольно долго уже говорят. А выход новых Рельс послужит "пинком".
Но если подумать - новая версия Руби, под нее выйдет обновление для RoR. А Джанго все таки конкурирующий фреймворк. Хотя-бы оновять 0.96.1 до 1.0, о чем довольно долго уже говорят. А выход новых Рельс послужит "пинком".
На мой взгляд, разработчики Django адекватные ребята, и новую версию они выпустят, когда она будет готова, а не после пинка. ;)
Но если подумать - новая версия Руби, под нее выйдет обновление для RoR.
Это Вы просто не в курсе – большое обновление Rails уже было - еще 17 декабря 2007 года – когда вышел Rails версии 2.0 – если разработчики Django так внимательно отслеживают изменения в RoR (что несколько сомнительно ) – то тот самый «пинок» они должны были ощутить еще 3 месяца назад.
точно, wild and weird, только не ideas, а сам язык :)
было бы интересно его изучить
было бы интересно его изучить
Большое спасибо за информацию, теберь буду знать. Я так понимаю это сравнительно недавний язык?
Относительно. Начал разрабатываться аж в 1993, но реальную популярность по ряду причин получил за пределами Японии только в этом тысячелетии, а особенно в последние два года. Я помню когда только познакомился с ним, в году 2005 найти что-то на русском было очень сложно, про Ruby on Rails вобще никто не слышал. Сейчас, в основном в связи с популярностью Rails, можно найти почти любую информацию.
Фигасе у вас синтаксис. Дикий флэшбэк, как будто опять заново Перл разглядываю. Давно думал посмотреть, что такое Руби, теперь знаю. Пойду дальше Питон ковырять.
У руби прекрасный синтаксис. Что вас так испугало?
Это вы зря. У Ruby хороший и читабельный синтаксис.
Да, в некоторых местах руби вызывает некоторую "ностальгию" по перлу. Ностальгию в кавычках, потому что перл может красиво решать только некоторые задачи. А руби красиво решает практически всё - это философия языка, за которой внимательно следят.
Вопрос к тем, кто после php перешел руби. Есть в руби то, чего категорически не хватает в php? И не сделать... Вопрос важный для меня. (Без подколок).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вот привязывал полнотекстовый поиск. Поставил плагин (1 команда). дописал во всех моделях 1 строчку is_indexed :fields => поля. Запустил индексатор - поиск через сфинкс готов :). феррет аналогично... Хоть это и рельсы, но в полной мере отражает возможности языка)
Рельсы на php (и для php) написать невозможно?
Да, невозможно :), из-за самого языка пхп. Даже статья была про это. Но я уверен что можно написать что-то со своей идеологией. Но врят ли так же красиво получится
Symfony - те же рельсы, только в профиль.
http://www.symfony-project.org/
Вроде недавно проскакивало на Хабре.
http://www.symfony-project.org/
Вроде недавно проскакивало на Хабре.
НЛО прилетело и опубликовало эту надпись здесь
Симфони (symfony-project.org)
Мы на нём тоже пишем. Честно говоря - тошнилово :-( Ну просто нет сейчас причин не использовать рельсы... Уже всё есть - и программеры, и хостинги, и даже книги на русском для тех кто в школе плохо учился.
Мы на нём тоже пишем. Честно говоря - тошнилово :-( Ну просто нет сейчас причин не использовать рельсы... Уже всё есть - и программеры, и хостинги, и даже книги на русском для тех кто в школе плохо учился.
А где и какие книги?
Можно ссылочку?
Можно ссылочку?
Например, для чайников:
http://www.ozon.ru/context/detail/id/365…
http://www.ozon.ru/context/detail/id/363…
http://www.ozon.ru/context/detail/id/365…
http://www.ozon.ru/context/detail/id/363…
Я Вас прошу...
Скаффолды и прочие вещи из-коробки это только для завлечения. Я сейчас делаю проект на Рельсах и как раз занимаюсь поиском на данный момент. Как и в любом другом месте, много ньюансов.
И даже спестя пости 40 лет мы пишем код вручную (с).
Скаффолды и прочие вещи из-коробки это только для завлечения. Я сейчас делаю проект на Рельсах и как раз занимаюсь поиском на данный момент. Как и в любом другом месте, много ньюансов.
И даже спестя пости 40 лет мы пишем код вручную (с).
Вещи из коробки - не развлечение. Скаффолд - не развлечение, а средство быстрого прототипирования. Быстрое прототипирование необходимо в бизнесе, чтобы быстрее поставить данный этап продукта клиенту. Мы аналогичным образом смотрим и на остальные "заранее приготовленные" штуки в рельсах, чтобы решать типовые задачи. Просто, на мой взгляд, надо использовать осмысленно...
Реально нет. Если руки прямые и голова работает. То любимый фреймворк в руки и сайты будут не хуже чем на рельсах. Но с опытом приходит понимание того что занимешься изобретением велосипедов, что конструкции руби или питона банально удобнее чем того же пхп. Что пхп фреймворки смотрят на рельсы и реализуют то что уже год есть есть в рельсах или джанге. И тогда становится банально обидно и хочется перейти на острие прогресса.
Я пишу на РНР со второй версии, в этом году начал изучать руби и рельсы.
Если брать голый язык, то руби "красивее". Если вы пишете на РНР давно у вас должны были возникать к этому языку вопросы, например "как сделать этот код понятнее и короче?" или "почему разный стиль именования функций" или "почему у сходных функций такой разный порядок операторов". В руби такие вопросы у меня (пока) не возникают. Более того, он позволяет писать более понятный код, причем для этого не обязательно долго читать маны.
Отдельный разговор про блоки. Вы пользовали в JS c прототайпом не именованые функции? В общем они похожи на блоки в руби. В PHP ближайший аналог это использование create_function, но после него код становится ну совсем не читаемым.
Из минусов - говорят руби работает медленней, готов в это поверить.
Но в наше время на голом PHP пишут очень редко, в основном используют CMS или фреймворки. Для руби есть фреймворк Rails и с ним тяжело тягаться. Опишу основные плюсы, которые я заметил:
- Scaffolding, в часности Active Scaffold. Посмотрите демку на их сайте. Фактически, админку для БД можно сделать за считаные часы. Для фронт-энда пока не использовал, хотя, тоже можно.
- Active Record - работа с базой данных. Для РНР есть аналоги, но совсем не такие "феншуйные". Вы описываете в моделях свои таблицы (название, как устроена связка) и работаете с записями из б.д. как с методами объекта! Фактически, за весь проект я ни написал ни одного запроса! Опять же, никаких sql-injections
- MVC модель доведенная до совершенства. у вас действительно три разных файла, причем файлы находятся в отдельных папках. Намного удобнее поддерживать чужой код - ясно что где лежит.
- Хелперы, облегчают однообразные операции. В часности, элементы формы, ссылки и т.д. и т.п. не надо строить руками - вызывается хелпер с параметрами. Отдельный плюс - хелперы для джаваскрипта. Можно писать JS код прямо из руби, он сам подключится в проект. В основе лежит прототайп, так что проблем с функциональностью нет.
Из минусов: Скорость работы, хилая документация (к слову лучше мана чем у РНР я не видел), практически полное отсутствие русских книг, статей.
И самый главный минус: после ROR очень-очень тяжело возвращаться в PHP.
Вот самые интересные статьи, которые удалось найти Простой и понятный учебник по Ruby, обзорная статья про Rails
Если брать голый язык, то руби "красивее". Если вы пишете на РНР давно у вас должны были возникать к этому языку вопросы, например "как сделать этот код понятнее и короче?" или "почему разный стиль именования функций" или "почему у сходных функций такой разный порядок операторов". В руби такие вопросы у меня (пока) не возникают. Более того, он позволяет писать более понятный код, причем для этого не обязательно долго читать маны.
Отдельный разговор про блоки. Вы пользовали в JS c прототайпом не именованые функции? В общем они похожи на блоки в руби. В PHP ближайший аналог это использование create_function, но после него код становится ну совсем не читаемым.
Из минусов - говорят руби работает медленней, готов в это поверить.
Но в наше время на голом PHP пишут очень редко, в основном используют CMS или фреймворки. Для руби есть фреймворк Rails и с ним тяжело тягаться. Опишу основные плюсы, которые я заметил:
- Scaffolding, в часности Active Scaffold. Посмотрите демку на их сайте. Фактически, админку для БД можно сделать за считаные часы. Для фронт-энда пока не использовал, хотя, тоже можно.
- Active Record - работа с базой данных. Для РНР есть аналоги, но совсем не такие "феншуйные". Вы описываете в моделях свои таблицы (название, как устроена связка) и работаете с записями из б.д. как с методами объекта! Фактически, за весь проект я ни написал ни одного запроса! Опять же, никаких sql-injections
- MVC модель доведенная до совершенства. у вас действительно три разных файла, причем файлы находятся в отдельных папках. Намного удобнее поддерживать чужой код - ясно что где лежит.
- Хелперы, облегчают однообразные операции. В часности, элементы формы, ссылки и т.д. и т.п. не надо строить руками - вызывается хелпер с параметрами. Отдельный плюс - хелперы для джаваскрипта. Можно писать JS код прямо из руби, он сам подключится в проект. В основе лежит прототайп, так что проблем с функциональностью нет.
Из минусов: Скорость работы, хилая документация (к слову лучше мана чем у РНР я не видел), практически полное отсутствие русских книг, статей.
И самый главный минус: после ROR очень-очень тяжело возвращаться в PHP.
Вот самые интересные статьи, которые удалось найти Простой и понятный учебник по Ruby, обзорная статья про Rails
Из минусов: .... хилая документация (к слову лучше мана чем у РНР я не видел),
А можно вопрос - почему Вы считаете что документация "хилая"? Кроме того, что есть подробно описанный API на Amazon.com я насчитал около 30 наименований книг о Rails - такого количества литературы ни по одному web фреймворку даже близко нет.
"почему разный стиль именования функций" или "почему у сходных функций такой разный порядок операторов"
что есть то есть... но смертным грехом я это не считаю.
Спасибо за линки!
что есть то есть... но смертным грехом я это не считаю.
Спасибо за линки!
Про тесты не забудьте :-) Любая книжка по рельсам для начинающих содержит информацию про тесты. А многие ли php-программеры после 1-2 лет работы РЕАЛЬНО пишут тесты в режиме TDD? Немногие об этом хотя бы просто знают...
Всё, что написали - фигня. :)
Главное, что есть в руби, по сравнению с пхп - это отсутствие (дзен-буддизм, прямо).
В руби отсутствует ублюдочный пхп-шный синтакстис
В руби отсутствует дикая пхп-шная мешанина всего на свете и как попало.
Кроме того в руби есть стройность, логичность и красота.
"не сделать" - это сложно. В теории на пхп можно сделать (почти) всё. И чуть больше, чем почти всё можно сделать на руби. Вся разница в количестве прилагаемых усилий.
Главное, что есть в руби, по сравнению с пхп - это отсутствие (дзен-буддизм, прямо).
В руби отсутствует ублюдочный пхп-шный синтакстис
В руби отсутствует дикая пхп-шная мешанина всего на свете и как попало.
Кроме того в руби есть стройность, логичность и красота.
"не сделать" - это сложно. В теории на пхп можно сделать (почти) всё. И чуть больше, чем почти всё можно сделать на руби. Вся разница в количестве прилагаемых усилий.
Большое спасибо за статью. Хотелось бы увидеть её продолжение.
Я немного шокирован тем, что многие читатели впервые слышат о Руби.
Если Вы программист, то Вы обязательно должны познакомиться с этим языком.
Люди!!! Не давайте вашему мозгу закостенеть. Чем больше парадигм и языков программирования вы знаете - тем шире ваш профессиональный кругозор.
Я немного шокирован тем, что многие читатели впервые слышат о Руби.
Если Вы программист, то Вы обязательно должны познакомиться с этим языком.
Люди!!! Не давайте вашему мозгу закостенеть. Чем больше парадигм и языков программирования вы знаете - тем шире ваш профессиональный кругозор.
НЛО прилетело и опубликовало эту надпись здесь
Ну, там на на горизонте замена MRI (Matz Ruby Implementation) на YARV (Yet Another Ruby VM) в core, чтобы у ruby наконец появилась VM.
Хотя, мне нравится JRuby при надобности можно использовать Java код, например, использовать Lucene вместо Ferret, либо прикрутить родную Java локализацию к приложению на Ruby. Хотя, на практике пробовал это делать только в sandbox.
Хотя, мне нравится JRuby при надобности можно использовать Java код, например, использовать Lucene вместо Ferret, либо прикрутить родную Java локализацию к приложению на Ruby. Хотя, на практике пробовал это делать только в sandbox.
Изменение, касающееся «локальности» параметра в блоке выглядит довольно опасно, т. к. может оставить уже написанный код с виду работающим, но сделать его некорректным вдруг кто-нибудь пользовался этой особенностью языка. А такую ошибку искать долго. Поменьше бы таких изменений в языке (хотя новое поведение, безусловно, мне нравится больше). Long live Ruby! :-)
А где эмоции-то? :)
Про одну из эмоционально-приятных вещей забыли - скорость работы 1.9 заметно выше - и теперь ни чуть не уступает некоторым другим языкам :) - на Хабре еще в сентябре прошлого года мы это бурно обсуждали :)
Как джаваскриптеру, мне больше всего нравится изменение по поводу block scope - так намного приятнее. :) А вот изменения синтаксиса с проками и лямбдами мне очень не нравится - короче, но менее читабельно и логично с синтаксической точки зрения.
с lambda действительно как-то странно вышло.
Я надеялся, что этот синтаксис позволит вместо
arr.each_with_index {|el, i| puts "#{i}: #{el}" }
писать
arr.each_with_index -> el, i { puts "#{i}: #{el}" }
или даже
arr.each_with_index -> el, i do
puts "#{i}: #{el}"
end
но "анонимный блок" так чистенько не запишешь. Почему, собственно? По мне так smalltalk-овские || вокруг аргументов блока — одна из самых синтаксически странных особенностей ruby.
Выходит, оператороподобная -> практически всегда будет идти после операторов же: =, =>, &: или еще каких-то. Не симпатично. Просто workaround парсера, неспособного съесть |a, b=3, c=4|.
Я надеялся, что этот синтаксис позволит вместо
arr.each_with_index {|el, i| puts "#{i}: #{el}" }
писать
arr.each_with_index -> el, i { puts "#{i}: #{el}" }
или даже
arr.each_with_index -> el, i do
puts "#{i}: #{el}"
end
но "анонимный блок" так чистенько не запишешь. Почему, собственно? По мне так smalltalk-овские || вокруг аргументов блока — одна из самых синтаксически странных особенностей ruby.
Выходит, оператороподобная -> практически всегда будет идти после операторов же: =, =>, &: или еще каких-то. Не симпатично. Просто workaround парсера, неспособного съесть |a, b=3, c=4|.
А подскажите, как сейчас у Ruby с производительностью?
Давно хочу перейти с php на руби. Что бы быстро на рельсах простенькие сайты делать.
Но вопрос производительности угнетает.
Давно хочу перейти с php на руби. Что бы быстро на рельсах простенькие сайты делать.
Но вопрос производительности угнетает.
Если сайты "простенькие", то, может, и вопрос производительности не так критичен, как кажется?
По-моему, основная проблема при переходе с ПХП будет не в производительности, а в хостинге. Оный с поддержкой рельсов сейчас и реже, и дороже.
По-моему, основная проблема при переходе с ПХП будет не в производительности, а в хостинге. Оный с поддержкой рельсов сейчас и реже, и дороже.
У меня собственный сервер, так что вопрос хостинга не стоит. А простенькие сайты все же могут быть более менее посещаемы и их может быть много. Ну, скажем 10-20 сайтов. В случае php суммарный трафик в размере 20-40k уников в день - это и не нагрузка вовсе. А вот про ror есть сомнения.
В среднем те же 14 баксов в месяц, что и для нормального php-шного хостинга... Конечно, бывают php-хостинги за 20 баксов в год, но это не самый лучший вариант.
Насколько я помню, сравнение различных web-MVC фреймворков показало, что самый быстрый — это Django.
порадовали «человечные» знаки вопроса :)
Не порадовали английские названия дней недели. Нельзя в язык вносить культурно-зависимые элементы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эмоциональный обзор Ruby 1.9