Как стать автором
Обновить

Комментарии 38

API у него есть? Как выглядит запрос вида «каждое утро я хочу получить log work по всем сотрудникам чтобы отображать у себя список кто чем занимался за последнюю неделю»?

У JIRA это выглядит примерно как 'getIssuesFromJqlSearch( «updated > time.now — time.week» )', на выходе получается список из 100+ элементов, JIRA захлебывается, отсылает клиенту частичный результат, клиент получает мусор, способа гарантированно получить данные не существует.

А у вас как?
У нас есть RESTful API, который, в частности, позволяет выгрести все тикеты для заданного запроса. Формат запросов такой же как в пользовательском интерфейсе. Например, for: mazine resolved date: {Last Month} — тикеты, которые я закрыл в прошлом месяце. Подробнее про запросы, можно прочитать в документации.
У JIRA тоже есть RESTFUL API — это им не мешает, в случае если результат запроса оказался слишком большим, порезать результат и ничего никому об этом не сказать O_O. Что будет с вашим REST, если результата случилось метров 20? Отошлет обратно двадцати мегабайтный HTML/JSON/XML/whatever?
Сорри, не попал. Ниже ответил.
У нас можно постранично забирать данные:
— after: Integer — A number of issues to skip before getting a list of issues. That is, when you specify, for example, after=12 in request, then in the response you will get all issues matching request but without first twelve issues found.
— max: Integer — Maximum number of issues to be returned. If not provided, 10 issues will be imported, by default.
Не понял. Как это поможет, если данные изменились между 1-м запросом с «after = 0, max = 50» и 2-м «after = 50, max = 50»? Относительно чего будет считаться after?
Никак не поможет. Вы можете отсортировать тикеты, например по id, тогда их порядок не будет зависеть от момента запроса: for: mazine resolved date: {Last Month} sort by: {issue id} asc.
Снова не понял :(. Мои извинения, понедельник день тяжелый, плохо на меня влияет. Я могу отсортировать тикеты по id — но порядок при этом будет зависеть от момента запроса. Или я не понимаю как у вас работает сортировка. Например, если у менять есть пять задач: A, B, C, D, E с id 1, 2, 3, 4, 5, обновлены все кроме A и я хочу получить все задачи, которые обновились за последнюю неделю:

«select обновились за неделю start 1 max 2 sort id»

Результат будет:

B( id 2 )
C( id 3 )

Теперь злобный пользователь Вася делает worklog на задаче A и расписывает как он там целый день работал и как все плохо.

… в это время клиент API делает следующий запрос чтобы получить следующий набор данных:

«select обновились за неделю start 4 max 2 sort id»

Что мы получим? У меня есть подозрение, что «start 4» нам не позволит получить информацию об обновлении тикета «A».

Подскажите старику, где я ошибся?
Все так, гарантированной консистентности добиться не удастся. А она действительно нужна в данном случае?
Можно еще по истории для каждого тикета ходить, но мне кажется, что это оверхед в данном случае.
Да нет — просто ряд бизнес задач формулируется как «если за прошедший день/неделю/месяц случилось <что-то>, то сделать <что-то еще>. Например, e-mail отослать». Соответственно, хочется относительно простой способ задать вопрос вида «а покажи мне все тикеты за последнюю неделю, которые обновлялись». При этом не хочется постоянно долбиться этим запросом в сервер — чтобы не создавать нагрузку на сервер и на сетку, ее в крупных компаниях не любят.

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

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

В принципе, понятно что на примерах вида «hello world» это ничего не нужно. И когда задачи — это просто большая куча откуда программисты и тестировщики по приоритету вытаскивают — тоже не нужно. Но при реальном использовании — нужно :(.
Не нужна :) пожалуста не слушайте eyeofhell, не делайте нового монстра. Лучше делайте простой, удобный и быстрый продукт. А команды где несколько тысяч человек в одном проекте — путь используют жиру. Иначе получим две тормозных жиры, а пользоваться нечем :(
Мне вот любопытно — а какое отношение имеет функциональность API к «простоте», «удобству» и «скорости» продукта? Тоесть если авторы разберутся как на самом деле работает REST и сделают, например, ETag-и — каким местом продукт монструозным станет? У него что, кнопочти нажиматься перестанут, или он работать медленнее будет?
Вы не поверите, но каждая новая шестеренка строка кода, новая фича, новая библиотека, формат, протокол, все остальное, оно усложняет продукт, добавляет новые баги, новые заплатки и новые тормоза. И к сожалению экспоненциально.
Не поверю. Я разрабатываю софт за деньги уже более пятнадцати лет. Специализируюсь на высокоуровневой архитектуре и управлении разработкой проектов сложностью от миллиона строк кода. Каждая новая строка кода усложняет продукт только если его пишут школьники, которые недавно прочли книжку «как стать крутым джава программистом за 21 день». При наличии квалифицированных разработчиков с хотя бы десятью годами опыта, добавление новой функциональности ничего не ломает и не замедляет. Уметь надо. У подмастерья стояра тоже шкафы вначале кривые и косые получаются.
Да, похоже мы говрим о разных вещах. Я зря написал про строки, я имел ввиду объем проекта в общем, количество фич. От того что выгрузка идет в json, xml и еще десятке форматов — вот от этого проект становистя монстром. И не важно как он написан, и кем.

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


Улучшение API не меняет пользовательский интерфейс, увы. Если ребята осилят сделать feed изменений в REST — это не затронет ни одной кнопки в пользовательском интерфейсе и не замедлит программу.
А каким образом в вашей задаче могут спасти ETag-и? что изменится в решении вашей задачи если во втором запросе

«select обновились за неделю start 4 max 2 sort id»

вы получите

А( id 1 )
F( id 5 )
G( id 6 )


не спора ради а для простветления только

Вкратце рассказать не смогу — краткое введение в REST это примерно 300 страниц из книжки «REST in Practice», а ее писали ребята которые лучше меня разбираются.

Если утрировать до плинтуса, то есть несколько вариантов относительно надежного взаимодействия с веб сервисом по ненадежному сетевому интерфейсу:

— Etag «идентификатор последнего изменения» и HTTP поле If-Match позволяет отменить запрос, если его результат зависит от предыдущих запросов (постраничное получение результата), а данные с момента первого запроса поменялись. Но это не очень хороший способ, потому как данных может быть много, а нагрузка на сервис постоянной. В песочнице такого не бывает, а в реальной жизни — через раз.

— Etag «предыдущая страница архива» используется при интеграции в крупных компаниях (когда не полтра человека в команде) — сервис (например, система управления задачами) публикует RSS/ATOM FEED изменений, а другие сервисы его втягивают по мере необходимости и переваривают в соответствии с бизнес-логикой.

Но это достаточно сложные техники — они сильно выходят за рамки школьной программы и используются в компаниях где значительно больше 2-3 человек и вопрос стоит не «Лучше делайте простой, удобный и быстрый продукт» а «либо мы сделаем это, это и вот это — либо департамент из трех сотен человек потеряет управляемость» :(.
Вот видите в том то и проблема, у каждого из нас разные цели и разные задачи, причем ОЧЕНЬ разные :)

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

Я крайне согласен что при определенных кейсах то что вы описываете крайне важно, но и имплементация этого может оказаться значительно сложнее нежли расставить Etag'и причем на обеих сторонах.

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

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

и вообще складывается ощущение после ваших постов что вы немного таки придераетесь :)
YouTrack — самый клевый треккер из тех что я видел. С удовольствием используем в работе :) Мечта гика прям :)
Вот только кнопочка new issue оранжевого цвета очень раздражает. Отвлекает от сути, раньше синяя была удобнее.
Хорошая система. Лучше чем Redmine всякий.
Есть ли импорт из Redmine? Как там с трекингом времени, сделали?
Импорт из Redmine нет. Вот список поддерживаемых для импорта трекеров. Трекинг времени пока не сделали. В настоящее время он запланирован на ближайший минроный релиз.
НЛО прилетело и опубликовало эту надпись здесь
Популярная, но трудоемкая фича. Будем делать в ближайшее время. Скорее всего она станет основной фичей следующего мажорного релиза.
НЛО прилетело и опубликовало эту надпись здесь
«ишью» — немного непривычно…
Вроде и баг, и фича, и таск одновременно. Я вот уже шесть лет в проекте, хорошего русского слова для «issue» пока не знаю.
Сейчас мы стали называть их «задачами». Главное, чтобы было понятно, о чем речь :)
Скажите, планируется ли реализация «списка дел задачи»?

В YouTrack 4.0 можно создавать подзадачи и отображать их в деревянном виде. Это не совсем то, но близко. Кроме того подзадачи задач на доске отображаются списком.
>(предлагается бесплатный план на 9 пользователей).
А где выбрать этот план? при регистрации inCloud предлагает триал на 30 дней.
p.s. YouTrack движется верным курсом имхо, не знаю багтреккера удобнее.
Вот здесь www.jetbrains.com/estore/index
Первый пункт — бесплатный вариант на 9 юзеров и 3000 ишью
Благодарствую
В phpstorm есть нативные средства или плагины для общения с YouTrack?
Прошу прощения, что не быстро. Вот ответ нашего специалиста:

Да, во всех IDEA-based продуктах YouTrack поддерживается out-of-the-box через таски.

Для того чтобы заработало, надо сделать следующее (никаких настроек со стороны YouTrack не надо):
0. Включите функции Task Management в phpStorm
1. Открываем меню Tools > Tasks & Contexts. Выбираем пункт Open Task
2. В диалоговом окне Open Task кликаем ссылку Configure. Откроется диалог Servers.
3. Нажимаем кнопку "+" и в появившемся списке выбираем YouTrack
4. Вводим все необходимые параметры: URL вашего YouTrack-сервера, ваши логин/пароль
5. Жмем тест чтобы проверить соединение
5.1 Открыть Commit Message и поправить дефолтный коммент к коммиту.
6. Если все хорошо, сохраняем настройки.
7. Финальный штрих, в диалоговом окне Open Task, вводим issueID того ишью над которым собираемся работать. Если все хорошо с настройками соединения с сервером, сработает контектстный поиск и комплишен.

Создается новый change list с ID и саммари этого ишью. таким образом человек как бы работает в скоупе своей задачи (например, фиксит конкретный баг)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий