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

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

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

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

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

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

Интерактивный гайд по CRDT

Благодаря CRDT можно легко создавать приложения с совместным редактированием, такие как Google Docs, но без необходимости подключаться к серверу.

В этой серии статей мы узнаем, что такое CRDT. Затем напишем простой редактор, объединим его с более сложными структурами данных и, наконец, применим то, что мы выучили, чтобы создать совместный редактор, похожий на Paint в онлайне.

https://jakelazaroff.com/words/an-interactive-intro-to-crdts/

#typescript #crdt


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

const

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

Сейчас мы можем использовать модификатор const. Он не делает переменную неизменной, а просто блокирует ее присвоение (пример 1). Если у вас не примитивное присвоение (объект или массив), в этом случае значение переменной может быть изменено (пример 2).


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

Что такое миксины?

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

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

let sayHiMixin = {
    sayHi() {
        console.log(`Привет, ${this.name}`);
    },
    sayBye() {
        console.log(`Пока, ${this.name}`);
    }
};

class User {
    constructor(name) {
        this.name = name;
    }
}

// Копируем методы sayHiMixin в User.prototype
Object.assign(User.prototype, sayHiMixin);

let user = new User("Вася");
user.sayHi(); // Привет, Вася
user.sayBye(); // Пока, Вася

В этом примере миксин sayHiMixin добавляет методы sayHi и sayBye к классу User.

Миксины в CSS (Sass/SCSS)
Обычно используются в препроцессорах, таких как Sass или Less. Миксины позволяют определять наборы стилей, которые можно повторно использовать в различных местах стилей.

@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
       -moz-border-radius: $radius;
            border-radius: $radius;
}

.box { 
    @include border-radius(10px);
    width: 100px;
    height: 100px;
    background-color: lightblue;
}

В этом примере миксин border-radius определяет стили для создания скругленных углов. Затем он используется в классе .box для применения этих стилей.

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

👉 @seniorFront

​GraphQL или REST: Какой API выбрать, чтобы не прогадать?

Расскажу о GraphQL, сравню с REST. Разберемся в плюсах и минусах каждого подхода к проектированию API. Выбираем лучший для вашего проекта!

Распространенность и интеграция
В 2015 году Facebook представил GraphQL. С тех пор эта технология набирает популярность, но REST остается лидером. По данным Postman на 2024 год, GraphQL используют 29% разработчиков, REST — 90%.

Если заранее неизвестны потребители API, лучше выбрать REST — он проще и популярнее:
- Разработчикам, знакомым с HTTP, легко освоить REST. Он использует стандартные HTTP-методы и принципы.
- REST API можно реализовать на любом языке, поддерживающем HTTP, без дополнительных слоев.
- REST — проверенная технология с сильным сообществом и множеством готовых инструментов.

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

Рассмотрим пример. Есть сущность «Игрушка» (Toy), которую создает «Мастер» (Master), привязанный к «Пользователю» (User). У игрушки также есть «Категория» (Category) и «Теги» (Tags).

GraphQL позволяет получить все данные одним запросом:

query getToy {
  toy(id: 1) {
    id
    name
    category {
      id
      name
    }
    tags {
      id
      name
    }
    master {
      id
      info
    }
  }
}

В случае REST API потребовалась бы серия запросов:

GET http://localhost:8080/toys/1 - Получаем игрушку по ID
GET http://localhost:8080/categories/2 - Получаем категорию игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/tags?id=1&id=2&id=3 - Получаем теги игрушки по ID, которые взяли из объекта игрушки
GET http://localhost:8080/masters/3 - Получаем мастера игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/users/4 - Получаем пользователя, к которому привязан мастер, по ID, который взяли из объекта мастера

В приложениях со сложными связями между доменами GraphQL упрощает получение данных: один запрос вместо пяти (в примере). Кроме того, можно исключить ненужные поля, например, createdAt и updatedAt. GraphQL возвращает только то, что нужно.

Версионирование
GraphQL использует одну версию endpoint. Изменения вносятся в схему без явного версионирования API, что упрощает развитие.

REST API нужно версионировать для безопасных изменений. Обычно это делается в URL, например: http://localhost:8080/v1/toys.

Ошибки и коды ответа
GraphQL всегда отвечает кодом 200 OK, даже при ошибках. Информацию об ошибке ищите в поле errors JSON-ответа. Клиент не может проверить статус по HTTP-коду и вынужден анализировать тело ответа.

REST использует стандартные HTTP-коды (400, 404, 500) для обозначения результата. Это делает обработку ошибок в REST более наглядной

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

Тестировать GraphQL сложнее, особенно с файлами: больше настроек в запросах, чем в REST. GraphQL проще версионировать — меняем схему, и всё, а в REST приходится менять URL. Наконец, GraphQL всегда отвечает кодом 200 и сообщает об ошибках в теле ответа, а REST использует стандартные коды ошибок, что делает их более заметными.

👉 @seniorFront

– OpenAI представила новый голосовой ассистент, который теперь может в реальном времени анализировать изображение, речь и текст — конкуренция Siri и Alexa становится серьезной.
– Google тестирует поиск с интеграцией ИИ-резюме, который меняет привычный способ продвижения сайтов. SEO-специалисты — держитесь!
– TikTok анонсировал AI Creative Assistant — теперь ИИ помогает создавать и тестировать рекламные креативы за секунды.

Хочешь быть в курсе последних новостей в мире ИИ/ИТ/маркетинга ?

Мы собрали папку Telegram-каналов, где эксперты каждый день:

https://t.me/addlist/gs3Io1EOk2lhNmEy

✔ разбирают тренды
✔ выкладывают кейсы
✔ делятся фреймворками, которые экономят десятки часов
✔ и сразу показывают, как использовать ИИ в маркетинге и ИТ на практике.

📂 Открой доступ к Telegram-папке → https://t.me/addlist/gs3Io1EOk2lhNmEy


Original post link: t.me/frontendnoteschannel/4625
Forwarded and filtered by @smartfeed_bot

Стрелочные и обычные функции в JavaScript: в чём разница?

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

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

Обычные функции пишутся с использованием ключевого слова function, а стрелочные — с помощью более компактного синтаксиса =>.

//Обычная функция
function greet(name) {
  return "Привет, " + name;
}

//Стрелочная функция
const greet = (name) => "Привет, " + name;

This. Одно из главных различий — как функции работают с контекстом this.

— В обычной функции this зависит от того, как её вызвали.
— В стрелочной функции this берётся из внешнего окружения и не меняется.
Это важно, когда вы работаете с объектами или обработчиками событий.

Аргументы. Обычные функции имеют встроенный объект arguments для доступа ко всем переданным параметрам, а стрелочные — нет (но можно использовать ...args).

Конструкторы. Обычную функцию можно использовать с new для создания объектов, стрелочную — нельзя.

Генераторы. Обычные функции поддерживают синтаксис function* для генераторов, стрелочные — нет.

Чтобы понять разницу работы с this на практике, рассмотрим пример с объектом:

const person = {
  name: "Алекс",
  sayHello: function() {
    console.log("Привет, я " + this.name);
  },
  sayHelloArrow: () => {
    console.log("Привет, я " + this.name);
  }
};

person.sayHello();       // Привет, я Алекс
person.sayHelloArrow();  // Привет, я undefined

— В методе sayHello (обычная функция) this указывает на объект person, и мы получаем доступ к свойству name.

— В методе sayHelloArrow (стрелочная функция) this берётся из внешнего контекста (например, window), где name не определён, поэтому результат — undefined.
Этот пример показывает, почему выбор типа функции важен в зависимости от задачи.

Стрелочные функции отлично подходят для коротких коллбэков (например, в map или setTimeout) и случаев, когда не нужен собственный`this`.

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

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

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

​Зачем нужен Nginx?

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

Как Nginx раздаёт фронтенд-приложение?
Когда мы билдим SPA-приложение (например, React/Vue/Angular), в папке dist появляются статические файлы (index.html, app.js, styles.css).

server {
    listen 80;
    server_name myapp.com;
    root /var/www/myapp/dist;
    index index.html;
    
    location / {
        try_files $uri /index.html;
    }
}

Как Nginx проксирует запросы к бэкенду?
Если фронтенд (myapp.com) и бэкенд (api.myapp.com) находятся на разных серверах, Nginx может перенаправлять запросы на API.

server {
    listen 80;
    server_name myapp.com;
    root /var/www/myapp/dist;
    index index.html;

    location / {
        try_files $uri /index.html;
    }

    # Проксирование API-запросов
    location /api/ {
        proxy_pass http://localhost:5000/; # Node.js, Python, PHP и т. д.
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Как Nginx балансирует нагрузку?
Если у нас несколько бэкенд-серверов, Nginx может распределять нагрузку между ними.

upstream backend {
    server backend1.myapp.com;
    server backend2.myapp.com;
}

server {
    listen 80;
    server_name api.myapp.com;

    location / {
        proxy_pass http://backend;
    }
}

Как Nginx ускоряет сайт с кэшем?
Кэширование уменьшает нагрузку на сервер и ускоряет загрузку страниц.

location /static/ {
    expires 7d; # Кэшировать файлы на 7 дней
    add_header Cache-Control "public, max-age=604800";
}

👉 @seniorFront

​Гореть, но не сгорать: практические советы по борьбе с burnout’ом

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

Что на самом деле нужно делать?
Только системный подход, только хардкор — смена личных и рабочих привычек, выстраивание нового подхода к рабочему процессу. Ниже — несколько советов.

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

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

Беремся за физическое восстановление
Здоровье у вас одно, стимуляторы из Fallout у нас пока не изобрели, а бионические протезы не так доступны, как в Cyberpunk 2077. Поэтому беремся за восстановление организма. Учимся замечать усталость. В глазах рябит от кода, в голове туман — идем отдыхать, а не терпим. Можно попробовать внедрить правило 90/30 (30-минутный отдых каждые полчаса) или другой формат перерывов. Естественно, во время отдыха не скроллим ленты и стараемся вообще не смотреть в экран. Обедаем где-нибудь вдали от клавиатуры, если на удаленке — тем более.

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

Главное — помните. К этому состоянию вы пришли не за один месяц, а значит, восстановление тоже займет какое-то время. Не ждите, что после недельки в новом режиме или отпуска сразу все наладится.

👉 @seniorFront