A til B dagbog

Hvor langt er du: flere eksperimenter

2019-07-16T09:37:30Z

Efter det sidste ikke 100% succesrige eksperiment med at gennemskue hvor brugeren er på en rute prøver jeg lidt flere ting. Næste forsøg har været at tage med i betragtning hvilken retning brugeren bevæger sig i. Det virker faktisk ret fornuftigt på de eksempler jeg har afprøvet.

Ruten jeg prøver her går fra København til Aalborg og i eksemplet fra sidst hvor der er forvirring omkring Vejle, hvis du bevæger dig i den rigtige retning kan den nu finde ud af at du er på vej fra Vejle mod Hedensted osse selv om du faktisk er tættere på en linje mellem Brejning og Vejle.

Omvendt hvis du bevæger dig i den modsatte retning af ruten er den om muligt mere forvirret end før. Sådan må det lissom være. Og i øvrigt hvis du sidder i et tog der kører den forkerte retning på skinnerne har du større problemer end at din app er forvirret.

Det løser dog ikke alting. Omkring Århus er der stadig et problem, dog et mindre nu end før.

Der skal nok noget mere snilde til plus for de ruter der kommer alt for vidt omkring mellem stoppene må man måske i sidste ende falde tilbage på at beskrive ruterne mere detaljeret så app'en ikke behøver gætte så meget.

Hvor langt er du: eksperimenter

2019-07-15T14:49:49Z

Jeg arbejder videre med at lave så man kan finde ud af hvor langt man er nået på en tur. Jeg har designet et første bud på hvordan man kan vise det i app'en,

Derudover leger jeg stadig med hvordan jeg rent praktisk skal afgøre hvor på ruten en bruger er når det eneste jeg ved er deres nuværende position. For at få et indtryk har jeg lavet en side hvor jeg kan tegne en rute ind på google maps og så beregne hvor på ruten systemet ville mene man er hvis man stod der hvor musen er. Det er lidt nemmere (og billigere!) end faktisk at rejse rundt i landet.

Udfordringen er at app'en ofte ikke ved præcis hvor en bus eller tog kører undervejs, den ved kun hvor de skal fra og til. Det vil sige at givet hvor brugeren er lige nu, som kan være langt væk fra den lige linje mellem sidste og næste stop, skal systemet give et bud på hvor langt de er mellem de to. Den tilgang jeg fandt på for et par uger siden virker sådan set okay langt hen ad vejen, når ruten ikke afviger alt for drastisk fra linjen mellem de to stop:

Men – kæden hopper desværre tit af. F.eks her kan man se at jernbanen fra Vejle til Hedensted faktisk kommer tættere på en lige linje fra Brejning til Vejle end fra Vejle til Hedensted, så på vejen fra Vejle til Hedensted vil systemet misforstå og tror du er mellem Brejning og Vejle. Ikke optimalt.

Endnu mere grelt er det i Århus hvor toget kører ind og ud af byen samme vej, så forvirringen er total.

Der er forskellige måder man kan håndtere det og jeg er ikke helt i mål med hvordan. En mulighed er at kigge ikke bare på hvor du er men hvilken retning du bevæger dig. Så kan man kende forskel på om du er på vej ind i eller ud af Århus, osse selv om sporene de to veje går lige ved siden af hinanden. En anden mulighed er at huske hvor du har været så hvis du lige har været i Brejning og Vejle er du nok ikke på vej tilbage men videre til Hedensted. En tredje mulighed er at tage med i betragtning hvor det er meningen toget skal være efter køreplanen men det er farligt for de kan både være for tidligt og for sent.

I sidste ende bliver det nok en kombination af tilgange. Plus i nogle tilfælde har man faktisk en mere præcis beskrivelse af ruten så man ikke skal gætte helt så meget.

Ny rutesøgning

2019-07-05T10:21:12Z

Jeg har brugt det meste af denne uge på at lave den nye måde at søge efter ruter på. Jeg kunne genbruge det meste af det jeg allerede havde lavet til den gamle måde men skulle bare strikke det sammen på en ny måde. Jeg tror jeg er det meste af vejen med det nu men det skal finpudses før det er helt klart. Forhåbentlig kan det komme ud med en opdatering næste uge.

Her er en demo af hvad det kan nu.

Fra og til

2019-07-02T12:43:32Z

I slutning af forrige uge blev jeg færdig (ahem, "færdig") med forbedringer til blinde brugere. Det sendte jeg afsted til afprøvning af nogle rigtige blinde brugere og resultatet var klart: det fungerer ikke super godt. Eller, det fungerer fint når jeg bruger app'en på min test maskine men anderledes og ringere når jeg gør det på min egen telefon og når mine test personer bruger den. Suk.

Samtidig viser det sig at det ikke kun er seende brugere der lige skal vænne sig til den måde man søger efter ruter men også blinde. Problemet er specielt at det er det allerførste nye brugere skal så det skal altså bare køre som smurt i olie. Og det gør det ikke. Så jeg er resigneret til at jeg kommer til at lave det om igen-igen, det bliver altså tredje forsøg. Jeg har i god ide om hvordan jeg gerne vil lave om og det burde forenkle det både i koden, for seende brugere og for blinde. Det er bare noget der kommer til at sluge noget tid.

Efter jeg var blevet "færdig" med forbedringerne forrige uge men før jeg vidste at det ikke fungerede var jeg hoppet med begge ben ud i nogle ret omfattende ændringer og dem har jeg arbejdet videre på indtil nu. Det er lidt langhåret at forklare hvad de består i men kort fortalt skrev jeg lang det meste af app'en om fra at være specifikt til android til at være lavet i C++ så det kunne bruges både på android og iOS. Der er dog stadig nogle få lommer af kode tilbage til android og en af dem er den kode der arbejder med bogmærker, hvilket betyder at C++ koden ikke kan få adgang til dem – de lever udenfor dens verden. Til noget af det næste jeg skal lave har C++ koden brug for at have den adgang så jeg har skullet flytte bogmærkerne fra android til C++. Det har så trukket forskellige andre ting med sig som har gjort strukturen meget enklere og mere generel, hvilket er super, men det har bare taget lidt tid. Det nærmer sig enden nu dog.

En ting der pludselig blev nem at lave var at vise hvor på en tur fra og til stoppene lå. Jeg har nu lavet det sådan at det bliver tegnet når man ser en tur, det er markeret hvor man skal stå på og af. Jeg ved ikke om det var det allervigtigste jeg kunne have lavet men når informationen nu var grydeklar alligevel tog det ikke lang tid at lave.

Jeg er lidt i tvivl om hvad det næste bliver jeg tager hul på men det kunne godt blive den nye måde at søge efter ruter.

Hvor langt er du?

2019-06-19T13:20:16Z

Jeg arbejder stadig det meste af tiden med at gøre app'en nemmere at bruge for blinde men er langsomt begyndt at kigge lidt fremad på nogle nye ideer. En af de ting jeg tænker måske at kigge på lidt senere på året er at få app'en til at kunne følge med i hvor langt du er på en rejse.

Jeg er ved den absolutte begyndelse af at finde ud af hvordan det skal fungere og der hvor jeg er startet er med at kigge på: hvis jeg kender din position og ved hvor en rute går hvordan finder jeg så ud af hvor på ruten det svarer til? Den tilgang jeg har forsøgt mig med i dag virker okay lovende. Jeg deler ruten ind i linjer mellem hvert par af stop der kommer efter hinanden og du finder ud af hvilke stop du er mellem ved at finde det linjesegment der er tættest på dig og så tage stoppene i hver ende.

Jeg har afprøvet det ved lave et lille program der kan tage et billede hvor der er indtegnet nogle linjesegmenter i forskellige farver og så tegner den de områder der hører til hver segment.

Der er lang vej igen men det ligner et sted at starte. Næste trin er at finde ud af: okay du er mellem de her to stop – men hvor meget af vejen mellem dem har du tilbagelagt?

Nærmeste færdig

2019-06-18T07:58:46Z

Bare en kort opfølgning: det er med i næste opdatering at man får vist de nærmeste transportformer først når man søger på ruter. Her er hvordan rækkefølgen er i Kastrup, Aarhus C, Frederikshavn og Ystad:

Nærheden mellemregninger

2019-06-17T10:27:37Z

Jeg blev færdig med koden til at kunne finde hvilke trafikselskaber og transportformer der er i nærheden i sidste uge. Jeg mangler stadig at binde det ind i brugergrænsefladen, det gør jeg i dag, men nu er funktionaliteten der i hvert fald sådan at hvis man giver et punkt og en radius kan man få en liste tilbage af hvilke trafikselskaber og transportformer er der i det område. De er sorteret efter omtrent afstand hvor omtrent betyder i værste tilfælde op til +/- 10 km.

For at checke om resultaterne ser rimelige ud har jeg prøvet lidt forskellige steder rundt i Danmark og er blevet overrasket et par gange. Her er et par eksempler.

Aakirkeby:

$ atb query_grid --type agencies --radius 50 55.070895 14.920060
+----+---------+------------------+
| id | dist_km | name             |
+----+---------+------------------+
| 0  | 0       | Bornholms Trafik |
| 28 | 0       | Rute700          |
| 9  | 15      | Mols-Linien      |
+----+---------+------------------+
$ atb query_grid --type route_types --radius 50 55.070895 14.920060
+----+---------+-------+
| id | dist_km | name  |
+----+---------+-------+
| 3  | 0       | BUS   |
| 4  | 15      | FERRY |
+----+---------+-------+

Mols-Linien på Bornholm? Det viser sig at den er god nok -- Rønne-Ystad er teknisk set Mols-Linien.

Skagen:

$ atb query_grid --type agencies --radius 50 57.724226 10.598802
+----+---------+------+
| id | dist_km | name |
+----+---------+------+
| 3  | 0       | NT   |
+----+---------+------+
$ atb query_grid --type route_types --radius 50 57.724226 10.598802
+----+---------+-------+
| id | dist_km | name  |
+----+---------+-------+
| 2  | 0       | TRAIN |
| 3  | 0       | BUS   |
| 4  | 35.3553 | FERRY |
+----+---------+-------+

Kun et trafikselskab men tre transportformer? Den er osse god nok, NT har både busser, tog, og færger.

Aarhus C:

$ atb query_grid --type agencies --radius 50 56.154194 10.214894
+----+---------+-------------+
| id | dist_km | name        |
+----+---------+-------------+
| 1  | 0       | DSB         |
| 3  | 0       | NT          |
| 7  | 0       | Midttrafik  |
| 10 | 0       | Arriva tog  |
| 6  | 29.1548 | Rejseplanen |
| 25 | 32.0156 | Samsø Bus   |
| 19 | 50      | Sydtrafik   |
+----+---------+-------------+
$ atb query_grid --type route_types --radius 50 56.154194 10.214894
+----+---------+-------+
| id | dist_km | name  |
+----+---------+-------+
| 2  | 0       | TRAIN |
| 3  | 0       | BUS   |
| 5  | 0       | TRAM  |
| 4  | 29.1548 | FERRY |
+----+---------+-------+

Ikke de store overraskelser der andet måske end at Samsø er tættere på Århus i lige linje end jeg ville have troet -- kun 30 km.

Frederiksberg:

$ atb query_grid --type agencies --radius 50 55.673477 12.521350
+----+---------+-------------------------------+
| id | dist_km | name                          |
+----+---------+-------------------------------+
| 1  | 0       | DSB                           |
| 4  | 0       | Movia                         |
| 13 | 0       | DSB S-tog                     |
| 14 | 0       | Metroselskabet                |
| 28 | 5       | Rute700                       |
| 17 | 5       | Gråhundbus                    |
| 12 | 10      | Movia                         |
| 23 | 28.2843 | Öresundståg                   |
| 22 | 40.3113 | Sporvejsmuseet Skjoldenæsholm |
| 6  | 41.2311 | Rejseplanen                   |
+----+---------+-------------------------------+
$ atb query_grid --type route_types --radius 50 55.673477 12.521350
+----+---------+---------+
| id | dist_km | name    |
+----+---------+---------+
| 1  | 0       | METRO   |
| 2  | 0       | TRAIN   |
| 3  | 0       | BUS     |
| 6  | 0       | S_TRAIN |
| 4  | 5       | FERRY   |
+----+---------+---------+

Nærheden

2019-06-14T09:21:34Z

Denne uge har jeg arbejdet på at gøre A til B nemmere at bruge for blinde. Det lyder måske langhåret men jeg fik en masse feedback sidste uge jeg går ud fra og det der skal laves om er ikke så omfattende som jeg havde frygtet. Det der er langhåret ved det er at selv hvis du ved hvordan du gerne vil have din app til at fungere er TalkBack på android uhyggeligt tungt at danse med.

Som en afveksling når jeg bliver frustreret er jeg begyndt at arbejde på noget jeg længe gerne har villet lave. Der er flere steder jeg viser lister af ting hvor det der er relevant afhænger af hvor du befinder dig i landet. F.eks transportformer: hvis du er i København er det typisk relevant at se metro, det er det ikke hvis du er i Århus. Tilsvarende er det typisk relevant at se letbanen hvis du er i Århus men ikke i København. Tilsvarende med trafikselskaber: hvis du er i Aalborg er det typisk mere relevant at se NT end Fynbus. Og så videre. Så jeg vil gerne kunne ordne listerne baseret på hvor du er.

For at kunne det har jeg brug for at vide hvad der er relevant forskellige steder i landet og kunne slå op, givet et bestemt sted brugeren befinder sig: hvad er relevant lige her. Min løsning er i store træk at lave nogle små, meget grove, kort som giver hvad der findes forskellige steder. Her er kortene for hvilke transportformer der findes, der er et for hver type:

De er, i rækkefølge, metro, tog, bus, færge, letbane, og s-tog. Tilsvarende gemmer jeg kort der giver hvilke trafikselskaber der er i hvilke dele af landet, her er et udsnit:

De er Samsø Bus, Arriva, Sydtrafik, DSB, og Movia.

Hvis jeg kan finde ud af at få det til at spille i forhold til at bede om den nuværende position (det er altid langhåret på grund af tilladelser og den slags) vil transportformer blive vist i rækkefølge i forhold til hvor man befinder sig. Trafikselskaberne bliver ikke brugt endnu men det kommer på længere sigt.

Klynger af stop

2019-06-05T07:45:36Z

I forbindelse med at jeg har arbejdet på at finde naboerne til et stop har jeg osse indført noget der hedder "klynger" af stop. En klynge er nogle stop i nærheden af hinanden der hedder det samme. Det er næsten altid par af stop, et på hver side af vejen, men ikke altid. Den største klynge er Slagelse St. (Ndr.Stationsvej) hvor der er 17 stop lige ved siden af hinanden der alle hedder det samme:

Problemet før var at når man søgte efter et stop fik man ofte flere og fordi de hedder det samme er det ikke til at hitte ud af hvilket der er det rigtige. Efter den næste opdatering bliver stop i den samme klynge ikke vist individuelt men kun en gang. Her er et eksempel på før og efter:

Det burde gøre det lidt nemmere at finde det man leder efter.

Naboer

2019-05-29T13:52:06Z

Jeg er gået i gang med at lave nogle nye funktioner i app'en. En stor del af arbejdet handler ikke om at tilføje noget som sådan men at få de funktioner der allerede er der til at virke mere hensigtsmæssigt. Men der er osse nogle nye ting man kommer til at kunne.

En ting jeg allerede har arbejdet med men som fortjener at blive gjort endnu bedre er at tage med i betragtning når man kan gå mellem stop. Lige nu er app'en ret striks omkring hvilket stop mener og kigger ikke altid på stop i nærheden. Det er jeg i gang med at gøre den lidt mere afslappet omkring.

For at kunne gøre det har app'en brug for at vide hvilke stop der er i nærheden af hinanden. Jeg kalder det at stoppene er naboer. Til det jeg skal lave er det nyttigt at vide for et givet stop, hvilke andre stop er der indenfor sådan rimelig gå afstand. Lige nu bruger jeg 1,25 km som radius – det er det man kan gå på et kvarter hvis man går 5 km/t. Der er i omegnen af 30.000 stop i Danmark og mange af dem, specielt inde i byerne, har mange naboer indenfor 1,25 km. Rekorden er Sankt Markus Allé & Vodroffsvej på Frederiksberg der har 149 andre stop indenfor 1,25 km. I alt er der 4,7 millioner "naboskaber", altså par af stop der er naboer. Jeg vil gerne gemme listen af naboer for hvert stop som en del af app'en for den er ret tung at beregne men 4,7 millioner er alt for meget – det ville fylde mere end hele resten af køreplanerne. Det jeg har arbejdet på denne uge er at løse det problem: hvordan gemmer jeg naboskaberne mellem stop uden at det fylder for meget.

Den løsning jeg er endt med at lave udnytter at når stop er i nærheden af hinanden har de gerne de samme andre stop som naboer. Det kan godt være Sankt Markus Allé & Vodroffsvej har 149 naboer og Danas Plads har 144 men fordi de ligger lige klods op og ned af hinanden er langt de fleste af de naboer de samme for de to. Måske 130 af dem er naboer til begge stop. Hvis jeg gemte en særskilt liste af naboer for hver af de to stop ville der være 293 i alt (149 + 144) men hvis jeg laver en liste med de 130 naboer de har til fælles og deler den mellem de to fylder det kun 163 tal (130 + 19 + 14). 19 er det antal stop Sankt Markus Allé & Vodroffsvej har ud over de 130 de begge har og 14 er det samme for Danas Plads. Det er en pladsbesparelse på næsten 50%.

Det har krævet lidt snilde at få til at virke og specielt at få systemet til selv at kunne genkende hvornår det er en god ide at dele naboer mellem flere stop. Men nu fungerer det og sparer så meget plads at det er realistisk at gemme nabo-listerne sammen med køreplanerne. Stoppet lige udenfor mit kontor bruger f.eks 3 delte nabo-lister som andre stop i nærheden osse henviser til.

Hvert screenshot viser en af de delte lister. De mørke stop er dem der indgår i listen, de lyse er andre stop der henviser til den liste. Her er et andet eksempel, det er et tilfældigt stop i Roskilde der osse bruger 3 delte nabo-lister

Meget af tiden når jeg arbejder på algoritmer går det op i meget abstrakte begreber: tal, afstande, afbildninger, scorings-funktioner, osv, ting der når jeg arbejder med dem ligger fjernt fra det praktiske problem jeg er i gang med at løse. Men når det så virker er det virkelig interessant at tage de løsninger algoritmen finder på og kigge på dem på et kort. Jeg kan ikke forklare præcis hvorfor der er tre delte nabo-lister lige der i Roskilde men det ser da meget fornuftigt ud.

Kosmetiske ændringer

2019-05-20T08:52:09Z

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.

Nyt android ikon

2019-05-14T09:30:15Z

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.

Brugerstatistik

2019-05-07T11:32:53Z

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:

hvad brugerne er interesseret i at app udvikleren ved
hvad udvikleren har brug for at vide
hvad udvikleren har lyst til at vide
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:

Mindst en gang på dagen torsdag den 2. maj 2019
Mindst en gang på dagen lørdag den 4. maj 2019
Mindst en gang på dagen søndag den 5. maj 2019
Mindst en gang i ugen der starter 29. april
Mindst en gang i måneden maj 2019
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.

Op ad bakke

2019-04-29T07:11:56Z

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.

Kontorhunden

2019-04-04T07:53:00Z

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.

"Attempt to read from null array"

2019-03-15T09:41:22Z

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.

"Opdaterede køreplaner"

2019-03-14T15:14:14Z

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.

Spam og selvpromovering

2019-03-13T16:58:23Z

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.

Video video

2019-03-07T14:24:53Z

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.

Et skridt tilbage, et skridt frem

2019-02-28T08:59:09Z

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.

Den rene og skære socialisme

2019-02-20T08:55:50Z

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.

A til B på en iPhone

2019-02-07T11:25:37Z

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.

Swift

2019-01-24T12:51:33Z

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.

Småting

2019-01-08T11:43:40Z

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.

Tilbage fra juleferie

2019-01-02T11:32:37Z

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.

Ny introduktion

2018-12-12T10:35:58Z

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.

Ny køreplan søgning launcher i dag!

2018-12-11T09:48:41Z

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.

Vælg stoppesteder live demo

2018-11-30T11:50:24Z

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.

Ny køreplan søgning live demo

2018-11-21T12:50:40Z

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.

Petitesser

2018-11-19T15:24:48Z

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.