для закрытых репозиториев имхо проще использовать ssh транспорт
ну а если требуется web доступ, то https или vpn спасают, смысла городить огород не вижу
описание вакансии на ООП — фигня по сравнению с тем, что претенденту нужно форкнуть проект, описать себя, свои скилы, и сделать pull-request.
В конце концов все претенденты будут сражаться между собой виртуально: github.com/reedlaw/ruby-mmo
> Это очень странно, возможно Вы начали работу с СУБД сразу с ORM.
:) познакомился я с SQL в 2000г на СУБД Informix, в то время очень крутой, в то время никто и не слышал об ORM
кол-во строк не показатель, обычно сложный SQL в ruby (в принципе не важно в каком языке) длинная строка в которой сходу ничего не поймешь, AREL вносит ясность
если хотите — в личку могу скинуть примеры кода и некоторые кейсы, когда использование SQL было бы гораздо сложней
я не агитирую полностью отказаться от SQL, возможно использование каких-то простых команд типа TRUNCATE. Но по возможности следует пользоваться AREL (имхо).
Мне как раз таки сложную выборку проще понять в AREL, это раз
во вторых обычно приходится статические запросы с 3мя и больше join на больших таблицах разбивать на отдельные запросы для производительности
третье — (основная моя мысль) составлять на лету сложный запрос ( в котором WHERE условия и JOIN таблички подключаются в зависимости от других бизнес-условий) гораздо проще и понятней через AREL, чем пытаться работать со строкой
четвертое — портабельность, я легко переключаюсь между mysql, postgresql и sqlite
все это мое имхо, я вижу явные преимущества в использовании AREL, кто считает что SQL строка удобней — дело его.
никто еще не умер и от SQL кода во вьюшках, но мировой опыт показывает, что это вызывает воспаление геморроидальных вен
да и поручать работу руби тоже не стоит
выглядит читабельней и понятней и гораздо проще в отладке и тестах
таким же блоком я ловлю ошибки и посылаю оповещения о них
ruby суперский язык, в котором можно вывернуться как угодно (ну или почти как угодно), но не стоит придумывать гемор. проще надо быть — KISS
все это имхо
в итоге получился сферический конь. нет, я не против задачек во имя академического интереса, но тут совсем мало практической пользы — все можно сделать гораздо красивей на чистом руби
Давай, до-свиданья
ну а если требуется web доступ, то https или vpn спасают, смысла городить огород не вижу
curl get.mojolicio.us | sudo shмой внутренний параноик упал и бьется в конвульсиях
В конце концов все претенденты будут сражаться между собой виртуально: github.com/reedlaw/ruby-mmo
:) познакомился я с SQL в 2000г на СУБД Informix, в то время очень крутой, в то время никто и не слышал об ORM
кол-во строк не показатель, обычно сложный SQL в ruby (в принципе не важно в каком языке) длинная строка в которой сходу ничего не поймешь, AREL вносит ясность
если хотите — в личку могу скинуть примеры кода и некоторые кейсы, когда использование SQL было бы гораздо сложней
я не агитирую полностью отказаться от SQL, возможно использование каких-то простых команд типа TRUNCATE. Но по возможности следует пользоваться AREL (имхо).
во вторых обычно приходится статические запросы с 3мя и больше join на больших таблицах разбивать на отдельные запросы для производительности
третье — (основная моя мысль) составлять на лету сложный запрос ( в котором WHERE условия и JOIN таблички подключаются в зависимости от других бизнес-условий) гораздо проще и понятней через AREL, чем пытаться работать со строкой
четвертое — портабельность, я легко переключаюсь между mysql, postgresql и sqlite
все это мое имхо, я вижу явные преимущества в использовании AREL, кто считает что SQL строка удобней — дело его.
да и поручать работу руби тоже не стоит
— вредный совет
изучайте AREL, берите в руки squeel или meta_where
выглядит читабельней и понятней и гораздо проще в отладке и тестах
таким же блоком я ловлю ошибки и посылаю оповещения о них
ruby суперский язык, в котором можно вывернуться как угодно (ну или почти как угодно), но не стоит придумывать гемор. проще надо быть — KISS
все это имхо