Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

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

Проходя собеседование на позицию Product Owner я понял, что у меня серьезный пробел по бизнес метрикам в Agile проекте, т.к. работаю в госструктуре. В русском сегменте информация достаточно скудная. В английском сегменте очень понравилась статья Ashwinee Kalkura. Поэтому решил сделать немного вольный перевод. Оригинал статьи здесь.

Что значат метрики для Agile команд?

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

Организации склонны копировать «то, что сработало для других», даже не заботясь об ограничениях и условиях, в которых конкретная метрика работала на «других».

Тогда, что измерять? На мой взгляд, организации, которые поняли, что и сколько измерять в продукте, выжили и процветают до сих пор. Они в конечном итоге стали Agile-организациями. Когда у них несколько продуктов, у них разные подходы для каждого из них. Некоторым продуктам потребуется много статистики и данных, в то время как некоторым понадобиться лишь пара метрик!

И как тогда понять, что именно нужно измерить? Для меня ближайший путеводитель — это 7-й принцип в Agile Manifesto — «работающее программное обеспечение — лучший измеритель прогресса». Если Вы можете определить, что является для Вас рабочим программным обеспечением, становится легче измерить прогресс.

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

Какой путь видит неподготовленный тимлид, когда возникает необходимость чему-то научить своих коллег, будь то команда разработчиков или люди, которые сопровождают, поддерживают или продают его продукт? Правильно — слепить презентацию на 100500 слайдов, забронировать переговорку или конференц-зал, кинуть приглашение на почту, и ждать, что все отдаленно заинтересованные сами придут и сами приложат усилия, чтобы разобраться в вопросе. Нетрудно догадаться, что шанс на успех такого мероприятия равен 0,00%.

А вот почему именно, и как на самом деле нужно подходить к передаче знаний внутри компании, чтобы добиться результата, знает Евгения Голева (cheaffa). И нам на TeamLead Conf рассказала, а теперь и с вами поделится многолетним опытом обучения взрослых.

Я все еще не до конца понял, как так получилось, но в прошлом году я слово за слово подписался прочитать курс по Deep Learning и вот, на удивление, прочитал. Обещал — выкладываю!

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

Материалы курса были опробованы на студентах кафедры АФТИ Новосибирского Государственного Университета, поэтому есть шанс, что по ним действительно можно чему-то научиться.

За последние восемь месяцев я прошел собеседования в самых разных компаниях — DeepMind в Google, Wadhwani Institute of AI, Microsoft, Ola, Fractal Analytics и некоторых других — в основном на позиции Data Scientist, Software Engineer и Research Engineer. По ходу дела мне предоставлялись возможности не только пообщаться со многими талантливыми людьми, но также по-новому взглянуть на себя с пониманием того, что хотят услышать работодатели, когда беседуют с кандидатами. Думаю, если бы я располагал этой информацией раньше, то мог бы избежать многих ошибок и подготовиться к собеседованиям куда лучше. Это и стало импульсом к написанию данной статьи — возможно, она поможет кому-нибудь получить работу мечты.


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

В Naumen мы сами организуем техническую конференцию. Мы назвали ее Devel Camp (от «developer»). Для наших сотрудников она стала хорошей альтернативой открытым профессиональным конференциям.

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

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

И, конечно, у нас нет явной или завуалированной под доклады рекламы.

Действительно ли нужны внутренние конференции? В чем профит для сотрудников, докладчиков, организаторов и компании? Как подобрать доклады и сделать конференцию интересной? Мы надеемся, что наш опыт может быть полезен для вас.

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

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



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

@innubis

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

Мы в Badoo относительно небольшими силами (в моей команде 30 человек) ежемесячно деплоим порядка сотни новых востребованных фич, при этом не теряя в качестве кода, планирования и поддержки. Каким образом нам удаётся оставаться «на коне» и как у нас построено взаимодействие инженерной команды с продуктовой, я расскажу в этой статье.

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

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

В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum. И все эти agile-ы и devops-ы можно внедрять и без этих людей. Так что если кто-нибудь вам скажет, что у них в команде все тестируют руками — потому что у них по каким-либо причинам нет разработчика автотестов — не верьте им. Они тестируют руками, потому что по-другому им лень. Или не умеют.

Данную статью меня побудил написать тот скрытый и для каждого свой смысл должности/роли Team Leader. Многие хотят им стать, многим интересно что там, "под капотом", работы в этой должности. Поэтому кому интересно узнать еще одно мнение об этом всем безобразии, то прошу под кат.

Люди, которые никак не могут уснуть и тщетно пытаются это сделать перед телевизором, наверняка, давно заметили, что самые интересные передачи почему-то крутят по ночам. Да, действительно, днем «… телевизор как унитаз, только не мы в него, а из него на нас» (к сожалению не смог найти автора цитаты, но тот, кто раньше постоянно читал журнал «Хакер», возможно, испытал дежавю). Зато ночью, просто листая каналы, можно наткнуться на что-то действительно интересное. Именно так я и наткнулся на фильм о Данидинском исследовании. Фильм смотрел не моргая. А когда авторы исследования заявили, что выяснили от чего больше всего зависит успех ребенка в будущем — даже привстал. Оказывается — основополагающий фактор успеха ребенка (любого человека) — это самоконтроль!

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

И попробовал. Кому интересно, что получилось, прошу под кат.

Предыстория

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

В конце 2012 года мы запустили в работу услугу SD для одного из наших клиентов в режиме 24/7/365. Полноценной службы SD у заказчика до этого не было, вся поддержка оказывалась силами внутренних подразделений. Под этот проект была подобрана и обучена новая команда, состоящая из 7 сотрудников, включая меня. Сервис стартовал активно — передача знаний, знакомство со спецификой работы. У команды было много идей и энтузиазма. Сервис заработал как часы.

Узнаете себя? А может, другие из-за вас чувствуют себя так?

Групповой чат похож на непрекращающееся совещание со случайными участниками и без повестки дня. Так считает Джейсон Фрайд, знаменитый сооснователь компании 37signals, автор бестселлеров Getting Real и Rework. Мы в Alconost перевели для вас его статью с анализом плюсов и минусов групповых чатов. Небольшой спойлер: минусов оказалось в несколько раз больше.

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

• Не заморачивайтесь с броским названием.
• Аудитория не знает, что именно и как вы собираетесь рассказывать.
• Докладчик — не слуга аудитории.
• Вы делаете доклад для тех, кто в зале прямо сейчас.
• Озвучьте аудитории удобные для вас правила ответов на вопросы. Соблюдайте их.
• Фиксируйте результаты выступления — в течение 3-х дней после мероприятия.

Далее немного подробнее о каждом пункте.

NUMA (Non-Uniform Memory Access — «Неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — технология совсем не новая. Я бы даже сказала, что совсем старая. То есть, в терминах музыкальных инструментов, это уже даже не баян, а, скорее, варган.
Но, несмотря на это, толковых статей, объясняющих, что это, а главное, как с этим эффективно работать, нет. Данный пост, исправляющий эту ситуацию, предназначен прежде всего для тех, кто ничего не знает про NUMA, но также содержит кое-что интересное и для знатоков-NUMизматов, а главное, он облегчает жизнь мне, инженеру Intel, так как отныне всех интересующихся NUMA русскоязычных разработчиков буду отсылать к нему.

Администраторам Linux: это статья о “Puppet” для Windows, и уже есть бета-версия DSC для Linux.
Для тех, кто в теме: не будет ничего о новинках PowerShell 5.0, только о том, что доступно из “коробки” Windows Server 2012 R2.

Преамбула

В 2013 году с выходом Windows Server 2012 R2 компания Microsoft сообщила о появлении Powershell Desired State Configuration (DSC).

К этому моменту я более или менее представлял, что делают подобные системы для Linux (например, уже упомянутый Puppet). Поэтому, предложенные возможности мне показались недостаточными для полной автоматической настройки системы. И только недавние сообщения о готовящемся Powershell 5.0 и о новых возможностях DSC побудили меня снова обратить внимание на эту технологию.

Чтобы разобраться, я выдумал задачку попроще:

• Пусть, есть некий клиент, который хочет самостоятельно установить разработанное нами ASP.NET приложение на своем сервере. Кроме IIS, нам нужен MS SQL Server, а также требуется сделать некоторые настройки операционной системы и установить какие-нибудь важные утилиты.

Можно ли вместо инструкции по установке и настройке выдать некий конфигурационный скрипт, который сделает все что требуется на только что установленном Windows Server 2012 R2?

Для лучшего понимания этой статьи, наверное, предварительно стоит прочесть описание в блоге Microsoft — http://habrahabr.ru/company/microsoft/blog/253497/.

Вы когда-нибудь работали с виртуальными машинами, создавали виртуальные диски? Если да, то наверняка вы обратили внимание на такие удобные возможности, как динамическое увеличение размера диска (возможность хранить только то, что было записано) и возможность создания snapshot'ов — моментальных снимков состояния диска. Если вам интересно узнать, каким именно способом достигаются эти возможности и как хранятся данные в VHD и VHDX файлах — добро пожаловать под кат.

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

Типичная схема организации выступления

Типичная схема выступления на конференции подразумевает следующие шаги:

• Принятие решения о выступлении на конференции — примерно за 3 месяца до конференции.
• Подача темы выступления и краткой аннотации (включая формат и длительность), а также резюме — примерно за 2 месяца до мероприятия.
• Предоставление готовой презентации, расширенной аннотации, резюме и фотографии — за месяц и ближе к мероприятию.
• Публикация точной программы — хорошо, если за неделю до мероприятия.
• Собственно выступление.
• Кулуарное общение и организация контактов на мероприятии.
• Фиксация результатов выступления — в течение 3-х дней после мероприятия.

По желанию выступающего или по специфике мероприятия сроки могут пропорционально сокращаться.

Я познакомился с Evernote лет пять назад, но первое время активно не использовал — у меня там были бессистемные блокноты для записи идей, документы, какие-то редкие фотографии, да и все. Задачи, которые я контролировал, хранил в Things, а контент — в Evernote. Примерно четыре года назад я начал формировать из контента личную базу знаний, раз в полгода её модифицируя. И вот уже как год я вношу только минорные изменения в структуру. Вот, что у меня получилось:

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