Labākais 2018. gada Tech Talks

Iepriekšējos divus gadus es publicēju savu iecienītāko sarunu sarakstu ar iepriekšējo gadu (šeit ir šīs ziņas 2016. gada izdevums un šeit ir 2017. gada izdevums).

Šis saraksts nekādā ziņā nav visaptverošs, un es esmu pārliecināts, ka no 2018. gada notiek daudz tehnoloģiju sarunu, kuras es atklāšu tikai daudz vēlāk. Bet starp sarunām, kuras apmeklēju vai skatījos, tās bija dažas no labākajām (nevienā īpašā secībā).

  1. Mikroprocesoru nākotne, Sofija Vilsone

Izskatās, ka oriģinālās ARM mikroshēmas slavenā pioniere Sofija Vilsone uzskata, ka Mūra likuma termiņš tuvojas beigām (kopā ar dažiem citiem, kas vēlāk uzskaitīti šajā amatā). Šī bija fenomenāla JuliaCon saruna, kas iedziļinās mikroprocesoru vēsturē, attīstībā un nākotnē.

Video

2. Hurricane’s Butterfly: patoloģiski funkcionējošu sistēmu atkļūdošana, Bryan Cantrill

Divas no sarunām, kas iekļuva mana iepriekšējā gada sarakstā, bija Zebras līdz galam un atkļūdošana ugunsgrēkā: Turiet galvu, kad sistēmas ir zaudējušas prātu. Šī bija saruna līdzīgā veidā un tika sniegta ar būtisko Kantrilas nojautu, modrību un sparu, no kā mēs esam pieraduši gaidīt. Programmatūra ir veidota kā abstrakciju kaudze ar šķietami nelielām problēmām vienā slānī (tauriņiem), kas var pārveidoties par sistēmiskiem patoloģiskiem veiktspējas jautājumiem citā (viesuļvētras). Ņemot vērā šādu viesuļvētru, kā var atrast tauriņus?

Slaid video

3. Aizveriet cilpas un atveriet prātus: kā pārņemt kontroli pār lielām un mazām sistēmām, Colm MacCarthaigh

Jāatzīst, ka es neesmu vērojis visas sarunas no AWS re: Invent, bet no tām, kuras es skatījos, šī, iespējams, bija mana iecienītākā saruna. Tas nosaka dažus projektēšanas principus ļoti stabilu un uzticamu sistēmu (piemēram, vadības plakņu) izveidošanai.

  1. Pārbaudīt visas lietas
  2. Kriptogrāfiskā autentifikācija
  3. Šūnas, čaulas un “saindēšanās degustētāji”
  4. Asinhronā sakabe
  5. Slēgtas atsauksmes cilpas
  6. Mazi spiedieni un lieli vilkšanas veidi (konfigurēšanai)
  7. Izvairieties no aukstiem startiem un aukstajām kešatmiņām
  8. Droseles
  9. Deltas
  10. Modalitāte un pastāvīgs darbs

Bija aizraujoši uzzināt, kā daži anti-raksti un neintuktīvi dizaini patiesībā varētu palīdzēt uzlabot sistēmu stabilitāti. Iespējams, ka visinteresantākā sarunas daļa bija ideja, ka stabilām vadības sistēmām ir nepieciešama “PID cilpa” - proporcionāli, integrāli, atvasināti komponenti un ka spēja apskatīt sistēmas dizainu un vietas, ja tajā trūkst kāda no šīm, ir lielvalsts. Šī ir pirmā reize, kad dzirdu par šo “PID cilpu”; saruna iesaka grāmatā Izkliedēto vadības sistēmu projektēšana, lai uzzinātu vairāk par to, kā vadības teorijas principus var attiecināt uz sadalīto sistēmu inženieriju.

Bija arī interesanti uzzināt AWS hierarhiju vai prioritātes: drošību, izturību, pieejamību, ātrumu.

Video slaidi

4. Datoru arhitektūras zelta laikmets, Deivids Pattersons un Džons Hennessijs

Šī bija fantastiska saruna par mikroprocesoru vēsturi un attīstību, pāreju no CISC uz RISC mašīnām līdz Mūra likuma beigām un Dennarda mērogošanai, kas savukārt piedāvā nebijušas iespējas progresam “domēna specifiskās arhitektūras” telpā. “Domēna specifiskā arhitektūra” ietver gan jauninājumus aparatūrā (neironu tīkla procesorus mašīnmācībai, piemēram, TPU, gan NVIDIA GPU, gan FGPA), kā arī specifisku domēna programmatūru (piemēram, Swift TensorFlow). Sarunu noslēdz ar stāstu par RISC V ISA pirmsākumiem un izaugsmi.

Tiem, kas dod priekšroku rakstītam rakstam, nevis videoklipam, šomēnes laikrakstā ACM ir raksts, kuru autori ir Hennessy un Patterson (slavenās grāmatas Computer Architecture autori) par šo pašu tēmu. Varētu būt beidzies Mūra likums par tranzistoriem, taču šķiet, ka pēdējos gados ir izdots mašīnmācīšanās darbu skaits, pēc Mūra likuma ievērošanas pieauguma.

Video [Hennessy at Stanford, ~ 1 stunda]

Video [Pattersons Facebook @ mēroga konferencē ~ 30 minūtes]

5. Droša klienta uzvedība, Ariel Goh

Tam ir jābūt acīmredzamam vecām izplatītām sistēmām, taču ir vērts atkārtot, ka klienti ir svarīga izplatītās sistēmas sastāvdaļa un tāpēc viņiem jāpiedalās noturības centienos. Šī ir fantastiska SRECon Asia / Austrālijas saruna par klientu dizaina paraugpraksi, lai uzlabotu visu sistēmas elastību. Piedāvātie paņēmieni ietver klienta pieprasījumu saraustīšanu, nejaušības pievienošanu, lai visi klienti nejauši neveicas sinhronizācijā, kad viņi iesniedz pieprasījumus, kad nav jāmēģina vēlreiz, jittering atkārtoti mēģinājumi, atkārtojumi ar eksponenciālu dublējumu (un vienlaicīgi iegūtie pirkumi), “atkārtoti mēģināt budžetus” (piemēram, kļūdu budžeti) ), pārvietojot daļu vadības uz serveri un izveidojot atgriezenisko saiti starp serveri un klientiem, adaptīvo droseles iestatīšanu klientiem un daudz ko citu.

Video

6. Kā apkalpot un aizsargāt (ar klienta izolāciju), Frančs Džonsons

Šī ir vēl viena lieliska SRECon Asia / Austrālijas saruna par tāda pakalpojuma kā Google Maps (ar pārpilnību iekšējo un ārējo klientu) aizsardzību no pārslodzes. Saruna skar tādas problēmas kā sistēmas pārslodze (un tādas aktuālas problēmas kā straumes, kas aizmirst par sistēmas pārslodzi), kaskādes kļūme, statisko kvotu nepilnības, plusi un mīnusi graciozu degradācijas paņēmienu ieviešanai dažādos steka slāņos (klientam, mala, fasāde, aizmugure).

Video

7. Lietišķā izpildījuma teorija, Kavja Džoša

Šī ir neticama (kā vienmēr) Kavya no QCon London saruna par to, kā izmantot veiktspējas modelēšanas paņēmienus, lai varētu atbildēt uz jautājumiem, piemēram, par to, kādu papildu slodzi sistēma var atbalstīt, nesamazinot reakcijas laiku, un kā atklāt sistēmas sašaurinājumus. Sākumā saruna iepazīstina mūs ar tipisku tīmekļa servera piemēru, lai parādītu, kā analizēt veiktspēju “atvērtās sistēmās”, kam seko “slēgtu sistēmu” piemērs, un kā abi balstās uz dažādiem pieņēmumiem un prasa dažādas analīzes metodes.

Slaid video

8. Amazon Aurora: Dizaina apsvērumi augstas caurlaidspējas mākoņu vietējo relāciju datu bāzēm, Sailesh Krišnamurthy

Šī bija absolūti uzkrītoša saruna no Facebook @Scale konferences par dažiem dizaina lēmumiem un kompromisiem, kas ir Amazon Amazonora pamatā - krātuves motoram, kas darbina daudzus populārus AWS datu bāzes piedāvājumus. Tiek apgalvots, ka Aurora veic automātisku mērogošanu līdz 64TB katrā datu bāzes instancē un nodrošina augstu veiktspēju un pieejamību ar līdz 15 zema latentuma lasīšanas replikām, atjaunošanu brīdī-laikā, nepārtrauktu S3 dublēšanu un replikāciju trijās pieejamības zonās.

Ir divas [1] [2] pievienotās baltās grāmatas, kuras Amazon publicējis vietnē Aurora. Sarunā ir atsauce uz daudziem punktiem, it īpaši no otrā darba, no kuriem galvenais ir tas, ka izplatītā vienprātība samazina sniegumu un ka vietējā valsts faktiski var būt laba lieta. Izmantojot patiesības avotu nemainīgu žurnālu, Aurora izvairās no izplatītas vienprātības par dalības izmaiņām, izmantojot dažas “konsekvences oāzes”, izmantojot laikmetus kā sargus kā kvoruma rakstīšanas veidu un izvairoties no kvoruma lasīšanas. Tas ir interesanti laikmetā, kad darījumu sistēmas rada kaut ko atgriezenisku, un Google sludina par to, kāpēc mums vajadzētu izvēlēties stingru konsekvenci, kad vien iespējams, Amazon izvēlas dažādus kompromisus.

Video

9. FoundationDB krātuves slāņa nākotne, Stīvs Athertons

Šī bija aizraujoša saruna par FoundationDB krātuves slāņa nākotni no FoundationDB samita. FoundationDB ir izplatīts, pasūtīts galveno vērtību krātuve, bet pats krātuves slānis nav izplatīts un tam var piekļūt ar vienu procesu no viena pavediena. Saruna iedziļinās jaunā uzglabāšanas motora prasībās, neprecizitātēs (vienlaicīgi rakstītāji, zems saistību latentums), pēc tam pēta vairāku datu struktūru plusus un mīnusus (B + koki, LSM koki) un Redwood versijas izvēles iemeslus. B + koks.

Video

Vēl viena lieliska fondaDB samita saruna bija par dokumentu slāni, kura video var atrast šeit.

10. Autonomā testēšana un programmatūras izstrādes nākotne, Vils Vilsons

Pirmkārt, Vils, iespējams, ir viens no labākajiem runātājiem, ko esmu redzējis runājam (viņa iepriekšējā saruna par Strangeloop 2014 izplatīto sistēmu testēšanu ar deterministisko simulāciju ir viens no visu laiku maniem favorītiem).

Šī ir fenomenāla saruna no dibināšanas dibināšanas fonda dibināšanas samita, kas padara diezgan pārliecinošu gadījumu uz AI balstītu pieeju testēšanai. Sarunā tiek identificētas 3 galvenās testēšanas problēmas: trauslums (jūsu tests ir atkarīgs no gadījuma rakstura jūsu sistēmas īpašībām - tās nav tās, kuras uzskatījāt, ka testējat), izsmeļoša un nepamanīta.

Sarunā tiek apgalvots, ka testi ir lieliski regresijas pagriešanai, bet gandrīz pilnīgi bezjēdzīgi nezināmu-nezināmu atklāšanai. Sarunā visas iepriekšminētās problēmas tiek uzskatītas par simptomiem, un patiesā pamatproblēma ir tā, ka pārbaude joprojām ir pilnībā manuāla. Pat “automatizēta pārbaude” jebkad ir saistīta ar to, ka Dženkinss vada testa komplektu, kuru autori ir cilvēki. Pēc tam saruna nosaka sapni par autonomu testēšanu kā nepieciešamību pēc automātiskas testu izpildes arī automātisku testu izveidošanu.

Video

11. Izkliedētu sistēmu projektēšana ar TLA +, Hillel Wayne

Šī bija lieliski pieejama CodeMesh saruna par formālās specifikācijas izmantošanu izkliedēto sistēmu projektēšanā. Padomājiet par to kā maigu ievadu TLA +. Kvotu skaitā ietilpst:

Dodiet sistēmai pietiekami daudz laika, un tā darīs visu, ieskaitot neveiksmi.
Kods nav dizains. Kods neparāda, kā darbojas jūsu sistēma. Tā ir tikai jūsu ieviešana; tam nav jābūt jūsu dizainam, tas nedrīkst būt jūsu dizains. Un, ja jūs domājat, ka varat izveidot sistēmu un saprast sistēmu, izmantojot tikai kodu, man ir tilts, lai jūs pārdotu, un es jums to pārdosim divreiz, vienlaikus.

Video

12. Ko mēs saņēmām nepareizi: mikrolīdzinājumu piedzimšanas mācība Google, Bens Sigelmans

Šīs bija virpuļviesnīcas runas par izplatītās skaitļošanas tehnikas galveno avotu Google, kas skāra visu, ko Google ieguva tiesības uz praksi, kas nebija gluži pareiza, bet kurai bija izteiktas paralēles ar to, ko mūsdienās pazīstam kā “mikropakalpojumus”. Sarunā tiek uzsvērts, kur plašāka nozare patiesībā izdara noteiktas lietas labāk nekā tas, kā to darīja Google (piemēram, pakalpojumu tīkls), kad un kāpēc Google tehnoloģiskās izvēles un prakses atdarināšana nedarbojas pārējiem mums un kāpēc tas kļūst īpaši svarīgi jāspēj atbildēt uz noteikta veida jautājumiem pirms arhitektūras paradigmu pieņemšanas (piemēram, “bez servera”).

Video slaidi

13. Izplatītā apaļkoku apstrādes dizaina darbnīca, Laura Nolan, Phillip Tischler, Salim Virji

Šīs ir absolūti neticamas sarunas par liela mēroga izkliedētās sistēmas arhitektūras praktiskajām iespējām, ieskaitot to, kā tuvināties mērogošanai, kā novērtēt kompromisus pa dažādām asīm, kā arī tonnas aploksnes aprēķinu aizmugures, lai pamatotu katru lēmumu.

Google SRE darbgrāmatā (brīvi pieejama tiešsaistē) ir vesela nodaļa ar nosaukumu Non-Abstract Large System Design, kas veltīta tieši šai tēmai, un esmu dzirdējis, ka tā ir izšķirīga intervija visā Google SRE intervijas ciklā, jo tieši tā ir tā, kas statistiski, visticamāk, apsteidza kandidātu, kam seko kodēšanas intervijas. Personīgi es domāju, ka tas attiecas ne tikai uz SRE, bet tas ir jālasa visiem, kas veido un izmanto izkliedētās sistēmas.

Diemžēl es tam neesmu atradis video.

Slaidi

14. Slodzes līdzsvarošana Hyper Scale, Alan Halachmi un Colm MacCarthaigh

Šī ir patiešām aizraujoša Facebook konferences Networking @Scale konference par slodzes līdzsvarošanas attīstību AWS. Tas izgaismo HyperPlane - sistēmu, kas ir AWS S3 Load Balancer, VPC NAT Gateway un PrivateLink pamatā, un daudz ko citu. Īpaši man patika mācīties par ierosināto SHOCK principu (pašdziedinošs vai pastāvīgs darbs), kas liek domāt, ka, veidojot sistēmu, tai jābūt izturīgai pret pat lieliem satricinājumiem. Vai izsakoties savādāk, “ja mainās kaut kas liels, sistēmai vajadzētu būt spējīgai darboties kā parasti”. Sarunā ierosināts:

1. Pastāvīgas pūles un atveseļošanās no neveiksmēm ir dabiskie stāvokļi
2. Vienmēr strādājiet remonta režīmā. Kad mezgls neizdodas, hiperplāns faktiski strādā mazāk!
3. Izstrādājot liela mēroga sistēmas, mēs nevēlamies, lai tās būtu sarežģītas. Mēs vēlamies, lai viņi būtu pēc iespējas vienkāršāki. Šajā nolūkā mēs vēlamies pēc iespējas mazāk darbības režīmu (piemēram, hiperplānam nav atkārtota režīma. Tas ir ķipars ar TCP iedzimto atkārtotas mēģināšanas mehānismu). Uzklājot dažādus darbības režīmus, rodas kombinatorisks sarežģītības eksplozija, kā rezultātā sistēmu ir neticami grūti pārbaudīt. Mēs vēlamies sistēmu, kas būtu konsekventa un vienmēr darbotos tā, kā mēs gaidām.
4. Saruna arī iepazīstina ar shuffle shading ideju - DDoS mazināšanas paņēmienu (kur izolēšana ir galvenā mazināšanas metode), ko tagad plaši izmanto daudzos AWS pakalpojumos.

Video

15. Izolēšana bez konteineriem, Tailers Makmulēns

Viena no manām interesējošajām jomām ir tā, ko es draugiem esmu raksturojusi kā “aprēķina spektru” - virtuālie automāti, mikroVM, ligzdotie VM, konteineri (un “smilšu kastes konteineru” aromāti, piemēram, Kata konteineri) un “serverless” (vai funkcijas kā pakalpojums). Īpaši mani interesē šo piedāvājumu “izolācijas spektrs” - no stingras procesa līmeņa izolācijas līdz izolēšanai, izmantojot smilšu kasti, piemēram, V8. Pēdējos gados virtualizācijas telpā ir parādījušās vairākas tehnoloģijas, piemēram, gVisor (hipervizors, kas lietotāja telpā ievieš Linux kodola API apakškopu) Firecracker - virtuālās mašīnas monitors, kas izveidots vieglu un bez serveru slodzēm mikro-VM. , kas veidots uz crosvm (Chrome OS virtuālās mašīnas monitors). Viens no aizraujošākajiem notikumiem šajā telpā ir WebAssembly. Sākotnēji tas bija paredzēts vietējā koda darbināšanai pārlūkprogrammās. Tagad CDN pakalpojumu sniedzēji izmanto WASM, lai palaistu patvaļīgu kodu bez jebkāda veida uz procesu balstītas izolācijas. Lai gan es joprojām domāju, ka žūrija nav pārliecināta par to, vai šī izolācijas forma patiešām iet garām, šī bija aizraujoša Strangeloop saruna par šo pašu tēmu, kas izskaidro WASM iezīmes, kas to padara pat nedaudz noturīgu.

Video

16. Kā darbojas C ++ atkļūdotāji, Simons Brends

Virsraksts ir diezgan pašsaprotams. Sarunās tiek izskaidrots viss, sākot no ELF binārajiem failiem, no DRAWF simboliem, no pārtraukumu punktu veikšanas mehānikas, par to, ko patiesībā nozīmē koda ievadīšana, no darba ar vairāku vītņu programmām atkļūdotājā un vēl daudz vairāk. Šī noteikti ir viena no manām trim sarunām šajā neticamo sarunu sarakstā.

Video

17. Programmatūras dizaina filozofija, John Ousterhout

Grāmata “Programmatūras dizaina filozofija” bija labākā tehniskā grāmata, kuru lasīju 2018. gadā. Katra grāmatas nodaļa ir zelta svara vērtībā, taču, iespējams, tā nodaļa, kas saistīta ar dziļajiem moduļiem, ir tā, kuru esmu citējis visvairāk. Saruna skar dažas no grāmatā apskatītajām galvenajām idejām un sarkanajiem karodziņiem, bet, ja es būtu tu, es vienkārši nopirktu grāmatu un tiktu ar to galā.

Video grāmata

18. Clangd: pielāgojama C ++ valodas servera arhitektūra, Iļja Biryukov

Viens no interesantākajiem Microsoft jaunumiem pēdējos gados ir Valodu servera protokols. Klanu kompilatora 5.0 izlaidums ieviesa Clangd, LLVM valodu servera protokola ieviešanu. Clangd ir Valodu servera protokola ieviešana, lai klientiem, piemēram, C / C ++ avota redaktoriem, nodrošinātu tādas funkcijas kā koda pabeigšana, labošana, goto definīcija, pārdēvēšana utt. Šīs bija labas CPPCon sarunas, kas skāra dažus libclang ierobežojumus un izskaidro Clangd attīstības motivāciju, kā arī tās vispārējo arhitektūru.

19. Kārtējās pārstāvniecības un ABI LLVM, John McCall

Izstrādājumus LLVM vispirms pievienoja Microsoft Gor Nishanov, un tie tika izstrādāti, ņemot vērā C ++ korutīnu TS vajadzības. Šī bija neticama LLVM izstrādātāju sanāksmes saruna, kurā apskatīti daži ieguvumi no plusiem un mīnusiem, kas saistīti ar dažādiem ieviešanas aspektiem, piemēram, cedēšanas kontrole (konteksta maiņa, korupcijas sadalīšana ar dalītu atsākšanu un vienas peļņas atsākšanas funkcijas) vietējās valsts glabāšanai (satriecoši korupcijas gadījumi). , sānu sadalījums, skursteņu kopdzīve) datu iegūšanai, kā arī problēmas, kas saistītas ar kodu ģenerēšanu valodas funkcijām, kuras darbina tādi korutīni kā ģeneratori. Pēc tam sarunā tiek apskatītas dažas detaļas par atšķirīgu pazemināšanas veidu, ko sauc par “atgrieztās turpinājuma garšu” Swift programmēšanas valodai, kur daži no optimizācijām notiek Swift SIL slānī, nevis tieši LLVM līmenī.

Video

PS: Visas sarunas no LLVM izstrādātāju sanāksmes ir dziļi izglītojošas. Es esmu vērojis tikai šo vienu sarunu, bet es esmu pārliecināts, ka es arī labprāt iesaku visas pārējās, tiklīdz esmu nokļuvis viņu skatīties.

20. Kotlin / Vietējās infrastruktūras attīstīšana ar LLVM / Clang, Nikolajs Igotti

Kotlin Native ir ļoti interesanta attīstība pēdējos gados, kas ļauj Kotlin kodu apkopot līdz platformu binārajiem failiem (ELF, Mach-O, WASM utt.), Tāpēc to var palaist vietēji papildus spējai darboties JVM. Šī bija patiešām laba saruna no Eiropas LLVM izstrādātāju sanāksmes par Kotlin / Native mehānismu, ieskaitot dažus no izaicinājumiem, kas saistīti ar atmiņas pārvaldības ieviešanu ārpus JVM, izņēmumu apstrādi un pārvietošanu uz WASM (kurai nav izpildlaika, nav atmiņas sadalītāja, bez izņēmumiem utt.), kā arī dažas no vispārīgajām problēmām, ar kurām nākas saskarties ar LLVM (lēns kodegēns un sasaiste, trūkstošā LLDB spraudņa API utt.).

Slaid video

21. Svaigs asins ar Kotlinu, Romāns Elizarovs

Asinhronās programmēšanas spektrs ir plašs un daudzveidīgs. Šī bija fantastiska Goto Kopenhāgenas saruna par izaicinājumiem, uz kuriem balstās dažas no šīm asinhronās programmēšanas paradigmām, jo ​​īpaši par atzvanīšanas balstītu pieeju nākotnes līgumiem. Pēc tam saruna turpinās par to, kā Kotlin mēģina atrisināt šo problēmu ar korutīniem, nodrošinot sinhronu interfeisu lietotājam (caur suspend primitīvu), atrodoties zem pārsega, izmantojot turpinājumus un balstiekārtas punktus, lai izveidotu valsts mašīnu. Visaizraujošākā sarunas daļa bija Kotlinas pieejas salīdzinājums ar C # pieeju async / gaidīt, un Kotlin dizaina izvēles galvenais virzītājspēks ir tāds, ka vienlaikus ir grūti un ergo ir jābūt skaidram. Saruna beidzas ar to, kā pat CSP-esque modeļus var ieviest, izmantojot Kotlinas sākotnējos primitīvus.

Video

22. Kotlinas dzimtā līdzvērtības modelis, Nikolajs Igotti

Kotlinam nav paralēlvalodas primitīvu valodas līmenī. Kotlin pamatprogramma, kā aprakstīts iepriekš minētajā sarunā, ir uz bibliotēku balstīts konstrukts, kura mērķis ir JVM. Kotlin / Native izvairās no JVM stila koplietota objekta kaudzes un bloķēšanas, saglabājot invariantu, ka objekts vai nu pieder vienam izpildes kontekstam, vai arī tas ir nemainīgs (dalīts XOR mainīgs). Šī bija lieliska KotlinConf saruna, kurā apskatīts, kā tas tiek panākts ar “ne uz āru atsauktiem objektu apakšgrāfiem”.

Turklāt Kotlīnas kā valodas tipu sistēmā nav iebūvēta negrozāmība. Nemaināmība tiek panākta ar sasalšanas jēdzienu, kas padara visu objektu, kas sasniedzami no dotā objekta, pārejošu slēgšanu nemainīgu. Turklāt Kotlin / Native arī ļauj nodot īpašumtiesības uz objektiem visos izpildes kontekstos. Saruna iepazīstina ar Kotlin / Native nodrošinātajiem pamata drošās vienlaicības primitīviem, piemēram, “atdalāmu objektu grafikiem”, atomu un aktieru stila “darbiniekiem”, kā atsauces skaitīšanas balstītā atmiņas pārvaldība darbojas Kotlin / Native, kā arī kā tā panāk savietojamību ar citām. runtimes.

Slaid video

23. Vai ir laiks uzrakstīt operētājsistēmu Rustā, Braiena Kantralā

Es bieži esmu ticis pakļauts kādam citam krēsla teorijai, ka Rūsa ir “valoda, kas paredzēta kodola ierakstīšanai”.

Nu, vai tā ir?

Šī ir lieliska galvenā eksperta saruna par tēmu, kāpēc Rust ir īpaši piemērota sistēmu programmatūras rakstīšanai, kā arī dažas problēmas, kas saistītas ar visa kodola potenciālu rakstīšanu Rustā. Ja jums patīk ceļojumi pa skaitļošanas vēstures žurnāliem un šī retā zīmola “karstā reize”, kuru patiesībā atbalsta labi pārdomāta un pamatota domāšana, tā varētu būt jūsu saruna.

Slaid video

24. Ko jūs domājat “drošs pavediens”, Geoffrey Romer

Šī bija lieliska CPPCon saruna, kuras mērķis ir izdalīt tādus terminus kā “drošs pavediens” vai precīzākus terminus, piemēram, “datu rase” un “sacensību apstākļi”, kuri bieži darbojas nepareizā abstrakcijas līmenī. Sarunā ierosināts izmantot jēdzienu “API rase” un invariantus, kurus var veidot ap “API rasi”, kam sekos ieteikumi gan C ++ bibliotēkai, gan aplikāciju autoriem.

Video

25. Ātri drošs, mainīgs stāvoklis, Bens Koens

Runājot par mainīgu stāvokli, ir svarīgi atcerēties, ka tas ir koplietojamais mainīgais stāvoklis, kas ir slikts, nevis mainīgs stāvoklis pats par sevi. Šī bija lieliska konferences Functional Swift saruna par to, kad un kā izmantot vietējo mainīgo stāvokli, neupurējot drošību vai veiktspēju. Sarunā tiek apskatītas dažas valodas Swift valodas funkcijas, kas tai piešķir noteiktu funkcionālu aromātu, novēršot noteiktas kļūdu kategorijas, kas iespējamas funkciju mutācijā.

Video

26. Kļūdu apstrādes dotības un ziedojumi, Džo Ārmstrongs

Man bija prieks skatīties šo sarunu tiešraidē GOTO Kopenhāgenā. Šīs sarunas galvenā būtība ir tāda, ka nav iespējams panākt kļūdas pielaidi, izmantojot vienu mašīnu; ziņojumu nodošana tādējādi kļūst neizbēgama. Ēku, kas iztur tolerantu, sadalītas sistēmas ļauj atklāt kļūdas un rīkoties ar tām. Kļūdu apstrādes filozofija, kas tiek uzskatīta par visapdomīgāko, ir tāda, kurā programmatūru var pierādīt, ka tā sastādīšanas laikā ir pareiza, un kurā tiek pieņemts, ka programmatūra faktiski ir nepareiza un paredzams, ka tā neizdosies izpildlaika laikā. Lielu, mazu lietu komplektu nav iespējams pierādīt kā pareizu; tādējādi kļūst svarīgi spēt definēt “kļūdas kodolu”, kas ir pareizs sistēmas apakškopā. Ja kā programmētājs nezināt, ko darīt, avarējiet. Tad jūsu programmatūra kļūst vienkāršāka.

Jums tiks piedots, ka domājat to par 45 minūšu skaidrojumu Erlang programmēšanas valodas esamībai.

Video

27. QUIC: Tīkla TCP aizstāšanas izstrāde un ieviešana, Ian Swett un Jana Iyengar

Šī bija lieliska NetDev uzstāšanās, kas iepazīstina ar Google izstrādāto QUIC protokolu, dizaina lēmumiem (kāpēc to uzklāt virs UDP, labāku zaudējumu atgūšanu, elastīgu sastrēgumu kontroli), tā attīstību, kā arī neskaitāmajiem piedzīvojumiem mērogojot QUIC Linux. .

Slaid video

28. Iepazīšanās ar Network.framework: mūsdienīga alternatīva ligzdām, Josh Graessley, Tommy Pauly, Eric Kinnear

Kontaktligzdas var būt grūti izmantot, ja runa ir par savienojuma izveidošanu vai datu pārsūtīšanu (pat ar bloķējošām ligzdām) vai mobilitāti.

Network.framework ir moderna transporta API, kas ir alternatīva rozetēm Apple platformās. Tas bija lielisks gājiens no WWDC 2018, kurš devās cauri sākotnējā savienojuma izveidošanas anatomijai līdz savienojuma dzīves ciklam, kā arī neskaitāmajām optimizācijām, kas veiktas dažādos posmos. Iespējams, ka šī saraksta labāk atspoguļotā saruna.

Video

29. Kubernetes un ceļš uz bez serveriem, Kelsey Hightower

Tā ir Kelsey Hightower saruna.

Vai man vairs jāsaka? Es domāju, ka nē.

Video

30. Rust izmantošana spēles attīstībā, Ketrīna Vest

Saruna sākas ar teikumu “Šī, iespējams, ir garlaicīgākā saruna…”

Tas nav.

Tā faktiski varētu būt pati labākā saruna šajā sarakstā.

Video