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

Вводные.

1. Комар типичный русский может летать на 100 метров, а отдельные виды летают на запах до 5 километров, что акула. Это значит, что для того, чтоб у вас не было комаров, комаров не должно быть в радиусе 100 метров.
2. Комар плодится каждые 5 дней. Поэтому, если в сутки уничтожается менее 1/5 популяции комаров, то методы будут бесполезны.
3. Комарам нужно много воды. Они живут возле заболоченых мест, либо там где вода. На участках они обычно вылетают вечером после жаркого дня, когда выпадает роса — чтоб напиться.

Методики уничтожения комаров

Чуть больше месяца назад мы выпустили iOS-приложение «Тинькофф Инвестиции». Приложение полностью написано на языке Swift, но имеет некоторые Objective-C-зависимости. Продукт быстро начал обрастать новой функциональностью, а вместе с тем время сборки проекта существенно увеличивалось. Когда мы пришли к тому, что после clean или значительных правок проект собирался дольше шести минут, мы осознали, что перемены необходимы.


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

Многие уже наслышаны о производительности СУБД Tarantool, её возможностях и особенностях. Например, у него есть классное дисковое хранилище — Vinyl, кроме того, он умеет работать с JSON-документами. Но в многочисленных публикациях обходят стороной одну важную особенность. Обычно БД рассматривают просто как хранилище, но всё же отличительная черта Tarantool — это возможность писать код внутри и очень эффективно работать с этими данными. Под катом рассказ, как мы строили одну систему почти полностью внутри Tarantool, написанный в соавторстве с Игорем igorcoding Латкиным.

Сейчас у нас в Одноклассниках есть четыре географически распределённых дата-центра, 11 тыс. серверов, более 1 тыс. сетевых устройств, 180 сервисов. Под сервисами мы понимаем фото, видео, музыку, ленту и т. д. Ежедневно сайт посещают десятки миллионов уникальных пользователей. И за всем этим хозяйством необходимо следить, чем и занимаются:

• команда инженеров, которая устанавливает оборудование, меняет диски, решает hardware-инциденты;
• команда мониторинга, которая как раз ищет эти инциденты и отдаёт в работу другим командам;
• сетевые администраторы, они работают с сетью, настраивают оборудование;
• системные администраторы, они администрируют и настраивают портал;
• разработчики.

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

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

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

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

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

Всё началось с того, что жена захотела повесить кормушку для птиц. Идея мне понравилась, но сразу захотелось оптимизировать. Световой день зимой короткий — сидеть днём и смотреть на кормушку времени нет. Значит нужно больше Computer Vision!



Идея была простой: прилетает птичка — вжуууух — она оказывается на телефоне. Осталось придумать как это сделать и реализовать.
В статье:

• Запуск Caffe на Raspberry Pi B+ (давно хотел это сделать)
• Построение системы сбора данных
• Выбор нейронной сети, оптимизация архитектуры, обучение
• Оборачивание, выбор и приделывание интерфейса

Все исходники открыты + описан полный порядок развёртывания получившейся конструкции.

Привет всем, я — сорокалетний программист-самоучка, а это моя история.

Пару недель назад я наткнулся на график распределения людей, интересующихся технологиями, ИТ и программированием. И он заставил меня задуматься о моей карьере.



Через каких-то 20 лет мне стукнет 60. И вероятность того, что я еще смогу заниматься тем, для чего был создан, составляет очень крошечную величину. Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 1990 году, через год после того, как мне на 14-тилетие родители подарили ПЭВМ «Микроша».

Четыре месяца назад у меня появилась идея написать Telegram-бота, который будет запускаться не на внешнем сервере, как большинство ботов, а на мобильном телефоне.

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

Две недели назад, 5 октября, состоялась восьмая встреча Rambler.iOS, которую мы предварительно анонсировали на Хабре. В этот раз основной акцент был сделан на контенте самой конференции — мы подготовили четыре крутых доклада, в том числе один от иностранного докладчика.

На недавнем DroidCon Moscow 2016 был доклад о MVVM c Databinding Library и доклад о библиотеке Moxy, помогающей работать с MVP. Дело в том, что за последние полгода мы успели опробовать оба подхода на живых проектах. И я хочу рассказать о своём пути от освоения Databinding Library и выпуска в продакшн проекта на MVVM до осознания, почему я больше не хочу использовать этот паттерн.

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

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

Как правило, статьи о кешировании начинаются за здравие, а заканчиваются LRU кешем. Попробуем переломить эту тенденцию? Начнем с того, чем LRU плох, а закончим за здравие. Я надеюсь.

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

А нужен ли PCI DSS?

Рано или поздно большинство владельцев и разработчиков интернет-магазинов и мобильных приложений, принимающих платежи в онлайне, задаются вопросом: «должен ли мой проект соответствовать требованиям стандартов PCI DSS?».

PCI DSS — это стандарт безопасности, который применяется для всех организаций сферы обработки платежных карт: торговых точек, процессинговых центров, финансовых учреждений и поставщиков услуг, а также других организаций, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.

Стандарт PA-DSS распространяется на поставщиков приложений и иных разработчиков приложений, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.

С веб-сайтом все довольно просто: при интеграции достаточно воспользоваться техническим решением, которое перенаправляет плательщика на форму ввода данных карты, расположенной на сайте PCI DSS сертифицированного платежного шлюза или загружает эту страницу во фрейме также с сертифицированного сайта. В этом случае торговец не подпадает под действия стандарта безопасности, так данные карты не хранятся и не передаются через его сервера, а к фрейму платежного шлюза сайт торговца не имеет доступа в силу политик безопасности web-браузеров.

С мобильным приложением все немного сложнее.

В 2014 году по информации Smart Insights количество пользователей мобильных приложений превысило число пользователей десктопных. Одним из наиболее популярных инструментов для сбора статистики приложений на мобильных устройствах является Flurry. Инструмент полностью бесплатен, доступен для основных мобильных платформ и имеет мощный функционал. Вот основные показатели, которые предоставляет данный инструмент:

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

Мы испольуем Flurry в мобильных версиях ICQ. Но он не предоставляет ни инструментария, ни открытого API для сбора статистики для десктопных приложений. Поэтому мы решили адаптировать возможности Flurry для десктопной версии нашего приложения.



В сети была найдена Flurry SDK для платформы BlackBerry. Компания Flurry предоставляет данную библиотеку по запросу на электронную почту. Интегрироваться с библиотекой для BlackBerry не удалось, исходные коды также не были найдены. Но был найден другой путь.

Писать многопоточные приложения нелегко. Некоторые средства статического анализа кода позволяют помочь разработчикам, давая возможность чётко определить политики поведения потоков и обеспечить автоматическую проверку выполнения этих политик. Благодаря этому появляется возможность отлавливать состояния гонки потоков или их взаимной блокировки. Эта статья описывает инструмент анализа потокобезопасности С++ кода, встроенный в компилятор Clang. Его можно включить с помощью опции командной строки −Wthread−safety. Данный подход широко распространён в компании Google — полученные от его применения преимущества привели к повсеместному добровольному использованию данной технологии различными командами. Вопреки популярному мнению, необходимость в дополнительных аннотациях кода не стала бременем, а наоборот, дала свои плоды выражающиеся в упрощении поддержки и развития кода.

Предисловие

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

Средства статического анализа кода помогают разработчикам определить политики потокобезопасности и проверять их при сборке проекта. Примером таких политик могут быть утверждения «мьютекс mu всегда должен использоваться при доступе к переменной accountBalance» или «метод draw() должен вызываться только из GUI-потока». Формальное определение политик даёт два основных преимущества:

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

Данная статья рассказывает о применении данного подхода в Clang, хотя изначально он был разработан для GCC, однако версия для GCC более не поддерживается. В Clang данная возможность реализована как предупреждение компилятора. В Google на данный момент вся кодовая база C++ компилируется с включенным по умолчанию анализом потокобезопасности.

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

Нет нужды описывать чем хорош pattern matching. Так как в любом случае такой конструкции в С++ нет.
Без него же работа с шаблонами, часто обрастает лесами понятного и полезного кода.
Итак предлагаю способ некоего подобия pattern matching`а для С++14 (скорее даже type matching'a), который укладывается в 50 строк кода, не использует макросы и вообще кросс-компиляторный.

Сначала пример использования: http://coliru.stacked-crooked.com/a/6066e8c3d87e31eb

template<class T>
decltype(auto) test(T& value) {
    return match(value
        ,[](std::string value)    { cout << "This is string"; return value + " Hi!"; }
        ,[](int i)                { cout << "This is int";    return i * 100; }
        ,[](auto a)               { cout << "This is default";return nullptr; }
    );
}

compile-time Условия: http://coliru.stacked-crooked.com/a/ccb13547b04ce6ad

match(true_type{}
         ,[](bool_constant< T::value == 10 >)                        { cout << "1" ; }
         ,[](bool_constant< (T::value == 20 && sizeof...(Args)>4) >) { cout << "2" ; }
    );

Возвращаем тип: http://coliru.stacked-crooked.com/a/0a8788d026008b4b

auto t = match(true_type{}
           ,[](is_same_t<T, int>) -> type_holder<short>  { return{}; }
           ,[](auto)              -> type_holder<T>      { return{}; }
         );

using I = typename decltype(t)::type;             
I i = 1000000;

В последнее время много разговоров идет о том, что для C++ нужен свой пакетный менеджер подобный pip, npm, maven, cargo и т.д. Все конкуренты имеют простой и стандартизированный механизм подключения нестандартной библиотеки. В C++ же все действуют как умеют: кто-то прописывает в README список пакетов для Ubuntu, CentOS и других дистрибутивов, кто-то использует git submodule и скрипты для их сборки, кто-то использует CMake ExternalProject, кто-то копирует все исходники в один гигантский репозиторий, кто-то делает образ Docker или Vagrant.

Чтобы решить проблему был даже создан стартап — biicode, но он обанкротился и его будущее неизвестно. Взамен появился conan, дополняя зоопарк конкурентов — nuget, cget, hunter, cpm, qpm, cppget, pacm и даже gradle for c++.

Меня не устраивал ни один из перечисленных способов. Я было начал писать пакеты для Conan, но столкнулся с большим числом хаков, неразвитым API, отсутвием гайдлайнов и, как следствие, низкой вероятностью переиспользования чужих пакетов. И тут вспомнилось, что когда-то мне очень понравились идеи пакетного менеджера в NixOS. И подумал — а зачем плодить пакетный менеджер специально для C++, если те же задачи решает обычный пакетный менеджер? Нужно только чтобы он был достаточно гибким и простым в части описания пакета. И Nix идеально подошел на эту роль.

Фильтр Блума представляет собой структуру данных, которая может эффективно определить является ли элемент возможным элементом набора или определенно не относится к нему. Эта статья продемонстрирует простую реализацию фильтра Блума в C++.

Заинтересовавшись темой функционального программирования я встал на распутье, — какой фреймворк выбрать для ознакомления. ReactiveCocoa — ветеран в iOS кругах, по нему вдоволь информации. Но он вырос с Objective-C, и хотя это не является проблемой, но все же в данный момент я в основном пишу именно на Swift, — хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка. RxSwift же порт Reactive Extensions, имеющего долгую историю, но сам порт свежий и написанный именно под Swift. На нем я и решил остановиться.
Но специфика документации по RxSwift в том, что описание всех команд ведет на reactivex.io, а там в основном дается общая информация, руки у разработчиков не дошли еще сделать документацию именно для RxSwift, что не всегда удобно. Некоторые команды имеют тонкости в реализации, есть те, о которых в общей документации нет ничего кроме упоминания.
Прочитав все главы вики с RxSwift гитхаба, я сразу решил поразбираться с официальными примерами, тут то и стало ясно, что с RX такое не пройдет, нужно хорошо понимать основы, иначе будешь как мартышка с копипастом гранатой. Я начал разбирать самые сложные для понимания команды, потом те, что вроде понятны, но задав себе вопросы по ним я понял, что лишь догадываюсь на то как верно ответить, но не уверен.
В общем ничтоже сумняшеся я решил проработать все операторы RxSwift. Лучший способ что то понять в программировании — запустить код и посмотреть как он отработает. Затем учитывая специфику реактивного программирования — очень полезны схемы, ну и краткое описание на русском. Закончив сегодня работу, я подумал, что грех не поделиться результатами с тем, кто лишь присматривается к теме реактивного программирования.
Много картинок и текста под катом, очень много!