Тестирование является важной составляющей процесса разработки приложения. Для Android тестирование особенно важно, так как устройства сильно отличаются друг от друга:

• Размером и разрешением экрана.
• Версией Android.
• Форм-фактором.
• Системой команд процессора.
• Наличием фронтальной камеры, NFC, внешней клавиатуры, и т.д.

Поэтому тестировать приложение приходится на множестве устройств.
В процесс тестирования входят различные виды тестирования. Рассмотрим, как происходит процесс функционального тестирования приложения вручную. Тестировщик устанавливает на устройство приложение, вдумчиво проверяет всю функциональность, затем возвращает устройство в первоначальное состояние. И так для каждого приложения и каждого устройства. Очевидный недостаток такого способа – большие затраты времени для регулярного тестирования.
Очевидный плюс автоматизированного тестирования – его можно регулярно проводить без особых затрат. Например, каждую ночь тестировать свежий билд приложения на всем множестве имеющихся устройств, а утром анализировать результаты и исправлять ошибки.
В данной заметке будут рассмотрены средства реализации автоматического тестирования. Рассматриваются только инструменты, входящие в Android SDK или распространяющиеся под Open Source лицензией.

О чем статья

В этой статье я сжато, без «воды», расскажу как отлаживать приложения для Android не имея их исходного кода на Java. Статья не совсем для новичков. Она пригодиться прежде всего тем кто более или менее понимает синтаксис Smali и имеет некоторый опыт в reversing engineering приложений для Android.

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



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

Списки, разделённые на секции, встречаются довольно часто как в системных приложениях, так и в сторонних. Но, как ни странно, платформа не предлагает способов для их реализации «из коробки», в отличие от iOS.

В данном руководстве описана разработка, компиляция и развертывание приложений Node.js в Windows Azure с помощью интегрированной среды разработки (IDE) Cloud9.

О чем пойдет речь в данном руководстве:

• Как создать проект в Cloud9 IDE.
• Как развернуть проект в Windows Azure.
• Как обновить развернутое приложение в Windows Azure.
• Как перемещать проекты между тестовыми и рабочими развертываниями.

Cloud9 IDE –– это кросс-платформенная среда разработки с веб-интерфейсом. Одна из функций Cloud9 для проектов на базе Node.js позволяет выполнять прямое развертывание приложений в Windows Azure. Кроме того, среда Cloud9 интегрирована с репозиториями GitHub и BitBucket, что облегчает обмен проектами с другими разработчиками.

С помощью Cloud9 можно разрабатывать и развертывать приложения в Windows Azure из большинства современных браузеров и операционных систем, причем установка дополнительных инструментов или SDK на локальном компьютере не требуется. Ниже описана работа в браузере Google Chrome на компьютере Mac.

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

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

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

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

Внимание! Данная статья рассчитана на людей, имеющих представление о том, что такое инспекции кода, и желающих внедрить эту методику в своей компании.


Когда мы начинали заниматься процессом внедрения инспекций кода (code review) в своих проектах, то были неприятно удивлены отсутствием толковых материалов по организации этого процесса с нуля. Еще один крайне скудно освещенный аспект — это масштабирование процесса инспекций.

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

Итак, начнем.

Возможно, многие из вас уже читали книгу Итана Маркотта «Responsive Web Design» в оригинале. Для тех, кто еще этого не сделал, у меня есть хорошая новость – весной этого года издательство «Манн, Иванов и Фербер» выпустило данную книгу на русском языке под названием «Отзывчивый веб-дизайн».

Почему стоит прочитать эту книгу?

Во-первых, эта тоненькая книга (всего 176 страниц) содержит описание технологии, которая уже стала революционной. Если оценивать влияние, которое оказала данная книга на Сеть и процесс веб-разработки, то ее можно поставить в один ряд с такими инновационными книгами прошлых лет, как: «WEB-дизайн по стандартам» Джеффри Зельдмана и «AJAX в действии».

Во-вторых, данная книга была написана Итаном Маркоттом (Ethan Marcotte) — человеком, который придумал само понятие отзывчивый веб-дизайн.

В-третьих, в ноябре 2011 года «Отзывчивый веб-дизайн» был признан журналом .net magazine одной из 25 лучших книг для веб-дизайнеров и разработчиков.

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

Далее о том, как все это дело автоматизировать.

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

Предисловие переводчика:
Недавно начал изучать PHPUnit (framework семейства xUnit) и с удивлением обнаружил, что на русском языке нет статей про автоматические тесты для самых-самых чайников.
В первой главе документации по PHPUnit на примерах очень доступно рассказывается, что такое автоматическое тестирование.


Даже хорошие программисты допускают ошибки. Разница между хорошим программистом и плохим заключается в том, что хороший программист как можно чаще использует тесты, чтобы найти свои ошибки.
Чем раньше Вы начнете тестировать, тем выше Ваши шансы найти ошибку, и тем ниже цена исправления.
Это объясняет, почему откладывание тестирования до момента передачи программы заказчику является очень плохой практикой. Большинство ошибок так и не будет найдено, а цена исправления станет такой высокой, что Вам придется составить большой график работы, т.к. сразу Вы не сможете их все исправить.

Довольно часто при написании модульных тестов нам приходится сталкиваться с тем, что тестируемый класс зависит от данных из внешних источников, состояние которых мы не можем контролировать. К таким источникам можно отнести далеко расположенную общедоступную базу данных или службу, датчик какого-нибудь физического процесса и пр. Либо нам необходимо убедиться, что некие действия выполняются в строго определенном порядке. В этих случаях к нам на помощь приходят Mock объекты (mock в переводе с английского — пародия), позволяя тестировать классы в изоляции от внешних зависимостей. Использованию Mock объектов в PHPUnit посвящается эта статья.

Предисловие переводчика
Эта статья продолжает серию переводов официальной документации по PHPUnit на русский язык.
Часть 1, Часть 2

Пример 4.1 демонстрирует как с помощью PHPUnit можно выполнить тестирование операций с массивами PHP. В этом примере показаны базовые соглашения и шаги, свойственные тестам PHPUnit:

Предисловие переводчика
Эта статья продолжает серию переводов официальной документации по PHPUnit на русский язык.
Часть 1, Часть 2, Часть 3,

Перевод статьи “Responsive workflow” финского веб-дизайнера и разработчика Вильями Салминена (Viljami Salminen).

На прошлой неделе я был на конференции Webshaped, где Стивен Хэй (Stephen Hay) рассказывал о процессе разработки адаптивного дизайна. Этот пост не совсем о том же самом, но подход Стивена напомнил мне мой собственный, поэтому я решил изложить некоторые мысли по этому поводу, описать как моя работа эволюционировала за прошедшие два или три года и как может измениться в будущем.

Groovy можно использовать по разному — для скриптов, для Grails, для быстрого написания прототипов, для DSL и т.д.

Меня же Groovy всегда привлекал как улучшенная Java. В самом деле — почти любой Java код будет валидным кодом Groovy — т.е. если не помнишь как что то делать в Groovy-way, можно всегда писать так, как принято в Java, а если помнишь — вот тебе и Closures, и удобные списки, и много других замечательных вещей.

Единственное, что мешало использовать Groovy для разработки production кода — отсутствие ошибок компиляции в большом числе случаев. Например если вызываешь несуществующий метод, обращаешься к несуществующей переменной и т.д.

Для многих Groovy фреймворков и библиотек это реально нужно (см. например работу с XML в Groovy), но если я пишу обычный код, мне это серьезно мешает.

Так вот, наконец в Groovy 2.0 появилась возможность сказать — проверяй в этом классе типы, существование методов и переменных!

var  singleton = (function () {
	var data, method_args;

	data = [];
	method_args = [];

	function add (items) {
		var i;

		data.push(items);
		method_args.push(arguments);
	}

	function remove () {
		data.pop();
		method_args.push(arguments);
	}

	return {
		add : add,
		remove : remove
	}
}());

Есть доступ к объекту singleton.

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