Главный вопрос этого поста: какие же изменения претерпевает agile коммуникация (и скрам, в частности), натягиваясь на распределенные команды?

Для этого, давайте сначала классифицируем коммуникацию:

1. стратегические митинги (планирование / ретроспектива)
2. ежедневную синхронизацию (в том числе daily standups)
3. прояснение рабочих вопросов

Давайте добавим еще одно измерение! Если попробуем наложить вышеприведенную классификацию на географию, то появляются дополнительные срезы для вышепреведенного:

Введение

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

Пример 1

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

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

• все системные логи разложенные по индексам в зависимости от их facility(auth,syslog,messages и т.д.);
• логи nginx — access и error;
• логи pm2;
• и др.

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

• Ubuntu 16.04 или debian 8-9;
• vm для развертывания;
• Прямые руки.

Приступим или добро пожаловать под кат

Введение

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

От переводчика: На проекте, где я работаю, сейчас идет активное переписывание логики, ранее реализованной в виде богатой модели предметной области (с использованием Active Record и Unit of Work). Новый подход включает в себя классы сущностей без поведения и служб без состояния, взаимодействующих посредством интерфейсов — фактически, он представляет собой анемичную модель, с перспективой перехода в дальнейшем на микросервисную архитектуру. Наблюдая в режиме реального времени, как «макаронный монстр» из примерно полутора миллионов LOC постепенно обретает форму, как упрощаются тестирование, масштабирование и кастомизация системы под нуждый различных заказчиков, я был весьма удивлен, узнав, что такой подход часто рассматривается как архитектурный анти-шаблон. Пытаясь разобраться в причинах этого, я наткнулся на данную статью и размещаю здесь ее перевод, чтобы обсудить с сообществом плюсы и минусы подхода.

Оригинал: The Anaemic Domain Model is no Anti-Pattern, it’s a SOLID design

Сергей Нужненко darkboatman, ведущий системный аналитик SuperJob, делится опытом запуска IT-проектов с точки зрения аналитика.

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

Это пригодится представителям заказчика, системным, бизнес-аналитикам, менеджерам проектов, другим участвующим в запуске ИТ-проектов, итераций или спринтов.

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

Возможно, вы уже знаете, что раз в месяц 2ГИС проводит DevDay — открытые встречи для общительных разработчиков. Так, 15 декабря мы собрали 140 человек, чтобы потолковать про функциональное программирование.

Делимся с вами записью двух выступлений. Первое видео будет полезно для входа в тему ФП, второе — расскажет о подводных камнях Akka Streams.

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



Дисклеймер: Каждая организация уникальна — от внутренней структуры, и до того, как она общается с внешним миром. Так что я не считаю ни один воркфлоу (или бизнес-процесс, как любят говорить на русском) универсальным решением. Пост не претендует на полноту и исключительность, он скорее о том, что подобный подход работает у нас в SkuVault, в текущей конфигурации команды, и демонстрирует положительные результаты. Наша специфика — это 50 человек, 16 из которых оторваны от другой части 10-часовой разницей во времени.

Недавно в Avito прошёл первый Product Analytics Meetup. Мы говорили об NPS в продуктовой разработке, персонализации веб-сайтов на основе customer journey map, кросс-продуктовых эффектах, способах повышения конверсии, построении и эволюции аналитических хранилищ данных. Под катом — видеозаписи выступлений, слайды от докладчиков и ссылка на фотоотчёт.

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

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

Введение

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

Дуальность

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

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

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

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

Разработка через тестирование (TDD) – отличный способ повысить качество и надежность кода. Этот же подход может быть распространен и на разработку требований. Он называется "Разработка через приемочные тесты" – acceptance test driven development (ATDD). Сначала я присматривался к этому подходу, потом пробовал применить, потом долго тюнинговал, чтобы приспособить его под мои нужды, и теперь хочу поделиться мыслями. И для себя еще раз разложить все по полочкам.

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

Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.

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

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

Я только что закончил семь собеседований в компаниях Кремниевой долины. В конечном итоге я принял предложение разработки программного обеспечения в Facebook.

Вот как я готовился к этим собеседованию и чему я научился на этом пути.

Мой многолетний путь в Кремниевую долину

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

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

Я оставил свое место в качестве ведущего инженера iOS в чудесной компании в Мельбурне и я вернулся обратно в мой родной город Перт, чтобы учиться. Тут я буду готовиться к переговорному процессу которое ждет меня в Кремниевой долине. Я знал, что это будет невероятно сложно и тяжело.

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

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

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

1. Думайте своей головой и проверяйте факты

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

Всем привет! В своей прошлой статье я писал об организации модульной системы мониторинга для микросервисной архитектуры. Ничего не стоит на месте, наш проект постоянно растёт, и количество хранимых метрик — тоже. Как мы организовали переход с Graphite+Whisper на Graphite+ClickHouse в условиях высоких нагрузок, об ожиданиях от него и результатах миграции читайте под катом.

В марте 2017 года мы собрали небольшую команду и взялись за разработку нового перспективного проекта. Без особых деталей могу сказать, что задача стояла интересная и соблазнительная — мобильный, синхронный, командный PvP. Спустя 7 месяцев активной разработки мне захотелось рассказать коллегам из других проектов и отделов Pixonic технические детали и я подготовил для них презентацию, которая в дальнейшем превратилась в эту статью.

Как техлид команды, я расскажу, с какими задачами и проблемами мы успели столкнуться, как их решаем и почему. Мы используем итеративный подход добавления функционала в проект и в данный момент у нас реализованы: PvP на iOS и Android (обе платформы играют на одних серверах); набор персонажей, три десятка игровых механик, боты; матчмейкинг; набор мета-фич (кастомизация персонажей, прокачка и другие); решена задача масштабируемости на весь мир.

Итак, поехали.