#книга дня
Я уже писал года два назад о книге
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❤2