Skolplattformens API:er lämnas inte ut – finns ingen dokumentation

Bra idé, men svårt att få gehör för hos företagen, skulle jag tro. Vet inte hur vedertaget det är med sådan licensering i Swenska föhretagh

Ser egentligen inget problem med det om beställaren köper hela lösningen inkl. källkoden(d.v.s. beställaren äger den) ifrån t.ex. ett multinationellt företag med säte i bl.a. Sverige och sedan väljer att offentliggöra den under en valfri licens.

När kunden fick räkningen på det så var det ingen som ville kännas vid fakturan(dom bollade bara runt den inom den statliga institutionen). Slutade istället med halva priset så att vi fortsatte att äga lösningen och dom fick istället en nyttjandelicens men ej tillgång till någon källkod.

Intressant. Att de bara bollade runt det handlade nog om att de inte visste hur de skulle förhålla sig till informationsmängden, d.v.s. källkoden. De förstod inte vad de hade köpt... eller ingen ville ta ansvar för det när det väl kom till kritan.

Ja det var denna jag syftade på i mitt inlägg. Finns handlingen klar att lämna ut med bara sekretessgranskning finns ingen tidsbegränsning, men behöver informationen hämtas från flera källor och sammanställas i ett nytt dokument gäller 4-6 timmar.

Jepp. Dokumentationen skall vara klar innan skarp driftsättning. Har man inte det så kanske man inte skall driftsätta något skarpt för det första. Låter i min värld om man gör det ändå så bedriver man en Kalle Anka organisation. Vilket jag anser mig se tydliga tecken på gällande det som tråden handlar om.

Det gör dom också sedan förra året, även om han egentligen gjorde så redan sedan år 2017 när vi tillsammans jobbade på ett litet projekt som inte är i samma storlek som det som omnämns i tråden men det var just ett API(brygga kallar vi den) mot hårdvara åt en statlig institution. Vi hade regelbunden testning och kontakt med beställarens tekniska representant. Nu var det troligtvis inte lika mycket att dokumentera för vår del(max 20 funktioner som exponerades, om ens det) som det som tråden handlar, men jag anser att samma princip skall tillämpas på så väl små som stora projekt. Jag anser att det är viktigare i större projekt än små att man börjar tidigt med dokumentationen.

Måste varit något sådant, för det såg riktig coolt ut för en som mig som har stannat på 90-talet, att han kunde anropa/se "hjälpen" direkt i källkoden för själva testprogrammet(som agerade kundens miljö) trots att bryggan(DLL fil som WFC tror jag?) var kompilerad och klar.

Jo, potentiell (allmän) handling... Får ofta svara på sådana frågor från HR-personer; "allmänheten" vill ha omfattande jämförande sammanställningar på överläkarlöner och whatnot

Ingen ville trycka på knappen "Betala".
Och den som hade godkänt beställningen hade inte förstått vad det skulle kosta(det gick enligt löpanderäkningsprincipen).

Vi lämnade aldrig ut källkoder innan full betalning anlänt, oavsett projekt.
Kunder kunde komma till kontoret i Lund(före Corona åren) för att se hur några sidor källkoder såg ut på några skärmar.

Efter lite snack så blev det halva priset(inga miljonbelopp men i alla fall en sexsiffrig summa) och vi fick inte vad vi hade räknat med men tillräckligt för att täcka våra kostnader och få en liten vinst. Det hade ändå inte gått att sälja den till någon annan så det var ett s.k one-off projekt där vi ville ha enligt överenskommelse(löpande) eftersom den var väldigt specifik för denna kund(dom bestämde i princip precis hur dom skulle vilja att anropen skulle formuleras ifrån deras miljö).

Åfan. Typiskt offentlig förvaltning imho

I Malmö, men förvisso statlig och inte kommunal förvaltning.

Jag håller med dig i att en vecka inte är så lång tid för denna typen av arbete, å andra sidan var det ju vad jag förstår ett krav i upphandlingen att det skulle skrivas dokumentation som upphandlaren skulle få. Så antingen har de inte gjort det trots att det var en del av dealen liksom, eller så är den så kass att de inte vill ge ut den (men upphandlaren borde inte bry sig om den aspekten).

Sen är det ju ett komplext system, men det är ju inte hela systemets API:er som är intressant egentligen utan bara det som är tillgängligt för vårdnadshavare. Öppna skolplattformen är väl inte intresserade av att exempelvis bygga en app för skoladministratörer eller liknande.

Sen förstår jag inte riktigt hur de inte kan ha detta lättillgängligt. Mitt team utökar och bygger nya API:er varje sprint, utan dokumentation så hade vi haft stora problem, men det hade förstås varit ännu värre för de andra team som ska använda våra API:er. Hela syftet med att bygga ett API är ju att någon annan ska använda det, internt eller externt, så dokumentationen är ju en central del av det liksom. Vårt byggsystem tillåter inte ett API utan kommentarer som kan användas för att generera dokumentation och förstås swagger.

Fast en del av problemet är fortfarande att dokumentationen redan borde varit klar och levererad. Det andra problemet att de som utvecklat APIet uppenbart är inkompetenta och helt saknar känsla för säkerhet.

Om vi håller oss till API, vad är vitsen med ett API om dess gränssnitt ej är dokumenterat?

Lär bli svårt att kunna dra nyttja utav det(även inom samma organisation) om man hela tiden skall skicka e-post eller använda andra metoder för att få ut information om hur man implementerar det.

Skulle det vara ett API för att kommunicera med något så blir det direkt omöjligt att nyttja API:et för just den kommunikation som API:et är avsett för, eftersom ingen annan än utvecklarna utav API:et vet hur det skall nyttjas korrekt för att få till en korrekt kommunikation .

Att där finns andra verkligheter där man ignorerar att skapa dokumentation för API:er är väldokumenterat i denna tråd . Att hoppas på att någon "räknar" ut hur dom skall anropa ett främmande gränssnitt på 100% korrekt sätt skapar bara mer jobb eftersom antalet felsökningstimmar som kan komma att behövas blir sannolikt fler.

Jag tillät t.ex. aldrig att API:et sattes i skarp drift förrän jag hade testat igenom det och kört det i en labbmiljö som motsvarade 30000 användare(samma mängd som i kundens verklighet). Utvecklaren fick helt enkelt laga felen innan vi släppte det, och det var säkert 30-40 sådana(stora som små) som han fick åtgärda. Det är aldrig värt att smutsa ner ett globalt företags namn oavsett om projektet med API:et var så litet att vi enbart hade en utvecklare hos oss som utvecklade det. Det är klart först när det är klart och vi höll tidsschemat ifrån vår sida. Att det tog kunden nästan 3 år att testa det visade sig vara att dom helt enkelt inte hade en organisation som brydde sig att prioritera det hela förrän deras gamla befintliga lösning började strula.

Sedan att där fanns folk hos beställaren som var svenskar och kallade sig för utvecklare men visade sig att dom inte kunde läsa dokumentationen tillsammans med exemplen som också var skrivna utav utvecklaren på det svenska språket, på ett API med mindre än 20 stycken publika funktioner, var inte vårt fel utan ett internt problem i beställarens organisation.

Den lanserades i mitten på mars månad förra året och än så länge har jag inte hört att där varit några fel som har med utvecklingen eller dokumentationen att göra.

Låter lite som samma kultur i kundens organisation som den man läser om som tråden handlar om men även den verklighet som Du beskriver, där utvecklingen börjar först när man driftsatt systemet skarpt, vilket låter för mig som helt fel ordning.

Men visst, om det är okej att löneutbetalningar, handelsplatser för värdepapper, lagersaldo, beställningar, logistik, kassor, bensinpumpar, hissar, dörrar, portar, kyla/värme, larmsystem, ljus fungerar lite som dom själv vill så förstår jag varför vissa bryr sig att påbörja utvecklingen först efter en skarp driftsättning .

Men å andra sidan så är jag inte förvånad när man ser hur dagens mjukvara ständigt behöver lappas och lagas, och då tänker jag inte på lösningar som finns i fri öppen källkod på nätet, utan i kommersiella lösningar.