Показаны сообщения с ярлыком ingress. Показать все сообщения
Показаны сообщения с ярлыком ingress. Показать все сообщения

среда, 1 апреля 2015 г.

Shonin XM Anomaly in YEKATERINBURG

В минувшую субботу прошел сабж. Ссылка на гплюс событие.

Те, кто не в курсе, что это вообще такое,  гуглите, смартфонная игра с геопривязкой. По всему миру.
В субботу очередной тур - в Екатеринбурге.

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


Мы - энлайты - выиграли в екб.

Расскажу о том, что мне особенно запомнилось и понравилось.

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

Напоминаю, несколько сотен по большей части незнакомых людей с общей идеей и целью.

Что было сделано для обеспечения такого качества координации? Дальше смесь того, о чем  знал точно и о чем примерно догадался.

Нас разбили на группы по 4-8 человек, названия групп - по фонетическому алфавиту ИКАО. Я был в группе Лума. Как я понимаю, первые несколько групп - альфа, браво, чарли - аналитики и небо.
У капитанов шевроны с буквой группы.
Каждый игрок шарит свое местоположение капитану и небу и слушает командную рацию.
Каждый капитан случает рацию операции.
У каждого капитана есть аналитик - небо, который дает ему указания из штаба и пересылает карты с оперативной информацией по задаче.
Задания для мобильных групп выдаются не заранее на всю игру, а за час-полчаса перед отсечками.
Группа аналитиков следит за явными действиями противников и за их перемещениями - косвенно, плюс по донесениям от полевых игроков.

По отзывам организация в Екб - круче питерской и киевской. Сильно запомнились способности и возможности людей по самоорганизации и самоотверженности при выполнении поставленной задачи (велокоманде, а имелась и такая, было реально холодно. Да, я был не в ней).
Оргам - спасибо и респект.


Вывод: мотивация - необходима, но не достаточна. Дисциплина и грамотная организация решает не меньше.


пятница, 6 июня 2014 г.

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


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


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

суббота, 8 марта 2014 г.

Уют

Всем девушкам екб намедни бойцами ingress был подарен красивый цветочек:
























Но это не все. Персонально Иринке подогнали такие вот элементы уюта:



















Для дома - отменная штука. Пост пишу, сидя на той, что с эмблемой энлайтов.

среда, 9 октября 2013 г.

Игры ingress пост

В минувшие выходные ingress-ekb тусовка (звучит, хех) устроила ивент мирового (это слово надо тянуть, ага) масштаба.
Процитирую итоговый пост организатора:

Операция "Fusion Star"
Екатеринбург, Россия, 5-6 октября 2013г.
Первая массовая совместная операция сопротивления и просвещения в Екатеринбурге.

Активная часть операции заняла 12 часов активной линковки.
В акции участвовало 27 агентов, 8 экипажей.

ИТОГО Общее кол-во линков 1214: 607 на зеленый портал и 607 на синий.
Узловые порталы выбраны в историческом сквере города:
«Памятник Татищеву и де Геннину» (Памятник основателям города был установлен 14 августа 1998 г. и приурочен к 275-летию Екатеринбурга)
«Водонапорная башня» - символ Екатеринбурга (архитектурный памятник конца XIX века)


Переведу: За ночь 27 человек на 8 машинах посетили 1214 точек в Екатеринбурге (памятники, красивые места, граффити, иногда - что попало) соблюдая внутриигровые правила.

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

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

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

Присоединяйтесь, чо.

Картинки. Раз:
Альбом: Ingress

Два:
Альбом: Ingress

Три:
Альбом: Ingress

Четыре:
Альбом: Ingress


Ссылки:
Пост в гуглоплюсе на мунспике.
Порадовали комментарии: That is super badass и Must be cold there, even inside they all wear jacket. Good job Russia.
Пост в гуглплюсе по-нашенски.
Вконтагтег

вторник, 17 сентября 2013 г.

Ingress Green Night

Неделю назад, в ночь со вторника на среду, мы провели Green Night.

В рамках акции перекрасили в красивый зеленый цвет центр и юго-запад Екатеринбурга, поставив 195 порталов 8 lvl (причем по России и ближнему СНГ их на тот момент было 410, считая наши). Восьмерки продержались до пятницы, к выходным сопротивление зачистило остатки.

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

В самую жару, часа в три ночи, деплоили с размаху, не выходя из транспорта, с вытянутых рук, некоторые по-македонски.

Выглядело это примерно так:


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

Ну а @Raspberries не останавливается, и проводит еще акции. Вива Enlightened!

вторник, 10 сентября 2013 г.

Lesson 292

В минувшие выходные боец @Raspberries жгла. Результат примерно такой:
Альбом: Ingress


Подробности и фоточки.

И еще история про кота от Александра Селяева.

Слово Канеру

Создайте стратегию тестирования как ответ на особенности и риски проекта

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

- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция — протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом — протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок — прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.

понедельник, 26 августа 2013 г.

Ingress

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

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

Изнутри выглядело как-то так:
Альбом: Ingress

вторник, 23 июля 2013 г.

Ingress

Накатал за неделю. Учтите, что было много дождей.
Альбом: Ingress


В Екатеринбурге я примерно пятый по enlightened, седьмой в общем зачете.
А еще сегодня научился настраивать дисковые тормоза. Лишил ребят из bikezone части заработка, вот ведь.

четверг, 18 июля 2013 г.

Ingress

Вот примерно так стараюсь проехаться ежевечерне, это вчерашняя:

Альбом: Ingress


Велик: 35 км,
Ingress: покоцал 7 и 8 фермы сопротивления.
Аудиокниги уходят только так.

понедельник, 15 июля 2013 г.

Lesson 277

Пока я стонал, что мне мешал дождик, enlightened боец Raspberries забацала нехилый trip автостопом(!) по уралу и создала, между прочим, вот такенное поле:
Альбом: Ingress


Слово Канеру

Проектируйте ваш план тестирования так, чтоб он соответствовал контексту.

Один из способов видуализации плана тестирования показан на рисунке. Это Satisfice Context Model. Пять пузырей на лучах звезды представляют то, что у нас имеется: ресурсы и ограничения. Центр звезды — наше решение. Объект планирования — решения по процессу тестирования, которые позволяют в рамках ограничений среды проекта и используя ресурсы достичь целей миссии.
Альбом: bug


Пять сущностей на картинке:

- Разработка. Система, которую вы тестируете. Как вы получаете продукт? Как его можно тестировать?
- Требования. Критерии качества продукта. Риски продукта. Чье мнение о качестве важно.
- Команда тестирования. Люди, которые тестируют продукт. Вы нанимаете команду? Are they up to speed on the technology?
- Лаборатория тестирования. Системы, инструменты, материалы, которые позволяют вам делать вашу работу. Есть ли у вас необходимое оборудование? В каком состоянии ваш баг-трекер?
- Миссии. Проблемы, решение которых будет рассматриваться как успех вашими клиентами. Находите ли вы быстро критичные баги? Производите ли точную оценку качества?

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

суббота, 13 июля 2013 г.

Lesson 276

Ingress и прочие велопоездки накрылись погодой.

Слово Канеру

Реальный план тестирования тест это набор идей, которым следует процесс тестирования.

План тестирования — основная идея всего, что вы делаете. Иметь эту идею очень важно. Документировать ли эту идею или нет — тема отдельного разговора.

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

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

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

вторник, 9 июля 2013 г.

Lesson 274

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

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

Слово Канеру

Три основных вопроса о стратегии тестирования «Зачем?», «Кому это нужно?» и «Сколько?»

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

- «Зачем?» Тестирование очень дорого. Не включайте в стратегию активности, которые не обращены к риску, достаточно важному, чтоб ради него проводить тестирование.
- «Кому это нужно?» Причины тестирования не являются законами природы, они коренятся в чувствах и ценностях людей, которым это важно. Не включайте в свою деятельность активности, если они не служат чьим-либо интересам.
- «Сколько?» Некоторые стратегии гораздо легче озвучить, чем реализовать. Мы протестируем все комбинации функций принтера — короткое предложение, включающее в себя тысячи (или сотни тысяч) тестов. Сколько из них вы в действительности проведете?

понедельник, 8 июля 2013 г.

Lesson 273

Черт побери, я 8 level ingress. Viva enlightened.
Для непосвященных, это примерно 1000 км с мая на велике.

Слово Канеру

О лицензировании инженеров ПО

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

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

Сейчас предпринимаются усилия для того, чтоб разработчики ПО подлежали лицензированию. Они достигли успеха в Texas, British Columbia, и Ontario. Отчет можно посмотреть в Construx Web page on Software Engineering Professionalism, http://www.construx.com/profession/home.htm. Mead (2001) дает продуманные аргументы в пользу лицензирования.

Организация Software Engineering Coordinating Committee (SWECC) занимается созданием Software Engineering Body of Knowledge (SWEBOK). SWECC это совместный комитет инженеров Institute for Electrical and Electronics Engineers Computer Society (IEEECS) и Association for Computing Machinery (ACM). Целью проекта SWEBOK является достижение консенсуса по уровню знаний, которые инженеры По должны иметь.
ACM не поддерживающая лицензирование инженеров ПО и вышла в июне 2000 в результате усилий SWEBOK от SWECC.

Позиция ACM заключается в том, что уровень наших знаний в разработке ПО слишком незрел, чтоб подлежать лицензированию. Кроме того Совет ACM считает, что лицензирование не будет эффективным в плане предоставлении гарантий качества и надежности ПО. Кроме того, совет заключил, что фреймворк лицензирования инженера, изначально разработанный для инженеров строителей не соответствует практикам разработки ПО. Подобная практика лицензирования даст лживые заверения в компетентности, даже если объем знаний будет достаточным. Также они исключит многих наиболее квалифицированных инженеров. Because SWECC has become so closely identified with licensing of software engineers under a professional engineer model, the ACM Council decided to withdraw from SWECC. (ACM 2000)
SWEBOK является важным аспектом движения по лицензированию. SWEBOK должен представлять интерес для вас, так как тестирование ПО является одной из областей SWEBOK, как и качество ПО. Вы могли бы загрузить SWEBOK по http://www.swebok.org.

Чтоб получить лицензию в качестве инженера разработчика вам придется сдать экзамен. Экзамен должен быть основан на знаниях и практиках, широко применяемых в нашей области. Лицензированному специалисту может быть предъявлен иск за злоупотребление положением. Профессионалы злоупотребляют положением когда причиняют вред клиентам (клиенты получают физические травмы, причиняется ущерб их имуществу, они терпят убытки) вследствие неприменения навыков или знаний в своей области. Если SWEBOK будет принят как основа знаний по разработке ПО, то законодатели, создатели экзаменов, судьи, адвокаты, присяжные и репортеры будут ссылаться на SWEBOK, когда захотят понять стандарты, определяющие, что инжернеры разработчики должны знать и уметь.
Мы критиковали SWEBOK в предисловии Главы 6, «Документирование тестирования». Мы не одни. Более подробно см. Notkin et al.'s (2000) отчет совету ACM.
База знаний инженерии ПО (IEEE Computer Society, Trial version 0.95) указывает в предислови, что:
Цель данного руководства — достижение консенсуса по способу подтверждения качеств и навыков разработчиков ПО и обеспечение доступа к актуальной совокупности необходимых для этого знаний...

===
Дальше еще три страницы байды в этом духе и очень мало слов о тестировании. При всем уважении к труду авторов - мне лень переводить.