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

Вступление

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

RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.

Под катом перевод первого из шести уроков официального сайта. Примеры на python, но его знание вовсе не обязательно. Аналогичные примеру программы можно воспроизвести практически на любом популярном ЯП. [так выглядят комментарии переводчика, т.е. меня]

(от 27 июля 2012)
При написании нативного веб-приложения легко начать чувствовать себя богом, способным работать просто с библиотекой работы с DOM (такой как jQuery) и горсткой сервисных плагинов. Вскоре возникает проблема в виде груды вложенных возвратных функций jQuery и разбросанных DOM-элементов без всякой структуры вместо приложения.

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

■ Что такое MVC или, лучше сказать, MV*?

Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:

Я думаю, что в процессе изучения той или иной СУБД каждый из вас не раз изобретал велосипеды для решения своих задач, не зная о существовании той или иной функции или приема, которые бы могли в разы ускорить выполнение запросов и уменьшить объем кода. В данной статье я хочу поделиться с вами своим опытом работы с очень «добрым» и «отзывчивым» MySQL, часто позволяющему программисту делать вещи, которые другие СУБД переварить бы не смогли. Материал будет полезен скорее тем, кто только решил углубиться в чудесный мир запросов, но возможно и опытные программисты найдут тут что-то интересное.

Javascript Enlightenment

Cody Lindley

Уровень знаний: средний
Тщательный обзор мировоззрения JavaScript через разбор встроенных объектов и нюансов.

Открыть

Eloquent Javascript

Marijn Haverbeke

Уровень знаний: начинающий
Вводная книга по JavaScript и программирование в целом.
Открыть

Building A JavaScript Framework

Alex Young

Уровень знаний: продвинутый
Избранные статьи из цикла«Let’s Make a Framework».
Открыть

В последнее время развелось очень много различных AJAX-приложений. По сути автоматизация тестирования такого приложения не отличается от автоматизации тестирования обычного WEB-приложения, но есть несколько тонкостей. Одна из тонкостей — это как раз ожидание завершения всех AJAX-запросов. Например, если отметка некого checkbox'а на странице вызывает обновление какого-нибудь select'a по AJAX-запросу, то тест, который сразу после отметки выбирает конкретный option, свалится, т.к. этого option'a там не будет. А всё потому, что сам тест выполняется намного быстрее чем AJAX-запрос на обновление списка.

В данном случае у автоматизатора есть несколько выходов.

Когда я вижу друзей, которые вкалывают в два раза больше, а зарабатывают в четыре раза меньше, каждый раз начинается разговор:
— А ты бы не хотел поработать программистом? Ты же реально умный. Может ты просто не на своем месте?

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

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

В статье — краткое описание CUITe для тех, кто не сталкивался, использование этого фреймворка для тестирования приложения с фронт-эндом на ASP.NET и проблемы, с которыми столкнулись.

Что есть CUITe

Как говорит описание проекта на codeplex, это тонкая надстройка над UI Testing фреймворком от Microsoft. В описании приведено много преимуществ, но для меня они сводятся к двум: вместо UIMap — Object repository (более красиво, определения (definitions) UI объектов отдельно от остального кода), и разнообразный синтаксический сахар (все наглядно — берем control в UI объекте и вызываем его метод).
Инсталляция банальна — запускаем инсталлер, Next->Next->Finish, подключаем к проекту CUITe.dll — все. Элементы для интеракции находятся с помощью фирменного CUITe Object Recorder™ или вручную (я предпочитаю последнее). Основы записи тут приводить не буду — статья не об этом, по основам информации много, чего не скажешь о проблемах, описанных ниже (будет интерес — напишу отдельный пост по основам).

Итак, не все так радужно.

И чем оно отличается от тестирования по сценариям (сценарного тестирования)

Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.
 

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

Об эмуляторе Android под названием Bluestacks на Хабре уже писали. Но писали или в общем, или мало, или сухо. Тем временем проект подрос и ныне вполне пригоден для использования при тестировании и отладке приложений под Android. Зачем это делать? А затем, что Bluestacks работает намного, нет, даже намного-намного быстрее стандартного эмулятора из Android SDK. Под катом я расскажу о нюансах использования Bluestacks, настройке отладки из-под Eclipse, приведу пару замеров скорости работы и расскажу о нескольких ложках дёгтя в бочке мёда.

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

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

В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

Нам же нужно что-то простое и пуленепробиваемое, как… целое число.

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

Курс этот предназначен прежде всего для junior developer'ов и позволяет повысить уровень аргументации в холиварах на тему «почему PHP (Java, Perl, Bash) отстой».

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

Часть первая: Как появлялись языки и зачем
Часть вторая: Принцип сохранения функционала
Часть третья: Синтаксический сахар или история развития языков

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

Кто-то освежит память, кто-то сверится как с чек-листом, а кто-то заинтересуется и прочтет книгу. Т.к. пост получился достаточно объемным, можно добавить его в закладки и периодически к нему возвращаться.

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

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

Часто подобные тесты могут занимать много времени, даже если использовать in-memory базу данных (я, кстати проверял почему — у нас много JPA entities с множеством свойств в каждом и инициализация Hibernate, имено она, занимает десятки секунд!)

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

Так что план такой:
1. Пишем сервисы, разбитые на два слоя приложения
2. Соединим их Спрингом
3. Напишем тест пользуясь JUnit для взаимодействия этих сервисов (настоящих, без всяких mock)
4. Делаем так, чтобы этот тест не бежал по умолчанию во время билда
5. Profit!

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

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

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

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

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

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

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

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