Днес беше празничен ден. Бях повален с температура, възпалено гърло и проблеми с корема от най-новия вирус, който обикаляше децата ми в „Лагерите за обмен на вируси“, … съжалявам, имам предвид училищата. Нямам представа дали някой друг говори за дни на угар, но има този израз за оставяне на полето да остане на угар. При редуването на културите засаждате различни култури във всяко поле всяка година и след това не засаждайте нищо на всеки няколко години, за да избегнете изтощаването на почвата. Стигнах до израза по време на докторската си степен. за да отбележа онези дни, в които изглежда не успях да свърша нищо продуктивно - обикновено защото бях болен или по-често, леко махмурлук.

Така че бях прекарал по-голямата част от сутринта в сън и нямах сили да сдвоявам, свърших малко администраторска работа — наваксване на няколко отдавна нерешени неща — и по-късно през деня успях да прекарам малко време в кодиране node/express/mongo, за да видя дали мога да настроя нещо малко, което може да формира основата на бота за асинхронно гласуване или агента за планиране на покер, за който мислехме. Нека обясня, планирането на покер е този процес на едновременно гласуване на сложността/трудността на дадена задача в среща. Така че задачата може да е да добавите нов отчет с данни към страницата със статистика и може да имате 5 души и те биха направили като камък, хартия, ножици с пръстите си, освен с числа, напр. 1, 2 или 3 и след това всички петима души ще покажат пръстите си едновременно и ще получите гласове за да речем 1, 2, 2, 2, 3 и след това можете да попитате хората, гласуващи срещу мнозинството, защо мислех, че нещата са повече или по-малко сложни и след известно ограничено обсъждане може да прегласувате или отклоняващите се ще се съгласят да съвпадат с мнозинството.

След това стойността, генерирана от това гласуване, може да бъде прикрепена към билет, свързан с проблем, и тогава това дава на някой, който ще започне тази задача, представа какво поема. Той също така позволява инструменти като Pivotal Tracker да помогнат с оценката кога ще бъдат изпълнени различни задачи. Друга централна част от гласуването е, че то разкрива разликите в предположенията между членовете на екипа и предоставя структуриран начин за сравнително бързо достигане до дъното. Правим онлайн синхронно гласуване в проекти на AgileVentures от дълго време. Склонни сме да използваме hangout, за да координираме срещата и след това да направим едновременното гласуване в чата. Често можете да видите следите от това в различните стаи за чат на AgileVentures в Slack, особено след като разбрахме, че чатът в Google Hangout не продължава.

Превъртете напред, има някои проекти, при които е трудно да се съберат хора по едно и също време, дори в отдалечен hangout. Също така гласуването за множество задачи, една след друга, може да бъде донякъде досадно, така че сега експериментираме с асинхронно дистанционно гласуване и през последните две седмици играх ролята на хипотетичен чатбот за LocalSupport и Проекти на WebSiteOne, където публикувам нещо подобно в съответния канал на Slack:

@channel new async vote on "make doit mentions in map key be hyperlinks" https://www.pivotaltracker.com/story/show/122461371, discuss here, or in ticket and then DM me your vote of 1 2 or 3

и след това ще получа индивидуални DM от разработчици като така:

Vote for https://www.pivotaltracker.com/story/show/122461371:   1

или понякога с малко обяснение

https://www.pivotaltracker.com/n/projects/742821/stories/122461371 seems like a 2, because it requires a bit of front-end and a bit of back-end, which means testing on both those fronts too
i’m not sure who wants to do this story, but my coworker seems interested in pairing with me on it

or

I guess the hyperlinks issue for "do-it" is not your run of the mill "link_to" type. It will involve JS so if that s the case I say 3.

и може да има дискусия в самия билет, но когато получа гласове, ще публикувам в канала на Slack така:

@here we have 2 votes for "make doit mentions in map key be hyperlinks" https://www.pivotaltracker.com/n/projects/742821/stories/122461371

Може също да подканя канала, ако не получаваме никакви актуализации известно време:

@channel we have two votes on https://www.pivotaltracker.com/story/show/122461371, we need one more vote to move forward - discuss here, or in ticket and then DM me your vote of 1 2 or 3

След като събера достатъчен брой гласове (в момента 3), публикувам резултатите в канала:

@channel vote on https://www.pivotaltracker.com/n/projects/742821/stories/122461371 "make doit mentions in map key be hyperlinks" complete - @decareano 3, @johnnymo87 2, @marouen 1 - I'm just imagining that this is just a simple `link_to` or am I missing something - @johnnymo87 @decareano any thoughts on why this is more complex than a 1?

и след това имаме дискусия в канала Slack (или може да е в билета):

@tansaku, did you read my comment in my vote? I had the same thought as @marouen but in reverse. Anyway, if it's a link_to my vote is 1.
@decareano thanks for your vote - we now have two votes of 1 for https://www.pivotaltracker.com/story/show/122461371 "make doit mentions in map key be hyperlinks" and a 2 from @johnnymo87 - @johnnymo87 happy to revise to 1 or is there some aspect of this we've missed?
oh, i thought that part of the UI was done in js. But I looked it up, and it’s not. I’ll revise to a 1, @tansaku

След това задавам оценката на билета и започваме отново:

okay @here so that story is unanimous as a 1
@channel we have a new async vote on https://www.pivotaltracker.com/story/show/131062023 "Refactor Build marker service" - please DM me 1 (simple), 2 (medium) or 3 (hard) - discussion in ticket or here as you prefer :slightly_smiling_face:

Така че това беше малко тривиален пример, но всъщност това гласуване разкри някои погрешни схващания относно въпросния билет. Мисля, че тези асинхронни гласувания са доста добри за онези проекти, при които членовете на екипа не могат да правят синхронни терени. Има доста логистични разходи за мен, докато го управлявам (което може да се автоматизира в бот), а също така, тъй като аз съм „ботът“, е малко нечестно да гласувам. Ако всичко това беше автоматизирано, аз също можех да гласувам и нещата можеха да се развиват малко по-бързо. Въпреки че, разбира се, трябва да вземем предвид времето, необходимо за автоматизиране, и дали автоматизирането би изхвърлило бебето заедно с водата за баня.

Други вече изразиха загриженост, че асинхронният характер на гласуването ще премахне критичната част от дискусиите, която се случва в синхронните срещи. Може да губим нещо, но като пуснем тази демонстрация с мен като бот, със сигурност ще продължим някакво ниво на дискусия. Друго притеснение е, че преминавайки към бот, хората няма да бъдат толкова изразителни за бота, колкото са за мен, като бот. Нещо като човек. Едно решение за това може да бъде да облечете бота като мен, което правим за пингване на известия за hangout, където ботът приема логото на всеки, който стартира hangout.

За съжаление мисля, че Slack все още не поддържа DM-ing с бот. Поне можете да изпратите DM, но след това всички отговори отиват в канала на слабия бот - не можете да продължите разговора един на един с бот. Както и да е, процесът също ми позволи да настроя „интерфейса“, тъй като чатовете с разработчици повдигнаха няколко точки:

  1. Винаги включвайте връзка към билета във всяка публикация
  2. Винаги включвайте заглавието на билета във всяка публикация
  3. Полезно е да включите инструкции за новодошли като: „моля, пишете ми DM 1 (просто), 2 (средно) или 3 (трудно) — дискусия в тикета или тук, както предпочитате“

И потвърдих, че функционалността намира известна полза. И така, имайки предвид всичко това, започнах да разглеждам тестово шофиране на приложение Node/Express. Почти съм сигурен, че мога да напиша нещо по-бързо в Ruby/Sinatra, но има и тази идея, че трябва да диверсифицираме приложенията, които използваме в AgileVentures, за да се харесаме на по-широк кръг от разработчици. Освен това след нашия опит с AgileBot, искам да видя дали след премахването на Hubot и CoffeeScript обикновеното приложение Node/Express ще бъде по-управляемо.

Вече използвах TDD’s Node/Express и преди, но мина около година и искам да съм запознат с най-добрите практики, така че се оглеждах за уроци и неща. Намерих:

Интересното е, че този на Heroku беше привлекателен, защото качването на нещо в стабилна крайна точка е критично, но не беше TDDd, така че избрах последното, което в крайна сметка успях, но беше малко разочароващо, защото всъщност не беше TDD. Имаше тестове, да, но функционалността не беше тествана. Сега забелязвам, че SemaphoreCI плаща по $200 на хората да пишат уроци... В полза на автора, те направиха връзка към пълния код на https://github.com/rajzshkr/todoapi, което ми позволи да получа нещата работят. Самият урок имаше недостатъци по следните точки:

  1. различен код от работния пример
  2. тестове, въведени след кода, който са тествали, т.е. не TDD
  3. битове код в урока, които не са свързани с определени файлове

Като част от работата по урока наистина инсталирах и стартирах mongodb, открих някои „трикове за експресно отстраняване на грешки“ и прекарах по-голямата част от времето си в работа, че приставката Postman Chrome, която използвах, за да тествам крайната точка на POST, трябваше да осигури необработен тялото на публикацията, което ще се обработва от това приложение; form-data и x-www-form-urlencoded опции, които просто се показват като празно тяло. Разочароващо, последният елемент изгори времето, което може би използвах за внедряване в Heroku. Така че до края гледах на по-очертана структура на приложението, отколкото бях виждал преди това с express, включваща модели от Mongoose (модул на MongoDB Schema), и контролери и рутер, всички в отделни файлове. По ирония на съдбата, не знам колко широко е разпространено това конкретно оформление, въпреки че ако познавам екосистемата на възела, може все още да няма приет стандарт.

Самият урок всъщност не предоставя крайни тестове, а само единични тестове. Репото показа тест на контролера и тест от край до край (те го нарекоха интеграция), използвайки модула за супертест. Намерих някои други публикации в блогове за това и за алтернативен тестов модул, наречен hippie:

Мислех си, че може би оттам трябваше да започна с слаб бот и намерих урок за това:

но надхвърлихме ограниченията си за интеграция за нашата AV застой и започнах да мисля, че вместо да се тревожа за техническите подробности, трябва да накарам двигателя за бота да работи, независимо от който и да е от интерфейсите (отново InsideOut), и така Приключих с написването на някои истории за системата, които вече разбирате, защото първата част на този блог ги излага, но в случай, че се интересувате, ето моите обобщени бележки от хакването през деня:

планиране на покер бот

/bot vote # незадължителен URL адрес на билет

–› обявява — имаме асинхронно гласуване на url адрес на билет (първо от репо, ако не е посочено) „заглавие“, моля, пишете ми DM 1 (просто), 2 (средно) или 3 (трудно) — дискусия в билета или тук като предпочиташ :лекоусмихнатолице:

тогава трябва да можете да получавате информация от хора — отпуснати DM? или изложете уеб интерфейс (може ли да реагирате там?) и след това публикувайте обратно в slack...

Цялото нещо може да бъде безпроблемно като начало, за да се намали сложността?

хората гласуват за билети

така че имаме AsyncVote, който се състои от билет със заглавие и url, и след това има брой гласове, които имат стойност и идват от физическо лице и може да имат обяснение, и когато броят на гласовете достигат зададена стойност (напр. 3), след което се разкриват пълните резултати и стойността на билета се задава, ако има съгласие или ние подтикваме към още дискусии....

Така че се замислих дали просто да направя TDD нещо в node, което ще работи на командния ред, и след това да изградя някои различни интерфейси върху него? Бих искал да имам време да направя както възел/експрес, така и версия на Ruby/Sinatra, за да покажа пълните паралели и/или липсата им между двете ... да видим кога ще имам още един свободен ден :-)

СВЪРЗАН КОД:

Първоначално публикувано в http://nonprofits.agileventures.org/2016/09/28/fallow-day/