Это первый пост из блога Surfingbird, который я выношу в общие хабы алгоритмов и искусственного интеллекта; честно говоря, раньше просто не догадался. Если интересно, заходите к нам, чтобы прочесть предыдущие тексты, – я не знаю, что произойдёт, если просто добавить новые хабы к постам несколькомесячной давности.

Краткое содержание предыдущих серий о рекомендательных системах:

• рекомендательные системы: постановка задачи;
• user-based и item-based коллаборативная фильтрация;
• SVD, часть I;
• SVD и базовые предикторы;
• SVD на Perl;
• оверфиттинг и регуляризация;
• теорема Байеса и наивный Байес;
• LDA (Latent Dirichlet allocation, тематическое моделирование).

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

Игра Oil Rush

В данной статье, состоящей из двух частей, речь пойдёт об использовании возможностей процедурных генераторов при создании контента для компьютерной игры Oil Rush и бенчмарка Valley (выйдет в феврале), разработанных на нашем собственном движке Unigine.

Исследователи разработали программное обеспечение, которое предсказывает, когда и где могут возникнуть вспышки болезней, основываясь на двадцатилетнем архиве статей New York Times и других интернет-данных, сообщает Mashable. Авторами разработки являются Microsoft и Технион — Израильский технологический институт.

Система показывает поразительные результаты при тестировании на исторических данных. Например, сообщения о засухе в Анголе в 2006 году вызвали предупреждение о возможной вспышке холеры в стране, потому что предыдущие события научили систему, что вспышки холеры более вероятны в годы после засухи. Второе предупреждение о холере в Анголе было вызвано новостями о бурях в Африке в начале 2007 года; менее чем через неделю появились сообщения о том, что в регионе действительно распространилась холера. В подобных испытаниях, связанных с прогнозированием болезней, насилия и значительного числа смертей, предупреждения системы были правильными в 70—90 % случаев.

В свет вышла обновленная карта интернет-магистралей от TeleGeography. На ней изображены 244 системы кабелей. Также на карте представлены инфографики о пинге, пропускной способности и истории развития сети, которая берет свое начало в 1997. Немного подробностей из блога компании +хайрез для печати — под катом.

Исторически в Почте Mail.Ru использовался механизм от «большого» Поиска (go.mail.ru); однако для задач поиска по почтовым ящикам такой вариант не был оптимальным ввиду большого потребления ресурсов и относительной сложности в обслуживании. Поиском по почте пользуются около 3% владельцев почтовых ящиков; однако, хотя эта цифра кажется относительно небольшой, ящики этих людей обычно достаточно объемны, и поиск им действительно необходим. Поэтому мы приняли решение написать специализированный поисковый демон, который будет заниматься именно поиском по почте. Основными требованиями к нему стали ограничения по потребляемым ресурсам (размер индекса — не более 3% от размера почтового ящика, среднее потребление оперативной памяти — не более 100 Мб, средняя утилизация CPU — не более 3%) и скорости исполнения запросов (среднее время — не более 200 мс). О том, как он был организован, я расскажу ниже.

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

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

До весны 2012 года у нас вместо такой базы существовали две базы данных разного уровня — со стороны спайдера, который имел свою собственную базу URL-ов, и со стороны индексатора. Это было крайне неудобно: допустим, если пользователь жаловался, что его сайт не индексируется, то для того, чтобы найти причину, при старой архитектуре пришлось бы анализировать массу данных. На это требовалось день-два, иногда даже неделя.

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

«И эти дурацкие иконки! Пиктограмма — это знак, который ни на одном человеческом языке невозможно объяснить. Не зря же появилась речь!»
Джеф Раскин.

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

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

Что такое whois?

Что такое и для чего нужен whois можно прочитать, например, здесь: http://en.wikipedia.org/wiki/Whois.

В нескольких словах, whois (от английского «who is» — «кто такой») – сетевой протокол, базирующийся на протоколе TCP. Его основное предназначение – получение в текстовом виде регистрационных данных о владельцах IP адресов и доменных имен (главным образом, их контактной информации). Запись о домене обычно содержит имя и контактную информацию «регистранта» (владельца домена) и «регистратора» (организации, которая домен зарегистрировала), имена DNS серверов, дату регистрации и дату истечения срока ее действия. Записи об IP адресах сгруппированы по диапазонам (например, 8.8.8.0 — 8.8.8.255) и содержат данные об организации, которой этот диапазон делегирован.

«Новый год шагает по стране»

Я являюсь ярым фанатом геосоциальных сервисов. Они позволяют наглядно увидеть физическую реализацию социального пространства. Это то, о чем писал Бурдьё, но что для него было доступно лишь в виде мысленного конструкта. Foursquare вообще является моей безответной любовью. Но об этом как-нибудь в следующий раз, а сегодня поговорим о Twitter.
Незадолго до конца предыдущего, 2012-го, года мне захотелось увидеть, как выглядит «волна» новогодних твитов-поздравлений. Посмотреть, как она проходит через часовые пояса. Сказано — сделано. Использованные инструменты: R, Python и ffmpeg.

Время от времени я езжу на работу на велосипеде. Иногда на улице идёт дождь, погода «не велосипедная», и тогда возникает дилемма: немного подождать, пока он закончится, либо вообще ехать на автомобиле. Бывает и так, что с утра погода хорошая, а вечером начинает идти дождь и хочется найти «окно» для того, чтобы вернуться домой сухим. Пару раз доходило до смешного – с утра светит солнце, я выезжаю, минут через пять начинается неслабый дождик, а ещё через несколько минут он заканчивается, снова светит солнце, а я вхожу в офис мокрый до трусов.

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

Под катом мы сделаем следующее – программно загрузим карты дождя с одного из сервисов и посмотрим, что будет происходить в окрестностях определённой точки, сохранив результаты в dropbox. Нехитрое пятничное упражнение исполним, разумеется, в LabVIEW.

Привет. Как и планировалось в прошлом посте об ограниченных машинах Больцмана, в этом будет рассмотрено применение RBM для предобучения обыкновенной многослойной сети прямого распространения. Такая сеть обычно обучается алгоритмом обратного распространения ошибки, который зависит от многих параметров, и пока не существует точного алгоритма выбора этих самых параметров обучения, как и оптимальной архитектуры сети. Разработано множество эвристик, позволяющих сократить пространство поиска, а также методик оценки качества выбранных параметров (например, кросс-валидация). Мало того, оказывается, и сам алгоритм обратного распространения не так уж хорош. Хотя Румельхарт, Хинтон и Вильямс показали сходимость алгоритма обратного распространения (тут еще более математическое доказательство сходимости), но есть небольшой нюанс: алгоритм сходится при бесконечно малых изменениях весов (т.е. при скорости обучения, стремящейся к нулю). И даже это не все. Как правило, этим алгоритмом обучают небольшие сети с одним или двумя скрытыми слоями из-за того, что эффект обучения не доходит до дальних слоев. Далее мы поговорим подробнее о том, почему же не доходит, и применим технику инициализации весов с помощью обученной RBM, которую разработал Джеффри Хинтон.

Вместо предисловия

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

Перед тем как начать я хотел бы сделать акцент на двух положениях:
Первое. Мы исходим из того что читатель знаком с такими пакетами как 3D Studio MAX (либо любым другим пакетом трехмерного моделирования) и Photoshop (или любым его аналогом). В данном конкретном случае я собираюсь использовать терминологию этих двух пакетов. Однако, не смотря на это те же самые принципы можно использовать, пользуясь любым другим софтом.

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

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

Хочу также отметить, что я не причисляю себя к мастерам, которые делают шедевры. Данное примечание я делаю для тех злых людей, которые говорят (или скажут после публикации), что я заносчив, что меня занесло под небеса, и тех кто вместо того чтобы работать предпочитает злословить словно ябедник Кийр из моей любимой книги Оскара Лутса «Весна».

С преамбулами покончено перейдем к сути.

Я утверждаю и не беспочвенно, что хороший фон можно и нужно создавать не за неделю, не за пять дней и даже не за три. Чтобы сделать хорошую картинку для казуальной игры, без разницы i-spy это, match-3 или аркада, достаточно 48 часов. Разумеется, при условии того, что человек занимается работой, а не просиживанием штанов.

Доброго времени суток, Хабр!

Я — участник маленькой компании (из двух человек), которая делает живые обои (live wallpapers) для Android-девайсов. В этой статье будет рассказано о развитии наших приложений, от сравнительно простых до более сложных, примененных технологиях, трюках и решенных проблемах — все на конкретных примерах, в (почти) хронологическом порядке. Все наши обои — полностью трехмерные, написаны с использованием OpenGL ES.

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

Мы живем в удивительное время, то что раньше казалось очень сложным внезапно становится доступным и простым. Задачи для решения которых надо было создавать научные институты и крупные организации, сейчас решаются саморганизованными группами энтузиастов. Энтузиасты создают карты и энциклопедии снимают фильмы и разрабатывают software. Я хочу рассказать о той области, в которую этот свежий ветер перемен еще не подул в полную силу – это погода. И нашим проектом – OpenWeatherMap — мы хотим изменить эту ситуацию!

В субботу у меня ближе к полуночи появилось свободное время и жгучее желание сделать игрушку под браузер, забавы ради и увеличения опыта для. С жанром определился довольно быстро: т.к. на MMORPG в этот раз у меня точно не хватило бы времени, я решил делать просто мясорубку. Минут 20 ушло на написание базового кода для управления игроком и его противниками. И тут встал вопрос — 2D или 3D (вернее так: Canvas/SVG или все же полноценный WebGL)?

Как вы, возможно, слышали, в июле разработчики мобильного Jabber-клиента Xabber обещали открыть исходный код своего приложения под открытой лицензией, если наберут 50 тысяч подписчиков в твиттере. Несмотря на то, что это условие и подняло много шума в интернете, подписчиков появилось только 4,7 тысячи.

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

Всех с Новым Годом.

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

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

 

В этой статье я расскажу о внутреннем устройстве популярного сервиса облачного хранения Dropbox. В частности, будет затронуто устройство протокола Dropbox, а также показана статистика его использования в некоторых странах Европы. Кроме этого, я сравню его с другими сервисами, такими как iCloud, Google Drive и SkyDrive.

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

Текст основан на научной статье “Dropbox изнутри: Изучаем сервисы облачного хранения” (Inside Dropbox: Understanding Personal Cloud Storage Services). PDF