Как случилось, что искусственный интеллект успешно развивается, а «правильного» определения для него до сих пор нет? Почему не оправдались надежды, возлагавшиеся на нейрокомпьютеры, и в чем заключаются три главные задачи, стоящие перед создателем искусственного интеллекта?

На эти и другие вопросы вы найдете ответ в статье под катом, написанной на основе выступления Константина Анисимовича, директора департамента разработки технологий ABBYY, одного из ведущих экспертов страны в сфере искусственного интеллекта.
При его личном участии были созданы технологии распознавания документов, которые применяются в продуктах ABBYY FineReader и ABBYY FormReader. Константин рассказал об истории и основах разработки AI на одном из мастер-классов для студентов Технопарка Mail.Ru. Материал мастер-класса и стал базой для цикла статей.

Всего в цикле будет три поста:
• Искусственный интеллект для программистов
• Применение знаний: алгоритмы поиска в пространстве состояний
• Получение знаний: инженерия знаний и машинное обучение

Коллеги, представляю вам перевод статьи про Супер-продуктивность, которая меня сильно зацепила. Надеюсь, что перевод будет вам полезен для организации своего рабочего времени.

Я познакомился с этой идеей где-то на Hacker News несколько недель назад и адаптировал концепцию для моего собственного образа жизни, и это изменило мой подход к работе.

Супер-продуктивность — как начать работать больше, чем когда-либо

Уже три года я публикую регулярные обзоры свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-ноябрь 2013.

^{Изображение: Chris Liverani — Unsplash}

Это продолжение разбора темы (часть 1), захватившей мое внимание и пришедшейся по душе на Хабре. Обсуждаем проект парня, который, применив свой опыт в IT, смог заработать полмиллиона долларов.

Есть такой специальный хедер для безопасности вебсайтов CSP.

CSP ограничивает загрузку каких либо ресурсов если они не были пре-одобрены в хедере, то есть отличная защита от XSS. Атакующий не сможет загрузить сторонний скрипт, inline-скрипты тоже отключены…

На уровне браузера вы можете разрешить только конкретные урлы для загрузки а другие будут запрещены. Помимо пользы этот механизм может принести и вред — ведь факт блокировки и есть детекция! Осталось только придумать как ее применить.

Надавно была опубликована библиотека node-fibers, вносящая в nodejs и v8 поддержку замечательного fiber/coroutine — тоесть, возможность использовать yield.
Параллельно, на nodejs groups прошел целый ряд обсуждений на тему всевозможных вариантов упрощения асинхронного синтаксиса.

Вдохновившись возможностями, которые дают «волокна», я написал библиотеку node-sync, которая делает разработку в асинхронном окружении nodejs значительно удобнее, а код — нагляднее.

Синопсис

// Обычная асинхронная функция, вызывает callback с результатом через 1 сек
function someAsyncFunction(a, b, callback) {
    setTimeout(function(){
        callback(null, a + b);
    }, 1000)
}
// Вызываем эту функцию синхронно, используя Function.prototype.sync(),
// работающий по тому же принципу, что и call()
// на этом моменте текуший поток "зависнет" на секунду, пока функция не вернет значение
var result = someAsyncFunction.sync(null, 2, 3);
console.log(result); // "5" через 1 секунду

Университет Иннополис объявляет о начале конкурса среди студентов 3-5 курсов ведущих вузов России и зарубежья в области ИТ. Победители конкурса – группа студентов численностью 30-40 человек получат целевой грант на обучение по этой программе.

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

Команда проекта GeeksLab 18 января 2014 года в Одессе провела конференцию Happу New Front-End: О фронтенде по-новому!. В рамках конференции были подняты темы современной верстки, разработки фронтенда на чистом JavaScript, а также использования различных CSS и JavaScrpt фреймворков для построения фронтенда веб-проектов. С докладами выступили представители таких компаний как: rollApp, Universal Mind, DataArt, Ciklum, Elis, R2Crew, RootUA Media, WMSoftware, Electric Cloud. Презентации и видеозаписи докладов под катом.

Данная статья была написана 21 января 2014 участником проекта HTML5Rocks, Алексом Данило. Хочу отметить, что это мой первый перевод на Хабре, поэтому к минусам я готов, к критике еще больше. По всем проблемам и недочетам старайтесь писать мне лично, я буду оперативно исправлять. Оригинал на английском.

Высокая производительность веб-приложений является ключевым моментом для конечного пользователя. Так как веб-приложения становятся всё более и более сложными, понимание управления производительностью является убедительным навыком программиста. За последние пару лет появилось множество новых API в браузере, позволяющих следить за производительностью сети, временем загрузки и т.д. но ни одно из них не позволяет достаточно гибко и детально определить, что же именно “тормозит” ваше приложение. Для этого и есть User Timing API, которое предоставляет механизм для вашего приложения, позволяющий определить, на что и когда расходуется время.

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

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

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

Sweet.js оперирует своим собственным форматом синтаксического дерева, почти на уровне токенов, с минимальной структурой. С одной стороны это делает возможным определять довольно экзотические синтаксисы для своих макросов, с другой — делает написание макросов несколько сложнее, как если бы они были определены над стандартным AST JavaScript.

Я постоянно слышу людей, ноющих об асинхронных коллбэках в JavaScript. Держать в голове порядок исполнения в этом языке немного трудно (это тот случай, который называют «Callback Hell» или «The Pyramid of Doom»), если до этого ты имел дело с синхронным программированием. Моим обычным ответом было «тебе придется как-то с этим обходиться». В конце концов, ожидаем ли мы, что все языки программирования будут выглядеть и ощущаться одинаково? Конечно нет.

Все поменял недавний обзор черновика ECMAScript 6, в котором описываются генераторы — возможность языка, которая целиком изменит наш способ написания и серверного, и клиентского JavaScript. С помощью генераторов мы можем превратить вложенные коллбэки в похожий на синхронный код без блокирования нашей единственной event loop.
Например, этот код:

    setTimeout(function(){
        _get("/something.ajax?greeting", function(err, greeting) {
            if (err) { console.log(err); throw err; }
            _get("/else.ajax?who&greeting="+greeting, function(err, who) {
                if (err) { console.log(err); throw err; }
                console.log(greeting+" "+who);
            });
        });
    }, 1000);

может быть написан так:

    sync(function* (resume) {
        try (e) {
            yield setTimeout(resume, 1000);
            var greeting = yield _get('/something.ajax?greeting', resume)
            var who = yield _get('/else.ajax?who&greeting=' + greeting, resume)
            console.log(greeting + ' ' + who)
        }
        catch (e) {
            console.log(e);
            throw e;  
        } 
    });

Интересно, не правда ли? Централизованная обработка исключений и понятный порядок исполнения.

Гость выпуска — Константин Щеглов, Google

Уже более 3 лет наша команда занимается разработкой такого важного компонента сети оператора как PCRF. Policy and Charging Rules Function (PCRF) – решение для управления политиками обслуживания абонента в сетях LTE (3GPP), позволяющее в реальном времени назначать ту или иную политику, принимая во внимание сервисы, подключенные у абонента, его местонахождение, качество сети в данном месте в данный момент, время суток, объем потребленного трафика и т.д. Под политикой в данном контексте подразумевается доступный абоненту набор сервисов и параметры QoS (качества обслуживания). Анализируя соотношение цена-качество для различных продуктов в данной области от разнообразных поставщиков, мы приняли решение разрабатывать свой продукт. И вот уже более 2 лет, наш PCRF успешно работает на коммерческой сети компании Yota. Решение полностью софтовое, с возможностью устанавливать даже на обычные виртуальные сервера. Работает в коммерции на Red Hat Linux, но в целом возможна установка и под другие Linux-системы.

Web Audio API для меня является одной из тех новинок, которыми сейчас напичканы браузеры и с которой хотелось подружиться поближе и хоть как-то проникнуться тем, что же можно с помощью этого натворить. Что бы проникнуться, я решил написать простенький визуализатор аудио.

Но прежде чем начать разбираться непосредственно с Audio API, нам необходимо набросать заготовку нашего визуализатора и делать мы будем это при помощи canvas.

Какое-то время назад пролетала статистика от одного из преподавателей Coursera Марка Морли [1], что «около 3% записавшихся студентов доходят до стадии финального экзамена и лишь 1,5% сдают его».

Статистика наших онлайн программ чуть выше: у нас до конца всех занятий доходят около 20% слушателей. Мы, правда не делаем экзаменов, потому что искренне верим, что в теме управления людьми и коммуникаций формальные экзамены чуть более чем бесполезны. Но 20% точно прослушивают все занятия до конца (статистика собрана на 1500+ слушателях за 3 года). Ну так у нас и слушателей поменьше чем у Coursera, есть возможность практически личного воздействия на людей. :)

Однако, что та, что та статистика — не утешительна. Или нормально все? На эту тему мой коллега Слава Панкратов недавно написал отличный текст про то, как мы учимся по книгам (к курсам тоже применимо), которым текстом и хотелось бы поделиться.

Слава Панкратов «Синдром Алисы в зазеркалье: что и как читать?..»

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

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

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

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

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

От переводчика: Это вторая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья написана по мотивам выступления Ллойда Хилайеля на конференции Node Philly 2012 в Филадельфии.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

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

Кроме того, мы представим модуль compute-cluster — маленькую библиотеку, которая облегчает управление коллекцией процессов для выполнения распределённых вычислений.

Постановка задачи

Для Persona нам было необходимо создать сервер, который справился бы с обработкой множества запросов со смешанными характеристиками. Мы выбрали для этой цели Node.js. Нам надо было обрабатывать два основных типа запросов: «интерактивные», которые не требовали сложных вычислений и должны были выполняться быстро, чтобы интерфейс приложения был отзывчивым, и «пакетные», которые отнимали примерно пол-секунды процессорного времени и могли быть ненадолго отложены без ущерба для удобства пользователя.

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

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

Вооружившись этими требованиями, мы можем осмысленно сравнивать разные подходы.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости