Все потоки

Привет, Habr! Продолжаем знакомить с нашими сотрудниками (уже был рассказ QA-инженера, который пришел к нам из авиации, разработчика с 30-летним стажем, а здесь – «один день из жизни» специалиста отдела аутсорсинга).

Cегодня речь пойдет про отдел внедрения. Мы намеренно стараемся избежать его сравнения с техподдержкой. Менеджеры внедрения поддержат, конечно. Но формат их работы сильно отличается от того, что принято видеть в классической ТП. Это сами клиенты говорят. Люди в отделе внедрения – сочетание льда и пламени, воды и металла. То есть лучшее сочетание софт и хард скиллз: знают про ПО и про психологию лучше, чем кто-то в компании. Пообщавшись с тремя сотрудницами составили их коллективный портрет.

Привет! Меня зовут Алексей, я работаю в команде Антиспама Почты Mail.ru, и сегодня хочу поделиться интересным опытом нашей команды по поиску проблем на бою. 

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

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

18–19 августа в павильоне «Авиация и космонавтика» на ВДНХ прошла конференция для руководителей Digital-студий и агентств.

Это вторая (из трех) часть переписанного руководства по дообучению совсем начинающих коллег всяким мелочам - зачем нужен Hashicorp Vault, при чем тут MS Active directory, как и куда смотреть в Windows логи на элементарном уровне, базовые / Entry (Junior) SA задачи.

Накопить за 7 лет терабайты данных в монолите и решить, что пора оптимизировать систему и разбивать её на микросервисы — страшный сон для айтишника. Добавим сюда ещё база на решениях от 1С и необходимость обеспечить непрерывность процесса. Стало страшно? А для нас — возможность показать экспертность и решить нетривиальную задачу. О том, как «кролик» помог сдвинуть гору рассказал архитектор 1С компании «Автомакон» Виталий Осиповский.

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

Любые сбои и простои были неадекватно затратны и влияли на все компоненты системы в целом. А сама система не годилась для быстрого масштабирования бизнеса. Поэтому уже в 2020 году приняли решение о поэтапном разделении монолита на отдельные программные компоненты.  

Несколько лет назад Всемирная организация здравоохранения окрестила наступившее столетие «веком аллергии», а саму болезнь — «эпидемией»: по данным ВОЗ, с 2001 по 2010 год число аллергиков в мире увеличилось на 20%. К 2025 году, считают в ВОЗ, страдать от этого недуга будет уже 50% мирового населения.

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

Что в этом дайджесте? 1 млн уников в сутки на сайте-новостнике на Joomla, немного статистики, маркетинговых исследований, обзоры, электронная коммерция. 46 (+66) расширений Joomla, 8 ресурсов для разработки, Joomla 4 REST API и мобильные приложения, 8 статей и переводов, события из жизни Joomla-сообщества.

Добрый день, меня зовут Рустам Ахметов, я архитектор ГК Юзтех и интеграционной шины данных UseBus. В предыдущей статье я рассказывал о Kafka и её аналогах, а сегодня хочу рассмотреть NiFi.

Вы узнаете:

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

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

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

Все об использовании шаблонов в Airflow с примерами кода. Продолжение серии публикаций astronomer.io

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

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

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

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

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

Когда выгорание по внутренним (и внешним) причинам достигает максимума, когда тошнит от одного воспоминания о том как выглядит IDE, когда мнится что в седло большой разработки больше не вернутся никогда, но, при всём при этом, вносить свой вклад в развитие индустрии хочется - остаётся одно.

Сменить угол обзора.

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

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

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

Доброе время!

Часть 2-я по открытому занятию нового учебного курса: реализация простого JWT через новый Spring Boot OAuth2 Resource Server (первая часть: Spring Boot 3.0 — готовимся заранее). Что такое JWT и зачем, писать здесь не буду - в сети материалов много, начинать знакомство обычно рекомендую с Википедии. А вот хорошая ссылка по реализации JWT+OAuth2. Здесь я привожу Java код, основанный на официальном примере spring-projects - простейшей реализации JWT Login Sample (без refresh token и отдельного авторизационного сервера), "творчески доработанный" и с моими пояснениями. Еще раз - без теории, для тех, кому интересен код актуальной Java реализации. Если это Вы - прошу.

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

Поехали!

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

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

Вспоминая темные века, я могу вспомнить, когда впервые прочитал о «нефункциональных требованиях». Этот термин поставил меня в тупик. Если это нефункционально, то почему меня это волнует? Я уверен, что автор этой книги разъяснил мне это на странице позже, но этот термин всегда казался мне странным. Я предпочитаю думать о нефункциональных требованиях как об ограничениях, которые мы накладываем на систему. Когда владелец продукта (Product owner) говорит, что «система должна адекватно работать, когда в ней одновременно находятся 100 000 пользователей», владелец продукта налагает ограничения на команду разработчиков.