Jump to content

morten7

Medlemmer
  • Content Count

    192
  • Joined

  • Last visited

Community Reputation

156 :)

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Antar basert på egen erfaring at mer enn 90% av det offentlige har egne ansatte og konsulenter som sitter såpass tett på at de har et forhold til det. Men igjen, er det verdt å spare 200kr i strøm i året ved å bruke 50timer ekstra, på noe som lever i 5-10år? Når det kommer til Python er det svært raskt og enkelt å prototype i mot Java. Koden som kjøres blir kompilert til C og ved neste kjøring er det C-koden som benyttes. Også vanlig å optimalisere Python både å bruke tillegg og ved å bytte ut delene som er CPU-krevende med C-kode. Eksempelet i artikkelen bør sånn sett ikke leses som at bør velge noe annet enn Python, men ha et forhold til DevOps (som de aller fleste allerede har). Ikke noe nytt med andre ord.
  2. Tok en rask titt på Volvo, og det er enkelt å se trafikken til appen der også og greit API. Bruk løsninger som Charles proxy (koster litt, men enkelt), MITMproxy (versjon 2 er enklere enn de nyere), SSLstrip i kombinasjon med Wireshark..
  3. Alt av apper på en Android/iPhone er i 99% av tilfellene enkelt å integrere i mot. Selv testet VW og Toyota sin. Pleier å trekke trafikken til/fra alle appene jeg installerer på telefonen, og det er noen hundre nå så sjeldent noe unntak. Så ingen kred fra denne kanten for å gjøre en dårlig jobb. Vurderer å bygge noe nytt for VW Golf sin app også, en app som låser seg hvis man gjør et par kall for mye i deres egen app. Når det kommer til å nekte bruk er det faktisk ikke noe de kan gjøre. I EUs Databasedirektiv og i EU sin utgave av Åndsverksloven (som vi følger) heter det seg at alt en bruker kan skaffe seg tilgang til også skal kunne automatiseres. Står så eksplisitt at selv om selskaper skriver at dette er strengt forbrudt i appen, så er slike avtalemessige begrensinger «null and void» og avtalen opprettholdes ved at disse kravene fravikes. Toppel opp til EU som tenker langsiktig på at alt som kan automatiseres og bygges videre på skal kunne bygges videre på.
  4. Kahoot! het i starten MobiTroll og prøvde å lage en interaktiv løsning for publikum som satt å ventet før kinoen startet. Det som gjorde de store tror jeg var at de itererte og turte å følge det kunden ville ha, selv om det var å forkaste den gamle ideen.
  5. Tror ikke det er samfunnsøkonomisk lønnsomt å flytte de som har hyppig dialog med andre etater og eksterne utenfor byen. Kanskje noen lokale gevinster, men det taper seg for samfunnet som helhet. Mer bekymret over at dette bygget blir så lydtett at det blir slitsomt stille. Nesten så man burde vurdert mikrofon på utsiden for å kunne regulere bakgrunnsstøyen på innsiden.
  6. Lett å tenke for den som er på utsiden. Dette handler om at det er mange systemer som igjen er integrert mot mange systemer. Som eksempel har har sykehus i snitt 200 IT systemer (ikke så ulikt kommunene, bare ikke under ett tak). Bare for Helse Sør-Øst er det ca 2000 systemer til sammen og under 10 av de er felles på tvers av sykehusene. Tror fort det er enda verre med kommunene som er langt flere enn antall sykehus. Et pasientjournalsystem er som hundrevis av moduler tilpasset mot alle ulike faggrupper, med regler, maler, egne behov for automatikk. Dette i seg selv er isolert ikke så komplekst hver for seg, men kompleksiteten kommer av behovet for samhandling mellom modulene for for å gi nødvendig effektivitet + all samhandling eksternt i tillegg. 1000 konsulenter det skisseres til ikke det mye av pengene går til, men for å betale for å hente ut sykepleiere, kirurger, fysioterapeuter +++ som skal jobbe sammen med designere og utviklere for å få til effektiv flyt. I tillegg skal alle eierne av de eksterne systemene ha godt betalt for alle endringer og bistand for å migrere bort ifra deres systemer. Ja, alt dette koster, men det koster fort betydelig mer å ikke gjøre noe i løpende utgifter for å vedlikeholde gammelt og tapt effektivitet (null-alternativet). Tror prisen på konsulenter her er under 20% av alle de andre kostnadene.
  7. Hvorfor må båtene først legge til kai før man kan laste over til små autonome båter. Kunne ikke de små båtene festet seg med «sugekopp» i fart og lastet om på vei inn mot Trondheim?
  8. Den største lønnsforskjellen tror jeg man vil se mellom størrelse på selskaper. Snakket med mange i Oslo området og de fleste tjener 1,1-1,6 millioner der det er mellom 20 og 50 ansatte, mens i de store konsulenthusene ligger det typisk mellom 600.000-900.000kr/år.
  9. Samme jeg kom til kommentarfeltet for å skrive. Mer forklaring+bilder av hvordan dette fungerer.
  10. Tibber sitt insentiv for å integrere Tibber er nok ikke smartstyring, men for å vite mer om oss slik at de bedre kan predikere forbruket. Svært verdifull informasjon hvis man ønsker å være det som kalles «aggregator» som balanserer i kraftmarkeded. For å bli en aggregator som typisk Statnett kan benytte seg av (og som vi alle betaler for via nettleien) må man ha svært mange effekter man kan styre. Eks elbiler. Prisene på strømmen vår settes hver dag settes igjennom budprosess hos Nordpool som går frem til kl 23 dagen før, derfor kan man etter det se strømprisen for neste dag etter dette. Hvert kraftselskap har da lovet å levere gitt effektiv på gitte timen, basert på estimert forbruk påfølgende dag. Avvik fra dette justeres igjennom en ny budprosess som pågår igjennom dagen. Alt dette balanseres igjennom pris-insentiver og balanserer det meste av nettet av seg selv. Den aller siste og mer «live» justeringen gjøres direkte av Statnett hvor de har avtaler med kunder som kan styre effekter, dette er både kunder man kan ringe til på 2t varsel eller automatiske på 15min og «live». De siste live styringene aggregator. Noe det er estimert at prisene vil gå opp på med fornybar energi. Tibber er derfor insentivert for mest mulig styring, data for å bistå denne styringen og å selge mest mulig grønn energi (som presser opp verdien på aggregator-tjenester). En ganske annerledes businessmodell en hva kanskje mange tror 😉 (Litt som at Mac.Donalds hovedsakelig tjener penger utleie av eiendom (og omkringliggende eiendom) og ikke burger, og derfor er insentivert for mest mulig trafikk for å drive opp tomteprisene og ikke å tjene penger på burger)
  11. En stor buss har plass til ca 60 personer mens den tar opp plass i trafikken som ca 2biler. Klarer man å få til reisetid uten stopp eller ventetid i mellom bytter så går man gradvis i mot reisetiden til en bil. Da vil det vel bli mindre kø og behovet for bil forsvinne? Tror selvkjørende mini-busser/biler er et steg på veien. Tror disse mini-bussene kommer til å koordinere med større selvkjørende busser på sikt. Hvor de større bussene kjører på motorvei og kobler byer sammen, mens disse selvkjørende minibussene som det her er eksempel på vil frakte folk den siste lille biten.
  12. Slik jeg forstår det er ikke utfordringen på værmelding, men å koble data om eksisterende vannføring, magasin-kapasitet der det er demning, mengde snø og hvordan denne oppfører seg avhengig av ulikt vær. F.eks vil helling og vinkel på en fjellside ha mye å si på hvor mye det smelter avhengig av solinnstråling. Tærreng påvirker også mye vind som igjen påvirker smeltingen. Jordsmon påvirker absorbsjonsevnen av vann, så her er det store variasjoner avhengig av typen grunn, om den allerede er mettet og om det er tele i bakken eller ikke osv. Noen datakilder og sensorer jeg tenker at det er naturlig å se på inn i et slikt prosjekt: NIBIO - Oversikt over jordsmon: https://kilden.nibio.no/ Høydedata - Lidar for det meste av Norge. Her får man lage detaljerte 3D-modeller. Merk at de allerede har ferdig prosesserte filer for områder om man velger Nedlasting til venstre (50-100GB per fil): https://hoydedata.no/LaserInnsyn/ Satelittbilder - To ganger daglig flyr det ESA-satelitter over Norge hvor man gratis kan laste ned bilder og data, som kan brukes estimering av snømengder: https://spacedata.copernicus.eu/ Snødybdemålinger - EU har en samleside for både snødybde, gjennomsnittstemperatur osv: https://www.ecad.eu/dailydata/index.php De noe mer innovative datakildene Fyllingsgrad på vannmagasiner - Statnett og NVE har en del ute på regionalt nivå, vet at en del selskaper selv har laget enkle løsninger ved å bruke kamera og maskinlæring. Ofte vanskelig å benytte høydemåler pga bevegelser i vannet. Ved å ha to metallpinner i bakken med god avstand fra hverandre (10-100m) kan man måle elektrisk motstand i bakken. Denne motstanden varierer mye med fuktighet i grunnen. Dette igjen kunne kanskje vært brukt til å automatisk detektere metning av vann. Dette er noe nettselskapene ofte gjør for alle sine trafostasjoner og kalles hos de for "jordplatemåling, men da er hensikten å sjekke om det er god jording og ikke om det er mye vann i grunnen. Vannmengden i grunnen er en effekt som gjør at slike målingen varierer mye. Fra nettselskapene kunne man sikkert fått tak i mange slike historiske målinger for å korrelert mot historisk vær for å bygge grunnlaget for en maskinlæringsmodell. Live vind og temperatur i ulike luftlag kan man få gratis fra alle fly ved å samle inn data med ADS-B mottaker (SDR radio til under 100kr). Deler man data med Flightradar24 får man gratis tilgang til data fra alle mottakere i hele verden. Må legge til at det henvises til maskinlæring som en svart boks. Det var man ferdig med for 2-3år siden og man har nå gode metoder for å finne ut av hva modellen har lært. Så denne påstanden er ikke lengre gyldig.
  13. I tillegg til Carpooling problemet som handler om hvem bør sitte på med hvem for å minst mulig reisevei, tenker jeg på buss-bytte-problemet hvor man ønsker raskest mulig reise med færrest mulig bytter mellom busser og færrest mulig stopp. Her åpner det seg opp mange muligheter med koordinering av busser, hvor man kan få individuelle beskjeder om hvor man bør bytte når for å korte ned den totale reisetiden. For så at bussene seg i mellom kan koordineres slik at ventetiden på perrongen blir kortest mulig. Resultatet tror jeg kan bli raskere reise for alle enn om en selvkjørende buss skal kjøre deg helt fra A-til-B.
  14. Noen idéer til hvordan en slik platform skulle vært satt opp for å administrere data på vegne av brukeren? Eks hvordan skal nettselskapet gi tilgang til en 3.part for å kunne opptre på vegne av en kunde? Via f.eks ElHub eller gi spesielle tilganger til strømleverandører med forutsetning om at du er strømkunde høres ut som en "rask" første løsning. Kunne selvsagt gi leverandøren mulighet til et uthopp til nettselskapet via målepunkt, for så å authentisere med BankID og sende brukeren tilbake. Dette hadde kanskje gitt en mer sømløs on-boarding?
  15. Interessant at de sier at man kan utvikle journalsystemer til en brøkdel av prisen, kun ved å kjøre kode i en database. Virker som de ikke kjenner særlig god til hva som er driverne til at dette koster penger. Det er IKKE utviklingen av journalsystemet. Problemet ligger i at det er ca 50 til 200 systemer som journalsystemet skal snakke med, som igjen snakker med andre systemer igjen. Dette krever ekstremt mye koordinering, allokering av nøkkelressurser fra mange systemer, testing på testing på testing (lovkrav). Bryte opp dette i mikrotjenester eller løse alt i et system vil begge deler gi problemer. Svært mange brukere, behov, oppretidskrav, masse integrasjoner til legekontorer med tilhørende egne systemer +++ Komplekst blir det uansett for å bli effektivt. Hilsen en som faktisk har jobbet med journalsystemer.
×
×
  • Create New...