?

Log in

No account? Create an account
Main

Рубиковыряние.

Ковыряясь в руби на рельсах открыл для себя плагин к мозилле SQLite Manager. Очень удобно для работы с файлами sqlite.

Все книжки по рельсам из моей коллекции устарели, -- они для версии 1.х. Пришлось искать Pragmatic - Agile Web Development with Rails в 3-й редакции, а уже есть и в 4, где будет про 3 рельсы, но я пока остановился на 2-х. Кстати руби-гемс уже по умолчанию ставит рельсы 3, нужно явно говорить, что хочешь 2.3.5. Очень понравился монгрел для девелопмента -- видна работа сервера в консоли. Однако, если хотеть несколько приложений на разных виртуальных хостах, то нужно через nginx или апач этот монгрел пропускать, сам он этого не умеет. А при пропускании нужно вешать процесс монгрела для каждого приложения на отдельный порт. Понятно, что портов много, но все же смущает немного.

Разбираюсь с рельсами, нравится все, но восторга нет. И правда, -- прагматичный подход. Ничего нового, но все ладно собрано и хорошо работает. Я представляю какой восторг должен был быть у тех, кто рельсы взял в самые первые времена. Когда еще на php не наделали клонов. А сейчас читаю так привычненько и знакомо все, только на руби :)

Comments

mongrel мастдай, рекомендую passenger
http://www.modrails.com/
Спасибо.

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

Наверное правильно для руби-приложений (redmine, capistrano) сделать запуск через modrails, а то, что девелопишь смотреть через монгрел.
Еще чтобы консоль посмотреть, в рельсах есть встроенный WEBrick, так что по-большому счету, нет необходимости для разработки дополнительно ставить mongrel.
А в продакшене никакого сравнения, мы недавно перевели все с кластера монгрелов на passenger и так стало хорошо, спокойно и стабильно :)
Необходимость есть. Пользоваться вебриком попросту невозможно, он раз в 6-7 медленнее.

Для продакшна modrails годится до 10 запросов в секунду. После этого уже unicorn
Все зависит от целей, конечно.
Мне хватает вебрика для разработки за глаза и за уши. А в продакшне passengerа.
passenger крайне не стабильная штука. mongrel для дева, http://code.macournoyer.com/thin/ для продакшена
Очень странное заявление.
passenger - "пром стандарт"
Что это вы такое говорите?
Мой восторг сошел на нет от того от чего и появился -
Магия.
Многое можно сделать одной строкой, но сколько же нужно перелопатить, чтобы понять какой.
Особенно трудно приходится, когда все на винде, и база в sql server.

Наупирался в SQL Server Adapter For Rails.
Кодировка - патчить гем,
many-to-many - имена колонок прошиты, хотя для других баз конфигурируются.
Запросы далеко не оптимальны. На больших таблицах рельсовые связи беспомощьны, нужно писать кастомные запросы, ну и вся прелесть уходит.
Есть ещё надежда что с использованием arel запросы таки будут строиться оптимальней (обязаны!) да lazy loading должен убрать бессмысленной перелопачивание базы...
Но нужно время, чтобы вдохновение вернулось :)
А в руби ОРМ сразу встроен как часть языка?
Не в руби, в рельсах (как часть фреймворка).
$ gem list

...
activerecord (2.3.5)
....

ОРМ Эктив рекорд -- отдельный гем, но когда ставишь рельсы, ставится автоматом.
«На больших таблицах рельсовые связи беспомощьны» — извините, но это фигня написана. Рельсовые связи — это инструмент для унифицированной генерации SQL-я. Если надо подпатчить генерируемый SQL, то можно совмещать и ORM, и сырой текст.

Сами же связи абсолютно никак не связаны с размером таблиц, по крайней мере несколько сот миллионов комментариев прекрасно извлекаются без какого либо сырого SQL-я.


Что же до винды, то да: винда и рельсы попросту несовместимы. Связано это с тем, что продакшна на винде в области применимости рельс попросту нет, поэтому никому и неохота чего-либо патчить или отлаживать для них.
Если я например вяжу к клиенту счета а к счетам документы, а те в свою очередь ещё имеют ещё и кореспондирующий счет, а счета имеют реквизиты, то при банальном выводе списка первых десяти клиентов, он строит их ORM, выбирая все счета, документы и прочую ненужную на этом этапе информацию.
Причем запросы будут выполняться заново для каждой записи, перелопачивая, к примеру огромную таблицу документов или реквизитов.

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

Про то, что у руби реперутар с коннектом к БД небогатый я читал. Но давно. Жаль, что это не вылечилось.

Edited at 2010-09-09 08:41 pm (UTC)
то что я с нуля писал на ПХП работало уже на следующий день, выглядело убого, но для моих задач годится.
Но как водится это практически несопровождаемые и неподвласные повторному использованию модули, конечно на MVC слюни потекли.
И вот уже обревший вид на руби заброшен, а ПХПшные одноразовые задачи каждый день приносят пользу людям.

Хотя к ПХП я не собираюсь возвращаться, просто потому, что может фреймворки аналогичные и есть, а вот Ruby там нет.