Мечта о том, чтобы машина понимала человеческий язык, завладела умами еще когда компьютеры были большими, а их производительность – маленькой. Главная проблема на пути к этому заключается в том, что грамматика и семантика естественных языков слабо поддаются формализации. Кроме того, от языков программирования их отличает присутствие многозначности.

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



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

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

В этом посте хочется поделиться личным опытом создания продукта с нуля. Путь «а давайте запилим/скопируем и выкинем на рынок» мы уже проходили. Такой подход чуть не убил нашу компанию.



По статистике, около 50% фич среднестатистического продукта никогда не используются и только 12% опций клиенты используют активно. Как всегда попадать в эти 12% функционала? А что, если я сам не являюсь пользователем этого продукта? Как сделать продукт простым и удобным? Наконец, стоит ли его вообще делать нашей компании? И как понять, будет ли продукт востребован рынком еще до его создания?

Итак, представим, что у нас девственно чистая система, в которой нет ни Putty, ни msysgit. Приступим к настройке нашего рабочего окружения.

Установка Putty

Качаем, устанавливаем, генерим и настраиваем ключ c Pagent (инструкция, ?).

Добавляем ключ на git-сервер

Открываем страницу с SSH ключами и добавляем из буфера наш ключ

Создаём и сохраняем в Putty профиль «git@github.com» и проверяем, что удаётся зайти по ключу – должна открыться и сразу закрыться консоль.

Устанавливаем и настраиваем msysgit

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

1. Вступление. Кратко о масштабировании
2. Некоторые примеры развертки mongoDB и их описание
3. Шардинг mongoDB

    Пункты 1 и 2 — теоретические, а номер 3 претендует на практическое руководство по поднятию кластера mongoDB и больше всего подойдет тем, кто столкнулся с этим в первый раз.

Привет, Хабр!

Сегодня я хочу рассказать о некоторых решениях проблем, которые возникают во время использования высоконагруженных систем. Все, о чем пойдет речь в этом материале, проверено на собственном опыте: я – Social Games Server Team Lead в компании Plarium, которая занимается разработкой социальных, мобильных, браузерных игр.

Для начала немного статистики. Plarium занимается разработкой игр с 2009 года. На данный момент наши проекты запущены во всех наиболее популярных социальных сетях («Вконтакте», «Мой мир», «Одноклассники», Facebook), несколько игр интегрированы в крупные игровые порталы: games.mail.ru, Kabam. Отдельно существует браузерная и мобильная (iOS) версии стратегии «Правила войны». В базах числятся более 80 миллионов пользователей (5 игр, локализация на 7 языках, 3 миллиона уникальных игроков в день), в итоге все наши серверы получают в среднем около 6500 запросов в секунду и 561 миллион запросов в сутки.

В качестве аппаратной платформы на боевых серверах в основном используются два серверных CPU с 4 ядрами (x2 HT), 32-64 GB RAM, 1-2 TB HDD. Серверы работают на базе Windows Server 2008 R2. Контент раздается через CDN с пропускной способностью до 5 Gbps.
Разработка ведется под .NET Framework 4.5 на языке программирования C#.

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

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


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

Директор по маркетингу сервисов Яндекса Андрей Себрант рассказал студентам Малого ШАДа о том, что такое большие данные, и о тех, зачастую неожиданных местах, где они находят своё применение.




Bid Data как понятие у всех на слуху уже не первый год. Но точное представление о том, что же представляет собой это понятие, есть далеко не у всех, особенно это касается людей за пределами IT-сферы. Проще всего несведущему человеку объяснить это на практическом примере.

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

Ну вот дошли руки до следующей части.
Сегоня расскажу что знаю про американский бухучет применительно к к нашей alien`ской конторе и налоги.

Это продолжение топиков HOWTO: свой бизнес в США из России,
и Бизнес в США из России. Часть II. Деньги и банки.

Сегодня попробую осветить денежные вопросы.
Банковский счет, карты, платежи, PayPal и все такое.
Это продолжение топика HOWTO: свой бизнес в США из России, если кто пропустил.

Департамент информационно-аналитических исследований RU-CENTER Group опубликовал годовой отчет с результатами мониторинга использования CMS и различных технологических решений в Рунете в 2013 году. Каждый месяц робот http://monoid.nic.ru/ опрашивал хосты по списку (из него исключены популярные паркинги). Всего было опрошено более 1 млн доменов в зоне .RU. Подробнее о методологии см. здесь.

Некоторые результаты довольно интересны. Поскольку опросы проводились ежемесячно, то можно посмотреть не только итоговый результат, но и оценить процесс в динамике. Другими словами, можно отследить миграцию сайтов между различными CMS.

Робот различает семь ведущих CMS по числу сайтов: Drupal, WordPress, Joomla!, MODx, «1С-Битрикс», NetCat, UMI.CMS. При этом есть два безоговорочных лидера — Joomla! и WordPress. На долю этих CMS приходится 70% веб-сайтов, работающих под управлением той или иной из обнаруживаемых систем управления контентом.

Ведущие инструменты для управления конфигурацией по разному подходят к автоматизации серверов

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

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

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

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

После написания моей предыдущей статьи Делаем вебсокеты на PHP с нуля я понял, что у сообщества есть некоторый интерес к поднятой мною теме.

В прошлой статье я обещал, что опишу:

• запуск нескольких процессов для обработки соединений
• межпроцессное взаимодействие
• разделение процессов мастер-воркер
• проксирование вебсокетов с помощью nginx
• запуск из консоли
• интеграция с вашим фреймворком на примере yii
• демонстрация

И, как обычно, — получившийся код и ссылка на демонстрационный чат в конце статьи.

Здравствуй, хабраюзер. Вот и подоспела третья часть моей статьи, которая подытожит цикл (часть 1 и часть 2) статей для начинающих. Эта часть будет посвящена конкретному примеру применения Chef в облаке Amazon. Как я уже упоминал – это достаточно популярный сценарий. Для простоты понимания, будет рассмотрен случай с двумя ec2-instance (виртуальные сервера Amazon), один из которых будет выполнять роль Chef-сервера, а второй – узла.

AWS и Chef

Сразу же уточню, что запускать instance мы будем используя AWS CloudFormation. Можно было бы, конечно, запустить и управлять ними вручную, но какой смысл в такой автоматизации?

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

Dokku это средство простого трансформирования Ubuntu сервера, в мини-Heroku. После установки dokku, вы получаете возможность делать:

$ git push production master

для могих популярных платформ (Node.js, Java, PHP, Python etc). Результатом процесса развертования, есть запущенное приложение, к которому сразу можно получить доступ по http/https.

Как это работает?

Если открыть репозиторий проекта, то в описании можно увидеть строчку - «Docker powered mini-Heroku in around 100 lines of Bash» — около 100 строчек баш кода, который иммитирует работу Heroku. Это довольно «легкая» реализация, как для такой большой проблемы, которую он решает.

Все объясняется тем, что Dokku стоит на плечах таких технологий как: Docker, Heroku Buildpacks, Nginx, Git.

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

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

Сегодня я хочу рассказать о том, как мы в своем проекте indexisto.com сделали аналог инструмента Google Webmaster Marker. Напомню, что Marker это инструмент в кабинете Google Webmaster, который позволяет аннотировать ваши страницы Open Graph тегами. Для этого вы просто выделяете мышкой кусок текста на странице и указываете что это title, а это рейтинг. Ваша страница при этом грузится в Iframe в кабинете вебмастера.



Теперь Google, встретив подобную страницу на вашем сайте, уже знает, что за контент на ней опубликован, и как его красиво распарсить в сущность (статью, товар, видео..)

Нам был нужен подобный функционал. Задача казалась несложной и исключительно клиентсайд. Однако на практике решение лежит на стыке клиентсайда и серверсайда («чистые» JS программисты могу ничего не знать про различные прокси серверы и очень долго подходить к снаряду). При этом я не нашел в интернетах статью которая описывала бы всю технологию от начала до конца. Также хочется сказать спасибо пользователю BeLove и нашим безопасникам за помощь.

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

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

16 января Amit Agarwal, разработчик расширения Add to Feedly опубликовал заметку в блоге, в которой признал, что его расширение было продано неизвестному за сумму в несколько тысяч долларов («предложение из четырёх цифр»).

Add to Feedly — это расширение, которое добавляло удобную кнопку подписки на RSS канал текущей страницы через сервис Feedly (популярная альтернатива почившему Google Reader). Расширение было сделано Амитом за час и набрало 30 000 пользователей в магазине Chrome. Расширение было продано, деньги получены через PayPal, и Амит передал права на расширение другому аккаунту Google.

Через месяц новые владельцы отправили обновление в магазин Chrome. Никаких новых фич, никаких исправлений багов. Только добавление рекламы на все страницы, которые просматривает пользователь. Все ссылки на каждом сайте превратились в реферальные, по которым выкидывалась реклама. Кроме того, новые хозяева получили возможность отслеживать все переходы пользователей. Проще говоря, автообновление Chrome загрузило вредоносный код напрямую в 30 000 аккаунтов, а синхронизация Chrome Sync распространила это по каждому подключённому компьютеру с установленными Google Chrome, Chromium или Chrome OS.

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

В какой-то момент меня очень удивило, что потрясающая и понятная книга о проектировании JavaScript-приложений от известного автора до сих пор не переведена на русский язык. Вместе с единомышленниками мы перевели все главы. Сейчас мы внимательно вычитали 5 из них и хотим их показать всем, кто интересуется JS. Каждую неделю мы обещаем публиковать по 2 главы.

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

Сайт перевода
Репозиторий на GitHub