Здарова бандиты! 😏
Я Пико (Данила), разработчик из Москвы. В IT тусуюсь уже седьмой год, накипело-наболело, хочу (и буду) изливать сюда свою душу и мысли.
Специализируюсь на .NET (C#/F#), прогаю всё, от мобайлов и десктопов до сайтов и игрушек, руковожу командами, обучаю.
Активно вливаюсь в кибербезопасность, осваиваю функциональщину и пипл-менеджмент
Ну а там как пойдет, встречайте!💪
Я Пико (Данила), разработчик из Москвы. В IT тусуюсь уже седьмой год, накипело-наболело, хочу (и буду) изливать сюда свою душу и мысли.
Специализируюсь на .NET (C#/F#), прогаю всё, от мобайлов и десктопов до сайтов и игрушек, руковожу командами, обучаю.
Активно вливаюсь в кибербезопасность, осваиваю функциональщину и пипл-менеджмент
Ну а там как пойдет, встречайте!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1🔥1💩1💯1
Недавно удалось потрогать прекраснейший инструмент для хранения в кодовой базе визуализации графовых структур - ascii диаграммы
Без шуток, если у вас в проекте есть графы и вы испытываете необходимость в документировании различных сценариев/представлений графов - этот подход максимально удобен.
Обычно документация к сложной логике, построенной на графах, располагается где-то вне кодовой базы, а в самом коде ссылок на эту документацию, как правило, не найти, вот и сидишь, ковыряешь, пытаешься разобраться.
Использование инструментария для рисования ASII диаграмм - это полноценный Docs-as-Code, который прост в генерации и лёгок в поддержке, а самое главное - читабелен для других коллег-разработчиков. Его можно использовать, например, для UML-диаграмм сложной ветвистой логики, или изображения диаграмм взаимодействия различных компонентов.
Я использовал этот подход для документирования unit-тестов, где рисовал то, как устроен граф, над каждым тестовым сценарием. Получилась годно.
Полезные ссылки: ASCIIFlow
#tools
👾 PICO
Без шуток, если у вас в проекте есть графы и вы испытываете необходимость в документировании различных сценариев/представлений графов - этот подход максимально удобен.
Обычно документация к сложной логике, построенной на графах, располагается где-то вне кодовой базы, а в самом коде ссылок на эту документацию, как правило, не найти, вот и сидишь, ковыряешь, пытаешься разобраться.
Использование инструментария для рисования ASII диаграмм - это полноценный Docs-as-Code, который прост в генерации и лёгок в поддержке, а самое главное - читабелен для других коллег-разработчиков. Его можно использовать, например, для UML-диаграмм сложной ветвистой логики, или изображения диаграмм взаимодействия различных компонентов.
Я использовал этот подход для документирования unit-тестов, где рисовал то, как устроен граф, над каждым тестовым сценарием. Получилась годно.
Полезные ссылки: ASCIIFlow
#tools
👾 PICO
👍1💩1
Я стартую уже второй проект с использованием этого подхода и не могу нарадоваться, как легко становится вносить в код изменения и не бояться за фатальные баги.
Сам подход состоит из нескольких шагов:
1. Описываем логику приложения на русском языке (с использованием нотации gherkin), наполняя пользовательские сценарии. Это происходит в отдельных .feature-файлах в директориях для тестов.
2. На каждый шаг сценария делаем его репрезентацию в коде. То есть говорим приложению, как транслировать русский текст сценария в конкретный набор исполняемого кода
3. Запускаем тест. Profit
Конечно, есть свои нюансы, но код, получающийся при проектировании по ATDD получается гораздо качественней, а "встроенная" документация по пользовательским сценариям напрямую из тестов позволит гораздо проще осознать логику приложения новым людям на проекте.
Ну и плюс ко всему - основные пользовательские сценарии автоматически становятся покрыты тестами, что обеспечивает приложению стабильность в рефакторинге и дальнейшим изменениям.
Не пренебрегайте TDD подходами, они реально рулят, когда речь заходит о создании качественного долгоживущего ПО.
Полезные ссылки: SpecFlow для .NET
👾 PICO
Please open Telegram to view this post
VIEW IN TELEGRAM
💩1
👊 Битва пет-проектов
Мы вместе с Хабр.Карьерой запускаем уникальное мероприятие - онлайн-битву IT-команд!
💎 Команда Sapphire - полнофункциональная команда с составом 14 человек.
Представители энтерпрайза, полноценного пайплайна разработки с аналитиками и тестировщиками, современным стеком технологий и разделением репозиториев на фронт/бек.
♨️ Команда Garnet - лимитированная с составом 8 человек.
Представители стартапа со специально подобранным стеком для ускоренной разработки, одним репозиторием на фронт и бек, полагающаяся исключительно на автоматизированные тесты
Перед обеими командами стоит одна задача: разработать продукт для командного взаимодействия и ведения проектов.
То как каждая команда подойдёт к этому заданию и что в итоге получится - узнаем совсем скоро!
Нас ждут также:
- Воркшопы по разработке и командные прямые эфиры
- Q&A сессии
- Стендапы и демо
И главная фишка: Все публично! Можно будет в онлайн-режиме следить за внутрикомандным взаимодействием в чатах самих команд и за ходом проектов в командных репозиториях.
От себя надеюсь, что мероприятие окажется в первую очередь полезным, ну, а там поглядим, может быть мы реально годные продукты забацаем :)
Старт уже на следующей неделе!
Ссылки: Лендинг битвы пет-проектов
👾 PICO
Мы вместе с Хабр.Карьерой запускаем уникальное мероприятие - онлайн-битву IT-команд!
💎 Команда Sapphire - полнофункциональная команда с составом 14 человек.
Представители энтерпрайза, полноценного пайплайна разработки с аналитиками и тестировщиками, современным стеком технологий и разделением репозиториев на фронт/бек.
♨️ Команда Garnet - лимитированная с составом 8 человек.
Представители стартапа со специально подобранным стеком для ускоренной разработки, одним репозиторием на фронт и бек, полагающаяся исключительно на автоматизированные тесты
Перед обеими командами стоит одна задача: разработать продукт для командного взаимодействия и ведения проектов.
То как каждая команда подойдёт к этому заданию и что в итоге получится - узнаем совсем скоро!
Нас ждут также:
- Воркшопы по разработке и командные прямые эфиры
- Q&A сессии
- Стендапы и демо
И главная фишка: Все публично! Можно будет в онлайн-режиме следить за внутрикомандным взаимодействием в чатах самих команд и за ходом проектов в командных репозиториях.
От себя надеюсь, что мероприятие окажется в первую очередь полезным, ну, а там поглядим, может быть мы реально годные продукты забацаем :)
Старт уже на следующей неделе!
Ссылки: Лендинг битвы пет-проектов
👾 PICO
🔥2💯1
📦 Kamal Deploy
Как же я долго ждал этого инструмента... и как жаль, что он существует уже несколько месяцев, а я узнал о нем только сейчас.
Перед стартом битвы пет-проектов стояла задача настроить быстрое и безболезненное развертывание веб-приложения на различные окружения. Ну я чето мурыжился, кубер настраивать очень не хочется (да и есть ограничения для него на инфраструктуре), ну, думаю, докер наше все, пошел уже настраивать docker-compose и тут...
Выходит пост у Феди Борщева про Kamal (бывш. mrsk). Ну я прочитал, думаю, прикольная тема, надо попробовать. И какой же это кайфовый инструмент!
Все что нужно на конечной машине - это поднятый docker. А на своей тачке (или внутри какого-нибудь пайплайна сборки) нужно просто поставить докер и утилиту kamal. Все, никаких зависимостей и громоздких инструментов.
Публикация проекта на окружения происходит с помощью трёх команд в первый раз и в одну во все последующие разы:
- kamal init для регистрации проекта и создания конфигов
- kamal setup для первоначального развертывания
- kamal deploy для всех последующих
Kamal просто подключается к нужной тачке, прописанной в конфиге, через ssh и сам собирает (с помощью Dockerfile) и деплоит ваше приложение, в добавок ко всему поднимает над ним reverse-proxy и делает базовый health-check. Он поддерживает откат релизов а также взаимодействует с различными registry для сохранения версий релизов.
Тупа огонь для скоростной настройки деплоя 🔥
Ссылки:
- Официальный сайт инструмента Kamal
- Настройка деплоя сервиса с помощью Kamal
#tools
👾 PICO
Как же я долго ждал этого инструмента... и как жаль, что он существует уже несколько месяцев, а я узнал о нем только сейчас.
Перед стартом битвы пет-проектов стояла задача настроить быстрое и безболезненное развертывание веб-приложения на различные окружения. Ну я чето мурыжился, кубер настраивать очень не хочется (да и есть ограничения для него на инфраструктуре), ну, думаю, докер наше все, пошел уже настраивать docker-compose и тут...
Выходит пост у Феди Борщева про Kamal (бывш. mrsk). Ну я прочитал, думаю, прикольная тема, надо попробовать. И какой же это кайфовый инструмент!
Все что нужно на конечной машине - это поднятый docker. А на своей тачке (или внутри какого-нибудь пайплайна сборки) нужно просто поставить докер и утилиту kamal. Все, никаких зависимостей и громоздких инструментов.
Публикация проекта на окружения происходит с помощью трёх команд в первый раз и в одну во все последующие разы:
- kamal init для регистрации проекта и создания конфигов
- kamal setup для первоначального развертывания
- kamal deploy для всех последующих
Kamal просто подключается к нужной тачке, прописанной в конфиге, через ssh и сам собирает (с помощью Dockerfile) и деплоит ваше приложение, в добавок ко всему поднимает над ним reverse-proxy и делает базовый health-check. Он поддерживает откат релизов а также взаимодействует с различными registry для сохранения версий релизов.
Тупа огонь для скоростной настройки деплоя 🔥
Ссылки:
- Официальный сайт инструмента Kamal
- Настройка деплоя сервиса с помощью Kamal
#tools
👾 PICO
👍5💩1
Не нравится? Перепиши!
За последние 2 месяца, так получилось, я начал два проекта с нуля. Один с командой, второй соло. Ну и ещё в третий проект вписался, в существующую команду и с имеющимся кодом.
Как же всё-таки важна программная архитектура. Новые проекты всегда хороши тем, что перед тобой чистый лист. Естественно ты практически сразу измажешь его говном, без вариантов, но до этого момента есть время насладиться реально красивым кодом.
Что делать чтобы этот лист испачкался как можно позже? Естественно, выстраивать ограничения для самого себя. Ставь заборы там, куда идти не стоит, клади асфальт туда, куда будешь ехать. И самое главное - модульность, модульность, модульность!
Понял, что капитально накосячил на старте? Ну и выкинь модуль, перепиши нормально, под переосознанные требования, завтра скажешь себе большущее спасибо, и не только ты, но и люди, которые с тобой работают.
После реализации очередного модуля стараюсь всегда спрашивать себя: а нравится ли мне то, что получилось?
Казалось бы такой банальный вопрос, но именно он иногда заставляет взять и подойти к решению по-новой. Сделать элегантнее и лучше.
👾 PICO
За последние 2 месяца, так получилось, я начал два проекта с нуля. Один с командой, второй соло. Ну и ещё в третий проект вписался, в существующую команду и с имеющимся кодом.
Как же всё-таки важна программная архитектура. Новые проекты всегда хороши тем, что перед тобой чистый лист. Естественно ты практически сразу измажешь его говном, без вариантов, но до этого момента есть время насладиться реально красивым кодом.
Что делать чтобы этот лист испачкался как можно позже? Естественно, выстраивать ограничения для самого себя. Ставь заборы там, куда идти не стоит, клади асфальт туда, куда будешь ехать. И самое главное - модульность, модульность, модульность!
Понял, что капитально накосячил на старте? Ну и выкинь модуль, перепиши нормально, под переосознанные требования, завтра скажешь себе большущее спасибо, и не только ты, но и люди, которые с тобой работают.
После реализации очередного модуля стараюсь всегда спрашивать себя: а нравится ли мне то, что получилось?
Казалось бы такой банальный вопрос, но именно он иногда заставляет взять и подойти к решению по-новой. Сделать элегантнее и лучше.
👾 PICO
❤4💩1
Автотесты - первый помощник тимлида
Для битвы пет проектов я решил попробовать относительно новый для себя подход - ATDD, о котором я уже рассказывал. И, к удивлению для себя самого, я ни разу об этом не пожалел.
Начну, внезапно, с минусов. Это время. Да, на реализацию фичи через автотесты уходит время. Где-то в каком-то исследовании даже видел конкретную цифру, фича занимает в среднем на 16% больше времени, если разработка идет через тестирование или если на фичу тесты пишутся после реализации. По прошествии полутора недель активной работы, это действительно ощущается так. Возможно, мы тратим на это даже больше.
Но самое интересное, что... больше минусов нет.
Вот серьезно, после реализации фичи вы получаете гарантированно работающий пользовательский сценарий (а то и несколько), который точно несет полезность для конечного потребителя продукта. Нужно больше уверенности? Просто добавляйте больше сценариев, покрывайте узкие, нестандартные кейсы и ошибки в рамках фичи.
Наш процесс приемки задач состоит из одного шага - код-ревью. Код решает задачу наших пользователей потому что мы начинаем разработку с пользовательского сценария. А в том что он точно работает я убеждаюсь благодаря автотестам.
Вы только посмотрите на наш Code Coverage (скрин в шапке). Помимо очевидного покрытия кода тестами эти цифры также показывают нам, что мы не делаем лишних вещей. Все о чем говорится в сценарии должно быть покрыто тестами. И оно покрыто.
Благодаря такому подходу я, как лид команды, в рамках ревью фокусируюсь на качестве кода, на его архитектуре, на взаимодействиях между модулями, и совершенно не беру на себя ответственность контролировать качество работы написанного кода, его соответствие требуемой бизнес-логике, так как эти вещи в нашем подходе автоматизированы благодаря ATDD.
Да, мы тратим больше времени на разработку, но мы получаем невероятную экономию буквально всех ресурсов команды на тестировании и контроле качества.
Пушка-бомба, лидам настоятельно рекомендую, особенно на новых проектах🦀
👾 PICO
Для битвы пет проектов я решил попробовать относительно новый для себя подход - ATDD, о котором я уже рассказывал. И, к удивлению для себя самого, я ни разу об этом не пожалел.
Начну, внезапно, с минусов. Это время. Да, на реализацию фичи через автотесты уходит время. Где-то в каком-то исследовании даже видел конкретную цифру, фича занимает в среднем на 16% больше времени, если разработка идет через тестирование или если на фичу тесты пишутся после реализации. По прошествии полутора недель активной работы, это действительно ощущается так. Возможно, мы тратим на это даже больше.
Но самое интересное, что... больше минусов нет.
Вот серьезно, после реализации фичи вы получаете гарантированно работающий пользовательский сценарий (а то и несколько), который точно несет полезность для конечного потребителя продукта. Нужно больше уверенности? Просто добавляйте больше сценариев, покрывайте узкие, нестандартные кейсы и ошибки в рамках фичи.
Наш процесс приемки задач состоит из одного шага - код-ревью. Код решает задачу наших пользователей потому что мы начинаем разработку с пользовательского сценария. А в том что он точно работает я убеждаюсь благодаря автотестам.
Вы только посмотрите на наш Code Coverage (скрин в шапке). Помимо очевидного покрытия кода тестами эти цифры также показывают нам, что мы не делаем лишних вещей. Все о чем говорится в сценарии должно быть покрыто тестами. И оно покрыто.
Благодаря такому подходу я, как лид команды, в рамках ревью фокусируюсь на качестве кода, на его архитектуре, на взаимодействиях между модулями, и совершенно не беру на себя ответственность контролировать качество работы написанного кода, его соответствие требуемой бизнес-логике, так как эти вещи в нашем подходе автоматизированы благодаря ATDD.
Да, мы тратим больше времени на разработку, но мы получаем невероятную экономию буквально всех ресурсов команды на тестировании и контроле качества.
Пушка-бомба, лидам настоятельно рекомендую, особенно на новых проектах
👾 PICO
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🤡1
Monolith over Microservices
Да-да, я снова про битву пет-проектов. На этот раз поговорим об архитектуре.
В кругу разработчиков часто популярен холивар в отношении программных архитектур для web-сервисов, мол, что выбрать, монолит или микросервисы, а для каких задач что подходит лучше и т.д. Есть строгие приверженцы одного из подходов, есть балансирующие между, но суть споров чаще всего одна - плюсы и минусы которые тот или иной подход в себе несет. Как-то я написал развернутый ответ на SO об отличиях монолитов и микросервисов и как плавно переходить от одного к другому.
Перед стартом битвы пет-проектов я тоже столкнулся с этой дилемой. С одной стороны есть монолит - простое и верное решение с минимальными затратами, но высокими рисками "завязывания" кода. С другой - микросервисы, хайповый и популярный путь с минимумом зависимостей, но сложностью развертывания и взаимодействия между сервисами.
А что если мы постараемся взять плюсы обоих подходов?
Допустим, у нас есть веб-сервис, единый (монолитный) исполняемый файл, под которым прячутся 2-4 микросервиса.
Какие плюсы:
- Простота развертывания. Один докерфайл и больше ничего. В отличие от классических микросервисов.
- Слабая связанность. Микросервисы внутри строго отделены друг от друга. От монолита требуется только запустить их всех вместе.
- Очень быстрый переход на микросервисные рельсы, в случаях, когда это необходимо. Мы просто выносим микросервис из монолита и разворачиваем отдельно по щелчку пальца.
Минусы:
- Нужно очень хорошо продумать архитектуру решения. Так чтобы можно было и быстро микросервис отделить и обеспечивалась достаточная обобщенность настройки.
- Не все внешние библиотеки можно настроить для исполнения под такой архитектурой. Я бы даже сказал, что их достаточно мало.
Можно сказать, что это переизобретенный SOA, но ключевое отличие тут в том, что микросервис - это не модуль ПО, а полноценное приложение со своими точками входа для пользователей.
Пример подобной архитектуры можно посмотреть в нашем репозитории для битвы
👾 PICO
Да-да, я снова про битву пет-проектов. На этот раз поговорим об архитектуре.
В кругу разработчиков часто популярен холивар в отношении программных архитектур для web-сервисов, мол, что выбрать, монолит или микросервисы, а для каких задач что подходит лучше и т.д. Есть строгие приверженцы одного из подходов, есть балансирующие между, но суть споров чаще всего одна - плюсы и минусы которые тот или иной подход в себе несет. Как-то я написал развернутый ответ на SO об отличиях монолитов и микросервисов и как плавно переходить от одного к другому.
Перед стартом битвы пет-проектов я тоже столкнулся с этой дилемой. С одной стороны есть монолит - простое и верное решение с минимальными затратами, но высокими рисками "завязывания" кода. С другой - микросервисы, хайповый и популярный путь с минимумом зависимостей, но сложностью развертывания и взаимодействия между сервисами.
А что если мы постараемся взять плюсы обоих подходов?
Допустим, у нас есть веб-сервис, единый (монолитный) исполняемый файл, под которым прячутся 2-4 микросервиса.
Какие плюсы:
- Простота развертывания. Один докерфайл и больше ничего. В отличие от классических микросервисов.
- Слабая связанность. Микросервисы внутри строго отделены друг от друга. От монолита требуется только запустить их всех вместе.
- Очень быстрый переход на микросервисные рельсы, в случаях, когда это необходимо. Мы просто выносим микросервис из монолита и разворачиваем отдельно по щелчку пальца.
Минусы:
- Нужно очень хорошо продумать архитектуру решения. Так чтобы можно было и быстро микросервис отделить и обеспечивалась достаточная обобщенность настройки.
- Не все внешние библиотеки можно настроить для исполнения под такой архитектурой. Я бы даже сказал, что их достаточно мало.
Можно сказать, что это переизобретенный SOA, но ключевое отличие тут в том, что микросервис - это не модуль ПО, а полноценное приложение со своими точками входа для пользователей.
Пример подобной архитектуры можно посмотреть в нашем репозитории для битвы
👾 PICO