Crystal Programming. Введение на основе проекта в создание эффективных, безопасных и читаемых веб-приложений и приложений CLI

Теперь, когда вы знакомы с основами Crystal, мы готовы применить эти навыки на практике. В этой части мы расскажем вам о создании интерфейса командной строки (CLI), в котором будут использованы концепции из Главы 1 "Введение в Crystal", а также некоторые новые.

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

Цель CLI – создать программу, позволяющую использовать данные YAML с jq, популярным CLI-приложением, которое позволяет разделять, фильтровать, отображать и преобразовывать структурированные данные JSON с помощью фильтра для описания этого процесса. Эта глава послужит отправной точкой нашего проекта, в которой будут рассмотрены следующие темы:

• Введение в проект

• Построение структуры проекта

• Написание базовой реализации

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

Технические требования

Для выполнения кода, описанного в этой главе, вам понадобится следующее программное обеспечение:

• Работающая установка Crystal

• Рабочая установка jq

Инструкции по получению Crystal можно найти в Главе 1 «Введение в Crystal». настраивать. jq, скорее всего, можно установить с помощью менеджера пакетов в вашей системе, но можно также можно установить вручную, загрузив его с https://stedolan.github.io/jq/download.

Все примеры кода, использованные в этой главе, можно найти в папке Chapter 4 на GitHub: https://github.com/PacktPublishing/Crystal-Programming/ tree/main/Chapter04.

Введение в проект

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

Фильтр состоит из строки различных символов и символов, некоторые из которых имеют особое значение. Самый простой фильтр —

.

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

• Индекс идентификатора объекта

• Индекс массива

• Запятая

• Pipe

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

null

.name

{"id":1,"name":"George"}

"George"

[1, 2, 3]

.[1]

2

Хотя первые два примера посвящены доступу к данным, фильтры «Запятая» и «Канал» предназначены для управления потоком данных через фильтр. Если несколько фильтров разделены запятой, входные данные передаются каждому фильтру независимо. Например, используя ранее полученный входной объект, фильтр

.id

.name

1

"George"

.id | . + 1

2

1

Доступ к определенным значениям из входных данных — это только половина дела, когда дело доходит до преобразования данных. jq предоставляет способ создания новых объектов/массивов с использованием синтаксиса JSON. Используя проверенный входной объект, который мы использовали, фильтр

{"new_id":(.id+2)}

{"new_id":3}

[]

[(.id), (.id*2), (.id)]

[1, 2, 1]

Давайте объединим все эти функции в более сложный пример, учитывая следующие входные данные:

[

 {

  "id": 1,

  "author": {

    "name": "Jim"

  }

 },

 {

  "id": 2,

  "author": {

    "name": "Bob"

  }

 }

]

Мы можем использовать фильтр

[.[] | {"id": (.id + 1), "name": .author.name}]

[.[] | {"id": (.id + 1), "name": .author.name}]' input.json

[

  {

    "id": 2,

    "name": "Jim"

  },

  {

    "id": 3,

    "name": "Bob"

  }

]

Если вы хотите узнать больше о возможностях jq, ознакомьтесь с его документацией по адресу https://stedolan.github.io/jq/manual, поскольку существует множество вариантов, методов и функций, выходящих за рамки этой книги.

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

Строительные леса проекта

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

crystal init

Начните с запуска

crystal init lib transform

Давайте подробнее рассмотрим, что представляют собой эти файлы/каталоги:

• .editorconfig — файл https://editorconfig.org, который позволяет некоторым IDE (если они настроены правильно) автоматически применять стиль кода Crystal к файлам *.cr.

• LICENSE — лицензия, которую использует проект. По умолчанию используется MIT, и нас это устраивает.

См. https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/licensing-a-repository для получения дополнительной информации.

• README.md — следует использовать для общей документации по приложению, такой как установка, использование и предоставление информации.

• shard.yml — содержит метаданные об этом осколке Crystal. Подробнее об этом в Главе 8 «Использование внешних библиотек».

• spec/ — папка, в которой хранятся все спецификации (тесты), относящиеся к приложению. Подробнее об этом в Главе 14 «Тестирование».

• src/ — папка, в которой находится исходный код приложения.

• src/transform.cr — основная точка входа в приложение.

Хотя эта структура проекта является хорошей отправной точкой, мы собираемся внести несколько изменений, создав еще один файл: src/transform_cli.cr. Также добавьте в файл shard.yml следующее:

targets:

  transform:

   main: src/transform_cli.cr

Это позволит нам запустить

run shards build

Разбивать код на несколько файлов — хорошая практика как по организационным причинам, так и для предоставления более специализированных точек входа в ваше приложение. Например, проект преобразования можно использовать как через командную строку, так и в другом приложении Crystal. По этой причине мы можем использовать src/transform.cr в качестве основной точки входа, тогда как src/transform_cli.cr требует src/transform.cr, но также включает некоторую логику, специфичную для CLI. Мы вернемся к этому файлу позже в этой главе.

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

Написание базовой реализации

module Transform

  VERSION = "0.1.0"

  # The same input data used in the example at the

 # beginning of the chapter.

  INPUT_DATA = %([{"id":1,"author":{"name":"Jim"}},{"id":2,

 "author":{"name":"Bob"}}])

  Process.run(

   "jq",

   [%([.[]	| {"id": (.id + 1), "name": .author.name}])],

   input: IO::Memory.new(INPUT_DATA),

   output: :inherit

  )

end

Process.run

:inherit

crystal src/transform.cr

require "yaml"

require "json"

module Transform::YAML

  def self.deserialize(input : String) : String

   ::YAML.parse(input).to_json

  end

  def self.serialize(input : String) : String

   JSON.parse(input).to_yaml

  end

end

require "./ yaml"

::YAML

::

.parse

#raise

require "./yaml"

  module Transform

   VERSION = "0.1.0"

   INPUT_DATA = <←YAML

   ---

   - id: 1

     author:

      name: Jim

   - id: 2

   author:

     name: Bob

   YAML

  output_data = String.build do |str|

   Process.run(

     "jq",

     [%([.[]	| {"id": (.id + 1), "name": .author.name}])],

     input: IO::Memory.new(

      Transform::YAML.deserialize(INPUT_DATA)

     ),

     output: str

   )

   end

  puts Transform::YAML.serialize(output_data)

end

String.build

transform

class Transform::Processor

 def process(input : String) : String

  output_data = String.build do |str|

   Process.run(

    "jq",

    [%([.[] | {"id": (.id + 1), "name": .author.name}])],

    input: IO::Memory.new(

     Transform::YAML.deserialize input

    ),

    output: str

   )

  end

  Transform::YAML.serialize output_data

 end

end

Transform::Processor

#process

require "./transform"

 INPUT_DATA = <←YAML

 ---

  - id: 1

   author:

    name: Jim

  - id: 2

   author:

    name: Bob

 YAML

puts Transform::Processor.new.process INPUT_DATA

require "./processor"

require "./yaml"

module Transform

  VERSION = "0.1.0"

end

Array(String)

class Transform::Processor

 def process(input : String) : String

  output_data = String.build do |str|

   Process.run("jq",

    ARGV,

    input: IO::Memory.new(Transform::YAML.deserialize

     input

    ),

    output: str

   )

  end

  Transform::YAML.serialize output_data

 end

end

crystal src/transform_cli.cr '[.[] | {"id": (.id + 1), "name": .author.name}]'

crystal run src/transform_cli.cr -- '[.[] | {"id": (.id + 1), "name": .author.name }]'

--

OptionParser

В этой главе будет подробно рассмотрено CLI-приложение, о котором говорилось в предыдущей главе, с акцентом на операции ввода/вывода (IO). В ней будут рассмотрены следующие темы:

• Поддержка терминального ввода-вывода, такого как STDIN/STDOUT/STDERR

• Поддержка дополнительного ввода-вывода

• Тестирование производительности

• Объяснение поведения ввода-вывода

К концу этой главы у вас должно быть общее представление об операциях ввода-вывода, в том числе о том, как их использовать и как они себя ведут. С помощью этих концепций вы сможете создавать интерактивные, эффективные потоковые алгоритмы, которые могут быть использованы в различных приложениях. Знание того, как работает IO, также поможет вам понять более сложные концепции, которые будут рассмотрены в следующих главах, таких как Глава 6 "Параллелизм".

Технические требования

Для выполнения кода, описанного в этой главе, вам потребуется следующее программное обеспечение:

• Рабочая установка Crystal

• Рабочая установка jq

• Средство измерения использования памяти, например https://man7.org/linux/man-pages/man1/time.1.html с параметром

-v

Инструкции по настройке Crystal приведены в Главе 1 "Введение в Crystal". Скорее всего, jq можно установить с помощью менеджера пакетов в вашей системе, но его также можно установить вручную, загрузив с сайта https://stedolan.github.io/jq/download.

Все примеры кода, использованные в этой главе, можно найти в папке Chapter 5 на GitHub: https://github.com/PacktPublishing/Crystal-Programming/tree/main/Chapter05.

Поддерживающий терминальный ввод/вывод

В предыдущей главе мы остановились на нашем типе процессора, имеющем метод

def process(input : String) : String

Более правильный способ справиться с этим - использовать терминальный ввод-вывод, а именно

Standard In(STDIN)

Standard Out (STDOUT)

Standard Error (STDERR)

puts

puts

puts

puts "Hello!"     # => Hello!

STDOUT.puts "Hello!" # => Hello!

Но подождите, что такое IO? Технически в Crystal IO — это все, что наследуется от абстрактного типа

IO

Однако на практике ввод/вывод обычно представляет собой что-то, что может записывать и/или считывать данные, например файлы или тела HTTP-запроса/ответа. IO также обычно реализуется таким образом, что не все читаемые/записываемые данные должны находиться в памяти одновременно, чтобы поддерживать «потоковую передачу» данных. Пользовательский IO также может быть определен для более специализированных случаев использования.

В нашем контексте типы

STDIN

STDOUT

STDERR

IO::FileDescriptor.

Crystal предоставляет некоторые полезные типы

IO

IO::Memory

String.build

IO::Memory

String.build

IO::Memory

io = IO::Memory.new

io << "Hello"

io << " " << "World!"

puts io # => Hello World!

string = String.build do |io|

  io << "Goodbye"

  io << " " << "World"

end

puts string # => Goodbye World!

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

IO::Buffered

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

• Delimited — IO, который оборачивает другой IO, считывая только до начала указанный разделитель. Может быть полезно для экспорта только части потока клиенту.

• Hexdump — IO, который печатает шестнадцатеричный дамп всех переданных данных. Может быть полезно для отладки двоичных протоколов, чтобы лучше понять, когда и как данные отправляются/получаются.

• Sized — IO, который оборачивает другой ввод-вывод, устанавливая ограничение на количество байтов, которые можно прочитать.

Полный список см. в документации API: https://crystal-lang.org/api/IO.html.

Теперь, когда мы познакомились с IO, давайте вернемся к обновлению нашего CLI, чтобы лучше использовать ввод-вывод на основе терминала. Планируется обновить src/transform_cli.cr для чтения непосредственно из

STDIN

STDOUT

INPUT_DATA

require "./transform"

STDOUT.puts Transform::Processor.new.process STDIN.gets_to_end

Главное, что изменилось, это то, что мы заменили константу

INPUT_DATA

STDIN

get_to_end

STDIN

#process

puts

STDOUT.puts

Остальная логика внутри нашего типа процессора остается прежней, включая

String.build

Мы можем убедиться, что наше изменение работает, запустив

echo $'---\n- id: 1\n author:\n name: Jim\n- id: 2\n author:\n name: Bob\n' | crystal src/transform_cli.cr '[.[] | {"id": (.id + 1), "name": .author.name}]',

---

- id: 2

  name: Jim

- id: 3

  name: Bob

Хотя сейчас мы читаем входные данные из STDIN, было бы также хорошим улучшением, если бы мы разрешили передачу входного файла для чтения входных данных. Crystal определяет константу ARGF, которая позволяет считывать данные из файла и возвращаться к STDIN, если файлы не предоставлены. ARGF также является вводом-выводом, поэтому мы можем просто заменить STDIN на ARGF в src/transform_cli.cr. Мы можем проверить это изменение, записав выходные данные последнего вызова в файл, скажем, input.yaml. Затем запустите приложение, передав файл в качестве второго аргумента после фильтра. Полная команда будет выглядеть так:

crystal src/transform_cli.cr. input.yaml

Необработанное исключение: Ошибка чтения файла: Является каталогом (IO::Error)

ARGF сначала проверит, пуст ли ARGV. Если да, то будет выполнено чтение из STDIN. Если ARGV не пуст, предполагается, что каждое значение в ARGV представляет файл для чтения. В нашем случае ARGV не пуст, поскольку содержит

[.", "input.yaml"]

ARGF#gets_to_end

#shift

Однако есть еще одна проблема, которую нам также необходимо решить. Поскольку мы используем ARGV напрямую для предоставления входных аргументов jq, нам нужно будет провести некоторый рефакторинг, чтобы иметь возможность получить доступ к фильтру перед вызовом

#gets_to_end

class Transform::Processor

 def process : Nil

  filter = ARGV.shift

  input = ARGF.gets_to_end

  output_data = String.build do |str|

   Process.run(

    "jq",

    [filter],

    input: IO::Memory.new(

    Transform::YAML.deserialize input

    ),

    output: str

   )

  end

   STDOUT.puts Transform::YAML.serialize output_data

 end

end

Ключевым дополнением здесь является введение

filter = ARGV.shift

Также обратите внимание, что мы удалили входной аргумент из метода

#process

Nil

Есть еще одна вещь, которую нам нужно обработать, прежде чем мы сможем объявить рефакторинг завершенным: что произойдет, если в jq будет передан недопустимый фильтр (или данные)? В настоящее время это вызовет не очень дружелюбное исключение. Что нам действительно нужно сделать, так это проверить, успешно ли выполнен jq, и если нет, записать сообщение об ошибке в STDERR и выйти из приложения, внеся следующие изменения в src/processor.cr:

class Transform::Processor

 def process : Nil

  filter = ARGV.shift

  input = ARGF.gets_to_end

  output_data = String.build do |str|

   run = Process.run(

    "jq",

    [filter],

    input: IO::Memory.new(

     Transform::YAML.deserialize input

    ),

    output: str,

    error: STDERR

   )

  exit 1 unless run.success?

  end

  STDOUT.puts Transform::YAML.serialize output_data

 end

end

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

STDERR

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

Поддержка других IO

В последнем разделе мы уже внесли немало улучшений: нам больше не нужно жестко кодировать входные данные, и мы лучше справляемся с ошибками, исходящими от jq. Но помните, как мы также хотели поддержать использование нашего приложения в контексте библиотеки? Как кто-то будет обрабатывать тело ответа HTTP и выводить его в файл, если наш процессор тесно связан с концепцией терминала?

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

Первым шагом в этом является повторное введение аргументов в

Processor#process

class Transform::Processor

 def process(input_args : Array(String), input : IO,

  output : IO, error : IO) : Nil

  filter = input_args.shift

  input = input.gets_to_end

  output_data = String.build do |str|

   run = Process.run(

    "jq",

    [filter],

    input: IO::Memory.new(

     Transform::YAML.deserialize input

    ),

    output: str,

    error: error

   )

   exit 1 unless run.success?

  End

  output.puts Transform::YAML.serialize output_data

 end

end

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

STDOUT

String.build

Откройте src/yaml.cr и обновите первый аргумент, чтобы он принимал IO, а также добавьте еще один аргумент IO, который будет представлять выходные данные. Оба метода

.parse

String | IO

#to_*

Nil

require "yaml"

require "json"

module Transform::YAML

 def self.deserialize(input : IO, output : IO) : Nil

  ::YAML.parse(input).to_json output

 end

 def self.serialize(input : IO, output : IO) : Nil

  JSON.parse(input).to_yaml output

 end

end

Поскольку мы добавили второй аргумент, нам, конечно, также потребуется обновить процессор для передачи второго аргумента. Аналогичным образом, поскольку сейчас мы работаем исключительно с операциями IO, нам нужно будет реализовать новый способ хранения/перемещения данных. Мы можем решить обе эти задачи, используя объекты

IO::Memory

Конечный результат этого рефакторинга следующий:

class Transform::Processor

 def process(input_args : Array(String), input : IO,

  output : IO, error : IO) : Nil

  filter = input_args.shift

  input_buffer = IO::Memory.new

  output_buffer = IO::Memory.new

  Transform::YAML.deserialize input, input_buffer

  input_buffer.rewind

  run = Process.run(

   "jq",

   [filter],

   input: input_buffer,

   output: output_buffer,

   error: error

  )

  exit 1 unless run.success?

  output_buffer.rewind

  Transform::YAML.serialize output_buffer, output

 end

end

Мы все еще смещаем фильтр с входных аргументов. Однако вместо использования

#gets_to_end

IO::Memory

По сути, это работает так: процесс десериализации будет использовать все данные входного типа IO, выводя преобразованные данные в первый

IO::Memory

IO::Memory

serialize

Еще один ключевой момент, на который стоит обратить внимание, — это то, как нам нужно вызывать

.rewind

IO::Memory

Другой способ подумать об этом — представить, что вы пишете эссе. Чем длиннее и длиннее эссе, тем дальше и дальше вы отходите от начала. Вызов

.rewind

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

exit 1

raise RuntimeError.new

run.success?

require "./transform"

begin

 Transform::Processor.new.process ARGV, STDIN, STDOUT, STDERR rescue ex : RuntimeError

 exit 1

end

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

Во-первых, пользователям нашей библиотеки необходимо будет установить наш проект как сегмент — подробнее об этом в Главе 8 «Использование внешних библиотек». Тогда они могли бы потребовать, чтобы наш src/transform.cr имел доступ к нашему процессору и логике преобразования. Это было бы намного сложнее, если бы мы не использовали отдельную точку входа для контекста CLI. Отсюда они могли создать тип

Processor

require "http/client"

require "transform"

private FILTER = %({"name": .info.title, "swagger_version": .swagger, "endpoints": .paths | keys})

HTTP::Client.get "https://petstore.swagger.io/v2/swagger.yaml" do

  |response|

 File.open("./out.yml", "wb") do |file|

  Transform::Processor.new.process [FILTER], response.body_io, file

 end

end

В результате файл будет следующим:

---

name: Swagger Petstore swagger_version: "2.0" endpoints:

- /pet

- /pet/findByStatus

- /pet/findByTags

- /pet/{petId}

- /pet/{petId}/uploadImage

- /store/inventory

- /store/order

- /store/order/{orderId}

- /user

- /user/createWithArray

- /user/createWithList

- /user/login

- /user/logout

- /user/{username}

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

Теперь, когда и наш процессор, и типы преобразования используют IO, мы можем сделать еще одну оптимизацию. Текущая логика преобразования использует метод класса

.parse

К счастью для нас, JSON и, как следствие, YAML являются форматами потоковой сериализации. Другими словами, вы можете переводить один формат в другой по одному символу за раз, не загружая все данные заранее. Как упоминалось ранее, это одно из основных преимуществ создания нашего приложения на основе IO. Мы можем использовать это, обновив нашу логику преобразования для вывода преобразованных выходных данных, одновременно анализируя входные данные. Начнем с метода

.deserialize

Здесь много всего происходит, поэтому давайте немного разберем алгоритм:

1. Мы начинаем использовать некоторые новые типы в модуле каждого формата вместо того, чтобы оба они полагались на метод

.parse

•

YAML::PullParser

•

JSON::Builder

2. Мы используем эти два объекта совместно для одновременного анализа YAML и вывода JSON. По сути, алгоритм начинает чтение потока данных YAML, запуская цикл, который будет продолжаться до конца документа YAML, переводя соответствующий токен YAML в его аналог JSON.

Метод

.serialize

Однако в этом случае алгоритм существенно обратный. Мы используем анализатор JSON и построитель YAML. Давайте проведем тест и посмотрим, насколько это помогло.

Тестирование производительности

Для тестирования я буду использовать реализацию GNU утилиты

time

-v

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

2. Соберите двоичный файл в режиме выпуска с помощью shards build

--release

3. Запустите тест через /

usr/bin/time -v ./bin/transform . invItems.yaml > /dev/null

/dev/null

Затем восстановите новый код и снова выполните предыдущие шаги, чтобы увидеть, приведут ли наши изменения к улучшению использования памяти. На этот раз у меня получилось 325 352, что более чем в 4 раза меньше, чем раньше!

До сих пор во входном IO находились данные для обработки либо из входного файла, либо из STDIN. Однако что произойдет, если наше приложение ожидает входные данные, но данных для обработки нет? В следующем разделе мы собираемся изучить, как ведет себя ввод-вывод в этом сценарии.

Объяснение поведения IO

Если вы создадите и запустите приложение как

./bin/transform .

STDIN

print "What is your name? "

if (name = gets).presence

  puts "Your name is: '#{name}'"

else

  puts "No name supplied"

end

Метод

get

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

• Использование волокон для одновременного выполнения работы

• Использование каналов для безопасной передачи данных

• Одновременное преобразование нескольких файлов

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

Технические требования

Прежде чем мы углубимся в эту главу, в вашей системе должно быть установлено следующее:

• Рабочая установка Crystal

• Рабочая установка jq

Инструкции по настройке Crystal можно найти в Главе 1 «Введение в Crystal». Обратите внимание, что jq, скорее всего, можно установить с помощью менеджера пакетов в вашей системе. Однако вы также можете установить его вручную, загрузив с https://stedolan.github.io/jq/download.

Все примеры кода, использованные в этой главе, можно найти в папке Chapter 6 на GitHub по адресу https://github.com/PacktPublishing/Crystal-Programming/tree/main/Chapter06.

Использование волокон (fibers ) для одновременного выполнения работы

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

В параллельном коде на различные фрагменты работы тратится немного времени, при этом в определенный момент времени выполняется только часть работы. С другой стороны, параллельный код позволяет одновременно выполнять несколько фрагментов работы. На практике это означает, что по умолчанию одновременно выполняется только одно волокно. В Crystal есть поддержка параллелизма, который позволяет одновременно выполнять более одного волокна, но он все еще считается экспериментальным. По этой причине мы собираемся сосредоточиться на параллелизме.

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

puts "Hello program!"

spawn do

  puts "Hello from fiber!"

end

puts "Goodbye program!"

Если бы вы запустили это приложение, оно выдало бы следующее:

Hello program!

Goodbye program!

Но подождите! Что случилось с сообщением в fiber, которое мы создали? Ответ можно найти в начале главы, в разделе "Определение fiber". Ключевые слова появятся в какой-то момент в будущем. Создание fiber не приводит к немедленному выполнению fiber. Вместо этого он запланирован для выполнения планировщиком Crytal. Планировщик выполнит следующий поставленный в очередь fiber при первой возможности. В этом примере такой возможности никогда не возникает, поэтому fiber никогда не выполняется.

Это важная деталь для понимания того, как работает параллелизм в Crystal, а также того, почему природа IO, рассмотренная в Главе 5 "Операции ввода/вывода", может быть настолько полезной. К числу факторов, которые могут привести к выполнению другого fiber, относятся следующие:

• Метод

sleep

•

Fiber.yield

• Операции, связанные с IO, такие как чтение/запись в файл или сокет

• Ожидание получения значения из канала

• Ожидание отправки значения в канал

• Когда текущее волокно завершит выполнение

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

sleep 1

Hello from fiber!

sleep

Метод

Fiber.yield

sleep 0

sleep

Fiber.yield

sleep 0

Fiber.yield

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

sleep

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

idx = 0

while idx < 4

  spawn do

    puts idx

  end

  idx += 1

end

Fiber.yield

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

• Волокна не выполняются немедленно.

• Каждое волокно ссылается на одну и ту же переменную.

Поскольку волокна не выполняются немедленно, они создаются при каждой итерации цикла

while loop

idx

while loop

4

spawn

idx = 0

while idx < 4

  spawn puts idx

  idx += 1

end

Fiber.yield

Это внутренне обрабатывает создание и выполнение

Proc

4.times { |idx| spawn { puts idx } }

Использование каналов для безопасной передачи данных

Если совместное использование переменных между волокнами не является правильным способом взаимодействия между волокнами, то что? Ответ – каналы. Канал — это способ связи между волокнами без необходимости беспокоиться об условиях гонки, блокировках, семафорах или других специальных структурах. Давайте посмотрим на следующий пример:

input_channel = Channel(Int32).new

output_channel = Channel(Int32).new

spawn do

  output_channel.send input_channel.receive * 2

end

input_channel.send 2

puts output_channel.receive

В предыдущем примере создаются два канала, содержащие входные и выходные значения

Int32

2

4

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

channel = Channel(Int32).new

spawn do

 loop do

  puts "Waiting"

  sleep 0.5

 end

end

spawn do

 sleep 2

 channel.send channel.receive * 2

 sleep 1

 channel.send channel.receive * 3

 end

channel.send 2

puts channel.receive

channel.send 3

puts channel.receive

Запуск программы приводит к следующему выводу:

Waiting

Waiting

Waiting

Waiting

4

Waiting

Waiting

9

Первые результаты отправки и получения во втором волокне выполняются первыми. Однако первая строка — это

sleep 2

Waiting

4

sleep 1

9

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

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

channel = Channel(Int32).new 2

spawn do

 puts "Before send 1"

 channel.send 1

 puts "Before send 2"

 channel.send 2

 puts "Before send 3"

 channel.send 3

 puts "After send"

end

3.times do

 puts channel.receive

end

Это выведет следующее:

Before send 1

Before send 2

Before send 3

After send

1

2

3

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

Before send 1

Before send 2

1

2

Before send 3

After send

3

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

В случае с буферизацией первое отправленное значение выполняет команду

channel.receive

puts “Before send 4”

channel.send 4

4.times do

Before send 1

Before send 2

Before send 3

Before send 4

1

2

3

4

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

channel.recieve

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

select

#select

select

channel1 = Channel(Int32).new

channel2 = Channel(Int32).new

spawn do

  puts "Starting fiber 1"

  sleep 3

  channel1.send 1

end

spawn do

  puts "Starting fiber 2"

  sleep 1

  channel2.send 2

end

select

when v = channel1.receive

  puts "Received #{v} from channel1"

when v = channel2.receive

  puts "Received #{v} from channel2"

end

Этот пример выводит следующее:

Starting fiber 1

Starting fiber 2

Received 2 from channel2

Здесь оба волокна начинают выполняться более или менее одновременно, но поскольку у второго волокна более короткий период сна и он завершается первым, это приводит к тому, что ключевое слово

select

select

channel.receive

select

timeout

channel3

spawn do

  puts "Starting fiber 3"

  channel3.send 3

end

Наконец, мы можем переместить наше ключевое слово

select

loop do

 select

 when v = channel1.receive

  puts "Received #{v} from channel1"

 when v = channel2.receive

  puts "Received #{v} from channel2"

 when v = channel3.receive

  puts "Received #{v} from channel3"

 when timeout 3.seconds

  puts "Nothing left to process, breaking out"

  break

 end

end

Эта версия ключевого слова

select

Starting fiber 1

Starting fiber 2

Starting fiber 3

Received 3 from channel3

Received 2 from channel2

Received 1 from channel1

Nothing left to process, breaking out

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

if

Ключевое слово

select

spawn_receiver = true

channel = Channel(Int32).new

if spawn_receiver

 spawn do

  puts "Received: #{channel.receive}"

 end

end

 spawn do

 select

 when channel.send 10

  puts "sent value"

 else

  puts "skipped sending value"

 end

end

Fiber.yield

Запуск этого как есть дает следующий результат:

sent value

Received: 10

Установка флага

spawn_receiver

false

send

else

select

select

if

else

Хотя использование каналов и волокон для сигнализации о завершении единицы работы является одним из вариантов их использования, это не единственный вариант использования. Эти две концепции, а также

select

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

Преобразование нескольких файлов одновременно

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

Причина, по которой логика, связанная с IO, и параллелизм так хорошо сочетаются друг с другом, заключается в планировщике Crystal. Когда волокно достигает точки своего выполнения, когда оно зависит от некоторой части данных из IO, планировщик может легко отложить это волокно в сторону до тех пор, пока не поступят эти данные.

Более конкретным примером этого в действии было бы рассмотрение того, как функционирует стандартная библиотека

HTTP::Server

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

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

Прежде чем мы перейдем непосредственно к делу, давайте потратим немного времени на то, чтобы спланировать, что нам нужно сделать, чтобы поддержать это:

• Найдите способ сообщить CLI, что он должен обрабатывать файлы в режиме нескольких файлов.

• Определить новый метод, который будет обрабатывать каждый файл из ARGV.

Первое требование можно удовлетворить, поддерживая опцию CLI

--multi

Processor

Processor

def process_multiple(filter : String, input_files :

 Array(String), error : IO) : Nil

  input_files.each do |file|

   File.open(file, "r") do |input_file|

    File.open("#{input_file.path}.transformed", "w") do

     |output_file|

     self.process [filter], input_file, output_file, error

    end

   end

  end

 end

Этот метод сводится к следующим шагам:

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

2. Переберите каждый входной файл, используя метод

File.open

3. Снова используйте

File.open

.transformed

4. Вызовите метод одиночного ввода, передав наш фильтр в качестве единственного аргумента и используя открытые файлы в качестве входных и выходных операций IO.

Прежде чем мы сможем это протестировать, нам нужно сделать так, чтобы передача опции

--multi

require "./transform"

require "option_parser"

processor = Transform::Processor.new

multi_file_mode = false

OptionParser.parse do |parser|

 parser.banner = "Usage: transform  [options]

  [arguments] [filename …]"

 parser.on("-m", "--multi", "Enables multiple file input mode") { multi_file_mode = true }

 parser.on("-h", "--help", "Show this help") do

  puts parser

  exit

 end

end

begin

 if multi_file_mode

  processor.process_multiple ARGV.shift, ARGV, STDERR

 else

  processor.process ARGV, STDIN, STDOUT, STDERR

 end

rescue ex : RuntimeError

 exit 1

end

И снова на помощь приходит стандартная библиотека Crystal в виде типа

OptionParser

-h

--help

--multi

multi_file_mode

true

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

./bin/transform --multi. file1.yml file2.yml file3.yml

process_multiple

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

def process_multiple(filter : String, input_files :

 Array(String), error : IO) : Nil

 channel = Channel(Bool).new

 input_files.each do |file|

  spawn do

   File.open(file, "r") do |input_file|

    File.open("#{input_file.path}.transformed", "w")

     do |output_file|

     self.process [filter], input_file, output_file, error

    end

   end

  ensure

   channel.send true

  end

 end

 input_files.size.times do

  channel.receive

 end

end

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

true

send

ensure

Я бы в любой день взял прирост производительности в 2-3 раза.

Резюме

И вот оно: одновременная обработка нескольких входных файлов! Параллельное программирование может быть ценным инструментом для создания высокопроизводительных приложений, позволяя разбивать рабочие нагрузки, связанные с IO, так, чтобы некоторая часть работы выполнялась постоянно. Кроме того, его можно использовать для уменьшения объема памяти приложения за счет одновременной обработки входных данных по мере их поступления, без необходимости ждать и загружать все данные в память.

На данный момент наш CLI почти готов! Теперь он может эффективно обрабатывать как одиночные, так и множественные входные файлы. Он может передавать данные в потоковом режиме, чтобы уменьшить использование памяти, и настроен для простой поддержки использования библиотек. Далее мы собираемся сделать что-то немного другое: мы собираемся поддерживать отправку уведомлений на рабочем столе о различных событиях в нашем CLI. Для этого в следующей главе мы узнаем о способности Crystal связываться с библиотеками C.

В этой главе основное внимание будет уделено одной из наиболее продвинутых функций Crystal: возможности взаимодействия с существующими библиотеками C путем написания привязок C. Эта функция Crystal позволяет повторно использовать высокооптимизированный и/или надежный код внутри Crystal, не написав ни строчки C и не беря на себя нетривиальную задачу по переносу всего этого в Crystal. Мы рассмотрим следующие темы:

• Знакомство с привязками C.

• Привязка libnotify

• Интеграция привязок

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

К концу этой главы вы сможете писать привязки C для существующих библиотек и понимать, как лучше всего скрыть детали реализации привязок от конечного пользователя. Привязки C позволяют коду Crystal использовать высокооптимизированный код C или просто разрешать повторное использование кода без необходимости предварительного переноса всей библиотеки в Crystal.

Технические требования

Требования к этой главе следующие:

• Рабочая установка Кристалла.

• Рабочая установка jq.

• Рабочая установка libnotify.

• Рабочий компилятор C, например GCC.

Инструкции по настройке Crystal можно найти в Главе 1 «Введение в Crystal». Последние версии jq, libnotify и GCC, скорее всего, можно установить с помощью менеджера пакетов в вашей системе, но их также можно установить вручную, загрузив их с https://stedolan.github.io/jq/download, https://gitlab. gnome.org/GNOME/libnotify и https://gcc.gnu.org/releases.html соответственно. Если вы работаете с этой главой в ОС, отличной от Linux, например, macOS или Windows/WSL, то все может работать не так, как ожидалось, если вообще работать.

Все примеры кода, использованные в этой главе, можно найти в папке главы 7 на GitHub: https://github.com/PacktPublishing/Crystal-Programming/tree/main/Chapter07.

Вводим привязки на языке C

#include 

void sayHello(const char *name)

{

  printf("Hello %s!\n", name);

}

char

@[Link(ldflags: "#{	DIR	}/hello.o")]

lib LibHello

  fun say_hello = sayHello(name : LibC::Char*) : Void

end

LibHello.say_hello "Bob"

@[Link]

lib

Nil

Void

Void

fun ceil_f32 = "llvm.ceil.f32"(value: Float32) : Float32

LibC::Char

“Bob”

Int32

Int64

LibC::Long

String

#to_unsafe

gcc -Wall -O3 -march=native -c hello.c -o hello.o

Hello Bob!

libnotify

lib

#include 

struct TimeZone {

 int minutes_west;

 int dst_time;

};

void print_tz(struct TimeZone *tz)

{

 printf("DST time is: %d\n", tz->dst_time);

}

TimeZone

@[Link(ldflags: "#{__DIR__}/struct.o")]

lib LibStruct

 struct TimeZone

  minutes_west : Int32

  dst time : Int32

 end

 fun print_tz(tz : TimeZone*) : Void

end

tz = LibStruct::TimeZone.new

tz.minutes_west = 1

tz.dst_time = 14

LibStruct.print_tz pointerof(tz)

.new

#to_unsafe

Время летнего времени: 14.

#include 

#include 

void number_callback(void (*callback)(int))

{

 srand(time(0));

 return (*callback)(rand());

}

@[Link(ldflags: "#{__DIR__}/callback.o")]

lib LibCallback

 fun number_callback(callback : LibC::Int -> Void) : Void

 end

LibCallback.number_callback ->(value) { puts "Generated: #{value}" }

Proc(LibC::Int, Nil)

callback = ->(value : LibC::Int) { ... }

gcc -Wall -O3 -march=native -c callback.c -o callback.o

Procs

Proc

multiplier = 5

LibCallback.number_callback ->(value : LibC::Int) { puts

value * multiplier }

Ошибка: невозможно отправить замыкание в функцию C (замыкающие переменные: множитель)

notify_init

notify_uninit

notify_notification_new

notify_notification_show

NotifyNotification

*.h

@[Link("libnotify")]

lib LibNotify

 alias GInt = LibC::Int

 alias GBool = GInt

 alias GChar = LibC::Char

 type NotifyNotification = Void*

 fun notify_init(app_name : LibC::Char*) : GBool

 fun notify_uninit : Void

 fun notify_notification_new(summary : GChar*, body :

  GChar*, icon : GChar*) : NotifyNotification*

 fun notify_notification_show(notification :

  NotifyNotification*, error : Void**) : GBool

 fun notify_notification_update(notification :

  NotifyNotification*, summary : GChar*, body : Gchar*, icon : GChar*) : GBool

end

Link

--verbose

build --verbose src/transform_cli.cr

-o

pkg-config --libs libnotify

-lnotify -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0

-llibnotify

@[Link(ldflags: "...")]

GInt

NotifyNotification

notify_notification_show

Void

notify_notification_update

lib_notify

“./lib_notify”

LibNotify.notify_init "Transform"

notification = LibNotify.notify_notification_new "Hello",

"From Crystal!", nil

LibNotify.notify_notification_show notification, nil LibNotify.notify_uninit

nil

Pointer

Nil

init

uninit

require "./lib_notify"

class Transform::Notification

 @notification : LibNotify::NotifyNotification*

 getter summary : String

 getter body : String

 getter icon : String

 def initialize(@summary : String, @body : String, @icon : String = "")

  @notification = LibNotify.notify_notification_new @summary, @body, @icon

 end

 def summary=(@summary : String) : Nil

  self.update

 end

 def body=(@body : String) : Nil

  self.update

 end

 def icon=(@icon : String?) : Nil

  self.update

 end

 def to_unsafe : LibNotify::NotifyNotification* @notification

 end

 private def update : Nil

  LibNotify.notify_notification_update @notification, @summary, @body, @icon

 end

end

#to_unsafe

notify_notification_update

require "./lib_notify"

require "./notification"

class Transform:	:NotificationEmitter

 @@initialized : Bool = false

 at_exit { LibNotify.notify_uninit if @@initialized }

 def emit(summary : String, body : String) : Nil

  self.emit Transform::Notification.new summary, body

 end

 def emit(notification : Transform::Notification) : Nil

  self.init

  LibNotify.notify_notification_show notification, nil

 end

 private def init : Nil

  return if @@initialized

  LibNotify.notify_init "Transform"

  @@initialized = true

 end

end

#emit

NotificationEmitter

at_exit

Интеграция привязок

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

Теперь вы, возможно, думаете, что мы просто создаем новые экземпляры

NotificationEmitter

def initialize(@emitter : Transform::NotificationEmitter = Transform::NotificationEmitter.new); end

Давайте сначала сосредоточимся на обработке контекста ошибки. К сожалению, поскольку jq будет выводить сообщения об ошибках непосредственно на IO, ошибок, мы не сможем их обработать. Однако мы можем обрабатывать реальные исключения из нашего кода Crystal. Поскольку мы хотим обрабатывать любые исключения, возникающие в нашем методе

#process

rescue

rescue ex : Exception

 if message = ex.message

  @emitter.emit "Oh no!", message

 end

 raise ex

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

В случае с методом

#process_multiple

К сожалению, на данный момент работа с каналами и волокнами находится на несколько более низком уровне, чем хотелось бы в идеале. Есть несколько выдающихся предложений, например https://github. com/crystal-lang/crystal/issues/6468, но в стандартной библиотеке еще не реализовано ничего, что позволяло бы использовать некоторые встроенные абстракции или API более высокого уровня. С другой стороны, проблема, которую мы хотим решить, довольно тривиальна.

В последней главе мы добавили отправку с использованием блока

ensure

Bool | Exception

Bool

rescue

ensure

channel.send true

rescue ex : Exception

channel.send ex

Подобно другим блокам восстановления, этот также будет идти сразу после

channel.send true

spawn

Exception

input_args.size.times do

case v = channel.receive

 in Exception then raise v

 in Bool

  # Skip

 end

end

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

#process_ multiple

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

./bin/transform -m .random-file.txt

Резюме

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

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