[Oracle SPb] Семинар по производительности Java.

Компания Oracle приглашает желающих на семинар по производительности Java.

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

На семинаре перечитываются доклады с прошедшего JavaOne Moscow:

“Java Platform Performance BoF”, Алексей Шипилёв, Сергей Куксенкоhttp://www.blogger.com/img/blank.gif
“(The Art of) (Java) Benchmarking”, Алексей Шипилёв
“Java Memory Model”, Сергей Куксенко

В оставшееся время проводятся дискуссии по темам докладов или сопутствующим проблемам.

Семинар рассчитан на 3-4 часа, включая вопросы-ответы

Регистрация: http://oracle.timepad.ru/event/7698


Семинар «Нагрузочное тестирование с точки зрения тестирования»

Когда: 26 мая, четверг, 18:30 – 20:30.

Где:  БЦ Воронцов, ул.Барочная 10/1 (Самый правый вход под вывеской «Катарсис»)

Краткое описание доклада

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

В докладе будут рассмотрены следующие темы:

1) volume тестирование: размер имеет значение
2) подходы к нагрузочному тестированию: эксплуатационный, пользовательский, компонентный
3) регрессионное нагрузочное тестирование

О докладчике

Марина Широчкина, ведущий инженер в компании Яндекс.

Подробнее здесь.


Отзыв о конференции АDD-2011.

29-30 апреля 2011г. в Санкт-Петербурге прошла очередная конференция Application Developer Days.

Лучшими «выступаторами», по мнению независимого сообщества тестировщиков Санкт-Петербурга, в первый день стал Роман Юферев, а во второй день – Саша Орлов и Слава Панкратов.

Полную версию отзыва можно найти здесь.

Рома, так держать! 🙂


От лампочки в २००३ году к Стар Трэку в २०११

Ниже приведен перевод цитаты из очень известного блога “Fabulous Adventures In Coding” на blogs.msdn.com. Этот пост Эрика Липперта стал статьей в книге Джоэла Х. Спольски “Лучшие примеры разработки ПО”.

В те времена, когда я действительно регулярно занимался добавлением новых возможностей в VBScript, мне часто присылали сообщения с просьбами реализовать те или иные функции. Чаще всего запросы были “одноразовыми” — для функций, решающих конкретную задачу. Скажем, “Мне нужно вызвать ChangeLightBulbWindowHandleEx, но для этого нет специального элемента ActiveX, а напрямую вызывать функции Win32 API из сценариев нельзя; нельзя ли включить метод ChangeLightBulbWindowHandleEx в список встроенных функций VBScript? Ведь это всего пять строчек кода!”

Я всегда отвечаю таким людям одно и то же: если это всего пять строк кода, напишите свой объект ActiveX. Потому что вы абсолютно правы, для включения этой возможности в библиотеку времени выполнения VBScript мне потребуется примерно пять минут. Но сколько работников Microsoft в действительности понадобится для того, чтобы сменить лампочку?

* Один разработчик, чтобы за пять минут реализовать ChangeLightBulbWindowHandleEx.

* Один руководитель проекта (РП), чтобы написать спецификацию.

* Один специалист по локализации, чтобы просмотреть спецификацию на предмет потенциальных проблем с локализацией.

* Один специалист по пригодности (usability), чтобы проанализировать спецификацию на предмет доступности для лиц с ограниченными возможностями и практической пригодности.

* По крайней мере один разработчик, один тестер и один РП, чтобы провести “мозговой штурм” для выявления потенциальных проблем безопасности.

* Один РП, чтобы включить модель безопасности в спецификацию.

* Один тестер, чтобы написать план тестирования.

* Один руководитель группы тестирования, чтобы обновить график тестирования.

* Один тестер, чтобы написать контрольные примеры и включить их в ночную автоматическую проверку.

* Три или четыре тестера, чтобы участвовать в выявлении ошибок именно данного случая.

* Один технический автор, чтобы написать документацию.

* Один технический рецензент, чтобы проверить документацию.

* Один редактор, чтобы проверить документацию.

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

* Двадцать пять переводчиков, чтобы перевести документацию и сообщения об ошибках на все языки, поддерживаемые Windows. Руководители переводчиков живут в Ирландии (европейские языки) и Японии (азиатские языки); оба места существенно сдвинуты по времени относительно Редмонда (главный офис Microsoft), поэтому общение с ними иногда создает непростые организационные проблемы.

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

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

Оригинал на английском:

http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx

Перевод на русский: http://o-noble.net/2009_05_04/skolko-rabotnikov-microsoft-nuzhno-dlya-togo-chtoby-smenit-lampochku/

Как автор “Fabulous Adventures In Coding” Эрик Липперт пришел к Стар Трэку в 2011 году?

http://blogs.msdn.com/b/ericlippert/archive/2011/04/25/maybe-there-s-something-wrong-with-the-universe-but-probably-not.aspx