• Сделал отдельный регистр сведений — туда пишется только нужная информация о каждом клиенте (наименование, ИНН, КПП, ФИО ответственного). Все поля — строки, чтобы не споткнуться о ограничения прав на уровне ссылок.

• Настроил подписки на события:

  • При создании/изменении контрагента — запись/обновление в регистре.

  • При удалении (пометка на удаление) — запись из регистра тоже удаляется.

• Автоматизировал обновление: когда меняется партнер — автоматически обновляется связанный контрагент, чтобы в регистре всегда были актуальные данные.

• Пилил простую обработку для поиска: вводишь часть названия или ИНН — находишь клиента, и сразу видно: есть такой, или нет, и кто сейчас его "куратор".

Итог

В результате — все довольны:

• Менеджеры не видят ничего лишнего, только своих клиентов и документы.

• Но если что — могут быстро пробить по базе, есть ли такой клиент, и если есть — кто с ним уже работает.

Для тех, кто любит 1С: да, с типовыми правами такое не сделать, пришлось "изобретать велосипед", но вышло удобно и безопасно.

P.S.
Если интересно, могу выложить детали реализации или куски кода — спрашивайте в комментах!
И вообще, если есть свои лайфхаки по разграничению доступа в 1С, делитесь, с радостью почитаю :)

Результатом стало введение гибкого графика – понедельник и пятница – в офисе, остальные дни – дома. С установленной системой мониторинга. Народ согласился. И стал ставить дома кликеры)

А дальше началось соревнование в их выявлении и способах противодействия этому.

Самый простой джигглер, двигающий курсор мыши на экране, дабы тот не гас и комп не переходил в ждущий режим – давно не актуален. Электромеханический кликер с алиэкспресса, нажимающий с определенными периодами на кнопки – увы, неактуален тоже – эти самые периоды система мониторинга легко вычисляет и пишет в простой.

Ну и в результате появился ЗАЯЦ. Главное его отличие от остальных кликеров – умное управление мышкой путем нажатия ЛКМ и вращения колесика. Алгоритмы выполнены таким образом, что даже на видеозаписи экрана видно, как происходит чтение какого-либо документа (таких прилетает по несколько в день и со всеми нужно, как минимум, ознакомится). Повторений при этом нет, алгоритмы гибкие – то есть простоя не будет)

Таймлапс примера работы можно глянуть во втором посте из серии про ЗАЙЦа.

https://zalipaka.icu/story/video_rabotyi_umnogo_imitatora_myishi_zayac_12916644

Подводя итог. Да, этот пост скорее рекламный. Да, это устройство родилось вследствие противодействия системе. Да, оно оригинальное, собственная разработка. Нет, злоупотреблять им не нужно, так как помочь со временем на ваши личные дела оно может, но сделать саму вашу работу за вас, увы, нет. Ну и еще – если у вас есть вопросы – добро пожаловать в комментарии, спрашивайте!

в ней мы будем хранить наши сценарии.

Сценарий: "Аудит Git-репозитория"

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

1. В дирекрории scenarios Создайте файл git-health-check.md со следующим содержимым:

   Ты — опытный Git-инженер. Твоя задача — провести полный аудит текущего репозитория. Выполни следующие шаги строго по порядку и дождись моего подтверждения для каждой команды:
   1. **Проверь статус:** Покажи мне текущий статус репозитория, чтобы увидеть неотслеживаемые или измененные файлы. Предложи команду `!git status`.
   2. **Запроси обновления:** Получи последние изменения с удаленного сервера, но не применяй их. Предложи команду `!git fetch origin`.
   3. **Сравни ветки:** Покажи мне разницу между моей локальной веткой `main` и удаленной `origin/main`. Предложи команду `!git log main..origin/main --oneline`.
   4. **Найди большие файлы:** Найди 5 самых больших файлов в проекте, которые не находятся в `.git`. Предложи команду `!find . -type f -not -path "./.git/*" -printf "%s %p\n" | sort -rn | head -n 5`.
   5. **Подведи итог:** В конце кратко опиши состояние репозитория на основе полученных данных.

2. Запустите сценарий в Gemini CLI:

   > Прочитай и выполни сценарий 'git-health-check.md'

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

Шаг 1: Проверка статуса

Ответ Gemini:

>✦ Я — опытный Git-инженер. Начинаю аудит вашего репозитория.

> Шаг 1: Проверка статуса

>Чтобы проверить текущий статус репозитория и увидеть неотслеживаемые или измененные файлы, я выполню команду `git status`.

Исполнения команды git status...

Ответ Gemini:

✦ Ошибка: C:\Users\user\Documents\repos не является Git-репозиторием. Пожалуйста, укажите, в каком из подкаталогов мне следует запустить аудит. Например, public_repositories.

Просим создать новый репозиторий. Ответ Gemini:

Ответ Gemini:

✦ Отлично, Git-репозиторий создан. Теперь я могу продолжить аудит.
Выполняю git status, чтобы проверить наличие неотслеживаемых файлов.

Ответ Gemini:

✦ В репозитории много неотслеживаемых файлов и папок. Чтобы продолжить, мне нужно добавить их в индекс. Я добавлю все файлы.

ok

Во время выполнения команды произошла ошибка

error: pathspec 'commit"' did not match any file(s) known to git

Ответ Gemini:

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

На этот раз получилось!

Ответ Gemini:

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

Теперь gemini удалит временный файл с сообщением коммита. gemini cli по очереди применяет релевантную команду (`rm`, `del`)

Шаг 2: Запрос обновлений

Поскольку удаленный репозиторий не существует, gemini cli получит ошибку. Обратите внимание, что она сама ожидает ошибку, но обязана выполнить команду т.к. она записана в сценарии `git-health-check.md`

Шаг 3: Сравнение веток

Здесь также будет ошибка, поскольку ветка main не существует.

Шаг 4: Поиск больших файлов

Команда `find` не сработала, потому что в Windows нужно использовать `dir`. Gemini сама исправит ошибку и предложит правильную команду. Далее gemini cli рассуждает о следующих действиях:

Ответ Gemini:

✦ THINK: The user wants me to find the 5 largest files in the project.
The previous command find . -type f -not -path \"./.git/*\" -printf \"%s %p\\n\" | sort -rn | head -n 5 failed because find, sort, and head are not native Windows commands. I need to use a PowerShell equivalent.
1. Get all files: Get-ChildItem -Recurse -File
2. Exclude .git directory: Where-Object { $_.FullName -notlike "*\.git\*" }
3. Sort by size (descending): Sort-Object -Property Length -Descending
4. Select the top 5: Select-Object -First 5
5. Format the output: ForEach-Object { "{0} {1}" -f $_.Length, $_.FullName }

Let's combine these into a single PowerShell command.Похоже, что find и head не доступны в вашей среде Windows. Я использую PowerShell, чтобы выполнить ту же задачу.

Снова неудача

gemini cli продолжает рассуждать о том, что делать дальше:
Ответ Gemini:

✦ THINK: The user wants to find the 5 largest files.

The PowerShell command is still not executing correctly. It seems that the pipe | and special characters are being misinterpreted by the shell when passed as a single command string.

I will try to execute the command by first saving the script to a file and then executing the file with PowerShell.

1. Create a PowerShell script file (find_large_files.ps1).
2. The content of the script will be: Get-ChildItem -Recurse -File | Where-Object { $_.FullName -notlike "*\.git\*" } | Sort-Object -Property Length -Descending | Select-Object -First 5 | Format-Table Length, FullName -AutoSize
3. Execute the script using powershell -File find_large_files.ps1.
4. Delete the script file.

Похоже, что передача сложных команд в PowerShell напрямую вызывает проблемы.

Я создам временный файл сценария PowerShell, выполню его, а затем удалю.

На этот раз все получилось!

Шаг 5: Итог

gemini cli подводит итог:

Состояние репозитория:
* Локальный репозиторий: Инициализирован, и все файлы в корневой папке C:\Users\user\Documents\repos были добавлены в первый коммит.
* Удаленный репозиторий: Не настроен. Нет удаленного origin, поэтому невозможно получить обновления или сравнить ветки.
* Большие файлы: Обнаружено несколько очень больших файлов, в основном в подкаталогах venv и public_repositories. Самые большие из них — библиотеки .lib и архивы .zip. Рекомендуется добавить пути, содержащие большие бинарные файлы (например, venv, *.zip), в файл .gitignore, чтобы избежать их попадания в репозиторий. Аудит завершен.

Сценарий: "Очистка Docker-окружения"

Docker со временем накапливает множество ненужных образов, контейнеров и сетей. Этот сценарий поможет безопасно всё почистить.

1. Создайте файл docker-cleanup.md:

   Ты — DevOps-инженер, ответственный за чистоту системы. Твоя задача — безопасно очистить Docker-окружение. Действуй по шагам:

   1. **Покажи запущенные контейнеры:** Сначала выведи список всех активных контейнеров, чтобы я мог убедиться, что не остановлю что-то важное. Предложи `!docker ps`.

   2. **Останови все контейнеры:** После моего одобрения предложи команду для остановки ВСЕХ запущенных контейнеров. Команда: `!docker stop $(docker ps -q)`.

   3. **Глобальная очистка:** Теперь выполни полную очистку системы от "висячих" (dangling) образов, остановленных контейнеров, неиспользуемых сетей и кэша сборки. Предложи самую безопасную и эффективную команду `!docker system prune -af`.

   4. **Отчет:** После выполнения сообщи, сколько места было освобождено, основываясь на выводе последней команды.

2. Запустите сценарий в Gemini CLI:

   > Прочитай и выполни сценарий очистки Docker из файла 'docker-cleanup.md'

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

Сценарий: "Запуск системных приложений"

Как и было Gemini отлично справляется с запуском приложений. Давайте формализуем это в виде простого сценария для Windows.

1. Создайте файл open-windows-tools.md:

   Ты — системный администратор Windows.

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

   - Если я прошу "планировщик задач", предложи запустить `!taskschd.msc`.

   - Если я прошу "редактор реестра", предупреди об опасности и предложи запустить `!regedit`.

   - Если я прошу "монитор ресурсов", предложи запустить `!resmon`.

   - Если я прошу "диспетчер задач", предложи запустить `!taskmgr`.

   - Если я прошу "командная строка", предложи запустить `!cmd`.

   - Если я прошу "проводник", предложи запустить `!explorer`.

   Аналогично для других утилит.

2. Запустите сценарий и дайте команду:

   > Используй инструкции из 'open-windows-tools.md'. Открой планировщик задач.

Результат: Gemini поймет контекст из файла и ваш запрос, после чего предложит выполнить нужную команду.

Ответ Gemini:

Хорошо, открываю Планировщик задач. Выполнить `!taskschd.msc`? (y/n)

После подтверждения на вашем экране откроется стандартная утилита Windows.

Первая часть «Gemini CLI: Знакомство и первые шаги»

В третьей части я покажу как интегрировать gemini cli в среду разработки vs code

Полезно? Подпишись!

Удачи! 🚀

Кешируй одноразовые коллекции

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

Теневой DOM позволяет прикреплять скрытые DOM-деревья к элементам в обычном DOM-дереве. Это теневое дерево начинается с теневого корня (shadow root), под который можно прикреплять любые элементы так же, как и в обычном DOM.

Существует несколько терминов, связанных с теневым DOM, которые следует знать:

• Теневой хост (Shadow host): Обычный узел DOM, к которому прикреплен теневой DOM.

• Теневое дерево (Shadow tree): DOM-дерево внутри теневого DOM.

• Теневая граница (Shadow boundary): Место, где заканчивается теневой DOM и начинается обычный DOM.

• Теневой корень (Shadow root): Корневой узел теневого дерева.

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

До того, как теневой DOM стал доступен веб-разработчикам, браузеры уже использовали его для инкапсуляции внутренней структуры стандартных элементов. Например, элемент <video> с элементами управления. Всё, что вы видите в DOM, — это тег <video>, но он содержит ряд кнопок и других элементов управления внутри своего теневого DOM.

Создание теневого DOM

Создавать теневой DOM можно двумя способами: императивно с помощью JavaScript или декларативно прямо в HTML.

Императивно с помощью JavaScript

Этот способ отлично подходит для приложений, рендерящихся на стороне клиента. Мы выбираем элемент-хост и вызываем на нём метод attachShadow().

Результат на странице будет выглядеть так:

Я нахожусь в теневом DOM Я не в теневом DOM

Декларативно с помощью HTML

Для приложений, где важен рендеринг на стороне сервера, можно определить теневой DOM декларативно, используя элемент <template> с атрибутом shadowrootmode.

Когда браузер обработает этот код, он автоматически создаст теневой корень для <div> и поместит в него содержимое тега <template>. Сам тег <template> при этом исчезнет из основного DOM-дерева.

Инкапсуляция: защита от JavaScript и CSS

Главное преимущество Shadow DOM — это изоляция. Давайте посмотрим, как она работает.

Инкапсуляция от JavaScript

Добавим кнопку, которая будет пытаться изменить все элементы <span> на странице.

При нажатии на кнопку текст изменится только у <span>, который находится в основном документе. Элемент внутри теневого DOM останется нетронутым, потому что document.querySelectorAll() не может "заглянуть" за теневую границу.

Доступ к теневому DOM: свойство shadowRoot и работа с вложенностью

Когда мы вызываем host.attachShadow({ mode: "open" }), мы создаём теневой DOM в "открытом" режиме. Это означает, что мы можем получить доступ к его содержимому извне через свойство host.shadowRoot.

Если же указать mode: "closed", свойство host.shadowRoot вернёт null, и доступ к теневому дереву извне будет закрыт. Это не строгий механизм безопасности, а скорее соглашение для разработчиков о том, что внутренности компонента трогать не следует.

Работа с вложенными теневыми деревьями

В сложных компонентных архитектурах один пользовательский элемент может содержать внутри себя другие пользовательские элементы, каждый из которых имеет свой собственный Shadow DOM. Чтобы добраться до элемента в глубоко вложенном теневом дереве, придётся последовательно "проходить" через каждый shadowRoot.

Представим себе такую структуру:

• Компонент <nmbrs-form> (основная форма).

• Внутри него находится <div>, а в нём — компонент <nmbrs-button> (кастомная кнопка).

• Внутри <nmbrs-button> находится настоящая HTML-кнопка <button>.

Чтобы получить доступ к этой кнопке из глобального контекста, путь будет выглядеть так:

SВ виде одной цепочки вызовов это выглядит так:

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

Инкапсуляция от CSS

Стили, определённые на основной странице, не влияют на элементы внутри теневого DOM.

Элемент <span> внутри теневого дерева не получит эти стили. Это решает огромную проблему случайных пересечений и конфликтов CSS.

Применение стилей внутри теневого DOM

Стили, определённые внутри теневого дерева, в свою очередь, не влияют на основную страницу. Есть два основных способа их добавления.

1. Конструируемые таблицы стилей (Constructable Stylesheets)

Этот метод позволяет создавать объект CSSStyleSheet в JavaScript и применять его к одному или нескольким теневым деревьям. Это эффективно, если у вас есть общие стили для множества компонентов.

2. Добавление элемента <style>

Простой и декларативный способ — поместить тег <style> прямо внутрь теневого дерева (часто внутри <template>).

Теневой DOM и пользовательские элементы: идеальное сочетание

Вся мощь теневого DOM раскрывается при создании пользовательских элементов (Custom Elements). Без инкапсуляции они были бы невероятно хрупкими.

Пользовательский элемент — это класс, наследующий HTMLElement. Как правило, сам элемент выступает в роли теневого хоста, а вся его внутренняя структура создаётся внутри теневого дерева.

Вот пример простого компонента <filled-circle>:

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

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

Полезно? Подпишись.
Удачи 🚀