Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.

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

Систему сбора и анализа событий можно обобщённо назвать кликстримом. Расскажу о технической стороне кликстрима в Авито: устройство событий, их отправка и доставка, аналитика, отчёты. Почему хочется своё, если есть Google Analytics и Яндекс.Метрика, кому портят жизнь разработчики кликстримов и почему go-кодеры не могут забыть php.

У разработчика, который впервые столкнулся с генерированием электронных писем, практически нет шансов написать приложение, которое будет делать это корректно. Около 40 % писем, генерируемых корпоративными приложениями, имеют те или иные нарушения стандартов, и, как следствие, проблемы с доставкой и отображением. На это есть причины: электронная почта технически гораздо сложнее, чем веб, работа почты регулируется несколькими сотнями стандартов и несчетным количеством общепринятых (и не очень) практик, а почтовые клиенты отличаются разнообразием и непредсказуемостью. Тестирование может заметно улучшить ситуацию, но материалов, посвященных тестированию почты, практически нет.

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

• Какие бывают электронные письма
• Кто участвует в процессе тестирования и контроля
• Почтовое сообщение и почтовый транспорт
• Интерфейс почтовой инфраструктуры и границы тестируемого приложения
• Определение тестируемых параметров
• Типичная структура генерирующего приложения
• Что и когда тестировать
  
  1. Инфраструктура доставки
  2. Генерирующее приложение
  3. Структурный и вёрсточный шаблоны письма
• Базовые требования при проверке инфраструктуры
• Требования к авторизации
• Проверка генерирующего приложения
  
  • Требования к почтовым адресам
  • Требования к заголовкам писем
  • Требования к структуре письма
  • Требования к URI
  • Требования к вёрстке письма
• Проведение сплит-тестов

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

Итак, задача: необходимо поднять окружение разработчика для одновременной работы с несколькими веб-проектами висящими на доменах вида example.app. При этом данные домены должны быть доступны из контейнеров, с хоста, а также, например, из эмулятора Genymotion. Кроме того, из контейнеров должен быть доступен и внешний интернет. Все это усугубляется корпоративным Intranet со своим внутренним DNS сервером.

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

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

Ого! Как много информации.

1 июня 2016 года Instagram отключит от своего API все приложения, которые не прошли модерацию. Что делать если вы в их числе?

Предыстория

Мы делаем сервис для постинга в Instagram по расписанию и используем API для получения информации об аккаунтах. Самим постингом занимаются телефоны в автоматическом режиме. Нам отказали в доступе к API после 1 июня (пробовали пройти модерацию два раза) поэтому было решено найти замену.

Сначала расскажу как мы использовали официальный API:

1. При добавлении аккаунта забираем из Instagram информацию об аккаунте: имя, фото профайла, количество постов, подписчиков, подписок.
2. Перед тем как опубликовать фото/видео мы запрашиваем количество постов, и тоже самое после публикации, если число постов увеличилось считаем публикацию успешной.
3. Если публикация прошла успешно забираем ссылку на последнее фото в профайле.
4. Если пользователь удаляет фото из нашего сервиса, то перед тем как выполнить задачу нужно проверить существует ли такой пост в Instagram (или его удалили).

Реализация

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

В нашем блоге на Хабре мы описываем любопытные схемы модернизации корпоративной телефонии, которые можно выстроить с помощью FMC-технологий, облачной АТС и интеграций с CRM-системами. Судя по тому, что почти половина наших клиентов интересуется именно интеграционными решениями, а белоснежные облака в первозданном виде только телефонного SaaS уже мало кому интересны, мы точно угадали тренд на рынке VoIP и двигаемся в верном направлении. Обычно интеграции телефонии, облачной АТС и мобильной связи — удел, как минимум, малого и среднего бизнеса и мы тоже так считали до недавнего времени, пока не выяснилось, что IP SIM-карты, виртуальная АТС и чудеса VoIP могут поработать и на микро бизнес. На бизнес, где предприниматель “one men show” и “швец и жнец и на дуде игрец”, где продажи строятся на продвижении товара через бесплатные объявления, входящие звонки от клиентов по всей РФ. Другими словами, сегодня расскажем о том, что мы придумали в помощь предпринимателям, зарабатывающим на продажах через доски объявлений.

Для кого эта статья?

В основном статья для технических лидеров команд разработчиков ПО и тех, кто стремится ими стать. И, конечно, для остальных, кого заинтересовала тема.  Для тех, кому интересно мнение относительно роли технического лидера, и для тех, кто готов делиться собственными соображениями на этот счет.

Что будет обсуждаться далее? В основном, это будут мысли на тему роли технического лидера, важных моментов в его работе, а также совсем немного про архитектуру и модульность.

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

Как грибы растут стандарты, фреймворки, развивается и становится всё слаще синтаксис, растут разнообразные инструменты.

И это здорово!

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



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

Тест, разумеется, пятничный и шуточный. Но в нём всё-таки есть доля истины.

Вот вы там все сидите и ничего не знаете, а мы, тем временем, пилим помаленьку мега-релиз поискового движка Sphinx за номером 3.0. Грядет ряд больших переделок. Часть из них, как полагается, ещё даже как следует не начата. Однако большая часть уже скорее готова, чем нет. А отдельно взятые изменения даже протекли в публичную ветку 2.3. Так что, пожалуй, настало время вкратце начинать рассказывать, чего ожидать в светлом будущем: надеюсь, не столь отдалённом. Кому интересно почитать, все под кат; кому послушать, приходите на meetup в эту субботу. Если совсем вкратце, то: прощай, концепция дополняющего основную базу движка; привет, хранилище документов, тотальный RT, репликация, REST и ряд других известных ключевых слов.

Настанет день, и ты поймешь, что одного потока в PHP тебе мало.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости.

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

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



Однако всегда хочется лучшего. Одна из главных проблем, с которыми мы сталкиваемся при общении с владельцами зараженных сайтов, — это поиск источника заражения на стороне сервера. У Яндекса, который каждые сутки размечает тысячи сайтов как зараженные вирусом и опасные для устройств человека, есть регулярно обновляемая база вирусов. И у нашей команды появилась идея, выросшая в большой проект, – антивирус для сайтов. Так мы создали Manul, который решили выложить в open source. Это утилита, которая поможет вебмастеру понять, что произошло с сайтом и вылечить его. Под катом я расскажу подробнее о том, как он устроен и какие проблемы решает.

Здравствуйте. Думаю, что большинство веб-программистов знает, как работает php-интерпретатор.

Для тех, кто не знает:
Вначале, написанный нами код разбирается лексическим анализатором. Далее, полученные лексемы, передаются в синтаксический анализатор. Если синтаксический анализатор дал добро, то лексемы передаются транслятору, а он, в свою очередь, генерирует так называемые opcodes (operation codes). И только после этого, в дело вступает виртуальная машина PHP (та самая Zend Engine) которая и выполняет наш алгоритм из получившихся opcodes. Opcodes так же называют эдаким php-шным ассемблером.
Данная статья расскажет вам о том, какие opcodes и в каких случаях генерируются. Конечно, рассказать про все opcodes в рамках одной статьи не получится, но в данной статье будет рассмотрен конкретный пример и на его основе мы попытаемся разобраться что к чему у этих opcodes. На мой взгляд, самое главное, что вы узнаете прочитав статью, это то, как на самом деле происходит выполнение ваших исходных текстов и, возможно, это поможет вам в лучшем понимании языка php.

Советую вам налить себе чашечку капучино или просто зеленого чая, т.к. под катом листинги opcodes и php-кода…

Я расскажу о том, как мы с releu придумали, сделали и развиваем сервис мини-уроков английского языка, которым пользуются уже 4000 человек каждый день. Для затравки рост числа активных пользователей:

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

Но, как и любая платформа, Node.js не застрахован от ошибок самих разработчиков. В одних случаях падает производительность, в других — система становится практически непригодной к использованию. И в этом посте я хотел бы рассмотреть 10 наиболее частых ошибок, которые делают разработчики с недостаточным опытом работы с Node.js.

Сегодня объекты используются очень активно, хотя это трудно было предположить после выхода PHP 5 в 2005 году. Тогда я ещё мало что знал о возможностях этого языка. Пятую версию PHP сравнивали с предыдущей, четвёртой, и главным преимуществом нового релиза стала новая, очень мощная объектная модель. И сегодня, десять лет спустя, около 90% всего PHP-кода содержит объекты, не изменившиеся со времени PHP 5.0. Это убедительно говорит о том, какую роль сыграло внедрение объектной модели, неоднократно улучшавшейся на протяжении последующих лет. В этом посте я хотел бы рассказать о том, как всё устроено «под капотом». Чтобы люди понимали суть процессов — почему сделано так, а не иначе — и лучше, полнее использовали возможности языка. Также я затрону тему использования памяти объектами, в том числе в сравнении с эквивалентными массивами (когда это возможно).

Я буду рассказывать на примере версии PHP 5.4, и описываемые мной вещи справедливы для 5.5 и 5.6, потому что устройство объектной модели там почти не претерпело изменений. Обратите внимание, что в версии 5.3 всё не так хорошо с точки зрения возможностей и общей производительности.

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

Сегодня мы поговорим о «низкоуровневых» кирпичиках нашего проекта — о демонах.
Хоть это и не очевидно, но практически весь функционал сайта во многом зависит от работы этих программ. Игра в “Знакомства”, поиск новых лиц, центр внимания, обмен сообщениями, статусы, геолокация и многие другие вещи завязаны на тот или иной демон. Так что можно сказать, что они помогают людям по всему миру общаться и находить новые знакомства. Одновременно на сайте могут работать и взаимодействовать между собой несколько десятков демонов. Их корректное поведение является очень важной задачей, поэтому мы решили покрывать основной функционал демонов автотестами.

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

В качестве VCS у нас используется Git, для непрерывной интеграции — TeamCity, а в роли баг-трекера выступает JIRA. Для тестирования мы используем PHPUnit. Разработка демонов, как и остального сайта, ведется по принципу «фича ― ветка». Для того чтобы понять, что это, мы рассмотрим проекции нашего flow на Git и на JIRA.

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?

Докер — это открытая платформа для разработки, доставки и эксплуатации приложений. Docker разработан для более быстрого выкладывания ваших приложений. С помощью docker вы можете отделить ваше приложение от вашей инфраструктуры и обращаться с инфраструктурой как управляемым приложением. Docker помогает выкладывать ваш код быстрее, быстрее тестировать, быстрее выкладывать приложения и уменьшить время между написанием кода и запуска кода. Docker делает это с помощью легковесной платформы контейнерной виртуализации, используя процессы и утилиты, которые помогают управлять и выкладывать ваши приложения.

Сегодняшняя статья будет про уведомления об изменениях в задачах Redmine. О том, какие средства есть в коробочном Redmine и о том, что мы доработали сами.

Любой task-трекер имеет средства уведомления об изменениях в задачах, и Redmine — не исключение.