Обновить
325.19

DevOps *

Методология разработки программного обеспечения

Сначала показывать
Порог рейтинга

Запустили Yandex Monium — observability‑платформу собственной разработки

Сегодня мы открываем доступ к Monium — платформе для мониторинга и анализа работы IТ‑систем. Новое решение собирает и анализирует большое количество телеметрических данных, в том числе логов, трейсов и метрик в едином интерфейсе, а также позволяет визуализировать их в виде дашбордов. С помощью Monium можно следить за работой сервисов, приложений, а также ИИ‑агентов — независимо от того, где они находятся: в облаке или на ваших собственных серверах (on‑premises).

Изначально observability‑платформа была разработана командой Yandex Infrastructure для обеспечения стабильной работы внутренних сервисов компании. Сейчас с Monium ежедневно работают 16 тысяч сотрудников Яндекса, платформа обрабатывает 50 гигабайт логов в секунду. При возникновении проблем ответственным дежурным отправляются автоматические уведомления через различные каналы: мессенджеры, почту, звонки и другие системы.

Monium использует современные механизмы аутентификации и авторизации, а данные о пользователях на платформе шифруются. Платформа соответствует требованиям международных и российских стандартов безопасности, в том числе ISO, PCI DSS и ГОСТ Р 57580.

Yandex Monium находится в общем доступе — зайти и оценить фичи платформы можно из облачной консоли.

Теги:
+12
Комментарии0

Как сейчас живется DevOps в разных компаниях и что будет дальше? Обсудили в новом выпуске подкаста МТС True Tech Talks 🎧

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

В новом выпуске к нам в гости заглянул Антон Егорушков — DevOps-эксперт и автор канала сыча. Вместе с Алексеем Костюковым, DevOps Lead в MWS, и Ариной Зайцевой, Senior DevOps в MWS, поговорили про то, как все меняется в профессии сейчас и что будет в будущем.

Обсудили:

  • что мотивирует в работе и профессии,

  • использование ИИ в рабочих задачах, 

  • варианты реализации IaC и EaC,

  • как лучше размещать инфраструктуру: on-prem, hybrid, one-cloud или multi-cloud,

  • каких изменений в DevOPS ожидать в ближайшие пару лет.

Смотрите и слушайте на удобной площадке: в VK Видео или на YouTube

Если было интересно — вступайте в сообщество МТС True Tech, чтобы быть в курсе лучших практик в ИТ.

Теги:
+4
Комментарии0

Прошу помощи. Не могу найти документацию на плату. Купил когда-то на а**-э*****сс, но к ней не было в комплекте вообще ничего. За время поисков удалось найти только два фрагмента схемы. Мб есть у кого такая....

Теги:
+3
Комментарии11

DevSecOps: как встроить безопасность в разработку и не тормозить релизы

DevSecOps — это подход, при котором безопасность перестает быть отдельным этапом перед релизом и становится частью всего жизненного цикла продукта. Проверки уязвимостей, контроль зависимостей и анализ конфигураций встраиваются прямо в CI/CD-пайплайн — команда получает обратную связь сразу, а не после деплоя в продакшн.

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

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

Теги:
+2
Комментарии0

Где хранить код и как настроить CI/CD, если GitLab CE уже не хватает

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

У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:

  • Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.

  • Обсудим, как сократить нагрузку на команды за счёт managed-подхода.

  • Проведём живое демо от коммита в консоли до артефакта в registry.

Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.

Теги:
+2
Комментарии0

Всем привет! Сделал Тетрис, в который можно играть в терминале. Получилось вполне залипательно)

Tetris
Tetris

Что умеет:

  • Все 7 фигур с wall kick при повороте

  • Превью следующей фигуры

  • Очки, линии, уровень

  • Скорость растёт с уровнем

  • Рекорд за сессию

  • Пауза, рестарт на ходу, экран game over

  • Центрируется в окне терминала

Видео геймплея
GitHub

Установка:

curl -sSL https://raw.githubusercontent.com/oakulikov/tetris/main/install.sh | bash

На Windows: открыть WSL/Ubuntu терминал и выполнить ту же команду.
Потом просто tetris.

Теги:
+7
Комментарии5

Redis упал.

Периодически Redis падает по OOM.

Интересно послушать разные мнение , на что стоит обратить внимание. Есть решение , почему происходит OOM .

Буду очень признателен комментарию . 🤝

Теги:
0
Комментарии8

Ребята, в свете блокировок Telegram я накидал bash-скрипт который сделает всю магию и поднимет вам прокси за пару минут. На выходе получите адрес прокси и сразу им поделиться с друзьями... 

Можете ставить на свои VPS-ки одной командой: 

curl -sSL https://raw.githubusercontent.com/itcaat/mtproto-installer/main/install.sh | bash

Исходники тут: https://github.com/itcaat/mtproto-installer

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
+7
Комментарии0

Статический анализ и ASOC: нулевая терпимость к ошибкам в проекте

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

Что делать в такой ситуации? Самый эффективный путь — не дать дефекту шанса появиться в коде. Именно эту задачу решает политика нулевой терпимости к ошибкам.

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

В статье обсудим, что такое политика нулевой терпимости и то, как статический анализ и ASOC помогут её достичь.

Теги:
+4
Комментарии0

Только что я релизнул cli-stash v0.2.9. Теперь можно редактировать сохраненную команду.

cli-stash - tui-тулза для добавления терминальных команд в избранное, с возможностью переноса из истории

Кейсы использования такие:

  1. Вы хотите параметр заменить на какое то ключевое слово. Например, я хочу в избранное добавить команду dig для определения NS серверов, которые отдает нам 1.1.1.1. Я не хочу видеть захаркорженные значения. И чтобы было красиво меняю их просто на ключевые слова. Это дает больше эстетического удовольствия при использовании команды - не более.
    Ну и в будущем я подвезу автосинк с шарингом на команду, так что может быть полезно.

  2. Да просто надо поменять команду - почему бы не дать такую возможность =)

Пример редактирования
Пример редактирования

Кстати, тут вопрошали сколько 🌟 наберет тулза в github - пока всего 37. Ну а что это за инструмент и чем он может быть полезен можно подробнее прочитать в предыдущем посте.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии0

Ребята, я сегодня релизнул cli-stash. Это TUI-утилита на Go + Bubble Tea для сохранения shell-команд в "избранном".

Пример использования cli-stash
Пример использования cli-stash

Она решает простую боль: сложные команды (docker, kubectl, ffmpeg) постоянно забываются, а копаться в history каждый раз это страдание.

Что умеет:

  • Сохраняет ваши команды в избранном

  • Возможность добавить из истории шелла

  • Нечеткий поиск

  • Сортировка по частоте использования

И самое крутое, что команда вставляется прямо в терминал. Таким образом вам не надо ничего копипастить: нашел → выбрал → enter → команда уже в cli.

# Установка в Linux
go install github.com/itcaat/cli-stash@latest

# Сборка из исходников
git clone https://github.com/itcaat/cli-stash.git
cd cli-stash
go build -o cli-stash .
sudo mv cli-stash /usr/local/bin/

В macOS поставить изян brew install itcaat/tap/cli-stash

Исходники и инструкция по использованию есть на github.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 9: ↑8 и ↓1+8
Комментарии10

Сегодня хочу поднять тему, которую редко обсуждают отдельно, но без неё Docker просто не работал бы так стабильно и предсказуемо - манифесты образов.

Периодически в разные частях документации или статьях про Docker вы будете встречать "манифесты". Обычно это звучит как что-то второстепенное: мол, есть какая-то мета-информация, по которой Docker собирает образ из слоёв.

Но на деле это одна из ключевых деталей, которая отвечает за то, что контейнеры:

  • воспроизводимы

  • одинаковые на разных машинах

  • и не превращаются в "ну у меня работало".

Я попытаюсь все описать максимально просто.

Docker Manifest - это JSON-документ, который описывает образ. Можно представить его как схему или инструкцию, по которой Docker понимает:

  • какие слои относятся к образу

  • какие контрольные суммы должны быть у каждого слоя

  • в каком порядке их нужно использовать

  • для какой ОС и архитектуры этот образ подходит

И важный момент: когда ты делаешь docker pull, Docker сначала получает манифест, а уже потом начинает скачивать слои.

Как посмотреть манифест самому: docker manifest inspect nginx:latest.

Тут можно заметить, что один тег (nginx:latest) может ссылаться сразу на несколько вариантов образа - например под amd64 и arm64. Это как раз история про multi-arch. Иногда под словом manifest имеют в виду не сам образ, а manifest list (index). Это как меню: Docker смотрит на твою платформу и выбирает подходящий вариант (amd64/arm64).

Каждый слой Docker-образа имеет SHA256-хеш, который вычисляется из его содержимого.

Логика максимально простая:

  • поменялся файл

  • поменялось содержимое

  • поменялся хеш

  • значит получился другой слой

По сути это очень похоже на философию Git: всё завязано на содержимое, а не на "имя файла".

Docker Registry использует Content Addressable Storage - то есть хранит и раздаёт данные не по названию, а по их хешам.

Что происходит при push / pull?

Если упростить до понятной схемы, то процесс примерно такой:

  • клиент сначала отправляет/получает манифест

  • registry проверяет хеши и наличие слоёв

  • передаются только те слои, которых ещё нет

  • каждый слой проверяется по SHA256

То есть никакой лишней передачи данных и никаких "примерно совпало".

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

  • Безопасность - слой нельзя незаметно подменить

  • Экономия места - одинаковые слои не хранятся по сто раз

  • Целостность - скачанное гарантированно равно загруженному

  • Версионирование - образ это конкретная комбинация слоёв, а не “что-то похожее”

Именно поэтому условный nginx:latest на dev и на prod - это реально один и тот же образ, а не "почти такой же, но чуть другой". Ладно, давайте будем более дотошными. На самом деле нет - использовать latest плохая практика. За время пока образ приехал,- там уже могут быть разные образы.

Как минимум используйте конкретный тег, а еще лучше даже sha256 docker pull nginx@sha256:...

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии0

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

Речь про vi...😱 

Как выйти из vi? Никак. Это не редактор, это пожизненный контракт.

Я открыл vi один раз в 2009 году. С тех пор у меня один и тот же терминал, потому что я всё ещё пытаюсь выйти.

Если ты случайно запустил vi на проде — проще выкинуть сервер, чем найти правильную комбинацию клавиш.


Это тот самый редактор, который в обычной жизни можно спокойно не трогать годами… А потом ты оказываешься в air-gap, где:

  • нет vscode

  • нет nano

  • нет mc

  • иногда даже less нет и кажется, что у тебя есть только vi и судьба

И вот ты открываешь конфиг… и мозг такой: эээээ мы не умеем, всё, до свидания.

Давай разберёмся, как перестать бояться vi и научиться выживать с ним спокойно.

Почему vi вызывает ступор? Потому что он не работает как обычные редакторы. Ты нажимаешь клавиши - а текст не печатается. Пытаешься выйти - не выходит. И где-то рядом уже открывается вкладка “как выйти из vi”, но интернет… в другой реальности.

Главное, что нужно понять - в vi есть несколько режимов:

  1. Normal mode - это режим команд и перемещения. Тут ты не печатаешь текст, а управляешь редактором.

  2. Insert mode - это режим, где можно реально редактировать и вводить текст.

  3. Command mode (через :) - cохранение, выход, всякие служебные команды и тд

Минимальный набор клавиш, чтобы выжить:

  • Войти в редактирование -> i, a, o

  • Вернуться обратно в команды -> Esc

  • Сохранить файл -> :w

  • Выйти -> :q

  • Сохранить и выйти -> :wq

  • Выйти без сохранения -> :q!

Полезные команды, которые реально пригодятся:

  • удалить строку -> dd

  • вставить строку ниже -> o

  • отменить действие -> u

  • повторить последнее действие -> .

  • поиск: / и дальше текст который ищем

Пример: быстро поправить конфиг и уйти живым

vi /etc/hostname

Дальше всё по шагам:

  1. нажми i и внеси правки

  2. нажми Esc

  3. введи :wq

  4. готово - конфиг сохранён, ты победил

А если ты хочешь владеть vi как ниндзя, то вот тебе Vim Cheat Sheet https://vim.rtorr.com/

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 8: ↑7 и ↓1+7
Комментарии14

Ближайшие события

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

Наверняка знакомо ощущение: смотришь логи через tail -f, делаешь какое-то действие - рестарт сервиса, деплой, правку конфига - и потом пытаешься глазами понять, где закончился старый вывод и началось новое. Спойлер: это не всегда просто.

Для таких случаев существует крошечная, но очень полезная утилита
spacer: https://github.com/samwho/spacer

Она вставляет визуальные разделители прямо в поток вывода и отлично работает в реальном времени. Без магии, без лишних настроек - просто аккуратно отделяет "было" от "стало".

В итоге это неожиданно удобно:

  • при отладке,

  • при сопровождении сервисов,

  • при поиске изменений в логах после конкретных действий.

Отдельный плюс - минимализм. Никаких зависимостей, ничего лишнего: скачал, поставил, используешь. Именно тот случай, когда инструмент делает ровно одну вещь - и делает её хорошо.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 9: ↑8 и ↓1+8
Комментарии0

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

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

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

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

Очень рекомендую заглянуть и дать мозгу немного свободы.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 4: ↑1 и ↓30
Комментарии0

“Наши руки не для скуки” (с). Я давно хотел накидать скрипт для супер быстрой диагностики Linux. Конечно, это не замена полноценному мониторингу. Это  дополнительный инструмент, который вы можете использовать в своем арсенале чтобы упростить себе жизнь. Самое главное что он сэкономит кучу времени.

В отчете вы получите:

  • Системную информацию - версия ОС, ядро, архитектура, uptime, внешний IP

  • Аппаратные ресурсы - CPU, RAM, Swap, температура процессоров

  • Дисковое пространство - занятое место, inodes, SMART статус

  • Тест скорости дисков - скорость записи/чтения (100MB тест)

  • Сетевые интерфейсы - статус, ошибки, активные соединения

  • Тест сети - ping до шлюза, ya.ru и 8.8.8.8 (по 10 пакетов каждый), скорость интернета

  • Процессы - топ по CPU и памяти, zombie процессы

  • Системные логи - критические ошибки, OOM события, kernel warnings

  • Системные службы - проверка упавших служб

  • Безопасность - неудачные входы, активные SSH сессии

  • Docker - статус контейнеров и их ресурсы

Пример запуска (можно без sudo - но там не будет всех показателей):

curl -o ~/linux-diag-script.sh https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh
chmod +x ./linux-diag-script.sh
sudo ./linux-diag-script.sh

# Одной командой
curl https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh | sudo bash

Бонусом в скрипте встроена возможность получать Telegram уведомления и сам отчет при обнаружении проблем. Для этого надо создать бота и добавить в выполнение скрипта в cron.

  1. Найди [@BotFather](https://t.me/BotFather) в Telegram

  2. Отправь команду /newbot

  3. Следуй инструкциям и получи токен бота (например: 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)

  4. Получи Chat ID:

        - Отправь сообщение боту

        - Откройте:  https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates

        - Найди "chat":{"id": - это твой Chat ID

Теперь можешь добавить в cron (подставь свой botToken и chatId) и будешь получать уведомление в telegram если будет обнаружена какая то проблема.

# Проверка каждые 6 часов
0 */6 * * * root TELEGRAM_BOT_TOKEN="your_token" TELEGRAM_CHAT_ID="your_chat_id" /usr/local/bin/linux-diag-script.sh >/dev/null 2>&1

Актуальная версия скрипты доступна на GitHub Gist.  Вы можете модифицировать его под свои нужды, добавлять новые проверки или как то интегрировать в runbook-и.

Пишите что еще можно добавить - я добавлю.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 7: ↑3 и ↓4+1
Комментарии0

Скрытые уязвимости в CI/CD: что мы упускаем и как защитить процесс доставки

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

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

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

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

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

Защита CI/CD начинается с принципа минимальных привилегий. Каждый токен, сервисный аккаунт и ключ должен иметь строго ограниченный набор прав и короткий срок жизни. Второй шаг — контроль цепочки зависимостей: фиксация версий, проверка хэшей, собственные зеркала и регулярный аудит используемых экшенов и образов.

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

CI/CD — это не просто автоматизация, а часть поверхности атаки. Чем раньше это осознаётся, тем меньше шансов, что уязвимость проявится уже после успешного релиза.

А какие риски в своих пайплайнах вы обнаружили только со временем?

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии1

Kubernetes Zero to Hero — базовый видеокурс от «Фланта»

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

В курсе 10 коротких — до 10 минут — видео. Они рассчитаны на начинающих разработчиков с опытом в продуктовой разработке, учебных или личных проектах, где возникает потребность в Kubernetes. С нами вы:

  • поднимете локальный кластер и разберётесь в ключевых сущностях Kubernetes;

  • научитесь развёртывать приложения, пройдя путь от коммита кода в Git-репозиторий до его выката в кластер;

  • поймёте, как устроены сетевое взаимодействие внутри кластера и доступ к приложениям извне;

  • познакомитесь с werf и Helm, шаблонизацией чартов и практиками реальных проектов.

Два первых ролика уже доступны. Во вводном будут план курса и желательный для старта бэкграунд, а второй поможет поднять локальный кластер Kubernetes с помощью Minikube и получить готовое окружение для экспериментов. Смотрите на удобной вам площадке:

Каждую неделю будет выходить по два ролика — по вторникам и четвергам. Присоединяйтесь, будем вместе проходить путь от новичка до Kubernetes Hero.

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии0

Kotlin и Hyperskill: как я искал курс и что получил в итоге.

Когда я решил изучать Kotlin, ожидал, что найти хороший курс будет просто: язык популярный, используется в Android и бэкенде, вокруг много материалов. Искал менторов и упирался в людей которые знаю java и вроде как используют в работе Kotlin. Это одновременно пугало и заинтересовывало, я решил поступить как мне казалось правильным, найти готовый курс  — особенно если хочется не “смотреть видео”, а именно учиться через практику и задачи.

Я перепробовал разные форматы обучения (платные и бесплатные), поэтому в этот раз подход был простой: найти платформу, где есть структурированная программа и много практики. В итоге я добрался до Hyperskill (hyperskill.org). Это не реклама — просто личный опыт, кому-то он может сэкономить время.

Как я пришёл к ресурсу.

Изначально искал курсы по Kotlin на привычных площадках. На Stepik в тот момент не нашёл того, что мне подходило по структуре (возможно, сейчас ситуация лучше). Видео-курсы на крупных “известных сайтах” сознательно не рассматривал: мне удобнее формат “прочитал → сделал → получил проверку”.

Дальше — обычный путь через поисковик и сравнение нескольких платформ. Из того, что выглядело цельно и практично, больше всего зацепил Hyperskill. Отдельно сыграло роль то, что платформа связана с JetBra…. (то есть ребята явно понимают, как устроена экосистема вокруг Kotlin и IDE).После регистрации быстро становится понятно: платформа активно ведёт к подписке.Раньше в сети встречались статьи про возможность оформить бесплатную подписку на полгода, но это устаревшая информация — сейчас такой опции нет (по крайней мере, в том виде, в каком её описывают старые гайды).

При этом у Hyperskill есть бесплатный режим, и я проходил курс именно так.

Что я проходил: Introduction to Kotlin.

На платформе несколько треков по Kotlin, я начал с Introduction to Kotlin. По ощущениям, это “введение с практикой”:

  • около 9 учебных проектов

  • порядка 60–70 тем

  • внутри тем — задачи/тренажёры с автоматической проверкой

В целом структура понравилась: материал подаётся дозировано, и почти сразу закрепляется практикой. Похожая на Степик.

Система “кристаллов” и лимиты.

Самая спорная часть бесплатного режима — ограничения на попытки.

У Hyperskill есть внутренняя валюта (“кристаллы”): ошибаешься в заданиях — кристаллы списываются. Когда кристаллы заканчиваются, обучение может блокироваться на 12–24 часа. Да, кристаллы можно зарабатывать активностью и выполнением некоторых задач, но при активном обучении и регулярных ошибках (что нормально) этого может не хватать.

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

Проекты: что внутри и зачем это полезно.

Сильная сторона Hyperskill — проекты. Они не выглядят как “игрушки ради галочки”, а позволяют постепенно потрогать основные конструкции языка.

Из того, что запомнилось:

  • “Сапёр”

  • “Крестики-нолики”

  • “Чат-бот”

  • “Кофемашина”

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

Минус: часть проектов закрыта платной подпиской, и это немного обидно — именно проекты дают максимальную пользу и ощущение прогресса.

Проверка решений: не всегда понятно, почему “не принято”

Ещё один недостаток — качество обратной связи в тестах. Иногда тесты “падают” так, что ты видишь только факт ошибки, но не понимаешь причину: что именно ожидалось, на каком кейсе сломалось, где расхождение.Часть проектов проверяется через IntelliJ IDEA, и здесь иногда всплывают технические нюансы: несовпадение версий, необходимость обновить IDE или компилятор, странные падения на конкретном проекте.

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

Итоги:

  • бесплатный режим может раздражать лимитами на ошибки (кристаллы и блокировки)

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

  • обратная связь тестов местами недостаточно информативная

    Если готовы, то вперед!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Поиск партнёра для совместной инженерной проверки идей (не найм)

Сразу обозначу границы, чтобы не тратить время друг друга.

Я не ищу работу, не нанимаю, не продаю услуги и не собираю команду.
Интересует формат равного партнёрского взаимодействия на уровне мышления и проверки гипотез.

Контекст

Мой бэкграунд - backend / инфраструктура / системы.
Умею проектировать и собирать техническую часть, доводить до рабочего состояния, автоматизировать, поддерживать.

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

Что именно ищу

Ищу одного человека, с которым можно:

  • разбирать идеи без романтизации

  • проверять гипотезы на реализуемость и смысл

  • делать небольшие, ограниченные по времени и объёму пробы (MVP / прототип / концепт)

Речь не про «стартап мечты», а про инженерный подход к неопределённости.

Кого не ищу

  • менторов и гуру

  • инвесторов

  • людей, ожидающих «готовый проект»

  • мотивационные разговоры без действия

Формат

  • асинхронная переписка

  • созвон 45–60 минут

  • если не совпали по подходу - спокойно расходимся

Без обязательств, без разговоров про доли, без долгих ожиданий.

Почему сейчас

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

Контакт для связи: Telegram @sachconzales

Теги:
Рейтинг0
Комментарии1
1
23 ...