В 2002 году Джеймс Греннинг представил миру концепцию Покера планирования (Planning Poker) в своей публикации. Стоит отметить, что он является соавтором Agile-манифеста, который по сей день является одним из фундаментальных принципов разработки программного обеспечения.

Итак, что такое Покер планирования?

Покер планирования – это техника, применяемая в Scrum-командах в рамках Agile-разработки для коллективной оценки трудоемкости задач.

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

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

Если вам нужен онлайн-сервис для покер планирования на русском языке, рекомендуем обратить внимание на https://pplanning.ru.

Но также существуют зарубежные сервисы для покер планирования:

Всем привет! На связи Олег Громов, автор телеграм-канала Приключения Громова, где я рассказываю про свой опыт работы программистом в крупных компаниях и стартапах, карьеру, переход из найма в в предпринимательство, способы развития для разработчиков, софт-скиллы и другие полезные в работе и жизни навыки и идеи.

Сегодня я расскажу про ведение личного профессионального блога. По моим наблюдениям, а также по результатам небольшого опроса (результаты ниже), единицы разработчиков ведут блоги, либо как-то ещё активны публично.

И это несмотря на то, что множество моих коллег в нынешней и прошлых компаниях (Facebook, Toptal, Klarna, Яндекс) — прекрасные профессионалы с огромным опытом, которым явно есть чем поделиться. Тем не менее, большинство из них неактивны публично. Почему?

На Хабре много статей про разработку Телеграм ботов на Python, в том числе при помощи Django. Однако, большинство из них направлено на первичное ознакомление с API Телеграм.

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

Как же объединить Django и Telegram бота в одном проекте?

Этой статьей я хотел дополнить тот маленький клочок информации доступный в интернете по теме создания ботов который мне явно бы пригодился в прошлом. Сегодня речь пойдет о соединения вашего серверного приложения с Telegram ботом на примере языка Python, его фреймворка для разработки серверных приложений - Django и библиотеки для создания Telegram ботов - pyTelegramBotApi.

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

💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.

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

Аркадий и Борис Стругацкие

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных и сам сервис ушел в офлайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими. Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы. It, как говорится, happens. Но надо отдать должное команде проекта: они нашли в себе силы отнестись ко всему с юмором, не потеряли голову и проявили удивительную открытость, написав обо всем в твиттере и выложив в общий доступ, по сути, внутренний документ, в котором команда в реальном времени вела описание разворачивающихся событий.

Во время его чтения буквально ощущаешь себя на месте бедного YP, который в 11 часов вечера после тяжелого трудового дня и безрезультатной борьбы с Постгресом, устало щурясь, вбивает в консоль боевого сервера роковое sudo rm -rf и жмет Enter. Через секунду он понимает, что натворил, отменяет удаление, но уже поздно — базы больше нет...

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

О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

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

System Design (сборник на английском языке).

Hello world!

В первой части шпаргалки (вопросника, если угодно) на высоком уровне рассматриваются такие вещи, как сеть, HTTP, операционная система, виртуализация, хранилище etc., а также несколько технологий, используемых в сфере DevOps, таких как Prometheus, OpenStack, Puppet, Elastic etc. (вопросы с ответами из основного репозитория оригинала). Полагаю, шпаргалка будет интересна всем, кто связан с разработкой программного обеспечения, прежде всего, с разработкой веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий/терминов, а также в обнаружении очепяток.

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

Настоящей статьей начинаем цикл статей, посвященных траблшутингу (решению проблем) и анализу работы межсетевых экранов производства Palo Alto Networks – одного из мировых лидеров в сфере разработки оборудования для обеспечения информационной безопасности.

Давайте разберемся, – что такое сессия, и как она работает в разрезе межсетевого экрана Palo Alto Networks.

Когда мы в Tarantool столкнулись с задачей настройки мониторинга для сдачи проекта заказчику, мы решили её с помощью grafonnet. Это библиотека для написания дашбордов Grafana с помощью кода на языке jsonnet, которая заметно облегчила нам жизнь.

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

Несколько несложных примеров того, как на практике можно использовать продвинутые возможности Helm для эффективной организации безупречной continuous delivery в Kubernetes. Полезные рецепты, чтобы поддерживать конфигурации множества тестовых и production сред - удобно, безопасно, без копипасты и приятно на вид. Методы поддержания целостности сред - чтобы "зелёный" статус пайплайна всегда означал удачный деплоймент, а в случае неудачи среда бы сама восстанавливалась.

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

Если у нас есть 5 вариантов решений, то новичку трудно понять, какой из них лучше.

Здесь я попробовал создать список общих указаний и рекомендаций, чтобы получить представление об оптимальных способах работы с helm-чартами.

Здесь будет 7 тем в 3-х постах, и в основном это есть в документации Helm по ссылке https://helm.sh/docs/chart_best_practices/

Привет, Хабр! Меня зовут Тимур, я тружусь ML-инженером в одной сибирской IT-компании.

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

В качестве бонусов - готовая GitLab CI джоба для сборки и публикации пакетов, а также шаблон Dockerfile для multi-stage сборки образов в проектах с использованием Poetry.

Добро пожаловать под кат!