Сегодня большие данные в тренде и таком же большом фаворе. Недавно в этой сфере отметился и Ларри Пейдж, который заявил, что будь в открытом доступе больше информации о состоянии здоровья, то благодаря её анализу в следующем году можно будет спасти около 100 000 человек. После Агентства Национальной Безопасности США, Google занимает второе место по объёму хранимых данных. Однако Пейдж, вероятно, несколько поторопился со своим утверждением, особенно в свете того, что крупная программа Google Flu Trends (официальный сайт) продемонстрировала низкую эффективность. Большие данные не являются волшебным инструментом, способным решить все нашим проблемы, и вряд ли Пейджу с их помощью удастся спасти тысячи жизней.

Что сложнее: отрендерить сцену со взрывающимися вертолётами или нарисовать унылый график функции y=x²? Да, верно, вертолёты взрывать дорого и сложно — но народ справляется, используя для этого такие мощные штуки, как OpenGL или DirectX. А рисовать график, вроде, просто. А если хочется красивый интерактивный график — можно его нарисовать теми же мощными штуками? Раз плюнуть, наверное?

А вот и нет. Чтобы заставить унылые графики вменяемо выглядеть и при этом работать без тормозов, нам пришлось попотеть: едва ли не на каждом шагу подстерегали неожиданные трудности.

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

Введение

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

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

Отметим, что приводимые подходы применимы не только к текстам, а вообще к любым объектам, которые можно представить в виде символьных последовательностей, например, какие-нибудь макромолекулы (ДНК, РНК, протеины) из генетики. Всего мы рассмотрим 4 метода:

1. Признаковое описание.
2. Попарное наложение (выравнивание) текстов.
3. Формирование профиля и скрытой марковской модели.
4. Представление фрагментами.

Итак, приступим.

Россияне, самостоятельно поступившие в ведущие иностранные вузы, смогут пройти в них обучение за государственный счет. По информации «Известий», в минувшую пятницу премьер-министр Дмитрий Медведев подписал соответствующее постановление.

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

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

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

Разбирая старые бумаги наткнулся на изрядно потрёпанную тетрадь, в которой обнаружил наброски алгоритма поиска покрытия. Автор алгоритма Виктор Анатольевич Щербанов — мой учитель, под руководством которого я работал в девяностые годы прошлого столетия. Моё скромное участие в основном заключалось в том, что я предлагал в большинстве случаев неверные (а порой и просто бредовые) варианты. Что в общем-то не помешало Шефу (так мы его называли между собой) таки довести работу над алгоритмом до логического завершения. Где-то в двухтысячных годах алгоритм был опубликован в одном из институтских изданий Томска. Но думаю, что не лишним будет вспомнить его ещё раз. Собственно в память о Шефе я и решил написать этот пост. Может быть алгоритм покажется кому-то интересным или подтолкнёт на какие-то новые идеи по реализации алгоритма.

Низкая скорость поисковых запросов

Работая над поисковым движком по социальной информации (ark.com), мы остановили свой выбор на Elasticsearch, так как по отзывам он был очень легок в настройке и использовании, имел отличные поисковые возможности и, в целом, выглядел как манна небесная. Так оно и было до тех пор, пока наш индекс не вырос до более-менее приличных размером ~ 1 миллиарда документов, размер с учетом реплик уже перевалил за 1,5 ТБ.

Даже банальный Term query мог занять десятки секунд. Документации по ES не так много, как хотелось бы, а гуглинг данного вопроса выдавал результаты 2х-летней давности по совсем не актуальным версиям нашего поискового движка (мы работаем с 0.90.13 — что тоже не достаточно старая вещь, но мы не можем позволить себе опустить весь кластер, обновить его, и запустить заново на текущий момент — только роллинг рестарты).

Низкая скорость индексации

Вторая проблема — мы индексируем больше документов в секунду (порядка 100к), чем Elasticsearch может обрабатывать. Тайм-ауты, огромная нагрузка на Write IO, очереди из процессов в 400 единиц. Все выглядит очень страшно, когда смотришь на это в Marvel.

Как решать эти проблемы — под катом

Суть проблемы

Сейчас появляется очень много материала про юнит и нагрузочное тестирования. Все поголовно пишут тесты, код создают исключительно через TDD, используют jmeter/ab. Однако, все тестирование очень тесно связано с тестовыми данными. А их нужно генерировать/писать. Проблема не стоит остро для юнит тестирования — накидал mock, погонял его и забыл. Но как быть с нагрузочным тестированием? Когда мне нужно не 1-2-5-10 объектов, а миллионы?

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

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

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

Пользователь StackOverflow под ником Mysticial опубликовал довольно лаконичное, но исчерпывающее объяснение, почему на сайте столько негативных комментариев и ругани. Это объяснение для StackOverflow, но похожие «схемы ненависти» можно составить практически для любого сообщества в интернете. Конечно, у каждого сообщества схема будет разной.

В целом, пишет Mysticial, на StackOverflow есть четыре группы пользователей:

1. «Смотрители», для которых важно поддерживать сайт в хорошем виде с качественным контентом.
2. «Хелп-вампиры», которые захламляют сайт плохими/повторными вопросами. Им нужен только ответ на свой вопрос — и больше ничего.
3. «Ботоотвечатели», которые отвечают на всё, что могут (и что не могут)
4. Те, кому всё пофиг.

19-летний итальянский разработчик Габриэле Чирулли (Gabriele Cirulli) создал чрезвычайно захватывающую игру 2048, скрестив тетрис и «пятнашки».



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

От переводчика: это вторая часть перевода статьи Olivier Goffart о внутренней архитектуре сигналов и слотов в Qt 5, перевод первой части тут.

Идею игр типа escape the room (англ. «выбраться из комнаты») связывают прежде всего с популярными браузерными играми на flash, в которых нужно было искать и применять друг к другу предметы, чтобы найти выход (многие помнят Crimson Room).

Мы живем в то время, когда идеи, еще недавно высказанные в литературе, кино и компьютерных играх — обретают жизнь. Американцы делают экзоскелет по мотивам «Железного человека», фильм «Игра» Дэвида Финчера вдохновляет на создание ARG, а «Форт Боярд», «Пила» и технологии умных домов — на постройку комнат-квестов.

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

Идея витала в воздухе, поэтому ее реализовали в США и в Гонконге одновременно. Статья на Википедии говорит, что некие программисты сделали эскейп-рум по мотивам Агаты Кристи достопримечательносью Кремниевой долины, но мне не удалось найти тому подтверждения. В Гонконге же это были изначально кампусные студенческие игры. В 2008 году несколько колледжей даже объединилось, чтобы провести большую игру на 60 человек.

А вот в 2007 — действительно «понеслось». Японская компания SCRAP с момента открытия провела игры для 200 000 человек (включая масштабные игры на несколько сотен человек на стадионах).

После нашей удачной первоапрельской шутки нас регулярно спрашивают, когда же мы выпустим C++ IDE. Понятно, что все, кто пишет под Linux, давно ждут такую среду разработки, да и альтернатива имеющимся в Windows и Mac OS никому не помешает.

C++ IDE — это отдельный продукт, она основана на платформе IntelliJ, как и прочие наши IDE. Поддержка C++ в ReSharper — это совершенно другая тема, и про нее мы отдельно напишем (не сегодня).

Некоторое время назад я начал рассказывать на Хабре про Elliptics — наше отказоустойчивое распределенное key-value хранилище (к слову, свободное и распространяемое под GPL-лицензией). Тогда я в общем описал устройство Elliptics: про архитектуру и основные принципы работы, за счет чего достигается надежность системы, как систему можно расширять, и как она ведет себя при сбоях.

Начиная с этой статьи попробуем погрузиться в Elliptics глубже: я хочу рассказать вам про внутреннюю архитектуру и различные поддерживаемые фичи.



Сегодня — про сетевую и программную архитектуру Elliptics и некоторые из его особенностей. Также я подробно расскажу про кэш и нашу низкоуровневую библиотеку для локального хранения данных — Eblob.

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

Громкие заявления требуют убедительных доказательств.
Карл Саган (оригинал)

Преамбула

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

Что же в сухом остатке с той самой лекции? Далеко не последний университет проводит в своих стенах лекцию сомнительного качества (с продажей книг выступающего, конечно же) и мало того, что выступает бесплатной площадкой для такого рода личностей, так еще и бьёт по своему статусу. Казалось бы, возможно это единичный случай. Например, та же лекция была прочитана в лектории Политехнического музея. В последствии администрация признала эту лекцию и ряд других лженаучными и даже организовали отличную лекцию "Что такое любительская лингвистика", прочитанную академиком Зализняком.

Однако, оказалось, что это не исключение.

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

В результате нескольких лет исследований, размышлений, изучения первоисточников, сопоставления данных, формирования и отсеивания гипотез и т.п. – появилась красивая и, по сути, простая модель, которая строго вписалась в классическую физику и была подтверждена численным моделированием в пакете Ansoft HFSS. С момента начала проекта, мы провели некоторое количество дискуссий в различных сообществах, где от нас требовали «статью для технарей» — в результате появился данный материал.

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

Речь пойдет об использовании rmate, небольшого скрипта позволяющего из консоли открыть удаленный документ в локальном текстовом редакторе, вместо nano или vim, он был написан для TextMate и те кто перешел на ST2 с этого редактора, наверняка пользуются этим инструментом, да и «матерые разрабы» не найдут в посте много нового, но если вы только начали пользоваться ST2 и единственный инструмент удаленного редактирования о котором вы слышали, это плагин SFTP, добро пожаловать под кат за подробностями.

Привет Хабралюди!
Это мой первый пост, поэтому не судите строго. Я хочу начать вольный перевод книги John Torjo «Boost.Asio C++ Network Programming» вот ссылка на нее.

Содержание:

• Глава 1: Приступая к работе с Boost.Asio
• Глава 2: Основы Boost.Asio
  
  • Часть 1: Основы Boost.Asio
  • Часть 2: Асинхронное программирование
• Глава 3: Echo Сервер/Клиент
• Глава 4: Клиент и Сервер
• Глава 5: Синхронное против асинхронного
• Глава 6: Boost.Asio – другие особенности
• Глава 7: Boost.Asio – дополнительные темы

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