Steven
Steven6 min läsning

Lugn programvara: att döda en flimrande växlare och lära chatten säga vilket läge den är i

Två små GeekBye-releaser, inga rubrikfunktioner — bara en inställningsväxlare som slutade flimra och en chattassistent som äntligen berättar om den svarade i mötesläge eller kodningsläge. Så mycket kostar "lugn programvara" i verkligheten, en detalj i taget.

Produkt
Design
Utveckling
GeekBye-releaser
Lugn programvara: att döda en flimrande växlare och lära chatten säga vilket läge den är i

Inte varje release är en krigshistoria. Vissa är bara en lista med små, nästan osynliga saker som tyst var fel — sådant som inte kraschar något men får en app att kännas lite opålitlig, lite nervös, lite inte-din. GeekBye v2.0.3 och v2.0.5 var två av dem. Inga nya funktioner. Bara lugn.

"Lugn programvara" låter som en känsla. Det är egentligen en hög specifika beslut. Här är tre av dem.

En växlare som inte kunde bestämma sig

Det fanns en inställningsväxlare — den som styr ljudåterhämtning — som flimrade när du klickade på den. Tryck på den för att slå på, och en bråkdel av en sekund visade den , sedan snäppte den tillbaka till av, och lade sig sedan till ro. En pytteliten visuell stamning, men ögat fångar den, och den läses som appen är inte säker på vad den gör.

Orsaken är en klassisk gränssnittskapplöpning som kallas en optimistisk uppdatering. När du klickar på en växlare har appen två val: vänta tills inställningen faktiskt sparas och sedan uppdatera reglaget (korrekt, men känns segt), eller slå om reglaget omedelbart och spara i bakgrunden (känns omedelbart). GeekBye gjorde det senare — slog om direkt — men den läste också tillbaka det sparade värdet när det kom. Så sekvensen var: du klickar, reglaget slår optimistiskt på, det verkliga sparade värdet anländer ett ögonblick senare, och under en bildruta var de två oense och reglaget studsade synligt.

Fixen är att få det optimistiska värdet och det bekräftade värdet att stämma rent — reglaget förbinder sig till det läge du valde och slutar tvivla på sig självt när sparningen bekräftas. Vid sidan av det gjorde v2.0.3 en oglamorös textgenomgång: beskrivningen av ljudåterhämtning kortades ned för att linjera med sina systerrader, och inställningsformuleringarna gjordes mer mänskliga. Inget av detta är en funktion. Allt är skillnaden mellan en inställningspanel som känns konstruerad och en som känns omsorgsfullt finslipad.

En rundtur som inte ville gå

Rundturer för nya användare är användbara exakt en gång. Problemet är den där engångsheten: efter att du sett den blir ett introduktionsöverlägg som du inte kan stänga en röra som signalerar den här appen tror fortfarande att du är ny. v2.0.3 fixade båda ändarna — produktrundturen kan nu döljas, och om du faktiskt vill ha tillbaka den finns en Spela om rundtur-knapp. Visa den när den hjälper, gå ur vägen när den inte gör det, och låt användaren kalla fram den på sina egna villkor. Att respektera att användaren inte längre är ny är sin egen lilla form av lugn.

Assistenten som inte ville säga hur den tänkte

Det här är den som verkligen spelade roll, och den hänger ihop med ett djupare problem vi hade jagat.

GeekByes assistent svarar olika beroende på sammanhang. På ett möte ska "vad tycker du om detta?" få ett samtalande, mötesmedvetet svar. I en kodningssession ska samma ord få ett tekniskt. Så backend kör frågan genom rätt ram — kalla det mötesläge eller kodningsläge — och den inramningen förändrar verkligen svaret du får.

Problemet: appen berättade aldrig vilket läge som svarade. Så när assistenten gav dig ett kodningsdoftande svar på en samtalande fråga — eller svarade på en kodfråga som om du chattade — såg det ut som att AI:n helt enkelt hade fel. Den hade inte fel; den var i det andra läget, och du hade inget sätt att se det. Ett dolt tillstånd fick korrekt beteende att se trasigt ut. (Själva läges-logiken är ett större arbete — orkestratorn som avgör hur icke-kodningsfrågor ska besvaras under en kodningssession — men inget av det är till nytta för dig om du inte kan se beslutet den fattade.)

v2.0.5 lade till ett skrivskyddat läges-chip i chatten: en liten etikett som visar om assistenten svarade i mötesläge eller kodningsläge. Skrivskyddat är hela poängen — det är inte en kontroll du ställer in, det är ett fönster in i ett beslut systemet redan fattat. Du slutar gissa varför ett svar känns fel; du kan se ramen det kom ifrån.

Detaljen som gör chippet ärligt

Här är det tekniska valet värt att föra vidare, för det är den sortens sak som skiljer en påklistrad indikator från en pålitlig.

Lägesinformationen kommer från backend som en del av det strömmade svaret — en liten mode-bildruta i strömmen av serverskickade händelser. Men en äldre klient som föregår den här funktionen skulle inte veta vad en mode-bildruta är; i bästa fall ignorerar den den, i värsta fall renderar den något förvanskat. Så klienten tillkännager sin förmåga: den skickar ett förfrågningshuvud som säger jag vet hur man visar ett läges-chip, och backend sänder bara ut mode-bildrutan till klienter som skickade det. Gamla klienter tar aldrig emot en signal de inte kan hantera; nya klienter får exakt den bildruta de bad om.

Det är en handskakning på ett enda huvud, och det är skillnaden mellan "vi lade till en funktion" och "vi lade till en funktion utan att ha sönder någon som inte har uppdaterat än." Samma granskningsomgång stramade upp resten av beteendet: chippet rensar sig självt vid återställning och när samtalskontexten ändras (en föråldrad lägesetikett är sin egen lilla lögn), och det visas bara i chattvyn där det hör hemma.

Vad två "ingen funktion"-releaser lärde oss

  1. Nervositet är en förtroendesignal. En flimrande växlare, ett studsande reglage, en etikett som dröjer sig kvar en bildruta för länge — inget av dem är en bugg i kraschbemärkelsen, men var och en viskar den här appen har inte riktigt kontroll. Lugn är frånvaron av de viskningarna, och du förtjänar det ett kapplöpningstillstånd i taget.
  2. Ett dolt läge får korrekt beteende att se ut som en bugg. Assistenten gjorde rätt sak och fick skulden för det, enbart för att användaren inte kunde se ramen. När ditt system fattar ett osynligt beslut som ändrar utdatan, visa beslutet — ett skrivskyddat chip är ofta hela fixen.
  3. Nya funktioner ska vara osynliga för klienter som inte kan använda dem. Förmåge-huvud-handskakningen betyder att lägessignalen bara når klienter som kan rendera den. Bakåtkompatibilitet är inte en versionskontroll som klistras på i efterhand; det är en klient som säger vad den förstår och en server som respekterar svaret.

Det här är releaserna ingen skriver changelog-rubriker om, och de är en stor del av varför GeekBye v2 känns som den gör. För releasen detta lugn byggdes på, se vad en version 2 faktiskt kräver (v2.0.0). För tillförlitlighetsarbetet vid sidan av den, dagen vår app DDoS:ade sig själv (v2.0.1) och varför ditt AI-anteckningsverktyg slutar spela in mitt i mötet (v2.0.9).

Relaterade artiklar

En CSS-variabel, fem granskningsrundor och en Swift-verktygskedja som ljög
Steven
Steven6 min läsning

En CSS-variabel, fem granskningsrundor och en Swift-verktygskedja som ljög

GeekBye v2.0.7 gjorde hela overlayn justerbart genomskinlig — vilket låter som en enda rad CSS men absolut inte var det. Den verkliga historien är vad kodgranskningen fångade: två ytor som vägrade tona bort, en inspelningsrad som såg fel ut vid samma opacitet, och en kompilerad binär som fladdrade 672 byte fram och tillbaka eftersom vår egen dokumentation gav en granskare fel Swift-version.

Utveckling
Design
Bygge
Anatomin bakom att skeppa programvara till perfektion: hur kodgranskning fångade det testerna inte kunde
Steven
Steven6 min läsning

Anatomin bakom att skeppa programvara till perfektion: hur kodgranskning fångade det testerna inte kunde

Genom hela GeekBye v2-serien händer samma sak om och om igen: en fix klarar varje test på utvecklarens maskin, och sedan bevisar kodgranskningen att den skulle ha misslyckats för nästan alla. Det här är arbetsflödet bakom nio releaser — granskningsporten, fånga-felen-först och disciplinen att testa-innan-skepp som förvandlar "det fungerar för mig" till "det fungerar".

Utveckling
Process
Kodgranskning
Din Mac-app beviljar mikrofonåtkomst — och glömmer den sedan vid varje start
Steven
Steven6 min läsning

Din Mac-app beviljar mikrofonåtkomst — och glömmer den sedan vid varje start

GeekBye bad om mikrofonbehörighet, du beviljade den, och den fungerade. Nästa start: borta. Och appen dök aldrig ens upp i Systeminställningar → Mikrofon. Boven var en säkerhetsfunktion i macOS som i tysthet körde appen från en sökväg som försvinner — här är diagnosen och fixen som bara kräver en dialogruta.

macOS
Behörigheter
Utveckling