Исследователь Кавел Литару, из Джордтаунского университета, собрал каталог из 250 миллионов событий произошедших в мире с 1979, который ежедневно обновляется и доступен каждому желающему кто хочет его изучить.

Каждая запись набора имеет 58 атрибутов. А сам набор делится на 300 различных категорий. На настоящий момент каталог имеет объем 100 Гб, а хостером является Goolge.

Всем привет!

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

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

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

Сегодня речь пойдет о том, какую роль в Интернет-поиске играет лингвистика. Чтобы поместить это в контекст, начну с того, как связаны между собой лингвисты и большая поисковая компания, например, «Яндекс» (более 5000 чел.), «Гугл» (более 50 000 чел.), «Байду» (более 20 000). От трети до половины этих людей работают непосредственно на поиск. Лингвисты внутри этих компаний примерно поровну делятся между поиском и остальными направлениями — новостями, переводом и т.д.



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

В данном посте представлен обзор новшеств и особенностей популярного среди Python разработчиков фреймворка Django 1.7. Релиз позиционируется как сообществом, так и основными разработчиками — как наиболее значимый релиз, с момента выхода в свет Django 1.0.

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

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

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

jQuery-плагин, который превращает вложенное (древовидное) меню в систему прокручивающихся меню.

Репозиторий: github.com/webasyst/waslidemenu
Попробовать: jsfiddle.net/7LnSY/
Пример: demo-ru.webasyst.com

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

Что же все-таки такое NoSQL?

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

Дело в том, что речь идет совсем не об SQL. Поясним. Язык запросов Hive явно был вдохновлен SQL. Это же можно сказать и о языке Esper, хоть он работает и не с потоками, а с отношениями. Интересна история PostgreSQL — изначально он назывался Postgres, в качестве языка запросов использовал Quel и являлся ORDBMS, а сегодня PostgreSQL обладает многими функциями, которые позволяют ему быть документноориентированным хранилищем.

В данном случае речь идет не о ACID — в определении NoSQL о транзакциях ничего не говорится. Hyperdex — это база NoSQL, которая стремится обеспечивать ACID-транзакции. MySQL, несомненно, является базой SQL и в своей истории имеет сомнительные интерпретации на тему, что же на самом деле означает ACID.

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

Некоторое время назад мне пришлось дорабатывать клиент-сайд ресурса, включающего просто невероятное количество анкетных форм. Одной из неприятных особенностей этих форм было жуткое количество разнотипных правил валидации ввода и ещё большее количество взаимосвязей между полями.
Пример: если выбран чекбокс А, то в поле Х можно ввести только цифры, а поле Y должно быть скрыто, но если дополнительно выбрана радиокнопка Z, то поле Y нужно показать, а в поле X можно ввести всё, кроме цифр.
Иными словами — сущий ад, рождённый нездоровым сознанием маркетологов.

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

Свойства и законы. Сценарии. Inversion of Control в Haskell.

Совсем немного теории

В прошлой части мы убедились, что очень легко запутаться в плохо спроектированном коде. К счастью, с древних времен нам известен принцип “разделяй и властвуй”, — он широко применяется при построении архитектуры и дизайна больших систем. Мы знаем разные воплощения этого принципа, как-то: разделение на компоненты, уменьшение зависимости между модулями, интерфейсы взаимодействия, абстрагирование от деталей, выделение специфических языков. Это хорошо работает для императивных языков, и надо полагать, что будет работать в функциональных, за тем исключением, что средства реализации будут другими. Какими же?

Статья нацелена на тех кто уже знает что такое Sphinx и SphinxQL
Цель: Обеспечить непрерывность работы поиска по сайту с помощью Sphinx в момент проведения технических работ над одной из нод Sphinx кластера.

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

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

DuckDuckGo — гибридный поисковик, который работает с 2008 года, без поискового спама, почти без рекламы, без слежки за пользователями (полностью анонимный), поддерживает горячие клавиши и другие классные штуки. В общем, эдакая гиковская «оппозиция» Google, созданная для крошечной группы протестного электората.

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

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

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

Стандартов синтаксиса, как и словарей, несколько. В этой статье мы и разберем на практических примерах наиболее распространенные:

• Microdata — Микроданные (словарь Schema.org чаще всего встречается именно в этом синтаксисе);
• Microformats.org — Микроформаты (напоминаем, что это объединенный стандарт синтаксиса и словаря);
• RDFa и RDFa Lite (в упрощенном виде RDFa рекомендуется создателями словаря Open Graph. Также встречается с другими словарями, например, со словарем Dublin Core или Data Vocabulary);
• JSON-LD — расширение JSON.

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

Once upon a time В 2004 году разработчики из W3C создали стандарт, который, по их мнению, подходил для «представления всего в мире». Так появился синтаксис RDFa (Resourse Description Framework in attributes), который позволяет однозначно транслировать HTML-разметку с семантическими данными в RDF.

Введение

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

Подготовка данных рубрикатора

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

• 1. Рубрикатор – это граф, а не дерево
• 2. Текст, тематика которого определяется, может быть отнесен к нескольким рубрикам одновременно
• 3. Для каждого соотнесения с рубрикой указывается коэффициент точности определения рубрики
• 4. Тематика текста определяется для каждого текста отдельно, и не зависит от того как были определены рубрики других текстов ранее

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

Алгоритм определения тематики текста, кратко

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

Совсем недавно на Хабре появилась статья о реализации дружеских связей в ВКонтакте с помощью Wolfram Mathematica. Идея мне понравилась, и, естественно, захотелось сделать такой же граф, используя Python и d3. Вот, что из этого получилось.

Здравствуйте, коллеги.

Случилось так, что мне рассказали о Qt5.2 и его новой возможности быстро и легко создавать кроссплатформенные приложения под Android и iOS. С Qt я знаком был уже давно, но в последнее время работа была связана с другими технологиями и я немного запустил его развитие. Узнав это, я отправился на сайт Qt, посмотрел красивое видео, где за 10 минут HelloWorld приложение создается сразу под android и ios. Впечатления были очень положительные.

Было принято решиение заняться мобильной разработкой. Появился план пройти путь от желания сделать приложение до его публикации в Google Play. Но на первом этапе хотелось пройти это с тем что не жалко и в чем можно делать ошибки. И все это на новом Qt5.2.

Чего мы больше всего хотим, когда открываем интернет-поисковик? Мы хотим как можно быстрее его покинуть, как это ни парадоксально. Формулируем наше желание, жмём кнопку и скорее отправляемся туда, где оно должно исполниться (мы надеемся).



Есть всего два основных способа выражения желаний: либо описать, что нужно получить (или сделать), либо указать, куда нужно «телепортироваться». В первом случае система пытается понять запрос, правильно выбрав лучшие из ответов cети, взвешивая сотни их свойств на деревьях принятия решений. Во втором правильный ответ, как правило, всего один, и мы ожидаем, что поисковик его знает.

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

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

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

Что посеешь, то и пожнешь
Из желудя вырастет дуб,
Из семени репейника — только репейник
Профессиональное образование —
это семена, которые мы сеем...

Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 2-3 года, ведущий разработчик — плюс 2 года, архитектор решения — плюс 3–5 лет ...).

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

Мы живем во времена, когда кажется, что все просто и все есть. Нужно сделать масштабируемый проект — используем MongoDB, нужна очередь — вот RabbitMQ, нужно поднять функционал поиска — раз плюнуть: ставим Sphinx, Solr, ElasticSearch (нужное подчеркнуть).

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

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

Мы посмотрим, как с помощью нашего проекта http://indexisto.com сделан поиск на сайте http://maximonline.ru и сравним его с тем, что есть на других сайтах.

Для начала несколько примеров. Возьмем запрос «Битва за Лос Анджелес» и представим, что его напишут неправильно «Лос Анжелес биттва». Как видно, пользователь не знает точно, как пишется имя города, и забыл, как звучит название фильма, а также у него дрогнула рука в конце на слове «битва».

Выберем достойные проекты рунета, в которых есть префиксный поиск, и попробуем поискать там наш запрос:

Проект	Правильный запрос	Неправильный запрос
afisha.ru	все ОК	Не найдено
ivi.ru	все ОК	Не найдено
vk.com	все ОК	Не найдено
maximonline.ru	все ОК	все ОК