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

Начнем с пары историй.

История А.

На днях разговаривал с одним программистом. Пишет он на С++, работает в крупной компании в Чикаго; софтом, к созданию которого он причастен, активно пользуются финансовые и трейдерские компании. У нас, говорит, в продукте 600 тысяч строк кода. Начиналось все с небольшого приложения для анализа биржевой статистики, и вот за 20 лет вымахал такой монстр. Здорово, говорю. Внушает уважение. И как вы его тестируете, вашего монстра? Для этого, отвечает мне программист, есть специальный индус. Он какие-то тест кейсы выполняет, отчеты пишет. А до него этим менеджер один занимался, но тот все больше ручное тестирование делал. Новые функции проверял, например. Теперь вот индус. Хорошо, продолжаю выпытывать я, это функциональное тестирование. А производительность вы как-то тестируете? Нет, говорит, если клиенты начинают жаловаться на медленную работу, мы тогда сами ищем узкие места и сами же из исправляем. Кто разрабатывает продукт, тот его и знает лучше. Какой тестер с этим справится?

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

Как обычно строят процесс тестирования непросветлённые тест-менеджеры?

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

Релиз.

Не работает основной функционал.

Почему такое возможно?

1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.

2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.

3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.

4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…

Что просветлённые тест-менеджеры делают по-другому?

Что они поменяют в первую очередь?

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

Кому и зачем это нужно?

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

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

Последние дни всё чаще натыкаюсь на сообщения в блогах и форумах про то, что тестирование — это либо очень скучно, либо тупая работа и т.д.
Что все эти люди делают в тестировании??

Позавчера я тестировала свой небольшой веб-проект.

За 4 часа я завела 25 дефектов.

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

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

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

Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!

И я задумалась. Кто пишет про «скучно», «рутина» и «тупая работа»? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.

Знакомый, в глаза не видевший Linux, но заинтересовавшийся опенсурсом, после выхода Ubuntu 10.10 попросил написать ему, "чем хорошо, чем плохо, какие осложнения, какие тонкости, как наладить отношения с вин7", чтобы он мог решить, нужно ли ему это счастье.

Сначала подумал "зачем буду писать текст, когда наверняка его уже сто человек написали — быстро нагуглю, пошлю ссылку, а потом уже на конкретные вопросы отвечать буду". Но затем обнаружил, что по запросам вроде "миграция на ubuntu" вываливаются гигантские мануалы с тонкостями настройки compiz, а недлинный текст для "неопределившихся" быстро найти не получается ни в интернете вообще, ни на ubuntu.com и ubuntu.ru (то есть все как и писал в предыдущем посте), ни на Хабре — вот и подумал, что пусть теперь хотя бы на Хабре будет.

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

Начало здесь.

Накопители

Прежде чем описывать инструменты, необходимо показать карту информации.

1. Вне человека — хаотичная.
2. В накопителе — хаотичная, но собранная в одном месте.
3. В человеке, его записях, файлах — отсортированная.

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

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

Многие знают, что за такими запросами стоит не действительно срочная потребность, а сумбурность мысли. Человек не всегда может осознать, к какому же сроку ему нужны те или иные данные? Зачастую, они кричат «срочно!» только потому что им хочется , а не потому что они действительно нуждаются.

Чтобы справиться с хаосом, Дэвидом Алленом был придуман простой инструмент — накопитель.

Владимир Долгов, Генеральный директор Google Россия

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

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

Пару лет назад возникла идея сделать локальный bittorrent-ретрекер для пользователей нашей «домашней» городской сети, чтобы и пользователи быстрее скачивали и у нас меньше трафика было. Установкой самого ретрекера дело только начиналось, необходимо было как-то анонсировать его для скачиваемых торрентов. В процессе выяснения способов и механизмов анонса я пришёл к достаточно общему и универсальному алгоритму, с которым и предлагаю познакомиться.

Итак, первое:

Вступление

C системой Аллена меня познакомили около двух лет назад. Начинал пользоваться вариантом Васи Кислого с помощью HTC Touch Pro, но глючность девайса сильно мешала освоить систему, а сам «Успеватель» не давал необходимого уровня понимания. С GTD пришлось на время расстаться.

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

Попытки вести мобильную версию системы в Nokia E63 с помощью «Активных заметок» привели к покупке книги Дэвида Аллена, переработке статьи В. Кислого, приобретению стабильно работающего, хоть и старенького HTC P3400 (а потом и более современного продукта от HTC) и введению бумажной, физически ощутимой части этой системы.

Итогом переработки стала строгая вариация за моим авторством на тему Дэвида Аллена в обработке Васи Кислого. Благодаря ей, работа стала занимать не больше 3-х часов в день. Но за это время я успеваю сделать действительно много.

Следуя этим принципам, я прихожу на работу к 11-12 часам, работаю плотно и не отвлекаясь до 15 часов. В 15 часов ухожу в зал потаскать железки, прихожу в офис к 17-30, прорабатываю за полчаса все накопившееся с 15 часов. И еду домой.

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

Кому интересно, прошу под кат.

Понедельник начинается в субботу.
А. Стругацкий, Б. Стругацкий.

Прошедшее забыто, грядущее сокрыто, настоящее даровано. Поэтому его и зовут настоящим!
Мудрая Черепаха из «Кунг-фу Панда»

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

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

Под катом простая схема, как этого достичь.

Несмотря на шумиху вокруг HTML 5, спецификации ещё не готовы для использования из-за проблем совместимости. Такова официальная позиция консорциума W3C, которую неделю назад высказал в интервью InfoWorld Филипп Ле Эгаре (Philippe Le Hégaret), руководитель направления W3C Interaction Domain. Эта группа занимается разработкой технологий для пользовательских интерфейсов: (X)HTML, CSS, MathML, SMIL, SVG, XForms.

«Прямо сейчас HTML 5 находится на разных стадиях реализации в различных веб-браузерах. Если посмотреть на них, то можно увидеть, что наиболее агрессивные реализации в бета-версиях, — сказал Ле Эгаре. — IE9, например, не планируется к финальному релизу до середины следующего года. Это момент, когда большинство предприятий начнут переходить на новое поколение браузеров».

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

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

Помощь в создании и продвижении материала ученым оказывала компания Samsung.

Приветствую, Хабрахабр.

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

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

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

Итак, бизнес. Преимущественно мы говорим о т.н. стартапе, когда бизнес основывается с нуля. Вы приняли это решение, и неважно, как вы к нему пришли — возможно, у вас появилась идея, возможно, вам просто не хочется просто работать на кого-то. Есть распространенное мнение о том, что для бизнеса нужен существенный начальный капитал. Начальный капитал необходим, но не обязателен, и существует ряд успешных примеров бизнеса, основанного практически на карманные расходы. Как говорит один из моих профессоров, бывший член совета директоров Exxon Enterprises и Genesis Group – «основывая стартап, не заботьтесь о капитальных вложениях, просто докажите, что ваш бизнес способен приносить доход и что вы способны им управлять, и тогда у вас не будет недостатка в капитале».

С чего начать?

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

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

Часть первая из серии

На написание топика сподвигла эта статья. Поэтому решил поместить топик в тот же блог.

Думаю, что настал очень удачный момент для того, чтобы отъесть долю рынка операционок у Microsoft
…
И при этом думаю, что компания Canonical сейчас этот момент упустит по собственной глупости.

Холиваря на тему “Windows vs Linux”, рассуждая, почему процент Linux десктопов так мал в сравнении с Windows, почему-то многие упускают из виду, что у Microsoft есть договоренности со всеми мыслимыми производителями десктопов, ноутбуков, нетбуков и т.д. о предустановке Windows на выпускаемую продукцию. В частности, ни в самом топике, ни в обсуждении данная тема пока не всплывала.
Тем не менее, imho, технические детали каждой из систем отходят на второй план, когда понимаешь, какой объем работ по “окучиванию” производителей компьютерной электроники проделала Microsoft.

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

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

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

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

Или с деньгами.

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

До недавнего времени предано нес знамя Microsoft .NET. Восхвалял Silverlight, ASP.NET MVC и верил в чудеса. За четыре года работы c .NET стал сертифицированным разработчиком по широкому спектру
технологий: ASP.NET, WCF, WPF, ADO.NET. Однако за год существования собственного интернет агентства разочаровался в выбранном пути и обратился в другую веру.

В серии статей “Big switch или жизнь после Microsoft” я расскажу об опыте полученном нашей командой при переходе со стэка веб-технологий Windows + .NET на Linux + Ruby on Rails, а также приведу конкретные инструкции к применению, которые помогут на первых порах.

Начну я с 3-х причин, которые побудили нас сказать .NET'у нет.

Введение

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

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

Думаю, что ещё более ранние модели отличались совсем просто — они говорили: «Солдат Крис Катарн, убил 10 враг, потратил 342 патрон, получил 0 ранение» и т. п., чем сразу палились.

Ведь до сих пор, несмотря на развитие веба, на многих сайтах можно встретить «50 пользователи», «1 комментарии», «0 сообщения» и т. п. А ведь насколько приятней, когда сайт говорит с тобой на человеческом языке и правильно спрягает слова по числам.

И ведь сделать это совсем несложно.