Крупные распределенные информационные системы зачастую состоят из более мелких модулей (подсистем) и разрабатываются группами программистов с использованием разных платформ и подходов. Часто, обмен данными в таких системах происходит в асинхронном режиме и предпочтительно использование промежуточного программного обеспечения, ориентированного на обработку сообщений (англ. Message-Oriented Middleware, MOM).

Для модульного и интеграционного тестирования таких систем удобно использовать старый добрый Apache JMeter.

Для примера выделим небольшой стандартный модуль такой системы. Допустим, есть некий адаптер, который читает XML сообщение из очереди входящих сообщений, выполняет преобразование структуры XML сообщения и публикует преобразованное сообщение в очередь исходящих сообщений. В качестве MOM, в данном случае, используется Websphere MQ 7.5.

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

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

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

Приветствую уважаемое сообщество!

Итак, это мой первый пост на хабре :)
Посвящен он будет серьезной теме, в которой, волею судеб, я неплохо разбираюсь. А именно, генной инженерии.

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

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

В статье описаны основные трудности создания приложений под Android.
Рассматриваются базовые понятия программирования Android.
Для примера описано создание игры Sudoku из книги Hello, Android – Ed Burnette.
Осторожно много скриншотов.

В блоге, посвященном приёмам работы с сообществами в Интернете, Ричард Миллингтон  предложил свод правил по созданию прочного сообщества.

Все вместе эти семь элементов выглядят довольно радикально, каждый из них действителен не только для Интернета, но и для реальной жизни, и в каждом из них есть и польза и применимость.

Итак, чтобы люди объединились в сообщество, нужны следующие элементы:

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

В этой статье я расскажу о добавлении разъема внешней Wi-Fi антенны на ноутбуки и Tablet PC.
Обычно антенны с высоким коэффициентом усиления используются для увеличения покрытия точками доступа, я же покажу какой эффект они оказывают на стороне передатчика.
Экспресс тестирование направленных и всенаправленных антенн в качестве бонуса.

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



Кстати, если вам понравится этот рассказ, приходите на Тестовую среду в нашем питерском офисе 30 ноября (зарегистрироваться), – там я расскажу больше об игровых механиках в тестировании и с удовольствием вживую с вами поговорю. Итак.

В 2005-2006 годах часть не поисковой инфраструктуры Яндекса стала испытывать нагрузки растущего как на дрожжах Рунета. Появилась необходимость тестировать производительность смежных с поиском сервисов, в первую очередь — баннерную крутилку. Тимур Хайруллин, на тот момент руководивший нагрузочным тестированием, озадачился поиском подходящего инструмента.

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

Я отвечу на вопросы: Что тестируем? Кто этим занимается? Зачем это все происходит? Что у нас есть?
А затем расскажу как все работает: опишу круги тестирования — с первого по девятый.

Что?

Наш продукт — корпоративное web-приложение Service Desk, написано на java.

Кто?

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

Зачем?

Цель моей группы — уберечь продукт от регрессионной спирали смерти.
Задача группы — необнаружение дефектов максимумом интересных способов с минимальным количеством ручного труда.

Что у нас уже есть?

900 коротких и не очень сценариев использования приложения закодированых в тесты.
CI Jenkins на шести серверах, три СУБД, два семейства ОС и три браузера под которые пишем продукт.

Как это работает?

Введение

Добрый день, уважаемое хабро-сообщество. По профессии я человек далёкий от IT, однако, практически все, так или иначе касающиеся данной сферы статьи мне очень интересны, поскольку в душе я тот еще гик.

Как вы, наверное, уже успели заметить, данная статья далеко не первая, посвящённая теме eGPU. Вполне возможно, что в моей статье вы найдёте мало интересного, но, тем не менее, я хочу поделиться своим опытом, результаты которого меня впечатлили. Прошу под кат (внимание трафик!)…

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

Большое количество вопросов, как повысить быстродействие виртуальной среды, побудило меня к написанию небольшого FAQ по оптимизации виртуальных машин на основе VMware vSphere – платформы используемой большинством наших корпоративных клиентов. При этом хочется отметить, что для решений на основе Hyper-V и Xen Server корректный выбор устройств также способен ускорить работу виртуальных серверов.

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

Как-то давно я уже писал об этом, но немного скудно и сумбурно. После я решил расширить список инструментов в обзоре, добавить статье структуры, учесть критику (большое спасибо Lefty за советы) и отправил ее на конкурс на СекЛаб (и опубликовал ссылку, но по всем понятным причинам ее никто не увидел). Конкурс закончен, результаты объявили и я с чистой совестью могу ее (статью) опубликовать на Хабре.

Бесплатные инструменты пентестера веб-приложений

В данной статье я расскажу о наиболее популярных инструментах для пентестинга (тестов на проникновение) веб-приложений по стратегии «черного ящика».
Для этого мы рассмотрим утилиты, которые помогут в данном виде тестирования. Рассмотрим следующие категории продуктов:

1. Сетевые сканеры
2. Сканеры брешей в веб-скриптах
3. Эксплойтинг
4. Автомазация инъекций
5. Дебаггеры (снифферы, локальные прокси и т.п.)

Недавно один из заказчиков TestLab² пожелал узнать, как будет работать его инсталлятор (с закачкой всякого на лету) на разных каналах. Внезапно первые подходы показали, что нам везет и обычные edge, umts и wimax-каналы (не говоря о проводных) в нашей округе как-то уж очень хорошо работают.
Чтобы создать тяжелые условия мы нашли и применили специализированный инструмент WANem, о котором я расскажу под катом.

Я провел настоящее исследование ситуации с автоматизированным тестированием интерфейса мобильных приложений. Речь идет не о тестировании модулей, а именно о тестировании интерфейса финального приложения. И, да, прямо на телефоне!

Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.

В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…

Такие тесты проводятся после каждого релиза и занимают очень много времени.

В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.

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

Введение

Так уж повелось, что любую статью о нечеткой логике принято начинать с упоминания имени Лотфи Заде. И я не стану исключением. Дело в том, что этот человек стал не только отцом-основателем целой научной теории, написав в 1965 году фундаментальный труд «Fuzzy Sets», но и проработал различные возможности ее практического применения. Он описал свой подход в 1973 году в тексте «Outline of a New Approach to the Analysis of Complex Systems and Decision Processes» (опубликованном в журнале IEEE Transactions on Systems). Примечательно, что сразу после его выхода одна предприимчивая датская фирма весьма успешно применила изложенные в нем принципы для усовершенствования своей системы управления сложным производственным процессом.

Но при всех заслугах Л. Заде, не менее важный вклад внесли последователи этой теории. Например, английский математик Э. Мамдани (Ebrahim Mamdani). В 1975 году он разработал алгоритм, который был предложен в качестве метода для управления паровым двигателем. Предложенный им алгоритм, основанный на нечетком логическом выводе, позволил избежать чрезмерно большого объема вычислений и был по достоинству оценен специалистами. Этот алгоритм в настоящее время получил наибольшее практическое применение в задачах нечеткого моделирования.

Начну, пожалуй, с очевидного (слева от этого текста). Изображение, приведенное здесь, довольно известно. Оно показывает, что сотрудники Интел обычно носят на пальцах вместо колец процессоры Atom и рисовые зерна.
Оно демонстрирует размер процессора Intel Atom в сравнении с рисовым зерном. А я продемонстрирую вам буквально «на пальцах» простые и, надеюсь, полезные для программистов на С\С++ советы по оптимизации софта для Intel Atom.

Привет, Хабражители!

По роду своей деятельности мне часто приходится подбирать тестировщиков для тестирования различных проектов (web, desktop, mobile и т.д.).
При этом тестировщики не всегда оправдывают свои заявленные умения и свой профессионализм.

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

Зачем нанимать «одного» тестировщика, если можно получить сотню и оплачивать только интересные баги.