История первая

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


Игровая компания немца разрабатывала 3 вида игр:

1. Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
2. Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
3. Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

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

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

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

Современные web-приложения зачастую содержат множество "движущихся частей" и сторонних зависимостей. В процессе рефакторинга и добавления/изменения функциональности в таком приложении может произойти поломка существующих use-case сценариев и нестабильная работа в определенных браузерах.

Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:

• https://devexpress.github.io/testcafe/
• http://nightwatchjs.org/
  

Мне всегда нравилась идея — работай меньше, делай больше. Но в моей жизни было время, когда я действовал по-другому. Несколько видов деятельности так сильно интересовали меня, что я никак не мог определиться на чем сосредоточиться. Логичнее было бы использовать правило 20% и отсечь все остальное, но я этого делать не стал и кое-что понял.

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

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

Немаловажный пункт, который очень часто упускают из вида разработчики — это эксплуатация проекта. Как выбрать дата-центр? Как прогнозировать угрозы? Что может произойти на уровне фронтенда? Как балансировать фронтенд? Как мониторить? Как настраивать логи? Какие нужны метрики?

И ведь это только фронтенд, а есть ещё бекенд и база данных. Везде разные законы и логика. Подробнее об эксплуатации highload-проектов в докладе Николая Сивко (okmeter.io) с конференции HighLoad++ Junior.

Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно.

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

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

Единственным на моей памяти исключением является node.js, авторы которой разработали «с чистого листа» на удивление удачную систему управления зависимостями. Ну, как удачную? Проблем там тоже много, начиная автовыполняемыми скриптами и заканчивая переходом от древовидной к flat структуре в 3-й версии. Но по сравнению с тем, что на тот момент было в других языках, нода — это прорыв.

Совсем недавно экосистема пополнилась новой утилитой rnpm, которая позволяет одной командой устанавливать React Native зависимости. В которых, на секундочку, может быть бинарный код для android и ios. Для разных архитектур. И все это работает из коробки. Мы в Voximplant хорошо знакомы с этой штукой: с ее помощью ставится наш собственный React Native SDK.

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

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

Конструкции, или почему не ломаются вещи, Дж. Гордон
Прекрасная, хоть и очень длинная штука, которая рассказывает про сопромат простыми словами и почти для детей. Но на уровне жёсткого хардкора. По своей полезности для осознания физики вокруг может сравниться с не менее прекрасной современной «Квантовая вселенная. Как устроено то, что мы не можем увидеть» Брайана Кокса и Джеффа Форшоу. Рекомендую обе. Будет, что почитать в дороге, если вдруг почувствуете, что играть на планшете надоело. И о чём подумать, когда выяснится, что вся та фигня, которую вам давали на уроках химии, физики и прочего в школе и университете вдруг начинает выстраиваться в стройную теорию.

Evil by Design, Крис Ноддер
Один из лучших подходов к проектированию чего-то хорошего — это спроектировать сначала самое ужасное из возможного. Пользователь обычно не скажет, как сделать ему хорошо, но точно знает, как бывает плохо. Например, юзер не говорит «я хочу, когда нажимаю на ссылку напоминания пароля, там в поле уже была введена почта», зато вполне способен сказать: «слушай, меня дико бесит, когда логинишься, тебе показывают новую страницу про то, что пароль не подошёл, и, чтобы его восстановить, надо ещё один долбанный раз вводить почту». Вся книга Криса состоит из таких «тёмных» шаблонов, когда какие-то гады намеренно вводят вас в заблуждение. Он там очень переживает за этику, поэтому вступления лучше пропустить. Единственная в этом обзоре книга на английском, но довольно простом.

Я в течение десятилетий программировал на объектно-ориентированных языках. Первым из них стал С++, затем был Smalltalk, и наконец .NET и Java. Я фанатично использовал преимущества наследования, инкапсуляции и полиморфизма, этих трёх столпов парадигмы объектно-ориентированного программирования. Мне очень хотелось воспользоваться обещанным повторным использованием и прикоснуться к мудрости, накопленной моими предшественниками в этой новой и захватывающей сфере. Меня волновала сама мысль о том, что я могу мапить объекты реального мира в классы и думал, что весь мир можно аккуратно разложить по местам.

Я не мог ошибаться сильнее.

Предлагаю читателям «Хабрахабра» перевод опубликованной на codeheaven.io статьи «15 Things You Should Know About Ansible» за авторством Marlon Bernardes.

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

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

(продолжение)

Как вам, думаю, известно, Раст входит в число языков реализующих сопоставление с образцом (pattern matching). В случае если вам незнаком данный термин, вы можете думать о нём как об обобщёном switch выражении в котором мы сравниваем объекты не только по значению, но и по структуре:

match hashmap.get(&key) {
    Some(value) => do_something_with(value),
    None => { panic!("Oh noes!"); },
}

Разумеется сравнением дело не ограничивается. Как вы можете видеть в примере выше, объекты так же могут быть деструктурированы во время сопоставления (Some(value)) и их части присвоены другим переменным (value), которые могут быть далее использованы в соответствующей ветви match выражения.

Изящно, не правда ли? В Расте сопоставление с образцом это хлеб и масло не только для match, но и для for, (if) let и даже для обыкновенных аргументов функции.

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

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

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

Привет, коллеги!

Я расскажу о библиотеке для Питона с лаконичным названием f. Это небольшой пакет с функциями и классами для решения задач в функциональном стиле.

— Что, еще одна функциональная либа для Питона? Автор, ты в курсе, что есть fn.py и вообще этих функциональных поделок миллион?

— Да, в курсе.

Причины появления библиотеки

Протокол передачи гипертекста (HTTP) — это простой, ограниченный и невероятно скучный протокол, лежащий в основе Всемирной паутины. По сути, HTTP позволяет считывать данные из подключённых к сети ресурсов, и в течение десятилетий он выступает в роли быстрого, безопасного и качественного “посредника”.
В этой обзорной статье мы расскажем об использовании и преимуществах HTTP/2 для конечных пользователей, разработчиков и организаций, стремящихся использовать современные технологии. Здесь вы найдёте всю необходимую информацию о HTTP/2, от основ до более сложных вопросов.

Полгода назад на моем проекте было примерно около 0% покрытие кода юнит-тестами. Простых классов было достаточно мало, создавать для них юнит-тесты было легко, но это было относительно бесполезно, так как на самом деле важные алгоритмы находились в сложных классах. А сложные, с точки зрения поведения, классы было трудно юнит-тестировать так как такие классы были завязаны на другие сложные классы и классы конфигурации. Создать объект сложного класса и тем более его протестировать юнит-тестами было невозможно.

Некоторое время назад я прочёл "Writing Testable Code" в Google Testing Blog .

Ключевая идея в статье заключается в том, что C++ код, пригодный для юнит-тестирования, пишется совсем не так, как привычный C++ код.

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