Это перевод поста из официального блога JS-движка V8. Статья короткая, текста мало, больше похоже на увлекательный рассказ о проблемах, подстерегающих ни о чём не подозревающих сотрудников Google в коде V8. Речь пойдёт об ускорении обработки ES6 Прокси в V8, которое будет доступно в Chrome 62 и Node v9.x, и совсем немного о том, как лучше применять прокси для получения максимальной скорости работы.

Введение

Прокси появились в JavaScript с принятием стандарта ES2015. Они позволяют перехватывать фундаментальные операции объектов и переопределять их поведение. Прокси являются основой таких библиотек, как jsdom или Complink RPC library. В последнее время мы приложили много усилий, чтобы улучшить производительность прокси в V8. Эта статья проливает немного света на общие подходы к улучшению производительности в V8 и для прокси в частности.

Предлагаю читателям Хабра мой перевод статьи «44 урока управления технарями» Славы Ахмечета, сооснователя RethinkDB. В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.

Немного об оригинальном тексте. Статья была написана в 2014 году в личном блоге автора, в октябре 2016 компания RethinkDB не смогла выйти в прибыль и закрылась, о чем на Хабре писали тут и тут, а Слава поразмышлял об этом здесь.

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

Источник

Похоже, сегодня ИТ-специалисту в России стало легче найти работу. Последние впечатления от российского рынка труда: предложения с уровнем зарплаты существенно выше среднего получают специалисты самых разных профилей и не обязательно высокой квалификации. Более того, похоже, что в кои-то веки ИТ-профессионалы получили возможность выбирать из конкурентных предложений! Кандидаты без специального образования и довольно посредственно, на уровне любителя, разбирающиеся в профильных технологиях, с гордостью публикуют в соцсетях свои новые должности — разработчиков, специалистов по технической поддержке, внедренцев…

К тому же, в прессе все чаще появляются истории о низкоквалифицированных разработчиках, которые тем не менее успешно проходили интервью, и уже в ходе работы наносили огромной финансовый ущерб компании. Так, Uber в 2015 случайно опубликовал паспортные данные своих водителей, а Google в 2010 году понес убытки в $100 млн долларов и проиграл суд компании Oracle за использование без разрешения 11 строк кода. И уже не из жизни гигантов: когда работодатель не понимает, что делает разработчик, а сам сотрудник пользуется этим и завышает как сложность своей работы, так и ее стоимость, а впоследствии и пренебрегает добросовестностью исполнения служебных заданий.

Наш интерес к этим вещам далеко не праздный, ведь для агентства AGIMA ИТ-профессионалы — главный производственный актив. Поэтому HR-отдел агентства попросил наших аналитиков отложить в сторону Google Analytics, сплит-тестирования, карточные сортировки и разобраться в этих вопросах. В ходе эксперимента ни один аналитик и текущий проект компании не пострадали.

Недавно мы опубликовали материал «Промисы в ES6: паттерны и анти-паттерны». Он вызвал серьёзный интерес аудитории, в комментариях к нему наши читатели рассуждали об особенностях написания асинхронного кода в современных JS-проектах. Кстати, советуем почитать их комментарии — найдёте там много интересного.



По совету пользователя ilnuribat мы добавили к материалу опрос, целью которого было выяснить популярность промисов, коллбэков и конструкций async / await. По состоянию на 9-е сентября промисы и async / await получили примерно по 43% голосов, с небольшим перевесом async / await, коллбэкам досталось 14%. Главный вывод, который можно сделать, проанализировав результаты опроса и комментарии, заключается в том, что важны все имеющиеся технологии, однако, всё больше программистов тяготеют к async / await. Поэтому сегодня мы решили опубликовать перевод статьи про переход на async / await, которая является продолжением материала о промисах.

Привет, Хаброжители! Данная книга — руководство по самым разным вычислительным и статистическим методам, без которых немыслима любая интенсивная обработка данных, научные исследования и передовые разработки. Читатели, уже имеющие опыт программирования и желающие эффективно использовать Python в сфере Data Science, найдут в этой книге ответы на всевозможные вопросы, например: как считать этот формат данных в скрипт? как преобразовать, очистить эти данные и манипулировать ими? как визуализировать данные такого типа? как при помощи этих данных разобраться в ситуации, получить ответы на вопросы, построить статистические модели или реализовать машинное обучение?

Ниже под катом обзор книги и отрывок «Гистограммы, разбиения по интервалам и плотность»

Привет! Меня зовут Артем, я из небольшой студии разработки игр в Нижнем Новгороде. За первый год в геймдеве у нашей команды накопились мысли о разных аспектах работы и появилось желание ими поделиться. Сразу хочется обозначить, что все дальнейшие выводы человеку с опытом могут показаться детским лепетом и это вполне понятно. Но для нас эти тезисы, в свое время, стали открытием, а значит, есть вероятность, что и для кого-то, кто только начинает свой путь в геймдеве они станут таким же открытием и помогут избежать подобных ошибок.

Большинство разработчиков начинает знакомство с Redux с Todo List Project. Это приложение имеет следующую структуру:

actions/
  todos.js
components/
  todos/
    TodoItem.js
    ...
constants/
  actionTypes.js
reducers/
  todos.js
index.js
rootReducer.js

На первый взгляд такая организация кода кажется логичной, ведь она напоминает стандартные соглашения многих backend MVC-фреймворков:

app/
  controllers/
  models/
  views/

На самом деле, это неудачный выбор как для MVC, так и для React+Redux приложений по следующим причинам:

1. С ростом приложения следить за взаимосвязью между компонентами, экшнами и редюсерами становится крайне сложно
2. При изменении экшна или компонента с большой вероятностью потребуется внести изменения и в редюсер. Если количество файлов велико, скролить IDE вверх/вниз не удобно
3. Такая структура потворствует копипасте в редюсерах

Не удивительно, что многие авторы(раз, два, три) советуют структурировать приложение по «функциональности» (by feature).

В официальной документации Laravel написана целая страница о Homestead, но проблема в том, что в ней мало разъяснений зачем это вообще надо. В документации скорее инструкция для тех кто уже знаком и с VirtualBox и с Vagrant и с Linux (Ubuntu). Если Вы из таких — статья не откроет что-то новое, но если Вы прочитали про Homestead в документации и не поняли зачем это вообще надо, или что-то не получилось выполнить по инструкции — в этой статье все будет разжевано подробно.

James Kyle как-то раз взял и написал пост про структуры данных, добавив их реализацию на JavaScript. А я взял и перевёл.

Дисклеймер: в посте много ascii-графики. Не стоит его читать с мобильного устройства — вас разочарует форматирование текста.

Меня зовут Павел, я фронтенд-разработчик Tinkoff.ru. Наша команда занимается разработкой интернет-банка для юридических лиц. Фронтенд наших проектов был реализован с применением AngularJS, с которого мы перешли, частично с использованием Angular Upgrade, на новый Angular (ранее позиционировался как Angular 2).

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

В этой статье мы заглянем «под капот» реализации форм в Angular и разберёмся, как создавать кастомные поля ввода.

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

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

Хотя это не самая простая тема, но как только мы сумеем ее понять, мы спросим себя, как мы могли без нее жить?

Мне очень понравилась ветка обсуждений на Quora.com: What is the hardest part about learning to program? Все 87 ответов я так и не прочитал, но понравившиеся, выделил в отдельную статью из 10 пунктов. Это вольный пересказ мнений многих разных людей. Если читателям будет интересно, я продолжу.

1. Разница между высокими стандартами и своими низкими умениями

В статье «Никто не говорит об этом новичкам» рассказывается об общей проблеме людей, занятых творческим или интеллектуальным трудом. Программирование — сложный предмет, и обычно за него берутся способные, амбициозные и склонные к перфекционизму люди. На начальном этапе у них не будет хорошо получаться. Привыкшие к высокой планке, они будут расстраиваться. Внутренний голос будет постоянно нашептывать: “У тебя никогда и не получится, лучше оставь это дело”. В такие моменты думайте о том, что ваша самокритичность — это признак вашей экстраординарности, и верьте, что преодолеете этот “неумелый период”.

Что касается необычайных преимуществ программирования, то вот они:

Не у каждого хватает смелости поменять освоенную профессию, в которой уже достиг каких-то вершин. Ведь это требует больших усилий, а положительный результат не гарантирован. Полтора года назад мы рассказывали, как один из наших тимлидов серверной разработки переквалифицировался в iOS-программиста. И сегодня мы хотим рассказать о ещё более «крутом повороте»: Алан Chetter2 Басишвили, занимавшийся frontend-разработкой, настолько увлёкся машинным обучением, что вскоре превратился в серьёзного специалиста, стал одним из ключевых разработчиков популярного проекта Artisto, а теперь занимается распознаванием лиц в Облаке Mail.Ru. Интервью с ним читайте под катом.

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

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

Но врожденные любознательность и энтузиазм довели меня до того, что я стал одним из разработчиков Synaptic — проекта фреймворка для построения нейронных сетей на JS с 3к+ звезд на GitHub. Сейчас мы с автором фреймворка занимаемся созданием Synaptic 2.0 с ускорением на GPU и WebWorker-ах и с поддержкой почти всех основных фич любого приличного NN-фреймворка.

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

Идея для написания этой статьи возникла прошлым летом, когда я слушал доклад на конференции BigData по нейронным сетям. Лектор «посыпал» слушателей непривычными словечками «нейрон», «обучающая выборка», «тренировать модель»… «Ничего не понял — пора в менеджеры», — подумал я. Но недавно тема нейронных сетей все же коснулась моей работы и я решил на простом примере показать, как использовать этот инструмент на языке JavaScript.

Мы создадим нейронную сеть, с помощью которой будем распознавать ручное написание цифры от 0 до 9. Рабочий пример займет несколько строк. Код будет понятен даже тем программистам, которые не имели дело с нейронными сетями ранее. Как это все работает, можно будет посмотреть прямо в браузере.

Мы знаем, что такое вести блог на Хабрахабр, а значит имеем представление и о том, как чувствует себя рекрутер в мире it. Знаем, что бывает непросто, но наша статья — это прям свет надежды на взаимопонимание и прощение.

Это перевод статьи Being a Remote Worker Sucks — Long Live the Remote Worker Скотта Хенселмана за 27 февраля.

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

Работать удалённо – прекрасно, отстой.

Этот материал посвящён тому, как внутренние механизмы V8 работают со свойствами JavaScript-объектов. Если рассматривать свойства с точки зрения JavaScript, то разные их виды отличаются друг от друга не так уж и сильно. Скажем, JS-объекты обычно ведут себя как словари со строковыми ключами и произвольными объектами в качестве значений. Однако, если почитать спецификацию языка, можно выяснить, например, что свойства разных видов по-разному ведут себя при их переборе. В других случаях поведение свойств различных видов, в основном, выглядит одинаково.

Казалось бы, реализация механизма работы со свойствами, учитывая их схожесть, задача не такая уж и масштабная, однако, в недрах V8 используется несколько различных способов представления свойств. Сделано это, во-первых, для обеспечения высокой производительности, во-вторых — ради экономии памяти.



В этом материале мы хотим рассказать о том, как V8 добивается высокой производительности при обработке динамически добавляемых свойств объектов. Знание особенностей механизма работы со свойствами необходимо для понимания сущности способов оптимизации выполнения JavaScript в V8, таких, например, как встроенные кэши.

Однажды я собирал материалы чтобы устроить ликбез по JavaScript для пары коллег. Тогда я и наткнулся на довольно интересный пример, в котором рассматривалось сравнение значения null с нулём. Собственно говоря, вот этот пример:

null > 0; // false
null == 0; // false
null >= 0; // true

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