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

И вот одному менеджеру не досталось пары, и я встал играть роль сотрудника. До этого всем пар хватало, поэтому к роли сотрудника я был не очень готов…

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

Цель кейса — донести до сотрудника обратную связь, что отчеты надо присылать вовремя. Егор начал сразу с места в карьер:

— Александр, как же так, почему Вы не присылаете мне отчеты?

Я стоял, думал-думал, чего сказать. И потом ляпнул первое, что пришло в голову:

— Егор, а чего ты хочешь, если ты такой хреновый менеджер?!

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

— Что значит “хреновый менеджер”?!!! Это недопустимо — так разговаривать с руководством…

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

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

По мотивам этой трансляции.

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

Документация по Ангуляру отлично подходит для начала работы и ковыряния в API. Однако, она не объясняет как организовать и управлять приложением, когда оно разрастется до десятков или сотен тысяч строк кода. Я собрал здесь некоторые из моих наблюдений и передового опыта по управлению расползающимися приложениями. Сначала взглянем на организацию, затем перейдем к некоторым советам по улучшению производительности и закончим краткой сводкой по инструментам, серверам и процессу сборки. Этот пост будет сосредоточен на больших приложениях, в частности, есть отличная статья по лучшим практикам AngularJS с декабрьской встречи, на которую также стоит взглянуть.

Привет, Хабраюзеры! Сегодня я хотел бы рассказать о инструментах, которые облегчают тестирование кукбуков. В чем собственно проблема? С ростом масштаба инфраструктуры становится сложнее следить за зависимостями и последствиями внесения изменений в кукбуки и на повестке дня становится вопрос о их тестировании. Решить данные проблемы помогают такие инструменты, как foodcritics, chefspec, minitest, test kitchen…
В данном посте я хотел бы поделиться своим опытом по освоению test kitchen в «преславутый 21 день». Я старался чтобы данный пост был максимально прост и удобен для начального ознакомления с test kitchen.

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

Кстати, если вы не можете приехать на наше мерпориятие для тестировщиков, можно будет посмотреть трансляцию, которая начнётся завтра, в субботу, 30 ноября в 11:00.



Эта статья основана на опыте решения задачи подготовки сложных наборов синтетических тестовых данных в процессе автоматизации тестирования системы медийной рекламы Яндекса. Конечно, мы не первые, кто сталкивается с такой задачей, поэтому для начала проанализировали существующие подходы и решения. В результате решением стала библиотека ObjectBuilders (на Python), которую можно применить в проектах, где необходимо создавать иерархически связанные наборы данных. Она позволяет задавать их связи, параметры и свойства. А также дает несколько бонусов в качестве побочных эффектов.

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

Друзья! Мы все очень любим (или не любим) поговорить о шаблонах проектирования. Лично я их сильно недолюбливаю, т.к. большинство из них достаточно очевидны для более или менее опытного разработчика, а шаблонность мышления еще никому в жизни не помогала.

Но поговорим мы сегодня не о них, а о других шаблонах, а именно шаблонах поведения, наших людских паттернах, а скорее даже антипаттернах. Чтобы подлить масла в огонь хотел бы немного расшифровать название этого поста.

В повседневной жизни я стараюсь не употреблять слово «программист». Оно для меня несет негативный оттенок и сразу вспоминаются 90-е, когда кого только программистами не называли. Они и картриджи у принтеров меняли и бабушкам-бухгалтерам помогали их первый комп осваивать. Помните это нетленное «Ты же программист!»? В общем дискредитировало себя это слово.

Я как-то привык своих людей называть разработчиками (developers) и для меня программист — это эдакий антипод разработчика. Ну и с годами опыта я познал большое количество антипаттернов для хорошего разработчика, пользоваться которыми он должен как можно реже. Чем реже я их слышу, тем я счастливее. Итак, приступаем.

001. А у меня на компе работает

Эта фраза знакома всем, кто хотя бы несколько месяцев работает в индустрии и просто должна быть исключена из лексикона любого разработчика. Чувак, если ты отправляешь на тестирование код, который не работает у тебя на компе, то тебе не место в профессии! По определению у тебя на компе код всегда работает. Разве может быть иначе? А не работает он у тестировщика, клиента, да кого угодно, потому, что ты не учел какие-то нюансы, различия в окружении, данных, погоде на Марсе и твоя задача выяснить, что именно и исправить, а не пытаться сразу откосить и доказать свою невиновность. Нет ничего страшного в том, что ты чего-то не учел. В моей практике бывали случаи учесть которые мог бы только… Да никто не мог бы!

Не знаю, как вы, я лично обожаю заниматься оптимизацией производительности программ. Я люблю, когда программы не тормозят, а сайты открываются быстро. В этой статье я бы хотел привести некоторые (базовые) подходы к улучшению производительности. В основном, они относятся к веб-приложениям, но некоторые вещи справедливы и для «обычных» программ. Я затрону такие темы, как профилирование, пакетная обработка, асинхронная обработка запросов и др. Этот топик можно считать продолжением «Стратегии оптимизации веб-приложений с использованием MySQL.

Здравствуй, Хабр!

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

• Раздача на Рутрекере (видео+слайды)
• Прямые ссылки на видеофайлы: первая лекция, вторая, третья, четвертая, пятая, шестая и седьмая
• Прямая ссылка на слайды (zip-архив pdf-файлов)
• Подкаст в iTunes
• Плейлист на YouTube
• Форум курса

Первая лекция: Введение в JavaScript, немного истории, числа (тут есть ошибка: функция toFixed округляет значения).



Остальное – под катом.

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

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

Перейдем к типам сервисов

Компания Google наконец-то открыла для всех желающих сервис облачных вычислений Google Compute Engine (GCE), анонсированный полтора года назад. Учитывая опыт компании Google в разработке масштабируемых решений, сервисов для разработчиков и самый большой в мире парк серверов, GCE вполне может составить конкуренцию EC2. Никому не будет плохо, если два гиганта-конкурента начнут демпинговать.

Ко дню премьеры приурочено ещё несколько приятностей:

• снижены цены на инстансы на 10%;
• поддержка 16-ядерных инстансов (до 104 ГБ RAM) для высокопроизводительных вычислений и баз NoSQL;
• кроме Debian и CentOS с ядром от Google, теперь в виртуальных машинах можно запускать FreeBSD и любые дистрибутивы Linux с любыми ядрами и программным обеспечением, включая Docker, FOG, xfs и aufs.

Когда мы говорим об автоматизации процесса разработки и тестирования, мы подразумеваем, что это очень масштабное действие, и это действительно так. А если разложить его по частям, то станут видны отдельные фрагменты всей картины ― такая фрагментация процесса очень важна в двух случаях:

• действия выполняются вручную, что требует сосредоточенности и аккуратности;
• жёсткие временные рамки.

В нашем случае налицо лимит по времени: релизы формируются, тестируются и выкатываются на продакшн-сервер два раза в день. При ограниченных сроках в жизненном цикле релиза процесс удаления (отката) из релизной ветки задачи, содержащей ошибку, имеет важное значение. Для её выполнения мы используем git rebase. Так как git rebase ― это полностью ручная операция, которая требует внимательности и скрупулезности и занимает продолжительное время, мы автоматизировали процесс удаления задачи из релизной ветки.

Автоматизация тестирования – место встречи двух дисциплин: разработки и тестирования. Наверное поэтому, я отношу эту практику к сложным, но интересным.

Путем проб и ошибок мы пришли к следующему технологическому стеку:

1. SpecFlow (опционально): DSL
2. NUnit: тестовый фреймворк
3. PageObject + PageElements: UI-абстракиця
4. Контекст тестирования (информация о целевом окружении, пользователях системы)
5. Selenium.WebDriver

Для запуска тестов по расписанию мы используем TFS 2012 и TeamCity.
В статье я опишу, как мы к этому пришли, типовые ошибки и пути их решения.

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

Отдельное спасибо автору, за разрешение отдельной публикации.

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

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

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



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

Настройка роутинга в Angular JS — не самая сложная штука. Поэтому я лишь предлагаю одно из возможных решений, которое поможет вам придерживаться принципа “don't repeat yourself” при работе с маршрутами.

Приветствую уважаемых хабражителей и Java-программистов!
Cтатья посвящена подготовке к сдаче экзамена Oracle Java SE7 Professional с кодовым номером 1Z0-804. Про это на Хабре уже было написано множество постов (например здесь, здесь, тут, здесь, здесь, тут, тут, и вот тут), поэтому постараюсь не повторяться и дополнить заметками о том что наиболее часто встречалось, важными нюансами, которые на мой взгляд были пропущены или недостаточно хорошо освещены в указанных статьях, и вообще в общедоступной литературе (сразу отмечу, что материал не претендует на полноту, здесь я лишь старался обозначить каверзные вопросы с экзамена и лаконично изложить некоторые сложные вещи). Так же поделюсь своими соображениями насчет того, по каким материалам лучше готовиться. С первого раза экзамен сдать не получилось, поэтому начал сохранять для себя различные заметки, где записывал всё что мне казалось сложным или трудно-запоминаемым. Которыми теперь и решил с вами поделится. Заранее прошу проявить понимание, если вы вдруг заметите ошибку, недочёт или очепятку — пишите в комментарии.

В последнее время набирает популярность семейство подходов и методологий обработки данных, объединенных общими названиями Big Data и NoSQL. Одной из моделей вычислений, применяемых к большим объемам данных, является технология Map-Reduce, разработанная в недрах компании Google. В этом посте я постараюсь рассказать о том, как эта модель реализована в нереляционной СУБД MongoDB.

Что касается будущего нереляционных баз вообще и технологии Map-Reduce в частности, то на эту тему можно спорить до бесконечности, и пост совершенно не об этом. В любом случае, знакомство с альтернативными традиционным СУБД способами обработки данных является полезным для общего развития любого программиста, так же как, к примеру, знакомство с функциональными языками программирования может оказаться полезным и для программистов, работающих исключительно с императивными языками.

Нереляционная СУБД MongoDB представляет данные в виде коллекций из документов в формате JSON и предоставляет разные способы обработки этих данных. В том числе, присутствует собственная реализация модели Map-Reduce. О том, насколько целесообразно применять именно эту реализацию в практических целях, будет сказано ниже, а пока ограничимся тем, что для ознакомления с самой парадигмой Map-Reduce эта реализация подходит как нельзя лучше.

Итак, что же такого особенного в Map-Reduce?

Сегодня мы поговорим про разработанную нами утилиту, которая оптимизирует тестирование PHP-кода с помощью PHPUnit и TeamCity. При этом нужно понимать, что наш проект — это не только веб-сайт, но и мобильные приложения, wap-сайт, Facebook-приложение и много чего ещё, а разработка ведется не только на PHP, но и на C, C++, HTML5 и т.д.

Методы, которые мы описываем, прекрасно адаптируются под любой язык, любую систему тестирования и любое окружение. Поэтому наш опыт может оказаться полезным не только разработчикам веб-сайтов на PHP, но и представителям других областей разработки. Кроме того, в ближайшем будущем мы планируем перевести нашу систему в Open Source ― без обязательной привязки к TeamCity и PHPUnit ― наверняка она кому-нибудь пригодится.

Эта маленькая библиотека позволяет очень просто создать пошаговое введение для сайта или приложения. Достаточно добавить атрибуты data-intro и data-step с описанием и номером шага соответственно к нужным элементам страницы. Вот так:

<a href='http://google.com/' data-intro='Hello step one!' data-step='1'></a>

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?