tag:dagbog.atilb.dk,2013:/posts A til B dagbog 2019-05-20T08:52:09Z tag:dagbog.atilb.dk,2013:Post/1410811 2019-05-20T08:52:09Z 2019-05-20T08:52:09Z Kosmetiske ændringer

I løbet af sidste uge har jeg lavet forskellige små-ændringer til app'en. Blandt andet ikonet som jeg nævnte tidligere. Den mest synlige ændring er nok at man ikke længere kan vælge til/fra på et google maps kort. Man kan næsten det samme men den nye måde at søge på google maps er blevet lidt mere skrabet. Her er hvordan det så ud før:

Og her er efter:
De minder om hinanden men kortet er væk. Det er fordi google har ændret på deres betingelser så man (det vil sige jeg) nu skal betale for at lave auto-complete og at vise kort. Det er jeg sådan set okay med og den nye udgave laver netop auto-complete som koster en smule. Men at vise kort koster bare uforholdsmæssigt meget så det er jeg blevet nødt til at slå fra.
]]>
tag:dagbog.atilb.dk,2013:Post/1408862 2019-05-14T09:30:15Z 2019-05-14T09:30:15Z Nyt android ikon

En af de ting man opdager når man laver en app er at man til en vis grad skal løbe for at stå stille. Google ændrer f.eks løbende kravene til android apps, de opfinder nye ting og fjerner gamle ting. Nogen gange er det noget man skal forholde sig til og bruge tid på bare for at ens app kan blive ved med at køre. Det er det samme med Apple og iPhone apps.

Det nyeste tiltag er at app ikoner skal fungere anderledes på android. Hvor det i gamle dage bare var et billede i en bestemt størrelse skal det nu være mere kompliceret. Det er for at de kan vise dit ikon med forskellige former, runde, firkantede, rund-oval, hvad ved jeg. Og animere dem på fancy vis. Det ser sådan set meget fedt ud men det kræver at jeg laver et nyt ikon i deres nye format. Så har jeg samtidig benyttet lejligheden til at ændre det en smule. Ikke meget, bare en anelse.

]]>
tag:dagbog.atilb.dk,2013:Post/1406339 2019-05-07T11:32:53Z 2019-05-07T12:00:15Z Brugerstatistik
Denne post er længere og måske mere tør end sædvanligt. Det er fordi den handler om noget jeg synes er virkelig vigtigt så jeg vil gerne være ekstra åben og detaljeret omkring det.

Den sidste uge har jeg arbejdet på fejlrapportering og brugerstatistik. Første gang google fjernede A til B fra play store var det fordi jeg ikke havde slået googles indbyggede fejlrapportering og brugerstatistik fra. Det gjorde jeg dengang, slog begge dele fra, så jeg stod uden begge dele. Dengang skrev jeg mit eget system til fejlrapportering så jeg har helt styr på at der ikke bliver gemt information om brugere derigennem, men jeg lavede ikke noget system til brugerstatistik. Det slog jeg fra uden at have en erstatning fordi jeg først skulle finde ud af hvordan jeg overhovedet gør det.

Brugerstatistik er viden om hvordan brugerne faktisk bruger din app. Hvis man har en fysisk forretning får man automatisk en masse viden om ens kunder: man kan se hvor de går hen, hvilke varer de kigger på, hvilke varer de køber, hvilke spørgsmål de stiller, osv. Den viden er super nyttig. Fordi A til B er en app får jeg i udgangspunktet intet at vide om hvordan folk bruger den. Hvilke funktioner bruger de? Hvordan bruger de dem? Fungerer de godt eller dårligt? Er folk forvirrede eller synes de det er nemt? I udgangspunktet har jeg ingen anelse. Det er der forskellige løsninger på og en af dem er at opsamle statistik om hvad folk gør.

Det der gør brugerstatistik svært, ikke kun for mig men for alle der lave en app, er at det rammer et spændingfelt mellem faktorer der trækker i forskellige retninger. Blandt andet:
  1. hvad brugerne er interesseret i at app udvikleren ved
  2. hvad udvikleren har brug for at vide
  3. hvad udvikleren har lyst til at vide
  4. hvad lovgivningen så kræver af udvikleren

Typisk er brugeren interesseret i at udvikleren ved så lidt som muligt om dem. Omvendt har udvikleren lyst til at vide så meget de overhovedet kan. Samtidig kræver loven at hvis udvikleren gemmer så detaljerede data om brugere at de er personhenførbare så skal brugeren have en masse rettigheder over dem. Så hvad gør man?

De fleste apps og websites "løser" problemet ved i det store hele at ignorere punkt 1 og 4 og gå all in på punkt 2 og 3. At ignorere punkt 1 har ikke de store konsekvenser, antallet af folk der som mig er villige til ikke at bruge en app fordi den overvåger dem er forsvindende lille. Man skulle tro at punkt 4 var sværere at ignorere men det er næsten lige så nemt: det er der første gang du bruger app'en hvor du trykker godkend til at langt juridisk dokument du ikke har læst, og så må de gøre hvad de vil med dine data. (Eller, jeg tror faktisk ikke et øjeblik på at det holder i retten men det gør ingen praktisk forskel så længe ingen trækker virksomheder i retten over det.)

Allerhelst ville jeg slet ikke at samle brugerstatistik men efter det meste af et år uden det må jeg bare indse at det er virkelig svært at leve uden. Det billede jeg har haft i baghovedet da jeg designede det var: nogen steder er der sådan nogen standere ved siden af cykelstierne der tæller hvor mange cyklister der er kørt forbi. Systemet ved ikke at det er mig der er kørt forbi, det eneste den holder styr på er at en eller anden er. Fra et privacy synspunkt er det helt fint med mig og jeg mener ikke det er urimeligt at opsamle den slags. Det jeg har forsøgt er at opsamle statistik i app'en i samme ånd.

Helt konkret den måde det virker er at app'en holder styr på hvilke dage du bruger den, og hvilke uger, måneder, og år. Det er bare internt i app'en, det bliver i første omgang ikke sendt nogen steder. Så f.eks hvis du har brugt app'en torsdag, lørdag, og søndag sidste uge ville den internt, på din telefon, have noteret at du brugte den sådan her:

  1. Mindst en gang på dagen torsdag den 2. maj 2019
  2. Mindst en gang på dagen lørdag den 4. maj 2019
  3. Mindst en gang på dagen søndag den  5. maj 2019
  4. Mindst en gang i ugen der starter 29. april
  5. Mindst en gang i måneden maj 2019
  6. Mindst en gang i året 2019

Hvor mange gange du bruger den, om det er 1 eller 100, er ligemeget.

På et tidspunkt den følgende uge, lad os sige det er den 8. maj i dette tilfælde, kigger app'en igennem det den har noteret og ser om der er noget omkring perioder der er overstået. I så fald sender den en besked med den information tilbage til en server jeg har sat op. I dette tilfælde ville den sende de 5 første elementer på listen fordi den 8. maj er vi forbi de dage og vi er inde i den næste uge og måned. Det sidste element kan ikke sendes endnu fordi vi stadig er i året 2019. Den besked der bliver sendt indeholder intet om hvem det drejer sig om, kun en at en eller anden ukendt bruger derude der brugte app'en i de angivne perioder.

Serveren har en tæller for hver periode og den holder styr på hvor mange har brugt app'en mindst en gang for hver givet dag, uge, måned, osv. Og altså ikke per bruger, men samlet for alle brugere. Når serveren modtager en ny besked løber den igennem og lægger 1 til for hver periode der er nævnt. Det er alt hvad den gemmer, derefter smider den beskeden væk.

Det vil sige at jeg kan ikke følge nogen brugere individuelt det eneste jeg kan se er hvor mange brugere der har været indenfor en given periode. Præcis ligesom cykel tælleren bare holder styr på hvor mange der er cyklet forbi. Med tiden kommer jeg til at tilføje flere ting der bliver noteret, f.eks hvis jeg tilføjer en ny funktion vil jeg gerne vide hvor mange der har brugt den indenfor en given periode. Og jeg kan osse inddele data med noget ekstra information f.eks android version. Det svarer til hvis cykel tælleren ikke kun talte hvor mange der var passeret men delte dem op i to grupper, de der kørte over og de der kørte under 25 km/t. Det giver lidt mere information men princippet er det samme, der bliver aldrig gemt information for specifikke brugere men kun et samlet tal for alle brugere. Brugerne bliver bare underopdelt, f.eks efter android version.

Den måde jeg ser resultaterne er med et værktøj jeg osse lavede sidste uge, wot:

$ wot stats ls
--- start_activity / day ---
2019-05-02 1
2019-05-04 1
2019-05-05 1

--- start_activity / week ---
2019-04-29 1

--- start_activity_by_version:27 / week ---
2019-04-29 1
Det skal læses som: den 2., 4., og 5., maj var der i alt 1 bruger der brugte app'en, det var der osse ugen der startede 29. april (dvs sidste uge). Og sidste uge var der en bruger der havde android 27 installeret der brugte app'en. (Jeg har testet koden på min egen telefon sidste uge så brugeren er i alle tilfælde mig selv.)

For at demonstrere hvor lidt data der bliver gemt er her et kig på de underliggende data som ligger til grund for det værktøjet viser:


Næste gang der kommen en opdatering af køreplanerne, forhåbentlig denne uge, opdaterer jeg app'en og så bliver statistikken rullet ud til alle brugere. Med tiden tænker jeg at lave en indstilling så man kan slå det helt fra fordi selv om jeg synes det er uproblematisk at opsamle ved jeg der er folk der er ligeglade med hvad jeg synes, de vil bare kunne slå det fra. Og det er i princippet fair nok. Men det bliver ikke lige det næste jeg laver.
]]>
tag:dagbog.atilb.dk,2013:Post/1403169 2019-04-29T07:11:56Z 2019-04-29T07:12:49Z Op ad bakke

Jeg er tilbage efter ferie. Eller, jeg kom faktisk tilbage sidste uge.

Jeg havde besluttet mig for at når jeg kom tilbage efter påsken ville jeg have taget stilling til hvordan jeg skulle fortsætte projektet. Det havde jeg sådan set osse: jeg tænkte, jeg kan ikke stoppe her jeg bliver nødt til som et minimum at blive færdig med iPhone udgaven. Derfor er jeg gået i gang med designe brugergrænsefladen til iOS, hvilket har været meget sjovt at komme i gang med. Jeg har allerede det basale system til at virke der og at se hvordan det kommer til at se ud osse begynder det at ligne noget der kan blive til noget. Her er bogmærker skærmen sammenholdt med mit design til Android.

Det var det ene positive indslag. Derudover har de sidste uger primært været surt show. Advarsel: resten af dette opslag er bare mig der klager min nød. Det reflekterer hvor jeg er henne hvilket er det denne dagbog er til for men jeg ved ikke om jeg vil anbefale nogen, inklusiv mig selv senere, at læse det.

Mens vi var på ferie fjernede google android app'en fra play store igen. Af samme grund som sidste gang: at jeg gemmer folks data uden at have en datapolitik, og så i øvrigt ikke flere detaljer. Sidste gang var det en fejl jeg kunne rette men hvad skulle jeg gøre denne gang – jeg havde allerede after min bedste overbevisning løst problemet første gang. Det ødelagde lidt en dag af ferien. I sidste ende viste det sig at jeg har en alpha udgave af app'en som ingen bruger, bogstaveligt talt det er umuligt for brugere at installere den. Derfor har jeg ikke opdateret den siden før app'en blev fjernet sidste gang. Jeg opdaterede den og det løste åbenbart problemet, app'en er tilbage.

Det virkelig deprimerende er at A til B nu er blevet fjernet to gange. Den første gang kan man godt sige var reel men denne gang var komplet meningsløs. Googles politik er at hvis jeg får fjernet en app nok gange, jeg er i tvivl om hvor mange, bliver jeg selv fjernet som udvikler. Så kan jeg aldrig udgive en app på google play igen og endnu værre: firmaer jeg arbejder for er i risiko for at blive "smittet" med min blokering. Så hver gang det sker er det ikke bare for sjov, det kan have virkelig langtrækkende konsekvenser for mig.

Okay. Så da jeg kom tilbage fra ferie tænkte jeg, jeg opdaterer lige køreplanerne. Da jeg testede de nye køreplaner viste det sig at nu viser app'en pludselig ikke tog fra Aarhus til København før til juli. Det er ikke fordi togene ikke går men i de data jeg får fra rejseplanen er rejsen pludselig knækket over i to: Aarhus til Odense og så Odense til København. Man kan osse se det på rejseplanen selv.
Teknisk set skal man "skifte" tog i Odense – men det er ikke passageren der skifter, det er toget der skifter navn. Det giver ikke meget mening for mig, eller passagerer forestiller jeg mig, men det må give mening for rejseplanen på en eller anden måde. Essensen er at fordi A til B kun viser direkte forbindelser og der er et "skift" mellem Aarhus og København indtil juli er A til B ubrugelig i forhold til tog over Fyn fra nu og indtil juli. Super.

Okay. Så tænkte jeg, jeg kaster mig over noget rent teknisk det kan da ikke gå galt. Google sendte en mail for nogle måneder siden om at de har lavet nogle ændringer til hvordan apps bruger google maps. Specifikt den funktion jeg bruger til at vælge til/fra på et kort. Jeg tænkte jeg kunne få fixet det. Da jeg så dykkede ned i det viste det sige at "ændringen" består i at de bare fjerner den funktion helt. De har nogle nye funktioner man kan bruge til selv at bygge noget tilsvarende men her er hagen: hvis man bruger de nye funktioner koster det hver gang, hvilket det ikke gjorde før. Så ja jeg kan godt bruge tid på at bygge noget der virker som det gør i dag, selv om det er træls i sig selv, men så hver gang en bruger vælger et sted på google maps skal jeg betale google. Jeg ved stadig ikke hvad jeg gør i forhold til det.

Jeg kæmper i forvejen med motivationen til at fortsætte projektet så sådan tre tilbageslag i rap, de to sidste på samme dag, er ikke nogen hjælp. Jeg gav lidt op hen imod slutningen af sidste uge og jeg har svært ved at svinge mig op til at gå videre med iPhone udgaven.
]]>
tag:dagbog.atilb.dk,2013:Post/1393614 2019-04-04T07:53:00Z 2019-04-04T07:53:00Z Kontorhunden

De sidste par uger har jeg været syg og uarbejdsdygtig og de næste par holder jeg ferie. Så projektet har stået stille og der er ikke det store at fortælle, bliver det nok heller ikke før måske efter påske.

I mellemtiden er her et billede af kontorhunden der tager en slapper under mit skrivebord.

]]>
tag:dagbog.atilb.dk,2013:Post/1385942 2019-03-15T09:41:22Z 2019-03-15T09:50:44Z "Attempt to read from null array"
I den sidste post viste jeg hvordan det ser ud at lave en opdatering af køreplanerne. Som endte med at jeg opdagede at der var en fejl i app'en, så opdateringen ikke kan bruges. Jeg tænkte, i forlængelse kunne jeg osse vise hvordan det ser ud at finde og rette en fejl i koden.

Når der sker en fejl i app'en bliver der automatisk sendt en fejlrapport tilbage til en server. Du kan se et eksempel på hvordan sådan en fejlrapport ser ud her. Den indeholder ikke særligt meget men nok til at jeg har noget at gå efter når jeg skal finde årsagen. Derudover, første gang en given fejl sker sender systemet mig automatisk en email, så jeg bliver opmærksom på at der er et problem. Emailen indeholder den samme information som er i rapporten. Så det er lissom der det starter. 


Hvis jeg vil have et overblik over alle kendte fejl i systemet bliver de osse gemt i et lagersystem jeg har. 


På den måde er jeg ikke afhængig af at søge rundt i min inbox for fejl-information, det er osse gemt samlet med alle detaljer.

I dette tilfælde kan jeg se at fejlen sker i NativeVisitList, og fejlen er Attempt to read from null array. Jeg ved at NativeVisitList er den kode der bygger listerne af afgange. Det passer med at jeg kan huske det skete da jeg kiggede på afgange fra Aarhus H til Odense St. Så der er muligvis et problem med hvordan afgange bliver beregnet.

I A til B er der en skarp opdeling mellem den kode der laver beregninger (f.eks, find afgange fra Aarhus H til Odense St.) og brugergrænsefladen, den del der viser resultaterne til brugeren. Det første jeg gerne ville checke var beregnings delen. For at kunne teste den del har jeg en udgave af A til B der slet ikke har en brugergrænseflade, som hedder atb. Den kan det samme som app'en men viser bare resultatet som tekst. Det første jeg forsøger er at bruge atb til at vise den liste afgange som gav problemer.

Det er lidt mere omstændigt end at gøre det gennem app'en, jeg kan f.eks ikke bare få vist afgangene men skal først slå forskellige kodenumre op. Det gør app'en osse men det sker bag kulisserne. Det viser sig at der ingen problemer er – den kan sagtens vise både 10, 100, og 1000 afgange. Det tyder på at problemet er i den kode der viser resultatet.

Brugergrænsefladen til android laver jeg i Android Studio så der kan jeg prøve at køre den komplette app og fange fejlene i en debugger.

Jeg kan ikke genskabe problemet på samme måde som da det først skete hvilket tyder på at fejlen er det man kalder nondeterministisk – fejlen opstår sådan lidt tilfældigt og der er ikke noget du kan gør som fremprovokerer den på den samme måde hver gang. Men det lykkes at finde den et andet sted, nu færgen fra Sælvig til Hou.

Problemet er at der på et tidspunkt mangler et stykke data som koden forventer findes. Jeg prøver at holde øje med hvor det data kommer fra og det viser sig at være en liste som tilfældigvis er tom. Så det er bare et spørgsmål om at noget kode (jeg ikke har skrevet) har valgt at repræsentere en tom liste som at listen slet ikke er der, i modsætning til at der er en liste men listen har ikke nogen elementer. Det er lissom, forestil dig at jeg skal ud og købe ind og beder dig om en liste af ting du skal bruge. Det koden gjorde svarede til at hvis ikke du mangler noget svarer du "nej tak, ikke noget til mig" og giver mig ingen liste. Det min kode forventede svarer til at du altid giver mig en liste, selv hvis ikke du skal bruge noget, der giver du mig bare et tomt stykke papir. (Man skal muligvis være indoktrineret programmør for at det giver mening, men det er altså forklaringen). Begge måder at gøre det giver mening, problemet opstår fordi mine forventninger var forkerte – eller nærmere at det ikke var noget jeg nogensinde havde overvejet.

Det er ikke en ny fejl, den er osse til stede i sidste version f.eks, men man ser den kun hvis man rammer lige i starten eller slutningen af en køreplan, det er der listen er tom, og langt det meste af tiden er man et eller andet sted midt inde i den. Det var derfor jeg opdagede den lige da jeg testede den nye køreplan, og det var derfor det holdt op med at ske for Aarhus til Odense, fordi der var gået en dag mere så jeg skulle scrolle længere tilbage for at komme til starten. Hvorimod Sælvig til Hou går så sjældent at den stadig var tæt på første afgang. Så det var slet ikke en nondeterministisk fejl, den var deterministisk men afhang af tidspunktet jeg testede.

Det var i sidste ende en ret nem fejl, det tog ikke meget mere end en times tid at finde og fixe. Fejl kan være meget mere langhårede dog.
]]>
tag:dagbog.atilb.dk,2013:Post/1385610 2019-03-14T15:14:14Z 2019-03-14T16:40:30Z "Opdaterede køreplaner"

Nu skrev jeg i sidste post om at jeg ville arbejde på at strømline det arbejde jeg skal gøre når der kommer nye køreplaner for at app'en bliver opdateret. Måske er det et godt tidspunkt at beskrive hvordan det ser ud, helt lavpraktisk, når jeg opdaterer køreplanerne i dag.

Jeg får køreplanerne fra rejseplanen, de kommer som en stor zip fil. Når der er en ny udgave sender de en mail ud og det er første trin for mig – jeg opdager at der er kommet en mail fra dem,

I mailen er der et link direkte til zip filen men det link bruger jeg aldrig. For lang tid siden lavede jeg en proces der en gang imellem automatisk henter filen fra rejseplanen og hvis den har ændret sig siden sidst gemmer den en kopi. Det kom sig af at jeg var på ferie og jeg så mailen fra rejseplanen men kunne ikke (og havde ikke lyst til) at sidde og rode med at hente filer. Så nu ved jeg altid at processen gør det for mig. Den gemmer filen i google cloud, og der ligger den klar.

Som der står i detaljerne, de nye køreplaner ligger i en fil der hedder 20190314_20190605_v00.zip som er 33.4MB stor. Navnet er ikke det rejseplanen kalder den, det er et internt navn den er blevet tildelt fordi køreplanerne i filen løber fra 14. marts (20190314) til 5. juni (20190605) og det er den første fil vi har set der gør det (v00).

For at kunne bruge køreplanerne i A til B skal de processeres og transformeres og komprimeres ret omfattende. Det har jeg et script der gør. Det står osse for at hente filen fra google cloud, jeg skal ikke downloade den manuelt men bare checke at den findes og se hvad den hedder. Jeg skriver detaljerne af hvad scriptet skal gøre i en konfigurationsfil, hvoraf det meste typisk er det samme som sidste opdatering, og så starter jeg det. Så står det og tygger et kvarters, tyve minutters tid og efterlader en fil i det specielle format A til B bruger, som indeholder køreplanerne. Filen er typisk omkring 10% af størrelsen på den fil jeg hentede fra rejseplanen, hvilket er en stor del af pointen.

Her er hvordan en kørsel af scriptet ser ud, med store dele af ventetiden klippet ud

Når jeg har filen med køreplanerne skal jeg bygge en ny udgave af android app'en som køreplanerne bliver "bagt" ind i. Det ligner meget den proces jeg brugte til at lave køreplans filen: ændre nogle konfigurationsfiler og køre et script. Så bliver app'en bygget. Det tager måske 5 min.

Derefter skal jeg opdatere app'en i google play. Det vil man typisk gøre på deres hjemmeside, plus det er nødvendigt at lave ændringer et par andre steder. Jeg gjorde det manuelt til at starte med men blev ved med at lave fejl, jeg glemte altid et eller andet. Nu har jeg pakket hele operationen sammen så et script gør det, jeg skal bare – du gættede det – ændre en konfigurationsfil og så køre scriptet, så laver det opdateringen.

Hele processen med at bygge til android og publicere på google play ser sådan her ud,


Første forsøg på at opdatere på google play fejler på grund at netværket i min lejlighed. (Jeg skal have ringet til stofa og klaget igen).

På google play udgives A til B i tre forskellige "spor": internt, beta, og produktion. Produktion er den udgave langt de fleste har. Beta er den eksperimentelle udgave der kommer ud til nogle folk jeg kender, venner og familie. Internt er en udgave det kun er mig selv der ser. Opdateringer starter som interne, så får jeg opdateringen på min telefon og kan prøve om den virker. Hvis jeg mener den gør det forfremmer jeg den til beta, så er der lidt flere folk der får den. Efter lidt tid der, hvis alt stadig ser ud til at virke, forfremmer jeg koden helt til produktion og så kommer den ud til alle.

Stort set med det samme jeg har kørt scriptet ovenfor og det har udgivet opdateringen på det interne spor kan jeg se den på min telefon,

Så leger jeg lidt rundt med den og når det bare er en opdatering af køreplaner og ikke en rigtig kodeændring er der stort set aldrig problemer så under normale omstændigheder ville jeg hurtigt forfremme opdateringen. Desværre var dette et eksempel på at der er forskel på "aldrig" og "stort set aldrig" for faktisk er der problemer med opdateringen,

Så du kommer ikke til at se version 0.3.1, jeg bliver nødt til at fixe problemet og så kommer den opdatering der kommer ud til alle brugere til at hedde 0.3.2. Det bliver næste uge. Der er stort overlap mellem opdateringerne. Den sidste, den der er med i 0.3.0, holder frem til 22. maj så jeg har ikke panik-travlt med at få den næste opdatering ud.
]]>
tag:dagbog.atilb.dk,2013:Post/1385251 2019-03-13T16:58:23Z 2019-03-13T17:05:44Z Spam og selvpromovering

I sidste uge blev jeg færdig med den nye hjemmeside. Jeg er faktisk helt godt tilfreds efterhånden.

Det tog noget tid at få videoen til at fungere som jeg gerne vil have den til men jeg synes jeg er endt med noget der fungerer selv når man ser siden på en telefon, og det var målet. En del af udfordringen var osse at få det lavet så det giver mening hvad der foregår på skærmen og jeg ved ikke om det jeg har lavet er perfekt, men jeg tror det er godt nok.

Jeg lagde sidste hånd på hjemmesiden fredag eftermiddag og så tænkte jeg, jeg poster om app'en på reddit på mandag. Jeg har tidligere postet på r/Aarhus og jeg syntes jeg fik noget mega godt feedback. Plus det virkede som om folk syntes det var relevant. Derfor tænkte jeg, hvis jeg nu poster på r/Denmark er det sikkert fint og jeg havde allerede nogle halvhøje forventninger til at det ville blive godt modtaget. At poste på reddit i det hele taget ligger i forlængelse af min ide om at gå direkte til potentielle brugere.

For at springe direkte til moralen, min post var oppe nogle få minutter så endte den sådan her

Så, det var en skuffelse. Som i, ligge vågen om natten, har ikke arbejdet siden, har mest lyst til at opgive projektet niveau skuffelse.

Det har ikke noget med det der skete på reddit som sådan. Det er mere at jeg er enig – det jeg postede var spam og selvpromovering. Jeg troede oprigtigt det var noget der ville være nyttigt for folk men hvor meget af det spam jeg modtager, og som jeg synes er mega irriterende, er fra folk der lige så oprigtigt mener det de sender vil være nyttigt for mig? I hvert fald en del er jeg sikker på. Den slags, og en masse andet af samme skuffe, har jeg grublet meget over de sidste par dage.

Jeg er stadig ikke færdig med at gruble men i hvert fald en smule af min motivation for at fortsætte er kommet tilbage. Min tanke lige nu er at jeg holder resten af ugen fri og laver alt andet end at arbejde (og at skrive dagbog tæller åbenbart ikke som arbejde). Når jeg så kommer tilbage næste uge går jeg i gang med at arbejde på automatisk opdatering, det vil sige at køreplanerne bliver opdateret i app'en helt automatisk når der kommer nye uden at jeg behøver gøre andet end måske trykke godkend et eller andet sted. Det skal jeg have lavet under alle omstændigheder og det er en forudsætning for at jeg kan holde op med at arbejde aktivt på projektet. Når det så er på plads ser jeg hvordan jeg har det og tager stilling til om projektet er slut. Hvis jeg kender mig selv ret er det ikke, men det vil vise sig til den tid.

I mellemtiden forsøger jeg mig med lidt mere selvpromovering og hvis jeg finder noget positiv respons og måske endda nogle nye brugere vil det gøre det meget nemmere at fortsætte. Hvis ikke er det selvfølgelig surt men det vil osse være nyttig input.

]]>
tag:dagbog.atilb.dk,2013:Post/1382611 2019-03-07T14:24:53Z 2019-03-13T17:02:47Z Video video

Det slog mig i begyndelsen af denne uge at der faktisk er lang vej fra at høre/læse om hvad A til B kan og så have en fornemmelse for hvordan den er at bruge i praksis. Det er et stort spring. Det er et problem for hvis ikke du har en fornemmelse af at det her er bedre hvorfor så installere den?

For at gøre det spring mindre fik jeg lyst til at lægge noget video ind på siden på atilb.dk som kan given en ide om hvordan den her app virker. Jeg er nok faldet lidt bagud med hvordan man laver hjemmesider så det viste sig at være et lidt omfattende projekt men det nærmer sig noget jeg synes virker okay. Der er mange trin undervejs.

Her er det sidste trin af udviklingen: jeg polerer en af de nye elementer i den nye hjemmeside med udviklingsværktøjerne i chrome. Det er mest farver, skrifttyper, marginer, den slags.

Den kode der tegner hjemmesiden arbejder jeg på i PyCharm. Det er den overordnede struktur.

Der er en smule grafik arbejde oveni. F.eks bliver videoen vist med omridset af en telefon nedenunder og noget halvgennemsigtig reflektion ovenpå. Det endte jeg at tegne i Inkscape.

Pointen er selvfølgelig at demonstrere app'en. Der er heldigvis indbygget skærmoptagelse i android emulatoren så jeg skal bare køre app'en og så bede emulatoren om at optage skærmen.
Der er en masse detaljer man skal have styr på – jeg har optaget hvert klip måske 10-20 gange for at ramme det rigtigt – men det er overkommeligt. En detalje jeg havde glemt var at tiden gik mellem optagelserne så når klippene blev sat sammen hoppede uret rundt. Det gjorde at jeg måtte optaget det hele igen hvor jeg huskede at indstille uret til 11.20 lige inden hver optagelse.

Jeg håber jeg kan få poleret færdig i morgen så jeg kan opdatere siden inden weekenden.
]]>
tag:dagbog.atilb.dk,2013:Post/1379555 2019-02-28T08:59:09Z 2019-02-28T09:04:09Z Et skridt tilbage, et skridt frem

Som et led i at få bedre kontakt til brugerne vil jeg gerne, ud over bare at være på twitter, facebook, osv, gøre noget gennem selve app'en. Men det er svært. Jeg vil ikke, ikke, lave den sædvanlige pop-up med "din mening er vigtig for os" for jeg synes selv de er irriterende. Men samtidig er brugernes mening vigtig for mig, det er lidt det der er pointen. Så spørgsmålet er om det at jeg gerne vil i kontakt med mine brugere er grundlæggende irriterende uanset hvordan jeg griber det an? Eller om det er okay og kan være ikke-irriterende hvis jeg gør det på den rigtige måde? Det er ikke noget jeg har et godt svar på, jeg tror det må komme an på et forsøg.

Her er mit design indtil videre:


En besked der dukker op under dine bogmærker og som du nemt kan slippe af med hvis ikke du er interesseret. Tanken er at jeg lavet noget logik der sørger for at beskeden først dukker op når du har brugt app'en et stykke tid.

Det næste er så at jeg gerne vil have et minimum af statistik omkring om beskeden så faktisk bliver vist, og om folk trykker på den. Brugsstatistik er en anden følsom ting, på samme måde som "din mening er vigtig for os" er det. Folk er som et gennemgående princip ikke interesseret i at der bliver opsamlet statistik om dem. Det er noget jeg har tænkt meget over, rigtig meget, og jeg mener efterhånden jeg har fundet en løsning der er acceptabel.

Nøglen er at hvor jeg tror folk har et problem med at nogen opsamler information specifikt om dem er det et mindre problem at gøre det på tværs af brugere. For eksempel, hvis jeg ved at "Trine brugte A til B i dag" er det problematisk. Hvorimod hvis jeg ved at "1632 brugere brugte A til B i dag", hvor Trine indgår som en af de 1632 uden at der er nogen måde at identificere at det er hende, er det mindre problematisk. Det er det sidste jeg reelt er interesseret i, jeg har ingen interesse i hvad individuelle brugere gør. Og ikke bare fordi det er noget folk ikke har lyst til at jeg ved, lovgivningsmæssigt og specielt efter GDPR blev indført, det nye regulativ om databeskyttelse, følger der en masse forpligtelser med.

Der findes mængder af grydeklare løsninger til at opsamle brugsstatistik men fælles for dem er at de gør præcis det jeg ikke vil: gemmer data om brugere individuelt. Det problem er jeg tidligere rendt ind i omkring fejlrapporter. Hvis jeg vil have en løsning der opfører sig som jeg gerne vil have skal jeg selv bygge den fra bunden, præcis som jeg gjorde med fejlrapporterne. Det er jeg gået i gang med men der er jeg så løbet ind i det næste problem. Jeg ville gerne bare udvide det system jeg bruger til fejlrapporter som er bygget på google app engine men så skal jeg bruge nogle funktioner som ikke bare er tilgængelige. Det kræver at jeg flytter fra den platform fejlrapport systemet bruger lige nu (standard python2) til en anden (enten standard python3 eller flexible python). Det kræver igen at jeg skriver en helt masse kode om fordi der er store forskelle mellem platformene. Det er jeg så gået i gang med men det har været super smertefuldt. Dårligt dokumenteret, svært til umuligt at teste, ugh, bare dødens pølse.

I sidste ende er jeg blevet enig med mig selv om at hvis jeg alligevel skal skrive det hele om så er det tid til helt at droppe google app engine og køre koden selv. App engine er bare for meget smerte for for få fordele. Det ville jeg skulle gøre under alle omstændigheder før eller siden og det bliver altså nu. Det føles som at smide en masse arbejde væk og så bruge tid på at gøre det hele igen, plus det føles som om jeg er kommet virkelig langt væk fra det jeg egentlig skulle, nemlig at vise en besked i app'en. Men jeg tror det er sådan det må være.

Jeg kommer til at skrive mere om brugsstatistik, jeg har virkelig stærke holdninger til privacy og der ligger en mængde tanker og arbejde bag min tilgang til det, men det kommer til at vente. Jeg vil hellere beskrive hvordan det virker når det virker, hellere end hvad jeg har tænkt mig som kan risikere at ændre sig når jeg går i gang med at implementere det.
]]>
tag:dagbog.atilb.dk,2013:Post/1376176 2019-02-20T08:55:50Z 2019-02-20T08:55:50Z Den rene og skære socialisme

Jeg har indtil videre fokuseret på det tekniske, først at få app'en til at fungere overhovedet og på det sidste på at få den til at være mere poleret og nemmere at bruge. Det med at få en masse brugere har jeg tænkt, det gør jeg noget ved når det tekniske er godt nok. Og ved du hvad, det kan man simpelthen se på hvor mange brugere jeg har:

Det svæver omkring 100 og har gjort det længe. Jeg er faktisk meget glad for mine 100 brugere, det er en overraskende stor procentdel af dem jeg har markedsført app'en overfor og det er ret stabilt – det er ikke sådan at folk forsvinder igen når de først er begyndt at bruge app'en. Men det er bare overhovedet ikke nok at bygge en forretning på.

Det har jeg så overvejet grundigt og lagt en plan med konkrete trin til at nå over 10.000 brugere over de næste 2 måneder. Eller, det er så komplet løgn. Det jeg i virkeligheden har gjort er at arbejde videre på det tekniske, fuld af skyldfølelse over ikke at arbejde på at få flere brugere, ligget vågen om natten og grublet og grublet og overvejet bare at opgive hele projektet fordi det fører ingen vegne, og holdt op med rigtig at svare når folk spørger hvordan det går med app'en fordi jeg synes det går skod.

Men det er osse bare sådan jeg typisk har det i januar/februar. Hvis ikke det er det ene jeg hopper ned i et sort hul over så er det det andet. Og så lidt senere kommer jeg op af hullet igen og det hele bliver mere konstruktivt og mindre selvpineri.

En del af problemet er at jeg faktisk har gjort lidt forskellige tiltag for at få flere brugere og det har bare ingen effekt haft overhovedet. Fælles for de ting jeg har gjort dog er at det ikke har været min målgruppe direkte men indirekte gennem f.eks medier, grupper der repræsenterer brugere af kollektiv trafik, osv. Det tror jeg har været en fejl. Jeg skal have fat i potentielle brugere direkte.

Baseret på den ide har jeg nu, og det er ikke løgn denne gang, en konkret plan for at få flere brugere. Den involverer i første omgang at A til B nu er til at finde på facebook, twitter, og instagram (som @HerErATilB alle tre steder). Derudover har jeg pustet nyt liv i atilb.dk:

Min sociale strategi er endnu ikke helt fuldt udformet men der er i hvert fald et omrids af en. Jeg arbejder på nogle flere tiltag og forhåbentlig, i løbet af marts begynder kurven at bevæge sig opad.
]]>
tag:dagbog.atilb.dk,2013:Post/1371401 2019-02-07T11:25:37Z 2019-02-07T11:25:38Z A til B på en iPhone

Eller, det vil sige en meget meget lille del af A til B. Og, det vil sige på en iPhone simulator.

Det ser måske ikke ud af så meget men "E Main St / S Irving St" er navnet på et stoppested fra et test dataset jeg har, og jeg er nået langt nok til at jeg kan lave en iPhone app der indeholder det data set og den samme kode som på android der kan finde ud af at læse fra det.

At vise navnet på et stoppested er selvfølgelig ikke nær nok så nu skal jeg i gang med det næste trin: finde ud af hvordan man laver brugergrænseflader på iOS. Jeg ser mængder af instruktionsvideoer om den slags i øjeblikket og så snart de har dækket det jeg skal bruge går jeg i gang med at lave det.

Der skal nok blive en iPhone app ud af det her tænker jeg.

Nøglen til overhovedet at komme så langt er at jeg har opgivet min gamle mac og købt en ny. Eller, jeg siger ny, det er en brugt en fra 2013 som var på januar-tilbud. En sprit ny mac er grotesk dyr og i øvrigt er jeg bitter over at jeg overhovedet skal købe en for at kunne lave en iPhone app. Ingen krævede at jeg købte en ny computer for at lave android udgaven. Men den er rigtig hurtig, det er pludselig en fornøjelse at arbejde i XCode.

]]>
tag:dagbog.atilb.dk,2013:Post/1366611 2019-01-24T12:51:33Z 2019-01-24T12:51:33Z Swift
Deeet gååår sååå laaangsomt. Jeg tror det er en kombination af at det er dødssyg januar, jeg er begyndt at arbejde på iOS som jeg ikke er hjemme i, og min mac som jeg skal arbejde på er omkring 10 år gammel og sløv som sirup. Taget sammen gør det at jeg ikke er top-motiveret.

Men det går fremad. Efter nogle meget frustrerende dage har jeg nu hul igennem til swift, det sprog jeg skal skrive iPhone udgaven i. Jeg kan tage en fil med køreplaner i og få adgang til indholdet fra swift, på samme måde som jeg kan fra java til android-udgaven. 


Det er faktisk en virkelig stor ting. Jeg aner overhovedet ikke hvad jeg laver når jeg arbejder med swift og det med at strikke flere sprog sammen plejer at være blandt de mest langhårede aspekter af et sprog. Det er så der jeg har valgt at starte og jeg har seriøst overvejet muligheden af at give op og arbejde på noget lettere indtil jeg forstod noget bedre hvordan sproget fungerer. Derfor er det virkelig fedt at det til sidst er lykkedes. Jeg kan godt bruge en lille sejr.
]]>
tag:dagbog.atilb.dk,2013:Post/1361335 2019-01-08T11:43:40Z 2019-01-08T11:45:00Z Småting

Over de sidste par uger har jeg ramt ind i lidt forskellige uhensigtsmæssigheder ved app'en som jeg besluttede mig for at forsøge at fixe denne uge. Nogle af dem ordnede jeg i går, et par stykker i dag, og nogle af dem har vist sig ikke at være noget jeg kan fixe.

Et problem har været at tidligere når man fik vist afgange mellem to stop hvor man skulle gå i en eller begge ender så viste den ikke afstanden man skulle gå. Det har jeg lavet om nu, og jeg benyttede mig af lejligheden til at rydde lidt op i hvordan afgange bliver vist i det hele taget.

Her er efter:

Og her som det var før:

Det er ikke specielt gennemgribende men en forbedring. Et specielt smertespunkt tidligere er at jeg skrev 40m et sted i betydningen "der er 40 meter" og lige ved siden af kunne der stå 40m i betydningen "om 40 minutter". For klarheds skyld står der nu altid 40 min når det er tid, 40m når det er afstand.

Et andet problem jeg opdagede er at de fleste (alle?) færger pludseligt mangler. Det viser sig at det gør de osse på rejseplanen og google maps – så der er et underliggende problem med rejseplanen. Det kan jeg ikke gøre så meget ved, andet end at gøre dem opmærksomme på, hvilket jeg har gjort.

]]>
tag:dagbog.atilb.dk,2013:Post/1359459 2019-01-02T11:32:37Z 2019-01-02T11:33:39Z Tilbage fra juleferie

Jeg er tilbage på kontoret efter juleferien.

Mit store dilemma har været: jeg havde en deadline der hed at jeg skulle nå at lave tre nye funktioner inden juleferien, og derefter ville jeg gå over til at arbejde på iOS udgaven. Jeg nåede kun de to funktioner så spørgsmålet er: skal jeg blive ved og lave den tredje funktion eller skal jeg lade den ligge og gå direkte til iOS. Hvad er vigtigst?

Jeg er stadig ikke helt sikker. Den tredje funktion er "mine steder" og den vil være virkelig nyttig for alle brugere men specielt for blinde, hvilket er den vigtigste grund til at jeg har svært ved at udskyde den. Samtidig er det jeg hører 75% af tiden når jeg demonstrerer app'en "det ser super nyttigt ud, sig til når det virker til iPhone".

Min kompromis er at indtil videre arbejder jeg på begge ting samtidig. Jeg arbejder langsomt videre på "mine steder" (og har snydt og arbejdet lidt på det i ferien osse) men samtidig bruger jeg en masse tid på at sætte mig ind i hvordan man laver apps til iOS med timevis af instruktionsvideoer. Jeg har aldrig lavet en iOS app så jeg starter helt fra bunden. Før jul gik jeg osse selv over til at bruge en iPhone. Det er ret smertefuldt – jeg var for nærig til at købe en ny så jeg har en brugt 6'er jeg købte sidste år og den er super langsom og batteriet er skod. Men af samme grund er den perfekt at udvikle på. Hvis jeg kan få det til at køre godt på den kan jeg regne med at det kører godt på andre slags iPhones osse.

]]>
tag:dagbog.atilb.dk,2013:Post/1352706 2018-12-12T10:35:58Z 2018-12-12T10:35:59Z Ny introduktion

Jeg har længe ikke været super tilfreds med den introduktion man får vist første gang man åbner A til B. En ting er at jeg selv synes den slags introduktioner er lidt irriterende, men oveni synes jeg måske ikke jeg har eksekveret det specielt godt. Det ligner lidt noget rod. Det er et problem fordi det er den allerførste ting nye brugere ser – og en god oplevelse første gang du bruger en app er mega super vigtigt.

Jeg havde en ide til en bedre måde at gøre det og besluttede mig for at give det et forsøg i dag. Det viste sig at være meget nemmere end jeg havde frygtet at lave, og det fungerer mere eller mindre præcis som jeg gerne ville have det til.

]]>
tag:dagbog.atilb.dk,2013:Post/1352370 2018-12-11T09:48:41Z 2018-12-11T09:48:41Z Ny køreplan søgning launcher i dag!

Siden sidste opdatering har jeg arbejdet på at få den nye måde at søge efter køreplaner færdig. Jeg har haft det meste klar siden sidste uge men har slåsset med nogle detaljer som bare ikke ville helt på plads. Det mener jeg de er nu så med forbehold for uforudsete omstændigheder kommer der en opdatering ud med den nye søgning i dag.

Jeg er opmærksom på lidt forskellige mangler skarpe hjørner der trænger til at blive pudset men det er relativt småting. Det er meget bedre end det der er nu, selv med de små mangler der er, og det er det der gør forskellen.

Nu kommer den næste fase så: se hvad feedback der kommer.

]]>
tag:dagbog.atilb.dk,2013:Post/1348948 2018-11-30T11:50:24Z 2018-11-30T11:53:02Z Vælg stoppesteder live demo
Det jeg arbejder på i øjeblikket er stadig den nye måde at søge efter køreplaner. Det basale er på plads med de tre input felter så forskellen mellem det jeg havde sidste uge (og ugen før for den sags skyld) er til at overse. Men der er fremdrift. Nu, når man vælger at skulle fra sin nuværende position, eller et bestemt stop, så er de destinationer man får vist kun dem man faktisk kan komme til derfra. Før virkede det kun hvis man valgte en hel by. 

Derudover har jeg lavet den kode som skal bruges når man har valgt både fra og til, til at bestemme hvordan man kommer mellem de to steder og hvilke stop de to steder man kan bruge. Hvis du f.eks vælger at du skal fra Aarhus til Kolding med tog skal systemet kunne gennemskue at så behøver den ikke vide mere om Kolding, der er kun et stop det kan være (Kolding St), men der er to stop i Aarhus man kan bruge (Aarhus H og Viby St) så du skal vælge hvilket af de to du mener.

Jeg forestiller mig at der skal være et par forskellige måder at vælge hvilket stop du vil bruge indenfor en bestemt by: du kan vælge dem fra en liste eller på et kort. Det første jeg er begyndt at arbejde på er at kunne vise kort hvor man kan vælge mellem forskellige punkter. Det er det sidste i demoen. De tre stop man kan vælge imellem er bare tre helt tilfældige men det er bare for at have noget at arbejde med. Der er stadig noget vej igen men for en dags arbejde synes jeg det er okay.

]]>
tag:dagbog.atilb.dk,2013:Post/1346100 2018-11-21T12:50:40Z 2018-11-21T12:50:40Z Ny køreplan søgning live demo

Det går fremad med den nye måde at søge efter køreplaner. Det basale er på plads og brugergrænsefladen opfører sig i det store hele rigtigt. Som noget nyt har jeg tilføjet en måde at vælge steder med google maps.

Tanken lige nu er at den side du ser i demoen er den første, hvor man kan angive relativt groft hvilken køreplan man er interesseret i. Når man har udfyldt den afgører app'en om det er nok til bare at vise en bestemt køreplan. Hvis ikke kommer man ind på en side to hvor man skal vælge f.eks hvis der er flere stop i den by du rejser fra, hvilket stop vil du se. Og hvis der er flere ruter, f.eks IC, ICL, og RE, får du mulighed for at vælge nogle af dem fra.

]]>
tag:dagbog.atilb.dk,2013:Post/1345457 2018-11-19T15:24:48Z 2018-11-19T15:24:48Z Petitesser

De sidste par uger har jeg brugt det meste af tiden på forskellige petitesser, hvis jeg skal være helt ærlig. Det er lissom min motivation har taget et dyk, hvilket den plejer omkring nu så det er ikke så overraskende.

Det går stadig fremad med den nye måde at søge efter køreplaner på men der er bare meget arbejde i det, så det går ret langsomt. Den måde jeg har designet det på er meget enkel – der er tre tekstfelter der skal udfyldes: transportform, fra, og til – men der sker en enorm masse bag kulisserne. Jeg vil gerne have at man kan udfylde dem i hvilken som helst rækkefølge, og har man udfyldt noget skal det tages i betragtning i hvilke muligheder der bliver vist for de andre.

F.eks, hvis du allerede har valgt at din transportform er tog og du er ved at vælge hvor du skal til skal den kun vise steder man kan komme til med tog. Og den modsatte vej: hvis du har valgt at du vil til Silkeborg og nu vil vælge transportform skal den kun vise bus og tog, for det er de eneste måder at komme til Silkeborg. Plus, og det er den mest langhårede, hvis du har valgt hvor du skal fra og skal vælge hvor du vil til skal du kun se steder du faktisk kan komme til derfra. Gang så det med at der er flere forskellige slags steder man kan komme fra og til: et bestemt stoppested (f.eks specifikt Dokk1 letbanestation), et stednavn (f.eks hele Silkeborg) og din nuværende position, som er et sæt geografiske koordinater. Det er mange forskellige mulige kombinationer. Det er dem jeg arbejder mig, langsomt, igennem de her dage.

Nåja og så, bare for afvekslingen, fandt jeg min oldgamle mac frem. Jeg kan nu bygge al C++ koden på den og kun en enkelt test der fejler, som er en ligegyldig en. Det er allerførste skridt i retning af at lave en iPhone version. Eller, okay at skrive det hele om i C++ til at starte med var vel rimeligvis det første skridt så reelt er jeg gået mange skridt i den retning allerede, men du ved hvad jeg mener.

]]>
tag:dagbog.atilb.dk,2013:Post/1345440 2018-11-02T14:04:00Z 2018-11-19T14:59:12Z At søge efter stop og steder

Denne uge har jeg arbejdet videre på den nye måde at søge i køreplaner. Der er stadig meget der mangler men man begynder at kunne få en fornemmelse for hvordan det vil virke i praksis.

Den oprindelige udgave fra først på ugen viste alle steder og stop bare alfabetisk hvilket er okay, det virker, men det er ikke optimalt. Der er  mange navne at man i de fleste tilfælde skal skrive næsten hele navnet før den man leder efter dukker op. Det er lidt irriterende for store byer. Når man har skrevet “ve” er det overvejende sandsynligt at man mener “Vejle”, ikke “Vejlby”, men Vejlby kommer før Vejle alfabetisk så den vil dukke op først.

Det sidste jeg lavede inden jeg lavede videoen var at dele steder op i tre vægtklasser. Store byer, øer, landsdele, osv er “tunge” og vil altid blive vist først hvis det er nogen der passer på det du har skrevet. Mindre byer, øer, og landsdele, plus lufthavne, er “mellemtunge” og vil blive vist efter de tunge. De mindste af alting er “lette” og vil altid blive vist efter de tunge og middeltunge. I eksemplet fra før er Vejle tung og Vejlby let, så du skal bare skrive “ve” så står den øverst. Det kommer til at være noget jeg skal tilpasse og justere men det har hjulpet meget på hvor nemt det er at finde steder allerede.

]]>
tag:dagbog.atilb.dk,2013:Post/1345439 2018-10-28T21:29:00Z 2018-11-19T14:58:14Z ...og i øvrigt

Jeg kiggede lige ned over bloggen og hæftede mig ved to ting jeg manglede at skrive om. Så dem vil jeg lige tage fat i her.

For det første, navnet. A til B. Jeg havde en periode tidligt i projektet hvor jeg forsøgte mig med en masse forskellige navne og da jeg gav A til B et forsøg var det bare et i rækken, jeg vidste ikke at det ville blive det endelige. Så jeg skrev ikke noget om det på det tidspunkt. Det beskriver ikke nødvendigvis app’en bedre end f.eks “køreplanen” eller “næste stop”, som var andre kandidater. Men det var bare det der viste sig at give mig den bedste fornemmelse. Det ligner ikke navne på andre tilsvarende apps i Danmark. Det er et udtryk jeg støder ind i hele tiden og uafbrudt omkring offentlig transport – det virkede helt åbenlyst da jeg først kom på det. Det var ikke, skal jeg understrege, ikke, grunden til at jeg valgte det, det gik faktisk først op for mig senere, men “A til B” vil sortere først i enhver alfabetisk listen den optræder i.

Men det der virkelig har slået hovedet på sømmet er at når jeg siger navnet til folk har jeg altid en fornemmelse af at det går lige ind. Jeg er aldrig blevet spurgt, hvad var det nu lige din app hed igen? Og nogen gange får folk et lille skævt smil, som i: ah, jeg ser hvad du har gjort der. Det kan jeg godt lide.

Den følelse har jeg ikke med ikonen. Den er okay, lissom “næste stop” var et okay navn, men jeg vil gerne arbejde videre på den og ende med at have noget der føles rigtigt på samme måde som “a til b” gør. Jeg er dog sikker på at jeg sammen med min ven Maiken, som osse hjalp mig med det ikon jeg har nu og som er meget bedre til den slags end mig, når derhen og det er ikke noget jeg har travlt med.

Den anden ting jeg manglede at skrive om er at jeg pludselig, helt umotiveret, skiftede fra engelsk til dansk på bloggen. Softwareudvikling foregår bare gennemgående på engelsk. Plus det ideen til at jeg overhovedet skriver en blog kommer fra, weekly snippets jeg skrev hos google, var osse på engelsk for det er alting hos google. Så det føltes naturligt da jeg gik i gang at det var det jeg skrev på. Men jeg er flere gange kommet til at skrive på dansk og har skullet gå tilbage og slette det og skrive det igen på engelsk. Og på et tidspunkt tænkte jeg, det er fjollet. Hvis jeg skal tvinge mig selv til at skrive på engelsk hvad er så pointen. Så jeg lod det jeg havde skrevet på dansk stå og er bare fortsat sådan derfra.

]]>
tag:dagbog.atilb.dk,2013:Post/1345438 2018-10-28T20:27:00Z 2018-11-19T14:57:47Z Stednavne brugergrænseflade design

Jeg er ved at være nået så langt med de nye funktioner omkring søgning og geografiske steder at de kan betragtes som klar til at blive taget i brug i app’en. Om ikke af andre grunde så fordi jeg har kunnet lege med dem på min computer og jeg kan ikke vente med at få dem i app’en osse så jeg kan bruge dem i praksis.

Det betyder at jeg har støvet de designs af jeg lavede for måneder siden og som var grunden til at jeg overhovedet gik i gang med de nye funktioner. Jeg var lidt urolig for hvor besværligt det ville være at realisere designet men det har vist sig at være ret ligetil. Jeg har allerede et skelet der i alt væsenligt ligner designet. Jeg er så tæt på at kunne prøve at finde ruter mellem byer i praksis. Derfor er jeg osse kommet til at arbejde det meste af dagen selv om det er søndag. Jeg burde vide bedre.

]]>
tag:dagbog.atilb.dk,2013:Post/1345436 2018-10-23T10:57:00Z 2018-11-19T14:56:37Z Anholt???

Nu sagde jeg godt nok at der måtte være en fejl med listen af steder der kan nås fra Vonsild fordi det åbenlyst ikke kan lade sig gøre at komme til Anholt derfra. Men der tog jeg fejl.

Det viser sig at jeg havde gjort den klassiske antagelse at der kun findes et sted der hedder Anholt. Selvfølgelig findes der flere. F.eks er der tre byer der hedder Anholt, hvoraf en ligger ved Kolding og kan nås med bus fra Vonsild. Anholt i Kattegat er ikke engang den eneste ø der hedder det, der findes en anden Anholt i Rinkøbing Fjord.

]]>
tag:dagbog.atilb.dk,2013:Post/1345435 2018-10-23T10:43:00Z 2018-11-19T14:56:11Z En ny måde at teste på

Det har længe været lidt pinefuldt at teste nye funktioner med de danske køreplaner fordi det har krævet at jeg lavede brugergrænsefladen til Android før jeg kunne se resultaterne.

Nu har jeg lavet en genvej: et kommando linje værktøj der kan noget af det samme som app’en og som er meget nemmere at se resultater igennem. Her er tre eksempler:

  • Lister af afgange fra et bestemt stop. Det er den funktion der allerede er i app’en.
  • Søgning efter geografiske steder efter navn. Det kommer til at blive en del af den nye måde man kan søge efter ruter. Jeg skal dog først have løst et problem der er tydeligt i eksemplet: resultaterne er ikke sorteret, det burde de være.
  • Steder man kan nå fra et givet geografisk sted, så fra Samsø kan man komme til Kalundborg og Hov, og dermed osse til Sjælland og Jylland. Det kommer osse til at indgå som en del af søgning efter ruter. Her er dog osse et problem der først skal løses: hvis man kigger efter står der at man kan komme fra Vonsild til Anholt – det er så afgjort forkert.

Så allerede nu har det været et vældigt nyttigt værktøj, det har afsløret to forskellige problemer med de nye funktioner jeg skal have løst før jeg kan gå videre med at lave den rigtige brugergrænseflade.

]]>
tag:dagbog.atilb.dk,2013:Post/1345432 2018-10-18T14:20:00Z 2018-11-19T14:55:10Z Iztacalco til Mixcoac

Det jeg har lavet denne uge har mestendels været at gøre det sådan at app’en kender til byer og geografisk steder i det hele taget. Så man kan sige “jeg skal fra Samsø til Jylland” og så finder app’en ud af hvad det vil sige, i stedet for at man skal sige “jeg skal fra Sælvig Havn til Hou Havn”. Man kan stadig gøre det men hvis man hellere bare vil bruge nogle bredere geografiske betegnelser – og det vil man typisk – bliver det muligt. 

Jeg har lavet det meste af benarbejdet nu, det primære der er tilbage er at få det testet grundigt og så at få lavet brugergrænsefladen i app’en. Af forskellige grunde tester jeg ikke med danske køreplaner, til det bruger jeg gerne data fra Mexico City. Det er fordi betingelserne for de danske køreplaner gør at jeg ikke må bruge dem til at teste med. Plus de mexicanske data er meget mindre og nemmere at have med at gøre.

Det betyder at for at teste nye funktioner til de danske køreplaner bliver jeg nødt til at sætte mig ind i hvordan det tilsvarende virker for Mexico City, så jeg kan afgøre hvordan testene skal opføre sig. Så så lærer jeg osse lidt om det.

]]>
tag:dagbog.atilb.dk,2013:Post/1345431 2018-10-18T14:12:00Z 2018-11-19T14:53:39Z Yikes!

Jeg fik en grim overraskelse forrige uge. Der kom en mail fra google om at A til B var blevet fjernet fra Google Play. Mailen kom fredag først på aftenen så det var bare super, jeg endte med at arbejde over weekenden for at løse det.

Det der viste sig at være galt var en kombination af uheldige omstændigheder. Jeg bruger et system der hedder firebase til at gemme fejlrapporter hvis der sker fatale fejl i app’en, det er det der er indbygget i Google Play. Samtidig så gemmer jeg ingen data om brugere af app’en hvilket betyder at jeg ikke behøver en en datapolitik – der er ingen data at lave politik omkring. Så alt var okay, tænkte jeg.

Bortset fra at det var ikke okay. Når der sker en fejl og firebase laver en fejlrapport gemmer den en masse om brugeren af app’en. Det er ikke noget jeg bruger eller er interesseret i så det var ikke lige sunket ind hos mig. Så det var forkert når jeg troede at der ikke blev gemt brugerdata, og jeg derfor ikke havde brug for en datapolitik.

Løsningen burde jo bare være at slå fra at firebase gemmer en masse information om brugere men det kan ikke slås fra. I stedet blev løsningen at jeg har lavet mit eget system til at rapportere fejl så jeg har 100% styr på hvad der bliver gemt og ikke gemt. Og nu bliver der ikke gemt noget om brugere, så app’en er tilbage i Google Play. Men det kostede lige det meste af sidste uge.

]]>
tag:dagbog.atilb.dk,2013:Post/1345430 2018-10-02T14:04:00Z 2018-11-19T14:52:55Z Køge til København

Jeg arbejder stadig med at gøre app’en smartere omkring danmarks geografi. Jeg har nu al det data jeg har brug for (tror jeg) og er gået i gang med at få systemet til at fordøje det.

Det punkt jeg er nået til nu er at der findes steder – byer, bydele, øer, og nogle få andre – og stop er markeret med hvilke steder de ligger i. Det sidste jeg har lavet er at systemet har en forståelse af hvilke ruter der bevæger sig mellem stederne. Det skal stadig pakkes sammen så det kan bruges i app’en så der er noget vej endnu men jeg kan godt allerede nu lege lidt med det og få et indtryk af hvordan det vil fungere i praksis.

Ovenfor er nogle eksempler hvor man giver to vage geografiske steder: fra Aarhus til Viborg, fra Køge til København, og fra Samsø til Kalundborg. Selv om det er vagt er det nok til at systemet ved hvilke ruter der kan være tale om. (Det er ikke nødvendigvis helt korrekt – der kan være ruter der faktisk ikke går mellem de to steder – men de kan sorteres væk i det næste trin så der er præcis dem tilbage der er relevante)

]]>
tag:dagbog.atilb.dk,2013:Post/1345429 2018-09-27T12:08:00Z 2018-11-19T14:52:12Z Østerby, Østerby, Østerby

Efterhånden som jeg begynder at få integreret mere geografisk viden i det data jeg bruger bliver det osse mere håndgribeligt – jeg kan begynde at danne mig et bedre indtryk af hvordan det faktisk ser ud.

F.eks viser det sig at bynavne ikke, slet slet ikke, altid er en god måde at identificere steder i Danmark. Vi er ikke specielt opfindsomme når det kommer til navne. Der er f.eks 24 steder der hedder Østerby, 19 der hedder Sønderby, og så videre derud af.

Af ren nysgerrighed fik jeg lyst til at plotte Østerbyerne og se hvor i landet de ligger. Det første kort viser byer der hedder Østerby med rød og bydele i andre byer der hedder det med blå. Ironisk nok bliver der flere Østerbyer jo længere vestpå man kommer. De ligger osse overraskende tæt. Jeg tænker det måske skaber lidt forvirring at Østerby ved Stauning ikke ligger mere end 19 km fra Østerby ved Bølling? Nåja det finder de nok ud af.

Det at de fleste Østerbyer ligger vestpå gjorde mig endnu mere nysgerrig: er det fordi retningsbyer (altså byer med en kompasretning) gerne ligger i den modsatte r

etning? Måske hvis man bor vestpå er det med vest det normale, så det at ligge mod øst er usædvanligt nok til at det er det man opkalder byen efter? Eller måske er det bare populært i det vestlige Danmark at opkalde byer efter retninger?

For at afprøve det plottede jeg osse alle Sønderbyer. Hvis de gennemgående lå nordpå tyder det på at modsat-retning teorien holder. Hvis de gennemgående lå vestpå tyder det på at retningsbyer-i-vesten holder. Svaret var ret entydigt: Vestjylland er klart overrepræsenteret og Nordjylland er ikke. Så navne med retninger i er vist bare ekstra populære i Vestjylland.

Og så skal jeg have fundet på en måde der gør det nemt for folk at skille byer med det samme navn fra hinanden. Det er de to konklusioner jeg har kunnet drage indtil videre.

]]>
tag:dagbog.atilb.dk,2013:Post/1345427 2018-09-26T13:46:00Z 2018-11-19T14:51:14Z DAWA ❤️

Efter at have arbejdet på at kunne gå mellem stop sidste uge og begyndelsen af denne uge har jeg skiftet til at arbejde på en af de andre hovedområder jeg har på programmet indtil jul: stednavne. Helt kort fortalt går det ud på at i stedet for at sige at man skal fra Vejle Station til Odense Banegård skal man bare sige at man skal fra Vejle til Odense og så finde app’en selv ud af detaljerne, f.eks hvilke stop/stationer i de respektive byer man kan bruge til at komme det. Det er måske oplagt for Vejle og Odense men i mange tilfælde er det ikke – og selv hvis det virkelig er oplagt er det stadig alt andet lige nemmere. 

Det er ved at være noget tid siden jeg først dykkede ned i at løse det problem og jeg smækkede en hurtig prototype sammen som viste sig at virke virkelig godt. Det umiddelbare problem var at jeg havde brug for en masse viden om hvilke steder der findes i Danmark. Hvis app’en skal vide at der findes noget der hedder Vejle og Odense skal jeg have den viden et sted fra.

Det viser sig at den slags data kan man få fra Danmarks Adresse Web API (”DAWA”) som er en gratis service fra Styrelsen for Dataforsyning og Effektivisering, som er en ting jeg aldrig havde hørt om før jeg skulle bruge det. Der kan man få at vide præcis hvor alle byer er, og øer, og bydele, og lufthavne, og stort set alt af betydning i Danmark. Hvis man henter det hele fylder det omkring 85MB. Denne uge har jeg arbejdet på at hente data fra DAWA og massere det så det passer ind i det jeg skal bruge det til, nemlig at afgøre for et givet stoppested hvilket sted det ligger i. Screenshottet ovenfor er et eksempel på hvordan det ser ud nu jeg har fået hul igennem: du giver programmet en position og den fortæller hvilken del af Danmark, inklusiv by/bydel hvis det er indenfor en by, hvilken ø det ligger på. Man kan osse given en radius så selv om det ikke er indenfor et bestemt sted, hvis der er et sted i nærheden kan man få det at vide.

I det næste stykke tid kommer jeg til at arbejde videre på at få de data helt ind i app’en. Det virker måske som en triviel ting men ideen er at app’en selv bliver nødt til at forså de steder man rejser imellem på en tilsvarende måde til dem der bruger den. Så jeg tror det potentielt kan gøre en stor forskel i længden.

]]>