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

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

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

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

Помнится, кстати, что в комментариях к статьям о проектировании мне задавали такие вопросы вроде «А что делать, когда нет времени и денег на проектирование?». Ответ ниже.

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

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

Стоит ли вообще браться за JMeter

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

Составление сценария

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

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



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

На написание поста меня сподвигла найденная на просторах хабра ссылочка на сайт с альтернативами Basecamp. Уверен многие уже заходили и смотрели предлагаемые альтернативы. Я же решил просмотреть их все. По результатам просмотра было выбрано 4 (+ 1 бонусная) системы управления проектами, которые можно назвать реальными альтернативами Basecamp. Из них три являются чуть менее, чем полностью неизвестными на просторах хабра (поиск дает практически нулевой результат), что дает мне надежду на то, что данный топик сообщит вам что-то новое. Критерии выбора и краткий обзор систем под катом (осторожно скриншотный трафик ~0.5 Mb).

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

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

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

Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.

Под катом много текста о том, что следует помнить при тестировании.

Что такое междоменное отслеживание и зачем оно нужно?

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

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

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

В Google Analytics существует раздел «Обратный путь к цели», с помощью которого мы можем проследить путь посетителя до совершения им заказа.

Вот как можно это использовать на практике.

Нужно использовать много изображений на сайте? Не хочется забивать хостинг изображениями? Хочется уменьшить нагрузку на сервер?
Тогда можно использовать сервис от гугл picasaweb і Picasa API как хостинг для изображений

процесс загрузки фотографий на сервер

Доброго времени суток.

В этой статье я хочу продолжить рассказ о «прагматическом» Agile процессе разработки ПО. На суд Читателя предлагается иная перспектива обзора этого процесса — с точки зрения создания и эволюции артефактов (Artifact Flow) в ходе развития проекта. А также мы рассмотрим практический подход для работы с артефактом «Коллекция Требований» с использованием Google Wave и Google Docs.

Может кому будет интересно как «по-быстрому» провести нагрузочное тестирование своего веб-приложения.
Подробности под катом

Меня часто спрашивают, почему именно Django стоит использовать для написания сайтов? Почему не ASP.NET, Ruby on Rails, Grails и т.п.? Ниже я кратко опишу свое мнение, и причины, его сформировавшие. Но хочу сразу сказать, что это не сравнительный анализ фреймворков, и я не ставил перед собой цель что-то кому-то доказывать. Это просто перечисление преимуществ и мои мысли о них.

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

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

Ничто не предвещало (преамбула)

Приходит посредник (или представитель заказчика), приносит концепцию (почти всегда гордо именуемую ТЗ) и просит оценить фронт работ в человеко-часах или баксо-рублях. После просмотра предоставленного документа я прикидываю, что работа займет около x (икс) недель и будет стоить примерно y (игрек) денег. Оценочная прикидка, ничего более. При оценке учитывается, что ТЗ (концепция) штука достаточно расплывчатая, чтобы при его уточнении можно было бы упихать функциональности раз в 5 больше, чем нарисовано изначально и сам проект выше среднего по сложности, причем не социальщина какая-нибудь, а программно-аппаратный комплекс взаимодействующий ещё и со сторонними приложениями. Оценки высылаются запросившему. В ответ приходит письмо с просьбой расписать чуть подробнее. Опускаюсь на уровень ниже выделяю какие-то наиболее существенные подпроекты, высылаю. Получаю замечательный ответ: «Вы просите так много, что я даже не буду показывать это заказчику.» Где-то рядом крутится смайл с ВОТ ТАКИМИ глазами.

Очередная порция расширений для браузера Google Chrome.

— Google Tasks
— Gmail Checker
— Google Reader Checker
— Vkontakte Toolbar
— Cleeki

UPD. Спасибо за карму. Перенес в соответствующий блог
UPD2. Сайт с расширениями постиг хабраэффект
UPD3.Все кроме Reader Checker залил сюда slil.ru/28124675. Распаковывать в C:\Users\*Имя пользователя*\AppData\Local\Google\Chrome\User Data\Default\Extensions\ не канает %(

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

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

http://www.site.com/page.php?var=<script>alert('xss');</script>

Как-то не очень страшно :) Чем же действительно может быть опасной данная уязвимость?

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

С 1 июля 2009 года общества с ограниченной ответственностью будут действовать на основании единственного учредительного документа – устава. Учредительные договоры обществ с 1 июля 2009 года утрачивают силу учредительных документов. Все ООО с момента регистрации обязаны вести список своих участников. В него войдет информация об учредителях, включая данные об их адресах, сведения о принадлежащих им долях и их оплате, данные о долях, перешедших к обществу.
Обществам с ограниченной ответственностью необходимо внести изменения в свой устав. Сделать это нужно не позднее 1 января 2010 года. Изменения в устав вступают в силу с момента регистрации. То есть в срок, установленный в законодательстве, нужно успеть не только внести изменения в устав, но и зарегистрировать их. Поскольку 1 января 2010 года – нерабочий день, окончание срока переносится на первый рабочий день года.

Изменения в законодательстве прежде всего коснулись содержащихся в уставе сведений:

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

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

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