А почему все примеры для веб-разработки? Все ООП, да ещё и все на одних и тех же базовых паттернах. Так не интересно, по сути тут нет никакого перехода, всё в рамках одной специализации. Практического толку мало, но при этом есть серьёзная опасность начать в одном фреймворке искать что-то из другого, что грозит попаданием в патовую ситуацию «а мне всегда чего-то не хватает...» ;-)
Тут ещё надо помнить, что освоить язык — это не то же самое что освоить синтаксис. Язык можно считать освоенным только когда вы можете на нём думать. В случае с языками одной парадигмы это не особо сложно, но если меняется парадигма, то это уже смена специальности, а не специализации.
«Без проблем переключиться» — это значит придти на другое место работы и сразу работать наравне с теми, кто там работает. В данных примерах так не получится, придётся проходить практически полную переквалификацию, а потом ещё заново проходить всю иерархию, начиная с джуниора, если не со стажера.
Итого переход с должности ведущего программиста на .NET на ведущего программиста на C займёт года 3 в лучшем случае, а в худшем человек вообще не сможет программировать на новом языке на столь же высоком уровне, какой у него был на привычном языке… Кстати, всё то же самое верно и при попытке перехода в другую сторону с C на C#.
> Только не забыть, что после malloc надо вызывать free, а функциям передавать this в качестве отдельного аргумента.
Ну конечно, это ж единственные отличия… А libc и .NET — просто близнецы-братья :-)
Это всего касается… или Вы действительно считаете, что человек годами программировавший на C#, без особых усилий возьмёт и за пару месяцев перейдёт на Erlang или на Haskell или на Prolog или на C? Далеко не все языки программирования базируются на ОО-парадигме. Поэтому способность мыслить объектами легко может стать непробиваемым барьером для программирования на многих языках, если человек не сможет эту способность при необходимости полностью отключать.
> в любой сфере деятельности можно прийти к выводу, что профессия, которая занимается этой деятельностью — суперобобщение.
Так и есть. Хотя автору статьи кажется, что физик — это очень конкретная специальность, но на деле специализаций у физиков гораздо больше, чем у программистов. И точно так же представитель одной специализации не может сходу подменить представителя любой другой. Точно так же есть базовые знания, общие для всех специализаций. И точно так же при необходимости квалифицированный специалист может переквалифицироваться в другую специализацию за 1-2 года, если ему до пенсии ещё далеко ;-)
В общем иерархия практически везде примерно такая: профессия — специальность — специализация.
Ну во-первых, с помощью Cells можно делать в том числе и контроллеры недоступные через HTTP. Другими словами можно просто не подключать к ним роутинг.
А во-вторых, ограничения — это контракт для разработчиков, работающих над проектом. А то Вы с такой позицией далеко в неправильное направление рискуете уйти, ведь ничто нам не помешает вызвать метод через var.send(:method), но это отнюдь не повод отказываться от объявления приватных методов; ведь ничто не помешает сохранить невалидную модель через raw SQL(если нет валидации на уровне СУБД), но это не повод не писать валидации и т.д. и т.п.
Да, практически любое ограничение можно нарушить, а изредка даже нужно, но в целом именно следование конвенциям в рамках ограничений в конечном итоге и отличает качественный код от лапшы.
Для того, чтобы синхронно вызвать другой контроллер в том же приложении (процессе/потоке) из представления другого контроллера Cells подходит идеально.
Теперь по поводу произвольности вызываемого контроллера…
На мой взгляд, разрешение вызова контроллера из представления — это серьёзное архитектурное решение и если фреймворк сам принимает это решение, разрешая подобный доступ к любому контроллеру, то это очень плохо. Только разработчик должен решать какие действия каких контроллеров можно так дёргать, что не отменяет возможности дёргать их и через обычный HTTP-запрос при желании.
Что касается веб-сервисов, то, на мой взгляд, они должны возвращать клиентскому коду только данные и ничего кроме данных. Для использования таких сервисов собственного сочинения отлично подходит ActiveResource, но это уже к вопросу о разнесении частей приложения по разным серверам…
Скажем прямо, подобный приём масштабирования действительно нужен крайне редко и, как правило, для узкоспециальных вещей. Потребности в неком универсальном решении для произвольного контроллера такие задачи не имеют.
Похоже мы говорим о разных вещах…
HMVC, в моем представлении, — это возможность из одного контроллера (или из его представления) вызвать другой контроллер и получить в качестве результата его представление, т.е. в любом случае либо кусочек html, либо plain text, либо некую структуру данных (не важно в xml, json, etc.), чего уж тут смешного… Это помогает решить проблему с чистотой MVC, когда представления состоят из разнородных блоков.
А вопросы коммуникации веб-сервисов, на мой взгляд, никакого отношения к HMVC не имеют.
Большая просьба писать английские слова английскими буквами или по возможности заменять на русские слова… А то канвасы, эпики и фасилитации сильно затрудняют чтение.
P.S. За книгу спасибо.
Ну причём здесь Rails Engines? Они придуманы для повторного использования изолированных кусков приложения, а не для HMVC.
Те же namespace там используются для усиления изоляции, а Вы пытаетесь эту изоляцию нарушить, а это ни к чему хорошему не приведёт.
Не, ну может быть я чего-то не понимаю, но если у вас возникает необходимость вызывать собственное приложение через внешний HTTP-вызов, чтобы получить кусочек html или некую структуру данных, то это epic fail в архитектуре и «HMVC» призывается лишь с целью отвлечь внимание от проблемы.
> В Cells каждый компонент не является полноценным MVC.
С чего вдруг? Cells-контроллеры наследуют AbstractController::Base из Rails, имеют доступ к моделям и могут рендерить любые views. Абсолютно полноценный MVC.
> я думаю, что вполне реально делать эти запросы какими-то внутренними механизмами
Хотите полноценное HMVC в Rails, используйте Cells.
А посылать HTTP-запрос из приложения в это же приложение — это, уж извините, извращение, а не HMVC.
Насчёт ремонта квартир можно сказать, что ситуация делится как минимум на два случая: типовой ремонт и ремонт по индивидуальному проекту.
Согласитесь, сделать евро-ремонт в двушке и осуществить дизайнерский проект в особняке на 1000 кв.м. — это две большие разницы. И если в первом случае, заказчик вправе рассчитывать на оценку с точностью ± 20%, то во втором ему никто точно стоимость не оценит. Так же и с программными проектами, одно дело сайт-визитка и совсем другое очередной «супер-пупер» стартап, в котором заказчик постоянно вносит изменения в требования.
К сожалению, и для реальных проектов нередки случаи, когда какой-нибудь менеджер, оценивающий сроки, наивно полагает, что программисты будут работать над проектом по 168 рабочих часов в месяц. Поэтому в рассказе и подчёркивается игнорирование физических возможностей человека.
Итого переход с должности ведущего программиста на .NET на ведущего программиста на C займёт года 3 в лучшем случае, а в худшем человек вообще не сможет программировать на новом языке на столь же высоком уровне, какой у него был на привычном языке… Кстати, всё то же самое верно и при попытке перехода в другую сторону с C на C#.
> Только не забыть, что после malloc надо вызывать free, а функциям передавать this в качестве отдельного аргумента.
Ну конечно, это ж единственные отличия… А libc и .NET — просто близнецы-братья :-)
Так и есть. Хотя автору статьи кажется, что физик — это очень конкретная специальность, но на деле специализаций у физиков гораздо больше, чем у программистов. И точно так же представитель одной специализации не может сходу подменить представителя любой другой. Точно так же есть базовые знания, общие для всех специализаций. И точно так же при необходимости квалифицированный специалист может переквалифицироваться в другую специализацию за 1-2 года, если ему до пенсии ещё далеко ;-)
В общем иерархия практически везде примерно такая: профессия — специальность — специализация.
А во-вторых, ограничения — это контракт для разработчиков, работающих над проектом. А то Вы с такой позицией далеко в неправильное направление рискуете уйти, ведь ничто нам не помешает вызвать метод через var.send(:method), но это отнюдь не повод отказываться от объявления приватных методов; ведь ничто не помешает сохранить невалидную модель через raw SQL(если нет валидации на уровне СУБД), но это не повод не писать валидации и т.д. и т.п.
Да, практически любое ограничение можно нарушить, а изредка даже нужно, но в целом именно следование конвенциям в рамках ограничений в конечном итоге и отличает качественный код от лапшы.
Теперь по поводу произвольности вызываемого контроллера…
На мой взгляд, разрешение вызова контроллера из представления — это серьёзное архитектурное решение и если фреймворк сам принимает это решение, разрешая подобный доступ к любому контроллеру, то это очень плохо. Только разработчик должен решать какие действия каких контроллеров можно так дёргать, что не отменяет возможности дёргать их и через обычный HTTP-запрос при желании.
Что касается веб-сервисов, то, на мой взгляд, они должны возвращать клиентскому коду только данные и ничего кроме данных. Для использования таких сервисов собственного сочинения отлично подходит ActiveResource, но это уже к вопросу о разнесении частей приложения по разным серверам…
Скажем прямо, подобный приём масштабирования действительно нужен крайне редко и, как правило, для узкоспециальных вещей. Потребности в неком универсальном решении для произвольного контроллера такие задачи не имеют.
HMVC, в моем представлении, — это возможность из одного контроллера (или из его представления) вызвать другой контроллер и получить в качестве результата его представление, т.е. в любом случае либо кусочек html, либо plain text, либо некую структуру данных (не важно в xml, json, etc.), чего уж тут смешного… Это помогает решить проблему с чистотой MVC, когда представления состоят из разнородных блоков.
А вопросы коммуникации веб-сервисов, на мой взгляд, никакого отношения к HMVC не имеют.
P.S. За книгу спасибо.
Те же namespace там используются для усиления изоляции, а Вы пытаетесь эту изоляцию нарушить, а это ни к чему хорошему не приведёт.
С чего вдруг? Cells-контроллеры наследуют AbstractController::Base из Rails, имеют доступ к моделям и могут рендерить любые views. Абсолютно полноценный MVC.
> я думаю, что вполне реально делать эти запросы какими-то внутренними механизмами
как, например, в Cells!
А посылать HTTP-запрос из приложения в это же приложение — это, уж извините, извращение, а не HMVC.
Согласитесь, сделать евро-ремонт в двушке и осуществить дизайнерский проект в особняке на 1000 кв.м. — это две большие разницы. И если в первом случае, заказчик вправе рассчитывать на оценку с точностью ± 20%, то во втором ему никто точно стоимость не оценит. Так же и с программными проектами, одно дело сайт-визитка и совсем другое очередной «супер-пупер» стартап, в котором заказчик постоянно вносит изменения в требования.
А без git работает:
set :scm, :none
?set :repository, "."
set :deploy_via, :copy
Насколько я помню, Capistrano, Unicorn, RVM в принципе Windows не поддерживают… Но кто его знает, может у Capistrano политика изменилась…