Перешел тут недавно на новый VDS для своих сайтов на хостинг webbynode.com. Очень все по-рельсовому сделано. Но сейчас речь не о них.

При регистрации предложили сделать аккаунт в приложении мониторинга RoR сайтов. Называются New Relic. Посмотрел презентации, и надо признаться, очень впечатлило. Как промо акция, там дают недельный gold-account, где можно воспользоваться всеми отчетами. Это, друзья мои, стоит внимания.

Дашборд для лайт версии

Вместо введения

За последние 3 года работы мне довелось работать в самых различных ипостасях: исследователем, разработчиком и руководителем проектов. Есть различные стили управления: западный (когда предоставляется большая свобода в коллективе и многое построено на доверии, уважении, личной организованности отдельного индивидуума) и восточный (когда штрафуется каждое опоздание, жестко фиксируются сроки, во главе угла стоит железная дисциплина коллектива и если человек не справился с поставленными целями — наступает расставание). Руководитель проекта должен сочетать в себе два этих элемента: яблоко и кнут, подпускать людей к себе, чтобы разработчики вам доверяли, но и соблюдать субординацию, так как отношение-отношениями, а нацеленность на результат должна быть всегда.

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

Для удобства сделал субтитры к видео, чтобы смотреть было проще. Замечу лишь, что это не профессиональная видео-лекция и лектор нигде эту методологию не читает специально. Дина Насырова (Тим Лидер из Fujitsu) пришла к нам в знак уважения, чтобы помочь наладить процесс работы коллектива и заодно поделилась своим собственным богатым опытом. Встреча прошла год назад — с тех пор много воды утекло. Но спустя время до сих пор вспоминаю ее, так как информация представленная в ней мне очень сильно пригодилась.

SCRUM? Какой SCRUM?

Впервые подход SCRUM (англ. scrum «схватка вокруг мяча») описали Хиротака Такэути и Икудзиро Нонака, которые заметили, что небольшие команды (5 — 9 человек), укомплектованные разнопрофильными специалистами, дают лучшие результаты. Наиболее полное описание SCRUM впервые представил в своей книге Джефф Сазерланд. Книга так и называется — SCRUM. Джефф начинал свою карьеру как военный летчик, во время войны во Вьетнаме выполнивший более ста боевых вылетов. Затем Джефф занимался наукой, но мир его запомнит как одного из родоначальников SCRUM. Книга начинается с реальной истории из жизни ФБР, тратившего миллионы долларов на разработку автоматизированной системы, предназначенной для поиска и отслеживания преступников. Проблема заключалась в том, что по истечении сроков проекта подрядчики демонстрировали ФБР абсолютно нерабочий продукт. Это означало лишь одно — американские налогоплательщики потратили миллионы впустую. Ситуация казалась безвыходной до тех пор, пока руководство ФБР не обратилось к тогда еще зарождавшемуся методу управления проектами SCRUM. Этот метод описан доступным языком в вышеупомянутой книге, которая, кстати, переведена на русский язык. Далее в статье рассмотрены основные заблуждения и мифы, которые могут отпугнуть топ менеджеров, задумавших внедрить SCRUM в свои проекты.

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

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

Залп скосил 50 офицеров и 760 рядовых. Французы дрогнули, запаниковали и — обратились в бегство. «Тут дела наши пошли не вполне хорошо», — описывает этот момент битвы официальная французская депеша.

Келли Дж. Порох. От алхимии до артиллерии.

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

Пытаясь как-то спасти положение, активисты Scrum вспоминают, что Scrum — это же еще и framework. Объявляется новая стратегия: “Мы не только Scrum, мы еще и Agile! Мы используем best practices, берем из Scrum только самое лучшее, то, что подходит конкретно для нашей ситуации, а все остальное лишнее и необязательно”. А раз так — “Мы — молодцы и все делаем правильно”.

В январе 2018 года свет увидел обновленный фреймворк Nexus — инструмент на базе Scrum, заточенный под командную работу над крупными проектами. Авторы методологии внесли исправления в ряд определений терминов и поменяли порядок лицензирования. С начала года Nexus Guide распространяется по лицензии Creative Commons. И это значит, что любая компания может свободно использовать Nexus (как и Scrum).

Расскажем об особенностях методологии и её основных компонентах.

Сегодня мы хотим поделиться впечатлениями от участия в тренингах Certified Scrum Master и Certified Scrum Product Owner от Innovel и ProCognita, которые проходили в Варшаве 29-30 июня и 1-2 июля соответственно. Здесь мы рассмотрим наиболее интересные с нашей точки зрения инструменты и техники, представленные на обоих тренингах, которые будут полезны как тем, кто делает свои первые шаги в SCRUM, так и уже имеющим некоторый опыт в применении гибких SCRUM в своих проектах. Мы оставили оригинальные названия упражнений, чтобы упростить поиск тем, кто впоследствии пожелает найти больше информации; кроме того, статья дополнена ссылками на англоязычные статьи, поясняющие суть некоторых упражнений.

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

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

Некоторое время назад я гуглил интернет по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая новый музон и думая о новой фиче в проекте. Как появилось время, решил восполнить этот пробел, заодно написав полезную статью по этому поводу.

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.

Введение

Современные проекты все чаще предъявляют высокие требования к покрытию автоматическими тестами. В наше время писать тесты не просто признак хорошего тона, но одно из требований, которое предъявляется к коду. Все чаще мы слышим такие аббревиатуры, как TDD (Test Driven Development) и BDD (Behaviour Driven Development) и многие строго следуют этим подходам в разработке.
BDD это одна из разновидностей TDD, и об этом я хотел бы написать в этой статье. Точнее не о самом BDD, а о frameworks, которые нам предоставляет индустрия на сегодняшний день. А если уж быть совсем точным, то о трех из них: spock, easyb и cucumber.

BDD — разработка через поведение. BDD для микросервисов — это сотрудничество клиента, разработчиков и тестировщиков. BDD — это разработка, которая учитывает и технические интересы и бизнес-требования. Этот подход обычно применяется для описания интерфейсов приложений, а так как микросервисы — детали реализации системы, то BDD прекрасно походит и для разработки микросервисов. Как это сделать — в переводе материала Ken Pugh.



Об авторе: Ken Pugh обучает компании развивать гибкость, создает высококачественные системы с помощью Acceptance Test-Driven Development, BDD, ускорения DevOps. Кен написал несколько книг по разработке ПО, был лауреатом премии Jolt Award 2006 Prefactoring, один из создателей курса SAFe Agile Software Engineering.

Два подхода к разработке через тестирование вызывают особенно много споров — из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. Старшие инженеры по автоматизации тестирования «Альфа-Лаборатории» Юлия Ковалева и Анна Чернышева рассказывают базовые вещи о сходстве и различиях двух популярных методик и то, какой подход у них используется в самой компании.

Статья публикуется от имени Трубанова Вадима, @vonaburt

Методология BDD все чаще завоевывает внимание IT-индустрии как логически верная ступень развития традиционных подходов к тестированию проектов, в том числе подходов к автоматизации тестирования. Текущая эпоха информационных технологий диктует свои правила, и в этой гонке технологий выигрывает тот, кто умеет реагировать на любые изменения быстро и качественно. Особенно это касается компаний связанных с банковской деятельностью, например таких, как наш банк, где каждый отложенный час до релиза может повлиять на общую картину качества сервисов, составляемую нашими клиентами. При правильном использовании методология BDD позволяет сократить время, затрачиваемое на тестирование выпускаемых продуктов, повышать качество проводимого тестирования и делать сам процесс прозрачным и понятным для всех, что и подтолкнуло нас к её использованию. На данный момент методология BDD внедряется на двух наших web-продуктах, активно развивается и уже приносит свои плоды. Хочется поделиться нашим опытом внедрения BDD со стороны автоматизации тестирования и рассказать об основных принципах, которые позволят вам внедрить эту методологию безболезненно, быстро и, самое главное, сделать её использование эффективным.

by Jonathan Dahl

Мы в Alconost активно пользуемся облачными сервисами. Для такой распределенной команды, как наша (лишь 20% коллектива работает в офисе), это просто находка — работа получается такой же быстрой и слаженной, как если бы наши сотрудники сидели рядом друг с другом. Кратко о том, какие облачные инструменты мы используем и любим — в этом посте.

Компания Аплана подготовила обширный обзор сценариев использования платформенных сервисов Windows Azure. С удовольствием делимся с вами этим интересным документом, который будет полезен для любых отдельных разработчиков и компаний занимающихся созданием приложений и рассматривающих облако Windows Azure в качестве платформы для своих решений. Данное руководство состоит из трех частей, в первой части вы узнаете о сценариях хранения и обработки данных.
UPD: Вторая часть статьи

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

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

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

Гибридное облако представляет собой объединение ключевых возможностей частного и публичного облака.

Пока компании вроде Google и Microsoft активно рассказывают простому пользователю о счастье, которое ожидает их на облачных сервисах, я хочу поделиться другой стороной облаков — счастьем для разработчиков и тестировщиков ПО. За те несколько лет, в течение которых я руковожу группой тестирования Parallels Plesk Panel, была собрана неплохая коллекция лайфхаков по использованию облака для наших целей.

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

С преамбулой вроде всё. Любопытных приглашаю под кат.

В первом посте серии мы упомянули основные функции, доступные в Облаке на платформе Parallels Automation for Cloud Infrastructure (PACI). В том числе:

• Создание образов серверов
• Клонирование серверов
• Создание и управление балансировщиком нагрузки
• Настройка резервного копирования
• Настройка Брандмауэра

Все они доступны на этапе некоммерческого тестирования. Откроем панель управления услугой «Облачные серверы» и посмотрим, как они реализованы в её интерфейсе. На самом деле, панель управления — это все лишь GUI-оболочка над API-методами, о которых мы рассказывали в прошлый раз.

Как наладить эффективный процесс управления проектом в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо? В статье дан обзор применения JIRA для управления проектом по разработке программного обеспечения в интересах крупного государственного заказчика. Я буду рад, если описанные подходы помогут лично вам повысить эффективность своей команды и снизить напряженность на проекте. Приветствуется любая критика.

Источник