#книга дня
Я уже писал года два назад о книге
Web Browser Engineering, описывающей разработку простого браузера с нуля: https://browser.engineering/
Но они же не останавливались, и последняя на данный момент часть — про встраиваемые элементы — вышла в марте.
Описываются все сложности, преследующие разработчиков на каждом этапе разработки. Естественно, свой Chrome написать после прочтения не выйдет, но лучше понять, как работают браузеры — вполне.
Но в любом случае, чтение достаточно хардкорное :)
#python #dev #browser
Я уже писал года два назад о книге
Web Browser Engineering, описывающей разработку простого браузера с нуля: https://browser.engineering/
Но они же не останавливались, и последняя на данный момент часть — про встраиваемые элементы — вышла в марте.
Описываются все сложности, преследующие разработчиков на каждом этапе разработки. Естественно, свой Chrome написать после прочтения не выйдет, но лучше понять, как работают браузеры — вполне.
Но в любом случае, чтение достаточно хардкорное :)
#python #dev #browser
🔥12👍4
#ссылка дня
Я не удивлюсь, если в комментариях напишут: "Ну ты чо вообще, все это знают", но тем не менее.
У Google помимо прекрасных блогов разработчиков (того же Chrome) и весьма неплохой документации на их проекты имеется и простая обучающая платформа — Code Labs.
https://codelabs.developers.google.com/
Повторю, это не тайна, но я не знал, что материалов настолько много. От дизайна и веба до Flutter и ИИ. Ну и всеми любимый Python, куда ж без него.
Прошел несколько примеров по Flutter. Да, это в основном "пиши вот так", но на то оно и простая платформа. На некий путь вполне может навести, руку набить. Ну и бесплатно при этом.
Моя рекомендация, в общем.
#google #dev #education
Я не удивлюсь, если в комментариях напишут: "Ну ты чо вообще, все это знают", но тем не менее.
У Google помимо прекрасных блогов разработчиков (того же Chrome) и весьма неплохой документации на их проекты имеется и простая обучающая платформа — Code Labs.
https://codelabs.developers.google.com/
Повторю, это не тайна, но я не знал, что материалов настолько много. От дизайна и веба до Flutter и ИИ. Ну и всеми любимый Python, куда ж без него.
Прошел несколько примеров по Flutter. Да, это в основном "пиши вот так", но на то оно и простая платформа. На некий путь вполне может навести, руку набить. Ну и бесплатно при этом.
Моя рекомендация, в общем.
#google #dev #education
👍25❤🔥4❤4
#ссылка дня
Я не удивлюсь, если в комментариях напишут: "Ну ты чо вообще, все это знают", но тем не менее.
У Google помимо прекрасных блогов разработчиков (того же Chrome) и весьма неплохой документации на их проекты имеется и простая обучающая платформа — Code Labs.
https://codelabs.developers.google.com/
Повторю, это не тайна, но я не знал, что материалов настолько много. От дизайна и веба до Flutter и ИИ. Ну и всеми любимый Python, куда ж без него.
Прошел несколько примеров по Flutter. Да, это в основном "пиши вот так", но на то оно и простая платформа. На некий путь вполне может навести, руку набить. Ну и бесплатно при этом.
Моя рекомендация, в общем.
#google #dev #education #бородач
Я не удивлюсь, если в комментариях напишут: "Ну ты чо вообще, все это знают", но тем не менее.
У Google помимо прекрасных блогов разработчиков (того же Chrome) и весьма неплохой документации на их проекты имеется и простая обучающая платформа — Code Labs.
https://codelabs.developers.google.com/
Повторю, это не тайна, но я не знал, что материалов настолько много. От дизайна и веба до Flutter и ИИ. Ну и всеми любимый Python, куда ж без него.
Прошел несколько примеров по Flutter. Да, это в основном "пиши вот так", но на то оно и простая платформа. На некий путь вполне может навести, руку набить. Ну и бесплатно при этом.
Моя рекомендация, в общем.
#google #dev #education #бородач
👍36
This media is not supported in your browser
VIEW IN TELEGRAM
#заметка дня
А как вы, котаны, боретесь с багами?
Даже не так. Как боретесь — понятно, пишете код. Но каков процесс?
Мы вот у себя пытаемся играть в Zero Bug Policy. Это не значит, что в продукте нет багов и никогда их больше не будет. Это значит, что ни один баг не должен оставаться незамеченным или проигнорированным. По каждому обязательно принимается решение.
1. Баг в продакшене:
Создаётся user story (здесь и далее сторя). Отправляемся чинить или писать статью о том, почему это не баг.
2. Баг найден в процессе функционального тестирования
Должно быть принято решение:
a) Если он мешает процессу и блокирует релиз — немедленно создаётся сторя и баг уходит в работу
б) Если процессу работы не мешает и релиз уйдёт как есть — обновляем описание основной стори. Ни стори ни подзадачи не создаётся.
3. Примерно то же самое происходит если баг найден в процессе регресс-тестирования:
Либо создаётся задача и чинится, либо не создаётся ничего, если мы удовлетворены обходными путями или наличием технической документации по этому поводу.
Всплытие багов в регресс-тестировании означает, что имеются большие пробелы функциональном тестировании или даже планировании.
Мы раз в две недели проводим Bug Busting встречу на которой баги распределяются по категориям или закрываются как неактуальные. Наличие багов в бэклоге означает, что процесс сломан или баги не столь важны.
Да, может показаться, что мы просто заметаем проблемы под ковёр — но это не так.
Во-первых, наличие багов в бэклоге портит планирование, что в свою очередь портит настроение разработчикам.
Во-вторых, мы можем быть уверен, что баг от саппорта как минимум прочитал кто-то кроме, собственно, человека его создавшего.
В-третьих, ничто не вечно под луной. Сегодня ты тратишь три дня на баг, влияющий на мелкого пользователя, а завтра вся фича переписывается или выкидывается.
А у вас чо как?
#dev #process #bugs
А как вы, котаны, боретесь с багами?
Даже не так. Как боретесь — понятно, пишете код. Но каков процесс?
Мы вот у себя пытаемся играть в Zero Bug Policy. Это не значит, что в продукте нет багов и никогда их больше не будет. Это значит, что ни один баг не должен оставаться незамеченным или проигнорированным. По каждому обязательно принимается решение.
1. Баг в продакшене:
Создаётся user story (здесь и далее сторя). Отправляемся чинить или писать статью о том, почему это не баг.
2. Баг найден в процессе функционального тестирования
Должно быть принято решение:
a) Если он мешает процессу и блокирует релиз — немедленно создаётся сторя и баг уходит в работу
б) Если процессу работы не мешает и релиз уйдёт как есть — обновляем описание основной стори. Ни стори ни подзадачи не создаётся.
3. Примерно то же самое происходит если баг найден в процессе регресс-тестирования:
Либо создаётся задача и чинится, либо не создаётся ничего, если мы удовлетворены обходными путями или наличием технической документации по этому поводу.
Всплытие багов в регресс-тестировании означает, что имеются большие пробелы функциональном тестировании или даже планировании.
Мы раз в две недели проводим Bug Busting встречу на которой баги распределяются по категориям или закрываются как неактуальные. Наличие багов в бэклоге означает, что процесс сломан или баги не столь важны.
Да, может показаться, что мы просто заметаем проблемы под ковёр — но это не так.
Во-первых, наличие багов в бэклоге портит планирование, что в свою очередь портит настроение разработчикам.
Во-вторых, мы можем быть уверен, что баг от саппорта как минимум прочитал кто-то кроме, собственно, человека его создавшего.
В-третьих, ничто не вечно под луной. Сегодня ты тратишь три дня на баг, влияющий на мелкого пользователя, а завтра вся фича переписывается или выкидывается.
А у вас чо как?
#dev #process #bugs
👍8🤩3
#ссылка дня
Я не удивлюсь, если в комментариях напишут: "Ну ты чо вообще, все это знают", но тем не менее.
У Google помимо прекрасных блогов разработчиков (того же Chrome) и весьма неплохой документации на их проекты имеется и простая обучающая платформа — Code Labs.
https://codelabs.developers.google.com/
Повторю, это не тайна, но я не знал, что материалов настолько много. От дизайна и веба до Flutter и ИИ. Ну и всеми любимый Python, куда ж без него.
Прошел несколько примеров по Flutter. Да, это в основном "пиши вот так", но на то оно и простая платформа. На некий путь вполне может навести, руку набить. Ну и бесплатно при этом.
Моя рекомендация, в общем.
#google #dev #education #бородач
Я не удивлюсь, если в комментариях напишут: "Ну ты чо вообще, все это знают", но тем не менее.
У Google помимо прекрасных блогов разработчиков (того же Chrome) и весьма неплохой документации на их проекты имеется и простая обучающая платформа — Code Labs.
https://codelabs.developers.google.com/
Повторю, это не тайна, но я не знал, что материалов настолько много. От дизайна и веба до Flutter и ИИ. Ну и всеми любимый Python, куда ж без него.
Прошел несколько примеров по Flutter. Да, это в основном "пиши вот так", но на то оно и простая платформа. На некий путь вполне может навести, руку набить. Ну и бесплатно при этом.
Моя рекомендация, в общем.
#google #dev #education #бородач
👍27
#статья дня
Фича-флаги: фронтенд против бэкенда — где провести линию раздела?
Сегодняшняя статья от ConfigCat — отличный разбор того, как по-разному работают feature flags в клиенте и на сервере.
Если ты не в курсе:
фича-флаг — это переключатель, который позволяет включать или отключать части функциональности без выката новой версии. Прекрасный способ тестировать, экспериментировать и чинить баги на лету.
Фронтенд-флаги
Плюсы:
— моментальные изменения, удобны для UX-экспериментов
— не требуют изменений на сервере
Минусы:
— логика доступна в клиенте (а значит и пользователю)
— сложно скрыть саму фичу, даже если она выключена
— возможны баги при сбоях SDK
Да ладно, кому нужны исходники вашего SPA...
Бэкенд-флаги
Плюсы:
— безопасно: логика и флаги не видны снаружи
— удобно управлять доступом, ролями, регионами и т.п.
Минусы:
— отклик медленнее
— нужна координация между фронтом и бэком
— UI не всегда знает, что делать с отключённой фичей
Автор также говорит о гибридном подходе, который позволяет совместить лучшее из двух миров: контроль на бэке, адаптация интерфейса на фронте.
В статье всё по делу, с примерами и выводами:
https://configcat.com/blog/2025/05/08/frontend-vs-backend-feature-flags/
#feature #dev
Фича-флаги: фронтенд против бэкенда — где провести линию раздела?
Сегодняшняя статья от ConfigCat — отличный разбор того, как по-разному работают feature flags в клиенте и на сервере.
Если ты не в курсе:
фича-флаг — это переключатель, который позволяет включать или отключать части функциональности без выката новой версии. Прекрасный способ тестировать, экспериментировать и чинить баги на лету.
Фронтенд-флаги
Плюсы:
— моментальные изменения, удобны для UX-экспериментов
— не требуют изменений на сервере
Минусы:
— логика доступна в клиенте (а значит и пользователю)
— сложно скрыть саму фичу, даже если она выключена
— возможны баги при сбоях SDK
Да ладно, кому нужны исходники вашего SPA...
Бэкенд-флаги
Плюсы:
— безопасно: логика и флаги не видны снаружи
— удобно управлять доступом, ролями, регионами и т.п.
Минусы:
— отклик медленнее
— нужна координация между фронтом и бэком
— UI не всегда знает, что делать с отключённой фичей
Автор также говорит о гибридном подходе, который позволяет совместить лучшее из двух миров: контроль на бэке, адаптация интерфейса на фронте.
В статье всё по делу, с примерами и выводами:
https://configcat.com/blog/2025/05/08/frontend-vs-backend-feature-flags/
#feature #dev
👍7❤3
#инструмент дня
Монорепозитории имеют неприятное свойство разрастаться. Сюрприз-сюрприз.
Со временем файловая структура перестаёт что-то говорить: папок много, вложенность глубокая, понять где живой код, а где мёртвый — сложно.
Git Truck решает эту проблему через визуализацию репозитория. Он строит интерактивную «карту» проекта на основе git-истории: видно размеры файлов и директорий, активность изменений, вклад разных авторов, а также как структура менялась со временем.
Инструмент запускается локально, без облаков и интеграций, и просто открывает браузер с наглядным представлением репо. Полезная штука, когда нужно быстро разобраться в большом монорепозитории или посмотреть на кодовую базу целиком, а не по папкам.
https://github.com/standardgalactic/git-truck
#git #dev #tool
Монорепозитории имеют неприятное свойство разрастаться. Сюрприз-сюрприз.
Со временем файловая структура перестаёт что-то говорить: папок много, вложенность глубокая, понять где живой код, а где мёртвый — сложно.
Git Truck решает эту проблему через визуализацию репозитория. Он строит интерактивную «карту» проекта на основе git-истории: видно размеры файлов и директорий, активность изменений, вклад разных авторов, а также как структура менялась со временем.
Инструмент запускается локально, без облаков и интеграций, и просто открывает браузер с наглядным представлением репо. Полезная штука, когда нужно быстро разобраться в большом монорепозитории или посмотреть на кодовую базу целиком, а не по папкам.
https://github.com/standardgalactic/git-truck
#git #dev #tool
❤15👍7
#инструмент дня
Иногда мелкие неудобства в разработке настолько привычны, что мы перестаём их замечать. Один из таких примеров — бесконечные localhost:3000, localhost:5173, localhost:8080.
Запускаешь несколько сервисов — фронтенд, API, сторибук, документацию — и через час уже не помнишь, что было на каком порту. Перезапустил сторибук — и он уже на другом.
Бесит.
В Vercel Labs решили попробовать убрать саму причину проблемы и выпустили экспериментальный инструмент Portless. Идея очень простая: вместо портов использовать локальные доменные имена.
Было так:
Стало так:
Домены просто пробрасываются на реальные порты. Но разработчику больше не нужно их помнить.
Самое интересное — почему это вообще стало возможным.
Несколько лет назад в спецификациях закрепили правило: любой домен вида *.localhost должен автоматически резолвиться в loopback-адрес (127.0.0.1). Браузеры реализовали это поведение, поэтому api.localhost, app.localhost и любые другие подобные имена гарантированно указывают на ваш компьютер и даже считаются безопасным контекстом для веб-API.
Это открыло путь для инструментов, которые делают локальную разработку похожей на продакшен и больше не вспоминать, где был :3000, а где :5173.
Такая схема неожиданно удобна и для AI-инструментов. Когда адрес сервиса всегда один и тот же (app.localhost), кодовые агенты не ломаются из-за того, что dev-сервер внезапно переехал на другой порт.
В общем, такое мы одобряем.
Впрочем, никто никогда не мешал поднять локальный nginx и делать вообще что угодно.
#dev #port
Иногда мелкие неудобства в разработке настолько привычны, что мы перестаём их замечать. Один из таких примеров — бесконечные localhost:3000, localhost:5173, localhost:8080.
Запускаешь несколько сервисов — фронтенд, API, сторибук, документацию — и через час уже не помнишь, что было на каком порту. Перезапустил сторибук — и он уже на другом.
Бесит.
В Vercel Labs решили попробовать убрать саму причину проблемы и выпустили экспериментальный инструмент Portless. Идея очень простая: вместо портов использовать локальные доменные имена.
Было так:
http://localhost:3000
http://localhost:8080
http://localhost:5173
Стало так:
http://app.localhost
http://api.localhost
http://docs.localhost
Домены просто пробрасываются на реальные порты. Но разработчику больше не нужно их помнить.
Самое интересное — почему это вообще стало возможным.
Несколько лет назад в спецификациях закрепили правило: любой домен вида *.localhost должен автоматически резолвиться в loopback-адрес (127.0.0.1). Браузеры реализовали это поведение, поэтому api.localhost, app.localhost и любые другие подобные имена гарантированно указывают на ваш компьютер и даже считаются безопасным контекстом для веб-API.
Это открыло путь для инструментов, которые делают локальную разработку похожей на продакшен и больше не вспоминать, где был :3000, а где :5173.
Такая схема неожиданно удобна и для AI-инструментов. Когда адрес сервиса всегда один и тот же (app.localhost), кодовые агенты не ломаются из-за того, что dev-сервер внезапно переехал на другой порт.
В общем, такое мы одобряем.
Впрочем, никто никогда не мешал поднять локальный nginx и делать вообще что угодно.
#dev #port
1👍34
#событие дня
Я понятия не имею, как я пропустил! Итак, соревнование March MadCSS!
16 лучших фронтенд-разработчиков схлестнутся в жаркой битве по вёрстке интерфейсов.
Ну, я надеюсь, вам что-то говорят имена Josh Cameau, Wes Bos, Kyle Cook, Chris Coyier... если нет — очень зря!
Первый раунд был неделю назад и его можно посмотреть на YouTube: https://www.youtube.com/watch?v=nuxSFTjXrhI
А второй как раз будет сегодня.
И да, даже лучшие верстальщики мира гуглят, как выровнять текст.
Сайт ивента с турнирной таблицей и мерчом: https://madcss.com/
Смотрим?
#css #dev #battle
Я понятия не имею, как я пропустил! Итак, соревнование March MadCSS!
16 лучших фронтенд-разработчиков схлестнутся в жаркой битве по вёрстке интерфейсов.
Ну, я надеюсь, вам что-то говорят имена Josh Cameau, Wes Bos, Kyle Cook, Chris Coyier... если нет — очень зря!
Первый раунд был неделю назад и его можно посмотреть на YouTube: https://www.youtube.com/watch?v=nuxSFTjXrhI
А второй как раз будет сегодня.
И да, даже лучшие верстальщики мира гуглят, как выровнять текст.
Сайт ивента с турнирной таблицей и мерчом: https://madcss.com/
Смотрим?
#css #dev #battle
❤6👍1🤩1