Изучаем SQL. Линн Бейли

Ссылка на OZON.

Потрясающая книга!!! Вся серия «Бестселлеры O'Reilly» — просто супер! Читается на одном дыхании, новая информация усваивается играючись. Все, как я люблю  

Если вы ничего не знаете про SQL, но хотите узнать → обязательно прочитайте! Все просто, понятно, доступно.

Например, условие «and» внутри селекта объясняется историей: есть девочка, пусть будет Полли. Она очень хочет пончиков с глазурью. И вот она ищет по базе данных ресторанов: select name from table where type = 'с глазурью'.

Но не хочется есть жесткое или невкусное. Делаем второй select с выборкой ресторанов, у которых рейтинг более 8. И там и там результатов много, надо их вручную сопоставлять, вот пичалька то... Рисунок — сидит грустный ребенок над результатами выборок.

Но!!! Можно совместить эти два условия, написать внутри селекта "where type = xxx AND rating = yyy". И вот уже мы видим лучшие рестораны. Рисунок — девочка стоит таким ангелочком, ручки за спину, «Мааааам, а пошли в ресторан А?» 

Я знаю SQL, работаю с ним каждый день. Мне хотелось пополнить теоретическую базу, почитать подробнее о нормальных формах, например. О разных видах соединений и индексации. Я получила все, что хотела :)

В книге 600 страниц формата А4, поэтому это не быстрое чтение. Но очень увлекательное! И длительное → надо каждый пример пробовать вводить у себя на компьютере. Создавать таблички, играться с селектами. Только так информация уляжется в мозгу. Без практики — никак. Фишка серии «Бестселлеры O'Reilly» в том, что они дают практику. Ты можешь вводить конкретные примеры, чтобы набить руку. А в конце каждой главы есть упражнения для самостоятельной работы.

Когда я читала «Изучаем Java», я честно делала каждое задание, вбивала код в блокнотик. В SQL немного халтурила → писала все запросы мысленно, а потом шла читать ответ. Потому что половину книжки я уже знаю. И то после прочтения осталось такое чувство, что забыл что-то важное. Все-таки надо работать честно и честно выполнять все домашки! 

Когда закончила читать про SQL, осталось дикое желание тут же начать читать другую книжку из той же серии. Настолько они вдохновляют и воодушевляют! Если хотите изучить что-то с нуля, поищите эту тему в «Бестселлерах O'Reilly» → это идеальный старт для основ теории и начала практики!

PS - Добавила книгу в общий список прочитанных мною книг.

Принцип пирамиды Минто. Барбара Минто

Ссылка на OZON.

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

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

Структура книги:
— Почему именно пирамида? Обоснование
— Составляющие пирамиды. Компоненты
— Построение пирамиды, особенности формулирования разных частей.

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

В целом книжка правильная, но, если вы хотите научиться писать текст, который читают, курс Максима Ильяхова даст больше. Некоторые примеры мне было тяжело читать даже после «преобразования». В голове осталось мало полезных идей после прочтения, для меня КПД книжки низкий.

PS - Добавила книгу в общий список прочитанных мною книг.

Идеи багов. POST и GET запросы

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

1. Есть у нас страница для поиска по параметрам-фильтрам, которых примерно 40-50 разных. При определенном сочетании фильтров (название некоторых довольно длинные) генерируемый POST-запрос превышал размер того, что мог принять сервер (2кб было в нашем случае). Забыл, к сожалению, какую ошибку возвращал сервер.

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

3. На одной из страниц, с еще одним поиском, есть две кнопки «Apply» (фильтры) и «Export CSV». Если на этой странице нажать сначала «Export CSV», а затем  «Apply», апплай начинала работать как экспорт. Оказалось, что после нажатия «Export CSV джаваскрипт переписывал функцию кнопки «Apply».

По-моему, это отличная идея — делиться интересными идеями багов 
А потом тестируешь себе, тестируешь продукт и все уж, глаз замылен. Что можно сделать? Можно почитать туры Виттакера или «заметки с полей», идеи для багов от коллег → это тоже может на толкнуть на мысль «О, круто! Надо и у себя на проекте такое проверить».

Сделала новый лейбл «идеи багов», буду собирать :)

Ретроспектива проекта. Норм Керт

Ссылка на книгу (издательство «Альпина Паблишер»).

Мои выдержки из книги:
Если ретроспектива приводит к одним и тем же рекомендациям — выделите больше времени!

Отличная книга о том, как проводить ретроспективу! Единственный минус — описывается ретроспектива, проходящая раз в полгода-год по завершении проекта, а не маленькой итерации. А хочется улучшать ежемесячные ретроспективы, проходящие в Agile-командах. И такая книжка как раз на подходе! Следующая книга от издательства Дмитрия Лазарева — «Agile Ретроспектива», как раз о маленьких и частых встречах. Станьте соиздателем и получите книгу одним из первых!

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

Можно, конечно, фигачить проекты один за другим. «Нам некогда размышлять, что можно сделать лучше, сроки поджимают!»

Стоит ли ожидать от такой команды хорошего качества? Врядли.

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

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

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

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

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

Основная установка Керта

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

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

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

Вот оно! Ретроспектива — это не сессия жалоб! Пожалуй, самая полезная цитата из книжки. Я бывала на «сессиях жалоб», поэтому меня это так затронуло. Вот оно, что самое главное, научиться извлекать пользу, уроки, опыт. Без жалоб и обвинений. Это звучит разумно, но иногда этому сложно следовать. Особенно когда ретроспектива внедряется впервые в компании. Очень важно все сделать правильно, чтобы у участников не осталось негативного впечатления!

Развитие интенсива-10

Выпустили очередной курс — недельную и 3-х недельную версии.
Как обычно, постарались его улучшить по отзывам + дать новые полезные материалы.

Изменения в СДО (системе дистанционного обучения):

• Добавила ссылку «Как вы будете сдавать домашки :)» — на блог моей лучшей выпускницы Ольги Алифановой. Я и сама не описала бы процесс точнее  Да и кто поверит тренеру?)) От студента все равно интереснее читать фидбек.
• Переделала секцию с доп материалами к теме про баги — их стало много! Добавила ссылку на статью «Как описывать баги», выделила разные типы секций: «MUST READ — прочитать и запомнить, иначе баги все верну», «Дополнительные материалы» и «Инструменты».
• Пополнила статью про описание тест-кейсов, расписала подробнее о своих возможных претензиях к предварительным шагам → студенты оценили, сказали, что так понятнее.
• Переделала доп материалы и к первой теме, разделила на разные секции — вот общие, вот про тест-кейсы, вот про чек-листы.
• Переформулировала ДЗ про собеседование, дав в нем явные подсказки + переписав получаемое кандидатом письмо в чуть более официальном стиле.
• Создала рассылку в новостном форуме в начале курса о том, как задавать вопросы — чтобы студенты не пугались ответов "см чат", ведь достаточно уточнить вопрос и тренер все прояснит =)

Полезные статьи, написанные для студентов:

• Сопроводительное письмо соискателя.
• Как получить прямую ссылку на всплывающее окно.
• Какой результат писать в чек-листе

Отзывы

Если ретроспектива приводит к одним и тем же рекомендациям — выделите больше времени!

Выдержка из книги Нормана Керта «Ретроспектива проекта»:

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

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

«Мы пробовали проводить ретроспективы. Через некоторое время мы заметили, что каждая ретроспектива приводила к одним и тем же рекомендациям. Было очевидно, что ничего не менялось, и мы решили, что ретроспектива — это потеря времени. Поэтому больше их не проводим»

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

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

**************

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

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

Меня зацепил этот отрывок словами «каждая ретроспектива приводила к одним и тем же рекомендациям». Бывало ли у вас такое? Что периодически одна и та же мысль всплывала на ретроспективе раз за разом. Например, делать большие задачи в отдельном бранче или начинать тестирование до линии N?

Разумеется, тупо выделить больше времени на ретроспективу тут не поможет. Однако стоит задуматься... Если одна и та же идея всплывает раз за разом → необходимо уделить ее анализу чуть больше времени. Да, тогда ретро займет не час, а полтора или два, но это окупится! Ведь ведь смысл ретроспектив — научиться. Научиться быть лучше, повторять успех и не повторять ошибок.

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

Также и с ретроспективами. Если какая-то мысль мелькает уже не первый и даже не пятый раз, чуть приостановитесь и задумайтесь, а не поверхностное ли ваше «решение» проблемы?

Тур, отмененный из-за дождя. The Rained-Out Tour

Входит в «Туры по отельным районам», Tours Through the Hotel District

Вольный перевод статьи Виттакера из книги “Exploratory Software testing”. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!

В мае в Таиланде начинается сезон дождей — время внезапной отмены экскурсий. Местные смело продают билеты и уверяют, что бояться нечего — «Дожди еще небольшие, тур не отменится». А за день до начала звонят — «Простите, из-за дождей экскурсия переносится на три дня». А потом еще на три, и еще. И вот уже отпуск закончен, пора домой. А вы так и не съездили на экскурсию, потому что шел дождь и она отменилась…

Такие планы были, а из-за дождя остались дома....

Для туриста отмена — плохо.

Для тестировщика — хорошо, даже идеально! Тестировщик просто обязан использовать отмену всегда и везде, где только возможно.

Идея тура в том, чтобы начать операцию и остановить ее.

Найти идею: Введение в ТРИЗ. Генрих Альтшуллер

Ссылка на книгу (издательство "Альпина Паблишер").

ТРИЗ — теория решения изобретательских задач. Я не сильна в конструировании и изобретательстве, но было интересно почитать основы.

Автор рассказывает о том, что метод перебора разных вариантов давно укоренился в наших головах. Многие люди считают, что нет прогресса для науки без многочисленных пробных версий "наугад". Но сильно сузить зону поиска, если использовать ТРИЗ.

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

Если исходно стояла задача «как достать застывший шлак из ковша», то решение по ТРИЗ приводит к тому, что мы создаем крышку из воздуха (ну почти...)! Которая мешает шлаку застыть и в то же время легко разрушается, когда его пора вылить.

Главная идея ТРИЗ:

Система идеальна, если ее нет, а функция осуществляется.

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

Результат может удивить и даже заставить усомниться в том, что ТРИЗ помогает. Как пример — Заказчик скептически настроен к ТРИЗ, попросил решить задачу. Нужен ледокол, сейчас все технические возможности исчерпаны, он двигается со скоростью ХХХ. Хочется быстрее.

К доске вышла студентка и стала решать задачу по АРИЗ (алгоритм решения изобретательских задач). Она дошла до противоречия «низ корабля есть, чтобы двигаться вперед — низа корабля нет, чтобы там проходил лед». И вот он, ИКР (идеальный конечный результат) — низа корабля просто нет, есть только ножи, соединяющие верхнюю часть с нижней.

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

Рекомендую книгу тем:

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

PS - Добавила книгу в общий список прочитанных мною книг.