JavaScript *

Всем привет! Сегодня мы напишем своего первого боевого торгового робота для игры на бирже. Криптобирже. Почему криптобирже?

а) хайповая тема;
б) у них как-то все попроще.

Во-первых, хочу сразу предупредить любителей казино «три топора»: на машину вы завтра не заработаете. Статья больше о том, как начать писать своих роботов, поэтому алгоритм будет примитивный, но рабочий.

Во-вторых, Вы заработаете. Просто немного.

В материале, перевод которого мы сегодня публикуем, речь пойдёт о том, что делать в ситуации, когда данные, получаемые с сервера, выглядят не так, как нужно клиенту. А именно, сначала мы рассмотрим типичную проблему такого рода, а потом разберём несколько путей её решения.

Сегодня, в переводе 17 части материалов, посвящённых особенностям всего, что так или иначе связано с JavaScript, речь пойдёт о веб-компонентах и о различных стандартах, которые направлены на работу с ними. Особое внимание здесь будет уделено технологии Shadow DOM.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Заметил за собой, что постоянно записываю всякие мелочи, полезную информацию, просто что-то из буфера обмена прямо в текстовом редакторе. Всегда где-то на фоне висит открытый Sublime Text с кучей вкладок.

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

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

Всё это привело меня к мысли написать что-то вроде своего движка для хранения всей информации в одном месте и в удобном виде. Да-да, есть куча всяких Evernote, каких-нибудь заметок, встроенных в MacOS/iOS и так далее, которые и синхронизируются, и фичи полезные имеют — но, как говорится, хочешь сделать что-то хорошо (для себя), сделай это сам. Да и, как почти любой программист, в любой непонятной ситуации я беру и пишу всё сам. Так вышло и в этот раз.

Некоторое время назад я задумался, почему так много UI frameworks для web? Я довольно давно в IT и не помню чтоб UI библиотеки на других платформах рождались и умирали с такой же скоростью как в WEB. Библиотеки для настольных OS, такие как: MFC, Qt, WPF, и т.д. — были монстрами, которые развивались годами и не имели большого количества альтернатив. В Web все не так — frameworks выходят чуть ли не каждую неделю, лидеры меняются — почему так происходит?

Думаю главная причина в том — что резко снизилась сложность написания UI библиотек. Да, для того чтобы написать библиотеку которой многие будут пользоваться — по прежнему требуется значительное время и экспертиза, но чтобы написать прототип — который будучи обернутый в удобный API — будет готов к использованию — требуется совсем немного времени. Если интересно как это можно сделать — читайте дальше.

Совсем недавно вышла версия 10.5.0 платформы Node.js. Одной из её главных возможностей стала впервые добавленная в Node.js поддержка работы с потоками, пока носящая статус экспериментальной. Этот факт особенно интересен в свете того, что данная возможность теперь есть у платформы, адепты которой всегда гордились тем, что потоки ей, благодаря фантастической асинхронной подсистеме ввода-вывода, не нужны. Однако, поддержка потоков в Node.js всё же появилась. С чего бы это? Кому и зачем они могут пригодиться?



Если в двух словах, то нужно это для того, чтобы платформа Node.js могла бы достигнуть новых высот в тех областях, в которых раньше она показывала не самые замечательные результаты. Речь идёт о выполнении вычислений, интенсивно использующих ресурсы процессора. Это, в основном, является причиной того, что Node.js не отличается сильными позициями в таких сферах, как искусственный интеллект, машинное обучение, обработка больших объёмов данных. На то, чтобы позволить Node.js хорошо показать себя в решении подобных задач, направлено немало усилий, но тут эта платформа пока выглядит куда скромнее, чем, например, в деле разработки микросервисов.

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

При проектировании веб-приложения чрезвычайно важно выбрать подходящие средства для локального хранения данных. Речь идёт о механизме, который позволит надёжно хранить информацию, будет способствовать снижению объёма данных, передаваемых между серверной и клиентской частями приложения, и при этом не ухудшит скорость реакции приложения на воздействия пользователя. Хорошо продуманная стратегия локального кэширования данных является центральным звеном в разработке мобильных веб-приложений, которые могут работать без подключения к интернету. Современные пользователи всё чаще и чаще относятся к подобным возможностям как к чему-то привычному и ожидаемому.



Сегодня, в переводе 16 части серии материалов, посвящённых всему, что связано с JavaScript, мы поговорим о механизмах хранения данных на стороне клиента, которые могут использоваться в веб-разработке, и о выборе системы хранения данных для конкретного проекта.

Объявления для участников конкурса по программированию.

Порядок окончательного тестирования

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

Мы попробуем разобраться — как можно снизить нагрузку на серверное железо, обеспечив при этом максимальную производительность Web-приложения.

В разработке больших высоконагруженных проектов с огромным онлайном часто приходится думать, как снизить нагрузку на сервера, особенно при работе в webSocket'ами и динамически изменяемыми интерфейсами. К нам приходит 100500 пользователей и мы имеем 100500 открытых соединений по сокетам. А если каждый из них откроет по 2 вкладки — это уже *201000 соединений. А если пять?

В наши дни использование классов являются одним из самых популярных способов структурирования программных проектов. Этот подход к программированию применяется и в JavaScript. Сегодня мы публикуем перевод 15 части серии материалов, посвящённых экосистеме JS. В этой статье речь пойдёт о различных подходах к реализации классов в JavaScript, о механизмах наследования и о транспиляции. Начнём мы с рассказа о том, как работают прототипы и с анализа различных способов имитации наследования, основанного на классах, в популярных библиотеках. Далее мы поговорим о том, как, благодаря транспиляции, можно писать JS-программы, использующие возможности, которые либо отсутствуют в языке, либо, хотя и существуют в виде новых стандартов или предложений, находящихся на разных стадиях согласования, пока не реализованы в JS-движках. В частности, речь пойдёт о Babel и TypeScript и о классах ECMAScript 2015. После этого мы разберём несколько примеров, демонстрирующих особенности внутренней реализации классов в JS-движке V8.

Привет, Хабр! Мы в Хекслете запустили в этом году открытый и бесплатный проект для новичков: code-basics.ru. Это интерактивные курсы с практикой, рассчитанные на тех, кто вообще никогда не программировал. Мы учим основам программирования и рассказываем про базовое устройство компьютеров.

Сейчас доступен полный курс по PHP и первый модуль по JavaScript. На подходе Racket и Python. Весь исходный код платформы и самих уроков — в open source.

Сегодня хочу рассказать немного о сути Code Basics, его внутренностях и технологическом стеке.

Chrome Web Store принял решение запретить inline-установку расширений для Chrome. Это напрямую касается WebRTC-приложений, так как сейчас для скриншаринга в Chrome нужно расширение. Придет ли getDisplayMedia API на помощь?

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

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

Управление этой видимостью может стать полным кошмаром с увеличением количества ролей. Вероятно, вы уже писали или видели код вроде этого:

На прошлой неделе состоялся релиз Node.js версии 10.5.0, содержащий нововведение, чью значимость трудно переоценить, – поддержку многопоточности в виде модуля worker_threads. Сразу оговорюсь API находится в экспериментальной стадии и поэтому может измениться, но уже сейчас можно составить первое впечатление и получить представление о заложенных в его основу принципах и технологиях. А если у вас есть желание, то и поучаствовать в финализации интерфейса, написании кода или исправлении багов (список issues).

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

Вот первый:	Вот второй:
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10] .filter(int => isEven(int)) .filter(int => isBiggerThan(3, int)) .map(int => int + 1) .map(int => toChar(int)) .filter(char => !isVowel(char)) .join('') // 'fhjl'	[1, 2, 3, 4, 5, 6, 7, 8, 9, 10] .filter(isEven) .filter(isBiggerThan(3)) .map(plus(1)) .map(toChar) .filter(not(isVowel)) .join('') // 'fhjl'

«Готов поспорить, что второй вариант отличается гораздо лучшей читабельностью, чем первый», — говорит автор материала, перевод которого мы сегодня публикуем. По его словам — всё дело в аргументах методов filter() и map().



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

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

D3.js — это JavaScript библотека для манипулирования документами на основе входных данных. Angular — фреймворк, который может похвастаться высокой производительностью привязки данных.

Ниже я рассмотрю один хороший подход по использованию всей этой мощи. От симуляций D3 до SVG-инъекций и использования синтаксиса шаблонизатора.


Демо: положительные числа до 300 соединенные со своими делителями.

1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение

Данный пост завершает серию статей о функциональном программировании под названием "Мышление в стиле Ramda".

В последние восемь постов мы говорили о JavaScript библиотеке Ramda, которая предоставляет функции для работы с JavaScript в функциональном, декларативном и иммутабельном стиле.

В течении этой серии статей, мы узнали, что Ramda имеет несколько основных принципов, которыми движется её API:

• Данные идут последними: почти все функции принимают параметр с данными последним аргументом.
• Каррирование: почти каждая функция в Ramda "каррирована". То есть, вы можете вызвать функцию только с частью неоходимых аргументов, и получить новую функцию, которая будет ожидать оставшиеся аргументы. Как только все аргументы будут предоставлены — оригинальная функция будет вызвана.

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