Области видимости в JavaScript всегда были непростой темой, особенно в сравнении с более строго организованными языками, такими, как C и Java. В течение многих лет области видимости в JS особенно широко не обсуждались, так как в языке попросту не было средств, которые позволяли бы существенно повлиять на сложившуюся ситуацию. Но в ECMAScript 6 появились некоторые новые возможности, которые позволяют разработчикам лучше контролировать области видимости переменных. Эти возможности в наши дни уже очень хорошо поддерживают браузеры, они вполне доступны для большинства разработчиков. Однако новые ключевые слова для объявления переменных, учитывая ещё и то, что старое ключевое слово var никуда не делось, означают не только новые возможности, но и появление новых вопросов. Когда использовать ключевые слова let и const? Как они себя ведут? В каких ситуациях всё ещё актуально ключевое слово var? Материал, перевод которого мы сегодня публикуем, направлен на исследование проблемы областей видимости переменных в JavaScript.

«Я думаю, что компиляторы — это очень интересно», — говорит Ури Шейкед, автор материала, перевод которого мы сегодня публикуем. В прошлом году он написал статью, в которой шла речь о реверс-инжиниринге компилятора Angular и об имитации некоторых этапов процесса компиляции, помогающей понять особенности внутреннего устройства этого механизма. Надо отметить, что обычно то, о чём автор этого материала говорит как о «компиляторе», называют «движком рендеринга».

Когда Ури услышал о том, что вышла новая версия компилятора Angular, названная Ivy, он тут же захотел рассмотреть её поближе и узнать, что в ней изменилось по сравнению со старой версией. Тут, так же, как и раньше, на вход компилятора поступают шаблоны и компоненты, созданные средствами Angular, которые преобразуются в обычный код на HTML и JavaScript, понятный Chrome и другим браузерам.



Если сравнить новую версию компилятора с предыдущей, то окажется, что Ivy использует алгоритм tree-shaking. Это означает, что компилятор автоматически удаляет неиспользуемые фрагменты кода (это относится и к коду Angular), уменьшая размер бандлов проектов. Ещё одно улучшение касается того, что теперь каждый файл компилируется самостоятельно, что уменьшает время повторной компиляции. Если в двух словах, то, благодаря новому компилятору мы получаем сборки меньших размеров, ускоренную повторную компиляцию проектов более простой готовый код.

Понимание того, как работает компилятор, интересно и само по себе (по крайней мере, автор материала на это надеется), но это, кроме того, помогает лучше понять внутренние механизмы Angular. Это ведёт к совершенствованию навыков «Angular-мышления», что, в свою очередь, позволяет более эффективно использовать этот фреймворк для веб-разработки.

Кстати, знаете, почему новый компилятор назвали Ivy? Дело в том, что это слово звучит как сочетание букв «IV», прочитанное вслух, которое представляет число 4, записанное римскими цифрами. «4» — это четвёртое поколение компиляторов Angular.

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



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

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

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

Фреймворк Bootstrap — это свободный набор инструментов для создания интерфейсов сайтов и веб-приложений. Его возможности ориентированы исключительно на фронтенд-разработку. Bootstrap — проект весьма популярный, о чём, например, говорит то, что он занимает (по состоянию на начало марта 2018-го года) второе место по количеству звёзд на GitHub.

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

Автор материала, перевод которого мы публикуем сегодня, Билл Соро, говорит, что написал первые строки кода на JavaScript вскоре после появления этого языка. По его словам, если тогда ему сказали бы, что однажды он выпустит серию статей об элегантных шаблонах проектирования в JavaScript, он умер бы со смеху. Тогда он воспринимал JS как странный маленький язык, писанину на котором можно было с большой натяжкой называть «программированием».

Но за 20 лет многое изменилось. Теперь Билл воспринимает JavaScript таким, каким видел его Дуглас Крокфорд, когда работал над книгой «JavaScript. Сильные стороны»: красивым, элегантным и выразительным динамическим языком программирования.



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

Иммутабельные структуры данных, реализующие методику совместного использования неизменяемых фрагментов информации (structural sharing), выглядят как отличная технология для хранения состояния приложения. Особенно — в комбинации с архитектурой, основанной на событиях. Однако за всё надо платить. В языке вроде JavaScript, где возможности по обеспечению иммутабельности не являются стандартными, создание нового состояния из предыдущего — это скучная, шаблонная задача. Для того чтобы осознать масштаб проблемы, и силы, брошенные на её решение, взгляните на эту страницу, где имеется список из 67 пакетов, предназначенных для упрощения работы с иммутабельными структурами данных в Redux.



К сожалению, все эти библиотеки не решают основную проблему: отсутствие поддержки иммутабельности языком. Например, в то время как update-in — это красивая конструкция языка ClojureScript, любые аналогичные идеи, реализованные на JavaScript, будут, в основном, полагаться на неудобные строковые пути. Такой подход подвержен ошибкам, он усложняет проверку типов и требует изучения особого API.

Как решить проблему иммутабельности в JavaScript? Пожалуй, стоит прекратить сражаться с языком, воспользовавшись вместо этого его возможностями. Такой подход позволит не терять удобство и простоту, которые дают стандартные структуры данных. Собственно говоря, библиотека immer, о которой мы сегодня поговорим, направлена то, чтобы использовать стандартные средства JS при работе с иммутабельными состояниями.

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


Мощная картинка для привлечения внимания :) Осторожно, может засосать!

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

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

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


Картинка по запросу «области видимости». Извините, если вызвали приступ ностальгии )

Элементарное определение области видимости выглядит так: это область, где компилятор ищет переменные и функции, когда они ему нужны. Думаете, что звучит это слишком просто? Предлагаем разобраться вместе.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

В прошлый раз, в третьей части этой серии материалов по bash-скриптам, мы говорили о параметрах командной строки и ключах. Наша сегодняшняя тема — ввод, вывод, и всё, что с этим связано.

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

Когда анимация способна улучшить впечатления пользователя от работы со страницами? Что именно стоит «оживить» для того, чтобы взаимодействие с ресурсом стало бы более удобным, понятным, увлекательным?

Хочу рассказать о некоторых выводах, которые я сделал после работы над одним из самых посещаемых веб-сайтов в мире.



Мне довелось поучаствовать в работе над этим проектом в качестве консультанта. Посещаемость ресурса составляет порядка 200 миллионов уникальных пользователей в месяц. Такая популярность означает и высокий уровень рисков в сфере информационной безопасности, в частности, это риск подвергнуться различным видам атак, самые распространённые среди которых – DDoS. Организация, которую называть не буду, внедрила широкий спектр решений для предотвращения воздействия подобных атак на работоспособность сервиса.

«Болезни цивилизации»: проекция на 2030 и 2050

Ковид-19 — социальная болезнь. Речь не только об экономических и культурных последствиях пандемии. В историческом контексте ковид — очередное проявление в развивающейся уже 40 лет эпидемии, последнее пополнение в ряду диабета 2 типа, Альцгеймера, сердечно-сосудистых и раковых заболеваний. Эти болезни — побочный эффект развития пищевой промышленности. В начале индустриальной эры голод оставался реальной угрозой мирного времени (Великий голод в Ирландии в 1840-е, Голодомор в СССР в 1930-е), однако возникновение пищевой промышленности смогло обеспечить дешёвое и массовое производство продуктов питания.

На поверхности, Covid-19 с другими «болезнями цивилизации» объединяет сильная корреляция с избыточным весом. Например, лишний вес и ожирение связаны с 13 видами рака — 40% всех онкологических диагнозов в США (2017). Ожирение, диабет, раковые и сердечно-сосудистые заболевания, а теперь и ковид — букет последствий, растущих в большинстве случаев из одного корня: нарушений метаболизма.

У людей без метаболических нарушений более вероятно бессимптомное протекание заражения или слабая форма ковида, в которой он мало отличим от обычной простуды (тоже вызываемой коронавирусом, только другого типа). Таким образом, коронавирус SARS-CoV-2 и ковид-19 в слабой форме можно интерепретировать как простуду, вызывающую осложнения в организме с метаболическими нарушениями — собственно, ковид в средней или тяжёлой форме. Это перемещает ковид-19 из ряда обычных респираторных инфекций в ряд других так называемых «болезней цивилизации» — болезней, число которых в обществе растёт вместе с ростом потребления обработанных продуктов питания, выпускаемых современной пищевой промышленностью.

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

Если вы не разбираетесь в С++, не переживайте, эта статья имеет нулевой порог вхождения. Мы начнём с лёгкого, но вы даже не заметите, как начнёте разбираться в более сложных и непонятных, на первый взгляд, вещах. Главное, писать код логично. Думаю, данная статья будет интересна не только начинающим, ведь я постарался затронуть достаточно много тем. (для старожилов: моя цель не сделать оптимизирование или быстрее, а показать, что С++ не такой уж и сложный язык программирования. И да, я знаю, что существуют другие библиотеки, которые делают это быстрее и лучше. И да, было бы круче, если бы мы использовали булевую алгебру. И да, С++ про вечную оптимизацию, но это статья не про это. Спасибо.)

За сегодня мы узнаем, что такое: Перегрузка функций/конструкторов, прототипы функций, обработка исключений, пространство имён, псевдонимы типов, заголовок.h, как пользоваться отладчиком и как писать продвинутые/красивые комментарии. Пристёгивайтесь, будет безумно интересно.

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

Самодельный дымоуловитель для пайки

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

Хороший дымоуловитель можно и купить, но стоить он будет более $70. Я, узнав об этом, сделал такое устройство сам, использовав 120-миллиметровый компьютерный вентилятор и корпус, напечатанный на 3D-принтере.

На прошлой неделе в наших соцсетях выступил Иван Писцов, руководитель направления международного развития, в компании Gecko Robotics.

До переезда в США, Иван запустил в России компанию по международной логистике, экспериментировал в области автоматики в энергетике. В 2015 решив переехать в США, поступил на программу МБА в Carnegie Mellon University. Во время учебы, руководил бизнес развитием в университетском стартапе www.teratonix.com (RF-energy harvesting) – призовые места в университетских венчурных конкурсах (включая, Caltech), $1M грант Shell Game Changer 2017.

После неудавшейся попытки запустить собственный стартап в Силиконовой Долине, вернулся в Питтсбург — c 2019 руководит международным развитием в Gecko Robotics.

Делимся с вами расшифровкой эфира и записью.

Управление зависимостями — это часть повседневной работы Node.js-программиста. Сегодня мы поговорим о разных подходах к работе с зависимостями в Node.js, и о том, как система загружает и обрабатывает зависимости.

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



Прежде чем мы перейдём к разговору об управлении зависимостями, поговорим о модулях. Что это такое? Зачем разработчику задумываться о неких «фрагментах кода», вместо того, чтобы просто писать весь код в одном файле?

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

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



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

Здесь мне хотелось бы рассмотреть технологические тренды 2021 года, на которые стоит обратить внимание программистам. Всё то, о чём я буду говорить, основано на фактах, цифрах и данных из надёжных источников.

Современные браузеры могут намного больше, чем рендеринг веб-страниц. Это стало одной из причин появления WebAssembly. Эта технология создана в попытке вывести скорость решения сложных задач на новый уровень, построить мост между JavaScript и машинным кодом.

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



У WASM был огромный потенциал и невероятные перспективы. Что же пошло не так? Почему WASM, через 3 года после релиза, ещё не используется в каждом веб-проекте? Есть ли у WASM будущее в веб-разработке? Поищем ответы на эти вопросы.