Подарка пост

Ништячок из поста выиграл dibr.

Ответ:

Подарка пост

Получен первый презент.
Вот такой- раз:




И два, чтоб понятен габарит был:




Собственно, первому догадавшемуся усб-фонарик или усб-хаб, самовывозом. Ну и респект, хех.

Lesson 58

Друзья, эту уютненькую читают ПМы, тестировщики и программисты?

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


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

Ну а кто аргументирует или расскажет, как у них - вообще молодцы.





Слово Канеру:

Ваш багрепорт представляет вас.

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

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

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

Итогов года пост

В лето Господне 1420 конец света не наступил
Хоть многое говорило о том, что наступит

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

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

По месяцам:

Январь
В десять раз больше, чем в прошлом году, катался на борде.

Февраль
Умер Френки.
Я захотел рассказать кому-нибудь о том, что я знаю в тестировании.

Март
Я не понимаю, зачем митинги и почая политика.

Альбом: home

Апрель
Выступил на девелкампе с рассказом о том, как у нас было с тестированием. Захотелось рассказать - а как надо, и еще - как будет.
Съездил на SQA Days 9. Понравилось.

Май
Дали бойца в группу. Дел мы с ним натворим...

Июнь
Офис переехал на запад.

Июль
Весь месяц играл студентами-практикантами. Тестировали, таскали столы, читали лекции, делали CI и ревью кода.
Дали еще бойца в группу. С учетом временных студентов - в моей группе семеро автоматизаторов.

Август
Я перехал на запад.
Начал переводить Канера. Промежуточный итог - 57 за полгода, примерно 2 в неделю.

Альбом: home

Сентябрь
Двух из четырех студентов наняли, одного из них - мне в группу.
Минус один в группе.

Октябрь
Переехал чуть на юг.

Альбом: home

Ноябрь
Спорим, много спорим с группой. Пишем классные тесты.
Сходил на митинг. Больше не пойду.

Декабрь
Только в наше направление, только в нашу группу тестирования наняли третью Наташу. Сколько Наташ-тестировщиц ходит по компании - никто уж и не считает...
Ездил на SQA Days 10. Видел живого Астеникса.
Из группы забрали бойца.

Есть вопросы

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

Вот ты - честно только - обрадуешься?
Я - нет.
Хоть и люблю читать.
Но потом - уже прочтя- пойму и оценю. А сразу как-то нет.

Lesson 57

Слово Канеру:

Сделайте ваш багрепорт эффективным инструментом продаж.


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

Стратегия продаж, как правило, преследует две цели.

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

Предвидеть возражения и бороться с ними Многие баги отклоняются, как совсем незначительные, невоспроизводимые, непонятные, неповторимые в реальном мире, становящиеся проблемой только в очень специфическом окружении; баги, которые опасно фиксить или не беспокоящие реальных пользователей продукта. Вы могли бы учесть эти возражения, следуя хорошим практикам отчетности: писать ясные и простые проверки, уточнять, что бага повторяется на разных конфигурациях. Другие возражения меняются от дефекта к дефекту, но вы могли бы предвосхитить их и включить в репорт дополнительные сведения. Мы де говорим, что вы должны биться за ошибку. Rarely or never say, "I know you're thinking of not fixing this, but if you think it's unimportant for this reason, then you should know about that." (Вот вообще не понял предложение) Вместо этого мы предлагаем заранее подумать о ключевых возражениях и включить в отчет такие сведения, как "Похожая ошибка была найдена во 2й версии продукта и менеджер техподдержки оценил ее стоимость в $100 000 накладных технических расходов."

Справедливости пост

МТС молодцы.

Поясню.

Намедни взалкал дешевых GPRS, EDGE и HSDPA интернетов. Местный опсос тарифами не радовал, обратил очи к МТС. Через интерфейс системы "павильон и продавец в ем" приобрел симку и кинул на счет денег.

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

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

И что бы вы думали? Еще до обеда мне сказали, что мое мнение крайне важно. А вчерась так и вовсе - вернули деньги.

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

Выводы:
1. Сотрудник техподдержки всегда поймет сотрудника техподдержки, ящитаю.
2. Проблемы не в Системе(тм), а в пидорасах и лоботрясах людях на местах.

Lesson 56

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

Зачем делать сложным то, что лучше не делать.


Слово Канеру:

Защита багов - драйвер их исправления.

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

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

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

Lesson 55

С тех пор как wurstenator'а забрали в другой проект - нас в кабинете два человека.

Заказал диван, посмотрим, добудут ли.
Кстати, вот так незаметно - дошли до 4-го чаптера.


Слово Канеру:

Chapter 4 Защита багов.

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


Ты это то, что ты пишешь.

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

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

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

И напротив, вы получаете все преимущества, если вы тратите время на то, чтоб написать отчет хорошо.

Рутина

Помнится, еще М. Дорофеев говорил, что не надо автоматизировать бардак. Потому как получится автоматизированный бардак.

Такой вопрос: если команда работает плохо - поможет ли ей KPI?
А если команда работает хорошо - зачем ей KPI?

Анекдот в тему:

Лежит Каа. Прибегает Маугли:
- Каа, Каа, рыжие собаки бросили нам вызов!
Каа:
- Нууу...
Маугли:
-Балу принял вызов!
Каа:
- Нууу...
Маугли:
- И Акела принял вызов!!
Каа):
- Нууу...
Маугли:
- И Маугли принял вызов!!
Каа:
- Нууу?
Маугли:
- Ну и ты, ты, Каа, тоже принял вызов!!!
Каа:
- Бля...

Я просто оставлю это здесь

Bugs and Battleships
by Edward Z. Yang

http://blog.ezyang.com/2011/12/bugs-and-battleships/

Ы!

М. Дорофеев, презентация Shewhart, 6-Sigma and snowflake-men

Избранные цитаты:

Нужно ли думать что он - человек снежинка с руками из жопы?

Альбом: bug

У запора и диареи KPI - время сидения в туалете - одинаковые. Но лечить мы их будем по разному.

Ну это смех, а вообще - посмотрите, там интересно.

Доброе утро

Коллеги, значится, шутят:

Альбом: office

Lesson 54

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

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

Если отбросить аспект критичности их работы, то у них хотя бы объект работы - организм - остается более менее один.

Хорошая песня, про выборы.
Выбери любого, главное выбери, не зря же тебе право выбирать, блядь, выбили!




Слово Канеру:

Классификация техник тестирования зависит от того, что вы о них думаете.

You might be puzzled about why we placed particular techniques where we did (ну не получилось у меня это перевести). Если так, то у меня для вас хорошая новость - ваш мозг включен. Вспомните, любое тестирование включает в себя все пять аспектов Five-Fold System. Мы перечислили техники по категориям, чтобы просто дать вам почувствовать разницу и выделить случаи, когда одни виды мышления превалируют над другими. Ваше мнение может быть иным. Например, один читатель спорил с нами о том, что нагрузочное тестирование может быть классифицировано как проблемно-ориентированное тестирование, а не как тестирование, основанное на активности(виде деятельности). Наш ответ - вы можете думать об этом в любом ключе.

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

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

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

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

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

1. Кто будет тестировать?
2. Какие аспекты программы будут тестироваться?
3. Какие типы проблем мы будем искать?
4. Какие задачи будут выполнены при тестировании?
5. Как вы будете оценивать результаты?

Lesson 53

Слово Канеру:

Техники тестирования основанные на том, как вы оцениваете результаты теста.

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


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

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

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

Эвристическая согласованность Согласованность - важный критерий оценки программы. Несогласованность может быть причиной регистрации дефекта или отражать изменения в архитектуре программы. Мы выделяем семь основных согласованностей:

1. Согласованность с историей. Нынешнее поведение функции соответствует ее прошлому поведению.
2. Согласованность с вашим представлением. Функция ведет себя согласно тому, как вы себе представляете организацию продукта.
3. Согласованность с аналогичными продуктами. Функция ведет себя подобно тому, как ведут себя такие функции в аналогах продукта.
4. Согласованность претензий. Функция ведет себя так, как люди говорят, что она должна себя вести.
5. Согласованность с ожиданиями пользователя. Поведение функция соответствует тому, что мы думаем, что хотят пользователи.
6. Согласованность с продуктом. Поведение функции соответствует поведению сопоставимых функций продукта или функциональных моделей продукта.

7. Согласованность с целями. Функция ведет себя согласно ее прямому назначению.

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

Второе пришествие

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

Вот ее портрет, кстати:

Альбом: office

И в следующий раз будет новая Наташка. У нас этого добра полно.

Пока шли от метро, смотрели на гостиницу "Орехово", жалели, что наша бронь в "Царицыно". Это я уж потом понял, что жалели зря.

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

По докладам, ведь мое мнение крайне важно для вас.

Алексей Лянгузов Грамотная работа с дефект-трекером -- путь к успеху! Хороший, годный доклад про то, что и у программистов на собеседовании надо спрашивать умение работать с дефект трекером.
Заметки на полях: Статус - надо ли что-то делать, подстатус - что именно. Ответственный - тот, кто должен изменить код. Не настраивать воркфлоу жестко, разрешать любые переходы, но с аргументированием.

Александр Барановский Собеседование тестировщиков: что спросить и как ответить К собеседованию нужно готовиться, и, стало быть, понимать, что и зачем ты спрашиваешь. Спасибо, кэп.
Мои мысли: да, как же это классно, когда на собеседование приходят опытные тестировщики, им можно задавать умные и сложные вопросы. Только у нас не получается весело поболтать, потому как все опытные тестировщики города работают либо у нас либо у 1-2 конкурирующих компаний, которые ими упорно не хотят делиться.

Виктор Малый TPI Next®: оптимизируем процессы тестирования по-взрослому Очередная модель чвототам. Докладчик бойко рассказывал, отвечал и не отвечал на вопросы. Но уже есть TMMi. И их уже слишком много.

Роман Юферев О чем мы забываем в QA или “Знакомьтесь – Manageability!” Жог напалмом. Радовал и приводил примеры.
Заметки: Думайте заранее, блядь! Заранее, блядь, думайте. Проблемы не только и не столько от баг, сколько от сбоев. И их надо тестировать. Ибо кто, если не мы? Мне, как бывшему бойцу техподдержки сие близко, да.


Юлия Нечаева Команда, где каждый лидер
- Лидерство!
- Дааааааааа!
- Ответственность!
- Ото ж!
- Команда!
- Еще бы!
- Высокое качество!
- Конечно!
- Мы команда профессионалов!
- Дааааа! Ураааа!

Глеб Рыбалко Оценки имеют значение. Практические советы по оценке задач тестирования на каждый день Оценки в скрам и Agile своими словами, не?

Татьяна Зинченко Вредные советы для тестирования юзабилити Весело. Зажигательно. Интересно. Читайте Якоба Нильсена и Рольфа Молича. Лозунг: Интернет не для юзеров!
Только при чем тут тестирование? Доклад о проектировании интерфейсов.

Илья Фомин Вирусное тестирование. Что-то новое в конфигурационном тестировании Прикольно, забавно, но не мой домен, у нас серверная ява, вся конфигурация - тюнинг jvm.
Заметки: На этот доклад пошел методом исключения, а также потомушто Илья быстро говорит и мало капитанит. Исключил Наташу Руколь - ну не нравятся мне ее доклады, что поделаешь. Исключил "Качество софта ДО и ПОСЛЕ защиты" - у нас FOSS, нас невалнуэт.

Владимир Лысенко Увеличиваем мощь фреймворка: KDT & генератор тестов в TestComplete Междумордие DSL или как автоматизаторам сбагрить написание сценариев. Практическое руководство. Но - прозреваю значительное увеличение трудозатрат на техподдержку.

Николай Алименков DSL, Page Object и WebDriver – путь к надежным функциональным тестам Однозначный зачет. Были исходники.
Заметки: комментирование кода - для слабаков. Или для небольших проектов. Или для автоматизатора, который пишет тесты один.
Я то думал - мы с wurstenator и entarrion лабаем тесты, а Николай объяснил, что мы пишем на DSL согласно ODT и частично BDT.
Интересно было посмотреть, как другие специалисты решают проблему удаления тестовых данных. Решают они ее просто - они их, блин, не удаляют.
Первый час рассказывал, что рефакторинг, это, блядь, хорошо! А вот потом пошел цымес, да.
Подтвердил некоторые мои догадки, добавил пару идей. Думаю, что самый полезный для меня доклад.
В финале выступил А. Баранцев, сорвал покровы с webdrivera, показал пальцем на аудиторию и сказал: "А ты - выложил свой фреймворк на гитхаб?". Каюсь, мы не выложили.

Круглый стол "Сообщества тестировщиков. Старт дан. И что дальше?" Основной вопрос - откуда в Костроме столько тестировщиков? 0_о А в остальном - славно поговорили.
В кулуарах спросил Астеникса, что б такое натворить, чтоб взлабать у себя в городе сообщество. Он выразил мысль, что вряд-ли получится заставить сообщество быть. Жизнеспособней вариант, когда оформляется в сообщество уже существующая группа. Я буду эту мысль думать, чо.
Я знаком с одной жизнеспособной группой по it-интересам в ебурге, он она состоит из тестировщика, сисадмина и серверной техподдержки. Не получится даже сообщество любителей пива, 2 из трех почти не пьют. Как официально самоназваться-то?

Александр Александров Оценка трудозатрат на тестирование в проектах сопровождения Статистику нужно не только собирать, но и обрабатывать. И делать правильные выводы, да.

Павел Павлов Автоматизированное тестирование клиентской производительности Крайне полезный и актуальный для меня доклад... был бы, если бы, да кабы. В части теории и так все ясно, нужна была конкретика, тонкости, нюансы и исходники. Их не было, была ссылка на платный продукт, oh shi...

Евгения Фирсова Очередь на тестирование Зачетно проклассифицировала очереди. Причины. Последствия. Серебрянных пуль не давала. Статистику не вела. Мы статистику ведем, видим тенденции и тренды. Но с пулями тоже беда, декреты и насморки не запланируешь.

Андрей Терехин Автоматизация тестирования модели разграничения прав доступа к функционалу Хороший доклад для меня ибо домен близкий.
- Как тестировать права?
- Леххко! Берем эксель и разворачиваем 10 трехмерных матриц в плоскость.
- Что делать с получившимися 8 000 - 16 000 сценариями?
- Леххко! Кладем болт на атомарность, тестируем по 3-10 условий зараз.
- Что делать с получившейся 1000 длиннотестов?
- Леххко. Фигачить их.
- Что делать, когда на поддержку всей этой ереси будет уходить 40 часов за 5 рабочих дней?
- Хз, но уже страшно.


Алексей Лупан Качество отсутствует, коль баги присутствуют Этот доклад Алексей сперва рассказал участникам конференции по отдельности, а уже потом всем вместе. Хороший, индивидуальный подход, мне нравится.
Заметки: Качество не бывает второй свежести, оно или есть или его нет. Тестировщики работают по правилу мертвеца - они могут сделать не плохо. Хорошо они сделать не могут. Но - кто если не мы? Надо влиять: угрозами, подкупом и грубой лестью.

Теперь - фотки.

наташки и Оля:

Альбом: office

Я:

Альбом: office

Резюме:

Хорошо съездил. Больше не поеду.

Holy shit

Заявление
"У нас большая и сильная команда/отдел тестирования"

для коммерческих продуктов можно перевести как

"мы настолько тупы, что исправляем ошибки, а не предотвращаем".

Дискасс.

Хех

Тридцать из тридцати.

http://nazva.net/logic_test1/

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

Кстати, какие свойства логических операций вы помните навскидку? Я транзитивность, ассоциативность, симметричность. Или симметричность это свойство отношения, а не операции?

Так

Как то так:

http://kirguduev.livejournal.com/502184.html

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

Политики пост

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

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

Горки

Сегодня Одепт и Джонни вытащили меня покататься на борде. И не зря, хорошие ребята.

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

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

В целом хорошо, одобряю.

Пикрелейтед.



Не забываем, что наличие на фото ковра автоматически делает штаны и борд инсталляцией, а фото - предметом искусства.

Скоро

Скоро будет отчета о sqadays пост.
А пока - не успел я вернуться, как приехало начальство и интересуется, зачем наш проект. Я один из тех, кто будет объяснять - зачем. И еще много всякого.

По эскуа. Доклад Катукату Каменевой стоил того, чтоб его слышали. Но она маленькая хрупкая девочка. Алексей Лупан, судя по ттх, голосом должен уметь останавливать параходы. Но говорил не громче маленькой хрупкой девочки. Жаль.

От каждого из них я ждал настоящего боевого рыка тестировщика. Доклады того стоили. Подробности позже.