Спасибо за комментарий. Хорошо, что есть вдумчивые читатели. Конечно, Вы правы. Но не хочется превращаться в телевизор, поэтому стараюсь не повторяться, на важные блоки просто давать ссылки. Да и не книга тут, а так, "комикс" на 140+ буковок. Про циклы и производительность почти каждая третья публикация. Никуда без этого...
1. Про авторизацию не совсем понял, ну есть она и есть. Проблем не доставляет.
Да, в исходном коде тоже есть jql. Проекты ищутся просто для проверки. Но он не один. Их список известен, можно и вектором задать. Но всегда бывают нюансы, пусть уж будут в том виде, как они в системе хранятся.
А еще иногда консультанты так штатные модели данных раскорячат, что сразу и не поймешь что где лежит.
Как я сразу отметил, вопрос учета -- внешний вопрос. Куда и по каким правилам соотносить затраты. Ответ сошелся -- замечательно. Не сошелся -- смотрим косяки. Народ в джиру тоже не просто так пишет, а с подвыподвертом. Как только кто-то подумает, что так нельзя по процессу, так тут же найдется кейс с нарушителем.
Вы Jira, видимо, знаете неплохо, все под руками и в горячем доступе. Но джава -- редкий случай. Есть интерфейсы и все в контуре. Для других систем (особенно живущих в облаке) REST чаще всего будет выступать общим знаменателем. Ну вот джира подвернулась под руку. Это не специально.
Может будет а может не будет. Не знаю. Вопрос пользователям. Надо ассерты ставить и изучать нарушения. Потому что это потянет за собой двойной учет -- проблема более высокого порядка чем код. Для "задачи-пятиминутки" вопрос этот выходит за рамки.
Наверное, Вы архитектор и тогда это многое объясняет. Но непонятно, почему тогда Вы не читаете весь текст? Почти через абзац идет упоминание про документацию API. Про "магические преобразования", коими являются регулярки для json, похоже, Вы тоже не поняли. Почитайте про jq парсер, благо ссылки по тексту есть.
Поясняю еще раз, задачи подобного класса являются проходным мусором и представляют собой определенный вид инженерной/аналитической деятельности. Подключиться к чему угодно, содрать то, что надо, чтобы на выходе получить то, что требуется. Выход = f(вход). И все части являются переменными, включая передаточную функцию. Просто посмотрите на множество различных групп. С подобными вопросами мучается каждый второй начинающий.
В таких условиях глубокое чтение API не только бессмысленно, но и просто вредно. Время = деньги. Если задача решена быстро, считается правильно, код простой и ясный -- задача закрыта, можно переходить к следующей. Главное, что решение через доску все равно приводит к работе с ворклогом.
Вам цель непонятна -- это не страшно. Вы пытаетесь аргументировать в терминах ценностей, которые многим ценны, как фантик от бумажки. Так не работает. Конкретно Jira после закрытия on-premise ветки и высказыванием всяких позиций вообще неинтересна. Разбираться до винтиков в ее API -- бездарно и бессмысленно тратить время.
Может объясните, почему постоянно так получается? Вцепились в частность, которая вообще даже не на заднем плане. Текст -- иллюстрация по решению подобных задачек. Просто почитайте от начала до конца.
Да, Ваш ендпойнт хороший, но тут пошли сначала от проектов. В спринте много проектов, интересовали конкретные. Менеджеру удобно так думать -- прекрасно.
Прям спор как сумму в квадратной таблице считать. То ли по горизонтали, то ли по вертикали сначала.
Это АБСОЛЮТНО безразлично. Потянули с одной нитки -- ну ладно. Потянули с другой -- пожалуйста. Главное до конца дотянуть. Ворклоги все равно остаются. Цифровой шлак никуда не делся.
Взята Jira, а мог быть наумен, гитлаб, битрикс, и прочее имя чему Легион.
Просто скажите, какую мысль хотите донести. С Вами согласился же, можно было пробовать с доски. Но EDA запустили-по другому. Третий раз отвечать на второстепенный вопрос будет уже скучно и неинтересно.
Да, можно и с борда. Оттуда менеджеры и пытались сначала грузить в excel. И не устраивало по полной.
Если доска настроена.
Если спринты ведутся как надо.
Если все задачи в спринте ровно по тем проектам, что надо.
Если точно ясна методика разнесения часов.
Если ясно, что делать с перетекающими из спринта в спринт задачами.
Если...
Что от проектов, что от доски -- почти одинаково и никак не влияет на суть. Не воспринимайте это как мега задачу. Это просто иллюстрация подхода. Была бы не джира, а что-то другое... без разницы.
Шутить изволите-с? Но отмечу, что здесь никто никого не убеждает -- унылое это занятие.
Насчет сражений тоже сомнительно. Многие читают между строк и начинают на мельницы нападать. Нет бы что созидательное. Остается рядом стоять и руками разводить.
Не знаю, какая у Вас программа, но и data.table можно по верхам в один день вместить. Глубинам все равно не обучить, только практика и самостоятельное набивание шишек даёт устойчивое знание.. Но за руку провести по шоколадной фабрике и дать краткий обзор — возможно. У человека остаётся воспоминание, что есть разные методы и подходы, позже сможет сознательно вернуться сам.
Пока tidyverse развивался, функции претерпевали изменение. Это нормально. Сейчас многое застабилизировалось, главное, что здесь применяются лучшие практики разработки ПО. Читали про жизненный цикл функций в tidyverse?https://www.tidyverse.org/blog/2021/02/lifecycle-1-0-0/
Там найдете ответы на более сложные случаи. А про сортировку -- странный абстрактный вопрос. Если требуется получить n-ый по магнитуде элемент массива -- Вы что делаете при этом? Многие вещи на поверхности кажутся странными по причине неглубокого погружения. Все ссылки в тексте есть.
Я бы предпочёл не ругаться. Радости не доставляет, правда. Если действительно интересно, то могу детально пояснить. В глубине не все просто и очевидно.
Но реально удобнее в телеграме, в группе или peer-to-peer. Полагаю, стригальщики большинство вопросов смогу дать ответ. Если есть сомнения — поглядите прошлые публикации.
В R все в порядке
Консолидировал здесь: https://t.me/r_in_action/165
Михаил, спасибо за добавление.
https://tidyverts.org/ вообще сам по себе очень полезен.
Это перевод.
Это 2016 год, а на дворе 2022. Многое изменилось.
Спасибо за комментарий.
Хорошо, что есть вдумчивые читатели. Конечно, Вы правы. Но не хочется превращаться в телевизор, поэтому стараюсь не повторяться, на важные блоки просто давать ссылки. Да и не книга тут, а так, "комикс" на 140+ буковок. Про циклы и производительность почти каждая третья публикация. Никуда без этого...
Jira чужая и в облаке, доступ только через REST. Миссия провалена.
Но не в Jira дело.
Спасибо, хороший ответ.
1. Про авторизацию не совсем понял, ну есть она и есть. Проблем не доставляет.
Да, в исходном коде тоже есть jql. Проекты ищутся просто для проверки. Но он не один. Их список известен, можно и вектором задать. Но всегда бывают нюансы, пусть уж будут в том виде, как они в системе хранятся.
А еще иногда консультанты так штатные модели данных раскорячат, что сразу и не поймешь что где лежит.
Как я сразу отметил, вопрос учета -- внешний вопрос. Куда и по каким правилам соотносить затраты. Ответ сошелся -- замечательно. Не сошелся -- смотрим косяки. Народ в джиру тоже не просто так пишет, а с подвыподвертом. Как только кто-то подумает, что так нельзя по процессу, так тут же найдется кейс с нарушителем.
Вы Jira, видимо, знаете неплохо, все под руками и в горячем доступе. Но джава -- редкий случай. Есть интерфейсы и все в контуре. Для других систем (особенно живущих в облаке) REST чаще всего будет выступать общим знаменателем. Ну вот джира подвернулась под руку. Это не специально.
Может будет а может не будет. Не знаю. Вопрос пользователям. Надо ассерты ставить и изучать нарушения. Потому что это потянет за собой двойной учет -- проблема более высокого порядка чем код. Для "задачи-пятиминутки" вопрос этот выходит за рамки.
Дайте свой пример рабочего кода. Это будет хорошей аргументацией и демонстрацией. Просто комментарии "мне непонятно" писать -- дело нехитрое.
Наверное, Вы архитектор и тогда это многое объясняет.
Но непонятно, почему тогда Вы не читаете весь текст? Почти через абзац идет упоминание про документацию API. Про "магические преобразования", коими являются регулярки для json, похоже, Вы тоже не поняли. Почитайте про
jqпарсер, благо ссылки по тексту есть.Поясняю еще раз, задачи подобного класса являются проходным мусором и представляют собой определенный вид инженерной/аналитической деятельности. Подключиться к чему угодно, содрать то, что надо, чтобы на выходе получить то, что требуется.
Выход = f(вход). И все части являются переменными, включая передаточную функцию. Просто посмотрите на множество различных групп. С подобными вопросами мучается каждый второй начинающий.
В таких условиях глубокое чтение API не только бессмысленно, но и просто вредно. Время = деньги. Если задача решена быстро, считается правильно, код простой и ясный -- задача закрыта, можно переходить к следующей. Главное, что решение через доску все равно приводит к работе с ворклогом.
Вам цель непонятна -- это не страшно. Вы пытаетесь аргументировать в терминах ценностей, которые многим ценны, как фантик от бумажки. Так не работает.
Конкретно Jira после закрытия on-premise ветки и высказыванием всяких позиций вообще неинтересна. Разбираться до винтиков в ее API -- бездарно и бессмысленно тратить время.
Может объясните, почему постоянно так получается? Вцепились в частность, которая вообще даже не на заднем плане.
Текст -- иллюстрация по решению подобных задачек. Просто почитайте от начала до конца.
Да, Ваш ендпойнт хороший, но тут пошли сначала от проектов. В спринте много проектов, интересовали конкретные. Менеджеру удобно так думать -- прекрасно.
Прям спор как сумму в квадратной таблице считать. То ли по горизонтали, то ли по вертикали сначала.
Это АБСОЛЮТНО безразлично.
Потянули с одной нитки -- ну ладно. Потянули с другой -- пожалуйста. Главное до конца дотянуть. Ворклоги все равно остаются. Цифровой шлак никуда не делся.
Взята Jira, а мог быть наумен, гитлаб, битрикс, и прочее имя чему Легион.
Просто скажите, какую мысль хотите донести. С Вами согласился же, можно было пробовать с доски. Но EDA запустили-по другому. Третий раз отвечать на второстепенный вопрос будет уже скучно и неинтересно.
Да, можно и с борда. Оттуда менеджеры и пытались сначала грузить в excel. И не устраивало по полной.
Если доска настроена.
Если спринты ведутся как надо.
Если все задачи в спринте ровно по тем проектам, что надо.
Если точно ясна методика разнесения часов.
Если ясно, что делать с перетекающими из спринта в спринт задачами.
Если...
Что от проектов, что от доски -- почти одинаково и никак не влияет на суть. Не воспринимайте это как мега задачу. Это просто иллюстрация подхода. Была бы не джира, а что-то другое... без разницы.
Затрудняюсь ответить. Где-то просто есть код без результата.
Шутить изволите-с?
Но отмечу, что здесь никто никого не убеждает -- унылое это занятие.
Насчет сражений тоже сомнительно. Многие читают между строк и начинают на мельницы нападать. Нет бы что созидательное. Остается рядом стоять и руками разводить.
Не знаю, какая у Вас программа, но и data.table можно по верхам в один день вместить. Глубинам все равно не обучить, только практика и самостоятельное набивание шишек даёт устойчивое знание.. Но за руку провести по шоколадной фабрике и дать краткий обзор — возможно. У человека остаётся воспоминание, что есть разные методы и подходы, позже сможет сознательно вернуться сам.
Пока tidyverse развивался, функции претерпевали изменение. Это нормально. Сейчас многое застабилизировалось, главное, что здесь применяются лучшие практики разработки ПО. Читали про жизненный цикл функций в tidyverse?https://www.tidyverse.org/blog/2021/02/lifecycle-1-0-0/
Спасибо за ценный комментарий.
В первом же абзаце под катом приведен краткий список ключевых ссылок по теме R Markdown.
Там можно все определения прочитать и все аспекты технологии.
https://tineye.com/search/2fa1db3d0ee63c1dd19375a7c85d22ec3514ead2?sort=score&order=desc&page=1
Не сам рисовал. Могу заменить на что-то получше, если предложите.
Елена, Вы вообще о чем? Мне кажется, что диагональное чтение создало какие-то новые неведомые смыслы.
Ключевые слова:
Non-standard evaluation, environment hierarchy, variable lookup.
Lisp quote/unquote.
Там найдете ответы на более сложные случаи.
А про сортировку -- странный абстрактный вопрос. Если требуется получить n-ый по магнитуде элемент массива -- Вы что делаете при этом? Многие вещи на поверхности кажутся странными по причине неглубокого погружения. Все ссылки в тексте есть.
Если 100 раз упомянуть имя датафрейма в одном выражении -- защита возрастает! Компьютер убеждается, что ты точно знаешь, что хочешь.
Томас, Хант: Программист-прагматик, 2020
Тема 9. DRY - ПОРОКИ ДУБЛИРОВАНИЯ
Я бы предпочёл не ругаться. Радости не доставляет, правда. Если действительно интересно, то могу детально пояснить. В глубине не все просто и очевидно.
Но реально удобнее в телеграме, в группе или peer-to-peer. Полагаю, стригальщики большинство вопросов смогу дать ответ. Если есть сомнения — поглядите прошлые публикации.