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

Указать у сторонней библиотеки область видимости компилирования, и тогда классы из этой библиотеки будут упакованы в jar-файл разрабатываемого плагина. Для этого необходимо в файле pom.xml написать:

  <dependency>
            <groupId>com.google.code.gson</groupId>
            <artifactId>gson</artifactId>
            <version>2.2.2-atlassian-1</version>
	<scope>compile</scope>   
</dependency>

Собрать плагин таким образом, чтобы jar-файл сторонней библиотеки находился в папке dependencies файла obr разрабатываемого плагина.

Все мы в IT сталкивались с системами отслеживания ошибок — с так называемыми баг-трекерами, с issue-трекерами. Один из популярных продуктов такого рода — Atlassian JIRA.

На самом деле, Atlassian JIRA — это больше, чем просто система отслеживания ошибок. JIRA может использоваться довольно широко — в том числе и для управления проектами. Можно сказать, что JIRA — это система для отслеживания статуса задач. Задачи могут быть разными: это сбор требований, тестирование, непосредственно разработка и т. д. Я видел даже попытки подсадить на JIRA бухгалтеров — а что, мол, будет у нас agile-бухгалтерия!

На официальном же сайте JIRA описывается следующим образом:
JIRA is the tracker for teams planning and building great products. Thousands of teams choose JIRA to capture and organize issues, assign work, and follow team activity. At your desk or on the go with the new mobile interface, JIRA helps your team get the job done. В общем, основная идея JIRA в том, что она позволяет планировать работу.

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

Недавно мне на глаза попалась небольшая, но очень емкая статья одного разработчика, в которой он рассматривает code reiew с довольно неожиданной стороны. Большинство материалов, посвященных code review, рассказывают о технических вопросах: какими утилитами пользоваться, как интегрировать code review в процесс continuous integration и прочие технические моменты. Автор же рассматривает code review как социальное взаимодействие. И, на мой взгляд, об этом стоит почитать. Под катом — перевод.

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

Использование исключений для контроля хода выполнения программы (flow control) — давняя тема. Я хотел бы суммировать этот топик и привести примеры правильного и неправильного использования исключений.

20 июля вышла финальная версия Visual Studio 2015 RTM, несущая в себе, в том числе, много нового для веб-разработчиков, специализирующихся на JavaScript: улучшения в редакторе, поддержка популярных библиотек и систем управления пакетами и сборки кода, возможности ES6, а также обновление поддержки Apache Cordova и Node.js.

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

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Кадр из фильма Kingsman

Уверены, в этой статье вы точно узнаете своих сотрудников, а возможно, и себя. Шведский предприниматель и разработчик Дэвид Эльбе описал восемь типов программистов, с которыми ему приходилось иметь дело за последние 10 лет работы в проектах по веб-разработке. Какие типы лучше всего объединить в команду и какой код от них ждать — читайте в переводе от Alconost.

1. Агент 007

Кадр из мультфильма “Пингвины Мадагаскара”
Быстро вникает в ваши проблемы и решает их. Не очень заботится о качестве кода. Ему не придет в голову исправлять отступы в чужом коде. Если необходимо, «воспользуется скотчем».

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

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

Плохо срабатывается с Перфекционистом.

Всем привет!

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

«Ландшафт» СУБД в проектах нашей компании до недавнего времени выглядел так: большую часть составляла Oracle, существенно меньшие — MS SQL и MySQL.

Но, как известно, нет ничего вечного, и недавно к нам поступил запрос о применимости Postgres в одном из наших проектов. К этой СУБД мы присматривались в последние пару лет очень пристально — посещали конференции, meetup’ы, но вот попробовать ее в «боевых» условиях до недавнего времени не доводилось.

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

Тем не менее, написание тестов сложно назвать увлекательным процессом. Инициализация тестовых данных, инициализация моков, создание объекта тестирования… Пока доберешься до вызова метода, который ты собственно хотел проверить, тестировать уже и не хочется ничего. Я конечно утрирую, юнит-тест по своей природе не должен брать на себя слишком много и содержать пару сотен десятков строк инициализации (хотя и такое бывает), однако писать один и тот же код быстро надоедает. И вот уже появляются фабрики тестовых объектов, иерархия базовых классов для тестов и прочие ООП примочки, призванные «упростить» создание теста. Приводит это как правило к тому, что шансов быстро понять, что же делает тест, не путешествуя по этим самым объектам, практически не остается.

Собственно, инструмент, о котором я хочу рассказать, как раз и призван упростить, а в некоторых случаях и полностью убрать фазу инициализации или Arrange фазу теста.

Angular — зрелый и мощный JavaScript-фреймворк. Он довольно большой и основан на множестве новых концепций, которые необходимо освоить, чтобы работать с ним эффективно. Большинство разработчиков, знакомясь с Angular, сталкиваются с одними и теми же трудностями. Что конкретно делает функция digest? Какие существуют способы создания директив? Чем отличается сервис от провайдера?

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

В этой серии статей я собираюсь воссоздать AngularJS с нуля. Мы сделаем это вместе шаг за шагом, в процессе чего, вы намного глубже поймете внутреннее устройство Angular.

Я очень люблю статические типы, поэтому TypeScript стал незаменимым помощником при работе с NodeJS или браузерным JS.

По долгу службы приходится иметь очень много дел с JSON, и здесь система типов TypeScript не помогает ничем, даже мешает, ведь компилятор сообщает об отсутствии ошибок, JSON.parse возвращает тип Any. Кроме того, TypeScript не поддерживает рефлексию, ввиду специфики работы, а значит, нет возможности проверить тип, основываясь на уже существующем коде. Также, до последнего времени, средств для мета-программирования не было вовсе.

Зачастую проверка корректности пришедшего JSON-объекта оборачивается громадным кодом в конструкторах классов, либо такими же конфигурационными файлами. Но, наконец-то, в TypeScript 1.5 появились декораторы.

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

Каждый, кто всерьез занимался разработкой на Ruby, знает про замечательный гем Cucumber. Вкратце — это библиотека для автоматизированного тестирования, заточенная под BDD. Подробнее можно почитать в топике хабраюзера dapi, а еще лучше посмотреть подкаст от Райна Бэйтса. Основная прелесть «огурца» состоит в том, что он позволяет писать тесты на понятном человеку языке, и даже не обязательно английском. Выглядит это так:

Feature: Addition 
  In order to avoid silly mistakes 
  As a math idiot 
  I want to be told the sum of two numbers 

  Scenario: Add two numbers 
    Given I have entered 50 into the calculator
      And I have entered 70 into the calculator
     When I press add
     Then The result should be 120 on the scree

Благодаря Cucumber я подсел на BDD на рельсах. Но вот на PHP, с которым приходится работать основную часть времени, отношения с BDD как-то не сложились. И в первую очередь из-за отсутствия достойного инструментария. Но однажды судьба завела меня на страницу библиотеки Behat (написанной, кстати говоря, хабраюзером everzet). И на меня свалилось счастье…

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

Конечная цель автоматизации тестирования представляет собой некий набор автотестов, которые, при нажатии на кнопку «GO!», будут поочередно запускаться. Ну или всегда можно запустить какой-либо автотест отдельно, если для этого есть необходимость. Каждый такой скрипт проверяет правильность работы определенной части приложения и фиксирует ошибки в случае, если что-то работает не так.
О том, насколько выгоднее использовать автоматизированное тестирование чем ручное, а так же о плюсах автоматизированного тестирования хорошо написано в этой статье. Я же хочу описать возможные проблемы, с которыми может столкнуться тестировщик, решивший использовать автоматизированные тесты.

Зачем разработчикам писать автотесты? С таким же успехом их можно заставить класть плитку или вести бухгалтерию. Не барское это дело! Или, все-таки, барское?

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

Началось все в феврале 2014 года с приглашения посетить конференцию AgileDays2014. Вечером того же дня я засел на сайте конференции, чтобы выделить интересные мне темы и спланировать посещение докладов. Через 5-10 минут я уже смотрел запись выступления с AgileDays 2013 «Свобода и ответственность» Антона Волкова из Alternativa Platform.

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

Для того, чтобы взрастить чувство ответственности нужно:

• Добровольное принятие ответственности. Например, когда человек сам называет срок выполнения задачи, он принимает ответственность. А если срок спускают сверху ни о каком принятии ответственности речи не идет, она на том, кто спустил срок;
• Свобода выбора — люди в праве решать какую работу брать, выбирать стратегию решения задачи, с кем работать (определяют состав команд);
• Последствия (положительные и отрицательные) от принятых решений, действий и бездействий. Например, сдал качественно выполненный функционал в срок, получил признание коллег и, возможно, дополнительное денежное вознаграждение. Или, допустил баг в продуктовой среде, получи нагоняй и порицание от коллег.

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

Предположим, мы разрабатываем простой пакет для npm. Назовём его, например, storage (хранилище). Заранее предусмотрим возможность использования одного из нескольких типов хранилищ, например, FsStorage (файловое хранилище), MysqlStorage (MySQL-хранилище), MongoStorage (Mongo-хранилище).

Далее будет говориться об Oracle Database 11g, о тех привычках что мы выработали со временем.

Пишущую машинку я расчехляю нечасто, но сегодня есть повод.

Тесты для JavaScript пишут многие, некоторые пишут много тестов. Есть несколько популярных тестовых фреймворков, таких как Jasmine, Mocha, QUnit, а также инструменты для автоматического запуска тестов. Некоторые из них даже интегрированы в некоторые редакторы кода. Например, Karma runner и Mocha прекрасно интегрированы моими коллегами в WebStorm. Словом, существуют разные способы запускать тесты автоматически и получать результаты в течении одной или нескольких секунд. Впрочем, время зависит от количества и характера тестов.

Как мы используем наши JavaScript тесты