Статьи

Роллинг с Синатрой

Когда дело доходит до веб-разработки, Синатра удивительно гибок. В отличие от Rails, он ни в коей мере не является самоуверенным и в основном позволяет принимать все проектные решения. У него есть некоторые соглашения, такие как автоматический поиск шаблонов представления в папке ‘views’, но практически все эти настройки по умолчанию могут быть легко изменены. Синатра не принимает никаких решений за вас — вы буквально начинаете с чистого листа. Константин Хаазе, сопровождающий Sinatra, называет это самой сильной и слабой стороной Sinatra, поскольку Sinatra не помешает вам писать плохой код.

Учитывая, что при создании приложения в Sinatra вы можете сделать так много выбора, я решил спросить и выяснить, как люди катятся, когда они его используют. Я задал следующие вопросы:

  • У вас есть заданная структура папок или шаблоны кодирования?
  • Вы склонны использовать классический или модульный стиль?
  • Используете ли вы какой-либо код начальной загрузки?
  • Вы когда-нибудь использовали inline-представления?
  • Что-нибудь еще?

Я получил несколько интересных ответов, которые я поделился здесь. Вы также можете просмотреть всю ветку здесь:
https://groups.google.com/forum/#!msg/sinatrarb/BFAXCCK3D8I/mXLv6YDoBcAJ

У вас есть заданная структура папок или шаблоны кодирования?

У Sinatra нет структуры каталогов, о которой можно говорить — вы даже не получите папку приложения, если не создадите ее самостоятельно. Как упоминалось ранее, он имеет несколько хороших настроек по умолчанию, таких как автоматическое сохранение шаблонов представлений в каталоге ‘views’ и общедоступных ресурсов в каталоге ‘public’ и использование файла layout.erb в качестве макета по умолчанию. Все это можно легко изменить с помощью метода set, например:

set :public_folder, 'assets' set :views, 'templates' set :erb, :layout => :base 

Многие люди, которых я спрашивал, имели тенденцию использовать подобную Rails структуру папок «Модели, представления и контроллеры». Они также имели тенденцию использовать структуру, аналогичную той, которая используется RubyGems с папками, такими как «lib, test / spec /, public».

Другой популярный метод заключался в использовании файла с именем init.rb, который требует всех других соответствующих файлов. Это делает его полезным для запуска приложения из консоли или во время тестов.

Блейк Мизерани, создатель Sinatra, сказал, что он предпочитает использовать один каталог, где все его модули и представления хранятся в одном месте.

Мне нравится сохранять структуру папок очень простой, обычно с файлом main.rb, который содержит большую часть кода приложения. Затем я обычно использую папку public и views, а затем оставляю ее на этом. Любые дополнительные файлы обычно идут в корневой каталог.

Вы склонны использовать классический или модульный стиль?

Синатра имеет два разных стиля кодирования — классический и модульный. Большинство примеров, которые вы найдете в Интернете, являются классическими приложениями, вот еще один пример:

 require 'sinatra' get '/hello' do "Hello World!" end 

То же приложение, выполненное в модульном стиле, будет выглядеть так:

 require 'sinatra/base' class Hello < Sinatra::Base get '/hello' do "Hello World!" end end 

Как вы можете видеть, основное отличие в модульном приложении состоит в том, что весь код заключен в класс, который разделен на классы Sinatra :: Base. Принимая во внимание, что в классическом приложении вы просто требуете «sinatra» и продолжаете в том же духе — это стиль, используемый в большинстве onine-учебников.

Большинство людей, которые ответили на мои вопросы, предпочли использовать модульный стиль. Джош Чик упомянул, что классический стиль полезен для демонстрации техник (отсюда и причина, по которой он, вероятно, используется для большинства примеров в Интернете).

Джон Нунемейкер (GitHub) сказал:

Я бы никогда больше не использовал классику. Слишком загрязняющий.

Это относится к тому факту, что глобальное пространство имен может быть загрязнено методами с тем же именем. Обычно это не проблема при написании небольших приложений, но может стать проблемой, если вы пишете большое модульное приложение (особенно, если над разными модулями работают разные люди).

Джейсон Роджерс также указал на полезную технику, которая помогает сопоставить ваши URL с определенным классом:

Если я собираюсь разделять ресурсы по отдельным путям (например, «/ admin», «/ api» и т. Д.), Я буду использовать модульный подход и сопоставлять отдельные модули в Rack под их путевым именем.

Это можно сделать в файле config.ru с помощью метода map Rack, например:

 require 'sinatra/base' require './main' map('/admin') { run adminController } map('/api') { run apiController } 

Лично я люблю использовать классические приложения и считаю, что они очень прямолинейны, что позволяет быстро приступить к написанию кода. Недостатков немного, и очень легко перейти к модульному приложению, если оно становится больше. Однако, если вы хотите упаковать свое приложение как драгоценный камень или расширение, тогда вам действительно нужно использовать модульный стиль.

Я должен отметить, что разработчики Sinatra сохраняют приверженность сохранению двух разных стилей приложения.

Используете ли вы какой-либо код начальной загрузки?

В Rails есть много генераторов кода, которые быстро помогут вам начать работу с различным кодом начальной загрузки. Я задавался вопросом, использовали ли люди что-нибудь подобное для запуска своих проектов в Синатре.

Джеффри Грозенбах использовал немного кода начальной загрузки, чтобы сохранить настройку одних и тех же вещей снова и снова:

Иногда я начинаю с существующего простого репозитория Git, особенно если я собираюсь использовать Backbone или другие фреймворки, которые требуют некоторой настройки.

Другие предпочитали изначально включать такие вещи, как Knockout.js и Twitter Bootstrap (предположительно, чтобы облегчить разработку интерфейса).

Пользователь deminish упомянул инструмент генерации кода на странице групп Google Синатры, который находился в разработке и звучал интересно. Было бы хорошо видеть, был ли достигнут какой-либо прогресс в этом.

В моих собственных проектах на Sinatra я не склонен использовать какой-либо загрузочный код или код генератора, так как начать работу с проектом очень легко. Хотя я подумал о том, чтобы собрать минималистичную файловую структуру, которая включает в себя некоторые базовые CSS и макеты, которые я обычно использую.

Существует ряд похожих проектов, таких как Sinatra-Bootstrap-Starter , хотя они начинают отвлекать вас от некоторых дизайнерских решений — всегда лучше разрабатывать свои собственные, которые будут работать на вас!

Вы когда-нибудь использовали inline-представления?

Встроенные представления позволяют хранить весь код представления в том же файле, что и приложение. Вот быстрый пример:

 require 'sinatra' get '/hello/:name' do @name = params[:name] erb :hello end __END__ @@hello <h1>Hello!</h1> 

В этом примере представление с именем ‘hello’ помещается после объявления __END__ . Все представления помечаются, начиная с ‘@@’, после чего следует название шаблона.

Большинство людей не использовали их, хотя одним заметным исключением был Блейк Мизерани, который любил использовать их для небольших приложений:

Я буду использовать встроенные шаблоны, когда их всего несколько, и они маленькие

Лично мне часто нравится использовать встроенные представления, и я думаю, что они являются одной из самых крутых возможностей Синатры. Когда я играю с каким-то кодом или запускаю проект, мне очень нравится тот факт, что я могу создать что-то из одного файла. Фактически, Avdi Grimm удалось создать приложение Sinatra, в котором все было в одном файле, включая тесты! (Http://devver.wordpress.com/2009/05/13/single-file-sinatra-apps-with-specs-baked-in/)

Что-нибудь еще?

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

Джеффри Грозенбаху нравится, как Синатра показывает, как все работает лучше, и, следовательно, помогает вам овладеть этими навыками в большей степени:

Изучение и использование Синатры помогло мне лучше справиться с другими задачами (например, с настройкой тестов).

Он также думал, что дополнительные усилия окупились с более быстрым временем разработки:

Несмотря на то, что есть немного работы, мне нравится скорость работы с Синатрой.

Он также сказал:

Я редко использую генераторы Rails и часто использую базу данных NoSQL, поэтому Sinatra идеально подходит для большинства приложений, которые я хочу написать.

Рик Олсон (GitHub), любил использовать

Много усов и рэк-тест

Это отличается от того, что используют другие люди, но совершенно легко сделать с гибкостью Синатры.

Что касается высказывания некоторых людей о том, что Синатре не хватает функциональности, Джейсон Роджерс возражает:

Я бы сказал, что для этого нужны драгоценные камни. Одно из больших преимуществ Синатры — отсутствие мнений.

Он также отметил, что даже в этой небольшой выборке люди предпочитают использовать Синатру по-разному, а это означает, что не все могут быть удовлетворены подходом, который подходит всем. В этом заключается суть Sinatra — позволить вам выбрать свой собственный способ ведения дел, идеально подходящий для фанатов контроля, которым нравятся действия, совершенные определенным образом!

soldier.coder использовал отличную метафору для объяснения, почему вы можете захотеть использовать детальное решение выбора ваших драгоценных камней, предлагаемых Sinatra:

Почему бы просто не использовать рельсы? Rails — это как перевод эсминца в ситуацию с пиратами / заложниками, когда вам действительно нужна команда спецназа или печати. Большие приложения? Большие приложения вводят в заблуждение, поскольку это действительно зависит от того, как они организованы. Большой и монолитный сильно отличается от большого и модульного. Написание программного обеспечения как услуги поощряет разделение интересов. Синатра кажется идеальным для такого разделения.

Это хороший момент. Модульный стиль Синатры активно поощряет вас к написанию модульного кода, который можно объединить в больших приложениях. В этом есть ряд преимуществ: вы можете повторно использовать модули в других приложениях, вы можете удалить модуль, если он больше не требуется, разные команды могут работать независимо над отдельными модулями.

Блейк Мизерани также указал на преимущество небольшого предварительного планирования:

В общем, мне нравится тщательно продумывать то, что я делаю; Это позволяет мне быть проще.

С некоторым предварительным планированием вы можете настроить свой проект таким образом, чтобы его дизайн оставался простым, и Синатра позволит вам сделать это.

Я думаю, что все отзывы, которые я получил, помогают понять, почему Sinatra настолько гибок: если вы хотите быстро что-то запустить и запустить, вы можете сразу запустить классическое приложение со встроенными представлениями. Если вы хотите создать большое приложение, тогда вы можете использовать модульную структуру со своей собственной файловой структурой и отделить все свои проблемы.

Большинство из этих тем более подробно освещены в моей новой книге «Jump Start Sinatra».

Я надеюсь, что эта статья дала представление о множестве способов катания с Синатрой. А что насчет тебя? Если вы использовали Синатру, как вы катаетесь? Если вы еще не пробовали Sinatra, помог ли этот пост показать, на что способен Sinatra?

Не забудьте, Jump Start Sinatra скоро выйдет. Подпишитесь, чтобы получать уведомления, когда он будет готов!