Отслеживание проблем - инструмент в арсенале разработчиков, который часто недооценивают. Доски Trello / Pivotal / JIRA / YouTrack /… обычно имеют период полураспада обычного блога. Они чувствуют себя отличным упражнением в самосовершенствовании и дисциплине. Они чувствуют себя еще лучше после долгого дня безрезультатных действий в результате обременительного группового проекта. Чтобы было ясно, это хорошая идея, но долго ли они продержатся?

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

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

Отслеживание проблем, например модульные тесты, CI и процесс сборки, должно быть ПРОСТОым! Пожалуйста! Я могу согласиться с аргументом, что разработчики примут сложность для основных функций пользовательского интерфейса, приятной графики или более быстрых запросов к базе данных. Тесты, CI, процесс сборки и отслеживание проблем будут прекращены командой почти сразу, если они не будут простыми и надежными.

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

Эта серия статей посвящена сценариям повышения производительности. Моя первая статья может помочь вам в этом, а вот краткое содержание серии:

Серия GTD-SCRIPTS посвящена сценариям, призванным «Все наладить». Мне нравятся простые многоразовые однофайловые сценарии, которые в остальном выполняют кропотливую работу за считанные секунды. В конце концов, это то, для чего нужны компьютеры, а мы программисты. Вот мой краткий свод правил по GTD-SCRIPTS:

  1. Всегда пишите на языке и с помощью библиотек, которые вы хорошо знаете (для меня Node JS).
  2. Сосредоточьтесь на общем использовании (параметры, ввод / вывод).
  3. Будь простым, глупым!

На этой неделе мы рассмотрим простую утилиту командной строки для Trello. Если вы хотите его использовать:

  1. Это потребует одноразовой настройки API.
  2. Это упростит добавление задач на ваши доски и списки через командную строку.

Репозиторий доступен здесь.

В духе Trello я применил Канбан для gtd-скриптов. Утилиты и помощники будут реализованы по мере необходимости. Ограниченный рефакторинг пойдет по тому же пути. На этой неделе я добавил служебную программу узла, которая использует метод получения или создания ключей API. Поскольку добавить три параметра Trello, необходимых для доступа к API, обременительно, лучше запросить один раз и сохранить их в локальном текстовом файле.

Почему текстовый файл, не лучше ли ...?

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

ПРИМЕЧАНИЕ. Я никогда не делал этого для Google Translate API, потому что он использовал один ключ API, который гораздо проще применить по мере необходимости. Я вернусь и добавлю это по мере необходимости, если мы попробуем еще раз.

Вот способ:

exports.readOrPromptForKey = (file, keyOrKeyChain, promptMessage) => {
    return new Promise((resolve, reject) => {
        file = path.resolve(file);
        const keys = JSON.parse(fs.readFileSync(file, 'utf-8'));
        const foundKey = _.get(keys, keyOrKeyChain);
        if (foundKey) {
            resolve(foundKey)
        } else {
            //Write the given key to the file so it's not asked again
            prompt.start();
            prompt.get([{
                name: 'key',
                description: promptMessage
            }], (err, result) => {
                if (err) {
                    reject(err);
                } else {
                    fs.writeFileSync(file, JSON.stringify(_.merge({}, keys, _.set({}, keyOrKeyChain, result.key))));
                    resolve(result.key);
                }
            });
        }
    });
};
// Example
// readOrPromptForKey('keys.json', 'api.trello.userKey', 'Trello User Key').then(doSomethingWithKey).catch(handleError);

В этом методе используется библиотека flatiron / prompt, позволяющая пользователям вводить свои ключи. После первого ввода они сохраняются в текстовом файле (.json) (который не отслеживается в git).

Что мне нравится в этом сценарии, так это то, что он чрезвычайно универсален. Я могу использовать его с любыми будущими gtd-скриптами без явных изменений.

С другой стороны, сценарий Trello представляет собой адскую цепочку обещаний. По общему признанию, этот сценарий выглядел бы намного лучше с новым синтаксисом async await *. Когда я изначально писал быструю версию этого скрипта, async await изначально не был доступен в узле 6. Я недавно узнал, что это опция в узле 7.x, но мы сосредоточимся на выполнении задач цель перед рефакторингом.

Здесь скрипт add-trello-issue.

Сначала загляните на Начальную страницу Trello API. Вы можете быстро настроить ключ API и токен пользователя, ограниченные вашей учетной записью.

Основные функции находятся в этих запросах API:

const trelloApi = new Trello(YOUR_API_KEY, YOUR_USER_TOKEN);
trelloApi.getBoards(/* YOUR_USERNAME */) //returns Promise
trelloApi.getListsOnBoard(/* BOARD_ID */) //returns Promise
trelloApi.addCard(/* Name */, /* Description */, /* LIST_ID */) //returns Promise

Я добавил цвета, чтобы было немного приятнее для глаз, но ничего сумасшедшего. Вот последовательность:

  1. Ключи (API, токен пользователя, имя пользователя)? Убедитесь, что они у вас есть, и запишите в файл только один раз.
  2. Какую доску вы хотите?
  3. Какой список (дорожку) вам нужен?
  4. Добавьте название и описание своей карты.
  5. Карта создана.

Отклоните доски на closed === true, и все готово к работе со всеми действующими досками Trello. Цифровые подсказки всегда напоминают мне старые терминальные игры (выберите свой номер и т. Д.). Несмотря на старомодность, в этом подходе есть определенная элегантность.

Если есть интерес, было бы неплохо добавить необязательные теги, но это, конечно, не обязательно. По моему опыту, 80% проблем решаются, когда и если разработчики могут вводить проблемы в процессе. Обработка бэклогов - это дисциплина, дисциплина, которой можно будет управлять позже.

Быстрое спасибо Trello npm module. Похоже, работа в стадии разработки, но определенно полезно и лучше, чем создание и авторизация моих собственных HTTP-запросов.

В общем, менее двух часов усилий и простота использования на вашем пути. Как я уже упоминал ранее, очень полезно добавить узел #! / Usr / bin / env в заголовок файла, чтобы он работал как обычный сценарий оболочки (т.е. ./add-trello- проблема).

Если вам нравится что-то делать, я был бы признателен за ваши идеи сценария. Оставьте мне комментарий, спасибо за чтение.

* Дополнительную информацию об async / await можно найти в этом учебнике от Джамунда Фергюсона.