Вчера я шёл куда-то по городу и вдруг задумался, как можно реализовать на JavaScript деление строки по символам при помощи регулярного выражения и с полным учётом Юникода.

После перехода от Perl к JavaScript много лет тому назад, я всё испытывал за свой новый язык некоторый комплекс неполноценности из-за недостаточной поддержки Юникода. За всё то время, пока JavaScript совершал в этом направлении свой большой скачок (при переходе от ES5 к ES6), у меня в закладках осталось несколько хороших статей.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
JavaScript has a Unicode problem
Unicode-aware regular expressions in ECMAScript 6
ES6 Strings (and Unicode, ) in Depth

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

Автор: Антон Реймер
В первой части статьи, основанной моем вебинаре, мы рассмотрели общие принципы работы браузера. Во второй — я сконцентрировал внимание на важных событиях: repaints и reflows — и на принципах работы event loop.

Repaints and reflows

При загрузке страницы, если она не пустая, всегда выполняется, как минимум, по одному reflow и repaint. Далее эти события возникают в следующих случаях:

1. Часть дерева отображения нуждается в перерасчете, т. е. у какого-то узла изменились ширина, высота или координаты. Вызывается событие reflow.

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

Если вызывается reflow, после него обязательно вызовется и repaint. Но обратное неверно: repaint может вызываться независимо от reflow.

Какие действия вызывают reflow и/или repaint

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

— Насколько это увеличит дистрибутив?
— Как это поможет нам писать меньше и эффективнее?



Сейчас мы используем RxJava, Dagger 2, Retrolambda и AspectJ. И если о первых трёх технологиях слышал каждый разработчик, а многие даже применяют их у себя, то о четвёртой знают только хардкорные джависты, пишущие большие серверные проекты и разного рода энтерпрайзы.

Передо мной стояла цель ответить на эти два вопроса и обосновать использование AOP-методологии в Android-проекте. А это значит — написать код и показать наглядно, как аспектно-ориентированное программирование поможет нам ускорить и облегчить работу разработчиков. Но обо всём по порядку.

Введение

В данной статье рассматривается вопрос о том, как реализовать обмен типизированными сообщениями между Back-End на основе ASP.NET Web API и Front-End, созданного с использованием TypeScript. Это приобретает особенное значение при работе над объёмными проектами, и тем-более важно, если команда является распределенной. Например, когда Back-End и Front-End разработчики работают из разных мест, в разных часовых поясах, и не всегда имеют возможность проконтактировать и обсудить что-либо. В этом случае отслеживание изменений представляет кропотливую работу, которая может быть чревата множеством трудноуловимых ошибок.

Для автора статьи, как для человека, который пришел к разработке Front-End со стороны WPF и Silverlight, большой проблемой, стало отсутствие статической типизации. Сколько раз вместо того чтобы сложить “2” и “2” складывал “2” и “Функцию возвращающую 2”, или передавал DOM объект вместо его jQuery обертки. Появление статических анализаторов кода, таких как JSLint, несколько облегчило проблему, но настоящим прорывом, особенно в командной разработке, для нас стал TypeScript.

2,8 млн репозиториев, 3 ТБ исходного кода и метаданных

Google в сотрудничестве с Github выложила для общественного пользования полную актуальную базу всех open-source репозиториев через интерфейс BigQuery. (Проверка свободной лицензии осуществляется через API.)

Наборы данных Google BigQuery Public Datasets содержат информацию о более чем 2,8 млн свободных репозиториев, о более чем 2 млрд файлов (исходный код последних версий 163 млн файлов), 145 млн коммитов и т.д. Общий размер базы — около 3 терабайт.

Раньше архивы Github выкладывались на Github Archive. Теперь всё это богатство доступно для полнотекстового поиска и анализа через простые SQL-запросы. Github обещает обновлять наборы данных еженедельно.

Когда я впервые услышал о технологии WebAssembly — она сразу показалось мне крутой вещью и мне сразу захотелось попробовать её в деле. От первого желания, до чего-то работающего мне, однако, пришлось потратить немало времени и порой испытать кое-какие разочарования. Для того, чтобы сохранить ваше время и ваши нервы, если вам захочется повторить тот же путь, и написана данная статья.

Предупреждение читателю

Эта статья написана 24-го июня 2016-го года. Поскольку WebAssembly очень молодая и динамично развивающаяся технология, со временем многие описанные в данной статье вещи устареют или полностью изменятся — учитывайте это.

А теперь поехали.

Что такое WebAssembly?

Официальная документация говорит следующее: «WebAssembly или wasm это новый портабельный, эффективный по размеру и скорости загрузки формат компиляции для веба». Эм-м-м-м… Что? Формат чего? Текстовый или бинарный? Да, это откровенно плохое описание. Так что убирайте уже ваши баззворд-бинго карточки и я, на основе моего опыта, дам своё определение:

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

Теперь звучит лучше, неправда ли?

Если вы пытаетесь оптимизировать производительность Вашего основанного на PostgreSQL приложения, Вы наверняка пользуетесь базовыми инструментами: EXPLAIN (BUFFERS, ANALYZE), pg_stat_statements, auto_explain, log_statement_min_duration, и т.д.

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

Но задумывалились ли Вы о задержках в сети? Игроки знают о ней, но имеет ли это отношение к Вашему серверу с приложением?

До конференции PG Day'16 Russia остались считанные дни, расписание можно посмотреть на нашем сайте. Мы трудимся в поте лица, но тем не менее успеваем готовить для вас переводы самых интересных материалов о PostgreSQL. Сегодня представляем вашему вниманию перевод статьи Pat Shaughnessy о поведении запроса Select.

Готовясь летом к этой презентации, я решил изучить некоторые части исходного кода PostgreSQL на C. Я запустил очень простой запрос select и наблюдал, что Постгрес с ним делает, с помощью LLDB, отладчика C. Как Постгрес понял мой запрос? Как он нашел данные, которые я искал?



Этот пост — неформальный журнал моего путешествия через внутренности PostgreSQL. Я опишу пройденный мной путь и то, что я видел в процессе. Я использую серию простых концептуальных диаграмм, чтобы объяснить, как Постгрес выполнил мой запрос. В случае, если вы понимаете C, я также оставлю вам несколько ориентиров и указателей, которые вы можете поискать, если вдруг решите покопаться во внутренностях Постгреса.

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

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

График сравнения скорости работы моего алгоритма, с функцией strstr на 600 кб тексте русскоязычной книги, при поиске строк размером от 1 до 255 байт:

Представляю вашему вниманию небольшую js-библиотеку Jsqry.
Проще всего проиллюстрировать её назначение следующим примером.

До:

var name;
for (var i = 0; i < users.length; i++) {
    if (users[i].id == 123) {
        name = users[i].name;
        break;
    }
}

После:

var name = one(users, '[_.id==?].name', 123);

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

Эта статья — третья часть серии:

• Часть 1: Декораторы методов
• Часть 2: Декораторы свойств и классов
• Часть 3: Декораторы параметров и фабрика декораторов
• Часть 4: Сериализация типов и metadata reflection API

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

В этой статье мы расскажем про:

• Последний оставшийся тип декораторов — декоратор параметра
• Реализацию фабрики декораторов
• Реализацию конфигурируемых декораторов

Выступления и посты в блогах о производительности JavaScript часто обращают внимание на важность мономорфного кода, однако обычно не дается внятного никакого объяснения, что такое мономорфизм/полиморфизм и почему это имеет значение. Даже мои собственные выступления зачастую сводятся к дихотомии в стиле Невероятного Халка: «ОДИН ТИП ХОРОШО! ДВА ТИП ПЛОХО!». Неудивительно, что когда люди обращаются ко мне за советом по производительности, чаще всего они просят объяснить, что на самом деле такое мономорфизм, откуда берется полиморфизм и что в нем плохого.

Ситуацию осложняет еще и то, что само слово «полиморфизм» имеет множество значений. В классическом объектно-ориентированном программировании полиморфизм связан с созданием дочерних классов, в которых можно переопределить поведение базового класса. Программисты, работающие с Haskell, вместо этого подумают о параметрическом полиморфизме. Однако полиморфизм, о котором предупреждают в докладах о производительности JavaScript – это полиморфизм вызовов функции.

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

_{Я также попробовал новый способ объяснять вещи – изображая взаимодействие составных частей виртуальной машины в виде коротких комиксов. Кроме того, данная статья не покрывает некоторые детали, которые я посчитал незначительными, излишними или не связанными напрямую.}

Сегодня Redux — это одно из наиболее интересных явлений мира JavaScript. Он выделяется из сотни библиотек и фреймворков тем, что грамотно решает множество разных вопросов путем введения простой и предсказуемой модели состояний, уклоне на функциональное программирование и неизменяемые данные, предоставления компактного API. Что ещё нужно для счастья? Redux — библиотека очень маленькая, и выучить её API не сложно. Но у многих людей происходит своеобразный разрыв шаблона — небольшое количество компонентов и добровольные ограничения чистых функций и неизменяемых данных могут показаться неоправданным принуждением. Каким именно образом работать в таких условиях?

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!

Клонирование объектов в JavaScript довольно частая операция. К сожалению, JS не предоставляет быстрых нативных методов для решения этой задачи.

К примеру, популярная Node.JS ORM Sequelize, которую мы используем на backend-е нашего проекта, значительно теряет в производительности на предвыборке большого (1000+) количества строк, только на одном клонировании. Если вместе с этим, к примеру, в бизнес-логике использовать метод clone известной библиотеки lodash — производительность падает в десятки раз.

Но, как оказалось, не всё так плохо и современные JS-движки, такие как, например, V8 JavaScript Engine, могут успешно справляться с этой задачей, если правильно использовать их архитектурные решения. Желающим узнать как клонировать 1 млн. объектов за 30 мс — добро пожаловать под кат, все остальные могут сразу посмотреть реализацию.

«10.01 х 10.01 = 1000.1001»
Джордж Оруэлл. «1010001001001000.1001001000100001»



Существует ли позиционная система счисления с иррациональным основанием, в которой все натуральные числа записываются конечным числом цифр? В которой число больше единицы, не имеющее цифр после запятой, наверняка не целое и даже не рациональное? В которой 1 + 10 = 100, а 1 + 1 = 10.01?

Друзья, представляем вашему вниманию вторую часть перевода «Чем PostgreSQL лучше?». Надеемся, она вызовет такое же горячее обсуждение в комментариях, как и первая часть. А также с радостью продолжим с вами дискуссию лично на PG Day'16 Russia, до которой осталось совсем немного!

В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». В первой части этой серии мы рассмотрели хранение данных — модель, структуры, типы и ограничения по размеру, — чтобы дать вам несколько причин, почему Постгрес подтверждает свои слова делом. Во второй части мы поговорим о манипуляциях с данными и поиске, включая индексирование, виртуальных таблицах и возможностях запросов. В этой серии мы выясняем, что выгодно отличает PostgreSQL от других баз данных с открытым исходным кодом, а именно — от MySQL, MariaDB и Firebird.

От переводчика:
Предлагаю вам перевод поста из блога Мэтта Стэнклиффа (Matt Stancliff), автора нашумевшей на хабре статьи Советы о том, как писать на С в 2016 году.
Здесь Мэтт делится знаниями о квалификаторе типа const. Несмотря на вызывающий заголовок, возможно, многое из того что здесь описывается будет вам известно, но, надеюсь, и что-нибудь новое тоже найдется.
Приятного чтения.

Думаете, что вы знаете все правила использования const для С? Подумайте еще раз.

NeDB (Node.js Embedded Database) — встраиваемая база данных для NodeJS, реализующая подмножество MongoDB API. Эта легкая NoSQL СУБД написана на чистом JavaScript, не имеет бинарных зависимостей и, помимо NodeJS, может использоваться в NW.js, Electron или прямо в браузере.

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

Мы поговорили с Вячеславом Егоровым aka mraleph, инженером из Google, компиляторщиком до мозга костей, который работал над JavaScript движком под названием V8, встроенным в Chromium (и, как следствие в Chrome, Android версию браузера, облачную операционную систему Chrome OS) и в менее известный Maxthone.
JavaScript-программистам Вячеслав, скорее всего, известен как автор постов про внутренности V8 и как докладчик, увлеченно показывающий машинный код на конференциях для Web-разработчиков.

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

О! Сколько нам открытий чудных
Готовит просвещение дух,
И опыт, сын ошибок трудных,
И гений, парадоксов друг,

И случай, бог изобретатель…
А.С. Пушкин

Вместо вступления

Надеюсь представить решение проблемы факторизации чисел, основанного на использовании mod 6 и mod 4, что позволило найти закономерности перевода квадратичных зависимостей в линейные.

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

По данной методике была написана программа программистом — самоучкой Белых Сергеем Алексеевичем, которая показала её эффективность. К сожалению, она не адаптирована к большим числам. Методика написана как алгоритм для составления программы, с разъяснениями. Алгоритм представлен в табличном варианте.
На основании корреляционной зависимости между координатами числа по мод 6 и
мод 4, обеспечивается и корреляционная зависимость и между номерами числа по данным модулям: N6; N4.
Напомним, что все составные числа располагаются в 4-х квадрантах, как при использовании системы координат по мод 6, так и при использовании системы координат по мод 4.
Каждая таблица составлена для четырёх из 16 возможных вариантов. Почему из 16?
Каждый квадрант содержит составные числа, характеризующиеся 4-я расчётными вариантами.
Расчётные варианты зависят от чётности координат, и от соотношения величин координат различной чётности.

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