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

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

Мы Rails используем и довольны.
А можно, вкратце, про проект(ы)?
>Ruby — интереснее и красивее Python

Довольно субъективно. Объективно, что синтаксис богаче. А красив ли код полный спецсимволом — решает каждый для себя.

>перезагружать приложение после каждого изменения server-side-кода

В -dev режиме django не нужно перезагружать приложение после изменения кода.
>В -dev режиме django не нужно перезагружать приложение после изменения кода.
Можно поподробнее? У меня, почему-то, изменения не применяются что без --noreload, что с ним, а если его нет, то ещё и runserver продолжает висеть в процессах, даже если в эклипсе я остановил выполнение.
Странное поведение. В дев-режиме, конечно, сервер перезагружать тоже надо, просто он делает это автоматически. А при изменении темплейтов и этого не требуется.
С темплейтами всё нормально, поэтому я и написал про server-side. И ещё я читал, что это распространённая проблема, например, в pyCharm --noreload включён по умолчанию именно из-за такого поведения
Ключевое в вашей проблеме это — «в эклипсе». Девелопмент сервер отлично перезагружает код после изменения. Не у всех IDE получается с этим интегрироваться.
рельса в режиме разработки тоже не нужно перезагружать
Я опоздал %)
Руби — это ASCII-арт какой-то. Python очень красив отсутствием лишних знаков.
Пример в студию
Первый попавшийся файл с расширением rb :)
Например, github.com/mxcl/homebrew/blob/master/Library/Homebrew/install.rb

«if f.keg_only? == :provided_by_osx» — что за вопрос и двоеточие?
«rescue Exception => e» — что за стрелочка такая??
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
а может для начала все-таки немного подучит ЯП? а то в Си "*" тоже не одну функцию выполняет
Казалось бы, причем здесь C?
Мы сравниваем Python и Ruby. То, что в Python меньше лишних ASCII-символов используется — это факт.
НЛО прилетело и опубликовало эту надпись здесь
то же самое и в руби =)

сначала непонятно, что значит вопрос или воскл. знак в конце метода, но потом понимаешь, что все это не просто так, и на самом деле очень просто объясняется.

Вопрос ставится, если функция возвращает только true/false

А восклицательный знак — если функция меняет сам объект, а не возвращает значение, т.е. чтобы не писать foo = foo.downcase, а сразу написать foo.downcase!

Но для меня всегда было непонятным, зачем в языках типо питона (явы, с++ и т д) ставить обязательные скобочки в названиях функций. Ведь это только ухудшает читабельность кода и заставляет писать два ненужных символа.
НЛО прилетело и опубликовало эту надпись здесь
Вот меня всегда интересовал вопрос: где в Питоне явное завершение блока кода?
Там, где начинается строка кода с меньшим отступом ;)
Вы же ясно написали, что Ruby нравиться больше. Используйте рельсы.

А то, что вам что-то не понятно, так это вопрос времени и желания. Вы ещё столкнётесь с тысячью непонятных вещей. :)
Мне нравятся обе эти технологии. Я просто только что приехал с Ruby Shift (куда и попал-то случайно) и ещё нахожусь под впечатлением :) До этого я считал Django более интересным для себя, а теперь вот сомневаюсь.
Если вы под впечатлением, то начинайте изучать. Это же самое оно — под впечатлением изучать гораздо интереснее. :) Не понравиться руби, возьмётесь за питон. Не понравиться питон — вернётесь осваивать джаву.
Вы же линуксоид, а любой начинающий линуксоид знает, что нужно выбирать тот дистрибутив, которым пользуетя ближайший линукс-гуру. Я думаю так же и с языками по началу.
Спрашивать на Хабре об этом — тоже самое что узнавать среднюю температуру по больнице, всё равно большинство пробовало только один из них, и естественно они буду хвалить именно тот который знают.

Моё субъективное мнение: Питон+Джанго офигительная связка, но с рельсами я даже отдалённо не знаком, так-что имейте ввиду.

И по моим наблюдениям, тут Джанго-фанатов побольше будет, а значит объективность будет нулевая.

Вот здесь более-менее объективное сравнение stackoverflow.com/questions/91846/rails-or-django-or-something-else (если не знаешь английского, тогда задумайся о смене профессии).

А вот чтобы тебя ещё сильнее запутать: stackoverflow.com/questions/48681/pros-cons-of-django-vs-pylons
Английский знаю, спасибо за ссылку :)
Если изучение носит больше академический характер, то посмотрите на фреймворк Seaside для Smalltalk'а. Smalltalk более аккуратен и изящен нежели Ruby (субъективно), да и фреймворк очень хороший.
Говорю «академический» потому что могут возникнуть проблемы с хостингом, да и работу в вебе на Smalltalk у нас не найдешь, разве что самому стартап начинать. А так изучение было бы полезно во всяком случае.
Спасибо за совет, но я, наверное, им не воспользуюсь — всё-таки хочется овладеть чем-то более востребованным :)
Начните с того, что больше по душе, а дальше будь что будет. Средства и способы разработки не стоят на месте, поэтому с большой вероятностью в будущем все равно придется переучиваться.

Выбрать объективизм более лучшую и перспективную технологию вы сейчас не сможете, т.к. нет опыта работы ни с одной из них. Спрашивать тут бесполезно, т.к. голоса знающих обе эти технологии потонут в общем потоке.

Я выбирал года два назад. Для этого сделал по-небольшому приложению на django и rails. Выбрал то, на чем писать было удобнее лично мне.
и…
Оба варианта хороши.
Есть несколько вещей, которые ещё стоит учесть:
— у Django чертовски хорошая документация
— Ruby более гибкий, на мой взгляд, язык, чем python. Те же блоки кода в качестве аргументов — отличная вещь когда научишься ими пользоваться.
— Django состоит из отдельных (довольно толковых) компонентов связываемых удобным питоновым кодом
— Rails связывает компоненты скрытой магией, что может и само по себе сбивать с толку и затруднять возможность делать что-то нестандартное

Ну и в конце концов, выбери проект, который будешь делать, от него и пляши — выбирай, что удобнее.
В Rails 3 магии чуть поменьше :)
В rails документация если и не лучше, то точно не хуже.
Чи не все равно?
Посмотрите Grails, тем более если Java уже осваивается.
Я считаю, что Grails стоит изучать после Rails. Ибо начинать с Groovy/Grails достаточно сложно, а после руби и рельсов сразу видны все те подпорки, которые использовались для связки джавы с руби-образными языковыми конструкциями и концепциями рейлз.
разве? как по мне, так grails как раз гораздо проще изучать…
О, знакомые «лица» из твита. По мне, так не зная рельсов, grails кажется полным магии, ну а groovy так вообще тяжело изучать без бэкграунда продвинутых крестовых языков с блокам и замыканиями
*скриптовых
вполне себе начинал изучать grails, не имея такового бэкграунда.
как по мне, так «инопланетянский» синтаксис ruby куда менее понятен
На первых порах closures в Groovy будут казаться синтаксическим сахаром для function objects в Java. В динамическом типизировании ничего сложного нет. Так что не вижу особого смысла учить целый новый язык+стек со своими заморочками.

Хотя я лично, последнее время все больше склоняюсь от Grails в сторону Roo + Vaadin/GWT. Groovy лишь как скриптовой или dsl.
НЛО прилетело и опубликовало эту надпись здесь
можно поменять ActiveRecord на мербовый DataMapper — там вместо миграций используются описания полей в модели =)

Лично мне он даже больше AR'a нравится
НЛО прилетело и опубликовало эту надпись здесь
Есть же гем dm-migrations :)

Я им пользуюсь :) Хотя он, конечно, недоделан, но пока лень допиливать.
Попробуйте-ка вести совместную разработку без использования миграций
" То, что говорят насчет «в Rails больше магии» — это не совсем так. "
нет ну понятно что это всё достигается засчёт интроспекции самого ruby
но если забыть про это то многое действительно кажется магическим.
Блоки кода особенно впечатляют, если я правильно помню, там можно еще расширять стандартные классы (как, например, в C#, про другие не знаю).

В С# можно добавлять только статические методы к классам, если не изменяет память. В Руби можно изменять любые методы (класса или инстанса), какие в голову взбредут, в том числе и «перекрывать» уже написанные.

Насчет миграций в Rails — мое личное мнение, это отстой

Можно попробовать другие подходы к ORM, к примеру как у DataMapper'a.

Автору: не совсем по теме совет, но все же, попробуйте Sinatra www.sinatrarb.com/, в академических целях хотя бы :) Возможно, будет проще ориентироватся во «взрослых» фреймворках, типа рельс, ну и с блоками разберетесь. Ну и рельсоводы сейчас бурно ожидают 3-е пришествие Рельсы с тотальным агностицизмом, возможно, вам пока имеет смысл изучить Django или все же бету Rails 3.
В С# можно добавлять только статические методы к классам, если не изменяет память. В Руби можно изменять любые методы (класса или инстанса), какие в голову взбредут, в том числе и «перекрывать» уже написанные.

Наоборот, можно добавлять только instance методы.
>Werkzeug + Jinja2 + WTForms + SqlAlchemy
а лучше pylons конечно
пацаны на раёне не одобрят
> поддержка миграций «из коробки»
South (http://south.aeracode.org/) для Django вполне хорош. Он не «из коробки», но начать его использовать в проекте — дело максимум 10-и минут.
Хорошая штука. В одном проекте сейчас под сотню миграций на south, все устраивает.

В django 1.2 был отклоненный proposal на включение его в стандартную поставку, который был отклонен по желанию автора south, т.к. идет активная разработка и включение на этом этапе в django будет мешать — появится привязанность к неторопливым релизам django, например.
Скоро выйдет Rails 3, который будет включать много вкусностей. Например, такие «вшитые» компоненты, как ActiveRecord и RJS на js-фреймворке prototype можно будет поменять на DataMapper и jQuery =). Не спорю, что это можно сделать и сейчас, просто в 3-их рельсах это будет проще.

Лично я пользуюсь рельсами и доволен. Мне очень нравится синтаксис Ruby, нравится отсутствие необходимых скобок в именах процедур — foo.bar вместо foo.bar() или какого-нить foo.__bar__() выглядит намного приятнее.

Насчет скорости — это не такая уж проблема, приложение работает почти в несколько раз быстрее на Ruby 1.9.

Я бы стал писать на питоне, если бы мне нужно было разрабатывать не только веб-приложение, но еще и например, десктопную версию. Питон в этом плане как-то более приспособлен, нежели Ruby.

Думаю, автору стоит выделить один день под это дело, поставить оба фреймворка и попробовать сделать какой-нибудь простой проект, например новостную ленту с комментами. Что больше понравится — то и использовать -)
НЛО прилетело и опубликовало эту надпись здесь
Кто интересно молчит? For example я сейчас успешно разрабатываю проект на Rails 3. Разработка самого framework тоже открытая https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets. Ерунду говорите какую-то, честное слово.
Для начала вообще не мешает определиться, а что же именно тебе интересно разрабатывать. А уже после этого и выбирать язык. Как вариант, посмотреть какие проекты в интернете написаны на Django, какие на Ruby.

Из личного опыта — знаю компанию, которая зарабатывает, создавая сервисы на Ruby, очень неплохие деньги. С другой стороны сам участвовал в проекте на Django. Чужой незнакомый код был более чем понятен.

Сам как явашник больше склоняюсь к Ruby, а точнее к Grails. Очень интересный язык/фреймворк.
У нас есть здоровенный проект на Grails, кода много — несколько человек трудилось два года. Могу сказать, что тесная интеграция с джавой и спрингом — единственное преимущество этого фрейворка над другими обсуждаемыми. Grails может быть очень полезен, если нижележащая логика написана на Джаве или надо написать много кода (на джаве), не имеющего отношения к обработке веб-запросов. Однако сам Groovy глючит, и весь Grails глючит так же, неочевидно и не всегда исправимо. Это касается и тех частей где, казалось бы, можно откатиться к спрингу или «родному» hibernate-у. Производительность средняя (загляните в Yourkit на запущенное приложение Grails, удивитесь).
согласен с вами — для меня преимущество Grails — тесный контакт с явой, так как фирма ориентированна именно на яву. А какие глюки были замечены?
Да много разных, особенно доставляют те, где проблема решается переименованием переменной или переставлением двух не связанных строк между собой. Общий смысл — что-то происходит с кодом неочевидно и практически неотслеживаемо.

Я бы предпочел больше Джавы, и меньше Groovy. Как прекрасно было бы иметь в Grails-приложении все на Джаве (в спринге, особенно стартап-код, инициализацию), а от Grails оставить _только_ контроллеры и представления, и чтобы на стыке все работало как надо! Собственно, эта скриптовая часть и подкупает больше всего, позволяя в одном проекте совместить труд программиста некоторой сложной подсистемы (и интеграционной к ней логики) на Джаве и традиционный «скриптовый» подход веб-разработчиков. От остального остается двоякое впечатление — от великолепных Spring и Hibernate в интерпретации Grails остается какое-то, не побоюсь сказать, убожество.

Насчет Groovy есть такое мнение, что на JVM он ложится с большим трудом. При этом образуются тысячи (десятки, сотни тысяч) объектов типа Closure, которые не поддаются никакому профилированию и здорово загаживают память. Получаемый байткод для довольно простых операций вообще ни разу не оптимален, по использованию как памяти, так и процессора.
Печаль ТТ как говорится, в жизни все не так как на самом деле. В любом случае, спасибо за ответ!
>а от Grails оставить _только_ контроллеры и представления, и чтобы на стыке все работало как надо

В джаве jax-rs хорош, подойдет вплоне в качестве контроллеров. А на вью — freemarker. Так чо при желании можно и жаву использовать для бвстрой разработки.
Увы, чтобы отдавать шаблоны, все равно придется использовать либо голые сервлеты со своей логикой, либо какой-то еще фреймворк. Как представления связываются по данным с бекендом — не самое главное, важнее — как мы избегаем превращения представлений в помойку. Grails тут отлично все раскладывает по полочкам.
>несколько человек трудилось два года
grails 2 года назад и grails сегодня — это довольно большая разница в стабильности, производительности итд, вы не находите?
Ну вот что-что, а стабильность и легкий дебаг у меня с Grails не ассоциируются, так что товарищ во многом прав.

Кстати, занимательный факт) Единственная книжка на русском в Java направлении в этом году по Grails — www.ozon.ru/?context=search&group=nonfiction&text=java&sort=year
Да, дебаг — это отдельная песня, даже IDEA справляется не очень. Как выкручиваются пользователи Эклипса, вообще не представляю.
Мы переходили пару раз на новые версии, можно считать, что фреймворк годичной даывности. Не исключаю, что в последних релизах все могло стать несколько стабильнее (судя по багтрекеру, дырки закрываются), кроме того, есть много удобных плагинов, однако в том, как платформа устроена, не поменялось ничего. Groovy же, который я имел несчастье использовать в другом проекте, не изменился вообще — все то же множество глупых объектов в памяти и неэффективный код.
groovy++ для grails уже не за горами :)
У меня есть хороший знакомый который стал писать на джанге потому что не переносил руби и пхп, а на питоне кодил пару лет.
Я стал писать на рельсах потому что не люблю питон и не знаю пхп, но имею опыт руби-кодинга.

Все просто. А любая попытка сравнить RoR и Django или Ruby и Python обречена на холивар
Холивара тут не возникнет =)

программеры на Ruby и Python как правило относятся друг к другу с уважением, а не с ненавистью.
НЛО прилетело и опубликовало эту надпись здесь
Какие-то у вас сферические обобщения. И там и там люди со своими тараканами, даже на Хабре относительно недавно был срач на тему python и php, так неадекватов было с обоих сторон хоть отбавляй, некоторым сложно понять что ЯП — инструмент а не религия.
НЛО прилетело и опубликовало эту надпись здесь
Тролли такие php-исты. Я последнее время работаю с php, был проект и на RoR, поводов для холивара не было.
хзхз
у нас в конфе состояние перманентного срача с писькомерством. Рубисты и питонщеги объединяются только против пхпистов.
Мои пять копеек. Работал с РНР 6 лет, пересел на Rails. Понял, что жизнь прекрасна, когда заработал на MacBook PRO — понял что жизнь с Rails велликолепна! Попробовал textmate. Пока не знаю, чего еще желать, кроме как спокойно работать языком и фреймворком, который нравится. Максимум эффективности и продуктивности — Rails. Конечно это не реклама, а ИМХО.

Питоноводов не хочу обидеть, но я просто не пробовал питон. Говорят, класс, но каждый выбирает для себя. Все же — каждый язык и фреймворк — для своей цели. Все зависит от прямоты рук. ;) Питон попробую когда нибудь с Django. ;)
НЛО прилетело и опубликовало эту надпись здесь
только что запустил рельсы, на рельсах 1 небольшой проект 1.1% от 2024Mb = 22.22Mb

прочитав несколько форумов, могу лишь процитировать одного умного человека:
«быстродействие и отжираемость ruby\python\php приложений обратно пропорциональна кривизне рук»
НЛО прилетело и опубликовало эту надпись здесь
Веб-сервер какой?
Я юзал mongrel, получалось около 30 метров на процесс. Сейчас очень хочу перейти на mod_passenger для Apache.
Если кто-нибудь на больших проектах юзал, скажите, есть ли выигрыш в производительности?
НЛО прилетело и опубликовало эту надпись здесь
Согласен. Mac OS + Textmate + Rails это рай для веб-разработчика =)
А можете рассказать, что здесь такого классного? А то я много отзывов хвалебных слышал, но без конкретики… За что этот TextMate так любят?
За то что редактор простой и очень удобный) Попробуйте e-texteditor под windows — аналог textmate и все поймете)
Я под линуксом сижу :) Тут аналоги есть? Может, vim?
— gedit (с плагинами для Rails), для начала неплохо, если с gtk нет проблем. habrahabr.ru/blogs/ubuntu/74355/

— RubyMine — 99$, все классно, но не бесплатно. www.jetbrains.com/ruby/

— RedCar если 0.3 версия вас не пугает, ознакомьтесь redcareditor.com/
я долгое время пользовался вим/гвим на linux и был очень доволен, но когда
лет 5 назад перешел на мак и рельсы то начал пользоваться textmate
т.к. на тот момент было трудно сравниться с ним в удобстве разработки
на руби. но мне всё это время чего-то не хватало. время от времени ловил
себя на том что делаю лишние «пальцедвижения» для чего-то что в вим
решается буквально парой нажатий на кнопки :)
короче, пару месяцев назад, в очередной раз прочитаб как кто-то вернулся в
в vim из textmat-а я решил отложитъ мейт и какое-то время попробовать
вернутся в вим.

немного помучался в начале пока всё не настроил, но теперь очень доволен
и возвращаться в мейт не намерен.

если интересно мои вим настройки для руби/рельсов на виме тут:
github.com/astrails/dotvim

там есть README с кучей «интересностей»

работает на маке и *никсах.
А в чем, пардон, принципиальная разницы Macbook PRO + Rails + Textmate против Thinkpad + Ubuntu + RubyMine?
Вопрос не для холивара, сам второй год думаю над переходом, но объективных доводов в достаточном количестве так и не насобирал.
RubyMine я в свое время щупал и даже хотел разжиться бесплатной студлицензией. Но потом меня его даже воровать обламало.
Он написан на Java, памяти жрет как, наверное, 50 texmate или gvim, проц тоже не слабо грузит (пробовал осень-зима, на gentoo).
Может что и изменилось, не знаю.
Ну я брал, когда еще за 50 баксов продавали, вполне адекватная цена, которую не жалко. По части нагрузки на систему — с рубимайн, в отличие от ее старшего брата, ни разу проблем небыло. Более интересен вопрос, почему вселенской счастье наступает с переходом на мак ось?
Начал изучать Ruby и Rails. Ruby как язык очень нравится, просто тащусь от него. Rails кажется каким то огромным монстром. Сегодня узнал про Sinatra, HAML, Thin, попробовал и понял вот оно! С этого то и начну.
Попробуйте ещё Express.

А вообще, да, я тоже после Рельсов переехал на Синатру :)
Sinatra + haml + sequel + thin — идеальная связка.
Из личного опыта: сначала принялся за питон+джанго, даже сделал два несложных проекта на них. Автоадминка в джанге вещь суперская, но вот как-то в этих двух проектах не пригодилась.
Потом попробовал руби и рельсы, да там и остался, потому что (субьективно):
  • В рельсах все более лаконично
  • Принцип «convention over configuration»
  • Миграции из коробки (джанго тогда еще только до версии 1 дорос, со сторонними плагинами было не все так просто)
  • Я был просто в восторге от haml и sass
я в свое время наслушался про то какая классная админка в джанге и как все плохо в рельсах.
Но потом я нашел typus X)
спасибо за typus. какое-то время назад я искал полу/авто админ под релисы и ничего
действительно классного не нашел. остановился на neerajdotname.github.com/admin_data/
но не очень доволен. буду пробовать типус. вроде неплох
Кстати, вот тут есть интересная статья о выборе «что же учить из языков» — ru.wikibooks.org/wiki/Ruby/Идеология (середина статьи, раздел «Какой язык программирования учить первым?»)

Ты главное не торопись, а то еще, чего доброго, не то выберешь.
НЛО прилетело и опубликовало эту надпись здесь
Человек, который не может самостоятельно для себя сделать выбор между двумя технологиями, изучив область знаний и погуглив, вообще программистом быть не может.
бред.
обе две эти технологии служат для одинаковых целей.
языки на которых они основывается похожи (хотябы динамичностью)
и в вебе ведут себя похожим образом.
обе эти вещи популярны.

и уверне что на глаз по коду и струкруте нельзя определить что будет лучше и интереснее.
для этого и существуют коллеги (в широком смысле) которые могу высказатсья, и уже на их опыте можно сделать более точное предположение
сорр «уверен » и «высказаться»
Почему другие люди должны знать, что лучше и интереснее для него?

Не замечал за людьми нашей профессии стадного инстинкта.
а если перечитать?
не?
я не говорил что другие должны говорить что лучше и красивее.
они говорят собственное мнение, а автор вопроса, да и любой человек уже по ним определяет степень того насколько это ему подходит
Так если «обе две эти технологии служат для одинаковых целей.
языки на которых они основывается похожи (хотябы динамичностью)
и в вебе ведут себя похожим образом.
обе эти вещи популярны.», то нахрена ему глазеть на ваш вялотекущий холивар? =)
ок.
больше не кормлю.
А, ну давай всех, кто с тобой не согласен, в тролли записывать. Авось получишь конфетку от сообщества за набор рефлексивных фразочек.
Сначала надо с языком определится, потом уж ясно станет. Фреймворки как мода приходят и уходят, постоянно перенимают новые фичи. Языки все-таки несколько медленнее меняются и ассимилируются, переход между одним излюбленным языком к другому более болезненный.
Мне лично руби очень понравился, вряд ли слезу с него в ближайшее время.
Рекомендую также принять к сведению:


Оу, а вот это интересно, спасибо!
неправильное сравнение =)

половина запросов по django вообще не имеет отношения к языку. Вон там справа есть ссылки:
Да, поэтому вот такое сравнение может быть правильней: www.google.com/trends?q=python+django,+ruby+on+rails&ctab=0&geo=all&date=all&sort=0
Парсер лох… ссылка
НЛО прилетело и опубликовало эту надпись здесь
как-бы, фреймворк был назван в честь джаззмена, поэтому и неудивительно, что вы найдёте кучу инфы о некоем мистере Рейнхарде. Но самый сок будет, если вы внезапно захотите попробовать grappelli .)
ну для полноты картины

НЛО прилетело и опубликовало эту надпись здесь
скорее всего да, хотя кто его знает.

наверное в график стоит еще включить пару пхп фреймворков (хотя тут нет такой оленеводческой однозначности: пайтон-диджанго, руби — рельсы)
Ну пока нет причин сомневаться в том, что PHP 6 выйдет своевременно.
Бери Rails )
вне конкуренции.
и будет тебе свобода.

( сам использую и django и rails)

по поводу типа symbol всё просто) относись к ним как к облегчённым строкам… без кучи методов…
а смысл символов в том, что они потребляют намного меньше памяти чем просто строки) Потому что для одинаковых символов память выделяется 1 раз.
Вот все что понадобилось знать мне для их понимания)
и для записи используют меньше букв, нежели строки, а потому более понятны. но это придет со временем, главное начать же:)
блоки и прочие лямбды — без них никуда, но это можно понимать не сразу, никто ведь не заставляет начинать изучение руби с построение собственных DSL ;)
и забыл добавить что
более ярко выраженная в rails «Convention over configuration»
просто чёртовски охренительная вещь…
кстати да. у нас в команде возникало много проблем с джанго-проектами, из-за того, что джанга со стандартной структурой приложения позволяла сделать чуть больше чем нужно. Рельсы в этом плане более строги к внутренним соглашениям по расположению компонент веб-приложения.
Лично мне сам язык Python намного меньше нравится… В ruby все более красиво выглядит. После PHP пробовал изучить оба языка и фреймворка — ruby как то ближе по идеологии. Но в рельсах как то магия иногда пугает — хочется знать почему оно так и как работает, в джанго в этом плане попроще.
Для себя я выбрал ROR, но джанго потихоньку изучаю, ведь нельзя стоять на месте )

И просто небольшая история — как то раз я делал на PHP для себя проект небольшой, и у меня был затык на структуре БД. Было несколько вариантов и я долго думал как правильнее, спрашивал на форумах, хотелось сделать удобно и красиво…
Вот так я долго думал в итоге мне просто надоел проект, появились другие)

Так что если вы под впечатлением от ROR — начните с него. Изучите — вот и хорошо, с django судьба все равно сведет рано или поздно)
Руби молодой язык, слишком молодой. На многих стабля-дистрах вида долбияна или редхата вы увидите страшно старые версии руби. Обновления языка в недавнем прошлом (незнаю как сейчас) имели свойство ломать совместимость к черту из-за чего количество батареек в руби совместимых с конкретной версией довольно невелико.

Руби красивы, однако это красота японского самурая с мечем против роты солдат с пулеметами и атомной базукой наперевес в питоне. Страшно но эффективно.
По началу руби действительно выглядят магически красивыми, пока не понимаешь, что красота и эффективность зачастую разные вещи.

Количество батареек в питоне превосходит все мыслимые пределы и совместимость в питон-среде ломать не принято (даже переход на 3ю ветку будет длиться годами и мееедлееноой миграцией, в результате чего к моменту отрубания 2йки на 3ей будут все батарейки)

С изучением питона вы получаете в распоряжение в том числе возможность использования AppEngine.
Руби тоже тоже можно. Есть врапер для jRuby. Я не заметил отстование между 1.9 и питоном ни в скорости, ни в возможностях.
Руби молодой язык, слишком молодой.

  1. Ruby начал разрабатываться 24 февраля 1993 года и вышел в свет в 1995 году.
    Appeared in 1995
  2. В феврале 1991 года Гвидо опубликовал исходный текст в ньюсгруппе alt.sources[7]. С самого начала Python проектировался как объектно-ориентированный язык.
    Appeared in 1991
Сломы языка между минорными версиями говорят о том, что язык молод и несформировался. Питон стабилизировался еще в 1.x
вы забыли о волшебстве с GIL, когда вся ваша армия с атомными базуками и прочим хламом пытается уехать в светлое будущее на одном общим на всех велосипеде .) LLVM и прочий UnladenSwallow до продакшн версии так и не довели. psyco тихо умер, ограничившись х86 платформой. У вас есть что-то еще на примете?
import multiprocessing
это, конечно, клёво, да. Но скорость порождения процесса не сравнить с созданием потока ведь. Вообще об это много копий сломано, на сколько мне не изменяет память, и даже является одним из способов троллинга питонистов. Я просто напомню, что большинство модулей написано с учётом таки проблем с GIL, переписывать их — не сильно подъемная задача. Но это не мешает мне любить питон, не смотря на критику в его адрес =)
кто-то из нас несет бред:

1. Если у вас несколько процессоров/ядер, то задействовать их могут только полновесные ОС потоки, которые не сильно легче процессов (в юниксах так и вообще практически одна сущность).

2. Если у вас один процессор/ядро, то толку от тучи потоков никакой, поскольку в конкретный момент времени может выполняться только один и только один поток/процесс => GIL никак вообще это не ограничивает.

3. Правильный метод проектирования приложений которые задействуют множество процессоров/ядер — разделение на несколько потоков ОС уровня, выделение менеджера, воркеров и использование очередей/пайпов для обмена данными.

Объясните мне по человечески теперь, чем вам мешает GIL?
лично мне — ничем, multiprocessing действительно позволяет обойти проблему GIL, я скорее негодую о существующем багаже модулей, которые решают мои задачи не учитывая этот вариант реализации распараллеливания, на переписывание которых мне не хотелось бы тратить время.
снова бред. Используюя multiprocessing можно использовать абсолютно все модули питона, поскольку внутри каждого процесса продолжает существовать собственный GIL
НЛО прилетело и опубликовало эту надпись здесь
Там тоже есть GIL.
в JRuby GIL-а нет.
А какое есть «волшебство» с GIL?
GIL вполне себе рабочее решение. Ситуация, когда потоки нужны для распаралеливания кода довольно редки. Потому как не всем нужно фрактал им. тов. Мендельброка считать :(. А чаще всего потоки нужны для того, чтобы исключить ожидания длительных операций — работа с сетью, файлами, устройствами ввода/вывода. И с этим питон замечательно справляется.
Спасибо, то что надо :))
Отталкиваться лучше от философии этих проектов.

RoR:
— DRY ( c2.com/cgi/wiki?DontRepeatYourself, en.wikipedia.org/wiki/DRY )
— Convention Over Configuration ( en.wikipedia.org/wiki/Convention_over_configuration )
— REST ( en.wikipedia.org/wiki/Representational_State_Transfer )

Django:
— DRY ( c2.com/cgi/wiki?DontRepeatYourself, en.wikipedia.org/wiki/DRY )
— Explicit is better than implicit ( www.python.org/dev/peps/pep-0020/, line 2)
— много ещё вот тут: docs.djangoproject.com/en/dev/misc/design-philosophies/

Мне нравится в RoR:
— выпендрёжность
— прицнип REST (но можно и Django с ним подружить)
— поддержка NoSQL, CouchDB
— простой деплоймент (nginx+ mod_rails)
— RoR на порядок более известна и распиарена, заказчики её знают… Книжек тоже больше.

Мне не нравится в RoR:
— админка должна быть включена в rails по аналогии с Django
— мне не нравится принцип Convention Over Configuration, а, может, его реализация в RoR
— хелперы используют prototype, а не jQuery (есть расширение jrails, оно меняет..)

Мне нравится в Django:
— документация
— серьёзность системы
— классная админка
— разработчики не стали использовать принцип Convention Over Configuration

Мне не нравится в Django:
— более сложный деплоймент ( basicverbs.com/benchmark-of-django-deployment-techniques/ )
— разработчики не используют прицнип REST как основной (но можно расширить за счёт плагинов и сделать её RESTful)

Вообщем, мне как противнику подхода Convention Over Configuration Django нравится больше. Потому как проще настроить, чем запоминать, что и где системой предусмотрено по умолчанию. И хелперы эти… Для типовых сайтов отлично, для не типовых только путаница…

Также лично для меня Python посимпатичнее Ruby.

Но вообще, для большинства разработчиков было бы лучше (если они знают PHP) выучить PHP ещё лучше и использовать Symfony.
RoR/Django это скорее для тех, кто не хочет использовать php…
и чем же не нравится Convention Over Configuration?
неисползование его приводит в конце пути к тысячестроковым xml файлам йавы :)
В йаве уже для того чтобы это не происходило активно внедряют аннотации.
Просто сложные типовые сайты мне нравится делать на DJEM ( www.djem.ru ) (а совсем простые на бесплатной ModX ( www.modxcms.com ), так получается быстрее — база данных, первичные настройки там уже есть. Вот там как раз очень много договорённостей ( например, в МодХ принято выкладывать картинки в assets/images, а прочие файлы в assets/files и так далее, в DJEM там вообще всё сохраняется в одной таблице, что, учитывая, что используется реляционная БД, мне не очень понятно а также нельзя сделать длинный код у документа в системное поле _code (приходится вводить отдельное поле)… ). То есть злоупотребление принципом Convention Over Configuration очень упрощает систему и сводит все настройки на уровень договорённости. (и хорошо, если эти договоренности можно нарушить)… и кроме того, часть договоренностей такие договоренности, что о них узнаешь только когда натыкаешься на них и думаешь, «а вот почему так?» возникает желание сделать свои костыли для системы, что она учитывала твоё собственное мнение ( что я и сделал для DJEM )

А такие фреймворки как RoR/Django мне нужны для сложных нетиповых сайтов, игр и всяких онлайн сервисов…
то есть я намеренно искал такую систему, где было бы как можно меньше договоренностей, но система должна быть достаточно функциональная, а не «вот тебе ruby/python, сиди программируй»…

Лично мне проще было бы сделать несколько конфигов под типовые проекты чем мириться с тем, что кто-то из разработчиков решит за меня. Ну, а когда типовой конфиг не подходит — я бы его подправил.

То есть хочется более универсальный инструмент для решения любых задач в интернете и не только.

Вот по данному параметру у Django получше… Там, кстати, ещё нравится, что проекта как такового может и не быть, проект = набор приложений. Легко использовать некоторые из них в других проектах.
convention over configuration совершенно не значит что кто-то решил за тебя и ничего не возможно изменить :)
практически любая из conventions в рельсах может быть сконфигуририванна.

не нравится что модель User живёт в таблице «users» – юзай `set_table_name «cheloveki»`

не нравится стандартные директории кде всё лежит — кидай всё где угодно и подправь ActiveSupport::Dependencies.load_paths

мешает «id» как «primary key» — делай `primary_key «cheburashka»` и наслаждайся

не нравится что action «index» рэндерит «foo.html.erb», подключи liquid и рэндери в ручную «bar.liquid»

и т.д. и т.п.

просто кому это нах надо? :) времени жалко и если не «выпендриваться» то можно съэкономить кучу времени если использовать дефолты там гре ето имеет смысл. В этом и заключается одна из прелестей рельсов: надо — конфигь, не надо — не копай :)

а если очень нужно чтоб совсем без дефолтов, то можно и на асме, там совсем всё круто, ну для совсем реальных пацанов :)
Про выпендрежность интересное замечание :) «rails, jquery, git» — абсолютно уверен, что это все отличные штуки, но именно их выпендрежность отталкивала в тот момент, когда стоял вопрос, что бы поизучать — в итоге основные рабочие инструменты теперь — более скучные django, mootools и hg, которыми очень доволен.
Symfony да, крайне приятный фреймворк, если с доктриной то вообще песня.
ваш пост читается как
привет
мой ник лорд — бла бла бла
я тут погуглил про рор и джанго — что бы повыеживаться в этоп топике
но конечно как и большинство хабро-сообщества я пээхээпе недо программист, так что
ваши руби питоны и прочее говно, используйте пээхээпээ — ура УРа
«админка должна быть включена в rails по аналогии с Django» — попробуйте Typus.
А я PHP-шник. :) Выбрал рельсы сначала по той причине, что хорошо предложили. А потом и понял — что просто удобнее. Хотя с РНР было 7 лет. :) (ИМХО).
лично для меня сложны в понимании (тип данных Symbol, блоки кода в качестве аргументов методов)

О-о-о… дружище, если это сложно, то вы еще сделаете для себя много открытий чудных :) Руби на самом деле наркоманский язык с кучей тонкостей и нюансов.
Да нет там нюансов практически. Кроме странной записи class << self (что даёт, понятно, но почему запись именно такая, не понимаю до сих пор).

Ну есть мучение с utf8, но это тоже уже проходили в других языках, вылечат через пару лет :)
нюансов как раз очень даже есть :)

метакласы например, и всевозможные комбинации class+module+instnce_variable+class_variable+inheritance

вот например:

    module M
      def foo
        "module_foo"
      end
    end

    class C
      def foo
        "class_foo"
      end
      include M
    end

    puts C.new.foo


распечатает «class_foo». и я то знаю почему, но это совершенно не очевидно для начинающих, явный «нюанс» :)
зачем начинающему копаться в модулях и классах? :O
mixin'ы, к слову, есть не только в руби.
Такую вещь ещё в стародавние времена заметил один филосов, куда уж понятнее…

Самое занятное, что сбор такой статистики дело естественное и не обходимое, но ни к чему не приводящее — ведь выбор остаётся равнозначным. Так что либо изучи то, что больше по душе показалось, либо кинь монетку ;)
Пишу на руби и рельсах, работаю на них же. Уже давно решил, что следующий мой язык будет пайтон, просто для развития, но в руби нравится все (как и в рельсах).
Не буду писать, что руби лучше, нежели пайтон (потому что он не лучше =), но на данный момент мне руби нравится больше. И да, я знаю, что «в миру» пайтон используется чаще (да-да, гугл и яндекс), но я очень сомневаюсь, что когда-либо попаду в одну из подобных контор:)
Я бы брал питон, его еще в куче мест можно применить окромя веба.
поддерживаю! по этмоу мне тоже интересней Django
Блин, а я когда не в вебе пытался применить, так с простейшими вещами намучился…
Использую Ruby on Rails и практически насильно «привил» эту технологию коллегам по работе :)

Из не упомянутого вами:
табы в питоне убивают)
работы на RoR просто море

На самом деле, мне кажется что в любом случае вы не прогадаете с выбором. Чтобы убедиться в этом, попробуйте, всё-таки, сначала любой из PHP-фремворков.
кстати, табов в питоне быть не должно, знаменитый РЕР-8 настоятельно рекомендует 4 пробела .)
«Табы» (то есть обязательное форматирование) — как раз то, ради чего имеет смысл обратить внимание в первую очередь именно на него :)
Интересное мнение.

Мне кажется, что у человека, который выбирает между Ruby on Rails и Python уже должна быть некоторая культура кодирования.
НЛО прилетело и опубликовало эту надпись здесь
Переписывать — нет, апгрейдить можно и как утверждают, даже за 25 минут;)
Rails3 — это тотально переделаное ядро. Естественно, оно еще не доведено до состояния production-ready. И как минимум до осени вряд ли будет.

И, тем не менее, на rails3 уже запущено несколько проектов.
попробуйте написать несколько простых приложений и на рельсах и на джанго. посмотрите, что удобнее именно вам. Я выбрал рельсы
+ Django используют Google и Яндекс (равняемся на лучших!)

А рельсы используются на www.twitter.com, www.github.com, www.basecamphq.com — тоже довольно известные приложения, особенно первый =)
Твиттер уже, насколько мне известно, переписан на scala
Посмотрите в сторону Scala и их флагмана Liftweb. Я после Питона и Джанги счастлив.

Конечно, путь к админинтерфейсу у Лифта болезнее, чем у Джанги, но ведь это не главное, да и в угоду заказчику ради изменения какой-нибудь надписи приходится всё равно переписывать.

Scala порадовала тем, что в ней функциональное программирование не торчит сбоку как у Питона, и парадигмы ООП реализованы и находятся на своих местах, а не переделываются в что-то маркетолигическое как это сделано в Ruby.

Отдельно насчёт Rails, я сам им когда-то болел, но теперь мне кажется, что половиной своей популярности Rails обязан пиару(который сейчас постепенно сходит на нет), поэтому я бы совсем чуть-чуть его опасался :)
НЛО прилетело и опубликовало эту надпись здесь
Хехе. Интересно, что юзая их ActiveRecord, сначала как все сказал «Вау»(прям как у Пелевина), а потом через некоторое время ощутил, что где-то меня тут обманули :) Так часто бывает с Rails.
НЛО прилетело и опубликовало эту надпись здесь
Люди, но ведь умные люди, которые не ведутся на маркетинг и сами ищут лучшее решение.
НЛО прилетело и опубликовало эту надпись здесь
Кстати кусок инфрастуктуры Твиттера недавно переписали на Scala, т.к. стала всё больше проявлятся врожденная недостаточная масштабируемоть Твиттера.
Скала интересна ровно до тех пор пока решаешь на ней академические задачи.

Плюс надо ооочень хорошо понимать что внутри происходит и во что превращается тот или иной код.

При решении повседневных задач все чаще возникает желание портануться на джаву.

А рекомендовать лифтфреймворк новичку это вообще негуманно.
У меня смутное чувство, что вы говорите про haskell. Вот если в вашем комментарии заменить скала на хаскелл, а лифтфрэймворк на какой-нибудь HAppS тогда будет правильно :)
чем мне не нравится джанго:
1. отсутствие cucumber (если предложите другое адекватное джанго-ориентированное средство BDD, буду только рад и счастлив)
2. ненастраиваемая до тонкостей rails логика валидация ModelForm. Последовательная валидация в заданном порядке с условиями возврата и сброса проверок как-то не получилась. Особенно из-за порядка валидации типизированных полей.

чем мне не нравятся рельсы
1. крайне медленные хелперы. Использование собственных хелперов сильно сказывается на быстродействии проектов.
2. крайне убогий(по сравнению с джанговским ормом) ActiveRecord. Такого количества SQL как там, мне писать не приходилось нигде вообще.

пишу на django вот уже год, до этого работал с C#, asp.net mvc
НЛО прилетело и опубликовало эту надпись здесь
как уже сказали выше — рельсы не очень хорошо переживают отрыв от AR, как не вынесут этого и многие полезные джемы .)
Pyccuracy?
пробовал, не очень хорошо там всё, как минимум из-за того, что работает с selenium, набор селекторов ограничен, как и с русским языком там не всё дружно. Про написание всего сценария на русском я уже умалчиваю. В общем — не понравилось мне .( хочу еще попробовать подружить джангу с pycukes, но пока что не получается.
Тот же рельсовый огурец позволяет тестировать всё, кроме яваскрипта, хотя, знакомые спецы уже и эту проблему видели решенной (есть вариант с selenium, и с capybara
Я, разрабатывая на rails, sql практически не использую. Только если нужно что-то очень хорошо оптимизировать, и то — изредка. Достаточно всего функционала AR. По-моему, вы просто плохо его изучили.
К примеру, для построения отчетов по работе интернет-магазина стандартного функционала AR не хватает и силу хитрой математики. Считать на стороне приложения — ресурсоёмко. Приходится писать SQL включения. А в рельсах я, действительно, новичок, так что буду благодарен, если поправите меня в утверждениях.
Я бы подискуссировал, если бы вы привели конкретный пример )
Python + Django:
— реактивный PyPy уже умеет Django запускать!
— PIP Installs Packages. создаем файлик «deps.txt», пишем там «south django-something django-somethingelse clevercss cssutils» и так далее.
— Fabric ( fabfile.org/ ) + Bazaar VCS.
— Куча готовых приложений для джанги. Регистрация там, вход со всяких фейсбуков, профили, REST API ( bitbucket.org/jespern/django-piston/wiki/Home ), robots.txt и прочие мелочи…
— В комплекте админка, мини-фреймворки для RSS/Atom лент и Sitemap'ов (SEO
А PyPy уже умеет работать с postgre?
Django

— админка. используется всегда и везде. очень просто и красиво;
— clear way. читаемый код (субъективно конечно, но имхо Python чертовски красив);
— готовые приложения. есть для всего;
— документация и обсуждения ньюансов (не сравнивал с Rails но всё что потребуется уже обсуждалось на stackoverflow или на форумах). поддержка;

Рубисты ругают синтаксис пайтона, питонисты ругают синтасис руби. Так было всегда и так будет всегда.

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

Субъективно:

— в rails мировое сообщество дружелюбней и активней.

— тут все питонисты хвалят документацию джанги. Так вот в рельсах она как минимум не хуже. guides.rubyonrails.org/

— по количеству написаных приложений/плагинов django и rails мне сейчас сложно сравнивать — давно не слежу за django. Рельсовые полистай вот здесь, здесь и на github.com

— в джанге, правда, есть магическая админка, которая, впрочем, намертво завязана на djangoвский же orm. Со всеми вытекающими.

Могу дать только один совет: попробуй реализовать небольшое приложение и на rails и на django, чтобы сравнить подходы. И в той и в другой технологиях есть свои компромисы.

Сам я года два назад плотно работал с django (0.96 — stable, 0.97 — trunk). Сейчас же считаю, что для web-frontend'а ничего лучше rails не существует.
А теперь попробуй Django 1.2 :)
Сравнивать надо не количество, а качество приложений. В рельсах есть что-нибудь подобное bitbucket.org/slav0nic/django-flickrstorage bitbucket.org/offline/django-publicauth или github.com/myfreeweb/django-elsewhere? А github.com/jtauber/django-friends? Вот github.com/danfairs/django-lazysignup точно нет.
Ну расскажите мне, что же в Django 1.2 так кардинально поменялось?
НЛО прилетело и опубликовало эту надпись здесь
К слову, SqlAlchemy очень вкусный. Я его с pylons в основном юзал.
Сам-то смотрел прежде чем утверждать?
github.com/commonthread/flickr_fu
По аутентификации полно плагинов хороших и разных

Я так же могу сказать, что для django нет аналогов github.com/bborn/communityengine, но это будет глупо, как и твой комментарий. Также рекомендую посмотреть и восхититься ActiveResource. Ведь аналогов для джанги нет!
Я ничего не утверждал. Я спросил.
Сегодня (24-го) числа, Rails team сделали шикарный подарок всем своим пользователям — выпустили Rails 2.3.6, который не работал, а затем Rails 2.3.7, который так же отказывался частично работать, при этом я начал переводить все проекты на новые рельсы. Откатился на 2.3.5. Очень не приятно.
между тем, уже 2.3.8, я как-то переходы 2.3.5 -> 2.3.8 пропустил, не до обновлений было, так что меньшей кровью всё обошлось. Но осадок от нерабочих остался хотя бы по отклику сообщества.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Когда-то тоже выбирал между Django и Rails.
Выбрал Rails.
Аналогичная проблема, особенно ожидании грядущего Rails 3.0. После PHP я решил изучить новый скриптовый язык, выбрал Python. Потом с вебом соответственно Django. Но всегда тянуло изучить Ruby и Rails. После прочтения «Programming Ruby: The Pragmatic Programmers' Guide, Second Edition», «Rails Guides» и «Путь Rails» и руби и рельсы очень впечетлили. Ruby — синтаксис, блоки, возможность изменять даже стандартный класс, разнообразие символов и т.д. А Rails — Convention over Configuration, REST, более удобный шаблонизатор чем django templates, миграции из коробки. Но есть и минусы по сравнению с django — запросы не ленивые и не составляются в цепочки, нет динамической админки (хотя полезность ее для меня уменьшилась, мне сейчас кажется что проще её делать под каждый проект), отсутствие компонента аналогичного django forms. Но в Rails 3 добавлена нормальная реляционная алгебра (Arel), получается для меня рельсы еще больше выигрывают. На django сделал пару проектов со средней сложности (сайт знакомств и каталог квартир). Вот этим летом хочу написать средний проект на рельсах, что бы прочувствовать.
Для форм есть много плагинов и гемов интересных, типа formtastic.

Вместо ленивых запросо я использую хэш параметров, который раскрываю только в последнюю очередь. Кстати, DataMapper поддерживает цепочки.

Админка — Typus.
AR в 3-их рельсах вроде научился ленивым запросам
Уххх. Перечитал весь тред, т.к. тоже пытаюсь определиться. Изначально думал в сторону РоР. В процессе чтения подколбашивало из стороны в сторону в итоге всё же решил взяться за РоР. Возможно и из-за того, что сам считаю что нужно заниматься тем, что больше нравиться, а лежит сейчас больше к РоР, к тому же и 3.0 как раз вышел. Ну и пара полезных названий типа Typus и DataMapper, за что отдельное спасибо…

И только одно продолжает свербить затылок — Google и Яндекс :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.