Casper Bang

Netcompany: Mit.dk-nedbrud skyldtes menneskelig fejl

Menneskelig fejl? Som alternativ til... robot fejl?!

24. marts kl. 10:14
RFC8941 - Structured Fields

XML eller JSON, jeg forstår stadig ikke behovet for at gøre det nemt for mennesker. Det er computere der dekomprimerer indhold og for et Huffman træ spiller localization i forhold til entropi vel en ret stor rolle? Altså, key1,key2, key3; value1,value2,value3 er at foretrække frem for key1;value1,key2;value2,key3;value3?

11. februar 2021 kl. 18:18
PHK's 2021 quiz

...eller Little E?

7. december 2020 kl. 18:23
XML-opfinder og topchef i Amazon stopper i protest over fyring af whistleblowere

...at diskuttere at XML bruges forkert (der er godt nok mange forsøg på at gøre XML til turing-komplet sprog). With great power comes great responsibility. XML er jo bare om repræsention, ultra verbose og komprimeres ikke skide godt i sliding window algoritmer - men overbygninger som skemavalidering og tooling generelt er jo fantastisk.

Det lykkedes jo desværre aldrig Tim Brey at få WADL som spec da han var hos Sun, ellers havde vi nok ikke så mange der stadig hang fast i WSDL og WS-X legacy. Bevares, OpenAPI/Swagger gør det OK, men er aldrig helt nået samme niveau af standardisering.

On topic, hatten af for Tim. Han beviser til stadighed, at man stadig godt kan beholde sin integritet selvom man bevæger sig opad i hierakiet eller bliver opkøbt (Oracle det er dig jeg kigger på).

7. maj 2020 kl. 08:38
Professor om forsinket gælds-it: Ufornuftigt kun at benytte agil udvikling

...han anklager, tror jeg, ikke metoden som sådan.

Pointen jeg ikke helt lykkedes at komme frem med, er at agilitet er en filosofi eller et mindset - IKKE en metode. :)

Der er ingenting i det agile der dikterer at først gør du A, dernæst B - og derfor kan det ej heller være en metode.

Indlæg som disse fra Søren Lauesen, man skulle mene at vide bedre (kender ikke manden), er desværre med til at udvaske begrebet agilitet til noget det aldrig er tiltænkt og det er ikke fair.

11. september 2019 kl. 07:51
Professor om forsinket gælds-it: Ufornuftigt kun at benytte agil udvikling

Men hvad så, hvis den tilgang betyder, at det i sidste ende bliver umuligt at inddrive de sidste 30%?

Det er der vel ingen belæg for at konkludere? Tilgængæld betyder det at man kan starte med at indrive langt hurtigere så man ikke bliver ved med at skubbe problemerne foran sig til det har en størrelse hvor man er nødt til at afskrive hele molivitten.

Ved du hvad der typisk sker hvis du satser på de 100% i et faseopdelt forløb over mange år? Integrationerne har ændret sig, nye er kommet til osv. osv. Det er DETTE man anerkender ved agil udvikling, men at lave lighedstegn med et Kanban board eller referere til Agil som en metode er altså at fordreje tingene.

11. september 2019 kl. 07:36
Professor om forsinket gælds-it: Ufornuftigt kun at benytte agil udvikling

Her har vi desværre endnu et godt eksempel på hvorfor agil udvikling i disse år får et dårligt ry - det bliver simpelthen gradbøjet og voldtaget i en grad som aldrig har været tiltænkt!

Til at starte med, der findes ingen Agil metode - hvor en opskrift følges og værktøj anvendes som f.eks. RUP osv. Agilitet som defineret at 17 praktiserende guroer tilbage i 2002 består istedet af nogle værdier og principper omkring at løse en kundes behov på den bedste måde:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Det er slet og ret en anerkendelse af, at du bliver klogere undervejs og at vi derfor er nødt til at glemme forestillingen om store faste faser (analyse, design, implementation, test...) og én afleværing, men istedet tænke Minimum Marketable Features hvor scope har lov at ændre sig og hvor der er mange leverencer.

I det konkrete tilfælde, er det f.eks. nærliggende at forestille sig, at 30% af PSRM systemet kan indrage 70% af gælden - og så giver det naturligvis rigtig god mening at starte dér. Måske kræver det kun 6 integrationer med omverdenen istedet for 12.

Søren Lauesen synes direkte at angribe IT-udviklerens bedste våben; nedbrydning i mindre dele der kan overskues (divide n' conquer) og det fortæller mig at det er meget langt tid siden manden har haft rigtige udviklingsprojekter under fingrene. Ja jeg er på nippet til at kalde en sådan sætning for idioti.

Jeg mener vi har masser af eksempler på større problemer over i den modsatte grøft, vandfaldsmodellen med faste faser og hvor du principielt ikke anerkender at du bliver klogere undervejs - og sådan en type projekter går jo altid godt, ik?

11. september 2019 kl. 07:03
Scrum er fragile - ikke Agile

Det eneste Scrum vel reelt lover, er at være et arbejdsredskab der kan hjælpe med at:

  1. Sørge for at skabe værdi, ved for det første at dedikere en ansvarshavende PO (du får X timers udvikling i næste sprint, hvad er vigtigt for dig og dit produkt til næste release?) og for det andet, holde en iteration så tilpas kort at en evt. forkert vej bliver fanget i tide før det har kostet kassen.

  2. Skabe synlighed og fremdrift ved hurtigt at kunne identificere problemer og/eller folk der sidder alene med noget for længe og skal bruge hjælp. Hertil hører også krav til en generel forståelse af hvorledes problemet kan/skal løses i form af Definition of Ready kriterier der skal være overholdt ved planning.

  3. Sikre kvalitet ved at blive enige om hvornår opgaven er løst ved at definere nogle Done kriterier og typisk også højere QA kriterier (Done-Done) som, hvis udført korrekt, bliver til en drejebog for testere og evt. dokumentationsskrivning.

Hvad jeg ofte ser går galt, er enten at projektet i virkeligheden er et stort vandfaldspojekt hvor Scrum er mast ned over, og når det er helt galt, det ikke er teamet der tager stories ind men managers/kunde der hælder på. Med andre ord, et succesfuld scrum team skal først og fremmest have lov til at køre efter et pull-princip og ikke push.

Lykkedes dette ikke, må det anbefales at man forsøger en Kanban eller Scrumban stil istedet - da det er nemmere for managers/kunde at forholde sig til en kø samt WIP limit, men så får man typisk også brug for flere states på sit board (Blocked, QA etc.)

Personligt er jeg fan af Scrum når det handler om større projekter (der skal koordineres miljøer, teams, releases) med lange feature-branches og Kanban når det er mindre eller kun mig selv der udfører trunk-based development - ikke mindst når vi faktorerer release af software ind i kabalen også hvor CI/CD er noget nemmere af efterleve i Kanban.

27. maj 2019 kl. 23:00
100 dage tilbage: Her er en GDPR-guide til junglen af ændringer i databeskyttelse

GDPR trådte i kraft i april 2016, men det er først fra den 25. maj at den håndhæves - efter virksomheder har haft 2 år til at gøre deres software og data-praksis compliant.

Det er uheldigt at det af medier udlægges som "vi skal gøre noget inden den 25 maj 2018" for det er jo nok en af forklaringerne på, at det ikke har haft nok fokus for virksomheder - og hvorfor så få reelt når at efterleve lovgivningen.

14. februar 2018 kl. 08:36
Tre ud af fire Android-apps bruger tredjeparts-trackere

Det er normalt god stil at linke til den bagvedliggende artikel når man viderebringer en sådan.

Trackere får meget hurtig et negativ association, men de har rent faktisk et praktisk formål. Husk på, at deployment af en app reelt repræsenterer et meget stort distribueret system hvor man som udvikler ingen ide har om sundhedstilstanden på klienten. Crasher app'en på nogle versioner af operativ-systemet? Er der en memory leak et sted? Virker app'en ikke på Tunesisk? I en agil verden kan og bør man ikke teste i årevis, det er langt bedre at være reaktiv og for dette er man altså nødt til at monitorere.

I tilfældet med Crashlytics (oprindeligt Fabric og ejet af Twitter før Google overtog det) er det den bedste måde at holde øje med crash og fejl, ligesom man får overblik over hvorledes en udrulning af en ny version går.

Mht. egentlig analyse (a la Google Analytics, Firebase Analytics etc.), så er det ikke Crashlytics men Answers det foregår med. Selv om dette kan virke invasivt, så handler det igen om at forstå brugerne, måske endda foretage A/B testing (der nu er integreret i Firebase).

Så ja, app's kan vælge at logge personlige ting de ikke bør, men det gør ikke at al tredjeparts-tracking er problematisk.

29. november 2017 kl. 20:59
Her kommer Flutter - Googles nye mobil-system fra Aarhus
  1. ...hvorfor man ikke ønsker at en app følger platformen mht. opførsel, dvs. burger-menu på Android, knapper i toppen på iOS og så fremdeles. Her ender man med et kompromis hvor en app ikke rigtig kan følge telefonens UX/UI hverken på den ene eller anden platform - lidt ligesom det "lowest common denominator" problem Java Swing aldrig nåede at overvinde. Måske kunne jeg se en fordel hvis man fik en 3 tier med, web - for progressive web apps kan jo netop det hele især nu hvor Apple er hoppet med på service-worker!

  2. ...fordelen ved at tilføje endnu et niveau af indirection. Man kan ikke ret meget i Android på NDK laget hvor Flutter åbentbart primært befinder sig, så nu skal man altså til at lave adapters til Java-laget - eller også kommer Flutter med en masse af disse bygget ind under motorhjelmen. Det lyder ret skræmmende fra et maintenance og debugging synspunkt at have kæden Host layer (SDK) > Flutter layer (NDK) -> Adaptor layer (SDK) -> Native layer (SDK).

  3. ...hvorfor man divagerer fra mange års lærdom og fravælger templating/markup som en "by design" måde at undgå at blande UI og logik. Udover at være god til at overskue nesting helvede (det lille skole-eksempel ovenover har 7 niveauer) så virker det som om man også skal passe meget på med hvor man placerer sine ting.

The devil is in the details og der er bestemt spændende aspekter i Flutter, men jeg synes nu først det havde været RIGTIG interesant hvis sprog-motoren kunne udskiftes med f.eks. Kotlin og man kunne ramme web også. For med Flutter p.t. kan relativ få web-udviklere være interesserede i at hoppe på mobile, og få mobil-udviklere være interesseret i alternativer til native der alligevel afskærer sig fra en web-løsning.

5. oktober 2017 kl. 07:58
Udvikler blokerede for snyde-reklame i egen app - og så spærrede Google hans konto

...man får altså ikke bare sin konto blokeret ved at klikke en enkelt gang. Det er klart, at når der er penge involveret, er Google nødt til at være strikse for der er mange der snyder!

Skal man endelig klikke, så er det nok bedst at gøre det fra en "clean tlf." so-to-speak som Admob ikke allerede har registreret som udviklertlf. eller i det mindste fjerne data-adgang på device FØR man klikker og så bare holde øje med URL'en til browser eller Play evt. via LogCat, der vil vise noget a la:

08-29 07:48:59.079 W/Ads: Error while pinging URL: <a href="https://app.appsflyer.com/com.contextlogic.wish?pid=googleadwords_int…;.

...ovenstående er en reklame for app'en Wish fra Contextlogic via et AdMob banner i en Android app.

Mon ikke Grosh bliver taget til nåde igen efter en appel. Ellers findes der jo iøvrigt alternativer til Admob i form af Inmobi, Velti, Mobfox, Mopub mf.

29. august 2017 kl. 08:09
Git er ikke versionskontrol

Det er jo en gammel debat. Selv om dine argumenter er fine nok, så synes du at udelade at man jo sagtens kan bruge Git som traditionel versionskontrol - selv om Linus ikke oprindeligt havde dette for øje. Det kræver bare at man 1) udnævner ét master repo - det har de fleste organisationer alligevel 2) udnævner en master/stable/release/integration branch - det er der ligeledes mange der kører med og 3) benytter git commit nr. på sin master branch (git rev-list HEAD --count). Dette fungerer f.eks. fantastisk til Android udvikling, hvor kravet fra Google til versionCode netop et en fortløbende integer.

Som fan af semantisk versionering (og branches og tags), benytter jeg mig dog af ofte af tags til [major].[minor] og tæller [path] som antallet af commits siden seneste tag (git rev-list --tags --no-walk --max-count=1). Dette anser jeg dog som "marketingsversionsnavn" i dén forstand at her gælder det kommunikation til mennesker omkring bagudkompatibilitet osv.

Where there's a will there's a way.

1. marts 2017 kl. 07:20
Hvad bliver det næste vi slukker-tænder for ?

...er jo desværre ofte brugt når noget ikke er ordentligt forstået. Det handler vel både om økonomi samt håndværk (nogen vil sige 2 sider af samme sag, her er jeg dog uenig) og fejl kan altid opstå - spg. er bare i hvilken grad de forsøges mitigeret eller ej. En watchdog på en MCU er jo et glimrende eks. på en fin balance - men det er jo så heller ikke alle der udnytter disse. Godt med fokus på emnet QA og fejlhåndtering, det mangler vi sgu lidt i disse hast tider hvor IT tvinger sig ind alle steder.

13. februar 2017 kl. 23:16
Trump afleverer usikker Android-telefon til Secret Service

Trump er jo ved at lave om på alt så det skal han også nok forsøge her. Derfor ser flere af os nok også frem til en rigsret! :)

21. januar 2017 kl. 08:50
Elegant kode

Pudsigt, der er helt klart forskel på hvad man mener med "elegant kode". For mig er elegant kode hverken svært at læse eller forstå.

1. januar 2017 kl. 16:17
Når CPU, GPU og FPGA ikke er nok: Specialbyggede chips skal sætte fart på maskinlæring

Øhh ja, og hedder et sådant design ikke en ASIC og har da vist gjort det i mange år?!

7. december 2016 kl. 09:32
Java 9 får Ahead-of-Time-compiler for hurtigere opstart

Er jeg den eneste der synes at det lyder lidt underlidt, at funktionen skulle være serverrettet, hvis formålet er at give hurtigere opstart tider på programmet.

Nej, men de leger jo "catch up" med Google og Android, der i dén grad har formået at eksekvere på en "embrace and extend" strategi der ikke er set gjort bedre siden Microsofts storhedstid. Google har jo med overgangen fra Dalvik til ART netop bevist at AoT kan give store fordele, men som du selv er inde på, er klient Java jo stort set død - så det har næppe den store praktiske betydning. Jeg tror personligt mere det handler om strategi, i et retsopgør imellem Google og Oracle vil sidstnævnte ikke stå tilbage med et ringere klient produkt.

29. oktober 2016 kl. 17:01
C overhaler Java som mest populære programmeringssprog

Når IEEE inkl. "sprog" som SQL og HTML der ikke er Turing komplette, må man som professionel betragte IEEE listen som sludder for en sladder (det er IEEE/ACM gode til).

Tiobe har iøvrigt overvåget dette emne i rigtig mange år, og kommer til en ganske anden konklusion der nok er mere retvisende: http://www.tiobe.com/tiobe-index/

29. juli 2016 kl. 14:02
Analytiker: Dette er året for meningsløse blockchain-projekter

Det har jeg tilfældigvis Bent, men hvad har du at byde ind med andet end trolling?

26. juli 2016 kl. 12:51