По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Новый менеджер пакетов Windows от Microsoft упрощает установку приложений, позволяя это делать одной командой. В этой статье рассказываем про Windows Package Manager и новую команду winget.
Что такое менеджер пакетов Windows?
Менеджеры пакетов распространены в Linux. Вместо того, чтобы искать приложение в Интернете, загрузить установщик и запускать мастер установки, вы можете просто запустить быструю команду для поиска и установки приложения по его имени.
Например, чтобы установить Microsoft PowerToys, вы можете открыть окно терминала и ввести winget install powertoys. Команда автоматически найдет, загрузит и установит программное обеспечение без каких-либо дополнительных действий с вашей стороны. Это так просто.
Под капотом Microsoft размещает собственный репозиторий программного обеспечения, а другие организации и частные лица могут размещать свои собственные репозитории. Это важная функция, которая повышает производительность в Linux, особенно для разработчиков и системных администраторов.
Менеджер пакетов Windows - это проект с открытым исходным кодом, доступный и на GitHub.
Как установить менеджер пакетов Windows
Начиная с 19 мая 2020 года менеджер пакетов Windows доступен в форме предварительного просмотра. Позднее он будет интегрирован непосредственно в обновление для Windows 10.
Сейчас есть несколько способов получить его:
Установите инсайдерскую сборку Windows 10, зарегистрируйтесь в программе инсайдеров Windows Package Manager и установите обновление для пакета установщика приложений из Магазина Microsoft. Вы получите автоматические обновления диспетчера пакетов Windows по мере их выпуска, но вам придется запустить нестабильную версию Windows 10.
Загрузите менеджер пакетов Windows .appxbundle с GitHub. Установите его, дважды щелкнув файл и нажав Update. Вы должны будете установить будущие обновления вручную с этой же страницы загрузки, но вам не придется запускать нестабильную версию Windows 10.
В будущем в этом нет необходимости, и winget будет встроен во все стабильные версии Windows 10. По состоянию на май 2020 года он находится в форме предварительного просмотра, так как Microsoft тестирует его и устраняет ошибки.
Как использовать winget, менеджер пакетов Windows
Вы можете запустить winget из Windows PowerShell или из классической командной строки. Мы рекомендуем установить новый терминал Windows, если вы этого еще не сделали.
Вы можете скачать Windows Terminal из Магазина Microsoft. Вы даже можете получить исходный код на GitHub. Да, новый терминал Windows с открытым исходным кодом.
Из командной строки выполните команду winget, чтобы просмотреть дополнительную информацию об использовании инструмента.
Чтобы найти приложение, выполните следующую команду, заменив name поисковой фразой:
winget search name
Чтобы установить приложение, выполните следующую команду, заменив name на имя приложения:
winget install name
Для просмотра дополнительной информации о приложении выполните следующую команду, заменив name именем приложения или поисковой фразой:
winget show name
Чтобы просмотреть полный список доступных приложений, выполните следующую команду:
winget install
В своем первоначальном выпуске репозитории winget уже заполнены широким спектром популярных настольных приложений. Вы найдете все, от обычных приложений для настольных систем Windows до инструментов для разработчиков. Список включает в себя Google Chrome, Mozilla Firefox, Zoom, Steam, медиаплеер VLC, Spotify, терминал Windows, код Visual Studio, Ruby, Microsoft PowerToys и многие другие.
Чтобы управлять источниками, запустите winget source. Вы увидите список команд. Например, чтобы просмотреть текущие источники, запустите:
winget source list
В первоначальной версии winget есть только встроенный исходный код winget, управляемый Microsoft, расположенный по адресу https://winget.azureedge.net/cache. В будущем вы сможете добавлять сторонние источники с помощью дополнения winget source.
Вы можете увидеть больше информации о том, как использовать одну из встроенных команд winget, добавив -? к нему. Например, чтобы увидеть различные опции, которые вы можете использовать с winget, выполните следующую команду:
winget search -?
Заключение
Теперь вы знаете как работать с менеджером пакетов winget. Microsoft наверняка добавит дополнительные функции в диспетчер пакетов Windows в будущем, и он станет только более мощным. А другие статьи про Windows можно прочитать в нашем разделе.
В программировании понятие «состояние» (state) относится к состоянию системы, компонента или приложения в какой-то определенный момент времени.
Приведем простой пример. Допустим, вы совершаете покупки на amazon.com, и будь то факт того, что вы вошли в данный момент на сайт, или есть ли какие-то товары в вашей корзине, это все является примерами состояния.
Состояние – это данные, которые хранятся и используются для отслеживания текущего статуса приложения. Именно понимание и управление состоянием играет решающую роль в создании интерактивных и динамических веб-приложений.
Понятие «состояние» относится к многим компонентам архитектуры. Шаблоны проектирования (например, REST или GraphQL), протоколы (например, HTTP и TCP), межсетевые экраны и функции могут как сохранять состояние, так и не делать этого. Однако основной принцип «состояния» (независимо от компонента, к которому оно привязывается) остается прежним.
В этой статье мы расскажем, что такое состояние. Кроме того, мы объясним, что такое stateful и stateless-архитектуры, а также их плюсы и минусы.
Что такое stateful-архитектура?
Представьте, что вы идете в пиццерию, чтобы пообедать. В этом ресторане работает только один официант, и он подробно записывает всю информацию о вас: номер вашего стола, ваш заказ, ваши предпочтения на основе предыдущих заказов (тип корочки, который вам нравится, или начинки, на которые у вас аллергия) и т.д.
Иллюстрация: официант принимает заказ в пиццерии
Вся информация, которую официант записывает в блокнот, и есть состояние клиента. Доступ к этой информации имеет только официант, который вас обслуживает. Если вы хотите внести какие-то изменения в свой заказ или проверить готовность заказа, вам нужно обратиться к тому же официанту. Ну и поскольку официант всего один, это не является проблемой.
А теперь представьте, что в ресторане стало больше посетителей. Вашему официанту приходится обслуживать и других гостей, поэтому на работу вызывают дополнительных официантов. И в данной ситуации вы хотите проверить статус вашего заказа и внести в него небольшое изменение – обычную корочку вместо сырной. А единственный официант, который может вас обслужить, - не тот, который принял ваш заказ.
Иллюстрация: другой официант не может изменить заказ клиента
У этого официанта нет информации о вашем заказе, то есть о вашем состоянии. И по понятным причинам он не сможет проверить статус вашего заказа или внести в него изменения. Ресторан, где сообщать о готовности заказа или вносить в него изменения могут только официанты, принявшие этот заказ, придерживается архитектуры с сохранением состояния (stateful).
Подобным образом stateful-приложение будет иметь сервер, который будет запоминать данные клиентов (то есть их состояния). Все будущие запросы будут перенаправляться через балансировщик нагрузки (придерживаясь при этом механизма «липких сессий» (Sticky Sessions)) на тот же сервер. Таким образом, сервер всегда будет знать все о клиенте.
На схеме ниже показаны два разных пользователя, и они оба хотят получить доступ к веб-серверу через балансировщик нагрузки. Так как состояние приложения сохраняется на сервере, пользователи при каждом запросе должны направляться на один и тот же сервер, чтобы сохранять состояние.
Схема: как работает stateful-приложение
Sticky sessions (липкие сессии) – это настройка, позволяющая балансировщику нагрузки раз за разом направлять запросы пользователя на один и тот же внутренний сервер на протяжении всей сессии. В этом и заключается ее отличие от обычной балансировки нагрузки, при которой запросы пользователя направляются на любой доступный сервер по циклическому алгоритму или по какому-то другому шаблону распределения нагрузки.
В чем же проблема stateful-архитектуры? Представьте себе ресторан, который работает таким образом. Несмотря на то, что это такой вариант может оказаться вполне идеальным и простым в реализации для небольшого семейного ресторана с небольшим количеством посетителей, его
нельзя назвать отказоустойчивым
и масштабируемым
.
Что будет, если у официанта, который принял у клиента заказ, возникнет ЧП и ему придется уйти? Вся информация по заказу так и останется у этого официанта. Это подрывает качество обслуживания клиентов, так как любой новый официант, который придет, чтобы заменить старого, не будет ничего знать о предыдущих заказах. Такая структура не является отказоустойчивой.
Кроме того, распределение запросов таким образом, что клиент может обращаться только к одному и тому же официанту, подразумевает, что нагрузка на официантов распределяется неравномерно. Кто-то будет завален заказами, особенно если он обслуживает какого-нибудь требовательного клиента, который постоянно меняет или добавляет что-то в свой заказ. А кому-то будет нечем заняться, и при этом они не смогут вмешиваться и помогать другим официантам. И опять-таки, такая структура не является масштабируемой.
Точно так же хранение данных о состоянии разных клиентов на разных серверах нельзя назвать отказоустойчивым и масштабируемым. Если произойдет сбой сервера, то все данные о состоянии будут утеряны. Так что, если пользователь вошел в систему и собирается оформить большой заказ, например, на amazon.com, ему придется снова пройти этап аутентификации, и при этом его корзина окажется пустой. Покупателю придётся снова входить в систему и заново заполнять корзину, и это явно испортит его впечатление от использования сайта.
Кроме того, добиться масштабируемости в час пик, например, в Черную пятницу, при использовании stateful-структуры будет не так просто. Структура будет автоматически масштабироваться, добавляя новые серверы, но, так как работает механизм «липких сессий», клиенты будут направляться на одни и те же серверы, что может привести к их перегрузке, что, в свою очередь, приведет к увеличению времени отклика, и это плохо скажется на взаимодействии с пользователем.
Многие из этих проблем может решить stateless-архитектура.
Что такое stateless-архитектура?
Stateless-архитектура – это термин, который в какой-то степени сбивает с толку, так как подразумевает, что система не фиксирует состояние. Но тем не менее такой тип архитектуры вовсе не означает, что информация о состоянии нигде не сохраняется. Это лишь значит, что информация о состоянии хранится вне сервера. Так что, понятие «stateless» может применяться только к серверу.
Вернемся к примеру с рестораном. В данном случае можно сказать, что официанты в этом ресторане имеют крайне плохую память. Они не помнят старых клиентов и тем более не помнят, что вы заказывали ранее и какая пицца вам нравится. Они просто принимают заказы клиентов в отдельной системе, скажем, на компьютере, к которому есть доступ у всех официантов. После чего они могут обратиться к компьютеру, чтобы получить более подробную информацию о заказе и внести в него необходимые изменения.
Иллюстрация: «забывчивый» официант принимает заказ, а затем обращается к компьютеру, чтобы получить больше информации о заказе
Сохраняя «состояние» заказа клиента в централизованной системе, которая доступна всем официантам, любой из них может обслужить любого клиента.
В рамках stateless-архитектуры HTTP-запросы от клиентов могут отправляться на любой из серверов.
Как правило, состояние хранится в отдельной базе данных, которая доступна для всех серверов. Таким образом, вы получаете отказоустойчивую и масштабируемую архитектуру, так как при необходимости вы можете удалять или добавлять серверы, не влияя при этом на данные о состоянии.
Кроме того, нагрузка будет равномерно распределяться по всем серверам, так как балансировщику нагрузки не нужно придерживаться схемы липких сессий для направления одних и тех же клиентов на одни и те же сервера.
На схеме ниже продемонстрированы два разных пользователя, которые пытаются получить доступ к веб-серверу через балансировщик нагрузки. Так как состояние приложения хранится отдельно от серверов, пользователи могут быть направлены на любой из них. После чего сервер запросит информацию о состоянии из внешней базы данных, которая доступна для всех серверов.
Иллюстрация: схема stateless-архитектуры
В большинстве случаев данные о состоянии хранятся в кэше, например, в Redis – внутреннем хранилище данных. В отличие от хранения на диске, хранение данных в оперативной памяти требует меньше времени на такие операции, как чтение и запись.
Объединяем все вместе
В этой статье описывается, как работают веб-приложения с сохранением и без сохранения состояния, а также их недостатки. Однако принципы stateful и stateless-архитектуры могут применяться не только к веб-приложениям.
Если мы в качестве примера посмотрим на сетевые протоколы, то увидим, что, например, HTTP – это протокол без сохранения состояния. Это значит, что каждый HTTP-запрос от клиента к серверу является
независимым
и
не содержит информации о предыдущих запросах
или их содержимом. Сервер обрабатывает каждый запрос как отдельную транзакцию и по определению не сохраняет информацию о состоянии клиента между запросами.
Состояние может храниться либо на серверах (stateful-архитектура), либо в отдельной базе данных вне серверов (stateless-архитектура). Сам по себе HTTP-протокол не сохраняет состояние.
В отличие от HTTP, который не сохраняет состояние, TCP-протокол устанавливает соединение и сохраняет состояние. Он устанавливает соединение между двумя устройствами (как правило, это клиент и сервер) и поддерживает непрерывный канал связи до тех пор, пока соединение не будет завершено.
Та же логика может применяться и к межсетевым экранам – они могут как сохранять состояние, так и не делать этого.
В AWS группа безопасности – это виртуальный брандмауэр, который контролирует входящий и исходящий трафик виртуальных машин или облачных экземпляров. Группы безопасности сохраняют состояние. Когда вы пропускаете определенный входящий трафик, соответствующий исходящий трафик пропускается автоматически. Иными словами, отслеживается состояние соединения.
Для управления входящим и исходящим трафиком в AWS на уровне подсети используются Списки управления сетевым доступом (NACL - Network Access Control Lists), которые не сохраняют состояние. Отсутствие фиксации состояния говорит о том, что вы должны явно определить правила как для входящего, так и для исходящего трафика.
В отличие от групп безопасности, где при пропуске входящего трафика исходящий трафик пропускается автоматически, NACL требуют определить отдельные правила для входящего и исходящего трафика.
Функции и шаблоны проектирования тоже могут сохранять или не сохранять состояние.
Основная идея, которая лежит в основе чего-то, что сохраняет состояние, заключается в том, что это что-то обладает идеальной памятью или знает все о предыдущих вызовах и запросах. А вот то, что не сохраняет состояние, ничего не запоминает и не обладает знаниями о предыдущих вызовах или запросах.
Надеюсь, что теперь вы стали лучше понимать, как работают stateful и stateless-приложения, и сможете решить, какой вариант вам больше подходит.
Почти каждому проекту необходимо так или иначе взаимодействовать с внешним миром. Если вы работаете со средами JavaScript, то, вероятнее всего, для этой цели вы будете использовать Fetch API.
Но задумайтесь, когда вы работаете с API, помните ли вы синтаксические конструкции наизусть или вам все-таки нужны небольшие подсказки?
Я написал большое количество статей о JavaScript и о вещах, с ним связанных. И я сделал это только для того, чтобы потом я мог частенько (заново) посещать их, чтобы освежить свою память или позаимствовать какой-нибудь пример кода, который, как я помню, «где-то был».
В этой статье я постараюсь создать еще один примерно подобный ресурс. Я перечислю 9 самых распространенных запросов Fetch API.
Я уверен, что вы их использовали, и далеко не раз. Но было бы прекрасно не искать в старых проектах синтаксическую конструкцию того конкретного запроса, что вы использовали полгода назад?
?
Для чего нужен Fetch API?
Нас уже успели избаловать всеми службами, которые предоставляют хорошие SDK, которые абстрагируются от реальных запросов API. Мы просто запрашиваем данные с помощью обычных языковых конструкций, и даже не задумываемся о самом процессе обмена данными.
Но что, если у платформы, которую мы выбрали, нет SDK? Или что, если вы создаете как сервер, так и клиента? В таких случаях вам нужно будет обрабатывать запросы самостоятельно. И вот как это можно сделать с помощью Fetch API.
Простой запрос GET с помощью Fetch API
fetch('{url}')
.then(response => console.log(response));
Простой запрос POST с помощью Fetch API
fetch('{url}', {
method: 'post'
})
.then(response => console.log(response));
Запрос GET с маркером авторизации (токеном на предъявителя) в Fetch API
fetch('{url}', {
headers: {
'Authorization': 'Basic {token}'
}
})
.then(response => console.log(response));
Запрос GET с данными строки запроса в Fetch API
fetch('{url}?var1=value1&var2=value2')
.then(response => console.log(response));
Запрос GET с CORS в Fetch API
fetch('{url}', {
mode: 'cors'
})
.then(response => console.log(response));
Запрос POST с маркером авторизации и данными строки запроса в Fetch API
fetch('{url}?var1=value1&var2=value2', {
method: 'post',
headers: {
'Authorization': 'Bearer {token}'
}
})
.then(response => console.log(response));
Запрос POST с данными формы в Fetch API
let formData = new FormData();
formData.append('field1', 'value1');
formData.append('field2', 'value2');
fetch('{url}', {
method: 'post',
body: formData
})
.then(response => console.log(response));
Запрос POST с данными JSON в Fetch API
fetch('{url}', {
method: 'post',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
'field1': 'value1',
'field2': 'value2'
})
})
.then(response => console.log(response));
Запрос POST с данными JSON и CORS в Fetch API
fetch('{url}', {
method: 'post',
mode: 'cors',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
'field1': 'value1',
'field2': 'value2'
})
})
.then(response => console.log(response));
Как обработать результат запроса Fetch API
Fetch API возвращает
Promise
(промис). Именно поэтому я всегда использую
.then()
и функцию обратного вызова для того, чтобы обработать ответ:
fetch(...).then(response => {
// process the response
}
Но, если находитесь в асинхронной функции, вы можете просто дождаться результата:
async function getData(){
let data = await fetch(...);
// process the response
}
А теперь давайте посмотрим на то, как мы можем извлечь данные из полученного ответа.
Как проверить код состояния ответа Fetch API
Когда мы отправляем запросы POST, PATCH и PUT, чаще всего нас интересует возвращаемый код состояния:
fetch(...)
.then(response => {
if (response.status == 200){
// all OK
} else {
console.log(response.statusText);
}
});
Как получить обычное число из ответа Fetch API
Некоторые конечные точки API могут отправлять обратно идентификатор новой записи базы данных, которая была создана с помощью ваших же данных:
var userId;
fetch(...)
.then(response => response.text())
.then(id => {
userId = id;
console.log(userId)
});
Как конвертировать данные JSON из ответа Fetch API
Чаще всего в теле ответа вы получаете данные JSON:
var dataObj;
fetch(...)
.then(response => response.json())
.then(data => {
dataObj = data;
console.log(dataObj)
});
Помните о том, что вы сможете получить доступ к этим данным только после того, как разрешите оба промиса. Иногда это может создавать путаницу, поэтому я больше предпочитаю использовать асинхронные методы и дожидаться результатов:
async function getData(){
var dataObj;
const response = await fetch(...);
const data = await response.json();
dataObj = data;
console.log(dataObj);
}
Заключение
Эти примеры должны прикрыть вас в большинстве ситуаций.