Как в SQL получить то, чего в базе нет

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

Предыстория: регистрировал 1000 пользователей через http-запросы к системе. Получил отказы в 70% случаев. Регистрировал по маске u000
Задача: Выбрать список пользователей не зарегестрированых в системе. Если известен список зарегестрированых пользователей. А список пользователей, которых надо зарегестрировать соответствует определенной с буквенным префиксом и цифровым суффиксом, вырастающим инкрементально с шагом 1.

Получил решения от своих коллег разработчиков :)

Работа не должна мешать жизни, а жизнь работе

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

Где брать данные для проверки

Вещь поразительно очевидна. Самые лучшие тестовые данные - реальные данные.

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

Господа и дамы лидеры команд тестирования и не только, обновляйте тестовые ХД с серверов так часто как возможно (перед релизом это крайне полезно).

Почему мы не делаем работу на работе?

Пересматривал выступление Джейсона Фрида "Почему мы не делаем работу на работе" (Jason Fried Why Work Doesn't Happen at Work). Интересные результаты. 





Но вот при разработке программного продукта необходимо очень много командной работы. Когда действительно необходимо постоянное взаимодействие между людьми. И отвлекаться это нормально.
Хотя если надо написать тест дизайн или просто покрыть тестами функционал. Разобрать требования заказчика и проанализировать их. Проанализировать состояние проекта и написать отчет.... То тут явно хочется повесить видимую не только тебе табличку "Не беспокоить" на видимую не только тобой дверь (open space).

Overmeetinging

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

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

Следите за своими сроками

Подсмотрел у cartmendum'a тут. И не смог не перепостить :)

Многие дедлайны можно отложить или объем пересмотреть, но делать это надо заранее, и следить за этим постоянно. Иначе кто как умеет плавть :)