Прочитав замечательную статью Оптимизация Windows для использования SSD диска: мифы и реальность, подумал, что пришла пора поделиться накопленной статистикой тестов.
В середине октября собирал для себя новый системник. Давно собирался лично пощупать, что такое SSD. В итоге приобрел Intel SSDSC2CW120A3, на котором и проводил эксперимент.
Пара картинок и немного текста далее.
Читать полностью »
Постановка задачи: выбор наиболее дешёвого сервера для ролей сервера 1С, сервера СУБД MS SQL 2008 для 50 пользователей.
Подбор железа, используя сервер-эксперт:
В этом посте я опишу, как создать нагрузочный тест веб-приложения с помощью инструмента для проведения нагрузочного тестирования, разрабатываемого в рамках Apache Jakarta Project — JMeter.
JMeter является очень мощным инструментом нагрузочного тестирования с возможностью создания большого количества запросов одновременно благодаря параллельной работе на нескольких компьютерах. Поддерживает плагины, при помощи которых можно расширить функционал. Инструмент использовался мной ранее при тестировании крупного интернет-банкинга. Скачать JMeter можно по ссылке http://jmeter.apache.org/download_jmeter.cgi, для запуска нужно зайти в binjmeter.bat.
Запустив программу, слева видим 2 пункта — Test Plan и WorkBench. Добавим Читать полностью »
В посте речь пойдет о тестировании 6 операционных систем в качестве веб-сервера. Оси следующие: Debian, FreeBSD, CentOS, OpenSUSE, Ubuntu, и для потехи Windows 2008 R2 Standard. Почему именно такие, объясню ниже. ПО – стандартный набор: Apache2, MySQL5, PHP5 (далее AMP).
Это шестой вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 16 мин.):
Темы и детали видеозаписи под катом
Не рекламы ради, я не имею никакого отношения к данной игре.
Если вас заинтересовала кооперативная игра Warframe, но вам не удалось получить, заветный, ключик на ЗБТ — эта тема для Вас.
MMOBomb.com вместе с Digital Extremes устроили раздачу ключей на закрытый бета-тест Warframe.
Как получить ключ:
Читать полностью »
В практике юнит-тестирования часто возникает желание сделать несколько Assertion'ов в одном тест-методе. В теории же, такой подход критикуется с двух основных позиций. Во-первых, семантически, один тест должен проверять только один кейс, не разрастаться. Во-вторых, при падении одного из Assertion’ов в цепочке, выполнение теста прервется и мы увидим сообщение об ошибке лишь от него, а до всех остальных дело не дойдет, что не даст наиболее полной картины произошедшего. Первый аргумент безусловно резонен и при написании тестов его всегда следует держать в голове, но фанатичное следование этому принципу зачастую не представляется разумным (пример далее). Устранению же второй проблемы посвящен этот пост. Будет представлен небольшой класс, позволяющий просто и лаконично обеспечить исполнение нескольких Assertion’ов без прерывания выполнения метода и с выводом сообщения об ошибке каждого из них.
Читать полностью »
Привет!
Год назад разработали под свои задачи сервис который позволял нам хранить файлы (со всеми примочками файловых хранилищ) и прямо из хранилища создавать для файлов виджеты, делать удобные линки на файлы, которые мы добавляли на корпоративные сайты, статистику для отслеживания жизни виджетов и еще незначительный функционал, который нам был нужен.
Весной, в Калифорнии, пообщавшись с множеством предпринимателей решили (видимо воздух у них там такой) сделать публичный сервис, который бы давал возможность человеку управлять своими файлами непосредственно из своего хранилища. Проблему вы знаете — контента много, что с ним делать не всегда ясно. В Долине в одной компании нам сказали, что они уже не контролируют на каких сайтах и что они публиковали.Читать полностью »
Маленькое предварительное замечание: Подробное объяснение потребовало бы объёмов средней книжки. Тут всё дано схематично, кратко и без подробностей. Текст, конечно, хулиганский, но прежде чем наезжать на автора, стоит учесть, что за ним стоит двадцать лет опыта и много-много литературы как классической, так и специалистам ИТ не ведомой.
Есть слово, приносящее индустрии каждый год огромные убытки. И слово это — bug.
Баги — это некие виртуальные вредоносные жучки, прячущиеся внутри программ. Они обладают собственной волей. Они проникают в самые важные участки. Они портят результаты, прерывают выполнение работы и делают другие гадости.
Конечно, это бред, если смотреть правде в глаза. Но, если вывести ментальную модель из того, что делают и говорят программисты, как раз получаются виртуальные живые существа, которых ищут, ловят, выявляют и уничтожают.
Массовая глобальная нескончаемая игра, которой увлечённо предаются практически все работники отрасли, включая тестеров, менеджмент, организаторов процессов и высоколобых теоретиков.
Почему так происходит? Потому что в индустрии совершенно превратно понимают, что такое исходный код и для чего он нужен.
Если опросить специалистов, мы получим сотню разных мнений. Но в сухом остатке, если отбросить всю шелуху, код выступает плодом творческих усилий и выражением гениальности автора. В стандартной ситуации и при любом фактическом уровне профессионализма программист воспринимает себя почти святым гением, создающим почти идеальный продукт.
Если сделать программиста не идеальным, получается одна интересная штука: код перестаёт быть готовым результатом. Он даже перестаёт быть результатом. И становится отражением текущего понимания программистом условий поставленной задачи и способов её решения.
Код именно отражает, а не описывает. Последнее возможно, но требует перестройки всего процесса, от форматов записи до мозгов.
Мозги критичны. Нужны люди особой культуры, не боящиеся выглядеть дураками, каких в ИТ практически не встречается.
Писать и говорить то, что думаешь, — это всегда отсутствие такта, презрение к окружающим и хамство. Если кто-то ставит в своём коде комментарий «Stupid idea. Does not work, if N < 0. Correct ASAP.», он рискует прослыть минимум странным. А вот если это попадёт в участок ответственности гениального программиста, тут уже мелкой истерикой не ограничится. Даже, если «stupid» будет подразумеваться только по контексту. Или напишите в комментарии что-нибудь типа «I do not know why this works, but otherwise the function generates an exception.» Потом покажите это начальнику и попросите повышения.
И, конечно, гораздо выгоднее говорить «Мы исправляем баги в коммуникационном модуле», а не «Читая документацию мы прошляпили несколько критических моментов и неделю будем всё с нуля переделывать.»
Ладно, оставим. Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже… Короче, фиг с ним, перейдём к плюшкам.
Очень не хватало возможности ввести пользователей в контекст перед голосованием. Спасибо! И так
Работая со старым унаследованным кодом, порой встречаются достаточно проблемные участки, которые есть желание переписатьисправитьпеределать, но нет такой возможности. Этот код может быть с ошибками, которые не исправляются годами и с ними приходится мириться. Что делать с таким кодом?
Читать полностью »
