Senior Frontend - javascript, html, css
25.7K subscribers
1.28K photos
2.25K videos
705 links
Senior Front - канал для frontend программистов, практические задачки, проверки знаний, интересные статьи

Админ, сотрудничество, реклама:@seniorFrontPromo, @maria_seniorfront
Канал в реестре РКН https://rknn.link/bsU
Download Telegram
Зачем придумали async/await?

Ключевой целью введения async/await в JavaScript было упростить написание и чтение асинхронного кода, сделать его более линейным и похожим на синхронный.

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

Пример с промисами:

function fetchData() {
return new Promise((resolve) => {
setTimeout(() => {
resolve("some data");
}, 1000);
});
}

fetchData().then((data) => {
console.log(data);
}).catch((error) => {
console.error(error);
});


Пример с async/await:
async function fetchData() {
return new Promise((resolve) => {
setTimeout(() => {
resolve("some data");
}, 1000);
});
}

async function main() {
try {
const data = await fetchData();
console.log(data);
} catch (error) {
console.error(error);
}
}

main();


Избегание "ада коллбеков"
Когда асинхронные операции вложены друг в друга, код становится трудным для чтения и сопровождения. Это называется "адом коллбеков" (callback hell). async/await позволяет писать асинхронный код последовательно, без вложенности.

Пример с промисами:
getData((data) => {
processData(data, (processedData) => {
saveData(processedData, (result) => {
console.log(result);
});
});
});


Пример с async/await:
async function main() {
try {
const data = await getData();
const processedData = await processData(data);
const result = await saveData(processedData);
console.log(result);
} catch (error) {
console.error(error);
}
}

main();


Снижение вероятности ошибок
Когда используется async/await, ошибки могут быть обработаны с использованием привычного try/catch блока, что снижает вероятность пропуска ошибок.

Пример с промисами:
fetchData().then((data) => {
return processData(data);
}).then((processedData) => {
return saveData(processedData);
}).catch((error) => {
console.error(error);
});


Пример с async/await:
async function main() {
try {
const data = await fetchData();
const processedData = await processData(data);
const result = await saveData(processedData);
console.log(result);
} catch (error) {
console.error(error);
}
}

main();


👉 @seniorFront
👍3👎3
This media is not supported in your browser
VIEW IN TELEGRAM
Secret Project

Концепт приложения с множеством функций на HTML, CSS и JS

👉 @seniorFront
👍131
Как использовать японские подходы в IT. Часть 1: петля за петлей

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

Разберись в корне проблемы (root cause, 5 why)
Как бы сделали на производстве раньше: связали нить и стали ткать дальше, будто ничего не было. Этот процесс уже стал привычным, порождая проблемы с возвратом. Проблема привела к простой мысли: если нить рвется, то станок надо остановить и сделать так, чтобы она не рвалась.

Если что-то идет не так — остановись (дзидока)
Нить — это совокупность волокон, сплетенных между собой. Мы можем не заметить, если одно из волокон надорвется, но нить станет более хрупкой. Что говорить о том, когда рвется сама нить.

Дзидока (jidoka) — принцип «целой нити», когда, например, процесс создания ткани продолжается до тех пор, пока все подпроцессы функционируют корректно. Если что-то идет не так — работа останавливается. Наша задача — сделать так, чтобы производство не останавливалось (только если мы этого не хотим) в целом, как целая нить.

Но как сделать, чтобы нить не рвалась? Усовершенствовать станок!

Постоянно совершенствуй (kaizen)
Тоёда-сан шел по циклу Деминга:
- Замечал проблему.
- Придумывал решение.
- Записывал, что идет не так.
- Менял это.
Однако он не мог знать этого, так как до разработки цикла оставались еще десятки лет. Годы жизни Сакити Тоёда — 1867–1930 годы.

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

Оно-сан, путешествуя по США, был поражен устройством работы супермаркетов: все точно находилось на полках тогда, когда это было нужно, и никакой суеты — в отличие от производства Toyota. Помня об идеях Тоёда-сан (Киитиро), он разработал концепцию Just-in-Time (JIT). Если по-простому — все должно быть на своих местах ровно в тот момент, когда это требуется, и только тогда. Если рабочему нужен ключ — он должен быть под рукой. Нужен компонент для монтажа — он тоже должен быть доступен.

Для реализации принципа были построены процессы внутренней доставки по системе Kanban — с использованием карточек-инструкций. Как в супермаркете: у покупателя есть список покупок, он наполняет корзину и доставляет ее куда нужно. Profit!

Точно вовремя (JIT)
Синго-сан, сотрудничая с Оно-сан, углубился еще дальше и заметил, что помимо нехватки материалов производство теряет время из-за дефектов оборудования и ошибок сотрудников. Можно ли устранить дефекты с минимальными временными затратами? Можно, если ремонтировать оборудование во время работы и знать, когда оно сломалось. Это называется быстрой переналадкой или Single-Minute Exchange of Dies (SMED).

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

Узнавай о проблеме и не давай делать ошибки (andon и poka-yoke)
После наладки механической части производства Синго-сан и Оно-сан поняли, что нужно обучать персонал. Но как объяснить процесс неподготовленному рабочему? Очень просто — с помощью Kanban-доски. Как и карточки на производстве, Kanban-доска наглядно показывает, из чего состоит процесс и какие операции нужно выполнить. Это упростило контроль и сделало обучение сотрудников более быстрым.

Показывай наглядно (Kanban)
Как видите, история сделала круг и система Kanban стала применяться повсеместно. Сегодня ее «заимствуют» все, делая вид, что в этом есть что-то сложное. Смешной факт: на нескольких собеседованиях интервьюеры утверждали, что я не знаю, как работать с Kanban. Наивные!

👉 @seniorFront
👍4
Windsurf vs Cursor IDE: кто лучший AI-редактор кода?

Две популярные IDE (среды разработки) с поддержкой искусственного интеллекта: Windsurf и Cursor. Оба инструмента заявляют, что ускорят процесс написания кода, но какой из них лучше подойдет именно вам? Я тщательно изучил обе, и в статье расскажу к каким выводам пришел.

👉 @seniorFront
👍3🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Dropbox Color Picker

Вся сцена - это SVG картинка, анимируемая библиотекой gsap.

👉 @seniorFront
👍72
Media is too big
VIEW IN TELEGRAM
Next Prev & Hover Effects in JavaScript

В этом видео создается эффект при наведении на блок и его соседние блоки на JS.

👉 @seniorFront
👍4
This media is not supported in your browser
VIEW IN TELEGRAM
"Боже, просто подай знак, могу ли я сегодня ничего не делать и списать 8 рабочих часов"

Бог:

👉 @seniorFront
👍31👎3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Blurred Gear Loader

Реализовано с использованием возможностей препроцессоров Pug и SCSS.

👉 @seniorFront
3👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Image Slider

Слайдер, реализованный без использования JS, при помощи радио-кнопок.

👉 @seniorFront
👍143
Media is too big
VIEW IN TELEGRAM
Simple CSS Animation Effects

В этом видео создается оригинальный анимированный загрузчик на чистом CSS.

👉 @seniorFront
👍6👎1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Toggle Dark

Переключатель, реализованный на чистых HTML и CSS.

👉 @seniorFront
👍16🔥5
Roman Numerals Encoder

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

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

В римских цифрах:
1990 год записывается: 1000=M + 900=CM + 90=XC; в результате получается MCMXC.
2008 год записывается как 2000=ММ, 8=VIII; или MMVIII.
1666 год использует каждый римский символ в порядке убывания: MDCLXVI.

Пример:
   1 --> "I"
1000 --> "M"
1666 --> "MDCLXVI"


Справка:
символ - значение:

I 1
V 5
X 10
L 50
C 100
D 500
M 1,000


👉 @seniorFront
👍32
Топ-10 техник атак веб-приложений 2024 года

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

👉 @seniorFront
👍3
Зачем нужен виртуальный DOM?

Виртуальный DOM (Virtual DOM) — это концепция, используемая в современных фреймворках и библиотеках, таких как React, для оптимизации и ускорения работы с реальным DOM. Реальный DOM медленный при частых изменениях, поэтому виртуальный DOM решает эту проблему, делая процесс более эффективным.

Зачем он нужен
1. Улучшение производительности: Значительно уменьшает количество прямых манипуляций с реальным DOM, которые являются дорогостоящими с точки зрения производительности.
2. Упрощение разработки: Работая с ним, можно более эффективно управлять состоянием приложения и его представлением, абстрагируясь от непосредственной работы с реальным DOM.

Как он работает

1. Создание: Когда состояние приложения меняется, создаётся новый виртуальный DOM, представляющий обновлённое состояние.
2. Сравнение: Сравниваются старый и новый виртуальные DOM, чтобы определить, какие части реального DOM нужно обновить. Этот процесс называется "диффинг" (diffing).
3. Минимальные: После сравнения, в реальный DOM вносятся только необходимые изменения, что значительно снижает количество операций с ним.

Пример
import React, { useState } from 'react';

function Counter() {
const [count, setCount] = useState(0);

return (
<div>
<p>Вы нажали {count} раз</p>
<button onClick={() => setCount(count + 1)}>
Нажми меня
</button>
</div>
);
}

export default Counter;


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

Преимущества

1. Повышение производительности: Благодаря уменьшению количества прямых операций с реальным DOM.
2. Кроссбраузерная совместимость: Виртуальный DOM позволяет абстрагироваться от специфичных для браузера особенностей работы с DOM.
3. Лёгкость обновлений и рендеринга: Использование виртуального DOM делает процесс обновления интерфейса приложения более предсказуемым и управляемым.

👉 @seniorFront
👍91
This media is not supported in your browser
VIEW IN TELEGRAM
LED Controls

Оригинальные переключатели, реализованные на React и стилизованные в SCSS.

👉 @seniorFront
👍91
Scrum-то какой! За что критикуют спринты

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

Четыре причины недовольства

1 — Гонка за показателями. Классический спринт дробит процесс разработки на двухнедельные промежутки, в течение которых команда постепенно движется к цели. В теории тикеты в пределах одного спринта должны закрываться равномерно, но на практике бывает иначе. Некоторые разработчики отмечают, что в конце спринта часто начинается кранч — гонка за выполнением задач. Чтобы уложиться в сроки, команда помечает тикеты как завершенные, даже если осталось доделать еще 5% работы, а все недоделки перетекают в новые задачи. Еще хуже, когда команда применяет хаки и костыли, чтобы уложиться в срок, жертвуя качеством.

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

3 — Проблемы междисциплинарности и потеря фокуса. Scrum-гайд отмечает, что в спринтах участвует команда, состоящая из скрам-мастера (одна штука), владельца продукта (одна штука) и разработчиков. Иных ролей в «каноничном» Scrum нет. На практике компании пытаются дооснастить команду не только менеджерами, но и другими специалистами (аналитиками, тестировщиками, юзабилистами), которые, с одной стороны, тоже должны принимать участие в процессе разработки, а с другой — с трудом втискиваются в прокрустово ложе фреймворка.

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

И российские, и зарубежные специалисты при этом сходятся в одном: во-первых, оценить среднюю скорость/мощность/производительность команды (сколько стори поинтов команда может выполнить за спринт) можно только постфактум, по результатам двух или более спринтов, но никак не за «один пристрелочный подход». А во-вторых, даже эти оценки будут очень приблизительными, потому что команда не существует в вакууме: сотрудники уходят в отпуск и на больничный, у них рождаются дети, они увольняются, они, в конце концов, могут столкнуться с выгоранием или разочарованием в работе — все это влияет и на состав команды, и на ее скорость. А излишне оптимистичные оценки — это новый источник стресса, и привет, причина для недовольства номер 1 (кранч и гонка за показателями).

👉 @seniorFront
👍3
Как писать документацию, которую полюбят: 15 must-read книг (и не только)

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

👉 @seniorFront
👍7
This media is not supported in your browser
VIEW IN TELEGRAM
page flip

Создано и стилизовано на HTML и CSS. При нажатии изменяются CSS классы через JS.

👉 @seniorFront
6👍5
Media is too big
VIEW IN TELEGRAM
Fifteen Puzzle Game

В этом видео создается игра пятнашки на JS.

👉 @seniorFront
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Когда только ты знаешь, как работает легаси-код

👉 @seniorFront
🔥152👍2