Od zamestnancov Techopedia, 15. marca 2017
Jedlo s sebou: Host Eric Kavanagh diskutoval o ladení a profilovaní databázy s Dr. Robinom Bloorom, Dezom Blanchfieldom a Bertom Scalzom IDERA.
Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.
Eric Kavanagh: Dobre, dámy a páni, je stredu o 4:00 východného času, a to samozrejme znamená.
Robin Bloor: Nemôžem ťa počuť, Eric.
Eric Kavanagh: Bol som tu už dávno, takže nie ste sami. Ale téma je dnes skutočne zaujímavá. Je to druh veci, o ktorú sa chcete uistiť, že sa odohráva na pozadí vašej spoločnosti, pokiaľ to neurobíte osoba, v takom prípade sa chcete ubezpečiť, že to robíte správne. Pretože hovoríme o ladení. Nikto nemá rád chyby, nikto nemá rád, keď softvér prestane fungovať - ľudia sa rozčuľujú, používatelia sa dostanú nepriateľsky. To nie je dobré. Takže budeme hovoriť o „rýchlej reakcii: ladenie databázy a profilovanie na záchranu“.
Je tu skutočne vaše miesto, zasiahnite ma, samozrejme, na Twitteri, @eric_kavanagh.
Tento rok je horúci. A ladenie bude horúce, bez ohľadu na to. Bude to skutočne jeden z týchto problémov, ktorý nikdy nezmizne, bez ohľadu na to, ako dobre sa k týmto veciam dostaneme, vždy tu budú problémy, takže kľúčom je, ako sa dostanete k miestam, kde môžete tieto problémy rýchlo vyriešiť? V ideálnom prípade máte skvelých programátorov, skvelé prostredie, v ktorých sa príliš nedarí, ale ako sa hovorí staré príslovie: „Nehody sa stali v najlepších rodinách.“ A to isté platí aj pre organizácie. Takže, toto sa stane, stane sa to, otázkou je, aké bude vaše riešenie pre riešenie a riešenie týchto problémov?
Robin Bloor, potom náš vlastný Dez Blanchfield, budeme počuť zdola a samozrejme nášho dobrého priateľa, Bert Scalzo, z spoločnosti IDERA. A v skutočnosti odovzdám kľúče Robinovi Bloorovi, vezmem ich preč. Podlaha je na vás.
Robin Bloor: OK. Toto je zaujímavá téma. Myslel som si, že pretože Dez bude pravdepodobne pokračovať v skutočných technikách a vojnových príbehoch o ladení, myslel som si, že urobím iba diskusiu na pozadí, aby sme si mohli získať úplne okrúhly obraz o tom, čo sa deje. Urobil som to dlho a býval som kóder, tak to je, a bol som takmer v pokušení touto prezentáciou začať voskovať text o myšlienke open source, ale myslel som, že to nechám na niekoho iného.
Tu je zoznam známych bugov a väčšina z nich sa dostane na špičkový zoznam niekoho, v podstate všetko okrem posledných dvoch stojí najmenej 100 miliónov dolárov. Prvým z nich bol Mars Climate Orbiter, ktorý sa stratil vo vesmíre, a to kvôli problému s kódovaním, keď si ľudia zamieňali metrické jednotky s (smiechom) nôh a palcov. Pri lietadle Ariane Five Flight 501 došlo k nesúladu medzi motorom, ktorý bol nasadený, a počítačmi, ktoré mali pri spustení raketu spustiť. Viacnásobné zlyhania počítača, vybuchujúca raketa, hlavné správy. Sovietsky plynovod v roku 1982 bol vyhlásený za najväčší výbuch v histórii planéty; Nie som si istý, či to je. Rusi ukradli nejaký automatizovaný riadiaci softvér a CIA si uvedomila, že to urobia a vložia do nej chyby a Sovieti ju implementovali bez testovania. Takže vyhodili do povetria potrubie, ktoré bolo zábavné.
Morrisov červ bol kódovací experiment, ktorý sa zrazu stal dravým červom, ktorý obchádzal všetkých - zjavne spôsobil škodu v hodnote 100 miliónov dolárov; to je samozrejme odhad. Spoločnosť Intel urobila slávnu chybu s matematickým čipom - matematickou inštrukciou na čipe Pentium v roku 1993 - ktorá mala stáť viac ako 100 miliónov dolárov. Program Apple Maps je pravdepodobne najhorším a najnebezpečnejším spustením všetkého, čo spoločnosť Apple kedy urobila. Ľudia, ktorí sa pokúsili použiť ho, boli, myslím, niekto, kto šiel okolo 101, a zistili, že mapa Apple hovorí, že sa nachádzali uprostred San Francisco Bay. Ľudia sa preto začali odvolávať na aplikáciu Apple Maps ako iLost. - náš najdlhší výpadok v roku 1990 - je to jednoducho zaujímavé z hľadiska nákladov na niečo také - AT&T boli mimo prevádzky asi deväť hodín a pri diaľkových hovoroch to stálo asi 60 miliónov dolárov.
A ja som bol v britskej poisťovni a táto databáza implementovala novú verziu databázy a začala vymazávať údaje. A pamätám si to veľmi dobre, pretože som bol následne pozvaný, aby som sa kvôli tomu zúčastnil výberu databázy. A bolo veľmi zaujímavé, že vzali novú verziu databázy a mali veľa testov, ktoré urobili pre nové verzie databázy, ktoré prešli všetkými testami. Našlo sa skutočne nejasný spôsob vymazania údajov.
Takže to tak je. Myslel som, že budem hovoriť o nesúlade impedancie a vydaní SQL. Je zaujímavé, že relačné databázy ukladajú údaje do tabuliek a kódovače majú tendenciu manipulovať s údajmi v objektových štruktúrach, ktoré skutočne veľmi dobre nemapujú tabuľky. A z tohto dôvodu získate to, čo sa nazýva nesúlad impedancie, a niekto s tým musí nejakým spôsobom riešiť. Čo sa však skutočne deje, pretože jeden model, model kodéra a databáza iný model, nie sú nijako zvlášť zarovnané. Dostanete chyby, ktoré by sa jednoducho nestali, keby priemysel postavil veci, ktoré spolupracujú, čo je podľa mňa veselé. Takže v podstate, na strane kódovačov, keď získate hierarchie, môžu to byť typy, môžu to byť sady, môže to byť zlá schopnosť API, môže to byť veľa vecí, ktoré jednoducho vyhodia veci z hľadiska interakcie s databázou. Ale to, čo je pre mňa najviac, naozaj zaujímavé; vždy ma prekvapilo, že ste mali túto bariéru SQL, ktorá je tiež istým druhom impedancie takým spôsobom, že kodéry a databáza navzájom spolupracujú. Takže SQL má rozpoznávanie údajov, čo je v poriadku a má DML na výber, projektovanie a pripojenie, čo je v poriadku. Môžete s tým vyhodiť veľa možností, ako získať údaje z databázy. Má však veľmi malý matematický jazyk na vykonávanie vecí. Má to niečo z toho a toho a má veľmi málo času. Z tohto dôvodu je SQL nedokonalým prostriedkom na získanie údajov. Takže, chlapci z databázy zostavili uložené procedúry, aby mohli žiť v databáze, a dôvod, prečo tam uložené procedúry boli, bol, že ste naozaj nechceli hádzať údaje späť a späť do programu.
Pre niektoré funkcie bola mimoriadne špecifická pre dáta, takže nejde iba o referenčnú integritu a kaskádové vymazania a podobné veci, o databázu sa postarali všetky náhle, keď do databázy vkladáte funkčnosť, čo samozrejme znamenalo, že funkčnosť aplikácie by sa mohla rozdeliť medzi programátor a databázu samotnú. A to spôsobilo, že implementácia niektorých druhov funkcií bola veľmi náročná, a preto náchylnejšie k chybám. To je jedna strana databázovej hry, pretože to znamená, že ste napríklad dostali veľa implementácií, že som bol zapojený do relačných databáz, že v uložených procedúrach, ktoré sa spracúvajú, je skutočne strašne veľa kódu. oddelene od kódu, ktorý je umiestnený v aplikáciách. A zdá sa, že sa to muselo stať veľmi zvláštnou vecou, mala by byť dosť inteligentná pri vykonávaní rôznych vecí.
Myslel som, že by som hovoril aj o výkone databázy, pretože chyby výkonu sa často považujú za chyby, ale v zásade môžete mať problémové miesto v CPU, v pamäti, na disku, v sieti a problémy s výkonom môžu byť kvôli uzamknutiu., Predstava by bola taká, že kódovač sa nemusel skutočne zaujímať o výkon a databáza by v skutočnosti fungovala primerane dobre. Malo by byť navrhnuté tak, aby kódovač nemusel vedieť. Získate však zlý návrh databázy, dostanete zlý návrh programu, dostanete súbežné miešanie pracovnej záťaže, čo môže tiež viesť k problémom s výkonom. Získate vyrovnávanie záťaže, získate plánovanie kapacity, rast údajov - to môže spôsobiť zastavenie alebo spomalenie databázy. Je to zaujímavé, keď sa databázy takmer naplnia, spomaľujú sa. A môžete mať problém s dátovými vrstvami, pokiaľ ide o replikáciu a potrebu replikácie a potrebu zálohovania a obnovy. Aj tak je to všeobecný prehľad.
Jediné, čo by som chcel povedať, je to, že ladenie databázy môže byť iba také náročné a netriviálne - a hovorím to preto, že som to urobil veľa - a často zistíte, že je to ako všetky situácie v ladení, ktoré aké ste kedy zažili, je prvá vec, ktorú ste kedy videli, je neporiadok. A musíte sa pokúsiť prejsť z neporiadku, aby ste zistili, ako k neporiadku došlo. A často, keď sa pozeráte na problém s databázou, všetko, na čo sa pozeráte, sú poškodené údaje a myslíte si: „Ako sa to sakra stalo?“
Každopádne odovzdám Dezovi, ktorý pravdepodobne povie viac slov múdrosti, ako som vyšiel. Neviem, ako ti môžem dať loptu, Dez.
Eric Kavanagh: Pustím to, stojím, vydržím.
Automatizovaný hlas: Účastnícke linky boli ignorované.
Eric Kavanagh: Dobre, počkajte jednu sekundu, dovoľte mi dať Dezovi loptu.
Dez Blanchfield: Ďakujem, Eric. Áno, Dr. Robin Bloor, ste skutočne najpravdepodobnejší: toto je téma, doživotný miláčik, ak odpustíte slovnú hračku, prepáčte, že som si v tom nemohol pomôcť. Dúfajme, že tu uvidíte moju prvú obrazovku, ospravedlňujeme sa za problém s veľkosťou písma v hornej časti. Témou chýb je celodenná prednáška, v mnohých prípadoch podľa mojich skúseností. Je to taká široká a široká téma, preto sa zameriam na dve kľúčové oblasti, konkrétne na koncept toho, čo považujeme za chybu, ale za problém programovania. Myslím si, že v týchto dňoch sa zavedenie chyby samo osebe stáva integrovaným vývojovým prostredím, hoci to môžu byť dlhotrvajúce chyby. Ale často je to skôr prípad profilovania kódu a je možné napísať kód, ktorý funguje, čo by mala byť chyba. Takže, môj titul snímok tu, vlastne som mal kópiu tohto vo veľmi vysokom rozlíšení A3, ale bohužiaľ to bolo zničené v pohybe domu. Je to však rukou písaná poznámka o programovom liste z roku 1945, kde údajne niektorí ľudia na Harvardskej univerzite v USA, ich druhá zostava stroja s názvom Mark II. Ladili nejaký problém spoločným jazykom, ale snažili sa nájsť chybu a ukázalo sa, že prišlo niečo mierne odlišné od toho, čo bol hardvér a pravdepodobne aj softvérový problém.
Mestský mýtus je taký, že okolo 9. septembra 1945 tím na Harvardskej univerzite ťahal stroj, narazili na niečo, čo nazývali „štafeta sedemdesiat“ - v tých dňoch sa programovanie robilo vo fyzickom zmysle, vy ste zranili kód okolo dosky, a takto ste stroj naprogramovali efektívne - a zistili, že toto číslo relé sedemdesiat, s tým bolo niečo zlé, a ukázalo sa, že sa vyskytol skutočný termín „chyba“, pretože to doslova bol mol - pravdepodobne tam bola mama zaklinená medzi kúskom medeného drôtu z jedného miesta na druhé. A príbeh hovorí, že legendárny Grace Hopper ako tento nadpis, pre môj titulný snímok, „prvý skutočný prípad nájdenia chyby“, cituje bez úvodzoviek.
Ako však Robin zdôraznil už vo svojom prvom snímke, koncept chyby siaha až do minulosti, ako si dokážeme predstaviť, že ľudia robia výpočet, pojmy ako záplata. Pojem „náplasť“ pochádza zo skutočného kúsku pásky, ktorý sa nalepí cez otvor na diernej karte. Ide však len o to, že pojem „ladenie“ vyšiel z tohto pojmu nájdenia chyby vo fyzickom stroji. Odvtedy sme túto terminológiu používali na to, aby sme sa zaoberali problémami, či už to nie je problém s kódovaním v programe, ktorý sa nekompiluje, ale ako program, ktorý nefunguje dobre. A konkrétne nebol profilovaný, len nájdite veci ako nekonečné slučky, ktoré jednoducho nikam nevedú.
Máme však aj scenár a ja som si myslel, že by som dal pár vtipných snímok skôr, ako som sa dostal do trochu podrobnejších detailov. Tu je klasická karikatúra s názvom XKCD na webe a karikaturista má celkom vtipné názory na svet. A toto je o dieťati, ktoré sa volá „Little Bobby Tables“, a jeho rodičia údajne pomenovali tohto malého chlapca Roberta '); DROP TABLE Študenti; - a to sa volá, a niečo ako „Ahoj, toto je škola tvojho syna, ktorá má nejaké problémy s počítačom, “ a rodič odpovie: „Ach, drahý, niečo zlomil?“ A učiteľ hovorí: „Dobre, Svojím spôsobom, “a učiteľ sa pýta, „ naozaj ste skutočne pomenovali svojho syna Roberta “); DROP TABLE Študenti; -? “A rodič hovorí:„ Ó, áno, malé Bobby tabuľky, ktoré mu voláme. “Každopádne hovoria, že teraz stratili ročné študentské záznamy, dúfam, že ste šťastní. Odpoveď znie: „Dobre, mali by ste vyčistiť a dezinfikovať vstupy do svojej databázy.“ A používam toľkokrát, aby som hovoril o niektorých problémoch, ktoré máme pri hľadaní vecí v kóde, že často sa kód nedíva na údaje tiež.
Ďalší vtipný, neviem, či je to skutočné alebo nie - mám podozrenie, že je to spoof - ale opäť sa dotýka aj mojej vtipnej kosti. Niekto mení poznávaciu značku na prednej časti svojho vozidla na podobné vyhlásenie, ktoré spôsobuje, že databázy klesajú v rýchlostných radaroch a tak ďalej, ktoré zachytávajú poznávacie značky automobilov. A vždy to hovorím tak, že pochybujem, že každý programátor očakával zásah a spustenie svojho kódu skutočným motorovým vozidlom, ale nikdy to nepodceňoval - silu nahnevaného geeka.
(Smiech)
Myslím si však, že to ma vedie k môjmu kľúčovému bodu, a to je to, že raz za čas sme mohli ladiť a profilovať kód ako smrteľníkov. Ale som veľmi presvedčený, že tento čas už uplynul a podľa mojich skúseností anekdoticky môj prvý - a to ma strašne starne, som si istý; Robin, ty si vítaný, že si ma za to pobavíš - ale historicky som prišiel z pozadia vo veku 14 rokov, ktorý som putoval po konci mesta, a klopal na dvere dátového centra s názvom „Data Com“ v New Zélandu a pýtam sa, či by som mohol v škole zarobiť vreckové peniaze tým, že sa dostavím neskoro v autobuse domov, asi 25 km dochádzky každý deň, vložením papiera do tlačiarní a pások do páskových jednotiek a tým, že budem len všeobecným správcom. A napodiv, dali mi prácu. Ale časom sa mi podarilo dostať sa do personálneho obsadzovania a nájsť programátorov a uvedomil som si, že milujem kódovanie a prešiel procesom spúšťania skriptov a dávkových úloh, ktoré sú na konci dňa stále kódom. Musíte napísať skripty a dávkové úlohy, ktoré vyzerajú ako mini programy, a potom prejsť celý proces sedenia ručne na 3270 termináli.
V skutočnosti bola moja prvá skúsenosť na teletypovom termináli, ktorý bol vlastne fyzickou tlačiarňou so 132 stĺpcami. V podstate uvažujte ako o veľmi starom písacom stroji s papierom, ktorý sa v ňom posúva, pretože nemali trubicu CRT. A ladiaci kód bol veľmi netriviálnym problémom, takže ste mali sklon písať celý svoj kód ručne a potom sa správať ako pisárka, robíte maximum preto, aby ste sa nedostali k chybám, aby ste sa mohli vkradnúť, pretože je veľmi frustrujúce musieť to povedať jeden riadok editora ísť na určitý riadok a potom vytlačiť riadok a potom ho zadajte späť. Ale raz za čas, to bolo, ako sme napísali kód a to je to, ako sme odladili, a dostali sme veľmi, veľmi dobre. A v skutočnosti nás to prinútilo mať veľmi dobré techniky programovania, pretože opraviť to bolo skutočným problémom. Cesta však prešla - a všetci sme s tým oboznámení - išla od zážitku z terminálu 3270 v mojom svete k digitálnemu zariadeniu VT220, kde ste mohli vidieť veci na obrazovke, ale znova ste robili to isté urobili ste na papierovej páske druh tlačeného formátu iba na CRT, ale mohli ste ich ľahšie odstrániť a nemali ste zvuk „dit dit dit dit“.
A potom viete, terminály Wyse - ako je Wyse 150, pravdepodobne moje najobľúbenejšie rozhranie k počítaču vôbec - a potom počítač a počítač Mac a v súčasnosti moderné GUI a ID, ktoré sú založené na webe. A množstvo programov prostredníctvom toho, programovanie v jednom a assembleri a PILOT a Logo a Lisp a a Fortran a Pascal a jazyky, ktoré by mohli ľudí zvrhnúť. Ale to sú jazyky, ktoré vás prinútili napísať dobrý kód; nenechali ťa preč so zlými praktikami. C, C ++, Java, Ruby, Python - a my sa dostávame ďalej do tejto programovacej fázy, dostávame viac skriptov, dostávame sa bližšie a bližšie k Structured Query Language a jazykom ako PHP, ktoré sa v skutočnosti používajú na vyvolanie SQL. Zmyslom je povedať, že pochádzajúc z môjho pozadia, som sa učil mnohými spôsobmi a tí, ktorí mi pomohli učiť sa, učili mi veľmi dobré programovacie postupy a veľmi dobré postupy týkajúce sa návrhu a procesov, aby som sa ubezpečil, že som to neurobil. predstavte kód buggy.
Programovacie metódy v týchto dňoch, napríklad, štruktúrovaný dopytovací jazyk, SQL, je to veľmi výkonný, jednoduchý dotazovací jazyk. Ale zmenili sme ho na programovací jazyk a ja neverím, že jazyk SQL bol niekedy navrhnutý ako moderný programovací jazyk, ale skreslili sme ho tak, aby sa stal týmto. A to predstavuje celý rad problémov, pretože myslíme z dvoch hľadísk: z hľadiska kódovania az pohľadu DBA. Je veľmi ľahké prísť a predstaviť chyby týkajúce sa napríklad slabých programovacích techník, lenivého úsilia pri písaní kódu, nedostatku skúseností, klasického maznáčika, ktorý mám napríklad s ľuďmi, ktorí na webe SQL skákajú a hľadajú niečo a hľadajú webovú stránku, ktorá je dostal príklad a urobil kópiu a vloženie existujúceho kódu. A potom replikovať zlé kódovanie, zanedbávať správne postupy a uvádzať ich do výroby, pretože sa im jednoducho darí, aby dosiahli požadované výsledky. Máte iné výzvy, napríklad, v týchto dňoch sa všetci všetci ponáhľame k tomu, čo nazývame preteky na nulu: snažíme sa robiť všetko tak lacné a tak rýchlo, že máme scenár, v ktorom nezamestnávame nižšie - platení zamestnanci. A nemyslím to nenápadným spôsobom, ale najímame odborníkov na každú možnú prácu. Kedysi bolo s počítačmi nič spoločné s raketovou vedou; podieľalo sa na veciach, ktoré sa rozbili a boli veľmi nahlas, alebo šli do vesmíru, alebo inžinieri boli vysokokvalifikovaní muži a ženy, ktorí absolvovali tituly a absolvovali prísne vzdelanie, ktoré im bránilo robiť bláznivé veci.
V dnešnej dobe existuje veľa ľudí, ktorí sa dostávajú do vývoja, dizajnu a databázy, ktorí nemali dlhoročné skúsenosti, nemuseli mať nevyhnutne rovnaké školenie alebo podporu. A tak skončíte scenárom len tradičného amatérskeho verzus experta. A je tu slávna línia, neviem si spomenúť, kto cenovú ponuku vytvoril, riadok znie: „Ak si myslíte, že zamestnanie experta na prácu je drahé, počkajte, kým si najmete pár amatérov, ktorí spôsobujú problém, a vy musí to vyčistiť. “A tak má tento problém SQL a je veľmi ľahké sa ho naučiť, jeho používanie je veľmi jednoduché. Podľa môjho názoru to však nie je dokonalý programovací jazyk. Je veľmi ľahké robiť veci ako robiť hviezdu odkiaľkoľvek a ťahať to všetko do programovacieho jazyka, s ktorým ste pohodlnejšie ako PHP a Ruby alebo Python, a používať programovací jazyk, s ktorým ste natívne oboznámení, robiť manipulácia s údajmi, namiesto toho, aby robil komplexnejší dotaz v SQL. A my to vidíme veľa a potom sa ľudia pýtajú, prečo databáza beží pomaly; je to preto, že milión ľudí sa snaží kúpiť lístok z online predajného systému lístkov, kde robí vybranú hviezdu odkiaľkoľvek.
Teraz je to naozaj extrémny príklad, ale z toho všetkého vyvodzujete názor. Takže, aby som to skutočne udrel domov, tu je príklad, ktorý veľa nosím. Som veľký fanúšik matematiky, milujem teóriu chaosu, milujem sady Mandelbrot. Na pravej strane je stvárnenie sady Mandelbrot, o ktorej sme si istí, že všetci vieme. A na ľavej strane je kúsok SQL, ktorý to vlastne vykresľuje. Teraz zakaždým, keď to niekde umiestnim na obrazovku, začujem toto: „Ó môj bože, niekto vykreslil sériu Mandelbrot pomocou SQL, vážne? To je šialené! “Celkom to je objasniť, čo som tam len načrtol, a to je áno, v skutočnosti teraz môžete programovať takmer všetko v SQL; je to veľmi rozvinutý, výkonný a moderný programovací jazyk. Keď to bol pôvodne dopytovací jazyk, bol navrhnutý tak, aby iba zvýšil údaje. Takže teraz máme veľmi zložité konštrukty a máme uložené procedúry, máme aplikovanú metodológiu programovania na jazyk, a tak je to veľmi ľahké pre zlú prax v programovaní, nedostatok skúseností, kód na vystrihnutie a prilepenie, nízko platení zamestnanci, ktorí sa snažia byť vysoko platenými zamestnancami, ľudia predstierajú, že vedia, ale musia sa o práci učiť.
Celá škála vecí, v ktorých je profilovanie kódu a čo nazývame ladenie, čo nie je toľko nájdenie chýb, ktoré zastavia fungovanie programov, ale chyby, ktoré len poškodzujú systém a zle štruktúrovaný kód. Keď sa teraz pozriete na túto obrazovku a myslíte si, že je to proste roztomilé a myslíte si: „Páni, aká veľká grafika, rád by som ju spustil.“ Ale predstavte si, že to beží na nejakej obchodnej logike., Vyzerá to celkom elegantne, ale hovorí sa o matematicky graficky vykreslenej teórii chaosu, ale keď premýšľate o tom, na čo by sa mohla potenciálne použiť v nejakej obchodnej logike, získate obraz veľmi rýchlo. A aby som to naozaj ilustroval - a je mi ľúto, že farby sú obrátené, malo by to byť čierne pozadie a zelený text ako zelená obrazovka, ale stále to môžete prečítať.
Išiel som a rýchlo som sa pozrel na príklad toho, čo by si mohol urobiť, keby si bol naozaj blázon a nemal vôbec žiadne skúsenosti a prišiel z iného prostredia programovania a aplikoval rád C ++ na SQL, aby som naozaj ilustroval môj názor, predtým Odovzdám nášmu učenému hosťovi z IDERA. Toto je štruktúrovaný dotaz, ktorý sa píše ako C ++, ale je kódovaný v SQL. A v skutočnosti sa vykonáva, ale vykonáva sa po dobu troch až piatich minút. A údajne odtiahne späť jeden riadok údajov z viacerých databáz, viacerých pripojení.
Opäť platí, že ak nemáte správne nástroje, ak nemáte správne platformy a prostredia, ktoré tieto veci dokážu zachytiť a dostanú sa do výroby, máte 100 000 ľudí. biť systém každý deň, hodinu alebo minútu, veľmi skoro skončíte s černobyľskou skúsenosťou, keď sa veľké železo začne topiť a zahrabať sa do jadra planéty, pretože tento kus kódu by sa nikdy nemal dostať do výroby. Ospravedlňte ma, vaše systémy a nástroje, mali by ste to vyzdvihnúť skôr, ako sa dostane kamkoľvek blízko - dokonca aj počas testovacieho procesu, dokonca aj prostredníctvom integrácie UAT a systémov, by sa mal tento kód vyzdvihnúť a zvýrazniť a niekto by mal byť odložený stranou a a povedal: „Pozri, to je skutočne pekný kód, ale získaj DBA, ktorá ti pomôže správne zostaviť tento štruktúrovaný dotaz, pretože úprimne povedané, je to jednoducho škaredé.“ A adresy URL môžete ísť a pozrieť sa - nazýva sa to najzložitejší dotaz SQL, aký ste kedy napísali. Pretože mi verte, že sa skutočne kompiluje, beží. A ak to vystrihnete a vložíte a zosmiešate databázu, je to niečo, čo by ste mali sledovať; Ak máte nástroje na sledovanie databázy, skúste roztaviť po dobu troch až piatich minút, zavolať späť čo je jeden riadok textu.
Takže, aby som to zhrnul, moje celé pozadie v kódovaní ma naučilo, že môžete dať ľuďom zbraň, a ak nie sú opatrní, budú sa strieľať do nohy; trik je ukázať im, kde je bezpečnostný mechanizmus. So správnymi nástrojmi a správnym softvérom na dosah ruky, po dokončení kódovania si môžete skontrolovať svoj kód, môžete nájsť problémy profilovaním kódu, môžete nájsť efektívne nezamýšľané chyby, ktoré sú problémami s výkonom, a ako som povedal, skôr, raz za čas, ste to mohli urobiť pri pohľade na zelenú obrazovku. Už nemôžete; existujú stovky tisíc riadkov kódu, sú tu nasadené desiatky tisíc aplikácií, v niektorých prípadoch existujú milióny databáz a dokonca ani super ľudia to už nemôžu robiť ručne. Doslovne potrebujete správny softvér a správne nástroje na dosah ruky a potrebujete tím, aby tieto nástroje používal, aby ste tieto problémy mohli nájsť a veľmi rýchlo ich vyriešiť skôr, ako sa dostanete k veci, zatiaľ čo Dr. Robin Bloor zdôraznil, že to buď bude katastrofálne, a veci vyhodia do povetria alebo bežnejšie, jednoducho vás začnú stáť veľa dolárov a veľa času a úsilia a ničia morálku a veci, keď nedokážu zistiť, prečo sa veci berú dlhá doba na spustenie.
S týmto vedomím odovzdám nášmu hosťovi a teším sa, až budem počuť, ako vyriešili tento problém. A najmä demo si myslím, že sa chystáme dostať. Eric, pôjdem späť.
Eric Kavanagh: Dobre, Bert, vezmi to preč.
Bert Scalzo: OK, ďakujem. Bert Scalzo tu z IDERA, som produktový manažér pre naše databázové nástroje. A budem hovoriť o ladení. Myslím si, že jedna z najdôležitejších vecí, ktorú Robin povedal skôr - a je to veľmi pravda, je to, že ladenie je náročné a netriviálne, a keď idete na ladenie databázy, je to poradie veľkosti ešte ťažšie a netriviálne - takže to bol dôležitý citát.
OK. Chcel som začať s históriou programovania, pretože mnohokrát vidím ľudí, ktorí nie sú ladiaci, nepoužívajú ladiaci program, len programujú pomocou akéhokoľvek jazyka, ktorý používajú, a mnohokrát mi hovoria "No, tie debuggerove veci sú nové a my sme ich ešte nezačali používať." A tak to, čo robím, je, že im ukážem tento graf časovej osi, druh predhistorie, vek, stredný vek, je to druh kde sme boli z hľadiska programovacích jazykov. A my sme mali veľmi staré jazyky, ktoré sa začali v roku 1951 so zostavovacím kódom, a Lisp, FACT a COBOL. Potom sa dostaneme do ďalšej skupiny, Pascals a Cs a potom do ďalšej skupiny, C ++, a pozrieme sa, kde je ten otáznik - ten otáznik je približne v rokoch 1978 až 1980. Niekde v tomto rozsahu sme mali debuggery, ktoré máme k dispozícii, a tak poviem: „Hej, ja nepoužívam debugger, pretože to je jedna z tých nových vecí, “ potom musíte začať programovať, viete, v 50. rokoch 20. storočia, pretože to je jediný spôsob, ako by ste sa dostali k tomuto nároku.
Teraz je ďalšou vecou, ktorá je na tomto diagrame vtipná, Dez, práve urobil komentár k Grace Hopperovi, skutočne som Graceho poznal, takže je to trochu vtipné. A potom som sa zasmial tým, že hovoril o teletypoch a sedím tam a idem: „Človeče, to bol najväčší skok, aký sme kedy dosiahli v produktivite, keď sme prešli z kariet na teletypy, to bol najväčší skok v histórii. „Takže som tu naprogramoval všetky jazyky, vrátane SNOBOLu, o ktorom ešte nikto nepočul. Bolo to CDC, Control Data Corporation, takže myslím, že som pre toto odvetvie príliš starý.,
Dez Blanchfield: Chcel som povedať, že si nás tam strašne starol.
Bert Scalzo: Áno, hovorím vám, cítim sa ako starý otec Simpson. Pozerám sa teda na ladenie a existujú rôzne spôsoby ladenia. Dalo by sa hovoriť o tom, čo si všetci myslíme ako o tradičnom vstupe do debuggeru a prechode kódom. Ľudia však budú tiež používať svoj kód; to je miesto, kde nalepíte vyhlásenia do svojho kódu a možno vytvoríte výstupný súbor, sledovací súbor alebo niečo podobné, a tak svoj kód vybavíte. Počítal by som, že ako ladenie je to trochu ťažšie, spôsob, ako to urobiť, ale to sa počíta. Máme však aj slávne tlačové vyhlásenie: pozeráte sa a ľudia skutočne vkladajú tlačové vyhlásenia a vlastne som videl nástroj, kde - a je to databázový nástroj - kde, ak neviete, ako používať debugger, stlačíte tlačidlo a prilepí tlačové vyhlásenia v celom kóde a potom, keď budete hotoví, stlačíte ďalšie tlačidlo a odstráni ich. Pretože tak veľa ľudí ladí.
A dôvod, prečo ladíme, je dvojaký: v prvom rade musíme nájsť veci, vďaka ktorým je náš kód neúčinný. Inými slovami, zvyčajne to znamená, že existuje logická chyba alebo nám chýbala obchodná požiadavka, ale čo to je, kód nie je účinný; nerobí to, čo sme očakávali. Inokedy ideme a robíme ladenie, je to pre efektívnosť a to by mohla byť logická chyba, ale čo to je, je to, že som urobil správnu vec, jednoducho sa nevrátil dosť rýchlo. Teraz hovorím o tomto bode, pretože profiler je pravdepodobne lepší pre druhý scenár a budeme hovoriť o ladiacich aj profilovacích nástrojoch. Okrem toho existuje tento koncept vzdialeného ladenia; je to dôležité, pretože mnohokrát, ak sedíte vo svojom osobnom počítači a používate ladiaci program, ktorý zasiahne databázu, v ktorej je kód v databáze skutočne vykonaný, skutočne robíte to, čo sa nazýva vzdialené ladenie. Možno si to neuvedomujete, ale to sa deje. A potom je veľmi bežné, že tieto debuggery majú body prerušenia, sledovacie body, krok za krokom a niektoré ďalšie bežné veci, ktoré za chvíľu ukážem ľuďom na snímke obrazovky.
Teraz profilovanie: profilovanie môžete vykonať niekoľkými rôznymi spôsobmi. Niektorí ľudia budú hovoriť, že pracovné zaťaženie zachytáva a prehráva, kde zachytáva všetko, čo sa počíta ako profilovanie. Moja skúsenosť bola o to väčšia, že je lepšie, ak je to hotové. Nie je dôvod chytiť každé jedno vyhlásenie, pretože niektoré výkazy môžu bežať tak rýchlo, že vám je to jedno, čo sa naozaj snažíte vidieť, sú dobre, čo sú tie, ktoré sa neustále objavujú znova a znova, pretože beží príliš dlho. Takže niekedy môže profilovanie znamenať odber vzoriek skôr ako spustenie celej veci. A zvyčajne získate nejaký druh výstupu, ktorý môžete použiť, teraz, ktorý by mohol byť vizuálny vo vnútri vývojového prostredia IDE, kde vám môže poskytnúť ako histogram výkonnosti rôznych riadkov kódu, ale mohol by tiež je to, že vytvára sledovací súbor.
Profiléri sa prvýkrát objavili v roku 1979. Títo boli tiež už dlho. Skvelé na nájdenie spotreby zdrojov alebo problémov s výkonom, inými slovami, že vec efektívnosti. Všeobecne povedané, je to oddelené a odlišné od debuggeru, hoci som pracoval s debuggermi, ktoré robia obidva súčasne. A zatiaľ čo podľa mňa sú profilovatelia zaujímavejší z týchto dvoch nástrojov, ak mám pocit, že nie je dostatok ľudí na ladenie, potom rozhodne nie je dosť profilov ľudí, pretože sa zdá, že jeden z desiatich debuggerov bude profilovať. A to je škoda, pretože profilovanie môže skutočne urobiť obrovský rozdiel. Teraz, databázové jazyky, ako sme už hovorili, máte SQL - a my sme nejako nútili kruhový kolík do štvorcovej diery tu a prinútili ho, aby sa stal programovacím jazykom - a Oracle. To je PL / SQL - to je procedurálny jazyk SQL - a SQL Server, je to Transact-SQL, je to SQL-99, je to SQL / PSM - pretože, myslím, je to procedúra uložená v module. Postgres mu dáva iné meno, DB2 a ešte ďalšie meno, Informix, ale ide o to, že každý si vynútil konštrukty typu 3GL; inými slovami, FOR slučky, v deklaráciách premenných a všetky ostatné veci, ktoré sú cudzie SQL, sú teraz súčasťou SQL v týchto jazykoch. Preto musíte byť schopní ladiť PL / SQL alebo Transact-SQL rovnako ako program Visual Basic.
Teraz, databázové objekty, je to dôležité, pretože ľudia povedia: „Dobre, aké veci musím ladiť v databáze?“ A odpoveď znie, dobre, čokoľvek môžete uložiť do databázy ako kód - ak to robím T-SQL alebo PL / SQL - a ukladám objekty do databázy, pravdepodobne ide o uloženú procedúru alebo uloženú funkciu. Ale sú tu aj spúšťače: spúšť je niečo ako uložená procedúra, ale spúšťa sa pri nejakej udalosti. Teraz niektorí ľudia vo svojich spúšťačoch vložia jeden riadok kódu a zavolajú uloženú procedúru, aby si zachovali všetok uložený kód a procedúry, ale je to rovnaká koncepcia: stále to môže byť spúšť, ktorá iniciuje celú vec. A potom ako Oracle majú niečo, čo sa nazýva balík, ktorý je akosi ako knižnica. Do jedného zoskupenia, ktoré sa nazýva balík, umiestnite 50 alebo 100 uložených procedúr, takže je to niečo ako knižnica. Takže tu je debugger starý spôsob; Toto je vlastne nástroj, ktorý skutočne vstúpi a prilepí všetky tieto ladiace príkazy vo vašom kóde. Takže všade, kde vidíte blok ladenia, neodstraňujte, spustite a sledujte automatické ladenie, všetky boli zaseknuté nejakým nástrojom. A riadky mimo toho, čo je menšina kódu, nuž, je to metóda manuálneho ladenia.
A dôvod, prečo to uvádzam, je, že ak sa to snažíte ručne, v skutočnosti napíšete viac ladiaceho kódu, ktorý vložíte do všetkých týchto tlačových vyhlásení, ako ste s týmto kódom. Takže, aj keď to môže fungovať, a aj keď je to lepšie ako nič, je to veľmi zložitý spôsob ladenia, najmä od tej doby, čo, ak to trvá 10 hodín, kým sa táto vec spustí, a kde má problém, je v riadku tri? Keby som robil interaktívne ladenie relácie, vedel by som, že v riadku tri - päť minút do toho - hej, tu je problém, môžem skončiť. Ale s týmto, musím počkať, kým to beží, celú cestu k dokončeniu a potom sa musím pozrieť na nejaký stopový súbor, ktorý pravdepodobne obsahuje všetky tieto tlačené výroky, a skúsiť nájsť ihlu v kope sena. Opäť je to lepšie ako nič, ale nebol by to najlepší spôsob práce. Teraz by to vyzeralo, že tento súbor bude vyzerať ako ten, ktorý pochádza z predchádzajúcej snímky; Inými slovami, spustil som program a v tomto sledovacom súbore je práve kopa tlačených príkazov a ja alebo nemusím byť schopný sifónovať cez to a nájsť, čo potrebujem nájsť. Takže opäť si nie som istý, či by ste chceli pracovať týmto spôsobom.
Teraz, interaktívne debuggery - a ak ste na písanie programov použili niečo ako Visual Studio alebo Eclipse, mali ste debuggery a použili ste ich vo svojich ďalších jazykoch - jednoducho si nemyslel, že ich tu použijete vo svojej databáze. A existujú nástroje, ako je náš DB Artisan a Rapid SQL, toto je Rapid SQL tu, ktoré majú debugger, a vidíte na ľavej strane, mám uloženú procedúru s názvom „check for duplicates.“ V podstate ide len o to, aby som sa pozrel a zistil, či mám v tabuľke niekoľko riadkov s rovnakým názvom filmu. Databáza je teda určená pre filmy. A vy ste mohli vidieť na pravej strane, v hornej tretine, mám svoj zdrojový kód uprostred, mám to, čo sa nazýva moje sledovacie premenné a moje zásobníky zásobníkov, a potom v spodnej časti Mám nejaké výstupné správy. A čo je dôležité tu, ak sa pozriete na prvú červenú šípku, keď prejdem kurzorom na premennú, v skutočnosti vidím, aká hodnota je v tejto premennej v danom okamihu, keď prechádzam kódom. A to je naozaj užitočné, a potom môžem krok po jednom riadku cez kód, nemusím hovoriť spustiť, mohol by som povedať krok po riadku, dovoľte mi pozrieť sa, čo sa stalo, krok na inom riadku, dovoľte mi zistiť, čo sa stalo a robím to v databáze. Aj keď na svojom počítači sedím na Rapid SQL a moja databáza je v cloude, stále môžem robiť vzdialené ladenie a vidieť ho, ovládať odtiaľto a ladiť rovnako ako v akomkoľvek inom jazyku.
Teraz, nasledujúca šípka - vidíte trochu ako šípka smerujúca doprava, smerom k tomuto výstupu DBMS, to je miesto, kde sa momentálne nachádza môj kurzor - inými slovami som vstúpila a tam som na moment. Takže, ak poviem: „Znovu vstúpte“, pôjdem k tomu nasledujúcemu riadku. Teraz pod ňou uvidíte červenú bodku. No, to je bod prerušenia, ktorý hovorí: „Hej, nechcem prekračovať tieto riadky.“ Ak chcem len preskočiť všetko a dostať sa tam, kde tá červená bodka, môžem stlačiť tlačidlo spustenia a bude to bežať odtiaľ až do konca alebo do bodu prerušenia, ak sú stanovené nejaké body prerušenia, potom sa zastaví a dovoľte mi urobiť krok znova. A dôvod, prečo je toto všetko dôležité a silné, je, že keď robím všetko, čo sa deje v strede a dokonca aj v spodnej časti - ale čo je najdôležitejšie v strede - sa zmení a vidím hodnoty z mojich premenných, Vidím sledovanie zásobníka hovorov, viete, a preto sa všetky tieto informácie zobrazujú pri prechádzaní kódom, takže v skutočnosti vidím a cítim a chápem, čo sa deje a ako sa kód vlastne nachádza. práca v čase realizácie. A zvyčajne nájdem problém, ak nejaký existuje, alebo ak som dosť dobrý na to, aby som ho chytil.
Dobre, teraz budem hovoriť o profilovanom nástroji, a v tomto prípade je to profilový nástroj, ktorý vidím cez debugger. Pamätáte si, že som niekedy povedal, že sú oddelené a niekedy môžu byť spolu? V tomto prípade a znova som v rýchlom SQL a vidím, že na ľavej strane je vedľa čísel riadkov okraj. A čo to znamená, je to počet sekúnd alebo mikrosekúnd, ktoré potrebovali na vykonanie každého riadku kódu, a vidím to jasne, že všetok svoj čas trávim v tejto jednej slučke FOR, kde vyberiem všetko z tabuľky., A tak, čo sa deje vo vnútri tejto slučky FOR pravdepodobne je niečo, na čo sa musím pozrieť, a ak to dokážem zlepšiť, vyplatí dividendy. Nebudem mať žiadne vylepšenia tým, že budem pracovať na tých riadkoch, ktoré majú napríklad 0, 90 alebo 0, 86; nie je tam veľa času. Teraz, v tomto prípade a znova, som v Rapid SQL, vidíte, ako môžem robiť profilovanie zmiešané s mojím ladením. Teraz je pekné, že Rapid SQL vám to umožňuje robiť aj iným spôsobom. Rapid SQL vám umožňuje povedať: „Vieš čo? Nechcem byť v debuggere, chcem to len spustiť a potom sa chcem pozrieť na graficky alebo vizuálne rovnaké informácie. “
A vidíte, že už nie som v debuggere a beží program a po dokončení vykonávania programu mi dáva grafy, aby som im povedal veci, aby som videl, že mám jedno vyhlásenie, ktoré vyzerá, že začína väčšinu koláčového grafu a keď sa pozriem, vidím na tejto mriežke smerom dole, v riadku 23, opäť je tu slučka FOR: zaberá najviac času, je to v skutočnosti, že tmavo červená žuvanie všetkých koláčových grafov. Toto je ďalší spôsob, ako robiť profilovanie. V našom nástroji náhodou nazývame tento „analytik kódu“. Ale v podstate je to len profiler oddelený od debuggeru. Niektorí ľudia to radi robia prvým spôsobom, iní ľudia to radi robia druhým spôsobom.
Prečo robíme ladenie a profilovanie? Nie je to preto, že by sme chceli napísať najväčší kód na svete a získať zvýšenie mzdy - to by mohol byť náš dôvod, ale to nie je dôvod, prečo to robíte - sľúbili ste obchodu, že urobíte niečo správne, že váš program bude efektívny. To je to, čo budete používať debugger. Okrem toho koncoví podnikatelia; nie sú veľmi trpezliví: chcú výsledky ešte predtým, ako stlačia kláves. Mali by sme si prečítať ich myseľ a urobiť všetko okamžite. Inými slovami, musí to byť efektívne. A na to by sme profiler použili. Teraz, bez týchto nástrojov, naozaj verím, že ste tento chlapík v obleku s lukom a šípom a vy strieľate na cieľ a ste so zaviazanými očami. Pretože ako zistíte, ako sa program spúšťa len pri pohľade na statický kód a ako zistíte, ktorý riadok je miestom, kde by skutočne strávil najviac času na vykonanie, znova len pri pohľade na statický kód? Kontrola kódu môže alebo nemusí odhaliť niektoré z týchto vecí, ale neexistuje žiadna záruka, že by ich kontrola všetkých našla. Pomocou debuggeru a profilovača by ste mali byť schopní nájsť všetky tieto chyby.
Dobre, urobím tu skutočné rýchle demo. Nie je mojím zámerom tlačiť produkt, iba vám chcem ukázať, ako vyzerá ladiaci program, pretože ľudia mnohokrát povedia: „Nikdy som jeden z nich nevidel.“ A vyzerá to pekne na snímkach obrazovky., ale ako to vyzerá, keď je v pohybe? Takže tu na mojej obrazovke spustím produkt DB Artisan; máme tu tiež debugger. DB Artisan je určený skôr pre DBA, Rapid SQL je skôr pre vývojárov, ale videl som vývojárov, ktorí používajú DB Artisan, a videl som DBA, ktorí používajú Rapid. Nenechajte sa teda chytiť produktu. A tu mám na výber vykonanie ladenia, ale predtým, ako spustím ladenie, rozbalím tento kód, aby ste videli, ako vyzerá, skôr ako ho spustím. Toto je presne ten istý kód, aký bol na snímke obrazovky. Toto je moja kontrola duplikátov. A chcem to odladiť, takže stlačím ladenie. A teraz to chvíľu trvá a poviete: „Dobre, prečo to trvá chvíľu?“ Pamätajte si vzdialené ladenie: ladenie sa skutočne deje na mojom databázovom serveri, nie na mojom počítači. Takže tam muselo ísť a vytvoriť reláciu, vytvoriť vzdialenú ladiacu vec, pripojiť moju reláciu k tejto vzdialenej ladiacej relácii a nastaviť komunikačný kanál.
Takže, teraz je tu môj šíp, je tam hore, prvý riadok, to je miesto, kde som v kóde. A ak tam stlačím tretiu ikonu, čo je o krok ďalej, uvidíte, že sa šípka práve pohla, a ak ju stále stlačím, uvidíte, že sa neustále pohybuje. Ak by som teraz chcel ísť celú túto slučku FOR, pretože viem, že to je problém, môžem nastaviť bod prerušenia. Myslel som, že som to stanovil. Ach, strieľaj, mal som jeden z mojich klávesov na snímanie obrazovky mapovaných na ten istý kľúč ako debugger, čo spôsobuje zmätok. Dobre, tak som tam manuálne nastavil bod prerušenia, takže teraz namiesto toho, aby som urobil krok, krok, krok, krok, kým sa tam nedostanem, môžem skutočne povedať: „Choďte do toho a spustite túto vec“ a zastaví sa. Všimnite si, že ma to posunulo až na miesto prerušenia, takže teraz som v kontexte spustenia tejto slučky, vidím, na čo sú nastavené všetky moje premenné, čo nie je prekvapujúce, pretože som ich inicializoval všetky na nulu. A teraz môžem vstúpiť do tejto slučky a začať sa pozerať na to, čo sa deje vo vnútri tejto slučky.
Takže teraz si vyberiem počet nájomných a môžem nad tým chlapom prejsť myšou a pozerať sa, sú dvaja, dvaja väčší ako jeden, takže pravdepodobne urobí ďalší kus tohto kódu. Inými slovami, niečo našlo. Len sa do toho pustím a nechám to bežať. Nechcem tu prejsť všetko; čo ti chcem ukázať je, keď sa vykoná ladiaci program, skončí rovnako ako normálny program. Mám nastavený bod prerušenia, takže keď som povedal, že je spustený, jednoducho sa vrátil na ďalší bod prerušenia. Nechám ho bežať až do konca, pretože chcem, aby ste videli, že ladiaci program nemení správanie programu: keď je program hotový, mal by som získať rovnaké výsledky, ak by som ho spustil nie. vnútri debuggeru.
A s tým idem pozastaviť ukážku a vrátiť sa, pretože sa chceme uistiť, že máme čas na otázky a odpovede. A tak to otvorím pre otázky a odpovede.
Eric Kavanagh: Dobre, Robin, možno otázka od teba a potom pár od Deza?
Robin Bloor: Áno, určite to považujem za fascinujúce. Pracoval som s takýmito vecami, ale nikdy som s ničím podobným v databáze nepracoval. Môžete mi dať predstavu o tom, na čo ľudia používajú profiler? Pretože to vyzerá tak, že sa pozerajú - pretože predpokladám, že sú - pozerajú sa na problémy s výkonom, pomôže vám to rozlíšiť, kedy databáza trvá nejaký čas a kedy nejaký kód trvá nejaký čas?
Bert Scalzo: Vieš, to je fantastická otázka. Povedzme, že pracujem v jazyku Visual Basic a ja v rámci svojho jazyka Visual Basic volám Transact-SQL alebo PL / SQL. Dovoľte mi urobiť PL / SQL, pretože Oracle s nástrojmi spoločnosti Microsoft nehrá vždy dobre. Mohol by som profilovať svoj kód jazyka Visual Basic a profil tam môže hovoriť: „Hej, zavolal som túto uloženú procedúru a trvalo to príliš dlho.“ Ale potom môžem ísť do uloženej procedúry a môžem urobiť databázový profil na uloženej procedúre Postupujte a povedzte: „Dobre, zo 100 vyhlásení, ktoré sú tu, tu je päť, ktoré spôsobovali problém.“ A tak možno budete musieť urobiť tím značiek, v ktorom budete musieť použiť viac profilov.
Ide o to, že ak sa niekedy dozviete, že problém s výkonom je vo vašej databáze, databázový profil vám môže pomôcť nájsť ihlu v kupce sena, o ktorých tvrdeniach sa v skutočnosti jedná, kde máte problém. Hovorím vám ďalšiu vec, ktorá sa objavila s profilovaním: ak máte kúsok kódu, ktorý sa nazýva miliónkrát, ale každý miliónkrát to trvá len mikrosekundu, ale miliónkrát sa to nazýva, čo by profiler ukázal, tá vec bežala toľkých časových jednotiek. Aj keď môže byť kód vysoko efektívny, môžete vyzerať a povedať: „Ooh, tento hovor príliš často uskutočňujeme. Možno by sme to mali nazývať iba tak často, ako vždy, keď spracúvame záznam, “alebo tak niečo. A tak môžete skutočne nájsť, kde sa nachádza efektívny kód, ktorý sa volá príliš často a v skutočnosti ide o problém s výkonom.
Robin Bloor: Áno, to je úžasné. Nikdy som to neurobil. Vidíte, samozrejme, keď som mal problémy s databázou, bolo to, akoby som sa tak či onak zaoberal databázou alebo kódom; Nikdy by som sa s nimi nemohol vyrovnať naraz. Ale opäť som to neurobil - nikdy som sa vlastne nepodieľal na vytváraní aplikácií, kde sme ukladali procedúry, takže myslím, že som sa nikdy nestretol s problémami, ktoré ma používali, aby som bol divoký. Rozdelil by sa kód medzi databázu a program. Ale urobte všetko - predpokladám, že odpoveď bude áno, ale toto je súčasť aktivity vývojového tímu, keď sa nejakým spôsobom snažíte opraviť niečo, čo je rozbité, alebo sa možno pokúšate priniesť nový aplikácie spoločne. Je to všetko prispôsobené všetkým ostatným zložkám, ktoré by som v prostredí očakával? Môžem očakávať, že to dokážem pripnúť na všetky svoje testovacie balíčky a na všetky ostatné veci, ktoré by som robil, a na veci súvisiace s mojím projektovým riadením?
Bert Scalzo: Áno, môže sa stať súčasťou každého štruktúrovaného procesu, aby vykonal svoje programovacie alebo vývojové úsilie. A je to smiešne, minulý týždeň som mal zákazníka, ktorý zostavoval webovú aplikáciu, a ich databáza bola historicky malá, a preto skutočnosť, že neboli dobrí programátori, im nikdy neublížila. Ich databáza sa v priebehu rokov rozrástla a teraz na webovej stránke trvá 20 sekúnd, keď poviete: „Prihláste sa a dajte mi nejaké údaje, ktoré chcete vidieť“, a keď sa obrazovka skutočne objaví, a teraz je to teraz problém s výkonom. A vedeli, že problém nebol v žiadnej z ich Java ani na iných miestach. Mali však tisíce uložených procedúr, a preto museli začať profilovať uložené procedúry, aby zistili, prečo je potrebné, aby táto webová stránka vyšla 20 sekúnd? Skutočne sme zistili, že sa v jednom zo svojich vybraných výrokov pripojili karteziánski členovia a nevedeli sme to.
Robin Bloor: Páni.
Bert Scalzo: Ale niekto mi raz povedal: „Dobre, ako by sa mohli pripojiť karteziánske vzťahy a nevedieť to?“ A bude to znieť naozaj hrozne; niekedy programátor, ktorý nie je veľmi spokojný s SQL, urobí niečo, ako keď mi dá karteziánske pripojenie, ale potom mi vráti iba prvý záznam, takže viem, že niečo mám, a potrebujem iba prvý. A tak si neuvedomujú, že práve priniesli miliardu záznamov alebo prezreli milión záznamov, pretože dostali ten, o ktorý sa zaujímali.
Robin Bloor: Wow, viem, to sa volá - no, to je to, o čom Dez chodil, pokiaľ ide o ľudí, ktorí nie sú tak kvalifikovaní, ako by mali byť. Ak ste programátor, mali by ste vedieť, aké dôsledky má vydanie akéhokoľvek príkazu. Myslím tým skutočne nie je ospravedlnenie tejto úrovne hlúposti. Tiež predpokladám, že ste tak či onak v tejto súvislosti iba jazykovou agnostikou, pretože to všetko sa sústreďuje na databázovú stránku. Mám v tom pravdu? Je to rovnaké, bez ohľadu na to, čo používate na kódovaní?
Bert Scalzo: Určite to môžete urobiť vo Fortrane alebo v C alebo C ++. V skutočnosti, na niektorých Unixoch to môžete dokonca urobiť pre svoje skriptovacie jazyky; v skutočnosti poskytujú rovnaké nástroje. A potom sa chcem vrátiť na chvíľu späť za to, čo ste povedali, bez ospravedlnenia. Dám programátorom jednu prestávku, pretože nemám rád hádzanie programátorov pod autobus. Problém je však v skutočnosti v akademickom prostredí, pretože keď sa učíte, ako byť programátorom, učíte sa rekordne premýšľať. Neučíte sa množinové myslenie a to je to, čo Structured Query Language alebo SQL pracuje so sadami; Preto máme spojenie, križovatku a mínus operátora. A niekedy je veľmi ťažké pre človeka, ktorý nikdy nerozmýšľal, pokiaľ ide o súbory, prestať pracovať, prepúšťať rekordné spracovanie a pracovať so súbormi.
Robin Bloor: Áno, som na tom s vami. Myslím tým, že už chápem, že je to otázka vzdelávania; Myslím, že je to úplne vzdelávací problém, myslím si, že je prirodzené, že programátori premýšľajú procedurálne. A SQL nie je procedurálne, je deklaratívne. V skutočnosti iba hovoríte: „To je to, čo chcem, a je mi jedno, ako to robíte, “ viete? Zatiaľ čo s programovacími jazykmi ste si často navíjali rukávy a ste na okraji správnosti počítania, zatiaľ čo vy robíte slučku. Podám -
Bert Scalzo: Nie. OK, pokračujte.
Áno, chcel som povedať, že ste uviedli jeden ďalší príklad, že by profiler dobre chytil ten druh záznamu, ktorý pokračuje v tomto spracovaní záznamu v čase. Niekedy programátor, ktorý je dobrý v rekordnej logike, nemôže zistiť, ako vykonať program SQL. Povedzme, že robí dve slučky FOR a v podstate robí spojenie, ale robí to na strane klienta. Robí teda rovnaký efekt ako pripojenie, ale robí to sám a profil to zachytí, pretože by ste pravdepodobne nakoniec strávili viac času manuálnym spojením, než necháte to urobiť za vás databázový server.
Robin Bloor: Áno, to by bola katastrofa. Myslím, že by si sa len tak hádzal. Thrashing je vždy zlý.
Každopádne pôjdem do Dez; Určite má nejaké zaujímavé otázky.
Dez Blanchfield: Ďakujem, áno, áno. Idem sa k tebe pripojiť k programátorom, ktorí nehadzujú pod autobus. Myslím tým, že som strávil príliš veľa rokov tým, že som sám programátorom, na všetkých úrovniach, vieš, či už je to, ako si povedal, sedením na príkazovom riadku stroja Unix av niektorých prípadoch som sa dokonca zapojil v niekoľkých rôznych portoch Unixu z jednej hardvérovej platformy na druhú. A viete si predstaviť výzvy, ktoré sme tu mali. Realita je však taká, že karta na odchod z väzenia pre každého kódovača a skriptéra na svete. Je to raketová veda, doslova písať skutočne pevne zakaždým, keď je to raketová veda. A slávne príbehy ľudí, ako Dennis Ritchie a Brian Kernahan, pracujúci nezávisle na nejakom kóde a potom sa obrátia na chat s recenziou kódu nad kávou a zistia, že napísali presne ten istý kúsok kódu v presne rovnakom programe, presne rovnakým spôsobom. A urobili to v C. Ale táto puristická úroveň programovania existuje veľmi zriedka.
Faktom je, že na dennej báze je len 24 hodín denne, sedem dní v týždni, a my musíme len urobiť veci. A tak, pokiaľ ide o nielen tradičných programátorov, DBA a kódery a skripty, sysadmin a sieťových administrátorov a bezpečnostných pracovníkov, a všetko, čo sa v týchto dňoch až po údaje o občanovi týka; počujeme, každý sa len snaží robiť svoju prácu. A tak si myslím, že skvelým jedlom z tejto celej veci je to, že som miloval vaše demo a miloval som to s sebou, ktoré ste nám tu pred chvíľou nechali, keď som sa porozprával s Robinom o skutočnosti, že to má konkrétny - možno nie toľko výklenok - ale široký priestor, na ktorý sa vzťahuje, pokiaľ ide o opravu kódu a SQL a databáz. Ale bol som veľmi nadšený, keď som vás počul, že ste to mohli strčiť do skriptu a nájsť nejaké problémy, pretože viete, že v dnešnej dobe a veku sa vždy snažíme o čo najnižšiu cenu.
Dôvodom, prečo si niekde môžete kúpiť košeľu so 6 dolármi, je to, že niekto vybudoval systém dostatočne lacný na to, aby skutočne vyrábal a odosielal a logisticky dodával a predával a predával a maloobchodoval a prijímal platby online, aby získal košeľu 6 dolárov. A to sa nestane, ak máte ľuďom vyplatené 400 000 dolárov ročne, aby kód napísali dokonale; je to len celý vývoj. Takže v tomto bode si myslím, že jednou z otázok, ktoré by som vám skutočne páčil, aby ste nám poskytli viac podrobností, je to, aká je šírka a dosah typu ľudí, ktorých v súčasnosti vidíte a ktorí používajú tieto nástroje na profilovanie kód a hľadať problémy s výkonom? Pôvodne, historicky, odkiaľ pochádzajú? Boli to veľké inžinierske domy? A potom, v budúcnosti, mám pravdu, keď si myslím, že stále viac a viac spoločností implementuje tento nástroj alebo tieto nástroje, aby sa pokúsili pomôcť kodérom, ktorí vedia, ktorí práve robia veci, aby dokončili prácu. a dostať ich von zo dverí? A niekedy potrebujeme kartu s odchodom z väzenia? Mám pravdu v tom, že sme sa historicky viac zameriavali na vývoj a vývoj? To znamená, že teraz dostávame menej, ako povedal Robin, akademický prístup a teraz je to samouk, kód na vkladanie a vkladanie, alebo len veci stavajú? A to sa zhoduje s typom ľudí, ktorí teraz berú výrobok?
Bert Scalzo: Áno, presne. A dám vám veľmi konkrétny príklad, my len chceme prácu dokončiť, pretože podnikatelia nechcú dokonalosť. Je to niečo ako počítačová šachová hra: šachová hra nehľadá dokonalú odpoveď; hľadá odpoveď, ktorá je dosť dobrá v primeranom čase, takže takto naprogramujeme. Teraz však zistím, že väčšina ľudí namiesto toho, aby povedala, že chce v rámci testovania jednotky profilovateľa - takto by som to urobil, pretože to nevidím ako stratu času - čo sa deje teraz, keď sa to robí neskôr, niekedy počas testovania integrácie alebo stresového testovania, ak budeme mať šťastie. Ale vo väčšine prípadov je to súčasťou eskalácie, keď sa niečo stalo vo výrobe, chvíľu to bežalo, možno dokonca aj roky, a teraz to nefunguje dobre a teraz to budeme profilovať. A to sa zdá byť teraz bežnejším scenárom.
Dez Blanchfield: Áno, a myslím si, že termín „technický dlh“ je pravdepodobne taký, s ktorým ste viac ako oboznámení; Poznám Robina a určite som. Myslím si, že v súčasnosti, najmä v agilných prístupoch k rozvoju a budovaniu systému, je koncept technického dlhu veľmi skutočný a my to v projektoch skutočne zodpovedáme. Viem, myslím, máme vlastné projekty, ako sú Media Lens a ďalšie, kde sa každý deň deje kódovanie, a rôzne veci naprieč skupinou Bloor. A keď niečo budujeme, tak sa na to pozeráme, pozerám sa na to a vždy sa pozerám na to, čo ma bude stáť, aby som to napravil hneď teraz, v porovnaní s tým ho môžem len dostať do a dostať to tam vonku a potom sledovať a zistiť, či sa táto vec zlomí. A zdedím tento technický dlh, o ktorom viem, že sa budem musieť neskôr vrátiť späť a opraviť ho.
A myslím tým, že som to urobil za posledných sedem dní: napísal som niekoľko nástrojov a skriptov, napísal som pár kúskov jazyka Python a nasadil som ho na zadnú časť Monga, či je to pekné a čisté a bezpečné, ale dostane len dotaz, ktorý potrebujem, aby som vedel, že túto funkciu potrebujem, aby som sa dostal k väčšej hádanke; tam je moja skutočná bolesť. A tak vám vznikol tento technický dlh, a myslím si, že to teraz nie je len príležitostná vec, myslím si, že je to súčasť DNA, ktorá sa teraz vyvíja. Ľudia jednoducho - nie neúprimne - jednoducho akceptujú technický dlh, ktorý je normálnym modus operandi typu emisie, a jednoducho mu musia vzniknúť. To je miesto, kde vám vznikne technický dlh. A myslím si, že na tom, čo ste nám ukázali v ukážke, bolo skvelé, že ste mohli doslova profilovať a pozerať, ako dlho trvá beh. A to je pravdepodobne jedna z mojich obľúbených vecí. Myslím tým, že som vlastne postavil profilovacie nástroje - zvykli sme si vytvárať nástroje v Sed, Lex a Orc, aby sme spustili náš kód a zistili, kde boli slučky, predtým ako boli tieto nástroje k dispozícii - a kedy si postavil kód, ktorý chceš ísť a skontrolovať svoj vlastný kód, je veľmi dobré, že nemusíte kontrolovať svoj vlastný kód. Ale teraz tomu tak nie je. Existuje preto určitý trhový segment, ktorý to zaberá viac ako ktorýkoľvek iný? Vidieť ako omša -
Bert Scalzo: Och, áno, mám … urobím pre vás analógiu a ukážem vám, že to neprogramátori robia stále. Lebo ak niekedy učím debugger a profilovajúcu triedu alebo reláciu, spýtam sa ľudí: „OK, koľko ľudí tu chodí do programu Microsoft Word a zámerne nikdy nepoužívajú kontrolu pravopisu?“ A nikto nevzdvihne ruku, pretože pri písaní dokumentov všetci vieme, že dokážeme urobiť anglické chyby, a preto každý používa kontrolu pravopisu. A ja som povedal: „No, ako to, že keď píšete text v IDE, ako je Visual Basic, nepoužívate debugger? Je to to isté, je to ako kontrola pravopisu. “
Dez Blanchfield: Áno, v skutočnosti je to veľká analógia. Naozaj som o tom nepremýšľal, musím priznať, že s niekoľkými nástrojmi, ktoré používam, skutočne robím niečo podobné. V skutočnosti jeden, ODF, môj najobľúbenejší program Eclipse je len vystrihnúť a prilepiť kód a ísť hľadať veci, ktoré sa hneď zvýraznia a uvedomím si, že som pri nejakom triednom hovore urobil preklep. A s nástrojom, ako je tento, je teraz zaujímavé, že to môžete urobiť v reálnom čase, na rozdiel od návratu a pozerania sa naň neskôr, čo je pekné chytiť ho vopred. Ale áno, je to skvelá analógia iba pri vkladaní textu do textového procesora, pretože je to zaujímavý budiaci hovor, len si uvedomte, že ste urobili nejaké preklepy alebo dokonca gramatickú chybu, však?
Bert Scalzo: Presne tak.
Dez Blanchfield: Takže, vidíš, že teraz mám viac nepríjemný pocit, myslím, myslím, poslednú otázku odo mňa, predtým ako hodím na naše otázky a odpovede pre našich účastníkov. Ak by ste chceli dať nejaký druh odporúčaní v súvislosti s týmto prístupom - predpokladám, že je to rétorika - je to tak, že ste sa dostali čoskoro a implementovali ste to tak, ako sa vyvíjate, skôr ako sa budete vyvíjať? Alebo je to tak, že prevažne staviate, pohybujete sa, staviate niečo, čo potom príde a profilujete to neskôr? Mám podozrenie, že je to v prípade skorého vstupu a uistite sa, že je váš kód vopred pripravený. Alebo je to tak, že by mali zvažovať túto časť svojho post-nasadenia?
Bert Scalzo: V ideálnom prípade by to robili vopred, ale pretože všetci sú v rušnom svete zhonu, v ktorom práve robia veci, nemajú sklon to robiť, kým sa nestretnú s problémom výkonu, ktorý nedokážu vyriešiť pridanie ďalších CPU a pamäte na virtuálny stroj.
Dez Blanchfield: Áno. Takže ste vlastne spomenuli niečo zaujímavé, ak dokážem rýchlo? Už ste spomenuli, že sa dá spustiť odkiaľkoľvek a môžete hovoriť s databázou na zadnom konci. Toto je teda pohodlné s akýmsi bimodálnym poňatím, o ktorom hovoríme teraz, s cloudom v premise / mimo premise, podľa vzhľadu vecí, na konci dňa, ak môže hovoriť so zadným koncom a vidieť kód, to je jedno, naozaj?
Bert Scalzo: Presne tak, áno, môžete to spustiť v cloude.
Dez Blanchfield: Výborne, pretože si myslím, že to je miesto, kam smeruje náš nový statočný svet. Takže, Eric. Teraz sa k tebe vrátim a uvidím, že tu máme pár otázok a chcem, aby naši účastníci zostali s nami, aj keď sme prešli okolo hodiny.
Eric Kavanagh: Áno, je tam pár ľudí, len urobím rýchly komentár: Bert, myslím, že metafora, analógia, ktorú dávaš použitiu kontroly pravopisu, je úprimne brilantná. Je to hodné blogu alebo dvoch, úprimne povedané, pretože je to dobrý spôsob, ako načrtnúť kontext toho, čo robíte, aké cenné to je a ako by naozaj malo byť používanie osvedčeného postupu osvedčeným postupom. pravidelne, však? Stavím sa, že keď vyhodíte tú hlavu, prikývne vám hlava, nie?
Bert Scalzo: Absolútne, pretože im hovorím: „Prečo vykonávam kontrolu pravopisu svojich dokumentov? Nechcem byť zahanbený hlúpymi hláskovacími chybami. “No, nechcú byť zahanbení hlúpymi chybami kódovania!
Eric Kavanagh: Správne. Ano, naozaj. Ľudia, zhoreli sme tu hodinu a päť minút, takže vám všetkým ďakujeme za váš čas a pozornosť. Všetky tieto webové rozhovory archivujeme, neváhajte sa kedykoľvek vrátiť a skontrolovať ich. Najlepším miestom na nájdenie týchto odkazov je pravdepodobne techopedia.com, preto ho pridáme do tohto zoznamu tu.
A s tým sa ti rozlúčime, ľudia. Ešte raz, skvelá práca, Bert, vďaka našim priateľom z IDERA. Budeme s vami hovoriť nabudúce, v skutočnosti s vami budúci týždeň. Dávajte pozor! Zbohom.
