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

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

Начинающим аналитикам бывает не просто разобраться в разных подходах к документированию  требований и множестве нотаций моделирования. У кого-то даже проскальзывают сомнения, а нужно ли все это знать или можно просто изучить формат описания user story? Я попробую развеять эти сомнения на примере учебного проекта.

«Сосредоточьтесь на основах, делайте их хорошо и делайте их неустанно..»

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

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

Доступ к файлам через отображение-в-память (mmap) — это способность некоторых операционных систем отобразить содержимое какого-либо файла в адресное пространство программы. Сама программа получает доступ к содержимому файла через указатели, как если бы сам файл был бы целиком загружен в оперативную память. Операционная система прозрачно загружает части файла в оперативную память, и автоматически выгружает их, когда памяти не хватает.

MMAP захватила умы программистов СУБД на многие десятилетия, как альтернатива буферу данных. И вот здесь следует отметить, что в mmap имеются серьёзные проблемы с корректностью и скоростью работы с данными в современных СУБД. В реальности, некоторые известные СУБД сперва использовали mmap для работы с "больше-чем-вмещается-в-память" базами данных, но вскоре обнаружили эти скрытые ограничения, которые принудили их к самостоятельному управлению файловым вводом/выводом, после заметных трат на инженерные исследования. В этом смысле mmap и СУБД подобны сочетанию кофе и острой пищи: неудачное сочетание, которое не очевидно, пока сам не попробуешь.

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

Здравствуйте, уважаемые читатели! SCTP — достаточно специфичный протокол, о котором, наверняка, многие не слышали. Тем не менее, он более чем актуален в некоторых областях, одна из них — использование для доставки контрольных сообщений в LTE сетях.

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

В общем, главная мотивация — желание написать небольшую вводную на таком ресурсе как habr для более легкого старта у новичков.

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

Kubernetes сейчас называют стандартом для оркестрации контейнеров. Он лежит в основе многих облачных платформ контейнеризации: например, мы давно развиваем наш Kubernetes aaS на платформе Mail.ru Cloud Solutions.

Однако Kubernetes далеко не первый подобный инструмент на рынке: некоторые из систем-предшественников продолжают активно использовать и вроде бы даже успешно.

Почему так происходит, несмотря на то, что Kubernetes, можно сказать, одержал победу в своем классе и мы видим много примеров, когда он приходит на смену другим решениям? Например, не так давно разработчики Mesosphere DC/OS, в основе которой лежал Apache Mesos, прекратили ее развитие и сфокусировались на другой своей платформе — D2iQ Kubernetes (DKP). Думаю, что стоит разобраться, всегда ли хорош Kubernetes, когда оправдано использовать другие оркестраторы и о каких подводных камнях стоит знать.

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). В этой статье расскажу об устройстве ряда оркестраторов-предшественников, сравню их с Kubernetes, посмотрю на его преимущества и недостатки по сравнению с ними.

Привет! Меня зовут Леонид, я DevOps-инженер в компании KTS. 

В этой статье я рассмотрю различные оркестраторы и объясню, почему Kubernetes — лучший выбор.

Нашей компании уже 6 лет, и 4 из них мы живем с Kubernetes. До этого мы испытали все варианты деплоя приложений на серверах: начиная от простого git pull до ci/cd на нескольких серверах. 

За небольшой срок в 4 года мы набрали много опыта. Начинали с вопроса, который, возможно, стоит сейчас перед вами: «Какой оркестратор выбрать?» Мы рассмотрели разные варианты, и в итоге остановились на Kubernetes. В статье расскажу, почему.

Наше подразделение занимается автоматизацией бизнес-процессов обслуживания клиентов в офисах и отделениях банка. Такие бизнес-процессы специфичны для конкретной организации, связаны с соблюдением внутренних регламентов и нормативных документов банка, должны полностью соответствовать часто меняющимся требованиям законодательства и всем инструкциям и правилам ЦБ РФ. Так, например, за процедурой открытия вклада стоит множество взаимодействий различных классов систем и компонентов, начиная от сбора и хранения согласий клиента на обработку персональных данных, интеграций с госсервисами и системами сбора сведений и заканчивая формированием приходно-кассовых ордеров. 

Подобные процессы мы реализуем с помощью движка Camunda, который позволяет прототипировать и визуализировать сложную последовательность шагов и моделировать flow совместно с бизнес-заказчиком, а также обладает множеством инструментов для реализации интеграций, оркестрации, мониторинга, сбора бизнес-метрик и тестирования. + быстро и относительно незатратно менять процессы (можно привести пример с запретом перевода валюты в другие банки). Вдобавок Camunda является open-source решением, что крайне важно в текущих реалиях и т.д. 

Впервые в наше подразделение Camunda попала в рамках закупки некоторого функционала у вендора. Реализация вендора была закрытой, сам движок инкапсулировался в каждый отдельный микросервис и был окружён различными самописными расширениями для централизованной разработки bpmn-процессов в браузере и сбора данных от всех запущенных инстансов. 

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

Изучая задачу, мы выяснили, что материалов об автоматизации бизнес-процессов в Camunda немного, особенно на русском языке. Поделимся своим опытом реализации проекта на Camunda, Java и Spring Boot.

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

Привет Хабр!

Сегодня поговорим про логирование (или же ведение журналов) в Kubernetes посредством EFK стека.

Приложения в контейнерах должны создавать журналы только в виде потоков событий и оставлять агрегацию и маршрутизацию другим службам в Kubernetes. Этот шаблон подчеркивается как фактор 11 журналов методологии The Twelve Factors App.

Обычно для стека объединяются три компонента: ElasticSearch, Fluentd и Kibana (EFK). Иногда стек использует Fluent Bit вместо Fluentd. Fluent Bit в основном функционально такой же, но легче по функциям и размеру. Другие решения иногда используют Logstash (ELK) вместо Fluentd.

Всем привет! Я Александр Яковлев, в Тинькофф руковожу разработкой бизнес-линии в нефинансовых сервисах.

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

Привет! Меня зовут Олег Малахов, я работаю в AGIMA. Недавно на одном из проектов перед нами поставили задачу — разработать кластеризируемую систему для управления гипервизорами. Таким образом заказчик хотел сохранить высокую доступность и отказоустойчивость системы, а также обеспечить связность при работе в географически разнесенных Data-центрах. В итоге мы рассмотрели кучу вариантов, но остановились на Etdc. И сейчас расскажу, почему выбрали именно его.

Всем привет! Давайте знакомиться ;) Я Аня, и я php разработчик. Основной стек - Magento. С недавних пор начала посматривать налево на Symfony и писать свои Pet Projects на этом фреймворке.

Мне всегда нравилось писать решения которые легко бы расширялись / адаптировались под требования бизнеса (заказчика). И мне всегда хотелось сделать это более 'правильно' и красиво. Так я и познакомилась с понятиями чистой архитектурой.

Мой пост ни в коем случае не претендует на самый правильный. Но позвольте мне здесь донести свои идеи. В комментариях буду рада услышать конструктивную критику к данному посту.

Для нетерпеливых, вот прямая ссылка на гитхаб

1. Видео с доклада
2. Слайды

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

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

Гексагональная архитектура, ни в коем случае не новый подход к разработке с применением фреймворков. Напротив, это всего лишь обобщение «лучших практик» — практик новых и старых. Я обернул эти слова в кавычки, чтобы люди не воспринимали их совсем буквально. Лучшие практики, которые работают для меня, могут не работать для вас — все зависит от задачи и преследуемых целей.

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

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

На бизнес я отложил 100 000 ₽ и сначала не уходил с работы. Я думал, что сделаю 5 коллекций, но деньги закончились уже на второй. Когда я начал зарабатывать в 2 раза больше, чем на основной работе, я ушел в бизнес, и это было страшно.