В своей жизни я встречал людей, которым нравится пылесосить. Да, именно так, сам процесс наведения чистоты доставляет удовольствие. Причина может быть разной — от демонстрации собственной нужности до мизофобии.

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

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

Прочного и надежного робота-уборщика, способного нормально функционировать в самых тяжелых условиях:



Мой выбор пал на RC 3000 от Karcher, впечатлениям от эксплуатации которого и посвящается данная статья.

При разработке и тестировании какого-либо продукта появляется много рутинной работы. Чтобы избежать ошибок, связанных с человеческим фактором, мы используем AIDA.

AIDA (англ. Automated Interactive Deploy Assistant) — это учётная запись, значительно облегчающая работу с Git, TeamCity и JIRA.
Сегодня речь пойдет о том, как с её помощью нам удалось автоматизировать многие рабочие процессы.

В первую очередь мы вспомним об используемой в Badoo системе контроля версий, далее расскажем о том, как было автоматизировано создание веток релиза и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA (контроль и изменение статуса задач, заполнение полей) и ТeamCity (непрерывная интеграция и развёртывание на тестовое окружение).

В этой статье мы решили немного рассказать о средствах continuous integration (CI), которые используем в компании Дневник.ру, и поделиться небольшими наработками в этом направлении. Большая часть материала может показаться банальной рекламой выбранного движка CI или попыткой вызвать holy war (причем не один), но подобного не было в целях. Статья также не является путеводителем или описанием каких-либо фитч и может быть расценена как статья от кэпа – главное, чтобы она была интересна и вызвала дискуссию.

В последнее время в рунете появляется статей про технологию аукциона в реальном времени – Real-time Bidding (RTB). Пока эта тема больше обсуждается на специализированных ресурсах, поэтому я буду одним из первых, кто расскажет о ней на Хабре. Это подлинная, в том числе и технологическая инновация на рынке интернет-рекламы, с которой пора знакомить с ней тех, на кого она собственно нацелена: рекламодателей, покупающих рекламу в интернете, и площадки, зарабатывающие на продаже медийной рекламы и трафика (Habrahabr.ru, например :).

По прогнозам, расценки на медийную рекламу в интернете в 2013 году вырастут на 14 процентов, в то время как в среднем реклама подорожает на 10 процентов. Медийная реклама обгонит и другие инструменты интернет-рекламы – к примеру, контекстная реклама вырастет всего на 13%. На мой взгляд, драйвером этого роста станет именно RTB.

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

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

Что?

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

Кто?

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

Зачем?

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

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

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

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

Полгода назад здесь была опубликована статья, которая меня возмутила. В комментариях я обещал, что напишу свою версию. С другой стороны мне не хотелось этого делать, так как получу закономерные вопросы: «А ты собственно кто такой?». Не люблю подписываться в интернет-постах, у меня портилось мнение о многих писателях после того, как читал их жж-блог. Читаешь книгу, думаешь: «Классный чувак!», почитаешь блог, мнение меняется: «Что за кретин?». Такая разница возникает из-за того, что книга проходит пост-обработку, много раз редактируется.
Данная статья переписывалась несколько раз, в этом варианте, считаю, что она получилась наиболее взвешенной. Статья вполне подходит для хабрахабр, так как от людей технической направленности выходило немало известных произведений. И кому-то из вас захочется написать свою историю.

Введение

В это статье я расскажу о применении инструмента изначально предназначенного для функционального тестирования при тестировании нагрузочном web части системы электронного документооборота (СЭД).

Всем привет!

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

Мы столкнулись с необходимостью автоматизировать сборку и деплоймент на тестовые устройства, когда размер парка устройств превысил два десятка, а количество проектов, одновременно находящихся в QA достигло 30+. При таких объемах деплоймент билда на тестовые устройства с помощью “Build & Run” в XCode начал заметно затормаживать процесс прохождения QA. Было принято решение об автоматизации процесса сборки и заливки билдов на устройства.

Наша обновленная билд-система состоит из трех основных компонентов:

• Репозитории с исходными кодами проектов;
• Сервер сборки;
• Сервер раздачи билдов на устройства.

Процесс прохождения версии проекта от разработчиков до тестировщиков выглядит следующим образом:

• Разработчик делает коммит версии в репозиторий;
• Билд-сервер запускает сборку соответствующего проекта;
• В случае успешной сборки, билд выкладывается на сервер раздачи;
• Итоговый IPA устанавливается на устройства “по воздуху”.

Написать расширение для google chrome несложно. Но при написании первого раширения могут возникнуть (и возникают) вопросы. Большинство мануалов по написанию первого расширения расчитаны на использования манифеста первой версии, поддержка которого в скором будущем прекратится.

В этой статье будет рассмотрено:

• Как составлять манифест v.2
• Как работать с удаленными ресурсами
• Как работать с cookies
• Как работать с local storage
• Как работать с уведомлениями

Многие C++ программисты, пишущие под Windows часто путаются над этими странными идентификаторами как TCHAR, LPCTSTR. В этой статье я попытаюсь наилучшим способом расставить все точки над И. И рассеять туман сомнений.

В свое время я потратил много времени копаясь в исходниках и не понимал что значат эти загадочные TCHAR, WCHAR, LPSTR, LPWSTR,LPCTSTR.
Недавно нашел очень грамотную статью и представляю ее качественный перевод.
Статья рекомендуется тем кто бессонными ночами копошиться в кодах С++.

Вам интересно ??
Прошу под кат!!!

В какой-то момент разработчику андроид приложений становится тесно в рамках одного магазина Google Play. И тогда он начинает задумываться о том, как бы еще донести до пользователей свои приложения. Оказывается, достаточно много вариантов это сделать.

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

Исторически так сложилось, что моей «родной» операционной системой есть Windows. В предыдущей статье Интернет термометр или телеметрия загородного дома я пытался показать «чем мы не кони», «мы тоже можем» или «обезьяну тоже можно научить» причем легко. Но настал час «Х» — переезд на linux. Этот переезд ассоциируется у меня с вынужденной миграцией — ледниковым периодом.

Осенью 2008 года мы потратили две-три недели свободного от основной работы времени, чтобы написать маленькую утилитку для бэкапа баз данных (MS SQL Server и потом MySQL). Сегодня она приносит нам около $230 000 в год и можно с уверенностью говорить, что суммарно мы заработаем на ней больше $1 000 000.

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

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

Порядка 600 операторов в 4 странах, обрабатывающих звонки клиентов на американские (и немного на российские) номера.
Примерно 200 одновременных разговоров в пиковое время.
Примерно 15 000 звонков в день.
Возможность за несколько минут масштабировать это решение в несколько раз (по нашим прикидкам до ~1000 параллельных звонков, прежде чем начнутся проблемы).

Ну и конечно же, плотная интеграция с внутренними системами (CRM, сопровождение покупок, приоритеты операторов и клиентов и много-много других плюшек).

Кому интересно как это это работает и почему именно так — добро пожаловать

Добрый день, уважаемые хабровчане. В этом цикле статей мы с вами пройдем достаточно длинный, но весьма интересный путь по превращению обычного роутера в мини-компьютер с LCD-дисплеем. Для этого мы разработаем сначала USB-видеокарту на базе микроконтроллера STM32F103, потом тестовый драйвер, который позволит нам выводить на него графику, и, наконец – полноценный драйвер фреймбуффера, благодаря которому можно будет запустить настоящие графические приложения, такие как x-сервер. Заодно мы научимся включать наш код в дерево исходников OpenWRT, допиливать его ядро и делать прочие полезные вещи.
Ну а в самом конце мы получим результат, который, я надеюсь, вызовет ностальгическую слезу у многих читателей. Я постараюсь излагать материал таким образом, чтобы в конце каждого этапа мы получали осязаемый результат, не дающий угаснуть энтузиазму. Итак, начнем.

Смартфоны тоже под ударом

Мобильные устройства переживают свой бум. Рост использования смартфонов, естественно, не мог не повлиять на развитие вредоносного программного обеспечения (ВПО) для этих устройств. По сравнению с персональными компьютерами, планка пользовательской грамотности относительно вопросов информационной безопасности здесь еще ниже. Это открывает для злоумышленников большое поле для преступной деятельности. Простейшим способом увода денег являются вредоносные приложения, отправляющие SMS сообщения на платные номера. Но разработчики Zeus и SpyEye не сидят, сложа руки, и в 2010-2011 годах из-под их «пера» выходят модификации, поражающие своей изощренностью.
Многие, наверное, знают, что одним из популярных способов защиты проведения финансовых операций с использованием Интернета является mTan (mobile transaction authentication number — мобильный код аутентификации транзакций) — специальная последовательность цифр, которая присылается на ваш телефон в SMS при проведении какой-либо операции (транзакции), например, при оплате через WebMoney. Распространение смартфонов тут играет на руку злоумышленникам, разработавшим механизм обхода технологии mTan посредством вредоносных приложений для широко распространенных мобильных платформ.

ASLR — это Address Space Layout Randomization, рандомизация адресного пространства. Это механизм обеспечения безопасности, который включает в себя рандомизацию виртуальных адресов памяти различных структур данных, чувствительных к атакам. Расположение в памяти целевой структуры сложно предугадать, поэтому шансы атакующего на успех малы.

Реализация ASLR в Windows тесно связана с механизмом релокации (relocation) исполняемых образов. Релокация позволяет PE-файлу загружаться не только по фиксированной предпочитаемой базе. Секция релокаций в PE-файле является ключевой структурой при перемещении образа. Она описывает, какие необходимо внести изменения в определенные элементы кода и данных для обеспечения корректного функционирования приложения по другому базовому адресу.

Предположим, это ваша цепочка поставок. Сейчас экспертная система будет её оптимизировать.

Вводная: представьте, что вы некая компания, которая производит планшеты и телефоны — майфуны и майпады. Сами вы сидите в Калифорнии, у вас есть несколько своих заводов на Востоке, плюс вы регулярно заказываете кучу всяких комплектующих у тех поставщиков, от которых это выгоднее везти. И ещё у вас есть своя розничная сеть магазинов, где продаются планшеты и телефоны.

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

Есть три проблемы:

• Логистика у нас настолько сложная и разветвлённая, что сейчас над ней работают десятки людей: кто-то занимается распределением майфунов, кто-то раскидывает по магазинам обложки, а производственники просчитывают оптимальные пути сбора комплектующих на заводах со всего мира.
• При этом хочется сэкономить на логистической схеме: вы подозреваете, что умный анализ всех потоков позволит принять решения, например, о месте открытия нового производства или организации дополнительного склада, что в итоге даст вам выгоду.
• И при этом ваши люди постоянно ошибаются с отправлениями – а хочется сделать так, чтобы ничего и нигде не забывалось, всё работало как часы и товары приходили на точки вовремя. Это тоже экономия, но уже за счёт своевременности поставок и отсутствия ошибок.