improve README

README.md

@@ -1,101 +1,124 @@
 # projectlinter cli app layout
 
-Це шаблон(приклад) того як може виглядати ваш projectlinter
+This is a layout of cool cli program "projectlinter"
 
-Код розглядається виходячи з таких вводних даних:
+What does it do? - it is a solution for big companies with a huge code base. Now I`m talking about a hundred or thousand private git repositories
 
-- в вашій компанії є кілька відділів, кожен зі своїми програмістами
-- кожному відділу треба своя конфігурація projectlinter(або вони майже схожі, але все ж є певні відмінності)
-- ви вирішили зберігати конфігурацію в одному місці(наприклад якийсь окремий репозиторій в рамках вашого закритого CVS)
-- ви використовуєте кілька мов програмування
+So, you have a huuuuge codebase, and the code become more legacy every day.
 
----
+The problem with legacy we can divide by 3 parts:
+
+- the programming code become legacy(php code, golang code, js code, ...)
+- the configuration files become legacy(Makefile, composer, go.mod, phpunit, ....)
+- the dependencies become legacy
+
+The first problem is already solved. There are a lot of libraries(or apps) called linters. You create a linter configuration, setup the rules, and finally this apps change your code(or say you what to change), and the code can be easy actual
+
+
+But the 2 other problem does not solve. Your actual configuration can change from time to time. And maybe you even have a so called "template" project(from which you start with new app or library). So, your template is the correct version of every project in your git, and you want to always keep all the other project in "correct" state
+
+For example, you have agreed that composer.json must not exist the section "minimum-stability". You change it in template, but how to change it in 2000(for example) other repositories. This act will took too much time.
 
-## призначення директорій
+Is it a problem - yes. Because such small or even big thing would be only more in more in the future. So, you need a helper. Someone, who will know about all that things and tell you - does your project actual or not. And if not - what to change
 
-- `bin` - місце де знаходиться актуальний бінарник програми. Може бути корисним якщо перевірки відбуваються на стороні CI
-- `cmd` - власне тут описана логіка роботи cli projectlinter
-- `linter` - місце де ви власне налаштовуєте правила, які потім будете запускати
-- `internal` 
-  - `configuration` - місце де знаходиться json-schema по якій будуть налаштовуватися конфігураційний файл project-linter.yaml
-  - місце де можуть знаходитись якісь ваші приватні речі(наприклад нові модулі/правила/набори правил, ...)
+The `projectlinter` app is that helper
+
+![](docs/gif/projectlinter-work.gif)
 
 ---
 
-## Як це працює(з точки зору кода)?
+## the dependencies become legacy
 
-Візьмемо такий приклад:
+What about that part?
 
-Є компанія `UnitedLtd`, яка операційно поділена на 2 відділи(analytics,core) і розробка ведеться на 2х мовах(PHP,GOlang)
+Your project 100% has a dependencies. And sometimes you need to do a big update.
 
-Основну увагу слід зразу звернути на директорію `linter`. Як бачите, в ній є 2 папки - по кожній на відділ.
 
-Щоб не було плутанини, я назвав їх `united-core` та `united-analytics`.
+For example, you have a library "my-private-git/limit-lb". 
 
-Далі: кожна з директорій відділів має 2 піддиректорії - `go` та `php`.
 
----
+### Situation1: You had some problem, and now its fixed
 
-Далі, бачимо що папка з конкретною мовою теж має 3 підпапки:
+Example: "my-private-git/limit-lb" has a memory leak, and ofk this problem affects your prod. Your apps are crashed sometimes, sounds bad. One day that problem was fixed in version 3.25.
 
-- application
-- library
-- shared_source
+So, you need to go to all the projects and update the version.
 
-Що це значить? - UnitedLtd розділяє весь свій код(всі свої репозиторії) на 2 типи: код-програма(наприклад мікросервіси), і код-бібліотека
+### Situation2: You make a change, that is preferable be used in every project
 
-Це, грубо кажучи - режим роботи. Тобто щоразу при запуску projectlinter має розуміти в якому режимі запускатись - "application"(де один набір правил) або в режимі "library"(де вже інший набір правил)
+For example, you become to log some part of code, and if the app does not have this update - you would see no logs, and debug become harder
 
----
+So, you also need to go to all the projects and update the version.
 
-`shared_source` - папка в якій знаходяться спільні для режимів "application" і "library' конфігурації
 
-Що ж може там бути? - як ви бачите - спільними для обох типів проектів є bump та substitute конфігурації
+### Situation3: the new version of library is released
 
-Чому так? - тому що скоріш за все, якщо ви в режимі application(тобто власне на всіх мікросервісах) хочете замінити бібліотеку1 на бібліотеку2, то значить така ж сама заміна потрібна і на рівні режиму "library". Таким чином ми гарантуємо що рано чи пізно ця бібліотека буде повністю замінена у всіх можливих місцях
+"my-private-git/limit-lb" has released 4th version. Sooo amazing.
 
+Now, we wanna to migrate all the projects to new version of library in all the project(and maybe after that remove the v3=>v4 compatibility code)
 
----
+### Situation4: we need to substitute the library
 
-В папці `linter` також є файл `factory.go`
+So, "my-private-git/limit-lb" is cool, and its solve your problem. But what if the internet has better solution? And the solution is popular, maintainable by thousands of people and is much more robust than yours
+
+The idea of stop using own custom code instead of something popular is mature and wright.
+
+And now we need to make this change for all the projects and libraries
 
-Це налаштування що необхідні для cli команд `projectlinter init`(додати конфігураційний файл `project-linter.yaml` в проект) та `projectlinter run`(запустити projectlinter)
 
 ---
 
-## Як це працює(з точки зору користувача)?
+But the problem is - the update of library is not always easy. For example, because you need to update 1000 projects. So, you want to do it, but the amount of work is soooo big that you say - "fuck this update. If someone need - he would update"
 
-Отож, ви вже маєте сконфігуровану програму
+The same problem is for substitute library. It is much more harder then update, because you as a programmer need to read changelogs, understand what to change and how to change, and maybe spend much more time to avoid some secret pitfalls. It is hard, nervous, and not many people like to do it
 
-Для цього ви
 
-- скачали відповідний шаблон
-- замінили назву go модуля на свій
-- підналаштували під себе 
-  - `linter/factory.go`
-  - `internal/configuration`
-- доналаштували правила/набори правил
-- винесли цей проект в свій приватний git репозиторій
+So, you just ignore it. And I understand this pain. What if I can help you with it? So all the bump or substitute action would be absolutely easy
 
-З точки зору користувача все дуже просто. Нам треба знати всього лиш 2 команди:
+Is it possible? - with `projectlinter` - yes
 
-- `projectlinter init` - ініціалізація лінтера в проекті. Додає конфігураційний файл `project-linter.yaml`
-- `projectlinter run` - запуск лінтера в проекті. Програма дивиться на налаштування з `project-linter.yaml` і запускає перевірки для конкретно вашої мови, вашого підрозділа, і вашого режиму роботи(application/library)
+You can share all the knowledge about the libraries, and it would be as easy, as newer before
+For example:
 
-![](docs/gif/projectlinter-work.gif)
 
+![](docs/img/img.png)
+![](docs/img/img_1.png)
+
+The dependency updates are really simple now. They are verbose, they have an examples. So, now there is no problem with new version. Just read the examples, read the description and do it)
+
+Not enough info - chat with your colleagues which are "in context". They will help and consult you
+
+As for me - it is the game-change with such problem
+
+
+---
+
+## This program is working example
+
+This is a working solution right here right now. But it just an example. You need to reconfigure it for yourself
 
-Просто? - просто
+The idea of this app is the same as the other linter - we have an app, which firstly need to configure with rules and ruleSets(a set of rules grouped by some principle(dependency rules, composer rules, phpunit rules, npm rules, ...)) and then we run this app and fix the specified places.
 
-Поки що ця програма вміє тільки підказувати. Сама код не міняє(
+Easy? - easy
 
+As a creator of it I understand that the problem which `projectlinter` solves is big and complex. So, you need some time to investigate the code.
 
+So yes, spend some time to meet and understand it - and your company gain a big boost with obsolescence configuration/dependency problems
 
+## How to projectlinter?
 
+Some time later I will do a number of videos about how the program, how to use and configure it.
+Now the app has only some ukrainian description and videos:
 
+- [ukr README](docs/ua/README.md)
+- [ukrainian youtube presentation](https://www.youtube.com/playlist?list=PLXofZdsJKYx63R_zVuvi-3s7ndueyM3CB)
 
 
+## Can I help the project?
 
+Yes you can. This project was conceived as a multilanguage and multiConfiguration(something that is not programming language related but still a configuration) solution
 
+- You can share at least your needs and ideas.(because now it helps you with a little number of possible problems)
+- You can write your rules and ruleSets
 
+Let's make your configuration codebase actual again)
 

docs/ua/README.md

@@ -0,0 +1,101 @@
+# projectlinter-cli layout
+
+Це шаблон(приклад) того як може виглядати ваш projectlinter
+
+Код розглядається виходячи з таких вводних даних:
+
+- в вашій компанії є кілька відділів, кожен зі своїми програмістами
+- кожному відділу треба своя конфігурація projectlinter(або вони майже схожі, але все ж є певні відмінності)
+- ви вирішили зберігати конфігурацію в одному місці(наприклад якийсь окремий репозиторій в рамках вашого закритого CVS)
+- ви використовуєте кілька мов програмування
+
+---
+
+## призначення директорій
+
+- `bin` - місце де знаходиться актуальний бінарник програми. Може бути корисним якщо перевірки відбуваються на стороні CI
+- `cmd` - власне тут описана логіка роботи cli projectlinter
+- `linter` - місце де ви власне налаштовуєте правила, які потім будете запускати
+- `internal` 
+  - `configuration` - місце де знаходиться json-schema по якій будуть налаштовуватися конфігураційний файл project-linter.yaml
+  - місце де можуть знаходитись якісь ваші приватні речі(наприклад нові модулі/правила/набори правил, ...)
+
+---
+
+## Як це працює(з точки зору кода)?
+
+Візьмемо такий приклад:
+
+Є компанія `UnitedLtd`, яка операційно поділена на 2 відділи(analytics,core) і розробка ведеться на 2х мовах(PHP,GOlang)
+
+Основну увагу слід зразу звернути на директорію `linter`. Як бачите, в ній є 2 папки - по кожній на відділ.
+
+Щоб не було плутанини, я назвав їх `united-core` та `united-analytics`.
+
+Далі: кожна з директорій відділів має 2 піддиректорії - `go` та `php`.
+
+---
+
+Далі, бачимо що папка з конкретною мовою теж має 3 підпапки:
+
+- application
+- library
+- shared_source
+
+Що це значить? - UnitedLtd розділяє весь свій код(всі свої репозиторії) на 2 типи: код-програма(наприклад мікросервіси), і код-бібліотека
+
+Це, грубо кажучи - режим роботи. Тобто щоразу при запуску projectlinter має розуміти в якому режимі запускатись - "application"(де один набір правил) або в режимі "library"(де вже інший набір правил)
+
+---
+
+`shared_source` - папка в якій знаходяться спільні для режимів "application" і "library' конфігурації
+
+Що ж може там бути? - як ви бачите - спільними для обох типів проектів є bump та substitute конфігурації
+
+Чому так? - тому що скоріш за все, якщо ви в режимі application(тобто власне на всіх мікросервісах) хочете замінити бібліотеку1 на бібліотеку2, то значить така ж сама заміна потрібна і на рівні режиму "library". Таким чином ми гарантуємо що рано чи пізно ця бібліотека буде повністю замінена у всіх можливих місцях
+
+
+---
+
+В папці `linter` також є файл `factory.go`
+
+Це налаштування що необхідні для cli команд `projectlinter init`(додати конфігураційний файл `project-linter.yaml` в проект) та `projectlinter run`(запустити projectlinter)
+
+---
+
+## Як це працює(з точки зору користувача)?
+
+Отож, ви вже маєте сконфігуровану програму
+
+Для цього ви
+
+- скачали відповідний шаблон
+- замінили назву go модуля на свій
+- підналаштували під себе 
+  - `linter/factory.go`
+  - `internal/configuration`
+- доналаштували правила/набори правил
+- винесли цей проект в свій приватний git репозиторій
+
+З точки зору користувача все дуже просто. Нам треба знати всього лиш 2 команди:
+
+- `projectlinter init` - ініціалізація лінтера в проекті. Додає конфігураційний файл `project-linter.yaml`
+- `projectlinter run` - запуск лінтера в проекті. Програма дивиться на налаштування з `project-linter.yaml` і запускає перевірки для конкретно вашої мови, вашого підрозділа, і вашого режиму роботи(application/library)
+
+![](../gif/projectlinter-work.gif)
+
+
+Просто? - просто
+
+Поки що ця програма вміє тільки підказувати. Сама код не міняє(
+
+
+
+
+
+
+
+
+
+
+