> В каких целях лучше применять Sinatra вместо Ruby On Rails?
Sinatra хорошо подходит для написания веб-сервисов, когда у вас нет фронтенда в виде веб-интерфейса… Ну самый распространённый пример — флеш-игра в какой-нибудь соц.сети.
Для не слишком больших веб-приложений также имеет смысл присмотреться к Padrino.
Хотя сейчас границы применимости всё больше смешиваются, в том же RoR можно использовать и Rack-вызовы напрямую, и убрать все модули, ненужные для конкретного случая, из контроллера. Т.е. по сути в большинстве случаев это уже дело вкуса… исходя из того, что вам ближе: выпиливание или допиливание, убирать ненужные модули или искать и добавлять нужные.
P.S. Любителям легковесных контроллеров стоит присмотреться к Cells, которые с недавних пор можно использовать и для внешних вызовов.
Если бы в Sinatra добавили часто используемые фичи, то это был бы не DSL, а фреймворк…
А так есть DSL и есть куча надстроек над ним, начиная от sinatra-basic-auth и до Padrino — фреймворка поверх Sinatra.
Да дело тут даже не в том будет работать омнибар или нет, а в том что это вообще очень спорный подход для определения события «загружены все важные модули». От Google было бы логичнее ожидать более качественного решения, чем использование magick timeout, хотя бы с callback на нужном событии.
Как вариант можно проверять валидность домена, вместо того чтобы проверять его HEAD-запросом… Хотя это может обидеть любителей прописать невалидные домены в /etc/hosts для своих локальных сайтов :-)
> Так что, как ни крути, а начинающий писатель на vbscript и писатель программы рассчёта траектории полёта космического аппарата, оба они программисты.
Ну из начинающего писателя на vbscript такой же программист, как из школьника с учебником биологии — врач. Всё-таки чтобы именоваться программистом надо знать как минимум пару языков программирования и хотя бы основы в области алгоритмов и структур данных.
А почему все примеры для веб-разработки? Все ООП, да ещё и все на одних и тех же базовых паттернах. Так не интересно, по сути тут нет никакого перехода, всё в рамках одной специализации. Практического толку мало, но при этом есть серьёзная опасность начать в одном фреймворке искать что-то из другого, что грозит попаданием в патовую ситуацию «а мне всегда чего-то не хватает...» ;-)
Тут ещё надо помнить, что освоить язык — это не то же самое что освоить синтаксис. Язык можно считать освоенным только когда вы можете на нём думать. В случае с языками одной парадигмы это не особо сложно, но если меняется парадигма, то это уже смена специальности, а не специализации.
«Без проблем переключиться» — это значит придти на другое место работы и сразу работать наравне с теми, кто там работает. В данных примерах так не получится, придётся проходить практически полную переквалификацию, а потом ещё заново проходить всю иерархию, начиная с джуниора, если не со стажера.
Итого переход с должности ведущего программиста на .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 там используются для усиления изоляции, а Вы пытаетесь эту изоляцию нарушить, а это ни к чему хорошему не приведёт.
Sinatra хорошо подходит для написания веб-сервисов, когда у вас нет фронтенда в виде веб-интерфейса… Ну самый распространённый пример — флеш-игра в какой-нибудь соц.сети.
Для не слишком больших веб-приложений также имеет смысл присмотреться к Padrino.
Хотя сейчас границы применимости всё больше смешиваются, в том же RoR можно использовать и Rack-вызовы напрямую, и убрать все модули, ненужные для конкретного случая, из контроллера. Т.е. по сути в большинстве случаев это уже дело вкуса… исходя из того, что вам ближе: выпиливание или допиливание, убирать ненужные модули или искать и добавлять нужные.
P.S. Любителям легковесных контроллеров стоит присмотреться к Cells, которые с недавних пор можно использовать и для внешних вызовов.
А так есть DSL и есть куча надстроек над ним, начиная от sinatra-basic-auth и до Padrino — фреймворка поверх Sinatra.
gedit +номер_строки имя_файла
Ну из начинающего писателя на vbscript такой же программист, как из школьника с учебником биологии — врач. Всё-таки чтобы именоваться программистом надо знать как минимум пару языков программирования и хотя бы основы в области алгоритмов и структур данных.
Итого переход с должности ведущего программиста на .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 там используются для усиления изоляции, а Вы пытаетесь эту изоляцию нарушить, а это ни к чему хорошему не приведёт.