Графовые сети — это способ применения классических моделей нейронных сетей к графовым данным. Графы, не обладая регулярной структурой как изображения (каждый пиксель имеет 8 соседей) или тексты (последовательность слов), долгое время оставались вне поля зрения классических нейронных моделей, которые получили широкое распространение в области машинного обучения и искусственного интеллекта. Большинство моделей векторизации графов (построения векторного представления вершин в графе) были достаточно медленными и использовали алгоритмы на основе матричной факторизации или спектральной декомпозиции графа. В 2015-16 годах появились более эффективные модели (DeepWalk, Line, Node2vec, Hope) на основе случайных блужданий. Однако и они имели ограничения, потому что никак не затрагивали при построении векторной модели графа дополнительных признаков, которые могут храниться в вершинах или на ребрах. Появление графовых нейронных сетей стало логичным продолжением исследований в области графовых эмбеддингов и позволило унифицировать под единым фреймворком предыдущие подходы.

Для весенней конференции GTC стал доброй традицией рассказ об исследованиях и разработках Nvidia главного научного сотрудника и старшего вице-президента по исследованиям Билла Дэлли. Он поделился тем, как устроен отдел исследований и разработок Nvidia, а также немного рассказал о текущих приоритетах. В этом году Дэлли в основном занимался AI-инструментами, которые Nvidia и разрабатывает, и использует для совершенствования собственных продуктов. Например, Nvidia начала использовать ИИ для эффективного улучшения и совершенствования процесса проектирования GPU.

За последнее время у меня накопилось достаточно материалов по разработке плагинов для IntelliJ IDEA, чем и собираюсь поделиться с хабрасообществом.

Среда разработки и инфраструктура

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

Для разработки плагинов подойдет любая современная версия Intellij IDEA – она уже включает в себя полный набор необходимого инструментария.

Представляем уже 21-ую (из 24-х) лекцию легендарного Гарвардского курса CS50, который мы переводим и озвучиваем специально для JavaRush.

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

Совсем скоро мы закончим перевод всего курса из 24-х лекций. Если вы ещё не посмотрели предыдущие лекции – самое время начать знакомиться с ними. Список предыдущих лекций вот тут.

Привет, Хабрахабр! Мы долго думали, чем порадовать крупнейшее Dev-комьюнити рунета, и решили, что русскоязычные подкасты про Android-разработку от лучших разработчиков в индустрии — самое то. Собрать спикеров, подготовить темы и найти площадку для размещения было непросто, но мы справились. Встречайте!

Лицо моей жены, когда она вычитывала эту статью

Я решил написать цикл статей, который и сам был бы счастлив найти где-то полгода назад. Он будет интересен в первую очередь тем, кто хотел бы начать разрабатывать классные приложения на React.js, но не знает, как подступиться к зоопарку разных технологий и инструментов, которые необходимо знать для полноценной front-end разработки в наши дни.

Я хочу с нуля реализовать, пожалуй, наиболее востребованный сценарий: у нас есть серверная часть, которая предоставляет REST API. Часть его методов требует, чтобы пользователь веб-приложения был авторизован.

В статье описаны основные трудности создания приложений под Android.
Рассматриваются базовые понятия программирования Android.
Для примера описано создание игры Sudoku из книги Hello, Android – Ed Burnette.
Осторожно много скриншотов.

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

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

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

Вместе с поворотом поисковых систем к пользователям и учету пользовательских факторов, о которых мы неоднократно писали в нашем блоге, интересными становятся смежные вопросы, такие например, как взаимосвязь теории планируемого поведения и распространения вирусного контента. Данный текст рассказывает об оценке вирусного потенциала на примере ставшей уже легендарной кампании Scarecrow от Chipotle. Уникальный вирусный ролик был просмотрен более 13 миллионов раз не только благодаря замечательной анимации и четко спланированной кампании, включавшей в том числе и мотивацию пользовательской активности через приложения. За разработкой концепции этого вирусного материала стоит целая наука, о которой рассказала Кристин Тински. Весной 2014 года она опубликовала эту статью в блоге YouMoz Blog. Материал статьи достаточно дискуссионен, как и его подача, тем не менее, он затрагивает тему, которая близка философии продукта SocialTask: информационный шум от вашего контента в социальных медиа можно получить гораздо проще, чем кажется. Перевод выполнен для и размещён с разрешения аналитического отдела компании ALTWeb Group.

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

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

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


где s — число степеней свободы механической системы; — обобщенная координата; — кинетическая энергия механической системы; — обобщенная сила.

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

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

Что же, начнем!

В далёком 2007 году я приобрёл программу для ведения персональных финансов и до сих пор веду в ней учёт домашней бухгалтерии. В этом посте я расскажу о том, какой опыт приобрёл и что для себя вынес. Под катом не будет никаких обзоров программ по ведению финансов — я их не смотрю уже несколько лет (а свою программу я тоже не могу пролекламировать, потому что во многом она меня давно не устраивает, но накопленный архив данных делает сложным смену ПО). Также, хотя я и читал в своё время Кийосаки — но весьма критично и скептично отношусь к прочитанному, хотя многие вещи была возможность попробовать на собственной шкуре. Цикла статей не будет, постараюсь уложиться в одну.

С одной стороны, желание несколько странное — организация «серьезного» MPLS/VPLS на дешевом железе типа Mikrotik. С другой стороны — за 70 баксов (1500-2000р) за младшую модель RB/750(GL) мы получаем PE/CE-устройство, умеющее (помимо прочего) L2VPN/L3VPN поверх MPLS-среды и способное прокачать через себя порядка 70 мегабит дуплекса (на больших пакетах).
Mikrotik RouterOS умеет как MPLS (L3VPN, Traffic Engeneering), так и L2VPN (l2circuit aka VPWS, VPLS), что покрывает практически все возможные задачи (учитывая производительность железа, разумеется).

Интересно? Прошу под кат!

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

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

Есть один курс, который я бы добавил в программу обучения по всякой инженерной специальности, и он не о компиляторах или сложности алгоритмов. Это “Введение в реальность индустрии”, ибо об этом не говорят и это приводит к никому не нужным обломам. Эта статья претендует стать README.txt для молодого инженера в деле построения карьеры. Ее цель — сделать вас счастливее, заполнив пробелы в образовании относительно того, как работает реальный мир. Я не призываю следовать написанному как подробному руководству, но я надеюсь, что эта информация окажется для вас более ценной, чем то ничто, что вам рассказали об этом в университете.

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Наверняка многие уже слышали о подходе FRP для организации асинхронного кода. На хабре уже писали об FRP (Реактивное программирование в Haskell, FRP на Bacon.js) и есть хорошие доклады на эту тему (Программировние UI с помощью FRP и Bacon.js, Functional Reactive Programming & ClojureScript, О Bacon.js от Juha Paananen — автора бекона)

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

Вот что это дает по сравнению с обратными вызовами:

1) Поток событий (Event stream) и значение меняющаяся во времени (Property / Behavior) становятся объектами первого класса. Это значит что их можно передавать в функции и возвращать из функций.

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

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

К примеру можно написать функцию, возвращающую поток перетаскиваний (drag). В качестве параметров она будет принимать 3 потока — начало перетаскивания, движение, конец перетаскивания. Дальше можно передать в эту функцию: либо потоки для соответствующих событий мыши (mousedown, mousemove, mouseup), либо для touch событий (touchstart, touchmove, touchend). Сама же функция не будет ничего знать об источниках событий, а будет работать только с абстрактными потоками. Пример реализации на Bacon.

2) Явный state

Второе большое преимущество FRP это явное управление состоянием. Как известно, state — один из самых главных источников сложности программ, поэтому грамотное управление им позволяет писать более надежные и простые в поддержке программы. Отличный доклад от Рича Хикки о сложности (complexity) «Simple Made Easy».

FRP позволяет писать бОльшую часть кода на «чистых функциях» и управлять потоком данных (dataflow) явно (с помощью потоков событий), а состояния хранить тоже явно в Property.

31 января вышел релиз jQuery 1.5, одним из ключевых нововведений которого стал инструмент Deferred Object. Именно о нём я и хочу рассказать подробнее в этой статье.

Эта новая функциональность библиотеки направлена на упрощение работы с отложенными (deferred) вызовами обработчиков (callbacks). Deferred Object, аналогично объекту jQuery, «цепочный» (chainable), но имеет свой набор методов. Deferred Object способен регистрировать множество обработчиков в очередь, вызывать зарегистрированные в очереди обработчики и переключать состояние на «завершено» или «ошибка» для синхронных или асинхронных функций.

Введение

Так уж повелось, что любую статью о нечеткой логике принято начинать с упоминания имени Лотфи Заде. И я не стану исключением. Дело в том, что этот человек стал не только отцом-основателем целой научной теории, написав в 1965 году фундаментальный труд «Fuzzy Sets», но и проработал различные возможности ее практического применения. Он описал свой подход в 1973 году в тексте «Outline of a New Approach to the Analysis of Complex Systems and Decision Processes» (опубликованном в журнале IEEE Transactions on Systems). Примечательно, что сразу после его выхода одна предприимчивая датская фирма весьма успешно применила изложенные в нем принципы для усовершенствования своей системы управления сложным производственным процессом.

Но при всех заслугах Л. Заде, не менее важный вклад внесли последователи этой теории. Например, английский математик Э. Мамдани (Ebrahim Mamdani). В 1975 году он разработал алгоритм, который был предложен в качестве метода для управления паровым двигателем. Предложенный им алгоритм, основанный на нечетком логическом выводе, позволил избежать чрезмерно большого объема вычислений и был по достоинству оценен специалистами. Этот алгоритм в настоящее время получил наибольшее практическое применение в задачах нечеткого моделирования.

При разработке приложений с модульной структурой на JavaScript возникает две проблемы:

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

Обе эти задачи решаются при использовании подхода Asynchronous Module Definition. Он сводится к описанию модулей функцией define и подключению их с помощью require. На данный момент есть несколько инструментов, реализующих AMD. Я начал своё знакомство с ними с RequireJS и был удивлён, насколько удобно и просто можно описывать зависимости модулей. Расскажу, как это работает, на простом примере.