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

Что бы там ни было — V8, SpiderMonkey (Firefox), Carakan (Opera), Chakra (IE) или что-то ещё, знание внутренних процессов поможет вам оптимизировать работу ваших приложений. Но не призываю вас оптимизировать движок для одного браузера или движка – не делайте так.

Задайте себе вопрос:
— можно ли что-то в моём коде сделать более эффективным?
— какую оптимизацию проводят популярные движки JS?
— что движок не может компенсировать, и может ли сборка мусора подчистить всё так, как я от неё ожидаю?



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

В этой статье пойдёт речь о том, как реализован словарь в Python. Я постараюсь ответить на вопрос, почему элементы словаря не упорядочены, описать, каким образом словари хранят, добавляют и удаляют свои элементы. Надеюсь, что статья будет полезна не только людям, изучающим Python, но и всем, кто интересуется внутренним устройством и организацией структур данных.

Как известно, io.js ориентирован на новые версии движка V8, в которые включена поддержка стандарта ES6. В то время как в NodeJS для поддержки новых фич ES6 приходилось использовать флаг --harmony при запуске и другие заморочки, в io.js предусмотрены 3 группы новшеств:

• shipping — новшества, помеченные как stable в V8, такие как генераторы, шаблоны, новые строковые методы и т.д. Все они включены по умолчанию и не требуют специальных флагов при запуске
• staged — почти завершенные, но не оттестированные, либо не приведенные к стандарту ES6. Это новшества из разряда «используйте на свой страх и риск», которые требуют флаг запуска --es_staging (или --harmony)
• in progress — все остальные новшества, которые должны быть включены индивидуальным флагом (например --harmony_arrow_functions)

Часть 1. Вобще-то уже все поделили до нас!
Часть 2. Истина где-то рядом

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

Часть 1

4.2 Разделённое владение shared_ptr

Не у каждого объекта может быть один владелец. Нам надо убедиться, что объект уничтожен и освобождён, когда исчезает последняя ссылка на него. Таким образом, нам необходима модель разделённого владения объектом. Допустим, у нас есть синхронная очередь, sync_queue, для общения между задачами. Отправитель и получатель получают по указателю на sync_queue:

void startup() 
{ 
  sync_queue* p = new sync_queue{200}; // опасность! 
  thread t1 {task1,iqueue,p}; // task1 читает из *iqueue и пишет в *p 
  thread t2 {task2,p,oqueue}; // task2 читает из *p и пишет в *oqueue 
  t1.detach(); 
  t2.detach(); 
} 

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

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

Мой посыл не в том, что убедить вас отказаться от самостоятельного использования криптографических средств или пойти и нанять консультанта с зарплатой от $1000 в час всякий раз когда вы задумываетесь о шифровании.
Частично я веду к тому, что вам никогда не следует расслабляться, всегда нужно быть начеку, изыскивая пути, которые злоумышленник может использовать для получения дополнительной информации о вашей системе, а частично к тому, что Padding Oracle Attack является крутой демонстрацией всего этого. Итак, начнем.

Не все JSON нельзя комментировать (например, Хром[иум] вполне переносит комментарии в manifest.json), но в стандарте не предусмотрены комментарии к нему. Поэтому ряд функций в NodeJS не обрабатывают комментарии в формате JS и считают их ошибкой. Точно так же, AJAX с форматом JSON принимает их за ошибку. Поэтому для конфигурационных файлов в формате JSON имеется масса неудобств при попытках их использовать как человеко-читаемые файлы. Может быть, это иногда хорошо. Если хотим прокомментировать, то будем вынуждены оформить комментарий под или над строкой как «ключ-значение».

...{...
    "some-key_comment":"my comment for key and value",
    "some-key":"some-value",
...}...

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

...{...
    "some-key":"some-value", //какой-какой key?? Ай, комментарии - нельзя!
...}...

Придумаем JSON-подобный формат с комментариями в стиле JS, чтобы их можно было выполнять как JS, а, очистив от комментариев — читать как JSON. ("TL:DR: покажите мне код.")

Введение. Постановка вопроса.

В школьной программе, к сожалению, сферическую геометрию и геометрию Лобачевского не изучают. Тем временем, их изучение совместно с Евклидовой геометрией, позволяет глубже понять происходящее с объектами. Например, понять связь правильных многогранников с разбиениями сферы, разбиениями плоскости Евклида и разбиениями плоскости Лобачевского.
Знания геометрии пространств постоянной кривизны помогает подниматься над трёхмерием и выявлять многогранники в пространствах размерности 4 и выше. Вопросы нахождения многогранников, нахождения разбиений пространств постоянной кривизны, вывода формулы двугранного угла правильного многогранника в n-мерном пространстве — так тесно переплетены, что выносить всё это в название статьи оказалось проблематично. Пусть в центре внимания будут, всем понятные, правильные многогранники, хотя они не только результат всех выводов, но и, одновременно, инструмент для постижения пространств высших размерностей и равномерно искривлённых пространств.

Для тех кто не знает (забыл) сообщаю (напоминаю), что в привычном нам трёхмерном Евклидовом пространстве всего пять правильных многогранников:

1. Тетраэдр:	2. Куб:	3. Октаэдр:	4. Додекаэдр:	5. Икосаэдр:

1. Введение

В этой статье я попытаюсь исследовать и развенчать пять популярных мифов про C++:

1. Чтобы понять С++, сначала нужно выучить С
2. С++ — это объектно-ориентированный язык программирования
3. В надёжных программах необходима сборка мусора
4. Для достижения эффективности необходимо писать низкоуровневый код
5. С++ подходит только для больших и сложных программ

Если вы или ваши коллеги верите в эти мифы – эта статья для вас. Некоторые мифы правдивы для кого-то, для какой-то задачи в какой-то момент времени. Тем не менее, сегодняшний C++, использующий компиляторы ISO C++ 2011, делает эти утверждения мифами.

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

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

Все началось с данного топика на сайте gamedev.ru. Топикстартер предложил найти сортировку, которая обладает следующими свойствами:

1. Время выполнения — гарантированные O(nlogn).
2. Использование O(1) дополнительной памяти.
3. Применимость для сортировки данных в односвязных списках (но не ограничиваясь ими).

Оговорки на все три ограничения:

1. Гарантированные O(nlogn) означают, что, например, среднее время быстрой сортировки не подходит — должно получаться O(nlogn) для любых, даже самых худших входных данных.
2. Рекурсию использовать нельзя, поскольку она подразумевает O(logn) памяти на хранение стека рекурсивных вызовов.
3. Произвольного доступа к элементам сортируемого массива нет, мы можем двигаться итератором от любого элемента только к соседнему (за O(1)), причем только в одном направлении (вперед по списку). Модифицировать сам список (перевешивать указатели на следующие элементы) нельзя.

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

Под катом можно узнать, что в итоге получилось у нас.

Challenge. Прежде чем заглядывать под кат, предлагаю сначала самостоятельно подумать над алгоритмом. Если придумается что-то круче нашего варианта — напишите в комментариях.

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

1 Один столбец вместо нескольких

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

Maciej Czyzewski собрал на Github коллекцию исходных кодов различных алгоритмов хеширования: для вычисления контрольных сумм, некриптографических и криптографических.

В репозитории можно найти, к примеру, реализации CRC/MD5/ГОСТ 34.311-95/SHA-3. Каждая хеш-функция представлена исходником на языке С и make-файлом для его сборки. Алгоритмы предполагается использовать в целях обучения — в реальных проектах рекомендуется в целях безопасности использовать существующие библиотеки (например, Crypto++ для C++, BouncyCastle для Java и т.д.), список которых есть в репозитории.

Над репозиторием продолжается активная работа, поэтому в перспективе стоит ждать пополнения коллекции.

Github

Скриптинг — пожалуй наиболее важная (хотя и не самая сложная) часть задуманного мной проекта. Для того, чтобы всё заработало, мне потребуется язык общего назначения, с переменными, условным выполнением, циклами и исключениями. Мне не требуется что-то сложное, вроде анонимных функций или замыканий. Скорее всего, мне не пригодится даже рекурсия, во всяком случае, пока, для неё не нашлось применений, ни в одном из моих case-ов. В этом языке совсем не будет синтаксического сахара, поскольку все задачи метапрограмирования возьмёт на себя XSLT. В общем, этот язык будет прост настолько, насколько это возможно, но… не проще. 

Маленькая Лямбда решила, что уборку в комнате можно отложить и на потом.

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

foldl (+) 0 [1..10^8]

потребует для своего вычисления гигабайты памяти.

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

Тема ленивых вычислений рассматривалась во многих учебниках (например, в книге Саймона Томпсона «Haskell — The Craft of Functional Programming»), но информацию о них, кажется, всё ещё проблематично найти в сети. Надеюсь, моё руководство посодействует решению этой проблемы.

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

Часть 1

4.1 $rootScope

$rootScope не сильно отличается от $scope, просто это объект $scope самого верхнего уровня, от которого происходят все остальные области видимости. Когда Angular начинает создание вашего приложение, он создаёт объект $rootScope, и все привязки и логика приложения создают объекты $scope, являющиеся наследниками $rootScope.

Обычно мы не используем $rootScope, но с его помощью можно обеспечить передачу данных между разными областями видимости.

Первого января 2015 года по расписанию вышла новая версия библиотеки для работы с изображениями Pillow 2.7. Так как многие изменения в ней были сделаны командой Uploadcare, мы рады представить вам расширенную версию заметок о релизе этой версии.

Для начала вспомним, с чего все началось. Pillow — дружественный форк (как называют его авторы) популярной библиотеки PIL, Python Imaging Library. Последняя версия PIL 1.1.7 вышла в 2009 году и в основном содержала исправления ошибок. Изначально Pillow задумывался как проект только по приведению в порядок сборки PIL, и разработчики рекомендовали отправлять все баги, не связанные со сборкой, в оригинальный PIL. Но время шло, PIL стремительно устаревала, багов не уменьшалось, тут еще Python 3 маячил на горизонте. Поэтому с версией Pillow 2.0 все изменилось. «Pillow 2.0.0 добавляет поддержку Python 3 и включает много багфиксов со всего интернета» гласит описание проекта на PyPI. И с тех пор понеслось. Каждые три месяца выходили версии с огромным количеством багфиксов и другими улучшениями от различных разработчиков. Самым значительным нововведением за это время было, пожалуй, поддержка форматов WebP и JPEG2000. Теперь пришло время следующего большого шага.

В Java для введения порядка среди определённых объектов можно написать компаратор — класс, содержащий функцию compare, которая сравнивает два объекта. Альтернативой компаратору является естественный порядок объектов: объект реализует интерфейс Comparable, который содержит метод compareTo, позволяющий сравнить этот объект с другим. Сравнивающая функция должна вернуть 0, если объекты равны, отрицательное число (обычно -1), если первый объект меньше второго, и положительное число (обычно 1), если первый больше. Обычно реализация такой функции не представляет сложностей, но имеется один случай, о котором многие забывают.

Сравнение используется различными алгоритмами от сортировки и двоичного поиска до поддержания порядка в сортированных коллекциях вроде TreeMap. Эти алгоритмы завязаны на три важных свойства сравнивающей функции: рефлексивность (сравнение элемента с самим собой всегда даёт 0), антисимметричность (сравнение A с B и B с A должны дать разный знак) и транзитивность (если сравнение A с B и B с C выдаёт одинаковый знак, то и сравнение A с C должно выдать такой же). Если сравнивающая функция не удовлетворяет этим свойствам, алгоритм может выдать совершенно непредсказуемый результат. Причём скорее всего вы не получите никакого исключения, просто результат будет неверный.

Как обнаружилось, несоблюдение этих свойств — не такая уж редкая ситуация. Проблема возникает при сравнении вещественных чисел — float или double.

Я покажу как собрать простой, но достаточно мощный, генератор на 220 вольт.

Потребуется:

— коллекторный мотор, можно другой на 12 вольт
— насадка на ось мотора — патрон от дрели
— бесперебойник UPS или инвертор с 12 на 220
— диод на 10 ампер: Д214, Д242, Д215, Д232, КД203 и т. д.
— провода
— велосипед
— и желательно аккумулятор на 12 вольт

Сборка:

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

Содержание

1 Введение в AngularJS
2 Engineering concepts in JavaScript frameworks
3 Modules
4 Understanding $scope
5 Controllers
6 Services and Factories
7 Templating with the Angular core
8 Directives (Core)
9 Directives (Custom)
10 Filters (Core)
11 Filters (Custom)
12 Dynamic routing with $routeProvider
13 Form Validation
14 Server communication with $http and $resource

1 Введение в AngularJS

Angular – MVW-фреймворк для разработки качественных клиентских веб-приложений на JavaScript. Он создан и поддерживается в Google и предлагает взглянуть на будущее веба, на то, какие новые возможности и стандарты он готовит для нас.

MVW означает Model-View-Whatever (модель – вид – что угодно), то есть гибкость в выборе шаблонов проектирования при разработке приложений. Мы можем выбрать модели MVC (Model-View-Controller) или MVVM (Model-View-ViewModel).

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

Обработка текста в поисковом движке выглядит достаточно простой снаружи, однако на самом деле это сложный процесс. При индексации текст документов должен быть обработан стриппером HTML, токенайзером, фильтром стоп-слов, фильтром словоформ и морфологическим процессором. А ещё при этом нужно помнить про исключения (exceptions), слитные (blended) символы, N-граммы и границы предложений. При поиске всё становится ещё сложнее, поскольку помимо всего вышеупомянутого нужно вдобавок обрабатывать синтаксис запроса, который добавляет всевозможные спец. символы (операторы и маски). Сейчас мы расскажем, как всё это работает в Sphinx.

Картина в целом

Упрощённо конвейер обработки текста (в движке версий 2.х) выглядит примерно так:



Выглядит достаточно просто, однако дьявол кроется в деталях. Есть несколько очень разных фильтров (которые применяются в особом порядке); токенайзер занимается ещё чем-то помимо разбиения текста на слова; и наконец под «и т.д.» в блоке морфологии на самом деле находится ещё по меньшей мере три разных варианта.

Поэтому более точной будет следующая картина: