“The Morning Paper” af året - 2018-udgave

Fortsætter med min tidens ære tradition siden sin oprettelse helt tilbage i 2017, her er min meningsfulde liste over de bedste / mest interessante / mest relevante / mest øjenåbnende papirer vist i The Morning Paper af den utrolige Adrian Colyer i løbet af kurset sidste år.

AI og sådan

Konkrete problemer og AI-sikkerhed

Mellem AI-tekno-utopierne og AI-dommedagsprofeterne ligger AI-nørderne bare for at tygge væk og tænke over problemerne. Forfatterne repræsenterer nogle af markeringsinstitutionerne, der arbejder i dette område, og deres omdømme sikrer, at vi vil være opmærksomme. Taksonomier hjælper med at destillere kendskabet til et felt i fordøjelige bidder, og dette papir leverer med kortfattede og lægmandsvenlige formuleringer som "belønningshacking". (De kunne kun tage det indtil videre og til sidst bukke under for ”skrøbelighed i lyset af fordelingsskift”, når ”forvirring i uventede miljøer” ville have fungeret fint.) Vittigheder til side, papiret er meget tilgængeligt, og forfatterne gjorde en fantastisk job med eksemplerne. Når vi taler om robotter, der bryder urner, så de kan optimere rengøringsgevinsten, er det morsomste ved mig, at vi ved, at robotter / agenter ville have disse problemer med enkle objektive funktioner - når alt kommer til alt, har mennesker ikke disse problemer hele tiden? (Cue-historie om udviklere, der tillader fejl i deres kode, så de kan få fejlrettelsesbonus.)

EU-forordninger om algoritmisk beslutningstagning

Når tech-pressen, mainstream-pressen og Hacker News alle taler i forhastede, respektfulde toner om en EU-regulering - en EU-regulering! - du kan være sikker på, at der er noget, der er gået af. Det, der ligger bagefter, er et muligt (og muligvis fuldstændigt utilsigtet) angreb i hjertet af en uudtalt regel om AI-modelevaluering: At beviset ligger i indtægterne, alt andet er fordømt. Indtil forordningen faktisk er testet med en juridisk udfordring, eller måske flere juridiske udfordringer, forbliver dens fulde anvendelsesområde et spørgsmål om fortolkning og spekulation. Ikke desto mindre er det at give ofre (eller ”emner”) af algoritmer retten til at vide, hvorfor der blev truffet en beslutning, forklarbarheden til et [m | b] illion-dollar forslag.

Samme statistik, forskellige grafer

Jeg valgte dette bare for T. Rex, for at være ærlig.

Neural arkitektursøgning med forstærkningslæring

Denne artikel var en, der fremhævede nogle af den aktive forskning, der skete i skæringspunktet mellem stammerne til Pedro Domingos Master Algorithm. Kenneth Stanley dukkede ganske ofte op i denne vene med artikler, taler og podcasts om neuroevolution.

Dynamisk routing mellem kapsler

En obligatorisk inkludering. Vi ved endnu ikke, hvor virkningsfuldt dette vil være, men noget af Hintons tidligere arbejde har vist sig, skal vi sige med grov understatement, "noget nyttigt".

Automatisk indstilling af databasestyringssystem

I den kedelige gamle verden af ​​kedelige gamle virksomhedssystemer bliver administratorer rutinemæssigt overvældet af konfigurationshåndtag. Glad for at vide, at folk tænker også på disse administratorer. Hurra! ML handler ikke kun om at skille hotdogs og golden retrievers fra hinanden. Larry Ellison vendte markedsføringen op til 11 med sin meddelelse om Oracle Autonomous Database Cloud på Oracle OpenWorld 2017, men der har været masser af igangværende undersøgelser om dette emne.

Dette medfører en betydelig udfordring. Jo mere uigennemsigtig den sorte boks bliver - og de fleste virksomhedssoftware er en temmelig uigennemsigtig kasse - jo flere vil brugerne gå glip af at have en vis kontrol over den sorte boks opførsel. Dette vil blive forstærket af det faktum, at selv bygherrer af den sorte kasse sandsynligvis ofte ikke er i stand til tilfredsstillende at forklare, hvorfor den sorte kasse gjorde, hvad den gjorde.

Så hvad skal man gøre? Cue-alternativer som bayesiske metoder.

BÅD: Bygning af auto-tunere med struktureret Bayesian optimering

Og en anden deltager i emnet systemoptimeringer. Et interessant aspekt ved denne artikel for mig er, at det ser ud til at være en del af en genopblussen i interesse for Bayesiske metoder, dels som et svar på det stærke ønske om forklarbarhed i sådanne systemer. Det er måske ikke så interessant at “forstå”, hvordan en model regnede ud, hvad Van Goghs malestil i Starry Nights er, men det ville helt sikkert være interessant, hvis netværksudstyr besluttede at afslutte en bestemt forbindelse var “bedre generelt” og derefter ikke er i stand at forklare en irriterende bruger, hvordan den bestemte, at det var tilfældet.

Software Engineering

Om forståelse af software agility

Det siger ikke helt det på denne måde, men papiret hævder, at vi alt for ofte falder i fælden af ​​Overlevelsesskævhed - restriktivt tilskriver forudsigelig værdi, hvor ingen eksisterede, til forskellige handlinger, der blev truffet eller begivenheder. Det ville snarere være hensigtsmæssigt at acceptere kompleksiteten (i modsætning til blot kompliceret) af sytemet - mennesker, forretning, teknologi, kode, ... - og tage en tilgang til at tage små skridt, observere virkningerne af det trin, studere eventuelle ændringer i miljøet, justering efter behov og derefter tage et andet lille skridt. ML-folk kalder det "gradient descent". Software engineering folk kalder det "Agile". Fører mig tilbage til det punkt, hvor jeg var mest enig, lige nær starten af ​​papiret, som Adrian opsummerer således:

den oprindelige ånd af Agile er ofte blevet erstattet af fragtdyrkning af regler og tjeklister

En dissektion af den testdrevne udviklingsproces

Her er en anden artikel, der studerer et fænomen, der ser ud til at fungere temmelig godt i praksis og forsøger at undergå det med teori. Jeg formoder, at papiret vil blive godt modtaget af folk på begge sider af det religiøse kløft omkring TDD, fordi den ene ting, de er enige om, er, at små partier hersker (Toyota, Lean osv.).

Hvordan komplekse systemer mislykkes

Dejligt anvendelig til softwaresystemer, selvom forfatteren er MD og skriver fra et sundhedsmæssigt perspektiv! Organiseret som en række observationer, det er helt utroligt (måske dette taler til hvor begrænset min viden har været), hvor mange af dem, der direkte anvender til softwaresystemer. Den bedste observation af partiet er efter min mening “Komplekse systemer kører derfor i nedbrudt tilstand som deres normale driftsform”, men der er flere bemærkninger, f.eks. Om de farer, som RCA er fyldt med, og på producenten / operatørsaldo og hvad der sker, når de er den samme person. Med måske bare en lille dosis af bekræftelsesbias er det ikke svært at se alle måder, hvorpå dette understøtter Agile, Lean og DevOps.

Sky

Serverløs databehandling: økonomisk og arkitektonisk påvirkning

Den første af et par papirer om paradigmeskiftet, som den såkaldte serverløse bringer. For mig fortæller navnet: der er selvfølgelig en server et sted, der udfører kode, men for udvikleren er der ingen server. Serverløs gør cloud computing alt om koden - udvikleren skal ikke bekymre sig om andet. Naturligvis er dette papir meget møtrikker og bolte, dollars og cent, fordele og ulemper. Tænk på det som en akademisk version af en præsentation til en finansdirektør og CIO eller ThoughtWorks Technology Radar. Det er ikke designet til at overbevise nogen om noget, men det placerer serverløst i verden, skal vi sige, med rimelighed godt forstået.

Besæt skyen

Vinod Khosla, engang Silicon Valley-kongelige, sagde engang på en konference, “Forandring er det eneste værd at optimere for.” Mine damer og herrer, jeg giver Dem: serverløs. Dette andet af et par papirer, som jeg kunne lide om emnet, er mere en bredere visionerklæring, der forsøger at opbygge støtte til påstanden om, at fordelene ved en stærkt afkoblet arkitektur ved at fokusere på den formindskende værdi af optimeringer som beregning / datakollektion, at bemærke, at “på AWS EC2 er skrivning til fjernlagring hurtigere end at gemme data på en enkelt lokal SSD”. Avisen vil sandsynligvis ikke overbevise skeptikere, men det vil bestemt svække deres modstand. Jeg har lidt problemer med formuleringen "distribueret computing for 99%". Jeg foretrækker at sige “cloud computing for the 99%” - hvilket giver disse 99% en måde at bruge skyen på uden at bekymre mig (for meget) om distribueret computing.

Spanner

Dette var slags obligatorisk inkludering, hvad med al hype omkring det. Global! Distribueret! Ingen ops! SYRE! KASKET! Atomur! Denne meddelelse havde coolness værdi langt ud over databas geekdom.

BRR: overbelastningsbaseret overbelastningskontrol

For det sidste papir på min liste, her er et nikk til det, der betaler mine regninger - netværk. Så unsexy som VVS, så vigtig og så vanskelig at rydde, når tingene tilstoppes. Som en hurtig side er bufferopblæsning et overraskende dårligt forstået problem i netværkssamarbejde ("almindelig" fornuft og alt det), og noget lærte jeg om fra ekspertkolleger i Citrix, da jeg arbejdede med WAN Optimizers og sådan. Adrian leverede muligvis de bedste visualiseringer af sine blogs i 2017, der forklarede TCP-congestion-control-problemet, og hvordan BRR adresserer det.

Så der har du det. Informationsfloden fortsætter, og takket være Adrian Colyers kurationsbestræbelser kan vi meningsfuldt fordøje en del af den.

Ser frem til Adrians valg for 2018!

Bonuspapirer

Brug "cloud-native virtualisering". Hypervisor-opmærksom virtualisering er så passé. Også kendt som “sky er det nye operativsystem”.

Selvom deres brug af webskala er almindelig, synes tællefiltre at være meget nyttige, men groft underudnyttede konstruktioner i netværkssamarbejde. Jeg undrer mig hvorfor.