Разница между HTTP/1.1 и HTTP/2
В отличие от HTTP/1.1, в котором все запросы и ответы хранятся в простом текстовом формате, HTTP/2 использует двоичный уровень кадрирования для инкапсуляции всех сообщений в двоичном формате, при этом сохраняя семантику HTTP (методы, заголовки).
API прикладного уровня по-прежнему создает сообщения в обычных форматах HTTP, но нижележащий уровень преобразовывает эти сообщения в двоичные. Благодаря этому веб-приложения, созданные до HTTP/2, могут продолжать работать как обычно при взаимодействии с новым протоколом.
Преобразование сообщений в двоичные позволяет HTTP/2 применять новые подходы к доставке данных, недоступные в HTTP/1.1.
👉 @seniorFront
В отличие от HTTP/1.1, в котором все запросы и ответы хранятся в простом текстовом формате, HTTP/2 использует двоичный уровень кадрирования для инкапсуляции всех сообщений в двоичном формате, при этом сохраняя семантику HTTP (методы, заголовки).
API прикладного уровня по-прежнему создает сообщения в обычных форматах HTTP, но нижележащий уровень преобразовывает эти сообщения в двоичные. Благодаря этому веб-приложения, созданные до HTTP/2, могут продолжать работать как обычно при взаимодействии с новым протоколом.
Преобразование сообщений в двоичные позволяет HTTP/2 применять новые подходы к доставке данных, недоступные в HTTP/1.1.
👉 @seniorFront
👏11👍8🔥5❤4👎1
♥️ Все наши каналы по JS / PHP / Python, подпишись ♥️
@python_practics - всё про Python, обучающие материалы, полезные советы и статьи
@frontendInterview - подготовка к собеседованиям по фронтенду
@web_craft - php, Laravel, фронтенд
@sWebDev - обзор библиотек JS / CSS
@python_practics - всё про Python, обучающие материалы, полезные советы и статьи
@frontendInterview - подготовка к собеседованиям по фронтенду
@web_craft - php, Laravel, фронтенд
@sWebDev - обзор библиотек JS / CSS
❤7👍4👎1
Senior Frontend - javascript, html, css pinned «♥️ Все наши каналы по JS / PHP / Python, подпишись ♥️ @python_practics - всё про Python, обучающие материалы, полезные советы и статьи @frontendInterview - подготовка к собеседованиям по фронтенду @web_craft - php, Laravel, фронтенд @sWebDev - обзор библиотек…»
This media is not supported in your browser
VIEW IN TELEGRAM
SVG Menu Toggle
Внутри кнопки находится SVG картинка, стилизованная и анимированная в CSS.
👉 @seniorFront
Внутри кнопки находится SVG картинка, стилизованная и анимированная в CSS.
👉 @seniorFront
🔥12👍5❤3😁2
ТОП самых раздражающих факторов для программиста
Комментарии, которые объясняют "как", но не объясняют "зачем"
Еще в институте, на курсе программирования, нас учили что код необходимо комментировать, и максимально полно. Всегда лучше иметь слишком много комментариев, чем слишком мало. К сожалению, данная рекомендация иногда перерастает совсем уж в паранойю — программист комментирует каждую строчку кода. Например:
Отвлечение от работы
Очень мизерное количество программистов могут написать код с нуля мизинцем правой руки, одновременно разговаривая по телефону, бреясь и жуя очередной бутерброд. К сожалению, очень сложно влиться в "рабочий поток", когда ваш "поезд мыслей" пускают под откос толпа клиентов, менеджеров или коллег-программистов. Причина банальна — для работы над задачей нам необходимо держать в голове громадный объем данных, чтобы не упустить что-нибудь важное.
Изменения в проекте
На английском данная проблема звучит как Scope creep, Изменения в проекте могут превратить простую задачу в самый страшный ночной кошмар. Достаточно нескольких вполне невинных слов, внесенных в проект заказчиком, чтобы превратить задачу в кашу. Например:
Версия 1. Показать карту местности
Версия 2. Показать 3D карту местности
Версия 3. Показать 3D карту местности, по которой пользователи могут виртуально перемещаться
Менеджеры, которые ничего не смыслят в программировании
Когда менеджеры не способны понять базовые концепции работы программистов, мы получаем очередные изменения в проекте, нереалистичные дедлайны, раздражения и разочарования с обоих сторон процесса разработки. Это достаточно распространенная жалоба со стороны программистов и источник многих проблем.
Неопределенность
"Сайт не работает!". "Функционал Х работает не так как надо!". Неопределенные баг-репорты — как заноза в заднице.
Особенно, когда разозленные не-программисты на просьбу предоставить информацию по воспроизведению бага отвечают — "ты же программист! возьми просто и почини!" и не понимают что недостаточно информации, чтобы взять и починить.
Другие программисты
Программисты далеко не всегда уживаются с другими программистами. Шокирует, но это правда. Наиболее характерными раздражающими факторами являются:
- Несдержанность по отношению к оппонентам-программистам
- Непонимание того факта, что есть время обсуждения архитектуры системы и есть время для ее реализации
- Невозможность адекватной коммуникации с коллегами и заказчиком и различия в понимании терминологии
- Невозможность работать как надо и когда надо
- Безразличие к коду и, собственно, к проекту
Собственный код, 6 месяцев спустя
Вы когда-нибудь заглядывали в свой старый код? Это я написал такое??!!! Начинаешь выглядеть идиотом в собственных глазах.
Да, проблема… Но есть и хорошие новости — вы не один такой ;).
👉 @seniorFront
Комментарии, которые объясняют "как", но не объясняют "зачем"
Еще в институте, на курсе программирования, нас учили что код необходимо комментировать, и максимально полно. Всегда лучше иметь слишком много комментариев, чем слишком мало. К сожалению, данная рекомендация иногда перерастает совсем уж в паранойю — программист комментирует каждую строчку кода. Например:
$r = $n/2; // Устанавливаем $r равным $n поделенное пополам
// Цикл выполняется до тех пор пока $r - ($n/$r) больше $t
while (abs($r - ($n/$r)) > $t) {
$r = 0.5 * ($r + ($n/$r)); // Устанавливаем $r равное половине $r + ($n/$r)
}Отвлечение от работы
Очень мизерное количество программистов могут написать код с нуля мизинцем правой руки, одновременно разговаривая по телефону, бреясь и жуя очередной бутерброд. К сожалению, очень сложно влиться в "рабочий поток", когда ваш "поезд мыслей" пускают под откос толпа клиентов, менеджеров или коллег-программистов. Причина банальна — для работы над задачей нам необходимо держать в голове громадный объем данных, чтобы не упустить что-нибудь важное.
Изменения в проекте
На английском данная проблема звучит как Scope creep, Изменения в проекте могут превратить простую задачу в самый страшный ночной кошмар. Достаточно нескольких вполне невинных слов, внесенных в проект заказчиком, чтобы превратить задачу в кашу. Например:
Версия 1. Показать карту местности
Версия 2. Показать 3D карту местности
Версия 3. Показать 3D карту местности, по которой пользователи могут виртуально перемещаться
Менеджеры, которые ничего не смыслят в программировании
Когда менеджеры не способны понять базовые концепции работы программистов, мы получаем очередные изменения в проекте, нереалистичные дедлайны, раздражения и разочарования с обоих сторон процесса разработки. Это достаточно распространенная жалоба со стороны программистов и источник многих проблем.
Неопределенность
"Сайт не работает!". "Функционал Х работает не так как надо!". Неопределенные баг-репорты — как заноза в заднице.
Особенно, когда разозленные не-программисты на просьбу предоставить информацию по воспроизведению бага отвечают — "ты же программист! возьми просто и почини!" и не понимают что недостаточно информации, чтобы взять и починить.
Другие программисты
Программисты далеко не всегда уживаются с другими программистами. Шокирует, но это правда. Наиболее характерными раздражающими факторами являются:
- Несдержанность по отношению к оппонентам-программистам
- Непонимание того факта, что есть время обсуждения архитектуры системы и есть время для ее реализации
- Невозможность адекватной коммуникации с коллегами и заказчиком и различия в понимании терминологии
- Невозможность работать как надо и когда надо
- Безразличие к коду и, собственно, к проекту
Собственный код, 6 месяцев спустя
Вы когда-нибудь заглядывали в свой старый код? Это я написал такое??!!! Начинаешь выглядеть идиотом в собственных глазах.
Да, проблема… Но есть и хорошие новости — вы не один такой ;).
👉 @seniorFront
👍13❤4👏1
Media is too big
VIEW IN TELEGRAM
Active Nav Link indicator
В этом видео создаётся навигационное меню с оригинальным индикатором активного пункта на HTML, CSS и JS.
👉 @seniorFront
В этом видео создаётся навигационное меню с оригинальным индикатором активного пункта на HTML, CSS и JS.
👉 @seniorFront
👍5🔥3❤1
Предновогодний митап Frontend Night by Sber!⚡
Уже в понедельник, 11 декабря, Frontend-команда Сбера приглашает всех фронтендеров на свой заключительный митап в этом году. В программе:
✔️ Антон Непша — Senior Frontend-разработчик департамента IT-блока «Транзакционный банкинг B2C» — расскажет о том, как продать бизнесу рефакторинг и использовать простые решения для масштабных результатов.
✔️ Роман Ганин — Senior Frontend-разработчик команды «Салют В2В» — поделится секретами о важности тегов и их влиянии на работу сайтов.
✔️ Алексей Охрименко — TechLead Yandex Cloud — рассмотрит статистический анализ кода и покажет, как применить этот подход на практике.
А еще: много нетворкинга, игры и подарки.
Подключайтесь онлайн или приходите офлайн по адресу: г. Москва, ул. Маросейка, 7/8, FotoFaktura.
Важно: для участия в любом формате необходима регистрация.
Уже в понедельник, 11 декабря, Frontend-команда Сбера приглашает всех фронтендеров на свой заключительный митап в этом году. В программе:
✔️ Антон Непша — Senior Frontend-разработчик департамента IT-блока «Транзакционный банкинг B2C» — расскажет о том, как продать бизнесу рефакторинг и использовать простые решения для масштабных результатов.
✔️ Роман Ганин — Senior Frontend-разработчик команды «Салют В2В» — поделится секретами о важности тегов и их влиянии на работу сайтов.
✔️ Алексей Охрименко — TechLead Yandex Cloud — рассмотрит статистический анализ кода и покажет, как применить этот подход на практике.
А еще: много нетворкинга, игры и подарки.
Подключайтесь онлайн или приходите офлайн по адресу: г. Москва, ул. Маросейка, 7/8, FotoFaktura.
Важно: для участия в любом формате необходима регистрация.
🔥4❤2
This media is not supported in your browser
VIEW IN TELEGRAM
3D Tilting Card Effect
Логика поворота карточки реализована в JS и зависит от положения курсора пользователя.
👉 @seniorFront
Логика поворота карточки реализована в JS и зависит от положения курсора пользователя.
👉 @seniorFront
❤11👍3
Если задать этому CSS свойству отрицательное значение, то элемент сместится со своего обычного места.
Anonymous Quiz
40%
margin-right
11%
padding-bottom
39%
margin-top
10%
padding-left
🤨48👎21😐6❤4👏3👍1
Media is too big
VIEW IN TELEGRAM
Sticky Header Experiment
В этом видео создаётся "липкий" header, который перестаёт прилипать в определенной позиции. Реализовано на чистом CSS.
👉 @seniorFront
В этом видео создаётся "липкий" header, который перестаёт прилипать в определенной позиции. Реализовано на чистом CSS.
👉 @seniorFront
👍9❤2
Sum of a Beach
На пляже много песка, воды, рыбы и солнца. Создайте функцию, которая принимает строку и подсчитывает количество встречающихся слов Sand, Water, Fish и Sun.
Примеры:
👉 @seniorFront
На пляже много песка, воды, рыбы и солнца. Создайте функцию, которая принимает строку и подсчитывает количество встречающихся слов Sand, Water, Fish и Sun.
Примеры:
sumOfABeach("WAtErSlIde") ==> 1
sumOfABeach("GolDeNSanDyWateRyBeaChSuNN") ==> 3
sumOfABeach("gOfIshsunesunFiSh") ==> 4
sumOfABeach("cItYTowNcARShoW") ==> 0👉 @seniorFront
❤5
Как устроена специфичность стилей?
CSS устроен так, что одинаковые CSS-свойства с разным значением, применяемым к элементу, не могут быть применены к нему одновременно.
Например:
Какое-то из свойств должно "победить". Побеждает (имеет преимущество) свойство самого близкого по отношению к форматируемому элементу стиля. Или, правильнее выразиться, самого специфичного стиля. Вот упрощенная, но наглядная модель специфичности селекторов в условных единицах:
- Селектор тегов имеет специфичность, равную 1 условной единице.
- Класс — 10 условных единиц.
- Идентификатор — 100 условных единиц.
- Строчный стиль — 1000 условных единиц
В приведённом примере <h1> будет иметь чёрный цвет текста.
👉 @seniorFront
CSS устроен так, что одинаковые CSS-свойства с разным значением, применяемым к элементу, не могут быть применены к нему одновременно.
Например:
h1 {
color: red;
}
.h1 {
color: blue;
}
#h1 {
color: yellow;
} <h1 id="h1" class="h1" style="color: black">Header</h1>Какое-то из свойств должно "победить". Побеждает (имеет преимущество) свойство самого близкого по отношению к форматируемому элементу стиля. Или, правильнее выразиться, самого специфичного стиля. Вот упрощенная, но наглядная модель специфичности селекторов в условных единицах:
- Селектор тегов имеет специфичность, равную 1 условной единице.
- Класс — 10 условных единиц.
- Идентификатор — 100 условных единиц.
- Строчный стиль — 1000 условных единиц
В приведённом примере <h1> будет иметь чёрный цвет текста.
👉 @seniorFront
👍25😐4❤3🔥3👎1🤔1
Pet-проекты — это зло. Вредные советы для фронтендеров
Сегодняшний текст — о том, как, мне кажется, нужно и, наоборот, нельзя вести пет-проекты. Надеюсь, вы тоже любили эту книгу Григория Остера в детстве. Если вы с ней не знакомы, концепция состоит в том, что дети часто вредничают и делают всё наоборот, поэтому нужно давать им советы от противного.
Зачем вообще нужны пет-проекты, если можно просто овертаймить
Возможно, ваше желание работать сверхурочно связано с тем, что вы чувствуете себя недостаточно эффективными. Задумайтесь, влияет ли на вас всеобщий культ продуктивности.
Пробуй новые технологии вширь, а не вглубь
Изучать область вширь — это нормально и важно, если вы хотите быть конкурентоспособными. Однако развивать широту, пока у вас нет глубины, — провальная стратегия. Если вы джун или миддл фронтендер, в первую очередь стоит сделать глубокое погружение во фронтенд. И даже если вы миддл+ и уже нарастили мышцы в своих стандартных инструментах, ничто не мешает задипдайвить в свою предметную область ещё раз.
План не нужен, работай как работается
Раньше, начиная что-то делать, я не думал, какой результат хочу получить. Целью было попробовать свежеизученную технологию на абстрактной задаче, на этом всё.
Гораздо правильнее иметь роадмап.
👉 @seniorFront
Сегодняшний текст — о том, как, мне кажется, нужно и, наоборот, нельзя вести пет-проекты. Надеюсь, вы тоже любили эту книгу Григория Остера в детстве. Если вы с ней не знакомы, концепция состоит в том, что дети часто вредничают и делают всё наоборот, поэтому нужно давать им советы от противного.
Зачем вообще нужны пет-проекты, если можно просто овертаймить
Если все же вы решили
Сесть покодить внеурочно,
То пишите код в проекте,
Где работали фулл-тайм.
Возможно, ваше желание работать сверхурочно связано с тем, что вы чувствуете себя недостаточно эффективными. Задумайтесь, влияет ли на вас всеобщий культ продуктивности.
Пробуй новые технологии вширь, а не вглубь
Чтобы стать крутым синьёром,
Нужно срочно на реакте,
Ангуляре, вью и qwik-е
Вам закодить ту-ду лист.Изучать область вширь — это нормально и важно, если вы хотите быть конкурентоспособными. Однако развивать широту, пока у вас нет глубины, — провальная стратегия. Если вы джун или миддл фронтендер, в первую очередь стоит сделать глубокое погружение во фронтенд. И даже если вы миддл+ и уже нарастили мышцы в своих стандартных инструментах, ничто не мешает задипдайвить в свою предметную область ещё раз.
План не нужен, работай как работается
Знай, в своём проекте важно:
Быть художником- творить!
А роадмапы эти ваши
Мы оставим тимлидамРаньше, начиная что-то делать, я не думал, какой результат хочу получить. Целью было попробовать свежеизученную технологию на абстрактной задаче, на этом всё.
Гораздо правильнее иметь роадмап.
👉 @seniorFront
👎6👏5🤨2❤1👍1