Osoblje Techopedia, 15. ožujka 2017
Odlazak: Domaćin Eric Kavanagh razgovarao je o uklanjanju pogrešaka i profiliranja baze podataka s dr. Robin Bloor, Dez Blanchfield i IDERA-inog Berta Scalza.
Trenutno niste prijavljeni. Prijavite se ili prijavite da biste pogledali videozapis.
Eric Kavanagh: Dobro, dame i gospodo, u srijedu je 4:00 po istočnom vremenu, i to naravno znači.
Robin Bloor: Ne čujem te, Eric.
Eric Kavanagh: Bio sam tamo prije nekoliko dana, tako da nisi sam. Ali, tako da je danas tema zaista zanimljiva. To je vrsta stvari za koje želite biti sigurni da se događaju u pozadini u vašoj tvrtki, osim ako niste osoba koja to radi, u kojem slučaju želite biti sigurni da to radite pravilno. Jer govorimo o uklanjanju pogrešaka. Nitko ne voli bugove, nitko ne voli kad softver prestane raditi - ljudi se uznemiruju, korisnici postanu neprijateljski raspoloženi. To nije dobro. Dakle, razgovarat ćemo o "Brzom odgovoru: Otklanjanje pogrešaka baze podataka i profiliranje u spas."
Doista je spot o tvojem istinskom, nastrani me na Twitteru, @eric_kavanagh, naravno.
Ova godina je vruća. A uklanjanje pogrešaka bit će vruće, bez obzira na sve. To će zaista biti jedan od tih problema koji nikad neće nestati, bez obzira koliko dobro se snalazimo u tim stvarima, uvijek će biti problema, pa ključno je kako doći do mjesta gdje možete brzo riješiti te probleme? U idealnom slučaju imate sjajne programere, sjajno okruženje u kojem se previše ne kvari, ali kao što kaže stara izreka: „Nesreće se događaju u najboljim obiteljima“. Isto vrijedi i za organizacije. Dakle, ovo se događa, događa će se, pitanje je što će biti vaše rješenje za suočavanje s tim i rješavanje tih problema?
Čut ćemo se od dr. Robina Bloora, zatim našeg vlastitog Deza Blanchfielda odozdo, i naravno, našeg dobrog prijatelja Berta Scalza iz IDERA-e. A zapravo ću vam predati ključeve Robin Bloor, uzeti ih. Pod je tvoj.
Robin Bloor: OK. Ovo je zanimljiva tema. Mislio sam kako će Dez vjerojatno nastaviti o stvarnim tehnikama i ratnim pričama o uklanjanju pogrešaka i pomislio sam da ću napraviti pozadinsku raspravu kako bismo dobili potpuno zaokruženu sliku onoga što se događa. To sam radio dugo vremena, i nekada sam bio koder, tako je i gotovo sam bio u iskušenju s ovom prezentacijom da počnem debljati lirično o ideji otvorenog koda, ali mislio sam da ću to prepustiti nekome drugom.
Evo popisa poznatih bugova i većina njih ulazi na nečiji gornji popis, a u osnovi svi osim posljednja dva koštaju najmanje 100 milijuna dolara. Prvi je bio Mars klimatski orbiter, izgubio se u svemiru i to zbog problema s kodiranjem, gdje su ljudi zbunili metričke jedinice sa (smijeh) nogama i inčima. Ariane Five Flight 501 došlo je do neusklađenosti između motora koji je uključen i računala koja su trebala pokretati raketu kada je lansirana. Višestruki kvarovi na računalu, eksplozija rakete, vijesti iz naslova. Sovjetski plinovod 1982., rekao je da je najveća eksplozija u povijesti planeta; Nisam siguran je li. Rusi su ukrali neki automatizirani upravljački softver, a CIA je shvatila da će to učiniti i u njega je stavila bugove, a Sovjeti su to implementirali bez testiranja. Dakle, digao je cjevovod gore, pomislivši da je to zabavno.
Crv Morris bio je kodni eksperiment, koji je odjednom postao bijesan crv koji je obišao sve - očito je nanio štetu u vrijednosti od 100 milijuna dolara; to je procjena naravno. Intel je napravio poznatu grešku s matematičkim čipom - matematičkim uputama na Pentium čipu 1993. godine - koji je trebao koštati više od 100 milijuna dolara. Appleov program Maps je možda najgore i najstrašnije pokretanje svega što je Apple ikada napravio. Mislim, ljudi koji su ga pokušali koristiti, mislim da se netko vozio sa stazom 101 i otkrili da je Apple Map rekao da se nalaze usred zaljeva San Francisco. Tako su ljudi aplikaciju Apple Maps započeli nazivati iLost. - naš najduži prekid u 1990. - zanimljiv je s gledišta troškova takvog - AT&T je radio oko devet sati i koštao je oko 60 milijuna dolara u međugradskim pozivima.
A ja sam bio u osiguravajućem društvu u Velikoj Britaniji i baza podataka, implementirali su novu verziju baze podataka i ona je počela brisati podatke. I toga se dobro sjećam, jer sam nakon toga pozvan da sudjelujem u nekoj vrsti odabira baze podataka zbog toga. I bilo je vrlo zanimljivo da su uzeli novu verziju baze podataka i imali bateriju testova koju su napravili za nove verzije baze podataka koje su prošle sve testove. Pronašao je stvarno nejasan način brisanja podataka.
Dakle, svejedno, to je to. Mislio sam razgovarati o nepodudarnosti impedance i izdanom SQL-u. Zanimljivo je da relacijske baze podataka pohranjuju podatke u tablice i kodrere i imaju tendenciju da manipuliraju podacima u objektnim strukturama koje se stvarno ne preslikavaju na tablice. I zbog toga dobivate ono što se naziva neusklađenošću impedancije i netko se mora suočiti s tim na neki ili drugi način. Ali što se zapravo događa, jer jedan model, koder model i baza podataka drugi model nisu posebno usklađeni. Dobijate bugove koji se jednostavno ne bi dogodili da je industrija gradila stvari koje djeluju zajedno, a što mislim da je smiješno. Dakle, u osnovi kodira, kad dobijete hijerarhije, to mogu biti tipovi, mogu rezultirati skupovi, mogu biti slabe mogućnosti API-ja, može biti mnogo stvari koje samo izbacuju stvari u smislu interakcije s bazom podataka. Ali stvar koja mi je najviše, zaista zanimljiva; uvijek me iznenadilo što ste imali tu SQL barijeru koja je također svojevrsna impedancija na način na koji koderi i baza podataka djeluju jedan s drugim. Dakle, SQL ima prepoznavanje podataka, što je u redu i ima DML za odabir, projektiranje i pridruživanje, što je u redu. Time možete baciti puno mogućnosti u pogledu vađenja podataka iz baze podataka. Ali ima vrlo malo matematičkog jezika za obavljanje stvari. Ima malo toga i onoga, a ima vrlo malo stvari temeljenih na vremenu. Zbog toga je SQL nesavršen, ako želite, način prikupljanja podataka. Dakle, dečki iz baze ugradili su pohranjene postupke kako bi živjeli u bazi podataka, a razlog za pohranjene postupke koji žive tamo je taj što zapravo niste htjeli bacati podatke naprijed i nazad u program.
Neke su funkcionalnosti bile iznimno specifične za podatke, tako da nisu bile samo referentni integritet i kaskadno brišući i takve stvari, baza podataka se brinula za odjednom stavljanje funkcionalnosti u bazu podataka, što je značilo, naravno da funkcionalnost aplikacije se može podijeliti između kodatora i same baze podataka. A to je učinilo posao implementacije nekih vrsta funkcija zaista prilično teškim i samim tim više sklonim pogreškama. Dakle, to je jedna strana igre sa bazama podataka, jer to znači da ste, primjerice, imali puno implementacija, da sam bio uključen u relacijske baze podataka, stvarno ima jako puno koda koji sjedi u pohranjenim procedurama kojima se rukuje odvojeno od koda koji se nalazi u aplikacijama. A čini se da se mora dogoditi vrlo neobična stvar, trebala bi biti prilično pametna u obavljanju raznih stvari.
Mislio sam razgovarati i o performansama baze podataka jer se pogreške u performansama često smatraju pogreškama, ali u osnovi možete imati usko grlo u CPU-u, u memoriji, na disku, na mreži i možete imati problema s performansama zbog zaključavanja, Ideja bi bila da koder zaista ne treba brinuti o performansama i da bi baza podataka u stvari bila vrlo dobra. To bi trebalo biti dizajnirano tako da koder ne mora znati. Međutim, dobivate loš dizajn baze podataka, dobivate loše dizajniranje programa, dobivate konkurentnost u miješanju radnog opterećenja, što može dovesti i do problema s performansama. Dobivate uravnoteženje opterećenja, planirate kapacitet, rast podataka - što može uzrokovati da se baza podataka samo zaustavi ili uspori. Zanimljiva je stvar kada se baze podataka gotovo pune, usporavaju. I možete imati izdavanje slojeva podataka u smislu repliciranja i potrebe za kopiranjem i potrebom izrade sigurnosnih kopija i oporavka. U svakom slučaju, to je opći pregled.
Jedino što bih htio reći je da otklanjanje pogrešaka u bazama podataka može biti samo naporno i ne-trivijalno - i to kažem jer sam puno toga učinio - i često ćete otkriti da je to kao u svim situacijama u uklanjanju pogrešaka koje sam ikada doživljeno je, prva stvar koju ste ikada vidjeli je nered. I morate pokušati i preći iz nereda da biste utvrdili kako je do nereda došlo. A često kada gledate izdavanje baze podataka, sve što gledate su korumpirani podaci i mislite: "Kako se dovraga to dogodilo?"
U svakom slučaju, proslijedit ću Dezu koji će vjerojatno reći više riječi mudrosti nego što sam ispao. Ne znam kako ti preneti loptu, Dez.
Eric Kavanagh: Proći ću, stajati, čekati.
Automatizirani glas: linije sudionika su isključene.
Eric Kavanagh: U redu, stani na trenutak, daj mi Dez.
Dez Blanchfield: Hvala, Eric. Da, dr. Robin Bloor, uistinu ste najtačniji: ovo je tema, doživotna buba ako ćete se oprostiti s punicom, oprosti što se nisam mogao riješiti na tome. Nadam se da ćete tamo moći vidjeti moj prvi zaslon, na vrhu se ispričavam zbog problema sa veličinom fonta. Tema bugova je svakodnevno predavanje, u mnogim slučajevima iz mog iskustva. To je tako široka i široka tema, pa ću se usredotočiti na dva ključna područja, konkretno na koncept onoga što mi smatramo značajnom pogreškom, ali programski problem. Mislim da ovih dana uvođenje grešaka po sebi uglavnom dobiva integrirano razvojno okruženje, iako mogu biti dugotrajne pogreške. Ali često je to više slučaj kod profiliranja koda i moguće je napisati kôd koji funkcionira, to bi trebao biti problem. Dakle, moj naslovni slajd ovdje, ustvari sam imao kopiju ovoga u vrlo visokoj rezoluciji A3, ali nažalost je uništen u jednoj kući. Ali ovo je rukom pisana bilješka na programskom listu iz oko 1945. godine, gdje su, navodno, neki ljudi na Sveučilištu Harvard u SAD-u, svoju drugu konstrukciju stroja nazvali Mark II. Ispravljali su neki problem, zajedničkim jezikom, ali pokušavali su pronaći grešku, a ispostavilo se da se dogodilo nešto malo drugačije od hardvera i navodnog softverskog problema.
Dakle, urbani mit je da je oko 9. rujna 1945. godine tim na Sveučilištu Harvard razdvajao stroj, naišli na nešto što su nazivali "relej sedamdeset" - tih dana programiranje se odvijalo u fizičkom smislu, šivali ste šifru oko ploče i tako ste učinkovito programirali stroj - i otkrili su da ovaj relej broj sedamdeset ima nešto s tim u redu, a ispada da je stvarni izraz "bug" nastao jer je bukvalno bio moljac - navodno tamo bio je moljac zataknut između nekog komada bakrene žice koji je išao s jednog mjesta na drugo. A priča kaže da legendarna Grace Hopper za ovaj naslov, za moj naslov, "prvi stvarni slučaj pronalaska bube", navodi citat.
No, kao što je Robin istaknuo ranije u svom prvom dijapozitivu, koncept greške ide toliko daleko kao što možemo zamisliti da ljudi rade računajući, pojmove poput zakrpe. Izraz "zakrpa" nastao je od stvarnog dijela trake koji se lijepi preko rupe na kartici za bušenje. Ali cijela poanta ovoga je u tome što je izraz "uklanjanje pogrešaka" proizašao iz ovog koncepta pronalaska buga u fizičkom stroju. Otada se služimo tom terminologijom oko pokušaja rješavanja problema, bilo toliko koliko problema s kodiranjem u programu koji se ne sastavlja, nego kao program koji ne radi dobro. A posebno nije profilirano samo pronađite stvari poput beskonačnih petlji koje nigdje ne idu.
Ali imamo i scenarij, i pomislio sam da ću ubaciti par smiješnih slajdova prije nego što se pozabavim malo više detalja. Evo klasičnog crtanog filma, nazvanog XKCD na webu, a karikaturist ima prilično smiješne poglede na svijet. A ovo je o djetetu zvanom "Mali Bobby Stolovi" i navodno su njegovi roditelji tog dječaka prozvali Robertom "); DROP TABLE Učenici; - i to se zove, i vrsta: "Bok, ovo je škola vašeg sina koja ima problema s računarom", a roditelj odgovara, "O, dragi, je li nešto pokvario?", A učiteljica kaže: "Pa, na neki način ", i učiteljica pita, " jesi li stvarno imenovao svog sina Roberta "); DROP TABLE Studenti; -? ”A roditelj kaže, „ O da, mali Bobby Stolovi, zovemo ga. ”U svakom slučaju, oni nastavljaju da kažu da su sada izgubili studentske zapise o godini, nadam se da ste sretni. A odgovor je: "Pa, trebali biste očistiti i očistiti unose svoje baze podataka." I to mnogo puta koristim za razgovor o nekim problemima koje imamo u pronalaženju stvari u kodu, a to je to što koda često ne gleda na podatke također.
Još jedna smiješna, ne znam je li to stvarno ili ne - sumnjam da je to podvala - ali opet, to se također dotiče moje smiješne kosti. Netko mijenja registarske tablice na prednjem dijelu svog automobila, na sličnu izjavu koja uzrokuje pad podataka u brze kamere i tako dalje, koji snimaju registarske tablice automobila. Uvijek to smatram tako da sumnjam da je bilo koji programer predvidio pogodak i pokretanje svog koda stvarnim motornim vozilom, ali nikad to podcjenjivanje - moć bijesnog štrebera.
(Smijeh)
Ali pretpostavljam da me ovo vodi u moju ključnu točku, a to je da smo jednom davno mogli ispraviti pogrešku i profiliti kod kao obični smrtnici. Ali vrlo sam uvjeren da je to vrijeme prošlo i, anegdotski, u mom iskustvu, moje prvo - i to će me grozno ostariti, siguran sam; Robine, zbog mene se zbog toga zabavljaš - ali povijesno sam došao iz pozadine u dobi od 14 godina lutajući kraj grada i kucajući na vrata podatkovnog centra pod nazivom "Data Com" u Novom Zelandi i pitaju bih li mogao zaraditi džeparac u školi dolaskom kasnog autobusa kući, nekih 25 km putovanja dnevno, stavljanjem papira u pisače i vrpce u pogonske vrpce, i samo sam generalni administrator. I znatiželjno da su mi dali posao. Ali s vremenom sam se uspio upustiti u osoblje i pronaći programere i shvatio da volim kodiranje i prošao sam kroz proces izvršavanja skripti i skupnih poslova, što na kraju dana još uvijek kodira. Morate napisati skripte i skupne zadatke koji izgledaju kao mini programi, a zatim proći kroz cijeli proces sjedenja na 3270 terminalu za pisanje terminala.
U stvari, moje prvo iskustvo bilo je na teletapskom terminalu, koji je zapravo bio fizički pisač sa 132 stupca. U osnovi, mislite na vrlo staru pisaću mašinu s papirom koji se provlačio kroz nju, jer nisu imali CRT cijev. A kôd za uklanjanje pogrešaka na tom mjestu bio je ne-trivijalni problem, tako da ste skloni pisati sav kôd rukom, a zatim se ponašati kao daktilograf, radeći sve od sebe da ne dođete do grešaka, jer je izuzetno frustrirajuće to reći uređivač jednog retka otišao je do određenog retka, a zatim ispisao liniju i zatim je ponovo upisao. Ali jednom prilikom tako smo pisali kod i tako smo ispravljali greške, i u tome smo dobili vrlo, vrlo dobre. U stvari, to nas je prisililo na vrlo dobre tehnike programiranja, jer je bila prava gnjavaža da to popravimo. Ali putovanje je tada prošlo - i svi smo upoznati s ovim - prošlo je od iskustva 3270 terminala u mom svijetu, do Digitalne opreme VT220 na kojoj ste mogli vidjeti stvari na ekranu, ali opet, upravo ste radili istu stvar napravili ste na papirnoj vrpci neku vrstu tiskanog formata samo na CRT-u, ali ste je mogli lakše izbrisati i niste imali taj "dit dit dit dit" zvuk.
A onda znate, Wyse-ovi terminali - poput Wyse-a 150, vjerojatno moje najdraže sučelje s računalom ikad - a zatim osobno računalo i Mac, a danas moderni GUI-i i ID-ovi koji se temelje na webu. I niz programa kroz to, programiranje u jednom i alata za sklapanje i PILOT i Logo, Lisp i Fortran i Pascal i jezike koji mogu naterati ljude. Ali to su jezici koji su vas prisilili da napišete dobar kod; nisu te pustili da pobjegneš sa lošim postupcima. C, C ++, Java, Ruby, Python - i što više napredujemo u toj fazi programiranja, dobivamo više sličnih skriptu, približavamo se strukturiranom jeziku upita i jezicima poput PHP-a koji se zapravo koriste za pozivanje SQL-a. Poanta da vam kažem da sam, dolazeći iz svog podrijetla, bila sam samoučenica na mnogo načina, a oni koji su mi pomogli da učim, naučili su me vrlo dobrim programskim praksama i vrlo dobrim praksama oko dizajna i procesa kako biste bili sigurni da nisam uvesti buggy kod.
Način programiranja ovih dana, na primjer, Strukturni jezik upita, SQL, vrlo je moćan, jednostavan jezik upita. Ali pretvorili smo ga u programski jezik i zapravo ne vjerujem da je SQL ikada dizajniran kao moderan programski jezik, ali mi smo ga skovali da to postane. A to uvodi čitav niz problema, jer razmišljamo s dvije točke gledišta: sa kodiranja i stajališta DBA. Vrlo je lako doći i uvesti bugove za stvari poput samo loših programskih tehnika, lijenih napora kod pisanja koda, nedostatka iskustva, klasičnog peeea za kućne ljubimce kakvog imam, na primjer, SQL ljudi koji skaču na Google i traže nešto i pronalaze web stranicu koja je dobio primjer i napravio kopiju i lijepljenje postojećeg koda. A zatim kopiranje lošeg kodiranja, zloupotrebe i stavljanje u proizvodnju, jer se jednostavno događa da im da rezultate koje žele. Imate drugih izazova, na primjer, ovih dana svi žurimo prema tome, ono što nazivamo trkom do nule: pokušavamo sve učiniti tako jeftino i tako brzo, da imamo scenarij u kojem ne zapošljavamo niže -plaćeno osoblje. I ne mislim to na bezobziran način, ali mi ne zapošljavamo stručnjake za svaki mogući posao. Nekada davna povezanost s računalima bila je raketna znanost; bila je uključena u stvari koje su se gnjavile i bile vrlo glasne, ili su ulazile u svemir ili su inženjeri bili visoko kvalificirani muškarci i žene koji su diplomirali i imali strogu edukaciju koja ih je sprečavala da rade lude stvari.
Ovih dana ima puno ljudi koji se bave razvojem, dizajnom i bazom podataka koji nisu imali više godina iskustva, nisu nužno imali istu obuku ili podršku. I tako završite sa scenarijem samo tradicionalnog amatera nasuprot stručnjaka. Poznata je linija, zapravo se ne mogu sjetiti tko je stvorio citat, a redak glasi: "Ako mislite da je skupo angažirati stručnjaka za posao, pričekajte dok ne zaposlite nekoliko amatera koji će stvoriti problem i vi morate ga očistiti. "I tako SQL ima to pitanje, i to je vrlo, vrlo lako za naučiti, vrlo je jednostavan za korištenje. Ali, po mom mišljenju, to nije savršen programski jezik. Vrlo je lako učiniti stvari poput odabrane zvijezde odasvud i izvući sve to u programski jezik koji vam je ugodniji poput PHP-a i Ruby-a ili Pythona, i koristite programski jezik koji ste izvorno upoznati. manipulacija podacima, radije nego davanje složenijih upita u SQL-u. I to puno vidimo, i tada se ljudi pitaju zašto baza podataka radi sporo; to je zato što milijun ljudi pokušava kupiti kartu iz mrežnog sustava za prodaju karata, gdje to čini odabrana zvijezda iz bilo kojeg mjesta.
To je stvarno ekstremni primjer, ali vi od svega toga shvaćate. Dakle, da bih stvarno oduzeo točku kući, evo primjera koji ja puno nosim. Veliki sam ljubitelj matematike, volim teoriju kaosa, volim komplete Mandelbrot. S desne strane nalazi se predstava Mandelbrota, za koji sam siguran da smo svi dobro upoznati. A na lijevoj strani je dio SQL-a koji to zapravo i čini. Kad god ovo negdje stavim na ekran, čujem ovo "O, moj Bože, netko je napravio Mandelbrot seriju sa SQL-om, jesi li ozbiljan? To je suludo! “Pa, cijela svrha toga je ilustrirati ono što sam tamo samo iscrtao, i to je da, u stvari sada možete programirati gotovo sve u SQL-u; to je vrlo snažno razvijen, moćan, moderan programski jezik. Prvobitno je to bio jezik upita, dizajniran je samo da bi se dobili podaci. Dakle, sada imamo vrlo složene konstrukcije i pohranjene postupke, primjenjujemo metodologiju programiranja na jezik, tako da je vrlo lako zbog loše programske prakse, nedostatka iskustva, koda izrezati i zalijepiti, nisko plaćeno osoblje koje pokušava biti visoko plaćeno osoblje, ljudi se pretvaraju da znaju, ali moraju naučiti na poslu.
Čitav niz stvari kod kojih se profilira kod i ono što nazivamo uklanjanjem pogrešaka, što nije toliko pronalaženje grešaka koji zaustavljaju programe da rade, već greške koje samo štete sustavu i slabo strukturirani kod. Kad sada pogledate ovaj ekran i mislite da je to jednostavno, to je baš simpatično i mislite: "Jao, kakva sjajna grafika, volio bih to pokrenuti." Ali zamislite da to radi na nekom dijelu poslovne logike, Izgleda prilično uredno, ali govori matematički grafički prikazanu teoriju haosa, ali kad razmišljate za što bi se potencijalno moglo koristiti u nekoj poslovnoj logici, slika vrlo brzo dobiva sliku. A da to zaista ilustriram - i žao mi je što su boje obrnute, to bi trebalo biti crna pozadina i zeleni tekst da bi bio zeleni ekran, ali to još uvijek možete pročitati.
Krenuo sam i brzo pogledao primjer onoga što biste potencijalno mogli učiniti ako ste stvarno ludi i nemate nikakvog iskustva, a dolazili ste iz druge pozadine programiranja i primijenili simpatije C ++ na SQL, da stvarno ilustriram svoje stajalište, prije Predajem našem učenom gostu iz IDERA-e. Ovo je strukturirani upit koji je napisan poput C ++, ali je kodiran u SQL-u. I zapravo se izvršava, ali izvršava tijekom otprilike tri do pet minuta. I povlači naizgled jednu liniju podataka iz više baza podataka, više spojeva.
Opet, cijela poanta je u tome što ako nemate ispravne alate, ako nemate ispravne platforme i okruženja da biste mogli uhvatiti ove stvari, i one uđu u proizvodnju, a onda imate 100 000 ljudi udarajući na sistem svaki dan, sat ili minutu, vrlo brzo završite iskustvo u Černobilu u kojem se veliko željezo počne topiti i zakopati u srž planete, jer taj dio koda nikada ne smije ući u proizvodnju. Oprostite, vaši sustavi i vaši alati trebali bi to pokupiti prije nego što krene bilo gdje u blizini - čak i kroz testni postupak, čak i kroz UAT i integraciju sustava, taj dio koda treba pokupiti i istaknuti, a nekoga odvesti na stranu i govoreći: "Gledaj, to je zaista lijepa šifra, ali hajde da nabavimo DBA koji će vam pomoći da pravilno izgradite taj strukturirani upit, jer iskreno, to je samo gadno." A URL je tu, možete ga pogledati - naziva se najsloženiji SQL upit koji ste ikada napisali. Jer vjerujte mi, to se zapravo sastavlja, ali pokreće. A ako to izrežete i zalijepite i samo podsmjehnete bazu podataka, to je sasvim sigurno za gledanje; ako imate alate za gledanje baze podataka, samo pokušajte da se rastopite u periodu od tri do pet minuta, da nazovete ono što je jedan red teksta.
Dakle, da zaključim, imajući to na umu, cijela moja pozadina kodiranja naučila me je da ljudima možete dati pištolj, a ako nisu oprezni, oni će pucati sebi u stopalo; trik je u tome da im pokažete gdje je sigurnosni mehanizam. S pravim alatima i pravim softverom na dohvat ruke, nakon što izvršite kodiranje možete pregledati svoj kôd, možete pronaći probleme profiliranjem koda, možete pronaći učinkovito nenamjerne pogreške koje predstavljaju probleme s performansama i kao što sam rekao ranije, nekada, to možete učiniti gledajući zeleni ekran. Ne možete više; postoje stotine tisuća linija kodova, postoje deseci tisuća aplikacija, u nekim slučajevima postoje milijuni baza podataka, pa čak ni super ljudi to ne mogu više učiniti ručno. Doslovno vam je potreban pravi softver i pravi alati koji su vam na dohvat ruke, a treba vam i tim koji će koristiti te alate kako biste mogli vrlo brzo i brzo pronaći te probleme i riješiti ih, prije nego što dođete do točke, dok Dr. Istaknuo je Robin Bloor, stvari ili postaju katastrofalne, a stvari se razbuđuju, ili češće, jednostavno vas počinju koštati puno dolara, puno vremena i truda i uništavaju moral i stvari, kad ne mogu otkriti zašto stvari traju dugo trčati.
A s tim na umu, predat ću našem gostu i radujem se što ću čuti kako su riješili to pitanje. A pogotovo demonstracija za koju mislim da ćemo uskoro primiti. Eric, vratit ću se natrag.
Eric Kavanagh: Dobro, Bert, odnesi to.
Bert Scalzo: Dobro, hvala. Bert Scalzo ovdje iz IDERA-e, voditelj sam proizvoda za naše alate baza podataka. A ja ću razgovarati o otklanjanju pogrešaka. Mislim da je jedna od najvažnijih stvari koju je Robin rekao ranije - i vrlo je istina da je uklanjanje pogrešaka naporno i ne-trivijalno, a kad pređete na uklanjanje pogrešaka u bazu podataka, to je red veličine i još teži i ne-trivijalni - tako da bio je važan citat.
U REDU. Htio sam započeti s povijesti programiranja, jer puno puta vidim ljude koji ne rade ispravljanje pogrešaka, ne koriste ispravu za greške, samo programiraju na bilo kojem jeziku koji koriste i puno puta će mi reći, "Pa, te su ispravljači greške nove, a mi ih još nismo počeli koristiti." I tako, ono što ja radim je da im pokažem ovu vremensku shemu, neku vrstu pretpovijesti, starost, srednji vijek, to je vrsta recimo gdje smo bili u pogledu programskih jezika. A imali smo vrlo stare jezike, počevši od 1951. godine, s kôdom za montažu, a Lisp i FACT i COBOL. Zatim prelazimo u sljedeću skupinu, Pascals i Cs, a zatim slijedeću skupinu, C ++ s, i gledamo gdje je ta upitnica - ta je upitna tačno oko 1978. do možda 1980. Negdje u tom rasponu imali smo uređaji za uklanjanje pogrešaka dostupni su nam, i tako da kažemo: "Hej, ne koristim program za uklanjanje pogrešaka, jer to je jedna od tih novih stvari", onda ste sigurno počeli s programiranjem, znate u 1950-ima, jer je to jedini način kako biste se izvukli s tom tvrdnjom.
Druga stvar koja je smiješna u ovom grafikonu je Dez je upravo komentirao Grace Hopper, zapravo sam poznavao Grace, tako da je nekako smiješno. A onda je druga stvar kojoj sam se nasmijao, on je govorio o teletipovima i sjedim tamo i idem: „Čovječe, to je bio najveći skok u produktivnosti, kad smo prešli s karata na teletipe, to je bio najveći skok ikad. "Dakle, i programirao sam ovdje na svim jezicima, uključujući SNOBOL, za koji nitko prije nije čuo, bio je to CDC, Control Data Corporation, pa pretpostavljam da sam prestar za ovu industriju,
Dez Blanchfield: Htio sam reći da ste nas strašno ostarili.
Bert Scalzo: Da, kažem vam, osjećam se kao djed Simpson. Stoga pogledam ispravljanje pogrešaka i postoje različiti načini izvođenja ispravljanja. Moglo bi se razgovarati o onome što svi mi smatramo tradicionalnim ulaskom u program za uklanjanje pogrešaka i prelaskom koda. Ali također će ljudi instrumentirati svoj kod; tu ćete staviti kôde u svoj kôd i možda stvoriti izlaznu datoteku, datoteku s tragovima ili nešto slično, pa tako instrumentirate svoj kôd. Računao bih da je to otklanjanje grešaka, to je malo teže, način rada, ali računa se. Ali isto tako, imamo čuvenu izjavu o ispisu: vi gledate i ljudi zapravo stavljaju izjave o ispisu i zapravo sam vidio alat gdje - i to je alat baze podataka - gdje ako ne znate kako koristiti program za uklanjanje pogrešaka, pritisnete tipku i ona će za vas lijepiti izjave za ispis tijekom cijelog koda, a kad završite, pritisnete još jedan gumb i on ih ukloni. Jer tako mnogo ljudi ispravlja.
A razlog za uklanjanje pogrešaka je dvostruk: prije svega, moramo pronaći stvari koje naš kôd čine neefikasnim. Drugim riječima, obično to znači da postoji logična greška ili smo propustili poslovni zahtjev, ali ono što jest jest da li kôd nije učinkovit; ne radi ono što smo očekivali. Drugi put kad odlazimo i otklanjamo pogrešku, to je zbog učinkovitosti i to bi mogla biti logična pogreška, ali ono što je, jesam li ispravno postupio, jednostavno se ne vraća dovoljno brzo. E sad, mislim na to jer je profiler vjerojatno bolji za drugi scenarij, a mi ćemo razgovarati i o programima za uklanjanje pogrešaka i o profilima. Pored toga, tu je i ovaj koncept daljinskog uklanjanja pogrešaka; ovo je važno jer puno puta ako sjedite na svom osobnom računalu i koristite program za uklanjanje pogrešaka koji pogađa bazu podataka gdje se kôd zapravo izvodi u bazi podataka, zapravo radite ono što se naziva daljinsko uklanjanje pogrešaka. Možda to ne shvaćate, ali to se događa. I tada je vrlo često s ovim uređajima za uklanjanje pogrešaka da postoje prekidne točke, točke gledanja, ulazak i prijelaz i neke druge uobičajene stvari, koje ću im u trenu pokazati na snimku zaslona.
Sada, profiliranje: profiliranje možete raditi na nekoliko različitih načina. Neki će reći da se radno opterećenje hvata i reproducira tamo gdje sve bilježi, da se to računa i kao profiliranje. Moje je iskustvo bilo više i bolje ako se radi o uzorkovanju. Nema razloga za hvatanje svake pojedine izjave, jer se neke izjave mogu pokrenuti tako brzo da vas nije briga, ono što stvarno pokušavate vidjeti je dobro, a to su one koje se stalno iznova prikazuju, jer trče predugo. Dakle, ponekad profiliranje može značiti uzorkovanje, a ne pokretanje cijele stvari. Obično ćete dobiti nekakav izlaz koji možete koristiti, a koji bi sada mogao biti vizualan unutar razvojnog okruženja IDE-a gdje bi vam mogao dati sličan histogram performansi različitih linija koda, ali mogao bi i dalje biti da stvara datoteku u tragovima.
Profilrsi su se prvi put pojavili 1979. Dakle, i oni su dugo vremena ovdje. Izvrsno za pronalaženje potrošnje resursa ili problema sa performansama, drugim riječima, to je stvar učinkovitosti. Generalno gledano, odvojen je i različit od programa za uklanjanje pogrešaka, mada sam radio s programima za uklanjanje pogrešaka koji rade i jedno i drugo istovremeno. I dok su profili za dva alata zanimljiviji, ako smatram da nema dovoljno problema za uklanjanje pogrešaka, onda definitivno nema dovoljno profila ljudi, jer čini se da će se jedan od deset ispravljača. I to je sramota, jer profiliranje doista može napraviti ogromnu razliku. Kao što smo već govorili, jezici baza podataka, kao što smo ranije govorili, imate SQL - i mi smo nekako prisilno zaokrenuli zaokret u kvadratnu rupu i prisilili ga da postane programski jezik - i Oracle. To je PL / SQL - to je proceduralni jezik SQL - i SQL Server, to je Transact-SQL, to je SQL-99, to je SQL / PSM - jer, mislim, to je postupak pohranjen modul. Postgres mu daje drugo ime, DB2 još jedno ime, Informix, ali poenta je u tome što su svi prisilili konstrukte tipa 3GL; drugim riječima, FOR petlje, u deklaraciji varijable i sve ostale stvari koje su strane SQL-u sada su dio SQL-a na tim jezicima. I tako, trebate biti u mogućnosti ukloniti program za uklanjanje pogrešaka u PL / SQL ili Transact-SQL baš kao što bi radili program Visual Basic.
Sada, objekti baze podataka, ovo je važno jer će ljudi reći: "Pa, koje stvari moram ukloniti u program uklanjanja pogrešaka u bazu podataka?", A odgovor je: dobro, što god možete pohraniti u bazu podataka kao kod - ako radim T-SQL ili PL / SQL - i spremam predmete u bazu podataka, to je vjerojatno pohranjena procedura ili pohranjena funkcija. No postoje i okidači: okidač je poput pohranjene procedure, ali aktivira se na neki događaj. Sada će neki ljudi u svoje okidače staviti jednu liniju koda i nazvati pohranjenu proceduru tako da zadrže sve svoje pohranjene kodove i postupke, ali to je isti koncept: ipak je okidač mogao biti ono što pokreće cijelu stvar. I tada kao Oracle imaju nešto što se zove paket, što je nalik knjižnici ako hoćeš. Stavite 50 ili 100 pohranjenih postupaka u jedno grupiranje, koje se zove paket, pa je to nekako poput knjižnice. Dakle, evo uklanjanja pogrešaka na stari način; ovo je zapravo alat koji će se zapravo uključiti i zabiti sve ove izjave o pogreškama u vašem kodu. Dakle, svugdje gdje vidite blok za uklanjanje pogrešaka, ne uklanjajte, pokretanje automatskog uklanjanja pogrešaka i trag, sve ih je zaglavio neki alat. A linije izvan toga, što je manjina koda, dobro, to je metoda ručnog uklanjanja pogrešaka.
A razlog zašto ovo iznesem je, ako pokušavate to učiniti ručno, zapravo ćete unijeti više koda za uklanjanje pogrešaka koji ćete staviti u sve ove ispise iskaza nego što ih imate. Iako ovo može uspjeti, i iako je bolje nego ništa, ovo je vrlo težak način uklanjanja pogrešaka, posebno jer što ako je potrebno 10 sati da se ova stvar pokrene, a gdje je problem, u redu je tri? Da radim interaktivni program za uklanjanje pogrešaka, znao bih u liniji tri - pet minuta - hej, ovdje postoji problem, mogu prestati. Ali s ovim, moram pričekati da se pokrene, sve do završetka i tada moram pogledati datoteku s tragovima koja vjerojatno ima sve te izjave o ispisu, i pokušati pronaći iglu u plast. Opet, ovo je bolje nego ništa, ali to ne bi bio najbolji način rada. Eto, to bi izgledala datoteka koja dolazi iz prethodnog slajda; drugim riječima, pokrenuo sam program, a u ovoj datoteci s tragovima ima gomila ispisanih izjava i možda ću, ali možda neću moći pregledati to i pronaći ono što trebam pronaći. Dakle, opet, nisam baš siguran da bi to želio raditi.
Sada, interaktivni program za uklanjanje pogrešaka - i ako ste za pisanje programa ili Eclipse koristili nešto poput Visual Studio, imali ste ispravljače i koristili ih sa svojim drugim jezicima - jednostavno niste razmišljali o tome da ih ovdje koristite sa svojom bazom podataka. A tu su i alati, poput našeg DB Artisan-a i našeg Rapid SQL-a, ovdje je Rapid SQL, koji ima ispravljanje pogrešaka, a na lijevoj strani možete vidjeti pohranjenu proceduru koja se zove „provjera duplikata“. U osnovi, samo ću ići pogledati i vidjeti imam li u tablici više redova s istim naslovom filma. Dakle, baza podataka je za filmove. A mogli ste vidjeti s desne strane, u gornjoj trećini, u sredini imam svoj izvorni kod, imam ono što se naziva varijablama mog sata i ladicama za slanje poziva, a zatim pri dnu ' imam neke izlazne poruke. I ono što je ovdje važno jest, ako pogledate preko te prve crvene strelice, ako mišem preko varijable, zapravo mogu vidjeti koja je vrijednost u toj varijabli u tom trenutku dok prolazim kroz kod. To je zaista korisno i tada mogu kodati jedan red po jedan kôd kroz kôd, ne moram reći izvršiti, mogao bih reći korak redak, pogledati što se dogodilo, koraknuti drugu liniju, da vidim što se dogodilo, i to radim u bazi podataka. Iako sjedim na Rapid SQL-u na računalu i moja je baza podataka u oblaku, još uvijek mogu to udaljeno uklanjanje pogrešaka vidjeti i kontrolirati odavde, te raditi ispravljanje pogrešaka kao što bih to učinio s bilo kojim drugim jezikom.
Sljedeća tamo strelica - možete vidjeti malu strelicu usmjerenu udesno, prema tom DBMS izlazu, tu je trenutno moj pokazivač - drugim riječima, zakoračio sam i tu sam na Trenutak. Dakle, ako kažem „korak ponovo“, preći ću na sljedeći redak. Sada odmah ispod toga vidjet ćete crvenu točku. Pa, to je točka prijeloma, koja kaže: "Hej, ne želim prijeći preko ovih linija." Ako samo želim preskočiti sve i doći do mjesta gdje je crvena točka, mogu pritisnuti gumb za pokretanje i ona će se pokrenuti odavde ili do kraja ili do točke prekida, ako postoje postavljene prijelomne točke, i onda će se zaustaviti i pustiti me da ponovno napravim korak. A razlog što je sve ovo važno i moćno je taj što se, kad radim sve ovo, promijeni ono što se događa u sredini, pa čak i na dnu - ali što je najvažnije u sredini - i vidim vrijednosti svojih varijabli, Znate svoj trag stog poziva, i sve te informacije se prikazuju tamo dok prelazim kod, tako da zapravo mogu vidjeti i osjetiti i shvatiti što se događa i kako zapravo kôd radeći u vrijeme izvršenja. I obično mogu naći problem, ako postoji ili ako sam dovoljno dobar da ga uhvatim.
OK, sada ću razgovarati o profileru, a u ovom slučaju ovo je profil koji vidim kroz program za uklanjanje pogrešaka. Sjećate se, rekao sam da su ponekad odvojene, a ponekad mogu biti zajedno? U ovom slučaju, i opet, nalazim se u Rapid SQL-u i vidim da na lijevoj strani postoji margina pored brojeva redaka. I što je to, to je broj sekundi ili mikrosekundi potreban za izvršavanje svakog retka koda, i to jasno vidim, svo svoje vrijeme provodim u ovoj petlji FOR, gdje biram sve iz tablice, I tako, ono što se događa unutar te petlje za FOR vjerojatno je nešto što moram pogledati, i ako budem mogao poboljšati, isplatit će dividendu. Neću postići nikakva poboljšanja radeći na onim linijama koje imaju 0.90 ili 0.86; tamo se ne provodi puno vremena. U ovom slučaju i opet sam u Rapid SQL-u, vidiš kako mogu raditi profiliranje pomiješano s otklanjanjem pogrešaka. Ono što je lijepo je to što vam Rapid SQL omogućava i drugi način. Brzi SQL omogućava vam da kažete: "Znate što? Ne želim biti u programu za uklanjanje pogrešaka, samo želim pokrenuti ovo, a zatim želim grafički ili vizualno pogledati istu vrstu informacija. "
I vidite da više nisam u programu za uklanjanje pogrešaka i on pokreće program, a nakon izvršenja, daje mi grafikone da mi ispričaju stvari, tako da vidim da imam jednu izjavu koja izgleda kao da se zauzima većinu grafikona kaše i ako pogledam, vidim na toj rešetki prema dnu, redak 23, opet je petlja FOR: on zauzima najviše vremena, on je ustvari taj tamnocrveni žvakanje svih dijagrama pita. Dakle, ovo je još jedan način profiliranja. Slučajno nazivamo tog „Analitičara koda“ u našem alatu. Ali u osnovi je to samo profil koji je odvojen od ispravljača. Neki vole to raditi na prvi način, neki vole da to rade na drugi način.
Zašto radimo uklanjanje pogrešaka i profiliranje? Nije to zato što želimo napisati najveći svjetski kôd i dobiti povećanu plaću - to bi mogao biti naš razlog, ali to zapravo nije razlog zbog kojeg to radite - obećali ste poslu da ćete napraviti nešto ispravno, da će vaš program biti učinkovit. Za to ćete koristiti program za uklanjanje pogrešaka. Osim toga, poslovni krajnji korisnici; nisu baš strpljivi: žele rezultate čak i prije nego što pritisnu tipku. Trebali bismo čitati njihove misli i učiniti sve odmah. Drugim riječima, mora biti učinkovit. I tako, za to bismo koristili profil. Sada, bez ovih alata, stvarno vjerujem da ste taj momak u poslovnom odijelu s lukom i strijelom, a pucate u metu i vežete oči. Jer kako ćete pronaći kako se program izvodi samo gledanjem statičkog koda i kako ćete shvatiti koji je redak gdje bi stvarno proveo najviše vremena u izvršenju, opet, samo gledajući statički kod? Pregled koda neke od ovih stvari može ili ne mora prikazati, ali nema garancije da će ih pregled svih kodova pronaći. Pomoću programa za uklanjanje pogrešaka i profilatora trebali biste moći pronaći sve te bugove.
OK, napravit ću stvarno brz demo ovdje. Nije mi namjera gurati proizvod, samo bih vam želio pokazati kako izgleda program za uklanjanje pogrešaka, jer puno puta će ljudi reći: „Nikada prije nisam vidio nijednog takvog.“ I prilično izgleda na zaslonskim slajdovima, ali kako izgleda kad je u pokretu? Dakle, ovdje na svom ekranu trčim naš DB Artisan proizvod; tamo imamo i program za uklanjanje pogrešaka. DB Artisan znači više za DBA, Rapid SQL je više za programere, ali vidio sam programere koji koriste DB Artisan i vidio sam DBA koji koriste Rapid. Dakle, nemojte se zaokupiti proizvodom. I ovdje imam mogućnost raditi ispravljanje pogrešaka, ali prije nego što pokrenem program za ispravljanje pogrešaka, izdvojit ću ovaj kôd kako biste vidjeli kako izgleda kôd prije nego što ga počnem pokretati. Dakle, ovdje je točno isti kod koji je bio na snimci zaslona, ovo je moja provjera za duplikate. I želim to ispraviti, pa pritisnem ispravku. I sada treba trenutak i kažete: "Pa, zašto vam treba trenutak?" Sjetite se daljinskog uklanjanja pogrešaka: uklanjanje pogrešaka se zapravo događa na mom poslužitelju baze podataka, a ne na mom računalu. Dakle, tamo je trebalo preći preko i stvoriti sesiju, stvoriti stvar udaljenog uklanjanja pogrešaka, zakačiti moju sesiju na tu sesiju daljinskog uklanjanja pogrešaka i postaviti komunikacijski kanal.
Dakle, evo moje strelice, gore je na vrhu, u prvom redu, tu sam kod. A ako pritisnem tamo treću ikonu, što je korak u, vidjet ćete da se strelica upravo pomaknula, a ako nastavim pritiskati, vidjet ćete da se nastavlja pomicati. Ako bih htio skroz skrenuti do ove petlje ZA, jer znam da je tu problem, mogu postaviti točku prekida. Mislila sam da sam to postavila. O, pucaj, jedan od mojih tipki za snimanje zaslona preslikao je na isti ključ kao i za ispravljanje pogrešaka, to je ono što uzrokuje zbrku. U redu, pa sam ručno postavio tamo prijelomnu točku, tako da sada umjesto da napravim korak, korak, korak, korak dok ne stignem tamo, zapravo mogu samo reći: „Naprijed i pokreni ovu stvar“, i to će prestati. Primijetite da me je prebacio sve do točke gdje je prekid, pa sam sada u kontekstu pokretanja ove petlje, mogu vidjeti na što su postavljene sve moje varijable, što nije iznenađenje, jer sam ih sve pokrenuo. do nule. A sada mogu zakoračiti u ovu petlju i početi gledati što se događa unutar ove petlje.
Dakle, sada će se raditi prebrojavanje mojih stana i prelazim mišem preko tog tipa i pogledam, dva, dva su veća od jednog, pa će vjerojatno napraviti sljedeći dio ovog koda. Drugim riječima, nešto je pronašlo. Samo idem naprijed i pustim da trči. Ne želim sve ovdje prolaziti; Ono što vam želim pokazati je kada se napravi program za uklanjanje pogrešaka, on se završava kao u normalnom programu. Postavio sam prijelomnu točku, pa kad sam rekao trčanje, jednostavno se vratio na sljedeću prijelomnu točku. Pustim ga da radi do kraja, jer ono što želim je da vidite da program za uklanjanje pogrešaka ne mijenja ponašanje programa: kad se završi u radu, trebao bih dobiti potpuno iste rezultate da sam ga pokrenuo ne unutar programa za uklanjanje pogrešaka.
A s tim ću prekinuti demo i vratiti se jer želimo osigurati vremena za pitanja i odgovore. I tako, otvorit ću ga za pitanja i odgovore.
Eric Kavanagh: Dobro, Robin, možda imaš neko pitanje, a onda par iz Deza?
Robin Bloor: Da, naravno, smatram da je to fascinantno, naravno. Radio sam s ovakvim stvarima, ali nikad nisam radio s takvim nečim u bazi podataka. Možete li mi dati neku ideju za što ljudi koriste profil? Jer je to, gledaju li oni, jer pretpostavljam da jesu - gledaju na probleme performansi, hoće li vam to pomoći da razlikujete kada bazi podataka treba vremena i kad kôdu treba vremena?
Bert Scalzo: Znate, to je fantastično pitanje. Recimo da radim u Visual Basic-u, a unutar svog Visual Basic nazvat ću Transact-SQL ili PL / SQL. Dopustite mi da napravim PL / SQL, jer se Oracle ne igra uvijek dobro s Microsoftovim alatima. Možda profiliram svoj Visual Basic kôd, a tamošnji profil može reći: "Hej, nazvao sam taj pohranjeni postupak i trajao je predugo." Ali tada mogu ući u pohranjeni postupak i mogu napraviti profil baze podataka na pohranjenom Postupak i recite: "U redu, od 100 izjava koje su ovdje, evo pet koji su uzrokovali problem." I tako, možda ćete morati napraviti tim s oznakama, gdje morate koristiti više profila.
Ideja je da ako vam se ikad kaže da je problem s performansama u vašoj bazi podataka, profil baze podataka može vam pomoći pronaći iglu u sijenu na kojoj su izjave zapravo one s kojima imate problem. Kažem vam još jednu stvar koja se pojavila sa profiliranjem: ako imate komad koda koji se zove milijun puta, ali to traje samo mikrosekundu svaki od milion puta, ali zove se milijun puta, što bi pokazao profiler, ta stvar je trajala tokom mnogih jedinica. Iako je kod vrlo učinkovit, možda ćete izgledati i reći: "Ooh, upućujemo ovaj poziv na ovaj dio koda previše često. Možda bismo ga trebali zvati samo toliko često, a ne svaki put kad obrađujemo zapis, "ili tako nešto. Tako da zapravo možete pronaći gdje postoji učinkovit kod koji se jednostavno prečesto zove, a to je zapravo problem performansi.
Robin Bloor: Da, to je divno. Nikad to nisam učinio. Vidite, kad sam imao problema s bazom podataka, bilo je kao da bih se na ovaj ili onaj način bavio bazom podataka ili se bavio kodom; Nikada se ne bih mogao s njima istovremeno nositi. Ali tamo, opet, nisam učinio … Nikada zapravo nisam bio uključen u izradu aplikacija u kojima smo imali pohranjene procedure, pa pretpostavljam da nikada nisam naišao na probleme koji su me dirali, ideja da vi Podijelio bih kod između baze podataka i programa. Ali tako, učinite sve - pretpostavljam da će odgovor biti da, ali ovo je dio aktivnosti razvojnog tima, kada na jedan ili drugi način pokušavate popraviti nešto što je slomljeno ili možda pokušavate donijeti novo aplikacija zajedno. No, je li to usklađeno sa svim ostalim komponentama koje bih očekivao u okolini? Mogu li očekivati da bih to mogao snimiti zajedno sa svim svojim testnim paketima i sa svim tim ostalim stvarima koje bih radio i sa svojim stvarima u vezi s upravljanjem projektima, kako je to sve zajedno?
Bert Scalzo: Da, to može postati dio bilo kojeg strukturiranog procesa u koji ćete poduzeti svoje programiranje ili razvojne napore. I smiješno je, prošli tjedan sam imao klijenta koji je izrađivao web aplikaciju, a njihova je baza podataka, povijesno, bila mala, pa činjenica da nisu baš bili dobri programeri ih nikada nije naškodila. Pa, njihova je baza podataka tijekom godina rasla, a sada je potrebno 20 sekundi na web stranici, između vremena kada kažete: "Prijavite se i dajte mi neke podatke da vidim" i kada se zaslon zapravo pojavi, i sada je to problem performansi. I znali su da problem nije u bilo kojoj njihovoj Javi ili nekom drugom mjestu. Ali imali su tisuće pohranjenih postupaka i zato su morali početi profilirati pohranjene postupke kako bi otkrili zašto je ovoj web stranici potrebno 20 sekundi da bi se pojavilo? I zapravo smo ustanovili kako se u jednoj od njihovih odabranih izjava pridružili kartezijanski ljudi i nisu to znali.
Robin Bloor: Jao.
Bert Scalzo: Ali netko mi je jednom rekao: "Pa kako su mogli kartezijanski ljudi pridružiti, a ne znati?", A ovo će zvučati zaista grozno; ponekad programer koji nije baš ugodan SQL-u napravi nešto poput pridruživanja kartezijancu, ali tada će mi vratiti samo prvi zapis, tako da znam da imam nešto, a samo mi treba prvi. I tako, oni ne shvaćaju da su samo vratili milijardu zapisa ili pregledaju milijardu zapisa, jer su dobili ono što ih je zanimalo.
Robin Bloor: Wow, znam, tako se zove - eto, o tome se Dez išao u pogledu ljudi koji nisu baš tako vješti koliko bi trebali biti, znate. Ako ste programer, trebali biste znati kakve su implikacije izdavanja bilo koje naredbe. Mislim, stvarno, nema opravdanja za tu razinu gluposti. Pretpostavljam i da ste, na ovaj ili onaj način, samo jezični agnostik u vezi s tim, jer se sve to fokusira na strani baze podataka. Jesam li u pravu? Je li to isto, bez obzira što koristite sa kodirajuće strane?
Bert Scalzo: Apsolutno to možete učiniti u Fortranu ili C ili C ++. U stvari, na nekim Unixima čak možete to učiniti i za njihove skriptne jezike; zapravo pružaju iste alate. I onda se želim vratiti sekundu za ono što ste rekli bez izgovora. Ostavit ću programere na jednom odmoru, jer ne volim baciti programere ispod autobusa. Ali problem je zapravo akademsko okruženje, jer kad idete učiti kako biti programer, podučavate se da zapisujete istovremeno. Niste podučeni skupoj razmišljanju, a to je ono što Strukturirani jezik upita ili SQL radi s skupovima; zato imamo uniju, presjek i minus operatora. A ponekad je vrlo teško da osoba koja nikad nije razmišljala u vezi s setovima odustane, pusti se u obradu i snima s vremenom obrađuje.
Robin Bloor: Da, s tobom sam. Mislim, razumijem, to je pitanje obrazovanja; Mislim da je to potpuno pitanje obrazovanja, mislim da je prirodno da programeri razmišljaju proceduralno. A SQL nije proceduralni, već je deklarativan. Vi zapravo samo kažete: "Ovo je ono što želim i nije me briga kako vi to radite", znate? Dok s programskim jezicima često zasučete rukave i upadate u detalje čak i upravljanja brojevima, dok radite petlju. Predat ću se:
Bert Scalzo: Ne. U redu, nastavi.
Da, htio sam reći da ste naveli još jedan primjer da će profiler dobro uhvatiti, kakav se događa s ovom zapisom u isto vrijeme. Ponekad programer koji je dobar u logici snimanja, ne može smisliti kako napraviti SQL program. Pa, recimo da pravi dvije petlje za FOR i u osnovi čini spajanje, ali to radi na strani klijenta. Dakle, on postiže isti efekt kao pridruživanje, ali to radi sam, a profil bi to uhvatio, jer biste vjerovatno potrošili više vremena na ručno spajanje nego na dopuštanju da poslužitelj baze podataka to učini za vas.
Robin Bloor: Da, to bi bila katastrofa. Mislim, samo bi se mlatili. Bacanje je uvijek loše.
U svakom slučaju, proslijedit ću Dez; Siguran sam da ima zanimljiva pitanja.
Dez Blanchfield: Hvala vam, da, znam. Pridružit ću vam se ne bacajući programere ispod autobusa. Mislim, proveo sam previše godina u životu i sam bio koder, na svim razinama, znate, bilo da je to kao što ste rekli, sjedeći u naredbenoj liniji Unix-ovog stroja, a u nekim slučajevima sam čak bio uključen u nekoliko različitih portova Unixa s jedne hardverske platforme na drugu. I možete zamisliti izazove koje smo tamo imali. Ali stvarnost je takva da je kartica za izlazak iz zatvora za svaki koder i pisac na svijetu. Raketna je znanost, prilično doslovno, svaki put pisati stvarno usko, raketna znanost. A poznate priče ljudi poput Dennisa Ritchieja i Briana Kernahana koji samostalno rade na nekim dijelovima koda, a zatim prelaze na chat pregled čavrljanja uz kavu i otkriju da su napisali točno isti dio koda, u točno istom programu, na potpuno isti način. I to su učinili u C. Ali, ta puristička razina programiranja postoji vrlo rijetko.
Činjenica je da na dnevnoj bazi ima samo 24 sata dnevno, sedam dana u tjednu, a mi jednostavno moramo riješiti stvari. Pa, kad su u pitanju ne samo tradicionalni programeri, DBA-i, i koderi, i scripteri, i sysadmin, i mrežni administratori, i sigurnosno osoblje, i sve do ovih dana na strani podataka o građanima; Čujemo, svi samo žele raditi svoj posao. I zato mislim da je odvratno od svega što sam volio vaš demo i volio sam odlazak koji ste nam ostavili tamo, prije samo trenutak, razgovarajući s Robinom o činjenici da to ima osobito - možda ne toliko niša - ali široki prostor koji se odnosi na popravljanje koda, SQL-a i baza podataka. Ali bio sam jako uzbuđen kad sam čuo da možete reći kako biste ga mogli nabaciti na skriptu školjke i pronaći neka pitanja, jer znate, u današnjem danu i vremenu mi uvijek radimo na najnižu cijenu svega.
Razlog zašto negdje možete kupiti majicu od 6 dolara jest taj što je netko izgradio dovoljno jeftin sustav da zapravo proizvodi i isporučuje i logistički isporučuje, prodaje i prodaje na malo i uzima putem interneta plaćanje da biste dobili tu majicu od 6 dolara. A to se ne događa ako vam se ljudi plaćaju 400 000 dolara godišnje da pišu kod na savršen način; to je samo cijeli razvoj. Dakle, u tom trenutku, pretpostavljam da bi jedno od pitanja koje bih vas zaista volio samo da nam date još malo uvida, je kakva je širina i doseg tipa ljudi koje trenutno vidite koji koriste ove alate za profil kôd i tražite poteškoće s performansama? U početku, povijesno, odakle dolaze? Jesu li to bile velike inženjerske kuće? I onda, idete li prema naprijed, je li to točno, jesam li korektan misleći da sve više i više tvrtki provodi ovaj alat ili ove alate kako bi pokušali pomoći koderima, za koje znaju koji samo rade stvari kako bi dovršili posao. i izvaditi je kroz vrata? A ponekad nam treba karta za izlazak iz zatvora? Da li sam u pravu kad razmišljam da smo povijesno imali više inženjerskog fokusa i razvoja? To sada postižemo manje, kao što je Robin rekao, akademski pristup, a sad je samouk, ili izrezati i zalijepiti kod, ili jednostavno graditi stvari? I podudara li se s onom vrstom ljudi koji sada uzimaju proizvod?
Bert Scalzo: Da, točno. I dat ću vam vrlo konkretan primjer, mi samo želimo obaviti posao, jer poslovni ljudi ne žele savršenstvo. To je poput računalne igre u šahu: šahovska igra ne traži savršen odgovor; traži odgovor koji je dovoljno dobar u razumnom roku, tako to i programiramo. Ali ono što sada pronalazim jest da većina ljudi umjesto da kaže da žele profilare kao dio testiranja uređaja - što bih i učinila, jer to ne doživljavam kao gubljenje vremena - što se događa sada kada se to radi kasnije, ponekad za vrijeme integracijskog testiranja ili testiranja otpornosti na stres, ako imamo sreće. Ali većinom je to dio eskalacije, gdje je nešto propalo u proizvodnji, neko je vrijeme trajalo, možda je radilo i godinama, a sada ne radi dobro, a sada ćemo to objasniti. I čini se da je to sada češći scenarij.
Dez Blanchfield: Da, i mislim da je izraz "tehnički dug" vjerojatno jedan više nego što ste upoznati; Znam Robina i sigurno jesam. Mislim da je za mene koncept tehničkog duga ovih dana, posebno u okretnim pristupima razvoju i izgradnji sustava, vrlo stvarna stvar, i to zapravo i vodimo računa u projektima. Znam, mislim, imamo vlastite projekte poput Media Lens-a i drugih, gdje se svakodnevno događamo kodiranje i razne stvari u grupi Bloor. I kad god nešto gradimo, mi nekako gledamo, gledam to i uvijek gledam s gledišta onoga što će me koštati da to ispravim sada, nasuprot tome mogu li to jednostavno može i izvaditi ga, a onda gledati i vidjeti hoće li se ta stvar pokvariti. I naslijediti ovaj tehnički dug za koji znam da ću se morati kasnije kružiti i popraviti.
I mislim, to sam učinio u posljednjih sedam dana: napisao sam nekoliko alata i skripti, napisao sam par komada jezika Pythona i prebacio ga na Mongo stražnji kraj, čineći siguran da je lijep, čist i siguran, ali jednostavno dobiva upit koji mi je potreban, znajući da mi treba ta funkcija da radim, da dođem do veće slagalice; tu je moja prava bol. I tako ste preuzeli ovaj tehnički dug, i mislim da to sada nije samo povremena stvar, mislim da je to dio DNK koji se razvija. Ljudi samo - ne bezobrazno - samo prihvaćaju da je tehnički dug uobičajen način izdavanja i jednostavno ga moraju pokrenuti. Tamo snosite tehnički dug. I mislim da je sjajna stvar u onome što ste nam pokazali na demonstraciji to što možete doslovno profilisati i gledati koliko vremena nešto treba proći. I to mi je vjerojatno jedna od najdražih stvari. Mislim, zapravo sam ugradio alate za profiliranje - koristili smo alate u Sed i Lexu i Orcu da bismo pokrenuli naš kôd i vidjeli gdje su petlje, prije nego što je takav alat dostupan - i kad ste napravili kod za pokretanje i Pregledajte vlastiti kôd, postaje vam jako dobro što ne morate pregledavati vlastiti kôd. Ali to sada nije slučaj. Imajući to u vidu, postoji li određeni tržišni segment koji to uzima više nego bilo koji drugi? Vidjeti kao masa -
Bert Scalzo: O da, imam - napravit ću analogiju za tebe i pokazati vam da to rade ne-programeri stalno. "Jer ako ikad predajem klasu za ispravljanje grešaka i profiliranje ili seansu, pitati ću ljude:" OK, koliko ljudi ovdje ulazi u Microsoft Word i namjerno nikada ne koristi provjeru pravopisa? "I nitko ne diže ruku, jer za pisanje dokumenata svi znamo da možemo napraviti engleske pogreške i tako svi koriste provjeru pravopisa. I rekao sam: "Pa, kako to da kad u IDE pišete tekst poput Visual Basic, ne koristite program za uklanjanje pogrešaka? To je ista stvar, to je poput provjere pravopisa. "
Dez Blanchfield: Da, zapravo, to je sjajna analogija. Nisam baš razmišljao o tome, moram priznati da zapravo radim nešto slično s nekoliko alata koji koristim. Zapravo, jedan, ODF, moj omiljeni kod Eclipse-a je samo izrezati i zalijepiti kod i krenuti u potragu za stvarima koje će se odmah istaknuti i shvativši da sam napisao pogrešku u pozivu na neki klas. Ali, ali sada je zanimljivo sa ovakvim alatom to možete učiniti u stvarnom vremenu, za razliku od toga da se vratite i pregledate kasnije, što je nekako lijepo kad biste ga uhvatili unaprijed. Ali da, to je sjajna analogija samo stavljanja teksta u program za obradu teksta, jer je to zanimljiv poziv za buđenje, samo shvatite da ste napravili neke pogreške pri upisu ili čak gramatičku pogrešku, zar ne?
Bert Scalzo: Točno.
Dez Blanchfield: Dakle, vidite li više poteškoća od, valjda, mislim, posljednjeg pitanja od mene, prije nego što odem na pitanja i pitanja, možda, za naše polaznike. Ako biste htjeli dati neku vrstu preporuke oko pristupa tome - pretpostavljam da je to retoričko - je li slučaj da rano uđete i implementirate to dok razvijate, prije nego što se razvijate? Ili je slučaj da uglavnom gradite, krećete se, nešto napravite, a zatim uđite i profilirate kasnije? Pretpostavljam da je slučaj ranije doći i provjeriti je li kôd čist unaprijed. Ili je slučaj da bi trebali razmišljati o ovom dijelu svog posla nakon razmještanja?
Bert Scalzo: U idealnom slučaju, oni bi to mogli učiniti unaprijed, ali zato što su svi u svijetu gužve u kojem moraju tek završiti stvari, oni to obično ne rade dok ne naiđu na problem sa performansom koji ne mogu riješiti dodavanjem više CPU-a i memorije u virtualni stroj.
Dez Blanchfield: Da. Dakle, zapravo ste spomenuli nešto zanimljivo, ako mogu brzo? Prije ste spomenuli da se to može pokrenuti s bilo kojeg mjesta i može razgovarati s bazom podataka sa zadnje strane. Dakle, ovo je ugodno s vrstom bimodalnog koncepta o kojem sada govorimo, o oblaku na mjestu / van prostora, i po izgledu stvari, na kraju dana, ako može razgovarati sa stražnjim dijelom i vidjeti kôd, to uopće ne zanima, zar ne?
Bert Scalzo: Točno, da, možete to pokrenuti u oblaku.
Dez Blanchfield: Izvrsno, jer mislim da to nekako kreće u naš novi hrabri svijet. Dakle, Eric. Vratit ću vam se sada i vidjet ćemo da imamo nekoliko pitanja ovdje i želim da naši polaznici i dalje ostanu s nama, iako smo prošli sat.
Eric Kavanagh: Da, ima nekoliko ljudi vani, samo ću brzo prokomentirati: Bert, mislim da je metafora, analogija koju daješ provjeri pravopisa iskreno sjajna. To je vrijedno bloga ili dva, sasvim iskreno, jer je to dobar način da uokvirite kontekst onoga što radite i koliko je vrijedan i kako bi zaista trebala biti najbolja praksa za korištenje ispravljača pogrešaka redovito, zar ne? Kladim se da ćeš neke glave kimnuti kad ga izbaciš, zar ne?
Bert Scalzo: Apsolutno, jer ono što im kažem je: „Zašto pokrećem pravopisnu provjeru svojih dokumenata? Ne želim se sramiti glupih pravopisnih pogrešaka. "Pa, ne žele da se sramote zbog glupih pogrešaka u kodiranju!
Eric Kavanagh: Dobro. Da svakako. Pa, ljudi, već smo prošli sat i pet minuta, veliko hvala svima vama na vašem vremenu i pažnji. Arhiviramo sve te internetske chatove, slobodno se vratite bilo kada i provjerite ih. Najbolje mjesto za pronalaženje tih veza vjerojatno je techopedia.com, pa ćemo ovo dodati ovdje na ovaj popis.
I s tim ćemo se oprostiti, ljudi. Još jednom, sjajan posao, Bert, zahvaljujući našim prijateljima iz IDERA-e. Razgovarat ćemo s vama sljedeći put, razgovarat ćemo s vama idući tjedan. Čuvaj se! Doviđenja.
