A 2018 legjobbja a Tech Talks-ban

Az elmúlt két évben közzétettem az előző év kedvenc technológiai beszélgetéseim listáját (itt van ennek a bejegyzésnek a 2016. évi kiadása és itt a 2017. évi kiadás).

Ez a lista semmiképpen sem átfogó, és biztos vagyok benne, hogy 2018-tól kezdve számos technikai beszélgetés zajlik, amelyeket csak sokkal később fedezek fel. De azon a beszélgetésen belül, amelyen részt vettem vagy néztem, ezek voltak a legjobbak (nem külön sorrendben).

  1. A mikroprocesszorok jövője, Sophie Wilson

Sophie Wilson, az eredeti ARM chip híres úttörője úgy tűnik, hogy meggyőződése, hogy a Moore's törvény véget ér (néhány, a későbbiekben felsorolt ​​másokkal együtt). Ez a JuliaCon fenomenális beszéde volt, amely a mikroprocesszorok történetéhez, fejlődéséhez és jövőjéhez vezet.

Videó

2. A Hurricane's Butterfly: Patológiásan teljesítő rendszerek hibakeresése, Bryan Cantrill

Két olyan beszélgetés, amely az előző évi listámhoz került, a Zebra egészen lefelé volt, és a hibakeresés tűz alatt: Tartsa a fejét, amikor a rendszerek elveszítették a fejüket. Ez hasonló beszélgetés volt, és a kantrilliai lényegében felmerülő érzelmekkel, életerővel és életerővel valósult meg, amire számíthattunk. A szoftver absztrakciók halmazaként van felépítve, és látszólag kisebb problémák egy rétegben (a pillangók) képesek átalakulni egy másik rendszerben (a hurrikánban) szisztémás kóros teljesítménybeli kérdésekké. Egy ilyen hurrikán miatt hogyan lehet megtalálni a pillangók?

Dia diák

3. Zárt hurkok és nyitó gondolkodásmód: Hogyan lehet átvenni a rendszerek irányítását, a nagy és kicsi, Colm MacCarthaigh

Igaz, hogy nem figyeltem az AWS re: Invent összes beszélgetését, de azok közül, amelyeket néztem, valószínűleg ez volt a kedvenc beszédem. Meghatározza néhány rendszabályt a rendkívül stabil és megbízható rendszerek (például irányító síkok) felépítésére.

  1. Ellenőrizze az összes dolgot
  2. Kriptográfiai hitelesítés
  3. Sejtek, kagylók és „méregkóstolók”
  4. Aszinkron tengelykapcsoló
  5. Zárt visszajelzési hurkok
  6. Kis tolók és nagy húzások (konfigurációhoz)
  7. Kerülje a hidegindítást és a hideg-gyorsítótárat
  8. fojtószelepek
  9. delták
  10. Modalitás és állandó munka

Izgalmas volt megtanulni, hogy bizonyos anti-minták és nem intuitív minták valóban hozzájárulhatnak a rendszerek stabilitásának javításához. A beszélgetésnek talán a legérdekesebb része az volt az elképzelés, hogy a stabil vezérlőrendszereknek „PID hurkot” kell igényelniük - arányos, integrált, származékos komponenseket, és hogy képes megvizsgálni a rendszer kialakítását és a helyszínét, ha hiányzik ezek közül egyik. szupererő. Ez az első alkalom, amikor ezt a „PID hurkot” hallom; a beszélgetés az Elosztott Vezérlő Rendszerek Tervezése című könyvben javasolja, hogy többet megtudjon arról, hogy a vezérlés elmélete hogyan alkalmazható az elosztott rendszerek tervezésére.

Érdekes volt megtanulni az AWS hierarchiáját vagy prioritásait is: biztonság, tartósság, rendelkezésre állás, sebesség.

Videó diák

4. A számítógépes építészet aranykora, David Patterson és John Hennessy

Ez fantasztikus beszéd volt a mikroprocesszorok történetéről és fejlődéséről, a CISC-ről a RISC-gépekre való átállásról a Moore's Law és a Dennard méretezés végére, ami viszont példátlan lehetőségeket kínál a „domain-specifikus építészet” térben történő előrelépés számára. A „tartomány-specifikus architektúra” magában foglalja mind a hardver fejlődését (ideghálózati processzorok gépi tanuláshoz, mint például a TPU-k, az NVIDIA GPU-k az FGPA-kig), mind a tartományspecifikus szoftverekkel (mint például a Swift for TensorFlow). A beszélgetés a RISC V ISA létrehozásának és növekedésének történetével zárul.

Azok számára, akik inkább írott cikket szeretnének, mint egy videót, az ACM közleménye ebben a hónapban Hennessy és Patterson (a híres könyv, a Computer Architecture szerzője) szerzőjének írt cikket erről a témáról. Lehet, hogy a Moore tranzisztorokra vonatkozó törvénye véget ért, de úgy tűnik, hogy az utóbbi években a Moore-törvény szerint növekszik a gépi tanulmányok száma.

Videó [Hennessy Stanfordban, ~ 1 óra]

Videó [Patterson a Facebook @Scale konferenciáján ~ 30 perc]

5. Az ügyfelek biztonságos viselkedése, Ariel Goh

Ennek nyilvánvalónak kell lennie a régi elosztott rendszerek számára, de érdemes megismételni, hogy az ügyfelek az elosztott rendszer fontos részét képezik, és így részt kell venniük a rugalmassági erőfeszítésekben. Ez egy fantasztikus beszéd az SRECon Asia / Australia-tól az ügyfél-tervezés bevált gyakorlatairól a teljes rendszer rugalmasságának javítása érdekében. A javasolt technikák magukban foglalják az ügyfélkérések elcsúsztatását, a véletlenszerűség hozzáadását, így minden ügyfél véletlenül nem végez szinkronizálást kérések benyújtásakor, amikor nem akar újrapróbálkozni, megpróbálják újrapróbáltatni, exponenciális visszaeséssel (és ezzel együtt járó vásárlásokkal), „újrapróbálkozni a költségvetésekkel” (mint például a hiba költségvetések) ), a vezérlés egy részének áthelyezése a szerverre és egy visszajelzési hurok létrehozása a kiszolgáló és az ügyfelek között, adaptív gázszabályozás az ügyfelekön és még sok más.

Videó

6. Hogyan kell kiszolgálni és megvédeni (kliens elszigeteléssel), Frances Johnson

Ez egy újabb kiváló beszélgetés az SRECon Asia / Ausztrália részéről a Google Mapshez hasonló szolgáltatás védelméről (rengeteg belső és külső ügyféllel) a túlterhelés ellen. A beszélgetés olyan problémákat érint, mint a rendszer túlterhelése (és az ahhoz kapcsolódó problémák, mint például az alulról folyó áramlások, amelyek elhanyagolják a rendszer túlterhelését), lépcsőzetes meghibásodás, statikus kvóták csapdái, a kecses degradációs technikák előnyei és hátrányai a verem különböző rétegein (kliens, él, előlap, háttér).

Videó

7. Alkalmazott teljesítményelmélet, Kavya Joshi

Ez egy hihetetlen beszéd (mint mindig), a QCon London képviselője Kavya arról, hogyan lehet a teljesítmény modellezési technikákat alkalmazni olyan kérdések megválaszolására, mint például a rendszer további töltetét képes támogatni anélkül, hogy csökkentené a válaszidejét, és hogyan lehet felismerni a rendszer kihasználási szűk keresztmetszeteit. A beszélgetés először a webszerver egy tipikus példáján vezet be, hogy bemutassuk, hogyan kell elemezni a teljesítményt a „nyitott rendszerekben”, ezt követi a „zárt rendszerek” példája, és hogy mindkettő eltérő feltételezésekre támaszkodik, és miért igényelnek különböző technikákat az elemzéshez.

Dia diák

8. Amazon Aurora: A nagy teljesítményű felhő-natív relációs adatbázisok tervezési szempontjai, Sailesh Krishnamurthy

Ez a Facebook @Scale konferenciájának abszolút feltörő beszéde volt néhány olyan tervezési döntésről és kompromisszumokról, amelyek az Amazon Aurora alapját képezik, mivel a tároló motor számos népszerű AWS adatbázis-kínálatot táplál. Az Aurora állítása szerint automatikusan méretezi akár 64 TB-ot adatbázispéldányonként, és nagy teljesítményt és elérhetőséget biztosít akár 15 alacsony késleltetésű olvasási replikával, pont-pontbeli helyreállítással, folyamatos biztonsági mentéssel az S3-ra és replikációval három rendelkezésre állási zónán keresztül.

Két, az Amazon által az Aurora-ban közzétett fehér könyv található [1] [2]. A beszélgetés sok szempontot említ különösen a második tanulmánytól, a legfontosabb elvitel az, hogy az elosztott konszenzus megöli a teljesítményt, és hogy a helyi állam valóban jó dolog lehet. A változatlan naplónak az igazság forrásaként történő felhasználásával az Aurora elkerüli az elosztott egyetértést a tagsági változásokkal kapcsolatban azáltal, hogy egyes „konzisztencia oázákat” hoz létre, amikor korszakot őrökként használnak írásbeli kvórum formájában, és elkerüli a kvórum teljes olvasását. Érdekes egy olyan korszakban, amikor a tranzakciós rendszerek visszatérnek, és a Google prédikál arról, hogy miért kell az erős következetességet választanunk, amikor csak lehetséges, az Amazon különböző kompromisszumokat választ.

Videó

9. Az FoundationDB tárolóréteg jövője, Steve Atherton

Ez egy izgalmas beszéd volt az FoundationDB tárolórétegének jövőjéről az FoundationDB csúcstalálkozón. Az FoundationDB egy elosztott, megrendelt kulcsérték-tároló, de a tárolóréteg maga nincs elosztva, és egyetlen folyamatból érhető el egyetlen szálból. A beszélgetés egy új tárolómotor követelményeire, a nem követelményekre (egyidejű írók, alacsony késleltetési késleltetés) megy át, majd felvázolja több adatruktúra előnyeit és hátrányait (B + fák, LSM fák) és a Redwood kiválasztásának okait. B + fa.

Videó

Az FoundationDB csúcstalálkozójának másik nagyszerű beszéde volt a dokumentumréteggel kapcsolatos beszélgetés, amelynek videója itt található.

10. Autonóm tesztelés és a szoftverfejlesztés jövője, Will Wilson

Először is, Will valószínűleg az egyik legjobb hangszóró, akit valaha láttam beszélni (a Strangeloop 2014-ből származó elosztott rendszerek tesztelése determinisztikus szimulációval kapcsolatos korábbi beszéde az egyik minden idők kedvence).

Ez egy fenomenális beszéd az alapító Alapítvány csúcstalálkozóján, amely elég vonzó érvként szolgál az AI-vezérelt teszteléshez. A beszélgetés három fő problémát azonosít a teszteléssel kapcsolatban: törékenység (a teszt a rendszer azon tulajdonságain alapszik, amelyek véletlenszerűek - amelyek nem azok, amelyeket gondoltak tesztelni), a teljesség és a hamisság hiánya.

A beszélő azt állítja, hogy a tesztek nagyszerűek a regressziók felbukkanására, de szinte teljesen használhatatlanok az ismeretlen-ismeretlen észlelésére. A beszélgetés során az összes fent említett problémát tüneteknek tekintik, és a valódi alapvető probléma az, hogy a tesztelés továbbra is teljesen manuális. Még az „automatizált tesztelés” során Jenkins csak egy ember által manuálisan készített tesztkészletet futtat. A beszélgetés ezután az autonóm tesztelés álmát írja le, mint a tesztek automatizált végrehajtása mellett a tesztek automatikus létrehozásának szükségességét.

Videó

11. Elosztott rendszerek tervezése a TLA + segítségével, Hillel Wayne

Ez a CodeMesh csodálatosan elérhető beszéde volt a formális specifikációk használatáról az elosztott rendszerek tervezésében. Gondolj rá a TLA + szelíd bevezetésére. A kvótatartalom a következőket foglalja magában:

Adjon elég időt a rendszernek, és mindent megtesz, beleértve a kudarcot is.
A kód nem tervezés. A kód nem mutatja meg a rendszer működését. Ez csak a megvalósítás; Nem szabad, hogy ez legyen a formatervezés, nem lehet a design. És ha úgy gondolja, hogy egy rendszert megtervezhet, és meg tudja érteni a rendszert, csak a kóddal, van egy híd, hogy eladjam, és kétszer, egyidejűleg fogom eladni.

Videó

12. Mit tévedtünk: Tanulságok a mikroszolgáltatások születéséről a Google-on, Ben Sigelman

Ez egy forgószélű beszéd volt a szétszórt számítástechnika fő erőfeszítéséről a Google-on, mindent érintve, amelyet a Google megszerezte a gyakorlatokra, amelyek nem voltak eléggé, de szoros párhuzamok voltak azzal, amit manapság „mikroszolgáltatásoknak” hívunk. A beszélgetés rávilágít arra, hogy a szélesebb körű iparág miként végez bizonyos dolgokat jobban, mint hogy a Google hogyan csinálta (például a szolgáltatási hálókat), mikor és miért nem működik jól a Google technológiai döntéseinek és gyakorlatainak utánozása a mi többiünk számára, és miért különösen fontos, hogy képesnek kell lennie arra, hogy válaszoljon bizonyos típusú kérdésekre, mielőtt elfogadná az építészeti paradigmákat (például „kiszolgáló nélküli”).

Videó diák

13. Elosztott log-feldolgozó tervező műhely, Laura Nolan, Phillip Tischler, Salim Virji

Ez egy teljesen hihetetlen beszélgetés a nagy léptékű elosztott rendszer felépítésének gyakorlati lehetőségeiről, ideértve azt is, hogyan lehet megközelíteni a méretezést, hogyan kell értékelni a különböző tengelyek közötti kompromisszumokat, valamint a boríték számításának tonna hátulját, hogy igazolják az egyes döntéseket.

A Google SRE-munkafüzetének (szabadon elérhető online) a teljes témája a nem absztrakt, nagyméretű rendszer kialakítása című fejezet, és hallottam, hogy ez a kritikus interjú az egész Google SRE interjúkörben, mivel ez az, amelyik statisztikailag legvalószínűbb, hogy egy jelöltet kibocsájt, majd a kódoló interjúkat követi. Személy szerint úgy gondolom, hogy ez nemcsak az SRE-re vonatkozik, hanem mindenki számára el kell olvasni, ha elosztott rendszereket építenek és működtetnek.

Sajnos erre nem találtam videót.

Diák

14. Terheléselosztás a Hyper Scale, Alan Halachmi és Colm MacCarthaigh mellett

Ez egy nagyon izgalmas beszéd a Facebook Networking @Scale konferenciáján a terheléselosztás alakulásáról az AWS-en. Megvilágítja a HyperPlane-t, egy olyan rendszert, amely az AWS S3 Load Balancer, a VPC NAT Gateway és a PrivateLink alapját képezi. Különösen örültem annak, hogy megismertem a javasolt SHOCK elvet (öngyógyító vagy állandó munka), amely azt sugallja, hogy egy rendszer felépítésekor ellenállónak kell lennie még a nagy sokkok ellen is. Vagy másként fogalmazva: „ha valami nagy megváltozik, akkor a rendszernek képesnek kell lennie arra, hogy a normál módon tovább működjön”. A beszélgetés a következőket javasolja:

1. A folyamatos erőfeszítések és a kudarcból való felépülés a természetes állapotok
2. Mindig javítási üzemmódban működjön. Amikor egy csomópont meghibásodik, a Hyperplane valójában kevesebb munkát végez!
3. A nagyméretű rendszerek tervezésekor nem akarjuk, hogy azok komplexek legyenek. Azt akarjuk, hogy a lehető legegyszerűbbek legyenek. Ebből a célból a lehető legkevesebb működési módot akarjuk (például a hipergépnek nincs újrapróbálási módja. Ez a TCP veleszületett újrapróbálási mechanizmusa). A különféle működési módok rakása kombinációs kombinációs robbanást eredményez, amelynek eredményeként a rendszer hihetetlenül nehéz tesztelni. Olyan rendszert akarunk, amely következetes és mindig a várt módon működjön.
4. A beszélgetés bevezette a shuffle sharding ötletét is, egy DDoS enyhítő technikát (ahol az izolálás az elsődleges enyhítő technika), amelyet ma sok AWS szolgáltatáson széles körben alkalmaznak.

Videó

15. Izolálás konténerek nélkül, Tyler McMullen

Az egyik érdeklődési köröm az, amit a barátoknak a számítási spektrumának írtam le - virtuális gépek, mikroVM-ek, beágyazott virtuális gépek, konténerek (és a „homokozó dobozok”, például a Kata konténerek ízei) és a „kiszolgáló nélküli” (vagy funkciók) mint szolgáltatás). Különösen érdekli az ajánlat „az izoláció spektruma” - a szigorú folyamatszintű izolálástól a homokozó, például V8-n keresztül történő izolálásig. Az elmúlt években számos technológia jelent meg a virtualizációs térben, például a gVisor (egy hipervizor, amely a Linux kernel API részhalmazát a felhasználói térben valósítja meg) a Firecracker-hez - egy virtuális gépmonitor, amelyet könnyű és szerver nélküli munkaterhelések futtatására használnak mikro-virtuális gépekben. , amely maga a crosvm tetejére épült (a Chrome OS virtuálisgép-figyelője). Ezen a téren az egyik legérdekesebb fejlesztés a WebAssembly. A WASM-et, amelyet eredetileg a natív kód céljára tervezték a böngészőkön történő futtatáshoz, most arra használják fel, hogy tetszőleges kódot futtasson bármiféle folyamat alapú elkülönítés nélkül. Miközben továbbra is azt gondolom, hogy a zsűri nem akarja megnézni, vajon az elszigeteltségnek ez a formája valóban megfelel-e az összegyűjtésnek, a Strangeloop lenyűgöző beszéde volt erről a témáról, amely megmagyarázza a WASM tulajdonságait, ami ezt még kissé tartóssá teszi.

Videó

16. Hogyan működnek a C ++ hibakeresők, Simon Brand

A cím elég önmagától értetődő. A beszélgetések mindent elmagyaráznak, mi az ELF bináris fájlok, a DRAWF szimbólumok, a töréspontok működésének mechanikája, a kód átlépése valóban magában foglalja, a többszálú alkalmazásokkal való munka a hibakeresésben és még sok más. Ez határozottan az egyik három legfontosabb beszélgetésem a hihetetlen beszélgetések ezen listáján.

Videó

17. A szoftvertervezés filozófiája, John Ousterhout

A A szoftverfejlesztés filozófiája című könyv a legjobb műszaki könyvet írta le, amelyet 2018-ban olvastam. A könyv minden egyes fejezete megéri aranyának súlyát, de valószínűleg a mélyebb modulokról szóló fejezetet említik a legjobban. A beszélgetés néhány, a könyvben bemutatott fő gondolatot és vörös zászlót érint, de ha én lennék az, én csak megvásárolnám a könyvet, és megtenném.

Videókönyv

18. Clangd: méretezhető C ++ nyelvkiszolgáló architektúrája, Ilya Biryukov

A Microsoft az utóbbi évek egyik legérdekesebb fejlesztése a Language Server Protocol volt. A clang-fordító 5.0 kiadása bevezette a Clangd, az LLVM által a Language Server Protocol számára megvalósított változatot. A Clangd a Language Server Protocol megvalósítása, amely olyan szolgáltatásokat nyújt, mint a kód kitöltése, a javítás, a goto meghatározás, az átnevezés stb. Olyan ügyfelek számára, mint a C / C ++ forrás szerkesztők. Ez egy jó beszéd volt a CPPCon részéről, amely a libclang néhány korlátozására vonatkozott, és megmagyarázza a Clangd fejlődésének motivációit, valamint általános építészetét.

19. Az LLVM tisztségviselői és ABI-k, John McCall

Az LLVM-ben szereplő korutineket először a Microsoft Gor Nishanov adta hozzá, és a C ++ coruteines TS igényei szerint alakították ki. Ez egy hihetetlen beszéd volt az LLVM Fejlesztői Találkozón, amely a különböző megvalósítási szempontok előnyeire és hátrányaira terjed ki, például a cedés vezérlésére (kontextusváltás, a szétválasztás megosztott folytatással és hozamonkénti visszatérési funkciókkal), a helyi állam tárolására (egymásra épülő korutinák). , oldalkiosztás, verem-együttélés) az adatok előállítása érdekében, valamint a kódgenerálás kihívásai olyan nyelvi funkciók számára, amelyeket főként a generátorok hajtanak végre. A beszélgetés ezután a Swift programozási nyelv „visszatérő folytatása ízének” nevezett eltérő típusú süllyesztés néhány részletével foglalkozik, ahol néhány optimalizálás a Swift SIL rétegén zajlik, és nem közvetlenül az LLVM szinten.

Videó

PS: Az LLVM Fejlesztői Találkozó minden beszélgetése mélyen oktató jellegű. Csak ezt az egy beszélgetést néztem, de biztos vagyok benne, hogy boldogan ajánlom az összes többi beszélgetést is, mihelyt megnézem őket.

20. Kotlin / natív infrastruktúra fejlesztése az LLVM / Clang segítségével, Nikolay Igotti

A Kotlin Native egy szuper érdekes fejlesztés az elmúlt években, amely lehetővé teszi a Kotlin kód lefordítását a platformon elérhető bináris fájlokba (ELF, Mach-O, WASM stb.), Így natív módon futtatható a JVM-en belüli futtatás mellett. Ez egy nagyon jó beszéd volt az Európai LLVM Fejlesztői Találkozón a Kotlin / Native mechanikájáról, ideértve a memóriakezelés JVM-en kívüli megvalósításának, a kivételek kezelésének és a WASM-höz való átvitel néhány kihívását (amelynek nincs futási ideje, nincs memória allokátora, nincs kivétel stb.), valamint az LLVM-mel felmerült általános problémákról (lassú kódolás és összekapcsolás, hiányzó nyilvános LLDB plugin API stb.).

Dia diák

21. Friss Async Kotlinnel, Roman Elizarov

Az aszinkron programozás spektruma széles és változatos. Ez egy fantasztikus beszéd volt a Goto Koppenhágától az aszinkron programozás ezen paradigmáinak néhány alapját képező kihívásokról, különös tekintettel a jövőbeli visszahívási alapú megközelítésre. A beszélgetés ezután azt tárgyalja, hogy Kotlin miként akarja megoldani ezt a problémát a korutinákkal azáltal, hogy szinkron interfészt biztosít a felhasználónak (a felfüggesztés primitívjén keresztül), miközben a motorháztető alatt folytatásokat és felfüggesztési pontokat használ egy állapotgép létrehozására. A beszélgetés leglenyűgözőbb része Kotlin megközelítésének és az aszinkron / várakozás C # megközelítésének összehasonlítása volt, miközben Kotlin tervezési döntéseinek mögöttes ereje az volt, hogy a párhuzamosság nehéz és az ergo kifejezetten kifejezett. A beszélgetés azzal ér véget, hogy még a CSP-esque mintákat hogyan lehet megvalósítani Kotlin korutin primitívumainak felhasználásával.

Videó

22. Kotlin natív párhuzamos modell, Nikolay Igotti

Kotlinnek nincs nyelvi szintű párhuzamos primitívje. A fentiekben ismertetett Kotlin szokások egy könyvtár alapú konstrukció, amely a JVM-et célozza meg. Kotlin / Natív megkerüli a JVM stílusú megosztott objektum-halom és zárolást azáltal, hogy fenntartja annak invariánsát, hogy egy objektum vagy egyetlen végrehajtási környezet tulajdonában van, vagy változatlan (megosztott XOR-változtatható). Ez a KotlinConf nagyszerű beszéde volt, amely megvizsgálja, hogyan lehet ezt elérni a „nem külsőleg hivatkozott objektum algráfokkal”.

Ezenkívül a Kotlinnek mint nyelvnek nincs beépíthetetlensége a típusrendszerbe. A megváltoztathatatlanságot a fagyasztás fogalma érinti el, amely minden objektumnak egy adott objektumból eljutó tranzitív bezárását megváltoztathatatlanná teszi. Ezenkívül a Kotlin / Native lehetővé teszi az objektumok tulajdonjogának átruházását a végrehajtási környezetben is. A beszélgetés bemutatja a Kotlin / Native által biztosított alapvető biztonságos párhuzamos primitívumokat, mint például a „leválasztható objektum grafikonok”, az atomikus és a színészi stílusú „dolgozók”, hogyan működik a referenciaszámláláson alapuló memóriakezelés Kotlin / Native-ban, valamint hogy miként érhető el az interoperabilitás más runtimes.

Dia diák

23. Ideje írni operációs rendszert Rust-ban, Bryan Cantrill

Gyakran vettek magam szem előtt valakivel vagy más karosszékkel, aki elmélete szerint a Rust „olyan nyelv, amelynek célja a kernel beírása”.

Nos, igaz?

Ez a legfontosabb szakértő nagyszerű beszéde arról a témáról, amelyben a Rust különösen alkalmas rendszeríró szoftverek írására, valamint arról, hogy ki lehet-e nézni azokat a kihívásokat, amelyek a Rust teljes kernelének esetleges írására vonatkoznak. Ha szereti a számítógépes történelem naplóit, és azt a ritka márkájú forró vásárlást, amelyet valóban jól tájékozott és indokolt gondolkodás támaszt alá, ez lehet a beszélgetés az ön számára.

Dia diák

24. Mit ért „menetbiztosnak”, Geoffrey Romer

Ez egy csodálatos beszéd volt a CPPCon részéről, amelynek célja az olyan fogalmak egyértelművé tétele, mint például a „menetbiztos”, vagy pontosabbak, mint például az „adatverseny” és a „versenyfeltétel”, amelyek gyakran rossz absztrakciószinten működnek. A beszélgetés az „API verseny” fogalmának és az „API verseny” körül felépíthető invariantok használatát javasolja, amelyet ajánlások követnek mind a C ++ könyvtár, mind az alkalmazás szerzői számára.

Videó

25. Gyorsan biztonságos, változtatható állam, Ben Cohen

A módosítható állapotról fontos, hogy ne felejtsük el, hogy a megosztott módosítható állapot rossz, nem pedig a módosítható állapot. Ez egy csodálatos beszéd volt a Functional Swift konferencián arról, hogy mikor és hogyan kell használni a helyi változtatható állapotot a biztonság vagy a teljesítmény feláldozása nélkül. A beszélgetés áttekint bizonyos Swift nyelvi funkcióit, amelyek bizonyos funkcionális ízét biztosítják azáltal, hogy megakadályozzák a funkciók mutációjában esetlegesen felmerülő hibák bizonyos kategóriáit.

Videó

26. A hibakezelés dolgai és adományai, Joe Armstrong

Örültem, hogy ezt a beszélgetést élőben láttam a koppenhágai GOTO-n. Ennek a beszélgetésnek az a lényege, hogy lehetetlen egyetlen gépen hibatűrést elérni; az üzenet átadása tehát elkerülhetetlenné válik. Az épület hibatűrő elosztott rendszerek felépítése a hibák felismerésére és azok kezelésére szolgál. A legmegfontosabbnak tartott hibakezelési filozófia az, amelyben a szoftver helyesnek bizonyítható a fordításkor, és ahol a szoftvert valójában hibásnak tekintik, és várhatóan futási idő alatt hibás lesz. A kis dolgok nagy csoportjait lehetetlen igazolni; így fontos lesz a „hibamag” meghatározása, amely a rendszer egy részének kell lennie, amelynek helyesnek kell lennie. Ha programozóként nem tudja, mit kell tennie, összeomlik. Akkor a szoftver egyszerűbbé válik.

Bocsánatot kap, ha úgy gondolja, hogy ez egy 45 perces magyarázat az Erlang programozási nyelv létezésére.

Videó

27. QUIC: TCP-csere fejlesztése és telepítése az interneten, Ian Swett és Jana Iyengar

Ez a NetDev nagyszerű beszéde volt, amely bemutatja a Google-ban kifejlesztett QUIC protokollt, a tervezési döntéseket (miért kell az UDP tetejére rétegezni, jobb veszteség-visszatérítést, rugalmas torlódás-szabályozást), az evolúciót, valamint számtalan kalandot, amellyel a QUIC-t Linuxra méretezik .

Dia diák

28. A Network.framework bemutatása: A Sockets modern alternatívája, Josh Graessley, Tommy Pauly, Eric Kinnear

Az aljzatok használata nehéz lehet kapcsolat létesítéséhez vagy adatátvitelhez (még nem blokkoló aljzatok esetén is) vagy mobilitáshoz.

A Network.framework egy modern szállítási API, amely alternatívája az Apple platformon lévő aljzatoknak. Ez egy nagyszerű séta volt a 2018-os WWDC-től, amely az első kapcsolatépítés anatómiáján átment a kapcsolat életciklusához, a különféle szakaszokban végzett számtalan optimalizálással együtt. Ez valószínűleg a legjobban bemutatott beszéd is ezen a listán.

Videó

29. Kubernetes és a kiszolgáló nélküli út, Kelsey Hightower

Ez Kelsey Hightower beszéde.

Többet kell mondanom? Azt hiszem, nem.

Videó

30. A rozsda felhasználása a játék fejlesztéséhez, Catherine West

A beszélgetés azt mondja: "Ez talán a leg unalmasabb beszélgetés ..."

Ez nem.

Lehet, hogy ez a lista legjobb beszélgetése.

Videó