“Aruandes pole õigust olla igav”: intervjuu Baruch Sadogurskyga konverentsidel peetud kõnede kohta

Baruch Sadogursky - JFrogi arendaja advokaat, raamatu "Liquid Software" kaasautor, kuulus IT-esineja.

Intervjuus selgitas Baruch, kuidas ta valmistub oma ettekanneteks, mille poolest erinevad väliskonverentsid Venemaa omadest, miks peaksid osalejad neil osalema ja miks peaksid nad esinema konnakostüümis.

“Aruandes pole õigust olla igav”: intervjuu Baruch Sadogurskyga konverentsidel peetud kõnede kohta

Alustame kõige lihtsamast. Miks sa arvad, miks üldse konverentsidel esineda?

Tegelikult on konverentsidel esinemine minu jaoks töö. Kui vastata üldisemalt küsimusele “Miks on minu töö?”, siis on see (vähemalt JFrogi ettevõtte jaoks) kahe eesmärgi saavutamiseks. Esiteks kontakti loomiseks meie kasutajate ja klientidega. See tähendab, et konverentsidel esinedes olen kättesaadav, et kõik, kellel on küsimusi, tagasisidet meie toodete ja ettevõtte kohta, saaksid minuga rääkida, saan neid kuidagi aidata ja parandada nende kogemusi meie toodetega töötamisel.

Teiseks on see vajalik brändi tuntuse suurendamiseks. See tähendab, et kui ma räägin mõnest huvitavast asjast, siis inimesed tunnevad huvi selle vastu, milline JFrog see on, ja selle tulemusena satuvad nad meie arendajasuhete lehtrisse, mis lõpuks läheb meie kasutajate lehtrisse, mis lõpuks läheb meie ostjate lehter.

Palun rääkige meile, kuidas te esinemisteks valmistute? Kas on mingi ettevalmistusalgoritm?

Enam-vähem standardset ettevalmistusetappi on neli. Esimene on algus, nagu filmides. Mingi idee peab tekkima. Idee tekib ja siis küpseb see päris kaua. See küpseb, mõtled, kuidas seda ideed kõige paremini esitada, mis võtmes, mis formaadis, mida selle kohta öelda. See on esimene etapp.

Teine etapp on konkreetse plaani kirjutamine. Teil on idee ja see hakkab omandama üksikasju selle kohta, kuidas te seda esitate. Tavaliselt tehakse seda mingis mõttekaardi formaadis, kui idee ümber ilmub kõik raportiga seonduv: toetavad argumendid, sissejuhatus, mõned lood, mida selle kohta rääkida tahad. See on teine ​​etapp – plaan.

Kolmas etapp on selle kava järgi slaidide kirjutamine. Kasutate mõnda abstraktset ideed, mis ilmuvad slaididel ja toetavad teie lugu.

Neljas etapp on läbisõidud ja proovid. Selles etapis on oluline veenduda, et loo kaar on välja kujunenud, et lugu oleks sidus, ja veenduda, et ajastuse osas on kõik korras. Pärast seda saab aruande valmisolekuks kuulutada.

Kuidas te aru saate, et "selle teemaga" tuleb tegeleda? Ja kuidas kogute aruannete jaoks materjali?

Ma ei tea, kuidas vastata, see lihtsalt tuleb kuidagi. Kas see on "Oi, kui lahe see siin välja tuli" või "Oh, keegi ei tea ega mõista seda tegelikult" ja on võimalus rääkida, selgitada ja aidata. Üks neist kahest valikust.

Materjali kogumine sõltub suuresti aruandest. Kui see on ettekanne mingil abstraktsel teemal, siis on see rohkem kirjandus, artiklid. Kui see on midagi praktilist, siis on selleks koodi kirjutamine, mõned demod, toodetes õigete kooditükkide leidmine jne.

Baruchi kõne hiljutisel Amsterdami 2019. aasta DevOpsi tippkohtumisel

Esinemishirm ja ärevus on ühed levinumad põhjused, miks inimesed lavale ei lähe. Kas teil on nõuannet neile, kes tunnevad end esinedes närviliselt? Kas olete mures ja kuidas saate hakkama?

Jah, mul on see, see peaks olema ja ilmselt hetkel, kui ma enam muretsemise lõpetan, on see põhjus sellest asjast loobuda.

Mulle tundub, et see on täiesti normaalne nähtus, kui lähed lavale ja su ees on palju inimesi. Sa muretsed, sest see on suur vastutus, see on loomulik.

Kuidas sellega toime tulla? On erinevaid viise. Mul pole seda kunagi olnud sellisel tasemel, et peaksin sellega otse võitlema, nii et mul on raske öelda.

Kõige tähtsam, mis mind samuti aitab, on sõbralik nägu – mõni tuttav nägu publikust. Kui palute kellelgi tuttaval teie jutule tulla, istuge esireas keskele, et saaksite talle alati otsa vaadata ja inimene on positiivne, naeratab, noogutab, toetab, minu arvates on see tohutu, tohutu abi. Ma ei palu seda konkreetselt kellelgi teha, aga kui juhtub, et publiku hulgas on tuttav nägu, aitab see palju ja maandab stressi. See on kõige olulisem nõuanne.

Esinete palju Venemaa ja rahvusvahelistel konverentsidel. Kas näete erinevust Venemaa ja väliskonverentside ettekannete vahel? Kas publikus on vahet? Organisatsioonis?

Ma näen kahte suurt erinevust. Selge on see, et konverentsid on erinevad nii Venemaal kui välismaal, aga kui võtta haigla keskmine, siis Venemaal on konverentsid aruannete sügavuse, hardcore poolest tehnilisemad. Sellega on inimesed harjunud, võib-olla tänu sellistele suurtele konverentsidele nagu Joker, JPoint, Highload, mis on alati põhinenud hardcore ettekannetel. Ja just seda inimesed konverentsidelt ootavadki. Ja paljude jaoks on see näitaja sellest, kas see konverents on hea või halb: seal on palju liha ja hardcore'i või palju vett.

Kui aus olla, siis võib-olla tänu sellele, et esinen palju väliskonverentsidel, ei nõustu ma selle lähenemisega. Usun, et pehmete oskuste aruanded, “poolhumanitaarsed raportid” pole vähemad ja võib-olla isegi olulisemad konverentside jaoks. Kuna mõningaid tehnilisi asju saab lõpuks lugeda raamatutest, saate need selgeks teha kasutusjuhendi abil, kuid kui rääkida pehmetest oskustest, psühholoogiast, suhtlemisest, siis seda kõike pole vähemalt kuskilt võtta. lihtne, juurdepääsetav ja arusaadav. Mulle tundub, et see pole vähem oluline kui tehniline komponent.

See on eriti oluline DevOpsi konverentside (nt DevOpsDays) puhul, sest DevOps ei puuduta üldse tehnoloogiat. DevOps on ainult suhtlus, see on lihtsalt viis, kuidas inimesed, kes pole varem koos töötanud, saavad koos töötada. Jah, seal on tehniline komponent, sest automatiseerimine on DevOpsi jaoks kriitiline, kuid see on vaid üks neist. Ja kui DevOpsi konverents ei räägi DevOpsist rääkimise asemel saidi töökindlusest või automatiseerimisest või torujuhtmetest, siis vaatamata sellele, et see on väga raske, jätab see konverents minu arvates mööda DevOpsi olemusest ja muutub süsteemihalduse konverentsideks. , mitte DevOpsi kohta.

Teine erinevus on ettevalmistuses. Jällegi võtan haigla keskmised ja üldjuhtumid, mitte konkreetsed. Välismaal eeldavad nad, et enamik inimesi on oma elus läbinud mingisuguse avaliku esinemise koolituse. Vähemalt Ameerikas on see osa kõrgharidusest. Kui inimene on kõrgkooli lõpetanud, siis on tal juba arvestatav avaliku esinemise kogemus. Seega, pärast seda, kui programmikomisjon on kavaga tutvunud ja aru saanud, millest raport räägib, ei tehta kõneleja eest rääkimise kohta enam koolitust, sest arvatakse, et ta suure tõenäosusega teab, kuidas seda teha.

Venemaal selliseid oletusi ei tehta, sest vähesel inimesel on avaliku esinemise kogemus ja seetõttu koolitatakse kõnelejaid palju rohkem. Jällegi üldiselt on läbijooksud, esinejatega tunnid, esinejate abistamiseks on avaliku esinemise kursused.

Selle tulemusena kõrvaldatakse nõrgad esinejad, kes suhtlevad halvasti, või aidatakse neil saada tugevamaks esinejaks. Asjaolu, et läänes peetakse avalikku esinemist oskuseks, mis paljudel inimestel on, annab lõppkokkuvõttes vastupidise efekti, sest see oletus osutub sageli valeks, ekslikuks ja inimesed, kes ei tea, kuidas avalikult esineda, ajavad avalikult sassi. lavastada ja koostada vastikuid aruandeid. Ja Venemaal, kus arvatakse, et avaliku esinemise kogemus puudub, tuleb lõpuks palju paremini välja, sest neid koolitati, testiti, valiti hea jne.

Need on kaks erinevust.

Kas olete DevOpsDaysil teistes riikides käinud? Mille poolest need teie arvates teistest konverentsidest erinevad? Kas on mingeid erilisi omadusi?

Olen ilmselt käinud mitmekümnel DevOpsDaysi konverentsil üle maailma: Ameerikas, Euroopas ja Aasias. See konverentsifrantsiis on üsna ainulaadne selle poolest, et sellel on enam-vähem väljakujunenud formaat, mida võite igalt poolt neilt konverentsidelt oodata. Formaat on järgmine: eesliinikonverentsi ettekandeid on suhteliselt vähe ja avatud ruumide formaadile pühendatakse palju aega.

Avatud ruumid on formaat, kus koos teiste osalejatega arutatakse teemat, mille poolt hääletas kõige rohkem inimesi. See, kes selle teema välja pakkus, on juht, tema hoolitseb selle eest, et arutelu algaks. See on suurepärane formaat, sest nagu me teame, pole suhtlus ja võrgustike loomine ühegi konverentsi vähem tähtsad osad kui ettekanded. Ja kui konverents pühendab poole oma ajast võrguvormingule, on see väga lahe.

Lisaks peetakse DevOpsDaysil sageli välgukõnelusi – need on lühikesed viieminutilised aruanded, mis võimaldavad teil palju kohta palju teada saada ja avada oma silmad uutele asjadele mitteigavas vormingus. Ja kui keset tavaaruannet saite aru, et see pole teie oma, siis on aeg raisatud, 30-40 minutit teie elust raisatud, siis siin räägime viie minuti aruannetest. Ja kui te ei ole huvitatud, siis see lõpeb varsti. “Räägi meile, aga kiiresti” on samuti väga hea formaat.

On rohkem tehnilisi DevOpsDays ja on neid, mis on spetsiaalselt kohandatud DevOpsiga: protsessid, koostöö ja sellised asjad. Huvitav on omada mõlemat ja huvitav on omada mõlemat. Ma arvan, et see on täna üks parimaid DevOpsi konverentsi frantsiise.

Paljud teie etendused sarnanevad etenduste või näidenditega: mõnikord peate kõne Kreeka tragöödia vormis, mõnikord mängite Sherlocki rolli, mõnikord esinete konnakostüümis. Kuidas sa nendega välja mõtled? Kas on mingeid lisaeesmärke peale selle, et aruanne ei oleks igav?

Mulle tundub, et ettekandel pole õigust olla igav, sest esiteks ma raiskan kuulajate aega, igavas reportaažis on nad vähem kaasatud, nad on vähem õppinud, vähem uusi asju õppinud ja see pole nii. nende aja parim raiskamine. Teiseks pole ka minu eesmärgid saavutatud: nad ei arva minust midagi head, nad ei arva midagi head JFrogist ja minu jaoks on see mingi ebaõnnestumine.

Seetõttu pole igavatel reportaažidel vähemalt minu jaoks õigust eksisteerida. Püüan muuta need huvitavaks, atraktiivseks ja meeldejäävaks. Etendused on üks võimalus. Ja tegelikult on meetod üsna lihtne. Kõik, mida vajate, on välja mõelda mõni huvitav formaat ja seejärel esitada samad mõtted, mis esitatakse tavaaruande vormis ebatavalises vormingus.

Kuidas ma selle peale tulen? See ei ole alati sama. Mõnikord tulevad mulle pähe need ideed, mõnikord on need mõned ideed, mis mulle antakse, kui ma läbi jooksen või aruande kohta mõtteid jagan ja nad ütlevad mulle: "Oh, seda saab nii teha!" See juhtub erinevalt. Idee ilmumine on alati väga rõõmus ja lahe, see tähendab, et saate teha huvitavama ja kaasahaaravama reportaaži.

“Aruandes pole õigust olla igav”: intervjuu Baruch Sadogurskyga konverentsidel peetud kõnede kohta

Kelle kõned IT-valdkonnast teile isiklikult meeldivad? Kas selliseid kõlareid on? Ja miks?

On kahte tüüpi esinejaid, kelle esitlusi ma naudin. Esimene on kõlarid, mille moodi ma püüan olla. Nad räägivad huvitavalt ja kaasahaaravalt, püüdes tagada, et kõik oleksid huvitatud ja kõik kuulaksid.

Teist tüüpi kõnelejad on need, kes suudavad rääkida igast tavaliselt igavast hardcore'ist väga huvitavalt ja põnevalt.

Teise kategooria nimedest on selleks Aleksei Šepelev, kes räägib huvitavalt ja humoorikalt mingist sügavast jõudlusprügikogumisest ja java virtuaalmasina sisemustest. Veel üks uusimate DevOopsi avastus on Sergei Fedorov Netflixist. Ta rääkis puhttehnilisest asjast, kuidas nad oma sisu edastamise võrku optimeerisid, ja rääkis seda väga huvitaval viisil.

Esimesest kategooriast - need on Jessica Deen, Anton Weiss, Roman Shaposhnik. Need on kõnelejad, kes räägivad huvitavalt, huumoriga ja saavad vääriliselt kõrgeid hinnanguid.

Tõenäoliselt on teil konverentsidel esinemiseks rohkem kutseid kui aega seda teha. Kuidas valida, kuhu lähed ja kuhu mitte?

Konverentse ja esinejaid, nagu peaaegu kõike muud, juhivad pakkumise ja nõudluse turusuhted ning üksteise väärtus. On konverentse, mis, noh, ütleme, tahavad mind rohkem, kui ma neid vajan. Mis puudutab publikut, keda ma seal kohtun, ja mõju, mida ma loodan seal avaldada. On konverentse, kus ma, vastupidi, tahan käia palju rohkem, kui neil mind vaja on. Minu jaoks pakutava väärtuse põhjal otsustan, kuhu minna.

See tähendab, et kui see on näiteks mingi geograafia, kuhu mul on strateegiliselt vaja minna, see on suur tuntud konverents, millel on hea maine ja kuhu inimesed lähevad, siis ilmselgelt on mul seda väga vaja. Ja ma eelistan seda teistele konverentsidele.

Kui see on mingi väike piirkondlik konverents ja võib-olla meid ei huvita, siis võib juhtuda, et reis sinna ei õigusta sellele asjale kuluvat aega. Nõudluse, pakkumise ja väärtuse normaalsed turusuhted.

Hea geograafia, hea demograafia, potentsiaalselt head kontaktid, suhtlus on garantii, et konverents on minu jaoks huvitav.

Ühes oma intervjuus mainisite, et esinete umbes neljakümnel konverentsil aastas. Kuidas sa tööga hakkama saad ja esinemisteks valmistud? Ja kas sellise graafikuga õnnestub töö/pereelu tasakaalu hoida? Jagage oma saladusi?

Konverentsidele reisimine on lõviosa minu tööst. Muidugi on kõike muud: on aruanneteks valmistumine, enda tehnilises vormis hoidmine, koodi kirjutamine, uute asjade õppimine. Seda kõike tehakse paralleelselt konverentsidega: õhtuti, lennukis, päev varem, kui oled juba konverentsile saabunud ja on homme. Midagi sellist.

Muidugi on raske töö- ja eraelu tasakaalu säilitada, kui veedate nii palju aega ärireisidel. Aga ma püüan seda kompenseerida sellega, et vähemalt siis, kui ma ei ole komandeeringus, olen 100% perega koos, õhtuti meilidele ei vasta, üritan mitte osaleda helistab õhtuti ja nädalavahetustel. Kui ma ei ole ärireisil ja on pereaeg, on see tõesti 100% pereaeg. Kas see töötab ja kas see lahendab probleemi? Ei. Aga ma loodan, et see kompenseerib kuidagi mu perele kogu äraoleku aja.

Üks Baruchi aruannetest on "Meil on DevOps. Vallandame kõik testijad."

Kas nii tiheda graafiku juures õnnestub hoida tehnilist taset või oled juba programmeerimisest eemaldunud?

Konverentsi kõnedeks ja muudeks tegevusteks valmistudes püüan teha tehnilisi asju. Need on kõikvõimalikud tehnilised demod, mingid minireportaažid, mida me stendidel anname. See ei ole programmeerimine-programmeerimine, see on rohkem integreerimine, kuid see on vähemalt tehniline töö, mida ma üritan teha. Nii säilitan teadmisi meie toodete, uute funktsioonide ja muu kohta.

Muidugi on ilmselt võimatu öelda, et ma olen praegu sama hardcore kodeerija kui 7 aastat tagasi. Pole kindel, kas see on halb. See on ilmselt mingi loomulik evolutsioon. See on minu jaoks vähem huvitav ja mul on vähem aega, nii et tõenäoliselt Jumal õnnistagu teda.

Endiselt pean end tugevaks tehnikaspetsialistiks, hoian end ikka toimuvaga kursis, hoian end käpuli. Selline on minu tänane hübriidolukord.

Rääkige meile paar naljakat lugu või äärmuslikku olukorda, mis teiega juhtusid: jäite lennukist maha / kustutasite esitluse / teate ajal katkes vool / pagas ei jõudnud kohale?

Naljakatest olukordadest on mulle kõige rohkem meelde jäänud kõikvõimalikud kohutavad ebaõnnestumised, mis reportaažide ajal juhtusid. Loomulikult, kuna see on kõige stressirohkem olukord, sest see on publik, aeg ja peate veenduma, et nad seda ei raiskaks.

Mul oli kõne ajal nii Windowsis kui ka Macis "sinine surmaekraan". Windowsis juhtus see korra, Macis paar korda. See on muidugi stressirohke, kuid me kuidagi lahendame selle probleemi, arvuti taaskäivitub, ma jätkan sel ajal midagi ütlemist, kuid stress on tohutu.

Ilmselt kõige naljakam olukord, mis mul oli, oli Groovy konverentsil. Ma ei mäleta täpselt, kus konverents toimus, tundub, et hotellis ja selle hotelli vastas toimus mingi ehitus või renoveerimine. Ja nii ma rääkisin mõnest koodist, mille ma kirjutasin, see oli demo. See oli demo esimene iteratsioon, mis oli arusaadav, kuid võib-olla mitte hästi kirjutatud. Ja ma kavatsesin seda lihtsalt ümber kujundada ja täiustada ning mainisin mõnda fraasi, näiteks "enese mahajätmine" selle kohta, et see on "pask kood". See asus teisel korrusel ja sel ajal tõstis vastas ehitusplatsil kraana just teisaldatavat tualetti. Ja lava oli akna vastas. See tähendab, et ma vaatan sellest aknast välja, ütlen "pask kood" ja tualett ujub aknast mööda. Ja ma ütlen kõigile: "Pöörake ümber, meil on siin illustratsioon." See oli ilmselt minu mõtete parim slaid – lendav tualett minu raportis, kui rääkisin nõmedast koodist.

Sellistest lugudest nagu pagas ei tulnud – see on põhimõtteliselt tavaline lugu, millest pole isegi rääkida. Kõikvõimalikest reisinippidest saame kokku leppida eraldi intervjuu, kus saab rääkida pagasist, mis kohale ei jõudnud, aga midagi kriitilist polnud.

Püüan iga hinna eest väga kõvasti lennata, tulla ja osaleda kõigil konverentsidel, millel lubasin, sest jällegi on inimeste aeg. Inimeste aeg on hindamatu, sest see on selline usalduskrediit, mille nad teile annavad. Ja kui see laen raisku läheb, siis seda hiljem enam tagasi ei saa.

Kui inimene veetis aega, tuli konverentsile minu ettekannet kuulama ja ma võtsin selle kätte ja ei tulnud, on see halb, sest selle inimese aega ei saa kuidagi tagasi. Seetõttu on minu jaoks ülitähtis kõigist antud lubadustest kinni pidada ja siiani kõik toimib.

Paljud mõtlevad nii: „Milleks üldse konverentsidele minna? Saate vaadata videot YouTube'is ja saate alati veebis vestelda. Miks peavad osalejad teie arvates konverentsidel käima?

Suurepärane küsimus! Võrgustiku loomiseks peaksite minema konverentsidele. See on hindamatu ja selle saamiseks pole muud võimalust. Olen juba maininud suhtlemise, suhtlemise ja pehmete oskuste tähtsust. Kahjuks ei anna YouTube'is video vaatamine pehmete oskuste kogemust. Seetõttu peate suhtlemise huvides käima konverentsidel.

Lisaks on vähemalt minu jaoks YouTube’ist videoid vaadates kaasamine hoopis teistsugune ning materjal jääb meelde ja jääb palju kehvemini meelde. Võib-olla olen asi ainult minus, aga ma kahtlustan, et vestluse ajal ruumis viibimine ja YouTube'is video vaatamine on täiesti erinevad asjad. Eriti kui aruanne on hea, siis mulle tundub, et seda on palju-palju parem otse-eetris kuulata. See on nagu live-kontserdi ja plaadi kuulamine.

Ja kordan veel kord: võrgustike loomine ja suhtlus ei ole midagi, mida YouTube'ist võtta.

Ühisaruanne Leonid Igolnikuga DevOpsConil

Palun ütle mõned lahkumissõnad neile, kes alles plaanivad esinejaks saada või on alles rääkima hakanud?

Otsige kohalikke kohtumisi. Kohalikud kohtumised on suurepärane viis oma esinejakarjääri alustamiseks mitmel põhjusel. Esiteks otsivad kohalikud kohtumised alati esinejaid. Võib juhtuda, et ilma kogemusteta ja kuulus esineja olemata on sul raske mõnele kuulsale konverentsile kandideerida või saab programmikomitee pärast sinuga suhtlemist aru, et võib-olla on sul veel veidi vara. Seevastu kohalikud kohtumised otsivad alati esinejaid ja sisenemisriba on palju-palju madalam, nii et kohale jõudmine on palju lihtsam.

Samuti on stressitase täiesti erinev. Kui tuleb 10-15-30 inimest, pole see sugugi sama, kui saalis on 150-200-300 inimest, nii et see on palju lihtsam.

Jällegi on kohaliku kohtumise kulud palju väiksemad: te ei pea kuhugi lendama, ei pea veetma päevi, võite tulla lihtsalt õhtul. Meenutades minu nõuannet publiku sõbraliku näo tähtsuse kohta, on palju lihtsam tulla kellegagi kohalikule kohtumisele, sest see ei maksa raha. Kui esinete konverentsil, tulete esinejana tasuta, kuid see teie +1, kes on avalikkuses sõbralik nägu, peab pileti ostma. Kui räägite kohtumisel, siis seda probleemi pole, võite kaasa võtta ühe või kaks või kolm sõpra, kes on ruumis sõbralik nägu.

Ja täiendav pluss on see, et kohtumiste korraldajatel on palju rohkem võimalusi teid aidata. Sest konverentsikorraldajatel on näiteks 60 ettekannet, mis vajavad ülevaatamist, harjutamist ja ettevalmistamist. Ja kohtumiste korraldajatel on üks, kaks või kolm, nii et saate loomulikult palju rohkem tähelepanu.

Lisaks on kohalikelt kohtumistelt palju lihtsam tagasisidet saada. Olete oma raporti lõpetanud ja nüüd teie ja publik juba suhtlete ja arutavad midagi teie raportiga seonduvat. Suurte konverentside puhul see sageli nii ei ole. Tegite raporti ja kõik. Publik, kes oli teie raporti ajal hall mass, on lahkunud ja te ei tea neist enam midagi, te ei kuule, te ei saa tagasisidet.

Mida iganes võib öelda, kohalikud kohtumised on suurepärane teema üldiselt ja eriti algajatele.

Baruch esineb 7. detsembril toimuval konverentsil DevOpsDays Moskva. Baruch analüüsib oma raportis reaalseid tõrkeid, mis iga päev ja igal pool tarkvara uuendamisel ette tulevad. See näitab, kuidas kõikvõimalikud DevOpsi mustrid sobivad erinevatesse stsenaariumidesse ja kuidas nende õige rakendamine võib teid päästa.

Saates veel: Aleksander Tšistjakov (vdsina.ru), Mihhail Tšinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrei Šorin (DevOpsi konsultant).

Tule tutvuma!

Allikas: www.habr.com

Lisa kommentaar