Топ-10 техник атак веб-приложений 2024 года
PortSwigger опубликовали топ-10 техник атак веб-приложений 2024 года, проекта, созданного усилиями сообщества, чтобы определить самые инновационные и важные исследования в области веб-безопасности, опубликованные за последний год.
👉 @seniorFront
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 вносятся только необходимые изменения, что значительно снижает количество операций с ним.
Пример
В этом примере при каждом изменении состояния
Преимущества
1. Повышение производительности: Благодаря уменьшению количества прямых операций с реальным DOM.
2. Кроссбраузерная совместимость: Виртуальный DOM позволяет абстрагироваться от специфичных для браузера особенностей работы с DOM.
3. Лёгкость обновлений и рендеринга: Использование виртуального DOM делает процесс обновления интерфейса приложения более предсказуемым и управляемым.
👉 @seniorFront
Виртуальный 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
👍9❤1
This media is not supported in your browser
VIEW IN TELEGRAM
LED Controls
Оригинальные переключатели, реализованные на React и стилизованные в SCSS.
👉 @seniorFront
Оригинальные переключатели, реализованные на React и стилизованные в SCSS.
👉 @seniorFront
👍9❤1
Scrum-то какой! За что критикуют спринты
На первый взгляд, гибкая разработка и сопутствующие методологии уже лет двадцать как стали новой нормой. Но если копнуть поглубже, немало инженеров и сегодня считают, что появление в компании консультантов по Scrum — повод срочно обновить резюме. Разбираемся, за что не любят спринты, кто виноват и можно ли с этим что-то сделать.
Четыре причины недовольства
1 — Гонка за показателями. Классический спринт дробит процесс разработки на двухнедельные промежутки, в течение которых команда постепенно движется к цели. В теории тикеты в пределах одного спринта должны закрываться равномерно, но на практике бывает иначе. Некоторые разработчики отмечают, что в конце спринта часто начинается кранч — гонка за выполнением задач. Чтобы уложиться в сроки, команда помечает тикеты как завершенные, даже если осталось доделать еще 5% работы, а все недоделки перетекают в новые задачи. Еще хуже, когда команда применяет хаки и костыли, чтобы уложиться в срок, жертвуя качеством.
2 — Бюрократия. Также все чаще звучат мнения о том, что гибкие методологии приводят к микроменеджменту. Да, планирование, ретроспективы, стендапы — все это неотъемлемые составляющие каждого спринта, которые призваны помочь команде координировать усилия. К сожалению, как и в случае со многими другими разумными инициативами, их можно довести до абсурда — особенно, если команда обрастает менеджерами, с излишним рвением следующими букве фреймворка. В итоге программисты вместо реализации новых фич занимаются бюрократией: ресурсы уходят на отчёты и обсуждения.
3 — Проблемы междисциплинарности и потеря фокуса. Scrum-гайд отмечает, что в спринтах участвует команда, состоящая из скрам-мастера (одна штука), владельца продукта (одна штука) и разработчиков. Иных ролей в «каноничном» Scrum нет. На практике компании пытаются дооснастить команду не только менеджерами, но и другими специалистами (аналитиками, тестировщиками, юзабилистами), которые, с одной стороны, тоже должны принимать участие в процессе разработки, а с другой — с трудом втискиваются в прокрустово ложе фреймворка.
4 — Субъективная оценка производительности. Один из краеугольных камней, который появляется в каждом первом материале с критикой Scrum — сложности в оценке того, какой объем работы команда может реализовать за спринт. Вне зависимости от того, происходит оценка в человекочасах или стори пойнтах, точно спланировать объем работы, который не будет ни чрезмерным, ни недостаточным, крайне затруднительно.
И российские, и зарубежные специалисты при этом сходятся в одном: во-первых, оценить среднюю скорость/мощность/производительность команды (сколько стори поинтов команда может выполнить за спринт) можно только постфактум, по результатам двух или более спринтов, но никак не за «один пристрелочный подход». А во-вторых, даже эти оценки будут очень приблизительными, потому что команда не существует в вакууме: сотрудники уходят в отпуск и на больничный, у них рождаются дети, они увольняются, они, в конце концов, могут столкнуться с выгоранием или разочарованием в работе — все это влияет и на состав команды, и на ее скорость. А излишне оптимистичные оценки — это новый источник стресса, и привет, причина для недовольства номер 1 (кранч и гонка за показателями).
👉 @seniorFront
На первый взгляд, гибкая разработка и сопутствующие методологии уже лет двадцать как стали новой нормой. Но если копнуть поглубже, немало инженеров и сегодня считают, что появление в компании консультантов по Scrum — повод срочно обновить резюме. Разбираемся, за что не любят спринты, кто виноват и можно ли с этим что-то сделать.
Четыре причины недовольства
1 — Гонка за показателями. Классический спринт дробит процесс разработки на двухнедельные промежутки, в течение которых команда постепенно движется к цели. В теории тикеты в пределах одного спринта должны закрываться равномерно, но на практике бывает иначе. Некоторые разработчики отмечают, что в конце спринта часто начинается кранч — гонка за выполнением задач. Чтобы уложиться в сроки, команда помечает тикеты как завершенные, даже если осталось доделать еще 5% работы, а все недоделки перетекают в новые задачи. Еще хуже, когда команда применяет хаки и костыли, чтобы уложиться в срок, жертвуя качеством.
2 — Бюрократия. Также все чаще звучат мнения о том, что гибкие методологии приводят к микроменеджменту. Да, планирование, ретроспективы, стендапы — все это неотъемлемые составляющие каждого спринта, которые призваны помочь команде координировать усилия. К сожалению, как и в случае со многими другими разумными инициативами, их можно довести до абсурда — особенно, если команда обрастает менеджерами, с излишним рвением следующими букве фреймворка. В итоге программисты вместо реализации новых фич занимаются бюрократией: ресурсы уходят на отчёты и обсуждения.
3 — Проблемы междисциплинарности и потеря фокуса. Scrum-гайд отмечает, что в спринтах участвует команда, состоящая из скрам-мастера (одна штука), владельца продукта (одна штука) и разработчиков. Иных ролей в «каноничном» Scrum нет. На практике компании пытаются дооснастить команду не только менеджерами, но и другими специалистами (аналитиками, тестировщиками, юзабилистами), которые, с одной стороны, тоже должны принимать участие в процессе разработки, а с другой — с трудом втискиваются в прокрустово ложе фреймворка.
4 — Субъективная оценка производительности. Один из краеугольных камней, который появляется в каждом первом материале с критикой Scrum — сложности в оценке того, какой объем работы команда может реализовать за спринт. Вне зависимости от того, происходит оценка в человекочасах или стори пойнтах, точно спланировать объем работы, который не будет ни чрезмерным, ни недостаточным, крайне затруднительно.
И российские, и зарубежные специалисты при этом сходятся в одном: во-первых, оценить среднюю скорость/мощность/производительность команды (сколько стори поинтов команда может выполнить за спринт) можно только постфактум, по результатам двух или более спринтов, но никак не за «один пристрелочный подход». А во-вторых, даже эти оценки будут очень приблизительными, потому что команда не существует в вакууме: сотрудники уходят в отпуск и на больничный, у них рождаются дети, они увольняются, они, в конце концов, могут столкнуться с выгоранием или разочарованием в работе — все это влияет и на состав команды, и на ее скорость. А излишне оптимистичные оценки — это новый источник стресса, и привет, причина для недовольства номер 1 (кранч и гонка за показателями).
👉 @seniorFront
👍3
Как писать документацию, которую полюбят: 15 must-read книг (и не только)
Техническая документация — это не просто набор инструкций, а мощный инструмент, который делает продукт понятным, удобным и, в конечном счете, успешным. Но чтобы создавать такие материалы, одного знания инструментов мало — нужно понимать, как ясно излагать мысли, структурировать информацию и говорить с аудиторией на одном языке. Поговорим о книгах, которые помогут научиться писать такую документацию.
👉 @seniorFront
Техническая документация — это не просто набор инструкций, а мощный инструмент, который делает продукт понятным, удобным и, в конечном счете, успешным. Но чтобы создавать такие материалы, одного знания инструментов мало — нужно понимать, как ясно излагать мысли, структурировать информацию и говорить с аудиторией на одном языке. Поговорим о книгах, которые помогут научиться писать такую документацию.
👉 @seniorFront
👍7
This media is not supported in your browser
VIEW IN TELEGRAM
page flip
Создано и стилизовано на HTML и CSS. При нажатии изменяются CSS классы через JS.
👉 @seniorFront
Создано и стилизовано на HTML и CSS. При нажатии изменяются CSS классы через JS.
👉 @seniorFront
❤6👍5
This media is not supported in your browser
VIEW IN TELEGRAM
Dynamic Image Colorizing
Реализовано без использования JS. Вся сцена - это стилизованный input type="color".
👉 @seniorFront
Реализовано без использования JS. Вся сцена - это стилизованный input type="color".
👉 @seniorFront
👍16🔥4
Какое свойство чистых функций делает pipe более предсказуемым?
Anonymous Quiz
10%
Они всегда возвращают null.
4%
Они изменяют глобальное состояние программы.
77%
Они не изменяют исходные данные и возвращают новый результат.
9%
Они выполняются только один раз.
This media is not supported in your browser
VIEW IN TELEGRAM
Pure CSS diagonal scroll reveal
Слайдер, реализованный без JS, при помощи возможностей препроцессоров Pug и SCSS.
👉 @seniorFront
Слайдер, реализованный без JS, при помощи возможностей препроцессоров Pug и SCSS.
👉 @seniorFront
👍3
Stop gninnipS My sdroW!
Создайте функцию, которая принимает строку из одного или нескольких слов и возвращает ту же строку, но с перевернутыми буквами в словах, которые состоят из пяти или более букв. Передаваемые строки будут состоять только из букв и пробелов
Пример:
👉 @seniorFront
Создайте функцию, которая принимает строку из одного или нескольких слов и возвращает ту же строку, но с перевернутыми буквами в словах, которые состоят из пяти или более букв. Передаваемые строки будут состоять только из букв и пробелов
Пример:
spinWords("Hey fellow warriors") // "Hey wollef sroirraw"
spinWords("This is a test") // "This is a test"
spinWords("This is another test") // "This is rehtona test"👉 @seniorFront
Собеседование Яндекса, как обряд инициации: для чего нужны такие собеседования
Без всяких сомнений, в IT-отрасли РФ не так много людей, кто не был бы знаком с особенностями найма в Яндекс. Некоторые считают, что этот процесс имеет чёткую цель отбора наиболее сильных программистов, другие же шутят про "-40% от рынка" и радость ночных дежурств. Но всё же, зачем нужны такие собеседования?
👉 @seniorFront
Без всяких сомнений, в IT-отрасли РФ не так много людей, кто не был бы знаком с особенностями найма в Яндекс. Некоторые считают, что этот процесс имеет чёткую цель отбора наиболее сильных программистов, другие же шутят про "-40% от рынка" и радость ночных дежурств. Но всё же, зачем нужны такие собеседования?
👉 @seniorFront
👍5👎1
Как работает свойство display в CSS?
Свойство
Основные значения свойства display:
-
-
-
-
-
-
Как работает свойство display:
- Влияет на то, как элемент взаимодействует с потоком документа (то есть, как он размещается среди других элементов) и какие CSS-свойства к нему применимы (например, ширина, высота, отступы).
- Изменение его значения может изменить поведение элемента от блочного к инлайновому и наоборот, что влияет на расположение соседних элементов и на возможность применения определённых свойств к элементу.
- Например, блочный элемент (
- Значение
👉 @seniorFront
Свойство
display является одним из ключевых свойств для управления макетом страницы. Оно определяет, как должен отображаться элемент и его потомки в документе. Оно может принимать различные значения, каждое из которых меняет поведение элемента в потоке документа, его видимость или способ взаимодействия с другими элементами.Основные значения свойства display:
-
block: Элемент отображается как блочный. Блочные элементы занимают всю доступную ширину контейнера, независимо от своего содержимого, и начинаются с новой строки.-
inline: Элемент отображается на той же строке, что и соседние элементы, и занимает только столько места, сколько необходимо для содержимого. Высота и ширина не применяются.-
inline-block: Элемент отображается как inline, но позволяет задавать ширину и высоту, как у block элементов.-
none: Элемент полностью убирается из потока документа, и его не видно на странице. Важно отличать от visibility: hidden, где элемент не виден, но занимает место в макете.-
flex: Элемент становится flex-контейнером, и его непосредственные потомки становятся flex-элементами, что позволяет использовать гибкую систему выравнивания и распределения пространства между элементами внутри контейнера.-
grid: Элемент становится grid-контейнером, и его непосредственные потомки становятся grid-элементами, что позволяет создавать сложные макеты с помощью двумерной сетки размещения элементов.Как работает свойство display:
- Влияет на то, как элемент взаимодействует с потоком документа (то есть, как он размещается среди других элементов) и какие CSS-свойства к нему применимы (например, ширина, высота, отступы).
- Изменение его значения может изменить поведение элемента от блочного к инлайновому и наоборот, что влияет на расположение соседних элементов и на возможность применения определённых свойств к элементу.
- Например, блочный элемент (
display: block;) будет пытаться занять всю доступную ширину контейнера и вытолкнет другие элементы на новую строку, в то время как инлайновый элемент (display: inline;) расположится на той же строке с другими инлайновыми или текстовыми элементами.- Значение
flex или grid превращает элемент в контейнер, который использует гибкую или сеточную модель для расположения своих потомков, соответственно, предоставляя мощные инструменты для создания адаптивных макетов.👉 @seniorFront
1❤8👍6
This media is not supported in your browser
VIEW IN TELEGRAM
Black or White
На картинку накладывается CSS filter со значением invert(1). При нажатии на переключатель запускаются CSS трансформации через JS, которые перемещают фильтр.
👉 @seniorFront
На картинку накладывается CSS filter со значением invert(1). При нажатии на переключатель запускаются CSS трансформации через JS, которые перемещают фильтр.
👉 @seniorFront
👍10
Самооценка в перфоманс-ревью: если не можешь победить ситуацию, залидируй ее
Я уверена, что самооценка - это ключевой этап и фактор успеха в процессе прохождения ревью. И от этого этапа зависит как в дальнейшем весь процесс для специалиста пройдет и насколько успешно закончится.
Почему самооценка важна?
Я много раз сталкивалась с непониманием зачем вообще нужен процесс ревью в компании, почему на него необходимо тратить так много времени. Так вот несколько пунктов "за":
1. Осознание прогресса. Позволяет увидеть свой рост, сильные и слабые стороны.
2. Готовность к диалогу. Подготовленный специалист увереннее обсуждает результаты работы.
3. Аргументированная позиция. Помогает избежать субъективности при оценке со стороны руководства.
4. Развитие навыков саморефлексии. Позволяет лучше понимать свои сильные стороны и зоны роста.
Как провести самооценку, чтобы был результат?
Соберите данные по результатам работы
Для объективной оценки соберите информацию о своей работе за период:
- Задачи и проекты. Какие задачи вы выполняли, какие проекты закрыли?
- Метрики. Например, количество закрытых тикетов, время выполнения задач, влияние на бизнес (!) - многие теряют этот пункт.
- Обратная связь. Комментарии от коллег, клиентов, пользователей.
- Дополнительные достижения. Ведение внутреннего обучения, менторство, автоматизация процессов и т. д.
Оцените свои достижения
Используйте систему оценки, например:
- Что получилось хорошо? Какие задачи вы выполнили на высоком уровне?
- Что можно улучшить? Какие моменты вызвали трудности и почему?
- Какие навыки развиты? Как вы выросли за этот период?
Попробуйте применить фреймворк STAR (Situation, Task, Action, Result) для описания своих достижений. Это поможет сделать аргументацию конкретной.
Визуализируйте результаты
Для наглядности можно использовать:
- Таблицы (с проектами, сроками, результатами).
- Графики (например, динамику выполненных задач).
- Примеры кода, демо или презентации.
- Отзывы коллег - можно сгруппировать по важным фокусам
Выделите на этот этап больше времени, не 1-2 дня, дайте себе возможность поработать с этим этапом как минимум неделю, чтобы несколько раз вернуться к задаче.
Как обсудить самооценку с руководителем?
- Структурируйте разговор. Начните с главного: ключевые достижения, влияние на команду и компанию.
- Будьте открыты к обратной связи. Важно не только презентовать свою работу, но и услышать комментарии.
- Предлагайте варианты роста. Например, новые зоны ответственности, развитие в конкретных технологиях.
- Оперируйте фактами. Чем больше конкретных примеров и метрик — тем лучше.
👉 @seniorFront
Я уверена, что самооценка - это ключевой этап и фактор успеха в процессе прохождения ревью. И от этого этапа зависит как в дальнейшем весь процесс для специалиста пройдет и насколько успешно закончится.
Почему самооценка важна?
Я много раз сталкивалась с непониманием зачем вообще нужен процесс ревью в компании, почему на него необходимо тратить так много времени. Так вот несколько пунктов "за":
1. Осознание прогресса. Позволяет увидеть свой рост, сильные и слабые стороны.
2. Готовность к диалогу. Подготовленный специалист увереннее обсуждает результаты работы.
3. Аргументированная позиция. Помогает избежать субъективности при оценке со стороны руководства.
4. Развитие навыков саморефлексии. Позволяет лучше понимать свои сильные стороны и зоны роста.
Как провести самооценку, чтобы был результат?
Соберите данные по результатам работы
Для объективной оценки соберите информацию о своей работе за период:
- Задачи и проекты. Какие задачи вы выполняли, какие проекты закрыли?
- Метрики. Например, количество закрытых тикетов, время выполнения задач, влияние на бизнес (!) - многие теряют этот пункт.
- Обратная связь. Комментарии от коллег, клиентов, пользователей.
- Дополнительные достижения. Ведение внутреннего обучения, менторство, автоматизация процессов и т. д.
Оцените свои достижения
Используйте систему оценки, например:
- Что получилось хорошо? Какие задачи вы выполнили на высоком уровне?
- Что можно улучшить? Какие моменты вызвали трудности и почему?
- Какие навыки развиты? Как вы выросли за этот период?
Попробуйте применить фреймворк STAR (Situation, Task, Action, Result) для описания своих достижений. Это поможет сделать аргументацию конкретной.
Визуализируйте результаты
Для наглядности можно использовать:
- Таблицы (с проектами, сроками, результатами).
- Графики (например, динамику выполненных задач).
- Примеры кода, демо или презентации.
- Отзывы коллег - можно сгруппировать по важным фокусам
Выделите на этот этап больше времени, не 1-2 дня, дайте себе возможность поработать с этим этапом как минимум неделю, чтобы несколько раз вернуться к задаче.
Как обсудить самооценку с руководителем?
- Структурируйте разговор. Начните с главного: ключевые достижения, влияние на команду и компанию.
- Будьте открыты к обратной связи. Важно не только презентовать свою работу, но и услышать комментарии.
- Предлагайте варианты роста. Например, новые зоны ответственности, развитие в конкретных технологиях.
- Оперируйте фактами. Чем больше конкретных примеров и метрик — тем лучше.
👉 @seniorFront
👍5
Про найм, собесы и объемное видение
Давайте поговорим про найм. Я даже не представляю, сколько сотен человек я собеседовала за свою карьеру. Несколько сотен? Больше тысячи? Понятия не имею. С какого-то момента просто перестаешь считать.
И да, статья навеяна тем, что сейчас я снова участвую в найме...
И кого я только не собеседовала: аналитиков, тестировщиков, разработчиков (бэк и фронт), дизайнеров, менеджеров, лидов, техписов, различных руководителей отделов. В общем, список длинный. И знаете, что каждый раз удивляет?
👉 @seniorFront
Давайте поговорим про найм. Я даже не представляю, сколько сотен человек я собеседовала за свою карьеру. Несколько сотен? Больше тысячи? Понятия не имею. С какого-то момента просто перестаешь считать.
И да, статья навеяна тем, что сейчас я снова участвую в найме...
И кого я только не собеседовала: аналитиков, тестировщиков, разработчиков (бэк и фронт), дизайнеров, менеджеров, лидов, техписов, различных руководителей отделов. В общем, список длинный. И знаете, что каждый раз удивляет?
👉 @seniorFront
👎3