Odnést: Host Eric Kavanagh diskutoval o ladění databáze a profilování s Dr. Robinem Bloorem, Dezem Blanchfieldem a IDERAs Bertem Scalzem.
Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.
Eric Kavanagh: Dobře, dámy a pánové, ve středu je 4:00 východního času, a to samozřejmě znamená.
Robin Bloor: Neslyším tě, Ericu.
Eric Kavanagh: Byl jsem tam před dny, takže nejsi sám. Ale dnes je to téma opravdu zajímavé. Je to druh věcí, které se chcete ujistit, že se děje na pozadí vaší společnosti, pokud nejste osobou, která to dělá, v tom případě se chcete ujistit, že to děláte správně. Protože mluvili o ladění. Nikdo nemá rád chyby, nikdo nemá rád, když software přestane fungovat - lidé jsou naštvaní, uživatelé jsou nepřátelští. To není dobré. Chtěli jsme tedy hovořit o „rychlé reakci: ladění databáze a profilování záchrany“.
Je tu opravdu vaše místo, opravdu mě zasáhnete, samozřejmě @ @ @icic_kavanagh.
Tento rok je horký. A ladění bude horké, bez ohledu na to. Je to opravdu jeden z těchto problémů, který nikdy nezmizí, bez ohledu na to, jak dobře se k tomu dostaneme, vždycky to bude problém, takže klíčem je, jak se dostanete k místu, kde můžete tyto problémy rychle vyřešit? V ideálním případě máte skvělé programátory, skvělá prostředí, kde se moc nepovede, ale jak se říká staré rčení: „Nehody se stávají v nejlepších rodinách.“ A totéž platí pro organizace. Takže, toto se stane, stane se to, otázkou je, jaké bude vaše řešení pro řešení a řešení těchto problémů?
Robin Bloor, potom náš vlastní Dez Blanchfield zdola a samozřejmě náš dobrý přítel Bert Scalzo z IDERA. A ve skutečnosti, já budu rozdávat klíče Robin Bloorovi, vzít je pryč. Podlaha je vaše.
Robin Bloor: OK. Toto je zajímavé téma. Myslel jsem, že protože Dez bude pravděpodobně pokračovat ve skutečných technikách a válečných příbězích o ladění, myslel jsem si, že Id jen provádí diskusi na pozadí, takže bychom měli získat úplně zaoblený obrázek o tom, co se děje. Dělal jsem to dlouho a býval jsem kodér, takže je to podobné, a byl jsem téměř v pokušení touto prezentací začít voskovat lyriku o myšlence open source, ale myslel jsem si, že to nechám na někoho jiného.
Zde je seznam slavných chyb, a většina z nich se dostane do top seznamu anybodys, v podstatě všechny kromě posledních dvou stojí nejméně 100 milionů dolarů. Prvním z nich byl Mars Climate Orbiter, který se ztratil ve vesmíru, a to kvůli problému s kódováním, kdy lidé zaměňovali metrické jednotky s (smíchem) nohou a palcem. V letu Ariane Five Flight 501 došlo k neshodě mezi motorem, který byl nasazen, a počítači, který měl při spuštění raketu spustit. Více selhání počítače, explodující raketa, hlavní zprávy. Sovětský plynovod v roce 1982 řekl, že je největší explozí v historii planety; Nejsem si jistý, zda je. Rusové ukradli nějaký automatizovaný řídicí software a CIA si uvědomila, že to udělají a vloží do něj chyby, a Sověti to provedli bez testování. Takže vyhodili do povětří potrubí, které bylo zábavné.
Morrisův červ byl kódovací experiment, který se najednou stal drzým červem, který obcházel všudy - zjevně způsobil škodu v hodnotě 100 milionů dolarů; to je samozřejmě odhad. Intel udělal slavnou chybu s matematickým čipem - matematickou instrukcí na čipu Pentium v roce 1993 - která měla stát více než 100 milionů dolarů. Program Mapy jablek je možná nejhorším a nejnebezpečnějším zahájením všeho, co Apple kdy udělal. Lidé, kteří se to pokusili použít, byli, myslím, někdo, kdo jel po 101, a zjistili, že mapa Apple řekla, že jsou uprostřed San Francisco Bay. Takže lidé začali odkazovat na aplikaci Apple Maps jako iLost. Náš nejdelší výpadek v roce 1990 - je to prostě zajímavé z hlediska nákladů na něco podobného - AT&T byly venku asi devět hodin a při dálkových hovorech to stálo zhruba 60 milionů dolarů.
A byl jsem u pojišťovny UK a databáze, implementovali novou verzi databáze a začala stírat data. A pamatuji si to velmi dobře, protože jsem byl poté pozván, abych se kvůli tomu zúčastnil výběru databáze. A bylo velmi zajímavé, že vzali novou verzi databáze a měli spoustu testů, které udělali pro nové verze databáze, které prošly všemi testy. Našel opravdu nejasný způsob, jak vymazat data.
Takže to tak je. Myslel jsem, že Id mluví o nesouladu impedance a vydaném SQL. Je zajímavé, že relační databáze ukládají data do tabulek a kodéry mají tendenci manipulovat s daty v objektových strukturách, které do tabulek opravdu dobře mapují. A kvůli tomu získáte tzv. Nesoulad impedance a někdo s tím musí nějakým způsobem jednat. Co se však ve skutečnosti děje, protože jeden model, kodérový model a databáze jiný model, nejsou nijak zvlášť zarovnány. Dostanete chyby, které by se prostě nestalo, kdyby průmysl postavil věci, které spolupracují, což je podle mě veselé. Takže v podstatě na straně kodérů, když získáte hierarchie, mohou to být typy, může to vést k sadám, může to být špatná schopnost API, může to být spousta věcí, které prostě vyhodí věci z hlediska interakce s databází. Ale to, co je pro mě nejvíce, opravdu zajímavé; vždy mě překvapilo, že jste měli tuto bariéru SQL, která je také druhem impedance takovým způsobem, že kodéry a databáze spolupracují. SQL má tedy rozpoznávání dat, což je v pořádku a má DML pro výběr, projektování a připojení, což je v pořádku. Můžete s tím hodit spoustu schopností, pokud jde o získávání dat z databáze. Má však jen velmi malý matematický jazyk pro práci. Má to něco z toho a toho a má jen velmi málo času. A z tohoto důvodu je SQL nedokonalým prostředkem, jak získat data. Takže, chlapci z databáze vytvořili uložené procedury, aby žily v databázi, a důvod, proč tam uložené procedury žijí, byl, že jste opravdu nechtěli házet data tam a zpět do programu.
U některých funkcí byla extrémně specifická data, takže se nejednalo pouze o referenční integritu a kaskádové vymazání a podobné věci, databáze se postarala o veškerou funkci náhlého uvedení do databáze, což samozřejmě znamenalo, že funkčnost pro aplikace by mohla být rozdělena mezi kodér a samotnou databázi. A to způsobilo, že implementace některých funkcí byla opravdu obtížná, a proto náchylnější k chybám. To je jedna strana databázové hry, protože to znamená, že jste se dostali do mnoha implementací, například, že jsem byl zapojen do relačních databází, je to opravdu strašlivé množství kódu, který sedí v uložených procedurách, které se zpracovávají odděleně od kódu, který sedí v aplikacích. A vypadá to, že se k tomu muselo dostat velmi podivné, mělo by to být docela chytré v provádění různých věcí.
Myslel jsem, že Id také mluví o výkonu databáze, protože chyby výkonu jsou často považovány za chyby, ale v zásadě můžete mít problémové místo na CPU, v paměti, na disku, v síti a můžete mít problémy s výkonem kvůli zamykání. Myšlenka by byla taková, že by se kodér opravdu nemusel zajímat o výkon a databáze by ve skutečnosti fungovala přiměřeně dobře. Má být navržen tak, aby kódovač nemusel vědět. Získáte však špatný návrh databáze, dostanete špatný návrh programu, dostanete souběžnost při míchání pracovní zátěže, což může také vést k problémům s výkonem. Získáte vyvažování zátěže, získáte plánování kapacity, růst dat - to může způsobit zastavení nebo zpomalení databáze. Je to zajímavé, když se databáze téměř zaplní, zpomalí se. A můžete mít problém s datovými vrstvami, pokud jde o replikaci a nutnost replikace a nutnost zálohování a obnovy. Každopádně to je obecný přehled.
Jediná věc, kterou bych chtěl říci, je, že ladění databáze může být pouze tak obtížné a netriviální - a říkám to proto, že jsem to udělal hodně - a často budete objevovat jeho jako všechny situace v ladění, které jsem kdy zažil je první věc, kterou jste kdy viděli, je nepořádek. A musíte se pokusit přejít z nepořádku, abyste zjistili, jak došlo k nepořádku. A často, když se díváte na problém s databází, všechno, co se díváte, jsou zkorumpovaná data a vaše myšlení: „Jak se to sakra stalo?“
Každopádně předám Dezovi, který pravděpodobně řekne více slov moudrosti, než jsem vyšel. Nevím, jak ti přihrát míč, Dez.
Eric Kavanagh: Nechte to projít, držte se, vydržte.
Automatizovaný hlas: Linky účastníků byly ztlumeny.
Eric Kavanagh: Dobře, počkejte jednu sekundu, dovolte mi dát Dezovi míč.
Dez Blanchfield: Děkuji, Ericu. Ano, doktore Robine Bloore, jste skutečně nejprávnější: toto je téma, celoživotní bugbear, pokud mi uděláte omluvu, omlouvám se, že jsem tomu nemohl pomoci. Doufejme, že tam uvidíte moji první obrazovku, omlouvám se za problém s velikostí písma nahoře. Téma chyb je celodenní přednáška, v mnoha případech podle mých zkušeností. Je to tak široké a široké téma, takže se zaměřím na dvě klíčové oblasti, konkrétně na koncept toho, co považujeme za chybu, ale za programovací problém. Myslím, že v těchto dnech zavedení chyby samo o sobě je obecně zachyceno integrovaným vývojovým prostředím, i když se mohou jednat o dlouhodobé chyby. Ale často je to spíše případ profilování kódu a je možné napsat kód, který funguje, to by měla být chyba. Takže, můj titulní snímek sem, vlastně jsem měl kopii tohoto ve velmi vysokém rozlišení A3, ale bohužel se zničil v pohybu domu. Jedná se však o ručně psanou poznámku o programovém listu z roku 1945, kde údajně někteří lidé na Harvardské univerzitě v USA, jejich druhá sestava stroje jménem Mark II. Odebírali nějaký problém běžným jazykem, ale snažili se najít chybu, a ukázalo se, že došlo k něčemu mírně odlišnému od hardwaru a údajně softwarového problému.
Městský mýtus je tedy kolem 9. zářítis, 1945 tým na Harvardské univerzitě rozebíral stroj, narazil na něco, čemu říkali „štafeta sedmdesát“ - v těch dnech bylo programování prováděno ve fyzickém smyslu, vy jste si ovíjeli kód kolem desky, a tak jste efektivně naprogramovali stroj - a zjistili, že toto relé číslo sedmdesát bylo s tím něco v nepořádku, a ukáže se skutečný termín „bug“, který vznikl, protože to doslova byl můra - pravděpodobně tam byla můra zaklíněná mezi kusem měděného drátu z jednoho místa na druhé. A příběh pokračuje, že legendární Grace Hopper jako tento titulek, pro můj titulní snímek, „první skutečný případ nalezení chyby“, cituje bez citace.
Ale jak Robin zdůraznil dříve ve svém prvním snímku, koncept chyby jde tak daleko zpět, jak si dokážeme představit, že lidé dělají výpočet, pojmy jako patch. Termín „náplast“ pocházel ze skutečné pásky, která byla nalepena přes otvor na děrné kartě. Celé toto však spočívá v tom, že pojem „ladění“ vycházel z tohoto pojmu nalezení chyby ve fyzickém stroji.A od té doby používal tuto terminologii kolem pokusů o řešení problémů, buď ne tolik jako problémy s kódováním v programu, který se nezkompiluje, ale jako program, který nefunguje dobře. A konkrétně nebyl profilován jen najít věci jako nekonečné smyčky, které prostě nikam nechodí.
Ale máme také scénář a já myslel, že Id vložil pár vtipných skluzavek, než jsem se dostal do trochu podrobnějších detailů. Tady je klasická karikatura zvaná XKCD na webu a karikaturista má některé docela vtipné pohledy na svět. A tohle o dítěti zvaném „Little Bobby Tables“ a pravděpodobně jeho rodiče pojmenovali tohoto mladého chlapce Roberta); DROP TABLE Studenti; - a to se nazývá, a něco jako „Ahoj, tohle je vaše synová škola, která má nějaké potíže s počítačem,“ a rodiče odpoví: „Ach, drahý, něco zlomil?“ A učitel říká: „No, svým způsobem, “a učitel se ptá,„ opravdu jste pojmenovali svého syna Roberta); DROP TABLE Studenti; -? “A rodič říká:„ Ach ano, maličké Bobby tabulky, které mu říkáme. “Každopádně říkají, že nyní ztratili léta studentských záznamů, doufám, že jste šťastní. A odpověď zní: „Dobře, měli byste vyčistit a dezinfikovat své vstupy do databáze.“ A já používám to mnohokrát, abych mluvil o některých problémech, které máme při hledání věcí v kódu, že často se kód také nedívá na data. .
Další vtipný, nevím, jestli je to skutečné, nebo ne - mám podezření, že je to spoof - ale znovu se to dotkne i mé legrační kosti. Někdo mění poznávací značku na přední části svého automobilu, na podobné tvrzení, které způsobuje pokles databází v rychlostních kamerách a tak dále, že snímají poznávací značky automobilů. A vždycky na to odkazuji jako na to, že pochybuji, že každý programátor očekával zásah a běh jejich kódu skutečným motorovým vozidlem, ale nikdy to nepodceňuji - sílu rozzlobeného geeka.
(Smích)
Ale to mě vede k mému klíčovému bodu, myslím, a to je to, že jednou za čas jsme mohli ladit a profilovat kód jako pouhé smrtelníky. Ale jsem velmi toho názoru, že ten čas uplynul, a anekdoticky podle mých zkušeností, můj první - a tohle mě strašně stárne, jsem si jistý; Robin, vítejte, že se na mě budete bavit - ale historicky Ive pocházím z pozadí ve věku 14 let putujících po konci města a klepe na dveře datového centra s názvem „Data Com“ na Novém Zélandu a ptá se, zda Ve škole bych si mohl vydělat kapesné tím, že přijdu pozdě autobus domů, asi 25 km dojíždění každý den, vložím papír do pásků a pásky do páskových jednotek a budu jen obyčejným správcem. A kupodivu mi dali práci. Ale postupem času se mi podařilo dostat se do personálního obsazení a najít programátory a uvědomit si, že miluji kódování, a prošel jsem procesem běhu skriptů a dávkových úloh, což je na konci dne stále kód. Musíte psát skripty a dávkové úlohy, které vypadají jako mini programy, a pak projít celým procesem sedění na terminálu 3270 ručně psaným kódem.
Moje první zkušenost byla ve skutečnosti na terminálu teletypu, což byl ve skutečnosti fyzický er na 132 sloupcích. V podstatě uvažujte o tom, že jako velmi starý psací stroj s papírem, který jím procházel, protože nemají CRT trubku. A ladicí kód byl velmi netriviální záležitost, takže jste měli sklon psát celý svůj kód ručně, a pak se chovat jako pisatel, dělat, co je v jeho silách, aby se nedostaly chyby, do kterých se vplížit, protože je nesmírně frustrující, že to musíte říct jeden řádkový editor, který přejde na určitý řádek a pak na řádek a poté jej zadá zpět. Ale jednou za čas jsme takto psali kód a to je to, jak jsme ladili, a dostali jsme se velmi, velmi dobře. A ve skutečnosti nás to donutilo mít velmi dobré programovací techniky, protože to bylo opravdové potíže opravit. Cesta však prošla - a to vše bylo dobře známo - a šlo od zážitku z terminálu 3270 v mém světě k digitálnímu zařízení VT220, kde jste mohli vidět věci na obrazovce, ale znovu jste dělali to samé, co jste udělali na papírové páskové podobě ve formátu ed jen na CRT, ale byli jste schopni je vymazat snadněji a nemáte ten zvuk „dit dit dit dit“.
A pak víte, terminály Wyse - jako je Wyse 150, pravděpodobně moje oblíbené rozhraní k počítači vůbec - a pak PC a Mac, a v dnešní době moderní GUI a ID, které jsou založeny na webu. A řada programů prostřednictvím toho, programování v jednom a assembleru a PILOT a Logo a Lisp a a Fortran a Pascal a jazyky, které by lidi mohly krčit. Ale to jsou jazyky, které vás nutily psát dobrý kód; nedovolili vám uniknout špatným praktikám. C, C ++, Java, Ruby, Python - a my se dostaneme dále do této programovací fáze, dostaneme více skriptů, dostáváme se blíže a blíže k Structured Query Language a jazykům jako PHP, které se ve skutečnosti používají k vyvolání SQL. Smyslem je říct, že pocházím z mého pozadí, jsem se naučil mnoha způsoby a ti, kteří mi pomohli učit se, učili mi velmi dobré programovací postupy a velmi dobré postupy kolem designu a procesů, abych se ujistil, že jsem nezavedl kočár kód.
Programovací metody v těchto dnech, věci jako například strukturovaný dotazovací jazyk, SQL, jeho velmi silný, jednoduchý dotazovací jazyk. Ale Weve to změnil v programovací jazyk a já opravdu nevěřím, že SQL byl někdy navržen tak, aby byl moderním programovacím jazykem, ale Weve to zkosil, aby se z toho stal. A to zavádí celou řadu problémů, protože když uvažujeme ze dvou hledisek: z hlediska kódování az pohledu DBA. Je to velmi snadné přijít a představit chyby pro věci, jako jsou jen špatné programovací techniky, líné úsilí při psaní kódu, nedostatek zkušeností, klasický mazlíček, který mám například s lidmi SQL, kteří na webu Google skákají a hledají něco a hledají webovou stránku. dostal příklad a udělal kopii a vložení existujícího kódu. A pak replikovat špatné kódování, zanedbávat praktiky a uvádět je do výroby, protože se jim prostě daří dosáhnout požadovaných výsledků. Dostali jste další výzvy, například, v těchto dnech se všichni řítili k tomu, co nazýváme závod nula: snažíme se dělat všechno tak levné a tak rychle, že máme scénář, kde nezaměstnáváme méně placené zaměstnance. A to nemyslím nenápadným způsobem, ale nejsem odborníky na každou možnou práci. Kdysi kdysi něco s počítači bylo raketová věda; zapletl se do věcí, které zazněly a byly velmi hlasité, nebo šly do vesmíru, nebo inženýři byli silně kvalifikovaní muži a ženy, kteří udělali tituly a měli přísné vzdělání, které jim bránilo dělat bláznivé věci.
V dnešní době existuje spousta lidí, kteří se dostávají do vývoje a designu a databáze, kteří havent měli dlouholeté zkušenosti, havent měl nutně stejné školení nebo podporu. A tak skončíte scénářem tradičního amatérského versus odborníka. A tam je slavná linka, já si vlastně vzpomínám, kdo vytvořil nabídku, linka jde: "Pokud si myslíte, že jeho drahé najímání odborníka k práci, počkejte, až najmete několik amatérů, kteří vytvoří problém a musíte vyčistit to. “A tak SQL má tento problém a jeho velmi, velmi snadné se naučit, jeho velmi snadné použití. Ale podle mého názoru to není dokonalý programovací jazyk. Je velmi snadné dělat věci, jako je vybrat hvězdu odkudkoli a všechno to vtáhnout do programovacího jazyka, který vám vyhovuje, jako je PHP a Ruby nebo Python, a používat programovací jazyk, který jste nativně obeznámeni, k manipulaci s daty, spíše než dělat složitější dotaz v SQL. A my to vidíme hodně a pak se lidé diví, proč databáze běží pomalu; je to proto, že milion lidí se pokouší koupit lístek z online lístkového systému, kde udělá vybranou hvězdu odkudkoli.
Teď je to opravdu extrémní příklad, ale z toho všeho vycházíte. Takže, abych opravdu udeřil tenhle bod domů, tady je příklad, který hodně nosím. Jsem velký fanoušek matematiky, miluji teorii chaosu, miluji sady Mandelbrot. Na pravé straně je ztvárnění sady Mandelbrot, se kterými jsem si jistý, že jsou všichni dobře obeznámeni. A na levé straně je kousek SQL, který to vlastně činí. Teď pokaždé, když to někde umístím na obrazovku, slyším toto: „Bože můj, někdo vykreslil sérii Mandelbrot pomocí SQL, to myslíš vážně? To je šílené! “Celým smyslem je ilustrovat to, co jsem tam právě nastínil, a to ano, ve skutečnosti nyní můžete programovat téměř cokoli v SQL; je to velmi silně vyvinutý, výkonný a moderní programovací jazyk. Když to byl původně dotazovací jazyk, byl navržen tak, aby pouze zvedl data. Nyní jsme dostali velmi složité konstrukty a dostali uložené procedury, aplikovali jsme metodiku programování na jazyk, a tak je to pro špatné programovací praktiky, nedostatek zkušeností, vyjmutí a vložení kódu, nízký počet zaměstnanců se slabým platem velmi snadné být vysoce placeným personálem, lidé předstírat, že vědí, ale musí se o práci učit.
Celá řada věcí, kde profilování kódu a co nazýváme ladením, což není tolik hledání chyb, které přestanou programy fungovat, ale chyby, které jen poškozují systém a špatně strukturovaný kód. Když se nyní podíváte na tuto obrazovku a myslíte si, že je to prostě její druh roztomilé a myslíte si: „Páni, to je skvělá grafika, mám rád to spustit.“ Ale představte si, že běží na nějaké obchodní logice. Vypadá to docela elegantně, ale mluví o matematicky graficky vykreslené teorii chaosu, ale když přemýšlíte o tom, k čemu by to mohlo být použito v nějaké obchodní logice, získáte obrázek velmi rychle. A abych to opravdu ilustroval - a omlouvám se, že barvy jsou obrácené, mělo to být černé pozadí a zelené jako zelená obrazovka, ale stále si to můžete přečíst.
Šel jsem a rychle jsem se podíval na příklad toho, co byste mohli potenciálně udělat, kdybyste byli opravdu blázniví a neměli žádné zkušenosti a přišli z jiného pozadí programování a aplikovali jako C ++ na SQL, abych opravdu ilustroval můj názor, předtím Předám našemu naučenému hostu z IDERA. Toto je strukturovaný dotaz, který je psán jako C ++, ale je kódován v SQL. A skutečně se to provádí, ale provádí se po dobu asi tří až pěti minut. A zdánlivě táhne zpět jednu řadu dat z více databází, vícenásobných spojení.
Opět platí, že pokud nemáte správné nástroje, pokud nemáte správné platformy a prostředí, abyste je mohli chytit, a dostanou se do výroby, a pak máte 100 000 lidí, kteří zasáhnou systém každý den, hodinu nebo minutu, velmi brzy skončíte s černobylským zážitkem, kdy se velké železo začne roztavovat a pohřbívat se do jádra planety, protože tento kus kódu by se nikdy neměl dostat do výroby. Vaše systémy a vaše nástroje, omluvte mě, by si to měly vyzvednout, než se dostane kamkoli blízko - dokonce i během testovacího procesu, dokonce i prostřednictvím integrace UAT a systémů, by měl být tento kód vyzvednut a zvýrazněn a někdo by měl být odložen stranou a říká: „Podívejte, to je opravdu pěkný kód, ale umožňuje získat DBA, která vám pomůže správně sestavit strukturovaný dotaz, protože upřímně řečeno, je to prostě ošklivé.“ A adresy URL tam můžete jít a podívat se - to se označuje jako nejsložitější SQL dotaz, jaký jste kdy napsali. Protože mi věřte, že to ve skutečnosti kompiluje, běží. A pokud to vyjmete a vložíte a vysmíváte se databázi, je to něco, co byste měli sledovat; Pokud máte nástroje pro sledování databáze, zkuste to roztavit po dobu tří až pěti minut, zavolat zpět, co je jeden řádek.
Abych to shrnul, má to na paměti moje celé pozadí v kódování mě naučilo, že můžete dát lidem zbraň, a pokud nebudou opatrní, budou se střílet do nohy; trik je ukázat jim, kde je bezpečnostní mechanismus. Se správnými nástroji a správným softwarem na dosah ruky, po dokončení kódování si můžete zkontrolovat svůj kód, můžete najít problémy profilováním kódu, můžete efektivně najít nechtěné chyby, které jsou problémy s výkonem, a jak jsem již řekl dříve, , jednou za čas, můžete to udělat při pohledu na zelenou obrazovku. Už nemůžete; existují stovky tisíc řádků kódu, jsou nasazeny desítky tisíc aplikací, v některých případech jsou miliony databází a dokonce i super lidé to nemohou dělat ručně. Doslova potřebujete správný software a správné nástroje na dosah ruky a potřebujete tým, aby tyto nástroje používal, abyste tyto problémy mohli najít a velmi rychle je vyřešit, než se dostanete k věci, zatímco Dr. Robin Bloor zdůraznil, věci se buď katastrofální, a věci vyhodí do vzduchu, nebo častěji, prostě vás začnou stát hodně dolarů a spoustu času a úsilí a ničí morálku a věci, když nedokážou zjistit, proč se věci berou dlouhá doba k běhu.
A s ohledem na to se chystám předat našemu hostovi a těším se, až uslyším, jak vyřešili tento problém. A zejména demo, které si myslím, že se chystá dostat. Ericu, jdu zpět.
Eric Kavanagh: Dobře, Berti, vezmi to pryč.
Bert Scalzo: OK, díky. Bert Scalzo zde z IDERA, produktový manažer našich databázových nástrojů. A já budu mluvit o ladění. Myslím si, že jedna z nejdůležitějších věcí, kterou Robin řekl dříve - a je to pravda, je to, že ladění je obtížné a netriviální, a když jdete do databáze, odladí jeho řád ještě závažnější a netriviální - takže byl důležitý citát.
OK. Chtěl jsem začít s historií programování, protože mnohokrát vidím lidi, kteří neodstraňují, nepoužívají debugger, prostě programují s jakýmkoli jazykem, který používají, a mnohokrát mi řeknou: „No, ty debuggerské věci jsou nové a my jsme je zatím ještě nepoužívali. “A tak to, co dělám, jim ukážu tento časový rozvrh, jakýsi pre-historie, stáří, středověk, jeho druh slova, kde jsme byli podmínky programovacích jazyků. A my jsme měli velmi staré jazyky, počínaje rokem 1951 s kódem sestavení, a Lisp a FACT a COBOL. Pak se dostaneme do další skupiny, Pascals a Cs a pak do další skupiny, C ++, a podíváme se, kde je ten otazník - ten otazník je přibližně v letech 1978 až 1980. Někde v tomto rozsahu jsme měli debugovací nástroje, které máme k dispozici, a tak říkají: „Hej, já nepoužívám debugger, protože to je jedna z těch nových věcí,“ pak musíte začít programovat, víte, v padesátých letech, protože to je jediný způsob, jak byste se dostali pryč s tímto nárokem.
Teď další věc, která je na tomto grafu vtipná, je, že Dez právě udělal komentář k Grace Hopperovi, vlastně jsem Grace znal, takže je to trochu vtipné. A další věc, na které jsem se zasmál, je, že mluvil o teletypech a já jsem tam seděl a pokračoval: „Člověče, to byl největší skok, jaký jsme kdy měli v produktivitě, když jsme šli od karet k typům, to byl ten největší skok vůbec.“ Takže , a já jsem zde naprogramoval ve všech jazycích, včetně SNOBOL, o kterém nikdo předtím neslyšel, bylo to CDC, Control Data Corporation, takže myslím, že jsem pro toto odvětví trochu starý.
Dez Blanchfield: Chtěl jsem říct, že jsi tam strašně zestárl.
Bert Scalzo: Jo, říkám ti, cítím se jako děda Simpson. Takže se podívám na ladění a na různé způsoby provádění ladění. Dalo by se mluvit o tom, co všichni považujeme za tradiční, jak se dostat do debuggeru a překročit kód. Ale lidé budou také používat svůj kód; to je místo, kde přidáváte příkazy do svého kódu a možná vytvoříte výstupní soubor, sledovací soubor nebo něco, a tak svůj kód vybavíte. To bych považoval za ladění, je to o něco těžší, způsob, jak to udělat, ale počítá se. Ale také jsme dostali slavné prohlášení: vy sledujete a lidé skutečně vkládají prohlášení a já jsem vlastně viděl nástroj, kde - a jeho databázový nástroj - kde, pokud nevíte, jak používat debugger, stisknete tlačítko a bude to držet prohlášení v celém kódu pro vás a pak, když jste hotovi, stiskli jste další tlačítko a to je odstranilo. Protože to je, jak mnoho lidí ladí.
A důvod, proč ladíme, je dvojí: v prvé řadě musíme najít věci, které činí náš kód neúčinným. Jinými slovy, obvykle to znamená logickou chybu nebo jsme vynechali obchodní požadavek, ale co to je, kód není účinný; nedělá to, co jsme očekávali. Jindy jdeme a děláme ladění, je to pro efektivitu a to by mohla být logická chyba, ale co to je, je, že jsem udělal správnou věc, prostě se nevrátil dostatečně rychle. Teď říkám, že bod, protože profilers pravděpodobně lepší pro tento druhý scénář a měli mluvit o debuggers a profilers. Kromě toho existuje tento koncept vzdáleného ladění; je to důležité, protože mnohokrát, pokud sedíte na svém osobním počítači a používáte debugger, který zasáhne databázi, kde je kód ve skutečnosti spuštěn v databázi, skutečně děláte to, co se nazývá vzdálené ladění. Možná si to neuvědomujete, ale to se děje. A pak je velmi běžné, že s těmito debuggery mají body zlomu, sledovací body, krok vpřed a krok zpět a některé další běžné věci, které já za chvíli ukážu těm na snímku obrazovky.
Nyní profilování: můžete provádět profilování několika různými způsoby. Někteří lidé říkají, že zátěž zachycuje a přehrává, kde zachycuje vše, co se počítá jako profilování. Moje zkušenost byla o to lepší, když provedl odběr vzorků. Neexistuje žádný důvod chytit každé prohlášení, protože některé výkazy mohou běžet tak rychle, že vám to nezajímá, co se opravdu snažíte vidět, dobře, což jsou ty, které se stále znovu a znovu objevují, protože běží příliš dlouho . Takže někdy může profilování znamenat spíše vzorkování než spuštění celé věci. A obvykle získáte nějaký výstup, který můžete použít, nyní, který by mohl být vizuální uvnitř vývojového prostředí IDE, kde vám to může poskytnout jako histogram výkonu různých řádků kódu, ale také to může stále je, že vytváří trasovací soubor.
Profiléři se poprvé objevili v roce 1979. Takže tito byli už dlouho. Skvělé pro nalezení spotřeby zdrojů nebo problémů s výkonem, jinými slovy, že věc účinnosti. Obecně řečeno, jeho oddělené a odlišné od debuggeru, i když jsem pracoval s debuggery, které dělají oba současně. A zatímco si myslím, že profilers jsou zajímavější z těchto dvou nástrojů, pokud mám pocit, že není dost lidí na ladění, pak rozhodně není dost lidí na profil, protože jeden z deseti debuggerů bude profilovat, zdá se. A to je škoda, protože profilování může opravdu udělat obrovský rozdíl. Nyní, databázové jazyky, jak jsme již dříve hovořili, jste dostali SQL - a jaksi jsme přinutili kulatý kolík do čtvercové díry a donutili ho, aby se stal programovacím jazykem - a Oracle.To je PL / SQL - to je procedurální jazyk SQL - a SQL Server, jeho Transact-SQL, SQL-99, SQL / PSM - pro, myslím, jeho procedura uložený modul. Postgres mu dává jiné jméno, DB2 ještě jiné jméno, Informix, ale jde o to, že každý si vynutil konstrukty typu 3GL; jinými slovy, FOR smyčky, u proměnných deklarací a všechny další věci, které jsou cizí pro SQL, jsou nyní součástí SQL v těchto jazycích. A tak musíte být schopni ladit PL / SQL nebo Transact-SQL stejně jako program Visual Basic.
Nyní, databázové objekty, je to důležité, protože lidé řeknou: „No, co musím ladit v databázi?“ A odpověď je, dobře, cokoli můžete uložit do databáze jako kód - pokud dělám T- SQL, nebo PL / SQL - a Im ukládání objektů do databáze, pravděpodobně uložená procedura nebo uložená funkce. Ale také spouští: spoušť je něco jako uložená procedura, ale vystřelí na nějakou událost. Nyní někteří lidé do svých spouštěčů vloží jeden řádek kódu a zavolají uloženou proceduru, aby si zachovali veškerý uložený kód a procedury, ale je to stejný koncept: stále to může být spouštěč, co iniciuje celou věc. A pak jako Oracle mají něco, čemu se říká balíček, což je něco jako knihovna, pokud chcete. Vložili jste 50 nebo 100 uložených procedur do jedné skupiny, nazvané balíček, takže je to jako knihovna. Takže tu je debugger stará cesta; Toto je vlastně nástroj, který skutečně vstoupí a vloží všechny tyto debugovací příkazy do kódu pro vás. Takže všude, kde vidíte blok ladění, neodstraňujte, spouštění a sledování automatického ladicího programu, to vše bylo zaseknuto nějakým nástrojem. A řádky mimo to, což je menšina kódu, to je metoda nemanuálního ladění.
A důvod, proč to uvádím, je, že pokud se to snažíte ručně, musíte ve skutečnosti napsat více ladicího kódu, který vložíte do všech těchto příkazů, než jste s kódem. Takže, i když to může fungovat a i když je to lepší než nic, je to velmi obtížný způsob ladění, zejména od té doby, co když to trvá 10 hodin, než se tato věc spustí, a kde má problém, je v řádku tři? Kdybych dělal interaktivní ladicí relaci, věděl bych to na řádku tři - pět minut do ní - hej, tady je problém, můžu skončit. Ale s tímto, musím počkat, až to běží, celou cestu k dokončení, a pak jsem se musel podívat na nějaký stopový soubor, který pravděpodobně obsahuje všechna tato prohlášení, a zkusit najít jehlu v kupce sena. Opět je to lepší než nic, ale nebyl by to nejlepší způsob práce. Teď je to, jak by ten soubor vypadal jako ten, který pochází z předchozího snímku; jinými slovy, spustil jsem program a jeho právě dostal spoustu prohlášení v tomto souboru trasování a možná i nemusí být schopen sifonovat skrz to a najít to, co musím najít. Takže opět, nejsem si tak jistý, že to je způsob, jakým byste chtěli pracovat.
Nyní, interaktivní debuggery - a pokud jste použili něco jako Visual Studio k psaní programů, nebo Eclipse, youve měli debuggery a použili jste je s jinými jazyky - prostě si nemyslete, že je použijete tady ve své databázi. A jsou tam nástroje, jako je náš DB Artisan a náš Rapid SQL, toto je Rapid SQL zde, které mají debugger, a vidíte na levé straně, mám uloženou proceduru nazvanou „check for duplicates.“ V podstatě je to prostě jít a podívat se a uvidíme, jestli mám v tabulce více řádků se stejným názvem filmu. Databáze je tedy určena pro filmy. A vy jste mohli vidět na pravé straně, na horní třetině, já jsem dostal svůj zdrojový kód uprostřed, Ive dostal, co se nazývá moje sledovací proměnné a moje zásobníky zásobníku volání, a pak na spodní straně Ive dostal nějaké výstupy. A co je zde důležité, když se podíváte na tu první červenou šipku, když přejdu myší na proměnnou, ve skutečnosti vidím, jaká hodnota je v té proměnné v tu chvíli v čase, když Im procházím kódem. A to je opravdu užitečné, a pak mohu krokovat jeden řádek najednou skrz kód, nemusím říkat vykonat, mohl bych říci krok za řádkem, nechal jsem se podívat, co se stalo, krok další řádek, nechal mě vidět, co se stalo, a Dělám to v databázi. A i když na svém počítači sedím na Rapid SQL a moje databáze je v cloudu, stále mohu provést vzdálené ladění a vidět ho a ovládat odtud, a ladit stejně, jako bych to měl s jakýmkoli jiným jazykem.
Teď, další šipka tam - můžete vidět trochu jako šipka směřující doprava, směrem k výstupu DBMS, to je místo, kde je můj kurzor v tuto chvíli - jinými slovy, Ive vystoupila a to je kde jsem v tuto chvíli. Pokud tedy řeknu: „Krok znovu,“ jdu na další řádek. Teď pod ní uvidíte červenou tečku. No, to je bod zlomu, který říká: „Ahoj, já nechci překročit tyto řádky.“ Pokud chci jen přeskočit všechno a dostat se tam, kde ta červená tečka, můžu stisknout tlačítko běh a odtud půjde buď konec, nebo do bodu přerušení, pokud jsou nastaveny nějaké body přerušení, a pak se zastaví a dovolte mi provést krok znovu. A důvod, proč je to všechno důležité a silné, je, protože když dělám tohle všechno, co se děje uprostřed a dokonce i dole - ale co je nejdůležitější uprostřed - se změní a já vidím hodnoty ze svých proměnných, mohu viz můj sled zásobníku hovorů, víte, a tak jsou všechny tyto informace zobrazeny jako Im procházím kódem, takže ve skutečnosti vidím a cítím a chápu, co se děje a jak kód ve skutečnosti pracuje v době provádění . A obvykle najdu problém, pokud nějaký existuje, nebo pokud jsem dost dobrý na to, abych ho chytil.
Dobře, teď budu mluvit o profilerovi, a v tomto případě je to profiler, který vidím přes debugger. Pamatujete, že jsem někdy řekl, že jsou oddělené a někdy mohou být spolu? V tomto případě a znovu, Im v Rapid SQL, a já vidím, tam je okraj, na levé straně, vedle čísla řádků. A co to je, je to počet sekund nebo mikrosekund, které trvalo provedení každého řádku kódu, a vidím to jasně, celý můj čas je stráven v této jedné smyčce FOR, kde Im vybírám všechno z tabulky. A tak, co se děje uvnitř této smyčky FOR, je asi něco, na co se musím podívat, a pokud to dokážu zlepšit, vyplatí dividendy. Nebudu mít žádné vylepšení tím, že pracuji na těch linkách, které mají jako 0,90 nebo 0,86; tam není moc času. Nyní, v tomto případě a znovu, v Rapid SQL, jste viděli, jak mohu dělat profilování, smíchané s mým laděním. Nyní je to, co je pěkné, rychlé SQL také vám umožňuje dělat to opačným způsobem. Rapid SQL vám umožňuje říct: „Víte co? Nechci být v debuggeru, chci to jen spustit a pak se chci podívat na graficky nebo vizuálně stejný typ informací. “
A vidíte, že Im již v debuggeru a spouští program a po dokončení provádění mi dává grafy, které mi mají co říci, takže vidím, že jsem dostal jedno prohlášení, které vypadá jako jeho převzetí většiny z koláče graf a když se podívám, vidím na této mřížce směrem dolů, řádek 23, znovu je tu smyčka FOR: HES zabírá nejvíce času, je to vlastně ten tmavě červený žvýkání všech koláčových grafů. A to je další způsob, jak udělat profilování. V našem nástroji náhodou nazýváme tento „analytik kódu“. Ale je to v podstatě jen profiler oddělený od debuggeru. Někteří lidé to rádi dělají prvním způsobem, jiní to rádi dělají druhým způsobem.
Proč provádíme ladění a profilování? Není to proto, že chceme psát největší kód světa a získat odměnu - to může být náš důvod, ale to není důvod, proč to děláte - slíbili jste podnikání, že uděláte něco správně, že váš program bude efektivní. To je to, co budete používat debugger. Kromě toho koncoví obchodní uživatelé; Nejsou příliš trpěliví: chtějí výsledky ještě předtím, než stisknou klávesu. Měli číst jejich mysl a dělat všechno okamžitě. Jinými slovy, musí být efektivní. A na to bychom použili profiler. Nyní, bez těchto nástrojů, opravdu věřím, že jsi ten chlap v obleku s lukem a šípy a střílíš na cíl a jsi zavázán. Protože jak zjistíte, jak se program provádí pouhým pohledem na statický kód a jak zjistíte, který řádek je místem, kde by skutečně strávil nejvíce času při provádění, znovu jen prostým pohledem na statický kód? Kontrola kódu může nebo nemusí ukázat některé z těchto věcí, ale neexistuje žádná záruka, že by je kontrola kódu našla všechny. Pomocí debuggeru a profileru byste měli být schopni najít všechny ty chyby.
Dobře, já tady udělám skutečné rychlé demo. Není to můj záměr tlačit produkt, jen vám chci ukázat, jak vypadá debugger, protože mnohokrát lidé řeknou: „Nikdy jsem jednoho z nich neviděl.“ A vypadá to docela slušně na snímcích obrazovky, ale co Vypadá to, že když je v pohybu? Takže tady na mé obrazovce Im spustím náš produkt DB Artisan; máme tam také debugger. DB Artisan je určen spíše pro DBA, Rapid SQL je více pro vývojáře, ale viděl jsem vývojáře, kteří používají DB Artisan, a Ive jsem viděl DBA, kteří používají Rapid. Takže, nenechte se chytit produktu. A tady mám na výběr ladění, ale než spustím ladění, budu extrahovat tento kód, abyste viděli, jak tento kód vypadá, než ho začnu spouštět. Tady je přesně stejný kód, jaký byl na snímku obrazovky, toto je moje kontrola duplikátů. A chci to odladit, takže stisknu ladění. A teď to chvíli trvá a řeknete: „No, proč to chvíli trvá?“ Pamatujete si vzdálené ladění: ladění se skutečně děje na mém databázovém serveru, ne na mém PC. Takže to muselo jít tam a vytvořit relaci tam, vytvořit vzdálenou ladicí věc, připojit moji relaci k této vzdálené ladicí relaci a nastavit komunikační kanál.
Takže teď, tady je můj šíp, je to nahoře nahoře, na prvním řádku, to je místo, kde jsem v kódu. A pokud tam stisknu třetí ikonu, což je krok do, uvidíte, že se šipka právě pohnula, a pokud ji stále tlačím, uvidíte, že se neustále pohybuje. Nyní, pokud jsem chtěl jít celou cestu dolů k této smyčce FOR, protože vím, že to je místo, kde je problém, mohu nastavit bod přerušení. Myslel jsem, že jsem to stanovil. Ach střílet, měl jsem jednu z mých kláves pro snímání obrazovky mapovanou na stejnou klávesu jako debugger, což způsobuje zmatek. Dobře, tak jsem tam ručně nastavil bod přerušení, takže nyní místo toho, abych udělal krok, krok, krok, krok, dokud se tam nedostanu, vlastně mohu jen říct: „Jděte do toho a spusťte tuto věc,“ a to se zastaví. Všimněte si, že mě to posunulo až na místo, kde je zlom, takže jsem nyní v provozu této smyčky, vidím, na co jsou nastaveny všechny mé proměnné, což není překvapením, protože jsem je všechny inicializoval nula. A teď mohu vstoupit do této smyčky a začít se dívat na to, co se děje uvnitř této smyčky.
Takže, teď to bude dělat výběr z mých výpůjček a můžu se nad tím chlápkem dívat a vypadat, že dva, dva jsou větší než jeden, takže pravděpodobně udělá další kousek tohoto kódu. Jinými slovy, něco našlo. Jen se do toho pustím a nechám to běžet. Nechci zde projít všechno; Chci vám ukázat, že když je debugger hotový, skončí stejně jako normální program. Mám stanoven bod přerušení, takže když jsem řekl, že běžel, prostě se vrátil k dalšímu bodu přerušení. Im nechat to běžet až do konce, protože to, co chci, abys viděl, je to, že debugger nemění chování programu: když je hotovo běh, měl bych získat přesně stejné výsledky, kdybych to spustil ne uvnitř debuggeru.
A s tím se chystám pozastavit demo a vrátit se, protože se chceme ujistit, že máme čas na otázky a odpovědi. A tak to otevřu pro otázky a odpovědi.
Eric Kavanagh: Dobře, Robine, možná otázka od tebe a pak pár od Deze?
Robin Bloor: Jo, určitě to samozřejmě považuji za fascinující. Ive pracoval s takovými věcmi, ale nikdy jsem s ničím podobným v databázi nepracoval. Můžete mi poskytnout představu o tom, k čemu lidé používají profiler? Protože to vypadá, protože se dívají - protože předpokládám, že jsou - dívají se na problémy s výkonem, pomůže vám to rozlišovat mezi tím, kdy databáze zabere čas a kdy kód zabere čas?
Bert Scalzo: Víte, to je fantastická otázka. Řekněme, že pracuji v jazyce Visual Basic, a já, uvnitř mého jazyka, budu volat Transact-SQL nebo PL / SQL. Dovolte mi provést PL / SQL, protože Oracle s nástroji Microsoft nehraje dobře vždy. Mohl bych profilovat svůj kód jazyka Visual Basic a profil tam může říkat: „Hej, volal jsem tuto uloženou proceduru a trvalo to příliš dlouho.“ Ale pak se můžu dostat do uložené procedury a mohu udělat databázový profil na uložené Postupujte a řekněte: „Dobře, ze 100 výroků, které jsou zde, je tu pět, které způsobovaly problém.“ A tak možná budete muset udělat tým tagů, kde budete muset použít více profilerů.
Myšlenka je, pokud vám kdykoli řekneme, že problém s výkonem je ve vaší databázi, může vám databázový profil pomoci najít jehlu v kupce sena, na které jsou ve skutečnosti ta prohlášení, kde máte problém. Říkám vám další věc, která se objevila s profilováním: pokud máte kus kódu, který se nazývá milionkrát, ale trvá to jen mikrosekundu každý z miliónkrát, ale to se nazývá milionkrát, co by profiler ukázal , ta věc běžela tolik časových jednotek. A i když kód může být vysoce účinný, můžete vypadat a říkat: „Ooh, dělali toto volání na tento kus kódu příliš často. Možná bychom to měli nazývat jen tak často, než pokaždé, když zpracováváme záznam, “nebo tak něco. A tak můžete skutečně zjistit, kde je účinný kód, který se právě volá příliš často, a to je vlastně problém s výkonem.
Robin Bloor: Jo, to je úžasné. Nikdy jsem to neudělal. Vidíte, samozřejmě, když jsem měl problémy s databází, bylo to, jako bych se tak či onak zabýval buď databází, nebo kódem; Nikdy jsem s nimi nemohl jednat současně. Ale znovu jsem to neudělal - nikdy jsem se vlastně nepodílel na tvorbě aplikací, kde jsme měli uložené procedury, takže myslím, že jsem se ve skutečnosti nikdy nedostal do problémů, které mě používaly k divokému, myšlence, že jsi rozdělil kód mezi databáze a program. Ale ano, udělejte vše - Předpokládám, že odpovědi budou ano, ale je to součást činnosti vývojového týmu, když se tak či onak snažíte opravit něco, co je rozbité, nebo se možná pokusit přinést novou aplikaci dohromady. Ale přizpůsobuje se to všem ostatním složkám, které bych v prostředí očekával? Mohu očekávat, že to dokážu spojit se všemi svými testovacími balíčky a všemi dalšími věcmi, které budu dělat, a se svými věcmi pro řízení projektu, je to, jak všechny tyto klipy dohromady?
Bert Scalzo: Ano, může se stát součástí jakéhokoli strukturovaného procesu, který bude vyvíjet vaše programovací nebo vývojové úsilí. A je to vtipné, minulý týden jsem měl zákazníka, který vytvářel webovou aplikaci, a jejich databáze byla historicky malá, a proto skutečnost, že nebyli velmi dobří programátoři, jim nikdy neublížila. Jejich databáze se v průběhu let rozrostla a nyní to trvá 20 sekund na webové stránce, když řeknete: „Přihlaste se a dejte mi data, abych viděl“, a když se obrazovka skutečně objeví, a tak nyní její problém s výkonem. A věděli, že problém nebyl v žádné z jejich Java nebo na jiných místech. Měli však tisíce uložených procedur, a tak museli začít profilovat uložené procedury, aby zjistili, proč tato webová stránka trvá 20 sekund, než se objeví? Ve skutečnosti jsme zjistili, že se v jednom ze svých vybraných výroků připojili karteziánští, a nevěděli jsme to.
Robin Bloor: Wow.
Bert Scalzo: Ale někdo mi jednou řekl: „Dobře, jak by mohli mít kartézské spojení a neví to?“ A tohle zní opravdu hrozně; Někdy programátor, který není příliš spokojený s SQL, udělá něco, co mi dá kartézské spojení, ale pak mi vrátí pouze první záznam, takže vím, že něco mám, a potřebuji pouze ten první. A tak si neuvědomují, že právě přinesli zpět miliardu záznamů nebo prohlédli miliardu záznamů, protože dostali ten, o který se zajímali.
Robin Bloor: Páni, já vím, to se říká - no, to je to, o čem se dělal Dez, pokud jde o lidi, kteří nejsou tak kvalifikovaní, jak by snad měli být, víte. Pokud jste programátor, měli byste vědět, jaké jsou důsledky vydání jakéhokoli příkazu. Opravdu, není tu žádná omluva této úrovně hlouposti. Předpokládám také, že jste v tomto ohledu nějakým způsobem pouhá jazyková agnostika, protože to vše se zaměřuje na stranu databáze. Mám v tom pravdu? Je to stejné, cokoli, co používáte na straně kódování?
Bert Scalzo: Absolutně to můžete udělat ve formátu Fortran nebo C nebo C ++. Ve skutečnosti, na některých Unixech to můžete dokonce udělat pro jejich skriptovací jazyky; ve skutečnosti poskytují stejné nástroje. A pak se chci vrátit na vteřinu za to, co jste řekl, bez omluvy. Dám programátorům jednu přestávku, protože nemám rád házení programátorů pod autobus. Problém je však ve skutečnosti v akademickém prostředí, protože když se naučíte, jak být programátorem, učili jste rekordní myšlení. Nejste učeni množinovému myšlení, a to je to, co Structured Query Language nebo SQL pracuje se sadami; proto máme spojení, křižovatku a minus operátora. A to je někdy velmi těžké pro osobu, která nikdy nemyslela, co se týče množin, odejít, pustit rekordní zpracování a pracovat se sadami.
Robin Bloor: Jo, jsem s tebou. Chci říct, teď to je otázka vzdělání; Myslím, že to je zcela vzdělávací záležitost, myslím, že je přirozené, aby programátoři postupovali. A SQL není procedurální, jeho deklarativní. Ve skutečnosti jen říkáte: „To je to, co chci, a je mi jedno, jak to děláte,“ víš? Zatímco u programovacích jazyků jste si často stáhli rukávy a ztratili jste se na minutě dokonce i při správě počtů, zatímco jste to udělali. Nemám ruku -
Bert Scalzo: Ne, OK, pokračujte.
Jo, chtěl jsem říci, že jsi uvedl další příklad, že by profiler dobře chytil ten druh záznamu s tímto zpracováním záznamu v čase. Někdy programátor, který umí dobře zaznamenat logiku, nedokáže přijít na to, jak provést program SQL. Řekněme, že dělá dvě smyčky FOR a v podstatě se připojí, ale dělá to na straně klienta. Hle, dělá stejný efekt jako spojení, ale dělá to sám a profil by to chytil, protože byste pravděpodobně nakonec strávili více času děláním spojení ručně, než necháte to udělat pro vás databázový server.
Robin Bloor: Jo, to by byla katastrofa. Chci říct, jen bys se házel kolem. Thrashings vždy špatné.
Každopádně předám Dezovi; Určitě mám nějaké zajímavé otázky.
Dez Blanchfield: Děkuji, jo, ano. Připojím se k vám v programátorech, kteří neházejí pod autobus. Myslím, že jsem strávil příliš mnoho let v mém životě tím, že jsem sám kodérem, na všech úrovních, víš, jestli je to, jak jsi řekl, seděl na příkazové řádce stroje Unix a v některých případech jsem se dokonce podílel na několik různých portů Unixu z jedné hardwarové platformy na druhou. A dokážete si představit, jaké výzvy jsme tam měli. Skutečností však jsou heres, které dostanou kartu vězení pro každého kodéra a skripta na světě. Je to raketová věda, doslova psát opravdu těsně, pokaždé, je to raketová věda. A slavné příběhy lidí jako Dennis Ritchie a Brian Kernahan, kteří samostatně pracují na nějakém kódu, a poté se obrátí na chat s recenzemi kódu nad kávou a zjistí, že napsali přesně stejný kus kódu, přesně ve stejném programu, přesně v stejně. A udělali to v C. Ale ta puristická úroveň programování existuje velmi zřídka.
Skutečnost je taková, že každý den je to pouze 24 hodin denně, sedm dní v týdnu a my prostě musíme dělat věci. A tak, pokud jde o nejen tradiční programátory, DBA a kodéry a skripty, sysadmin a síťové administrátory a bezpečnostní personál, a všechno, co se v těchto dnech až k datům občanů týká; slyšíme, všichni se jen snaží dělat svou práci. A tak si myslím, že skvělý s sebou to celé je, že jsem miloval vaše demo a měl jsem rád s sebou, že jste nás tam před chvílí opustili, když jsem mluvil s Robinem o tom, že to má něco zvláštního - možná ne tolik výklenek - ale široký prostor, na který se vztahuje, pokud jde o opravu kódu a SQL a databází. Ale byl jsem opravdu nadšený, když jsem vás slyšel říkat, že byste to mohli strčit do shellového skriptu a najít nějaké problémy, protože víte, v dnešní době a věku vždy pracovali na co nejnižší ceně.
Důvodem, proč si někde koupit tričko s $ 6, je to, že někdo postavil systém dostatečně levně, aby skutečně vyráběl a dodával a logisticky dodával a prodával a prodával a prodával a přijímal platby online, aby získal tričko s $ 6. A to se nestane, pokud jste lidem dostávali 400 000 dolarů ročně, aby kód psali dokonale; je to jen celý vývoj. Takže, v tomto bodě, myslím, že jedna z otázek, které tě opravdu miluji, abys nám dal více informací, je to, co je šířka a dosah typu lidí, které v současné době vidíte a které používají tyto druhy nástrojů k profilování kódu a vzhledu pro problémy s výkonem? Zpočátku, historicky, odkud pocházejí? Byly to velké inženýrské domy? A pak, pokud jde o budoucnost, mám pravdu v domnění, že stále více společností implementuje tento nástroj nebo tyto nástroje, aby se pokusily pomoci kodérům, kteří vědí, kdo právě dělá věci, aby dokončil práci a dostat to ze dveří? A někdy potřebujeme kartu s odchodem z vězení? Mám pravdu, když jsem si myslel, že jsme se historicky více zaměřili na vývoj a vývoj? To se teď, jak řekl Robin, dostávaly méně, akademický přístup a nyní jeho samouk, nebo kód pro vkládání a vkládání, nebo jen stavěl věci? A odpovídá to typu lidí, kteří nyní berou tento produkt?
Bert Scalzo: Jo, přesně tak. A já vám ukážu velmi konkrétní příklad, chceme jen udělat práci, protože obchodní lidé nechtějí dokonalost. Je to jako počítačová šachová hra: šachová hra nehledá dokonalou odpověď; hledá odpověď, která je dostatečně dobrá v rozumném množství času, takže to je, jak programujeme. Ale co teď zjistím, je, že většina lidí místo toho, aby řekla, že chce v rámci testování jednotek profiler - což je způsob, jakým bych to udělal, protože to nevidím jako ztrátu času - co se děje, je to, že se to dělá později, někdy během testování integrace nebo stresového testování, pokud mělo štěstí. Ve většině případů však došlo k eskalaci, kdy se něco dostalo do výroby, chvíli to běželo, možná dokonce běželo roky, a teď to nefunguje dobře a nyní jej dobře profiluje. A to se nyní zdá být běžnějším scénářem.
Dez Blanchfield: Jo, a myslím si, že termín „technický dluh“ je pravděpodobně jeden, koho znáte víc; Znám Robina a určitě ano. Domnívám se, že v dnešní době, zejména v agilních přístupech k rozvoji a budování systému, je koncept technického dluhu velmi skutečnou věcí a ve skutečnosti to v projektech zohledňujeme. Vím, myslím, weve dostal naše vlastní projekty, jako je Media Lens a další, kde weve dostal kódování děje každý den, a různé věci napříč Bloor Group. A kdykoli jsme něco stavěli, díváme se na to, dívám se na to a vždy se dívám na to, z čeho to bude stát, abych to napravil hned teď, versus mohu to jen dostat do plechovky a dostat to tam, a pak se dívat a uvidíme, jestli se to bude zlomit. A zdědím tento technický dluh, o kterém vím, že musím kroužit později a opravit.
A myslím tím, že jsem to udělal za posledních sedm dní: napsal jsem pár nástrojů a skriptů, napsal jsem pár kusů jazyka Python a Ive jej nasadil na zadní stranu Mongo, aby se ujistil, že je pěkný, čistý a bezpečný, ale dostane jen dotaz, který musím udělat, protože vím, že potřebuji tuto funkci, abych se dostal k většímu puzzle; to je místo, kde je moje skutečná bolest. A tak vám vznikne tento technický dluh, a myslím si, že to nyní není jen příležitostná věc, myslím si, že je to součást DNA, která se nyní vyvíjí. Lidé prostě - ne upřímně - prostě akceptují technický dluh, který je běžným typem operandi emise, a prostě mu musí vzniknout. Je to místo, kde vám vznikne technický dluh. A myslím, že skvělou věcí na tom, co jste nám ukázali v demu, bylo, že můžete doslova profilovat a sledovat, jak dlouho něco trvá. A to je asi jedna z mých oblíbených věcí. Myslím tím, že jsem vlastně vytvořil profilovací nástroje - my jsme stavěli nástroje v Sed, Lex a Orc, abychom spustili náš kód a zjistili, kde byly smyčky, dříve než byly takové nástroje k dispozici - a když jsi vytvořil kód, abys šel a zkontroloval svůj vlastní kód , dostanete velmi dobře, že nemusíte kontrolovat svůj vlastní kód. Teď to však neplatí. Existuje tedy určitý tržní segment, který to zabírá více než kterýkoli jiný? Vidím jako mše -
Bert Scalzo: Ach jo, já jsem - připravím pro tebe analogii a ukážu ti, že to neprogramátoři dělají pořád. Protože pokud někdy učím debugger a profilovací třídu nebo relaci, zeptám se lidí: „Dobře, kolik lidí sem chodí do aplikace Microsoft Word a záměrně nikdy nepoužijí kontrolu pravopisu?“ všichni víme, že dokážeme udělat anglické chyby, a proto každý používá kontrolu pravopisu. A řekl jsem: „Jak to, že když píšete ve svém IDE jako Visual Basic, nepoužíváte debugger? Je to totéž, je to jako kontrola pravopisu. “
Dez Blanchfield: Ano, ve skutečnosti je to velká analogie. Opravdu jsem o tom nepřemýšlel, musím přiznat, že ve skutečnosti dělám něco podobného s několika nástroji, které používám. Ve skutečnosti, jeden, ODF, můj oblíbený u Eclipse je prostě vyjmout a vložit kód tam a jít hledat věci, které jen zvýraznit okamžitě a uvědomil jsem si udělal překlep v nějaké třídě volání. A nyní je to zajímavé díky nástroji, jako je tento, můžete to udělat v reálném čase, na rozdíl od návratu a při pohledu na něj později, což je docela příjemné chytit ho předem. Ale jo, to je skvělá analogie pouhého vložení do textového procesoru, způsobí jeho zajímavé buzení, jen si uvědomíte, že jste udělali překlepy nebo dokonce gramatickou chybu, že?
Bert Scalzo: Přesně tak.
Dez Blanchfield: Takže, vidíš teď víc upticku, myslím, myslím, konečnou otázku ode mě, než hodím na naše otázky a odpovědi, možná pro naše účastníky. Pokud byste chtěli dát nějaké doporučení ohledně přístupu k tomu - předpokládám, že je to rétorika - je to tak, že se dostanete brzy a necháte to implementovat jako svůj vývoj, než se budete vyvíjet? Nebo je to tak, že se převážně stavíte, pohybujete se, stavíte něco, co přijde a profil to později? Mám podezření, že je to v případě brzkého vstupu a ujistěte se, že se vaše kódy předem vyčistí. Nebo je to případ, že by měli zvážit tuto část svého post-rozmístění?
Bert Scalzo: V ideálním případě by to dělali předem, ale protože všichni jsou v rušném, rušném světě, ve kterém se právě dostali, aby to udělali, nemají sklon to dělat, dokud nenarazí na problém s výkonem, který nedokážou vyřešit přidáním dalších procesorů a paměti. na virtuální stroj.
Dez Blanchfield: To jo. Takže, ve skutečnosti jsi zmínil něco zajímavého, pokud můžu rychle? Už jste zmínili, že to lze spustit odkudkoli a můžete mluvit s databází na zadní straně. To je tedy příjemné s jakýmsi bimodálním pojmem, o kterém teď mluvíme, o cloudu on-premise / off-premise, podle vzhledu věcí, na konci dne, pokud může mluvit se zadní částí a vidět kód, to je opravdu jedno, že?
Bert Scalzo: Přesně tak jo, můžete to spustit v cloudu.
Dez Blanchfield: Výborně, protože si myslím, že to je místo, kam náš nový statečný svět jde. Ericu. Vrátím se k vám teď a uvidím, že tady má pár otázek, a já chci, aby naši účastníci zůstali s námi, i když by za nimi šel přes hodinu.
Eric Kavanagh: Jo, je tam pár lidí, já jen udělám rychlý komentář: Berti, myslím, že metafora, analogie, kterou dáváš použití kontroly pravopisu, je upřímně brilantní. To je hodné blogu nebo dvou, upřímně řečeno, protože je to dobrý způsob, jak stanovit rámec toho, co děláte, jak hodnotné je a jak by skutečně mělo být osvědčeným postupem použít debugger na pravidelně, že? Vsadím se, že když hlavy vyhodíte, trochu přikývnete, že?
Bert Scalzo: Naprosto, protože jim říkám: „Proč v dokumentech provádím kontrolu pravopisu? Nechci být zahanbena hloupými pravopisnými chybami. “No, nechtějí se stydět chybami hloupého kódování!
Eric Kavanagh: Že jo. Ano vskutku. Lidi, tady jsme spálili hodinu a pět minut, takže vám všem děkujeme za váš čas a pozornost. Všechny tyto webové chaty archivujeme, neváhejte se kdykoli vrátit a zkontrolovat je. Nejlepším místem k nalezení těchto odkazů je pravděpodobně techopedia.com, takže tento seznam přidejte přímo sem.
A s tím, se tě chci rozloučit, lidi. Ještě jednou skvělá práce, Berti, díky našim přátelům z IDERA. Příště s tebou mluvit, příští týden s tebou mluvit. Opatruj se! Ahoj.