Вступление

Как вы уже, наверное, знаете, 8-9 декабря в Москве пройдёт очередной Heisenbug, поэтому мы решили познакомить Хабр с программой предстоящего события.

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

Почему тебе, дорогой хаброжитель, вообще стоит слушать какого-то маркетолога, который пишет эту статью? Что он может понимать в нашем нелёгком труде? За этой инфой пришлось лезть в самые тёмные глубины LinkedIn: когда-то давно, в 2010 году я устроился в одну небольшую уютную компанию в Новосибирском Академгородке на первую свою работу Java-программистом. Чтобы немножко изучить продукт, руководство поручило ответственную миссию: вручную бегать по интерфейсу нашего веб-приложения, прокликивать кнопочки и выдергивать оттуда ошибки. Довольно скоро мне поручили придумывать тест-планы, а потом и вовсе дали невероятно ответственную задачу: написать совершенно новый фреймворк для автоматического тестирования.

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

Привет Хабр!

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

В ожидании чудес

Канун Нового Года — время чудес. В преддверии нового года мы все вспоминаем год уходящий и строим планы на следующий. И надеемся, что все проблемы останутся в прошлом, а в новом году случится чудо, и мы заживём по-новому.

Какой же Java разработчик не мечтает о чуде, которое осенит его и позволит стать Самым Крутым На Свете Java Программистом.

Хорошие новости: я хочу рассказать как раз о таком чуде.

Имя ему — автоматические тесты!

Предисловие от переводчика

На протяжении многих лет разработки ПО, будучи участником многих команд, работая с разными хорошими и опытными людьми, я часто наблюдал (да и чего греха таить, до определенного момента — создавал) одну и ту же проблему — тотальный бардак в репозитории. Каждый писал комментарии к коммитам в своем стиле (и хорошо, если постоянно в одном); половина комментариев была бесполезна (из разряда "это мост"), половина оставшейся половины — едва понятна.

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

На написание данной статьи подтолкнуло не столько недавнее получение заветного статуса ISTQB Certified Tester, сколько собирание по крупицам материалов для подготовки к экзамену. Например, последняя статья на Хабре по этой теме была в 2012 году. Плюс большинство материалов подразумевает проведение экзамена на английском, а я предпочел сдавать на русском (как оказалось в дальнейшем, в один день со мной сдающих на английском не оказалось вовсе).

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

Предисловие

Как бывший программист на С++, который перешел на православную Java, я решил постепенно подкрепить свои знания сертификатами. Просто для себя (не совсем так просто, но о мотивации чуть далее). Получение подобной «бумаги» стало для меня новым квестом и о том, как его пройти я и буду рассказывать, параллельно сдав все явки и пароли в Киеве. Само собой, не считая конкретного центра сертификации, все сказанное актуально и для не киевлян.

Добрый день жители хабра и остального мира. Эта статья является продолжением первого поста о сдаче экзамена Java Progammer I. Часть информации будет продублирована тут. Сегодня я хотел бы затронуть такие вопросы:

• зачем нужна сертификация;
• какие виды сертификатов может получить инженер от Oracle;
• что нужно знать или выучить, чтобы успешно сдать экзамены по Java Programmer I/II.

Доброго времени суток, дорогой Хабраюзверь. Буду краток. Немного метрик: за последние три года я увеличил свой доход в 10 раз и не превратился в дикого трудоголика, а скорее наоборот, стал больше путешествовать; при этом количество проектов, которые я успешно начал и довёл до конца, выросло втрое — я не говорю о чисто рабочих проектах, возможно Вам знакомы мои курсы по Java, которые я успешно продолжаю развивать в нерабочее время. Ключ ко всему этому состоит из трех частей:

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

В этом посту я затрону первый аспект (самый ключевой аспект). Никакой абстрактной теории, только личные кейсы, которые я наработал годами и обкатал на собственной шкуре, а главное все бесплатно, без смс и регистрации, на Мегамозге. Если статья понравится, тогда напишу и про другие аспекты.

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

Данная статья является продолжением к самым важным советам по повышению продуктивности: «Личная продуктивность (только проверенные на себе подходы)».

В прошлых статьях мы говорили о том, как правильно поставить перед собой долгосрочные цели, — назовем это уровнем стратегии. Мы уже поговорили о том, как эффективно проводить микроменеджмент своих задач и доводить проект до конца. Назовём этот уровень тактическим. Сегодня я хочу рассказать о том, как правильно связать эти уровни между собой, чтобы то, что делается на тактическом уровне, связалось со стратегическим уровнем. Очень часто именно этот аспект подкашивает молодых адептов моих советов. Кажется продуктивность выросла и долгосрочные цели стоят правильные, но почему-то в конце квартала/года понимаешь, что сделано намного меньше, чем хотелось. Если вам это знакомо, то сегодня я расскажу почему так происходит и как с этим бороться.

Для примера я взял ОЧЕНЬ упрощенный кейс (личный давний опыт), который мне помог найти мою первую работу в большой международной компании на позиции Android-разработчик.

Данная статья подготовлена на базе нащего скринкста комманды Java Hexlet, выпуск №3. Посему, если вы слушали скринкаст, то можете смело проигнорировать статью.

Статья публикуется от имени Перфильева Алексея, akaaxel

Gatling – это framework для проведения нагрузочного тестирования. Он основан на трех технологиях: Scala, Akka и Netty.
В этой статье мы:

1. Посмотрим, как установить и начать использовать Gatling.
2. Разберем синтаксис скриптов Gatling на языке Scala.
3. Напишем небольшой тест, где используем основные функции Gatling. Запустим тестовый скрипт при помощи sbt и сохраним отчет.

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

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

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

Статья публикуется от имени Масленникова Сергея, sergeymasle

UPD. Добавлен раздел "Реализация расширения для Gatling"

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

Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo, в отделе QA. Большую часть времени занимаюсь автоматизацией тестирования. Недавно я столкнулся с задачей максимально быстро развернуть Selenium-тесты для одного из наших проектов. Условие было простое: код должен лежать в отдельном репозитории и не использовать наработки предыдущих автотестов. Ах, да, и нужно было обойтись без CI. При этом тесты должны были запускаться сразу после изменения кода проекта. Отчёт должен был приходить на почту.

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

Поехали!

Создатель Ruby on Rails Давид Хейнемейер Ханссон (David Heinemeier Hansson) однажды написал статью под заголовком «В программах встречаются баги. Это нормально». За всю историю работы человека с ПО (и не только с ним) баги были неизбежным и порой дорогостоящим спутником новых и интересных решений.

В прошлом году только сбои программного обеспечения, зафиксированные в отчете Software Fail Watch, обошлись компаниям по всему миру в $1,7 трлн. Такие потери побуждают бизнес наращивать расходы на тестирование ПО. Компании нанимают штатных тестировщиков и все больше денег вкладывают в автоматизированные системы.

Есть и еще одно направление, на которое компании также не жалеют денег, — программы Bug Bounty. Крупные технологические корпорации — Apple, Facebook, Google — и даже правительственные организации выплачивают вознаграждения «белым хакерам» за поиск уязвимостей в ПО. Разберемся в истории этого явления.

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

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

Allure-framework успешно применяется в работе автоматизатора функционального тестирования в программе ЕФС и значительно упрощает разбор результатов тестовых прогонов.

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