#книга дня
Я уже писал года два назад о книге
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
❤7👍1🤩1
#заметка дня
Делаю дома мелкий ремонт и поймал себя на забавной аналогии с разработкой.
Когда на двери начинает откалываться краска, снять только тот кусок, который уже сам отвалился, обычно недостаточно. Берёшь шпатель и проходишься по краям того, что с виду ещё кажется нормальным. Где-то краска держится крепко, а где-то следом отходит ещё сантиметр, потом ещё десять. Значит, этот слой уже был частью повреждения — просто ещё не выглядел повреждённым.
С багами часто так же. Очень легко принять первое заметное проявление проблемы за её настоящую границу.
Допустим, пользователь дважды нажал «Оплатить» и получил два заказа. Самый очевидный фикс — задизейблить кнопку после первого клика. Исходный сценарий больше не воспроизводится, и формально баг можно закрывать. Но это примерно как закрасить только то место, где старая краска уже успела отвалиться.
Куда полезнее чуть пройтись по краям: что будет, если отправить то же действие из двух вкладок? Если клиент после таймаута повторит запрос? Если два одинаковых запроса придут на backend почти одновременно?
Как тут не вспомнить некоторых разработчиков, которые просто скажут: «Нефиг делать два заказа, проблема пользователя».
Если каждый из этих сценариев вскрывает новую проблему, значит дело было не в кнопке. Настоящая граница дефекта глубже: операция должна быть идемпотентной — повтор одного и того же запроса не должен приводить к повторному выполнению действия.
Это не значит, что при каждом сколе нужно сдирать всю дверь до дерева. В какой-то момент шпатель упирается в слой, который действительно держится, и там можно остановиться.
Иногда самое полезное, что можно сделать с багом перед тем, как его чинить, — сначала сделать его немного больше.
#dev #work
Делаю дома мелкий ремонт и поймал себя на забавной аналогии с разработкой.
Когда на двери начинает откалываться краска, снять только тот кусок, который уже сам отвалился, обычно недостаточно. Берёшь шпатель и проходишься по краям того, что с виду ещё кажется нормальным. Где-то краска держится крепко, а где-то следом отходит ещё сантиметр, потом ещё десять. Значит, этот слой уже был частью повреждения — просто ещё не выглядел повреждённым.
С багами часто так же. Очень легко принять первое заметное проявление проблемы за её настоящую границу.
Допустим, пользователь дважды нажал «Оплатить» и получил два заказа. Самый очевидный фикс — задизейблить кнопку после первого клика. Исходный сценарий больше не воспроизводится, и формально баг можно закрывать. Но это примерно как закрасить только то место, где старая краска уже успела отвалиться.
Куда полезнее чуть пройтись по краям: что будет, если отправить то же действие из двух вкладок? Если клиент после таймаута повторит запрос? Если два одинаковых запроса придут на backend почти одновременно?
Как тут не вспомнить некоторых разработчиков, которые просто скажут: «Нефиг делать два заказа, проблема пользователя».
Если каждый из этих сценариев вскрывает новую проблему, значит дело было не в кнопке. Настоящая граница дефекта глубже: операция должна быть идемпотентной — повтор одного и того же запроса не должен приводить к повторному выполнению действия.
Это не значит, что при каждом сколе нужно сдирать всю дверь до дерева. В какой-то момент шпатель упирается в слой, который действительно держится, и там можно остановиться.
Иногда самое полезное, что можно сделать с багом перед тем, как его чинить, — сначала сделать его немного больше.
#dev #work
👍7❤2