I några år nu så har jag haft ett höjd-"histogram" under kartan i inläggen för cyklingen, jag har aldrig varit nöjd med utseendet på den, vet inte riktigt varför men japp, egentligen var det tänkt att jag skulle lägga till fler histogram; tex puls, tempo, i framtiden watt om jag skaffar kraftmätare osv osv, men eftersom jag inte gillade utseendet så har det inte blivit av att jag lagt till det, ville komma på en bättre design först Tänkte att jag experimenterar när det gäller utseendet i rodden sålänge, det har ju varit lite för lite info under rodd ändå, har ju bara haft sammanfattningen hittills; distans, tid, tempo, watt, puls, kalorier & nu har jag alltså lagt till lite histogram under + zon-info Jag gillar fortfarande inte designen 🤷‍♂️ Det är fult, tar för mycket plats osv osv, måste komma på någon bättre design för egentligen skall det tillkomma fler histogram både för rodd & för cykling, kommer bli ett jumla scrollande, kanske inte gör något, kan ju "toggla" fram datan i värsta fall också men då blir det ju ett klick extra om man vill se infon. Så, hur skall jag kompakta det utan att det ser trångt & kladdigt ut? Jag vill ha en minimalistisk design men ändå inte för abstrakt Dessutom är det ett extra problem med histograferna för rodd: graferna blir taggiga, det finns helt enkelt inte tillräckligt med datapunkter, när det gäller cykling så finns det 1 datapunkt per sekund & dom flesta av mina cykelturer är +2 timmar så då har jag ju minst 7'200 datapunkter att använda, fast det är för många så jag sållar bort dom flesta ändå, roddmaskinen däremot mäter bara var 3-5s (fast graferna i "ErgData" är mycket mjukare & "högupplösta" så det verkar som roddmaskinen faktiskt mäter oftare men att den sen inte sparar all data till .csv filen) + att jag tränar bara 20-30min så japp, det finns inte tillräckligt med datapunkter att göra en "mjuk" graf av, kanske får gå över till canvas eller svg 🤷‍♂️

Eller ja, jag har ju varit klar ett bra tag nu: Utvecklar tränings-segment, senaste månaden så har det mest varit att testa ifall allt fungerar som det skall, har inte helt litat på det, har dykt upp endel buggar sen jag trodde att jag var klar, edgecases & lite annat bröte, GPX parsern känns nu som ett lapptäcke med massa skräp i, den var ganska clean innan men nu när jag försökte baka in alla segment funktioner så...japp, hade nog varit bättre att göra om parsen helt från grunden & göra den mer modulbaserad, rör jag 1 sak nu så känns det som det påverkar allt annat, får se, kanske blir att göra om allt en vacker dag, iaf: En av mina favorit-segment (att kolla statistik på, inte att cykla) är: Dom första gångerna jag cyklade upp för den jumla backen snittade jag ~10km/h, mitt snabbaste är nu 17.6km/h, vilket kanske inte låter som någon stor förbättring men en ökning på 76% är ju helt okej för mig iaf & det gick ju åt en hel del ansträning när man vägde 110kg Det jag gillar mest är att första gången jag cyklade uppför backen så fick jag stanna 2ggr, helt utmattad & när jag kollade på Stravas KOM efteråt så var det någon tjomme som slängt sig uppför backen i över 30km/h, 2017 när jag bara klarade hålla 10km/h i den backen så var det ofattbart för mig hur någon kunde köra uppför backen i 30km/h när jag då t.om hade problem att ens komma upp i 30km/h på planbacke & denna personen hade alltså hållt det tempot i en ~4% backe (lutningen är alltid lite missvisande, några svackare partier "förstör" snittet), så ja, på den tiden trodde jag ALDRIG att jag ens skulle kunna hålla halva KOM-tempot, men ja, något år senare så passerade jag halv-tempot, tar nog något år innan jag snittar 20km/h, är ingen "klättrare" så japp, får se Det jag saknar på Stravas segment är per cykel info så det lade jag till, så att jag kan se mina bästa tider per cykel, vilken cykel jag använder kan ju ha stor effekt på resultatet, denna backen är ju bra mycket jobbigare med min 3-växlade damcykel som jag hade i början jämfört med mina "riktiga" cyklar. Så i tabellen på segment sidan kan jag se både dom absolut bästa tiderna & också se vilken placering varje cykel har; så den snabbaste tiden på min MTB kan vara på 6:e platsen totalt Tabellen kan vara lite förvirrande också: tex det är många rader i tabellen som har samma placering: tex det är flertalet #1 längst till vänster, det är lite förvirrande MEN den siffran representerar vilken position jag hamnade på vid just det träningstillfället, jag vill ju fortfarande kunna se det nu i efterhand, att jag satte mitt personbästa på en runda för 2 år sedan, räknar jag om siffrorna så går ju det förlorat, då är ju den informationen alltid borta. Listan i sig är ju sorterad efter bästa tid så det bör ju inte vara konstigt ändå, hovrar man över siffran med muspekaren så får man upp informationen att den siffran gäller för själva träningstillfället Iaf, nu är det mesta av segment-projektet klart; fattas bara några saker att göra; lite snyggare presentation med tex karta & bättre sammanfattning, just nu är det bara några tabeller som håller all data (vet inte hur jag skall mobilanpassa tabellen heller, för mycket data för att kompakta på 1 rad utan att ta bort data 🤷‍♂️), men det får duga sålänge, är lite halv-trött på detta projektet nu, får se när jag blir sugen på att fortsätta men nu är iaf det största arbetet avklarat 😅

Hujedamig vilket projekt, detta var ett sånt där typiskt projekt där man tror att det skall ta några timmar & tillslut visar det sig att det tar 10ggr längre tid än vad man tänkt Jag utvecklade en GPX parser 2019 & har sedan dess laddat upp alla(?) tränings-loggar men ända sedan jag har jag viljat lägga till segment också, det har alltså dröjt 3 år tills jag fick tummen ur 😂 Inför utvecklingen hade jag funderat på hur jag skulle gå tillväga, finns alltid 100 olika sätt att göra samma sak på så jag fastnade inte på bara en lösning, så bara att köra igång & testa, jag testade massa olika tillvägagångssätt & till slut landade jag på nedanstående, tror det är hyffsat optimerat, mitt första försök tog 500 databasanrop & 20s att parsa för en 1 timmes cykeltur, nuvarande implementering tar 2s & ~50st databasanrop, antalet databasanrop låter högt men jag gör 1 var 500:e meter; detta kan ökas rejält men just nu finns det ingen anledning när detta är något som görs 3-4 gånger i veckan på sin höjd, hade detta varit en kommersiell sida där detta körs flera gånger i sekunden så hade det varit en annan femma Att skapa själva segmenten var ju inget större problem; alla GPX filer är ju sparade efter att dom parsats så jag gjorde bara en tabell med alla träningstillfällen & använde dom för att skapa segment: Så; fyll i namn, klicka i "histogramet" för att välja start & slut long/lat & sen klicka på spara, efter det så går parsern igenom GPX filen & räknar ut segmentets distans, höjdmeter (upp & ner), genomsnittlig lutning osv osv (visar inte all information i segment tabellen, bara dom viktigaste), jag sparar resultatet i databasen + start long/lat & slut long/lat för att lättare kunna söka efter segment baserad på geografisk data. När jag laddar upp en träningsrunda så sparar jag inte några av datapunkterna i en databas, det är ju 1 datapunkt per sekund så det skulle bli några miljoner rader i databasen till ingen egentlig nytta, hade ju kunnat spara % 10 av punkterna kanske men äh 🤷‍♂️ Läs mer...

Så nu fick jag äntligen tummen ur & implementerade lite väderdata för siten, borde egentligen gjort det för längesedan men aja, nu är det gjort iaf Jag hämtar väder-information från: OpenWeather och använder datan på 2 sätt: 1) Hämtar nuvarande väder från min nuvarande position 1 gång per timme; temperatur, vindstyrka, vindriktning, lufttryck, vädertyp (regn, sol, molnigt osv osv), visibilitet, luftfuktighet & massa mer metadata 2) Hämtar historisk väderdata för varje mil på min cykeltur, sparar i princip samma data som i #1. Egentligen hade det nog räckt att använda datan från #1 men ibland kan temperatur & vind osv osv vara ganska lokaliserad så jag tänkte att datan blir lite bättre om jag hämtar data regelbundet under cykelturen, finns det ingen data för min position & tidpunkt så defaultar jag till datan från #1. Rätt kul att kunna följa historisk väderlek under cykelturen Så, vad är poängen med att hämta väderdata? Det viktiga är pga #2; temperatur påverkar cyklingen endel MEN det som har väldigt stor påverkan är vindstyrka, ibland har man så extrem motvind att det känns som att man står stilla, ibland kan det vara jobbiga att cykla i motvind än att cykla uppför den brantaste backen häromkring, samma sak med medvind. Så denna datan kan vara bra att ha för att lättare kunna jämföra mellan 2 olika cykelturer på samma sträcka, visst finns det många andra parametrar & variabler som påverkar prestandan men ja, ju mer data desto bättre Har bara cyklat 1 gång sedan jag implementerade detta: Det börjar bli höst (funderar på att köpa historisk data också, med mitt nuvarande konto går det "bara" hämta historisk data för 5 dagar bakåt i tiden men det går att köpa bulkdata för 40 år tillbaka i tiden också, så kanske gör det så alla mina cykelturer har väderdata, får se), lade till den genomsnittliga väderdatan ovanpå kartan, är inte nöjd med den designen, ser väldigt "billigt" ut, som något random påklistrat på kartan, skall se om jag kan putsa till det så det ser bättre integrerat ut, kanske ser bättre ut i framtiden för jag har tänkt att implementera en egen karttjänst när jag får tummen ur, inget fel på kartan nu men tänkte byta till en mer "abstrakt" kart-design, istället för en bild som är ihopbakad av "tiles" så tänkte jag använda mig av SVG lines istället, mycket mindre data, kommer inte ha någon terräng-info, inte till att börja med iaf, utan bara ha kvar den röda linjen som är på nuvarande kartan (fast linjen kommer var svart istället), sen några enstaka stads/by-namn på kartan med kanske. Varför byta karta? Jo, tänkte implementera ett system för att skapa egna segment, så som Strava har, så jag kan jämföra PB:n osv osv & då kommer jag nog inte orka utveckla ett eget tile-system så då får den "abstrakta" kart-designen duga. Det låter som att detta kommer bli en rejäl försämring mot nuvarande karta men så som jag tänkt ut det i huvudet ser & fungerar det faktiskt helt okej, tror inte det blir någon direkt försämring, jag har inget direkt behov av en detaljerad karta... Aja, onödigt mö text men men....

Marknadsföring förstör mycket för mig, alla minns väl när "molnet" blev ny trend-ordet som spammades sönder i all marknadsföring från ALLA IT företag trots att ingen av deras infrastruktur förändrades, samma med AI & ML för massa år sedan, såfort marknadsförings-avdelningen fick nys om dom nya trend-orden så spottade dom ur sig det all marknadsföring trots att inget i deras företag förändrades, vissa gjorde precis som den där "AI/ML if statements memen" & påstod sig erbjuda tjänster som byggde på ML & AI trots att inget i deras stack hade någon som helst med AI/ML att göra När det sker & man matas med vilseledande marknadsföring så tappar jag alltid intresset av den äkta varan, tyvärr, för AI/ML är ju faktiskt något roligt att jobba/experimentera med & senaste åren har det ju tagit rejält med fart inom detta segmentet & numera är det ju något som i många fall är väldigt användbart, så det är dags att ta sig en titt på det, kommer inte djupdyka i det då många implementationer som jag faktiskt vill använda "kräver" en GPU vilket jag inte har, eller kräver gör det ju inte men vill man inte vänta 384893473983 miljarder år på resultat så... Så, det är en hel djungel av AI/ML verktyg där ute men dom senaste åren har jag tittat mest på YOLO, verkar vara det som är mest intressant för mig så tänkte börja lära mig det genom att implementera det på denna hemsidan, tänkte i början använda det för att auto-tagga bilder som också kan användas till att söka efter bilder osv, får se vad mer det blir i framtiden Så som sagt har jag ju tyvärr inte tillgång till en GPU med CUDA så tyvärr får jag köra YOLO med CPU vilket inte är helt optimalt, speciellt när webbserverns CPU inte ens har AVX så jag har ingen hårdvaru-accelerering av YOLO så tyvärr kan jag inte träna nätet på mina egna bilder då varje iteration med min CPU tar mellan 10-20 sekunder & med tio-tusentals iterationer om jag vill ha ett dussin egna klasser så skulle detta ta en evighet, skulle gå åt 100% CPU i flera veckor på min slöa webbserver så istället valde jag att använda färdiga vikter & efter att testat YOLOv4(light), Open Images, YOLO9000 osv osv så valde jag tillslut YOLO9000, alla har sina styrkor & svagheter men YOLO9000 blev den bästa kompromissen för dom bilderna jag för tillfället har laddat upp. I en perfekt värld; om jag haft en GPU så hade jag använt både YOLOv4 & YOLO9000, men nuvarande lösning får duga sålänge Får ju ganska vettigt resultat, ibland hittar den lite fel objekt i bilderna: Men på dom flesta av mina bilder blir det ett väldigt exakt resultat, om än ibland lite väl lågt förtroende: Så, YOLO9000 är väldigt säker på att bilden innehåller en cykel, den klassar också cykeln som en mountainbike, om än med bara 55% säkerhet, den har rätt men ja, den är inte så säker på att den gissat korrekt Spenderade väldigt mycket tid med att experimentera med width/height också vid detection för med rekommenderade 608/608 tar ungefär 10-15s per bild för igenkänning & för tillfället har jag ju över 2'000 bilder så det kommer ju ta en stund att auto-tagga alla bilder, minst 5-6 timmar jämfört med 10-20s om jag hade haft en hyfsad vettig GPU, extremt stor skillnad mellan CPU & GPU, 0.1 fps jämfört med 100-300 fps, men iaf, så 608 ger ju bäst precision så tillslut fick jag välja det, testa många multipler av 32, ända ner till 320/320 vilket gjorde att igenkänningen tog så lite som 1-2s per bild men precisionen blev lite väl lidande Det dumma är att på vissa bilder, speciellt på syrrans Grand Danois så var 512/512 bättre, det var mycket oftare som den kände igen korrekt ras MEN med 512/512 på syrrans Old English Sheepdog så blev resultatet absurt, blev helt fel ras, ibland helt fel djur också; oftast ett får ;) Det är ändå imponerande hur exakt ML har blivit, bästa vore ju att träna med YOLO på mina egna bilder men att använda färdiga vikter duger gott för tillfället, tex, när man tänker på det så är det ju ganska otroligt att det går att få detta resultatet: Så, ja, det är en kompromiss, vilket "nät"/vikter man skall använda & vilken storlek på detekteringen, som sagt, bästa hade ju varit om jag tränade mitt egna men tyvärr, får vänta tills jag skaffat en vettig GPU Har bara kört igenom några av mina befintliga bilder, det tar ju som sagt 5-6 timmar att köra igenom hela mitt bibliotek så jag tar en bild lite då & då istället, alla nya bilder kommer gå igenom YOLO direkt när jag laddar upp bilden så alla framtida bilder kommer åtminstone auto-taggas Kollar man på bilderna i singelvy så dom bilderna som processats av YOLO har en liten ML ikon längst uppe till höger, går klicka på ikonen också för att se vilka objekt som YOLO hittat, det skapas också taggar efter dom taggarna som jag vanligtvis lägger in, dom taggarna som är genererade med YOLO har ett "!" framför taggen

Detta börjar bli lite överdrivet, vad ska man med all statistik till? Troligen ingenting men ändå är det lite intressant att se ens träningsstatistik, jag hade ju redan lite statistik på #cykling (distans per cykel & totaldistans) men tydligen ville jag ha mer så jag fixade en dedikerad sida för cykling Har inte lagt in så mycket än, skall fixa in mycket mer så man får en överblick likt Stravas profilsida med genomsnittlig distans per vecka, tid per vecka + massa annat men detta får räcka sålänge: har lagt in så jag kan se dom 3 längsta turerna, dom 3 "högsta" turerna, fixade in ett stapeldiagram också där jag kan filtrera träningen efter vecka osv, skall utöka det också så man kan filtrera per år, per månad, per cykel, per allt... Sedan GPX Parser inlägget har jag fortsatt laddat upp min backlog av cykelturer men det tar ju en evighet men har åtminstone kommit fram till mitten av 2019 nu så det är ju inte SÅ långt kvar till dagens datum, får försöka få tummen ur & fixa det en kväll så statistiken blir komplett 👍

Har spenderat några timmar senaste dagarna med att utveckla en GPX/GPS parser, har ju börjat cykla en hel del & använder endel träningsrelaterade hemsidor för att logga min träning men vore ju roligare att ha allt samlat på min hemsida också, hade inget bättre för mig just nu heller så tänkte att detta kunde vara ett kul projekt När man använder träningsappar eller cykeldatorer som loggar GPS så kan man hämta ut en GPX fil som loggar 3 datapunkter (4:a om man är petig); latitud/longitud, m.ö.h & tidpunkt & utifrån detta kan man räkna ut nuvarande hastighet, medelhastighet, maxhastighet, distans, lutning, klättring osv osv. Min cykeldator loggar även endel extra metadata om dom är tillgängliga på rundan; temperatur, kadens, puls osv Så, detta var egentligen inget svårt projekt, "bara" att parsa alla datapunkter & spara resultatet & beräkna mellan varje datapunkt MEN problemet är att GPS data är inte så exakt som man tror, eller jo, i 99% av fallen så är det ganska exakt men ibland görs det ganska ordentliga felmätningar som sparas så använder man bara rådatan i sin parser så kan det snabbt bli ganska fel, tex så dyker det ibland upp GPS jitter eller drift som gör att 2 mätpunkter som har 1 sekunds mellanrum kan fluktuera i distans ganska rejält, speciellt när det är dålig GPS täckning, så om GPS:en tappar täckning helt så kanske mätpunkten är 100 meter bort & är då mätningarna med 1 sekunds mellanrum så motsvarar det en hastighet på 360km/h (mitt rekord är 28'700km/h) & riktigt så snabbt cyklar jag ju inte så dessa mätvärden måste identifieras & därefter kasseras Så efter man implementerat en parser som använder all rådata från GPS:en så måste man börja filtrera eller helt enkelt kasta bort datapunkter som har absurda värden, vissa scenarion är väldigt enkelt att identifiera men ibland dyker ett absurt scenario upp som ens filter för tillfället inte kan identifiera & så får man implementera det scenariot också & varje gång man tror man täckt in allt så laddar man upp en till GPX fil som man testar emot & så visar det sig att även den har ett absurt scenario som inte täckts Just nu gör jag bara jämförelse mellan nuvarande datapunkt & föregående datapunkt (eller upp till 5 punkter bakåt om algoritmen börjar identifiera en "klättring"), vilket är så man får fram distans, hastighet, lutning, höjdskillnad osv & oftast är detta tillräckligt för att hitta felmätningar & absurda scenarion MEN det finns utrymme att förbättra i framtiden när jag har lust, tex att göra beräkningarna på hela block, tex om man gör ett block som är 10 mätningar långt så är det lättare att hitta avvikande datapunkter. Vill man ta det ett steg längre så kan man expandera detta till överliggande block, kör man separata block så hittar man inte felmätningar mellan sista mätningarna i första blocket & första mätningarna i andra blocket så implementerar man överliggande block så kan man även hitta dessa fel. Men det är får bli ett projekt i framtiden, att jämföra 2 (5) mätpunkter är tillräckligt exakt för tillfället Så, algoritmen blir bara mer & mer avancerad för att kunna filtrera bort det mesta & bara spara dom datapunkterna som algoritmen anser vara korrekt. Så mer jobb än vad man först tror, att beräkna på rådatan var enkelt men väldigt missvisande så ja, det tog lite tid att hitta alla "fel", jämförde med Wahoos egna beräkningar, jämförde med Strava & kollade även på Lantmäteriets kartor för att se så att min algoritm stämmer så bra som möjligt & efter typ 20 iterationer så är Wahoo, Strava, Lantmäteriet & min parser inom några få % gentemot varandra, oftast under 1% när det gäller alla mätvärden (distans, klättring, tid, snitthastighet osv osv), eftersom jag såklart inte har tillgång till deras algoritmer så är det ju svårt att veta vad som skiljer oss emellan men våra värden är väldigt lika, skillnaden kan vara något så enkelt som avrundande värden, tex mina datapunkters beräkningar har en precision på float(6) medan dom andra kanske har en precision på 2 decimaler eller kanske bara beräknar på ints, vem vet, spelar inte så stor roll egentligen, allas värden är "fel" ändå I början testade jag bara GPX filer som producerats av min Wahoo Elemnt Bolt & fick mätvärden inom 1% av ovanstående men sen när jag laddade upp GPX filer som skapats av en iPhone så fick jag helt absurda mätvärden, GPS:er i telefoner är tydligen extremt värdelösa, antagligen för att vara så energisnåla som möjligt & dessutom har dom ganska dåliga antenner så GPS mottagningen är relativt dålig. Så när jag upptäckte det fick jag anpassa algoritmen för iPhone datan också så som sagt, algoritmen blir bara mer & mer avancerad för att täcka in alla scenarion. En GPS enhet är sjukt mycket mer exakt & har striktare uppdaterings tidpunkter, min cykeldator har även barometer för att mäta höjdmeter så ofta har en dedikerad GPS enhet fler sensorer för att få pålitligare data, speciellt i jämförelse med en smartphone Sen har tex Strava endel konstiga egenheter, min Bolt har också endel av dessa egenheter; tex så är deras threshold vid lutning/klättring ofta satt alldeles för låg så ofta när man cyklar på väldigt små lutningar så registreras det inte att man "klättar", det är ofta jag är ute & cyklar & det är uppenbart att jag cyklar uppför i en lutning på kanske 0.5% men dessa kastas bort av dom, ganska frustrerande, ibland kan man cykla jämte en väg, sen upp på en "påfart" & upp på en bro som är över den vägen man precis cyklade på, så säkerligen minst +6 höjdmeter men eftersom påfartens lutning var så låg så kastas dessa mätningar bort. Jag har dock valt att sätta min threshold lite lägre än vad Strava & Wahoo gör då jag anser att även om det lutar ganska lite så är det markant tyngre när man är ute & cyklar & därför tycker jag att den typen av klättring skall ingå i den totala klättringen. Det är ju inte så att min parser resulterar i mer klättring ändå då detta bara handlar om några få meter men ja...Ibland visar min totala klättring även mindre än dom andra, det beror helt på scenariot & vad man anser är "klättring": Så vad innebär "klättring" egentligen, använder man bara rådatan från GPS:en & lägger till höjdskillnaden i sin klättrings-"pool" så kommer man få alldeles för höga siffror, tex kan GPS:en mäta ett litet gupp som har en höjdskillnad på 0.2 meter, såpass exakt är den ibland, skall man ta med ett gupp? Visst, det är en höjdskillnad MEN man har ju egentligen inte använt någon energi för att ta sig över guppet, kommer man i 30km/h så kan man säkert rulla över en 4 meter hög kulle utan att använt någon nämnvärd extra energi så i min algoritm (troligen i Stravas & Wahoos också då dessa ger snarlika resultat) måste vissa kriterier uppnås för att anses som "klättring", så små gupp & små kullar sållas bort & istället tar jag bara med backar som man faktiskt måste trampa för att kunna ta sig uppför, först då läggs höjdmetrarna i klättrings-"poolen" Finns mycket mer att säga om detta projektet & hur alla våra plattformar hanterar GPS datan men redan nu är detta inlägget alldeles för långt så får ta en mer djupdykning om ämnet i framtiden På #cykling går det att se resultatet av projektet. Lade till "cykel" också som utrustning för träningen så jag kan se hur långt jag cyklat på respektive cykel. Har inte hunnit lägga in så många än, när detta skrivs har jag bara hunnit fram till mitten av 2017, ett år då jag inte cyklade så mycket, 2018 cyklade jag ännu mer så det är sjukt mycket som måste laddas upp, över 250 totalt så det kommer ta ett tag, aja, har lite att göra framöver

Nu fick jag ju lite press på mig att faktiskt visa upp något, så här kommer den hemliga funktion 3 (det kommer att bli ett antiklimax för dom flesta tror jag) Skrev att funktion 3 var påväg i mitt förra inlägg: Att utveckla en fönsterhanterare till Linux & nu har jag suttit & knåpat lite på den Så funktion 3 är en inbakad version av HTCondor, eller ja, snarlikt koncept, dock kör jag utan schemaläggare eller kö, allt körs "live", ej distribuerat/klustrat (än), en dator åt gången per process nöjer jag mig med just nu. Man kan också beskriva den som "x11vnc" fast utan vnc delen & bara input injection delen, jag är en flitig användare av x11vnc MEN mitt stora problem är att ifall jag använder lösningar baserad på frambuffer så funkar det skitdåligt då jag ofta sitter på 4g & 3g uppkoppling med väldigt tvivelaktig uppkoppling & begränsad bandbredd, då är det inte så roligt att hålla på & polla från en framebuffer & slösa bort den lilla bandbredden man har & eftersom x11vnc ändå implementerar en injection lösning för input så varför skicka framebuffer när man lika gärna kan köra hela fönstret lokalt & bara skicka kommandona till remote datorn som kör den relevanta processen ändå? Det blir mycket "billigare" bandbreddmässigt att bara dela input + data (return från remote process) istället för framebuffer Funktion #3 hör ihop med funktion #2, all data är delad mellan alla datorer (om inte data-policyn säger annat men då får man hålla koll på att den processen man kör inte använder osyncad data, rörigt förklarat, går in mer på policy i framtiden), detta gör att alla "remote" processer körs lokalt men kan flyttas mellan vilken dator som helst, det spelar egentligen ingen roll på vilken dator en process körs på, processen går att nå från vilken dator som helst (hade ju underlättat om man kunde använda samma PID på alla datorer så man slipper mappa olika PID som är "samma" process mellan dom olika datorerna, har någon en lösning på att tvinga fram en PID så säg till) Så kör jag ett program lokalt, tex "Writer" så fungerar allt precis som det gör på alla datorsystem, programmet öppnas & startar diverse processer. Medan programmet körs kan jag välja att programmet skall köras på en annan dator i nätverket, all data från processen sparas i ett "middleware", sen spawnas (eller använder en befintlig process om den finns tillgänglig & "tom") en likvärdig process på remote host:en (en annan dator i nätverket alltså), den nya processen mappas till den processen som sparades (middleware agerar som en translator mellan olika men samma process (hur illa förklarar jag egentligen? )) & därefter kopieras all process data till denna nya processen på remote host:en. X öppnar inget fönster på remote host:en utan endast en dolt process då ett fönster inte behövs, detta är som sagt ingen VNC lösning Förväxla inte detta med X över nätverk heller, inte samma sak Därefter skickas all interaktion med det lokala fönstret till remote processen (fönstret körs fortfarande lokalt till skillnad från VNC lösningar men skickar viss userinput (ej musrörelser & endast interaktion med GUI:t som resulterar i ny data) till den externa datorns process & därmed kan den externa datorns processorkraft användas istället) (Liten demonstrations-film, filmen är rätt suddig, körde skräpet i en VM på macOS där jag kör en skalad upplösning, glömde av att ändra, så macOS skapar någon obskyr upplösning för att visa 1920xXXXX, så när jag spelade in skärmen via macOS så blev filmen i upplösningen 3686x2304 såååååå, jag, det blev som blev, hoppas det är okej, spelade in typ 10ggr innan skiten slutade krascha så vill inte göra om) Edit igen: I filmen nämnde jag (tror det var denna jag nämnde det i) att webbläsaren också går att köra remote, det stämmer inte riktigt, det GÅR men det är för tillfället inte användbart, kör man remote så går det inte klicka på länkar, har inget sätt att få tillgång till länkarna & skicka data emellan processerna, i mina egna program skickas datan till remote-processer vid UI:event, men skit samma, man kör inte webbläsare remote ändå, eller jag har inte kommit på någon vettig anledning att göra det iaf Varför? Enkla svaret är lätt tillgång till andra datorer i nätverket, istället för VNC, SSH eller andra lösningar, förenklad delning av data. Tex jag jobbar ofta på min bärbara som går på knäna när jag kompilerar stora projekt, här är det superenkelt att flytta över kompileringen till en annan dator i nätverket så jag kan jobba vidare lokalt utan att störas av resurserna kompileringen kräver Encoding är ett annat svar, eftersom all lagring är syncad (med den policyn jag kör nu) så är det lätt att dela upp jobb mellan dom datorerna man har tillgänglig om man vill, finns ju andra (bättre) lösningar som är klustrade, tex Compressor & jag tror Adobe också har något liknande, men licenskostnad & ibland krånglig setup osv, man kan komma undan med att bara skicka iväg lite ffmpeg jobb istället Andra saker när den lokala datorn inte har resurser nog (få CPU kärnor & för lite ram), kör det remote på en biffigare dator istället Till skillnad från VNC lösningar såsom x11vnc så kopplar man inte upp sig till ett remote fönster utan man kan flytta en process mellan alla datorer man har tillgängliga, programmen är alltså INTE låst till en dator på sättet som VNC lösningar används till Tusen andra användningsområden (visar lite andra exempel såfort jag knåpat ihop lite relevantare program). Många (alla) användningsområden finns det redan lösningar på men har alltid viljat ha det inbakat direkt i OS:et Känns som jag behöver gå igenom systemet mer genomgående framöver, tror inte jag förmedlade dess styrkor tillräckligt bra i detta inlägget

Har kört Linux lite av & till dom senate 15 åren, lite hat-kärlek, senaste åren har jag dock börjat köra det lite mer & framförallt börjat gilla tiled-WM såsom i3 & bspwm & är numera inte jättelångt från att köra dom som main, kör mestadels Ubuntu + i3 nuförtiden (utöver macOS då) Jag har 3 funktioner som jag ända från det att jag upptäckte Linux första gången till dagens datum hela tiden har hoppats på att någon skulle implementera men verkar inte som om någon kommer göra det, så dags att kavla upp armarna & utveckla dessa på egen hand istället Kommer bara utveckla fönsterhanteraren i Debian & kommer bara se till Debian distros stöds då det i princip bara är dessa jag använder men bör vara kompatibelt med det mesta, får se Funktion 1: En slags "Viewport scroll" så ens arbetsyta består av en virtuell yta som är bredare än skärmen man använder, så, när man sitter på en liten skärm, tex på en bärbar så kan man placera sina program/fönster sida vid sida på samma sätt som med en ultrawide skärm, sen antingen använda tangentbords-genvägar eller trackpad för att scrolla i sidled. Man kan också placera dessa strategiskt så man, hmm, ser mer än vad man ser när man glor på en statisk skärm, går inte förklara, kanske syns på videorna, eller får nog göra en separat film för att förklara, men går öka sin produktivitet om man lägger upp sina fönster med lite tanke bakom...aja Jag är medveten om att detta inte är något som många är ute efter, kanske t.om ser krångligt ut & saknar funktion, men när jag arbetat med det så tycker jag det fungerat smidigt, tex när man har flera dokumentationer öppna & flera IDE fönster öppna samtidigt, slipper man öppna massa tabbar å skit, bara att hoppa mellan fönstrena istället & slipper man ha flera fönster stackade ovanpå varandra också Tiled med gaps (trasig margin dock, skall fixas) "Exposé" liknande funktion där man ser en överblick över hela sitt virtuella område, virtuella ytan är 10ggr bredare än skärmens fysiska upplösning, finns "Spaces"/"Workspaces" också så 10ggr bredare per "workspace", så ganska mycket yta att placera sitt skräp på, får att få plats med dessa fönster som demonstreras här med ett mer traditionellt upplägg så skulle man behöva lägga alla fönster ovanpå varandra, mycket lättare (när jag testat iaf) att komma åt det man vill komma åt när inte allt skräpa är staplat på varandra...svårt att göra det rättvisa på bild & video men sidoscrollen är faktiskt ganska smidigt. (nej, trackpad är inte ett krav, bara att tabba fram till sitt fönster, klicka på app ikonerna i "menubar":en längst upp i mitten eller scrolla med tangentbordet) Funktion 2: Kommer inte beskriva den i text här, gjorde en video tidigare idag (skitdåligt filmat, hatar min röst, tror min röst hörs, satte ljudet på mute när jag redigerade filmen då jag hatar att höra min röst men antar att filmen har ljud, låter skitlöjlig & hatar att vara med på film så själva demonstrationen är inte direkt imponerande men tror det framgår rätt tydligt vad funktionen är ändå) Detta är en funktion som jag sett fram emot VÄLDIGT länge, jag skiftar dator flera gånger per dag & hatar att synka GIT, positionera fönster & skit, jag vill bara sätta mig framför datorn & börja precis där jag slutade, oavsett vilken dator jag för tillfället använder Hatar att höra min röst :S Funktion 3: Lite hemlig just nu, håller på & utvecklar den nu men hoppas kunna visa upp ett demo om ett par veckor Framtiden & mini FAQ: Beror lite på, om någon här ens är intresserad av denna projektloggen, tänkte att folk som är intresserade också kunde komma på någon idé eller förslag; något ni saknar i operativsystemet/skrivbordsmiljön/fönsterhanteraren ni använder nu så säg gärna till så får vi se om den går att implementera Ni kanske också tänker att "Fan, *suck*, ännu en fönsterhanterare", & ja, jag håller med, för tillfället kommer jag fortsätta utveckla denna skrivbordsmiljön/fönsterhanteraren men det är bara för att testa lite olika idéer, se om det fungerar som det är tänkt så till en början kommer det vara en egen fönsterhanterare, dock hoppas jag, när denna börjar bli klar kunna implementera åtminstone funktion 1 & 2 i i3 istället, har kollat i i3 dokumentationen & det kan vara svårt att implementera dessa funktioner, speciellt funktion 2 då det inte är helt uppenbart hur man skall plocka ut datan från programmen men förhoppningsvis går det att lösa på något sätt, vi får se! Kommer inte lägga upp detta projektet på github (eller liknande) eller dela med mig av koden nu till en början (har gjort det på tidigare projekt & trots att jag säger till personer upprepade gånger att koden inte ens har alfa-status & jag inte kommer agera support så dyker det upp massa folk ändå & tjatar om support & annat skräp, sen klagar på när det inte fungerar & hur instabilt det är (no shit, det är ju inte ens avsett att användas annat än som experiment), har inte tid med det). Kanske om några månader när jag fixat en lättare installations-process kan jag nog dela med mig koden & lägga upp på GIT, men då krävs det att personen förstår vad detta projektet är, kommer aldrig vara avsett att köras på sin main & kommer inte ha någon support överhuvudtaget, detta är mest ett experiment & hobby För tillfället är detta tiling + float. Tanken är att aldrig behöva använda mus men självklart går det om man vill Varför? Kul grej bara, skönt att ha ett avbrott mellan dom mer seriösare grejerna man utvecklar, har börjat störa mig på hur tungrodda många operativsystem/fönsterhanterare är nuförtiden, känns bara ivägen & skapar frustration, kommer fokusera mest på att underlätta för oss programmerare så detta kommer bli en fönsterhanterare för programmerare & folk som skriver mycket Tidsplan? Ett evighetsprojekt antagligen, detta handlar om år. Detta kommer inte vara något jag jobbar fulltid med så kommer fokusera mest på dom projektet som ger mig tak över huvudet & mat för dagen, vilket detta projektet inte göra. Men kommer åtminstone försöka få till synbara uppdaterar minst 1 ggr i veckan

Så, börjar snart bli klar med "Flappy Andersson", fattas bara lite roliga bilder på spelarna & lite andra bilder till "poängstjärnor", tänkte det vore roligt att kasta in massa roliga bilder i spelet mellan pelarna, lite slumpmässigt & om spelaren träffar en av dessa stjärnor med dom roliga bilderna så får dom 5 extra poäng. Men iaf, först, fixa in morsans, Mias, farsans & mitt huvud i spelet istället för fågeln Ser lite skumt ut men vafan, detta är ju inte tänkt att vara det absolut i särklass bästa spelet ever utan bara en rolig grej som jag kan ge bort på julafton :P Har fixat ihop lite statistik osv på servern, PHP & Redis, passar riktigt bra till just statistik & highscores. Problemet är att Swift, återigen, har sina egenheter som gör saker svårare än vad det skall vara. Tex så får jag ju JSON från servern som sen skall behandlas i Swift, men vanilla Swift hatar JSON, speciellt när man stackar JSON "arrayer", då får man hålla på & unwrappa hur många gånger som helst i Swift & råkar man unwrappa en NIL så krashar spelet, tack för det. Gör man samma sak i PHP så ignoreras bara "felet", eller ja, kanske inte ignoreras men värdet blir då NULL istället & man kan fortsätta köra vidare i sitt program. Helt idiotiskt att Swift krashar spelet, den borde bara skicka ett felmeddelande istället. Men nepp, man måste på egen hand programmera in error handling, det blir ganska snabbt överdrivet stort när man bara vill hämta lite highscores från en server. Så, att behandla JSON i PHP tar bara ett par rader jättekort kod, i Swift tar det 19203920 miljarder rader & lika mycket kod som i bibeln, till ingen nytta. Så SwiftyJSON till räddningen, SwiftyJSON är PRECIS så som Swift borde varit från första början, sköter felhanteringen helt på egen hand utan att man behöver oroa sig allt för mycket.