В этой статье мы познакомимся с бинарным поиском с примером на JavaScript, а так же сравним бинарный поиск и линейным.

Недавно мне задали вопрос «почему пересечение в TS работает не как в теории множеств, а совсем наоборот?»

Озадачился, задумался и стал разбираться, как согласуются, и согласуются ли вообще операции «объединение» и «пересечение» в TypeScript и в теории множеств? И действительно ли пересечение в TS работает прямо противоположно?

Фронтенд-разработка — это как собирать лего без инструкции: иногда весело и творчески, но порой ты забираешься на кровать и кричишь: «*@#%*, да где же этот пропавший блок?!»

Каждый новый проект во фронтенде — это как уникальный набор лего, и ты никогда не знаешь, какие интересные вызовы подкинет он на этот раз. 

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

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

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

Начинающие разработчики часто встречают на ревью пулл-реквестов очень дотошных ревьюеров, дающих кучу комментариев по теме чистоте кода. Меня зовут Мария Кондаурова, я фронтенд-разработчик в департаменте вычислительной биологии в BIOCAD. И у меня есть свои мысли на тему чистого кода и рефакторинга.

Со временем у разработчика опытным путем или с чтением хорошей технической литературы нарабатывается чувство чистого кода, но что делать новичкам? В этой статье я не буду долго мучать теорией про чистый код и паттерны —  про это уже было в Симпсонах в учебниках, конференциях и на Хабре в том числе. Но приведу примеры плохого (на мой взгляд) кода в приложениях на React и JavaScript — и также покажу, как его улучшить.

Надеюсь, что начинающим моя статья будет полезна — и после прочтения они смогут применить всё на практике.

Привет! Меня зовут Фёдор, я фронтенд-тимлид в KTS и преподаватель школы Metaclass.

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

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

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

Привет, Хабр! Я Илья Белявский — старший Frontend-разработчик в Cloud.ru. Сегодня расскажу, как можно перенести ответственность с разработчика на компилятор TypeScript, повысить надежность приложения, упростить поддержку кодовой базы и ускорить разработку проекта с помощью простого хелпера — notReachable. Если интересно, заглядывайте под кат!

CSS не отстаёт от JavaScript. Постоянно развивается. Классно же. Мне особенно радостно видеть, как старые задачи, которые я решал при помощи костылей, теперь можно сделать при помощи одного свойства.

Только многие фишки неизвестны широкому кругу разработчиков. Честно говоря, некоторые я сам узнал недавно. В любом случае так дальше нельзя. Надо исправлять ситуацию!

Я собрал фишки, которые могут быть полезны в разного рода проектах. Неважно, верстаете ли вы сайт для малого бизнеса или создаёте супермодное React приложение. Они поддерживаются большинством браузеров, начиная с 2021 года. Отдельно отмечу, что я не считаю IE11 браузером, который поддерживается в современной разработке. По этой причине я не учитывал его.

Больше не буду затягивать. Давайте посмотрим, что я вам подготовил.

Привет, друзья!

В данном туториале я покажу вам, как тестировать компоненты на React с помощью Jest и Testing Library.

Список основных задач, которые мы решим на протяжении туториала:

1. Создание шаблона React-приложения с помощью Vite.
2. Создание компонента для получения приветствия от сервера.
3. Установка и настройка Jest.
4. Установка и настройка Testing Library.
5. Тестирование компонента с помощью Testing Library:
   
   1. Используя стандартные возможности.
   2. С помощью кастомного рендера.
   3. С помощью кастомных запросов.
6. Тестирование компонента с помощью снимков Jest.

Репозиторий с кодом проекта.

Если вам это интересно, прошу под кат.

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

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

Что такое Scrum?

Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.

Agile не является: Библией разработки ПО, догматическим набором строгих правил, тикетами Jira или коучами Agile, суетящимися в вашей компании.

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

Я frontend-разработчик SimbirSoft Эллина, и в этой статье расскажу, как создать внутренний пакет компонентов в React с помощью инструмента сборки Rollup, а также как сделать его более качественным и удобным для использования. Материал будет полезен frontend-разработчикам уровней junior+ и middle.

Данная статья посвящена реализации не блокирующего рендеринга - Concurrent React. Мы рассмотрим то, как работают под капотом Concurrent Features добавленные в 18 версии React. На основе теоретических знаний разберем результат профилирования тренировочного приложения и наглядно увидим, как Concurrent Features разбивают рендеринг приложения.

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

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

React 18 представил конкурентные (concurrent) возможности, которые радикально меняют способ рендеринга приложений. В этой статье мы рассмотрим, как эти возможности улучшают производительность приложения.

Начнем с повторения основ "долгих (долго выполняющихся) задач" (long tasks) и соответствующих метрик производительности.

На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.

В то же время, если мы хотим использовать отказоустойчивые решениями вроде Sentinel и Cluster, нам понадобится поддержка этих технологий на уровне библиотеки, которую приложение использует для подключения в Redis. Причем лишь немногие библиотеки умеют читать из реплик Redis — в обоих вариантах (Sentinel и Cluster) чтение, как правило, происходит с мастеров. И запись, естественно, тоже происходит в мастеры. 

В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.

Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется. 

Звучит как фантастика?

Любое приложение, которое можно написать на JavaScript, будет в итоге написано на JavaScript.

В статье рассказываем, как оптимизировать базу данных PostgreSQL на примере Linux на IBM Z. Опираясь на представленные примеры, вы шаг за шагом узнаете, какие опции и параметры конфигурации улучшат установку PostgreSQL с точки зрения:

Я сколько лет на заводе козловой кран вожу, ни разу не выгорел! А эти, прям неженки! 

Знакомо?

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

Ишь какие, депрессия у него! Работать не может! Дури вам в голову напихали, вот и оправдываете свою лень!

За свои скромные семь лет на руководящей позиции мне довелось управлять разными людьми. Был опыт тимлидства над командой разработчиков. Не претендую на истину и уж тем более на какое-то серьезное научное исследование. Но все же хочу систематизировать свои наблюдения и сделать цикл статей «команда глазами начальника».