#тред дня

Мне приходится проводить всё больше и больше собеседований к нам в Supermetrics на позицию фронтенд-разработчика, поскольку компания растёт.

Да, внезапно, хоть канал и называется «Будни верстальщика», моя позиция — Tech Lead команды разработки одного из наших основных продуктов.

И я уже пересмотрел достаточно много тестовых заданий. Чаще всего они меня не устраивают с самого начала.

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

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

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

2. Проверяющий скорее всего будет смотреть на формальные признаки. Сам код будет прочитан по диагонали и если там нет цепляющих взгляд вещей то он пройдет “ревью”.

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

4. Первая мелочь - не пиши весь код в одном файле, даже если кода 50 строк. Проверяющий доебется что не умеешь декомпозировать и в прод будешь писать так же в одном файле.

5. Вторая мелочь - обязательно юнит тесты, даже если нечего тестировать. Нужно просто наличие - два-три теста которые проверяют ничего лучше чем их полное отсутствие. (Как писать юниты для фронта я не знаю, поделитесь в комментах)

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

7. Хорошо если ты заморочишься и сделаешь мейкфайл, а еще докерфайл. Делов на 15 минут а сразу бонусных очков заработаешь.

8. Если можешь - лучше пиши на английском - ридми, коммит месседжи, комментарии к коду. Добавит очков, у нас странное отношение к английскому.

9. Добавь файл с версией, пусть будет вечный 0.1.0-SNAPSHOT но проверяющий заметит что ты подумал о версии. Совсем мелочь на 10 секунд работы, а очень бросается в глаза.

10. Старайся форматировать код читабельно, чтоб он выглядел красиво. Не комментируй каждую строку. Код должен выглядеть прилично если его смотреть по диагонали. Однобуквенные переменные оставь для прода, в тестовом задании их писать нельзя. (Ну счетчики i,j можно)

11. Если просят задание в виде репозитории отформатируй git log. Он должен выглядеть прилично и показывать ход мысли. Даже если ты писал за один присест. Покажи что ты умеешь атомарно вносить изменения а не одним куском. Ну и автора не забудь поправить. Фамилия имя вот это все.

12. Вот тут можно посмотреть как делал тестовое я (2pizza, прим. редактора). Кода меньше чем обвязки в виде скриптов и описаний.

13. Главный принцип - тестовое задание должно выглядеть как настоящий проект, даже если там делов на час. Это все не гарантия стопроцентного прохождения, но сильно сильно улучшит мнение проверяющего.

#собеседование #тестовое #работа #личинкатимлида #twitter

#заметка дня

Мне не очень нравится вложенность в SASS/SCSS/LESS и иже с ними.

Не очень нравится и будущее предложение внести вложенность (nesting) в CSS.

И я поясню, почему.

В первой части заметки много кода, телега не справится. Пройдите сюда, пожалуйста: https://gist.github.com/bekharsky/dea79c6b51fb693fba81897a40a594a4

Не так давно я в чате пытался помочь человеку, который накидал & для формирования классов (пытался в БЭМ) и никак не мог понять, как же сделать &:hover.

Получалось что-то вроде:

.block {
  &__element {
   // styles
  }

  &:hover {
    &__element {
      // styles
    }
  }
}

Кто-то на этом месте фыркнет. И будет неправ, потому что SCSS мог бы вместо простой конкатенации строк делать что-то более умное с блоками. Но надо ли?

Более опытные вспомнят про кеширование селекторов. Тоже вариант. Закешируем с десяток, почему нет… попробуй разберись.

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

Нестинг затрудняет понимание кода и поиск. Стили потомка могут оказаться в любом месте стилей родителя. Зачем?

Все мои аргументы касаются только читаемости кода. Ты можешь быть юным гением, который знает любое место в своём проекте. Но зачем вообще тратить ресурсы мозга на это?

#css #scss #nesting

#статья дня

Схлопывание отступов… марджинов, маргинов, margin — да как пожелаете.

В мире flexbox и grid всю боль этой фразы понять непросто, хотя стоило бы. Возможно, перестали бы пихать флекс там, где достаточно блока… ну да ладно. Чего только стоит один мой недавний вопрос: https://t.me/htmlshit/531

Но Джош Камю просто взял и сделал прекрасную статью, на пальцах и картинках объясняющую схлопывания в разных ситуациях: https://www.joshwcomeau.com/css/rules-of-margin-collapse/

Как всегда, горячо рекомендую если не читать, то хотя бы по примерам потыкать. Лучше никто не делает пока :)

#css #margin #collapse #tutorial

#фишка дня
…несуществующая

В эту последнюю пятницу лета (в Финляндии лето считают с мая по июль, чтобы хотя бы два месяца осени были без снега) хочется помечтать.

Вы только подумайте, насколько простым стало бы создание стилизованных радиокнопок и чекбоксов если бы у нас в руках был :has… суть – родительский селектор.

Но его нет. Он только лишь обсуждается: https://www.w3.org/TR/selectors-4/#relational

Правда, это сломает многие оптимизации в браузерах… но может, новые завезут.

Мечты, мечты…

#css #has

#заметка дня

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

А все потому что коллега перед тем, как в отпуск уйти, сделал рефакторинг ключей (key) в выводе массивов в React. И почти всё протестировал.

Казалось бы, ключи. Но даже вроде бы опытные разработчики ошибаются и делают key недостаточно уникальными, что может привести, и приводит, к последствиям, описанным выше.

Форму я, конечно, починил, косяк был буквально в паре строк. Но придётся коллеге по возвращению скинуть тред небезызвестного Дэна Абрамова: https://mobile.twitter.com/dan_abramov/status/1415279090446204929?s=20

Буквально на пальцах и кружках 🔴🔵🟡 описано, в чем же вообще проблема и зачем React’у так нужны ключи в выводе массивов.

#react #key

#фишка дня

Мне тут сообщили, что в 92 Хром и в 90 Фаерфокс с пылу с жару завезли метод Array.prototype.at(). Передаёте в at индекс элемента массива и получаете его значение, собственно.

Я сижу и честно говоря не очень понимаю, зачем он так сильно всем нужен.

Если коротко, то при передаче положительного числа, он работает точно так же, как и . Т. е. arr[2] и arr.at(2) оба вернут третий элемент.

Веселье заключается в том, что at поддерживает отрицательные значения индекса. И вы правильно догадались, они отсчитывают значения элементов с хвоста.

Последний элемент имеет индекс -1.

Т. о. то, что раньше писалось как arr[arr.length - 1] теперь пишется как arr.at(-1). Ну и так далее.

Собеседник сказал, что от первого варианта пахнет языком Си 🧐. По-моему так от обоих.

А каково ваше мнение?

#js #array

Кажется, я нашёл способ гарантированно и бесплатно повторять баги вёрстки в Safari на Windows-машинах. Оставайтесь на связи, попробую упаковать эту информацию максимально доступно 🧐

#заметка дня

Давайте разбираться, что же не так с Safari и почему он отстаёт.

История Safari начинается с движка KHTML, первая версия которого вышла в 1998 году. KHTML разрабатывался как движок рендеринга HTML для среды рабочего стола KDE (как пропатчить KDE2 под FreeBSD?). Как и Trident в Internet Explorer для Windows, его планировалось использовать вообще везде в системе.

Разрабатывался медленно, но верно, и получился великолепным. В итоге именно его форкнули в Apple для создания движка своего браузера и взорвали общественность в 2003 году. Я сокращаю историю, советую почитать хотя бы Википедию, там интересно.

В общем, Safari просто был лучше всех существующих аналогов на тот момент и поэтому именно его движок решили использовать в Google для создания своего браузера. WebKit как раз был выпущен как открытый проект в 2005. В раскрутку Chrome была брошена вся медийная сила Google.

Но двум мощным корпорациям недолго работалось настолько плотно вместе и в 2013 году уже Google форкнули WebKit, создав Blink. Некоторое время рендеринг в движках не сильно отличался, но время шло.

В итоге мы пришли к тому, что Safari, побыв некоторое мультиплатформенным браузером (с 2007 по 2012), уступил место на Windows окончательно. Для Apple это был маркетинговый ход, ибо выглядел он на Windows точно так же, как на macOS, включая даже рендеринг шрифта. Они надеялись так переманить к себе людей.

Прошло 8 лет. Blink и WebKit очень сильно разошлись по своим возможностям. Google начала активно подминать под себя веб, давя всё на своём пути (почитайте хотя бы, почему сдохла Opera). Новые возможности начали появляться как на дрожжах, иногда просто ради реализации желаний того или иного вендора. Иногда этим вендором была сама Google (удивительное рядом).

Apple не имела таких длинных рук в вебе. Ошибка ли это или нет, но компания решила занять позицию "защиты" своих пользователей от посягательств (других вендоров, в основном). Правда где-то они переборщили и далеко не каждая фича современного веба реально имела какое-то отношение к безопасности. Например, различные поля ввода (даты, времени, цвета). Но давайте честно — они и в Chrome c Firefox совершенно неудобны и выглядят крайне странно.

Второй аргумент Apple — это энергоэффективность Safari. И тут им сложно что-то противопоставить, Chrome жрёт батарею просто на ура. Firefox чуть лучше, но в целом у него точно так же имеются проблемы с совместимостью то тут то там, особенно на мобильных устройствах.

Apple, перестав развивать версию Safari для Windows, забросила и адаптацию WebKit, оставив это сторонним разработчикам. Появились WebKitGTK и Qt WebKit. Если слова GTK и Qt вам не знакомы, это, очень грубо говоря, UI-киты для разработки десктопных приложений на разных платформах, но в основном, конечно, для основанных на Linux системах. На WebKit стали появляться независимые браузеры и он приобрёл большую любовь сообщества. Некоторые из них были даже доступны на Windows (Midori, Epiphany).

А потом в мир ворвалась вечно везде опаздывающая последние лет 15 Microsoft и представила WSL, Windows Subsystem for Linux. Стало возможным запускать даже графические приложения без особых проблем вообще и разработка версий вышеупомянутых браузеров для Windows окончательно застопорилась.

Apple никак не помогала адаптировать процессы разработки WebKit, и многие независимые Windows-разработчики повернулись в сторону Blink. Но под Linux разработка не прекращалась и последние версии движка WebKit всё так же доступны в составе современных браузеров.

Завтра я покажу наш первый вариант решения проблемы. Как минимум, из трёх. Многие уже точно догадались, к чему я веду :)

#apple #webkit #safari #wsl

Ну, как обещал. Смотрим на баги Safari в Windows. С опозданием на день, но вы мне простите, надеюсь :)

Подробное описание летит следом, терпение.

#заметка дня

Продолжаем наше сафари по Safari (офигеть каламбур).

Тенденция такова, что вообще никто не любит собирать браузеры на WebKit. Blink компилировать и интегрировать намного приятнее. Остались лишь самые упорные. Ну, с ними и поработаем.

Итак, давайте запустим браузер Epiphany в Windows. Он же GNOME Web.

Установка

Нам понадобится:

1. WSL2: https://docs.microsoft.com/en-us/windows/wsl/install-win10

Не надо бояться, там делов на десять минут.

Кстати, горячо рекомендую попутно поставить WIndows Terminal. И ещё более горячо рекомендую привыкнуть к мысли, что на WSL вообще всё делать удобнее, VSCode вас в этом поддержит.

Могу потом показать, что именно я имею в виду.

2. Я буду производить эксперименты на Ubuntu, так что устанавливаем её из магазина приложений. Более опытные могут брать что угодно.

3. Устанавливаем в Ubuntu epiphany-browser:

sudo apt install epiphany-browser

Возможно, списки серверов, раздающих пакеты приложений (да и списки приложений вообще) нужно будет обновить:

sudo apt update

4. Если у вас версия Windows 10 ниже 20H2, вам потребуется VcXsrv.

Это сервер X Window System. Я намеренно опускаю объяснения, что есть что, для этого есть Википедия, но именно эта штука позволит вам запускать графические приложения Linux в Windows.

Можно ещё XMing, но я в него не умею. Поделитесь.

Если же у вас Windows 10 20H2 или Windows 11, вам даже этот шаг не нужен. Всё заработает из коробки:

В общем, это всё.

Запуск

Можете посмотреть видео выше, а можете — почитать инструкцию:

1. Сначала нужно запустить X-сервер, для этого в составе VcXsrv имеется утилита XLaunch. Стартуем.

2. Она предложит режим работы на выбор, я предпочитаю многооконный полноэкранному.

3. На втором экране выбираем просто запуск сервера, без конкретного клиента (Start no client). Клиент это, собственно, приложение. Логика X-сервера немного перевёрнута с ног на голову, кому интересно — почитает Википедию, а мы двигаемся дальше.

4. Поскольку моё личное железо довольно бывалое (ThinkPad T450s), я решил не пытаться запускать графическое ускорение, оно всё равно для наших целей не нужно. А вот авторизацию стоит отключить (Disable access control), одна машина же.

5. Ubuntu надо указать, где же находится наш сервер окон. Для чего выполняем следующую команду:

export DISPLAY=$(grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'):0.0


Так получилось, что WSL2 требует IP-адрес даже локального компьютера, так что приходится ему его и указывать. Т. е. вот этот кусок внутри большой команды:

grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'

Просто выводит ваш собственный локальный IP-адрес.

Для этого и нужна вся магия grep и awk. В моём случае получается:

export DISPLAY=192.168.3.1:0.0

В вашем – ваш собственный адрес.

Можно потом и в конфигурацию вашей командной строки внести (.bashrc или .zshrc), чтобы работало сразу при запуске.

6. Ну теперь, пожалуй, надо запустить и сам браузер:

epiphany


Если всё было проделано верно, откроется окно браузера, не совсем похожее на ваши привычные Windows-окошки (что за день, каламбур за каламбуром). Это всё потому, что Epiphany использует так называемые Client-side decorations. Это когда управление окном отрисовывается самим приложением. Мы отвлеклись.

Версия WebKitGTK в моём случае 2.32.3. Это примерно соответствует Safari 14. Внизу баги, которые я проверял на видео:

1. Clip-path и stacking context:
https://bugs.webkit.org/show_bug.cgi?id=140535
https://bug-140535-attachments.webkit.org/attachment.cgi?id=244746

2. Flexbox на summary:
https://github.com/philipwalton/flexbugs
https://philipwalton.github.io/flexbugs/9.3.a-bug.html

3. important и animate:
https://bugs.webkit.org/show_bug.cgi?id=75558
https://bugs.chromium.org/p/chromium/issues/detail?id=552085
http://jsfiddle.net/fFJ3m/1/

И — о чудо — они совпадают с Safari 14.1.2. Уж можете мне поверить.

Засылайте ваши любимые баги в комментарии, посмотрим-с.

#safari #linux #webkit #epiphany

#такое дня

Разбавим увеличившийся накал серьёзности канала краткой демонстрацией умеренного подхода к тестированию UI/UX от Софии Валитовой.

Хороших выходных! Нам ещё многое с вами предстоит проверить.

#codepen дня

Прекрасная работа Стива Гарднера: https://codepen.io/ste-vg/pen/GRooLza

За прошедшие полтора года многие уже, наверное, забыли, что такое самолёты. Этот пример позволит вспомнить 👀

А вообще, если коротко, это очень хороший пример интеграции библиотеки анимации GSAP и 3D-модели в WebGL при помощи Three.js. Код простой, чистый, абсолютно понятный.

И не забывайте, их держит в воздухе магия.

#gsap #scroll #webgl

#видео дня

Если вдруг так получилось, что вам в этот воскресный день дождливо и грустно, советую посмотреть лекцию Жени Обрезкова с детальным разбором настроек конфигурации TypeScript и typescript-eslint. Естественно, совсем не обязательно смотреть все два с половиной часа, ведь есть оглавление. Каждый пример демонстрируется в песочнице. Подойдёт всем :)

https://youtu.be/4Vc-O20llVs

#typescript #tsconfig #eslint

Глядите, чего я принёс. Запуск WebKit без виртуальных машин! Продолжение Safari-эпопеи.

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

Подробности через минуту.

#заметка дня

Знаете, идти сложным путём иногда не так плохо. Делиться его прохождением – тем более.

Мне в комментарии и ответы накидали ещё вариантов запуска WebKit на Windows без необходимости в виртуальной машине вообще.

И, кажется, я был не совсем прав.

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

Как обычно, давайте по порядку.

У проекта WebKit существует некий сборочный цех. Портал, на котором скрипт-боты запускают сборки, пересборки и тесты всего проекта под различные операционные системы и платформы.

Конечно, большинство сборщиков работают для iOS, macOS и Linix различных конфигураций, но и под Windows тоже имеются!

Поехали.

1. Давайте пройдём в раздел сборок. Видим список с ответственными за них ботами.

Нас конечно же интересуют с префиксом Win в названии сборщика. Фильтруем.

2. Находится не так много, берём Apple-Win-10-Release-Build.

Можно и Debug, но размер его – мама не горюй.

3. Проваливаемся в параметры сборщика и видим огромное число готовых к употреблению сборок.

Как несложно догадаться, они все привязаны к конкретным ревизиям движка. Ну то есть, можно повыбирать…

Но не то чтобы. Оказалось, файлы хранятся не так долго, всего около пары недель. Ну давайте двухнедельной давности и возьмём. Ревизия r280313 не могла уйти далеко.

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

Вообще, обещали, что минифицированные архивы будут храниться пару лет: https://webkit.org/blog/7978/introducing-webkit-build-archives/

Видимо, не для всех сборок… надо узнавать.

4. Прямая ссылка скрыта в шаге 12: transfer-to-s3. Находим её в логе, называется S3 URL. Скачиваем архив, распаковываем.

5. Находим в распаковке MiniBrowser.exe и… и запускаем?

Хрен там. Нужен Apple Application Support. Грубо говоря, набор библиотек для запуска.

Как его получить? Установить iTunes. Apple в своём репертуаре, конечно.

Раньше можно было распаковать установщик iTunes и установить библиотеки отдельно, но теперь – не выйдет :(

6. Ну что же, установили iTunes. И вот теперь можно и запустить!

Как и прежде, проверять я буду на:

1. Clip-path и stacking context:
https://bugs.webkit.org/show_bug.cgi?id=140535
https://bug-140535-attachments.webkit.org/attachment.cgi?id=244746

2. Flexbox на summary:
https://github.com/philipwalton/flexbugs
https://philipwalton.github.io/flexbugs/9.3.a-bug.html

В рассматриваемой ревизии этот баг уже исправлен.

3. important и animate:
https://bugs.webkit.org/show_bug.cgi?id=75558
https://bugs.chromium.org/p/chromium/issues/detail?id=552085
http://jsfiddle.net/fFJ3m/1/

Как и прежде, прошу вас делиться результатами и любимыми багами.

Оставайтесь на связи. Мы ещё не закончили.

#safari #bug #webkit #windows

Сборка WebKit Apple-Win-10-Release-Build от 27 июля 2021 года.

#заметка дня

У всей этой истории с Safari должен быть happy end.

TL;DR Browserstack.com

Но не все могут себе позволить даже 150 долларов в год за фриланс-план… или всё же есть выход?

Выход правда есть!

Browserstack активно поддерживает open-source проекты и даёт бесплатные лицензии на год!

Если у вас есть такой — смело топайте на https://www.browserstack.com/open-source и вбивайте там ссылку на репозиторий.

Главное — чтобы была подходящая лицензия. Полного списка я не нашёл, но уверен, что GPL, BSD и MIT точно включены. Я же указал Creative Commons Attribution 4.0 International.

Ах да, что же у меня за проект такой опенсорс? Да просто сайт этого канала: https://github.com/HTMLShit/htmlshit.site

Он немного в анабиозе сейчас, но работа над ним не прекращена.

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

Короче, если вы ещё не начали свой проект – чего вы ждёте вообще?

#browserstack #safari #windows #test

#фишка дня

Залогиньтесь на GitHub, проследуйте в любой репозиторий и нажмите точку — .. Желательно иметь браузер посвежее.

Просто сообщаю…

#github #feature