Avtor osebja Techopedia, 15. marec 2017
Odhod: Domačin 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: Ne slišim te, Eric.
Eric Kavanagh: Bil sem tam pred dnevi, 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 ste oseba, ki to počne, v tem primeru pa se želite prepričati, da to počnete pravilno. Ker govorimo 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, govorili bomo o "Hitrem odzivu: Odpravljanje napak v zbirki podatkov in profiliranje v reševanje."
Resnično obstaja spot o tvojem, na Twitterju me objavi, @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 bo izginila, 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, se bo zgodilo, vprašanje je, kaj bo vaša rešitev za reševanje in reševanje teh težav?
Slišali bomo od dr. Robina Bloorja, nato našega lastnega Deza Blanchfielda od spodaj, in seveda našega dobrega prijatelja Berta Scalza iz IDERA. In v resnici bom izročil ključe Robinu Bloorju, ga odnesel. Tla so tvoja.
Robin Bloor: V redu. To je zanimiva tema. Mislil sem, da ker bo Dez verjetno nadaljeval dejanske tehnike in vojne zgodbe o odpravljanju napak, sem mislil, da bom samo opravil razpravo v ozadju, da bi dobili popolno zaokroženo sliko tega, kar se dogaja. To sem delal dolgo časa in včasih sem bil koder, tako je bilo in skorajda me je s to predstavitvijo skoraj mikalo, da bi začel delovati lirično o ideji o odprtem kodu, vendar sem mislil, da bom to prepustil komu drugemu.
Tu je seznam znanih hroščev in večina teh se uvrsti na zgornji seznam nikogar, 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 tako. 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 kodirni poskus, ki je nenadoma postal besen črv, ki je obšel vse - 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. Apple-ov program 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. Najdaljši izpad v letu 1990 - z vidika stroškov takega je zanimiv - AT&T so imeli približno devet ur in stanejo 60 milijonov dolarjev medkrajevnih klicev.
Bil sem pri zavarovalnici v Veliki Britaniji 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 bom govoril 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 se v tabelah resnično ne preslikajo dobro. In zaradi tega dobite, 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 kodirnika in baza podatkov drug model, nista posebej usklajena. 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, 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 vgradili shranjene postopke, da bi lahko živeli v bazi, in razlog za shranjene postopke, ki živijo tam, je bil, da resnično niste želeli metati podatkov naprej in nazaj v program.
Nekatera funkcionalnost je bila izjemno specifična za podatke, zato ni bila le referenčna celovitost in kaskadni brisi in podobno, baza podatkov je skrbela za nenadno vstavljanje funkcionalnosti v bazo podatkov, kar je seveda pomenilo, da funkcionalnost aplikacije se lahko razdeli med kodirnik in samo 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 imate na primer veliko izvedb, da sem sodeloval v relacijskih bazah podatkov, je resnično veliko kode, ki je shranjena v shranjenih postopkih, ki se obdelujejo ločeno od kode, ki je v aplikacijah. In zdi se, da bi moralo biti zelo nenavadno, saj naj bi delal različne stvari dokaj pametno.
Mislil sem, da bom govoril tudi o uspešnosti baze podatkov, ker napake v delovanju pogosto veljajo za napake, toda v bistvu lahko imate 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 koderju res ni treba skrbeti za uspešnost in bo baza podatkov dejansko dobro delovala. Zasnovana naj bi bila tako, da koderju 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 je 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 to veliko storil - in pogosto boste odkrili, da je tako kot v vseh situacijah pri odpravljanju napak, ki jih prva izkušnja je, da 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, so samo pokvarjeni podatki in razmišljate: "Kako za vraga se je to zgodilo?"
Kakor koli že, bom posredoval Dezu, ki bo verjetno povedal več besed modrosti, kot sem jih izšel. Ne vem, kako bi ti dal žogo, Dez.
Eric Kavanagh: Prestavil ga bom, bodi pripravljen, drži.
Samodejni glas: Udeleženice so izključene.
Eric Kavanagh: V redu, počakaj za eno sekundo, naj dam Dez žogo.
Dez Blanchfield: Hvala, Eric. Da, doktor Robin Bloor, resnično ste najbolj pravi: to je tema, vseživljenjska napaka, če se boste oprostili punčke, oprostite, da se pri tem nisem mogla rešiti. 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 gre za primer profiliranja kode in je mogoče zapisati kodo, ki deluje, to bi moral biti napaka. 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.
Torej, urbani mit je, da je okrog 9. septembra 1945 ekipa na univerzi Harvard raztrgala stroj, naletela je na nekaj, kar so poimenovali "štafeta sedemdeset" - programiranje je bilo v fizičnem smislu narejeno okoli deske, in tako ste učinkovito programirali stroj - in ugotovili so, da je ta rele številka sedemdeset nekaj narobe, in izkazalo se je, da je prišlo do dejanskega izraza "hrošček", ker je bil dobesedno molj - je bil molj klečen med nekaj kosa bakrene žice, ki je šel 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 uporabljamo to terminologijo, da poskušamo reševati težave, bodisi ne toliko kot težave s kodiranjem v programu, ki se ne sestavlja, ampak kot program, ki ne deluje dobro. In še posebej, ni bilo profilirano, poiščite stvari, kot so neskončne zanke, ki ne gredo nikamor.
Imamo pa tudi scenarij in mislil sem, da bom postavil nekaj smešnih diapozitivov, preden sem se podrobneje seznanil. Tu je klasična risanka, ki se v spletu imenuje XKCD, karikaturist pa ima nekaj precej smešnih pogledov na svet. In ta je o otroku, imenovanem "Mali Bobby Tables" in menda naj bi starši tega mladega poimenovali Robert "); DROP TABLE Učenci; in to se imenuje, in nekako: "Živjo, šola vašega sina 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 resnično poimenoval svojega sina Roberta "); DROP TABLE Študenti; -? "In starš reče:" O, da, mali Bobby Tables, mu pravimo. "Kakorkoli že, trdijo, da so zdaj izgubili študentske evidence letnika, 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, da koda pogosto ne pogleda podatkov tudi.
Še ena smešna, ne vem, ali je to resnična ali ne - sumim, da gre za prevaro -, vendar se spet 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. Vendar sem zelo prepričan, da je ta čas minil, in po mojih izkušnjah sem prvi - in to me bo grozno postaralo, prepričan sem; Robin, dobrodošel je, da se mi je zaradi tega posmehoval - toda zgodovinsko sem prišel iz ozadja pri 14 letih in se sprehajal po koncu mesta in trkal na vrata podatkovnega centra, imenovanega "Data Com" v Novi Na Zelandiji in sprašujem, ali bi lahko v šoli zaslužil žepnino, tako da bom vsak dan prišel pozni avtobus domov, približno 25 km poti, dajem papir v tiskalnike in trakove v tračne pogone in sem samo splošen 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 fizični tiskalnik s 132 stolpci. V bistvu si omislite kot zelo star pisalni stroj s papirjem, ki se je premikal po njem, ker niso imeli epruvete za CRT. In odpravljanje napak pri tej napaki je bilo zelo nepomembno, zato ste navadno vso kodo napisali ročno in se nato obnašali kot tipkar, da bi se potrudili, da ne bi prišli do napak, ker je izredno frustrirajoče. urejevalnik ene vrstice, da gremo do določene vrstice in nato natisnemo vrstico in jo nato vtipkamo. Toda nekoč smo tako pisali kodo in tako smo odpravili napako in v tem smo se zelo dobro razšli. 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 smo že 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 stvar naredili ste na papirnem traku nekakšno tiskano obliko samo na CRT, vendar ste lahko 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; niso te pustili, 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 sem vam povedati, da sem iz svojega ozadja, na več načinov sem bil samouk in tisti, ki so mi pomagali pri učenju, me je naučil zelo dobrih programerskih praks in zelo dobrih praks v zvezi z oblikovanjem in procesi, da se prepričam, da nisem uvesti kodo buggy.
Načrtovanje programiranja v teh dneh, na primer strukturiran jezik poizvedb, SQL, je zelo močan in preprost jezik poizvedb. Toda to smo 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, ker 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šem, na primer s SQL, ki skačejo po Googlu in iščejo nekaj in najdejo spletno mesto, ki je 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 vsi hitimo temu, čemur pravimo dirka do ničle: poskušati narediti vse tako poceni in tako hitro, da imamo scenarij, kjer ne zaposlujemo nižje -plačano osebje. In to ne mislim na nenavaden način, vendar ne zaposlujemo 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 početi norega.
Danes je veliko ljudi, ki se ukvarjajo z razvojem, oblikovanjem in bazo podatkov, ki niso imeli dolgoletnih izkušenj, niso nujno imeli istega usposabljanja ali podpore. In tako zaključite s scenarijem samo tradicionalnega amaterja v primerjavi s strokovnjakom. In obstaja znana vrstica, ne morem se pravzaprav spomniti, kdo je ustvaril citat, se glasi: "Če menite, da je drago najeti strokovnjaka za delo, počakajte, da najamete nekaj amaterjev, ki ustvarijo težavo in vi to mora očistiti. "In tako ima SQL to težavo, in to je zelo, zelo enostavno za učenje, je 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 potegniti v programski jezik, ki vam je bolj všeč, kot sta PHP in Ruby ali Python, in uporabljati programski jezik, ki ga domače poznate, manipulacija podatkov, 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 se odloči zvezda od kjer koli.
To je res ekstremni primer, toda iz vsega navedenega izveste bistvo. Torej, da resnično prebijem točko domov, tukaj 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 ga vsi dobro poznamo. Na levi strani je del SQL-a, ki to dejansko predstavlja. 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 konstrukte in shranjene postopke, uporabljamo programsko metodologijo, ki se uporablja za jezik, zato je zelo enostavno za slabo programsko prakso, pomanjkanje izkušenj, kodo za rezanje in lepljenje, nizko plačani uslužbenci, ki poskušajo biti visoko plačani, 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 mislite, da je to preprosto, je nekako luštno in si mislite: "Vau, kakšna odlična grafika, to bi rad vodil." Ampak predstavljajte si, da teče po nekem delu poslovne logike . 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, naj bi bilo črno ozadje in zeleno besedilo zeleni 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, ki je 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 te stvari lahko ujeli, in te vstopijo v proizvodnjo, in potem imate 100.000 ljudi vsak dan ali uro ali minuto udarite v sistem, kmalu na koncu doživite černobilsko izkušnjo, 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 dajmo si DBA, ki vam bo pomagal pravilno sestaviti strukturirano poizvedbo, ker odkrito povedano, to je samo grdo." In URL je tam, lahko poiščete in si ogledate - imenovan je najbolj zapletena poizvedba SQL, kar ste jih kdaj napisali. Ker verjemite mi, to 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 treh do petih minutah, da pokličete nazaj tisto, kar je ena vrstica besedila.
Če povzamem, glede na to me je moje celotno ozadje kodiranja naučilo, da lahko ljudem daste pištolo in če niso previdni, se bodo streljali v nogo; trik je, da jim pokažete, kje je varnostni mehanizem. S pravimi orodji in pravo 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 rekel prej, ko boste to nekoč lahko gledali 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 več storiti 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 bomo kmalu prejeli. Eric, vrnil se bom nazaj.
Eric Kavanagh: V redu, Bert, vzemi ga.
Bert Scalzo: V redu, hvala. Bert Scalzo tukaj iz IDERA, vodja 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 res je, da je odpravljanje napak težavno in nepomembno, in ko odidete v odpravljanje napak v zbirki podatkov, je to razsežnost še bolj naporna in nepomembna - 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 v katerem koli jeziku, ki ga uporabljajo, in velikokrat mi bodo rekli, "No, te stvari za odpravljanje napak so nove in tega še nismo začeli uporabljati." In zato, kar počnem, jim pokažem ta časovni načrt, nekakšna predzgodovina, starost, srednji vek, nekako je prijazen recimo kje smo bili v smislu 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 napak, ker je to ena od teh novih stvari", potem ste morali začeti programirati, saj veste, v petdesetih letih prejšnjega stoletja, ker je to samo tako bi se umaknili s to trditvijo.
Zdaj je druga stvar, ki je smešna pri tej lestvici, Dez je pravkar komentiral Grace Hopper, Grace sem pravzaprav poznal, tako da je nekako smešno. In potem sem se drugemu, kar sem se smejal, govoril o teletipih in sedim tam, ko grem: "Človek, to je bil največji preskok produktivnosti, ko smo šli od kart do teletipov, to je bil največji skok doslej. "Torej, in programiral sem v vseh jezikih, vključno s SNOBOL, za katerega še nihče ni slišal, bil je to CDC, Control Data Corporation, tako da mislim, da sem za to panogo nekoliko prestar. .
Dez Blanchfield: Hotel sem reči, da ste nas strašno postarali.
Bert Scalzo: Ja, pravim vam, počutim se kot dedek Simpson. Zato pogledam na odpravljanje napak in obstajajo različni načini 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; tam v kodo vstavite izjave in morda ustvarite izhodno datoteko, datoteko sledenja ali kaj podobnega, in tako povežete svojo kodo. To bi štel kot razhroščevanje, nekoliko težje, način, kako to storiti, vendar šteje. Poleg tega imamo znano izjavo o tiskanju: opazujete in ljudje dejansko vstavljajo izjave o tiskanju in dejansko sem videl orodje, kamor - in to je orodje za bazo podatkov - kjer, če ne veste, kako uporabljati odpravljalnik, pritisnete tipko in ta bo za vas vtisnila izjave o tiskanju skozi kodo, nato pa, ko končate, pritisnete še en gumb in ta jih odstrani. Ker tako odpravlja napako 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, da je prišlo do logične napake ali smo zamudili poslovno zahtevo, toda kaj je, če koda ni učinkovita; ne naredi tistega, kar smo pričakovali. Drugič, ko gremo za odpravljanje napak, gre za učinkovitost in to bi lahko bila logična napaka, toda kaj je, če sem naredil pravilno, se preprosto ne vrne dovolj hitro. Zdaj to poudarjam, ker je verjetno, da je profiler boljši za ta drugi scenarij in se bomo pogovarjali tako o razpravljalcih kot o profilnikih. Poleg tega obstaja ta koncept oddaljenega odpravljanja napak; to je pomembno, ker velikokrat, če sedite za osebnim računalnikom in uporabljate odpravljalec napak, ki zadene bazo podatkov, kjer je koda dejansko izvedena v bazi, pravzaprav počnete tako imenovano oddaljeno odpravljanje napak. Morda se tega ne zavedate, vendar se to dogaja. In potem je pri teh razhroščevalcih zelo pogosto, da imajo prelomne točke, točke gledanja, stopite korak naprej in nekatere druge običajne 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 to vzorčenje. Ni razloga, da lovite vsako posamezno izjavo, ker se nekatere izjave lahko začnejo izvajati tako hitro, da vam ni vseeno, kaj resnično poskušate videti, je tisto, ki se vedno znova pojavlja, ker se predolgo tečejo. 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 jeziki baz podatkov, kot smo že govorili, imate SQL - in tu smo nekako prisilili okrogel zatič v kvadratno luknjo in ga prisilili, da postane programski jezik - in Oracle. To je PL / SQL - to je proceduralni jezik SQL - in SQL Server, to je Transact-SQL, SQL-99, SQL / PSM - za, mislim, da je postopek shranjen 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 baze podatkov, je to pomembno, ker bodo ljudje rekli: "No, kakšne stvari moram odpraviti napak v bazi?" In odgovor je, no, vse, kar lahko shranite v bazo kot kodo - če počnem T-SQL ali PL / SQL - in shranjujem predmete v bazo podatkov, verjetno je shranjena procedura ali shranjena funkcija. Obstajajo pa tudi sprožilci: sprožilec je nekako kot shranjena procedura, vendar se sproži na nekakš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: še vedno je sprožilec lahko tisto, kar sproži vso stvar. In potem kot Oracle imajo nekaj, kar imenujejo paket, ki je nekako podoben knjižnici, če hočete. V eno združenje, ki se imenuje paket, postavite 50 ali 100 shranjenih postopkov, tako da je nekako podobno knjižnici. Torej, tukaj 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, je to ne-ročna metoda za odpravljanje napak.
Razlog, da to povem, je, da če to poskušate storiti z roko, boste dejansko vnesli več kod za odpravljanje napak, da boste vnesli v vse te izjave o tiskanju, kot jih imate s kodo. Čeprav je to mogoče, in čeprav je bolje kot nič, je to zelo težaven način za odpravljanje napak, še posebej, kaj pa, če traja 10 ur, da se ta stvar zažene, in če ima težavo, je na vrsti tri? Če bi delal sejo za odpravljanje napak, bi v vrstici tri - pet minut zanjo vedel - hej, tu je težava, lahko neham. Toda s tem moram počakati, da se zažene, vse do zaključka, nato pa moram pogledati neko datoteko sledenja, ki ima verjetno vse te izjave o tiskanju, in poskusiti in najti iglo v seneni nahod. Spet je to bolje 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 v tej datoteki sledenja je na voljo kup natisnjenih izjav in morda ne bom mogel prebrskati tega in najti tisto, kar moram najti. Torej, spet nisem tako prepričan, da bi si tako želeli delati.
Zdaj, interaktivni razhroščevalci - in če ste za pisanje programov ali Eclipse uporabljali nekaj podobnega kot Visual Studio, ste imeli razhroščevalce in ste jih uporabljali z drugimi jeziki - preprosto jih niste mislili uporabljati tukaj 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 grem 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, v sredini imam svojo izvorno kodo, imam tako imenovane spremenljivke ure in pladnji za skladanje klicev, nato pa na dnu ' Imam nekaj izhodnih sporočil. In kar je tukaj pomembno je, da če pogledam 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 pregledujem kodo. In to je res koristno, nato pa lahko prek kode stopam eno vrstico naenkrat, ni mi treba reči izvršiti, lahko bi rekel korak črto, naj 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 je naslednja puščica tam - vidite malo podobno puščico, ki kaže desno, proti izhodu DBMS, tam je trenutno moj kazalec - torej z drugimi besedami, stopil sem in tam sem na trenutek. Torej, če rečem, "korak znova", grem do naslednje vrstice. Zdaj tik pod tem boš videl rdečo piko. No, to je točka preloma, ki pravi: "Hej, nočem prestopiti čez te vrstice." Če hočem samo preskočiti vse in priti do te rdeče pike, lahko pritisnem na gumb za tek in bo tekel. od tu bodisi do konca, bodisi do točke preloma, če so določene točke preloma, in potem 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, vendar najpomembneje na sredini, spremenilo, in ko sem videl vrednosti iz svojih spremenljivk, Vidim sled svojega zaloga klicev, veste, in tako se vse te informacije prikažejo tam, ko prečkam kodo, tako da dejansko vidim in čutim ter razumem, kaj se dogaja in kako v resnici je koda ki delajo v času izvedbe. Običajno lahko najdem težavo, če obstaja, ali če sem dovolj dobra, da jo ujamem.
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 sem spet v sistemu Rapid SQL in vidim, da je na levi strani rob poleg številk vrstic. In to je to, to je toliko 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 torej, karkoli se dogaja znotraj te zanke FOR, je verjetno nekaj, kar moram pogledati, in če bom lahko izboljšal, bo izplačal dividende. Ne bom izboljšal, če bom delal na tistih vrsticah, ki imajo 0, 90 ali 0, 86; tam ni veliko časa preživetega. Zdaj, v tem primeru in spet sem v Rapid SQL, vidite, kako lahko naredim profiliranje, pomeš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 nisem več v razhroščevalniku in zažene program, in ko je izvedba končana, mi da grafikone, da mi pove stvari, tako da vidim, da imam eno izjavo, ki je videti, kot da se je lotil Večina skodelice in če pogledam, vidim na tej rešetki proti dnu, vrstica 23, spet je zanka ZA: zanj je vzela največ časa, v resnici je temno rdeča, ki žveči vse karte z lističi. In tako, to je še en način za profiliranje. V našem orodju smo poimenovali tega „analitika kode“. A v bistvu gre le za profil, ločen od odpravljalca 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, vendar 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 jim brati 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 človek v poslovni obleki z lokom in puščico in streljate v tarčo in imate zavezane 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 zagotovila, da jih bo pregled kode našel. Z napravo za odpravljanje napak in profilerjem bi morali najti vse te napake.
V redu, tukaj bom samo naredil hiter demo posnetek. Ni mi namen, da bi potisnil izdelek, samo želim vam pokazati, kako izgleda odpravljanje napak, ker bodo ljudje velikokrat rekli: »Nikoli še nisem videl nobenega od teh.« In videti je precej na zaslonskih diapozitivih., ampak kako izgleda, ko je v gibanju? Torej, tukaj na mojem zaslonu zaženem 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 tukaj imam na izbiro 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, tukaj je moja puščica, zgoraj na vrhu, prva 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, ustrelil sem, da imam enega od tipk za zajem zaslona preslikan na isti tipki kot za odpravljanje napak, to pa 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, tako da sem zdaj v kontekstu izvajanja te zanke, vidim, na kaj so nastavljene vse moje spremenljivke, kar ni presenečenje, ker sem jih inicializiral vse na nič. In zdaj lahko stopim v to zanko in začnem gledati, kaj se dogaja znotraj te zanke.
Torej, zdaj bom opravil 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. Grem samo naprej in pustim, da teče. Nočem 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 mejo preloma, ko sem rekel teči, se je vrnil na naslednjo prelomno točko. Pustim, da teče do konca, kajti želim, da vidite, da razhroščevalnik ne spremeni vedenja programa: ko se konča, 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. Delal sem s takimi, vendar v bazi podatkov še nikoli nisem delal česa takega. Mi lahko daste kakšno predstavo, za kaj ljudje uporabljajo profiler? Ker je tako, ali gledajo - ker domnevam, da so - gledajo na težave glede zmogljivosti, ali vam bo to 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, znotraj svojega Visual Basic pa bom poklical Transact-SQL ali PL / SQL. Naj naredim PL / SQL, saj Oracle ne igra vedno 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, 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, kličemo na ta del kode prepogosto. 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 imenujemo prepogosto in to je pravzaprav 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 v resnici vpletena v gradnjo aplikacij, kjer smo imeli shranjene postopke, tako da verjetno nikoli nisem naletela na težave, ki so me dolgočasile, ideja, da si kodo razdelim med bazo podatkov in program. Ampak tako, naredite vse - domnevam, da bo odgovor "da", vendar je to del dejavnosti razvojnega tima, ko tako ali drugače poskušate popraviti nekaj, kar je zlomljeno, ali morda poskušate prinesti novo prijava skupaj. 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, v katerem si lahko prizadevate za programiranje ali razvoj. In smešno je, prejšnji teden sem imel stranko, ki je gradila spletno aplikacijo, njihova podatkovna baza pa je bila v preteklosti majhna, zato dejstvo, da niso bili zelo dobri programerji, jim nikoli ni škodilo. No, njihova baza podatkov je z leti rasla in zdaj traja 20 sekund na spletni strani, med tem, ko rečeš: "Prijavi se in mi daj nekaj podatkov, da si jih ogledam" in kdaj se zaslon dejansko prikaže, in tako je zdaj težava z uspešnostjo In vedeli so, da težava ni 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 se je v eni izmed izbranih izjav pridružila kartuzijana 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 bo zveni res 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 se ne zavedajo, da so pravkar prinesli milijardo plošč ali pa pogledajo skozi milijardo zapisov, ker so dobili tistega, ki jih zanima.
Robin Bloor: Wow, vem, tako se imenuje - no, Dez se je dogajal tako, da ljudje, ki niso ravno tako spretni, kot bi morda morali biti, veste. Če ste programer, bi morali vedeti, kakšne so posledice izdaje katerega koli ukaza. Mislim, res, ni nobenega opravičila za to stopnjo neumnosti. Domnevam tudi, da ste na tak ali drugačen način zgolj 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 že uporabljate na strani kodiranja?
Bert Scalzo: Vsekakor 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, saj ne maram metati programerjev pod avtobus. Toda težava je v resničnem akademskem okolju, ker ko se greš učiti, kako biti programer, te naučijo razmišljati sproti. 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 operater. In včasih je zelo težko, da oseba, ki nikoli ni razmišljala o sklopih, neha, prepušča posnetek obdelave posnetkov in dela s seti.
Robin Bloor: Ja, jaz sem s tabo. Mislim, zdaj razumem, to je vprašanje izobraževanja; Mislim, da je to povsem vprašanje izobraževanja, mislim, da je naravno, da programerji razmišljajo postopkovno. In SQL ni proceduralni, je deklarativen. Pravzaprav pravzaprav pravite: "To je tisto, kar si želim, in ne zanima me, kako to storite, " veste? Medtem ko s programskimi jeziki pogosto zavihate rokave in ste dolgi, da celo upravljate štetje, medtem ko počnete zanko. Predal bom:
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. Recimo, da naredi dve zanki FOR in v bistvu naredi spoj, vendar to stori na strani stranke. Torej, ima enak učinek kot združitev, vendar to počne 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 dopustil za vas.
Robin Bloor: Ja, to bi bila katastrofa. Mislim, samo bi se vrgli okoli. Vrtanje je vedno slabo.
Kakor koli že, grem naprej k Dezu; Prepričan sem, da ima nekaj zanimivih vprašanj.
Dez Blanchfield: Hvala, da, da. Pridružil se vam bom v tem, da programerje ne mečemo pod avtobus. Hočem reči, da sem predolgo leta v življenju bil sam koder, 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ščih Unixa z ene strojne platforme na drugo. In predstavljate si lahko izzive, ki smo jih imeli tam. A resničnost je takšna, kot je kartica za izhod iz zapora za vsak koder in skriptor 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 se nato prikažejo na klepetu za pregledovanje kode ob kavi in ugotovijo, da so napisali popolnoma isti del kode, v točno istem programu, na povsem enak način. In to so storili v C. Toda ta puristična raven programiranja obstaja zelo redko.
Dejstvo je, da vsak dan imamo samo 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, vsi samo poskušajo narediti 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 res navdušen, ko sem vas slišal, da bi ga lahko pokrpali pri skriptu lupine in našli nekaj težav, saj veste, da v današnjem času in starosti vedno delamo 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 boste morali ljudem prejemati 400.000 dolarjev na leto, da napišejo kodo na popoln način; gre samo za celoten razvoj. Torej, v tem primeru je verjetno eno od vprašanj, za katerega bi vas resnično rad sprejel, samo da bi nam dali nekaj več vpogleda, kakšna je širina in doseg vrste ljudi, ki jih trenutno vidite, ki nameščajo tovrstna orodja za profil kodo in iščete 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, kot je rekel Robin, manj akademskega pristopa, zdaj pa je samouk ali koda 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. Navedel bom zelo natančen primer, saj želimo samo opraviti delo, saj poslovni ljudje ne želijo popolnosti. To je 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, zato tako programiramo. Toda zdaj ugotavljam, da večina ljudi namesto, da bi rekel, da želijo profilerja kot del svojega testiranja enot - tako bi to storil, ker tega ne vidim kot izgubo časa - kaj se dogaja zdaj, ko to storimo kasneje, včasih med integracijskim testiranjem ali stresnim testiranjem, če imamo srečo. Toda večinoma je to del stopnjevanja, kjer je nekaj propadlo v proizvodnji, nekaj časa je tekla, morda celo tekla leta in zdaj ne deluje dobro, zdaj pa bomo to profilirali. Zdi se, da je zdaj to pogostejši scenarij.
Dez Blanchfield: Ja, in mislim, da je izraz "tehnični dolg" verjetno tisti, ki ga poznate več kot; 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, imamo lastne projekte, kot so Media Lens in drugi, kjer se vsakodnevno dogaja kodiranje, in razne stvari v celotni skupini Bloor. In kadarkoli nekaj gradimo, nekako pogledamo, gledam na to in vedno gledam z vidika, koliko bo to stalo, da to popravim zdaj, v nasprotju s tem, ali lahko to preprosto prejmem v lahko in ga spravite ven, nato pa opazite in preverite, ali se bo ta stvar zlomila. In podedujem ta tehnični dolg, za katerega vem, da ga bom moral kasneje obkrožiti in popraviti.
In mislim, to sem storil v zadnjih sedmih dneh: napisal sem nekaj orodij in skript, napisal sem nekaj kosov jezika Python in ga razporedil v zadnji del Mongo. prepričan je, da je lep, čist in varen, toda samo dobim poizvedbo, ki jo potrebujem, saj vem, da potrebujem to funkcijo za delo, da pridem do večje uganke; tu 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čno 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 - uporabljali smo 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 ste izdelali kodo in preglejte 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 počnejo neprogramerji ves čas. "Ker bom kdaj poučeval razred ali sejo za odpravljanje napak in profiliranje, bom ljudi vprašal:" V redu, koliko ljudi tukaj gre v Microsoft Word in namenoma nikoli ne uporablja preveritelja črkovanja? "In nihče ne dvigne roke, ker pri pisanju dokumentov vsi vemo, da lahko delamo angleške napake in tako vsi uporabljajo preverjanje črkovanja. In sem si rekel: "No, kako to, da v IDE pišete besedilo, kot je Visual Basic, ne uporabljate odpravljalnika? To je ista stvar, je kot preverjanje črkovanja. "
Dez Blanchfield: Ja, pravzaprav to je odlična analogija. Nisem še razmišljal, priznati moram, da z nekaj orodji pravzaprav delam nekaj podobnega. 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 takim orodjem, ki ga lahko naredite v realnem času, v nasprotju s tem, da se vrnete in si ga ogledate pozneje, kar je nekako lepo, če ga ujamete vnaprej. Ampak ja, to je odlična analogija samo vstavljanju besedila v urejevalnik besedil, ker gre za zanimiv klic budnosti, samo zavedajte se, da ste naredili nekaj tipk ali celo slovničnih napak, kajne?
Bert Scalzo: Točno.
Dez Blanchfield: Torej, ali opazite več prizadetosti, mislim, končno vprašanje od mene, preden se vrnem na naša vprašanja in vprašanja za naše udeležence. Če bi dali kakšno priporočilo v zvezi s pristopom k temu - predpostavljam, da je to retorično - ali se zgodi, da začnete zgodaj in to izvajate, ko razvijate, preden se razvijate? Ali pa se zgodi, da pretežno gradite, se premikate, nekaj zgradite in pozneje vstavite in profilirate? Sumim, da gre za zgodnjo zgodnjo in poskrbite, da bo koda čista vnaprej. 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 se morajo le lotiti stvari, tega ne počnejo, dokler ne naletijo na težavo z zmogljivostmi, ki je ne morejo rešiti dodajanje več procesorjev in pomnilnika v 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, ja, to lahko zaženete v oblaku.
Dez Blanchfield: Odličen, ker mislim, da gre nekako v 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, nekaj ljudi je tam, samo na kratko bom pripomnil: Bert, mislim, da je metafora, analogija, ki jo dajete uporabi črkovanja, odkrito. To je vredno bloga ali dveh, odkrito povedano, saj je to dober način za določitev konteksta tega, kar počnete, in kako dragoceno je, in kako bi morala biti res najboljša praksa za uporabo odpravljalnika redno, kajne? Stavim, da boste nekoč kimali, ko jo vržete ven, kajne?
Bert Scalzo: Vsekakor zato, ker jim rečem: "Zakaj preverim črkovanje svojih dokumentov? Nočem biti nerodni zaradi neumnih črkovalnih napak. "No, ne želijo biti nerodne zaradi neumnih napak pri kodiranju!
Eric Kavanagh: Prav. Da, resnično. No, ljudje, tu smo že uro in pet minut spali, tako da se zahvaljujem vsem vaši 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 bomo to dodali na seznam tukaj.
In s tem se bomo poslovili, ljudje. Še enkrat, odlično delo, Bert, zahvaljujoč se prijateljem iz IDERA. Z vami se bomo pogovarjali naslednjič, v resnici se bomo pogovarjali naslednji teden. Pazite! Adijo.
