#quote #twitter
Универсальная таблица оценки задач
изян - 1ч
изи - 2ч
просто - 4ч
вроде просто - 6ч
норм - 8ч
норм так - 12ч
хз - 16ч
хз как-то - 20ч
как-то сложно - 24ч
сложно - 30ч
очень сложно - 40ч
бля - 48ч
пиздец - 60ч
пиздец какой-то - 80ч
вроде изян - 100ч
https://twitter.com/sevaorlasvegas/statuses/1153635852997865473
Универсальная таблица оценки задач
изян - 1ч
изи - 2ч
просто - 4ч
вроде просто - 6ч
норм - 8ч
норм так - 12ч
хз - 16ч
хз как-то - 20ч
как-то сложно - 24ч
сложно - 30ч
очень сложно - 40ч
бля - 48ч
пиздец - 60ч
пиздец какой-то - 80ч
вроде изян - 100ч
https://twitter.com/sevaorlasvegas/statuses/1153635852997865473
Twitter
апартаменты в стиле лофт возле...
Универсальная таблица оценки задач изян - 1ч изи - 2ч просто - 4ч вроде просто - 6ч норм - 8ч норм так - 12ч хз - 16ч хз как-то - 20ч как-то сложно - 24ч сложно - 30ч очень сложно - 40ч бля - 48ч пиздец - 60ч пиздец какой-то - 80ч вроде изян - 100ч
#js #es #esnext #webpack #twitter
Отличный тред Андрея Ситника о том, что же не так в мире ES-модулей и почему радоваться рано.
Коротко для фронтенда: реализация модулей в Webpack отличается от стандарта, поддержка браузерами чистых модулей ещё не совсем достаточна, а когда она будет достаточна — встанет проблема доставки до потребителя и генерации карт исходного кода. В общем, от бандлеров избавиться удастся совсем не скоро, а скорее всего — никогда. Но это и не нужно.
https://twitter.com/andrey_sitnik/status/1229753395961044993
Отличный тред Андрея Ситника о том, что же не так в мире ES-модулей и почему радоваться рано.
Коротко для фронтенда: реализация модулей в Webpack отличается от стандарта, поддержка браузерами чистых модулей ещё не совсем достаточна, а когда она будет достаточна — встанет проблема доставки до потребителя и генерации карт исходного кода. В общем, от бандлеров избавиться удастся совсем не скоро, а скорее всего — никогда. Но это и не нужно.
https://twitter.com/andrey_sitnik/status/1229753395961044993
Twitter
ES-модули в JS — крутая функция, но грустный пример сложного внедрения.
На самом деле нет одних ES-модулей — есть 3 разных технологий: модули в браузере, в Node.js и в сборщиках. И они не очень совместимы между собой.
Тред про всю правду о ES-модулей ↓
На самом деле нет одних ES-модулей — есть 3 разных технологий: модули в браузере, в Node.js и в сборщиках. И они не очень совместимы между собой.
Тред про всю правду о ES-модулей ↓
#заметка дня
#twitter #типографика #баг
Вы, наверное, замечали, что некоторые русскоязычные твиты отображаются весьма странно: буквы округлые и вычурные, как прямой курсив, некоторые из них даже похожи на латиницу.
Оказывается, это – болгарица. Иначе – болгарская кириллица. Болгарица была призвана увеличить идентичность болгарской письменности и отделить её от остальных кириллических алфавитов: https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%BB%D0%B3%D0%B0%D1%80%D1%81%D0%BA%D0%B0%D1%8F_%D0%BA%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0_(%D1%82%D0%B8%D0%BF%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D0%BA%D0%B0)
Так вот дело в том, что Твиттер иногда ошибается и ставит русскоязычным твитам признак болгарского языка (lang=“bg”), отчего и происходит сей казус. Вообще, я с трудом могу понять, как можно спутать русский с болгарским, но в Твиттере явно сидят люди, которым нет дела до этого.
А ещё в iOS Safari до версии 14.3 болгарица отображается для всего шрифта Monserrat, у кого айфоны – можете проверить: https://codepen.io/alexeyten/full/QWNYqLK (там и хороший пример болгарицы имеется)
Честно говоря, мне болгарица не нравится. Выглядит вторично для обоих алфафитов, пусть даже намерения были самые благие. Ну а Твиттеру – просто позор.
#twitter #типографика #баг
Вы, наверное, замечали, что некоторые русскоязычные твиты отображаются весьма странно: буквы округлые и вычурные, как прямой курсив, некоторые из них даже похожи на латиницу.
Оказывается, это – болгарица. Иначе – болгарская кириллица. Болгарица была призвана увеличить идентичность болгарской письменности и отделить её от остальных кириллических алфавитов: https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%BB%D0%B3%D0%B0%D1%80%D1%81%D0%BA%D0%B0%D1%8F_%D0%BA%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0_(%D1%82%D0%B8%D0%BF%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D0%BA%D0%B0)
Так вот дело в том, что Твиттер иногда ошибается и ставит русскоязычным твитам признак болгарского языка (lang=“bg”), отчего и происходит сей казус. Вообще, я с трудом могу понять, как можно спутать русский с болгарским, но в Твиттере явно сидят люди, которым нет дела до этого.
А ещё в iOS Safari до версии 14.3 болгарица отображается для всего шрифта Monserrat, у кого айфоны – можете проверить: https://codepen.io/alexeyten/full/QWNYqLK (там и хороший пример болгарицы имеется)
Честно говоря, мне болгарица не нравится. Выглядит вторично для обоих алфафитов, пусть даже намерения были самые благие. Ну а Твиттеру – просто позор.
Wikipedia
Болгарская кириллица (типографика)
«Болгарская кириллица» («болгарица», прямой курсив) — придание символам кириллических шрифтов и надписей черт, свойственных латинскому алфавиту. Может использоваться намеренно в качестве эксперимента с формой символов. Характерно для болгарской школы шрифтового…
#тред дня
Мне приходится проводить всё больше и больше собеседований к нам в 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
Мне приходится проводить всё больше и больше собеседований к нам в 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
👍1
#тред дня
Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.
Сегодня поговорим о код-ревью в треде от Олега Климакова.
Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.
Поехали.
1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.
2. Для начала - зачем это всё?
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.
3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
4. Способы чтобы иметь хорошо поддерживаемый код:
✅Покрытие тестами
✅Ведение документации
✅Код ревью
И все эти способы нужно уметь готовить. Есть тесты которые только мешают, бесполезная документация и бессмысленный код ревью.
5. Что даёт код ревью:
➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои
6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью
Дальше советы из моей практики. На объективность не претендую.
7.
❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все
В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.
8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.
9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.
10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).
Ваша задача как ревьюера получить такой код, который в случае болезни разработчика вы завтра будете поддерживать и не потонете.
11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее
12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.
Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.
13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код
Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо
#работа #pr #github #twitter
Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.
Сегодня поговорим о код-ревью в треде от Олега Климакова.
Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.
Поехали.
1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.
2. Для начала - зачем это всё?
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.
3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
4. Способы чтобы иметь хорошо поддерживаемый код:
✅Покрытие тестами
✅Ведение документации
✅Код ревью
И все эти способы нужно уметь готовить. Есть тесты которые только мешают, бесполезная документация и бессмысленный код ревью.
5. Что даёт код ревью:
➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои
6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью
Дальше советы из моей практики. На объективность не претендую.
7.
❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все
В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.
8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.
9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.
10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).
Ваша задача как ревьюера получить такой код, который в случае болезни разработчика вы завтра будете поддерживать и не потонете.
11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее
12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.
Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.
13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код
Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо
#работа #pr #github #twitter
#тред дня
Я очень люблю треды в Твиттере. К сожалению, в Телеграме подобный формат практически невозможен, разве что в виде комментариев. В блогах — только в Медиуме, но Медиум — это рак.
А в Твиттере каждый абзац — может быть законченной мыслью, каждый абзац может содержать альбомы и комментироваться отдельно, порождая новые ветки. В этом вся суть.
Ну а если какой-то тред охота сохранить — есть инструменты вроде https://threadreaderapp.com/
Так вот, сегодняшний тред — о проблемах программистов, пришедших с курсов.
TL;DR У них отсутствует инженерное мышление и желание это мышление получить.
Ну и ссылка, куда ж без неё: https://twitter.com/kalashnikovisme/status/1456880323929657348
И для тех, кому Твиттер не по душе: https://unrollthread.com/t/1456880323929657348/ (выглядит как обычный пост в блоге).
#twitter
Я очень люблю треды в Твиттере. К сожалению, в Телеграме подобный формат практически невозможен, разве что в виде комментариев. В блогах — только в Медиуме, но Медиум — это рак.
А в Твиттере каждый абзац — может быть законченной мыслью, каждый абзац может содержать альбомы и комментироваться отдельно, порождая новые ветки. В этом вся суть.
Ну а если какой-то тред охота сохранить — есть инструменты вроде https://threadreaderapp.com/
Так вот, сегодняшний тред — о проблемах программистов, пришедших с курсов.
TL;DR У них отсутствует инженерное мышление и желание это мышление получить.
Ну и ссылка, куда ж без неё: https://twitter.com/kalashnikovisme/status/1456880323929657348
И для тех, кому Твиттер не по душе: https://unrollthread.com/t/1456880323929657348/ (выглядит как обычный пост в блоге).
#драма дня
Тут такое дело. В общем, некто Эрик Лоуренс внёс в кодовую базу браузера Chromium исправление, позволяющее политикам безопасности блокировать просмотр исходного кода страницы: https://t.co/00MoEdcJry
Абсолютное большинство восприняло изменение в штыки. То ли они проигнорировали факт, что блокировка просмотра исходного кода регулируется администратором машины, а не сайтом. То ли то, что механизм блокировки URL и так давно уже был и это лишь ещё один протокол (view-source).
Прям скандал: https://twitter.com/textfiles/status/1458555850524663815
Мне нравится манипуляция вида: «in the middle of the Chrome Dev summit». Ну приплыли, это-то какое отношение имеет к делу?
Но знаете, что позабавило больше? Что в тестах на google forms можно посмотреть ответы в исходном коде! Мне лениво проверять, но я шокирован.
А вы тоже в начале своего пути смотрели исходники на каждом встречном сайте? Я — да. Но данный багфикс меня никак не задел.
#chrome #chromium #twitter
Тут такое дело. В общем, некто Эрик Лоуренс внёс в кодовую базу браузера Chromium исправление, позволяющее политикам безопасности блокировать просмотр исходного кода страницы: https://t.co/00MoEdcJry
Абсолютное большинство восприняло изменение в штыки. То ли они проигнорировали факт, что блокировка просмотра исходного кода регулируется администратором машины, а не сайтом. То ли то, что механизм блокировки URL и так давно уже был и это лишь ещё один протокол (view-source).
Прям скандал: https://twitter.com/textfiles/status/1458555850524663815
Мне нравится манипуляция вида: «in the middle of the Chrome Dev summit». Ну приплыли, это-то какое отношение имеет к делу?
Но знаете, что позабавило больше? Что в тестах на google forms можно посмотреть ответы в исходном коде! Мне лениво проверять, но я шокирован.
А вы тоже в начале своего пути смотрели исходники на каждом встречном сайте? Я — да. Но данный багфикс меня никак не задел.
#chrome #chromium #twitter
👍3
#тред дня
В Twitter проходит очередной челендж: требуется уместить паттерн в 280 символов.
https://twitter.com/anatudor/status/1479135302925041671
Примеры можно увидеть на иллюстрации, в треде есть ещё.
Ну коллекция кодпенов для вдохновения: https://codepen.io/thebabydino/full/OJmpzya
#twitter #css #pattern #contest #challenge
В Twitter проходит очередной челендж: требуется уместить паттерн в 280 символов.
https://twitter.com/anatudor/status/1479135302925041671
Примеры можно увидеть на иллюстрации, в треде есть ещё.
Ну коллекция кодпенов для вдохновения: https://codepen.io/thebabydino/full/OJmpzya
#twitter #css #pattern #contest #challenge
👍2
#тред дня
Помните, недавно я выкладывал руководство по созданию цветовых схем в редакторах? Ну вот это вот: https://yangx.top/htmlshit/914
Тема на самом деле достаточно обширная и касается не только, собственно, редакторов кода, но и, наверное даже в первую очередь, наборов UI виджетов. UI-китов, по-простецки. Или правил HIG.
Итак, возьмём, например, Material Design от Google. Кто-то же сидел и придумывал палитру цветов для кнопок, теней, акцентов… По каким же принципам?
Вот наш сегодняшний Твиттер-тред как раз об этом: https://twitter.com/mobileunderhood/status/1486965874351386625
Кому неудобно читать в Твиттере, как всегда — сохранённый тред: https://threadreaderapp.com/thread/1486965874351386625.html
Stay tuned!
#material #ui #color #twitter
Помните, недавно я выкладывал руководство по созданию цветовых схем в редакторах? Ну вот это вот: https://yangx.top/htmlshit/914
Тема на самом деле достаточно обширная и касается не только, собственно, редакторов кода, но и, наверное даже в первую очередь, наборов UI виджетов. UI-китов, по-простецки. Или правил HIG.
Итак, возьмём, например, Material Design от Google. Кто-то же сидел и придумывал палитру цветов для кнопок, теней, акцентов… По каким же принципам?
Вот наш сегодняшний Твиттер-тред как раз об этом: https://twitter.com/mobileunderhood/status/1486965874351386625
Кому неудобно читать в Твиттере, как всегда — сохранённый тред: https://threadreaderapp.com/thread/1486965874351386625.html
Stay tuned!
#material #ui #color #twitter
👍4🔥4
#тред дня
Мне приходится проводить всё больше и больше собеседований к нам в Supermetrics на позицию фронтенд-разработчика, поскольку компания растёт.
И я уже пересмотрел достаточно много тестовых заданий. Чаще всего они меня не устраивают с самого начала.
Не хочу разводить полемику о нужности или ненужности самих тестовых, но в твиттере 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
Мне приходится проводить всё больше и больше собеседований к нам в Supermetrics на позицию фронтенд-разработчика, поскольку компания растёт.
И я уже пересмотрел достаточно много тестовых заданий. Чаще всего они меня не устраивают с самого начала.
Не хочу разводить полемику о нужности или ненужности самих тестовых, но в твиттере 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
👍39❤4👎1
#тред дня
Отличный тред Андрея Ситника о том, что же не так в мире ES-модулей и почему радоваться рано. Тред из конца 2020, но не потерял популярности и сейчас.
Почему вспомнил сейчас? Потому что отлично дополняет предыдущий пост про Vite.
Коротко для фронтенда: реализация модулей в Webpack отличается от стандарта, поддержка браузерами чистых модулей ещё не совсем достаточна, а когда она будет достаточна — встанет проблема доставки до потребителя и генерации карт исходного кода. В общем, от бандлеров избавиться удастся совсем не скоро, а скорее всего — никогда. Но это и не нужно.
https://twitter.com/andrey_sitnik/status/1229753395961044993
Для тех, кто не про твиттер: https://threadreaderapp.com/thread/1229753395961044993.html
#js #es #esnext #webpack #twitter
Отличный тред Андрея Ситника о том, что же не так в мире ES-модулей и почему радоваться рано. Тред из конца 2020, но не потерял популярности и сейчас.
Почему вспомнил сейчас? Потому что отлично дополняет предыдущий пост про Vite.
Коротко для фронтенда: реализация модулей в Webpack отличается от стандарта, поддержка браузерами чистых модулей ещё не совсем достаточна, а когда она будет достаточна — встанет проблема доставки до потребителя и генерации карт исходного кода. В общем, от бандлеров избавиться удастся совсем не скоро, а скорее всего — никогда. Но это и не нужно.
https://twitter.com/andrey_sitnik/status/1229753395961044993
Для тех, кто не про твиттер: https://threadreaderapp.com/thread/1229753395961044993.html
#js #es #esnext #webpack #twitter
👍3