Steven
Steven5 min lukuaika

Yksi CSS-muuttuja, viisi katselmuskierrosta ja Swift-työkaluketju joka valehteli

GeekBye v2.0.7 teki koko overlaystä säädettävän läpikuultavan — mikä kuulostaa yhden rivin CSS-muutokselta ja ei todellakaan ollut sitä. Todellinen tarina on siinä, mitä koodikatselmus nappasi: kaksi pintaa jotka kieltäytyivät haalistumasta, tallennuspalkki joka näytti väärältä samalla peittävyydellä, ja käännetty binääri joka heilahti 672 tavua koska omat dokumenttimme kertoivat katselmoijalle väärän Swift-version.

Ohjelmistokehitys
Suunnittelu
Build
GeekBye-julkaisut
Yksi CSS-muuttuja, viisi katselmuskierrosta ja Swift-työkaluketju joka valehteli

"Tee overlaystä läpikuultava" on sellainen tehtävä, joka kuulostaa liukusäätimeltä ja CSS:n opacity-ominaisuudelta. GeekBye v2.0.7 toi täsmälleen tuon käyttäjälle näkyvän lopputuloksen — yhden säädettävän "light moden", jonka avulla näet assistentin paneelien läpi sen mitä ikinä niiden takana onkin. Mutta tämän julkaisun kiinnostavin osa ei ole ominaisuus. Se on ne viisi katselmuskierrosta, jotka tarvittiin sen saamiseksi oikein, sekä sotatarina käännetystä binääristä, joka muutti kokoaan koska oma dokumentaatiomme valehteli katselmoijalle.

Oikea tapa tehdä koko käyttöliittymästä läpikuultava

Naiivi versio tästä on ripotella peittävyysarvo jokaiseen paneelikomponenttiin ja pitää työtä valmiina. Se on ylläpitoansa: kymmenen kovakoodattua arvoa, jotka ajautuvat erilleen sillä hetkellä kun joku koskee yhteen niistä.

Sen sijaan v2.0.7 käyttää yhtä jaettua CSS-apuluokkaa ja pintakohtaista tokenia. On yksi overlay-surface-luokka, joka laskee paneelin taustan kahdesta custom propertysta: pohja_peittävyydestä, jonka kukin pinta ilmoittaa itselleen (hallintapalkki, chat, transkriptikuplat, koodilohkot ja niin edelleen valitsevat kukin omansa), sekä globaalista _alpha-kertoimesta, joka kulkee overlayn juuressa ja edustaa käyttäjän liukusäätimen asetusta. Jokainen pinta lukee saman kertoimen; kukin säilyttää oman luonteensa. Ratkaisevaa on, että vain paneelin tausta skaalautuu — teksti, ikonit ja backdrop-blur pysyvät täysin renderöityinä, joten "läpikuultava" ei koskaan tarkoita "lukukelvotonta".

Kaksi tuon ratkaisun päätöstä ansaitsevat maininnan, koska ne ovat ero auttavan ominaisuuden ja tukipyyntöjä synnyttävän ominaisuuden välillä:

  • Oletus on täysin peittävä. Peittävyysasetus julkaistaan arvolla 100 % — tyhjä toimenpide. Kenenkään overlay ei yhtäkkiä muuttunut läpinäkyväksi päivityksen yhteydessä; läpikuultavuus on siellä kun tartut siihen ja näkymätön siihen asti.
  • Asetus validoidaan puolustavasti. Minimille, maksimille, oletukselle ja askeleelle on yksi totuudenlähde, sekä normalisoija joka suojaa tyhjän/puuttuvan tapauksen. Sillä on merkitystä JavaScriptin jalkaanampuma-aseen takia: Number(null) on 0, joten puuttuva asetus naiivisti pakotettuna napsauttaisi overlayn sen läpinäkyvimpään tilaan oletuksensa sijaan. Normalisoija nappaa sen ennen kuin se pääsee tapahtumaan.

Vedä liukusäädintä ja koko overlay värjäytyy uudelleen livenä, kesken tallennuksen, koska jokainen pinta on tilannut saman asetuksen. Ei uudelleenkäynnistystä, ei uudelleenlatausta.

Mitä katselmus nappasi (ja mitä yhden näytön testi ei koskaan olisi napannut)

Tässä kohtaa "yksi CSS-muuttuja" lakkasi olemasta yksinkertainen. Katselmuksessa nousi pintaan kolme virhettä, ja kaksi niistä on sama oppitunti eri hatussa.

Paneeli joka ei haalistunut. Näppäinoikoteiden overlay pysyi itsepintaisesti kiinteänä samalla kun kaikki muu muuttui läpikuultavaksi. Syy: se renderöityy peittävyysmuuttujaa kantavan DOM-alipuun ulkopuolella, joten se ei koskaan perinyt overlayn juuresta valuvaa arvoa. CSS custom propertyt periytyvät DOM-puun läpi — ja jos solmu ei ole todellisuudessa muuttujan asettamispaikan jälkeläinen, se saa hiljaa tyhjää. Korjaus oli asettaa muuttuja paikallisesti myös siihen paneeliin.

Hover-sävy joka katosi. Fn/Assist-napit menettivät syaaninsä hover-hehkun. Läpikuultavuusapuluokka asetti taustan !importantilla (sen on voitettava pintaoletukset), ja se jyräsi saman elementin hover:-taustasävyn. Spesifisyystörmäys. Korjaus oli tehdä hover-sävystä yhtä painokas, jotta se voisi voittaa takaisin hoverin aikana.

Molemmat näistä ovat sama pohjimmainen totuus: CSS-muuttujan kaskadi on todellinen oikeellisuuden raja, ei tyyliyksityiskohta. Periytyminen ja spesifisyys ratkaisevat, päätyykö arvosi ylipäätään elementille, eikä kumpikaan näy kuvakaappauksessa ennen kuin se on väärin.

Sama peittävyys, eri ulkonäkö. Kaikkein hienovaraisin: tallennuspalkki ja lepopalkki oli asetettu täsmälleen samaan pohjapeittävyyteen, ja silti ne näyttivät selvästi erilaisilta. Miksi? Tallennuspilleri käytti raskaampaa backdrop-bluria, ja voimakas sumeus tumman taustan päällä keskiarvottuu tummempaan tulokseen — joten sama alpha tuotti eri ulkonäön. Sillä oli myös himmeä reuna siinä missä lepopalkilla oli kirkas gradienttirenkaan reuna. Korjaus sovitti sumeustason ja renkaan yhteen. Oppi jäi mieleen: sama alpha ei ole sama ulkonäkö sen jälkeen kun sumeus astuu kuvaan. Läpikuultavuus on vuorovaikuttavien efektien järjestelmä, ei yksi ainoa luku.

Binääri joka muutti kokoaan koska dokumentit valehtelivat

Nyt se sotatarina, ja se on suosikkilajiani — sellainen jossa työkalut ja dokumentit ovat eri mieltä ja huolellinen katselmoija jää ristituleen.

GeekBye toimittaa muutamia esikäännettyjä Swift-binäärejä (natiivit apurit esimerkiksi kokousten tunnistukseen). Koska käännetty binääri on committoitu repoon, jokaisen kehittäjän on käännettävä se täsmälleen samalla Swift-versiolla — eri työkaluketjut tuottavat eri tavut identtisestä lähdekoodista, ja se tarkoittaisi haamu-git-konfliktia joka kerta kun joku kääntää uudelleen. Niinpä on skripti, joka valvoo yhtä tiettyä versiota: Swift 6.3.x, tarkistettuna käännösaikana.

Tämän julkaisun katselmuksen aikana katselmoija huomautti, että eräs binääri pitäisi kääntää uudelleen vastaamaan "repon määräämää työkaluketjua". Kehittäjä teki juuri niin — ja binäärin koko muuttui 89,184 tavusta 88,512 tavuun. Commit-viesti jopa sanoi, että kyseessä oli "tavuvakaan tulosteen palauttaminen" kääntämällä uudelleen Swift 6.2.1:llä, "repon määräämällä työkaluketjulla".

Paitsi että 6.2.1 oli väärä versio. Käännösvalvontaskripti vaati 6.3.x:ää. Ongelma oli, että _proosa_dokumentaatio — README ja avustajan opas — sanoi yhä 6.2.1 parissa kohdassa. Niinpä tunnollinen katselmoija ja tunnollinen kehittäjä, molemmat yrittäen tehdä oikein, seurasivat dokumentteja suoraan committamaan täsmälleen sen artefaktin, jonka hylkäämiseksi valvontaskripti on olemassa. 6.2.1-binääri 6.3.x-reposssa on juuri se ajautuma, joka rikkoisi jokaisen muun kehittäjän puhtaan uudelleenkäännöksen.

Seuraava commit korjasi sen — ja korjaus on tässä pointti. Se ei pelkästään kääntänyt binääriä takaisin 6.3.x-muotoonsa (koko palautui 89,184:ään, juuri sinne mistä lähdettiin). Se myös korjasi dokumenttien vanhentuneet "6.2.1"-viittaukset niin ettei ansaa voisi virittää uudelleen. Binääri heilahti 672 tavua ja takaisin kahden commitin yli, eikä todellinen virhe koskaan ollut binääri. Se oli se, että kaksi totuudenlähdettä — valvontaskripti ja kirjoitetut dokumentit — olivat eri mieltä, ja ihminen luotti väärään.

Kolme asiaa jotka tämä julkaisu opetti

  1. CSS-muuttujan kaskadi on oikeellisuuden raja. Kaksi kolmesta katselmusvirheestä palautui muuttujaan joka ei periytynyt ja !importantiin joka jyräsi hover-tilan. Jos arvon on päästävä elementille periytymisen kautta tai voitettava spesifisyyden kautta, se polku on logiikkaa — varmenna se kuin logiikka, ei kuin tyylittely.
  2. Samat parametrit voivat tuottaa eri tuloksia. Tallennuspalkki ja lepopalkki jakoivat peittävyyden ja näyttivät silti erilaisilta, koska eri sumeus muutti lopputuloksen. Kun yhdistät visuaalisen järjestelmän yhteen lukuun, tarkista etteivät muut kunkin pinnan ympärillä olevat muuttujat hiljaa muuta sitä, mitä tuo luku tarkoittaa.
  3. Kun dokumentit ja valvonta ovat eri mieltä, korjaa erimielisyys — älä pelkkää oiretta. Vika ei ollut huono binääri; se oli dokumentti joka nimesi väärän työkaluketjun ja valvontaskripti joka sanoi toisin. Binäärin uudelleenkääntäminen hoitaa oiretta. Jokaisen totuudenlähteen saaminen yksimieliseksi on todellinen korjaus, koska seuraavakin katselmoija luottaa dokumentteihin.

GeekBye v2.0.7 toimitti yhtenäisen läpikuultavuuden, kaikki reunatapaukset katselmoituna ja työkaluketjun dokumentit suoristettuina. Se on viimeinen "hiljaisen käsityön" julkaisuista ennen sitä seurannutta luotettavuussprinttiä. Sen alla olevasta perustuksesta lue mitä versio 2 oikeasti vaatii (v2.0.0); sisarpolituksesta rauhallinen ohjelmisto: välkynnän korjaus ja vastaustilan siru (v2.0.3 + v2.0.5); ja siitä, miten overlay pysyy piilossa puhelun aikana miten pysyä näkymättömänä näytönjaon aikana.

Aiheeseen liittyvät artikkelit

Ohjelmiston toimittaminen täydellisyyteen asti – anatomia: miten koodikatselmointi löysi sen, mitä testit eivät löytäneet
Steven
Steven5 min lukuaika

Ohjelmiston toimittaminen täydellisyyteen asti – anatomia: miten koodikatselmointi löysi sen, mitä testit eivät löytäneet

Koko GeekBye v2 -sarjassa toistuu sama asia: korjaus läpäisee jokaisen testin kehittäjän koneella, ja sitten koodikatselmointi todistaa, että lähes kaikilla muilla se olisi epäonnistunut. Tämä on yhdeksän julkaisun taustalla oleva työnkulku – katselmointiportti, korjaus-ensin-löydöt ja testaa-ennen-toimitusta-kuri, joka muuttaa lauseen "minulla se toimii" lauseeksi "se toimii".

Ohjelmistokehitys
Prosessi
Koodikatselmointi
Mac-sovelluksesi myöntää mikrofonin käytön — ja unohtaa sen joka käynnistyksellä
Steven
Steven5 min lukuaika

Mac-sovelluksesi myöntää mikrofonin käytön — ja unohtaa sen joka käynnistyksellä

GeekBye pyysi mikrofonin käyttöoikeutta, myönsit sen, ja se toimi. Seuraava käynnistys: poissa. Eikä sovellus näkynyt lainkaan kohdassa Järjestelmäasetukset → Mikrofoni. Syyllinen oli macOS:n turvaominaisuus, joka ajoi sovellusta hiljaa polusta, joka katoaa — tässä on diagnoosi ja yhden kehotteen korjaus.

macOS
Käyttöoikeudet
Ohjelmistokehitys
Rauhallinen ohjelmisto: vilkkuvan kytkimen tappaminen ja chatin opettaminen kertomaan, missä tilassa se on
Steven
Steven5 min lukuaika

Rauhallinen ohjelmisto: vilkkuvan kytkimen tappaminen ja chatin opettaminen kertomaan, missä tilassa se on

Kaksi pientä GeekBye-julkaisua, ei näyttäviä ominaisuuksia — vain asetuskytkin, joka lakkasi vilkkumasta, ja chat-avustaja, joka vihdoin kertoo, vastasiko se kokoustilassa vai koodaustilassa. Näin paljon "rauhallinen ohjelmisto" oikeasti maksaa, yksi yksityiskohta kerrallaan.

Tuote
Suunnittelu
Kehitys