Kuidas luua GitHubi probleeme 5 korda kiiremini
GitHubi probleemid on suurepärased, et jälgida uusi funktsioone või vigu, kes on määratud, neid kategoriseerida, projektidesse lisada ja nii edasi. Samal ajal on nende loomine üsna aeglane ja nende hulga loomine võtab liiga palju aega.
Üks valupunkte, mida ma GitHubi probleemide puhul tööl näen, on see, et nende loomine on tülikas, eriti neile, kes ei ole arendajad ega disainerid, näiteks juhid või testijad, kes soovivad veast teatada ilma nende loomise protsessi läbimata. GitHubis.
Mõni aeg tagasi kirjutasin rakendusest, mida kirjutasin GitHubi probleemide loomise kiirendamiseks. Ma tegelikult ehitasin selle rakenduse, kuid unustasin sellest siia kirjutada, nii et siin on õige ajaveebi postitus. Selles postituses näeme:
- GitHubi probleemide partii kirjutamine lihttekstiga
- Rakenduse taga olev tehniline virn
- Rohkem ideid probleemide loomise parandamiseks
Miks rakendus GitHubi probleemide kiiremaks loomiseks?
GitHubi kasutajaliides on tavaliselt probleemi tekitamiseks sobiv. Või kaks. Ja see sobib tehnoloogilistele inimestele, näiteks arendajatele või disaineritele. Kuid meie ettevõttes Reconnect palume mõnikord pärast uue funktsiooni väljatöötamist oma mittetehnilistel töötajatel seda testida. Ja see toimib suurepäraselt, sest tavaliselt leiavad nad mõned probleemid. Kuid GitHubi probleemide kasutajaliidese hüppamine on neile väga kulukas. See on veelgi tülikam, kui nad peavad looma rohkem kui ühe väljaande ja tõenäoliselt erinevates hoidlates.
Kui me kvantifitseerime, mitu korda me keskendume GitHubi probleemide loomisele pärast seda, kui oleme jõudnud lehele, et tekitada probleem hoidlas, kus me neid luua tahame, oleks see enam-vähem selline:
- sisestage pealkiri
- kirjelduse sisestamiseks liikuge probleemi tekstikasti
- minge külgribale, et probleem kellelegi määrata
- sildi lisamiseks liikuge külgribal plokki Sildid
- minge ja klõpsake probleemi tegelikuks loomiseks nuppu
See on 5 korda, kui me suuname oma tähelepanu ühelt alalt teisele! Liiga palju tähelepanu nihkumist ülesande jaoks, mis on sisuliselt kirjutamine, ja liiga palju aega keskendumisele. Ja mis siis, kui peate kirjutama probleemi teise hoidlasse? Peate navigeerima sellesse hoidlasse uuel vahekaardil või praeguses ja nii läheb rohkem aega.
Niisiis, kuidas saate GitHubi probleeme hõlpsamini ja kiiremini luua? Kas poleks lihtsam, kui saaksime seda teha ühele kohale keskendudes, ilma et peaksime mitu korda tähelepanu pöörama?
GitHubi probleemide partii kirjutamine lihttekstiga
Kirjutamine on seadmetes üks elementaarsemaid oskusi, elementaarsem kui isegi puudutusliigutused. Kuna need on puutetundlikele seadmetele omased, peate teistel kasutama hiirt või puuteplaati. Kuid kirjutamine on tavaliselt alati sama. Ja GitHubi probleemid on tekst, nii et miks mitte kasutada nende loomiseks teksti ilma klaviatuurilt lahkumata?
See rakendus teeb täpselt seda: https://fast-issues.herokuapp.com/
Volitate selle GitHubi rakenduse ja võite alustada probleemide kirjutamist kõigis oma hoidlates. Peate lihtsalt valima hoidla, kuhu soovite probleemi luua, ja hakkama kirjutama mitu probleemi, üks igale reale.
Ja see toetab pealkirja ja kirjelduse kirjutamist, selle määramist ja märgistamist. See nõuab ainult väljaande pealkirja. Ülejäänu on valikuline. Peate lihtsalt järgima teatud tava:
- pealkiri on esikohal
- seejärel eraldab määrajaid torumärk. Valisin selle selliseks, sest vähemalt vajate probleemi ja kedagi, kes sellega tegeleks
- teine torumärk eraldab probleemi kirjelduse. Sellel võib olla mis tahes pikkus, kuid sellel ei tohi olla reavahetusi, kuna see käivitaks uue väljaande
- Kolmas torumärk eraldab sildid
See toetab mitut määrajat ja silti, eraldades need komadega. Nii et põhimõtteliselt:
This is the title | username1, username2 | This is the issue description, as long as you want it but without line breaks. | Label 1, Label 2<br>This is another issue | username3 | And another issue description | Bug
Kui see on tehtud, tuleb klõpsata nupul Mine! nuppu ja see tekitab kõik probleemid. Igaüks neist on teie autor. Hiljem saate neid redigeerida, et lisada pilte või videoid, meeme või kõike.
Kui teil on vaja teises hoidlas rohkem probleeme luua, valige see rippmenüüst uuesti ja alustage nende probleemide kirjutamist. Pole enam lehtede vahel hüppamist!
Rakenduse taga olev tehniline virn
Selle rakenduse hoidla asub aadressil https://github.com/eliorivero/fast-issues
Tehniline virn on eriti lihtne ja põhineb täielikult JavaScriptil :
- Reactiga ehitatud esiosa
- Node.js -iga ehitatud taustaprogramm
- kasutab serverina Expressi
- ja Octokit REST teeki, mis töötab GitHubi API-ga
Üks asi, mida meeles pidada, on see, et me ei taha ületada GitHub Issues API lubatud päringute limiiti. Nad soovitavad lasta taotluste vahel mööduda vähemalt üks sekund, nii et peatasin täitmise 1,5 sekundiks iga väljaande loomise vahel.
Alates esialgsest prototüübist kuni lõpliku versioonini muutsin selle GitHubi rakendusest OAuthi rakenduseks. Põhjus on selles, et viimane võimaldab teil luua probleeme ja esineda autorina.
Rohkem ideid probleemide loomise parandamiseks
Näitasin seda sõbrale ja ta ütles mulle, et tal oli idee luua Chrome’i laiendus, et teha veast ekraanipilt, lisada sellele märkused ja esitada see GitHubi probleemina. Minu arvates oli see suurepärane idee, nii et otsisin võimalust ekraanipildi tegemiseks, kuid Reacti rakenduses leidsin kiiresti html2canvase, mis võimaldab teha ekraanipilte ja salvestada need PNG-failidena.
Millegi sellise kombineerimine minu tööriistaga probleemide tekitamiseks oleks hea lahendus, mis võiks olla saadaval Reacti rakenduses selle arendus- või lavastustsükli ajal. Igaüks, kes testib rakendust, võib käivitada probleemide aruandluspaneeli ja esitada GitHubi probleemi.
Ainus probleem sellega praegu on see, et GitHubi API ei luba pilte üles laadida, nii et need peaksid olema kusagil mujal ja sellesse tööriista sisestama selle asukoha link, kuid see on kindlasti hea edasiminek.
Nii et jällegi on rakendus aadressil https://fast-issues.herokuapp.com/ ja kui te seda lõpuks kasutate, andke mulle sellest kommentaarides teada.