Еще в далекие времена, когда балом смартфонов заправляли Nokia и Microsoft, возникла одна характерная особенность мобильной разработки — разношерстность устройств по характеристикам и модификациям операционок. Приходилось тестировать приложение не только на разных версиях ОС, но и на разных физических устройствах. После выхода iOS самих моделей телефонов всегда было мало, поэтому с ними проблем не возникало. А вот в мире Android проблема фрагментации встала во весь рост. Моделей на рынке тысячи, и все время появляются новые, и твое приложение или игра должны гарантированно работать на каждой из них. Добавим еще разные версии прошивок на этих моделях… И поймем, что вручную потребуется куча человеко-часов для проверки каждого релиза.

Сегодня Яндекс выложил в open source собственную библиотеку CatBoost, разработанную с учетом многолетнего опыта компании в области машинного обучения. С ее помощью можно эффективно обучать модели на разнородных данных, в том числе таких, которые трудно представить в виде чисел (например, виды облаков или категории товаров). Исходный код, документация, бенчмарки и необходимые инструменты уже опубликованы на GitHub под лицензией Apache 2.0.



CatBoost – это новый метод машинного обучения, основанный на градиентном бустинге. Он внедряется в Яндексе для решения задач ранжирования, предсказания и построения рекомендаций. Более того, он уже применяется в рамках сотрудничества с Европейской организацией по ядерным исследованиям (CERN) и промышленными клиентами Yandex Data Factory. Так чем же CatBoost отличается от других открытых аналогов? Почему бустинг, а не метод нейронных сетей? Как эта технология связана с уже известным Матрикснетом? И причем здесь котики? Сегодня мы ответим на все эти вопросы.

В статье описаны ряд моментов (количество соединений и последовательность выполнения, сторонние ресурсы в сценарии, группировка запросов), на которые стоит обращать внимание при подготовке к выполнению теста с высокой нагрузкой на Web-систему с Web-интерфейсом.

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

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

Создание прототипа адаптивной фитолампы на Arduino

Эта статья будет посвящена созданию прототипа светодиодной лампы для досветки растений. Конечно, это не просто лампа иначе зачем писать об этом на geektimes? Фитолампа управляется с помощью контроллера Arduino и имеет на борту датчик освещенности ( для адаптивной регулировки яркостью), LED драйвер для управления яркостью по средствам ШИМ, радиомодуль 433 Mhz и конечно bluetooth ( по тому что с ним все становится круче...) на самом деле для управления с телефона из разработанного приложения под Android. Также я немного затрону вопрос побора годных светодиодов, источников питания и как они себя показали на протяжении 6 месяцев эксплуатации. С момента зарождения идеи меня интересовал вопрос создания мелкосерийного производства, но об этом ниже.

Monero — краткая предыстория

Monero — это криптовалюта, запущенная 18 апреля 2014 года как форк Bytecoin. Bytecoin (не путать с Bitcoin, прим. пер.) был первой цифровой валютой, реализующей протокол CryptoNote (подробнее об этом ниже по тексту). Как только ByteCoin всплыл на форуме Bitcointalk, люди открыли для себя множество подозрительных свойств, вместе с тем фактом, что более 80% всей эмиссии были уже добыты. Таким образом, сообщество приняло решение его перевыпустить, начав с чистого листа, с нулевым премайном. Так появился Monero.

Вот что строил испанский архитектор Антонио Гауди:



Его здания описывают как «бионические дома», некоторые говорят о «летящей пластичной материи». За морем восторгов художников и дизайнеров, как мне показалось, упущена некоторая невероятная рационализация и прагматичность. Гауди был в первую очередь отличным разработчиком, математиком и геометром. Но чтобы объяснить это, сначала я покажу другую картинку:


Это два крепления. Первое производится серийно — оно просто в проектировании, просто в изготовлении, дёшево и невероятно уродливо. Второе красивое, и требует на 25% меньше материала для того, чтобы выдержать тот же вес (то есть — куда прочнее). Только его трудно рассчитать, оно будет дороже в серии — и придётся подумать.

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

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

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

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

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

• Snapshot ensembles (апрель 2017)
• FreezeOut (июнь 2017)

Известная как минимум с 19 века задача коммивояжера имеет множество способов решения и неоднократно описана. Ее оптимизационная версия является NP-трудной, поэтому оптимальное решение можно получить либо полным перебором, либо оптимизированным полным перебором — методом ветвей и границ.

Пытаясь запрограммировать алгоритм Литтла (частный случай метода ветвей и границ), я понял, что в рунете крайне трудно найти его правильное описание понятным языком и разобранную программную реализацию. Однако имеющиеся в изобилии описания обманчиво правдоподобны на данных малого размера и с трудом проверяются без визуализации.

Привет всем! Меня зовут Сергей Камардин, я программист команды Почты Mail.Ru.

Это статья о том, как мы разработали высоконагруженный WebSocket-сервер на Go.

Если тема WebSocket вам близка, но Go — не совсем, надеюсь, статья все равно покажется вам интересной с точки зрения идей и приемов оптимизации.

Расскажем о том, как устроен поиск похожих треков среди всех аудиозаписей ВКонтакте.

Зачем всё это надо?

У нас действительно много музыки. Много — это больше 400 миллионов треков, которые весят примерно 4 ПБ. Если загрузить всю музыку из ВКонтакте на 64 ГБ айфоны, и положить их друг на друга, получится башня выше Эйфелевой. Каждый день в эту стопку нужно добавлять еще 25 айфонов — или 150 тысяч новых аудиозаписей объёмом 1.5 ТБ.

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

Если научиться достаточно точно находить одинаковые (или очень похожие) аудиозаписи, можно применять это с пользой, например:

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

Не знаю, стоило ли делать отдельную заметку по оптимизации уже опубликованных алгоритмов или нужно было просто добавить в старую статью revised code. Я решил, что все же новенькое будет интереснее. Сразу должен сказать, что данная заметка предназначена не для профессиональных программистов.

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

Введение

Я потратил много времени, обсуждая онлайн паттерны использования Redux, была ли это помощь тем, кто изучает Redux в Reactiflux каналах, дискуссии о возможных изменениях в API библиотеки Redux на Github'е, или обсуждение различных аспектов Redux'а в комментариях к тредам на Reddit'е или HN (HackerNews). С течением времени, я выработал свое собственное мнение о том, что представляет собой хороший, идиоматичный Redux код, и я хотел бы поделиться некоторыми из этих мыслей. Несмотря на мой статус мейнтейнера Redux'а, это всего лишь мнения, но я предпочитаю думать, что они являются достаточно хорошими подходами.

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

Несмотря на эту простоту, или, возможно, вследствие ее, существует широкий спектр походов, мнений и взглядов о том, как использовать Redux. Многие из этих подходов широко расходятся с концепциями и примерами из документации.

В то же время, продолжаются жалобы на то, как Redux «заставляет» вас делать вещи определенными способами. Многие из этих жалоб на самом деле включают концепции связанные с тем, как Redux обычно используется, а не фактическими ограничениями наложенными самой библиотекой Redux. (Например, только в одном недавнем HN треде я видел жалобы: «слишком много шаблонного кода», «константы action'ов и action creator'ы не нужны», «я вынужден редактировать слишком много файлов чтобы добавить одну фичу», «почему я должен переключаться между файлами чтобы добраться до своей логики?», «термины и названия слишком сложны для изучения или запутанны», и слишком много других.)

В одном из наших первых постов мы рассказывали, что блокчейн представляет собой децентрализованную систему, работа которой поддерживается множеством компьютеров, объединенных в сеть. Блокчейн, хотя и обладает определенного рода недостатками (ограниченной скоростью работы, по сравнению с централизованными базами данных, а также высоким энергопотреблением — в случае блокчейнов на основе доказательства работы), все равно остается безопасным и надежным решением. Поэтому к этой технологии присматриваются разного рода финансовые институты, банки и даже гиганты IT-индустрии (IBM, Cisco и Intel).

В 1994 году криптограф Ник Сабо (Nick Szabo) предложил использовать компьютеры и криптографию для автоматического выполнения и аудита контрактов. Позднее это привело к появлению так называемых умных контрактов, или просто смарт-контрактов. Такие контракты оформляются в виде кода, а затем сохраняются в системе, где за их выполнением следит сеть компьютеров, управляющая блокчейном. О них мы и поговорим в нашем сегодняшнем материале.

Как Alexion зарабатывает столько денег, если её главное лекарство помогает менее чем 11 000 людей?

Керри Оуэнс, доктор из Оклахома-Сити, специализирующаяся на проблемах с почками, была ошарашена звонком, поступившим на её мобильный телефон в сентябре 2015 года. Они с командой специалистов лечили женщину, ставшую недавно матерью, из близлежащего городка Инид, чьё здоровье начало ухудшаться после родов. Доктора проводили бесчисленное количество тестов, но не могли определить причину проблем. Какое-то время они волновались по поводу того, что это может оказаться чрезвычайно редкое и смертельное заболевание крови, атипичный гемолитико-уремический синдром (аГУС), от которого каждый год страдает 1 из 500 000 человек. Они прописали пациенту лекарство "Солирис" [с действующим веществом экулизумаб], которое совсем недавно было одобрено для применения. Но её здоровье продолжало ухудшаться, и они прекратили применение лекарства.

Ранее мы, Smart Engines, уже писали про наши технологии распознавания (паспорта РФ, банковских карт и многих других). Основной ценностью SDK является "ядро" или "движок" распознавания Smart IDReader, который объединяет функциональность сканирования всего, что мы умеем сканировать, под единым интерфейсом.

Библиотека распознавания написана на С++ для достижения максимальной производительности, но для использования с различными языками программирования у нас есть версии интерфейсов библиотеки на C++, C, C#, Objective-C, Java и даже Visual Basic. Мы поддерживаем все популярные операционные системы: iOS, Android, Windows, Linux, MacOS, Solaris и, разумеется, Эльбрус и AstraLinux. Наши алгоритмы оптимизированы под такие архитектуры, как ARMv7-v8, AArch64, x86, x86_64, SPARC, E2K.

Мы решили выложить демо-версию нашего SDK на Github, чтобы вы могли ознакомиться с интерфейсом библиотеки (как Objective-C часть, так и C++), почитать документацию и попробовать встроить Smart IDReader в ваше приложение. Репозиторий с демо-версией Smart IDReader iOS SDK доступен по ссылке: https://github.com/SmartEngines/SmartIDReader-iOS-SDK

Чтобы посмотреть, как Smart IDReader выглядит в нашем исполнении после встраивания, вы можете скачать бесплатные полные версии приложений из App Store и Google Play.

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

Часть 3: Yubikey 4 и LUKS

Введение

В статье рассматривается реализация двухфакторной аутентификации с помощью ключа Yubikey 4 для монтирования зашифрованного раздела LUKS.

Процесс реализации двухфакторной аутентификации с помощью ключа Yubikey 4 для монтирования зашифрованного раздела LUKS можно разбить на три части:

1. Подготовка LUKS раздела.
2. Подготовка к использованию ключа Yubikey 4 в операционной системе.
3. Непосредственно использование ключа Yubikey 4 для двухфакторной аутентификации.

Начальные условия:

• Linux Mint 18 Sarah 64-bit
• Yubikey 4

Официальный репозиторий проекта был запущен буквально пару дней назад. Расскажем немного подробнее об этой новости и приведем полезные источники по теме.

При разработке нового дизайна для стандарта MINI-ITX, мы сделали акцент на строгом внешнем виде, добавили немного геймерской агрессивности, чуть-чуть винтажности и элегантности. Все это вылилось в симметричные линии в очень компактном размере. Мы сразу отказались от рамной конструкции, сделав дизайн монолитным, где каждая деталь вытачивается на станке с ЧПУ и являет собой жесткую основу, крепежные и декоративные элементы. Благодаря этому стало возможным применить более эффективный воздухообмен и замечательную финишную обработку. Такой дизайн обеспечивает отличную жесткость всей конструкции, защиту от вибраций и внешних воздействий, таких как попадание жидкостей и мелких металлических предметов внутрь, что полностью соответствует Европейскому стандарту для корпусов персональных компьютеров, в которых используются внутренние блоки питания.