Мы уже познакомились с Себастьяном Рамирез по библиотеке SQLModel, но это не самая популярная библиотека у Себастьяна. Фреймворк FastAPI — это быстро набирающий популярность инструмент для разработки HTTP сервисов на Python. FastAPI из коробки дает тайпинг для валидации данных вкупе с библиотекой pydantic, автогенерацией openapi спецификации и много приятных мелочей. Была затронута и тема популярности: для примера, у фреймворка Django сейчас — 60к звезд на GitHub, а у FastAPI — 37к.
https://github.com/tiangolo/fastapi
#rdclr_backend #python #read
https://github.com/tiangolo/fastapi
#rdclr_backend #python #read
GitHub
GitHub - fastapi/fastapi: FastAPI framework, high performance, easy to learn, fast to code, ready for production
FastAPI framework, high performance, easy to learn, fast to code, ready for production - fastapi/fastapi
RTKQuery, как инструмент общения с API
На одном из проектов используем именно его. Плюсы:
- является частью Redux Toolkit — который мы уже используем для хранилища;
- поддержка React Native — хороший задел на будущее;
- генерация React hooks — буквально вчера вышел в релиз кодогенератор v1.0 см документацию (https://redux-toolkit.js.org/rtk-query/usage/code-generation);
- полная поддержка Typescript;
- отслеживание статуса запросов — плюс не нужно писать мидлвары для асинхронных запросов;
- возможность преобразования полученных ответов;
- встроенный кэш: по-умолчанию данные хранятся в памяти, пока на него существует подписка, например, при анмаунте компонента кэш очистится спустя минуту;
- система инвалидации кэша: мы можем связать различные эндпоинты между собой, чтобы при PATCH/POST запросе автоматически происходил refetch (например, постим в список — список обновляется);
- и многое другое.
Почитать обзорный материал можно тут: https://redux-toolkit.js.org/rtk-query/overview
#rdclr_frontend #React #product #read #library
На одном из проектов используем именно его. Плюсы:
- является частью Redux Toolkit — который мы уже используем для хранилища;
- поддержка React Native — хороший задел на будущее;
- генерация React hooks — буквально вчера вышел в релиз кодогенератор v1.0 см документацию (https://redux-toolkit.js.org/rtk-query/usage/code-generation);
- полная поддержка Typescript;
- отслеживание статуса запросов — плюс не нужно писать мидлвары для асинхронных запросов;
- возможность преобразования полученных ответов;
- встроенный кэш: по-умолчанию данные хранятся в памяти, пока на него существует подписка, например, при анмаунте компонента кэш очистится спустя минуту;
- система инвалидации кэша: мы можем связать различные эндпоинты между собой, чтобы при PATCH/POST запросе автоматически происходил refetch (например, постим в список — список обновляется);
- и многое другое.
Почитать обзорный материал можно тут: https://redux-toolkit.js.org/rtk-query/overview
#rdclr_frontend #React #product #read #library
redux-toolkit.js.org
Code Generation | Redux Toolkit
RTK Query > Usage > Code Generation: automated creation of API code
Redux Toolkit createSlice — функция, которая помогает писать редьюсеры проще
Предлагаю взглянуть на демо крохотного приложения с использованием createSlice:
https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/index.tsx
Слева мы можем добавлять/удалять записи.
Справа отображается лог наших действий.
Вся логика реализована через 2 слайса:
contactsSlice https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/store/features/contactsSlice.ts
loggerSlice https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/store/features/loggerSlice.ts
Для создания слайса мы указываем название, начальное состояние и редьюсеры:
Кроме того, мы можем указать extraReducers, что бы «ловить» действия от других слайсов. см. loggerSlice
Как вы могли заметить, при описании редьюсеров мы «мутируем состояние». Но на самом деле это не так.
Redux Toolkit использует под капотом Immer (https://immerjs.github.io/immer/).
Который в свою очередь отслеживает все мутации, а затем возвращает новое (не мутированное) состояние.
Например, вот редьюсер без Immer:
А вот с использованием Immer:
Как я и сказал, это позволяет писать редьюсеры проще.
Любые вопросы и критика приветствуется.
Как вы реализовали бы функцию отмены конкретного действия в логгере (см. демо)?
#rdclr_frontend #React #product #read #library #redux
Предлагаю взглянуть на демо крохотного приложения с использованием createSlice:
https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/index.tsx
Слева мы можем добавлять/удалять записи.
Справа отображается лог наших действий.
Вся логика реализована через 2 слайса:
contactsSlice https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/store/features/contactsSlice.ts
loggerSlice https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/store/features/loggerSlice.ts
Для создания слайса мы указываем название, начальное состояние и редьюсеры:
export const someSlice = createSlice({
name,
initialState,
reducers,
});Кроме того, мы можем указать extraReducers, что бы «ловить» действия от других слайсов. см. loggerSlice
Как вы могли заметить, при описании редьюсеров мы «мутируем состояние». Но на самом деле это не так.
Redux Toolkit использует под капотом Immer (https://immerjs.github.io/immer/).
Который в свою очередь отслеживает все мутации, а затем возвращает новое (не мутированное) состояние.
Например, вот редьюсер без Immer:
function handwrittenReducer(state, action) {
return {
...state,
first: {
...state.first,
second: {
...state.first.second,
[action.someId]: {
...state.first.second[action.someId],
fourth: action.someValue
}
}
}
}
}А вот с использованием Immer:
function reducerWithImmer(state, action) {
state.first.second[action.someId].fourth = action.someValue
}Как я и сказал, это позволяет писать редьюсеры проще.
Любые вопросы и критика приветствуется.
Как вы реализовали бы функцию отмены конкретного действия в логгере (см. демо)?
#rdclr_frontend #React #product #read #library #redux
CodeSandbox
todo-list-logger - CodeSandbox
todo-list-logger by gormonn using @reduxjs/toolkit, @types/faker, @types/object-hash, @types/react-redux, @types/styled-components, faker, localforage, object-hash, react
Суть в том, что существует «старый добрый» способ описания хранилища состояний при помощи обычного react-redux.
Проблема старого способа в том, что приходилось писать очень много шаблонного кода (на жаргоне — бойлерплейта).
За это его постоянно ругали разработчики всех мастей.
Но затем вышел Redux Toolkit, который создан специально для решения данной проблемы.
Мы можем создавать все те же хранилища состояний, но при этом писать гораздо меньше кода, по сравнению с react-redux.
Однако реалии таковы, что это все же новый инструмент со своими нюансами, поэтому редко кто-то перепрыгивает
с react-redux на ReduxToolKit прямо на ходу.
#rdclr_frontend #React #product #read #library #redux
Проблема старого способа в том, что приходилось писать очень много шаблонного кода (на жаргоне — бойлерплейта).
За это его постоянно ругали разработчики всех мастей.
Но затем вышел Redux Toolkit, который создан специально для решения данной проблемы.
Мы можем создавать все те же хранилища состояний, но при этом писать гораздо меньше кода, по сравнению с react-redux.
Однако реалии таковы, что это все же новый инструмент со своими нюансами, поэтому редко кто-то перепрыгивает
с react-redux на ReduxToolKit прямо на ходу.
#rdclr_frontend #React #product #read #library #redux
Генерация клиента из OpenAPI
Если ваш бэкенд использует Swagger (OpenApi 3.0) для генерации документации, то вы можете знатно упростить себе жизнь на крупном проекте.
Однако это упрощение идет дальше типичного чтения документации. Прямо сейчас вы можете генерировать Клиент, Сервер и Типы данных для TypeScript из файла openapi schema.
🎁 Пакет для генерации Клиента: https://github.com/OpenAPITools/openapi-generator-cli
Установка:
yarn add @openapitools/openapi-generator-cli
либо
npm install @openapitools/openapi-generator-cli
1️⃣ Предварительно создайте папку для результатов генерации и файл конфигурации.
2️⃣ После установки вам нужно создать файл конфигурации openapitools.json для генератора и папку для хранения результатов
openapitools.json:
generated-api/models — здесь хранятся типы данных и функции для трансформации данных бэк->фронт фронт->бэк
generated-api/apis — здесь вы найдете сгрупированные по эндпоинтам классы для запросов к API
В идеале этого хватает для полноценного использования.
Однако, в случаях, когда ваш проект еще недостаточно стабилен, хорошая практика — использовать сгенерированный код, как референс.
Вы потратите меньше усилий на поддержке актуальности кода, т.к. проще сделать diff между двумя каталогами, чем вносить все изменения в модели вручную.
🦷 Если вам необходимы только типы для TypeScript, может подойти пакет: https://github.com/drwpow/openapi-typescript
Полный список генераторов вы найдёте здесь: https://openapi-generator.tech/docs/generators
#rdclr_frontend #React #product #read #library
Если ваш бэкенд использует Swagger (OpenApi 3.0) для генерации документации, то вы можете знатно упростить себе жизнь на крупном проекте.
Однако это упрощение идет дальше типичного чтения документации. Прямо сейчас вы можете генерировать Клиент, Сервер и Типы данных для TypeScript из файла openapi schema.
🎁 Пакет для генерации Клиента: https://github.com/OpenAPITools/openapi-generator-cli
Установка:
yarn add @openapitools/openapi-generator-cli
либо
npm install @openapitools/openapi-generator-cli
1️⃣ Предварительно создайте папку для результатов генерации и файл конфигурации.
2️⃣ После установки вам нужно создать файл конфигурации openapitools.json для генератора и папку для хранения результатов
openapitools.json:
{
"$schema": "node_modules/@openapitools/openapi-generator-cli/config.schema.json",
"spaces": 2,
"generator-cli": {
"version": "5.1.1",
"generators": {
"v1": {
"generatorName": "typescript-fetch",
"inputSpec": "link_or_path_to_yours_openapi_schema",
"output": "path_to_yours_output",
"additionalProperties": {
"supportsES6": true,
"sagasAndRecords": true,
"typescriptThreePlus": true,
"withInterfaces": true,
"withoutRuntimeChecks": false
}
}
}
}
}
```3️⃣ Затем запустите процесс генерации командой:
```yarn openapi-generator-cli generate
4️⃣ В результате мы получим:generated-api/models — здесь хранятся типы данных и функции для трансформации данных бэк->фронт фронт->бэк
generated-api/apis — здесь вы найдете сгрупированные по эндпоинтам классы для запросов к API
В идеале этого хватает для полноценного использования.
Однако, в случаях, когда ваш проект еще недостаточно стабилен, хорошая практика — использовать сгенерированный код, как референс.
Вы потратите меньше усилий на поддержке актуальности кода, т.к. проще сделать diff между двумя каталогами, чем вносить все изменения в модели вручную.
🦷 Если вам необходимы только типы для TypeScript, может подойти пакет: https://github.com/drwpow/openapi-typescript
Полный список генераторов вы найдёте здесь: https://openapi-generator.tech/docs/generators
#rdclr_frontend #React #product #read #library
Всем привет! Наступил декабрь, а это значит, что скоро Новый год. В преддверии этого праздника на просторах интернета часто появляются различные мини-игры, акции, забавные дудлы и тому подобное.
К счастью для нас, сфера разработки не исключение. Уже не первый год энтузиаст Eric Wastl разрабатывает адвент-календарь, суть которого в решении серии небольших программных головоломок различного уровня сложности. Каждый день, начиная с 1 декабря и заканчивая Новым годом, вам предоставляется новая задача, которую вы можете решить на вашем любимом языке программирования. Само собой начальные задачи не представляют какой-либо сложности и решаются довольно просто, но чем ближе 31 декабря, тем всё больше усилий от вас будет требовать этот мини-квест.
Предлагаю вам проверить свои силы и присоединиться к этому чиловому соревнованию!
Ссылка на календарь: https://adventofcode.com/
#read
К счастью для нас, сфера разработки не исключение. Уже не первый год энтузиаст Eric Wastl разрабатывает адвент-календарь, суть которого в решении серии небольших программных головоломок различного уровня сложности. Каждый день, начиная с 1 декабря и заканчивая Новым годом, вам предоставляется новая задача, которую вы можете решить на вашем любимом языке программирования. Само собой начальные задачи не представляют какой-либо сложности и решаются довольно просто, но чем ближе 31 декабря, тем всё больше усилий от вас будет требовать этот мини-квест.
Предлагаю вам проверить свои силы и присоединиться к этому чиловому соревнованию!
Ссылка на календарь: https://adventofcode.com/
#read
Spring framework: под капотом
До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.
Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.
У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.
Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU
#rdclr_backend #java #read
До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.
Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.
У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.
Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU
#rdclr_backend #java #read
Java. Какую версию выбрать?
Начиная с 2017 года релизная политика версий java в корне поменялась. Вместо продолжительных застоев в несколько лет с накоплением большого количества фич, было принято решение перейти на релизы каждые полгода, выпуская маленькими партиями новый функционал. Если раньше можно было выбрать просто 8 версию, которая являлась LTS, и не прогадать с выбором, то теперь версий стало куда больше (на текущий момент уже 17). В связи с этим у многих новичков встает очевидный вопрос: как выбрать версию джавы? Может я просто возьму последнюю и все? Не совсем так, давайте разбираться.
Основным провайдером java является компания Oracle, которая предоставляет нам 2 типа jdk: OpenJdk и OracleJdk. Основное их отличие в том, что OracleJdk является платной и содержит в себе поддержку от самой компании (вы сможете им позвонить или написать письмо), если у вас возникнут какие-то проблемы. Такой вариант обычно необходим только очень большим продуктам и компаниям, поэтому мы его отбрасываем и будем пользоваться бесплатной версией. Скачать её можно тут – http://jdk.java.net
Теперь про версионность. Основной выбор всегда падает на LTS (Long Time Support) версии java, так как из-за долгой поддержки и исправления багов эти версии наиболее стабильны и преподносят меньшее число сюрпризов в продакшне. На текущий момент в мире все еще преобладает использование java 8, которая вышла в 2014 году. В основном это связано с тем, что на этой версии уже написаны крайне массивные продукты, которые потребуют больших трудозатрат и средств для переноса на более новые версии. А так как эти огромные продукты продолжают жить, то продолжает жить и java 8.
Для новых решений зачастую берется просто последняя LTS версия джавы. Да, вот так вот просто! До недавнего времени это была java 11, на текущий момент java 17. Но так как 17 версия все еще очень молодая (ей всего пару месяцев), я бы рекомендовал вам пока что выбрать 11 версию для изучения, так как не все еще основные инструменты и библиотеки успели переехать на новый релиз.
Также предлагаю вам посмотреть наикрутейшее выступление Тагира Валеева на JockerConf про то, как менялась java под капотом с 9 по 14 версию. https://youtu.be/5Y0Alqb9H_I
#rdclr_backend #java #read
Начиная с 2017 года релизная политика версий java в корне поменялась. Вместо продолжительных застоев в несколько лет с накоплением большого количества фич, было принято решение перейти на релизы каждые полгода, выпуская маленькими партиями новый функционал. Если раньше можно было выбрать просто 8 версию, которая являлась LTS, и не прогадать с выбором, то теперь версий стало куда больше (на текущий момент уже 17). В связи с этим у многих новичков встает очевидный вопрос: как выбрать версию джавы? Может я просто возьму последнюю и все? Не совсем так, давайте разбираться.
Основным провайдером java является компания Oracle, которая предоставляет нам 2 типа jdk: OpenJdk и OracleJdk. Основное их отличие в том, что OracleJdk является платной и содержит в себе поддержку от самой компании (вы сможете им позвонить или написать письмо), если у вас возникнут какие-то проблемы. Такой вариант обычно необходим только очень большим продуктам и компаниям, поэтому мы его отбрасываем и будем пользоваться бесплатной версией. Скачать её можно тут – http://jdk.java.net
Теперь про версионность. Основной выбор всегда падает на LTS (Long Time Support) версии java, так как из-за долгой поддержки и исправления багов эти версии наиболее стабильны и преподносят меньшее число сюрпризов в продакшне. На текущий момент в мире все еще преобладает использование java 8, которая вышла в 2014 году. В основном это связано с тем, что на этой версии уже написаны крайне массивные продукты, которые потребуют больших трудозатрат и средств для переноса на более новые версии. А так как эти огромные продукты продолжают жить, то продолжает жить и java 8.
Для новых решений зачастую берется просто последняя LTS версия джавы. Да, вот так вот просто! До недавнего времени это была java 11, на текущий момент java 17. Но так как 17 версия все еще очень молодая (ей всего пару месяцев), я бы рекомендовал вам пока что выбрать 11 версию для изучения, так как не все еще основные инструменты и библиотеки успели переехать на новый релиз.
Также предлагаю вам посмотреть наикрутейшее выступление Тагира Валеева на JockerConf про то, как менялась java под капотом с 9 по 14 версию. https://youtu.be/5Y0Alqb9H_I
#rdclr_backend #java #read
YouTube
Тагир Валеев — Java 9-14: Маленькие оптимизации
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Мы видели много докладов об улучшениях в свежих версиях Java. Модули, var, неизменяемые коллекции, switch-выражения достаточно популярны…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Мы видели много докладов об улучшениях в свежих версиях Java. Модули, var, неизменяемые коллекции, switch-выражения достаточно популярны…
Java. Какую версию выбрать? Часть 2
Помимо основного вендора java в лице Oracle, существуют и другие выпуски от других компаний. Давайте их рассмотрим:
🍒 1) AdoptOpenJDK
Проект, поддерживаемый сообществом. Команда выпускает билды, основанные на OpenJDK, отличие лишь в более долгосрочной поддержке. Команда занимается только билдами и не выпускает патчи для openjdk
🍩 2) Red Hat OpenJDK
Основана на версиях сборки OpenJDK, является коммерческим продуктом с платной поддержкой. В своих версиях компания нацелена на исправления безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7.
🫀 3) Azul Zulu
Основана на версиях OpenJDK, поставляется как open-source, но так же имеется — по сравнению с OracleJDK — более длительная коммерческая поддержка java 9, 13, 15.
🩱4) IBM JDK
Компании IBM требовалось написать свой собственный JIT-компилятор и свою собственную JVM, чтобы программы, написанные на java, могли запускаться на их мейнфреймах и при этом не заставлять разработчиков изучать новую java. Поэтому эти версии, с точки зрения программиста, практически идентичны.
🥡 5) Amazon Correto
Бесплатная версия сборки OpenJDK с долгосрочной поддержкой. Данная версия нацелена на максимальную производительность в облачных вычислениях. Так же Амазон каждый квартал выпускает багфиксы, что позволяет более оперативно устранять уязвимости.
🛺 6) Liberica JDK
Отечественная версия java, основанной также на OpenJDK. Плюсы перед OpenJDK все те же, что и других вендоров. Она бесплатна, более продолжительная коммерческая поддержка, частые выпуски обновлений безопасности, маленький размер контейнера (минимальный — всего 43.5мб).
Еще существенным плюсом является тот факт, что Liberica JDK Pro была внесена в реестр российского ПО. Это означает расширение диапазона применения Liberica JDK в государственных информационных системах, где крайне важна защита ПО от внешних факторов (например, санкций).
#rdclr_backend #java #read
Помимо основного вендора java в лице Oracle, существуют и другие выпуски от других компаний. Давайте их рассмотрим:
🍒 1) AdoptOpenJDK
Проект, поддерживаемый сообществом. Команда выпускает билды, основанные на OpenJDK, отличие лишь в более долгосрочной поддержке. Команда занимается только билдами и не выпускает патчи для openjdk
🍩 2) Red Hat OpenJDK
Основана на версиях сборки OpenJDK, является коммерческим продуктом с платной поддержкой. В своих версиях компания нацелена на исправления безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7.
🫀 3) Azul Zulu
Основана на версиях OpenJDK, поставляется как open-source, но так же имеется — по сравнению с OracleJDK — более длительная коммерческая поддержка java 9, 13, 15.
🩱4) IBM JDK
Компании IBM требовалось написать свой собственный JIT-компилятор и свою собственную JVM, чтобы программы, написанные на java, могли запускаться на их мейнфреймах и при этом не заставлять разработчиков изучать новую java. Поэтому эти версии, с точки зрения программиста, практически идентичны.
🥡 5) Amazon Correto
Бесплатная версия сборки OpenJDK с долгосрочной поддержкой. Данная версия нацелена на максимальную производительность в облачных вычислениях. Так же Амазон каждый квартал выпускает багфиксы, что позволяет более оперативно устранять уязвимости.
🛺 6) Liberica JDK
Отечественная версия java, основанной также на OpenJDK. Плюсы перед OpenJDK все те же, что и других вендоров. Она бесплатна, более продолжительная коммерческая поддержка, частые выпуски обновлений безопасности, маленький размер контейнера (минимальный — всего 43.5мб).
Еще существенным плюсом является тот факт, что Liberica JDK Pro была внесена в реестр российского ПО. Это означает расширение диапазона применения Liberica JDK в государственных информационных системах, где крайне важна защита ПО от внешних факторов (например, санкций).
#rdclr_backend #java #read
Trunk Based Development
Итак, TBD. Модель управления ветками в репозитории, переросшая в методологию и становящаяся все популярнее в последние годы. Сразу оговорюсь, всю теорию вы можете прочитать на официальном сайте комьюнити https://trunkbaseddevelopment.com, там все описано очень (местами даже слишком) подробно.
По определению, Trunk Based Development — это модель управления ветками, когда у вас есть только одна долгоживущая ветвь кода (trunk, main, master, название неважно) и вы всячески сопротивляетесь соблазнам завести вторую. А соблазнов много:
🥎 различия в окружениях (кластеризованные и сингл нод базы данных, разный уровень доступа, дебаг режим на лоу стендах и т.д.);
⚾️ большие изменения функционала, когда кажется, что проще поступиться обратной совместимостью, запилить и накатить новые версии на все компоненты сразу;
🎾 страх менеджмента, привыкшего работать с монолитными системами десятилетиями.
Все эти риски решаемы, но требуют немного поменять свои подходы к разработке. Многокомпонентный микросервисный проект в своем развитии гораздо ближе к живому организму, чем к механизму.
Вся сложность из кода смещена на взаимодействия компонентов, поэтому главной гарантией безотказности будет эволюционный подход. Мы же не меняем щенку лапы каждый месяц по мере роста, он понемногу растет каждый день. 🐶
Именно этот принцип — развивать проект небольшими инкрементальными изменениями — и лежит в основе разработки. Для этого используются следующие техники:
⚽️ Branch By Abstraction
🏀 Short Living Feature Branches
🏈 Continuous Deployment
🏉 Feature Toggling
🏐 Shift Right
Про них мы подробно поговорим в следующем посте.
#rdclr_backend #rdclr_frontend #product #read
Итак, TBD. Модель управления ветками в репозитории, переросшая в методологию и становящаяся все популярнее в последние годы. Сразу оговорюсь, всю теорию вы можете прочитать на официальном сайте комьюнити https://trunkbaseddevelopment.com, там все описано очень (местами даже слишком) подробно.
По определению, Trunk Based Development — это модель управления ветками, когда у вас есть только одна долгоживущая ветвь кода (trunk, main, master, название неважно) и вы всячески сопротивляетесь соблазнам завести вторую. А соблазнов много:
🥎 различия в окружениях (кластеризованные и сингл нод базы данных, разный уровень доступа, дебаг режим на лоу стендах и т.д.);
⚾️ большие изменения функционала, когда кажется, что проще поступиться обратной совместимостью, запилить и накатить новые версии на все компоненты сразу;
🎾 страх менеджмента, привыкшего работать с монолитными системами десятилетиями.
Все эти риски решаемы, но требуют немного поменять свои подходы к разработке. Многокомпонентный микросервисный проект в своем развитии гораздо ближе к живому организму, чем к механизму.
Вся сложность из кода смещена на взаимодействия компонентов, поэтому главной гарантией безотказности будет эволюционный подход. Мы же не меняем щенку лапы каждый месяц по мере роста, он понемногу растет каждый день. 🐶
Именно этот принцип — развивать проект небольшими инкрементальными изменениями — и лежит в основе разработки. Для этого используются следующие техники:
⚽️ Branch By Abstraction
🏀 Short Living Feature Branches
🏈 Continuous Deployment
🏉 Feature Toggling
🏐 Shift Right
Про них мы подробно поговорим в следующем посте.
#rdclr_backend #rdclr_frontend #product #read
Trunkbaseddevelopment
Trunk Based Development
A portal on this practice
🔥3
📕Что почитать о доступности
1️⃣Интерактивные примеры по конкретным атрибутам ARIA на сайте w3c. Переходим в интересующий раздел, открываем devtools и изучаем структуру страницы.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/
2️⃣Достаточно полный справочник MDN по role- и aria-атрибутам.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques
3️⃣Пример реализации focus trapping на сайте w3c.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
4️⃣Но не забываем про inert-polyfill, с ним это реализовать гораздо проще, плюс в будущем он может быть реализован нативно.
https://github.com/WICG/inert
5️⃣Хорошие примеры нативных элементов форм. Если вам нужны стилизованные формы с полными нативными возможностями без js-а.
http://wtfforms.com/
6️⃣В продолжение темы — опенсорсная либа паттернов, реализующих доступность, с примерами и демками.
https://a11y-style-guide.com/style-guide/
#rdclr_frontend #read
1️⃣Интерактивные примеры по конкретным атрибутам ARIA на сайте w3c. Переходим в интересующий раздел, открываем devtools и изучаем структуру страницы.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/
2️⃣Достаточно полный справочник MDN по role- и aria-атрибутам.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques
3️⃣Пример реализации focus trapping на сайте w3c.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
4️⃣Но не забываем про inert-polyfill, с ним это реализовать гораздо проще, плюс в будущем он может быть реализован нативно.
https://github.com/WICG/inert
5️⃣Хорошие примеры нативных элементов форм. Если вам нужны стилизованные формы с полными нативными возможностями без js-а.
http://wtfforms.com/
6️⃣В продолжение темы — опенсорсная либа паттернов, реализующих доступность, с примерами и демками.
https://a11y-style-guide.com/style-guide/
#rdclr_frontend #read
👍5
Видосик про прятки от OpenAI
Всегда интересно наблюдать, как большие компании, которые занимаются исследованиями в области машинного обучения, презентуют свои материалы.
Например, OpenAi — компания, одним из основателей которой является Илон Маск. В видео ИИ учится играть в прятки. Приятного просмотра! 🙈
#NN #read
Всегда интересно наблюдать, как большие компании, которые занимаются исследованиями в области машинного обучения, презентуют свои материалы.
Например, OpenAi — компания, одним из основателей которой является Илон Маск. В видео ИИ учится играть в прятки. Приятного просмотра! 🙈
#NN #read
YouTube
Multi-Agent Hide and Seek
We’ve observed agents discovering progressively more complex tool use while playing a simple game of hide-and-seek. Through training in our new simulated hide-and-seek environment, agents build a series of six distinct strategies and counterstrategies, some…
🔥1
Про стадии рендера на почитать
В качестве наглядного пособия сколько всего происходит в графике за один кадр, можно изучить отличнейшую статью про стадии рендера в Grand Theft Auto V. 🚗
Хотя игра уже далеко не новая, в сегодняшних реалиях мало что поменялось в подходах рендеринга сцены с отложенным освещением/затенением и экранных эффектов.
#rdclr_frontend #WebGL #read
В качестве наглядного пособия сколько всего происходит в графике за один кадр, можно изучить отличнейшую статью про стадии рендера в Grand Theft Auto V. 🚗
Хотя игра уже далеко не новая, в сегодняшних реалиях мало что поменялось в подходах рендеринга сцены с отложенным освещением/затенением и экранных эффектов.
#rdclr_frontend #WebGL #read
Adrian Courrèges
GTA V - Graphics Study - Adrian Courrèges
The Grand Theft Auto series has come a long way since
the first opus came out back in 1997.
About 2 years ago, Rockstar released GTA V.
The …
the first opus came out back in 1997.
About 2 years ago, Rockstar released GTA V.
The …
А вот все то же самое, только уже в виде видоса, с разделением по дроуколлам. 🛴
#rdclr_frontend #WebGL #read
#rdclr_frontend #WebGL #read
Введение в тест-анализ #2: проблемы с поиском серых зон
🍩 неуточнённые и неполные требования
С первого раза их не заметить. Например, как должно выглядеть сообщение «Заказ оформлен»? Отдельное всплывающее окно? А какого цвета должен быть текст сообщения? Ещё одна серая зона: почему поле «Отчество» обязательное? Что делать, если его нет?
🍩 скрытые требования
Авторы документации не всегда включают требования, которые кажутся им очевидными. Например, логотип состоит из двух слов и должен быть кликабельным: только первое слово при нажатии ведёт на главную страницу, а второе — на каталог товаров.
макеты и требования расходятся. На макетах есть нижний блок со ссылками, но в требованиях его функциональность не описана. Другой пример: на макете поле называется «Email», а в требованиях — «Электронный адрес».
🍩 требований нет.
Такое тоже бывает)
Тест-анализ заканчивается, когда тебе удастся декомпозировать и визуализировать все требования, а также исключить серые зоны.
Советую на почитать:
1. Как находить ошибки в бизнес-логике фичей
2. Зачем проводить декомпозицию требований
3. Mind Map в помощь тестировщику
#rdclr_QA #read
🍩 неуточнённые и неполные требования
С первого раза их не заметить. Например, как должно выглядеть сообщение «Заказ оформлен»? Отдельное всплывающее окно? А какого цвета должен быть текст сообщения? Ещё одна серая зона: почему поле «Отчество» обязательное? Что делать, если его нет?
🍩 скрытые требования
Авторы документации не всегда включают требования, которые кажутся им очевидными. Например, логотип состоит из двух слов и должен быть кликабельным: только первое слово при нажатии ведёт на главную страницу, а второе — на каталог товаров.
макеты и требования расходятся. На макетах есть нижний блок со ссылками, но в требованиях его функциональность не описана. Другой пример: на макете поле называется «Email», а в требованиях — «Электронный адрес».
🍩 требований нет.
Такое тоже бывает)
Тест-анализ заканчивается, когда тебе удастся декомпозировать и визуализировать все требования, а также исключить серые зоны.
Советую на почитать:
1. Как находить ошибки в бизнес-логике фичей
2. Зачем проводить декомпозицию требований
3. Mind Map в помощь тестировщику
#rdclr_QA #read
👍2
Тестирование API: на что обратить внимание
API (Application Programming Interface — программный интерфейс приложения) — интерфейс, который помогает приложениям взаимодействовать.
Приложения тоже могут отправлять команды, и другие приложения будут их выполнять. API помогает сервисам «общаться» и обмениваться информацией друг с другом.
🧐 На что обратить внимание при тестировании АПИ?
🦴 1. В первую очередь на URL, т. к. вы указываете куда идти за ресурсом. Неверный URL запроса вернет вам ошибку Couldn’t not send request, вы просто не сможете отправить запрос.
🦴 2. Method, чтобы понимать что с ресурсом надо сделать.
🦴 3. Тело запроса также важно проверять, так как в теле вы передаете информацию или обновляете существующую. Например, если неверно указать id — вернется ошибка 400 Bad Request.
🦴 4. В теле ответа также следует быть внимательным, создалось ли то, что мы хотели; какие значения в наших полях.
🦴 5. Формат передаваемых данных (json/xml). Если сервис принимает запросы только в джейсон, то при отправке другого формата вы получите ошибку 415 Unsupported Media Type.
🦴 6. Перестановка мест параметров не должна вызывать ошибку, так как от перестановки слагаемых... дальше мы знаем :).
🦴 7. Статус-код показывает успешен или нет наш запрос, а текст ошибки поможет понять, где мы допустили ошибку. Так как только наше АПИ будут использовать другие разработчики при интеграции первое с чем они столкнутся — это с ошибками. Они могут забыть указать заголовок или опечататься, поэтому сообщение об ошибки должно быть понятным.
🦴 8. Регистронезависимость заголовков: вне зависимости от написания они все должны передаваться.
🤬 При тестировании API негативные тесты очень важны! Например:
1. Что будет, если какой-либо из заголовков не передать?
2. Что будет, если передать неправильно и какой текст об ошибке мы увидим?
Позитивные тесты мы проводим по документации (все ли вернулось?). Проверяем это независимо от метода. Различие лишь в том, есть ли тело у метода или нет.
Что еще почитать по теме:
- Различия в тестировании REST и SOAP
- Быстро про API
#rdclr_QA #read
API (Application Programming Interface — программный интерфейс приложения) — интерфейс, который помогает приложениям взаимодействовать.
Приложения тоже могут отправлять команды, и другие приложения будут их выполнять. API помогает сервисам «общаться» и обмениваться информацией друг с другом.
🧐 На что обратить внимание при тестировании АПИ?
🦴 1. В первую очередь на URL, т. к. вы указываете куда идти за ресурсом. Неверный URL запроса вернет вам ошибку Couldn’t not send request, вы просто не сможете отправить запрос.
🦴 2. Method, чтобы понимать что с ресурсом надо сделать.
🦴 3. Тело запроса также важно проверять, так как в теле вы передаете информацию или обновляете существующую. Например, если неверно указать id — вернется ошибка 400 Bad Request.
🦴 4. В теле ответа также следует быть внимательным, создалось ли то, что мы хотели; какие значения в наших полях.
🦴 5. Формат передаваемых данных (json/xml). Если сервис принимает запросы только в джейсон, то при отправке другого формата вы получите ошибку 415 Unsupported Media Type.
🦴 6. Перестановка мест параметров не должна вызывать ошибку, так как от перестановки слагаемых... дальше мы знаем :).
🦴 7. Статус-код показывает успешен или нет наш запрос, а текст ошибки поможет понять, где мы допустили ошибку. Так как только наше АПИ будут использовать другие разработчики при интеграции первое с чем они столкнутся — это с ошибками. Они могут забыть указать заголовок или опечататься, поэтому сообщение об ошибки должно быть понятным.
🦴 8. Регистронезависимость заголовков: вне зависимости от написания они все должны передаваться.
🤬 При тестировании API негативные тесты очень важны! Например:
1. Что будет, если какой-либо из заголовков не передать?
2. Что будет, если передать неправильно и какой текст об ошибке мы увидим?
Позитивные тесты мы проводим по документации (все ли вернулось?). Проверяем это независимо от метода. Различие лишь в том, есть ли тело у метода или нет.
Что еще почитать по теме:
- Различия в тестировании REST и SOAP
- Быстро про API
#rdclr_QA #read
YouTube
Что такое API
Простым и понятным языком, с примерами! :)
Объяснение для тех, кто с API еще не сталкивался
Это фрагмент моего курса по тестированию REST API — http://testbase.ru/learn/rest-api
Объяснение для тех, кто с API еще не сталкивался
Это фрагмент моего курса по тестированию REST API — http://testbase.ru/learn/rest-api
👍4❤2
Web-приложения и особенности их тестирования
В отличие от веб-сайта, веб-приложение — это полноценная программа, доступ к которой пользователь получает через интернет, то есть она не требует установки на устройство. Веб-приложение интерактивно и позволяет пользователям взаимодействовать с разными элементами: например, оставить заявку на покупку товара, оформить покупку авиабилета или прокомментировать пост друга.
Веб-приложения можно классифицировать по-разному: в зависимости от их функционала и назначения. Давайте подробнее разберем эти типы приложений, чтобы лучше понимать, как они работают и какое подойдет для ваших бизнес-задач.
Есть три основных шаблона построения сайтов:
🥘 MPA (multi-page application): многостраничное приложение, которое отправляет запрос на сервер и полностью обновляет страницу, когда с ней совершается действие.
🍔 SPA (single-page application): одностраничное приложение, содержащее HTML-страницу,которая динамически обновляется в зависимости от действий пользователя — без полной перезагрузки.
🧅 PWA (progressive web application): приложение, которое пользователь устанавливает и может использовать в режиме офлайн.
Компоненты веб приложения:
🫖 UI — интерфейс пользователя. Реализуется через браузер в виде Web страниц. Написание на HTML, CSS, JavaScript.
🍵 Серверная часть. Языки программирования PHP, Perl, C/C++, Java, Python, Ruby, NodeJS.
Что тестировать? 🌅
1. Дефекты могут находиться как на клиентской, так и на серверной стороне.
2. Отображение клиента — кроссбраузерность.
3. Тестирование форм и ролевых моделей.
4. Тестирование установки веб-приложения.
5. Тестирование базы данных.
6. Тестирование передачи данных.
7. Безопасность, нагрузка.
Можно еще почитать о распространенных багах на веб.
#rdclr_QA #read
В отличие от веб-сайта, веб-приложение — это полноценная программа, доступ к которой пользователь получает через интернет, то есть она не требует установки на устройство. Веб-приложение интерактивно и позволяет пользователям взаимодействовать с разными элементами: например, оставить заявку на покупку товара, оформить покупку авиабилета или прокомментировать пост друга.
Веб-приложения можно классифицировать по-разному: в зависимости от их функционала и назначения. Давайте подробнее разберем эти типы приложений, чтобы лучше понимать, как они работают и какое подойдет для ваших бизнес-задач.
Есть три основных шаблона построения сайтов:
🥘 MPA (multi-page application): многостраничное приложение, которое отправляет запрос на сервер и полностью обновляет страницу, когда с ней совершается действие.
🍔 SPA (single-page application): одностраничное приложение, содержащее HTML-страницу,которая динамически обновляется в зависимости от действий пользователя — без полной перезагрузки.
🧅 PWA (progressive web application): приложение, которое пользователь устанавливает и может использовать в режиме офлайн.
Компоненты веб приложения:
🫖 UI — интерфейс пользователя. Реализуется через браузер в виде Web страниц. Написание на HTML, CSS, JavaScript.
🍵 Серверная часть. Языки программирования PHP, Perl, C/C++, Java, Python, Ruby, NodeJS.
Что тестировать? 🌅
1. Дефекты могут находиться как на клиентской, так и на серверной стороне.
2. Отображение клиента — кроссбраузерность.
3. Тестирование форм и ролевых моделей.
4. Тестирование установки веб-приложения.
5. Тестирование базы данных.
6. Тестирование передачи данных.
7. Безопасность, нагрузка.
Можно еще почитать о распространенных багах на веб.
#rdclr_QA #read
👍2
Библиотека: Все необходимое для ручного тестирования Web-приложений
🫁 Теория:
- Чек-лист тестирования WEB приложений
- Особенности тестирования веб-приложений
- Виды тестирования веб-приложений — как выбрать нужный?
- Основы тестирования и отладки Веб-приложений
- Web Application Testing: Step by Step Process to make it Right
- Frameworks
- Все про HTML и CSS
- Все про JavaScript
- Domain, Host, DNS: google support | статья
- Браузеры и движки: статья | Blink | Gecko | WebKit
🫀 Названия элементов UI:
- Гайдлайны платформ
- Статья с примерами и названиями элементов
- User Interface Elements
- UI Docs
- UI Kit Rambler
🧠 Статистика и аналитика:
- Яндекс.Радар
- gs.statcounter.com
👋🏻 Инструменты:
- extensions: Web Developer | EditThisCookie
- Chrome DevTools: Documentation | статья | breakpoints
- Responsive design testing tool
- Xenu's Link Sleuth (check broken links)
- Валидаторы данных: Валидатор JSON | Валидатор XML
- JSON encode/decode: json_encode | json_decode
- Fiddler: Fiddler | статья
- Charles: Charles Proxy | статья
🦷 Облачные платформы для кросс-браузерного тестирования:
Browserstack | CrossBrowser Testing | Browser Ling | Lambdatest | Sauce Labs | TestingBot | Comparium | Browseemall | Multibrowser | Digital.ai | Ranorex | TestComplete
#rdclr_QA #product #read
🫁 Теория:
- Чек-лист тестирования WEB приложений
- Особенности тестирования веб-приложений
- Виды тестирования веб-приложений — как выбрать нужный?
- Основы тестирования и отладки Веб-приложений
- Web Application Testing: Step by Step Process to make it Right
- Frameworks
- Все про HTML и CSS
- Все про JavaScript
- Domain, Host, DNS: google support | статья
- Браузеры и движки: статья | Blink | Gecko | WebKit
🫀 Названия элементов UI:
- Гайдлайны платформ
- Статья с примерами и названиями элементов
- User Interface Elements
- UI Docs
- UI Kit Rambler
🧠 Статистика и аналитика:
- Яндекс.Радар
- gs.statcounter.com
👋🏻 Инструменты:
- extensions: Web Developer | EditThisCookie
- Chrome DevTools: Documentation | статья | breakpoints
- Responsive design testing tool
- Xenu's Link Sleuth (check broken links)
- Валидаторы данных: Валидатор JSON | Валидатор XML
- JSON encode/decode: json_encode | json_decode
- Fiddler: Fiddler | статья
- Charles: Charles Proxy | статья
🦷 Облачные платформы для кросс-браузерного тестирования:
Browserstack | CrossBrowser Testing | Browser Ling | Lambdatest | Sauce Labs | TestingBot | Comparium | Browseemall | Multibrowser | Digital.ai | Ranorex | TestComplete
#rdclr_QA #product #read
Хабр
Чек-лист тестирования WEB приложений
Привет! После публикации статьи « Чек-лист тестирования мобильных приложений », поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос...
❤2
Бибилиотека: все, что нужно для тестирования мобильных приложений 📚
📝 Теория, книги, статьи:
Чек-лист тестирования мобильных приложений
Push-уведомления
UI-элементы и жесты в мобильных приложениях
🖇 Guidelines:
iOS Interface Guidelines
Android Components
💻 IDE:
Android Studio
Xcode
🧩 Android specific:
Android Debug Bridge (adb)
Android developer options
Exerciser Monkey
Apkanalyzer
⚖️ Аналитика:
Firebase Crashlytics
⚙️ Симуляторы и эмуляторы Android:
Genymotion
BrowserStack App Live
🛠 Симуляторы и эмуляторы iOS:
Xcode Simulator
🍪 Фермы устройств:
Firebase Test Lab
Microsoft App Center
Samsung Remote Test Lab
AWS Device Farm
HUAWEI DIGIX Lab Test Services
🚜 Распределение платформ и устройств:
Мобильные ОС
Worldwide Mobile Vendor
🎮 Инструменты прокси трафика:
Fiddler
Charles Proxy
Mitmproxy
#read #rdclr_QA
📝 Теория, книги, статьи:
Чек-лист тестирования мобильных приложений
Push-уведомления
UI-элементы и жесты в мобильных приложениях
🖇 Guidelines:
iOS Interface Guidelines
Android Components
💻 IDE:
Android Studio
Xcode
🧩 Android specific:
Android Debug Bridge (adb)
Android developer options
Exerciser Monkey
Apkanalyzer
⚖️ Аналитика:
Firebase Crashlytics
⚙️ Симуляторы и эмуляторы Android:
Genymotion
BrowserStack App Live
🛠 Симуляторы и эмуляторы iOS:
Xcode Simulator
🍪 Фермы устройств:
Firebase Test Lab
Microsoft App Center
Samsung Remote Test Lab
AWS Device Farm
HUAWEI DIGIX Lab Test Services
🚜 Распределение платформ и устройств:
Мобильные ОС
Worldwide Mobile Vendor
🎮 Инструменты прокси трафика:
Fiddler
Charles Proxy
Mitmproxy
#read #rdclr_QA
Хабр
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда...
👍6
Android Debug Bridge (adb)
Android Debug Bridge (adb) — инструмент командной строки, который позволяет взаимодействовать с устройством. Команда adb упрощает выполнение различных действий с устройством, которую можно использовать для выполнения различных команд на устройстве.
Это клиент-серверная программа, состоящая из трех компонентов:
🌵 Клиент, отправляющий команды.
Клиент работает на вашей машине разработки. Вы можете вызвать клиента из терминала командной строки, введя команду adb.
🍀 Демон, запускающий команды на устройстве.
Демон работает в фоновом режиме на каждом устройстве.
🌳 Сервер, который управляет обменом данными между клиентом и демоном. Сервер работает как фоновый процесс на вашей машине разработки.
Установка ADB
adb входит в пакет Android SDK Platform-Tools. Скачать этот пакет можно с помощью SDK Manager , который устанавливает его в android_sdk/platform-tools/. Или, если вам нужен автономный пакет Android SDK Platform-Tools, вы можете скачать его с официального сайта.
Основные команды:
$ adb devices — просмотр списка устройств;
$ adb get-state — состояние устройства;
$ adb reboot — перезагрузка устройства;
$ adb install -f /path/some_name.apk — можно выполнить установку приложения во внутреннюю память;
$ adb shell pm list packages — список установленных приложений;
$ adb logcat — просмотр журналов системы и приложений.
Еще можно почитать про команды для ADB :)
#rdclr_QA #read
Android Debug Bridge (adb) — инструмент командной строки, который позволяет взаимодействовать с устройством. Команда adb упрощает выполнение различных действий с устройством, которую можно использовать для выполнения различных команд на устройстве.
Это клиент-серверная программа, состоящая из трех компонентов:
🌵 Клиент, отправляющий команды.
Клиент работает на вашей машине разработки. Вы можете вызвать клиента из терминала командной строки, введя команду adb.
🍀 Демон, запускающий команды на устройстве.
Демон работает в фоновом режиме на каждом устройстве.
🌳 Сервер, который управляет обменом данными между клиентом и демоном. Сервер работает как фоновый процесс на вашей машине разработки.
Установка ADB
adb входит в пакет Android SDK Platform-Tools. Скачать этот пакет можно с помощью SDK Manager , который устанавливает его в android_sdk/platform-tools/. Или, если вам нужен автономный пакет Android SDK Platform-Tools, вы можете скачать его с официального сайта.
Основные команды:
$ adb devices — просмотр списка устройств;
$ adb get-state — состояние устройства;
$ adb reboot — перезагрузка устройства;
$ adb install -f /path/some_name.apk — можно выполнить установку приложения во внутреннюю память;
$ adb shell pm list packages — список установленных приложений;
$ adb logcat — просмотр журналов системы и приложений.
Еще можно почитать про команды для ADB :)
#rdclr_QA #read
👍3