Спасибо за статью. Не хватает ссылки на javascript реализацию в проекте swarm. Еще недавно про swarm активно докладывали на MoscowJS, но что-то давно про них ничего не слышал…
Так статья врет. И самое ужасное то, что кто-то действительно прочитает ее, не будет читать комментарии здесь или к оригиналу и пойдет по своему коду изменять for на forEach с твердой уверенностью, что все делает правильно.
Статья требует апдейта из комментариев к оригиналу.
Во-первых, в последнем примере sort() без параметром сортирует числа как строки, что может привести к абсолютно неверному нахождению медианы.
Во-вторых, isIn2 быстрее, чем isIn1, а не наоборот. Почему ошибся автор? Он запускал код в CodePen, который в каждый цикл внедряет специальный код, не позволящий уйти в бесконечность. Так что мир не перевернулся, не пугайтесь: цикл for быстрее, чем forEach.
Так что лучший способ сделать свой код быстрее — подумать головой, измерить и подумать еще раз)
Достаточно сумбурно, но в целом познавательно. Совсем недавно на highload 2015 был отличный доклад на аналогичную тему перевода старого фронтенда на новый лад в Акронис. Так вот ребята не испугались и таки провели постепенный переход с ExtJS на React + собственную реализацию Flux. Соответственно встает несколько вопросов:
1) Что же у вас за такой магический сборщик, в который и JSX не вставляется, и ES6 не подтягивается, но выкинуть на свалку его вы не захотели? И вместо того, чтобы взять готовые webpack + babel, вы решили написать свою обвязку к virtual dom? На мой взгляд, если не начать переводить код на ES6 сейчас, то через год-два фронтендеры будут задавать вам на собеседованиях дополнительные вопросы типо: «IE6 вы тоже еще поддерживаете да?».
2) Самому очень нравится Redux + чистые функции. Но используете ли вы какую-то библиотеку для immutable данных или свое решение?
Автоматизированные тесты (в том числе юнит тесты) — это не только проверочное средство, но еще и дополнительное орудие в борьбе со сложностью системы в целом. Без юнит тестов немыслимо развивать большие системы: фиксят одни баги — появляются другие, реализовывают новый функционал — отваливается старый. При налаженной системе тестирование вносить в код любые изменения можно быстрее и с меньшим количеством ошибок.
По-разному. Мои коллеги в общем-то несколько разочарованы. Мне же удалось услышать во второй день интересную/полезную информацию в секции фронтенда, например, парень из YouTube неплохо говорил, «Скорость с доставкой до пользователя» отличный глубокий доклад.
Но в основном всякие очевидности преподносят, как что-то ценное: мы запустили Node.js с NODE_ENV=production и стало реально быстрее. Смешно.
Спасибо за перевод подробного туториала. Ожидал увидеть в статье информацию по PM2, но не увидел. Не знаете в каком сейчас состоянии проект и можно ли его использовать на продакшн?
Как раз в статье я указываю, что сортировка неустойчивая. Из неустойчивости и вытекает ваш пример.
Думаю будет полезно добавить ссылочку в саму статью на ваш комментарий, спасибо.
v8 не написан целиком на javascript, большинство составляющих (парсер, неоптимизирующий компилятор, оптимизирующий компилятор и др) написаны на C++. А вот стандартная библиотека написана на JS, и она компилируется в нативный код почти так же, как ваш «внешний» js код (только у вас нет доступа к native syntax, а в стандартной библиотеке он используется повсеместно).
Не знаю, с чего вы срываете покровы, но быстрая сортировка используется далеко не везде.
В статье есть ссылка на исходный код SpiderMonkey, в котором используют сортировку слиянием. И если мне не изменяет память, то в настоящий момент в CPython и OpenJDK используется алгоритм Timsort.
Насчет Google. Возможность корректно отображать документ в разных браузерах в первую очередь связано с тем, как сервис вычисляет размеры букв каждого конкретного шрифта, а не c HTML4 vs HTML5.
В случае, когда используется определение размера букв шрифта силами браузера, то результат в разных браузерах+ОС будет заметно отличаться; если же размеры шрифта вычисляются на основе информации присланной с сервера или извлекаются непосредственно из woff или ttf файла, то на всех платформах размер будет рассчитан идентично. Но, как видим, Google использует первый вариант.
Если тема интересна с технической точки зрения, то можете ознакомится с презентацией моего доклада Редактор Mail.ru. Frontend.
Во-первых, в последнем примере sort() без параметром сортирует числа как строки, что может привести к абсолютно неверному нахождению медианы.
Во-вторых, isIn2 быстрее, чем isIn1, а не наоборот. Почему ошибся автор? Он запускал код в CodePen, который в каждый цикл внедряет специальный код, не позволящий уйти в бесконечность. Так что мир не перевернулся, не пугайтесь: цикл for быстрее, чем forEach.
Так что лучший способ сделать свой код быстрее — подумать головой, измерить и подумать еще раз)
1) Что же у вас за такой магический сборщик, в который и JSX не вставляется, и ES6 не подтягивается, но выкинуть на свалку его вы не захотели? И вместо того, чтобы взять готовые webpack + babel, вы решили написать свою обвязку к virtual dom? На мой взгляд, если не начать переводить код на ES6 сейчас, то через год-два фронтендеры будут задавать вам на собеседованиях дополнительные вопросы типо: «IE6 вы тоже еще поддерживаете да?».
2) Самому очень нравится Redux + чистые функции. Но используете ли вы какую-то библиотеку для immutable данных или свое решение?
Но в основном всякие очевидности преподносят, как что-то ценное: мы запустили Node.js с NODE_ENV=production и стало реально быстрее. Смешно.
Думаю будет полезно добавить ссылочку в саму статью на ваш комментарий, спасибо.
В статье есть ссылка на исходный код SpiderMonkey, в котором используют сортировку слиянием. И если мне не изменяет память, то в настоящий момент в CPython и OpenJDK используется алгоритм Timsort.
В случае, когда используется определение размера букв шрифта силами браузера, то результат в разных браузерах+ОС будет заметно отличаться; если же размеры шрифта вычисляются на основе информации присланной с сервера или извлекаются непосредственно из woff или ttf файла, то на всех платформах размер будет рассчитан идентично. Но, как видим, Google использует первый вариант.
Если тема интересна с технической точки зрения, то можете ознакомится с презентацией моего доклада Редактор Mail.ru. Frontend.