Мысли о Rails от разработчика Django

Мой первый и до сих пор мой любимый язык программирования Python и Django до сих пор мои рамки выбора для моего личного проектов. Тем не менее, когда мой хороший друг scrounged сделал бесплатный сайт для меня некоторое время назад, я не делаю то, что обычно делают, когда друзья просят бесплатно: создание другой экземпляр WordPress на моем сервере и пусть они выберут бесплатный шаблон. Вместо этого я решил написать свою собственную CMS на своем сайте использованием Rails.

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

Хотя работа через документации и учебников я не мог удержаться, чтобы несравненить Rails и Django, так как она является основой. Больше всего меня устраивает, и она занимает немного времени, чтобы высказать свои предположения и ожидания того, как web framework должty работать. Таким образом, это односторонний мини-обзор Rails.


Ruby программирование



Я не знаю ничего о Ruby до этого проекта, но всем известно, в эти дни, что блоги двигатель нового 'Hello World'. Ruby и Python являются более похожими, чем они отличаются. Оба они интерпретируются, набрав немного команд и наложив немного структуру исходных файлов можно приступать к работе. Ruby чуть менее читаем мне из-за следующих вещей:

слишком много sigils(Возможно «точек». Примечание Пер.)
несколько возможных function/method вызова синтаксиса
блок синтаксис (def… end) — Мне потребовалось некоторое время, чтобы привыкнуть как я вырос, и полюбил его

Я читал, что Ruby не хватает объема не WEB библиотек, Python имеет. Но это не беспокоит меня, поскольку я почти исключительно делать WEB вещи. Я просто не достаточно умен, чтобы использовать для для SciPy и NumPy.

Что мне не нравится в Rails


ActiveRecord

Указанные проекта, очевидно, не нужно на самом деле сложная модель данных: несколько предприятий с простыми многие-к-одному. Особенно потому ActiveRecored позиционирующей себя как простое решение для супертяжелом ORMs предприятия, как Hibernate, я обнаружил, создание этой схеме удивительно трудно. По сравнению с Django, Rails вводит несколько новых концепций, которые приняли меня немного, чтобы получить мою голову вокруг него.

Разделение схемы и модели(separation of schema and model): в Django модель схемы, и я не мог понять, почему эти две вещи должны быть отделены
миграций(migrations): Я вижу, как это может пригодиться, но в моем случае это был еще один дополнительный вещь я должен был держать вкладках
если у вас есть многие-ко-многим(many-to-many relationship) придется определить присоединиться к таблице себе, на мой взгляд, это именно тот тип то, что ORM на уровне абстракции от ActiveRecord должен заботиться

Особенно благодаря тому, что последний момент я думал, что ActiveRecord просто SQL переписать в Ruby.

Шаблоны (Templating)

Использование чистого Ruby в .erb шаблоны, безусловно, является мощным, но для меня пахнет Java сценарием, не так ли? Я присоединяюсь к мнению, что язык шаблонов для дизайнеров и должен только обеспечить безопасный конструкций. Не совсем хорошая, а маленькая причуда.

Нет встроенного администратора (No built-in admin)

Это то, что мне нравится в Django и найти рода сделки-выключатель в Rails. Django предоставляет большим нетерпением администратора интерфейсы для редактирования данных из коробки. Он отнимет у вас 95% от того, где вы хотите, чтобы ваши админки были и я сам никогда не нужно настраивать шаблон. Я слышал, что с введением newforms библиотеки сейчас больше не так трудно, чтобы написать свои взгляды администратора. В общем, я очень удивлен тем, что Rails не события получили нечто отдаленно похожи. (Может быть, я бросил просмотрел? Позвольте мне знать в комментариях.)

Что мне нравится в Rails



Структура каталогов

Rails достаточно хорошо дает вам ощущение того, где файлы должны быть в каталоге, структура, четко давая вам контроллера в модели. Кроме того, я очень хотел различие между верхней папки на уровне: конфигурации(config), приложения(app), БД(db), испытания(test) и т.д. Это, на мой взгляд, что-то слабое место в Django, где я никогда не понимал, где вещи должны жить. Да, вы говорите, что должно быть разделения кода на отдельные приложения Django, но я думаю, что это не тот уровень абстракции и как понятия плагинов-то лучше. Это может быть разработчик Java у мененя говорят — драгоценный камень(gem) может гораздо больше, чем JAR.

Управление зависимостями

Это здорово, что вы можете указать необходимые камни(gem) для вашего приложения, и даже запускать приложения, на конкретной версии Rails, котору вам нужно. Я не пробовал, но кажется, что необходимо драгоценные камни(gem) устанавливаются автоматически, если они этого не сделали. Управление зависимостями — любопытно но не существует в Django.

Трава не всегда зеленеет


Ну, я не знаю, что я ожидал, но Rails не может магическим образом решить все проблемы и не банальной веб-разработок. С другой стороны, я не был недоволен Django — Я просто хотел бы расширить свой кругозор.

Rails, безусловно, повышает производительность, но я нашел кое-что, главным образом вокруг ActiveRecord, немного странным и нелогичным. Я не могу сказать, что я влюбился в Rails, но это стоит прочную основу его популярности. Имейте в виду, что это мне выступая после использования Rails около 2 недель — я уверен, что у меня есть я только царапал поверхность того что Rails может сделать для меня, я слышу, что испытания и развертывания фантастичны. Может быть, я сделаю выводы как изменился мой взгляд, после того как я использовал их. Следите за будущими моими постами.

Оригинал: lenni.info/blog/2010/07/thoughts-about-rails-from-a-django-guy/

Неругайте за перевод.

Далее в комментариях идет обсуждение того что написано выше. И все плохое было разобрано теми кто программирует на руби. И оказывается это все есть или решается плагинчиком.

1 комментарий

Dit81
:-) Перевод просто ужасен… Переписать бы с учетом русской грамматики.
Комментарий отредактирован: 21 января 2011, 15:20
0