Архив за месяц: Июль 2021

Жанр Zero Player Game или ZPG. Игры, которые играют сами в себя

Опубликовано автором
Ответить

Привет друзья! Абсолютно каждый сталкивался с разными жанрами в играх не так ли? Рпг, шутеры или стратегии, у каждого из нас есть свои любимые жанры игр и те, которые мы терпеть не можем.

Я думаю у нас тут есть люди, которые пробовали не все жанры в видеоиграх и даже есть жанры, о существовании которых вы даже не догадывались. Вы когда-нибудь слышали про жанр ZPG ну или Zero Player Game? Вот и я не слышал до сегодняшнего момента, ну, а если кто-то и знает о нём, то снимаю пред вами шляпу.

Извините за большое количество слов жанр)

В данном блоге мы узнаем, что такое ZPG, посмотрим где применяется данный жанр и познакомимся с подобными играми. Так что, присаживайся и приготовься слушать, ну или читать, как тебе удобнее.

Если хочешь усвоить всю эту информацию в простой и расслабляющей форме, то можешь пройти по ссылке на видео!

Что такое Zero Player Game?

Zero Player Game или «игра с нулём игроков» — это компьютерная игра, в которой вмешательство человека в игровой процесс сводится к минимуму или отсутствует вовсе. Так же бывает, что в этих играх в основном используется искусственный интеллект вместо игроков. Пользователь конечно может поучаствовать в игровом процессе, но максимум в создании персонажа, в его кастомизации и распределении каких-нибудь характеристик если таковые имеются конечно же. В дальнейшем игрок никак не может влиять на игровой процесс, за небольшим исключением конечно же, но в большей мере вы занимаетесь созерцанием игровой картины.

Да, представите себе, есть и такие игры в которые как таковой и не нужно играть.

Несмотря на явное отсутствие вмешательства игрока в игру, вам всё-таки позволяют оказывать ограниченное воздействие на мир игры. Делается это обычно за счёт реализации непрямого управления. Иными словами, вместо отдачи прямых указаний своему персонажу, игроку разрешают менять определённые параметры мира (или персонажа), например, изменение ландшафта, который влияет на сложность игры, подталкивая события в нужную вам сторону.

К слову жанр зародился как пародия на обычные ролевые игры (РПГ или ММОРПГ), в которых большое внимание уделялось росту параметров героя и его прокачке в ущерб сюжету и другим составляющим игры. От этого его ещё можно встретить название Zero Role Player Game, то бишь ZRPG.

Данный вид игр без игроков можно приблизительно разделить на несколько категорий:

  • Setup-only game («только начальная установка») — игры, в которых решения человека исчерпываются заданием начальной позиции/конфигурации (например, большинство игр данного жанр и игры для программистов, к которым мы позже перейдём);

  • Games played by AIs («игры между искусственными интеллектами») — игры между компьютерными программами, алгоритмами или копиями реализаций одного и того же алгоритма в одной программе (шахматы, шашки и т. д. с включённой опцией автоматической игры);

  • Solved games («решённые игры») — игры, подвергнутые анализу, в котором рассмотрена каждая возможная или каждая достижимая конфигурация, исход которой (победа, поражение или ничья) может быть правильно предсказаны из любого положения, при условии, что оба игрока играют отлично. Эта концепция обычно применяется к абстрактным стратегическим играм, и особенно к играм с полной информацией и без элемента случайности, например, (крестики-нолики, английские шашки, гекс). Простым языком можно даже не играть, а просто провести анализ где будет известен результат, так как нет никакого рандома.

Для тех, кто забыл как выглядит гекс.
Для тех, кто забыл как выглядит гекс.

Давайте теперь перейдём к применению

Игры этого специфического жанра могут использоваться для отработки «генетического программирования» для разработок алгоритмов противодействия и выживания посредством естественного отбора. Так же для разработки стратегии противодействия другим игрокам. Многие задачи теории игр являются ZPG в общем смысле, когда множественное повторение симуляции действий игрока применяется для нахождения оптимального решения частных проблем. Также концепция ZPG часто применяется для демонстрации возможностей игры в режиме паузы или на выставках.

Для кого эти игры?

С применением разобрались, теперь зададимся вопросом, а для кого эти игры? Этот вопрос уже более сложный, и каждый сам решит для себя нравится ему это или нет, в принципе ZPG можно поверхностно отнести и к тому же интерактивному кинцу, ну или например кто-то захочет побыть в режиме бога и понаблюдать за происходящим в игре внося небольшие изменения, некоторым людям просто нравится наблюдать за происходящим в игре как она сама в себя играет и как постепенно развивается её игровой мир. Мы же все с вами смотрим прохождение игр на youtube или как кто-то просто играет на twich, тут такой же принцип, нужно как говориться только попробовать, чтобы понять для себя стоит это того или нет.

Ну, а так как мой блог об играх надо и о них немного рассказать, сейчас мы затронем ярких представителей этого жанра.

Progress Quest

Progress Quest — это компьютерная игра, разработанная как пародия на игру EverQuest и жанр MMORPG в целом. Она является «игрой для нуля игроков» в том смысле, что после создания персонажа какое-либо взаимодействие между ним и игроком не предусмотрено. Игра начинает «играть» в саму себя, а игрок становится сторонним наблюдателем.

Перед началом новой игры игроку предлагается сделать выбор среди таких характеристик персонажа как, например, раса и класс. Характеристики персонажа генерируются случайным образом. Они определяют силу, телосложение, ловкость, интеллект, мудрость и обаяние. Персонаж начинает игру с плохим снаряжением, постепенно обретая все более хорошее оружие, доспехи и заклинания. Однако, ни один их упомянутых выше параметров или предметов не оказывает какого-то влияния на геймплей. Исключением является параметр силы, определяющий размер инвентаря персонажа, что немного влияет на скорость увеличения уровня.

Игровой процесс запускается сразу после создания персонажа и игра следует своим курсом. На игровом экране отображаются параметры персонажа, а также progress bar, отражающие успехи игрока.

Игрок может создать как локальную учётную запись исключительно для собственного развлечения, так и сетевую учётную запись, которая позволяет сохранить параметры персонажа на рейтинговом сайте. Это даёт возможность игрокам сравнивать свои достижения, пытаясь достичь высших рейтинговых позиций на своём сервере. Персонаж так же может вступить в гильдию доброго, нейтрального или злого направления, но это не приносит никаких преимуществ.

Игра для программистов

Помните мы затрагивали игры для программистов, так вот

Игра для программистов — компьютерная игра, в которой человек не участвует напрямую в игре. Вместо этого он пишет управляющую программу, сражающуюся с себе подобными программами. Такие игры являются сложным и нетривиальным упражнением для программистов.

Программа может писаться на особом виде ассемблера, либо на языках высокого уровня. Чаще всего применяются интерпретируемые языки наподобие Python.

По цели игры такие игры делятся на:

  • Бои в памяти. Задача программы — «сломать» программу противника.

  • Настольные игры (например, на заре кибернетики были популярны шахматные турниры среди ЭВМ).

  • Боевые роботы. Целью игры является создать управляющую программу для боевого робота.

  • Прочие игры. Управление гоночной машиной, колонией микробов, и т. д.

Годвилль

Русский аналог Progress Quest

Годвилль (Godville) — это текстовая ролевая игра с ZPG направлением, то есть для «нуля игроков», доступная на мобильных устройствах и в интернет-браузерах. Игрок управляет персонажем, именуемым богом или богиней. Этот бог или богиня взаимодействует с неигровым персонажем, называемым героем. Игра получила положительные оценки, прежде всего благодаря геймплею. Ввиду этого иногда игру называют «духовным наследником» Progress Quest, но так как это является Русской разработкой, то она покажется всем намного интереснее так как диалоги здесь в разы насыщеннее и в отличии от Progress Quest сделаны в юморной форме, ну и конечно же более понятны для русских игроков.

В игре присутствует персонаж-герой, являющийся неигровым, а также персонаж-бог, которым управляет игрок. Герой является религиозным фанатиком. Для общения с богом он использует свой дневник. Время от времени ему требуются свидетельства божественного присутствия. Бог может в позитивном или негативном ключе воздействовать на героя с помощью пульта управления. Это воздействие выражается в каких-либо дарах герою, лечении или в наказании героя молнией. Также бог может что-то сказать герою напрямую с помощью «гласа божьего». При этом глас может иметь значение и заставлять героя что-либо делать, хотя подопечные не часто слушаются своих покровителей, но всегда как-то реагируют на глас и воздействие.

При создании героя бог, то есть вы даёт ему имя выбирает пол и некоторые характеристики. Со временем герой получает новые уровни, изучает особые умения, и, в результате всех приключений и взаимодействий с богом, приобретает собственную личность. Как и в любой ролевой игре, в «Годвилле» герой бродит по игровому миру, сражается с монстрами, находит и использует ящики с сокровищами и иные предметы, а также иногда проигрывает монстрам и прочим недружественным неигровым персонажам. Также в игре присутствуют предметы с особыми функциями, которые можно активировать только с помощью бога, в противном случае герой продаст эти предметы, несмотря на то, что. Также герой может приручить питомца, который будет его спутником. Приручение питомца и выбор его имени неподконтрольны богу.

В игре присутствует ограниченный режим PvP: бог может послать героя на дуэль с героем другого бога. Победивший герой забирает все золото и часть предметов проигравшего героя. В ходе боя бог может помочь своему герою, однако иногда эти попытки оборачиваются помощью противнику.

Еще игра содержит многочисленные отсылки к произведениям мировой культуры и разнообразные типы языковой игры. Механика и мир игры представляют собой пародию на религию, компьютерные ролевые игры, игры жанра MMORPG и компьютерные игры в целом.

Ещё можно отметить русский проект «Сказка» отчасти схожий с Годвилем, тоже многопользовательская ролевая игра для нуля игроков, только тут вы уже являетесь духом-Хранителем, который взял под опеку смертного и сделал того бессмертным героем. Вы также можете помогать своему войну какими-то заклинаниями, отправлять его на ПВП, вступать в гильдии, влиять отчасти на мир игры и просто любоваться его прогрессом.

MyBrute

Последним проектом на сегодня будет MyBrute — это ZPG немного не такая как все, My Brute — это файтинг с элементами ролевой игры, впервые выпущенная в марте 2009 года. My Brute возникла как бесплатная браузерная Flash-игра.

Игрок начинает с создания аватара под названием Brute. Игроки могут создавать столько Брутов, сколько захотят. Бруты новых пользователей по умолчанию общедоступны и могут использоваться кем угодно в битвах. Тем не менее, пароль может быть добавлен на страницу ячейки Brute, чтобы его мог использовать только человек, который создал Brute.

Игроки могут настроить своего Брута, дав ему имя и регулируя такие переменные, как пол, одежда, причёска, аксессуары и цвет кожи. Затем Бруту случайным образом назначаются очки способностей (здоровье, сила, ловкость и скорость), навыки, оружие и питомцы. В игре 26 видов оружия, 28 навыков для изучения и 3 питомца: собаки, волки и медведи. После создания персонажа отправляем его на арену и наслаждаемся анимированным боем. Опыт идёт как за выигранные, так и за проигранные бои.

Каждый раз, когда уровень игрока повышается, одна из трёх характеристик Брута (сила, ловкость и скорость) увеличивается. Также есть шанс, что Брут получит новое оружие, новый навык или нового питомца, который дерётся с вами на арене.

Бои на арене полностью автоматические и не требуют вмешательства пользователя. Бойцы с более высокими уровнями и навыками, как правило, более успешны. Хотя игроки не могут контролировать своих Брутов в бою.

Брут также ограничен тремя или пятью (в зависимости от версии игры) боями в день. В день создания персонажа разрешено шесть боев. Однако, поскольку игрокам разрешено создавать столько Брутов, сколько они пожелают, игроки могут продолжать сражаться, используя других персонажей.

Приведённые выше проекты — это конечно же не все, я рассказал о тех, которые ярко описывают жар ZPG, есть ещё такие игры как Квест NPC, Хроники Астерии и Lords of Midnight III где игрок может ничего не делать, а только наблюдать как бегают персонажи, изредка вмешиваясь в происходящие события.

В нынешнее время таких игр конечно же не делают, но можно отметить недавно вышедшую Loop Hero, где есть отголоски данного жанра, в игре вы меняете рельеф тем самым усложняя или упрощая игру и получая нужны ресурсы в то время как Протагонист самостоятельно идёт по тропе и сражается со встречаемыми монстрами, при этом у вас нет возможности влиять на его действия.

Ну и что в итоге?

Жанр Zero Player Game, является очень нишевый и весьма непопулярен как у игроков, так и у разработчиков видеоигр, и возможно он так и останется никому не известен и представлять жанр будут несколько игр, но это стоит того чтобы в него поиграть. Я думаю будет круто добавить себе в копилку такой жанр как ZPG. Моя мысль была в том, чтобы донести вам ту небольшую информацию о существовании данного жанра и его играх, и я думаю у меня получилось и может даже кто-то захочет стать богом ненадолго.

ссылка на оригинал статьи https://habr.com/ru/post/568812/

Лайфхак для твиттерян, или по следам Твидиума

Опубликовано автором
Ответить

После закрытия Леонидом Кофманом своего знаменитого проекта Твидиум длинный ряд пользователей Твиттера в полной мере ощутил, сколь неудобна и недружелюбна к юзерам эта социальная сеть. Говорю практически без сарказма, т. к. сам прочно нахожусь в числе недовольных… анфолловинг и массфолловинг нажатием всего одной кнопки, парсинг твитов и отложенный постинг, как в Твиттере жить без всего этого? — согласитесь, ну нереально же.

Недовольство влечет за собой, как правило, желание подвигать за… пошевелить мозгами. Данный материал представляет собой, так сказать, отчет о результатах соответствующих изысканий, призванных вернуть себе — хотя б в некоторой степени — прежние удобства. Но автор не жадина и всегда готов поделиться тем немногим, чем располагает, с благодарными читателями… Представленный сегодня на ваш суд скрипт, пожалуй, сыроват для имиджа коммерческого интернет-сервиса (API Twitter всячески противится такого рода использованию своих ресурсов, что и было, как представляется автору, началом конца Твидиума и ему подобных проектов), но в качестве однопользовательского «домашнего» приложения — изрядно облегчает работу с несколькими твиттер-аккаунтами.

Twitter Toolkit onRails
Twitter Toolkit onRails

Итак, поехали. Для начала зададимся вопросом, что именно нам понадобится, дабы автоматизировать процесс анфолловинга невзаимных аккаунтов? Иными словами — как в Твиттере «на автомате» отписаться от тех, кого читаете вы, но кто не читает вас? — все, на самом деле, весьма несложно. И беспрестанные изменения веб-интерфейса Твиттера (твиттеряне этого почти не замечают) нам с вами ровно побоку, коль скоро API Twitter не чинит (в данном случае) никаких препятствий.

Примечание. Вам потребуются установленные на вашем ПК Ruby и gem ‘twitter’ (зависимости будут инсталлированы автоматически).

Понадобятся ключи доступа, запрос которых теперь проходят в Твиттере ручную модерацию. Которые, после получения, инициализируем следующим образом:

  def client     config = {       consumer_key: '******************',       consumer_secret: '*******************',       access_token: '***************************',       access_token_secret: '************************'     }     Twitter::REST::Client.new config   end

И — элегантно получаем список читателей (фолловеров) аккаунта, вызывая метод get_followers с параметрами client, user_id (user_id — ваш никнейм в Твиттере):

  def get_followers(*args)     follower_ids = []     next_cursor = -1     while next_cursor != 0       cursor = args[0].follower_ids(args[1], cursor: next_cursor)       follower_ids.concat cursor.attrs[:ids]       next_cursor = cursor.send(:next_cursor)     end     followers = []     follower_ids.each_slice(100) do |ids|       followers.concat args[0].users(ids)     end   end

Совершенно аналогично достаем массив френдов, после чего вычитаем первый массив из второго, получая список аккаунтов, предназначенных для анфолловинга. В скобках: в этот перечень войдут также и аккаунты, действие которых приостановлено Твиттером.

Вот, собственно, и вся премудрость… а дальше совсем просто:

unfollow(client, list)

Полностью рабочий скрипт доступен по ссылке, требуется лишь вписать токены доступа и никнейм твиттер-аккаунта. Автор готов поручиться, что ни один ваш читатель не будет таким образом анфолловлен, не беспокойтесь. Пробуйте.

И сразу возникает вопрос: если изменить вектор вычитания — получим, стало быть, список аккаунтов уже для фолловинга? — т.е. перечень тех, кто подписан на вас, но на которых не подписались пока еще вы. Как с этим?

Получаем перечень фолловеров
Получаем перечень фолловеров

Ответ — да, верно. Список акков мы таким образом получим, но далее пойдет не столь гладко, как с анфолловингом. Вкупе с массфолловингом в игру моментально вступают ограничения API Twitter.

Ответный фолловинг
Ответный фолловинг

Взгляните на скриншоты. Сперва прога получает перечень фолловеров, затем — френдов; далее идет сравнение двух массивов и начинается фолловинг. Каждый раз после подписки на несколько аккаунтов — от Твиттера приходит отлуп, и приложению приходится засыпать (rescue) на некоторое время, после чего работа возобновляется. Увы, в отличие от анфолловинга, API Twitter делает все для того, чтобы затруднить нам с вами автоматический фолловинг, хотя бы и ответный, приходится с этим мириться. В качестве альтернативы я написал некий комбинированный сервис: приложение (да, это уже не скрипт) в качестве итога работы выводит на страничку заданное число ссылок на ваших фолловеров, в каждую из которых нужно ткнуться мышкой и вручную зафолловить. Как вариант.

Несколько слов о приложении, которое всегда доступно в гитхабе. Это rails-app (Ruby on Rails 6), веб-интерфейс которого выполнен на основе Bootstrap 4, информационные сообщения — Flash Messages; на данный момент умеет ответный фолловинг описанными выше двумя способами (автоматический и наполовину ручной), анфолловинг без никаких ограничений, парсинг твитов из любого указанного вами твиттер-аккаунта и постинг твитов с рандомными промежутками времени, также любое количество ретвитов по ключевым словам или тэгам; также способен вытаскивать перечень читателей твиттер-аккаунта (меня однажды попросили об этой фиче).

Парсинг твитов
Парсинг твитов

Приложение способно работать с любым количеством твиттер-аккаунтов, в том числе и одновременно: все задачи объявляются на основе Active Job, позволяя параллельное выполнение. Разумеется, реализована возможность работы посредством https-прокси (внимание, без проксей одновременная работа с несколькими аккаунтами крайне нежелательна и способна привести к временному либо даже перманентному их закрытию; но работа с одним аккаунтом вполне безопасна). Не составляет труда доустановить сверху sidekiq, при желании (вкупе с Redis обеспечит более стабильную работу).

Авторетвиты по ключу "checkmate"
Авторетвиты по ключу «checkmate»

Ну, вот как-то так. Леонид Кофман скептически пожмет плечами, вероятно, но… но вот как умеем. Хотя Твидиум был круче, конечно.

ссылка на оригинал статьи https://habr.com/ru/post/568814/

Почему мы так долго ждали изобретения молотилки и наступления промышленной революции?

Опубликовано автором
Ответить

Из книги «Рост индустриального искусства» 1892 года

Съедобные семена спелой пшеницы заключены в оболочку. И после сборки урожая, прежде чем их можно будет перемолоть в муку, сделать из них кашу или посадить в поле для получения урожая следующего года, с них необходимо удалить шелуху. Этот процесс называется молотьбой, или обмолотом.

Оболочка у семян прочная, поэтому молотьба требует много усилий. Традиционно её проводили при помощи цепа. Цеп – это просто короткая палка, соединённая с длинной верёвкой или цепью. Зерно разбрасывали по земле и били по нему палкой, чтобы вскрыть оболочку.

Среди других методов можно упомянуть «вытаптывание», когда деревенский скот топтался копытами по зёрнам или протаскивал по ним специальные салазки (по-латыни они назывались tribulum, и от этого слова в английском произошло tribulation, что означает «несчастье», «бедствие»).


Вытаптывание

Иногда зёрна тёрли о проволочное сито или засыпали в мешок и били по нему камнями. По-английски молотьба будет threshing, а архаичное написание этого слова – thrashing, что в современном языке означает «взбучка», «порка».

Поскольку молотьба была одним из наиболее энергозатратных этапов сбора пшеницы, она естественным образом требовала механизации. Молотилка – относительно простое устройство – как и хлопкоочистительная машина, челнок или велосипед, оно не требовало никаких научных открытий. И тем не менее, молотилки практически нигде не использовались вплоть до конца XVIII века в Британии и начала XIX века – в США.

Возникает вопрос: почему мы так долго ждали изобретения молотилки?

Ранние заявки и концепции

Нет, не потому, что никому не приходило в голову механизировать обмолот. Принято считать, что промышленная революция оказалась небывало изобретательной эпохой, по сравнению с которой предыдущие года в упор не видели изобретений. Однако стоит вспомнить, что и до XVIII века случались изобретения, многие из которых затем повсеместно использовались – особенно, когда они помогали в самых необходимых экономических процессах. Ткацкий станок и печатный пресс появились за несколько столетий до молотилки, и не сказать, чтобы кто-то из них был гораздо проще её [В России мастеровые Андрей Терентьев и Моисей Крик «придумали, как хлеб водою молотить» в 1655 году. В Измайловской вотчине царя Алексея Михайловича они построили молотилку с цепами и ступами, действовавшую от водяного колеса. / прим. пер.].

Молотилка упоминается в английских патентах ещё в 1636 году (с исторической точки зрения – почти сразу после работ Галилея и Фрэнсиса Бэкона). Сэр Джон Кристофер ван Берг, рыцарь Моравийский (сегодня это часть Чехии), сбежав от религиозных войн в Германии под протекцию английского короля Карла I, предложил ему и всей Англии свои идеи по поводу «различных механических инструментов и конструкций, работающих посредством весов». По современным стандартам патент получился слишком обширным и туманным. В нём перечислялось невероятное разнообразие машин: для накачки воды, стирки одежды, готовки мяса, раздувания кузнечных мехов, дноуглубления рек, подъёма затонувших кораблей, измерения расстояний и глубин – практически для всех механических задач. Ближе к концу списка упоминается изобретение «возбуждаемое ветром, водой или же лошадьми для чистого обмолота кукурузы (зерна), посредством которого множество теряемого ныне урожая можно сохранить, получая солому с качеством сена». В то время патенты не требовали подробных описаний, диаграмм или моделей, поэтому непонятно, как подобная машина могла работать, и было ли вообще это изобретение реальным. Суть в том, что уже к началу XVII века молотилка казалось нужной и возможной.

Почему бы и нет? Помол зерна в муку был механизирован водяными мельницами ещё в древнем Риме. Процесс обмолота был достаточно похож, так что мельница схожего рода вполне справилась бы и с ним. Через сто лет после ван Берга изобретатели на самом деле начали работать над этой задачей. Майкл Мензис из Шотландии запатентовал молотилку в 1734 году, а кроме него в XVIII веке было и ещё несколько попыток.

Так почему ни одна из этих машин не распространилась широко?

Проблемы с надёжностью

Одна из подсказок следует из отчётов об испытаниях ранних прототипов.

Некоторые подобные машины просто ломались. Про одну из машин Мензиса один историк писал: «вследствие большой скорости, необходимой для достижения идеального результата, машины эти вскоре ломались, и изобретение впало в немилость». Ещё одну такую машину испытывали в Шотландии в конце XVIII века, однако «всего через несколько минут модель разорвало на кусочки».

А когда они не ломались, они часто не могли нормально работать. В испытаниях 1753 года обнаружилось, что машина «отрывает ростки ячменя и пшеницы, вместо того, чтобы очищать зерно, и в лучшем случае подойдёт для овса». Во время другой попытки в конце XVIII века выяснилось: «Вследствие опытов над этим агрегатом он показал себя дефективным, как произведя слишком мало работы за отведённое время, так и повредив зерно, к тому же и сам видимо пострадал, и тем значительно снизил свою рыночную ценность».

В целом историк Макклиланд пишет, что молотилки конца XVIII – начала XIX веков находились «среди самых сложных и дорогих сельскохозяйственных агрегатов Америки и Британии. Высокая их стоимость и частые поломки не способствовали их быстрому принятию, когда ‘наименьшей их неисправностью была смерть машины целиком’ ». Он пишет о том, что и Вашингтон, и Джефферсон интересовались молотилками, но:

Машина Вашингтона, построенная по планам Уильяма Букера, вскоре продемонстрировала неудовлетворительные результаты. У машины Мэриленда, построенной с помощью планов полковника Андерсона, искривилось колесо, и её забросили. В 1802 году иммигрант из Эдинбурга продемонстрировал в Средне-Атлантических штатах «шесть-семь» машин, основанных на «шотландском принципе», но у всех их вскоре начались проблемы, с которыми не смогли справиться «обычные работники». Машину, запатентованную в 1803 году Джедедайей Тёрнер, и основанную «на совершенно новых и очень простых принципах», так никогда и не начали производить. Возможно, Вашингтон обращался ко многим потенциальным сельскохозяйственным пионерам, выражая своё разочарование этой новой и перспективной технологией в 1793 году: «Я уже столько перевидал начавшихся и окончившихся изобретений, что почти уже решил придерживаться старого способа обмолота».

В чём была проблема?

Одной из сложных задач было найти правильную базовую идею дизайна машины. Как это часто бывает, некоторые из ранних попыток пытались слишком точно имитировать работу человека – эти машины автоматизировали движения цепа, продолжая при этом молотить зерно, лежащее на земле. Такой принцип получил название «избиения».


Схема машины-«избивалки»

«Все машины, работавшие на принципе избиения, страдали от одной и той же проблемы. Ударная нагрузка, вызванная механическими движениями, отделявшими зерно, вызывала быструю поломку частей машины, приводя её в ветхость», писал Макклиланд. Эта проблема не миновала и машину Мензиса 1734 года.


Ещё одна «избивалка»

Принцип «протирания» был лучшей идеей. Он был больше похож на работу мельницы или хлопкоочистительной машины: зерно поступало во вращающийся барабан, колышки или другие выступы которого стирали шелуху с семян. И хотя споры насчёт того, как лучше молотить – избивать или перетирать – шли вплоть до 1830-х годов, все успешно работавшие машины принадлежали ко второму типу.


Обмолоточная машина Мейкля, 1786 год

Однако остаётся впечатление, что обмолоточная машина не получила распространения вплоть до одного ключевого прорыва в схеме её работы. Нельзя назвать одного изобретателя молотилки, или точную дату её появления. Последовательность изобретений растянулась на несколько поколений: Эндрю Мейкль построил первую такую успешную машину в Шотландии в 1786 году: Джозеф Поуп изобрёл её популярный вариант в США в 1820-м: братья Питтс улучшили её систему привода и провеивания (очистки зерна от плевел и мусора) в 1830-х.


Обмолоточная машина Поупа, 1832

Нельзя также сказать, что какая-то одна схема стала наиболее популярной. История рассказывает нам о постепенных улучшениях эффективности, надёжности и стоимости, благодаря которым машину принимало всё большее количество фермеров. Подобная тенденция постепенного улучшения применима к большинству изобретений – даже тех, у которых есть свой «герой» и точная дата изобретения. Но даже с этой точки зрения у молотилки получается необычно долгая и постепенная история развития.

По моему мнению, схема работы успешной молотилки как раз немного превышала порог сложности комбинации из достаточно большой силы и достаточно деликатного обращения с материалом. Ткацкий станок – это достаточно сложная машина, выполняющая замысловатую работу, но при этом не прикладывающая к материалу значительных усилий. Мельница, которая мелет муку, или падающий молот в кузнице, оказывают очень сильное воздействие на материал, однако ничего сложного или тонкого в их работе нет. Упомянутые устройства использовались задолго до Промышленной революции. Но молотилке требовались оба эти качества, причём в такой комбинации, из-за которой качество изготовления механизма стало критично важным. Только так машина могла соответствовать высоким стандартам надёжности и стать практичным инструментом, пригодным для реального применения. Этому способствовала простая и надёжная схема работы – но грамотное её исполнение значило не меньше.

Проблемы производства

И вот некоторые свидетельства в пользу этого, взятые из исторических источников:

Периодическое издание сельскохозяйственной тематики Genesee Farmer в апреле 1831 года пишет в статье, посвящённой молотилкам:

Одна из важнейших причин отказа подобных машин разных конструкций заключается в ненадёжной, дешёвой и беспечной манере, в которой они изготовлены. Часто их делают обычные плотники, если их можно так назвать – люди, едва способные изготовить ручку для двери сарая.

Вследствие всего этого фермер часто получает плохо продуманную, непрочную и шаткую машину, которую после каждого оборота приходиться заваривать, укреплять гвоздями и скобами.

В продолжении статьи автор даёт конкретные советы по сборке и использованию материалов этих машин:

Движущаяся машина, работающая на силе лошадей или же воды, должна быть так же хорошо сконструирована, и с использованием таких же хороших материалов, как мельница для муки. Делать основное колесо и шестерню из дерева – это даже хуже, чем бесполезно. Положиться можно только на самый мягкий и лучший чугун.

Уже отмечалось, что использование железа вместо дерева стало одним из ключевых шагов, предпринятых Генри Модсли для увеличения точности станков.

В книге 1843 года Рэнсом выступает в защиту молотилки, опровергая её плохую репутацию, приобретённую вследствие плохого изготовления:

Слышны предостережения против использования подобных машин, поскольку они ломают стебель, царапают и повреждают ячмень, делая его непригодным к осолаживанию; однако все эти неприятности случаются не из-за принципов работы машин, а из-за того, в какое состояние они часто приходят в руках рабочих; а иногда это происходит из-за недостатка навыков или желания, а также неправильных решений тех, кто ими управляет.

Многие подобные машины изготавливают люди, не способные похвастаться какими бы то ни было познаниями в механизации. Они покупают никуда не годные отливки, и с помощью деревенских умельцев изготавливают имитацию качественных механизмов. Усовершенствование этих машин должно полагаться подгонку всех их частей с математической точностью, на чёткое и точное совмещение всех их частей. Неразумно поэтому ожидать, что строительство подобной машины можно осуществить в таком месте, где есть только кузня да верстак. В результате появляется определённая степень недоверия к эти машинам, несправедливо переносимая на принципы их работы.

Если качество производства было критически важным фактором, как изготавливали самые первые машины?

Производственные системы

Сегодня сельскохозяйственное оборудование производят крупные специализированные компании, распространяющие свою продукцию по всей планете. Но в XVIII и XIX веках ничего такого не было. Под «сельскохозяйственным оборудованием» подразумевались плуги, серпы и телеги, а изготавливали его местные умельцы – городские плотники, кузнецы и каретники. В мире не просто было очень мало крупных производителей – до серьёзного распространения железных дорог в середине XIX века не было эффективных сетей для доставки продукции большому количеству фермеров.

Из рекламы ранних изобретателей молотилок видно, какие способы приобретения своих машин они предполагали.


«The Virginia Gazette», Уильямсбург, 1772

Во многих случаях изобретатели предлагали прислать планы и/или модели, предполагая, что машину будут строить местные мастеровые – плотник или мельничных дел мастер [millwright] (последние были ближайшим аналогом инженеров-механиков в XVIII веке). В рекламе 1772 года из газеты The Virginia Gazette восхваляется изобретение, «которое сможет осуществить любой мало-мальски способный плотник» или даже «слуги хозяина». Более чем 50 лет спустя, в 1823 году, мало что поменялось. В статье издания American Farmer, описывающей молотилку Джозефа Поупа, цитируется письмо от сына умершего изобретателя, который говорит, что эту машину «можно собрать очень дешёво – материалы, включая станину, обойдутся в $13, а сделать её может любой квалифицированный рабочий (плотник или столяр) за 12 дней».

В других случаях изобретатели предлагали высылать не планы, а запчасти «с необходимостью самостоятельной сборки». В 1735 году Эндрю Гуд Райт из Эдинбурга рекламировал свою молотилку так: «Желающие их приобрести отправляйте заявки в Эдинбург. Получать посылку должен мельничных дел мастер, чтобы он понял, как собирать машину; любой подобный специалист справится с этим делом, увидев однажды эту машину в действии». Он также упоминает о возможности приобретения лицензии на распространение: «Мельничных дел мастера с рекомендациями от джентльменов могут приехать в Эдинбург, дабы разобраться в принципе работы машины, и смогут изготавливать их по всей стране на условиях лицензии». В рекламе 1796 года «Джон Джабб, мельничных дел мастер и изготовитель механизмов», предлагает оба варианта: он «отправит машину в любую часть Королевства» за 25 гиней плюс стоимость пересылки, или отправит планы вместе «машиной, изготовленной в Лидсе, разобранной, с тщательно размеченными запчастями – так, чтобы любой рабочий с лёгкостью мог собрать её».


The National Gazette, Филадельфия, 1823

Есть свидетельства того, что молотилки процветали там и тогда, где их собирали их изобретатели, или опытные механики, решившие специализироваться на них. В одном источнике сообщается, что к 1800 году «почти все молотилки в Англии» были изготовлены одним «промышленным рабочим по имени Стивенсон». В статье хвалили эти машины за то, что их легко было крутить вручную, за малое трение – «однозначная гарантия качественной работы». Изобретатель Джозеф Поуп вскоре после выхода этой статьи договорился с производителем машин о производстве его молотилки.

С мая по октябрь 1823 года в «Philadelphia National Gazette» публиковалась реклама, в которой говорилось, что «господа S. V. Merrick & Co. Engine Manufacturers, Филадельфия» наделены привилегией производить и продавать его машину; потенциальных клиентов поощряли «обращаться» за машиной именно к ним. В то время у производителя двигателей был хорошо оборудованный механический цех с точными инструментами и квалифицированными рабочими, что было обязательным для изготовления надежных машин.

По итогам, в первые десятилетия существования молотилка страдала от плохого качества изготовления ввиду отсутствие специализированных слесарей.

Контраст с жаткой

Для сравнения рассмотрим близкое по теме сельскохозяйственное оборудование, изобретённое на несколько десятилетий позже: жатку.


Жатка Маккормика, 1831, «Scientific American»

Жатка срезала стебли злаков в поле, автоматизируя шаг, непосредственно предшествующий обмолоту. Как и в случае с молотилкой, критически важной характеристикой жатки была надёжность – у ранних моделей не получалось срезать запутанные стебли, они засорялись, если стебли были сырые, или плохо справлялись с холмами.

Одну из наиболее успешных жаток придумал Сайрус Маккормик. Он начал продавать их в 1840-х, но не стал полагаться ни на местных мастеров, ни на производственных партнёров. Первые машины он сделал сам, и в итоге создал большую центральную фабрику.

Маккормик пытался выйти на национальный рынок, но ему мешали примитивные сети грузоперевозок. Один из его биографов, Кассон, в 1909 году писал:

Чтобы доставить сем жаток, проданных в 1844 году, на Запад, сначала их нужно было фургонами перевезти в Скотсвилл, потом каналом в Ричмонд, затем по реке Джеймс к Атлантическому океану, вокруг Флориды до Нового Орлеана, там перегрузить на речное судно, шедшее вверх по рекам Миссисипи и Огайо до Цинциннати, а оттуда в разных направлениях – до ожидавших поставки фермеров. Четыре жатки опоздали к началу сбора урожая 1844 года, и за две из них не заплатили.

Позднее Маккормик переехал из Виргинии в Чикаго, открыв офис в сердце транспортной сети, объединявшем железные дороги и водные пути – и при этом ближе всего к крупнейшему его рынку на Среднем Западе (с плоскими угодьями и нехваткой рабочих рук).

Он также привнёс несколько инноваций в бизнес-практики: он активно рекламировался в газетах, организовывал полевые демонстрации, предлагал фермерам письменную гарантию и беспроцентную рассрочку до следующего урожая, и в каждом регионе строил свою сеть дистрибьюторов.

Ни один из изобретателей, о которых я читал, не делал ничего подобного с молотилками – по крайней мере, до 1830-х годов, когда они уже достаточно сильно распространились.

Почему на это ушло столько времени?

Вопрос распространения молотилки включается в более общий вопрос, интересующий меня: почему мы так долго ждали Промышленной революции?

Некоторые изобретения зависели от теоретических концепций, открытых только во время Научной революции – электрогенератор или паровой двигатель. Другие не зависели: молотилка, хлопкоочистительная машина, прялка «Дженни». В чём разница между этими и другими, казалось бы сходными по сложности и важности изобретениями, принятыми обществом на столетия ранее – ткацким станком, прялкой, печатным прессом?

Одна из причин – возможность производить доступные и надёжные машины. Вероятно, эта же возможность была важна для появления велосипеда – и, вероятно, даже более важна; я уже писал об этом в одной из статей. Ещё один пример приводит в своей книге 2009 года Роберт Аллен – производство точных деталей для часов было необходимо для появления ранней версии прядильной машины, известной, как "ватермашина" (и работавшей от водяного колеса). «Часовая промышленность стала источником шестерёнок – в частности, латунных – именно эти шестерёнки стали точными деталями ватермашины. Без часовщиков ватермашину невозможно было бы спроектировать».

Вторая причина – для любого изобретения должны существовать предпосылки. Если требуется особое производство, централизованному производителю нужен доступ на обширный рынок. Для этого требуется коммуникационная инфраструктура, типа газет, для рекламы товаров, и транспортная инфраструктура, типа железных дорог, для их доставки.

Ещё одна причина, по которой механизация пришла в текстильную промышленность на десятилетия раньше сельского хозяйства, заключается, вероятно, в разных бизнес-моделях. Ричард Аркрайт изготавливал свои прялки не для того, чтобы, как Маккормик свои жатки, продавать их другим, а для того, чтобы производить дешёвую нить. Он сам был рынком для своих машин, они были инвестициями в бизнес нового типа. Такая бизнес-модель не была доступной для ранних производителей сельскохозяйственного оборудования.

Ещё одним поучительным сравнением будет паровой двигатель, для которого тоже требовалось существование производства высокой точности и качества. Компания «Бултон и Ватт» перешла к постройке централизованных фабрик специального назначения в 1770-х, за десятилетия до того, как эта модель пришла в сельскохозяйственное оборудование. Я предполагаю, что рынок фермеров состоял из большого количества мелких и географически разбросанных клиентов – в отличие от горной добычи, металлургов, пивоварен, и других клиентов, приобретавших двигатели Ватта. Поэтому в сельском хозяйстве проблемы маркетинга и дистрибуции были существенно более сложными. Не говоря уже о том, что, к примеру, добыча руды давала больше возможностей для капиталовложений в оборудование, чем фермерство.

Маховые колёса

Вероятно, всё это можно обозначить одним словом, инфраструктура. Способность производить оборудование заключается в инфраструктуре, типа железных дорог и газет (а сегодня – перевозок грузовиками и интернета). Инфраструктура уменьшает количество энергии, необходимой для активации любой разработки. Иногда сами разработки улучшают инфраструктуру, что создаёт самоподдерживающийся цикл, порождающий экспоненциальный рост.

Достаточно ли этого для описания скорости прогресса в нашей истории? Нужно ли нам вводить культурные причины – общий фактор изобретательности — «идею прогресса» от Джоэля Мокира против «поклонения предкам» и «чести и престижа буржуазии» Дейдры Макклоски? Кажется очевидным, что имеет значение, считали ли люди прогресс возможным и нужным. Если это не так, кажется удивительным совпадением, что Промышленная революция началась вскоре после трудов Бэйкона и начала Научной революции, причём в той же части света. Однако теперь, когда я лучше стал понимать проблемы изобретателей молотилки XVIII века, я склоняюсь в пользу инфраструктуры как главной причины задержки.

Или, говоря шире, я представляю себе существование набора перекрывающихся маховых колёс, каждое из которых создаёт свой добродетельный цикл. Улучшение инфраструктуры ускоряет прогресс, создающий в свою очередь больше инфраструктуры лучшего качества. Вера в прогресс порождает реальный прогресс, подкрепляющий веру. Прибавление дохода позволяет инвестировать в прогресс, порождающий ещё большее прибавление. Наука ведёт к прогрессу, помогающему продвигать науку. А поскольку все эти колёса пересекаются на прогрессе, все они усиливают друг друга косвенно, а может быть, и напрямую.

Библиография

ссылка на оригинал статьи https://habr.com/ru/post/568816/

Какие API и функции Kubernetes будут удалены в релизе 1.22

Опубликовано автором
Ответить

Kubernetes API развиваются и периодически обновляются. Когда готов улучшенный API на замену старому, старый удаляют. См. политику Kubernetes по удалению API.

Скоро будет удалено несколько API. Это беты, которые еще можно использовать в текущих версиях Kubernetes, но они уже deprecated. Им на смену придут обновленные стабильные версии API («GA», General Availability).

В Kubernetes 1.22 (релиз ожидается в августе 2021 года) будет удалено несколько deprecated API. На странице релиза Kubernetes 1.22 можно посмотреть его график.

Удаленные API версии в Kubernetes 1.22

В релизе 1.22 не будут поддерживаться версии API из списка ниже. Все это бета-версии, их заменят обновленные и более стабильные версии API.

  • Бета-версии API ValidatingWebhookConfiguration и MutatingWebhookConfiguration (версии API admissionregistration.k8s.io/v1beta1)

  • Бета-версия API CustomResourceDefinition (apiextensions.k8s.io/v1beta1)

  • Бета-версия API APIService (apiregistration.k8s.io/v1beta1)

  • Бета-версия API TokenReview (authentication.k8s.io/v1beta1)

  • Бета-версии API SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview (версии API из authorization.k8s.io/v1beta1)

  • Бета-версия API CertificateSigningRequest (certificates.k8s.io/v1beta1)

  • Бета-версия API Lease (coordination.k8s.io/v1beta1)

  • Все бета-версии API Ingress (extensions/v1beta1 и networking.k8s.io/v1beta1)

В документации Kubernetes описывается удаление API в релизе 1.22 и объясняется, чем бета-версии отличаются от стабильных.

Что делать

Ниже подробно описано, на какие ресурсы повлияет удаление и что нужно делать.

Ingress

Мигрируйте на API networking.k8s.io/v1 Ingress (доступно с v1.19). Связанный API IngressClass дополняет Ingress, позволяя настраивать разные виды Ingress в одном кластере. Если сейчас вы используете аннотацию kubernetes.io/ingress.class, замените ее полем .spec.ingressClassName.

Переводя Ingress на API v1, изучите каждое правило в этом Ingress. Предыдущие Ingress используют старый тип пути ImplementationSpecific. Вместо ImplementationSpecific переключите path matching на Prefix или Exact. Одно из преимуществ перехода на альтернативные типы путей — простота миграции между разными классами Ingress.

Вам нужно не только обновить свои методы использования Ingress API, но и убедиться, что каждый контроллер ingress, который вы используете, совместим с Ingress API v1. См. предварительные требования для Ingress, чтобы узнать больше об Ingress и контроллерах ingress.

ValidatingWebhookConfiguration и MutatingWebhookConfiguration

 Используйте API v1, чтобы извлечь или обновить существующие объекты API, даже если они были созданы с использованием более старых версий API.

Перейдите на версии admissionregistration.k8s.io/v1 для API ValidatingWebhookConfiguration и MutatingWebhookConfiguration, доступные с релиза 1.16.Используйте API v1, чтобы извлечь или обновить существующие объекты API, даже если они были созданы с использованием более старых версий API.

CustomResourceDefinition

Перейдите на API CustomResourceDefinition apiextensions.k8s.io/v1, доступный с v1.16.

Если вы используете внешние CustomResourceDefinitions, переключите существующие манифесты на новые версии API с помощью kubectl convert. Между бета- и стабильной версиями CustomResourceDefinitions есть функциональные различия, поэтому лучше протестировать их, чтобы убедиться, что после апгрейда все работает корректно.

APIService

Перейдите на API apiregistration.k8s.io/v1 APIService, доступный с 1.10.Если у вас уже есть агрегирование API с помощью объекта APIService, это агрегирование будет работать после апгрейда.

TokenReview

Перейдите на API authentication.k8s.io/v1 TokenReview, доступный с 1.10.

Предоставляя этот API через HTTP, сервер Kubernetes API использует тот же формат для отправки TokenReviews в вебхуки. Релиз 1.22 продолжает использовать v1beta1 API для TokenReviews, отправляемых в вебхуки. См. дальнейшие планы, где приводятся советы по переходу на стабильный API.

SubjectAccessReview, SelfSubjectAccessReview и LocalSubjectAccessReview

Перейдите на версии authorization.k8s.io/v1 этих API авторизации, доступные с v1.6.

CertificateSigningRequest

Перейдите на API certificates.k8s.io/v1 CertificateSigningRequest, доступные с v1.19.

Lease

Перейдите на версию coordination.k8s.io/v1 для API Lease, доступную с v1.14.

kubectl convert

Существует плагин для kubectl, который предоставляет подкоманду kubectl convert. Это официальный плагин, который можно скачать с Kubernetes. Подробности см. на странице о загрузке Kubernetes.

Используйте kubectl convert, чтобы указать в файлах манифестов другую версию API. Например, если в системе контроля версий у вас есть манифест, который использует бета-версию Ingress API, выгрузите это определение и выполните команду kubectl convert -f <manifest> --output-version <group>/<version>. Используйте команду kubectl convert, чтобы автоматически преобразовать существующий манифест.

Например, чтобы конвертировать старое определение Ingress в networking.k8s.io/v1, выполните команду:

kubectl convert -f ./legacy-ingress.yaml --output-version networking.k8s.io/v1

Подготовка к апгрейду

 Если вы управляете серверным компонентом API в кластере, попробуйте удалить эти API до апгрейда до Kubernetes 1.22.

Добавьте следующие аргументы kube-apiserver:

--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1=false,apiregistration.k8s.io/v1beta1=false,authentication.k8s.io/v1beta1=false,authorization.k9s.io/v1=false,certificates.k8s.io/v1beta=false,coordination.k8s.io/v1beta1=false,extensions/v1beta1/ingresses=false,networking.k8s.io/v1beta1=false

(Побочный эффект — отключится EndpointSlice v1beta1, обратите на это внимание при тестировании).

Когда вы переключите все kube-apiserver в кластере на этот параметр, бета-версии этих API будут удалены. Проверьте, что клиенты API (kubectl, инструменты деплоймента, кастомные контроллеры и т. д.) по-прежнему работают корректно. Если нужно, можно отменить изменения без сложного плана перехода на предыдущую версию.

Совет для разработчиков

Это совет для разработчиков расширений или других компонентов, которые интегрируются с Kubernetes.

Если вы работаете над контроллером Ingress, аутентификатором вебхуков, агрегацией API или другими инструментами, которые используют deprecated API, вы уже наверняка начали переход на новые.

Руководствуйтесь советами в разделе Подготовка к апгрейду, чтобы в вашем кластере Kubernetes использовались только новые API, и убедитесь, что код работает нормально. Укажите в документации, что должны сделать пользователи в связи с апгрейдом Kubernetes до 1.22.

По возможности помогите пользователям уже сейчас опробовать новые API (можно в тестовой среде), чтобы они сообщили вам о проблемах, если они возникнут.

В Kubernetes 1.25 будут еще deprecation, так что планируйте заранее.

Удаление Kubernetes API

Почему из Kubernetes удаляются некоторые API и что дают новые стабильные версии.

У Kubernetes есть политика deprecation для функций, включая Kubernetes API. Эта политика используется, чтобы заменять стабильные API (GA) в Kubernetes. В соответствии с этой политикой стабильные API заменяются только на новые стабильные версии тех же API.

Гарантии стабильности важны: если вы используете стабильный Kubernetes API, вас никогда не заставят перейти с него на альфа- или бета-версию.

Сначала выходит альфа, которая еще не до конца проработана и пока тестируется. Альфа-версии почти всегда отключены по умолчанию. Если ничего не получилось, они удаляются.

После альфы идет бета. Бета-версии обычно включены по умолчанию. Если тестирование проходит нормально, они становятся стабильными версиями. Если нет — дорабатываются.

В прошлом году Kubernetes официально принял политику для API, которые достигли бета-версии:

Если Kubernetes REST API доходит до бета-версии, начинается обратный отсчет. Затем у беты API два пути:

— выпускается GA, а бета признается deprecated — или

— выпускается новая бета-версия (а прежняя признается deprecated).

Раньше на три релиза в Kubernetes уходило примерно девять месяцев. Сейчас Kubernetes принял новый график, по которому выходит три релиза за календарный год.

Когда API удаляется, потому что переводится из бета-версии в стабильную или потому что оказался неудачным, Kubernetes следует политике deprecation и документирует варианты миграции.

Дальнейшие планы

Если вы используете проверки аутентификации для вебхуков, в будущем релизе Kubernetes объекты TokenReview будут отправляться в вебхуки с помощью authentication.k8s.io/v1 по умолчанию. Сейчас поведение по умолчанию — отправлять authentication.k8s.io/v1beta1 TokenReviews в вебхуки, и в Kubernetes 1.22 этот вариант останется дефолтным. Но вы можете перейти на стабильный API прямо сейчас: добавьте --authentication-token-webhook-version=v1 в параметры командной строки для kube-apiserver и убедитесь, что вебхуки для аутентификации работают корректно.

Если все нормально, можно оставить --authentication-token-webhook-version=v1 на всей control plane.

В релизе 1.25, который ожидается в следующем году, не будут поддерживаться бета-версии некоторых Kubernetes API, которые сейчас стабильны. Еще в v1.25 будет удалена PodSecurityPolicy, которая считается deprecated и не перейдет в стабильную версию. См. PodSecurityPolicy Deprecation: прошлое, настоящее и будущее.

Официальный список удаляемых API для Kubernetes 1.25:

  • Бета-версия API CronJob (batch/v1beta1)

  • Бета-версия API EndpointSlice (networking.k8s.io/v1beta1)

  • Бета-версия API PodDisruptionBudget (policy/v1beta1)

  • Бета-версия API PodSecurityPolicy (policy/v1beta1)

Нужно больше подробностей?

О deprecated функциях сообщается в заметках к релизам Kubernetes: 1.19, 1.20 и 1.21.

Больше о deprecation и удалении см. в официальной политике Kubernetes.

ссылка на оригинал статьи https://habr.com/ru/company/southbridge/blog/568712/

Тестирование или управление качеством? Часть 2. Типы тестирования

Опубликовано автором
Ответить

В предыдущей статье «Часть 1. Что такое тестирование?» я поделилась с читателями мыслями о том, в чем заключается суть тестирования. Во второй части моих рассуждений о тестировании и управлении качеством я подробно рассмотрю различные типы тестирования и проанализирую модели, которые помогают разработчикам визуализировать процесс тестирования, чтобы вовлечь в него всех участников команды.

Тестирование — это не только поиск багов. Также оно заключается в поиске различной информации, которая помогает выявить риски. Собранные данные облегчают принятие решений по устранению этих рисков.

ТИПЫ ТЕСТИРОВАНИЯ

Существуют разные способы разделения процессов тестирования на категории. Вот один из вариантов:

Постановка вопросов

Тестировщики умеют формулировать правильные вопросы, поскольку они привыкли рассматривать такие сценарии «что, если?», о которых зачастую не задумываются остальные. Умение задавать вопросы — тема обширная и заслуживает отдельного поста. Но самое важное — задав вопрос, внимательно выслушать и понять ответ. Нужно побороть соблазн просто поблагодарить и не тратить время на уточняющие вопросы.

Кроме того, лучше задавать вопросы открытого типа вместо тех, которые требуют ответа «да» или «нет». Например, вместо вопроса «Пользователем системы будет X?» лучше спросить «Кто будет пользователем системы?» — в этом случае мы оставим задел под уточняющие вопросы.

Задание направления разработки

Разработка на основе приемочных испытаний (ATDD) или на основе поведения (BDD) — это две распространенные методологии ведения разработки на основе примеров.

Команда рассматривает какую-то пользовательскую историю (user story) — возможно, обсуждая в формате «трех амиго» на понятных примерах, чтобы донести ее суть до каждого участника дискуссии. Отталкиваясь от этих примеров, они составляют приемочные испытания и проводят дополнительные обсуждения. По мере детализации они продолжают составлять тесты для бизнес-правил в исполняемом формате под API или уровень служб.

Взяв получившиеся тесты, программист может вести разработку на основе тестирования (TDD) — писать модульные тесты, затем сам код и постепенно дорабатывать его, чтобы все тесты завершались успешно. Если организовать работу команды таким образом, тесты на уровне модулей и API будут автоматизироваться в процессе разработки кода, и в нужных местах будут предусмотрены проверки, удостоверяющие, что результаты работы системы соответствуют ожиданиям команды. Тестировщик сможет направлять в нужное русло процесс автоматизации, применяя свои навыки проектирования тестов, помогая создавать оптимальные тесты — не только для благоприятных сценариев, но и для нештатного поведения и других случаев «что, если?».

Углубленное тестирование

Разумеется, нам не обойтись без углубленного тестирования, которое всецело опирается на возможности человеческого интеллекта. Большинство тестировщиков занимаются этим видом тестирования с большим энтузиазмом. Опираясь на свой опыт и критическое мышление, они пытаются найти менее очевидные баги в коде, которые остались незамеченными на предыдущем этапе. Если команда прорабатывала все аспекты тестирования с ранних этапов, обнаружится лишь незначительное число не самых критичных багов.

Но недостаточно просто находить баги и докладывать о них. Следует также разъяснять риски, описывать сценарии тестирования, предлагать потенциальные решения, расспрашивать клиентов об их впечатлениях и на основе этих дискуссий предлагать команде различные пути улучшения.

Проверка

Не буду слишком вдаваться в подробности автоматизации в целом, но скажу пару слов об автоматизации регрессионного тестирования, с помощью которого мы убеждаемся, что сегодня система по-прежнему правильно делает все то, что она делала вчера. Такое тестирование эффективно для валидации любых изменений, поскольку оно проверяет одни и те же аспекты снова и снова абсолютно идентичным образом, с чем не очень хорошо справляются люди.

Автоматизация дает нам возможность убедиться в согласованности кода, а также отслеживать и документировать результаты на протяжении всего процесса разработки. Если тесты автоматизированы должны образом, тестировщики могут сосредоточиться на описанных выше типах тестирования, требующих более деятельного участия человека.

КВАДРАНТЫ ГИБКОГО ТЕСТИРОВАНИЯ

Давайте посмотрим на схему квадрантов гибкого тестирования, где приведены примеры типов тестов, которые может выполнять команда. Хотя типов здесь указано немало, схема далеко не полная, да и контекст каждой команды по-своему уникален, поэтому я рекомендую рассматривать ее как инструмент, который облегчает выбор подходящих тестов в процессе дискуссии. К вопросу контекста я вернусь в этой статье немного позже.

Слева располагаются тесты ранних этапов, выполняемые до написания кода. Благодаря им вскрываются риски и любые случаи недопонимания, которые являются частой причиной недоработок и ошибок. Если заранее исключить недопонимание, можно избежать серьезных ошибок в коде.

Вот пример из моего личного опыта:

Во время встречи с разработчиком я сказала ему, что все автоматизированные тесты API внесены в систему и готовы к реализации. Он взял их из системы контроля версий, проглядел и сказал, что продукт не сможет пройти ни одного теста. Я посмотрела на него с удивлением, поскольку мы вместе присутствовали на всех встречах и вместе согласовывали метод тестирования.  Почему же тесты оказались непригодными? Он ведь даже еще не написал код. Выяснилось, что у нас было разное представление о том, как должна работать функция поиска. Именно после этого случая я стала оперировать более конкретными примерами во время обсуждений. Но я хотела подчеркнуть другое: если бы я не написала эти тесты и мы бы их вместе не изучили, разработчик написал бы код с серьезной ошибкой.  А поскольку нам удалось выяснить суть проблемы на раннем этапе, устранить ее было довольно легко. Код еще не был написан, и я помогла предотвратить появление бага.

Вернемся к нашим квадрантам. Справа располагаются тесты, сфокусированные на критике продукта. Сверху справа находятся бизнес-тесты, то есть те, которые понятны представителям бизнеса. Кроме того, бизнес может принимать участие в их проведении — например, в приемочном пользовательском тестировании. Снизу справа приведены тесты, критикующие техническое исполнение продукта. Этот квадрант включает большинство тестов, связанных с атрибутами качества развертывания и эксплуатации. Даже если команда заранее обсудила самые важные моменты с точки зрения клиента и самой команды, в том числе подходы к написанию кода, которые помогут в их реализации, или различные способы повышения безопасности, мой опыт подсказывает, что реальные тесты невозможно провести, не имея на руках готового кода. Такое углубленное тестирование заключается не только в поиске дефектов, но и в анализе тестируемого приложения и предоставлении команде обратной связи.

ТЕСТИРОВАНИЕ В РАЗЛИЧНОМ КОНТЕКСТЕ

Подобно тому, как существует множество видов тестирования, есть и множество контекстов тестирования. И один человек попросту не может учесть все комбинации этих двух факторов.

До этого момента я не упоминала гибкую (agile) методологию разработки, DevOps, непрерывное развертывание ПО, каскадную (водопадную) модель и вообще любой другой процесс организации разработки, которому может следовать ваша команда.  В каскадных проектах обычно существует команда тестировщиков, между которыми распределяется ответственность за тестирование предоставленного им ПО. Основная часть их тестов сосредоточена на отлове багов.

Последние 20 лет я провела в коллективах, работающих короткими циклами с частой выдачей результатов; компаниях, где тестировщики входили в команды разработки продуктов; командах, которые тесно взаимодействовали с бизнесом. Если кратко, то это agile, DevOps, непрерывное развертывание — для простоты я буду называть все это гибкой разработкой. Даже если в команде есть отдельный тестировщик, он не способен сам полностью оттестировать продукт. Он просто не может обладать всем спектром необходимых навыков. Он может оперировать базовыми методами тестирования и иметь опыт в применении одной или нескольких специфических методологий. Он может пополнять и углублять свои знания в предметной области. Но в зависимости от разрабатываемого продукта ему могут понадобиться другие навыки: например, при работе с хранилищами данных нужно хорошо разбираться в базах данных и целостности информации.

Невозможно найти такого универсального тестировщика, который будет все уметь, поэтому ответственность за организацию тестирования ложится на всю команду. И вся команда отвечает за качество.

ИТОГИ

Основная задача тестирования — выявление рисков и их устранение, притом в самой разной форме, будь то правильная постановка вопросов на ранних этапах прототипирования, формирование тестов до написания кода для направления разработки в нужное русло, исследование продукта на предмет неизвестных и неучтенных факторов либо анализ результатов тестирования в поисках тенденций, которые могут быть полезны для улучшения продукта или процесса. Все эти мероприятия вносят свой вклад в повышение качества продукта, но задачи тестировщика этим не ограничиваются.

Тестировщикам приходится выступать в роли наставников, налаживать связи, убеждать, мыслить нестандартно, относиться ко всему критически, предлагать способы устранения багов и последствий инцидентов, генерировать идеи для новых продуктов, которые решают более глобальные проблемы в программных и других продуктах, узнавать у клиентов и пользователей их впечатления и извлекать из собранной информации идеи для разработки и тестирования, управлять различными средами тестирования, участвовать в управлении релизными версиями и так далее. Список можно продолжать бесконечно, но все эти задачи сами по себе не решают проблему качества.

О ней и других важных аспектах мы поговорим в следующей статье.

В преддверии старта курса QA Lead приглашаем всех желающих на бесплатный двухдневный интенсив в рамках которого изучим теоретические основы методов тестирования требований. Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований. Изучим Example Mapping как способ протестировать технические требования. А также попрактикуемся в построении Example Mapping.

ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/568744/