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

Технология внутри Яндекса получила название «Сибирь». От CBIR — Content-Based Image Retrieval.

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

Для чего всё это нужно?

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

Всем привет!

Я бы хотел рассказать о проблемах, с которыми я сталкивался в процессе освоения Selenium WebDriver, c их решением и тем, как эти решения, в принципе, можно использовать. Все это представлено в виде прототипа фрэймворка, ссылка на который будет в конце статьи.

В этом посте я хочу поделиться своими идеями реализации шаблона Page Object, о том как можно обрабатывать ошибки, возникающие в процессе выполнения тестов, рассказать немного о логгинге. А так же поделиться сведениями о некоторых инструментах, которые реализованы с использованием Selenium WebDriver, и своими наработками.

План моей статьи следующий:

1. Капитан очевидность, вместо вступления.
2. Немного о себе, надо представиться…
3. Почему Selenium?
4. О Page Object…
5. Не баг, а фича!
6. И снова про логгинг и отчетность.
7. А разве нет аналогов?
8. Обещанные ссылки.
9. В заключение.

Итак, поехали!

Бенчмарк Valley

Это вторая и заключительная часть статьи, посвященной процедурным методам производства контента для 3D приложений. Первую часть Вы можете найти здесь.

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

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

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

На Хабре Swing не любят. Поиск по «Swing» дает либо нейтральные, либо негативные упоминания. Вот некоторые из них:

• «Java-апплеты (доразвивались до смертельной болезни под названием Swing)»
• «Swing — мягко говоря не самый оптимальный UI фреймворк»
• «Swing был ужасен»

Я не возьмусь утверждать, что Swing — идеал. Это неправда. Однако я постараюсь описать те плюсы и минусы с которыми пришлось столкнуться.

Разработка

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.

dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны.

Все мы ходим, о чем-то думаем…
Результат — в голову приходят различные идеи. А может наоборот?

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

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

— А что будет интересно людям?
— Много всего, но самое простое, это время.

Как это ни странно звучит, но:
Готовь елку летом… примерно так можно переделать известную поговорку.

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

Родина, с Новым Годом!



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

Мы каждый день находим недорогие билеты для наших пользователей на buruki.ru. Но как устроен рынок авиабилетов «под капотом»?

На первой ступени цепочки стоят авиакомпании — производители продукта.

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

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

TL;DR — за два года маленькая команда из 2 человек (я как «строитель», и мой московский друг как главный конструктор) сумела спроектировать раму и механику дорожного электробайка, а так же построила его первый прототип. Собственно, на КПДВ — именно этот самый прототип, да. Видео тестовых покатушек — в конце статьи.

Если вам интересна история его создания — прошу под кат.

Мифы – это попытки осмысления картины окружающего мира, присущие первобытной культуре.

Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. Оно прошло путь от каменных пещер до современных небоскребов, от сигнальных костров до мобильной связи, от навигации по звездам до навигации по космическим спутникам. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.

То, что производят программисты, нематериально – это brainware, результат коллективного мыслительного процесса проектной команды, материализованный на одном из языков программирования. Программной инженерии чуть больше полувека. Если сравнивать с материальным производством, то необходимо констатировать, что разработка ПО пребывает еще в первобытном состоянии.

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

Вот наиболее распространенные мифы и факты, которые их опровергают.

Хочу поделиться опытом изучения Tarantool. Про все преимущества и особенности самого Тарантула я писать не буду, на эту тему было много статей (например, эта, эта и эта). Этот пост рассказывает о том, как начать работать с тарантулом и про некоторые особенности и вкусности которые можно получить из коробки.

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

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

Суть их рассуждений в следующем:

1. Статической типизации недостаточно для выявления багов, поэтому необходимы модульные тесты;
2. Статическая типизация становится лишней, так как у вас есть тесты;
3. Из-за статической типизации некоторые корректные программы могут выдавать предупреждения на стадии компиляции.

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

Британская компания Imagination Technologies, недавно купившая американского разработчика микропроцессоров MIPS Technologies, к концу 2014 года выпустит новый процессор Warrior Series 5 на базе нового дизайна и для новых технологических норм.
Новинка будет охватывать каждый сегмент рынка, включая и использование в маломощных серверах (микросерверах).

Это часть более широкой инициативы по выпуску MIPS-совместимых процессоров для продуктов разного направления, в том числе: серверов, планшетов, смартфонов и носимых вычислительных устройств.
«Мы намерены привести MIPS во все сектора рынка, где в принципе применяются процессоры», — заявил CEO Imagination Хоссейн Яссай.

Новая технология от MIT позволяет смоделировать 3D-карту местности/помещения с помощью обычной видеокамеры.

Суть в том, что обычная камера снимает окружение и запоминает его с помощью специального алгоритма. Как только камера после своего кругового путешествия возвращается к начальной точке маршрута, алгоритм понимает, что это одно и то же место, и быстро «сшивает» концы пространства, образуя связную 3D-карту.

Введение

Нормальной русскоязычной информации по теме просто нет. Java-tutorials тоже оставляют желать лучшего. А архитектура javax.sound.sampled хоть и проста, но далеко не тривиальна. Поэтому свой первый пост на Хабре я решил посвятить именно этой теме. Приступим:

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

Честно говоря, над “позитивным” ракурсом я и не подумал бы, если б не письмо Alex_Mukh. Он умудрился поделиться опытом весьма сочно и веско. К сожалению, Alex не имеет достаточно кармы, чтобы написать даже коммент (намекаю на возможные аплодисменты ему как соавтору), потому текст его письма я разодрал на цитаты и разместил по своим виршам ниже.

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

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

На Хабре я недавно (чуть меньше месяца), до этого Хабр практически не читал. Пришёл, огляделся, походил по тематическим «хабам», почитал «Лучшее за всё время», просмотрел статьи отдельных, заинтересовавших меня персонажей и понял, что для того, чтобы получше понять, как живёт и чем дышит это замечательное сообщество, мне придётся Хабр распарсить и позадавать ему разные вопросы. К тому же, раз уж в своих статьях я писал в основном об автореферентности в разных её проявлениях, как не написать на Хабре статью о Хабре?

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

Если я ничего не пропустил в интерфейсе сайта, единственные списки самых-самых, которые можно посмотреть — это общий рейтинг пользователей и список статей, т.н. «Лучшее за всё время». Оба списка отсортированы по рейтингу (пользователей и статей, соответственно). Между тем, существует ещё куча параметров, по которым было бы интересно всё отранжировать.

История с утекшими исходниками драйвера exFAT для ядра Linux неожиданно получила вполне логичное завершение. Так как этот драйвер был создан на основе других наработок opensource- сообщества, лицензия кода которых требует раскрытия исходников производных продуктов, компании Samsung ничего не оставалось как официально опубликовать открытый драйвер exFAT. Вопрос лицензионной чистоты использования этого драйвера в коммерческих продуктах остается открытым ввиду наличия у Microsoft соотвествующих патентов.

Скачать исходники можно здесь — opensource.samsung.com, введя поисковый запрос exfat.

Нью-Йоркский программист Патрик Макконлог проводит интересный социальный эксперимент. Каждый день, идя на работу по городу, он видит многочисленных бомжей, и поневоле задается вопросом: что если многие из этих людей — не на своем месте, и могли бы жить более достойно при других обстоятельствах? Он решил поставить опыт, что бы выяснить это.

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

Рассуждаю я примерно так.

Сколько же надо платить программисту? Как правило, рыночная «вилка» вознаграждения для конкретной квалификации известна и составляет от X до 1.5*X. Можно рискнуть и платить по нижней планке — X. Однако, возможность получать в 1.5 раза больше за ту же работу скорее всего перевесит все остальные мотивы, которые удерживают бойца в моей команде. Ситуация усугубляется еще и тем, что агрессивные «охотники за головами» делают разрыв в вилке еще больше, чтобы побыстрее перекупить квалифицированные кадры. Надо ли платить по верхней планке, тем более, если она сильно завышена? А, может быть, следует платить еще больше?

Заранее, приношу свои извинения, за занудность и излишнюю детальность нижеследующего изложения в стиле — «как для домохозяек». Я много раз пытался объяснять свое видение подхода к решению этого вопроса людям, которые должны были принимать решение о повышении оклада, но они не всегда меня понимали. Или, может, просто, не хотели?