Oduzeti: Domaćin Eric Kavanagh razgovarao je o uklanjanju pogrešaka i profiliranja baza podataka s dr. Robin Bloor, Dez Blanchfield i IDERA-em Bertom Scalzom.
Trenutno niste prijavljeni. Prijavite se ili prijavite da biste pogledali videozapis.
Eric Kavanagh: U redu, dame i gospodo, u srijedu je 4:00 po istočnom vremenu, i to naravno znači.
Robin Bloor: Ne mogu te čuti, Eric.
Eric Kavanagh: Bila sam tamo prije nekoliko dana, pa nisi sama. Ali, tako da je danas tema zaista zanimljiva. To je vrsta stvari za koju želite biti sigurni da se događa 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 razgovarali su 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, namjeravali su razgovarati o "Brzom odgovoru: Otklanjanje pogrešaka baze podataka i profiliranje u spas."
Doista, mjesto je za tvoje, pogodi me, naravno @eric_kavanagh.
Ova godina je vruća. A uklanjanje pogrešaka bit će vruće, bez obzira na sve. Stvarno će 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 ta pitanja? 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, događaju se ove stvari, dogodit će se, pitanje je što će biti vaše rješenje za suočavanje s tim i rješavanje tih problema?
Dobro se čujte s dr. Robin Bloorom, zatim našim Dez Blanchfield-om odozdo, i naravno, našeg dobrog prijatelja Berta Scalza iz IDERA-e. A zapravo ću vam predati ključeve Robin Bloor, oduzeti. Pod je tvoj.
Robin Bloor: U REDU. Ovo je zanimljiva tema. Mislio sam da će Dez vjerojatno nastaviti s trenutnim tehnikama i ratnim pričama o uklanjanju pogrešaka i pomislio sam da samo radim pozadinsku raspravu kako bismo dobili potpuno zaokruženu sliku onoga što se događa. To sam radio dugo, i nekada sam bio koder, tako da je bilo, 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 ostaviti nekom drugom.
Ovdje je popis poznatih bugova, a većina njih ulazi na gornji popis anybodyys, u osnovi, sve 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 vrste - očito je prouzročio š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. Program Apples Maps vjerojatno je 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. godini - njegov zanimljiv iz perspektive cijene takvog - AT&T su radili oko devet sati i koštali su oko 60 milijuna dolara u međugradskim pozivima.
Bio sam u američkom osiguravajućem društvu 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 da govorim o nepodudarnosti impedance i izdanom SQL-u. Zanimljivo je da relacijske baze podataka pohranjuju podatke u tablice i kodre i imaju tendenciju da manipuliraju podacima u objektnim strukturama koje se stvarno ne preslikavaju u tablice. I zbog toga dobivate ono što se naziva nepodudarnost impedancije i netko se mora suočiti s tim na neki ili drugi način. Ali što se zapravo događa, jer jedan model, model kodiranja i drugi model baze podataka nisu posebno usklađeni. Dobijate bugove koji se jednostavno ne bi dogodili da je industrija gradila stvari koje djeluju zajedno, a mislim da je smiješno. Dakle, u osnovi kodira, kad dobijete hijerarhije, to mogu biti tipovi, mogu rezultirati skupovi, može biti slaba sposobnost API-ja, može biti puno stvari koje jednostavno izbacuju stvari u smislu interakcije s bazom podataka. Ali stvar koja je za mene najviše zanimljiva, 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 procedure koje ž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 samo referentni integritet i kaskadno brišući i takve stvari, baza podataka brinula je za sve iznenadne uvrštavanja funkcionalnosti u bazu podataka, što je naravno značilo da je funkcionalnost za Aplikacija se može podijeliti između kodera 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 s bazama podataka, jer to znači da ste imali na primjer puno implementacija, da sam sudjelovao u relacijskim bazama podataka stvarno grozno puno koda koji sjedi u pohranjenim procedurama, a obrađuje se odvojeno od koda koji sjedi u aplikacijama. I čini se kao da je vrlo čudno što se mora dogoditi, jer bi trebalo biti prilično pametno raditi razne stvari.
Mislio sam da Id govorim 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. Njegova bi trebala biti dizajnirana tako da koder ne treba 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 uklanjanje pogrešaka u bazu podataka može biti samo naporno i ne-trivijalno - i to kažem zato što sam puno toga učinio - i često ćete otkriti njegove situacije kao i sve situacije pri uklanjanju pogrešaka koje sam ikad doživio je, prvo što ste ikada vidjeli je nered. I morate pokušati i preći iz nereda da biste utvrdili kako je do nereda došlo. I često kada gledate u bazu podataka, sve što gledate su korumpirani podaci i mislite: "Kako se dovraga to dogodilo?"
U svakom slučaju, preći ću na Dez koji će vjerojatno reći više riječi mudrosti nego što sam izašao. Ne znam kako ti prebaciti loptu, Dez.
Eric Kavanagh: Proći ću, stajati, čekati.
Automatizirani glas: Linije sudionika su isključene.
Eric Kavanagh: U redu, stani na trenutak, daj da Dez dam loptu.
Dez Blanchfield: Hvala, Eric. Da, dr. Robin Bloor, uistinu ste najtačniji: ovo je tema, doživotna buba ako se oprostite od bundeva, oprosti što se nisam mogao pomoći sebi. 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 velikom 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 slučaj profiliranja koda i mogućeg pisanja koda koji funkcionira, to bi trebao biti problem. Dakle, moj naslovni slajd ovdje, zapravo 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, njihova druga konstrukcija stroja nazvana 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 drukčije od hardvera i navodnog softverskog problema.
Dakle, urbani mit je onaj krug oko 9. rujnath, 1945. tim na Sveučilištu Harvard razdvajao je stroj, naišli su na nešto što su nazivali "sedamdeset relejnih" - tih dana programiranje se odvijalo u fizičkom smislu, vezali ste kod oko ploče i tako ste učinkovito programirali stroj - i otkrili su taj broj releja sedamdeset da nešto nije u redu s njim, a ispada da je stvarni izraz "bubica" nastao jer je bukvalno bio moljac - navodno je bio moljac zataknut između nekog komada bakrene žice 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, kako je Robin istaknuo ranije u svom prvom dijapozitivu, koncept greške seže 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 bušilici. Ali cijela poanta ovoga je u tome što je izraz "uklanjanje pogrešaka" proizašao iz ovog koncepta pronalaska buga u fizičkom stroju.I od tada, mi smo koristili tu terminologiju pokušavajući rješavati probleme, ne toliko koliko problema s kodiranjem u programu koji se ne sastavlja, već kao program koji ne radi dobro. A posebno nije profilirano samo pronađite stvari poput neprekidnih petlji koje nigdje ne idu.
Ali imamo i scenarij, i pomislio sam da sam stavio nekoliko smiješnih slajdova prije nego što sam se pozabavio malo više detalja. Evo klasičnog crtanog filma, nazvanog XKCD na webu, a karikaturist ima prilično smiješne poglede na svijet. A oni o djetetu zvanom "Mali Bobby Stolovi" i navodno su njegovi roditelji tog dječaka prozvali Robertom); DROP TABELA Učenici; - i to se zove, i vrsta „Bok, ovo je da škola tvojih sinova 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 ", a učitelj pita," jesi li stvarno imenovao svog sina Roberta); DROP TABLE Učenici; -? ”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, nadam se da ste sretni. A odgovor je: "Pa, trebali biste očistiti i sanitirati unose u svoju bazu podataka." I to mnogo puta koristim za razgovor o nekim problemima koje imamo u pronalaženju stvari u kodu, a često i kod ne gleda podatke. ,
Još jedna smiješna, ne znam je li ovo stvarno ili ne - sumnjam da je to podvala - ali opet, to se dotiče i moje smiješne kosti. Netko mijenja registarske tablice na prednjem dijelu automobila, u sličnu izjavu koja uzrokuje pad podataka u kamere za brzi hod 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 ja uvelike smatram da je to vrijeme prošlo, i to anegdotalno u mom iskustvu, moje prvo - i ovo će me grozno dobivati, siguran sam; Robin, dobrodošao si da mi se zbog toga zabaviš - ali povijesno dolazim iz pozadine u dobi od 14 godina lutajući kraj grada i kucajući na vrata podatkovnog centra zvanog „Data Com“ na Novom Zelandu i pitati je li Mogao bih zaraditi džeparac u školi tako što bih svaki dan dolazio u kasni autobus, oko 25 km vožnje, stavljajući papir u kasete 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 teleletnom terminalu, koji je zapravo fizički bio 132 stupca. U osnovi, mislite na vrlo staru pisaću mašinu s papirom koji se provlačio kroz nju, jer oni nisu imali CRT cijev. A kôd za uklanjanje pogrešaka na tom mjestu bio je ne-trivijalni problem, pa ste skloni pisati sav kôd rukom, a zatim se ponašati kao daktilograf, trudeći se da ne biste pogriješili, jer je to vrlo frustrirajuće što morate reći uređivač jednog retka otišao je do određenog retka, a zatim redak i zatim ga ponovo upisao. Ali jednom prilikom, tako smo pisali kod i tako smo ispravljali greške, i dobili smo vrlo, vrlo dobar u tome. 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 su bili upoznati s tim - prošlo je od iskustva 3270 terminala u mom svijetu, do Digitalne opreme VT220 gdje ste mogli vidjeti stvari na ekranu, ali opet, upravo ste radili isto što i Vi na papirnoj vrpci vrsta ed formata samo na CRT-u, ali mogli ste ih 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 samouka na mnoge načine i 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 uveo buggy kodirati.
Način programiranja ovih dana, na primjer, Strukturni jezik upita, SQL, njegov je vrlo moćan, jednostavan jezik upita. Ali pretvorili smo ga u programski jezik i stvarno 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, kad promišljamo s dvije točke gledišta: s 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 peee-a za kućne ljubimce, na primjer, sa SQL-ovcima koji skaču na Google i traže nešto i pronalaze web stranicu 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. Na primjer, imate drugih izazova, na primjer, ovih dana svi su žurili ka tome, ono što mi nazivamo utrkom u nuli: pokušavajući sve učiniti tako jeftino i tako brzo, da imamo scenarij u kojem nisu zaposleni zaposlenici s nižim plaćama. I ne mislim to na bezobrazan način, ali nisam zapošljavao 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 je dana puno ljudi ušlo u razvoj i dizajn i bazu podataka koji nisu imali dugogodišnje iskustvo, nisu imali nužno istu obuku ili podršku. I tako završite sa scenarijem samo tradicionalnog amatera nasuprot stručnjaka. I postoji poznata linija, zapravo se ne sjećam tko je stvorio citat, a zatim slijedi: "Ako mislite da je skupo angažiranje stručnjaka za posao, pričekajte dok ne zaposlite nekoliko amatera koji će stvoriti problem i morate očistite. "I tako SQL ima to pitanje, i to je vrlo, vrlo lako naučiti, vrlo je jednostavan za korištenje. Ali, po mom mišljenju, to nije savršen programski jezik. Vrlo je jednostavno učiniti stvari poput odabrane zvijezde odakle god bilo, a sve to izvucite u programski jezik koji vam je ugodniji poput PHP-a i Ruby ili Python, a za manipuliranje podacima koristite programski jezik koji ste izvorno poznavali, umjesto da radite složeniji upit 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 sustava online prodaje karata, gdje to čine odabrana zvijezda iz bilo kojeg mjesta.
To je stvarno ekstremni primjer, ali vi od svega toga shvaćate. Dakle, da bih stvarno pogodio tu točku kući, evo primjera koji ja puno nosim. Veliki sam ljubitelj matematike, volim teoriju kaosa, obožavam komplete Mandelbrot. S desne strane nalazi se prikaz Mandelbrotovog skupa, za koji sam siguran da su svi bili 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; vrlo 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 imamo pohranjene procedure, imamo metodologiju programiranja koja se primjenjuje na jezik, tako da je vrlo lako zbog loše programske prakse, nedostatka iskustva, kôda skraćivanja i lijepljenja, nisko plaćenog osoblja koje pokušava biti visoko plaćeno osoblje, ljudi koji se pretvaraju da znaju, ali moraju uč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 baš simpatično i pomislite: "Jao, kakva sjajna grafika, volim to pokrenuti." Ali zamislite da to radi na nekom poslovnom logikom. 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. I da to zaista ilustriram - i žao mi je što su boje obrnute, to bi trebala biti crna pozadina, a zelena boja zelena boja, 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 napisan kao C ++, ali 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 ovoga je u tome što ako nemate ispravne alate, ako nemate ispravne platforme i okruženja da biste mogli uhvatiti ove stvari, i oni uđu u proizvodnju, i onda morate 100.000 ljudi udarati u sustav svaki dan ili sat ili minutu, vrlo brzo završite iskustvo u Černobilu, gdje se veliko željezo počne topiti i zakopati u srž planete, jer taj dio koda nikada ne bi trebao 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 omogućuje vam da dobijete DBA kako bi vam pomogao da pravilno izgradite taj strukturirani upit, jer iskreno, to je samo gadno." A tamo navedeni URL adrese možete pogledati i nazvati 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 jedna linija.
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, kao što sam već rekao prije , jednom davno, to možete učiniti gledajući zeleni ekran. Ne možeš više; postoje stotine tisuća linija kodova, postoje deseci tisuća aplikacija, postoje milijuni baza podataka u nekim slučajevima, pa čak i super ljudi to više ne mogu raditi rukom. 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 mnogo dolara, puno vremena i truda i uništavaju moral i stvari, kad ne mogu otkriti zašto stvari traju dugo trčati.
I imajući to na umu, predati ću našem gostu i radujem se slušanju kako su riješili ovo pitanje. A pogotovo demonstracija za koju mislim da je trebala primiti. Eric, prebacujem se.
Eric Kavanagh: OK, Bert, odnesi to.
Bert Scalzo: Ok hvala. Bert Scalzo ovdje iz IDERA-e, Im upravitelj 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 ranije rekao - i vrlo je istina da je uklanjanje pogrešaka naporno i ne-trivijalno, a kada odete u bazu podataka, uklanjanje pogrešaka je njen red veličine još teže i ne-trivijalno - 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 program za ispravljanje pogrešaka, oni samo programiraju na bilo kojem jeziku koji koriste i puno puta će mi reći: „Pa, te su ispravljanje pogrešaka 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, vrstu govorenja gdje smo bili uvjeti 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 koji su nam dostupni, i tako da kažemo: "Hej, ne koristim program za uklanjanje pogrešaka, to je jedna od tih novih stvari", onda ste sigurno počeli programirati, znate, u 1950-ima, to je jedini način na koji možete doći daleko s tom tvrdnjom.
Druga stvar koja je smiješna u vezi s ovim grafikonom je Dez koji je upravo komentirao Grace Hopper, zapravo sam poznavao Grace, pa je onako smiješna. I onda se druga stvar kojoj sam se nasmijao jest da je govorio o teletipovima i da sam sjedio tamo išao: "Čovječe, to je bio najveći skok u produktivnosti, kad smo išli od karata do teletipija, to je bio najveći skok ikad." , i programirao sam na svim jezicima ovdje, uključujući SNOBOL, za koji nitko do sada nije čuo, bio je to CDC, Control Data Corporation, pa pretpostavljam da sam postao malo prestar za ovu industriju.
Dez Blanchfield: Htio sam reći, ostavili ste nas strašno tamo.
Bert Scalzo: Da, kažem vam, osjećam se kao djed Simpson. Stoga gledam na ispravljanje pogrešaka i postoje različiti načini ispravljanja pogrešaka. 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 držite izjave u vašem kodu i možda stvarate izlaznu datoteku, datoteku u 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ži način, ali to se računa. Ali isto tako, dobili smo čuvenu izjavu: gledate i ljudi zapravo stavljaju izjave i zapravo sam vidio alat gdje - i njegov alat za bazu podataka - gdje ako ne znate koristiti alat za uklanjanje pogrešaka, pritisnete gumb i on će se zalijepiti izjave iz cijelog koda za vas, 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 je da li kôd nije učinkovit; ne čini ono što smo očekivali. Drugi put kad odlazimo i otklanjamo programsku pogrešku, to je učinkovitost 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 su profili vjerojatno bolji za drugi scenarij i htjeli su razgovarati i o programima za uklanjanje pogrešaka i o profilima. Osim toga, postoji ovaj koncept daljinske uklanjanja pogrešaka; ovo je važno jer puno puta ako sjedite na svom osobnom računalu i koristite alat 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 eto, događa se. A onda, vrlo je često da s ovim uređajima za uklanjanje pogrešaka postoje prekidne točke, točke gledanja, korak i prijelaz i neke druge uobičajene stvari, koje ću im pokazati na trenutak 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 bolje ako je izvršeno uzorkovanje. Nema razloga za hvatanje svake pojedine izjave, jer neke izjave mogu jednostavno proći tako brzo da vas nije briga, ono što stvarno pokušavate vidjeti je dobro, a to su one koje se prikazuju iznova i iznova, jer se predugo prikazuju , Dakle, ponekad profiliranje može značiti uzorkovanje, a ne pokretanje cijele stvari. Obično ćete dobiti nekakav izlaz koji možete koristiti, što bi sada moglo biti vizualno unutar IDE razvojnog okruženja, gdje vam može dati sličan histogram izvođenja različitih linija koda, ali može i dalje biti da stvara datoteku u tragovima.
Profillovi su se prvi put pojavili 1979. Dakle, i oni su dugo vremena bili ovdje. Izvrsno za pronalaženje potrošnje resursa ili problema sa performansama, drugim riječima koja je stvar učinkovitosti. Generalno gledano, njegova je zasebna i različita 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 pogrešaka profilisati. I to je šteta, jer profiliranje doista može napraviti ogromnu razliku. Sada, jezici baza podataka, kao što smo govorili ranije, dobili ste SQL - i mi smo na neki način prisilili okrugli zatič u kvadratnu rupu i prisilili ga da postane programski jezik - i Oracle.To je PL / SQL - taj procesni jezik SQL - i SQL Server, njegov Transact-SQL, SQL-99, SQL / PSM - za, mislim, njegov pohranjeni modul postupka. 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.
Dakle, 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 Im pohranjuju predmete u bazu podataka, vjerovatno pohranjenu proceduru ili pohranjenu funkciju. Ali tu se također pokreće: okidač je poput pohranjene procedure, ali aktivira se na nekakav događaj. Sada će neki ljudi u svoje okidače staviti jednu liniju koda i nazvati pohranjenu proceduru tako da zadrže sav svoj pohranjeni kod i postupke, ali isti je koncept: ipak bi njegov 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 naziva paket, tako da izgleda kao knjižnica. 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 crte 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 upisati više koda za uklanjanje pogrešaka koji ćete unijeti u sve ove izjave nego što je to slučaj s kôdom. Iako ovo može uspjeti, a 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 interaktivnu sesiju za uklanjanje pogrešaka, znao bih u liniji tri - pet minuta do toga - hej, postoji problem ovdje, mogu prestati. Ali s ovim moram pričekati da se pokrene, sve do završetka i onda moram pogledati datoteku s tragovima koja vjerojatno ima sve te izjave i pokušati pronaći iglu u sijenu. Opet, ovo je bolje nego ništa, ali ne bi bio najbolji način rada. Eto, to bi izgledala datoteka koja dolazi iz prethodnog slajda; Drugim riječima, pokrenuo sam program i njegov je spisak zapisa u ovoj datoteci s tragovima dobio, a možda i neću moći prolaziti kroz to i pronaći ono što trebam pronaći. Dakle, opet nisam siguran da bi to želio raditi.
Eto, 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 koristiti ih ovdje 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 je potrebno 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, na gornjoj trećini, u sredini sam dobio svoj izvorni kod, dobio sam ono što se naziva varijablama mog sata i ladicama za slanje poziva, a zatim sam na dnu dobio neke izlazne signale. 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 Im prolazi kroz kôd. I to je zaista korisno, a onda mogu kodati jedan po jedan redak putem koda, ne moram reći izvršiti, mogao bih reći korak redak, pustiti me da pogledam što se dogodilo, koraknuti drugu liniju, da vidim što se dogodilo i Radim to 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.
Sada, sljedeća strelica tamo - možete vidjeti malu strelicu koja je usmjerena udesno, prema onom izlazu DBMS-a, tamo je trenutno moj pokazivač - dakle drugim riječima, Ive je zakoračio i to je ono gdje sam u ovom trenutku. Dakle, ako kažem "korak opet", idem na sljedeći redak. Sada odmah ispod te crvene točke. Pa, to je prijelomna točka, 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 pokrenuti se odavde do kraju ili prijelomnoj točki, ako su postavljene neke prijelomne točke, a onda će se zaustaviti i pustiti me da ponovno napravim korak. A razlog što je sve ovo važno i moćno je, jer kad se ja bavim time, promijenit će se ono što se događa u sredini, pa čak i na dnu - ali što je najvažnije u sredini - i vidim vrijednosti svojih varijabli, mogu vidite moj trag stog poziva, znate, i tako su se sve te informacije tamo prikazale kao da prolazim kroz kod, tako da zapravo mogu vidjeti i osjetiti i shvatiti što se događa i kako kod zapravo radi u vrijeme izvršenja , I obično mogu naći problem, ako postoji ili ako sam dovoljno dobar da ga uhvatim.
U redu, sada ću razgovarati o profileru, a u ovom slučaju to 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, ja sam u Rapid SQL-u i vidim lijevu marginu na lijevoj strani, pored brojeva redaka. I što je to, to je onaj broj sekundi ili mikrosekundi potreban za izvršavanje svakog retka koda, i to jasno vidim, svo svoje vrijeme provodim u ovoj petlji FOR, gdje ja biram sve iz tablice. I tako, Whatevers koji se događaju u toj petlji FOR vjerojatno je nešto što moram pogledati, i ako uspijem 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 nema puno vremena. U ovom slučaju, i opet, ja sam u Rapid SQL-u, vidiš kako mogu raditi profiliranje miješano s mojim ispadanjem pogrešaka. Dakle, ono što je lijepo je da 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 možete vidjeti da Ja više nije 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 sam dobio jednu izjavu koja izgleda kao da zauzima većinu pita grafikona i ako pogledam, vidim na onoj rešetki prema dnu, redak 23, opet je petlja FOR: hen uzima najviše vremena, on je ustvari taj tamnocrveni žvakanje svih tablica 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 se odvojio 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? To nije zato što želimo napisati najveći kôd na svijetu i dobiti povećanje plaće - to bi mogao biti naš razlog, ali to zapravo nije razlog zbog kojeg to radite - obećali ste poslu da ćete nešto ispravno napraviti, da će vaš program biti učinkovit. Za to ćete koristiti ispravljanje pogrešaka. Osim toga, poslovni krajnji korisnici; nisu baš strpljivi: žele rezultate čak i prije nego što pritisnu tipku. Trebali su č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 ovaj čovjek u poslovnom odijelu s lukom i strijelom, a pucate u metu i vezani ste očima. 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 možda ili ne mora prikazati neke od ovih stvari, ali nema jamstva da će ih pregledati sve. Pomoću programa za uklanjanje pogrešaka i profilatora trebali biste moći pronaći sve te bugove.
OK, upravo ću napraviti pravi brzi demo ovdje. Nije mi namjera gurati proizvod, samo vam želim pokazati kako izgleda ispravljanje pogrešaka, jer mnogi ljudi će reći: „Nikada prije nisam vidio nijednog takvog.“ I izgleda prilično na zaslonskim slajdovima, ali što? izgleda li to kad je u pokretu? Dakle, evo na mom zaslonu pokreću 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, izvadit ću ovaj kod 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, tamo gore na vrhu, po prvoj liniji, tu sam Im u kodu. 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 skroz do ove petlje FOR, jer znam da je tu problem, mogu postaviti točku prekida. Mislila sam da sam to postavila. Pucaj, imao sam jedan od mojih tipki za snimanje zaslona preslikan na isti ključ kao i za ispravljanje pogrešaka, a 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 dolje na mjesto gdje je prekidna točka, tako da sam sada u zamahu pokretanja ove petlje, vidim na što su postavljene sve moje varijable, što nije iznenađenje, jer sam ih sve inicijalizirao u nula. A sada mogu zakoračiti u ovu petlju i početi gledati što se događa unutar ove petlje.
Dakle, sada će se odbrojati broj mojih stanova i prelazim mišem preko tog tipa i pogledam, dva, dva veća su od jednog, pa će vjerojatno uraditi sljedeći dio ovog koda. Drugim riječima, nešto je pronašlo. Samo idem naprijed i pustim da se pokrene. 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. Imam postavljenu prijelomnu točku, pa kad sam rekao trčanje, jednostavno se vratio na sljedeću prijelomnu točku. Ako ga pustim da se izvodi do kraja, uzrokujem ono što želim da vidite je da program za uklanjanje pogrešaka ne mijenja ponašanje programa: kad se izvrši, trebao bih dobiti potpuno iste rezultate da sam ga pokrenuo ne unutar ispravljača greške.
I s tim ću suspendirati demo i vratiti se jer želimo osigurati vremena za pitanja i odgovore. I tako, otvorit ću ga za pitanja i odgovore.
Eric Kavanagh: U redu, Robin, možda pitanje od tebe i 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 kao što je, gledaju li oni - jer pretpostavljam da jesu - gledaju 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 ja ću unutar svog Visual Basic nazvati 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 kôd vrlo učinkovit, možda ćete izgledati i reći: „Ooh, upućivali smo 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. I tako zapravo možete pronaći tamo gdje postoji učinkovit kod koji se često poziva, a to je zapravo problem performansi.
Robin Bloor: Da, to je divno. Nikad to nisam radio. 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 ... Nikad nisam bio uključen u izgradnju aplikacija u kojima smo imali pohranjene postupke, pa pretpostavljam da nikada nisam naišao na probleme koji su me neko vrijeme divili, ideju da šifru razdvojiš na baze podataka i programa. Ali tako, učinite sve - Pretpostavljam da će odgovori 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 spojiti novu aplikaciju. 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 što je smiješno, prošli tjedan sam imao klijenta koji je izrađivao web aplikaciju, a njihova je baza podataka, povijesno, bila mala, pa činjenica da nisu bili vrlo dobri programeri ih nikada nije naškodila. Pa, njihova je baza podataka tijekom godina rasla, a sada joj 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 njegov problem performansi. A 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 da im se u jednoj od njihovih odabranih izjava pridružila kartezijanska ploča i da to nismo znali.
Robin Bloor: Wow.
Bert Scalzo: Ali netko mi je jednom rekao: "Pa kako bi mogli dobiti kartuzijanski oblik i ne znaju ga?", A ovo zvuči zaista grozno; ponekad programer koji nije baš ugodan za SQL učinit će 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 upravo vratili milijardu zapisa ili gledaju milijardu zapisa, jer su dobili ono što ih je zanimalo.
Robin Bloor: Wow, znam, tako se zove - eto, o čemu se Dez događa, u smislu 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, zaista, to ne može opravdati 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, što god koristili na strani kodiranja?
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. Dat ću programerima jednu pauzu, jer ne volim baciti programere ispod autobusa. Ali problem je zapravo akademsko okruženje jer kad ste krenuli da naučite kako biti programer, naučili ste zapise u to vrijeme razmišljati. 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 za osobu koja nikad nije razmišljala u vezi s setovima, da odustane, pusti se u obradu i snima s vremenom obrađuje i radi sa setovima.
Robin Bloor: Da, s tobom sam. Mislim, shvaćam sada, 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ć njegov deklarativni. 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 zalazite u detalje čak i upravljanja brojevima, dok radite petlju. Nestrpljivo predajem:
Bert Scalzo: Ne. OK, 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 radi isti efekt kao pridruživanje, ali on to čini sam, a profil bi to uhvatio, jer biste vjerovatno potrošili više vremena radeći spajanje ručno, nego da poslužitelj baze podataka to učini za vas.
Robin Bloor: Da, to bi bila katastrofa. Mislim, samo bi se trzao uokolo. Thrashings uvijek loše.
U svakom slučaju, prebacim Dez; Sigurna sam da ima nekih zanimljivih 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 postajući koder, i to na svim razinama, znate, bilo da je, kako ste rekli, sjeo u naredbenu liniju Unix-ovog stroja, a u nekim sam slučajevima č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 to da je kartica za izlazak iz zatvora za svaki koder i skripter na svijetu. Raketna je znanost, prilično doslovno, svaki put pisati stvarno usko, raketna znanost. I poznate priče ljudi poput Dennisa Ritchieja i Briana Kernahana koji samostalno rade na nekim dijelovima koda, a zatim prelaze na razgovor za pregled koda uz kavu i otkriju da su napisali točno isti dio koda, u točno istom programu, u točno istom 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 pokušavaju 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 vas čujem kako biste mogli nabaciti na skriptu školjke i pronaći neka pitanja, jer znate, u današnjem danu i starosti uvijek su radili do najnižih troškova na svemu.
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 ljudi dobivaju 400 000 dolara godišnje da pišu kod na savršen način; njegov cjelokupni razvoj. Dakle, ta točka, pretpostavljam da je jedno od pitanja koje vas volim da biste nam dali samo malo više uvida, je kolika je širina i doseg vrste ljudi koje trenutno vidite koji koriste ovakve alate za profiliranje koda i izgled za probleme s izvedbom? 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 je sada dobivalo manje, kako je Robin rekao, akademskog pristupa, a sada njegov samouk, ili koda za rezanje i lijepljenje ili samo postavljanje stvari? I podudara li se s onom vrstom ljudi koji sada uzimaju proizvod?
Bert Scalzo: Da, točno. I dajem vam vrlo konkretan primjer, mi samo želimo obaviti posao, jer poslovni ljudi ne žele savršenstvo. Svoja vrsta računalne igre u šahu: šahovska igra ne traži savršen odgovor; traži odgovor koji je dovoljno dobar u razumnom roku, tako da tako programiramo. Ali ono što sada nalazim je da većina ljudi umjesto da kaže da žele profilare kao dio testiranja uređaja - što bih i učinila, jer ne vidim da gubim vrijeme - što se događa sada je to što se radi kasnije, ponekad, tijekom integracijskog testiranja ili testiranja otpornosti na stres, ako su imali sreće. Ali većinu vremena njegov dio eskalacije, gdje je nešto išlo u proizvodnju, trajalo je neko vrijeme, možda je čak i radilo godinama, a sada to ne radi dobro, a sada to dobro prepoznaje. I čini se da je to sada češći scenarij.
Dez Blanchfield: Da, i mislim da je izraz "tehnički dug" vjerojatno više nego poznat; 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, dobili smo vlastite projekte poput Media Lens-a i drugih, gdje se kodiranje svakodnevno događa, i razne stvari u Bloor Grupi. I kad god smo nešto radili, 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 shvatiti u kantu i izvadite ga vani i gledajte i hoće li se ove stvari pokvariti. I naslijediti ovaj tehnički dug za koji znam da se moram zaobići kasnije i popraviti ga.
I mislim, to sam učinio u posljednjih sedam dana: napisao sam nekoliko alata i skripti, napisao sam par komada jezika Pythona i rasporedio sam ga u zadnji dio Mongoa, osiguravajući da je njegov lijep, čist i siguran, ali dobiva samo upit koji trebam obaviti, 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 gdje imate 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š kod i vidjeli gdje se nalaze petlje, prije nego što su dostupni ovakvi alati - i kad napravite kod da biste pregledali vlastiti kod , vrlo ste dobri u tome š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 vas i pokazati vam da to rade ne-programeri stalno. Jer ako ikad podučavam predavač za uklanjanje pogrešaka i profiliranje ili seansu, pitam 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 kada pišete u svoj IDE poput Visual Basic, ne upotrebljavate ispravu? To je ista stvar, poput provjere pravopisa. "
Dez Blanchfield: Da, u stvari, to je sjajna analogija. Nisam stvarno razmišljao, 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, no što je sada zanimljivo sa ovakvim alatom možete to 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 u program za obradu teksta, što će izazvati zanimljiv poziv na 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 se uputim na naša 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 stupite i to implementirate kako se razvijate, prije nego što se razvijate? Ili je slučaj da pretežno gradite, krećete se, nešto napravite pa uđete i kasnije to profilirate? Sumnjam da je slučaj rano stići i provjeriti se da vaši kodovi unaprijed budu čisti. 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 uradili unaprijed, ali pošto su svi u svijetu užurbanosti, u kojem su tek trebali riješiti stvari, skloni su da to ne učine dok ne naiđu na problem s performansama koji ne mogu riješiti dodavanjem više CPU-a i memorije. na 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 kod, to baš i ne brine, zar ne?
Bert Scalzo: Točno, da, možete to pokrenuti u oblaku.
Dez Blanchfield: Izvrsno, jer mislim da tamo otprilike ide 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 vremena.
Eric Kavanagh: Da, postoji nekoliko ljudi vani, samo brzo napišem komentar: 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 uobličite ono što vi radite i koliko je to vrijedno i kako bi zaista trebala biti najbolja praksa da se program za uklanjanje pogrešaka koristi na redovito, zar ne? Kladim se da ćeš neke glave kimnuti kad ga izbaciš, zar ne?
Bert Scalzo: Apsolutno, ono što im kažem je: „Zašto pokrenem pravopisnu dokumentaciju? Ne želim se sramiti glupih pravopisnih pogrešaka. "Pa, ne žele da ih sramotaju glupe pogreške kodiranja!
Eric Kavanagh: Pravo. Da svakako. Pa, ljudi, proživjeli smo ovdje 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 pronalazak tih veza je vjerojatno techopedia.com, pa dobro dodajte ovo na ovaj popis ovdje.
I s tim su se htjeli oprostiti, ljudi. Još jednom, sjajan posao, Bert, zahvaljujući našim prijateljima iz IDERA-e. Pa razgovaramo s vama sljedeći put, a dobro razgovaramo sljedeći tjedan. Čuvaj se! Doviđenja.