Комментарии

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

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

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

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

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

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

Некоторые технологии становятся лидерами рынка и получают более широкое распространение, например, Node.js, ASP.NET и другие. Однако окончательное решение зависит от потребностей и предпочтений команды в отношении Node.js или его альтернатив.

Имхо, Node тут как спутниковый навигатор для авто: позволит создать оптимальный маршрут. Но если дороги загружены на 7+ баллов, то чуда конечно же не случится.

Почему-то вспомнилась реализация многозадачности в win 3.1 (или 95, но в меньшей мере) и та же беда с CPU ёмкими задачами, а появление модуля Worker Threads говорит том, что чуда не произошло.

Собственно, а существуют ли исследования о том, на сколько подобная экономия на «переключении задач» эффективна? Вот почему-то мне кажется, что значительное количество одновременно обслуживаемых клиентов у Node будет, если эти клиенты в основной массе простаивают (затраты на переключение задачи в многопоточной реализации сопоставимы с затратами на выполнение полезного действия), но в случае, когда все клиенты работают (затраты на переключения задачи малы по сравнению с затратами на выполнение полезного действия) эффект будет минимальный (если вообще будет).

Не работал с монгой, так что не дам комментариев по её поводу, но вот утверждение о том, что Оракл или постгрес блокируют поток — однозначно ложный. Если бы это было так, то применение этих СУБД с нодой было бы невозможным :)

Если внешняя система не поддерживает неблокирующий I/O, нода использует пул потоков, о котором в статье как раз говорится.

Спасибо, здесь действительно содержатся те факты про nodejs и worker threads, которые надо держать в уме, если хочется сконструировать на nodejs что-то более или менее нагруженное. Правда, для тех, кто интересуется платформой, эти факты, скорее всего, не будут новостью.

Тем не менее, совсем недавно мне рассказывали, что неблокирующим образом nodejs умеет обращаться только к MongoDB, а когда используются «старые» реляционные БД (Oracle, Postgres), то обращение к ним из nodejs все равно блокирует поток, потому что для них нету асинхронных неблокирующих драйверов (какие есть для монги). Может быть, кто-нибудь из экспертов откомментирует, так это или не так?

В наши дни платформа Node.js является одной из самых популярных платформ для построения эффективных и масштабируемых REST API's. Она так же подходит для построения гибридных мобильных приложений, десктопных программ и даже для IoT.

Я работаю с платформой Node.js более 6 лет и я на самом деле люблю её.

Мир до Node.js

Многопоточный сервер

Веб-приложения, написанные следуя клиент/серверной архитектуре, работают по следующей схеме — клиент запрашивает нужный ресурс у сервера и сервер отправляет ресурс в ответ. В этой схеме сервер, ответив на запрос, прерывает соединение.

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

Значит ли это, что сервер может обрабатывать только один запрос за раз? Не совсем! Когда сервер получает новый запрос он создаёт отдельный поток для его обработки.

Поток, если простыми словами, это время и ресурсы, что CPU выделяет на выполнение небольшого блока инструкций. С учётом сказанного, сервер может обрабатывать несколько запросов одновременно, но только по одному на поток. Такая модель так же называться thread-per-request model.

Для обработки N запросов серверу нужно N потоков. Если сервер получает N+1 запросов, тогда он должен ждать пока один из потоков не станет доступным.

На рисунке выше, сервер может обрабатывать до 4 запросов (потоков) единовременно и когда он получает следующие 3 запроса, эти запросы должны ждать пока любой из этих 4 потоков не станет доступным.

Один из способов избавиться от ограничений — добавить больше ресурсов (памяти, ядер процессора и т. д.) на сервер, но это не самое лучшее решение….

И, конечно, не забываем о технологических ограничениях.

Блокирующий ввод/вывод

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

Допустим, Вы разрабатываете онлайн магазин и Вам нужна страница где пользователь может просматривать список всех товаров.

Пользователь стучится на yourstore.com/products и сервер рендерит HTML файл со всеми продуктами с базы данных в ответ. Совсем не сложно, да?

Но, что же происходит за кулисами?

— Когда пользователь стучится на /products особый метод или функция должна выполниться, что бы обработать запрос. Маленький кусочек кода (Ваш или фреймворка) анализирует URL-адрес запроса и ищет подходящий метод или функцию. Поток работает.
— Теперь нужный метод или функция выполняться, так как и в первом пункте — поток работает.
— Так как Вы хороший разработчик, Вы сохраняете все системные логи в файл, ну и конечно же, что бы быть уверенными, что роутер выполняет нужный метод/функцию — Вы так же логируете строку «Method X executing!!». Но всё это блокирующие операции ввода/вывода. Поток ждёт.
— Все логи сохранены и следующие строки функции выполняются. Поток работает снова.
— Время обращаться к базе данных и получать все продукты – простой запрос, вроде SELECT * FROM products, выполняет свою работу, но угадайте что? Да-да, это блокирующая операция ввода/вывода. Поток ждёт.
— Вы получили массив или список всех продуктов, но убедитесь, что Вы всё это залогировали. Поток ждёт.
— Теперь у Вас есть все продукты и пришло время рендерить шаблон для будущей страницы, но перед этим Вам нужно их прочитать. Поток ждёт.
— Движок рендеринга делает свою работу и шлёт ответ клиенту. Поток работает снова.
— Поток свободен, словно птица в небесах.
Операции сети и чтения с диска слишком медленные. Представьте сколько запросов или обращений к внешним API ваша система могла бы обработать за это время.

Подбивая итоги: операции ввода/вывода заставляют поток ждать и тратить ресурсы впустую.

Node.js мощная технология, которую стоит изучить при возможности.
Моя личная рекомендация – всегда будьте любопытными! Если Вы знаете, как что-то работает изнутри, Вы сможете работать с этим более эффективно.

Два комментария с Reddit по теме:
Консультант по SEO/a11y на проводе. Не могу передать, сколько раз я сталкивался с SEO-специалистами и/или клиентами, которые клялись, что вам нужен SSR, чтобы поисковые роботы правильно индексировали ваш SPA. Это не так уже почти десять лет. Есть множество гигантских Ecommerce брендов, которые используют SPA уже много лет и имеют чрезвычайно высокие показатели SEO (на ум приходит Walmart). Анекдотично, я лично руководил конверсией сайта .NET MVC Ecommerce со 100 000+ SKU на Vue 2 SPA, и мы действительно увидели улучшение наших SEO-метрических показателей. Это было 8 лет назад.

Мы обычно исходим из следующих соображений:

— Является ли HTML семантическим и доступным (a11y)?

— Предоставляется ли схема через JSON+LD и/или теги?

— Соответствуют ли основные показатели сайта (core web vitals) требованиям?

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

Все это Google укажет в Search Console / Lighthouse, чтобы сообщить вам о наличии проблемы.

I keep reading advice about how necessary it is to use SSR for SEO, but that advice does not match my personal experience. That advice was probably valid years ago, before search engines became good at running Javascript.

From what I have seen personally, Bing is pretty good at running Javascript too.

Не понимаю, в чём сложность. Нужен сайт на JavaScript есть SSR. Он хорошо дружит с SEO (сужу по опыту компаний и по своему тоже), всё индексируется и продвигается. Не хочется постоянно запекать страницы, ну используйте ISR

Ах да, Angular Universal с ним не дружит, с ISR. Ну тогда вам придётся выбирать между Next.js или Nuxt.js (Ещё конечно можно использовать VuePress или VitePress, на них можно не только документации делать, ну и вполне себе хорошие сайты с динамическими компонентами и всё это хорошо для SEO — проверял)

Кстати, это не сарказм, это опыт, я попробовал, и у меня есть результаты. Да и не только у меня, у всех кто это пробовал тоже есть положительные результаты. Для профи там ничего сложного это всё настроить.

Если title статичный, значит там что-то с промисами начудили, или забыли убрать статические данные.

SEO оптимизация — это что-то среднее между backend и frontend, поэтому фронтенд разработчику сложно настроить семантическое ядро и учесть другие фишки и инструменты SEO. Знание OpenGraph и Schema.org — это далеко не всё. Я уже молчу про генерацию robots.txt и sitemap.xml (Столько тонкостей надо знать, это кстати легче поймёт бэкендер)

Про бэкенд я услышал только про PHP/ — так, уровень знаний мне понятен, стало очевидно, почему SSR для автора проблема. Если знать как работает контекст в динамических страницах SSR, то проблемы автоматически улетучиваются, и в настройках можно явно указать что показать, если такой страницы не будет, можно показать ошибку 404 или не отображать страницу вовсе, или будет ошибка при компиляции. Жаль что не упомянули про Rust, Java, С#, Python — на них же тоже можно сделать backend

Мне на самом деле сложно судить без Code Review
(чтобы понять почему автор не возлюбил SSR)

По теме. Буквально месяц назад стоял выбор — какую архитектуру использовать для SEO. Остановился на SSG… Как будто штаны через голову натягиваешь)) А уж SSR городить… Чур меня!

А вообще забавные кульбиты прогресс вытворяет — вот вам технология, которая может полноценно отображать весь контент без перезагрузки страницы… а, стоп! вам нужна статика для поисковых ботов? Тогда держите новую технологию, которая позволяет одностраничное приложение распарсить в виде многостраничной статики. Что, опять не так? Теперь нужна технология, которая SSR будет обратно в SPA собирать?..

И после каждой такой неоднозначной технологии начинаются холивары под лозунгом «даёшь всё новое!». Что, вы собрались манипулировать DOM во Vue-приложении? Это совершенно не так работает — уясните для себя что такое «декларативная отрисовка». Вы совершенно не понимаете методологии реактивных фреймворков!

Выходит Vue3 — Держите то, о чём вы так долго просили — ref-ссылки для манипуляции DOM…

Еще одним фактором использования генерации на сервере являются свои open graph мета-теги для каждой страницы для построения сниппетов Фейсбуком, Телеграмом и другими соцсетями. К сожалению, они JavaScript не понимают от слова «совсем», поэтому при необходимости использовать прикладную логику на сервере фронтенда придется.

Однако, сгенерировать и вставить несколько строчек в head секцию html страницы намного проще, и вполне реализуется одним скриптом на Python, PHP, вместо поднимания сервера на Node.js.

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

Оба поисковика утверждают, что что-то уже могут по индексированию SPA приложений.

Результат: Google — хорошо, Yandex — не очень.

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

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

— SSG

— Prerendering

— SSR (с Node.js и гидратацией — Nuxt, Next.js и др.)

— Отдельная облегченная версия сайта для поисковиков с генерацией контента на сервере и SPA для людей

— Обычная серверная генерация (PHP и пр.)

Основная причина делать сайты как гибридные SSR — требование иметь SEO. Разрабатывать SPA приложения намного легче, комфортней (DX), они поддерживаемей и расширяемей, их разработка дешевле и быстрей. Поэтому SEO оптимизация — давняя боль фронтенд разработки.

С целью проверки текущего положения дел у поисковиков в плане понимания JavaScript-a при индексации страниц было проведено два эксперимента. Первый со страницей на голом JavaScript и запросами на fetch(), и второй — простое Vue приложение.

Несмотря на достаточно оптимистичные результаты, нужно отметить, что например мой рабочий (уже не такой элементарный) Vue 3 проект на Google не индексируется, то есть, успешность всего этого зависит, естественно, от логики приложения, а также, вероятно, от используемых библиотек.

Требуется проверка работы других фронтенд фреймворков и каждого приложения индивидуально, но поддержка индексирования SPA у Google уже на очень приличном уровне. У Yandex — нет.

В англоязычном сегменте интернета при опоре на Google использование SSR становится не обязательным.

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

От межсайтового скриптинга (XSS) до инъекций и атак типа «отказ в обслуживании» (DoS) — существует множество распространенных JavaScript уязвимости, о которых разработчики должны знать и защищать. Итак, пристегните ремни и приготовьтесь изучить все тонкости безопасности JavaScript!

Атаки с использованием межсайтового скриптинга (XSS)

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

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

— Проверка вводимых данных. Чтобы повысить безопасность вашего веб-сайта, крайне важно проверять и дезинфицировать вводимые пользователем данные, отфильтровывая потенциально опасные символы, которые могут быть использованы для внедрения кода.

— Кодировка вывода. Защитите свой веб-сайт от выполнения вредоносного кода, кодируя все отображаемые пользовательские данные, такие как кодировка HTML, URL и JavaScript.

— Политика безопасности контента (CSP). Создайте политику безопасности контента (CSP) для определения утвержденных источников сценариев и ресурсов, тем самым блокируя несанкционированное выполнение сценариев, в том числе внедренных злоумышленниками.

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

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

Атаки с подделкой межсайтовых запросов (CSRF)

CSRF-атаки могут принимать разные формы, но цель всегда одна: заставить пользователя выполнить нежелательное действие.

К распространенным типам CSRF-атак относятся:

— CSRF на основе формы. Злоумышленник отправляет форму от имени пользователя без его ведома и согласия.

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

— CSRF на основе JSON: злоумышленник использует данные JSON для выполнения нежелательного действия.

Как работают CSRF-атаки:

CSRF-атака: Совершение незаконных действий от имени пользователя путем использования уязвимого веб-сайта.

Вот как это работает:

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

Злоумышленник получает доступ к данным пользователя или выполняет вредоносное действие.

Методы предотвращения CSRF-атак:

Существует несколько методов, которые можно использовать для защиты веб-сайта от CSRF-атак, в том числе:

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

— Файлы cookie SameSite: файлы cookie SameSite снижают риск атак с подделкой межсайтовых запросов (CSRF), блокируя файлы cookie для межсайтовых запросов.

— Проверка заголовков Referer. Подтвердите подлинность заголовка Referer, чтобы гарантировать, что запросы поступают с вашего веб-сайта, а не от хакера.

Внедрение

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

Распространенные типы инъекций

Существует несколько типов инъекционных атак, каждая со своим методом атаки и потенциальными последствиями:

* Внедрение SQL: вредоносный код SQL, внедренный в поля ввода, может привести к взлому базы данных, утечке данных или порче веб-сайта злоумышленниками. Внедрение SQL (SQLi) На долю сейчас приходится 65,1 % всех атак на веб-приложения, что значительно больше, чем всего два года назад, когда она составляла 44 %.

* Внедрение LDAP: использование злоумышленниками параметра запроса LDAP (Lightweight Directory Access Protocol) приводит к несанкционированному доступу к конфиденциальным данным.

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

* Межсайтовый скриптинг (XSS): вредоносные скрипты, внедренные злоумышленниками во входные данные веб-сайта, могут привести к выполнению кода на стороне клиента, краже данных или порче веб-сайта.

Как защитить свой веб-сайт

Защита вашего веб-сайта от инъекций требует многоуровневого подхода, включающего следующие меры:

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

— Параметризированные запросы: предотвратите атаки путем внедрения кода SQL, отдав предпочтение параметризованным запросам вместо встроенных запросов.

— Аутентификация и авторизация пользователя: надежный пользователь аутентификация и авторизация необходимы для предотвращения незаконного доступа к конфиденциальным данным.

— Практики безопасного кодирования. Соблюдайте нормы безопасного кодирования: санация входных данных и кодирование выходных данных для предотвращения атак путем внедрения.

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

Атаки типа «отказ в обслуживании» (DoS)

DDoS: DoS-атака с использованием нескольких устройств с использованием распределенных местоположений для повышенной скрытности и устойчивости. В 2022 году активность DDoS резко возросла, а ее продолжительность резко увеличилась. По сравнению со вторым кварталом 2021 года, когда DDoS-атаки длились в среднем 30 минут, за тот же период 2022 года атаки продолжались в среднем 50 часов.

Итак, как вы можете защитить себя от DoS-атак? Вот несколько советов:

— Используйте сеть доставки контента (CDN). Использование CDN облегчает распределение трафика между различными серверами, усиливая защиту от объемных атак, которые в противном случае могли бы вывести из строя один сервер.

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

— Используйте брандмауэр веб-приложений (WAF). WAF может помочь обнаружить и заблокировать подозрительный трафик до того, как он достигнет вашего веб-сайта, помогая предотвратить DoS-атаку.

— Отслеживайте трафик своего веб-сайта. Следите за моделями трафика вашего веб-сайта и следите за внезапными всплесками, которые могут быть признаком атаки.

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

Рекомендации по безопасности JavaScript

Что касается передовых методов обеспечения безопасности JavaScript, необходимо сосредоточиться на нескольких ключевых областях.

Вот несколько общих советов:
Используйте политику безопасности контента (CSP)

Защитите свои веб-страницы от вредоносных скриптов и предотвратите атаки XSS с помощью политики безопасности контента (CSP), которая предписывает авторизованные источники контента для загрузки и выполнения.

Проверка ввода пользователя

Защищенный пользовательский ввод в JavaScript имеет решающее значение. Проверяйте все вводимые пользователем данные для предотвращения инъекций. Используйте такие методы, как регулярные выражения, чтобы обеспечить безопасность пользовательского ввода.

Обновляйте свои библиотеки и платформы

Опережайте злоумышленников, регулярно обновляя библиотеки и платформы JavaScript, чтобы устранить новые уязвимости в системе безопасности.

Используйте HTTPS везде

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

Используйте правильную аутентификацию и авторизацию

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

Защитите свой серверный код

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

Внедрение надежной системы тестирования и мониторинга

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

Вот несколько советов по использованию библиотеки JavaScript Filestack

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

* Используйте функции безопасности Filestack: Filestack предоставляет надежные инструменты безопасности для защиты ваших приложения, включая подписанные URL-адреса, ограничивающие доступ к файлам только авторизованным пользователям, и политики безопасности, обеспечивающие детальный контроль над действиями пользователей над вашими файлами.

* Проверка ввода пользователя: всегда проверяйте ввод пользователя перед его обработкой в ​​коде JavaScript. Это может помочь предотвратить атаки путем внедрения и другие уязвимости.

Когда дело доходит до написания JavaScript, разработчики совершают несколько распространенных ошибок. Здесь мы рассмотрим некоторые из самых распространенных и способы, как можно их избежать.

Ошибка: Неправильное использование ключевого слова this

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

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

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

Еще одна известная ошибка разработчиков — не использование строгого режима. Строгий режим — это способ перейти на ограниченный вариант JavaScript. В строгом режиме определенный синтаксис запрещен, а некоторые поведения изменены. Например, в строгом режиме вы не можете использовать необъявленные переменные.

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

"use strict";

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

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

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

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

Ошибка: Использование == вместо ===

В JavaScript есть два способа проверить, равны ли два значения: == и ===. Оператор == проверяет равенство значений, в то время как оператор === проверяет равенство значений и типов.

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

Ошибка: Забывают привязать this

Когда вы работаете с объектно-ориентированными функциями JavaScript, вам часто нужно ссылаться на текущий объект внутри метода. Для этого вы используете ключевое слово: this.

Однако значение this может быть изменено в зависимости от того, как вызывается метод. Например, если вы вызываете метод для объекта, this будет ссылаться на этот объект. Но если вы вызовете тот же метод, используя другой объект, this вместо этого будет ссылаться на этот объект.

Это может быть проблемой, потому что могут возникнут трудности с отслеживанием к чему this относится. Чтобы избежать этого, обязательно привяжите значение this к текущему объекту. Вы можете сделать это с помощью метода bind.

var obj = {
  foo: function() {
    console.log(this);
  }
};
 
var bar = obj.foo.bind(obj);
 
bar(); // prints the obj object

В приведенном выше коде мы создаем объект с помощью методов foo. Затем мы создаем переменную с именем bar и присваиваем ей значение результата вызова bind в foo. Это устанавливает значение this внутри foo для объекта obj. Когда мы вызываем bar, он выводит obj на консоль.
Ошибка: Изменение строки вместо создания новой

В JavaScript строки неизменяемы. Это означает, что как только строка создана, она не может быть изменена.

Однако есть несколько методов, которые можно использовать для изменения строк. Например, метод replace можно использовать для замены части строки другой строкой.

var str = "Hello world!";
 
str.replace(" world", " JavaScript"); // returns "Hello JavaScript!"

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

Чтобы избежать этой ошибки, обязательно создавайте новую строку при изменении существующей строки. Это можно сделать с помощью метода slice.

var str = "Hello world!";
 
var newStr = str.slice(0, 5) + " JavaScript!"; // returns "Hello Ja

В приведенном выше кода использован метод slice для создания новой строки, содержащей первые пять символов исходной строки. Затем объединяем это со строкой «JavaScript!». Это создает новую строку, которую мы можем присвоить переменной newStr.
Ошибка: Создание утечки памяти

Утечка памяти — это проблема, которая может возникнуть при программировании на JavaScript. Это происходит, когда вы удерживаете ссылку на объект, который больше не нужен.

Например, рассмотрим следующий код:

var arr = [1, 2, 3, 4, 5];
 
var foo = function() {
  arr.push(6);
};
 
setInterval(foo, 1000);

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

Этот код вызовет утечку памяти, потому сто массив arr никогда не будет удален сборщиком мусора. Это происходит, потому что функция foo имеет ссылку на массив arr, и функция foo вызывается каждую секунду.

Чтобы избежать этой ошибки, обязательно удалите ссылки на объекты, которые больше не нужны. В приведенном выше примере можно сделать это с помощью метода clearInterval.

var arr = [1, 2, 3, 4, 5];
 
var foo = function() {
  arr.push(6);
};
 
var interval = setInterval(foo, 1000);
 
clearInterval(interval);

В данном примере сохраняется возвращаемое значение setInterval в переменной. Это возвращаемое значение является ссылкой на созданный интервал. Затем можно использовать метод clearInterval, чтобы очистить интервал и удалить ссылку на массиве arr.
Ошибка: Не использовать IIFE

IIFE (Выражение функции с немедленным вызовом) — это функция, которая выполняется немедленно. IIFE обычно используются в JavaScript для создания локальной области видимости.

Для примера рассмотрим следующий код:

var foo = "foo";
 
(function() {
  var foo = "bar";
})();
 
console.log(foo); // prints "foo"

В данном примере кода есть глобальная переменная foo, которая имеет значение «foo». Затем мы создаем IIFE, который имеет локальную переменную с тем же именем. Эта локальная переменная доступна только внутри IIFE.

Когда мы записываем значение foo в консоль, она выводит «foo». Это происходит потому, что IIFE создает новую область, которая отделена от глобальной области.

Чтобы избежать этой ошибки, обязательно используйте параметр IIFE для создания новой области.

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

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

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

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

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

Ну и вот какие языки программирования используются в бэкенде. Естественно стоит понимать что в бэкенде много языков программирования. Вот какие входят в топ-8:

1. Java ― кроссплатформенный язык программирования с поддержкой объектно-ориентированного программирования (ООП). Суть в том, что вся работа в нём происходит через объекты — ими могут быть, например, клиент банка и его счёт в мобильном приложении. Эти объекты описываются в виде кода и учатся взаимодействовать друг с другом. Java применяют в веб- и мобильной разработке, он подходит для создания надёжных и безопасных приложений и систем.

2. Python подходит для начинающих бэкенд-разработчиков благодаря простому синтаксису. Он работает с разными платформами и программными системами. Применяется во многих сферах — от машинного обучения до создания игр. Python лаконичен — на нём можно писать меньше кода для выполнения задач.

3. PHP — скриптовый язык программирования с открытым исходным кодом. Скрипт — набор команд, которые необходимы для выполнения задачи. PHP чаще используют для создания веб-приложений. Хорошо работает с базами данных и поддерживается на самых популярных операционных системах (Windows, Linux, macOS).

4. Golang (Go) — ещё один простой, как Python, язык программирования для бэкенда. На Go можно быстро запускать независимые друг от друга функции и не опасаться, что не хватит памяти. Язык хорошо подходит для создания отдельных частей системы, которые выполняют конкретную функцию и вместе складываются в полноценное приложение или сайт. Например, в маркетплейсе с помощью Go можно создать отдельно корзину или карточку товара.

5. C# («си-шарп») — объектно-ориентированный язык, разработанный компанией Microsoft для платформы .NET. Он менее гибкий, так как зависит от этой платформы. Но у языка много библиотек и готовых решений. На C# пишут программы для экосистемы Microsoft и веб-приложения.

6. C++ — объектно-ориентированный язык, на котором пишут сложные сервисы, требующие скорости и производительности. Учить его тяжелее, чем Python и Go, но зато на C++ можно создавать разные продукты: от беспилотных автомобилей до веб-приложений и компьютерных игр.

7. JavaScript — популярный язык, на котором работают и фронтенд-, и бэкенд-разработчики. JavaScript подходит и для пользовательской части продукта, и для серверной. Чаще с его помощью создают динамический контент на странице: например, всплывающие уведомления. Используют заранее написанные шаблоны — фреймворки.

8. Kotlin. Создан на основе Java и полностью совместим с ним. Kotlin можно применять везде, где работает Java: бэкенд, веб, десктоп. Но главная сфера применения языка — разработка приложений для устройств (смартфонов, телевизоров, умных часов) на Android. Большинство таких приложений написаны на Kotlin, в том числе приложения Google.

А не подскажите какие языки программирования используются в бэкенде? Так же как понимаю — чем выше уровень разработчика, тем большую важность приобретают его софт-скилы или «гибкие» навыки — личные качества, которые помогают в работе.