Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 215
Мы Rails используем и довольны.
>Ruby — интереснее и красивее Python
Довольно субъективно. Объективно, что синтаксис богаче. А красив ли код полный спецсимволом — решает каждый для себя.
>перезагружать приложение после каждого изменения server-side-кода
В -dev режиме django не нужно перезагружать приложение после изменения кода.
Довольно субъективно. Объективно, что синтаксис богаче. А красив ли код полный спецсимволом — решает каждый для себя.
>перезагружать приложение после каждого изменения server-side-кода
В -dev режиме django не нужно перезагружать приложение после изменения кода.
>В -dev режиме django не нужно перезагружать приложение после изменения кода.
Можно поподробнее? У меня, почему-то, изменения не применяются что без --noreload, что с ним, а если его нет, то ещё и runserver продолжает висеть в процессах, даже если в эклипсе я остановил выполнение.
Можно поподробнее? У меня, почему-то, изменения не применяются что без --noreload, что с ним, а если его нет, то ещё и runserver продолжает висеть в процессах, даже если в эклипсе я остановил выполнение.
Странное поведение. В дев-режиме, конечно, сервер перезагружать тоже надо, просто он делает это автоматически. А при изменении темплейтов и этого не требуется.
С темплейтами всё нормально, поэтому я и написал про server-side. И ещё я читал, что это распространённая проблема, например, в pyCharm --noreload включён по умолчанию именно из-за такого поведения
Ключевое в вашей проблеме это — «в эклипсе». Девелопмент сервер отлично перезагружает код после изменения. Не у всех IDE получается с этим интегрироваться.
рельса в режиме разработки тоже не нужно перезагружать
Я опоздал %)
Руби — это ASCII-арт какой-то. Python очень красив отсутствием лишних знаков.
Руби — это ASCII-арт какой-то. Python очень красив отсутствием лишних знаков.
Пример в студию
Первый попавшийся файл с расширением rb :)
Например, github.com/mxcl/homebrew/blob/master/Library/Homebrew/install.rb
«if f.keg_only? == :provided_by_osx» — что за вопрос и двоеточие?
«rescue Exception => e» — что за стрелочка такая??
Например, github.com/mxcl/homebrew/blob/master/Library/Homebrew/install.rb
«if f.keg_only? == :provided_by_osx» — что за вопрос и двоеточие?
«rescue Exception => e» — что за стрелочка такая??
то же самое и в руби =)
сначала непонятно, что значит вопрос или воскл. знак в конце метода, но потом понимаешь, что все это не просто так, и на самом деле очень просто объясняется.
Вопрос ставится, если функция возвращает только true/false
А восклицательный знак — если функция меняет сам объект, а не возвращает значение, т.е. чтобы не писать foo = foo.downcase, а сразу написать foo.downcase!
Но для меня всегда было непонятным, зачем в языках типо питона (явы, с++ и т д) ставить обязательные скобочки в названиях функций. Ведь это только ухудшает читабельность кода и заставляет писать два ненужных символа.
сначала непонятно, что значит вопрос или воскл. знак в конце метода, но потом понимаешь, что все это не просто так, и на самом деле очень просто объясняется.
Вопрос ставится, если функция возвращает только 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
Моё субъективное мнение: Питон+Джанго офигительная связка, но с рельсами я даже отдалённо не знаком, так-что имейте ввиду.
И по моим наблюдениям, тут Джанго-фанатов побольше будет, а значит объективность будет нулевая.
Вот здесь более-менее объективное сравнение 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 у нас не найдешь, разве что самому стартап начинать. А так изучение было бы полезно во всяком случае.
Говорю «академический» потому что могут возникнуть проблемы с хостингом, да и работу в вебе на Smalltalk у нас не найдешь, разве что самому стартап начинать. А так изучение было бы полезно во всяком случае.
Начните с того, что больше по душе, а дальше будь что будет. Средства и способы разработки не стоят на месте, поэтому с большой вероятностью в будущем все равно придется переучиваться.
Выбрать объективизм более лучшую и перспективную технологию вы сейчас не сможете, т.к. нет опыта работы ни с одной из них. Спрашивать тут бесполезно, т.к. голоса знающих обе эти технологии потонут в общем потоке.
Выбрать объективизм более лучшую и перспективную технологию вы сейчас не сможете, т.к. нет опыта работы ни с одной из них. Спрашивать тут бесполезно, т.к. голоса знающих обе эти технологии потонут в общем потоке.
Я выбирал года два назад. Для этого сделал по-небольшому приложению на django и rails. Выбрал то, на чем писать было удобнее лично мне.
Оба варианта хороши.
Есть несколько вещей, которые ещё стоит учесть:
— у Django чертовски хорошая документация
— Ruby более гибкий, на мой взгляд, язык, чем python. Те же блоки кода в качестве аргументов — отличная вещь когда научишься ими пользоваться.
— Django состоит из отдельных (довольно толковых) компонентов связываемых удобным питоновым кодом
— Rails связывает компоненты скрытой магией, что может и само по себе сбивать с толку и затруднять возможность делать что-то нестандартное
Ну и в конце концов, выбери проект, который будешь делать, от него и пляши — выбирай, что удобнее.
— у Django чертовски хорошая документация
— Ruby более гибкий, на мой взгляд, язык, чем python. Те же блоки кода в качестве аргументов — отличная вещь когда научишься ими пользоваться.
— Django состоит из отдельных (довольно толковых) компонентов связываемых удобным питоновым кодом
— Rails связывает компоненты скрытой магией, что может и само по себе сбивать с толку и затруднять возможность делать что-то нестандартное
Ну и в конце концов, выбери проект, который будешь делать, от него и пляши — выбирай, что удобнее.
Чи не все равно?
Посмотрите Grails, тем более если Java уже осваивается.
Я считаю, что Grails стоит изучать после Rails. Ибо начинать с Groovy/Grails достаточно сложно, а после руби и рельсов сразу видны все те подпорки, которые использовались для связки джавы с руби-образными языковыми конструкциями и концепциями рейлз.
разве? как по мне, так grails как раз гораздо проще изучать…
На первых порах closures в Groovy будут казаться синтаксическим сахаром для function objects в Java. В динамическом типизировании ничего сложного нет. Так что не вижу особого смысла учить целый новый язык+стек со своими заморочками.
Хотя я лично, последнее время все больше склоняюсь от Grails в сторону Roo + Vaadin/GWT. Groovy лишь как скриптовой или dsl.
Хотя я лично, последнее время все больше склоняюсь от Grails в сторону Roo + Vaadin/GWT. Groovy лишь как скриптовой или dsl.
можно поменять ActiveRecord на мербовый DataMapper — там вместо миграций используются описания полей в модели =)
Лично мне он даже больше AR'a нравится
Лично мне он даже больше AR'a нравится
Попробуйте-ка вести совместную разработку без использования миграций
" То, что говорят насчет «в Rails больше магии» — это не совсем так. "
нет ну понятно что это всё достигается засчёт интроспекции самого ruby
но если забыть про это то многое действительно кажется магическим.
нет ну понятно что это всё достигается засчёт интроспекции самого ruby
но если забыть про это то многое действительно кажется магическим.
Блоки кода особенно впечатляют, если я правильно помню, там можно еще расширять стандартные классы (как, например, в C#, про другие не знаю).
В С# можно добавлять только статические методы к классам, если не изменяет память. В Руби можно изменять любые методы (класса или инстанса), какие в голову взбредут, в том числе и «перекрывать» уже написанные.
Насчет миграций в Rails — мое личное мнение, это отстой
Можно попробовать другие подходы к ORM, к примеру как у DataMapper'a.
Автору: не совсем по теме совет, но все же, попробуйте Sinatra www.sinatrarb.com/, в академических целях хотя бы :) Возможно, будет проще ориентироватся во «взрослых» фреймворках, типа рельс, ну и с блоками разберетесь. Ну и рельсоводы сейчас бурно ожидают 3-е пришествие Рельсы с тотальным агностицизмом, возможно, вам пока имеет смысл изучить Django или все же бету Rails 3.
>Werkzeug + Jinja2 + WTForms + SqlAlchemy
а лучше pylons конечно
а лучше pylons конечно
> поддержка миграций «из коробки»
South (http://south.aeracode.org/) для Django вполне хорош. Он не «из коробки», но начать его использовать в проекте — дело максимум 10-и минут.
South (http://south.aeracode.org/) для Django вполне хорош. Он не «из коробки», но начать его использовать в проекте — дело максимум 10-и минут.
Хорошая штука. В одном проекте сейчас под сотню миграций на south, все устраивает.
В django 1.2 был отклоненный proposal на включение его в стандартную поставку, который был отклонен по желанию автора south, т.к. идет активная разработка и включение на этом этапе в django будет мешать — появится привязанность к неторопливым релизам django, например.
В 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.
Думаю, автору стоит выделить один день под это дело, поставить оба фреймворка и попробовать сделать какой-нибудь простой проект, например новостную ленту с комментами. Что больше понравится — то и использовать -)
Лично я пользуюсь рельсами и доволен. Мне очень нравится синтаксис Ruby, нравится отсутствие необходимых скобок в именах процедур — foo.bar вместо foo.bar() или какого-нить foo.__bar__() выглядит намного приятнее.
Насчет скорости — это не такая уж проблема, приложение работает почти в несколько раз быстрее на Ruby 1.9.
Я бы стал писать на питоне, если бы мне нужно было разрабатывать не только веб-приложение, но еще и например, десктопную версию. Питон в этом плане как-то более приспособлен, нежели Ruby.
Думаю, автору стоит выделить один день под это дело, поставить оба фреймворка и попробовать сделать какой-нибудь простой проект, например новостную ленту с комментами. Что больше понравится — то и использовать -)
Для начала вообще не мешает определиться, а что же именно тебе интересно разрабатывать. А уже после этого и выбирать язык. Как вариант, посмотреть какие проекты в интернете написаны на Django, какие на Ruby.
Из личного опыта — знаю компанию, которая зарабатывает, создавая сервисы на Ruby, очень неплохие деньги. С другой стороны сам участвовал в проекте на Django. Чужой незнакомый код был более чем понятен.
Сам как явашник больше склоняюсь к Ruby, а точнее к Grails. Очень интересный язык/фреймворк.
Из личного опыта — знаю компанию, которая зарабатывает, создавая сервисы на Ruby, очень неплохие деньги. С другой стороны сам участвовал в проекте на Django. Чужой незнакомый код был более чем понятен.
Сам как явашник больше склоняюсь к Ruby, а точнее к Grails. Очень интересный язык/фреймворк.
У нас есть здоровенный проект на Grails, кода много — несколько человек трудилось два года. Могу сказать, что тесная интеграция с джавой и спрингом — единственное преимущество этого фрейворка над другими обсуждаемыми. Grails может быть очень полезен, если нижележащая логика написана на Джаве или надо написать много кода (на джаве), не имеющего отношения к обработке веб-запросов. Однако сам Groovy глючит, и весь Grails глючит так же, неочевидно и не всегда исправимо. Это касается и тех частей где, казалось бы, можно откатиться к спрингу или «родному» hibernate-у. Производительность средняя (загляните в Yourkit на запущенное приложение Grails, удивитесь).
согласен с вами — для меня преимущество Grails — тесный контакт с явой, так как фирма ориентированна именно на яву. А какие глюки были замечены?
Да много разных, особенно доставляют те, где проблема решается переименованием переменной или переставлением двух не связанных строк между собой. Общий смысл — что-то происходит с кодом неочевидно и практически неотслеживаемо.
Я бы предпочел больше Джавы, и меньше Groovy. Как прекрасно было бы иметь в Grails-приложении все на Джаве (в спринге, особенно стартап-код, инициализацию), а от Grails оставить _только_ контроллеры и представления, и чтобы на стыке все работало как надо! Собственно, эта скриптовая часть и подкупает больше всего, позволяя в одном проекте совместить труд программиста некоторой сложной подсистемы (и интеграционной к ней логики) на Джаве и традиционный «скриптовый» подход веб-разработчиков. От остального остается двоякое впечатление — от великолепных Spring и Hibernate в интерпретации Grails остается какое-то, не побоюсь сказать, убожество.
Насчет Groovy есть такое мнение, что на JVM он ложится с большим трудом. При этом образуются тысячи (десятки, сотни тысяч) объектов типа Closure, которые не поддаются никакому профилированию и здорово загаживают память. Получаемый байткод для довольно простых операций вообще ни разу не оптимален, по использованию как памяти, так и процессора.
Я бы предпочел больше Джавы, и меньше Groovy. Как прекрасно было бы иметь в Grails-приложении все на Джаве (в спринге, особенно стартап-код, инициализацию), а от Grails оставить _только_ контроллеры и представления, и чтобы на стыке все работало как надо! Собственно, эта скриптовая часть и подкупает больше всего, позволяя в одном проекте совместить труд программиста некоторой сложной подсистемы (и интеграционной к ней логики) на Джаве и традиционный «скриптовый» подход веб-разработчиков. От остального остается двоякое впечатление — от великолепных Spring и Hibernate в интерпретации Grails остается какое-то, не побоюсь сказать, убожество.
Насчет Groovy есть такое мнение, что на JVM он ложится с большим трудом. При этом образуются тысячи (десятки, сотни тысяч) объектов типа Closure, которые не поддаются никакому профилированию и здорово загаживают память. Получаемый байткод для довольно простых операций вообще ни разу не оптимален, по использованию как памяти, так и процессора.
Печаль ТТ как говорится, в жизни все не так как на самом деле. В любом случае, спасибо за ответ!
Увы, чтобы отдавать шаблоны, все равно придется использовать либо голые сервлеты со своей логикой, либо какой-то еще фреймворк. Как представления связываются по данным с бекендом — не самое главное, важнее — как мы избегаем превращения представлений в помойку. Grails тут отлично все раскладывает по полочкам.
>несколько человек трудилось два года
grails 2 года назад и grails сегодня — это довольно большая разница в стабильности, производительности итд, вы не находите?
grails 2 года назад и grails сегодня — это довольно большая разница в стабильности, производительности итд, вы не находите?
Ну вот что-что, а стабильность и легкий дебаг у меня с Grails не ассоциируются, так что товарищ во многом прав.
Кстати, занимательный факт) Единственная книжка на русском в Java направлении в этом году по Grails — www.ozon.ru/?context=search&group=nonfiction&text=java&sort=year
Кстати, занимательный факт) Единственная книжка на русском в Java направлении в этом году по Grails — www.ozon.ru/?context=search&group=nonfiction&text=java&sort=year
Мы переходили пару раз на новые версии, можно считать, что фреймворк годичной даывности. Не исключаю, что в последних релизах все могло стать несколько стабильнее (судя по багтрекеру, дырки закрываются), кроме того, есть много удобных плагинов, однако в том, как платформа устроена, не поменялось ничего. Groovy же, который я имел несчастье использовать в другом проекте, не изменился вообще — все то же множество глупых объектов в памяти и неэффективный код.
У меня есть хороший знакомый который стал писать на джанге потому что не переносил руби и пхп, а на питоне кодил пару лет.
Я стал писать на рельсах потому что не люблю питон и не знаю пхп, но имею опыт руби-кодинга.
Все просто. А любая попытка сравнить RoR и Django или Ruby и Python обречена на холивар
Я стал писать на рельсах потому что не люблю питон и не знаю пхп, но имею опыт руби-кодинга.
Все просто. А любая попытка сравнить RoR и Django или Ruby и Python обречена на холивар
Холивара тут не возникнет =)
программеры на Ruby и Python как правило относятся друг к другу с уважением, а не с ненавистью.
программеры на Ruby и Python как правило относятся друг к другу с уважением, а не с ненавистью.
Какие-то у вас сферические обобщения. И там и там люди со своими тараканами, даже на Хабре относительно недавно был срач на тему python и php, так неадекватов было с обоих сторон хоть отбавляй, некоторым сложно понять что ЯП — инструмент а не религия.
Тролли такие php-исты. Я последнее время работаю с php, был проект и на RoR, поводов для холивара не было.
хзхз
у нас в конфе состояние перманентного срача с писькомерством. Рубисты и питонщеги объединяются только против пхпистов.
у нас в конфе состояние перманентного срача с писькомерством. Рубисты и питонщеги объединяются только против пхпистов.
Мои пять копеек. Работал с РНР 6 лет, пересел на Rails. Понял, что жизнь прекрасна, когда заработал на MacBook PRO — понял что жизнь с Rails велликолепна! Попробовал textmate. Пока не знаю, чего еще желать, кроме как спокойно работать языком и фреймворком, который нравится. Максимум эффективности и продуктивности — Rails. Конечно это не реклама, а ИМХО.
Питоноводов не хочу обидеть, но я просто не пробовал питон. Говорят, класс, но каждый выбирает для себя. Все же — каждый язык и фреймворк — для своей цели. Все зависит от прямоты рук. ;) Питон попробую когда нибудь с Django. ;)
Питоноводов не хочу обидеть, но я просто не пробовал питон. Говорят, класс, но каждый выбирает для себя. Все же — каждый язык и фреймворк — для своей цели. Все зависит от прямоты рук. ;) Питон попробую когда нибудь с Django. ;)
только что запустил рельсы, на рельсах 1 небольшой проект 1.1% от 2024Mb = 22.22Mb
прочитав несколько форумов, могу лишь процитировать одного умного человека:
«быстродействие и отжираемость ruby\python\php приложений обратно пропорциональна кривизне рук»
прочитав несколько форумов, могу лишь процитировать одного умного человека:
«быстродействие и отжираемость ruby\python\php приложений обратно пропорциональна кривизне рук»
Веб-сервер какой?
Я юзал mongrel, получалось около 30 метров на процесс. Сейчас очень хочу перейти на mod_passenger для Apache.
Если кто-нибудь на больших проектах юзал, скажите, есть ли выигрыш в производительности?
Я юзал mongrel, получалось около 30 метров на процесс. Сейчас очень хочу перейти на mod_passenger для Apache.
Если кто-нибудь на больших проектах юзал, скажите, есть ли выигрыш в производительности?
Согласен. Mac OS + Textmate + Rails это рай для веб-разработчика =)
А можете рассказать, что здесь такого классного? А то я много отзывов хвалебных слышал, но без конкретики… За что этот TextMate так любят?
За то что редактор простой и очень удобный) Попробуйте e-texteditor под windows — аналог textmate и все поймете)
Я под линуксом сижу :) Тут аналоги есть? Может, vim?
gmate — github.com/gmate/gmate
— gedit (с плагинами для Rails), для начала неплохо, если с gtk нет проблем. habrahabr.ru/blogs/ubuntu/74355/
— RubyMine — 99$, все классно, но не бесплатно. www.jetbrains.com/ruby/
— RedCar если 0.3 версия вас не пугает, ознакомьтесь redcareditor.com/
— RubyMine — 99$, все классно, но не бесплатно. www.jetbrains.com/ruby/
— RedCar если 0.3 версия вас не пугает, ознакомьтесь redcareditor.com/
я долгое время пользовался вим/гвим на linux и был очень доволен, но когда
лет 5 назад перешел на мак и рельсы то начал пользоваться textmate
т.к. на тот момент было трудно сравниться с ним в удобстве разработки
на руби. но мне всё это время чего-то не хватало. время от времени ловил
себя на том что делаю лишние «пальцедвижения» для чего-то что в вим
решается буквально парой нажатий на кнопки :)
короче, пару месяцев назад, в очередной раз прочитаб как кто-то вернулся в
в vim из textmat-а я решил отложитъ мейт и какое-то время попробовать
вернутся в вим.
немного помучался в начале пока всё не настроил, но теперь очень доволен
и возвращаться в мейт не намерен.
если интересно мои вим настройки для руби/рельсов на виме тут:
github.com/astrails/dotvim
там есть README с кучей «интересностей»
работает на маке и *никсах.
лет 5 назад перешел на мак и рельсы то начал пользоваться textmate
т.к. на тот момент было трудно сравниться с ним в удобстве разработки
на руби. но мне всё это время чего-то не хватало. время от времени ловил
себя на том что делаю лишние «пальцедвижения» для чего-то что в вим
решается буквально парой нажатий на кнопки :)
короче, пару месяцев назад, в очередной раз прочитаб как кто-то вернулся в
в vim из textmat-а я решил отложитъ мейт и какое-то время попробовать
вернутся в вим.
немного помучался в начале пока всё не настроил, но теперь очень доволен
и возвращаться в мейт не намерен.
если интересно мои вим настройки для руби/рельсов на виме тут:
github.com/astrails/dotvim
там есть README с кучей «интересностей»
работает на маке и *никсах.
А в чем, пардон, принципиальная разницы Macbook PRO + Rails + Textmate против Thinkpad + Ubuntu + RubyMine?
Вопрос не для холивара, сам второй год думаю над переходом, но объективных доводов в достаточном количестве так и не насобирал.
Вопрос не для холивара, сам второй год думаю над переходом, но объективных доводов в достаточном количестве так и не насобирал.
Начал изучать Ruby и Rails. Ruby как язык очень нравится, просто тащусь от него. Rails кажется каким то огромным монстром. Сегодня узнал про Sinatra, HAML, Thin, попробовал и понял вот оно! С этого то и начну.
Из личного опыта: сначала принялся за питон+джанго, даже сделал два несложных проекта на них. Автоадминка в джанге вещь суперская, но вот как-то в этих двух проектах не пригодилась.
Потом попробовал руби и рельсы, да там и остался, потому что (субьективно):
Потом попробовал руби и рельсы, да там и остался, потому что (субьективно):
я в свое время наслушался про то какая классная админка в джанге и как все плохо в рельсах.
Но потом я нашел typus X)
Но потом я нашел typus X)
спасибо за typus. какое-то время назад я искал полу/авто админ под релисы и ничего
действительно классного не нашел. остановился на neerajdotname.github.com/admin_data/
но не очень доволен. буду пробовать типус. вроде неплох
действительно классного не нашел. остановился на neerajdotname.github.com/admin_data/
но не очень доволен. буду пробовать типус. вроде неплох
Кстати, вот тут есть интересная статья о выборе «что же учить из языков» — ru.wikibooks.org/wiki/Ruby/Идеология (середина статьи, раздел «Какой язык программирования учить первым?»)
Ты главное не торопись, а то еще, чего доброго, не то выберешь.
Человек, который не может самостоятельно для себя сделать выбор между двумя технологиями, изучив область знаний и погуглив, вообще программистом быть не может.
бред.
обе две эти технологии служат для одинаковых целей.
языки на которых они основывается похожи (хотябы динамичностью)
и в вебе ведут себя похожим образом.
обе эти вещи популярны.
и уверне что на глаз по коду и струкруте нельзя определить что будет лучше и интереснее.
для этого и существуют коллеги (в широком смысле) которые могу высказатсья, и уже на их опыте можно сделать более точное предположение
обе две эти технологии служат для одинаковых целей.
языки на которых они основывается похожи (хотябы динамичностью)
и в вебе ведут себя похожим образом.
обе эти вещи популярны.
и уверне что на глаз по коду и струкруте нельзя определить что будет лучше и интереснее.
для этого и существуют коллеги (в широком смысле) которые могу высказатсья, и уже на их опыте можно сделать более точное предположение
сорр «уверен » и «высказаться»
Почему другие люди должны знать, что лучше и интереснее для него?
Не замечал за людьми нашей профессии стадного инстинкта.
Не замечал за людьми нашей профессии стадного инстинкта.
а если перечитать?
не?
я не говорил что другие должны говорить что лучше и красивее.
они говорят собственное мнение, а автор вопроса, да и любой человек уже по ним определяет степень того насколько это ему подходит
не?
я не говорил что другие должны говорить что лучше и красивее.
они говорят собственное мнение, а автор вопроса, да и любой человек уже по ним определяет степень того насколько это ему подходит
Сначала надо с языком определится, потом уж ясно станет. Фреймворки как мода приходят и уходят, постоянно перенимают новые фичи. Языки все-таки несколько медленнее меняются и ассимилируются, переход между одним излюбленным языком к другому более болезненный.
Мне лично руби очень понравился, вряд ли слезу с него в ближайшее время.
Мне лично руби очень понравился, вряд ли слезу с него в ближайшее время.
Рекомендую также принять к сведению:
Оу, а вот это интересно, спасибо!
нет, интереснее вот это => www.google.com/trends?q=django%2C+ruby+on+rails
неправильное сравнение =)
половина запросов по django вообще не имеет отношения к языку. Вон там справа есть ссылки:
половина запросов по django вообще не имеет отношения к языку. Вон там справа есть ссылки:
Да, поэтому вот такое сравнение может быть правильней: www.google.com/trends?q=python+django,+ruby+on+rails&ctab=0&geo=all&date=all&sort=0
Парсер лох… ссылка
как-бы, фреймворк был назван в честь джаззмена, поэтому и неудивительно, что вы найдёте кучу инфы о некоем мистере Рейнхарде. Но самый сок будет, если вы внезапно захотите попробовать grappelli .)
ну для полноты картины
ну и для полноты картины
www.indeed.com/trendgraph/jobgraph.png?q=django%2C+ruby+on+rails%2C+php%2C+ruby%2C+python
www.indeed.com/trendgraph/jobgraph.png?q=django%2C+ruby+on+rails%2C+php%2C+ruby%2C+python
Бери Rails )
вне конкуренции.
и будет тебе свобода.
( сам использую и django и rails)
по поводу типа symbol всё просто) относись к ним как к облегчённым строкам… без кучи методов…
вне конкуренции.
и будет тебе свобода.
( сам использую и django и rails)
по поводу типа symbol всё просто) относись к ним как к облегчённым строкам… без кучи методов…
и забыл добавить что
более ярко выраженная в rails «Convention over configuration»
просто чёртовски охренительная вещь…
более ярко выраженная в rails «Convention over configuration»
просто чёртовски охренительная вещь…
Лично мне сам язык Python намного меньше нравится… В ruby все более красиво выглядит. После PHP пробовал изучить оба языка и фреймворка — ruby как то ближе по идеологии. Но в рельсах как то магия иногда пугает — хочется знать почему оно так и как работает, в джанго в этом плане попроще.
Для себя я выбрал ROR, но джанго потихоньку изучаю, ведь нельзя стоять на месте )
И просто небольшая история — как то раз я делал на PHP для себя проект небольшой, и у меня был затык на структуре БД. Было несколько вариантов и я долго думал как правильнее, спрашивал на форумах, хотелось сделать удобно и красиво…
Вот так я долго думал в итоге мне просто надоел проект, появились другие)
Так что если вы под впечатлением от ROR — начните с него. Изучите — вот и хорошо, с django судьба все равно сведет рано или поздно)
Для себя я выбрал ROR, но джанго потихоньку изучаю, ведь нельзя стоять на месте )
И просто небольшая история — как то раз я делал на PHP для себя проект небольшой, и у меня был затык на структуре БД. Было несколько вариантов и я долго думал как правильнее, спрашивал на форумах, хотелось сделать удобно и красиво…
Вот так я долго думал в итоге мне просто надоел проект, появились другие)
Так что если вы под впечатлением от ROR — начните с него. Изучите — вот и хорошо, с django судьба все равно сведет рано или поздно)
Руби молодой язык, слишком молодой. На многих стабля-дистрах вида долбияна или редхата вы увидите страшно старые версии руби. Обновления языка в недавнем прошлом (незнаю как сейчас) имели свойство ломать совместимость к черту из-за чего количество батареек в руби совместимых с конкретной версией довольно невелико.
Руби красивы, однако это красота японского самурая с мечем против роты солдат с пулеметами и атомной базукой наперевес в питоне. Страшно но эффективно.
По началу руби действительно выглядят магически красивыми, пока не понимаешь, что красота и эффективность зачастую разные вещи.
Количество батареек в питоне превосходит все мыслимые пределы и совместимость в питон-среде ломать не принято (даже переход на 3ю ветку будет длиться годами и мееедлееноой миграцией, в результате чего к моменту отрубания 2йки на 3ей будут все батарейки)
С изучением питона вы получаете в распоряжение в том числе возможность использования AppEngine.
Руби красивы, однако это красота японского самурая с мечем против роты солдат с пулеметами и атомной базукой наперевес в питоне. Страшно но эффективно.
По началу руби действительно выглядят магически красивыми, пока не понимаешь, что красота и эффективность зачастую разные вещи.
Количество батареек в питоне превосходит все мыслимые пределы и совместимость в питон-среде ломать не принято (даже переход на 3ю ветку будет длиться годами и мееедлееноой миграцией, в результате чего к моменту отрубания 2йки на 3ей будут все батарейки)
С изучением питона вы получаете в распоряжение в том числе возможность использования AppEngine.
Руби тоже тоже можно. Есть врапер для jRuby. Я не заметил отстование между 1.9 и питоном ни в скорости, ни в возможностях.
Руби молодой язык, слишком молодой.
- Ruby начал разрабатываться 24 февраля 1993 года и вышел в свет в 1995 году.
Appeared in 1995 - В феврале 1991 года Гвидо опубликовал исходный текст в ньюсгруппе alt.sources[7]. С самого начала Python проектировался как объектно-ориентированный язык.
Appeared in 1991
AppEngine можно и с Руби пользоваться: code.google.com/p/appengine-jruby/
вы забыли о волшебстве с GIL, когда вся ваша армия с атомными базуками и прочим хламом пытается уехать в светлое будущее на одном общим на всех велосипеде .) LLVM и прочий UnladenSwallow до продакшн версии так и не довели. psyco тихо умер, ограничившись х86 платформой. У вас есть что-то еще на примете?
import multiprocessing
это, конечно, клёво, да. Но скорость порождения процесса не сравнить с созданием потока ведь. Вообще об это много копий сломано, на сколько мне не изменяет память, и даже является одним из способов троллинга питонистов. Я просто напомню, что большинство модулей написано с учётом таки проблем с GIL, переписывать их — не сильно подъемная задача. Но это не мешает мне любить питон, не смотря на критику в его адрес =)
кто-то из нас несет бред:
1. Если у вас несколько процессоров/ядер, то задействовать их могут только полновесные ОС потоки, которые не сильно легче процессов (в юниксах так и вообще практически одна сущность).
2. Если у вас один процессор/ядро, то толку от тучи потоков никакой, поскольку в конкретный момент времени может выполняться только один и только один поток/процесс => GIL никак вообще это не ограничивает.
3. Правильный метод проектирования приложений которые задействуют множество процессоров/ядер — разделение на несколько потоков ОС уровня, выделение менеджера, воркеров и использование очередей/пайпов для обмена данными.
Объясните мне по человечески теперь, чем вам мешает GIL?
1. Если у вас несколько процессоров/ядер, то задействовать их могут только полновесные ОС потоки, которые не сильно легче процессов (в юниксах так и вообще практически одна сущность).
2. Если у вас один процессор/ядро, то толку от тучи потоков никакой, поскольку в конкретный момент времени может выполняться только один и только один поток/процесс => GIL никак вообще это не ограничивает.
3. Правильный метод проектирования приложений которые задействуют множество процессоров/ядер — разделение на несколько потоков ОС уровня, выделение менеджера, воркеров и использование очередей/пайпов для обмена данными.
Объясните мне по человечески теперь, чем вам мешает 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…
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 файлам йавы :)
неисползование его приводит в конце пути к тысячестроковым xml файлам йавы :)
В йаве уже для того чтобы это не происходило активно внедряют аннотации.
Просто сложные типовые сайты мне нравится делать на DJEM ( www.djem.ru ) (а совсем простые на бесплатной ModX ( www.modxcms.com ), так получается быстрее — база данных, первичные настройки там уже есть. Вот там как раз очень много договорённостей ( например, в МодХ принято выкладывать картинки в assets/images, а прочие файлы в assets/files и так далее, в DJEM там вообще всё сохраняется в одной таблице, что, учитывая, что используется реляционная БД, мне не очень понятно а также нельзя сделать длинный код у документа в системное поле _code (приходится вводить отдельное поле)… ). То есть злоупотребление принципом Convention Over Configuration очень упрощает систему и сводит все настройки на уровень договорённости. (и хорошо, если эти договоренности можно нарушить)… и кроме того, часть договоренностей такие договоренности, что о них узнаешь только когда натыкаешься на них и думаешь, «а вот почему так?» возникает желание сделать свои костыли для системы, что она учитывала твоё собственное мнение ( что я и сделал для DJEM )
А такие фреймворки как RoR/Django мне нужны для сложных нетиповых сайтов, игр и всяких онлайн сервисов…
то есть я намеренно искал такую систему, где было бы как можно меньше договоренностей, но система должна быть достаточно функциональная, а не «вот тебе ruby/python, сиди программируй»…
Лично мне проще было бы сделать несколько конфигов под типовые проекты чем мириться с тем, что кто-то из разработчиков решит за меня. Ну, а когда типовой конфиг не подходит — я бы его подправил.
То есть хочется более универсальный инструмент для решения любых задач в интернете и не только.
Вот по данному параметру у Django получше… Там, кстати, ещё нравится, что проекта как такового может и не быть, проект = набор приложений. Легко использовать некоторые из них в других проектах.
А такие фреймворки как 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»
и т.д. и т.п.
просто кому это нах надо? :) времени жалко и если не «выпендриваться» то можно съэкономить кучу времени если использовать дефолты там гре ето имеет смысл. В этом и заключается одна из прелестей рельсов: надо — конфигь, не надо — не копай :)
а если очень нужно чтоб совсем без дефолтов, то можно и на асме, там совсем всё круто, ну для совсем реальных пацанов :)
практически любая из 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, но это тоже уже проходили в других языках, вылечат через пару лет :)
Ну есть мучение с utf8, но это тоже уже проходили в других языках, вылечат через пару лет :)
нюансов как раз очень даже есть :)
метакласы например, и всевозможные комбинации class+module+instnce_variable+class_variable+inheritance
вот например:
распечатает «class_foo». и я то знаю почему, но это совершенно не очевидно для начинающих, явный «нюанс» :)
метакласы например, и всевозможные комбинации 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». и я то знаю почему, но это совершенно не очевидно для начинающих, явный «нюанс» :)
Такую вещь ещё в стародавние времена заметил один филосов, куда уж понятнее…
Самое занятное, что сбор такой статистики дело естественное и не обходимое, но ни к чему не приводящее — ведь выбор остаётся равнозначным. Так что либо изучи то, что больше по душе показалось, либо кинь монетку ;)
Самое занятное, что сбор такой статистики дело естественное и не обходимое, но ни к чему не приводящее — ведь выбор остаётся равнозначным. Так что либо изучи то, что больше по душе показалось, либо кинь монетку ;)
Пишу на руби и рельсах, работаю на них же. Уже давно решил, что следующий мой язык будет пайтон, просто для развития, но в руби нравится все (как и в рельсах).
Не буду писать, что руби лучше, нежели пайтон (потому что он не лучше =), но на данный момент мне руби нравится больше. И да, я знаю, что «в миру» пайтон используется чаще (да-да, гугл и яндекс), но я очень сомневаюсь, что когда-либо попаду в одну из подобных контор:)
Не буду писать, что руби лучше, нежели пайтон (потому что он не лучше =), но на данный момент мне руби нравится больше. И да, я знаю, что «в миру» пайтон используется чаще (да-да, гугл и яндекс), но я очень сомневаюсь, что когда-либо попаду в одну из подобных контор:)
Я бы брал питон, его еще в куче мест можно применить окромя веба.
Использую Ruby on Rails и практически насильно «привил» эту технологию коллегам по работе :)
Из не упомянутого вами:
табы в питоне убивают)
работы на RoR просто море
На самом деле, мне кажется что в любом случае вы не прогадаете с выбором. Чтобы убедиться в этом, попробуйте, всё-таки, сначала любой из PHP-фремворков.
Из не упомянутого вами:
табы в питоне убивают)
работы на RoR просто море
На самом деле, мне кажется что в любом случае вы не прогадаете с выбором. Чтобы убедиться в этом, попробуйте, всё-таки, сначала любой из PHP-фремворков.
Переписывать — нет, апгрейдить можно и как утверждают, даже за 25 минут;)
Rails3 — это тотально переделаное ядро. Естественно, оно еще не доведено до состояния production-ready. И как минимум до осени вряд ли будет.
И, тем не менее, на rails3 уже запущено несколько проектов.
И, тем не менее, на rails3 уже запущено несколько проектов.
попробуйте написать несколько простых приложений и на рельсах и на джанго. посмотрите, что удобнее именно вам. Я выбрал рельсы
+ Django используют Google и Яндекс (равняемся на лучших!)
А рельсы используются на www.twitter.com, www.github.com, www.basecamphq.com — тоже довольно известные приложения, особенно первый =)
Посмотрите в сторону Scala и их флагмана Liftweb. Я после Питона и Джанги счастлив.
Конечно, путь к админинтерфейсу у Лифта болезнее, чем у Джанги, но ведь это не главное, да и в угоду заказчику ради изменения какой-нибудь надписи приходится всё равно переписывать.
Scala порадовала тем, что в ней функциональное программирование не торчит сбоку как у Питона, и парадигмы ООП реализованы и находятся на своих местах, а не переделываются в что-то маркетолигическое как это сделано в Ruby.
Отдельно насчёт Rails, я сам им когда-то болел, но теперь мне кажется, что половиной своей популярности Rails обязан пиару(который сейчас постепенно сходит на нет), поэтому я бы совсем чуть-чуть его опасался :)
Конечно, путь к админинтерфейсу у Лифта болезнее, чем у Джанги, но ведь это не главное, да и в угоду заказчику ради изменения какой-нибудь надписи приходится всё равно переписывать.
Scala порадовала тем, что в ней функциональное программирование не торчит сбоку как у Питона, и парадигмы ООП реализованы и находятся на своих местах, а не переделываются в что-то маркетолигическое как это сделано в Ruby.
Отдельно насчёт Rails, я сам им когда-то болел, но теперь мне кажется, что половиной своей популярности Rails обязан пиару(который сейчас постепенно сходит на нет), поэтому я бы совсем чуть-чуть его опасался :)
Хехе. Интересно, что юзая их ActiveRecord, сначала как все сказал «Вау»(прям как у Пелевина), а потом через некоторое время ощутил, что где-то меня тут обманули :) Так часто бывает с Rails.
Кстати кусок инфрастуктуры Твиттера недавно переписали на Scala, т.к. стала всё больше проявлятся врожденная недостаточная масштабируемоть Твиттера.
Скала интересна ровно до тех пор пока решаешь на ней академические задачи.
Плюс надо ооочень хорошо понимать что внутри происходит и во что превращается тот или иной код.
При решении повседневных задач все чаще возникает желание портануться на джаву.
А рекомендовать лифтфреймворк новичку это вообще негуманно.
Плюс надо ооочень хорошо понимать что внутри происходит и во что превращается тот или иной код.
При решении повседневных задач все чаще возникает желание портануться на джаву.
А рекомендовать лифтфреймворк новичку это вообще негуманно.
чем мне не нравится джанго:
1. отсутствие cucumber (если предложите другое адекватное джанго-ориентированное средство BDD, буду только рад и счастлив)
2. ненастраиваемая до тонкостей rails логика валидация ModelForm. Последовательная валидация в заданном порядке с условиями возврата и сброса проверок как-то не получилась. Особенно из-за порядка валидации типизированных полей.
чем мне не нравятся рельсы
1. крайне медленные хелперы. Использование собственных хелперов сильно сказывается на быстродействии проектов.
2. крайне убогий(по сравнению с джанговским ормом) ActiveRecord. Такого количества SQL как там, мне писать не приходилось нигде вообще.
пишу на django вот уже год, до этого работал с C#, asp.net mvc
1. отсутствие cucumber (если предложите другое адекватное джанго-ориентированное средство BDD, буду только рад и счастлив)
2. ненастраиваемая до тонкостей rails логика валидация ModelForm. Последовательная валидация в заданном порядке с условиями возврата и сброса проверок как-то не получилась. Особенно из-за порядка валидации типизированных полей.
чем мне не нравятся рельсы
1. крайне медленные хелперы. Использование собственных хелперов сильно сказывается на быстродействии проектов.
2. крайне убогий(по сравнению с джанговским ормом) ActiveRecord. Такого количества SQL как там, мне писать не приходилось нигде вообще.
пишу на django вот уже год, до этого работал с C#, asp.net mvc
Pyccuracy?
пробовал, не очень хорошо там всё, как минимум из-за того, что работает с selenium, набор селекторов ограничен, как и с русским языком там не всё дружно. Про написание всего сценария на русском я уже умалчиваю. В общем — не понравилось мне .( хочу еще попробовать подружить джангу с pycukes, но пока что не получается.
Тот же рельсовый огурец позволяет тестировать всё, кроме яваскрипта, хотя, знакомые спецы уже и эту проблему видели решенной (есть вариант с selenium, и с capybara
Тот же рельсовый огурец позволяет тестировать всё, кроме яваскрипта, хотя, знакомые спецы уже и эту проблему видели решенной (есть вариант с 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 уже умеет 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
Django
— админка. используется всегда и везде. очень просто и красиво;
— clear way. читаемый код (субъективно конечно, но имхо Python чертовски красив);
— готовые приложения. есть для всего;
— документация и обсуждения ньюансов (не сравнивал с Rails но всё что потребуется уже обсуждалось на stackoverflow или на форумах). поддержка;
— админка. используется всегда и везде. очень просто и красиво;
— 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 не существует.
Большинство комментариев которые ты тут увидишь будут защищать ту технологию, с которой автор работает (даже если другую он никогда и не пробовал).
Субъективно:
— в 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 точно нет.
Сравнивать надо не количество, а качество приложений. В рельсах есть что-нибудь подобное 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 так кардинально поменялось?
Сам-то смотрел прежде чем утверждать?
github.com/commonthread/flickr_fu
По аутентификации полно плагинов хороших и разных
Я так же могу сказать, что для django нет аналогов github.com/bborn/communityengine, но это будет глупо, как и твой комментарий. Также рекомендую посмотреть и восхититься ActiveResource. Ведь аналогов для джанги нет!
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. Очень не приятно.
Сделай голосование :)
Когда-то тоже выбирал между Django и Rails.
Выбрал 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.
Вместо ленивых запросо я использую хэш параметров, который раскрываю только в последнюю очередь. Кстати, DataMapper поддерживает цепочки.
Админка — Typus.
AR в 3-их рельсах вроде научился ленивым запросам
Уххх. Перечитал весь тред, т.к. тоже пытаюсь определиться. Изначально думал в сторону РоР. В процессе чтения подколбашивало из стороны в сторону в итоге всё же решил взяться за РоР. Возможно и из-за того, что сам считаю что нужно заниматься тем, что больше нравиться, а лежит сейчас больше к РоР, к тому же и 3.0 как раз вышел. Ну и пара полезных названий типа Typus и DataMapper, за что отдельное спасибо…
И только одно продолжает свербить затылок — Google и Яндекс :)
И только одно продолжает свербить затылок — Google и Яндекс :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Django vs Rails: дилемма начинающего web-разработчика