Привет, Хабр! Представляю вашему вниманию перевод статьи "Equivalents in Python and JavaScript. Part 1".

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

Это не справочник, здесь не будет базовой информация о типах переменных, if-ах и циклах.
Но мы рассмотрим более сложные структуры данных и операции с ними используя Python и Javascript.

Также я проиллюстрирую это примерами из практики.

Эта серия будет интересна бэкендерам, использующим Django, Flask или любой другой Python-фреймворк, которые хотят получше узнать о современном Javascript'е. С другой стороны, эти статьи будут полезны фронтендерам, которые желают лучше понять как работает бэкенд, или даже написать свой сайт на Django.

Остальные статьи в этой серии:

1. Часть вторая: JSON, регулярки, ошибки-исключения
2. Часть третья: современные Python и JS: строковые шаблоны (f-строки), распаковка списков, лямбда-функции, итерации по спискам, генераторы, множества.
3. Четвертая часть — аргументы функций, создание и работа с классами, наследование, геттеры-сеттеры и свойства класса.

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

Я никогда так не думал. Я любил офис и эту спокойную сосредоточенность рабочего места. Думал, никогда со мной не случится. Но удалёнка случилась. Уже два года. И я пишу сюда, на любимый Хабр, свой очень субъективный пост — просто, чтобы была вторая сторона этой, как оказалось, тянущей шею медали.


Adme.ru

Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

С момента появления Node.js диагностика совершенствовалась в несколько этапов, от отладки приложений до глубокого анализа производительности. В этот раз речь пойдет о стратегиях использования таких инструментов, как core dump debuggers, flame graphs, ошибках в production и утечке памяти.


Мы расшифровали для Хабра доклад Николая Матвиенко из Grid Dynamics с нашей конференции HolyJS. Далее повествование идёт от лица спикера.

Экзамен в школе прапорщиков.
— Вот смотрите. Это большой палец, это — указательный, это — средний, это — безымянный, это — мизинец. Мешаем, мешаем, мешаем (двигает пальцами)… Теперь где какой?

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

Перед моими студентами регулярно встаёт задача случайного перемешивания массива. За её решением они, как правило, лезут в гугл. И гугл им подсказывает следующее:

var shuffledArr = arr.sort(function(){
  return Math.random() - 0.5;
});

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

React — это один из ведущих фронтенд-фреймворков не только потому, что за ним стоит Facebook, но и благодаря его высокой производительности. Виртуальный DOM React известен благодаря эффективному рендерингу компонентов. Но как быть, если эти компоненты внезапно становятся не такими уж и быстрыми? Куда стоит посмотреть? Как это исправить?

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

Webpack фактически стал стандартом для сборки крупных приложений на JS. Его используют практически все. Для разработчика webpack выглядит как магический черный ящик: если забросить в него файлы и небольшой конфиг, на выходе автоматически появится бандл.

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


В основе материала — доклад Алексея Иванова на конференции HolyJS 2017, проходившей в Санкт-Петербурге 2-3 июня.

Если вы не в курсе, в Node.js, начиная с версии 7.6, встроена поддержка механизма async/await. Говорят о нём, конечно, уже давно, но одно дело, когда для использования некоей функциональности нужны «костыли», и совсем другое, когда всё это идёт, что называется, «из коробки». Если вы ещё не пробовали async/await — обязательно попробуйте.


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

Рассказ о том, как выглядит интернет, развивающийся в отрыве от глобальной сети

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

Может, я такой расист и ненавижу Китай? Или я не знаю языка? Или я просто вредный зануда? 

Пока все активно делятся своими впечатлениями от CSS-гридов, я не слышал, чтобы кто-то столь же много говорил о новой единице длины в CSS — fr (см. спецификацию). И теперь, когда браузеры все лучше начинают поддерживать ее, я думаю, пора взглянуть на то, как ее можно использовать в сочетании с этой техникой вёрстки, поскольку это дает нам ряд преимуществ. Главные из них — это более понятный и удобный в сопровождении код.

От переводчика:
Предлагаю вашему вниманию перевод краткого (действительно краткого) руководства по ES6. В нём можно ознакомиться с основными понятиями стандарта.
Оригинальный текст в некоторых случаях был дополнен или заменён на более подходящий источник. Например, часть определения ключевого слова const является переводом документации с MDN.
Чтобы лучше разобраться в некоторых концепциях (для выполнения качественного перевода) использовалось описание стандарта на сайте MDN, руководство "You Don't Know JS: ES6 & Beyond" и учебник Ильи Кантора.

Перевод выложил на Гитхаб: https://github.com/etnolover/ES6-for-humans-translation. В случае нахождения ошибок пишите, исправлю.
Ссылка на оригинальный текст: https://github.com/metagrover/ES6-for-humans

Update 22.07.2016: добавил опрос про const

Содержание

• let, const и блочная область видимости
• Стрелочные функции
• Параметры по умолчанию
• Spread/Rest оператор
• Расширение возможностей литералов объекта
• Восьмеричный и двоичный литералы
• Деструктуризация массивов и объектов
• Ключевое слово super для объектов
• Строковые шаблоны и разделители
• for...of против for...in
• Map и WeakMap
• Set и WeakSet
• Классы в ES6
• Тип данных Symbol
• Итераторы
• Генераторы

• Промисы

  
  
• Опрос: в каком регистре писать const?

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

Когда вышла версия 1.0 Redux, я решил потратить немного времени на серию рассказов о моем опыте работы с ним. Недавно я должен был выбрать “реализацию Flux” для клиентского приложения и до сих пор с удовольствием работаю с Redux.

Почему Redux?

Redux позиционирует себя как предсказуемый контейнер состояния (state) для JavaScript приложений. Редакс вдохновлен Flux и Elm. Если вы раньше использовали Flux, я советую прочитать, что Redux имеет с ним общего в разделе "Предшественники" новой (отличной!) документации.

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

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

В JavaScript есть тысячи способов выделить память, но разработчики языка лишили нас права её освобождать. Этим занимается сборщик мусора (Garbage collector, GC), функций управления которым также нет. В большинстве случаев он неплохо справляется со своей работой, однако когда в программе непрерывно освобождаются большие объёмы данных, порядка мегабайта в секунду, сборщик мусора может тупить, из-за чего процесс браузера разрастается в памяти до невменяемых размеров. В этой статье я покажу пару грязных трюков, с помощью которых можно ускорить освобождение памяти.

Если вы желаете что-то сделать, то есть два способа этого достичь.

Первый, более распространённый и в значительной мере неправильный вариант — попытаться мотивировать себя.

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

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

В чём же разница?

В этой статье хочу поделиться переводом статьи о нативных ECMAScript модулях, которые все больше и больше обсуждаются среди фронтендеров. Javascript ранее никогда не поддерживал нативно работу с модулями, и нам, фронтендерам, всегда приходилось использовать дополнительные инструменты для работы с модулями. Но вы только представьте, что в скором времени не нужно будет использовать Webpack для создания бандлов модулей. Представьте мир, в котором браузер будет собирать все за вас. Подробнее об этих перспективах я и хочу рассказать.

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

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

JavaScript принято считать прототип-ориентированным языком программирования. Но, как ни странно, этим подходом практически никто не пользуется: большинство популярных JS-фреймворков явно или неявно оперируют классами.
В этой статье я хочу рассказать об альтернативном способе программирования на JavaScript, без использования классов и конструкторов — чистым прототипным ООП и особенностях его реализации на ECMA Script 5.

В этой статье я кратко в примерах объясню что такое свойства __proto__, prototype и работу оператора new в JavaScript.

Свойство __proto__

Абсолютно любой объект в JavaScript имеет свойство __proto__. Это скрытое системное свойство, и не во всех реализациях языка оно доступно пользователю.
При обращении к любому свойству объекта, оно в первую очередь ищется в самом объекте:

var obj = {ownProperty: 1};
console.log(obj.ownProperty);// 1

Но если его там нет, поиск происходит в свойстве __proto__:

obj.__proto__ = {propertyOfProto: 2};
console.log(obj.propertyOfProto);// 2

Если его нет и там, оно ищется дальше по цепочке:

obj.__proto__.__proto__ = {propertyOfProtosProto: 3};
console.log(obj.propertyOfProtosProto);// 3

Эта цепочка называется цепочкой прототипов (prototype chain).