Порты в веб-разработке: от локальной разработки до продакшена

Эта статья предназначена в первую очередь для веб-разработчиков. Я не являюсь экспертом в области сетей, администрирования или DevOps, поэтому представленный материал не углубляется в сетевые аспекты.

Из любопытства, я как то задался вопросом практического использования разных номеров портов: что они означают для разработчиков, почему используются определенные порты, и какие приложения чаще всего запускаются на них. Цель статьи — пролить немного света на эти “магические” циферки с точки зрения их прикладного применения веб-разработчиками.

👉 @seniorFront


Original post link: t.me/seniorFront/4927
Forwarded and filtered by @smartfeed_bot

Создаем React с нуля

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

Подробности: https://www.rob.directory/blog/react-from-scratch

#react #туториал


Original post link: t.me/tproger_web/5203
Forwarded and filtered by @smartfeed_bot

Полезные ИИ для веб-разработчиков

Вчера в открытом доступе появилась китайская нейросеть DeepSeek, новость о которой обвалила фондовый рынок США Чуть ранее вышло обновление китайской Qwen2.5-Plus, которая якобы ещё мощнее, чем DeepSeek и ChatGPT. Они обе бесплатны и неплохо справляются с написанием кода, это админ проверил лично.

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

Изучаем и выбираем инструменты для себе по ссылке: https://habr.com/ru/companies/timeweb/articles/873430/

P.S.: так как исследование проводилось до выхода китайских «убийц OpenAI», они в исследование не попали.

#ml #ии


Original post link: t.me/tproger_web/5206
Forwarded and filtered by @smartfeed_bot

Небольшой лайфхак, как избежать ненужных useEffects, когда пишешь на реакте.

#react


Original post link: t.me/tproger_web/5210
Forwarded and filtered by @smartfeed_bot

#вопросы_с_собеседований
Что такое цикл событий (event loop) и как он работает?

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

Список событий, подлежащих обработке, формирует очередь событий. Когда стек освобождается, движок может обрабатывать событие из очереди. Координирование этого процесса и происходит в event loop.

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


Original post link: t.me/senior_front/2409
Forwarded and filtered by @smartfeed_bot

Как правильно работать с DOM в JavaScript в 2025 году?

Работа с DOM (Document Object Model) — это основа веб-разработки. С каждым годом появляются новые, более эффективные способы манипуляции элементами страницы. Давайте разберём, как сегодня правильно работать с DOM в JavaScript, чтобы код был быстрым, удобным и безопасным.

1. Получение элементов

Вместо старых getElementById и getElementsByClassName сегодня лучше использовать querySelector и querySelectorAll. Они более универсальные и понятные.

const title = document.querySelector("#title"); // Получает 1 элемент (по id)
const buttons = document.querySelectorAll(".btn"); // Получает список всех кнопок с классом .btn

querySelector и querySelectorAll позволяют находить элементы так же, как в CSS (.класс, #id, input[type="text"] и т. д.). А также querySelectorAll возвращает не «живую» коллекцию, а обычный статичный список (NodeList), что логичнее при итерации.

2. Изменение текста и HTML

Всё зависит от того, что именно нужно поменять.

textContent — если надо изменить только текст (без HTML).

title.textContent = "Привет, мир!";

Не используйте innerHTML, если вставляете данные от пользователя — это дыра в безопасности (XSS-атаки). Если всё же используется innerHTML, убедитесь, что данные проверены.

title.innerHTML = "<strong>Важное сообщение!</strong>";

insertAdjacentHTML — отличная альтернатива innerHTML, если нужно добавить HTML в определённое место, не перезаписывая весь элемент.

title.insertAdjacentHTML("beforeend", "<span> 👋</span>");

3. Изменение классов

Правильный способ через classList, потому что `className`заменяет все классы сразу, из-за чего можно случайно удалить важные стили.

title.classList.add("highlight"); // Добавит класс
title.classList.remove("hidden"); // Удалит класс
title.classList.toggle("active"); // Переключит класс (если был — уберёт, если не было — добавит)

4. Изменение стилей

Не стоит вручную писать style.cssText, потому что он затирает всё, что было до этого. Используйте style для отдельных свойств.

title.style.color = "red";
title.style.fontSize = "24px";

Если нужно много стилей — лучше добавьте или измените класс. Так проще, централизованно и удобнее управлять дизайном.

title.classList.add("error"); // В CSS заранее определите .error { color: red; }

5. Создание и добавление новых элементов

Лучший способ — использовать createElement, а не innerHTML.

const newDiv = document.createElement("div"); // Создаём элемент <div>
newDiv.textContent = "Новый блок!";
newDiv.classList.add("box");  
document.body.appendChild(newDiv); // Добавляем в конец <body>

Если нужно добавлять элементы в разные места:

appendChild() — добавляет в конец родителя.

prepend() — добавляет в начало.

before() и after() — добавляют перед или после элемента.

title.after(newDiv); // Вставит newDiv сразу после title

// С помощью append() можно сразу добавлять текст и несколько элементов
const container = document.querySelector(".container");
container.append("Просто текст", document.createElement("span"));

6. Удаление элементов

Самый актуальный способ — remove().

newDiv.remove(); // Удалит элемент из DOM

Раньше приходилось делать так (и это было неудобно):

newDiv.parentNode.removeChild(newDiv); // Старый подход

7. Обработчики событий (современный подход)

Раньше часто использовали`onclick`, но перезаписывает предыдущие обработчики и плохо управляется. Лучше используйте addEventListener.

const button = document.querySelector("#myButton");

button.addEventListener("click", () => {
  alert("Кнопка нажата!");
});

Мы рассказали только часть советов. Если знаете что-то ещё важное, о чем мы не рассказали тут, поделитесь в комментариях.

#простымисловами #фронтенд

​Как стоит оценивать задачи, чтобы улучшить прогнозирование сроков?

Одной из самых частых проблем, с которыми сталкиваются команды, является неточность планирования сроков выполнения задач.
Разработчик говорит: «Это на пару часов». Проходит день, потом два, и выясняется, что в процессе работы всплыли интеграционные проблемы, тестировщики нашли баги, а кто‑то еще ждет согласования. В итоге задача, которую оценили в несколько часов, затягивается на несколько дней или недель.

Почему так происходит? Потому что абсолютные оценки в часах не работают. Они не учитывают неопределенности, возникающие в процессе работы:

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

Как же тогда планировать и прогнозировать сроки выполнения задач?

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

Как это сделать:
- Фиксируйте, когда задача была взята в работу и когда она реально была завершена (включая тестирование и релиз).
- Отслеживайте не только время разработки, но и задержки, связанные с ожиданием ответов, согласованиями и релизами.
- Разделите задачи по размеру (например, S, M, L, XL) и собирайте статистику по каждому типу.

2. Оценивать задачи не в часах, а в относительных единицах
Когда команда оценивает задачи в часах, это создает иллюзию точности, которая на самом деле приводит к ошибкам. Вместо этого лучше использовать относительные оценки, например:

- Story Points (по ряду Фибоначчи: 1, 2, 3, 5, 8 и так далее).
- Оценку в «футболках» (XS, S, M, L, XL).

Как это работает:
- Находим в бэклоге самую маленькую задачу, принимаем ее за 1 SP (или XS).
- Сравниваем другие задачи с ней и оцениваем их относительно друг друга.
- Планируем спринт и смотрим, сколько SP команда реально завершает за итерацию.
- Через 3–5 спринтов накапливается статистика, на которую можно опираться при планировании.

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

3. Использовать статистику выполнения прошлых спринтов
Если вы работаете по Scrum, можно анализировать, сколько Story Points команда выполняла в прошлых спринтах.

Как это сделать:
- Фиксируйте скорость команды (Velocity) — среднее количество выполненных SP за спринт.
- Учитывайте тенденции — если команда стабильно делает 30 SP за спринт, то планировать на следующий спринт 50 SP бессмысленно.
- Анализируйте вариативность — насколько часто сроки отклонялись от запланированных, какие были причины.

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

👉 @seniorFront

Позиционирование элементов с помощью JS

Для позиционирования элементов на странице веб-сайта можно использовать CSS свойства, такие как position, top, left, right, bottom. Однако, в некоторых ситуациях может потребоваться изменять эти свойства динамически с помощью JavaScript.

Для изменения кастомных CSS свойств с помощью JavaScript можно использовать метод setProperty() объекта style. Для этого необходимо указать имя свойства и его значение.

Использование setProperty() позволяет создавать анимации и другие эффекты на странице, которые изменяют CSS свойства элементов динамически.


Original post link: t.me/senior_front/2426
Forwarded and filtered by @smartfeed_bot

​Как использовать японские подходы в 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

​Scrum-то какой! За что критикуют спринты

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

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

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

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

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

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

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

👉 @seniorFront

JavaScript. Что будет выведено в консоль?


Original post link: t.me/senior_front/2440
Forwarded and filtered by @smartfeed_bot

Меняем JS-библиотеку анимации на View Transitions

Теперь не нужно подтягивать тяжелые JavaScript библиотеки для анимаций в ваш проект. В Chrome и Safari появилась поддержка View Transitions API. Эта апишка дает нам механизм для простого создания анимированных переходов между различными состояниями веб-сайта без необходимости расписывать сложную логику с помощью JS.

Как это работает вы можете увидеть здесь.

#фронтенд #css #javascript


Original post link: t.me/tproger_web/5326
Forwarded and filtered by @smartfeed_bot

Используем tan(atan2()) для работы с вьюпортами в CSS

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

Как это работает и где можно использовать, подробно рассказано здесь.

#css #фронтенд #лайфхак


Original post link: t.me/tproger_web/5328
Forwarded and filtered by @smartfeed_bot

​Как тебя тянут назад, а ты этого не замечаешь. Менталитет краба

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

Суть менталитета краба: когда люди видят, что вы пробуете новое или добиваетесь успеха, вместо поддержки они критикуют, буллят, обесценивают. Их цель — остановить вас, чтобы вы не выбились вперёд. Почему? Зависть и страх.

Примеры менталитета краба:
— Вижу это у "опытных" в IT — они внушают новичкам, что "Рынок переполнен", "Без 5 лет страданий ничего не добьёшься". Одна из причин (осознанно или нет) — отпугнуть конкурентов и сохранить свой статус.

— Те, кто хотел бы уехать, но боится, осуждают тех, кто решился: "Ты там никому не нужен", "Вот уедешь, а потом пожалеешь!", "Ты предал нас".

— Ты строишь карьеру или делаешь бизнес: "Деньги — это не главное, когда жить собираешься?", "Ты как робот — только работа, цели, задачи. Расслабься!", "Ты слишком амбициозная, независимая, серьезная — мужчинам это не нравится" (женский вариант).

— Ты развиваешь свой блог или канал: "Да кому это вообще интересно?", "Блогеры — это несерьёзно, вот на заводе (в больнице и тп) настоящие профессии".

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

— Когда старшее поколение считает, что молодые должны повторить их сложный путь: "Мы в 90-е без выходных пахали за копейки, а вы хотите нормальные зарплаты, удалёнку, баланс работы и жизни, путешествия, свободу выбора? Много хотите!"

— "А ты уверен, что тебе это надо?", "Ты что думаешь, лучше других?", "Бизнес — это опасно", "Ты недостаточно молодой/старый [подставить нужное]". И так далее.

И тут вы скажете — просто не общаться с такими людьми и будете правы (в книгах по саморазвитию не зря говорят о важности окружения). Но есть несколько нюансов:

1. Это только самые очевидные примеры, но на деле всё сложнее.
— Если это говорит авторитетный человек — его слова воспринимаются совсем иначе. "Нельзя переезжать, пока не выучишь язык" — и ты уже сомневаешься (это ж гуру говорит, как ему не поверить).
— Чем умнее человек, тем он опаснее в этом плане. Он выдаст 500 фактов, расчётов, логичных доводов, почему вам нельзя что-то начинать делать и у вас не получится.

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

3. Люди не всегда хотят навредить — часто это просто их сомнения и страхи, но результат один: тебя это тянет вниз.

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

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

Идти своим путём — только я знаю, что для меня правильно. Слушать советы, но не позволять другим управлять жизнью. Зависнешь на чужом мнении — останешься в ведре.

👉 @seniorFront

Как в Notion развивают код с помощью пользовательских правил ESLint

В Notion разработали систему «растягивания», которая помогает постепенно внедрять правила линтинга в течение длительного периода времени, что способствует модернизации кодовой базы без ущерба для скорости работы разработчиков.

О том, как это работает и как вам попробовать эту систему, рассказали в блоге.

#eslint


Original post link: t.me/tproger_web/5339
Forwarded and filtered by @smartfeed_bot

​Зачем необходим DOM?

DOM (Document Object Model) необходим для взаимодействия с веб-страницами и управления их содержимым, структурой и стилями программным образом. DOM представляет собой программный интерфейс для HTML и XML документов. Он описывает логическую структуру документов и позволяет языкам программирования взаимодействовать с ними.

Зачем он нужен
1. Доступ к элементам страницы: Позволяет программно получать доступ к элементам HTML-документа (теги, текст, атрибуты) и манипулировать ими.
2. Изменение содержимого: С помощью него можно изменять содержимое страницы динамически, например, обновлять текст, менять изображения, добавлять или удалять элементы.
3. Обработка событий: Позволяет обрабатывать события, такие как клики, нажатия клавиш, прокрутка и другие взаимодействия пользователя с веб-страницей.
4. Динамическое изменение структуры страницы: Предоставляет методы для добавления, удаления и изменения элементов и атрибутов, что позволяет динамически изменять структуру страницы.
5. Интерактивность: С помощью него можно создавать интерактивные веб-приложения, которые реагируют на действия пользователя без перезагрузки страницы.

Как он работает
Представляет собой древовидную структуру, где каждый элемент страницы является узлом дерева. Вершиной дерева является объект document, который представляет весь HTML-документ. Узлы могут быть элементами (<div>, <p>, <a> и т.д.), текстом, комментариями и другими типами.

Пример HTML-документа:

<!DOCTYPE html>
<html>
<head>
  <title>Document Object Model</title>
</head>
<body>
  <h1>Hello, world!</h1>
  <p>This is a paragraph.</p>
</body>
</html>

Структура для этого документа:

document
 └── html
     ├── head
     │   └── title
     │       └── "Document Object Model"
     └── body
         ├── h1
         │   └── "Hello, world!"
         └── p
             └── "This is a paragraph."

Основные методы и свойства

Доступ к элементам:
✅document.getElementById(id): Возвращает элемент по его id.
✅document.getElementsByClassName(className): Возвращает все элементы с указанным классом.
✅document.getElementsByTagName(tagName): Возвращает все элементы с указанным тегом.
✅document.querySelector(selector): Возвращает первый элемент, соответствующий CSS селектору.
✅document.querySelectorAll(selector): Возвращает все элементы, соответствующие CSS селектору.

Создание и удаление элементов:
✅document.createElement(tagName): Создает новый элемент.
✅parentElement.appendChild(childElement): Добавляет элемент в конец дочерних элементов родителя.
✅parentElement.removeChild(childElement): Удаляет элемент из дочерних элементов родителя.

Изменение содержимого и атрибутов:
✅element.innerHTML: Изменяет или получает HTML-содержимое элемента.
✅element.textContent: Изменяет или получает текстовое содержимое элемента.
✅element.setAttribute(name, value): Устанавливает значение атрибута элемента.
✅element.getAttribute(name): Получает значение атрибута элемента.

Пример:

// Изменение текста заголовка
const header = document.querySelector('h1');
header.textContent = 'Hello, DOM!';

// Добавление нового параграфа
const newParagraph = document.createElement('p');
newParagraph.textContent = 'This is a new paragraph.';
document.body.appendChild(newParagraph);

// Изменение атрибута
const link = document.querySelector('a');
link.setAttribute('href', 'https://www.example.com');

👉 @seniorFront

Разница между SPA и PWA

Мы часто сталкиваемся с терминами SPA (Single Page Application) и PWA (Progressive Web App). Давайте разберемся, что они означают и в чем их основные отличия.

SPA — это веб-приложение, которое загрузится однажды и будет динамически обновлять контент на странице без необходимости перезагрузки. Это значит, что после начальной загрузки сайта пользователю не нужно ожидать, пока загрузится новая страница. Все взаимодействия происходят на одном HTML-документе, что делает работу с приложением более плавной и быстрой. Примеры SPA: Gmail, Google Maps.

Для создания простого SPA можно использовать библиотеки или фреймворки, такие как React или Vue.js. Вот небольшая структура на React:

import React from 'react';
import ReactDOM from 'react-dom';
function App() {
    return (
        <div>
            <h1>Привет, мир!</h1>
            <p>Это простое SPA приложение.</p>
        </div>
    );
}
ReactDOM.render(<App />, document.getElementById('root'));

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

Для создания простого PWA вам нужно добавить файл манифеста и service worker. Пример манифеста:

{
    "name": "Мое PWA приложение",
    "short_name": "PWA",
    "start_url": ".",
    "display": "standalone",
    "background_color": "#ffffff",
    "theme_color": "#000000",
    "icons": [
        {
            "src": "icon.png",
            "sizes": "192x192",
            "type": "image/png"
        }
    ]
}

Основные отличия:

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

2. SPA может быть частью PWA. PWA включает все возможности SPA и добавляет дополнительные функции, такие как работа в офлайн-режиме, установка на устройство и поддержка push-уведомлений.

3. SPA чаще всего использует JavaScript-библиотеки и фреймворки (React, Angular, Vue), тогда как PWA требует дополнительных технологий, таких как сервисные работники и манифесты.

#простымисловами #spa #pwa

​Ожидание vs реальность: какие взгляды я поменял за 10 лет в разработке

Старший инженер-программист в Amazon Крис Киль (Chris Kiehl), автор книги по дата-ориентированному программированию на Java поделился заметкой о том, как изменились его взгляды за 10 лет пребывания в индустрии разработки ПО.

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

О чём поменял своё мнение
Вот что я верю сейчас, но о чём раньше бы поспорил:

- Простота — не данность. Она требует постоянной работы.
- Нечем гордиться, если вы оперируете и мыслите сложными конструкциями.
- Типизация в языках программирования нужна в командах с разным уровнем опыта.
- Java — великий язык, потому что скучный.
- Среды REPL (интерактивные среды исполнения) бесполезны в проектировании, но как инструмент для исследований они хороши.
- Львиную долю программирования нужно выполнять задолго до написания первой строчки кода.
- Frontend-разработка — это кафкианский кошмар, который я больше не выношу.
- Привлекательность — это не метрика.
- Эффективное управление бесценно. За свою карьеру я многое повидал и пережил прежде, чем сам узнал, что такое хороший менеджмент.
- DynamoDB — хорошая база данных, только если ваша рабочая нагрузка не выходит за рамки её возможностей.
- Объекты хороши исключительно для тех целей, для которых они предназначены. Слепая преданность функциональному подходу — глупость.

О чём сформировал мнение

- Разработка — это про коммуникацию.
- Никогда не используйте полные монады в Java.
- Планировщик запросов — это злая госпожа.
- Если что-то кажется мне простым — это точно что-то, чего я до конца не понимаю.
- Молодым разработчикам нужно давать пространство для ошибок и экспериментов.
- Нужно активно инвестировать в развитие своих софт-скиллов. Это быстро окупается.
- В разработке приложений мало места для абстракций. Просто пишите нужный код.
- А вот разработка библиотек, наоборот, основана на абстракциях. Потратьте время на поиски алгебраических структур.
- ORM — это дьявол во всех языках и реализациях. Используйте SQL.
- Главная беда функционального программирования — это функциональные программисты.
- В долгосрочной перспективе вы глубоко пожалеете о выборе бессерверных функций.
- Типы — это просто утверждения о мире, в котором работает ваш код.
- Распределённые блокировки по-прежнему и по какой-то непонятной причине остаются очень сложными.
- Навыки формального моделирования и анализа — это база.
- Изоляция — важнейшее свойство хорошего набора интеграционных тестов.
- Худшее, что можно выбрать для разработки приложений общего назначения — это DynamoDB.
- Большинству плевать на ремесло программиста. Берегите тех, кому не всё равно. С остальным смиритесь.
- Будущее за языками с постепенной зависимой типизацией.
- Вы буквально не можете добавлять к тестовому коду слишком много комментариев (готов поспорить с тем, кто сможет).

О чём мнение не поменялось
- Те, кто заморачивается над стилем кода, правилами линтинга и прочими мелочами — извращенцы. Занимайтесь более важными вещами.
- Покрытие кода никак не связано с качеством кода. А зачастую и вовсе обратно пропорционально ему.
- Монолиты остаются довольно няшными.
- Крайне сложно превзойти десятилетия исследований и доработок реляционных баз данных.
- Использование микросервисов нужно обосновывать, а то их всё чаще воспринимают как решение по умолчанию.
- Большинство проектов не нужно масштабировать. Иллюзия этой необходимости только вредит.
- Если завтра исчезнут 93%, а может быть, даже 95,2% проджектов — ничего не изменится, а то и повысится эффективность работы.

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

👉 @seniorFront

​Переключение между контекстами убивает эффективность разработчиков на корню

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

Как избежать переключения между контекстами

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

2. 📝 Заносите задачи в список дел. Используйте любой инструмент, например, Todoist или Microsoft To Do, чтобы выгружать задачи из головы. Это снизит напряжённость. В любой момент можно свериться со списком и решить, над какой задачей работать дальше. Выберите самую важную задачу и начните с неё.

3. 🔢 Расставляйте приоритеты. Этот приём поддерживает вовлечённость в работу и не даёт отвлекаться.

4. 🔒 Выделяйте время для сосредоточенной работы. Установите полуторачасовые интервалы для сосредоточенной работы по методике, описанной в книге Кэла Ньюпорта «В работу с головой». Это оптимальное время для сохранения стабильной концентрации внимания. При этом нужно организовать минимум 4–6 часов сосредоточенной работы. Отметьте эти блоки у себя в календаре и для их выполнения выберите время дня, когда вы на пике энергии. Для большинства людей это — утро.

5. 🅿️ Используйте «парковку идей». Во время работы держите открытым текстовый файл. Если вам в голову приходит мысль или возникает новая задача, не переключайтесь на неё, а просто быстро запишите её в файл. Так вы сможете не отвлекаться.

6. 🚧 Оставляйте себе «хлебные крошки» на случай, если вас отвлекут. Когда вы занимаетесь сложной задачей, оставляйте себе подсказки. Если вас отвлекли, лаконичный комментарий о том, почему в файле с исходным кодом в IDE вы написали именно эту строчку, сэкономит вам несколько часов, которые ушли бы на восстановление вашего хода мысли. Этим же приёмом можно пользоваться в конце дня. Тогда завтра вы точно будете знать, с чего продолжить. А ещё это помогает бороться с эффектом Зейгарник — стремлением заполнять рабочую память незавершёнными задачами.

7. 🔕 Минимизируйте отвлекающие факторы. Как вариант, наденьте шумоподавляющие наушники, отключите неважные уведомления или создайте изолированное рабочее пространство. Отличный вариант — выключать на какое-то время мессенджеры и включать на телефоне режим «Не беспокоить».

8. 🤹 Откажитесь от многозадачности. Наш мозг может корректно и сосредоточенно работать только над одной задачей. Так что берите в работу что-то одно.

9. 💺 Продумайте эргономику. Обзаведитесь эргономичным столом и стулом, настройте монитор, чтобы сократить физический дискомфорт.

10. 📂 Организуйте пространство. Не загромождённое рабочее пространство снижает когнитивную нагрузку и помогает сосредоточиться на задаче.

👉 @seniorFront