Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 89
Чего очень не хватает подобным туториалам — описывается обычно настройка дев-среды, но очень вскользь рассматриваются вопросы настройки продакшена и деплоя на него, а часто вообще не рассматриваются.
Как правило, такие туториалы предназначаются для самого начального уровня, чтобы можно было быстро вовлечь человека. Рассматривать здесь вопросы настройки продакшена совершенно не к месту. К тому же из начала статьи понятно, что текст от новичка к совсем новичку.
Ну, туториалы для PHP подобного уровня часто содержат всё необходимое, чтобы не просто написать приложение и на локалхосте посмотреть, но и миру его показать. Для RoR же в лучшем случае ограничиваются деплоем на Heroku. Думаю отчасти популярность PHP обусловлена и тем, что прошедший подобный туториал может написать простейшее CRUD-приложение не только в учебных целях, но и выложить его на продакшен и использовать в работе, хобби или бизнесе.
P.S. «продакшен» здесь просто как «паблик», «не дев», «не локалхост» на какой-нибудь вдске за 100 рублей, а не «хайлоад». Понятно что можно на vds всё из статьи сделать (с изменениями типа
P.S. «продакшен» здесь просто как «паблик», «не дев», «не локалхост» на какой-нибудь вдске за 100 рублей, а не «хайлоад». Понятно что можно на vds всё из статьи сделать (с изменениями типа
sudo rails s -p 80 вместо rails s -p 3000, но о недостатках такого подхода вы, наверное, лучше меня знаете, а они могут иметь последствие обратные «вовлечь».
Так вроде всё легко, если использовать nginx + phusion passanger + capistrano + postgresql + jenkins? Особо и писать нечего…
лол. вы серьезно?
напишите хотя бы почему вы в эту цепочку добавили Jenkins. И почему именно Postgresql? с мускулем работать не будет?
деплой это тот ещё гемор. Даже с капистранкой. Но когда есть опыт и написанные рецепты деплоить всяко проще и горадо проще чем на PHP.
напишите хотя бы почему вы в эту цепочку добавили Jenkins. И почему именно Postgresql? с мускулем работать не будет?
деплой это тот ещё гемор. Даже с капистранкой. Но когда есть опыт и написанные рецепты деплоить всяко проще и горадо проще чем на PHP.
Абсолютно серьезно. nginx устанавливается одной командой, для минимальной работоспособности дополнительной настройки не требует, passenger устанавливается 4 командами, для минимальной настройки хоста достаточно 5 строчек в конфиге. Capistrano — установка — добавление одной строки в Gemfile, 10 строчек конфига. Постгрес устанавливается 1 командой, создание юзера и бд — еще 2 команды. jenkins — установка — 1 команда, настройка — строчек 5 конфига и пара кликов мышью, позволяет легко содержать стейджинг и продакшн, деплой благодаря нему перестанет быть чем-то страшным и непонятным.
Итога за полчаса-час можно с нуля руками развернуть работоспособный сервер, с деплоем по гит-хуку или периодическим деплоем, забыть про ад деплоя и всё такое.
Почему postgres? Потому что с ним работаю. Может быть и мускуль. В любом случае, стоит попрактиковаться проектах на 2-3, и деплой станет простым и безболезненным.
Итога за полчаса-час можно с нуля руками развернуть работоспособный сервер, с деплоем по гит-хуку или периодическим деплоем, забыть про ад деплоя и всё такое.
Почему postgres? Потому что с ним работаю. Может быть и мускуль. В любом случае, стоит попрактиковаться проектах на 2-3, и деплой станет простым и безболезненным.
Хорошо быть гуру в песочнице) Это как если бы Павел Дацюк читал лекцию 10-ти летним мальчикам из «Юниора»:
-Что вы там с азами и теорией маятесь? Взяли клюшку, коньки — и вперёд, в лучшие игроки НХЛ, это же просто, надо только забивать шайбы в ворота, мимо голкипера!)
-Что вы там с азами и теорией маятесь? Взяли клюшку, коньки — и вперёд, в лучшие игроки НХЛ, это же просто, надо только забивать шайбы в ворота, мимо голкипера!)
Да нет, там на самом деле всё достаточно просто. Ну ладно, первый раз это часа 2-4 может занять, так как непривычно. Но вся фишка в том, что документации по настройке всего этого — море, там всё написано простым понятным языком и нету никакой магии (ну если только чуть-чуть, где-нибудь в районе capistrano или jenkins). Ну и делать это всё легче тогда, когда проект еще маленький и не оброс кучей странного хардкода и костылей :)
2-4 часа для разбирания как выложить в паблик «hello world», написанный по туториалу, непозволительно много. Так вот и складывается «высокий порог вхождения». Туториал, претендующий на «простейшее, но полноценное приложение с нуля», по-моему, просто обязан содержать команды для установки всего этого и конфиги, чтобы развернуть приложение можно было копипастой, так же как и написать его. А то получается как в туториале по какому-нибудь компилируемому языку рассказать как скомпилировать «hello world» в объектный файл, но не рассказать как из него сделать исполняемый.
Специально для таких людей есть heroku. Там всё бесплатно, деплоится — одной командой, автоматически при пуше в гит. Этим вашим php такое и не снилось.
Насчет «не снилось» не перегибайте. У меня в проекте тоже деплоится по пушу в гит, если тесты прошли. С помощью capistrano кстати деплоится :) И без всякой зависимости от конкретного хостера.
А не использовать heroku может быть много разных причин. От его забугорности до наличествующей вдски с «привязанным» доменом, настройки которого трогать весьма нежелательно.
А не использовать heroku может быть много разных причин. От его забугорности до наличествующей вдски с «привязанным» доменом, настройки которого трогать весьма нежелательно.
Для человека, который не в теме деплоя, но хочет быстренько свой блог разместить в сеть надо не только знать, какие 10 строк прописать в капистрано, но ещё и для начала знать, что для используется nginx, и phusion passenger, чем они отличаются и нужно ставить их по принципу и или или. Даже для человека, который программирует тыщу лет, но никогда не занимался вебом всерьез, такие вещи легко могут оказаться неизвестны.
Мало того, некоторые вещи могут оказаться неизвестными человеку, занимающемуся вебом всерьез давно, но в другой экосистеме. nginx он-то установит, а вот passenger уже может в тупик поставить.
А зачем этому человеку тогда настраивать продакшен вообще? Для него есть уютные appfog, heroku и иже с ними. Продакшн там автоматом работает по пушу в гит. Подробно описано в рельсотуториале.
passenger установить не так просто, не нарушая общей целостности системы. Для туториала бы лучше подошел unicorn. сapistrano ещё куда не шло, но вот Jenkins в этом списке явно лишний.
Ну и главное — мало всё это установить, нужно ещё и заставить работать в одной связке. Проще говоря нужны примеры конфигов.
Ну и главное — мало всё это установить, нужно ещё и заставить работать в одной связке. Проще говоря нужны примеры конфигов.
Да ладно, что там нарушать? Удаляешь старый nginx, ставишь по мануалу новый. Я даже не представляю, где там можно ошибиться. И гораздо удобнее, чем unicorn, в плане конфигурирования — для добавления rails-хоста ни надо разбираться со всякими fcgi, держать отдельно god/runit/etc для fastcgi сервера, рестарт — одной командой. Что может быть проще?
Все примеры конфигов уже 100 раз разобраны в документации для описанных мной выше средств.
Все примеры конфигов уже 100 раз разобраны в документации для описанных мной выше средств.
Обновлять nginx как? Каждый раз пересобирать? Для многих дистров это не православно. Из популярных наверное только гентушникам привычно.
Ладно бог с ними с обновлениями, но туториал претендует на «всё в одном месте», а значит и процесс установки должен быть и конкретные конфиги. Пускай без пояснений (кроме типа «замените „example.com“ на свой домен) и ссылок, но и без необходимости идти на сторонние ресурсы и, тем более, что-то гуглить (особенно учитывая, что гуглятся часто холивары, что лучше для тех или иных целей, аргументы сторон в которых новичку непонятны).
Ладно бог с ними с обновлениями, но туториал претендует на «всё в одном месте», а значит и процесс установки должен быть и конкретные конфиги. Пускай без пояснений (кроме типа «замените „example.com“ на свой домен) и ссылок, но и без необходимости идти на сторонние ресурсы и, тем более, что-то гуглить (особенно учитывая, что гуглятся часто холивары, что лучше для тех или иных целей, аргументы сторон в которых новичку непонятны).
Ну вот у меня unicorn, и вот меня несколько раздражает, что для того, чтобы поднять ещё одно приложение приходится совершать очень много телодвижений.
А именно:
Возможно что-то ещё не учёл. В итоге куча однотипных файлов, похожих друг на друга.
А именно:
- Скрипт в /etc/init.d/ (хотя тут достаточно написать один раз и создавать симлинк каждый раз)
- Конфиг nginx — тут приходится всегда заново писать, по крайней мере я не нашёл информацию о том, как их динамически генерировать
- Конфиг unicorn — также приходится писать каждый раз
- Конфиг capistrano — также приходится писать каждый раз
Возможно что-то ещё не учёл. В итоге куча однотипных файлов, похожих друг на друга.
Чем этот туториал отличается от первых 10 страниц любой книжки по рельсам/ овер9000 других таких туториалов?
Вот про продакшн действительно не мешало бы, хотя и это гуглится на раз.
Вот про продакшн действительно не мешало бы, хотя и это гуглится на раз.
И мне не понятно. Уже тема интро для рельс давным давно избита. Плюс ко всему описана настройка рельс для семейства GNU/Linux, а проблемы зачастую возникают у тех, кто на винде. Хотя тут настраивается всё в несколько кликов и туториала, собственно, не требует. Я запутался…
Ну, на винде, к слову гораздо меньше проблем с тем, чтобы поднять рельсы — railsinstaller.org/; на все про все пару кликов.
Вот когда у Вас возникнуть проблемы на винде, так это когда Вам нужно будет собирать гемы — процесс до того временами тяжкий, что даже сильного мужчину заставит плакать.
В общем, лучше не использовать винду для разработки на руби и для работы с рельсами.
Вот когда у Вас возникнуть проблемы на винде, так это когда Вам нужно будет собирать гемы — процесс до того временами тяжкий, что даже сильного мужчину заставит плакать.
В общем, лучше не использовать винду для разработки на руби и для работы с рельсами.
>> Ну, на винде, к слову гораздо меньше проблем с тем, чтобы поднять рельсы — railsinstaller.org/; на все про все пару кликов.
К слову, с использованием Rails Installer возникали проблемы, поэтому лучше всё делать другим образом. Ставим Ruby Installer, дальше gem install rails, а дальше вручную бандлим и настраиваем окружение вручную. Меньше хлопот приносит, знаете ли.
>> Вот когда у Вас возникнуть проблемы на винде, так это когда Вам нужно будет собирать гемы — процесс до того временами тяжкий, что даже сильного мужчину заставит плакать.
А можете указать конкретный юзкейс? У меня просто с этим проблем не возникало.
>> В общем, лучше не использовать винду для разработки на руби и для работы с рельсами.
Без обид, но это конечно уж совсем какой-то не корректный вывод, не подкреплённый ничем. Вообще это тема для отдельного спора. Разумеется, когда мы говорим о рельсах и рубях — имеем ввиду GNU/Linux окружение, что называется, by default. Но есть множество людей, которые пишут и деплоят приложения на винде и у них проблем не возникает абсолютно. И я в их числе.
К слову, с использованием Rails Installer возникали проблемы, поэтому лучше всё делать другим образом. Ставим Ruby Installer, дальше gem install rails, а дальше вручную бандлим и настраиваем окружение вручную. Меньше хлопот приносит, знаете ли.
>> Вот когда у Вас возникнуть проблемы на винде, так это когда Вам нужно будет собирать гемы — процесс до того временами тяжкий, что даже сильного мужчину заставит плакать.
А можете указать конкретный юзкейс? У меня просто с этим проблем не возникало.
>> В общем, лучше не использовать винду для разработки на руби и для работы с рельсами.
Без обид, но это конечно уж совсем какой-то не корректный вывод, не подкреплённый ничем. Вообще это тема для отдельного спора. Разумеется, когда мы говорим о рельсах и рубях — имеем ввиду GNU/Linux окружение, что называется, by default. Но есть множество людей, которые пишут и деплоят приложения на винде и у них проблем не возникает абсолютно. И я в их числе.
А можете указать конкретный юзкейс? У меня просто с этим проблем не возникало.Да установка любого нативного гема, часто превращается в кошмар, тот же json, например, или therubyracer, который вообще не собрать под виндой. В принципе, сборка чего либо по Windows, мне видится гораздо менее тривиальной задачей, чем сборка под Linux.
Без обид, но это конечно уж совсем какой-то не корректный вывод, не подкреплённый ничем. Вообще это тема для отдельного спора. Разумеется, когда мы говорим о рельсах и рубях — имеем ввиду GNU/Linux окружение, что называется, by default. Но есть множество людей, которые пишут и деплоят приложения на винде и у них проблем не возникает абсолютно. И я в их числе.Успешность использования того или иного инструмента зависит во многом от задач, которые Вы решаете с его помощью. Если мне нужен Sidekiq для своего проекта, я не рискну связываться с Windows. Мой комментарий, что для Ruby\Rails разработки лучше использовать Linux означал, что при прочих равных возникнет гораздо меньше проблем связанных с настройкой рабочего окружения и функционированием отдельных его компонент при использовании Linux, а не Windows. Т.е. все, что я могу сделать в Windows я могу сделать и в Linux и скорее всего это будет даже проще, но не все, что я могу сделать в Linux, я могу сделать в Windows. Default, он, знаете ли, не просто так default.
>> Да установка любого нативного гема, часто превращается в кошмар, тот же json, например, или therubyracer, который вообще не собрать под виндой. В принципе, сборка чего либо по Windows, мне видится гораздо менее тривиальной задачей, чем сборка под Linux.
Native Development Kit же нужно для этого ставить самому. github.com/oneclick/rubyinstaller/wiki/development-kit
По второму пункту, в общем-то я согласен.
Native Development Kit же нужно для этого ставить самому. github.com/oneclick/rubyinstaller/wiki/development-kit
По второму пункту, в общем-то я согласен.
Генератор Rails давно уже генерирует другие миграции с одним change методом. Незачем генерировать отдельно модель и контроллер, есть
rails g scaffold
rails g scaffold
Имхо после такого туториала у меня отпало бы желание изучать что такое руби он рейлс. Зачем такой туториал нужен я не понимаю, разве что отпугнуть людей.
Я тоже вторую неделю изучаю RoR. Книга на подобии той которую можно скачать тут rusrails.ru/ на много лучше в своих первых главах чем такой туториал.
Конечно лучше, тоже читаю. Но для написания такой книги нужны недели. И месяцы практики. Я сделал выжимку из проблем, с которыми столкнулся в самом начале. С удовольствием прочитаю Вашу статью на данную тему.
и плюс скринкасты www.youtube.com/feed/UCPIyDzf1vwWc8EQJGUX-vYw
Спасибо за комплимент в адрес rusrails :)
Не думал, что скачиваемый pdf популярен, немного пристыдился, на сайте гораздо свежее переводы… Нужно бы сверстать pdf поновее :)
Не думал, что скачиваемый pdf популярен, немного пристыдился, на сайте гораздо свежее переводы… Нужно бы сверстать pdf поновее :)
Очень полезный ресурс, несомненно! Если это Ваше творение, тогда ОГРОМНОЕ СПАСИБО! Очень помогает! Особенно, когда начинаешь изучать RoR. У меня www.rusrails.ru/ всегда открыт на одной из вкладок.
Вам не кажеться что это уже заезженная тема?
Ну а это вообще вершина:
source /Путь_к_домашней_директории*/.rvm/scripts/rvm
особенно когда потом пишете
. ~/.bash_profile
Ну а это вообще вершина:
source /Путь_к_домашней_директории*/.rvm/scripts/rvm
особенно когда потом пишете
. ~/.bash_profile
Я понимаю, что пост нацелен на то, чтобы помочь поднять рельсы людям, которые не рискнули немного поднапрячься и погуглить или заглянуть в pick axe. И возможно это дело благое, все-таки все по разному обучаются, и не мне судить. Но упрощая, не создавайте дополнительный хаос высказываниями вроде
"@" означает, что переменная будет передана в шаблон.не стоит забывать, что мы все-таки не на рельсах программируем, а на руби.
Да жесть, полная жесть там в статье.
Вот это например: «Кстати, синтаксис языка очень чувствителен к табуляциям — их очень хорошо можно отслеживать в редакторе, которым пользуюсь я — sublime_text» — что это вообще такое? Речь о Python'e может быть идет??
Action'ы в контроллерах сразу преподносятся не в rest'овом стиле, зачем делать index, если можно сделать list. Офигеть. RVM без гемсетов, зачем его ставить тогда. Мое личное мнение такие статьи нужно писать когда уже давно ориентируешься в теме, когда есть опыт и действительно можешь дать совет новчикам. А это полная жесть.
Вот это например: «Кстати, синтаксис языка очень чувствителен к табуляциям — их очень хорошо можно отслеживать в редакторе, которым пользуюсь я — sublime_text» — что это вообще такое? Речь о Python'e может быть идет??
Action'ы в контроллерах сразу преподносятся не в rest'овом стиле, зачем делать index, если можно сделать list. Офигеть. RVM без гемсетов, зачем его ставить тогда. Мое личное мнение такие статьи нужно писать когда уже давно ориентируешься в теме, когда есть опыт и действительно можешь дать совет новчикам. А это полная жесть.
И многое Вы сможете с этой стандартной CRUD-логикой? Все-равно придется практически все переделывать, если это хоть немного серьезный проект, а не учебный пример.
Уже имею опыт разработки на RoR, и пользовался scaffold только в самом начале… совершенно не впечатлило использование «строительных лесов». Хотя спорить не буду — это очень удобный механизм для построения каркаса приложения.
Но тем не менее, можно подробнее о «Ну вообще-то да, многое.». Например? Кроме того, что за вас построен каркас приложения с минимальной функциональностью?
Но тем не менее, можно подробнее о «Ну вообще-то да, многое.». Например? Кроме того, что за вас построен каркас приложения с минимальной функциональностью?
Просто ради интереса. Достаточно громоздкая архитектура базы — это какая по Вашему мнению? На каждый чих отдельная модель с контроллером? Уж не из тех ли Вы, кто полагает, что «на каждую „сущность“ — отдельный класс»?
Вы так говорите, как будто это что-то плохое «на каждую „сущность“ — отдельный класс». Контроллер на каждый «чих» не обязателен, но вот модель, имхо, да. Исключение разве что, когда возникает необходимость в оптимизации, и тогда проводишь «денормализацию», делая, например,
user.profile_address_city_name вместо user.priofle.address.city.name, порождая классы с десятками, а то и сотнями полей, логически друг с другом слабо связанными. Хммм… все ясно.
Тогда Вам точно без скаффолдов никак.
Вопросов более не имею.
Тогда Вам точно без скаффолдов никак.
Вопросов более не имею.
Надеялся на более конструктивный разговор. По вашему тону похоже, что я заблуждаюсь в чем-то, но вот в чем вы не говорите.
Почему-то мне кажется, что Вы — фанатик ООП, так показалось. А я избегаю ООП-фанатизма. Поэтому и свел тему на нет.
Вполне возможно, что мне просто показалось.
Вполне возможно, что мне просто показалось.
Да нет, не фанатик. Скорее я фанатик мультипарадигменных языков, которые мне позволяют выбирать ту парадигму, которую я считаю более уместной в данном контексте, а не искусственно меня загоняют в рамки какой-то конкретной, будь-то ООП, ФП, ПП или ещё какое *П. Правда, очень часто при решении конкретных задач я выбираю именно ООП парадигму за основу или к ней перехожу в процессе. По крайней мере в части приложения, касающейся бизнес-логики — как-то так получается, что чаще всего приходится моделировать объекты реального (или вымышленного) мира со своими свойствами и поведением в рамках грамматики «субъект как-то действует на объект», а не «два объекта на равных взаимодействуют».
Тогда все же, какую архитектуру БД Вы считаете громоздкой? Я так и не получил ответа…
Я предпочитаю слова «архитектура модели». Но в целом считаю громоздкой, если в одной сущности (таблице) содержится больше 5-7, край — 10 свойств (столбцов). А это обычно означает, что нужно вводить много небольших классов и описывать связи междуними, даже если это строгие 1:1 связи. Ладно ьописать сами свойства, но вот отдельную синтаксическую обвязку для каждой группы свойств…
Нет, все же мои предположения подтверждаются, как ни крути… Вы, конечно же, будете возражать и приведете множество доводов в свою пользу. Я даже спорить не буду. Дело Ваше — плодите классы пачками, пока не столкнетесь с поистине сложным проектом, в котором просто начнете путаться в этом зоопарке объектов и классов, и даже скаффолд будет не в помощь.
Довольно показательна на эту тему шуточная статья:
inet777.ru/skladyivaem-chisla-v-oop-stile/8660
Я не против ООП, не против скаффолда, но все должно быть разумно и в меру.
Удачи Вам!
Довольно показательна на эту тему шуточная статья:
inet777.ru/skladyivaem-chisla-v-oop-stile/8660
Я не против ООП, не против скаффолда, но все должно быть разумно и в меру.
Удачи Вам!
… да, еще вдогонку… так, к слову…
вместо того, чтобы использовать спокойно 10-20-… свойств в одной модели, что ничем страшным не грозит, Вы предпочтете поделить это все… не понятно для чего и почему, но тем не менее… А вот это бессмысленное деление просто ради отдельных сущностей, классов приводит к увеличению нагрузки как на сервер БД, так и на само приложение. Так, просто к сведению. Или тормоза ради ООП — это оправдано?
Советую почитать книги по ООП-проектированию. Кстати, ни в одной из них не читал о том, чтобы класс делили на несколько только потому, что якобы перебор с количеством свойств получился. Все же классы определяются по иным принципам.
вместо того, чтобы использовать спокойно 10-20-… свойств в одной модели, что ничем страшным не грозит, Вы предпочтете поделить это все… не понятно для чего и почему, но тем не менее… А вот это бессмысленное деление просто ради отдельных сущностей, классов приводит к увеличению нагрузки как на сервер БД, так и на само приложение. Так, просто к сведению. Или тормоза ради ООП — это оправдано?
Советую почитать книги по ООП-проектированию. Кстати, ни в одной из них не читал о том, чтобы класс делили на несколько только потому, что якобы перебор с количеством свойств получился. Все же классы определяются по иным принципам.
Я делю не просто количественно, а логически. В книгах по проектированию это называется «декомпозиция» (процесс очень похож на нормализацию РБД). Иногда ну никак не избавиться от пары десятков свойств — в смысле никак их не сгруппировать логически. А что до нагрузки — когда будут тормоза, тогда и буду решать, а так мне проще оперировать кучей небольших классов, как правило разделенных на несколько уровней, чем одним большим суперклассом.
«Но в целом считаю громоздкой, если в одной сущности (таблице) содержится больше 5-7, край — 10 свойств (столбцов). А это обычно означает, что нужно вводить много небольших классов и описывать связи междуними, даже если это строгие 1:1 связи. „
как-то не вяжется с
“Я делю не просто количественно, а логически.»
так все-таки что играет роль — логика или количество столбцов?
Вы уже начинаете противоречить сами себе.
В общем-то я уже закончил диалог. Мне не интересны беседы с ООП-фанатами.
Всего хорошего!
(кстати, о минусах… видимо, у Вас товарищ есть, который Вас поддерживал на рабочей неделе (-2 в каждом моем посте, и соответственно +2 — в каждом Вашем), а сегодня Вы в одиночку трудитесь (-1 — +1) — очевидная тенденция. Не утруждайтесь, меня минуса не пугают.)
как-то не вяжется с
“Я делю не просто количественно, а логически.»
так все-таки что играет роль — логика или количество столбцов?
Вы уже начинаете противоречить сами себе.
В общем-то я уже закончил диалог. Мне не интересны беседы с ООП-фанатами.
Всего хорошего!
(кстати, о минусах… видимо, у Вас товарищ есть, который Вас поддерживал на рабочей неделе (-2 в каждом моем посте, и соответственно +2 — в каждом Вашем), а сегодня Вы в одиночку трудитесь (-1 — +1) — очевидная тенденция. Не утруждайтесь, меня минуса не пугают.)
Вот смотрю я на некоторые таблицы, вижу, что они громоздкие, но ничего не могу с этим сделать (кроме как разделить чисто количественно, без всякой логики) — я и не делаю. Но если вижу в таблице, например, user 50 столбцов, которые можно сгруппировать по признакам типа аутентификационные данные, адрес, контактные данные, статистика, рейтинги и т. п., то я их группирую (переношу в отдельные таблицы). Хотя бы чтобы просто в IDE в автодополнении после точки не появлялся список на 50 полей, а только 5-7.
Насчёт минусов — это вы мимо. Не ко мне.
Насчёт минусов — это вы мимо. Не ко мне.
Мы живем в объективном мире. Объект, как философская категория зародился, тысячилетия назад. ООП как парадигма насчитывает 15-20 лет? Разработка любого приложения по сути проекция взаимодействия объектов. В какой парадигме ее реализовать — дело каждого конкретного разработчика.
Удивляюсь почему ООП выделятся Вами в парадигму достойную отчуждения. Тем более, в хабе где среда разработки подразумевает, что вообще все объект. Вас минусуют за свои уставы в отдельно взятом, и видимо чужом для Вас, монастыре.
И уж никто из адекватных специалистов не усомнится, что процедурное программирование, например, это круто! И тем более ругать функциональное программирование за «чтобытонибыло».
Удивляюсь почему ООП выделятся Вами в парадигму достойную отчуждения. Тем более, в хабе где среда разработки подразумевает, что вообще все объект. Вас минусуют за свои уставы в отдельно взятом, и видимо чужом для Вас, монастыре.
И уж никто из адекватных специалистов не усомнится, что процедурное программирование, например, это круто! И тем более ругать функциональное программирование за «чтобытонибыло».
Знаете, я не против ООП, я ООП сам с успехом использую. Не нужно говорить, что я типа в чужом монастыре. Если бы Вы читали внимательно диалоги и старались понять, то пришло бы понимание того, что я против фанатизма в ООП — когда любую мелочь стараются сделать объектом. ООП призвано облегчить разработку, его использование должно быть целесообразным и уместным, но почему-то некоторые считают, что если уж ООП, то «ээээххх! щас прокачу» — кучу объектов наворочу!
Давайте простой пример. Запись о человеке — вот то, что можно смело реализовать в виде объекта с конкретными свойствами: фамилия, имя, отчество, пол, возраст, место рождения, адрес проживания, место работы и т.п.
А вот тот же пример на фанатичном ООП уровне. Имя человека — объект со свойствами: фамилия, имя и отчество. Возраст — объект типа число. Пол — тоже отдельный объект. Адрес проживания, место проживания — два разных объекта класса Адрес, место работы — тоже отдельный объект. Все они, естественно, связаны между собой, потом сверху приправлены интерфейсом и, возможно, не одним, различными proxy, декораторами, фабриками и т.п.
Чувствуете разницу?
Прежде чем возражать, желательно бы все-таки постараться понять, против чего я тут высказываюсь.
Давайте простой пример. Запись о человеке — вот то, что можно смело реализовать в виде объекта с конкретными свойствами: фамилия, имя, отчество, пол, возраст, место рождения, адрес проживания, место работы и т.п.
А вот тот же пример на фанатичном ООП уровне. Имя человека — объект со свойствами: фамилия, имя и отчество. Возраст — объект типа число. Пол — тоже отдельный объект. Адрес проживания, место проживания — два разных объекта класса Адрес, место работы — тоже отдельный объект. Все они, естественно, связаны между собой, потом сверху приправлены интерфейсом и, возможно, не одним, различными proxy, декораторами, фабриками и т.п.
Чувствуете разницу?
Прежде чем возражать, желательно бы все-таки постараться понять, против чего я тут высказываюсь.
Эмм. Ну я на своем веке встречал не одно приложение, где адрес, вуз и место работы объекты, а не просто строчные поля в базе :)
Если это одна тупая запись с которой не нужно работать, то бог с ней. Везьде есть мера.
В остальный случаях — денормальизация. Т.е. если вы не взаимодействуете со свойством сложнее чем вывод значения на экран, то заводить ради этого десятки свойств — плохой тон, 100500 лет назад для этого придумана сериализация.
А что вы имели в виду, мне так и не ясно. Возможно это не моя проблема.
Начали со скафолдов закончили за упокой.
Если это одна тупая запись с которой не нужно работать, то бог с ней. Везьде есть мера.
В остальный случаях — денормальизация. Т.е. если вы не взаимодействуете со свойством сложнее чем вывод значения на экран, то заводить ради этого десятки свойств — плохой тон, 100500 лет назад для этого придумана сериализация.
А что вы имели в виду, мне так и не ясно. Возможно это не моя проблема.
Начали со скафолдов закончили за упокой.
> А что вы имели в виду, мне так и не ясно. Возможно это не моя проблема.
Ну если уже и после последнего ответа не поняли, тут уже вообще ничем не могу помочь, извиняйте.
> Начали со скафолдов закончили за упокой.
Отвечал на возникшие вдруг возражения, только лишь.
Еще вопросы будут? Или все-равно вы меня не понимаете, то смысл?
Ну если уже и после последнего ответа не поняли, тут уже вообще ничем не могу помочь, извиняйте.
> Начали со скафолдов закончили за упокой.
Отвечал на возникшие вдруг возражения, только лишь.
Еще вопросы будут? Или все-равно вы меня не понимаете, то смысл?
Если в системе много объектов у которых есть свойство «город проживания», и с городами нужно работать то город резко становится объектом со своими счетчиками и связями со странами и регионами.
Если фейсбук группирует по местам работы пользователей, то место работы резко становится объектом.
А из имени объект класса имя никто делать не будет, такую идиотию никто не прелагал.
Если фейсбук группирует по местам работы пользователей, то место работы резко становится объектом.
А из имени объект класса имя никто делать не будет, такую идиотию никто не прелагал.
> такую идиотию никто не прелагал.
Хорошо, если Вы это понимаете.
Но вот некоторые цитаты из этой ветки диалога, если Вы сами не удосужились понять, против чего я возражал:
«Я предпочитаю слова «архитектура модели». Но в целом считаю громоздкой, если в одной сущности (таблице) содержится больше 5-7, край — 10 свойств (столбцов). А это обычно означает, что нужно вводить много небольших классов и описывать связи междуними, даже если это строгие 1:1 связи. „
“Но если вижу в таблице, например, user 50 столбцов, которые можно сгруппировать по признакам типа аутентификационные данные, адрес, контактные данные, статистика, рейтинги и т. п., то я их группирую (переношу в отдельные таблицы). Хотя бы чтобы просто в IDE в автодополнении после точки не появлялся список на 50 полей, а только 5-7.»
Что это? Это ООП? Когда человек пилит на несколько объектов со связями 1:1 только потому, что его напугало большое количество полей. Это бред!
Хорошо, если Вы это понимаете.
Но вот некоторые цитаты из этой ветки диалога, если Вы сами не удосужились понять, против чего я возражал:
«Я предпочитаю слова «архитектура модели». Но в целом считаю громоздкой, если в одной сущности (таблице) содержится больше 5-7, край — 10 свойств (столбцов). А это обычно означает, что нужно вводить много небольших классов и описывать связи междуними, даже если это строгие 1:1 связи. „
“Но если вижу в таблице, например, user 50 столбцов, которые можно сгруппировать по признакам типа аутентификационные данные, адрес, контактные данные, статистика, рейтинги и т. п., то я их группирую (переношу в отдельные таблицы). Хотя бы чтобы просто в IDE в автодополнении после точки не появлялся список на 50 полей, а только 5-7.»
Что это? Это ООП? Когда человек пилит на несколько объектов со связями 1:1 только потому, что его напугало большое количество полей. Это бред!
Началось все с CRUD. CRUD для рельсовика это как grep для юниксойда. И да, все можно сделать CRUD-ом. Это необходимые и достаточные операции над объектом, как раз чтобы сущности не плодить :)
Потом началось группирование объектов по признакам, «которые можно сгруппировать по признакам» — связь 1 ко многим, или разместить в этом же объекте в своих группах.
Это удобство разработки, а вовсе не бред. Невозможно вычленить глазами все свойства объекта, особенно если их 50. А если дебаг? Сколько строк на экране займет объект с 50-ю свойствами. Да это нужно попилить в 1:1 лишь бы довести проект до рабочего конца. А джоин одного объекта по индексу погоду не сделает :) Да и не бывает такого, обычно столько свойств хранить не нужно. Самое длинние что я видел на своей практике — характеристики автомобиля — но хранить их в одной записи в виде 50-ти полей — полный бред.
Предложите по-настоящему сложный объект у которого 50 полей и с этим ничего нельзя сделать?
Потом началось группирование объектов по признакам, «которые можно сгруппировать по признакам» — связь 1 ко многим, или разместить в этом же объекте в своих группах.
Это удобство разработки, а вовсе не бред. Невозможно вычленить глазами все свойства объекта, особенно если их 50. А если дебаг? Сколько строк на экране займет объект с 50-ю свойствами. Да это нужно попилить в 1:1 лишь бы довести проект до рабочего конца. А джоин одного объекта по индексу погоду не сделает :) Да и не бывает такого, обычно столько свойств хранить не нужно. Самое длинние что я видел на своей практике — характеристики автомобиля — но хранить их в одной записи в виде 50-ти полей — полный бред.
Предложите по-настоящему сложный объект у которого 50 полей и с этим ничего нельзя сделать?
> Предложите по-настоящему сложный объект у которого 50 полей и с этим ничего нельзя сделать?
По-настоящему разумное решение — это не делать с объектом ничего, если в этом нет никакой необходимости, когда не появляются удобные связи 1:n, когда нет деления на общее и частное. В том-то и дело, что не нужно пытаться обязательно что-то сделать. Ну 50 полей… и что? Что из этого? ООП ради ООП?
И все, давайте уже на этом закончим. Не вижу смысла продолжать диалог, тем более, когда собеседник все-равно недопонимает или совсем не понимает сказанного мной.
Фрейд: «Есть только намерение — помнить или забыть».
Так вот у вас намерение во что бы то ни было опровергнуть.
По-настоящему разумное решение — это не делать с объектом ничего, если в этом нет никакой необходимости, когда не появляются удобные связи 1:n, когда нет деления на общее и частное. В том-то и дело, что не нужно пытаться обязательно что-то сделать. Ну 50 полей… и что? Что из этого? ООП ради ООП?
И все, давайте уже на этом закончим. Не вижу смысла продолжать диалог, тем более, когда собеседник все-равно недопонимает или совсем не понимает сказанного мной.
Фрейд: «Есть только намерение — помнить или забыть».
Так вот у вас намерение во что бы то ни было опровергнуть.
> Ну я на своем веке встречал не одно приложение, где адрес, вуз и место работы объекты, а не просто строчные поля в базе.
Согласен, имеет смысл сделать объектами, но только в том случае, если будут использованы связи 1:n, т.е. есть всего несколько вузов и определенные предприятия.
Опять же, все дело во внимательном прочтении и Вашем намерении либо понять, либо изначально опровергнуть.
Сделаю акцент: «Адрес проживания, место рождения — два разных объекта класса Адрес», чтобы конкретно Вам было понятнее.
Согласен, имеет смысл сделать объектами, но только в том случае, если будут использованы связи 1:n, т.е. есть всего несколько вузов и определенные предприятия.
Опять же, все дело во внимательном прочтении и Вашем намерении либо понять, либо изначально опровергнуть.
Сделаю акцент: «Адрес проживания, место рождения — два разных объекта класса Адрес», чтобы конкретно Вам было понятнее.
Сделаю акцент: «Адрес проживания, место рождения — два разных объекта класса Адрес», чтобы конкретно Вам было понятнее.
Вы издеваетесь?
> Вы издеваетесь?
Отнюдь. Но Ваше нежелание понять, вникнуть, а, возможно, просто невозможность Вами понимания точки зрения отличной от вашей… это уже Ваши проблемы, мне абсолютно параллельно…
> Вас минусуют за свои уставы в отдельно взятом, и видимо чужом для Вас, монастыре.
У многих срабатывает стадное чувство на заминусованные посты. Один небуч минусанул, другой поддержал. И тут же возникает чувство общности, желание принадлежности к правильному мнению. Отсюда и ответы явной направленности — опровергнуть.
Кстати, минусы в мой адрес — совершенно мимо, никоим образом не расстраивает даже.
Я не буду с вами спорить, мне это неинтересно.
Удачи Вам!
Отнюдь. Но Ваше нежелание понять, вникнуть, а, возможно, просто невозможность Вами понимания точки зрения отличной от вашей… это уже Ваши проблемы, мне абсолютно параллельно…
> Вас минусуют за свои уставы в отдельно взятом, и видимо чужом для Вас, монастыре.
У многих срабатывает стадное чувство на заминусованные посты. Один небуч минусанул, другой поддержал. И тут же возникает чувство общности, желание принадлежности к правильному мнению. Отсюда и ответы явной направленности — опровергнуть.
Кстати, минусы в мой адрес — совершенно мимо, никоим образом не расстраивает даже.
Я не буду с вами спорить, мне это неинтересно.
Удачи Вам!
Кстати, ваше наигранное непонимание не прибавляет Вам и Вашим высказываниям значимости и не характеризует Вас как более грамотного, чем Ваш собеседник. Ошибочный прием в разговоре — изображать искреннее непонимание и недоумение. Конечно, ЧСВ от этого у Вас явно повышается, не более того.
Непонимание — это… ну сами понимаете, надеюсь.
Непонимание — это… ну сами понимаете, надеюсь.
С одной стороны это адреса разных событий, значит вы издеваетесь, мол я не могу понять, чо это экземпляры одного класса.
С другой стороны адрес проживания длинный с индексом, городом, страной, улицами и домом, который, на почте например, нужен в развернутом виде, а место рождения всеголишь страна и город, причем можно через запятую, т.к. место рождения не несет никакого смысла, даже юридического. Тогда это как понимать?
Я правильно не понимаю?
А на личности переходить ну уж совсем не этично.
С другой стороны адрес проживания длинный с индексом, городом, страной, улицами и домом, который, на почте например, нужен в развернутом виде, а место рождения всеголишь страна и город, причем можно через запятую, т.к. место рождения не несет никакого смысла, даже юридического. Тогда это как понимать?
Я правильно не понимаю?
А на личности переходить ну уж совсем не этично.
опечатка:
вместо: «Адрес проживания, место проживания — ...»
следует читать: «Адрес проживания, место рождения — ...»
не успел поправить, пока возможность была… на хабре это время ограничено
вместо: «Адрес проживания, место проживания — ...»
следует читать: «Адрес проживания, место рождения — ...»
не успел поправить, пока возможность была… на хабре это время ограничено
Написано небрежно, с туевой хучей опечаток.
Команды rails в сокращённом виде. Новичкам, для которых вы написали статью, хорошо бы объяснить, что «d» — это «destroy», «g» — «generate» и так далее.
«sublime_text» это переменная руби что ли? Видно, что вы торопились или скопировали из своего личного блокнотика и добавили текста, раз название редактора написали хер знает как.
Где здесь? Ссылки нет.
Ждём от вас статью «учимся программировать микроконтроллеры на ассемблере за 10 минут».
Для новичков есть замечательнейший учебник: railstutorial.ru. Первые две главы оттуда намного наглядней, легче и интересней объяснят то же самое, что и в этом недопосте.
Команды rails в сокращённом виде. Новичкам, для которых вы написали статью, хорошо бы объяснить, что «d» — это «destroy», «g» — «generate» и так далее.
«sublime_text» это переменная руби что ли? Видно, что вы торопились или скопировали из своего личного блокнотика и добавили текста, раз название редактора написали хер знает как.
Документацию по HAML можно почитать здесь
Где здесь? Ссылки нет.
Ждём от вас статью «учимся программировать микроконтроллеры на ассемблере за 10 минут».
Для новичков есть замечательнейший учебник: railstutorial.ru. Первые две главы оттуда намного наглядней, легче и интересней объяснят то же самое, что и в этом недопосте.
Согласен. Пост вообще ниачем! Такой пост только отпугнет от Рельсов.
Сам начать изучать RoR со знакомства с railstutorial.ru — очень неплохо все описано, по шагам. Только новичкам посоветую смело пропускать всю информацию, касающуюся тестирования. Поверьте мне, информация о построении тестов только мешает первоначальному восприятию нового материала, а пропустив ее вы ничего не потеряете. Я понимаю, что автор как бы сразу пытается показать хороший тон программирования, но для такого туториала — это лишнее.
Вот как я начинал:
inet777.ru/izuchenie-ruby-i-ruby-on-rails/8470
Сам начать изучать RoR со знакомства с railstutorial.ru — очень неплохо все описано, по шагам. Только новичкам посоветую смело пропускать всю информацию, касающуюся тестирования. Поверьте мне, информация о построении тестов только мешает первоначальному восприятию нового материала, а пропустив ее вы ничего не потеряете. Я понимаю, что автор как бы сразу пытается показать хороший тон программирования, но для такого туториала — это лишнее.
Вот как я начинал:
inet777.ru/izuchenie-ruby-i-ruby-on-rails/8470
Переписывал действительно из записей, которые накидывал по ходу… Мне казалось, что написано более-менее гладко, но неудачный опыт написания статьи такого плана тоже опыт. Все неточности и ошибки устраню по мере сил.
До ассемблера надеюсь не дойдёт в ближайшем будущем)
До ассемблера надеюсь не дойдёт в ближайшем будущем)
В этой маленькой статье, которую с удовольствием прочитал бы сам неделю назад...
Обычно с таких слов начинаются статьи, полные ереси и вредных советов. Вы неделю назад начали изучать рельсы, ну куда вы ломитесь писать статьи для новичков? Разберитесь сначала хоть немного в основах.
так как статья написана совсем начинающим для таких же начинающих, было бы правильным добавить в каких именно проектах стоит использовать RoR и в каких случаях он просто избыточен. Честно говоря ожидал это увидеть в разделе «Зачем» но там ничего про это не сказано. П.С. Тоже начинающий как и вы :)
RoR избыточен для «Hello, World!», для всех остальных веб-приложений — в самый раз!
В разделе «Зачем» я попытался объяснить зачем я всё это написал)
Я думаю, он избыточен если только для написания сайта-визитки или персонального блога.
Сам изучаю ввиду того, что в ближайшем будущем буду заниматься поддержкой проекта, написанного именно на RoR.
Я думаю, он избыточен если только для написания сайта-визитки или персонального блога.
Сам изучаю ввиду того, что в ближайшем будущем буду заниматься поддержкой проекта, написанного именно на RoR.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ruby on Rails. Установка, настройка, начало работы