Как рассказал Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio, открытое ПО имеет длинную историю как в инженерной, так и в производственной инфраструктуре: от операционных систем (Linux) до систем управления базами данных (PostgreSQL). Доверие к таким решениям складывается из практических механизмов: прозрачности, воспроизводимости и коллективного аудита. Например, OpenSSL, ядро Linux и PostgreSQL регулярно проходят независимые проверки, включая исследования университетов и консалтинговых компаний.

Алексей Варлаханов, руководитель отдела прикладных систем Angara Security, считает, что Open Source заслуживает доверия, прежде всего, благодаря прозрачности исходного кода, что позволяет проводить независимый аудит безопасности и модифицировать продукт под конкретные нужды организации.

«Один из ключевых аргументов в пользу OSS-продуктов – любой желающий может посмотреть исходный код, пересобрать его, провести аудит с помощью инструментов статического, композитного или динамического анализа. Всё это снижает вероятность возникновения скрытых бэкдоров, неочевидных шпионских функций или недокументированных механизмов сбора данных, к примеру, телеметрии», — рассказал Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio.

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

Как рассказал генеральный директор Swordfish Security Александр Пинаев, продукты с открытым исходным кодом пользуются доверием разработчиков, поскольку его безопасность можно проверить. Инженеры могут самостоятельно просканировать исходный код или заказать проверку у ИБ-специалистов. С проприетарным кодом это не всегда возможно, так как компании чаще всего не поставляют исходный код вместе с продуктом.

С точки зрения доверенности и безопасности, наличие свободных компонентов является большим плюсом, поскольку возможности их исследования значительно выше, чем проприетарных, отметил Алексей Смирнов, председатель совета директоров «Базальт СПО». К тому же, благодаря доступности исходного кода в его исследовании принимает участие большое сообщество разработчиков.

Широко известны OSS-проекты, такие как Linux, Nginx, Kubernetes, OpenSSH, которые выбирают из-за ряда преимуществ и используют повсеместно крупные коммерческие компании. Эксперты считают, что эти программы являются более надёжными, чем многие проприетарные аналоги.

«Идея о том, что OSS-продукты более уязвимы – миф. Действительно, есть риски, связанные с качеством управления проектом, атаками на цепочку поставок и отсутствием централизованной ответственности, но корректное управление ими делает использование OSS-продуктов более безопасным», — отметил Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio. 

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

«Можно сказать, что идея о потенциально более высокой уязвимости Open Source по сравнению с проприетарным софтом является ошибочным стереотипом. Действительно, публичность кода означает, что уязвимости видны всем, включая злоумышленников, но одновременно это обеспечивает гораздо более быстрый отклик сообщества и производителей на их устранение» — прокомментировал Алексей Варлаханов, руководитель отдела прикладных систем Angara Security.

Мой GitHub - https://github.com/prog-time

Идея проекта

Большинство Open Source-проектов создаётся не с целью прямой монетизации, а ради социального признания. К таким показателям можно отнести звёзды на GitHub, лайки и подписчиков в социальных сетях. Эти метрики позволяют получить внешнюю оценку проделанной работы и, в определённой степени, повысить свою заметность на рынке.

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

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

Отдельное внимание стоит уделить масштабу проекта. Оптимальное время разработки до первой MVP-версии не должно превышать 1–2 недель. Более длительный цикл без ощутимого результата значительно повышает риск выгорания и потери интереса к проекту.

Для вдохновения вы можете посмотреть проекты которые сейчас в тренде на GitHub или подписаться на Topic по интересующему вас направлению (https://github.com/trending).

Выбор аудитории

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

В общем случае проекты можно условно разделить на два типа:

• проекты для разработчиков;

• проекты для конечных (сторонних) пользователей.

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

Проекты для разработчиков

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

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

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

Проекты для конечных пользователей

Если проект ориентирован на пользователей, не связанных с разработкой (как в моём случае), приоритеты смещаются. Здесь особенно важно уделять внимание:

• производительности и оптимизации;

• качественной и понятной документации;

• простоте установки и быстрому развёртыванию проекта.

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

Наблюдения из практики

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

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

Начало разработки

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

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

Если же проект представляет собой отдельный сервис (как в моём случае), стоит заранее задуматься о контейнеризации. Использование Docker позволяет изолировать зависимости, стандартизировать окружение и значительно упростить процесс установки и запуска проекта.

В процессе разработки проекта tg-support-bot я предусмотрел два варианта установки:

• Полный вариант — развёртывание через docker-compose, включающее все необходимые сервисы: PostgreSQL, PgAdmin, Loki, Grafana, Redis и другие компоненты.

• Упрощённый вариант — установка проекта на обычный хостинг с возможностью подключения внешней базы данных и отключения необязательных сервисов.

При этом важно избегать жёстких зависимостей между контейнерами. Пользователи должны иметь возможность отключать или заменять отдельные сервисы внутри docker-compose без нарушения работоспособности основного приложения.

Линтинг, настройка CI и тесты

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

Code style и линтеры

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

Также необходимо настроить линтеры, которые проверяют код на:

• синтаксические ошибки и типизацию;

• соответствие имен переменных и функций выбранному стилю;

• распространённые ошибки и потенциальные уязвимости.

Автоматическое тестирование

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

В проекте tg-support-bot я реализовал систему shell-скриптов для автоматизации линтинга и тестирования с передачей дополнительных параметров к инструментам анализа.

Скрипты интегрированы с git-хуками:

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

• Статический анализатор PHPStan проверяет код на ошибки и нарушения типизации;

• Выполняются unit-тесты для изменённых классов;

• Если изменён Dockerfile, запускается Hadolint для проверки Dockerfile;

• Если изменены shell-скрипты, применяется ShellCheck для выявления ошибок и потенциальных уязвимостей.

При push выполняется проверка всего проекта: PHPStan анализирует весь код, запускаются все unit-тесты и линтеры. Это позволяет выявить проблемы, которые могли быть пропущены при коммите.

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

В случае обнаружения ошибки системы блокирует изменения до исправления ошибок.

Скрипты для git-hooks вы можете посмотреть здесь - https://github.com/prog-time/git-hooks

Таким образом, процесс тестирования делится на три уровня:

1. Локальная проверка при коммите — только файлы, добавленные в коммит.

2. Проверка при push — весь проект для предотвращения глобальных ошибок.

3. CI/CD — полная автоматическая проверка, включая сторонние изменения.

Продуманная система тестирования и линтинга позволяет снизить риски и обеспечивает стабильность проекта, что особенно важно в Open Source-разработке.

Структура GitHub репозитория

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

Структура веток

На своих проектах я использую следующую схему:

• Ветка main является основной. Прямые коммиты в неё запрещены — все изменения вносятся через дочерние ветки.

• Релизные ветки создаются перед планированием релиза. Например, для шестого релиза создаётся ветка release_6. В этой ветке я фиксирую все задачи, которые должны войти в релиз.

• Ветки задач создаются для каждой отдельной задачи из релиза. В наименовании ветки обязательно указывается номер соответствующего Issue. Это строгое правило: ветка с некорректным именем не пройдет проверки CI, и изменения не смогут быть слиты в проект.

Такой подход помогает:

1. Приучиться создавать Issues для любых изменений;

2. Контролировать работу сторонних контрибьюторов;

3. Поддерживать прозрачность процесса разработки.

Структура коммитов

Для упрощения отслеживания изменений я использую shell-скрипты, которые автоматически:

• Добавляют в начало описания коммита номер задачи (issues-62 | update tests);

• Формируют список изменённых файлов с пометками Added, Changed, Deleted.

Пример такого комментария:

Структура релизов

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

• прозрачное ведение истории изменений;

• удобство для контрибьюторов и пользователей;

• облегчение поддержки проекта в долгосрочной перспективе.

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

Документирование

Документирование — один из ключевых аспектов Open Source-разработки. Хорошая документация делает проект доступным для пользователей и контрибьюторов, ускоряет внедрение и снижает количество ошибок при использовании.

Основные элементы документации

1. README.md

   • Основной файл, который видит каждый пользователь на GitHub.

   • Должен содержать:

     • краткое описание проекта;

     • инструкции по установке и настройке;

     • пример использования;

     • ссылки на документацию.

2. CONTRIBUTING.md

   • Описание процесса внесения изменений в проект.

   • Рекомендуется включать:

     • правила создания веток и коммитов;

     • процесс отправки pull request;

     • требования к тестированию и линтингу.

3. CHANGELOG.md

   • Фиксирует историю релизов и внесённых изменений.

   • Формат: версия, дата релиза, исправления, новые функции.

Отдельно хочу выделить раздел Wiki на GitHub...

GitHub Wiki — это встроенный инструмент для более подробной и структурированной документации проекта. В отличие от README, Wiki позволяет создавать несколько страниц, объединённых логической структурой, что удобно для больших проектов.

Использование Wiki целесообразно для расширенной документации: здесь можно описать архитектуру проекта, инструкции по деплою и CI/CD, гайды по использованию библиотек и сервисов, а также рекомендации для контрибьюторов. Важно, чтобы Wiki дополняла README, а не дублировала его, оставляя последний кратким и ориентированным на быструю установку и запуск.

Практические рекомендации

• Документируйте всё ключевое сразу, не откладывая на будущее. Это экономит время и снижает риск потери информации.

• Используйте шаблоны и стандарты (например, Markdown, OpenAPI, DocBlock), чтобы документация была однородной.

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

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

Взаимодействие с аудиторией

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

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

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

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

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

Таким образом, налаженная коммуникация с аудиторией позволяет объединить пользователей, повысить вовлечённость и создать сообщество вокруг проекта, что является ключевым фактором успешного Open Source-развития.

Популяризация проекта

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

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

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

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

Заключение

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

Если вам интересно следить за моими проектами и участвовать в их развитии, подписывайтесь на мой GitHub — там вы найдёте все обновления и сможете присоединиться к работе над проектами.

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

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

Веб-сайт с общедоступным расписанием клуба World Class

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

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

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

Поворотный момент и техническая проблема

В какой-то момент я наткнулся на чистую ссылку, которая ведёт только на само расписание фитнес-клуба World Class без любой рекламы. Ссылка выглядит следующим образом:

https://my.worldclass.ru/scheduling?clubs=d35ba5fc-1f7e-11ec-b664-50e548298f06

Где вместо d35ba5fc-1f7e-11ec-b664-50e548298f06 должен стоять идентификатор вашего клуба. Выше это идентификатор клуба в городе Перми.

Все доступные идентификаторы других клубов можно посмотреть прямо в браузере в режиме просмотра страницы:

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

ICG Color Cycle (сайкл)

В пермском клубе World Class не обязательно записываться на занятия по сайклу заранее - достаточно прийти примерно за полчаса до занятия и взять на входе черную карточку для участия - места есть до тех пор пока карточки не закончатся. Правда бывают приходят и те кто записались онлайн, но карточку не взяли - просто не знали про это и мест не хватает. Это некоторая путаница.

Создание решения

Поскольку я использую Гугл календарь, то написал Google Apps скрипт. Apps Script - платформа на основе JavaScript для быстрой и простой разработки решений.

Скрипт может значительно упростить работу пользователя, избавив его от необходимости вручную проверять расписание и добавлять занятия в свой Гугл календарь.

Скрипт работает следующим образом:

1. Получение расписания: скрипт отправляет запрос в API World Class с идентификатором определенного спортзала. Далее извлекает расписание на следующие семь дней.

2. Фильтрация соответствующих занятий: после извлечения расписания скрипт отфильтровывает занятия «ICG Color Cycle» и «CORE», которые я хочу посещать. Все дальнейшие действия происходят только для отобранной выборки.

3. Создание событий календаря: для каждой отфильтрованной тренировки скрипт автоматически создает событие в Google календарь по умолчанию. Каждое событие включает:

• Название: название тренировки (в моём случае либо «ICG Color Cycle», либо «CORE»).

• Продолжительность: каждое событие запланировано на один час.

• Описание: подробное объяснение зачем нужна эта тренировка.

• Расположение: конкретный адрес клуба World Class, где проходит занятие.

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

По сути, этот скрипт - инструмент экономии времени для резидентов клуба World Class, которые могут быть уверены, что всегда будут знать когда проходят их любимые занятия.

Версия скрипта полного дня:

function WorldclassAPISchedulingPerm() {

console.log(`Функция WorldclassAPISchedulingPerm начала работу в ${(new Date()).toLocaleString("ru-RU")}`);

const url = 'https://my.worldclass.ru/api/v1/clubs/scheduling';

const currentDate = new Date();

const endDate = new Date(currentDate);

endDate.setDate(currentDate.getDate() + 7);

// Подробное описание: https://pikabu .ru/story/kak_ya_uluchshil_svoyo_vzaimodeystvie_s_fitnesklubom_world_class_naydya_i_ispolzuya_ikh_api_11835205

// Это версия скрипта полного дня

const payload = {

"gymList": [

"d35ba5fc-1f7e-11ec-b664-50e548298f06" // это World Class в Перми

],

"startDate": currentDate.toISOString().split('.')[0],

"endDate": endDate.toISOString().split('.')[0],

"chain": 1,

"token": "70a69ca6-XXXX-XXXX-a975-005056b1372d"

};

const options = {

method: 'post',

contentType: 'application/json',

payload: JSON.stringify(payload),

muteHttpExceptions: true,

headers: {

'brand': 'WorldClass',

'language': 'Ru',

'chain': '1',

'Accept': '*/*',

'Origin': 'https://my.worldclass.ru',

'Referer': 'https://my.worldclass.ru/scheduling?clubs='

},

timeoutSeconds: 30

};

try {

const response = UrlFetchApp.fetch(url, options);

const responseCode = response.getResponseCode();

console.log(`Код ответа: ${responseCode}`);

const responseText = response.getContentText();

const responseData = JSON.parse(responseText); // Разбираем JSON-строку

if (responseCode === 200) {

// Фильтрация для "ICG Color Cycle (сайкл)" и "CORE"

const filteredDates = responseData.data

.filter(item => item.service.name === "ICG Color Cycle (сайкл)" || item.service.name === "CORE")

.map(item => ({

name: item.service.name,

startDate: item.startDate,

employee: item.employee.firstName + " " + item.employee.lastName,

shortDescription: item.service.shortDescription

}));

console.log('Отфильтрованные даты:', filteredDates);

// Создаем события в календаре для каждой отфильтрованной даты

filteredDates.forEach(eventData => {

const startTime = new Date(eventData.startDate);

const endTime = new Date(startTime);

endTime.setHours(startTime.getHours() + 1); // Устанавливаем продолжительность события на 1 час

let eventTitle = `${eventData.name} - ${eventData.employee}`;

let eventDescription = '';

eventDescription = eventData.shortDescription +

'\n\nhttps://my.worldclass.ru/scheduling?clubs=d35ba5fc-1f7e-11ec...' +

'\nСоздано автоматически ' + (new Date()).toLocaleString("ru-RU");

CalendarApp.getDefaultCalendar().createEvent(

eventTitle,

startTime,

endTime, {

description: eventDescription,

location: 'Фитнес клуб World Class, Пермская ул., 33, Пермь, Пермский край, Россия, 614045'

}

);

console.log(`Событие создано для: ${startTime} - ${eventTitle}`);

});

} else {

console.error(`Ошибка: получен статус ${responseCode} с ответом: ${responseText}`);

}

} catch (error) {

console.error('Ошибка запроса:', error.message);

}

console.log(`Функция WorldclassAPISchedulingPerm закончила работу в ${(new Date()).toLocaleString("ru-RU")}`);

}

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

Ниже версия скрипта для дневного браслета, когда обязательный выход из зала до 17:00:

// Фильтрация для "ICG Color Cycle (сайкл)" и "CORE", а также по времени начала (до 17:00)

const filteredDates = responseData.data

.filter(item => (item.service.name === "ICG Color Cycle (сайкл)" || item.service.name === "CORE") &&

new Date(item.startDate).getHours() < 17)

.map(item => ({

name: item.service.name,

startDate: item.startDate,

employee: item.employee.firstName + " " + item.employee.lastName,

shortDescription: item.service.shortDescription

}));

console.log('Отфильтрованные даты:', filteredDates);

Как Вы можете воспользоваться этим скриптом?

Если вы новичок и хотите тоже автоматизировать получение определенных занятий, то скрипт Google Apps это мощный инструмент, который может вам помочь:

Шаг 1: Доступ к скрипту Google Apps

1. Откройте Google Drive: начните с перехода на Google Drive.

2. Создайте новый скрипт:

• Нажмите кнопку Создать в верхнем левом углу.

• Выберите Еще в раскрывающемся меню.

• Нажмите Скрипт Google Apps. Откроется редактор скриптов Google Apps на новой вкладке.

Шаг 2: Назовите свой проект

1. Назовите свой скрипт: как только откроется редактор скриптов приложений, вы увидите проект без названия. Нажмите на заголовок (обычно это «Проект без названия») и дайте ему осмысленное имя, например «Расписание World Class».

Шаг 3: Скопируйте код

1. Удалите код по умолчанию: в редакторе вы увидите код по умолчанию (function myFunction() {}). Вы можете удалить его, чтобы освободить место для нового скрипта.

2. Скопируйте и вставьте код:

• Перейдите к статье с кодом скрипта Google Apps.

• Скопируйте весь скрипт, предоставленный в статье.

• Вернитесь в редактор скриптов приложений и вставьте код в пустое место.

Шаг 4: Сохраните свой скрипт

1. Сохраните свою работу: Щелкните значок дискеты или нажмите Ctrl + S (или Cmd + S на Mac), чтобы сохранить свой скрипт.

Шаг 5: Запустите скрипт

1. Запустите свой скрипт: Чтобы протестировать скрипт, щелкните значок воспроизведения (▶) в верхней части редактора. Если вы запускаете скрипт впервые, Google запросит авторизацию.

2. Авторизуйте свой скрипт: Следуйте инструкциям, чтобы разрешить скрипту доступ к вашему Google Calendar и другим необходимым службам.

Шаг 6: Проверьте вывод

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

Шаг 7: Автоматизируйте его

1. Установите триггер: если вы хотите, чтобы этот скрипт запускался автоматически через регулярные интервалы, вы можете настроить триггер:

• Нажмите на значок часов на панели инструментов (Триггеры).

• Нажмите + Добавить триггер в правом нижнем углу.

• Установите запуск скрипта еженедельно, например на ночь между понедельником и вторником.

И это все! Вы успешно создали скрипт Google Apps, который автоматизирует добавление расписания в ваш календарь Google.

Результаты

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

Автор: Михаил Шардин