<commit_before>* Черновик, попытка описания что есть capsule и как её использовать

** Первые шаги
   Для начала нужно получить себе версию capsule, проще всего просто воспользоваться git. Предполагается,
   что у вас есть какой-нибудь linux, где установлены или nodejs или gnome3.
   
   В общем клонируем:
   git clone https://github.com/ixdu/capsule

   Далее ради интереса заглядываем в папку examples и просто пошарившись там делаем какие-нибудь выводы о
   структуре проектов, которые используют capsule.
   Затем создаём свою папку, скажем tutproject, в корне capsule
   capsule/tutproject

   Затем было бы неплохо ещё раз залесть в examples и попытаться вникнуть в структуру того же player, ну
   да ладно.
   Любом проект использующий capsule состоит как минимум из 3х файлов:
   + config.json
     В нём указывается как минимум имя и местоположение первой функции, которая будут выполнена при запуске
     приложения. То есть в отличие от обычных js окружений нет какого-то главного файла, который выполняется
     типо как загружаемый html в браузер или файл, который вы указываете в качестве аргумента nodejs. 
     Здесь же чётко указывается какая функция в каком модуле выполняется при запуске.
     По умолчанию это capsulated.main. Это значит модуль capsulated, функция main.
     
     Далее можно указать дополнительные настройки, вроде
     + deploy_type - http|file. 
       + http означает приложение при разворачивании будет выставлено как web приложение
       с помощью web server. 
       + file же значит, что приложение будет упаковано в набор html и js файлов. 
       При этом сама настройка deploy_type специфична для web платформы на данный момент
     + deploy_url
       адрес, по которому будет выстановлено приложение, если был указан deploy_type как http

   + somefile.json
     любой файл, с расширением .json, только если это не config.json будет загружаться в алфавитной
     последовательности(типо как правла во всяких там init, udev и тд).
     Такие файлы имеют одинаковую структуру(тут самое время посмотреть её на примере 
     examples/player/04capsulated.json. Смысл этих файлов описать все файлы, которые используются в проекте
     и сформировать виртуальное дерево из этих файлов. То есть если у нас допустим есть модуль capsulated.js,
     то мы его можем с помощью способа формирования виртуального дерева представить его и как ./capsulated.js
     и как ./somefolder/lib/capsulated.js.
     На что это влияет? На использование этих модулей или ресурсов в проекте. То есть из примера выше мы бы
     подгружали уже в коде данный модуль либо как require('capsulated') либо как 
     require('somefolder/lib/capsulated').
     В виртуальное дерево упаковываются не только модули, но и другие ресурсы, например изображения.
     Затем в коде они подгружаются как модули:
     require('somefolder/someimage').
     О том как это просходит и благодаря чему, мы ещё поговорим. Пока лишь скажу, что все ресурсы подгружаются
     не низкоуровнево как мы привыкли(прочитал файл, распарсил его с помощью какой-либо либы, получил объект),
     а сразу как объекты. То есть подгружаемое таким образом изображение сразу можно добавить на канвас например
     или отправить куда-нибудь.

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

   Дальше копируем содержимое examples/skeleton к себе в папку проекта и получаем самый минимум того, с чем
   можно работать. Правда скорректиируем пути в 04capsulated.json, заменив examples/skeleton на наш tutproject.

   Затем переходим(для этого удобно хотя бы иметь ещё одну вкладку терминала) в 
   capsule/platforms/ваша платформа/deployer. Допустим у вас gnome3, тогда вы очутитесь здесь:
   capsule/platforms/gjs/deployer
   И собираем наш скетел:
   ./deployer gjs assemble tutproject
   И запускаем:
   ./deployer gjs run tutproject
   Если видим hello, значит всё прошло хорошо и мы готовы двигаться дальше.

** Разбираемся дальше, модули, ресурсы, как оформлять и кто на ком стоит. 
   А самое главное, зачем всё это?<commit_msg>добавлена вторая глава в tutor_ru<commit_after>* Черновик, попытка описания что есть capsule и как её использовать

** Первые шаги
   Для начала нужно получить себе версию capsule, проще всего просто воспользоваться git. Предполагается,
   что у вас есть какой-нибудь linux, где установлены или nodejs или gnome3.
   
   В общем клонируем:
   git clone https://github.com/ixdu/capsule

   Далее ради интереса заглядываем в папку examples и просто пошарившись там делаем какие-нибудь выводы о
   структуре проектов, которые используют capsule.
   Затем создаём свою папку, скажем tutproject, в корне capsule
   capsule/tutproject

   Затем было бы неплохо ещё раз залесть в examples и попытаться вникнуть в структуру того же player, ну
   да ладно.
   Любом проект использующий capsule состоит как минимум из 3х файлов:
   + config.json
     В нём указывается как минимум имя и местоположение первой функции, которая будут выполнена при запуске
     приложения. То есть в отличие от обычных js окружений нет какого-то главного файла, который выполняется
     типо как загружаемый html в браузер или файл, который вы указываете в качестве аргумента nodejs. 
     Здесь же чётко указывается какая функция в каком модуле выполняется при запуске.
     По умолчанию это capsulated.main. Это значит модуль capsulated, функция main.
     
     Далее можно указать дополнительные настройки, вроде
     + deploy_type - http|file. 
       + http означает приложение при разворачивании будет выставлено как web приложение
       с помощью web server. 
       + file же значит, что приложение будет упаковано в набор html и js файлов. 
       При этом сама настройка deploy_type специфична для web платформы на данный момент
     + deploy_url
       адрес, по которому будет выстановлено приложение, если был указан deploy_type как http

   + somefile.json
     любой файл, с расширением .json, только если это не config.json будет загружаться в алфавитной
     последовательности(типо как правла во всяких там init, udev и тд).
     Такие файлы имеют одинаковую структуру(тут самое время посмотреть её на примере 
     examples/player/04capsulated.json. Смысл этих файлов описать все файлы, которые используются в проекте
     и сформировать виртуальное дерево из этих файлов. То есть если у нас допустим есть модуль capsulated.js,
     то мы его можем с помощью способа формирования виртуального дерева представить его и как ./capsulated.js
     и как ./somefolder/lib/capsulated.js.
     На что это влияет? На использование этих модулей или ресурсов в проекте. То есть из примера выше мы бы
     подгружали уже в коде данный модуль либо как require('capsulated') либо как 
     require('somefolder/lib/capsulated').
     В виртуальное дерево упаковываются не только модули, но и другие ресурсы, например изображения.
     Затем в коде они подгружаются как модули:
     require('somefolder/someimage').
     О том как это просходит и благодаря чему, мы ещё поговорим. Пока лишь скажу, что все ресурсы подгружаются
     не низкоуровнево как мы привыкли(прочитал файл, распарсил его с помощью какой-либо либы, получил объект),
     а сразу как объекты. То есть подгружаемое таким образом изображение сразу можно добавить на канвас например
     или отправить куда-нибудь.

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

   Дальше копируем содержимое examples/skeleton к себе в папку проекта и получаем самый минимум того, с чем
   можно работать. Правда скорректиируем пути в 04capsulated.json, заменив examples/skeleton на наш tutproject.

   Затем переходим(для этого удобно хотя бы иметь ещё одну вкладку терминала) в 
   capsule/platforms/ваша платформа/deployer. Допустим у вас gnome3, тогда вы очутитесь здесь:
   capsule/platforms/gjs/deployer
   И собираем наш скетел:
   ./deployer gjs assemble tutproject
   И запускаем:
   ./deployer gjs run tutproject
   Если видим hello, значит всё прошло хорошо и мы готовы двигаться дальше.

** Разбираемся дальше, модули, ресурсы, как оформлять и кто на ком стоит, часть 1 
   Чтобы что-то написать, нужно хотя бы уметь использовать те возможности, которые предоставляет capsule.
   Эти возможности предоставляются с помощью модулей и встроенных типов. Эта же глава является введением в
   то, как использовать модули, ресурсы и чем они являются по своей сути.
   
   Итак, любой модуль это в любом случае .js файл. Да, могут быть исключения для различных платформ, где модули
   встроены, но это другой разговор. Подгружается модуль с помощью стандартного выражения  для commonjs 
   окружений: require(somepath)
   Все модули, даже стандартные, формируют единое виртуальное дерево модулей с помощью единого механизма,
   который является частью капсулизации(процесса сборки приложения и всех его зависимостей в пакет). Частью
   это процесса является конфиг сборки - файл с расширеним .json, подобно тому что был предыдущей главе под 
   именем somefile.json. Его более реальную версию можно глянуть в examples/player/04capsulated.json.
   О структуре этого файла подобробно будет описано в следующей главе, пока лишь важно понимать именно с 
   помощью таких файлов(явно или неявно) описывается из каких модулей и ресурсов будет состоять ваше 
   приложение. Это касается как написанных вами частей, так и встроенных модулей. При необходимости, в 
   готовое приложение можно будет собрать только те модули, которые вы используете.

   Ну если с модулями всем, кто писал на js всё более-менее понятно, то что есть ресурс? Ресурс в понимании
   capsule это некоторая порция данных, для которых есть встроенный тип. Например ресурсом может быть
   изображение. В таком случае вы добавляете это изображение в конфиг сборки, допустим таким образом:
   "images" : {
       "type" : "image",

       "blue" : "tutproject/images/blue.png"
   }

   В результате, blue.png упакуется в приложение вместе с основным кодом и будет доступно для использования
   внутри него с помощью:
   var blue = require('images/blue')

   Как это происходит, и что возвращает require? Как точно изображение упакуется в приложение зависит от
   платформы, скажем для web и для gjs(на данный момент) - изображение упаковывается в base64, а затем в 
   модуль. То есть данные изображения упаковываются в модуль, при подгрузки которого данные изображения 
   передаются реализации встроенного типа - в нашем случае это будет types/image. На выходе мы получаем
   объект types/image, который уже готов к применению в любом модуле capsule.
   Это значит, что можно сделать так:
   comp.frame_add(frame1, comp.image_create({source : blue}));

   и если frame1 это допустим область в середине экрана, то мы получим синию точку в этой области.
   
   Зачем такие сложности, если можно взять, прочитать файл, распарсить его с помощью нужного модуля и
   использовать? Ну потому что никаких файлов у капсулированного приложения нет, только виртуальное дерево.
   К тому же, так удобнее. То же comp.image_create это устаревший метод, который в будущем будет не нужен и
   c image сразу можно будет работать на канвасе. То есть ресурсы сокращают объём кода и делают работу с
   данными проще. Ко всему прочему разные платформы могут по разному работать с данными, и то что в конечном
   счёте называется типом может быть реализованно совсем по разному. В общем без типов, работа с данными
   была бы несколько разной для разных платформ, а это нам не нужно:)

** Встроенные модули

   Собственно это то, что вы скорее всего будете использовать очень часто чтобы ваше приложение хоть как-то
   взаимодействовало с внешним миром. 
   Единственно, что здесь нужно сказать заранее. capsule не пытается быть фреймворком, могущим всё
   (вроде той же java). В capsule есть только те модули, которые кому-нибудь понадобились(и были реализованны
   теми, кому они понадобились:)) Плюс к этому, все модули должны быть просты и эффективны(об этом как-нибудь
   позже) и их api _обязано_ быть кросплатформенно. Иными словами модуль, если он есть, должен быть способным
   к реализации на других платформах(то есть его api). Как правило, это значит что его авто хорошо знаком с
   как минимум 3мя платформами и точно знает, что api его модуля можно на этих платформах реализовать. И он
   принимает все усилия, чтобы api был максимально кросплатформенным.
   Что это значит на практике? Ну например вы можете столкнуться с тем, что привычные вам и доступные
   вещи в какой-нибудь java(скажем библиотека для доступа к nfc) могут здесь отсутствовать напрочь. Да что
   там nfc, в capsule сейчас проще сказать что есть(а это всего парочка api), чем перечислять чего нет.
   
   Ну а кому всё ещё интересно, продолжаем.
{'fraction_non_alphanumeric': 0.03719196836020688, 'fraction_numerical': 0.001673258290234256, 'mean_word_length': 3.7814545454545456, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3550491', 'n_tokens_mistral': 5007, 'n_tokens_neox': 5960, 'n_words': 1766}