mefody.dev – Telegram
mefody.dev
5.31K subscribers
14 photos
1 video
3 files
425 links
Доброжелюбный бородач про фронтенд, тимлидство, спикерство.
Автор — @dark_mefody

Канал про работу: @mefody_work.

Не размещаю рекламу в своём канале. Даже за деньги. Даже большие.
Download Telegram
CodeRun

Только что наша большая команда запустила бету нового сервиса для решения алгоритмических и не только задач. Если кто-то знаком с https://contest.yandex.ru/, то вы знаете, что у нас уже много лет есть платформа для проведения олимпиад и контестов. Но хотелось сделать что-то, что будет доступно не только олимпиадникам, а вообще всем. Например, полноценные задачи на вёрстку, а не только на написание кода на JavaScript.

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

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

Например, адаптивности пока нет, доступность некоторых элементов не доделана, нет OpenGraph.

Всем заранее спасибо, кто откликнется. Мы очень старались сделать хорошо, но хотим ещё лучше!

https://coderun.yandex.ru/catalog
🔥31👍92🥴1
«Давайте созвонимся на пару минут»

Вчера читал доклад у Podlodka TeamLead Crew про то, нужны ли созвоны, как их проводить более эффективно и можно ли ставить все встречи впритык, чтобы потом после них пойти поработать.

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

https://www.youtube.com/watch?v=EEGM38yA9Wo
🔥143👍2
text-wrap: balance

Сначала Адам Аргайл написал статью, про то, как это работает. Потом Ахмад Шадид добавил полезных примеров.
В общем, прямо во время записи подкаста заслал в Shower пулл-реквест, чтобы в теме Ribbon тоже автоматом рисовались красивые заголовки.

text-wrap: balance — это способ попросить браузер рисовать текст внутри какого-то контейнера до 4 строчек сбалансированно. Например, если у вас на сайте есть длинные заголовки, в которых постоянно в последней строчке висячее слово остаётся, то браузер постарается сделать все строчки приблизительно одной длины, что по меркам типографики красиво и правильно.

Это свойство пока работает только в Chrome Canary за флагом, но как только оно начнёт работать в стабильном браузере, у вас просто станет красиво сразу. Поэтому есть смысл показать свойство дизайнерам уже сейчас, добавить его в правильных местах (см. статью Ахмада, очень хорошие примеры на мой субъективный взгляд) и уже выкатить в прод. Люблю CSS за то, что он не ломается, когда не знает какое-то свойство.

https://ishadeed.com/article/css-text-wrap-balance/
https://developer.chrome.com/blog/css-text-wrap-balance/
👍18👌72
Новые_возможности_CSS_Никита_Дубко.pdf
30.7 MB
Новые возможности CSS, которые меняют взгляд на вёрстку

Вчера читал доклад на конференции DUMP про то, что наши страхи использовать новые фичи в CSS во многом обусловлены «детской травмой» веб-мастеров 2000-ых, что любое новое свойство скорее всего работает всего в одном браузере, а в остальных либо кое-как, либо никак. А на самом деле благодаря инициативе Interop многие фичи появляются чуть ли ни одновременно в вечнозелёных браузерах (вот бы ещё Safari подтянули релизный цикл хотя бы до обновления в пару месяцев).

Заодно поделился CSS-свойствами, которые нашёл крайне интересными за последние полгода.

Приятно, доклад зрители оценили как лучший во фронтенд-секции. Значит, много у кого болело. Постараюсь поделиться с вами видео выступления, когда оно появится в сети. А слайдами делюсь уже сейчас.
👍44🔥187❤‍🔥4😱1🥴1
Переопределение заголовков ответа для дебага

В Chrome 113 Dev Tools появилась, на мой взгляд, потрясающая фича, которая сильно ускорит параллельную разработку фронтенда и бэкенда в некоторых конкретных случаях.

Представьте, что у вас есть какая-то функциональность на сайте, которая зависит от HTTP-заголовков ответа сервера. Да даже представлять особо не надо, она точно есть: кэширование, куки, CORS, CSP, скачивание файлов, редиректы и разное другое. И вот в какой-то момент эту функциональность нужно доработать новыми заголовками, но на бэкенде доработка требует 2 дня разработки, тестирование и деплой, а на фронтенде — пары часов небольших правок с тестированием. Что можно сделать, чтобы не стопорить фронтенд в таком случае:

1. Сделать заглушку на бэкенде, которая топорно возвращает нужные заголовки по параметрам в URL. Плохой вариант, потому что отвлекается бэкендер, который мог бы уже фичу начать делать. И всё равно нужно ждать деплой.

2. Настроить фронтендеру что-то проксирующее, вроде Charles, научить подменять конкретные заголовки на уровне сети. Уже лучше, но джуну, который только-только освоил вёрстку и какой-нибудь фреймворк, объяснять, как сниффить трафик, кажется оверинжинирингом. К тому же не на всех корпоративных машинках можно ставить сторонние прокси.

3. Воспользоваться новой фичей Chrome Dev Tools! (как будто в телемагазине вещаю, простите)

В чём суть фичи:
- В открытых Dev Tools во вкладке Network > Headers > Response Headers теперь можно редактировать заголовки ответа сервера. Или добавить новые.
- Во вкладке Sources > Overrides можно найти домен, на котором экспериментируете с заголовками, и отредактировать там файл .headers, внутри которого можно задать переопределения не конкретному ответу, а вообще всем ответам.

А ещё обязательно покажите эту фичу вашему QA, чтобы ему было ещё удобнее ломать тестировать подобные кейсы без страданий.

https://developer.chrome.com/blog/new-in-devtools-113/#network
🔥28👍7🤯3🥴1
D&D Tokenizer

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

За выходные собрал приложение для рисования токенов персонажей в настольных играх. По названию можно понять, что фокус сделал на D&D. Мы с друзьями привыкли, что у всех NPC и у наших игровых альтер-эго есть красивые картинки, а рамка — часть этого впечатления. Делал для себя, но почему бы не поделиться со всеми.

Разумеется, буду приложение дорабатывать постепенно, там есть над чем работать. Но PWA на вкус попробовал — очень нравится.

Исходники: https://github.com/MeFoDy/dnd-tokenizer
Сам проект: https://dnd-tokenizer-41471e.netlify.app/
🔥38🤔1
Одно PWA, чтобы править всеми

Вчера на HolyJS читал доклад про то самое приложение для генерации картинок-токенов, про которое писал выше. Цель доклада в том, чтобы убедить разработчиков, что PWA вполне себе могут заменить нативные приложения в каких-то случаях. Не во всех, это точно, но во многих. На самом деле не так уж и часто нативные приложения нуждаются в каких-то редких низкоуровневых API, при этом под капотом часто у них WebView, из которого уже можно сделать PWA меньшими усилиями.

Самую большую дискуссию вызвал вопрос безопасности PWA: «Можно ли написать что-то банковское и безопасное фронтенд-инструментами?» На мой взгляд, здесь между нативным и PWA разница очень маленькая:

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

— Любой клиент, как фронтенд, так и нативный, не должен содержать в себе какой-то сложной логики по безопасности. Клиент — это вьюшка, которой должен управлять бэкенд. И именно бэкенд должен давать или не давать доступ к тем или иным действиям на сайте.

— На фронтенде есть множество решений про то, как готовить приложения безопасно. Это требует погружения в область, изучения новых знаний, но на самом деле опыт поколений там колоссальный, вам вряд ли придётся придумывать что-то уникальное.

— Банковские приложения внезапно начали писать на PWA. А у банков аудиты безопасности обычно очень даже серьёзные.

Дискуссия интересная, на конференциях явно нужен доклад про безопасность в PWA, будет полезно.

Видео доклада пока нет, но слайдами уже могу поделиться: https://mefody.github.io/talks/pwa-2023/
👍26🔥63
MinskJS #10

Кто давно со мной знаком, знают, что когда-то я был в составе организаторов минских сообществ MinskJS и MinskCSS. У нас были крутые оффлайн-митапы с трансляциями, полные залы на площадке Space в Минске.

Недавно вернулся в мои любимые сообщества, помогаю Саше Шинкевич и Глаше Жур делать классные онлайн-митапы: искать спикеров, прогонять доклады, делать минский движ ярче. MinskCSS #10 вообще транслировали из моей квартиры.

Завтра (31 мая) в 19:00 у нас как раз состоится онлайн-митап MinskJS #10, где поговорим про путь браузера от ввода урла в адресную строку до отрендеренной страницы, «толстые клиенты» и расширение круга знакомств в индустрии, если ты интроверт. Всех приглашаю, заваривайте пельмешки, зовите коллег и задавайте вопросы в чате. Увидимся!

https://minskjs.timepad.ru/event/2406669/
🔥30👍6🥴1
Стратегия оптимизации перфоманса веб-страницы

Давно хотел собрать чеклист, по которому можно проходить при аудите перфоманса веб-приложений. Разумеется, магистр чеклистоведения Виталий Фридман сделал это раньше и с большим количеством ссылок.

Шаг 0. Настройте инструменты, измерьте текущее состояние страницы.
Шаг 1. Правильно поместите всё самое важное внутрь <head>.
Шаг 2. Настройте загрузку критического CSS.
Шаг 3. Поиграйтесь со шрифтами.
Шаг 4. Позаботьтесь о метрике LCP.
Шаг 5. Разберитесь с загрузкой JavaScript.

https://smashed.by/perf-strategy
👏13👍8🔥32
Sunday CSS

У Юли Миоцен на канале раз в неделю выходят ролики о том, как при помощи CSS рисовать. Не верстать страницы, а именно рисовать. Кинематографичные анимации, иллюстрации, псевдо-3D псевдоигры. Юля объясняет и показывает, из чего состоят такие иллюстрации и как из одного HTML-элемента на странице извлечь максимум пользы на «холсте».

Вдохновиться готовыми демками Юли можно здесь: https://codepen.io/miocene

https://youtube.com/playlist?list=PLbNASFXzvzeaS5ELuPN4imYOuETjxX_x_
🔥26🤩1
Приложил руку к большому числу заданий. Приходите ломать.
🔥8👏5
Forwarded from UfoStation
Анонс Frontend CTF 2023

На канале была небольшая пауза, потому что мы с ребятами готовили Frontend CTF 2023 — игровой фронтендерский турнир с элементами взлома

Запуск квеста состоится завтра 14 июня в 19:00

😎
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥103💯2
Техника появления из жёлтого

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

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

Сейчас всё ещё нужно делать так же, но скоро появится новый способ делать это исключительно средствами CSS. У Брамуса есть хороший пример, с которым всё становится понятнее.


div {
transition: background-color 0.5s;
background-color: transparent;

@starting-style {
background-color: yellow;
}
}


В этом примере сначала у дива будет жёлтый фон, потом за 0.5 секунды он станет прозрачным. Никакого JavaScript, исключительно магия CSS.

Пока что эта возможность доступна только пользователям Chrome Canary 115+ с включёнными экспериментальными флагами веб-платформы. Правило настолько свежее, что caniuse про него просто не знает, а в спецификации CSS Transitions даже в черновике пока про такую возможность ещё ничего не написано. Но раз Chrome потихоньку внедряет, скоро появится и спецификация.

https://www.bram.us/2023/05/24/the-yellow-fade-technique-with-modern-css-using-starting-style/
👍21🔥81
👍12🔥4
AI Explain: postmortem

Если вы вдруг пропустили, в MDN произошёл интересный случай с тем, как chatGPT внедрили в документацию, а через два дня его выключили.

27 июня появился анонс новой функции AI Help — эдакого помощника для подписчиков MDN Plus, в котором можно было спросить chatGPT 3.5 про всякое вроде «как центрировать div по вертикали», «как наложить маску на картинку» и так далее. Команда, на самом деле, проделала хорошую работу, чтобы обучить модель контексту: скормили модельке статьи на MDN, которые вышле после 2021 года (ограничение модели 3.5), протестировали, даже автотестами покрыли.

Рядом с этой функцией появился AI Explain — возможность попросить AI объяснить какой-то код на странице. В статьях на MDN часто есть сниппеты кода с примерами, но в них помимо объясняемого в статье свойства бывают и другие сложные для восприятия новичками особенности. Цель инструмента, как говорит команда MDN, была как раз в помощи новичкам.

30 июня на гитхабе появилось ишью про то, что MDN теперь врёт пользователям автоматизированно. Комьюнити собрало много примеров, где AI не просто не справлялся с задачей, но ещё и выдавал ложные сведения. Мы в подкасте тоже обсуждали этот инцидент, можете послушать, если хотите подробностей. В ишью выяснилось, что фичу катнули в принципе мимо согласования с MDN Core Team. И тем самым сильно подорвали доверие к MDN как источнику корректной технической информации.

1 июля AI Explain выключили для всех пользователей сайта.

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

Мораль:
- Применяйте AI осторожно. Он может помогать в вашей работе, но всё ещё не гарантирует валидности выдаваемой информации.
- Продумывайте UX. Если бы где-то на сайте была огромная плашка «Это ответ AI, он может врать, проверяйте за ботом», комьюнити, возможно, не так сильно бы и злилось.
- Не тащите AI бездумно в проект, лишь бы усидеть на паровозике хайпа.

https://developer.mozilla.org/en-US/blog/ai-explain-postmortem/
👍37🤔1
Доклады JS Nation 2023

Конференция JS Nation опубликовала записи докладов 2023 года. Там есть про перфоманс, доступность, веб-компоненты, TypeScript. Много крутых экспертов. Добавляйте в закладки, чтобы посмотреть на досуге, пока ваш проект собирается.

Себе в закладки добавил:
- доклад Вани Акулова про то, как некоторые общие советы по загрузке веб-приложений в конкретных случаях скорее вредят, чем помогают;
- доклад Максима Сальникова про веб-пуши — с их появлением в Safari тема как никогда актуальная;
- доклад Зака Лезермана про веб-компоненты — интересно посмотреть, как он их реализует совместимо с 11ty, который очень хорош по перфомансу из коробки.

https://portal.gitnation.org/events/jsnation-2023/talks
❤‍🔥20👍3
Better full screen mode with the Keyboard Lock API

Томас Штайнер делится хорошим примером, когда можно сделать пользовательский опыт лучше очень коротким сниппетом кода. Представьте, что вы открылы браузер в fullscreen-режиме, открыли модалку на сайте, пытаетесь её закрыть при помощи Esc — что произойдёт? Правильно, браузер выйдет из fullscreen-режима, потому что в ОС по умолчанию так сделано. Я на macOS постоянно из-за этого страдаю.

Так вот, есть Keyboard Lock API, который позволяет заблокировать какие-то кнопки или вообще все. В случае с Escape нужно будет не нажать кнопку, а зажать, чтобы выйти из fullscreen-режима.


// блокируем
await navigator.keyboard.lock(['Escape']);
// разблокируем
navigator.keyboard.unlock();


Я периодически пользуюсь веб-приложениями, которые для моего лучшего пользовательского опыта на любое нажатие клавиши на клавиатуре пытается что-нибудь сделать. Не через Alt+F, например, а через просто F, K, S и так далее. Беда в том, что я никогда этими шорткатами не пользуюсь, они мне не нужны, но в настройках выключить не могу. Если бы были нужны, то лучше через какие-то комбинации клавиш. И вот заполняю я форму на этом сайте, нечаянно фокус не выставил, начал набирать текст — а сайт в этом время заполнил форму, завёл тикет в саппорт, приготовил глазунью и включил тёмную тему. Теперь могу сделать себе через браузерные расширения или закладки отключение этой ненужной мне функции.

Эта апишка работает только в Chromium-браузерах, но довольно давно. Как прогрессивное улучшение — почему бы и не да.

https://developer.chrome.com/blog/better-full-screen-mode/
👍115
Браузер Arc

Свершилось. Сегодня браузер Arc вышел в версии v1.0 и отключил лист ожидания. Это значит, что его может установить каждый без инвайт-кодов.

Я им пользуюсь уже давно, хоть и не постоянно. Основные фичи, которые мне нравятся:
- Сплит-вью. Можно разместить вкладки в одном окне рядом. Незаменимая фича для подготовки докладов.
- Всё на комбинациях клавиш. К тачпаду тянусь довольно редко, причём комбинации можно переназначать под себя.
- Пользовательские стили. Раньше в такое умели все браузеры, а теперь как будто только в Arc это осталось без расширений. В твиттере у меня всё ещё птичка в качестве лого :)
- Разделение на пространства. Завёл себе группу вкладок для записи подкастов, для игр в D&D и для подготовки докладов.
- Вкладки закрываются сами, если не открывать их в течение суток.
- Список вкладок — горизонтальный список, а не табики. Просто нравится, экран ведь широкий.
- По умолчанию можно скрыть весь интерфейс. Больше от сайтов ничего не отвлекает.
- Режим превью. Любую ссылку можно открыть в окне предпросмотра, и если уже надо, то тогда открыть как полноценную вкладку.

Ничего лишнего. Настраиваемое. Удобное. Попробуйте.

Да, работу работаю я всё ещё в Chrome. Потому что там удобнее с инструментами разработчика играться. Но пользоваться интернетом пока приятнее в Arc. Плюс у них классная работа с сообществом, на мои багрепорты отвечали очень быстро. В общем, хорошо, когда на рынке появляется что-то новое, пусть под капотом там всё тот же Chromium.

https://arc.net/
🔥33😐10👍4
Стилизуй свой RSS

Дэрек Кэй предлагает интересное. Если у вас есть блог, или вы делаете новостной сайт, или сайт с какой-то обновляемой базой знаний, то скорее всего вы уже прикрутили RSS-ленту. Я, например, RSS пользуюсь постоянно, подписан много на кого через Feedly.

И вот пользователь переходит по прямой ссылке на RSS-ленту. Скорее всего он увидит месиво из XML-тегов и их содержимого. Казалось бы, ну и ладно, это же для автоматики страница, а не для людей.

Но у нас ведь есть древний способ стилизовать XML-документы — XSLT. В прошедшем недавно ЯЛФ CTF как раз было задание, где нужно было в XML-документе поиграться со стилями и получить нужный для ответа флаг.

Как это работает:
1. Вы заводите XML-документ с данными. RSS — это подмножество XML.
2. К нему прикрепляете XSL-стили. <?xml-stylesheet href="/rss.xsl" type="text/xsl"?>.
3. Внутри XSL описываете шаблон представления данных. По сути — HTML с дополнительными возможностями шаблонизации, среди которых циклы, фильтрация, работа с «объектами», условия и прочее.
4. Туда же добавляете обычные CSS-стили, потому что уже есть привычный HTML-шаблон с тегами и классами, если нужно.
5. Если в RSS-ленту зайдёт робот, он не будет ничего делать со стилями и просто распарсит вашу ленту, как ему надо. То есть ничего не меняется.
6. Если зайдёт по прямой ссылке реальный пользователь, он увидит красивую ленту в стиле вашего сайта. Можно, например, приделать инструкцию, как подписаться на эту ленту.

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

https://darekkay.com/blog/rss-styling/
👍11🤯8🤔3🤩1
О порядке применения трансформаций

София Валитова проверила по спецификации, в каком порядке применяются CSS-свойства transform, transform-origin, translate, rotate и scale, и на примерах показывает, чем задание индивидуальных свойств отличается от задания частей свойства transform.

Напомню, теперь во всех основных браузерах есть индивидуальные свойства трансформации, то есть вместо transform: scale(1.2) можно писать scale: 1.2. Помню, в чатике Веб-стандартов была заруба, что чаще всего нет разницы, как писать эти трансформации, потому что редко мы используем сложные трансформации, где подряд несколько translate, например. А я недавно как раз наткнулся на такой случай, где трансформации из библиотеки мешали трансформациям из дизайн-системы. В общем, однозначно полезная заметка от Софии, которая поможет не путаться.

Кстати, у Софии есть свой канал, где она делится похожими находками из мира CSS, подписывайтесь: https://news.1rj.ru/str/css_mind.

https://ru.ariarzer.dev/2023/notes/transformation_order/index.html
11👍3🔥3😍1