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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

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

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

Если вы хотите только попробовать её в работе, то можете скачать отсюда. Либо пролистайте вниз до раздела «Исходный код и использование». Хотите подробностей — читайте дальше.

Кадр из Top Gear: USA (серия 2)

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

Практически с самого начала в качестве реализации ассоциативных массивов мы использовали Judy. У неё есть C-интерфейс и множество преимуществ. Мы даже используем обёртку для PHP, так как в версиях PHP до 7.0 Judy сильно выигрывает по количеству потребляемой памяти по сравнению со встроенными мапами.

Однако время идёт, и с момента последнего релиза Judy прошло немало лет – самое время посмотреть на альтернативы.

Меня зовут Марко, я – системный программист Badoo в команде «Платформа». Мы с коллегами провели небольшое исследование в поисках альтернатив Judy, сделали выводы и решили поделиться ими с вами.

Если вы используете в своей игре спрайты с прозрачностью (а обычно так и бывает, как минимум для UI), то вам, вероятно, стоит уделить внимание к полностью прозрачным пикселям текстур (или «текселам»).

Даже если значение альфа-канала равно 0, с пикселем всё равно связано значение цвета. Этот цвет ни на что не влияет, так ведь? В конце концов, пиксель полностью прозрачен, кому есть дело до его цвета…

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

Обычно модели машинного обучения строят в jupyter-ноутбуках, код которых выглядит, мягко говоря, не очень — длинные простыни из лапши выражений и вызовов "на коленке" написанных функций. Понятно, что такой код почти невозможно поддерживать, поэтому каждый проект переписывается чуть ли не с нуля. А о внедрении этого кода в production даже подумать страшно.

Поэтому сегодня представляем на ваш строгий суд превью python'овской библиотеки по работе с датасетами и data science моделями. С ее помощью ваш код на python'е может выглядеть так:

my_dataset.
    load('/some/path').
    normalize().
    resize(shape=(256, 256, 256)).
    random_rotate(angle=(-30, 30)).
    random_crop(shape=(64, 64, 64))

for i in range(MAX_ITER):
    batch = my_dataset.next_batch(BATCH_SIZE, shuffle=True)
    # обучаем модель, подавая ей батчи с данными    

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

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

Человек издревле использовал различные приспособления для того, чтобы сделать какие-то производственные процессы более эффективными или же сделать более комфортным свое собственное существование. Настоящий прорыв случился в конце 40-х годов 20-го века, когда были изобретены транзисторы. Первыми были биполярные транзисторы, используемые до сих пор. За ними последовали МОП-транзисторы (металл-оксидид-полупроводниковые).

С каких пор программы научились выдавать себя за людей? Каким образом понять, искусная ли перед нами обманка или по-настоящему сильный ИИ? Когда программа справится с машинным переводом или напишет свой первый роман? Сергей oulenspiegel Марков, автор материала «Играть на уровне бога: как ИИ научился побеждать человека», возвращается к теме умных машин в нашей новой нейронной статье.

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

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

Об авторе. Статья основана на лекции «Искусственный интеллект. История и перспективы», проведенной в московском офисе Mail.Ru Group Сергеем oulenspiegel Марковым. Сергей Марков занимается machine learning в «Сбербанке». В банковской сфере строят предиктивные модели для управления бизнес-процессом на основе достаточно больших обучающих выборок, которые могут включать несколько сотен миллионов кейсов. Среди своих хобби Сергей указывает шахматное программирование, ИИ для игр, минимаксные задачи. Программа SmarThink, созданная Сергеем Марковым, становилась чемпионом России (2004) и СНГ (2005) среди шахматных программ (2004), и сегодня входит в топ-30 сильнейших программ в мире. Также Сергей является основателем некоммерческого научно-просветительского портала 22 век.

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

Привет! Меня давно интересовал вопрос, насколько Android есть Linux и можно ли в нем запускать терминальные (консольные) приложения, минуя песочницу под названием Dalvik.

Для этого я освоил способ создания приложений на языке C/C++ для Android с использованием Android NDK. NDK позволяет создавать как библиотеки с native-методами (C/C++) для Java, так и исполняемые приложения для запуска из командной строки.

Здесь я расскажу, как сделать первые шаги быстро и просто. Заранее оговорюсь, что Android NDK для Windows — это неудобно, поэтому далее рассматриваются OSX и Linux. Виртуалка c Ubuntu в помощь!

У нас в конторе не так давно назрела задача сделать бесшовное Wi-Fi-покрытие, долго терпели и перетаптывались, но в итоге его сделали. Поделюсь опытом, как это было. Началось с того, что два года назад мы полностью перешли на IP-АТС и почти извели аналоговые телефоны включая, в итоге и DECT. Однако, переносные трубки нужны и помимо настольных SIP-телефонов купили несколько Wi-Fi телефонов Tecom. Я и сам, как ответственный за техническую часть в компании постоянно хожу по офису с различными Wi-Fi-ными девайсами, ну и манагеры тоже. У многих на руках упомянутые Wi-Fi SIP-телефоны, + у складских пару Wi-Fi терминалов, есть просто Андроиды и Яблоки с установленными SIP-клиентами от АТС. Раньше все решалось несколькими Wi-Fi роутерами, в принципе, тоже было приемлемо (офис небольшой), но ровно пока ты сидишь на месте – пошел, все, кончился разговор, а Skype-соединение еще быстрее слетает. Это стало изрядно раздражать руководство и менеджеров и пошли наезды что вай-фай не вай-фай. Попытки просто увеличить количество роутеров ясное дело задачу не решило.

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

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

Это будет длиннопост. Я давно хотел написать этот обзор, но sim0nsays меня опередил, и я решил выждать момент, например как появятся результаты ImageNet’а. Вот момент настал, но имаджнет не преподнес никаких сюрпризов, кроме того, что на первом месте по классификации находятся китайские эфэсбэшники. Их модель в лучших традициях кэгла является ансамблем нескольких моделей (Inception, ResNet, Inception ResNet) и обгоняет победителей прошлого всего на полпроцента (кстати, публикации еще нет, и есть мизерный шанс, что там реально что-то новое). Кстати, как видите из результатов имаджнета, что-то пошло не так с добавлением слоев, о чем свидетельствует рост в ширину архитектуры итоговой модели. Может, из нейросетей уже выжали все что можно? Или NVidia слишком задрала цены на GPU и тем самым тормозит развитие ИИ? Зима близко? В общем, на эти вопросы я тут не отвечу. Зато под катом вас ждет много картинок, слоев и танцев с бубном. Подразумевается, что вы уже знакомы с алгоритмом обратного распространения ошибки и понимаете, как работают основные строительные блоки сверточных нейронных сетей: свертки и пулинг.

Всем привет!
Вы читаете вторую часть статьи про создание VST-синтезатора на С#. В первой части был рассмотрен SDK и библиотеки для создания VST плагинов, рассмотрено программирование осциллятора.
В этой части я расскажу про огибающие сигнала, их разновидности, применение в обработке звука. В статье будет рассмотрено программирование ADSR-огибающей для управления амплитудой сигнала, генерируемого осциллятором.
Огибающие есть в любом синтезаторе, применяются не только в синтезе, а повсеместно обработке звука.

Исходный код написанного мною синтезатора доступен на GitHub'е.

C утилитой для ПК и платой — программатором,
с использованием SPL,
с полноценной системой команд и проверкой CRC32,
с гарантией доставки и переотправки сбойной или потерянной команды,
с проверками ошибок, отладочными сообщениями и урезанным printf'ом.
Оптимизирован под современные USB-UART преобразователи и потоковую передачу.

Вступление

Началось все с того, что была поставлена задача отменять последнее действие в приложении при встряхивании устройства. Но как понять, что случилось это самое встряхивание? Через пару минут изучения вопроса стало ясно, что надо подписываться на события от акселерометра и дальше пытаться как-то определить, что устройство встряхнули.
Обнаружились и готовые решения. Все они были довольно похожи, но в чистом виде они меня не устраивали, и я написал собственный «велосипед». Это был класс, который подписывался на события от сенсора и менял свое состояние по мере их поступления. Потом пару раз я и мои коллеги подкручивали шестеренки этого велосипеда, и в результате он стал напоминать нечто из «Безумного Макса». Я пообещал, что, как выдастся свободное время, приведу это безобразие в порядок.

И вот, читая недавно статьи по RxJava, я вспомнил про эту задачу. «Хм, — подумал я, — RxJava выглядит очень подходящим инструментом для такого рода проблем». Не откладывая в долгий ящик, взял и написал решение на RxJava. Результат меня поразил: вся логика заняла 8 (восемь!) строк! Я решил поделиться своим опытом с другим разработчикам. Так появилась на свет эта статья.

Надеюсь, этот простой пример поможет принять решение тем, кто размышляет о применении RxJava в своих проектах.

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

Приступим!

Введение

В этой статье я расскажу, как профилировать и оптимизировать приложения на языке Go с использованием встроенных и общих инструментов, доступных в ОС Linux.

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

Я привел такое определение, чтобы сразу отсечь вопросы некорректной работы приложения. В этой статье мы не будем говорить о проблемах мультитредового программирования, о дата-рейсах (англ. data race), о поиске ошибок (англ. debugging). Для всего этого в Go есть свои утилиты и подходы, но оставим эту тему на будущее.

Введение

В Badoo несколько десятков «самописных» демонов. Большинство из них написаны на Си, остался один на С++ и пять или шесть на Go. Они работают примерно на сотне серверов в четырех дата-центрах.

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

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

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

Вчера мне довелось первым из представителей прессы побывать в компании Байкал электроникс, разработавшей и производящей процессор Baikal-T1.

Сегодня у многих IT-компаний есть собственные bounty-программы (или программы по поиску уязвимостей). Badoo — в их числе.

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

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

Мы хотим усилить интерес к ней, в том числе со стороны иностранных исследователей. Поэтому мы, во-первых, открыли страничку с нашей программой на крупнейшем портале исследователей hackerone.com, а во-вторых — увеличили суммы вознаграждений за найденные уязвимости! Теперь сумма вознаграждения, в зависимости от категории, начинается от £100 и может достигать £1000, сумма супер-премии составляет £2000 (а это более 200 000 рублей по текущему курсу!) и даже больше, если обнаруженная уязвимость представляет реальную угрозу для наших пользователей.

Мы сделали это! Несколько сотен наших application-серверов переведены на PHP7 и прекрасно себя чувствуют. Насколько нам известно, это второй переход на PHP7 проекта такого масштаба (после Etsy). В процессе мы нашли несколько очень неприятных багов в системе кеширования байт-кода PHP7, но они исправлены. А теперь — ура! — благая весть для всего PHP-сообщества: PHP7 действительно готов к продакшену, стабилен, потребляет значительно меньше памяти и дает очень хороший прирост производительности. Ниже мы подробно расскажем, как мы перешли на PHP7, с какими трудностями столкнулись, как с ними боролись и какие результаты получили.