Как GitHub сделали глобус на главной

Интересная статья про создание такой необычной главной страницы сервиса

github.blog/2020-12-21-how-we-built-the-github-globe/

Семантическая разметка HTML

Еще в HTML4 можно было создавать сайты с удобной для пользователя разметкой. Но она была удобной только для отображения, для иных манипуляций, таких как поисковая индексация или же подготовка контента для людей с ограниченными возможностями, это были безликие и однообразные блоки. Потому в HTML5 было решено ввести некоторые семантические теги, такие как header, footer, aside, article, section и др.
Семантические теги несут определенную смысловую нагрузку:
nav должен содержать блок навигации
header и footer говорят сами за себя
aside дополнительный контент
article основной контент на странице
section логические блоки контента

Легко запутаться когда использовать section а когда article. Есть простое правило: section формирует часть чего-то ещё, а article это что-то, что само по себе.
aside не обязательно должен находиться сбоку от основного контента, это могут быть, например, связанные ссылки.

medium.com/@stasonmars/semantic-html-c7cd5e6f1ebb

Emoji в JavaScript... это сложно!

Создатели unicode проделали огромную работу, он позволяет закодировать более миллиона кодовых позиций, хотя на данный момент занято всего 143 859 из них. Однако, по факту, unicode позволяет представить значительно больше символов за счет использования комбинируемых символов, которые могут быть обрамляющими, интервальными, безинтервальными и селекторами варианта начертания.
Это значит что для одного отображаемого символа может потребоваться использование нескольких кодовых позиций.
В случае emoji все еще сложнее т.к. они могут набираться из нескольких более простых emoji. Дополнительно это усложняется особенностью представлением JS строк: для кодирования некоторых кодовых позиций может потребоваться несколько символов JS строки, например: "😀".length вернет 2.
Все это может сильно усложнить обработку emoji, в частности их парсинг, что и раскрывается в сегодняшней статье.

thekevinscott.com/emojis-in-javascript/
#unicode #js

9 тяжёлых уроков, которые я усвоил за 18 лет разработки

1️⃣ Оставьте эго за дверью
2️⃣ Языки — это инструмент
С опытом понимаешь что у программирования одинаковая суть вне зависимости от языка.
Знание различных языков позволяет шире взглянуть на всю разработку
3️⃣ Дело не в запоминании алгоритмов, а в их поиске
Знать все нереально, зачастую достаточно знать как правильнее загуглить
4️⃣ Вы будете учиться всю свою карьеру
5️⃣ Работающее лучше идеального
6️⃣ Заставьте код работать, затем оптимизируйте
Однако это не значит что стоит лепить костыли направо и налево, архитектуру нужно делать хорошо сразу, потому как исправлять архитектуру слишком дорого
7️⃣ Последние 10 % проекта занимают 90 % времени
8️⃣ Когда вы в команде, нужна абстракция
Как и во всем - нужна мера. Основной критерий - легкость понимания кода
9️⃣ Сторонние проекты не обязательны, но могут помочь

m.habr.com/ru/post/533372/

Ошибочное понимание принципа DRY

Don't repeat yourself
Звучит просто. Или нет?
Стремление к избеганию дублирования кода может привести к его сильно связанности и нечитаемости - совершенно обратный эффект вместо ожидаемого.
Это происходит потому что принцип DRY имеет смысл применять прежде всего для бизнес логики - бизнес логика должна быть описана только в одном месте.

Также полезным оказалось правило трех повторений:
1. Пишешь новую функциональность — делай частное решение
2. Столкнулся с этой же проблемой второй раз — скопирую код, модифицируй чтобы работал для этого случая и пометь на будущее
3. Встретился с проблемой в третий раз — обобщай
Посыл был в том, что чтобы сделать более-менее хорошее обобщенное решение нужно понимание как это может использоваться. Имея только один вариант можно сделать слишком частное решение и его потом все равно придется модифицировать.
Подтверждение этой мысли я встречался и в своем коде и в коде коллег. Чаще было, что код излишне обобщен.

habr.com/ru/post/349978/
#theory

JS по условию: загружаем скрипты только если они удовлетворяют условиям

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

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

Так же браузер предоставляет возможность узнать часть этой информации не только через JavaScript непосредственно на клиенте, но и на сервере. Для этого достаточно всего лишь добавить соответствующий meta тег, а сама информация будет передана в заголовке запроса.

К сожалению, у разных браузеров набор доступных данных отличается и не все из них могут быть отправлены в заголовках. Так, из Firefox было удалено Battery Status API, т.к. это могло быть использовано в fingerprint.

umaar.com/dev-tips/242-considerate-javascript/
#browser

Паттерн PRPL для создания отзывчивых веб приложений

Этот паттерн описывает структурирование и доставку веб приложений. Название - аббревиатура ключевых этапов загрузки приложения:
1️⃣ Push загрузка ресурсов, притом только тех ресурсов, которые нужны именно этой странице.
Здесь отлично подойдет SSR.
2️⃣ Render инициализация полноценного приложения.
3️⃣ Pre-cache фоновая загрузка и кеширование часто используемых ресурсов.
Для этого отлично подходит Service Worker.
4️⃣ Lazy-load загрузка редко используемых модулей при обращении к ним.

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

addyosmani.com/blog/the-prpl-pattern/
#theory #patterns #ssr

Масштабируемая конфигурация nginx

Игорь Сысоев рассказывает как работают конфиги nginx и как написать конфигурацию, что бы она была удобна, масштабируема и легка в поддержке.

youtu.be/jf3wIN-FwW4
#nginx

TypeScript: почему интерфейсы предпочтительнее

Как-то Роб Палмер написал в твитере:
Вчера я уменьшил .d.ts файлы на проекте с 700Kb до 7Kb изменив всего одну строчку кода
Дело в том, что в ряде случаев яльяс типа будет заменен на его значение, в отличии от интерфейсов, которые всегда используются только по имени.

ncjamieson.com/prefer-interfaces
#typescript

Как использовать React Refs

Рефы в React позволяют получить ссылку непосредственно на HTML DOM элемент.
Рассмотрим виды и способы работы с рефами:
- React.createRef(): самый удобный способ:
const inputRef = React.createRef()
<input ref={inputRef} />
- callback: в атрибут ref передается колбек, который вызывается уже вместе с самой ссылкой:
<input ref={ref => inputRef = ref} />
- строковый: самый старый вид работы с рефами, не рекоммендуется к использованию.

Так же рефы можно передавать как обычные параметры и даже пробрасывать как собственный реф компонента:
const AnyComponent = React.forwardRef((props, ref) => <LogProps {...props} forwardedRef={ref} />;

Не злоупотребляйте рефами: большинство действий с компонентом удобнее и правильнее производить с помощью React.
Взаимодействие с рефами рекомендуется инкапсулировать в компонент, тем самым изолировать его логику.

makeweb.me/anatomiya-react-urok-12-chto-takoe-ref-y-i-kak-imi-polzovatsya/
rossbulat.medium.com/how-to-use-react-refs-4541a7501663
#react

Чем отличается Senior, Middle и Junior?

Градации очень условны и сильно разнятся в разных компаниях, но все же есть общие черты:
👨‍🎓 Джун
• Умеет программировать
• Задает вопрос в любой непонятной ситуации
👨‍💻 Миддл
• Умеет правильно программировать
• Самостоятелен, вопросы скорее инфраструктурные
🧔 Сениор
• Вопросы не задает, вместо этого он согласовывает один из вариантов решения бизнес задачи
• Может организовывать работу других людей

habr.com/post/513022/
medium.com/@ittheredpill/27e455fcaef4

Столкнулся с проблемой на iOs, что функция "Версия для ПК" в Chrome и "Запросить настольный веб-сайт" в Safari работали некорректно - сайт оставался в мобильном виде даже после включения режим просмотра для ПК.

На нашем сайте использовался метатег viewport:
<meta name="viewport" content="width=device-width,initial-scale=1">
Что значит что ширина viewport будет равна количеству реальных пикселей экрана.
Chrome на Android, для просмотра версии для ПК, по сути, выставляет метатегу viewport значение width=980px
По каким-то причинам, на iOs это не работает.
Я решил устанавливать такое значение вручную если идет просмотр версии для ПК.
Однако нет никакго флага, который показывал бы этот режим, UserAgent меняется на десктопный и, видимо, все.
Все же хак был найден:
const isIOsFakeDesktop = (navigator.platform === 'MacIntel' && navigator.maxTouchPoints > 1);
У мобильного устройства много точек касания а у десктопа только одна (точнее, их нет).

stackoverflow.com/a/58064481/13862767
#ios #safari #browser

SSR, CSR, SSG, WTF?

В зависимости от того, где формируется страница зависит то, как быстро пользователь ее увидит и как быстро он сможет с ней взаимодействовать.
Существует три варианта:
Server Side Rendering - генерация HTML страницы на стороне сервера
Client Side Rendering - генерация страницы только в браузере, на стороне клиента
Static Site Generation - предварительная генерация HTML файлов, после генерации можно отдавать сайт с любого хостинга статических файлов

Если страница сформирована сервером, то на клиенте может быть выполнена регидрация (Rehydration) - загрузка и выполнение JavaScript компонентов на клиенте таким образом, чтобы они повторно использовали HTML, сформированный на стороне сервера.

Все это влияет на ключевые параметры производительности:
TTFB (Time to First Byte, время до первого байта) - время между кликом по ссылке и поступлением первого фрагмента содержимого
FP (First Paint, первая отрисовка) - когда пользователю становится виден первый пиксель
FCP (First Contentful Paint, первая содержательная отрисовка) — время первого отображения запрашиваемого содержимого (например, статьи)
TTI (Time To Interactive, время до интерактивности) — момент времени, в который страница становится интерактивной (закрепляются все события и т. д.)

В статье (перевод и оригинал) детальнее, с графиками описываются плюсы и минусы различных подходов, инструменты и возможные сферы применения.
tproger.ru/translations/rendering-on-the-web/
developers.google.com/web/updates/2019/02/rendering-on-the-web
#performance #ssr #csr #ssg

Инкрементальная (ре)генерация статики в NextJS

Использование Incremental Static REgeneration (ISR) позволяет генерировать и обновлять страницы уже в процессе работы сервера.

Для этого в getStaticProps выставляется поле revalidate - время в секундах, в течении которого страница не требует обновления. Когда указанный интервал истекает то страница сама не обновляется, а обновление произойдет только после следующего запроса к этой странице. В ответ на этот запрос сервер вернет сохраненную версию страницы, и уже следующий запрос к этой странице вернет обновленную версию, но это не проблема если пользователей достаточно много.
Если страница была сгенерирована впервые то она будет сформированна в fallback mode - props пусты, а isFallback будет true.

Таким образом ISR позволяет получить плюсы и SSG и SSR, но команда next export становится недоступна.

arunoda.me/blog/what-is-nextjs-issg
blog.logrocket.com/incremental-static-regeneration-with-next-js/
#nextjs #isr #ssg #ssr

Подсчет размера блока до его отображения

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

❓Какие решения знаете вы?

dev.to/sstraatemans/calculate-html-element-width-before-render-4ii7
#ui #browser

Ведете ли вы какие-то каналы?
Не хотите ли поделиться ссылкой на них?

Тестирование типов с @ts-expect-error

При написании тестов, иногда возникает необходимость проверки именно типизации, особенно если в коде используются дженерики.
Например, если требуется убедиться что при компиляции с определенными типами TypeScript выбросит исключение.
Для этого в версии 3.9 был введен специальный комментарий
// @ts-expect-error
который проверяет следующую за ним строку и скрывает ошибку если она там есть, в ином случае генерирует исключение Unused '@ts-expect-error' directive .
У flow есть аналог $ExpectError, который работает так же.
В отличие от @ts-expect-error директива @ts-ignore подавляет любые ошибки.

dev.to/oliverjumpertz/making-good-use-of-ts-expect-error-in-typescript-1f41
#typescript #testing #tdd