Урок 3. Слайды 90-91

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

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

Мне достался Уралмаш.
Девять поездок, полное время - 20 часов из которых часов 5 добирался до уралмаша и уезжал из него.
Проехал 220 километров по городу.
Вот как-то так:

В процессе - открыл для себя уралмаш заново. По ощущениям Уралмаш - это проспект Космонавтов  в тисках деревень с севера, востока и запада и завода с юга.

В частном секторе несколько раз принимали за почтальона. Частный сектор - это как-то так:

Около проходных завода несколько раз привлекал внимание охраны, но в диалог со мной ни разу не вступили. Нашел одно бомбоубежище:

Понравилось. В следующий раз попробую взять не сто, а двести адресов, хех.


А дальше, как водится, лекции Канера. В этот раз совсем чуть-чуть.
Поехали:

Слайд 90
Добро пожаловать на третий урок.

Слайд 91
Вопрос, который я хочу рассмотреть сегодня - как узнать, прошла ли программа один из ваших тестов.

Урок 3. Введение. И Старая линза.

Откатались в Старую линзу. Туда и обратно.
Фотки: Как и зачем на на экскаватор надели покрышку? Она не разрезана.

 

Высота граффити метров десять:

Общий план:

Там есть откачивающий воду насос. А рядом - водопад:

Вблизи:

Стены карьера состоят из таких вот уступчиков:

А еще там есть адская бензопила, коорую обронил дредноут из вархаммера:

 

Только она работает не на бензине, а на суровости:

В целом - рекомендую .
Компания - мое почтение, четыре айтишника и сопровождающий их врач-педиатр.
70 километров туда и обратно.


Поехали.


Введение в лекцию.
Эта лекция расскажет об оракулах. Классический взгляд на оракулы говорит о том, что это механизм, позволяющий определить прошла ли программа тест. Например смотри Miller & Howden 1978 или википедию. Вместе с этим классически считается, что тестировщик может (или должен) иметь оракула для каждого теста. 

Эта лекция представит различные точки зрения. В идеале, вы узнаете о трех вариантах:

1. Ни у одного теста не может быть настоящего оракула. В лучшем случае у нас есть приближение, которое можно использовать. Мы считаем, что Elaine Weyuker (1980) первый автор этой точки зрения. Douglas Hoffman (1998) опубликовал диаграммы, иллюстрирующие корень проблемы. Мы ждем, что вы поймете и запомните диаграммы и выводы.Когда вы создаете тест, вы примерно представляете, что ПО должно делать и ожидаете от него соответствующего поведения. Но ваши спецификации неполны.
Не обязательно описаны все аспекты аппаратного и программного окружения до и после теста. К примеру, как часто вы описываете степень фрагментации памяти компьютера до и после теста? Поэтому оракулы можно использовать, хотя они могут и ошибаться: программа может пройти тест, но вести себя некорректно в области, не описанной вами. Правило, подверженное ошибкам, но которое при этом можно использовать называется эвристикой. Все оракулы являются эвристиками.

2. Мы можем описать процесс принятия решения о том, прошла ли программа тест, как результат работы некоторых широко используемых компараторов. Например, вы можете решить, что программа провалила тест, так как ее поведение не консистентно тому, как программа вела себя раньше или неконсистентна тому, как программа кажется нам, что должна себя вести или неконсистентно тому, как программа должна себя вести согласно спецификации. Мы ждем, что студенты изучат эвристики консистентности, описанные Bolton (2005) Тестирование без карты.

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

Самая серьезная слабость этой лекции в абсолютизации (1) и (2) относительно (3). Эвристики консистентности достаточны, так как они описывают и классифицируют большинство (может быть все) типы оракулов. Но они являются обобщением. Они не дают деталей для проектирования тестов, которые можно использовать для автоматизации. Мы вернемся к конкретным оракулам в вопросах и гайдах.

Литература:
Следующая литература обязательна к прочтению:

• Bolton M. (2005, январь) Тестирование без карты.

Следующая литература рекомендована:

• Kelly M. (2006) Использование эвристических оракулов тестирования.
• Koen B. (2011) Инженерный метод и эвристики: Персональная история.
• Weyker E. (1982) Тестирование не тестируемых программ.

Fireworks filmed with a drone

Урок 2. Слайды 87-89

Кстати да. Справа в этом бложике появился бейджик про сертификацию. И еще часть ребят есть тут:

Поехали:

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

Содержимое слайда:
Изменение контекста: внешняя лаборатория

• Люди могут отдавать свои продукты во внешние лаборатории по нескольким причинам:
• Лаборатория может предоставить некоторые уникальные навыки
• Заказчик может потребовать, чтоб тестирование проводилось независимой лабораторией
• Компания может считать, что аутсорсеры дешевле

Слайд 88
Тестирование во внешней лаборатории кардинально отличается от внутреннего тестирования. У них могут быть лучшие инструменты. у них могут быть лучшие навыки. Или нет.
Но у них отсутствует экспертиза в бизнесе клиента. Внешняя группа тестирования редко является экспертом в продукте клиента или его рынке. И их связи с сетью неформальных коммуникаций клиента очень слабы.
Внешние лаборатории обычно находят очевидные баги и несоответствия поведения продукта и документации, которую им предоставили.
Вспомните разницу между верификацией и валидацией. Верификация спрашивает, работает ли продукт корректно. Лаборатории тестирования занимаются именно верификацией.
Валидация же спрашивает, правильно ли был создан продукт. Когда тестировщик утверждает, что продукт не удовлетворяет нужды пользователей, он занят валидацией.
Многие компании не ждут от внешних лабораторий валидацией. Некоторые же реагируют с враждебностью на внешнюю критику ценности продукта для рынка.
Это не значит, что внешние лаборатории не могут проводить валидацию. Но если вы тестировщик или менеджер тестирования в лаборатории и собираетесь предоставлять подобный сервис, вам нужно будет ясно обозначить отношения с клиентом.
итак. что вы будете делать со всеми этими вариантами организации в таком случае? Мы можем сделать несколько предположений, работаете ли выы в компании производителе ПО или в IT отделе организации не связанной с ПО.

Слайд 89
Конец лекции 2.

Стих

Надышаться? Можно! Только ветром
На краю обрыва! На заре, -
Где берёзы свои руки – ветви
С нежностью протягивали мне!
Надышаться? Можно! Воздух – зыбок,
В дымке расстояний - чуть дрожит.
В этом вздохе... тысячи ошибок
Есть и моя, - маленькая, - жизнь! 

Говорят, отсюда, писал Альгис.

Урок 2. Слайды 85-86

Хорошая погода радует, а я таки обгорел.

Поехали:

Слайд 85
Позвольте мне рассказать о различиях между различиями между миссией в конкретном проекте и миссией группы тестирования в целом.
В проекте миссию диктуют потребности заинтересованных лиц. Но для группы миссия отражает то, какой она себя видит, причину ее существования.
Если говорить в терминах сервисов, которые предоставляет группа, некоторые видят себя исключительно охотниками на баги. Многие другие - защитниками качества. Кто-то считает себя полностью интегрированным в разработку и предоставляет множество сервисов, направленных на эффективность  и продуктивность группы.

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

• Охотники за багами
• Защитники качества
• Поддержка разработки
• Управление релизами
• Уменьшение стоимости поддержки

Слайд 86
Мир тестировщиков немного другой в IT организациях. Издатели продают ПО, которое создают их группы разработки.
Но есть и компании, которые не продают то, что программируют их IT отделы. В таких организациях IT - часть инфраструктуры компании, а не часть продукта или сервиса.
Многие американские компании обходятся со своими отделами разработки и продаж гораздо лучше, чем с инфраструктурными подразделениями. Они проводят границу между центрами создания денег и центрами затрат.
Они проводят агрессивную политику по снижению затрат. Многие такие компании видят в IT центр затрат. Я видел много эффективных групп тестирования в IT отделах, в которых работали квалифицированные тестировщики. Но еще я видел фундаментальную некомпетентность многих групп. И я видел, как это терпели гораздо дольше, чем я мог бы ожидать. Хуже того, я видел многих консультантов и докладчиков на конференциях, которые угождали некомпетентности таких групп, распространяя терпимость, нытье и обструкционистское отношение.
Нет абсолютно ясной связи между тем что ты делаешь и успехом компании: как твой сервис помогает успеху и эффективности IT, какой вклад IT вносит в успех компании, особенно если твои задачи рутинные, не требующие ума, твоя зарплата невелика и работаешь ты совсем недавно.

Урок 2. Слайды 82-84

Отличные выходные.
75км туда на велике, друзья. дача, мангал, баня, озеро, 70км обратно на велике.
Видимо, из за того, что отдыхалось хорошо - единственное фото за два дня:

Поехали:

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

Содержимое слайда:
Типичный контекст: задачи во времени.

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

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

Содержимое слайда:
Типичный контекст: редкие задачи

• Написание требований
• Участие в инспекциях
• Сборка продукта
• Руководство тестированием белого ящика
• Написание инсталляторов
• Конфигурирование и поддержка инструментов, связанных с программированием, таких как система контроля версий
• Архивирование ПО
• Исследование багов, анализ исходного кода
• Оценка надежности ПО
• Техподдержка
• Демонстрация продукта снаружи компании

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

Содержимое слайда:
Типичный контекст: редкие задачи

• Обучение новых пользователей использованию продукта
• Оценка рисков
• Сбор статистики от фидбеку
• Создание и поддержка инструментов тестирования
• Оценка продуктов конкурентов
• Оценка маркетинговой ценности различных программных и аппаратных конфигураций продукта
• Юзабилити тестирование
• Организация аудита продукта на соответствие стандартам
• Менеджмент проекта

Урок 2. Слайды 80-81

Разработчик:
- Сифилис по научному трипонема. Хм, так вот откуда слово трипак. А я думал это от слова trip, приключение.

Поехали:
Слайд 80
От компании к компании группы тестирования сильно отличаются друг от друга. Компании называют их тестировщиками, бизнес-аналитиками, инженерами по качеству или разработчиками в тестировании. Название не важно. Действительно важно - чем отличаются эти группы. Некоторые компании пытаются нанимать людей с похожим бэкграундом, похожими образованием, навыками, жизненной позицией - и вместе с этим приобретают одинаковые слабые стороны и слепые пятна. Я не думаю, что это хорошая идея.
Если бы я набирал группу тестирования в SoftCo, я бы искал людей с разными наборами навыков. SoftCo делает ПО для налогообложения, а значит у них большие базы данных и много вычислений. Я бы искал тестировщиков, которые знают, как ломать базы данных, и как ломать программы, работающие с числами.
Я бы пошел в колледж к юристов и поискал выпускников, специализирующихся на налогообложении. Они были бы экспертами в предметной области. Если бы я тестировал ПО по автоматизации фабрик, я бы пошел на фабрику.
Как тест менеджер я понимаю, какую информацию будет часто предоставлять моя группа и нанимаю людей которые действительно хорошо в ней разбираются.
В получившейся группе каждый будет специалистом, каждый сможет обучить чему-нибудь других, каждый представляет ценность и у каждого есть своя собственная возможность вызвать уважение заинтересованных лиц.

Содержимое слайда:
Типичная группа тестирования.
Группа SoftCo включает:

• Тестировщик специалист по БД и вычислениям
• Охотник на багов
• Создатель инструментов
• Специалист по налогам
• Специалист по сетям (включая нагрузку и безопасность)
• Тестировщик конфигураций
• Писатель
• Менеджер группы

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

Урок 2. Слайды 78-79

Поехали

Слайд 78
До сегодняшнего дня мы рассматривали шесть основных концепций.
Мы тестировали, чтоб найти информацию о качестве для заинтересованных лиц.
Мы фокусировали наше тестирование, чтоб быть уверенными в том, что мы достигнем информационных целей. На данном проекте наша миссия состоит в достижении информационных целей, чтоб получить специфическую информацию, которая нужна заинтересованным лицам.
Чтоб выполнить миссию мы разрабатывали стратегию. Главный компонент стратегии - описание техник, которые мы будем использовать, время и способ их применения и то, в какой степени мы будем полагаться на них.
Сегодня мы рассмотрим остальное, то как должны быть организованы работы по тестированию.

Содержимое слайда:
Мы рассмотрели:

• тестирование
• заинтересованные лица
• Информационные цели
• Миссия
• Стратегия
• Техники тестирвоания

Дальше:
Как должны быть организованы работы по тестированию.

Слайд 79
Нет единственного способа организации работ по тестированию.
Но позвольте мне начать с довольно типичного примера.
SoftCo создает ПО которое он продает другим людям. Их заказчики покупают  продукт и сервис обновлений. Они могут в любой момент перестать это делать.
SoftCo пишет и тестирует свой код. Программисты, менеджеры, тестировщики, техподдержка и директора работают в одном здании. У тестировщиков есть возможность встретить всех влиятельных людей и вступить в  социальные отношения с ними (прим. перев. - серьезно, он так и пишет).
В компании также есть неформальные митинги и праздники для поощрения общения между сотрудниками. Сотрудники, включая тестировщиков, обедают друг с другом, ходят в кафе и пабы и обсуждают проблемы продукта, проекта, компании. Такие обсуждения делают возможными появление неформальных сетей.
Такие неформальные сети - главная фича американских компаний, особенно компаний, создающих интеллектуальные продукты.

Урок 2. Слайды 76-77

Кстати да. Неделю назад сдал экзамен, ISTQB foundation level.
Фанфары не гремят, фотомодели на шею не вешаются. Я не рассчитывал, конечно, но небольшая надежда была.
Поэтому - возобновляю переводы и надеюсь наверстать отставание.

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

Кот взбешен.

Поехали:

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

Содержимое слайда:
Техники тестирования (Бах)
Техники тестирования обычно описывают как сделать следующее:

• проанализировать ситуацию
• смоделировать тестовый случай
• выбрать, что покрыть тестами
• определить оракулы
• сконфигурировать тестируемую систему
• наблюдать на тестируемой системой
• оценить результаты тестов

Слайд 77
Список Баха включает больше элементов, чем имеется в любой конкретной технике. Например тестирование доменов учит способам анализа программы. Она дает нам модель, описывающую дизайн каждого конкретного теста. Также она подсказывает, куда нужно смотреть дальше, если программа пройдет тест.
Но тестирование доменов не описывает, как оснастить тест, как настроить окружение, кто должен проводить тест и нужно ли его автоматизировать. Она говорит о данных, но не говорит о том, как хранить их или о том, какой инструмент лучше использовать для анализа результата.  Другие техники могут фокусироваться на этих аспектах в большей или  меньшей степени.
Мы вернемся к этому списку на нашем курсе тест дизайна. Если вы не видите большой ценности этого списка сейчас, не беспокойтесь. Когда вы получите больше опыта в этой области, вы, вероятно, измените точку зрения на то, как этот список может помочь узнать больше о значении техник тестирования и стратегии тестирования и на то, как выбирать техники, зная их слабые и сильные стороны. Еще позже вы перерастете этот список и создадите свой, чтоб описывать и сравнивать техники и стратегии тестирования.
А сейчас по мере изучения техник тестирования, вы доберетесь до точки, на которой вы споткнулись и дорисуете картину.

Рутина

Nautilus в ubuntu падает на замкнутых друг на друга симлинках.
Ы!

Мыслей вслух пост

http://www.the-village.ru/village/city/experience/145435-lichnyy-opyt-krugosvetka

О чем речь:

Двое молодых людей из Москвы 1,5 года назад бросили работу, сдали однокомнатную квартиру и отправились в кругосветное путешествие.

Прочтите, рекомендую, там очень интересно.
Очень неоднозначную реакцию вывали у меня эти ребята.

• Зачем нужны эти, такие люди? Для чего они? Для себя и счастья? Тьфу.
• Наверняка блоггеры и фотографы...
• Но интересно и немного завидно.
• А чему завидовать, я тоже могу так рвануть на полгодика, а то и больше.
• Они рассказывают, что скучают по работе.
• И, судя по тексту, им уже серьезно надоело и они хотят домой.
• И что путешествие - мечта, которую нужно исполнить. И это мне в них нравится.
• Совершать кругосветку в 20-30 лет гораздо лучше, чем в 50-60.

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

Попал в небольшое дтп

Жив, цел.

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

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

Дальше два варианта развития событий.
Первый, в моем идеальном мире: встаю, решительно иду к четверке и со словами:
- Зачем тебе зеркало, если ты им все равно не пользуешься?
ударом кулака сбиваю правое зеркало с виновника дтп. Потом поднимаю велосипед и уезжаю в дождливый закат.

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

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

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

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

Рутина

Анализ выдачи саджеста конкурента - важная задача

Выходные

Выходным - зачет.

В субботу с Турклубом  катали до песчаного и просто поматрасить по ближайшим лесам.
Как-то так:

Компания - мое почтение, слушал истории поддерживая челюсть. Сергей почти убедил меня перейти на контактные педали, Андрей показал тайную тропу на 7 ключей.
В основном ребята про воду и про горы, но я надеюсь, что мы еще покатаемся вместе.

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

Прогулка должна быть совсем небольшой и Паша обещал ехать в моем темпе, потому я вписался.
Выяснилось не зря.
Начали с повтора 40км маршрута майской прогулки, только без пробок и раза в два быстрее. Потом мы решили, что хотим озеро и купаться и долго искали подходящий берег около поселка Исеть. Не нашли.
Раз нет озера, то пусть будут скалы, решили мы и устремиличь на чертово городище.
Забраться туда не слезая с велосипеда мне так и не удалось.
На скалах уже торчали человек 50. Два десятка детишек 8-12 лет шастали по вертикальным отвесам как тараканы. Еще - на скалах обнаружилось огромное количество красивейших девушек, но на тех, кто не может подтянуться на 2 пальцах одной руки они, наверное, и не смотрят.

Попрыгав по камешкам - рванули покорять болото. Через полтора километра уткнулись в большую лужу, потыкались по сторонам, решили, что ну его все нафиг и надо ехать к озеру Песчаному.
Где я впервые за несколько лет попытался вспомнить, умею ли я плавать. Выяснилось - нет, не умею. И еще очень боюсь большой глубины. Надо тренироваться.
Народ вокруг считал, что купаться еще холодно, так что озеро было наше (на фото я справа):

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

Итого: 130 километров за два выходных дня, контакты нескольких отличных людей и огромное желание научиться нормально плавать.

Новостей пост

Купил рюкзак и питьевую систему.
Релиз города перенесен на неделю.
По другому проекту ниже критикала не регаю, ниже блокеров не чиним, ад и угар.
Откатал первую тысячу километров в этом году.


Давненько не играл. А плакатик хороший, если вы понимаете, о чем речь:

Равновесия пост

С подачи Ильи, хорошая музыка о распределении времени:

Anacondaz — Беляши