Привет!
Здесь мы делимся подходами и практиками в менеджменте #management и разработке #development. Опытом компании, tips and tricks.
Послушать наши голоса можно в подкасте SmartHead Space 🎙
Стать частью команды SmartHead 👉 https://smarthead.ru/#vacancies
По организационным вопросам — @doctorsolberg
Здесь мы делимся подходами и практиками в менеджменте #management и разработке #development. Опытом компании, tips and tricks.
Послушать наши голоса можно в подкасте SmartHead Space 🎙
Стать частью команды SmartHead 👉 https://smarthead.ru/#vacancies
По организационным вопросам — @doctorsolberg
Telegram
SmartHead Space
Привет! Это подкаст про развитие в IT и за ее пределами.
Канал, где собраны наши лучшие практики в менеджменте и разработке 👉 https://t.me/smarthead
Канал, где собраны наши лучшие практики в менеджменте и разработке 👉 https://t.me/smarthead
#development
Ни для кого сейчас не новость, что пользовательский опыт (UX, опыт взаимодействия) важен. Важно не только что можно делать с помощью продукта, но и как — насколько просто и удобно. Хороший UX в интерфейсах ведёт пользователя к решению задачи, помогает не отвлекаться на борьбу с неудобным интерфейсом, снижает когнитивную нагрузку, формирует положительное эмоциональное подкрепление.
Developer Experience (DX) — это частный случай UX, когда в качестве пользователя выступает разработчик, а в качестве продукта — язык программирования, фреймворк, технология, сервис или любой другой инструмент.
Продукт с хорошим DX ведёт разработчика, даёт возможность сфокусироваться на решении задачи, а не возиться в конфигурации инструмента. Хороший DX повышает удобство и скорость разработки, даёт уверенность в отсутствии ошибок и комфорт в работе.
Ни для кого сейчас не новость, что пользовательский опыт (UX, опыт взаимодействия) важен. Важно не только что можно делать с помощью продукта, но и как — насколько просто и удобно. Хороший UX в интерфейсах ведёт пользователя к решению задачи, помогает не отвлекаться на борьбу с неудобным интерфейсом, снижает когнитивную нагрузку, формирует положительное эмоциональное подкрепление.
Developer Experience (DX) — это частный случай UX, когда в качестве пользователя выступает разработчик, а в качестве продукта — язык программирования, фреймворк, технология, сервис или любой другой инструмент.
Продукт с хорошим DX ведёт разработчика, даёт возможность сфокусироваться на решении задачи, а не возиться в конфигурации инструмента. Хороший DX повышает удобство и скорость разработки, даёт уверенность в отсутствии ошибок и комфорт в работе.
#development
Что отличает инструмент с хорошим DX?
— Быстрый старт. Он не требует много времени в начале, а погружает по мере необходимости.
— Отличная документация. Понятный quick start, хорошая структура, полнота и актуальность.
— Хорошая коммуникация с пользователем через интерфейсы взаимодействия, в том числе cli и API.
— Адекватные параметры по умолчанию. Инструмент не требует большой конфигурации, возможно следует принципу Convention over Configuration. Он не заставляет разработчика принимать решения там, где это не требуется. А там, где требуется изменить поведение по умолчанию, даёт возможность это сделать.
— Следование стандартам индустрии и идиомам платформы. Стиль кода или наименование методов в API не вызывают удивления.
— Open source и использование возможностей сообщества разработчиков.
Хорошим DX следует не только пользоваться, но и производить самим. При разработке стоит задумываться о DX и разработчиках, которые пользуются нашим кодом.
Что отличает инструмент с хорошим DX?
— Быстрый старт. Он не требует много времени в начале, а погружает по мере необходимости.
— Отличная документация. Понятный quick start, хорошая структура, полнота и актуальность.
— Хорошая коммуникация с пользователем через интерфейсы взаимодействия, в том числе cli и API.
— Адекватные параметры по умолчанию. Инструмент не требует большой конфигурации, возможно следует принципу Convention over Configuration. Он не заставляет разработчика принимать решения там, где это не требуется. А там, где требуется изменить поведение по умолчанию, даёт возможность это сделать.
— Следование стандартам индустрии и идиомам платформы. Стиль кода или наименование методов в API не вызывают удивления.
— Open source и использование возможностей сообщества разработчиков.
Хорошим DX следует не только пользоваться, но и производить самим. При разработке стоит задумываться о DX и разработчиках, которые пользуются нашим кодом.
#development #management
В своей работе мы особое внимание уделяем качеству. О подходе к его обеспечению рассказал наш технический директор Рамиль Аминов.
https://habr.com/ru/post/549130/
В своей работе мы особое внимание уделяем качеству. О подходе к его обеспечению рассказал наш технический директор Рамиль Аминов.
https://habr.com/ru/post/549130/
Хабр
Качество вместо контроля качества
Говоря о качестве, обычно имеют ввиду некое соответствие требованиям. Часто под требованиями подразумевают те, что явно выдвинул заказчик, аналитик или кто-то другой, кто ставит задачи. Хуже, если они...
👍2
#development
Бывает, что разработчику жалко выкинуть или переписать свой код. Он шел к нему, писал, тратил своё время. К тому же, задача в таск-трекере сделана и закрыта.
Но в реальности невозможно избежать изменений. Не только потому, что сложно сделать хорошо с первого раза. А потому, что изменения и развитие в «живых» проектах и продуктах — это необходимость. Если не улучшать продукт, то отстанешь от конкурентов.
Цель разработки — не в написании кода самого по себе, а в решении с помощью него более высокоуровневых задач. Код должен иметь достаточную гибкость и устойчивость к изменениям, чтобы новые задачи можно было решать проще.
Не стоит рассматривать кодовую базу как нечто, что мы построили и сдали. Нужно относиться к ней как к среде, в которой мы живём. Нужно её обустраивать, делать комфортной и удобной для работы, не захламлять и оставлять место для чего-то нового.
В такой парадигме и выкидывать код, как старый хлам, приятно.
Бывает, что разработчику жалко выкинуть или переписать свой код. Он шел к нему, писал, тратил своё время. К тому же, задача в таск-трекере сделана и закрыта.
Но в реальности невозможно избежать изменений. Не только потому, что сложно сделать хорошо с первого раза. А потому, что изменения и развитие в «живых» проектах и продуктах — это необходимость. Если не улучшать продукт, то отстанешь от конкурентов.
Цель разработки — не в написании кода самого по себе, а в решении с помощью него более высокоуровневых задач. Код должен иметь достаточную гибкость и устойчивость к изменениям, чтобы новые задачи можно было решать проще.
Не стоит рассматривать кодовую базу как нечто, что мы построили и сдали. Нужно относиться к ней как к среде, в которой мы живём. Нужно её обустраивать, делать комфортной и удобной для работы, не захламлять и оставлять место для чего-то нового.
В такой парадигме и выкидывать код, как старый хлам, приятно.
👍2
#development
Наш друг и партнер Максим Аршинов опубликовал классную статью. Она про то, как делать MVP быстро и достаточно качественно, чтобы потом не выкидывать. Один из подходов — использовать максимум готовых решений. Вот и мы ссылку даем, а не свое пишем 🙂
Хочется отметить важный тезис об Impact mapping. Часто сталкиваемся с тем, что недостаточно четкое и трассируемое понимание конечных бизнес-целей приводит к «плохим» требованиям. Они, в свою очередь, приводят к «плохому» продукту, который дольше разрабатывать и сложнее развивать.
Работая над новыми продуктами, мы должны понимать, как каждая конкретная фича явным образом связана с достижением конечной бизнес-цели?
А еще про качество в MVP мы говорили с Максимом в подкасте SmartHead Space. Если послушать удобнее чем прочитать, то держите ссылки: Яндекс.Музыка, Apple Podcast и SoundCloud.
Наш друг и партнер Максим Аршинов опубликовал классную статью. Она про то, как делать MVP быстро и достаточно качественно, чтобы потом не выкидывать. Один из подходов — использовать максимум готовых решений. Вот и мы ссылку даем, а не свое пишем 🙂
Хочется отметить важный тезис об Impact mapping. Часто сталкиваемся с тем, что недостаточно четкое и трассируемое понимание конечных бизнес-целей приводит к «плохим» требованиям. Они, в свою очередь, приводят к «плохому» продукту, который дольше разрабатывать и сложнее развивать.
Работая над новыми продуктами, мы должны понимать, как каждая конкретная фича явным образом связана с достижением конечной бизнес-цели?
А еще про качество в MVP мы говорили с Максимом в подкасте SmartHead Space. Если послушать удобнее чем прочитать, то держите ссылки: Яндекс.Музыка, Apple Podcast и SoundCloud.
Хабр
Как запустить MVP и не превратить его в технический долг
Последние пять лет я работаю в аутсорсинге, поэтому часто занимаюсь запуском новых продуктов. Чаще всего жизненный цикл создаваемых нами приложения начинается с разработки так называемого MVP (...
👍1
Выразительность как основа надежности кода
#development
Запись познавательного завтрака от нашего CTO Рамиля о мыслительных и практических приемах (на TypeScript), которые позволяют сделать код более надёжным через выразительность. Выразительный код проще понимать, изменять и рассуждать о его корректности.
#development
Запись познавательного завтрака от нашего CTO Рамиля о мыслительных и практических приемах (на TypeScript), которые позволяют сделать код более надёжным через выразительность. Выразительный код проще понимать, изменять и рассуждать о его корректности.
👍7❤🔥3🔥2👏1
#development #management
Об излишней декомпозиции
Принято считать, что декомпозиция — это хорошо. Она действительно полезна: позволяет устранить неопределённость — разбить большую непонятную задачу так, чтобы можно было охватить её частями. В процессе разбиения мы лучше понимаем состав работ и даже по ходу занимаемся проектированием.
Но излишняя декомпозиция может быть опасна. Она создаёт иллюзию, что фича состоит только из технических задач, на которые мы её разбили.
🔹 Декомпозиция — это накладные расходы. Не только на создание и работу с отдельными задачами, но и на то, что задачи нужно делать отдельно: поддерживать отдельный жизненный цикл, реализовывать и выкатывать по отдельности.
🔹 Искусственная необходимость декомпозиции может приводить к преждевременному проектированию и планированию. Для того, чтобы декомпозировать, нужно спроектировать. Но часто на старте недостаточно информации для проектирования и мы делаем «как-то». Но потом не переделываем по мере поступления информации. Ведь мы же уже декомпозировали, надо делать!
🔹 Декомпозиция создает иллюзию контроля. Сделал половину подзадач — значит сделал полфичи. Сделал все подзадачи — сделал целиком. Это не так. Чтобы сделать фичу, недостаточно сделать все её подзадачи. Фича обычно больше, чем совокупность подзадач. Результаты подзадач ещё нужно собрать — и понять, что фича целиком выполнена. Есть эмерджентность — ценность, которую даёт совокупность результатов подзадач, и которой нет в простой сумме этих результатов. Чтобы фича была сделана, эта ценность должна быть тоже реализована.
🔹 Часто декомпозиция просто не имеет смысла. Например, фича достаточно простая и её можно сделать целиком «за один присест».
Декомпозиция фичи уместна, когда мы её разделяем по принципу поставки: на части, которые сами по себе являются конечным результатом с точки зрения продукта или сценария использования.
Не нужно декомпозировать фичу на работы (например, «разработать фронтенд», «разработать бэкенд», «написать миграцию»), лучше декомпозировать на отдельные «куски ценности».
Декомпозиция не должна быть заменой документации или описанию задачи. Из описания должно быть понятно, что должно быть результатом и что нужно не забыть. Но не обязательно каждый из этих пунктов должен быть отдельной подзадачей.
Другой случай, когда задача сформулирована не в виде ценности, а в виде работы, которую нужно выполнить. Её бывает уместно декомпозировать на независимые подработы.
При кажущейся очевидности пользы декомпозиции, она легко может стать «пятой ногой». Как и любой другой инструмент управления, её стоит использовать осознанно.
Об излишней декомпозиции
Принято считать, что декомпозиция — это хорошо. Она действительно полезна: позволяет устранить неопределённость — разбить большую непонятную задачу так, чтобы можно было охватить её частями. В процессе разбиения мы лучше понимаем состав работ и даже по ходу занимаемся проектированием.
Но излишняя декомпозиция может быть опасна. Она создаёт иллюзию, что фича состоит только из технических задач, на которые мы её разбили.
🔹 Декомпозиция — это накладные расходы. Не только на создание и работу с отдельными задачами, но и на то, что задачи нужно делать отдельно: поддерживать отдельный жизненный цикл, реализовывать и выкатывать по отдельности.
🔹 Искусственная необходимость декомпозиции может приводить к преждевременному проектированию и планированию. Для того, чтобы декомпозировать, нужно спроектировать. Но часто на старте недостаточно информации для проектирования и мы делаем «как-то». Но потом не переделываем по мере поступления информации. Ведь мы же уже декомпозировали, надо делать!
🔹 Декомпозиция создает иллюзию контроля. Сделал половину подзадач — значит сделал полфичи. Сделал все подзадачи — сделал целиком. Это не так. Чтобы сделать фичу, недостаточно сделать все её подзадачи. Фича обычно больше, чем совокупность подзадач. Результаты подзадач ещё нужно собрать — и понять, что фича целиком выполнена. Есть эмерджентность — ценность, которую даёт совокупность результатов подзадач, и которой нет в простой сумме этих результатов. Чтобы фича была сделана, эта ценность должна быть тоже реализована.
🔹 Часто декомпозиция просто не имеет смысла. Например, фича достаточно простая и её можно сделать целиком «за один присест».
Декомпозиция фичи уместна, когда мы её разделяем по принципу поставки: на части, которые сами по себе являются конечным результатом с точки зрения продукта или сценария использования.
Не нужно декомпозировать фичу на работы (например, «разработать фронтенд», «разработать бэкенд», «написать миграцию»), лучше декомпозировать на отдельные «куски ценности».
Декомпозиция не должна быть заменой документации или описанию задачи. Из описания должно быть понятно, что должно быть результатом и что нужно не забыть. Но не обязательно каждый из этих пунктов должен быть отдельной подзадачей.
Другой случай, когда задача сформулирована не в виде ценности, а в виде работы, которую нужно выполнить. Её бывает уместно декомпозировать на независимые подработы.
При кажущейся очевидности пользы декомпозиции, она легко может стать «пятой ногой». Как и любой другой инструмент управления, её стоит использовать осознанно.
Wikipedia
Эмерджентность
Эмердже́нтность или эмерге́нтность (англиц. от emergent «возникающий, неожиданно появляющийся») в теории систем — наличие у системы свойств, не присущих её компонентам по отдельности; несводимость свойств системы к сумме свойств её компонентов.
👍7❤2🤔1
Программирование типов в TypeScript
#development
TypeScript избавляет нас от многих проблем с безопасностью типов, которые могут возникать в JavaScript-коде.
Но часто его используют не на полную мощность.
Система типов в TypeScript — отдельное поле для проектирования и программирования, которое позволяет на порядки улучшить безопасность и Developer Experience прикладного кода.
21 июня в 11:00 наш CTO Рамиль проведет познавательный завтрак «Программирование типов в TypeScript».
Рассмотрим примеры магии, которую можно сделать на типах своими руками.
Принимайте участие интерактивно в Zoom или смотрите трансляцию на нашем YouTube-канале.
#development
TypeScript избавляет нас от многих проблем с безопасностью типов, которые могут возникать в JavaScript-коде.
Но часто его используют не на полную мощность.
Система типов в TypeScript — отдельное поле для проектирования и программирования, которое позволяет на порядки улучшить безопасность и Developer Experience прикладного кода.
21 июня в 11:00 наш CTO Рамиль проведет познавательный завтрак «Программирование типов в TypeScript».
Рассмотрим примеры магии, которую можно сделать на типах своими руками.
Принимайте участие интерактивно в Zoom или смотрите трансляцию на нашем YouTube-канале.
🔥13
#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
#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
v0.app
v0 by Vercel - Build Full-Stack Web Apps 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❤2
#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
#development
В новой статье Наташа предлагает подход к роли QA, который охватывает разные направления и всю широту влияния QA на разработку.
https://habr.com/ru/articles/845890/
В новой статье Наташа предлагает подход к роли QA, который охватывает разные направления и всю широту влияния QA на разработку.
https://habr.com/ru/articles/845890/
🔥7👍4❤🔥3
#development
Наташа начала серию статей об организации работы QA-инженера с использованием ChatGPT.
В первой — про самоонбординг в новом проекте.
https://habr.com/ru/articles/902702/
Наташа начала серию статей об организации работы QA-инженера с использованием ChatGPT.
В первой — про самоонбординг в новом проекте.
https://habr.com/ru/articles/902702/
❤🔥10👍2🔥2