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

Один из лучших способов это сделать — семантическое версионирование (semver). В практическом плане, для разработчиков и инструментов разработки, SemVer дает представление о рисках, связанных с переходом на новую версию программного обеспечения. Номера версий представлены в формате MAJOR.MINOR.PATCH, где каждый из трёх компонентов – целое число. Согласно SemVer, если меняется номер MAJOR, это указывает на существенные изменения API, с которыми разработчикам нужно быть очень осторожными.

Эта концепция версионирования обрастает нюансами, если говорить о jQuery, ведь совместимость с браузерами может быть так же важна, как совместимость API. В попытке создать более изящную jQuery, команда выпустила две версии в 2013 году. Первая осталась в линейке 1.* (сегодня это 1.11.1) и обеспечивает совместимость с максимальным количеством браузеров. Вторая версия, начиная с 2.0.0 и до сегодняшней 2.1.1, исключает поддержку ряда браузеров типа IE8 и ниже, чтобы оптимизировать код. Как 1.*, так и 2.* версии jQuery имеют одинаковый публичный API, хотя в их внутренней реализации есть некоторые различия.

Наши будущие релизы будут использовать другую номенклатуру. Как прежде, речь идет о двух разных пакетах. Преемником сегодняшней версии 1.11.1 будет jQuery Compat 3.0. Преемником jQuery 2.1.1 станет jQuery 3.0. Речь идет о двух разных пакетах на npm и Bower, но при этом они будут иметь одинаковую версию, чтобы обозначить тот факт, что их API одинаков.

Теория памяти человека, зачатки ИИ

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

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

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

1. Ребра графа имеют только положительные веса
2. Ребра графа могут иметь, как положительные так и отрицательные веса

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


Что же касается первого случая, когда все ребра имеют положительные веса, т.е. головной мозг человека не поврежден. Тогда почему же человек не может вспомнить моменты из своего детства? Ответ прост: “Любое тело стремится к покою”, так же и наша с вами нейронная сеть старается оптимизировать свою работу. (Владельцам навигаторов должно быть знакомо, что прокладка маршрута, как раз таки строится на принципах работы графа, нахождения кратчайшего пути и т.д.). Мозг человека более изощренная система и его оптимизация заключается в разрыве связей с малыми весами, и построении новых связей с более высокими. (рис. 2). Таким образом объяснятся многочисленные разрывы и новые соединения нейронов. Чем больше узел имеет связей, тем легче вспомнить необходимую информацию.

Статья является вольным переводом The Flaw Lurking In Every Deep Neural Net.

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

В статье "Интригующие свойства нейронных сетей" за авторством Christian Szegedy, Wojciech Zaremba, Ilya Sutskever, Joan Bruna, Dumitru Erhan, Ian Goodfellow and Rob Fergus, команды, включающей авторов из проекта Google по глубокому обучению, кратко описываются два открытия в поведении нейронных сетей, противоречащие тому, что мы думали прежде. И одно из них, честно говоря, поражает.

Сегодня один из легендарных разработчиков на Flash/JS — mr. doob, выложил в своем блоге экспериментальное демо на JavaScript. Демо было создано в сотрудничестве с trace (постановка) и supersole (музыка).

Это нужно видеть. (Смотреть желательно в Chrome)

А так же можно заглянуть в исходники данного демо.

Всем приятного просмотра!

В качестве небольшой разминки перед статьёй хотелось бы, чтобы читатель задал себе следующий вопрос: нужно ли фотографу для получения качественных снимков знать, как работает фотоаппарат? Ну, по крайней мере, должен ли он знать понятие «диафрагма»? «Отношение сигнал-шум»? «Глубина резкости»? Практика подсказывает, что даже со знанием таких сложных слов снимки могут получиться у наиболее «рукастых» не особо лучше снятых на мобильник через 0.3-МПикс-дупло. И наоборот, по-настоящему хорошие снимки могут получаться благодаря исключительно опыту и наитию при полном незнании матчасти (хотя это, скорее, исключения из правил, но всё же). Однако вряд ли со мной кто-то будет спорить, что профессионалам, которые хотят выжать из своей техники всё (а не только количество мегапикселей на квадратный миллиметр матрицы), эти знания нужны в обязательном порядке, поскольку в противном случае ему и называться профессионалом-то нельзя. И верно это не только для отрасли цифровой фотографии, но и для практически любой другой.

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

Человек изобрел компьютеры, чтобы они выполняли за нас большую часть повторяющихся задач. Это позволяет нам экономить много времени и использовать его с максимальной пользой. И, так как эта статья о front-end разработке, в этой области таких задач много: компиляция css- и js-препроцессоров, сборка спрайтов, оптимизация изображений, минификация файлов и др.

снизу фотографии настоящих жуков, сверху — моя реализация

Продолжение предыдущей статьи, на этот раз пишем шейдер.

Весной нам в голову пришла идея сделать простой сервис для облачного бэкапа серверов. Поскольку в то время работа над проектом велась преимущественно по вечерам и по выходным, для ускорения процесса было решено использовать только те технологии, в которых у нас есть опыт. Для backend-части был выбран Django, а реализация клиентской части предполагалась в виде SPA на базе AngularJS. Задумка была в следующем: сделать продукт с минимальным функционалом, а затем постепенно добавлять новые возможности. Для этого необходимо было сделать достаточно гибкую и масштабируемую систему. Немного пораскинув мозгами, мы приступили.

Не так давно издание о фондовом рынке Market Lab опубликовало интервью с Юрием Масловым, который в ITinvest занимается развитием инфраструктуры для работы на бирже с помощью торговых роботов. В блоге на Хабре мы публикуем выдержки из этого разговора, посвященные ответам на часто встречающиеся вопросы относительно технологий, используемых на фондовом рынке в России.

Пост написан под влиянием поста пользователя pchelintsev_an.

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

Всех с пятницей! По итогам недавно прошедшей встречи Moscow.pm я хочу предложить всем желающим посоревноваться в решении задачки.

Гольф (англ. golf) — спортивная игра, в которой отдельные участники или команды соревнуются, загоняя маленький мячик в специальные лунки ударами клюшек, пытаясь пройти отведённую дистанцию за минимальное число ударов.

Wikipedia

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

Легко подсчитать, что несжатое полноцветное изображение, размером 2000*1000 пикселов будет иметь размер около 6 мегабайт. Если говорить об изображениях, получаемых с профессиональных камер или сканеров высокого разрешения, то их размер может быть ещё больше. Не смотря на быстрый рост ёмкости устройств хранения, по-прежнему весьма актуальными остаются различные алгоритмы сжатия изображений.
Все существующие алгоритмы можно разделить на два больших класса:

• Алгоритмы сжатия без потерь;
• Алгоритмы сжатия с потерями.

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

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

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

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

Folly — это открытая С++ библиотека, разрабатываемая Facebook и используемая им во внутренних проектах. С целью оптимизации расходов памяти и процессорных ресурсов библиотека включает собственные реализации некоторых стандартных контейнеров и алгоритмов. Одной из них является folly::fbvector — замена стандартного вектора (std::vector). Реализация от Facebook полностью совместима с оригинальным интерфейсом std::vector, изменения всегда не-негативны, почти всегда измеримы, часто — существенно, а иногда даже грандиозно влияют на производительность и\или расход памяти. Просто включите заголовочный файл folly/FBVector.h и замените std::vector на folly::fbvector для использования его в своём коде.

Пример

folly::fbvector<int> numbers({0, 1, 2, 3});
numbers.reserve(10);
for (int i = 4; i < 10; i++) {
  numbers.push_back(i * 2);
}
assert(numbers[6] == 12);

Мотивация

std::vector — устоявшаяся абстракция, которую многие используют для динамически-аллоцируемых массивов в С++. Также это самый известный и самый часто используемый контейнер. Тем большим сюрпризом оказывается то, что его стандартная реализация оставляет достаточно много возможностей по улучшению эффективности использования вектора. Этот документ объясняет, как реализация folly::fbvector улучшает некоторые аспекты std::vector. Вы можете воспользоваться тестами из folly/test/FBVectorTest.cpp чтобы сравнить производительность std::vector и folly::fbvector.

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

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

В свете недавних изменений (начиная с релиза 0.7.3 от 27 декабря 2013) новая система сборки под Android становится очень интересной в том числе и для тех, кто использует NDK. Теперь стало действительно просто интегрировать нативные библиотеки в вашу сборку и генерировать APK для различных архитектур, корректно обращаясь с кодами версий.

Пусть мы хотим вычислить десятимиллионное число Фибоначчи программой на Python. Функция, использующая тривиальный алгоритм, на моём компьютере будет производить вычисления более 25 минут. Но если применить к функции специальный оптимизирующий декоратор, функция вычислит ответ всего за 18 секунд (в 85 раз быстрее):


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

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

Многим разработчикам и тестеровщикам, использующим Visual Studio, известен Брайан Келлер (http://blogs.msdn.com/b/briankel/ ) с его регулярно обновляемой виртуальной машиной, которая содержит последнюю версию Visual Studio и всю необходимую инфраструктуру для изучения и оценки всех возможностей средств разработки. Эта виртуальная машина сопровождается набором лабораторных работ aka.ms/VS13ALMVM, которые уже помогают оценить возможности средств разработки или даже научиться использовать новые возможности о которых вы либо не знали, либо не пользовались раньше.

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

О 4-х лабораторных я уже писал на habr: habrahabr.ru/company/microsoft/blog/235157. Сегодня мы рады сообщить, что благодаря ahriman, мы успешно выполнили проект по локализации этих лабораторных работ. Встречайте — полный набор из 24-х локализованых лабораторных работ, которые покрывают темы эффективной разработки, тестирования, совместной разработки и управления жизненным циклом ПО для Visual Studio 2013!

Видеоконтент уже прочно вошёл в мир Интернета и без него уже трудно представить глобальную сеть. Тем не менее, технологии встраивания видео в гипертекстовые документы за прошедшее время прошли определённую эволюцию: от RealPlayer к QuickTime и Flash, а в настоящий момент до встроенной поддержки видео в HTML5. Тем не менее, всё это время различные реализации видеоплееров страдали как от проблем кроссплатформенности и кроссбраузерности, так и от низкого или вообще нулевого уровня accessibility. И если способы борьбы с первой группой проблем в целом понятны и существуют в форме готовых решений, то вот проблемы доступности для подавляющего большинства web-разработчиков и без того, как правило, сложны для понимания, а в отношении видео совсем оставались загадкой. Однако, к счастью, появилось готовое решение и второй проблемы, так что все желающие смогут обеспечить своим пользователям полностью доступный видеоплеер и без глубоких компетенций в web accessibility.