“The Morning Paper” s dell'anno - Edizione 2018

Continuando nella mia tradizione secolare fin dalla sua fondazione nel lontano 2017, ecco la mia lista supponente dei documenti migliori / più interessanti / più rilevanti / più sorprendenti presenti in The Morning Paper dall'incredibile Adrian Colyer durante il corso dell'anno scorso.

AI e simili

Problemi concreti e sicurezza dell'IA

Tra i tecnoutopi dell'IA e i profeti dell'apocalisse dell'IA giacciono i nerd dell'IA, che si limitano a rilassarsi pensando ai problemi. Gli autori rappresentano alcune delle istituzioni del tendone che lavorano in quest'area e la loro reputazione ci assicura che presteremo attenzione. Le tassonomie aiutano a distillare la conoscenza di un campo in pezzi digeribili, e questo documento offre formulazioni succinte e amiche dei laici come il "hacking della ricompensa". (Potevano andare fino a quel punto, soccombendo infine alla "fragilità di fronte al cambiamento distributivo", quando la "confusione in ambienti inaspettati" sarebbe andata bene.) Scherzi a parte, il documento è estremamente accessibile e gli autori hanno fatto un fantastico lavoro con gli esempi. Parlando di robot che rompono le urne in modo che possano ottimizzare i premi per la pulizia, la cosa più divertente per me è che sappiamo che robot / agenti avrebbero questi problemi con semplici funzioni oggettive - dopo tutto, gli umani non hanno sempre questi problemi? (Indica la storia degli sviluppatori che consentono ai bug nel loro codice in modo che possano ottenere il bonus per la correzione di bug.)

Regolamenti UE sul processo decisionale algoritmico

Quando la stampa tecnica, la stampa mainstream e Hacker News parlano tutti in tono sommesso e rispettoso riguardo a un regolamento UE - un regolamento UE! - puoi essere sicuro che qualcosa è in corso. Bene, quello che sta succedendo è un possibile (e forse del tutto involontario) attacco nel cuore di una regola non espressa di valutazione del modello di intelligenza artificiale: che la prova è nelle entrate, tutto il resto è dannato. Fino a quando il regolamento non sarà effettivamente testato con una sfida legale, o forse diverse sfide legali, la sua portata completa rimane una questione di interpretazione e speculazione. Tuttavia, concedere alle vittime (o "soggetti") degli algoritmi il diritto di sapere perché è stata presa una decisione rende la spiegabilità una proposta di illion-dollar.

Stesse statistiche, grafici diversi

L'ho scelto solo per il T. Rex, a dire il vero.

Ricerca nell'architettura neurale con l'apprendimento per rinforzo

Questo documento ha messo in luce alcune delle ricerche attive in corso all'intersezione delle tribù di Pedro Domingos The Master Algorithm. Kenneth Stanley è apparso abbastanza frequentemente in questa vena con articoli, discorsi e podcast sulla neuroevoluzione.

Instradamento dinamico tra le capsule

Un'inclusione obbligatoria. Non sappiamo ancora che impatto avrà, ma alcuni dei precedenti lavori di Hinton hanno dimostrato, diciamo con eufemismo, "un po 'utili".

Ottimizzazione automatica del sistema di gestione del database

Nel noioso vecchio mondo dei noiosi vecchi sistemi aziendali, gli amministratori sono sistematicamente sopraffatti dalle manopole di configurazione. Sono contento di sapere che la gente sta pensando anche a quegli amministratori. Evviva! ML non si limita a distinguere hot dog e golden retriever. Larry Ellison ha portato il marketing a 11 con il suo annuncio su Oracle Autonomous Database Cloud a Oracle OpenWorld 2017, ma ci sono state molte ricerche in corso su questo argomento.

Ciò comporta una sfida significativa. Più la scatola nera diventa opaca - e la maggior parte dei software aziendali è una scatola piuttosto opaca - più gli utenti mancheranno di avere un certo controllo sul comportamento della scatola nera. Ciò sarà aggravato dal fatto che, molto probabilmente, anche i costruttori della scatola nera spesso non saranno in grado di spiegare in modo soddisfacente perché la scatola nera ha fatto quello che ha fatto.

Quindi che si fa? Indica alternative come i metodi bayesiani.

BARCA: Creazione di sintonizzatori automatici con ottimizzazione bayesiana strutturata

E un secondo concorrente al tema delle ottimizzazioni del sistema. Un aspetto interessante di questo documento per me è che sembra far parte di una rinascita dell'interesse per i metodi bayesiani, in parte come risposta al forte desiderio di spiegabilità in tali sistemi. Potrebbe non essere così interessante "capire" come un modello abbia capito quale sia lo stile pittorico di Van Gogh in Starry Nights, ma sarebbe sicuramente interessante se l'attrezzatura di rete decidesse che terminare una determinata connessione fosse "complessivamente migliore" e quindi incapace spiegare a un utente irato come ha determinato il caso.

Ingegneria software

Comprensione dell'agilità del software

Non lo dice abbastanza in questo modo, ma il documento sostiene che troppo spesso cadiamo nella trappola del pregiudizio di sopravvivenza - attribuendo in modo restrittivo il valore predittivo, dove non ne esisteva nessuno, a varie azioni intraprese o eventi che si sono verificati. Piuttosto, sarebbe appropriato accettare la complessità (in contrapposizione alla semplice complicità) del sistema - persone, affari, tecnologia, codice, ... - e adottare un approccio di fare piccoli passi, osservare gli effetti di quel passo, studiare eventuali cambiamenti nell'ambiente, adattandosi se necessario, e poi facendo un altro piccolo passo. ML persone lo chiamano "discesa gradiente". La gente di ingegneria del software lo chiama "Agile". Riportandomi al punto su cui ero più d'accordo, proprio all'inizio del documento, che Adrian riassume così:

lo spirito originale di Agile è stato spesso sostituito dal culto del carico di regole e liste di controllo

Una dissezione del processo di sviluppo guidato dai test

Ecco un secondo articolo che studia un fenomeno che sembra funzionare abbastanza bene nella pratica e cerca di sostenerlo con la teoria. Ho il sospetto che il documento sarà ben accolto dalle persone di entrambe le parti della divisione religiosa attorno al TDD perché l'unica cosa su cui concordano è che la regola dei piccoli lotti (Toyota, Lean, ecc.).

Come sistemi complessi falliscono

Deliziosamente applicabile ai sistemi software anche se l'autore è un MD e scrive dal punto di vista sanitario! Organizzato come una serie di osservazioni, è assolutamente sorprendente (forse questo dimostra quanto la mia conoscenza sia stata limitata) quante di esse si applicano direttamente ai sistemi software. La migliore osservazione del lotto secondo me è "I sistemi complessi funzionano quindi in modalità degradata come la loro normale modalità di funzionamento", ma ci sono diverse pepite degne di nota, ad esempio, sui pericoli con cui RCA è irto e sul produttore / equilibrio dell'operatore e cosa succede quando sono la stessa persona. Con forse solo una piccola dose di bias di conferma, non è difficile vedere tutti i modi in cui supporta Agile, Lean e DevOps.

Nube

Informatica senza server: impatto economico e architettonico

Il primo di un paio di articoli sul cambiamento di paradigma che porta il cosiddetto serverless. Per me, il nome sta dicendo: ovviamente c'è un server da qualche parte che esegue codice, ma per lo sviluppatore non esiste un server. Serverless rende il cloud computing tutto basato sul codice: lo sviluppatore non deve preoccuparsi di nient'altro. Naturalmente, questo documento è molto semplice, dollari e centesimi, pro e contro. Pensalo come una versione accademica di una presentazione a un CFO e CIO, o al radar tecnologico ThoughtWorks. Non è progettato per convincere nessuno di nulla, ma pone senza server nel regno del, diciamo, ragionevolmente ben compreso.

Occupa il cloud

Vinod Khosla, un tempo sovrano della Silicon Valley, una volta disse a una conferenza: "Il cambiamento è l'unica cosa per cui valga la pena di essere ottimizzato". Signore e signori, vi do: senza server. Questo secondo di un paio di articoli che mi è piaciuto sull'argomento è più di una visione più ampia che cerca di costruire il supporto per l'affermazione che i vantaggi di un'architettura altamente disaccoppiata concentrandosi sul valore decrescente delle ottimizzazioni come colocation calcolo / dati, osservando che "su AWS EC2 la scrittura su un archivio remoto è più veloce della memorizzazione di dati su un singolo SSD locale". È improbabile che il documento convinca gli scettici, ma indebolirà sicuramente la loro resistenza. Prendo un po 'di problemi con la formulazione "calcolo distribuito per il 99%". Preferirei dire "cloud computing per il 99%", offrendo a quel 99% un modo di usare il cloud senza preoccuparsi (troppo) del calcolo distribuito.

chiave

Era una specie di inclusione obbligatoria, con tutto il clamore che lo circondava. Globale! Distribuito! Nessuna operazione! ACIDO! PAC! Orologi atomici! Questo annuncio ha un valore di freddezza ben oltre il geekdom del database.

BRR: controllo della congestione basato sulla congestione

Per l'ultimo documento sulla mia lista, ecco un cenno a ciò che paga le mie bollette: il networking. Inafferrabile quanto idraulico, altrettanto importante e difficile da eliminare quando le cose si intasano. A parte ciò, buffer bloat è un problema sorprendentemente mal compreso nel networking (senso "comune" e tutto il resto), e qualcosa di cui ho appreso da colleghi esperti di Citrix quando lavoravo su ottimizzatori WAN e simili. Adrian ha probabilmente fornito le migliori visualizzazioni dei suoi blog del 2017 spiegando il problema del controllo della congestione TCP e come BRR lo affronta.

Così il gioco è fatto. L'ondata di informazioni continua e grazie agli sforzi di cura di Adrian Colyer, possiamo digerire in modo significativo una parte di essa.

In attesa delle selezioni di Adrian per il 2018!

Carte bonus

Utilizzare la "virtualizzazione nativa del cloud". La virtualizzazione consapevole dell'hypervisor è così passé. Conosciuto anche come "cloud è il nuovo sistema operativo".

Mentre il loro uso su scala web è comune, il conteggio dei filtri sembra essere molto utile ma costrutti fortemente sottoutilizzati nelle reti. Mi chiedo perché.