Accesso имеет логотип из трех точек разного формата.
Я слегка упоролся и сделал loader в этом формате, но в двух вариантах: все точки одинаковые и точки повторяют логотип
Я слегка упоролся и сделал loader в этом формате, но в двух вариантах: все точки одинаковые и точки повторяют логотип
Какой вариант лоадера лучше?
Anonymous Poll
31%
Точки одинаковые
47%
Точки разные
22%
Мне не нравятся такие лоадеры
Благодаря помощи чата, вспомнил простую истину анимаций: не надо вызывать reflow анимируемого элемента. В прошлой реализации я менял положение элемента среди других элементов, что вызывало пересчет положений, а следствие подергивание анимации, которое видно в предыдущем посте.
Когда вся анимация стала только transform, пересчета положений нет, сдвигается только само изображение элемента, хотя "физически" элемент остается на месте — в центре блока.
Собственно изменения можно заметить по замедленной увеличенной анимации. Кстати, эту вкладку можно открыть в выпадающей по Esc панели chrome devtools.
Всем спасибо!
Когда вся анимация стала только transform, пересчета положений нет, сдвигается только само изображение элемента, хотя "физически" элемент остается на месте — в центре блока.
Собственно изменения можно заметить по замедленной увеличенной анимации. Кстати, эту вкладку можно открыть в выпадающей по Esc панели chrome devtools.
Всем спасибо!
Относительно новый экспериментальный Javascript движок на Rust:
https://github.com/boa-dev/boa
Аналогично экспериментальный линтер Javascript на Rust:
https://github.com/RDambrosio016/RSLint
Шо, происходит? Джаваскриптелы ломанулись переписывать тулинг на Rust? Почему сейчас? Почему на Rust? Неужели жс таки медленный для тулзов?
https://github.com/boa-dev/boa
Аналогично экспериментальный линтер Javascript на Rust:
https://github.com/RDambrosio016/RSLint
Шо, происходит? Джаваскриптелы ломанулись переписывать тулинг на Rust? Почему сейчас? Почему на Rust? Неужели жс таки медленный для тулзов?
Заметил, что Apple на своих лендингах тоже использует data-аттрибуты в качестве селекторов.
Начал тред про девтулзы в эффекторе: https://twitter.com/_sergeysova/status/1313761384119898112?s=20
Ретвитайте, лайкайте и комментируйте, будет интересно!
Ретвитайте, лайкайте и комментируйте, будет интересно!
Twitter
Sova
Тред про effector devtools! Лайкайте, ретвитайте, отвечайте, а я постараюсь за вами поспевать!
Продолжается тред effector devtools! Налетай!
https://twitter.com/_sergeysova/status/1316045120702218242?s=20
https://twitter.com/_sergeysova/status/1316045120702218242?s=20
Twitter
Sova
Есть апдейт! Картиночки before/after. dense dir layout (before/after) — если после добавления блока-папки в строке остаётся место, то расположить следующую папку на пустующем месте, а не справа. это позволило уместить на экране на одну папку больше
Все каналы пишут про новый айфон. А если я не буду тут ничего писать, все уйдут?
Сова пишет…
Слушать подкаст можно по этим ссылкам Яндекс.Музыка https://music.yandex.ru/album/8469435 Google Podcasts https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zaW1wbGVjYXN0LmNvbS8xeHRNRlZWcA Apple Podcasts https://podcasts.apple.com/us/podcast/%D1%81%D0%BE%D0%B2%D0%B0…
О подкаст таки залетел в другие приложения:
- PocketCasts
- Deezer
- RadioPublic
- Breaker
- Gaana
- Yourcast
- PocketCasts
- Deezer
- RadioPublic
- Breaker
- Gaana
- Yourcast
Из-за ковида люди массово (и в основном бессмысленно) принимают антибиотики. Это очень опасно и может навредить всему человечеству
Пандемия коронавируса спровоцировала массовый прием антибиотиков без явных показаний — для профилактики инфекции, «на всякий случай» и «для очистки совести». Однако это опасно и для заболевших ковидом, и для человечества в целом: такое применение антибиотиков только усиливает устойчивость бактерий к антимикробным лекарствам, и в критический момент они могут просто не сработать.
https://meduza.io/feature/2020/10/26/iz-za-kovida-lyudi-massovo-i-v-osnovnom-bessmyslenno-prinimayut-antibiotiki-eto-ochen-opasno-i-mozhet-navredit-vsemu-chelovechestvu
Пандемия коронавируса спровоцировала массовый прием антибиотиков без явных показаний — для профилактики инфекции, «на всякий случай» и «для очистки совести». Однако это опасно и для заболевших ковидом, и для человечества в целом: такое применение антибиотиков только усиливает устойчивость бактерий к антимикробным лекарствам, и в критический момент они могут просто не сработать.
https://meduza.io/feature/2020/10/26/iz-za-kovida-lyudi-massovo-i-v-osnovnom-bessmyslenno-prinimayut-antibiotiki-eto-ochen-opasno-i-mozhet-navredit-vsemu-chelovechestvu
Я уже давно хотел себе сокращалку ссылок.
Но раньше я писал свою на nodejs, клал ссылку в бд, пытался упростить просто генерацией nginx конфига.
А в этот раз решил ограничиться самым простейшим решением настраиваемым за 10 минут — netlify. Оказалось, что это работает очень быстро и настраивается очень просто: создаешь сайт в netlify, подключаешь репо, кладешь в репо netlify.toml со списком редиректов и всё работает через минуту. Вот такое я люблю!
go.sova.dev/podcast/yandex
go.sova.dev/podcast/stitcher
go.sova.dev/twitter/effector-devtools
Но раньше я писал свою на nodejs, клал ссылку в бд, пытался упростить просто генерацией nginx конфига.
А в этот раз решил ограничиться самым простейшим решением настраиваемым за 10 минут — netlify. Оказалось, что это работает очень быстро и настраивается очень просто: создаешь сайт в netlify, подключаешь репо, кладешь в репо netlify.toml со списком редиректов и всё работает через минуту. Вот такое я люблю!
go.sova.dev/podcast/yandex
go.sova.dev/podcast/stitcher
go.sova.dev/twitter/effector-devtools
☄ effector patronum ✨ близится к релизу v1.0!Самое время просмотреть список значимых изменений и подготовиться, следующая версия не будет включать никаких ломающих изменений.
https://github.com/effector/patronum/releases
Milestone 1.0 96% complete
Может быть есть то, чего не хватает в документации?
GitHub
Releases · effector/patronum
☄️ Effector operators library delivering modularity and convenience ✨ - effector/patronum
Всем привет, ищу разработчиков себе в команду на отдельный проект!
UPD(3 Sept 2021): всех нашли!
Redmadrobot это компания аутсорс разработки, но мы ищем людей на постоянный проект. Не придется прыгать раз месяц в новую команду со своими правилами, но если захочется — обсуждаемо.
Задачи которые мы решали на этом проекте:
- проектировали TypeScript SDK для реалтайм чатов с кучей конверсейшенов и паблик каналов
- реализовали интерфейс визуального скриптинга в стиле Unreal Blueprint
- разрабатываем сложные интерфейсы планирования рассылок
Стек: TypeScript, Effector, React, WebAPI, D3, styled-components, antdesign, Docker
Какие скиллы нужны:
- Уметь решать на React задачи любой сложности
- Знать об Effector и иметь желание на нём писать
- Понимать базовые принципы дизайна (в этом проекте нет дизайнера)
- Знать паттерны проектирования
- Уметь писать документацию на английском
- Соблюдать чистоту в проекте: conventional commits, кросс-кодревью, линтеры
- Тестировать компоненты и бизнес-логику (unit, integration)
Что у нас есть:
- Полностью белая ЗП, ДМС
- Начало дня с 9 до 12, macbook, офис с плюшками
- Гибкость к технологиям и аргументам, внутренние митапы, профессиональный рост, менторство
- Сейчас удаленная работа в Питере, но после пандемии переберемся частично в офис(возможно)
- Стремимся сделать хорошо, за короткие сроки, планируем рефакторинги и проводим исследования
Как нас посетить:
- Написать мне и получить ссылку на полный текст вакансии
- Сразу же в первом сообщении написать, что идешь на эту вакансию
- Вилку можно узнать в личке, такова политика компании
- Приложить ссылки на свой github, личные проекты, opensource
- Отлично, если будет пару предложений почему именно к нам
У нас ограничены сроки, ищем двух разработчиков до конца года. Выбирать будем по взаимной симпатии. Собеседование в два этапа, чтобы понять случилась любовь или нет. Чем раньше найдем, тем лучше. Пожалуйста, репостните в любимые чаты и своим знакомым.
UPD(3 Sept 2021): всех нашли!
Redmadrobot это компания аутсорс разработки, но мы ищем людей на постоянный проект. Не придется прыгать раз месяц в новую команду со своими правилами, но если захочется — обсуждаемо.
Задачи которые мы решали на этом проекте:
- проектировали TypeScript SDK для реалтайм чатов с кучей конверсейшенов и паблик каналов
- реализовали интерфейс визуального скриптинга в стиле Unreal Blueprint
- разрабатываем сложные интерфейсы планирования рассылок
Стек: TypeScript, Effector, React, WebAPI, D3, styled-components, antdesign, Docker
Какие скиллы нужны:
- Уметь решать на React задачи любой сложности
- Знать об Effector и иметь желание на нём писать
- Понимать базовые принципы дизайна (в этом проекте нет дизайнера)
- Знать паттерны проектирования
- Уметь писать документацию на английском
- Соблюдать чистоту в проекте: conventional commits, кросс-кодревью, линтеры
- Тестировать компоненты и бизнес-логику (unit, integration)
Что у нас есть:
- Полностью белая ЗП, ДМС
- Начало дня с 9 до 12, macbook, офис с плюшками
- Гибкость к технологиям и аргументам, внутренние митапы, профессиональный рост, менторство
- Сейчас удаленная работа в Питере, но после пандемии переберемся частично в офис(возможно)
- Стремимся сделать хорошо, за короткие сроки, планируем рефакторинги и проводим исследования
Как нас посетить:
- Написать мне и получить ссылку на полный текст вакансии
- Сразу же в первом сообщении написать, что идешь на эту вакансию
- Вилку можно узнать в личке, такова политика компании
- Приложить ссылки на свой github, личные проекты, opensource
- Отлично, если будет пару предложений почему именно к нам
У нас ограничены сроки, ищем двух разработчиков до конца года. Выбирать будем по взаимной симпатии. Собеседование в два этапа, чтобы понять случилась любовь или нет. Чем раньше найдем, тем лучше. Пожалуйста, репостните в любимые чаты и своим знакомым.
Именование коммитов
До этого момента во всех личных и рабочих проектах, я продвигал использование структурированного текста коммитов, а именно conventional commits через commitizen. Это подход в котором текст коммита (сообщение и тело) пишется в особом формате, легко поддающемся программному анализу. Что нам предлагает эта спецификация? Разделить текст коммита на несколько секций: тип изменений, скоуп, сообщение и расширенное тело.
Подход нацелен на создание явной структуры сообщения, каждый коммит должен четко описывать смысл изменений, а также локацию и характер, ведь можно не только добавлять новую функциональность, но также и править тесты с документацией. Conventional commits предлагает для каждого типа изменений создавать свой коммит.
Например, добавление параметра в функцию, это новая функциональность, тип пусть будет feature, исправляются или дописываются типы — tests, документация — docs, система сборки — build и так далее. Список жестко задан.
Область изменений(scope) также должна быть либо одна, либо сразу всё приложение: исправил что-то в локальной библиотеке функций — тип fix, scope my-lib, добавил новую страницу — тип feat, scope pages.
Даже сообщение об изменениях имеет заданную спецификацию и должно быть описано в определенном падеже.
Что это дает на практике: все коммиты пишутся в общем формате, такое проще читать, так как вся необходимая информация на виду, за дополнительной можно проследовать в тело коммита, текст можно валидировать через линтеры, стимулируя команду писать в едином формате, текст можно генерировать через cli, ответив на несколько типичных вопросов о характере изменений, а из истории коммитов можно генерировать списки изменений для релизов.
До этого момента во всех личных и рабочих проектах, я продвигал использование структурированного текста коммитов, а именно conventional commits через commitizen. Это подход в котором текст коммита (сообщение и тело) пишется в особом формате, легко поддающемся программному анализу. Что нам предлагает эта спецификация? Разделить текст коммита на несколько секций: тип изменений, скоуп, сообщение и расширенное тело.
Подход нацелен на создание явной структуры сообщения, каждый коммит должен четко описывать смысл изменений, а также локацию и характер, ведь можно не только добавлять новую функциональность, но также и править тесты с документацией. Conventional commits предлагает для каждого типа изменений создавать свой коммит.
Например, добавление параметра в функцию, это новая функциональность, тип пусть будет feature, исправляются или дописываются типы — tests, документация — docs, система сборки — build и так далее. Список жестко задан.
Область изменений(scope) также должна быть либо одна, либо сразу всё приложение: исправил что-то в локальной библиотеке функций — тип fix, scope my-lib, добавил новую страницу — тип feat, scope pages.
Даже сообщение об изменениях имеет заданную спецификацию и должно быть описано в определенном падеже.
Что это дает на практике: все коммиты пишутся в общем формате, такое проще читать, так как вся необходимая информация на виду, за дополнительной можно проследовать в тело коммита, текст можно валидировать через линтеры, стимулируя команду писать в едином формате, текст можно генерировать через cli, ответив на несколько типичных вопросов о характере изменений, а из истории коммитов можно генерировать списки изменений для релизов.
Остановимся на последнем примере — чейнджлоги изменений. Если взять в пример open source фреймворк или библиотеку, насколько действительно пользователю нужны полные списки изменений, “Вася изменил имя внутренней функции в ядре фреймворка, но при этом совместимость для пользователей не сломалась”. Гораздо правильнее и практичнее ситуация, когда авторы самостоятельно выбирают какие изменения нужно подсветить пользователю, пишут для них наглядные примеры подчеркивающие отличия, и такое сгенерировать уже невозможно.
В больших проектах все изменения, большие и маленькие добавляются через PullRequest, название которого выбирается осмысленно, да и причина наглядно объясняется в теле PR. Можно же использовать список PR для генерации release notes? Да, и в своих opensource проектах я перешел на такой подход, это даже отбивает желание пушить напрямую в мастер, ведь тогда изменения не будут видны в release notes, придется писать вручную, а я люблю автоматизацию.
Но с другой стороны это слегка вербозно, особенно если ведешь проект самостоятельно.
С энтерпрайз разработкой всё ещё бесполезнее, ведь там release notes либо вообще не пишутся, либо их пишет продуктовая команда на основе списка story из JIRA, а разработчикам генерировать release notes для себя не особо надо. Кроме случая, когда пишешь внутреннюю библиотеку для нескольких команд, но и там решается через PullRequests.
Какой же тут может быть вывод? Я вижу основной плюс в conventional commits — это дисциплина и чистота. Когда все участники команды стараются четко описывать характер изменений, особенно если лид проекта держит историю git в чистоте. Такой подход помогает выявлять изменения и причину сразу через git blame, без томных походов в задачи JIRA и перечитывание сотен комментариев, если они вообще остались, ведь в теле коммита можно сразу описать причины такого кода “поговорил с Васей, он утверждает, что может быть дыра в безопасности, если не подставить костыль сейчас”.
Инструментарий вроде commitizen и commitlint позволят сгенерировать и провалидировать полученный коммит автоматически, сохранив при этом ясную структуру. Я бы рекомендовал выбрать тот формат, который удобен команде, conventional commits слишком длинный, я бы посмотрел на gitmoji как альтернативу.
Я не вижу практического смысла в программном анализе истории коммитов и генерации release notes из этого, ведь там не будет бизнес-ценности, а вычленять её и писать сложные эвристики ради этого кажется нерациональной тратой времени. Release notes лучше генерировать из списка PullRequest.
В больших проектах все изменения, большие и маленькие добавляются через PullRequest, название которого выбирается осмысленно, да и причина наглядно объясняется в теле PR. Можно же использовать список PR для генерации release notes? Да, и в своих opensource проектах я перешел на такой подход, это даже отбивает желание пушить напрямую в мастер, ведь тогда изменения не будут видны в release notes, придется писать вручную, а я люблю автоматизацию.
Но с другой стороны это слегка вербозно, особенно если ведешь проект самостоятельно.
С энтерпрайз разработкой всё ещё бесполезнее, ведь там release notes либо вообще не пишутся, либо их пишет продуктовая команда на основе списка story из JIRA, а разработчикам генерировать release notes для себя не особо надо. Кроме случая, когда пишешь внутреннюю библиотеку для нескольких команд, но и там решается через PullRequests.
Какой же тут может быть вывод? Я вижу основной плюс в conventional commits — это дисциплина и чистота. Когда все участники команды стараются четко описывать характер изменений, особенно если лид проекта держит историю git в чистоте. Такой подход помогает выявлять изменения и причину сразу через git blame, без томных походов в задачи JIRA и перечитывание сотен комментариев, если они вообще остались, ведь в теле коммита можно сразу описать причины такого кода “поговорил с Васей, он утверждает, что может быть дыра в безопасности, если не подставить костыль сейчас”.
Инструментарий вроде commitizen и commitlint позволят сгенерировать и провалидировать полученный коммит автоматически, сохранив при этом ясную структуру. Я бы рекомендовал выбрать тот формат, который удобен команде, conventional commits слишком длинный, я бы посмотрел на gitmoji как альтернативу.
Я не вижу практического смысла в программном анализе истории коммитов и генерации release notes из этого, ведь там не будет бизнес-ценности, а вычленять её и писать сложные эвристики ради этого кажется нерациональной тратой времени. Release notes лучше генерировать из списка PullRequest.