#development
Якорные ссылки в SPA
Одностраничные приложения (SPA) являются популярным подходом при создании современных веб-сайтов. И это не только модный тренд: SPA обладают рядом преимуществ по сравнению с традиционными приложениями.
Минусы подобного подхода также известны. Например, у SPA могут возникать проблемы с оптимизацией для поисковых систем (SEO), приложения могут долго открываться при первом запуске и нагружать устройства пользователей.
Но есть менее очевидные проблемы, с которыми можно столкнуться при разработке SPA. Одна из таких — это нерабочие якорные ссылки.
Якорные ссылки используются для навигации в рамках одной страницы. Также они позволяют ссылаться на определенный раздел внешней страницы. К примеру, вы можете поделиться ссылкой на свой лендинг и сразу прокрутить пользователя к разделу с информацией о компании.
Если в простом SPA попытаться реализовать якорные ссылки, они попросту не будут работать. При переходе по такой ссылке браузер отобразит самое начало страницы и не будет прокручивать к целевой секции.
Почему так происходит?
При прямом переходе по якорной ссылке из внешних ресурсов браузер прокручивает страницу к нужному разделу сразу после того, как произойдет событие DOMContentLoaded. Это значит, что документ проанализирован, DOM готов, а синхронные и отложенные (defer) скрипты загружены и только начали выполняться. По крайней мере так работают якорные ссылки в Chrome и Safari. В этот момент может получиться так, что нужный элемент попросту отсутствует в документе, так как еще не все ресурсы загружены и не все скрипты успели выполниться.
А при переходах между страницами внутри одного приложения (то есть, когда используется например react-router в одностраничном приложении) браузер пытается перейти к секции по смене URI до того, как новая страница успевает отрисоваться.
Если же перейти по якорной ссылке в пределах одной страницы, то сложностей скорее всего не возникнет, так как в этом случае все элементы страницы уже отрисованы.
Чтобы решить эту проблему, можно написать скрипт, который прокрутит страницу к нужному элементу уже после того, как DOM претерпит все изменения.
Также можно взять готовый пакет, например, react-router-hash-link для react-router. Он исправляет ряд проблем связанных с работой якорей в SPA на React. Подобные реализации есть и для других популярных фреймворков.
Однако лучшим вариантом будет отдавать полностью готовую HTML-страницу с сервера используя серверный рендеринг (SSR) или генератор статических сайтов (SSG). Это можно реализовать при помощи Next.js, Gatsby и др. В таком случае, когда браузер попытается перейти к нужной секции, DOM уже будет готов, а целевой элемент доступен.
Этот способ выглядит более естественным. Мы не выдумываем ничего нового, а используем уже существующие механизмы, реализованные в браузерах задолго до одностраничных приложений. А благодаря современным решениям мы можем «восстановить» изначальный принцип работы наших веб-сайтов, сохранив при этом преимущества SPA.
Якорные ссылки в SPA
Одностраничные приложения (SPA) являются популярным подходом при создании современных веб-сайтов. И это не только модный тренд: SPA обладают рядом преимуществ по сравнению с традиционными приложениями.
Минусы подобного подхода также известны. Например, у SPA могут возникать проблемы с оптимизацией для поисковых систем (SEO), приложения могут долго открываться при первом запуске и нагружать устройства пользователей.
Но есть менее очевидные проблемы, с которыми можно столкнуться при разработке SPA. Одна из таких — это нерабочие якорные ссылки.
Якорные ссылки используются для навигации в рамках одной страницы. Также они позволяют ссылаться на определенный раздел внешней страницы. К примеру, вы можете поделиться ссылкой на свой лендинг и сразу прокрутить пользователя к разделу с информацией о компании.
Если в простом SPA попытаться реализовать якорные ссылки, они попросту не будут работать. При переходе по такой ссылке браузер отобразит самое начало страницы и не будет прокручивать к целевой секции.
Почему так происходит?
При прямом переходе по якорной ссылке из внешних ресурсов браузер прокручивает страницу к нужному разделу сразу после того, как произойдет событие DOMContentLoaded. Это значит, что документ проанализирован, DOM готов, а синхронные и отложенные (defer) скрипты загружены и только начали выполняться. По крайней мере так работают якорные ссылки в Chrome и Safari. В этот момент может получиться так, что нужный элемент попросту отсутствует в документе, так как еще не все ресурсы загружены и не все скрипты успели выполниться.
А при переходах между страницами внутри одного приложения (то есть, когда используется например react-router в одностраничном приложении) браузер пытается перейти к секции по смене URI до того, как новая страница успевает отрисоваться.
Если же перейти по якорной ссылке в пределах одной страницы, то сложностей скорее всего не возникнет, так как в этом случае все элементы страницы уже отрисованы.
Чтобы решить эту проблему, можно написать скрипт, который прокрутит страницу к нужному элементу уже после того, как DOM претерпит все изменения.
Также можно взять готовый пакет, например, react-router-hash-link для react-router. Он исправляет ряд проблем связанных с работой якорей в SPA на React. Подобные реализации есть и для других популярных фреймворков.
Однако лучшим вариантом будет отдавать полностью готовую HTML-страницу с сервера используя серверный рендеринг (SSR) или генератор статических сайтов (SSG). Это можно реализовать при помощи Next.js, Gatsby и др. В таком случае, когда браузер попытается перейти к нужной секции, DOM уже будет готов, а целевой элемент доступен.
Этот способ выглядит более естественным. Мы не выдумываем ничего нового, а используем уже существующие механизмы, реализованные в браузерах задолго до одностраничных приложений. А благодаря современным решениям мы можем «восстановить» изначальный принцип работы наших веб-сайтов, сохранив при этом преимущества SPA.
👍4🔥4❤1
#development
Фронтенд на сервере
Когда-то веб-приложения были «бэкендоцентричны»: HTML-страницы генерировались на сервере, а для добавления динамических данных использовались шаблоны.
Со временем требования к интерактивности страниц стали выше, и фронтенд-технологии начали активно развиваться, в частности — подход Single Page Application (SPA). Фреймворки развивались так, что со временем фронтенд стал отдельным приложением, которое отдельно проектируется, разрабатывается отдельными людьми и хостится тоже отдельно.
Это разделение, при своих преимуществах, приводит к нескольким проблемам.
🔹 Код, отправляемый в браузер, становится тяжёлым и растёт при увеличении функциональности приложения.
🔹 Много логики переносится на клиент. Например, роутинг, который реализован заново и «в обход» механизмов браузера.
🔹 Много логики дублируется на фронтенде и бэкенде. Например, валидация и ограничение доступа.
🔹 Необходимо проектировать и разрабатывать API — дополнительный слой синхронизации фронтенда и бэкенда — даже там, где бэкенд выполняет только функции обслуживания интерфейса.
🔹 Разделение специалистов на фронтенд и бэкенд-разработчиков в командах создаёт накладные расходы, размывает понимание итоговой задачи и ответственности.
При этом принципы работы сети и браузеров не изменились: веб-сервисы с точки зрения пользователя — это всё так же цельные приложения. Для такой «цельной» разработки хорошо подходят фреймворки типа Next.js. Их возможности были сильно ограничены до недавнего времени, но последние версии Next.js и React меняют правила игры.
React представил серверные компоненты, а Next.js их реализовал вместе с новым подходом к роутингу — App Router. По сути, теперь часть React-компонентов выполняются на клиенте, а часть — на сервере, вместе формируя единую веб-страницу. Серверные компоненты могут напрямую работать с базой данных, и слой API становится необязательным — его заменяют механизмы роутинга Next.js. Полноценное веб-приложение становится возможно сделать вообще без бэкенда в старом смысле.
Интересно, что, например, Ruby On Rails — чисто бэкендовый фреймворк — тоже двигает границу разделения, но немного по-другому. Его авторы предлагают подход Hotwire — декомпозицию и стриминг отдельных частей HTML — в качестве альтернативы SPA.
Оба подхода сходятся в одном — значительная часть логики фронтенда выполняется на сервере, при этом мы не теряем преимущества SPA. Таким образом, разделение на клиентскую и серверную части не является эквивалентом разделения на фронтенд и бекенд. Фронтенд — часть приложения, отвечающая за взаимодействие с пользователем и обслуживание этого взаимодействия, в том числе на сервере.
История развивается по спирали. Больше кода снова выполняется на сервере, но теперь мы можем строить клиентские приложения любой сложности и красоты меньшими усилиями и с меньшими побочными эффектами.
Фронтенд на сервере
Когда-то веб-приложения были «бэкендоцентричны»: HTML-страницы генерировались на сервере, а для добавления динамических данных использовались шаблоны.
Со временем требования к интерактивности страниц стали выше, и фронтенд-технологии начали активно развиваться, в частности — подход Single Page Application (SPA). Фреймворки развивались так, что со временем фронтенд стал отдельным приложением, которое отдельно проектируется, разрабатывается отдельными людьми и хостится тоже отдельно.
Это разделение, при своих преимуществах, приводит к нескольким проблемам.
🔹 Код, отправляемый в браузер, становится тяжёлым и растёт при увеличении функциональности приложения.
🔹 Много логики переносится на клиент. Например, роутинг, который реализован заново и «в обход» механизмов браузера.
🔹 Много логики дублируется на фронтенде и бэкенде. Например, валидация и ограничение доступа.
🔹 Необходимо проектировать и разрабатывать API — дополнительный слой синхронизации фронтенда и бэкенда — даже там, где бэкенд выполняет только функции обслуживания интерфейса.
🔹 Разделение специалистов на фронтенд и бэкенд-разработчиков в командах создаёт накладные расходы, размывает понимание итоговой задачи и ответственности.
При этом принципы работы сети и браузеров не изменились: веб-сервисы с точки зрения пользователя — это всё так же цельные приложения. Для такой «цельной» разработки хорошо подходят фреймворки типа Next.js. Их возможности были сильно ограничены до недавнего времени, но последние версии Next.js и React меняют правила игры.
React представил серверные компоненты, а Next.js их реализовал вместе с новым подходом к роутингу — App Router. По сути, теперь часть React-компонентов выполняются на клиенте, а часть — на сервере, вместе формируя единую веб-страницу. Серверные компоненты могут напрямую работать с базой данных, и слой API становится необязательным — его заменяют механизмы роутинга Next.js. Полноценное веб-приложение становится возможно сделать вообще без бэкенда в старом смысле.
Интересно, что, например, Ruby On Rails — чисто бэкендовый фреймворк — тоже двигает границу разделения, но немного по-другому. Его авторы предлагают подход Hotwire — декомпозицию и стриминг отдельных частей HTML — в качестве альтернативы SPA.
Оба подхода сходятся в одном — значительная часть логики фронтенда выполняется на сервере, при этом мы не теряем преимущества SPA. Таким образом, разделение на клиентскую и серверную части не является эквивалентом разделения на фронтенд и бекенд. Фронтенд — часть приложения, отвечающая за взаимодействие с пользователем и обслуживание этого взаимодействия, в том числе на сервере.
История развивается по спирали. Больше кода снова выполняется на сервере, но теперь мы можем строить клиентские приложения любой сложности и красоты меньшими усилиями и с меньшими побочными эффектами.
nextjs.org
Next.js by Vercel - The React Framework
Production grade React applications that scale. The world's leading companies use Next.js by Vercel to build static and dynamic websites and web applications.
🔥5❤3👍3
Сложный выбор
Недавно у нас случился интересный кейс принятия сложного решения. Он натолкнул на мысль вспомнить, как можно действовать в таких ситуациях. Тема баяниста, но повторение — это мать, как говорится.
Было два проекта. Мы планировали их делать друг за другом. Оба одновременно взять не смогли, не хватало рук. И вот когда первый уже подходил к концу, мы получили дополнительные задачи по нему и новые сроки, к которым не были готовы. По второму проекту формальных договорённостей не было, но мы обещали второму заказчику начать в определенный момент.
Перед руководителем проекта встал сложный выбор, он раньше с подобным не сталкивался. Ему кажется, что нельзя не доделать первый проект, но с другой стороны нас ждёт другой заказчик. Показалось, что нужно действовать быстро. В итоге мы поспешно оценили все доработки и быстро согласились продолжать работу над первым проектом.
Стали думать, как преподнести второму заказчику неприятные новости в виде факта, что мы задерживаемся на 2 недели. При длительности проектов в 2-4 недели это существенно.
Можно ли было поступить иначе? Разбор кейса получился объёмным, прочитать его можно здесь.
Интересно узнать ваше мнение. Что ещё можно предпринять или как не допустить подобной ситуации?
#management
Недавно у нас случился интересный кейс принятия сложного решения. Он натолкнул на мысль вспомнить, как можно действовать в таких ситуациях. Тема баяниста, но повторение — это мать, как говорится.
Было два проекта. Мы планировали их делать друг за другом. Оба одновременно взять не смогли, не хватало рук. И вот когда первый уже подходил к концу, мы получили дополнительные задачи по нему и новые сроки, к которым не были готовы. По второму проекту формальных договорённостей не было, но мы обещали второму заказчику начать в определенный момент.
Перед руководителем проекта встал сложный выбор, он раньше с подобным не сталкивался. Ему кажется, что нельзя не доделать первый проект, но с другой стороны нас ждёт другой заказчик. Показалось, что нужно действовать быстро. В итоге мы поспешно оценили все доработки и быстро согласились продолжать работу над первым проектом.
Стали думать, как преподнести второму заказчику неприятные новости в виде факта, что мы задерживаемся на 2 недели. При длительности проектов в 2-4 недели это существенно.
Можно ли было поступить иначе? Разбор кейса получился объёмным, прочитать его можно здесь.
Интересно узнать ваше мнение. Что ещё можно предпринять или как не допустить подобной ситуации?
#management
👍11❤2👏1
#development
AI и Prompt engineering
Проектирование системы, основанной на LLM (Large Language Model), например, GPT, по большей части заключается в проектировании цепочек промптов. Промпт — текстовый запрос на естественном языке — по сути единственный интерфейс к LLM. И чтобы получить нужные результаты, нужно научиться строить корректные и точные запросы.
При этом важно учитывать особенности работы LLM.
🔹 Общение с LLM не хранит состояния и контекста. Всю «историю переписки» нужно передавать каждый раз.
🔹 Размер сообщения и ответа ограничен.
🔹 Результаты могут быть нестабильны. С одной стороны, это нестабильность формата и типа ответа — тут может помочь промпт-инжиниринг. С другой стороны — нестабильность ответов по сути: и к этому нужно готовить пользователей, чтобы они это понимали и правильно относились к результатам. Это задача проектирования UX.
🔹 Модель ограничена данными обучения.
🔹 Галлюцинирование. Без специальных указаний модель попытается дать ответ в любом случае: даже если данных не хватает, она его «придумает». Модель нужно явно инструктировать о том как получить ожидаемый результат. Показывать примеры или давать конкретные инструкции. Иначе может получиться результат, напоминающий требуемый по форме, но некорректный по сути.
Промпт-инжиниринг основан на экспериментах. Нельзя быть уверенным, что задуманный алгоритм сработает.
Нужно непрерывно экспериментировать. Но стабильного идеального результата всё равно не будет :) Остается большая степень непредсказуемости.
Несмотря на это, есть ряд техник, который позволяют достичь достаточно хороших результатов. Например, суммировать историю переписки в короткий текст, чтобы экономить токены или использовать внешние агенты для того чтобы предоставлять данные или заведомо верные решения в модель. Рекомендуем начать с изучения некоторых источников, чтобы сэкономить время на экспериментах:
https://www.promptingguide.ai/
https://www.pinecone.io/learn/langchain/
А часть из техник уже реализованы в фреймворке LangChain.
AI и Prompt engineering
Проектирование системы, основанной на LLM (Large Language Model), например, GPT, по большей части заключается в проектировании цепочек промптов. Промпт — текстовый запрос на естественном языке — по сути единственный интерфейс к LLM. И чтобы получить нужные результаты, нужно научиться строить корректные и точные запросы.
При этом важно учитывать особенности работы LLM.
🔹 Общение с LLM не хранит состояния и контекста. Всю «историю переписки» нужно передавать каждый раз.
🔹 Размер сообщения и ответа ограничен.
🔹 Результаты могут быть нестабильны. С одной стороны, это нестабильность формата и типа ответа — тут может помочь промпт-инжиниринг. С другой стороны — нестабильность ответов по сути: и к этому нужно готовить пользователей, чтобы они это понимали и правильно относились к результатам. Это задача проектирования UX.
🔹 Модель ограничена данными обучения.
🔹 Галлюцинирование. Без специальных указаний модель попытается дать ответ в любом случае: даже если данных не хватает, она его «придумает». Модель нужно явно инструктировать о том как получить ожидаемый результат. Показывать примеры или давать конкретные инструкции. Иначе может получиться результат, напоминающий требуемый по форме, но некорректный по сути.
Промпт-инжиниринг основан на экспериментах. Нельзя быть уверенным, что задуманный алгоритм сработает.
Нужно непрерывно экспериментировать. Но стабильного идеального результата всё равно не будет :) Остается большая степень непредсказуемости.
Несмотря на это, есть ряд техник, который позволяют достичь достаточно хороших результатов. Например, суммировать историю переписки в короткий текст, чтобы экономить токены или использовать внешние агенты для того чтобы предоставлять данные или заведомо верные решения в модель. Рекомендуем начать с изучения некоторых источников, чтобы сэкономить время на экспериментах:
https://www.promptingguide.ai/
https://www.pinecone.io/learn/langchain/
А часть из техник уже реализованы в фреймворке LangChain.
www.promptingguide.ai
Prompt Engineering Guide | Prompt Engineering Guide
A Comprehensive Overview of Prompt Engineering
👍7
#management
Формальное управление vs Реальность
Когда в обсуждении проектов появляются термины «риск», «стратегия минимизации», «ответственность», запал от интересной задачи угасает. Если мы ещё и реестры по шаблону составляем и ответственных за риски назначаем, то совсем 🤢
Причина не в отсутствии желания заниматься управлением. Просто такие разговоры кажутся чем-то искусственным, оторванным от реальности. Мы не говорим в обычной жизни «займёмся планированием» или «надо минимизировать риск». В итоге качество планирования страдает, потому что этим не интересно заниматься всем кроме рук.проекта. Может и ему неинтересно, но так надо.
А ещё формальные рассуждения и применение шаблонов из теории могут легко увести планы от реалистичности. Шаблон заполнили — всё правильно 🫣
Представим проект с несдвигаемым сроком запуска. Где-то в середине разработчикам нужно передать макеты. Обычно из этого получается веха «дизайн согласован». А мы знаем, что с ней бывает. Даже после прохождения вехи комментарии не заканчиваются. В плане появляется риск, что дизайн не будет согласован полностью и вовремя (рядовой риск из шаблонов реестров рисков). И мы пытаемся договориться о его минимизации и ответственности за влияние.
Есть искушение заявить, что клиент отвечает за появление изменений в требованиях после вехи. Если такое произойдёт, может сдвинуться дедлайн. Но в реальности заказчик не может заранее согласиться утвердить то, чего пока не видит. У него резонный вопрос, а мы то, разработчики, за что тогда отвечаем? 🤔
Получится разговор об ответственности, рисках и маловероятных последствиях, в общем об управлении в отрыве от цели. Перекладывать ответственность за результат, который производим мы, — в принципе плохой подход. Поэтому конструктива будет минимум 👎
В лучшем случае нам молча кивнут. Но мы в любом случае не сможем поставить точку где-то в середине проекта. Изменения неизбежны, и это в принципе не риск. Поэтому вместо нравоучений о персональной ответственности лучше проговорить, как будет на самом деле:
«Начинаем согласование дизайна за неделю, а 14 ноября запускаем разработку по имеющимся макетам. Все последующие изменения добавляем в общий бэклог до запуска, согласуем приоритеты и двигаемся дальше. Иначе мы можем не успеть гораздо больше» 👍
С таким планом адекватные люди спорить не будут. Они не скажут: «Нет, не запускаете без согласования». Всем нужен результат в срок. Это целеориентированный подход с разделением ответственности за получение результата, а не перекладыванием её за каждый отдельно взятый риск 🤝
Веху правильнее назвать «старт разработки». План выстраиваем так, чтобы недостаток «согласованности» дизайна не стопорил работу, и непредвиденные изменения не мешали релизить качественный результат в срок. Риски же нужно искать в других местах: интеграциях с внешними сервисами, кардинальных изменениях концепции проекта и пр.
Лучшее управление, когда мы просто говорим, что именно собираемся сделать и почему это поможет нам вместе с заказчиком оптимальнее достичь цели в условиях ограничений. Для этого нужно использовать личный реальный опыт и прислушиваться к опыту членов команды. Ну или быть одарённым и обладать предвидением будущего на основе прошлого, как у Герберта в Дюне.
Как вам такой подход?
Формальное управление vs Реальность
Когда в обсуждении проектов появляются термины «риск», «стратегия минимизации», «ответственность», запал от интересной задачи угасает. Если мы ещё и реестры по шаблону составляем и ответственных за риски назначаем, то совсем 🤢
Причина не в отсутствии желания заниматься управлением. Просто такие разговоры кажутся чем-то искусственным, оторванным от реальности. Мы не говорим в обычной жизни «займёмся планированием» или «надо минимизировать риск». В итоге качество планирования страдает, потому что этим не интересно заниматься всем кроме рук.проекта. Может и ему неинтересно, но так надо.
А ещё формальные рассуждения и применение шаблонов из теории могут легко увести планы от реалистичности. Шаблон заполнили — всё правильно 🫣
Представим проект с несдвигаемым сроком запуска. Где-то в середине разработчикам нужно передать макеты. Обычно из этого получается веха «дизайн согласован». А мы знаем, что с ней бывает. Даже после прохождения вехи комментарии не заканчиваются. В плане появляется риск, что дизайн не будет согласован полностью и вовремя (рядовой риск из шаблонов реестров рисков). И мы пытаемся договориться о его минимизации и ответственности за влияние.
Есть искушение заявить, что клиент отвечает за появление изменений в требованиях после вехи. Если такое произойдёт, может сдвинуться дедлайн. Но в реальности заказчик не может заранее согласиться утвердить то, чего пока не видит. У него резонный вопрос, а мы то, разработчики, за что тогда отвечаем? 🤔
Получится разговор об ответственности, рисках и маловероятных последствиях, в общем об управлении в отрыве от цели. Перекладывать ответственность за результат, который производим мы, — в принципе плохой подход. Поэтому конструктива будет минимум 👎
В лучшем случае нам молча кивнут. Но мы в любом случае не сможем поставить точку где-то в середине проекта. Изменения неизбежны, и это в принципе не риск. Поэтому вместо нравоучений о персональной ответственности лучше проговорить, как будет на самом деле:
«Начинаем согласование дизайна за неделю, а 14 ноября запускаем разработку по имеющимся макетам. Все последующие изменения добавляем в общий бэклог до запуска, согласуем приоритеты и двигаемся дальше. Иначе мы можем не успеть гораздо больше» 👍
С таким планом адекватные люди спорить не будут. Они не скажут: «Нет, не запускаете без согласования». Всем нужен результат в срок. Это целеориентированный подход с разделением ответственности за получение результата, а не перекладыванием её за каждый отдельно взятый риск 🤝
Веху правильнее назвать «старт разработки». План выстраиваем так, чтобы недостаток «согласованности» дизайна не стопорил работу, и непредвиденные изменения не мешали релизить качественный результат в срок. Риски же нужно искать в других местах: интеграциях с внешними сервисами, кардинальных изменениях концепции проекта и пр.
Лучшее управление, когда мы просто говорим, что именно собираемся сделать и почему это поможет нам вместе с заказчиком оптимальнее достичь цели в условиях ограничений. Для этого нужно использовать личный реальный опыт и прислушиваться к опыту членов команды. Ну или быть одарённым и обладать предвидением будущего на основе прошлого, как у Герберта в Дюне.
Как вам такой подход?
👍9❤3🔥1
v0.app
v0 by Vercel - Build Agents, Apps, and Websites with AI
Your collaborative AI assistant to design, iterate, and scale full-stack applications for the web.
#development
v0
v0.dev — хорошее прикладное применение генеративного AI.
Это экспериментальный генератор интерфейсов на React от Vercel.
Инструмент может помочь небольшими усилиями создать функциональные интерфейсы типа форм и личных кабинетов.
Сгенерированные компоненты вполне можно взять за основу просто скопировав код — за счет атомарного подхода Tailwind CSS. UI строится на базе shadcn/ui и выглядит современно и приятно.
v0
v0.dev — хорошее прикладное применение генеративного AI.
Это экспериментальный генератор интерфейсов на React от Vercel.
Инструмент может помочь небольшими усилиями создать функциональные интерфейсы типа форм и личных кабинетов.
Сгенерированные компоненты вполне можно взять за основу просто скопировав код — за счет атомарного подхода Tailwind CSS. UI строится на базе shadcn/ui и выглядит современно и приятно.
🔥11❤1
Хабр
Эффективное автотестирование с Qase: Интеграция Playwright и GitLab CI
Подход к ведению тестовой документации и выбранные для этого инструменты — важная часть процесса разработки, которая напрямую влияет на качество продукта. Особенно важно поддерживать тестовую...
#development
Часто тестовая документация и набор автотестов живут раздельно, каждый развиваясь в своём темпе и не формируя общую картину обеспечения качества.
Наш QA-инженер Наташа написала статью о варианте решения этой проблемы с помощью интеграции Qase с Playwright и GitLab CI
https://habr.com/ru/articles/826008/
Часто тестовая документация и набор автотестов живут раздельно, каждый развиваясь в своём темпе и не формируя общую картину обеспечения качества.
Наш QA-инженер Наташа написала статью о варианте решения этой проблемы с помощью интеграции Qase с Playwright и GitLab CI
https://habr.com/ru/articles/826008/
🔥8👍5❤3
#management
Что не так с грейдами?
Описали, почему мы решили отказаться от грейдов специалистов в небольшой статье: https://vc.ru/dev/1392053-u-nas-v-kompanii-net-greidov-i-eto-prekrasno
Если вкратце:
— В быстро меняющихся обстоятельствах, при работе на разных проектах действительно тяжело поддерживать качественную систему грейдов, учитывать индивидуальные особенности и контекст.
— Привязка к зарплате. Которая де-факто не всегда жестко отражает только формальное соответствие грейду.
— Искусственное деление функций в зависимости от грейда.
— Низкий грейд — плохой стимул для развития.
А как вы относитесь к грейдам? Считаете, что они помогают вам лично и вашей компании? Или больше похоже на карго-культ?
Что не так с грейдами?
Описали, почему мы решили отказаться от грейдов специалистов в небольшой статье: https://vc.ru/dev/1392053-u-nas-v-kompanii-net-greidov-i-eto-prekrasno
Если вкратце:
— В быстро меняющихся обстоятельствах, при работе на разных проектах действительно тяжело поддерживать качественную систему грейдов, учитывать индивидуальные особенности и контекст.
— Привязка к зарплате. Которая де-факто не всегда жестко отражает только формальное соответствие грейду.
— Искусственное деление функций в зависимости от грейда.
— Низкий грейд — плохой стимул для развития.
А как вы относитесь к грейдам? Считаете, что они помогают вам лично и вашей компании? Или больше похоже на карго-культ?
vc.ru
У нас в компании нет грейдов — и это прекрасно
Как мы в SmartHead разрабатываем сложные проекты без деления сотрудников на джунов, миддлов и синьоров, и почему отсутствие грейдов помогает нам втаскивать задачи и работать с удовольствием
🔥9👍2
Хабр
Качество на каждом уровне: мой подход к роли QA
Моя первая статья об интеграции Playwright и GitLab CI в Qase получилась довольно формальной. Переживания о ней были огромными: я хотела сделать ее «правильной» и, самое главное, доступной...
#development
В новой статье Наташа предлагает подход к роли QA, который охватывает разные направления и всю широту влияния QA на разработку.
https://habr.com/ru/articles/845890/
В новой статье Наташа предлагает подход к роли QA, который охватывает разные направления и всю широту влияния QA на разработку.
https://habr.com/ru/articles/845890/
🔥7👍4❤🔥3
Хабр
Как QA не утонуть в новом проекте. Часть 1: гайд, советы и ChatGPT
Привет, это Наташа из SmartHead! Как начать работу над проектом, написать тестовую документацию, понять, когда и как переходить к автоматизации… и выжить? Работа QA всегда связана с множеством...
#development
Наташа начала серию статей об организации работы QA-инженера с использованием ChatGPT.
В первой — про самоонбординг в новом проекте.
https://habr.com/ru/articles/902702/
Наташа начала серию статей об организации работы QA-инженера с использованием ChatGPT.
В первой — про самоонбординг в новом проекте.
https://habr.com/ru/articles/902702/
❤🔥10👍2🔥2
Запустили наш pet project — onbalance (https://onbalance.app)
Это бесплатный кешфлоу-планировщик и трекер финансов для микропредпринимателей, фрилансеров, креаторов и всех, кто ведёт небольшой бизнес или сайд-проект.
Удобная и безопасная альтернатива заметкам и гугл-таблицам, когда операций немного, но важно вести конфиденциальный учёт и видеть финансовый прогноз.
Фишки:
— Конфиденциальность by design — как в пассворд-менеджерах и крипто-кошельках. Данные только у вас.
— Нет обязательных полей (кроме суммы:)),
— Оффлайн-first и mobile native 😎 Быстро и приятно пользоваться.
📢 Мы только что вышли на Product Hunt и нам очень поможет ваша поддержка 🙌
https://www.producthunt.com/products/onbalance?utm_source=telegram&utm_medium=social
Это бесплатный кешфлоу-планировщик и трекер финансов для микропредпринимателей, фрилансеров, креаторов и всех, кто ведёт небольшой бизнес или сайд-проект.
Удобная и безопасная альтернатива заметкам и гугл-таблицам, когда операций немного, но важно вести конфиденциальный учёт и видеть финансовый прогноз.
Фишки:
— Конфиденциальность by design — как в пассворд-менеджерах и крипто-кошельках. Данные только у вас.
— Нет обязательных полей (кроме суммы:)),
— Оффлайн-first и mobile native 😎 Быстро и приятно пользоваться.
📢 Мы только что вышли на Product Hunt и нам очень поможет ваша поддержка 🙌
https://www.producthunt.com/products/onbalance?utm_source=telegram&utm_medium=social
onbalance.app
Privacy-first free cash flow planning app for solopreneurs and family businesses who value trust and privacy
🔥13❤4