PyCharm плагин: Combine and Copy Files to Clipboard. Отличный инструмент для DevOps и K8S инженеров.

Когда работаешь с конфигурациями или управляешь инфраструктурой, часто сталкиваешься с ситуацией, когда необходимо быстро поделиться фрагментами кода или конфигураций с коллегами, либо передать структуру проекта для дальнейшего анализа. Плагин Combine and Copy Files to Clipboard для PyCharm стал для меня настоящим спасением в этих задачах.

В чем его сила?

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

Вот как это работает:

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

Простой пример:

Представьте, что у вас есть несколько файлов с конфигурациями Kubernetes или CI/CD пайплайнов. Вместо того, чтобы вручную копировать каждый файл и объяснять, где он находится в проекте, плагин Combine and Copy Files to Clipboard делает это за вас. Он собирает файлы, добавляет их содержимое в один блок и позволяет вам легко делиться этим с коллегами или использовать при работе с AI-инструментами, такими как ChatGPT.

Это действительно "Over Powered" инструмент для тех, кто хочет эффективно управлять своими задачами, не тратя время на рутину.

Мой опыт:

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

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

Цена:
- 30 дней бесплатно
- 1 USD/month после 30 дней

Книга Kubernetes in Action (2nd edition by Marko Lukša, Kevin Conner) — отличный старт для знакомства с Kubernetes

Когда я начал читать книгу Kubernetes in Action, сразу понял — это не просто теория. Автор делает акцент на понятном объяснении того, что такое Kubernetes, как он работает и почему его популярность так стремительно выросла. Честно говоря, я был впечатлен уже с первых страниц.

Что мне особенно понравилось

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

Теперь давайте разберем основные идеи первых глав (1.1 Introducing Kubernetes - 1.2 Understanding Kubernetes), которые привлекли мое внимание.

---

Введение в Kubernetes: Зачем это нужно?

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

Причем, как отмечает автор, имя Kubernetes символично. Как штурман направляет корабль, так Kubernetes направляет ваше приложение, оставляя за вами только ключевые решения.

---

Почему Kubernetes стал таким популярным?

Развитие микросервисов и контейнеров изменило весь подход к разработке ПО. Если раньше приложения представляли собой большие монолитные системы, которые было сложно масштабировать и управлять, то теперь мы работаем с десятками и сотнями микросервисов. Kubernetes автоматизирует их управление, делая развертывание и масштабирование микросервисов тривиальной задачей. Автор книги подчеркивает: то, что раньше было сложно, с Kubernetes стало простым и очевидным.

---

Как Kubernetes решает повседневные задачи?

Читая книгу, я понял: Kubernetes — это не просто система для развертывания приложений. Это целая экосистема, которая позволяет автоматически управлять масштабированием, следить за здоровьем приложения и даже восстанавливаться после сбоев. Если ваше приложение упало — Kubernetes сам перезапустит его. А если произошел сбой оборудования, Kubernetes перенесет работу на здоровые узлы. Все это экономит время и нервы.

---

Основные компоненты Kubernetes

Автор подробно объясняет архитектуру Kubernetes, разделяя её на две главные плоскости: Control Plane и Workload Plane. Control Plane управляет состоянием всего кластера, а Workload Plane — это место, где запускаются приложения. Все выглядит логично, и благодаря иллюстрациям с каждым компонентом становится легче разобраться.

---

Личный опыт

Для меня этот материал стал отличным введением в тему. Книга Kubernetes in Action помогает понять не только теоретические основы, но и показывает, как Kubernetes действительно работает на практике. А самое главное — автор делает это легко и доступно, с примерами и наглядными пояснениями. Если вы хотите погрузиться в мир Kubernetes — это идеальная отправная точка.

От себя же я составил Mind Map первых двух частей, которым хотел бы поделиться в этом посте (пока что ссылкой на dropbox)

- https://www.dropbox.com/scl/fi/9fv5og1cchp44kofi9h0p/Kubernetes-in-Action-till-1.3.pdf?rlkey=vus4tw7vsrqf15naerns2x12v&st=6miusxfn&dl=0

Обзор следующих частей опубликую очень скоро🛥

SubStack: https://open.substack.com/pub/beops/p/kubernetes-in-action-2nd-edition?r=4g03ic&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Всем привет! 🎉

В закрепe: ссылки на свои публичные профили, чтобы вам было легче следить за обновлениями.

👉 BeOps Substack: https://beops.substack.com/
👉 TalkOps Apple Podcast: https://podcasts.apple.com/us/podcast/talkops/id1771206180
👉 BeOps Linkedin: https://www.linkedin.com/in/be-ops-54062132b/
👉 Medium: https://medium.com/@beops.it

Собеседование в Yandex Cloud: Консоль и траблшутинг

Хочу поделиться впечатлениями о втором собеседовании в Yandex Cloud, которое я недавно прошел. Эта секция называлась “Консоль и траблшутинг” и была посвящена навыкам работы в командной строке, пониманию операционных систем и способам диагностики различных проблем. Интересный момент — секция была без кодинга, и мне не пришлось сидеть и писать питон.

Интервьюер оказался настоящим ветераном — 12 лет работы в Яндексе, и общение сразу настроилось на легкую волну. Как и на первом этапе, все прошло в приятной атмосфере, говорили на “русско-айтишном”. Начали с привычного SSH-коннекта на яндексовскую машину, после чего я приступил к первому заданию.


Парсинг логов Nginx
Первое задание выглядело знакомо: нужно было распарсить Nginx логи. Довольно стандартная задача: нужно было посчитать все успешные (код ответа 200) и неуспешные ответы. К слову, это была уже третья такая задача за последние полгода.

Я использовал grep (https://man7.org/linux/man-pages/man1/grep.1.html) с регулярными выражениями, чтобы подсчитать успешные ответы:
grep ' HTTP/[0-9.]* 200 ' access.log | wc -l

Для неуспешных запросов я воспользовалася инверсией с grep -v, хотя еще предложил просто отнять успешные запросы от общего числа строк. Улыбнулись и поехали дальше.

Затем нужно было найти самые частые URL в логе. Мой любимый инструмент для таких задач — awk (https://linux.die.net/man/1/awk). В паттернизированном логе легко можно сосчитать когда появляется путь (типа /authenticate или /set/fflzuns), Подсчитать количество повторений каждого уникального URL (uniq -c), отсортировать его и вывести например 3 самых частых пути
awk '{print $6}' access.log | sort | uniq -c | sort -nr | tail -n 3

Определение типа системы
Следующий вопрос был интереснее: мне нужно было определить, виртуальная машина это, физическая или контейнер. Начал я с проверки файла /proc/1/cgroup, который иногда содержит информацию о контейнеризации, но файл оказался пустым. Тогда я использовал hostnamectl (https://man7.org/linux/man-pages/man1/hostnamectl.1.html), и вывод показал, что это виртуалка. Вывод выглядел примерно так:

 Static hostname: ixx
       Icon name: computer-vm
         Chassis: vm
  Virtualization: xen

Мы дальше исследовали какие процессоры стоят на даной машине и я использовал lscpu (https://man7.org/linux/man-pages/man1/lscpu.1.html).

Диагностика производительности
Дальше по накатанной был разговор про производительность системы (top/atop/laod averages/free/vmstat), процессы (ps -ef) и виды процессов. Я не смог развернуто ответить про статус процессов (Zombie, Sleep, Uninterrupted sleep, etc.) но думаю, что однажды я пойму эту концепцию до конца.
Найдя огромные load average values и только лишь один процесс который отжирает половину ядра (потому что top показывает процент на ядро, а не на все ядра) мне пришлось ответить на кажущийся простым вопрос - так что же нагружает систему. Я предположил что это какие то интенсивные IO операции и мы макнулись в прекрасный мир iostat (https://linux.die.net/man/1/iostat). Тула предназначенная для мониторинга статистики ввода-вывода (I/O) и загрузки процессоров (CPU) в Unix-подобных операционных системах. С ее помощью я смог понять что на сервере огромный %iowait, то есть процент времени CPU, когда он ожидал завершения операций ввода-вывода.


Финал: Исследование неизвестного сервиса
Финальная задача была исследовать неизвестный сервис (назовем его mi-service), который занимался операциями записи и чтения на диск. Я использовал systemctl для проверки статуса службы, но это не дало результата, поэтому я переключился на анализ логов в /var/log/mi-service. Именно там я нашел нужную информацию о работе демона (ну вы поняли) и выяснил, какие порты он использует, с помощью netstat -tuln (https://linux.die.net/man/8/netstat).

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

Оптимизация использования ConfigMap для NGINX в Kubernetes

Недавно я столкнулся с проблемой в одном из своих Kubernetes проектов, где nginx.conf в подах не обновлялся после сборки и деплоя Docker-образа, несмотря на изменения в конфигурацию. Проблема оказалась в том, что Kubernetes использовал ConfigMap для управления конфигурацией NGINX, а конфигурация в Docker-образе просто игнорировалась.

Решение проблемы и оптимизация процесса навели на размышления о том, как правильно управлять конфигурациями в Kubernetes и Docker. В этом посте я расскажу, как убрать избыточные шаги в Dockerfile и правильно работать с конфигурацией через ConfigMap.

---

Почему ConfigMap важен?

Прежде чем мы углубимся в изменения Dockerfile, давайте разберемся, зачем вообще нужен ConfigMap. Kubernetes использует ConfigMap для хранения и управления конфигурациями контейнеров. Это позволяет обновлять конфигурацию приложений без необходимости пересобирать Docker-образы и перезапускать все приложение целиком. Это особенно удобно в ситуациях, когда конфигурация может меняться в зависимости от среды (например, dev, staging, production), а сам код остается неизменным.

Проблема: Зачем копировать nginx.conf в Docker, если есть ConfigMap?

Изначально мой Dockerfile копировал nginx.conf в образ:

# Копирование конфигурационного файла nginx.conf
COPY nginx/nginx.conf /etc/nginx/nginx.conf

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

Решение: Удаление лишнего копирования из Dockerfile

Чтобы избавиться от дублирования и оптимизировать процесс сборки, я обновил Dockerfile, удалив строку, которая копирует nginx.conf. Теперь конфигурация управляется только через Kubernetes.

Вот как выглядит финальный Dockerfile после исправлений:

FROM nginx:1.21.6

# Удаляем ненужные конфигурации, которые могут вызвать конфликты
RUN rm -f /etc/nginx/conf.d/* /etc/nginx/snippets/*

# Обеспечиваем наличие каталога для SSL-сертификатов
RUN mkdir -p /etc/nginx/ssl && chmod -R 755 /etc/nginx

# Копируем только необходимые HTML-файлы для нашего приложения
COPY html/index.html /usr/share/nginx/html/index.html
COPY html/index2.html /usr/share/nginx/html/index2.html

# Устанавливаем права на выполнение для точки входа, если это необходимо
RUN chmod +x /docker-entrypoint.sh

Почему это решение лучше?

1. Избежание дублирования конфига. Теперь конфигурация NGINX управляется исключительно через ConfigMap. Это позволяет обновлять конфигурацию без пересборки Docker-образа.

2. Упрощение CI/CD-процессов. Теперь процесс деплоя становится более гибким, так как для внесения изменений в конфигурацию NGINX не требуется заново собирать образ. Достаточно обновить ConfigMap и перезапустить поды.

3. Поддержка среды без изменения кода. ConfigMap позволяет легко адаптировать конфигурацию под разные среды (например, использовать одну конфигурацию для development и другую для production) без необходимости изменения Docker-образа.

Как обновить ConfigMap и перезапустить поды?

После внесения изменений в конфигурацию NGINX, необходимо обновить ConfigMap:

kubectl delete configmap nginx-config
kubectl create configmap nginx-config --from-file=nginx/nginx.conf

После этого достаточно перезапустить деплоймент:

kubectl rollout restart deployment nginx-deployment


Теперь NGINX будет использовать обновленную конфигурацию из ConfigMap.

---

Личный опыт

Эта ситуация показала мне, как важно избегать дублирования конфигурации между Docker и Kubernetes. Благодаря такому подходу удается упростить процесс обновления конфигурации и сделать деплой более гибким. Если в вашем проекте активно используется Kubernetes, стоит обратить внимание на использование ConfigMap для управления конфигурациями, а не встраивать их в Docker-образы.

Надеюсь, этот пост был полезен для тех, кто работает с Docker и Kubernetes и стремится оптимизировать свои CI/CD процессы.

Книга Kubernetes in Action (2nd edition by Marko Lukša, Kevin Conner) - продолжаем знакомиться с книгой.

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

📦 Что такое контейнеры и зачем они нужны в Kubernetes?

Контейнеры стали основой современных технологий разработки, и Kubernetes — это именно та система, которая максимально эффективно управляет приложениями в контейнерах. Однако прежде чем начать работать с Kubernetes, важно понять, что такое контейнеры и почему они так важны. Автор разбирает основные концепции контейнеров, сравнивает их с виртуальными машинами и объясняет, как Docker стал основным инструментом для их создания и управления.

🤔 Зачем нужны контейнеры?

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

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

🔮 Контейнеры vs Виртуалки: в чем разница?

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

💪 Отмечаем преимущества:

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

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

🐧 Важные технологии Linux, которые делают контейнеры возможными

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

Контейнеры существуют благодаря функциям ядра Linux. Основные технологии, которые обеспечивают работу контейнеров, включают:

- Namespaces: Эта функция позволяет каждому процессу видеть только свою собственную версию файлов, процессов и сетевых интерфейсов. Благодаря этому контейнеры изолированы друг от друга. Какие бывают типы namespaces? Вот тут я был сильно удивлен.
- Mount namespace (mnt): Отвечает за изоляцию точек монтирования файловых систем. Процесс, работающий в отдельном mount namespace, видит только те файловые системы, которые смонтированы внутри этого пространства имен. Это означает, что контейнеры могут иметь свои собственные файловые структуры, даже если они используют один и тот же хост.
- Process ID namespace (pid): Изолирует идентификаторы процессов. Каждый контейнер имеет свой собственный набор PID, что позволяет избежать пересечения с процессами других контейнеров или хоста. Процессы внутри контейнера видят только те процессы, которые принадлежат этому контейнеру, что повышает безопасность и управляемость.
- Network namespace (net): Изолирует сетевые интерфейсы, IP-адреса, порты и сетевые стеки. Это позволяет каждому контейнеру иметь свой собственный виртуальный сетевой интерфейс, а также выделенные IP-адреса и маршруты. Благодаря network namespaces контейнеры могут взаимодействовать с сетью так, как будто они работают на разных физических машинах.
- Inter-process Communication namespace (ipc): Изолирует механизмы межпроцессного взаимодействия, такие как очереди сообщений и разделяемая память. Это помогает избежать утечек данных и нежелательного взаимодействия между процессами разных контейнеров.
- User namespace (user): Позволяет контейнерам иметь собственные пользовательские и групповые идентификаторы. Это важно для обеспечения безопасности, так как процессы могут работать от имени root внутри контейнера, но быть обычными пользователями на хосте.
- UTS namespace: Отвечает за изоляцию имени хоста и доменного имени системы. Это дает контейнеру возможность иметь собственное имя хоста, создавая впечатление, что он работает на отдельной машине.
- Time namespace: Позволяет контейнеру иметь собственные настройки системного времени, что может быть полезно для тестирования и других специфических сценариев.
- Cgroups (Control Groups) - это механизм в ядре Linux, который позволяет ограничивать, отслеживать и изолировать использование ресурсов (таких как процессор, память, дисковый ввод-вывод и сеть) для каждого процесса или группы процессов. Cgroups особенно важны для контейнеров, так как они обеспечивают разделение ресурсов и предотвращают ситуации, когда один контейнер потребляет все доступные ресурсы системы. Вот как Cgroups управляют основными ресурсами:
- Ограничение использования процессора: Cgroups позволяют ограничить использование процессорного времени контейнером. Это может быть реализовано двумя способами:
- cpusets: позволяет выделить конкретные ядра процессора для использования контейнером.
- CPU shares: распределение процессорного времени между контейнерами на основе относительных весов. Например, если контейнеру A назначено 1024 «доли» CPU, а контейнеру B — 512, то A получит в два раза больше процессорного времени, чем B.
- Ограничение памяти: Cgroups позволяют задавать жесткие лимиты на использование оперативной памяти контейнером. Если контейнер превысит лимит, то Linux может начать «вытеснять» данные из памяти в swap (если он разрешен) или даже завершить контейнер для освобождения памяти. Например, можно установить ограничение, чтобы контейнер использовал не более 1 ГБ памяти.
- Ограничение сетевых ресурсов: Позволяет ограничивать использование сети контейнером. Это может быть полезно для предотвращения перегрузки сетевого интерфейса одним контейнером, если несколько контейнеров работают на одном сервере.
- Ограничение дискового ввода-вывода: Cgroups могут ограничивать скорость операций чтения и записи на диск для каждого контейнера. Это предотвращает ситуации, когда один контейнер может замедлить систему, выполняя интенсивные операции ввода-вывода.

🐳 Docker: Как он упростил работу с контейнерами

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

- Images - это то, что содержит приложение и все его зависимости. Docker позволяет создавать образы, которые могут запускаться на любой системе с установленным Docker.
- Registries (e.g. Docker Hub) — это публичный репозиторий для хранения и распространения контейнерных образов.

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

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

🔐 Безопасность и изоляция контейнеров (Cgroups и неймспейсы были не всё!)

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

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

⚓️ Как Kubernetes управляет контейнерами?

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

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

❓Добавлю FAQ раздел (для TL;DR публики)

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

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

3. Как Docker изолирует контейнеры с помощью ядра Linux? Docker использует функции ядра Linux, такие как namespaces и cgroups, чтобы изолировать процессы и ресурсы для каждого контейнера.

4. Какие риски связаны с контейнерами? Главный риск — это общая операционная система для всех контейнеров. Если в ней есть уязвимость, один контейнер может потенциально повлиять на другие.

5. Как Kubernetes управляет контейнерами? Kubernetes автоматизирует развертывание, управление и масштабирование контейнеров, что делает управление большими системами с множеством микросервисов значительно проще.

Плюс, по классике, mind map 1-3 частей этой великолепной книги тут:

- https://www.dropbox.com/scl/fi/afeuq65sb7wxc2mzvpgud/Kubernetes-in-Action-till-3.pdf?rlkey=2f88qx4he5880b8vb594uv4h4&st=ltge2a9u&dl=0

Опять этот git…Интересный проект на кистартере: Карточная колода с командами Git

Девченка из Молдовы стартовала интересный проект на Kickstarter — .dot, Dev Cheatsheet: Git. Это карточная колода, созданная для помощи разработчикам (особенно джунам) в изучении команд Git. Основная цель — сделать процесс обучения легким и увлекательным.

Что это за проект?

.dot, Dev Cheatsheet: Git — это набор из 56 карточек, каждая из которых содержит полезные команды Git, советы и минималистичный дизайн, чтобы помочь освоить этот инструмент. Основные функции Git довольно просты, но он так же может быть сложным и громоздким если мы начнем пользоваться всем функционалом. Кароче, с удобными визуальными подсказками обучение будет точно проще.

Что входит в набор?

- 16 карт с командами Git — карты с описаниями основных команд Git и иллюстрациями для быстрой ссылки и легкого запоминания.
- 2 Джокера — включают основные сведения о Git и GitHub.
- 2 дополнительных карты с паттерном — двусторонние карты с дизайном, который соответствует задней стороне колоды.
- 36 стандартных игровых карт — карты с командами Git, их определениями и примерами использования.

Почему стоит поддержать этот проект?

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

Цена и сроки

Начальная цена на Kickstarter составляет 20 евро. Оплата будет списана только в случае успешного завершения кампании, а доставка начнётся в декабре 2024 года.

Перейти на страницу проекта на Kickstarter