Odvzem: Gostitelj Eric Kavanagh je z dr. Robin Bloor, Dez Blanchfield in IDERA Bertom Scalzojem razpravljal o odpravljanju napak in profiliranju baze podatkov.
Trenutno niste prijavljeni. Če si želite ogledati video, se prijavite ali prijavite.
Eric Kavanagh: V redu, gospe in gospodje, v sredo je 4:00 po vzhodnem času, in to seveda pomeni.
Robin Bloor: Se slišim, Eric.
Eric Kavanagh: Pred dnevi sem bil tam, zato nisi sam. Toda tako da je tema danes res zanimiva. To je tisto, za kar želite zagotoviti, da se v vašem podjetju dogaja v ozadju, razen če to počnete, v tem primeru pa se želite prepričati, da to počnete pravilno. Ker so govorili o odpravljanju napak. Nihče ne mara hroščev, nihče ne mara, ko programska oprema preneha delovati - ljudje se razburjajo, uporabniki so neprijazni. To ni dobro. Torej, se bodo pogovarjali o "Hitrem odzivu: Odpravljanje napak v zbirki podatkov in profiliranje v reševanje."
Res je spot o tvojem resnično, zadeti me, @eric_kavanagh, seveda.
Letos je vroče. In odpravljanje napak bo postalo vroče, ne glede na vse. Res bo to ena od teh težav, ki nikoli ne mine, ne glede na to, kako dobri smo pri teh stvareh, vedno bodo težave, zato je ključno, kako priti do tega, da lahko te težave hitro rešite? V idealnem primeru imate odlične programerje, odlična okolja, kjer ne gre preveč narobe, a kot pravi stari rek, "Nesreče se zgodijo v najboljših družinah." In to velja tudi za organizacije. Torej, to se dogaja, zgodilo se bo, vprašanje je, kaj bo vaša rešitev za spopadanje z njimi in njihovo reševanje?
Dobro poslušajte doktorja Robina Bloorja, nato našega lastnega Deza Blanchfielda od spodaj pod, in seveda našega dobrega prijatelja Berta Scalza iz IDERA. In v resnici bom izročil ključe Robinu Bloorju, ga odnesi. Tla so tvoja.
Robin Bloor: V REDU. To je zanimiva tema. Mislil sem, da ker bo Dez verjetno nadaljeval z dejanskimi tehnikami in vojnimi zgodbami o odpravljanju napak, sem mislil, da bom samo opravil razpravo v ozadju, da bi dobili popolno zaokroženo sliko, kaj se dogaja. To sem delal dolgo časa in včasih sem bil koder, tako podobno, in s to predstavitvijo me je skoraj zamikalo, da bi začel delovati lirično o ideji o odprtokodni datoteki, vendar sem mislil, da bom to prepustil nekomu drugemu.
Tukaj je seznam znanih hroščev in večina teh se znajde na zgornjem seznamu anybodyys, v bistvu pa vsi, razen zadnjih dveh, stanejo vsaj 100 milijonov dolarjev. Prvi je bil Mars Climate Orbiter, izgubil se je v vesolju, in to zaradi težave s kodiranjem, kjer so ljudje zmešali metrične enote s (smeh) nogami in centimetri. Pri Ariane Five Flight 501 je prišlo do neusklajenosti med vloženim motorjem in računalniki, ki naj bi ob izstrelitvi poganjali raketo. Več računalniških okvar, eksplozija rakete, novice o naslovih. Sovjetski plinovod leta 1982, ki naj bi bil največja eksplozija v zgodovini planeta; Nisem prepričan, ali je. Rusi so ukradli nekaj programske opreme za samodejno krmiljenje, CIA pa je ugotovila, da bodo to storili in vanj postavila hrošče, Sovjeti pa so to izvajali brez testiranja. Torej, počil je cevovod navzgor, mislil je, da je to zabavno.
Črv Morris je bil šifrirni eksperiment, ki je nenadoma postal divji črv, ki je obšel vsakogar - očitno je povzročil škodo v vrednosti 100 milijonov dolarjev; to je ocena seveda. Intel je naredil znano napako z matematičnim čipom - navodilom za matematiko na čipu Pentium leta 1993 -, ki naj bi stal več kot 100 milijonov dolarjev. Program Apples Maps je verjetno najslabši in najbolj katastrofalen začetek karkoli, kar je Apple kdajkoli storil. Mislim, da so ljudje, ki so ga poskusili uporabljati, nekdo vozil po 101 in odkrili, da je Apple Map rekel, da so sredi zaliva San Francisco. Tako so ljudje začeli Apple App imenovati kot iLost. - naš najdaljši izpad v letu 1990 - njegov zanimiv z vidika stroškov kaj takega - AT&T so imeli približno devet ur in je med klicem na dolge razdalje stalo približno 60 milijonov dolarjev.
Bil sem pri ameriški zavarovalnici in zbirki podatkov, uvedli so novo različico baze podatkov in začela je brisati podatke. In tega se zelo dobro spominjam, ker sem bil pozneje pozvan, da se zaradi tega udeležim neke vrste izbire podatkovnih baz. Zelo zanimivo je bilo, da so vzeli novo različico baze podatkov in imeli baterijo testov, ki so jo naredili za nove različice baze podatkov, da je prestala vse teste. Našel je res nejasen način za brisanje podatkov.
Torej, vseeno, to je to. Mislil sem, da govorim o neusklajenosti impedance in izdanem SQL. Zanimivo je, da relacijske baze podatkov shranjujejo podatke v tabele in kodirnike, ki ponavadi manipulirajo s podatki v objektnih strukturah, ki resnično ne ustrezajo dobro tabelam. In zaradi tega dobite tisto, kar se imenuje neusklajenost impedance in nekdo se mora na tak ali drugačen način spoprijeti. Toda kaj se dejansko zgodi, ker en model, model kodrov in drug model baze podatkov niso posebej usklajeni. Dobite hrošče, ki se preprosto ne bi zgodili, če bi industrija gradila stvari, ki delujejo skupaj, kar se mi zdi zabavno. Torej, v bistvu na strani kodrov, ko dobite hierarhije, so lahko tipi, lahko nastanejo nabori, lahko je slaba zmožnost API-ja, lahko veliko stvari, ki stvari samo vržejo v smislu interakcije z bazo podatkov. Ampak stvar, ki je zame najbolj zanimiva, res zanimiva; vedno me je presenetilo, da ste imeli to SQL oviro, ki je tudi nekakšna impedanca na način, da koder in baza podatkov delujeta med seboj. Torej, SQL ima prepoznavanje podatkov, kar je v redu in ima DML za izbiranje, projektiranje in združevanje, kar je v redu. S tem lahko vržete veliko zmogljivosti v smislu pridobivanja podatkov iz baze podatkov. Ima pa zelo malo matematičnega jezika za početje. Ima malo tega in tega in ima zelo malo časovno utemeljenih stvari. Zaradi tega je SQL, če želite, nepopolno sredstvo za pridobivanje podatkov. Torej, fantje iz baze so zgradili shranjene postopke za življenje v bazi podatkov, razlog za shranjene postopke pa je bil v tem, da resnično ne želite metati podatkov naprej in nazaj v program.
Nekatera funkcionalnost je bila zelo specifična za podatke, zato ni bila zgolj referenčna celovitost in kaskadni brisi in podobno, baza podatkov je skrbela za nenadno vstavljanje funkcije v bazo podatkov, kar je seveda pomenilo, da je funkcionalnost za program lahko razdeli med kodir in bazo podatkov. In to je naredilo izvajanje nekaterih funkcij resnično težko in zato bolj nagnjeno k napakam. To je ena stran igre z bazo podatkov, ker pomeni, da ste dobili na primer veliko izvedb, da sem sodeloval v relacijskih bazah podatkov resnično veliko kode, ki je shranjena v shranjenih postopkih, ki se obravnava ločeno od kode, ki sedi v aplikacijah. In zdi se, da se je to moralo lotiti zelo nenavadno, saj naj bi delal različne stvari dokaj pametno.
Mislil sem, da Id govorim tudi o uspešnosti baze podatkov, ker napake v delovanju pogosto veljajo za napake, toda v bistvu imate lahko ozko grlo v CPU-ju, v pomnilniku, na disku, v omrežju in lahko imate težave z zmogljivostmi zaradi zaklepanja. Ideja bi bila, da koder resnično ne bi smel skrbeti za uspešnost in bi baza podatkov dejansko dobro delovala. Njegova naj bi bila zasnovana tako, da koder ni treba vedeti. Vendar pa dobite slabo zasnovo baz podatkov, dobite slabo zasnovo programa, dobite sočasnost pri mešanju delovne obremenitve, kar lahko vodi tudi do težav z uspešnostjo. Dobite uravnavanje obremenitve, načrtujete zmogljivosti, povečate podatke - kar lahko povzroči, da se baza podatkov samo ustavi ali upočasni. Zanimiva stvar, ko se baze podatkov skoraj napolnijo, se upočasnijo. In lahko imate težave s podatkovnimi plastmi v smislu podvajanja in potrebe po kopiranju ter potrebe po varnostnem kopiranju in obnovitvi. Kakorkoli že, to je splošen pregled.
Edino, kar bi rad povedal, je, da je odpravljanje napak v zbirki podatkov lahko le tako naporno in nepomembno - in to pravim, ker sem veliko storil - in pogosto boste odkrivali podobne situacije v odpravljanju napak, ki sem jih kdaj doživel je, je prva stvar, ki jo kdaj vidiš, nered. In poskusiti moraš iz nereda, da bi ugotovil, kako je nered nastajal. In pogosto, ko gledate na bazo podatkov, vse, kar gledate, so pokvarjeni podatki in razmišljate: "Kako za vraga se je to zgodilo?"
Kakor koli že, bom prenesel na Dez, ki bo verjetno povedal več besed modrosti, kot sem jih izšel. Ne vem, kako bi ti dal žogo, Dez.
Eric Kavanagh: Prestavim ga, bodi pripravljen, drži.
Samodejni glas: Vrstice udeležencev so izključene.
Eric Kavanagh: V redu, počakaj eno sekundo, naj dam Dez žogo.
Dez Blanchfield: Hvala, Eric. Da, dr. Robin Bloor, resnično ste najbolj pravi: to je tema, vseživljenjska napaka, če se oprostite punčke, oprosti, ker si nisem mogla pomagati pri tem. Upam, da boste tam videli moj prvi zaslon, na vrhu se opravičujem za težavo z velikostjo pisave. Tema hroščev je celodnevno predavanje, v mnogih primerih po mojih izkušnjah. To je tako široka in široka tema, zato se bom osredotočil na dve ključni področji, natančneje na koncept tega, za kar menimo, da je hrošč, ampak programsko vprašanje. Mislim, da te dni uvedba hrošča sama po sebi po navadi pobere integrirano razvojno okolje, čeprav so morda dolgoročne napake. Toda pogosto je to bolj primer profiliranja kode in možne pisanja kode, ki deluje, to bi moral biti hrošč. Torej, moj naslovni diapozitiv je bil tu, pravzaprav sem imel kopijo tega v zelo visoki ločljivosti A3, vendar se je na žalost uničil v hiši. Toda to je ročno napisana opomba na programskem listu iz leta 1945, kjer naj bi bili nekateri ljudje na univerzi Harvard v ZDA, njihova druga zgradba stroja, imenovana Mark II. Odpravljali so težavo v skupnem jeziku, vendar so poskušali najti napako in izkazalo se je, da se je zgodilo nekaj nekoliko drugačnega od tistega, kar je bila strojna oprema in domnevno programska težava.
Mestni mit je tisti okrog 9. septembrath, 1945 je ekipa na univerzi Harvard raztrgala stroj, naletela je na nekaj, kar so imenovali "štafeta sedemdeset" - v tistih dneh je bilo programiranje v fizičnem smislu, ovili ste kodo okoli deske in tako ste učinkovito programirali stroj - in našli so ta rele številka sedemdeset, je bilo z njim nekaj narobe, in izkazalo se je, da je dejanski izraz "hrošček" nastal, ker je dobesedno bil molj - domnevno je bil molj, vpet v kakšen kos bakrene žice iz enega kraja v drugega. In zgodba pravi, da legendarna Grace Hopper v tem naslovu za moj naslov diapozitiva "prvi dejanski primer odkritja hrošča" citira citat.
Toda kot je Robin že v svojem prvem diapozitivu poudaril, koncept hrošča sega toliko daleč nazaj, kot si lahko predstavljamo, da ljudje delajo računanje, koncepte kot obliž. Izraz "obliž" je nastal iz dejanskega kosa traku, ki je bil pritrjen čez luknjo na kartici. Bistvo tega je, da je izraz "odpravljanje napak" izhajal iz tega koncepta iskanja hrošča v fizičnem stroju.In od takrat smo uporabili to terminologijo pri poskusu reševanja vprašanj, bodisi ne toliko kot kodiranje problemov v programu, ki se ne sestavlja, ampak kot program, ki ne deluje dobro. Posebej pa se nismo profilirali, poiščite stvari, kot so neskončne zanke, ki ne gredo nikamor.
Vendar imamo tudi scenarij in mislil sem, da sem Id postavil nekaj smešnih diapozitivov, preden sem se podrobneje seznanil. Tu je klasična risanka, ki jo v spletu imenujejo XKCD, karikaturist pa ima nekaj precej smešnih pogledov na svet. In to o otroku, imenovanem "Mali Bobby Tables" in menda naj bi starši tega mladega poimenovali Robert); DROP TABLE Študenti; - in to se imenuje, in nekako: "Živjo, šola vaših sinov ima težave z računalnikom," in starš odgovori: "O, dragi, je kaj pokvaril?" In učitelj reče: "No, na nek način, "in učitelj vpraša," si res poimenoval svojega sina Roberta); DROP TABLE Študenti; -? "In starš reče:" O, da, mali Bobby Tables, mu pravimo. "Kakorkoli, nadaljujeta, da sta zdaj izgubila študentske evidence, upam da ste srečni. In odgovor je: "Pa bi morali očistiti in sanitirati vnose v zbirko podatkov." In to velikokrat uporabim za pogovor o nekaterih težavah, ki jih imamo pri iskanju stvari v kodi, in da pogosto koda ne pogleda tudi podatkov. .
Še en smešen, ne vem, ali je to resnično ali ne - sumim, da je to laž - ampak spet se dotakne moje smešne kosti. Nekdo zamenja registrske tablice na sprednjem delu svojega avtomobila, na podobno izjavo, ki povzroča padec baz podatkov na hitrostne kamere in tako naprej, ki zajemajo registrske tablice avtomobilov. In vedno se sklicujem na to, da dvomim, da je katerikoli programer pričakoval, da bo zadevno motorno vozilo zadel in izvedel svojo kodo, vendar tega nikoli ne podcenjuj - moč jeznega geka.
(Smeh)
Mislim, da me to vodi k mojemu bistvu in to je, da bi lahko nekoč odpravili napako in profilno kodo videli zgolj kot smrtniki. Ampak zelo sem mnenja, da je ta čas minil, in po mojih izkušnjah tudi prvi - in to me je grozno postaralo, prepričan sem; Robin ste dobrodošli, da se zaradi tega posmehujete - toda zgodovinsko prihajam iz ozadja, pri 14 letih se sprehajam po koncu mesta in trkam na vrata podatkovnega centra, imenovanega "Data Com" na Novi Zelandiji, in sprašujete, ali V šoli bi lahko zaslužil žepnino, če bi vsak dan prišel pozni avtobus, nekje 25 km vožnje s službo, dajal papir v kasete in trakove v tračne pogone ter bil samo splošni skrbnik. Zanimivo je, da so mi dali službo. A sčasoma sem se uspel spraviti v kadre in poiskati programerje ter spoznal, da imam rad kodiranje in šel skozi postopek izvajanja skriptov in paketnih opravil, kar na koncu dneva še vedno kodiramo. Napisati morate skripte in paketne naloge, ki so videti kot mini programi, nato pa skozi celoten postopek sedenja na roko za pisanje terminala 3270 ročno.
Pravzaprav je bila moja prva izkušnja na terminalu za teleletje, ki je bil dejansko fizičen v stolpcu s 132 stolpci. V bistvu si omislite kot zelo star pisalni stroj s papirjem, ki se je pomikal po njem, ker nimajo cevi za CRT. In odpravljanje napak pri tem je bilo zelo nepomembno, zato ste se navadno vso kodo napisali z roko in se nato obnašali kot tipkar, da bi se potrudili, da ne bi prišlo do napak, ker se je izredno moteče sporočiti. urejevalnik ene vrstice, da gremo do določene vrstice, nato pa vrstico in jo nato vtipkamo. Ampak nekoč smo tako pisali kodo in tako smo odpravili napako in dobili smo zelo, zelo dobro v tem. In pravzaprav nas je prisililo, da imamo zelo dobre tehnike programiranja, saj je bilo to resnično odpraviti. Toda pot je šla potem - in vsi so bili seznanjeni s tem - šla je od izkušnje terminala 3270 v mojem svetu, do digitalne opreme VT220, kjer ste lahko na zaslonu videli stvari, vendar spet ste počeli isto, kot ste na papirnem traku nekakšen format ed samo na CRT, vendar ste ga lažje izbrisali in niste imeli tistega zvoka "dit dit dit dit".
In potem veste, Wyse terminali - kot Wyse 150, verjetno moj najljubši vmesnik do računalnika že kdaj - in nato osebni računalnik in Mac, nato pa sodobni grafični vmesniki in ID-ji, ki temeljijo na spletu. In vrsto programov prek tega, programiranje v enem in sestavljavcu ter PILOT in Logo in Lisp ter Fortran in Pascal ter jeziki, zaradi katerih se ljudje lahko stiskajo. Toda to so jeziki, zaradi katerih ste morali napisati dobro kodo; ti niso dovolili, da se umakneš slabi praksi. C, C ++, Java, Ruby, Python - in ko stopimo dalje na to programsko stopnjo, dobimo več podobnega scenariju, bolj se približamo strukturiranemu poizvedbenemu jeziku in jezikom, kot je PHP, ki se dejansko uporabljajo za priklic SQL-a. Smisel, da vam povem, da sem iz svojega ozadja, sem bil samouk na več načinov in tisti, ki so mi pomagali pri učenju, me naučil zelo dobrih programerskih praks in zelo dobrih praks v zvezi z načrtovanjem in procesi, da se prepričam, da nisem predstavil hroščev Koda.
Načrtovanje programiranja v teh dneh, na primer strukturiran jezik poizvedb, SQL, je zelo močan, preprost jezik poizvedb. Vendar smo ga spremenili v programski jezik in resnično ne verjamem, da je bil SQL kdaj zasnovan kot sodoben programski jezik, vendar smo ga skovali, da bi to postal. In to uvaja cel kup vprašanj, ki nastanejo, ko razmišljamo z dveh vidikov: s kodirnega vidika in z vidika DBA. Zelo enostavno je priti zraven in uvesti napake za stvari, kot so le slabe tehnike programiranja, leni napori pri pisanju kode, pomanjkanje izkušenj, klasični ljubimci, ki jih piščam, na primer s SQL ljudmi, ki skačejo po Googlu in iščejo nekaj in najdejo to spletno mesto dobil primer in naredil kopijo in lepljenje obstoječe kode. In nato posnemajo slabo kodiranje, napačno ravnanje in dajanje v produkcijo, ker se le zgodi, da jim dajo želene rezultate. Imate druge izzive, na primer, v teh dneh so vsi hiteli k temu, čemur pravimo dirka do ničle: poskušati narediti vse tako poceni in tako hitro, da imamo scenarij, kjer ne bi zaposlovali nižje plačanega osebja. In tega ne mislim na nenavaden način, vendar niso zaposlili strokovnjakov za vsako možno delo. Nekoč je bilo z računalniki karkoli opraviti z raketno znanostjo; sodelovala je pri stvareh, ki so se razletele in bile zelo glasne, ali pa so šle v vesolje ali so bili inženirji visoko usposobljeni moški in ženske, ki so diplomirali in imeli strogo izobrazbo, zaradi česar niso mogli delati norega.
V teh dneh je veliko ljudi, ki se ukvarjajo z razvojem in oblikovanjem ter baze podatkov, ki niso imeli dolgoletnih izkušenj, niso imeli nujno enakega usposabljanja ali podpore. In tako zaključite s scenarijem samo tradicionalnega amaterja v primerjavi s strokovnjakom. In tu je znana vrstica, pravzaprav se ne spomnim, kdo je ustvaril citat, se glasi: "Če menite, da je drago drago najeti strokovnjaka za delo, počakajte, da najamete nekaj amaterjev, ki ustvarijo težavo, in morate očistite ga. "In zato ima SQL to težavo in je zelo, zelo enostaven za učenje, zelo enostaven za uporabo. Vendar po mojem mnenju ni popoln programski jezik. Zelo enostavno je narediti stvari, kot je na primer izbrana zvezda od koder koli, in vse to povlecite v programski jezik, ki vam je bolj všeč, kot sta PHP in Ruby ali Python, in uporabljate programski jezik, ki ste ga domače poznali, za manipulacijo s podatki, namesto da bi opravili bolj zapleteno poizvedbo v SQL. In to veliko vidimo, potem pa se ljudje sprašujemo, zakaj baza podatkov deluje počasi; to je zato, ker milijon ljudi poskuša kupiti vozovnico v spletnem sistemu vozovnic, kamor koli izberejo zvezdico od kjer koli.
To je resnično ekstremni primer, toda iz vsega tega se razumete. Torej, da resnično prebijem to točko domov, je primer, ki ga veliko nosim. Sem velik ljubitelj matematike, obožujem teorijo kaosa, obožujem komplete Mandelbrot. Na desni strani je predvajanje kompleta Mandelbrot, za katerega sem prepričan, da so ga vsi dobro poznali. Na levi strani je delček SQL-a, ki to dejansko ustvari. Zdaj, ko to nekje postavim na zaslon, slišim tole »O moj bog, nekdo je upodobil serijo Mandelbrot s SQL, ali resno? To je noro! "No, ves smisel tega je ponazoriti, kaj sem pravkar orisala tam, in to je da, pravzaprav lahko zdaj v SQL programirate skoraj vse; je zelo močno razvit, močan, sodoben programski jezik. Ko je bil prvotno jezik poizvedovalca, je bil zasnovan tako, da je le pridobil podatke. Torej, zdaj imamo zelo zapletene konstrukcije in imamo shranjene postopke, uporabljamo programsko metodologijo, ki se uporablja za jezik, zato je zelo enostavno zaradi slabe programske prakse, pomanjkanja izkušenj, kode za rezanje in lepljenje, nizko plačanega osebja, ki poskuša biti visoko plačano osebje, ljudje se pretvarjajo, da vedo, vendar se morajo na delovnem mestu učiti.
Cela vrsta stvari, pri katerih se profilira koda in kar imenujemo odpravljanje napak, ne gre toliko za iskanje hroščev, ki programi nehajo delovati, temveč napake, ki sistemsko škodujejo in slabo strukturirana koda. Ko zdaj pogledate na ta zaslon in pomislite, da je to čisto simpatično in si mislite: "Vau, kakšna krasna grafika, to rad vodim." Ampak predstavljajte si, da deluje na nekem poslovnem področju. Zdi se precej čeden, vendar govori matematično grafično upodobljeno teorijo kaosa, ko pa pomislite, za kaj bi se lahko uporabil v neki poslovni logiki, sliko zelo hitro dobite. In da to resnično ponazorim - in žal mi je, da so barve obrnjene, to naj bi bilo črno ozadje in zeleno, da je zelen zaslon, vendar to še vedno lahko preberete.
Šel sem in si na hitro ogledal primer, kaj lahko potencialno storite, če bi bili res nori in nimate izkušenj in ste prišli iz drugega ozadja programiranja in uporabili všečke C ++ na SQL, da resnično ponazorim svojo poanto, preden Izročim našemu izučenemu gostu iz IDERA. To je strukturirana poizvedba, napisana kot C ++, vendar je kodirana v SQL. In dejansko se izvrši, vendar se izvrši v približno treh do petih minutah. In navidezno potegne nazaj eno vrstico podatkov iz več baz podatkov, več združevanja.
Ponovno je poanta tega v tem, da če nimate ustreznih orodij, če nimate ustreznih platform in okolij, da bi lahko ujeli te stvari, in se ti lotijo proizvodnje, potem pa moraš vsak 100.000 ljudi udariti v sistem na dan ali uro ali minuto, zelo kmalu končate doživetje v Černobilu, kjer se veliko železo začne topiti in se zakopati v jedro planeta, ker ta del kode nikoli ne sme priti v proizvodnjo. Oprostite, vaši sistemi in vaša orodja bi morali to pobrati, še preden gre nekje v bližini - tudi skozi testni postopek, tudi prek UAT-a in sistemske integracije, je treba to kodo pobrati in poudariti in nekoga spraviti na stran in rekoč: "Poglejte, to je res lepa koda, ampak dovolite si, da dobite DBA, ki vam bo pomagal pravilno sestaviti strukturirano poizvedbo, ker odkrito povedano, to je samo grdo." In URL-ji tam lahko greste in si jih ogledujete - to se imenuje najbolj zapletena poizvedba SQL, kar ste jih kdaj napisali. Ker verjemite mi, da se dejansko sestavlja, vendar deluje. In če to izrežete in prilepite in samo posnamete zbirko podatkov, je nekaj kar je treba gledati; če imate orodja za ogled baze podatkov, poskusite in se stopite v obdobju od tri do pet minut, da pokličete nazaj, kaj je ena vrstica.
Če povzamem, glede na to me je moje celotno ozadje kodiranja naučilo, da lahko ljudem daste pištolo in če ne bodo pozorni, se bodo streljali v nogo; trik je, da jim pokažete, kje je varnostni mehanizem. S pravimi orodji in ustrezno programsko opremo na dosegu roke lahko po opravljenem kodiranju pregledate svojo kodo, težave najdete s profiliranjem kode, najdete dejansko nenamerne napake, ki so težave z uspešnostjo, in kot sem že povedal prej , nekoč, lahko to storite s pogledom na zeleni zaslon. Ne morete več; obstaja na stotine tisoč vrstic kode, na desetine tisoč aplikacij je nameščenih, v nekaterih primerih je na milijone baz podatkov in tudi super ljudje tega ne morejo storiti več ročno. Dobesedno potrebujete pravo programsko opremo in ustrezna orodja na dosegu roke in potrebujete, da ekipa uporablja ta orodja, tako da lahko te težave najdete in jih rešite zelo hitro, preden pridete do točke, medtem ko dr. Robin Bloor je poudaril, da stvari postanejo katastrofalne in se stvari raznesejo, ali pogosteje, ko te začnejo stati veliko dolarjev in veliko časa ter truda in uničujejo moralo in stvari, ko ne morejo ugotoviti, zakaj stvari trajajo dolgo teči.
In glede na to bom predal našemu gostu in z veseljem bom zaslišal, kako so rešili to vprašanje. In še posebej demo, za katerega mislim, da ga bom kmalu prejel. Eric, bom šel nazaj čez.
Eric Kavanagh: V redu, Bert, vzemi ga.
Bert Scalzo: OK, hvala. Bert Scalzo tukaj iz IDERA, Im upravitelja izdelkov za naša orodja za baze podatkov. In govoril bom o odpravljanju napak. Menim, da je ena najpomembnejših stvari, ki jo je prej povedal Robin - in resnično je, da je odpravljanje napak naporno in nepomembno, in ko greš v bazo podatkov, odpravljanje napak v njegovem vrstnem redu še bolj zapleteno in nepomembno - tako da je bil pomemben citat.
V REDU. Želel sem začeti s zgodovino programiranja, saj velikokrat vidim ljudi, ki ne odpravljajo napak, ne uporabljajo odpravljalnika napak, ampak samo programirajo s katerim koli jezikom uporabljajo in velikokrat mi rečejo: "No, te razhroščevalne stvari so nove in jih še nismo začeli uporabljati. "In zato, kar počnem, jim pokažem ta časovni načrt, nekakšno predzgodovino, starost, srednji vek, svojevrstno povem, kje smo bili pogoji programskih jezikov. In že leta 1951 smo imeli zelo stare jezike s kodo za sestavljanje ter Lisp in FACT ter COBOL. Nato preidemo v naslednjo skupino, Pascals in Cs, nato pa naslednjo skupino, C ++ s, in poglejmo, kje je ta vprašalna znamka - ta vprašalna znamka je približno med letoma 1978 in morda 1980. Nekje v tem razponu smo imeli razhroščevalci, ki so nam na voljo, in tako rekoč: "Hej, ne uporabljam odpravljalnika, to je ena od teh novih stvari", potem ste morali začeti programirati, saj veste, v 50. letih prejšnjega stoletja, to je edini način, ki ga dobite stran s to trditvijo.
Zdaj je nekaj drugega, kar je smešno pri tej lestvici, Dez je pravkar komentiral Grace Hopper, Grace sem pravzaprav poznal, tako da je zelo smešna. In potem sem se drugemu, kar sem se smejal, govoril o teletipih in jaz sem sedel tam, ko sem govoril: "Človek, to je bil največji skok produktivnosti, ko smo šli od kart do teletipov, to je bil največji skok doslej." in sem programiral v vseh jezikih, vključno s SNOBOL-om, za katerega še nihče ni slišal, bil je to CDC, Control Data Corporation, zato mislim, da sem postajal nekoliko prestar za to industrijo.
Dez Blanchfield: Hotela sem reči, starali ste nas strašno tam.
Bert Scalzo: Ja, pravim vam, počutim se kot dedek Simpson. Zato pogledam na odpravljanje napak in obstaja različne načine za odpravljanje napak. Lahko bi govorili o tem, za kar vsi mislimo, da je tradicionalno vstavljanje napak in odkrivanje kode. Ampak tudi ljudje bodo inštrumentirali svojo kodo; to je, če v kodo vstavite izjave in morda ustvarite izhodno datoteko, datoteko sledenja ali kaj podobnega, in tako povežete kodo. To bi štel kot razhroščevanje, nekoliko težje, način tega, vendar šteje. Pa tudi, dobili smo znamenito izjavo: opazujete in ljudje dejansko dajejo izjave in Ive je dejansko videl orodje, kamor - in njegovo orodje za bazo podatkov - kjer, če ne veste, kako uporabljati razhroščevalnik, pritisnete gumb in lepilo se bo izjave v celotni kodi za vas, nato pa, ko končate, pritisnete še en gumb in ta jih odstrani. Ker tako odpravi veliko ljudi.
Razlog za odpravljanje napak je dvojen: najprej moramo najti stvari, zaradi katerih naša koda ni učinkovita. Z drugimi besedami, običajno to pomeni logična napaka ali smo zamudili poslovno zahtevo, toda kaj je, če koda ni učinkovita; ne naredi tistega, kar smo pričakovali. Ko drugič odpravimo napak, je to učinkovitost in to bi lahko bila logična napaka, ampak kaj je, če sem naredil pravilno, se preprosto ne vrne dovolj hitro. Zdaj to poudarjam, ker so profilniki verjetno boljši za drugi scenarij in bodo govorili tako o odpravljalcih kot o profilih. Poleg tega obstaja ta koncept oddaljenega odpravljanja napak; To je pomembno, ker velikokrat, če sedite za osebnim računalnikom in uporabljate odpravljalnik, ki zadene bazo podatkov, kjer je koda dejansko izvedena v bazi, dejansko delate tisto, kar se imenuje oddaljeno odpravljanje napak. Morda se tega ne zavedaš, ampak to se dogaja. In potem je pri teh razhroščevalcih zelo pogosto, da imajo prelomne točke, točke gledanja, korak in korak čez in še nekaj skupnih stvari, ki jih bom v trenutku pokazal na posnetku zaslona.
Zdaj profiliranje: profiliranje lahko izvedete na več različnih načinov. Nekateri bodo rekli, da se zajemanje in ponovna obremenitev, kjer zajame vse, šteje za profiliranje. Moje izkušnje so bile boljše, če je bilo opravljeno vzorčenje. Zato ni nobenega razloga, da bi ujeli vsako posamezno izjavo, ker lahko nekatere izjave tečejo tako hitro, da vam ni vseeno, kaj resnično poskušate videti, je tisto, ki se vedno znova pojavlja, ker se predolgo prikazujejo . Torej včasih profiliranje lahko pomeni vzorčenje in ne vodenje celotne stvari. Običajno boste dobili nekakšen izhod, ki ga lahko uporabite, zdaj, ko bi bil lahko viden znotraj razvojnega okolja IDE, kjer vam bo morda dal histogram uspešnosti različnih vrstic kode, vendar bi lahko še vedno naj bo to, da ustvari datoteko v sledovih.
Profilci so se prvič pojavili leta 1979. Torej, tudi teh je bilo že dlje časa. Odličen za iskanje porabe virov ali težav z uspešnostjo, z drugimi besedami, da je učinkovitost. Na splošno je ločen in ločen od napak, čeprav sem delal z napakami, ki delajo oboje hkrati. In medtem ko se mi zdijo profili zanimivi od obeh orodij, če menim, da premalo ljudi odpravlja napako, potem zagotovo premalo ljudi profilira, ker se zdi, da se bo od desetih napak odrezal profil. In to je škoda, ker lahko profiliranje resnično močno spremeni. Zdaj so jeziki zbirk podatkov, kot smo že govorili, dobili SQL - in tu smo nekako prisilili okrogel zatič v kvadratno luknjo in ga prisilili, da postane programski jezik - in Oracle.To je PL / SQL - tisti proceduralni jezik SQL - in SQL Server, njegov Transact-SQL, SQL-99, SQL / PSM - za, mislim, njegov shranjeni modul. Postgres mu daje drugo ime, DB2 še eno ime, Informix, toda poanta je, da so vsi prisilili konstrukte tipa 3GL; z drugimi besedami, zanke FOR, pri deklaracijah spremenljivk in vse druge stvari, ki so tujemu SQL, so zdaj del SQL-a v teh jezikih. In tako morate PL-SQL ali Transact-SQL odpraviti napako tako, kot bi to želeli program Visual Basic.
Zdaj, predmeti v bazi podatkov, je to pomembno, ker bodo ljudje rekli: "No, katere stvari moram odpraviti v program za odpravljanje napak v bazi?" In odgovor je, no, vse, kar lahko shranite v bazo kot kodo - če počnem T- SQL ali PL / SQL - in Im shranjuje predmete v bazo podatkov, njihov verjetno shranjeni postopek ali shranjeno funkcijo. Vendar pa se sproži tudi: sprožilec je nekako kot shranjena procedura, vendar se sproži na kakšnem dogodku. Zdaj bodo nekateri v svojih sprožilcih postavili eno vrstico kode in poklicali shranjeni postopek, tako da ohranijo vso svojo shranjeno kodo in postopke, vendar je isti koncept: njen sprožilec bi lahko bil tisto, kar sproži celotno stvar. In potem kot Oracle imajo nekaj, kar imenujejo paket, ki je nekako podoben knjižnici, če hočete. 50 ali 100 shranjenih postopkov vstavite v eno skupino, ki se imenuje paket, tako da je podobna knjižnici. Torej, tako je razhroščevalnik stari način; to je pravzaprav orodje, ki bo dejansko vstopilo in vse te izjave o odpravljanju napak v svoje kodo. Torej povsod, kjer vidite blok za odpravljanje napak, ne odstranjujte, samodejni odstranjevalec napak se začne in sledi, vse to je vse zataknilo orodje. In vrstice zunaj tega, kar je manjšina kode, dobro, to je ne-ročna metoda za odpravljanje napak.
Razlog, da to izpišem, je, da če to poskušate storiti z roko, boste dejansko vnesli več kod za odpravljanje napak, ki jih boste vnesli v vse te izjave, kot jih imate s kodo. Čeprav je to mogoče, in čeprav je boljše od ničesar, je to zelo težaven način za odpravljanje napak, še posebej, kaj pa, če traja 10 ur, da se ta zadeva zažene, in če ima težavo, je v tretji vrstici? Če bi delal sejo za odpravljanje napak, bi v vrstici tri - pet minut vanj vedel - hej, tu je težava, lahko neham. Toda s tem moram počakati, da se zažene, vse do dokončanja, nato pa moram pogledati datoteko v sledovih, ki ima verjetno vse te izjave, in poskusiti najti iglo v senu. Spet je to boljše kot nič, vendar to ne bi bil najboljši način za delo. Zdaj je videti ta datoteka, ki je nastala s predhodnega diapozitiva; z drugimi besedami, vodil sem program in njegov pravkar je dobil kup izjav v tej datoteki sledenja in morda ne bom mogel prebrskati tega in najti tisto, kar moram najti. Torej, spet nisem tako prepričan, da bi tako želeli delati.
Zdaj, interaktivni razhroščevalci - in če ste za pisanje programov ali Eclipse uporabljali nekaj takega, kot je Visual Studio, ste imeli razhroščevalce in ste jih uporabljali z drugimi jeziki - preprosto niste razmišljali, da bi jih tukaj uporabljali s svojo bazo podatkov. In tam so orodja, kot sta naš DB Artisan in naš Rapid SQL, tukaj je Rapid SQL, ki ima razhroščevalnik, in vidite na levi strani, imam shranjeno proceduro, imenovano "preverite dvojnike." V bistvu gre samo, da pogledam in vidim, ali imam v tabeli več vrstic z istim naslovom filma. Torej, baza podatkov je za filme. In lahko vidite na desni strani, na zgornji tretjini, Ive sem dobil svojo izvorno kodo na sredini, Ive je dobil, kar se imenuje moje spremenljivke ure in moji pladnji za skladanje klicev, nato pa sem na dnu Ive dobil nekaj izhodnih s. In kar je tukaj pomembno je, da če pogledaš čez tisto prvo rdečo puščico, če z miško pomaknem nad spremenljivko, dejansko vidim, kakšna je vrednost v tej spremenljivki v tistem trenutku, ko Im koraka skozi kodo. In to je res koristno, nato pa lahko prek kode stopam po eno vrstico, ne moram reči, da se izvaja, lahko bi rekel korak vrstica, da pogledam, kaj se je zgodilo, korak drugo vrstico, da vidim, kaj se je zgodilo, in To počnem v bazi podatkov. In čeprav v računalniku sedim na Rapid SQL in je moja baza podatkov v oblaku, še vedno lahko naredim to oddaljeno odpravljanje napak in jo vidim in nadziram od tu ter odpravljam napake tako, kot bi to storil s katerim koli drugim jezikom.
Zdaj pa naslednja puščica tam - vidite malo podobno puščico, ki kaže na desno, proti izhodu DBMS, tam je trenutno moj kazalec - torej z drugimi besedami, stopil sem Ive in to sem tam trenutno. Torej, če rečem, "korak znova", grem do naslednje vrstice. Zdaj tik pod to boš videl rdečo piko. No, to je prelomna točka, ki pravi: "Hej, nočem stopiti čez te vrstice." Če samo hočem preskočiti vse in priti tja, kjer je ta rdeča pika, lahko pritisnem na gumb za tek in odtečem od tu bodisi do do konca ali do točke preloma, če so določene točke preloma, nato pa se bo ustavilo in naj še enkrat naredim korak. In razlog, da je vse to pomembno, je močan, ker se bo dogajanje na sredini in celo na dnu - a kar je najpomembneje na sredini - spremenilo, in ko sem videl vrednosti svojih spremenljivk, se lahko glej sled mojega števila klicev, veš, in tako so vse te informacije tam prikazane kot Im, ki koraka skozi kodo, tako da dejansko vidim in čutim ter razumem, kaj se dogaja in kako koda dejansko deluje v času izvedbe . Običajno lahko najdem težavo, če obstaja, ali če sem dovolj dober, da jo rešim.
V redu, zdaj bom govoril o profilerju in v tem primeru je to profil, ki ga vidim skozi odpravljalnik. Se spomniš, da sem rekel, da sta včasih ločena in včasih sta lahko skupaj? V tem primeru in znova sem Im v Rapid SQL in na levi strani poleg številk vrstic lahko vidim rob. In to je tisto število sekund ali mikrosekund, potrebnih za izvedbo vsake vrstice kode, in to jasno vidim, ves svoj čas preživim v tej zanki ZA, kjer izbiram vse iz tabele. In zato moram videti nekaj, kar se verjetno dogaja znotraj te zanke FOR, in če bom lahko izboljšal, bo izplačal dividende. Ne bom izboljšal z delom na tistih linijah, ki imajo 0,90 ali 0,86; tam ni veliko časa preživetega. V tem primeru in spet, Im v Rapid SQL, vidite, kako lahko naredim profiliranje, premešano z mojo odpravljanje napak. Kar je lepo, je, da Rapid SQL omogoča tudi drugo pot. Rapid SQL vam omogoča, da rečete: »Veste kaj? Nočem biti v razhroščevalcu, želim to samo zagnati in nato grafično ali vizualno pogledam iste vrste informacij. "
In vidite, da Im ni več v razhroščevalniku in zažene program, in ko je izvedba končana, mi da lestvice, da mi pove stvari, tako da lahko vidim, da sem dobil eno izjavo, ki je videti, kot da zavzema večino pita grafikona in če pogledam, vidim na tej mreži proti dnu, vrstica 23, spet zanka ZA: hec jemlje največ časa, on je v resnici temno rdeč, ki žveči vso skorjo. In tako, to je še en način za profiliranje. V našem orodju smo poimenovali tega „analitika kode“. Toda v bistvu je le profilnik ločen od napak. Nekateri radi to počnejo na prvi način, nekateri radi to počnejo na drugi način.
Zakaj naredimo odpravljanje napak in profiliranje? Ne zato, ker želimo napisati največjo kodo na svetu in prejeti zvišanje plače - to je morda naš razlog, ampak to res ni razlog, da to storite - obljubili ste podjetju, da boste naredili nekaj pravilno, da bo vaš program učinkovit. Za to boste uporabili razhroščevalnik. Poleg tega poslovni končni uporabniki; niso zelo potrpežljivi: želijo rezultate, še preden pritisnejo tipko. Morali bi brati njihove misli in vse narediti takoj. Z drugimi besedami, mora biti učinkovit. In tako bi uporabili profiler. Zdaj brez teh orodij resnično verjamem, da ste ta moški v poslovni obleki z lokom in puščico in streljate na tarčo in imate zavežene oči. Kajti kako boste ugotovili, kako se program izvaja tako, da samo pogledate statično kodo in kako boste ugotovili, katera vrstica je, kje bi resnično porabili največ časa pri izvedbi, spet samo s pogledom na statično kodo? V pregledu kode se nekatere od teh stvari lahko pojavijo ali ne, vendar ni nobenega zagotovila, da jih bo pregled kode našel vse. Z napravo za odpravljanje napak in profilerjem bi morali najti vse te napake.
V redu, tukaj bom pravkar naredil hitro predstavitev. Ni mi namen, da bi potisnil izdelek, želim vam samo pokazati, kako izgleda odpravljanje napak, saj velikokrat ljudje rečejo: "Nikoli še nisem videl nobenega od teh." In videti je precej na zaslonskih diapozitivih, ampak kaj ali je videti, ko je v gibanju? Torej, tukaj na mojem zaslonu vodim naš izdelek DB Artisan; tudi tam imamo razhroščevalnik. DB Artisan je namenjen bolj DBA, Rapid SQL je bolj za razvijalce, vendar sem videl razvijalce, ki uporabljajo DB Artisan, in sem videl DBA, ki uporabljajo Rapid. Torej, ne ujemi se na izdelek. In tu imam možnost izvesti odpravljanje napak, vendar preden odprem napako, bom izvlekel to kodo, da boste lahko videli, kako izgleda koda, preden jo začnem izvajati. Torej, tukaj je popolnoma enaka koda, ki je bila na posnetku zaslona, to je moje preverjanje dvojnikov. In to želim odpraviti, zato pritiskam na odpravljanje napak. In zdaj traja trenutek in si rečete: "No, zakaj traja trenutek?" Ne pozabite na oddaljeno odpravljanje napak: odpravljanje napak se dejansko dogaja na mojem strežniku baz podatkov, ne na mojem računalniku. Torej je bilo treba iti čez in ustvariti sejo tam, ustvariti oddaljeno napravo za odpravljanje napak, priklopiti sejo na tisto sejo oddaljenega odpravljanja napak in vzpostaviti komunikacijski kanal.
Torej, zdaj je moja puščica, tam zgoraj na vrhu, ena vrstica, tam sem v kodi. In če tam pritisnem tretjo ikono, ki je korak v, boste videli, da se je puščica pravkar premaknila, in če jo še naprej pritisnem, boste videli, da se še naprej premika. Zdaj, če bi hotel iti vse do te zanke ZA, ker vem, da je tu problem, lahko postavim prelomno točko. Mislil sem, da sem to določil. Oh, streljaj, imel sem enega od tipk za zajem zaslona preslikan na isti tipki kot za odpravljanje napak, tisto, kar povzroča zmedo. V redu, tako da sem tam ročno nastavil prelomno točko, tako da zdaj namesto da naredim korak, korak, korak, korak, dokler ne pridem tja, pravzaprav lahko rečem samo: "Pojdi in zaženi to stvar", in ustavilo se bo. Opazite, da me je premaknilo vse do točke preloma, zato sem zdaj v zagonu te zanke in lahko vidim, na kaj so nastavljene vse moje spremenljivke, kar ni presenečenje, ker sem jih vse inicializiral nič. In zdaj lahko stopim v to zanko in začnem gledati, kaj se dogaja znotraj te zanke.
Torej, zdaj bo izbrano štetje mojih izposoj in lahko se pomaknem preko tega fanta in pogledam, dva, dva sta večja od enega, tako da bo verjetno naredil naslednji del te kode. Z drugimi besedami, nekaj je našlo. Samo grem naprej in pustim, da teče. Nočem iti skozi vse tukaj; to, kar vam želim pokazati, je, ko se napravi odpravljanje napak, se konča tako kot običajni program. Določil sem mejno točko, ko sem rekel teči, se je vrnil na naslednjo prelomno točko. Če ga pustim, da teče do konca, zato, kar želim, da vidite, je to, da odpravljalec napak ne spreminja vedenja programa: ko bi se ta končal, bi moral dobiti popolnoma enake rezultate, če bi ga izvajal ne znotraj razhroščevalca.
In s tem bom prekinil predstavitev in se vrnil, ker želimo zagotoviti čas za vprašanja in odgovore. In tako ga bom odprl za vprašanja in odgovore.
Eric Kavanagh: V redu, Robin, morda vprašanje od tebe in potem par iz Deza?
Robin Bloor: Ja, seveda se mi zdi to fascinantno, seveda. Delal sem s takšnimi stvarmi, vendar v bazi podatkov nisem nikoli delal česa takega. Mi lahko daste kakšno predstavo, za kaj ljudje uporabljajo profiler? Ker je to podobno, ali gledajo - ker domnevam, da so - da gledajo na težave glede zmogljivosti, ali vam bo pomagalo razlikovati med tem, kdaj baza podatkov vzame čas in kdaj vam koda vzame čas?
Bert Scalzo: Veste, to je fantastično vprašanje. Recimo, da delam v Visual Basic, in znotraj svojega Visual Basic bom poklical Transact-SQL ali PL / SQL. Dovolite mi, da naredim PL / SQL, saj se Oracle vedno ne igra dobro z Microsoftovimi orodji. Mogoče bi lahko profiliral svojo kodo Visual Basic in tamkajšnji profil bi lahko rekel: "Hej, poklical sem ta shranjeni postopek in je trajalo predolgo." Potem pa lahko grem v shranjeni postopek in lahko naredim profil baze podatkov na shranjeni postopek in reči: "V redu, od 100 izjav, ki so tukaj, je pet, ki so povzročile težavo." In tako boste morda morali narediti skupino za oznake, kjer morate uporabiti več profilov.
Ideja je, da če boste kadar koli seznanjeni s težavo z zmogljivostjo v svoji bazi podatkov, vam lahko profil baze podatkov pomaga najti iglo v senu, na kateri so izjave dejansko tiste, kjer imate težavo. Povem vam še eno stvar, ki se je izkazala s profiliranjem: če imate kodo, ki jo kličete milijonkrat, vendar je potrebna samo mikrosekunda vsak milijonkrat, vendar se jo imenuje milijonkrat, kaj bi pokazal profiler , ta stvar je tekla v tem času. In čeprav je koda morda zelo učinkovita, boste morda pogledali in rekli: „Ooh, prepogosto sem klicala ta klic na ta del kode. Mogoče bi ga morali poklicati le tako pogosto, ne pa vsakič, ko obdelujemo zapis, "ali kaj podobnega. In tako lahko dejansko najdete, kje obstaja učinkovita koda, ki jo preprosto kličete prepogosto, in to je dejansko težava z zmogljivostjo.
Robin Bloor: Ja, to je čudovito. Nikoli nisem storil tega. Seveda, ko sem imel težave z bazo podatkov, je bilo tako, kot da bi se tako ali drugače ukvarjal z bazo podatkov ali se ukvarjal s kodo; Nikoli se ne bi mogel ukvarjati z obema hkrati. Toda tam spet nisem storila - nikoli nisem bila vpletena v gradnjo aplikacij, kjer smo imeli shranjene postopke, zato mislim, da v resnici nikoli nisem naletel na težave, ki so me dolgočasile, ideja, da bi kodo razdelil na zbirka podatkov in program. Ampak tako, naredite vse - domnevam, da bodo odgovori pritrdilen, vendar je to del dejavnosti razvojnega tima, ko na tak ali drugačen način poskušate popraviti nekaj, kar je zlomljeno, ali morda poskušate združiti novo aplikacijo. Toda, ali se vse to ujema z vsemi drugimi komponentami, ki bi jih pričakoval v okolju? Ali lahko pričakujem, da bom lahko posnel to skupaj z vsemi svojimi testnimi paketi in vsemi temi, ki bi jih delal, in s svojimi stvarmi za upravljanje projektov, kako je vse to posnet?
Bert Scalzo: Ja, lahko postane del katerega koli strukturiranega procesa, ki bo opravil vaše programiranje ali razvojna prizadevanja. In kar je smešno, prejšnji teden sem imel stranko, ki je gradila spletno aplikacijo, njihova podatkovna baza pa je bila zgodovinsko majhna in tako dejstvo, da niso bili zelo dobri programerji, jim nikoli ne škodi. No, njihova baza podatkov je z leti rasla in zdaj traja 20 sekund na spletni strani, med tem, ko si rečeš: "Prijavi se in mi daj nekaj podatkov, da si jih ogledam" in kdaj se zaslon dejansko prikaže, in tako zdaj težava z uspešnostjo In vedeli so, da težava ni bila v nobeni njihovi Javi ali katerem koli drugem kraju. Vendar so imeli na tisoče shranjenih postopkov in zato so morali začeti profilirati shranjene postopke, da bi ugotovili, zakaj je za to spletno stran potrebnih 20 sekund? In v resnici smo ugotovili, da so se v eni izmed izbranih izjav pridružili kartezijanski osebi in tega niso vedeli.
Robin Bloor: Vau
Bert Scalzo: Toda nekdo mi je nekoč rekel: "No, kako bi se lahko pridružili kartezijanski osebi in je ne poznajo?" In to zveni resnično grozno; včasih programer, ki ni zelo primeren za SQL, naredi nekaj takega, kot da mi pridruži kartuzijo, potem pa mi vrne samo prvo ploščo, tako da vem, da sem nekaj dobil, in potrebujem samo prvo. In tako ne vedo, da so pravkar prinesli milijardo plošč ali pa pogledajo skozi milijardo zapisov, ker so dobili tistega, ki jih zanima.
Robin Bloor: Wow, vem, to se imenuje - no, o tem se je dogajalo Dez, v smislu ljudi, ki niso ravno tako spretni, kot bi morda morali biti, veste. Če ste programer, morate vedeti, kakšne so posledice izdaje katerega koli ukaza. Mislim, res, to ne opravičuje te stopnje neumnosti. Domnevam tudi, da ste na tak ali drugačen način samo jezikovni agnostik v zvezi s tem, ker se vse to osredotoča na stran baze podatkov. Ali imam prav v tem? Ali je to isto, karkoli uporabljate na strani kodiranja?
Bert Scalzo: Absolutno lahko to storite v Fortranu ali C ali C ++. Pravzaprav lahko na nekaterih Unixih to celo storite za njihove skriptne jezike; dejansko zagotavljajo enaka orodja. In potem se želim vrniti na sekundo nazaj za to, kar ste rekli brez izgovora. Programerjem bom dal en odmor, ker ne maram programerjev pod avtobus. Toda težava je v resnici akademskem okolju, ker ko se greš učiti programerja, si se učil razmišljanja o zapisu. Ne učite se nastavljenega razmišljanja in to je tisto, kar strukturirani jezik poizvedb ali SQL deluje z nabori; zato imamo zvezo, križišče in minus operaterja. In včasih je zelo težko, če oseba, ki ni nikoli razmišljala o setih, neha, se prepušča posnetku obdelovanja in dela z nabori.
Robin Bloor: Ja, s tabo sem. Mislim, zdaj imam, to je vprašanje izobraževanja; Menim, da je to povsem vprašanje izobraževanja, mislim, da je naravno, da programerji razmišljajo postopkovno. In SQL ni proceduralna, njegova deklarativna. Pravzaprav pravite, "to je tisto, kar si želim, in ne zanima me, kako to storite," veste? Medtem ko si s programskimi jeziki pogosto zavihate rokave in se spravite v podrobnosti, da celo upravljate štetje, medtem ko počnete zanko. Bolezen na ...
Bert Scalzo: Ne. V redu, nadaljuj.
Ja, želel bi reči, da ste predstavili še en primer, da bi profiler dobro dojel, kar se dogaja pri tej obdelavi zapisov v trenutku. Včasih programer, ki je dober v vnaprej zapisani logiki, ne more ugotoviti, kako narediti program SQL. No, recimo, da naredi dve zanki FOR in v bistvu naredi povezavo, vendar to stori na strani stranke. Torej, on dela enak učinek kot združevanje, vendar on to dela sam in profil bi to ujel, ker bi verjetno porabili več časa za ročno združevanje, kot pa da bi strežnik baz podatkov pustil, da to stori namesto vas.
Robin Bloor: Ja, to bi bila katastrofa. Mislim, samo bi se vrgli okoli. Tresenje vedno slabo.
Kakorkoli že, prestopim na Dez; Prepričan sem, da ima nekaj zanimivih vprašanj.
Dez Blanchfield: Hvala, da, da. Pridružil se vam bom, ko programerje ne mečemo pod avtobus. Mislim, da sem predolgo leta v življenju bil sam šifrant, na vseh ravneh, veste, ali je, kot rečeno, sedel v ukazni vrstici stroja Unix, v nekaterih primerih pa sem bil celo vpleten v nekaj različnih pristanišč Unixa z ene strojne platforme na drugo. In predstavljate si lahko izzive, ki smo jih imeli tam. Toda resničnost je, da je kartica za izhod iz zapora za vsakega koderja in pisateljev na svetu. Raketna znanost je, dobesedno, pisati resnično tesno, vsakič, raketna znanost. In znane zgodbe ljudi, kot sta Dennis Ritchie in Brian Kernahan, ki samostojno delajo kodo in nato preidejo na klepet s pregledovanjem kode ob kavi in ugotovijo, da so napisali točno isti del kode, v točno istem programu, v točno takem programu na enak način. In to so storili v C. Toda ta puristična raven programiranja obstaja zelo redko.
Dejstvo je, da vsak dan obstaja le 24 ur na dan, sedem dni v tednu, in stvari moramo samo opraviti. In ko gre za ne le tradicionalne programerje, DBA, in kodre, piskalnike in sysadmin, skrbnike omrežij in varnostno osebje, in vse do teh podatkov državljanov; slišimo, da vsi poskušajo opravljati svoje delo. In zato mislim, da je odličen odvzem vsega tega, da sem vzljubil vaš demo in ljubil sem se pri izhodu, ki ste nam ga pustili tam, pred nekaj trenutki in se z Robinom pogovarjali o tem, da ima to nekaj posebnega - morda ne toliko nišo - vendar širok prostor, ki se nanaša na popravljanje kode ter SQL in podatkovnih baz. Bil sem pa zelo navdušen, ko sem vas slišal, da bi lahko poklical skriptno lupino in poiskal nekaj težav, saj veste, v današnjem dnevu in starosti so vedno delali z najnižjimi stroški za vse.
Razlog, da lahko nekje kupite srajco za 6 dolarjev, je zato, ker je nekdo zgradil sistem dovolj poceni, da dejansko izdeluje in pošilja ter logistično dobavlja, prodaja in prodaja na drobno in prevzema spletna plačila, da bi dobil to majico s 6 dolarji. In to se ne zgodi, če dobiš ljudi, prejete 400.000 dolarjev na leto, da napišejo kodo na popoln način; njegov celoten razvoj. V tem primeru je verjetno eno od vprašanj, ki vas resnično ljubim, če nam želite dati nekaj več vpogleda, kakšna je širina in doseg vrste ljudi, ki jih trenutno vidite, ki nameščajo tovrstna orodja za profiliranje kode in ogled za težave z uspešnostjo? Sprva, zgodovinsko, od kod prihajajo? So bile to velike inženirske hiše? In potem, če grem naprej, ali je to prav, ali mislim, da čedalje več podjetij uporablja to orodje ali ta orodja, da poskusim pomagati kodircem, za katere vedo, ki šele delajo, da bi delo končali. in ga spravi skozi vrata? In včasih potrebujemo izstopno iz zapora? Ali imam prav, ko razmišljam, da smo imeli zgodovinsko bolj inženirski fokus in razvoj? To je zdaj dobilo manj, kot je dejal Robin, akademski pristop in zdaj njegov samouk ali kode za rezanje ali lepljenje, ali pa samo stvari sestavite? In ali se to ujema z ljudmi, ki zdaj jemljejo izdelek?
Bert Scalzo: Ja, točno tako. In dajem vam zelo natančen primer, želimo si le, da bi delo opravili, saj si poslovni ljudje ne želijo popolnosti. Nekako kot računalniška igra v šahu: šahovska igra ne išče popolnega odgovora; išče odgovor, ki je dovolj dober v razumnem času, tako da tako programiramo. Ampak tisto, kar zdaj ugotavljam, je večina ljudi, namesto da bi rekli, da želijo profilerja kot del svojega testiranja na enoto - tako bi to storil, ker tega ne vidim kot izgubo časa - kaj se dogaja je zdaj, da se to počne kasneje, včasih med integracijskim testiranjem ali stresnim testiranjem, če bi imeli srečo. Toda večino časa je bil njegov del stopnjevanja, kjer so se nekaj dogajale v proizvodnji, nekaj časa tekel, morda celo leta tekel, zdaj pa ne teče dobro, zdaj pa dobro profilira. Zdi se, da je zdaj to pogostejši scenarij.
Dez Blanchfield: Ja, in mislim, da je izraz "tehnični dolg" verjetno bolj kot poznan; Poznam Robina in zagotovo sem. Menim, da je po mojem mnenju koncept tehničnega dolga danes, zlasti pri agilnih pristopih k razvoju in oblikovanju sistemov, zelo resnična stvar, ki jih pravzaprav upoštevamo v projektih. Vem, mislim, dobili smo lastne projekte, kot so Media Lens in drugi, kjer se vsakodnevno dogaja kodiranje, in razne stvari v celotni skupini Bloor. In kadarkoli smo kaj gradili, nekako pogledamo, gledam na to in vedno gledam z vidika, kaj me bo stalo, da to popravim zdaj, v nasprotju s tem, ali lahko to samo dobim v pločevinki in pojdi ven in glej, ali se bodo te stvari zlomile. In podedujem ta tehnični dolg, za katerega vem, da ga moram pozneje obkrožiti in popraviti.
In mislim, to sem storil v zadnjih sedmih dneh: napisal sem nekaj orodij in skript, napisal nekaj kosov jezika Python in nameščal v Mongo zadnji del, s čimer sem poskrbel, da je lepo, čisto in varno, vendar dobi samo poizvedbo, ki jo moram opraviti, saj vem, da potrebujem to funkcijo, da lahko dosežem večjo sestavljanko; tam je moja prava bolečina. In tako prevzamete ta tehnični dolg, in mislim, da to zdaj ni le občasna stvar, mislim, da je to del DNK, ki se razvija. Ljudje samo - ne nespametno - samo sprejemajo, da je tehnični dolg običajni način izdaje in ga morajo samo prevzeti. Tam imaš tehnični dolg. In mislim, da je odlična stvar tega, kar ste nam pokazali v demonstraciji, ta, da lahko dobesedno pregledujete in gledate, kako dolgo nekaj traja. In to je verjetno ena mojih najljubših stvari. Mislim, dejansko sem izdelal orodja za profiliranje - včasih smo gradili orodja v Sed in Lex in Orc, da smo zagnali kodo in videli, kje so zanke, preden so bila na voljo ta orodja - in ko naredite vdelano kodo, da preverite svojo kodo , zelo dobro je, da vam ni treba pregledati lastne kode. Ampak to zdaj ni tako. Glede na to ali obstaja kakšen tržni segment, ki to prevzame bolj kot kateri koli drug? Videti kot masa -
Bert Scalzo: O ja, imam ... Naredil bom analogijo za vas in vam pokazal, da to nenehni programerji počnejo ves čas. Ker če kdaj poučujem razred ali odsek za odpravljanje napak in profiliranje, vprašam ljudi: "V redu, koliko ljudi je tukaj v programu Microsoft Word in namenoma nikoli ne uporablja preveritelja črkovanja?" vsi vemo, da lahko delamo angleške napake in tako vsi uporabljajo preverjanje črkovanja. In rekel sem si: "Kako to, da v IDE pišete, kot je Visual Basic, ne uporabljate odpravljalnika? To je isto, podobno kot preverjanje črkovanja. "
Dez Blanchfield: Ja, pravzaprav je to odlična analogija. Nisem res razmišljal, moram priznati, da dejansko naredim nekaj podobnega z nekaj orodji, ki jih uporabljam. V bistvu, ODF, moj najljubši pri Eclipseu, je samo rezanje in lepljenje kode in tam iskati stvari, ki so takoj poudarjene in zavedam se, da sem v nekem razrednem klicu natipkal tipko. In vendar je zdaj zanimivo z orodjem, kot je to, lahko to storite v realnem času, v nasprotju s tem, da se vrnete in si ga ogledate pozneje, kar je lepo, če ga ujamete vnaprej. Ampak ja, to je velika analogija samo vstavljanja v urejevalnik besedil, zaradi česar je zanimiv prebudni klic, samo zavedaš se, da si naredil nekaj tipk ali celo slovničnih napak, kajne?
Bert Scalzo: Točno tako.
Dez Blanchfield: Torej, ali opažate več prizadetosti, mislim, končno vprašanje, preden se vrnem na naša vprašanja, morda za naše udeležence. Če bi dali kakšno priporočilo v zvezi s pristopom k temu - če predvidevam, da je to retorično - ali se zgodi, da začnete zgodaj in to izvajate, ko se razvijate, preden se razvijate? Ali pa se zgodi, da se večinoma gradite, se premikate, nekaj zgradite in pozneje vstavite in profilirate? Sumim, da se je v primeru zgodnjega zgodilo in poskrbite, da bodo vaše kode vnaprej čiste. Ali je to slučaj, da bi morali razmišljati o tem delu svoje razporeditve?
Bert Scalzo: V idealnem primeru bi to storili vnaprej, a ker so vsi v svetu vrveža, kjer so se morali samo lotiti stvari, tega ne počnejo, dokler ne naletijo na težavo z zmogljivostmi, ki je ne morejo rešiti z dodajanjem več CPU-jev in spomina na virtualni stroj.
Dez Blanchfield: Ja. Torej ste pravzaprav omenili kaj zanimivega, če lahko hitro? Prej ste omenili, da se to lahko izvaja od koder koli in se lahko pogovarjate z bazo podatkov na zadnji strani. Torej, to je primerno s takšnim bimodalnim konceptom, o katerem govorimo zdaj, o oblaku v prostorih / izven prostora, tudi po videzu stvari, na koncu dneva, če se lahko pogovarja s hrbtnim delom in si oglejte koda, res ne skrbi, kajne?
Bert Scalzo: Točno tako, da, lahko to zaženete v oblaku.
Dez Blanchfield: Odlično, ker se mi zdi, da tam nekako gre naš novi pogumni svet. Torej, Eric. Zdaj se bom vrnil k vam in videl, da imamo tukaj nekaj vprašanj in želim, da naši udeleženci še vedno ostanejo pri nas, čeprav smo pretekli uro.
Eric Kavanagh: Ja, tukaj je nekaj ljudi, samo na kratko povem: Bert, mislim, da je metafora, analogija, ki jo podajaš s preverjanjem črkovanja, odkrito. To je vredno bloga ali dveh, odkrito povedano, saj je to dober način za določitev nasprotovanja tega, kar počnete, in kako dragocen je, in kako bi bilo v resnici najboljša praksa za uporabo odpravljalnika redno, kajne? Stavim, da boste nekoč kimali, ko jo vržete ven, kajne?
Bert Scalzo: Absolutno zato, ker jim rečem: "Zakaj preverim črkovanje svojih dokumentov? Nočem se sramiti neumnih črkovalnih napak. "No, nočejo se jih sramiti neumnih napak pri kodiranju!
Eric Kavanagh: Prav. Da, resnično. No, ljudje, tam smo goreli uro in pet minut, tako da se zahvaljujem vsem, ki ste jih imeli tam za vaš čas in pozornost. Vse te spletne klepete arhiviramo, se lahko kadar koli vrnete in si jih oglejte. Najboljše mesto za iskanje teh povezav je verjetno techopedia.com, zato dobro dodajte to na ta seznam tukaj.
In s tem bi se poslovili, ljudje. Še enkrat, odlično delo, Bert, zahvaljujoč se prijateljem iz IDERA. No, pogovoriva se naslednjič, pravzaprav se pogovoriva naslednji teden. Pazite! Adijo.