Od zaměstnanců Techopedia, 15. března 2017
S sebou: Host Eric Kavanagh diskutoval o ladění a profilování databáze s Dr. Robinem Bloorem, Dezem Blanchfieldem a Bertem Scalzem z IDERA.
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, což samozřejmě znamená.
Robin Bloor: Neslyším tě, Ericu.
Eric Kavanagh: Byl jsem tam před dny, takže nejste sami. 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 mluvíme 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é. Takže budeme hovořit o „rychlé reakci: ladění databáze a profilování na záchranu“.
Je tu opravdu vaše místo, hit mě na Twitteru, @eric_kavanagh samozřejmě.
Tento rok je horký. A ladění bude horké, bez ohledu na to. Skutečně to bude jeden z těchto problémů, který se nikdy nezmizí, bez ohledu na to, jak dobře se k tomu dostaneme, vždycky budou problémy, 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, tohle se stane, stane se to, otázkou je, jaké bude vaše řešení pro řešení a řešení těchto problémů?
Uslyšíme dr. Robina Bloora, potom našeho vlastního Dez Blanchfielda zespodu a samozřejmě našeho dobrého přítele, Bert Scalzo, z IDERA. A ve skutečnosti předám klíče Robinovi Bloorovi, vezmu 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 budu dělat jen diskusi na pozadí, abychom získali úplný kulatý obrázek o tom, co se děje. Dělal jsem to dlouho a býval jsem kodér, takže je to jako, a byl jsem téměř v pokušení touto prezentací začít voskovat lyriku o myšlence open source, ale myslel jsem, že to nechám na někoho jiného.
Tady je seznam slavných chyb a většina z nich se dostane na top seznam někoho, 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 to 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ý obešel všechny - 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 Apple's Maps je pravděpodobně 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 v britské pojišťovně a databáze, implementovali novou verzi databáze a začalo to vymazávat 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 budu mluvit 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 nemapují. A díky tomu získáte to, čemu se říká nesoulad impedance, a někdo s tím musí nějakým způsobem jednat. Co se však vlastně stane, protože jeden model, kodérův model a databáze jiný model, nejsou nijak zvlášť zarovnány. Dostáváte 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 existovaly, byl, že jste opravdu nechtěli házet data tam a zpět do programu.
Pro některé funkce byla extrémně specifická data, takže to nebyla jen referenční integrita a kaskádové mazání a podobné věci, databáze se postarala o najednou vkládáte funkčnost do databáze, což samozřejmě znamenalo, že funkčnost 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 máte například mnoho implementací, že jsem byl zapojen do relačních databází, že je opravdu strašně mnoho kódu, který se nachází v uložených procedurách, které se zpracovávají odděleně od kódu, který je umístěn v aplikacích. A vypadá to, že se muselo dostat do podivné věci, mělo by to být docela chytré v dělání různých věcí.
Myslel jsem, že budu hovořit také o výkonu databáze, protože chyby výkonu jsou často považovány za chyby, ale v podstatě můžete mít problém s CPU, pamětí, diskem, sítí a 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 jen tak obtížné a netriviální - a říkám to proto, že jsem toho udělal hodně - a často zjistíte, že je to jako všechny situace v ladění, které jsem kdy jste zažili, 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še, co se díváte, jsou zkorumpovaná data a přemýšlíte: „Jak se to sakra stalo?“
Každopádně půjdu k Dezovi, který pravděpodobně řekne více slov moudrosti, než jsem vyšel. Nevím, jak ti předat míč, Dez.
Eric Kavanagh: Projdu to, stojím, vydrž.
Automatizovaný hlas: Účastnické linky jsou ztlumeny.
Eric Kavanagh: Dobře, počkejte jednu sekundu, dovolte mi dát Dezovi míč.
Dez Blanchfield: Děkuji, Ericu. Ano, Dr. Robin Bloore, jste opravdu nejpřesnější: toto je téma, celoživotní bugbear, když uděláte milost hříčku, promiňte, nemohl jsem si na to pomoct. 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 toho, co byl hardware a pravděpodobně softwarový problém.
Městský mýtus je tak, že kolem 9. září 1945 tým na Harvardské univerzitě rozebíral stroj, narazili na něco, čemu říkali „relé sedmdesát“ - v té době bylo programování prováděno ve fyzickém smyslu, vy jste zranili kód kolem desky, a tak jste stroj naprogramovali efektivně - a zjistili, že toto reléové číslo sedmdesát bylo s tím něco špatného, a ukázalo se, že se objevil skutečný termín „chyba“, protože to doslova byl můra - pravděpodobně tam byl můra zaklíněná mezi kusem měděného drátu vedoucího 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 můžeme představit, že lidé dělají výpočet, pojmy jako patch. Pojem „záplata“ 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 jsme tuto terminologii používali při pokusech o řešení problémů, buď ne tolik jako problémy s kódováním v programu, který se nekompiluje, ale jako program, který nefunguje dobře. A konkrétně nebyl profilován, prostě najděte věci jako nekonečné smyčky, které prostě nikam nevedou.
Ale máme také scénář a já myslel, že bych dal 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é názory na svět. A tohle je o dítěti zvaném „Little Bobby Tables“ a jeho rodiče pravděpodobně pojmenovali tento mladý chlapec Robert '); DROP TABLE Studenti; - a to se nazývá, a něco jako „Ahoj, tohle je škola vašeho syna, 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, malý Bobby Tabulky, kterému říkáme. “Každopádně říkají, že nyní ztratili roční studentské záznamy, doufám, že jste šťastní. A odpověď zní: „No, 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 nedívá na data také.
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é zkušenosti, můj první - a to mě strašně stárne, jsem si jistý; Robine, jsi vítán, že se na mě takhle pobavíš - ale historicky jsem pocházel z pozadí ve 14 letech, putoval po konci města a klepal na dveře datového centra s názvem „Data Com“ v New Zélandu a zeptat se, jestli bych mohl vydělat kapesné ve škole tím, že přijdu pozdě autobus domů, asi 25 km dojíždění každý den, vložením papíru do tiskáren a pásek do páskových jednotek a jen jako obyčejný administrátor. 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ž byla ve skutečnosti fyzická tiskárna se 132 sloupci. V podstatě uvažujte o tom, že jako velmi starý psací stroj s papírem, který jím procházel, protože neměli trubku CRT. 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 maximum pro to, 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 poté řádek vytiskne a poté znovu zapíše. Ale jednou za čas jsme psali kód a tak jsme odladili 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 všichni jsme s tím obeznámeni - š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é udělali jste na papírové páskové podobě tištěného formátu jen na CRT, ale mohli jste 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; nenechali tě dostat se špatnými praktikami. 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 zavést kód buggy.
Programovací metody v dnešní době, například strukturovaný dotazovací jazyk, SQL, je to velmi silný a jednoduchý dotazovací jazyk. Ale proměnili jsme ji v programovací jazyk a já si opravdu nemyslím, že SQL bylo někdy navrženo jako moderní programovací jazyk, ale my jsme jej zkosili, aby se z něj stala. A to zavádí celou řadu otázek, protože když přemýšlíme ze dvou hledisek: z hlediska kódování az pohledu DBA. Je velmi snadné přijít a představit chyby týkající se například špatných programovacích technik, líného úsilí při psaní kódu, nedostatku zkušeností, klasického mazlíčka, který mám například s lidmi SQL, kteří na Googlu skočili a hledali něco a našli web, který je 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ů. Máte jiné výzvy, například, v dnešní době se všichni k tomu řítíme, to, čemu říkáme závod na nulu: snažíme se dělat všechno tak levné a tak rychle, že máme scénář, kde nebudeme zaměstnávat nižší -placený personál. A to nemyslím nechutně, ale nejsme 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ří nemají dlouholeté zkušenosti, neměli nutně stejné školení nebo podporu. A tak skončíte scénářem tradičního amatérského versus odborníka. A je tu slavný řádek, nemůžu si vzpomenout, kdo vytvořil cenovou nabídku, řádek zní: „Pokud si myslíte, že je drahé najmout si odborníka, aby udělal práci, počkejte, než najmete několik amatérů, kteří vytvoří problém a vy musí to vyčistit. “A tak má tento problém SQL a je velmi snadné se ho naučit, jeho použití je velmi snadné. Ale podle mého názoru to není dokonalý programovací jazyk. Je velmi snadné dělat věci jako dělat vybranou hvězdu odkudkoli a všechno to vtáhnout do programovacího jazyka, s nímž jste pohodlnější, jako je PHP a Ruby nebo Python, a používat programovací jazyk, se kterým jste nativně obeznámeni, dělat manipulace s daty namísto složitějšího dotazu 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 snaží koupit lístek z online lístkového systému, kde se stane vybranou hvězdou 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, o které jsem si jist, že jsme všichni dobře obeznámeni. A na levé straně je kousek SQL, který to vlastně vykresluje. 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é! “No, to všechno má ilustrovat to, co jsem tam jen nastínil, a to je 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. Takže nyní máme velmi složité konstrukty a máme uložené procedury, máme programovací metodiku aplikovanou na jazyk, a tak je to velmi snadné pro špatnou programovací praxi, nedostatek zkušeností, vyjmutí a vložení kódu, nízko placení zaměstnanci, kteří se snaží být vysoce placenými zaměstnanci, lidé předstírají, ž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ě roztomilé a myslíte si: „Páni, jaká skvělá grafika, ráda bych to spustila.“ Ale představte si, že to 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 je mi líto, že barvy jsou obrácené, mělo by to být černé pozadí a zelený text 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í, které tyto věci dokáží zachytit, dostanou se do výroby, a pak máte 100 000 lidí bít do systému 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ívej, to je opravdu hezký kód, ale pojďme získat DBA, která ti pomůže správně sestavit tento strukturovaný dotaz, protože upřímně řečeno, to je prostě ošklivé.“ A tam je URL, 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ěř, že se to skutečně 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 textu.
Abych to shrnul s tím, že mě to vezme v úvahu, celé mé 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 řekl, dříve, jednou za čas, jste to mohli 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 lidi to ve skutečnosti 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 si myslím, že se chystáme dostat. Ericu, půjdu zpět.
Eric Kavanagh: Dobře, Berti, vezmi to pryč.
Bert Scalzo: Dobře, děkuji. Bert Scalzo zde z IDERA, jsem produktový manažer našich databázových nástrojů. A budu mluvit o ladění. Myslím si, že jednou 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 ladění databáze, je to řá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, jen programují s jakýmkoli jazykem, který používají, a mnohokrát mi řeknou "No, ty debuggerovy věci jsou nové a my jsme je ještě nezačali používat." A tak to, co dělám, je, že jim ukážu tento časový rozvrh, jakýsi pre-historie, stáří, středověk, je to druh kde jsme byli, pokud jde o programovací jazyky. 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 debuggery, které máme k dispozici, a tak říkám: „Hej, 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 se zbavit tohoto tvrzení.
Teď další věc, která je na tomto grafu vtipná, je Dez, který právě napsal poznámku o Grace Hopperové, 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á tam sedím a pokračuji: „Č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 jsem naprogramoval ve všech jazycích tady, včetně SNOBOLu, o kterém nikdo předtím neslyšel, byla 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ě stárl.
Bert Scalzo: Jo, říkám vám, cítím se jako děda Simpson. Takže se podívám na ladění a existují různé způsoby, jak provést 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; tam vkládáte příkazy do svého kódu a možná vytvoříte výstupní soubor, sledovací soubor nebo něco takového, a tak svůj kód vybavíte. To bych považoval za ladění, je to trochu těžší, způsob, jak to udělat, ale to se počítá. Ale také máme slavné tiskové prohlášení: sledujete a lidé skutečně vkládají tiskové prohlášení a já jsem vlastně viděl nástroj, kde - a je to databázový nástroj - kde, pokud nevíte, jak používat debugger, stisknete tlačítko a bude to pro vás tisknout prohlášení v celém kódu pro vás a poté, když budete hotovi, stisknete další tlačítko a odstraní je. Protože tak 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á, že existuje logická chyba nebo nám chyběl 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 profiler pravděpodobně lepší pro tento druhý scénář a budeme 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, ve které je kód skutečně spuštěn v databázi, skutečně děláte tzv. vzdálené ladění. Možná si to neuvědomujete, ale to se děje. A pak je velmi běžné, že tyto debuggery mají body zlomu, sledovací body, krok a krok zpět a některé další běžné věci, které za okamžik ukážu ty 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 víc, že je lepší, pokud se provádí odběr vzorků. Neexistuje žádný důvod chytit každé jedno prohlášení, protože některé výkazy mohou běžet tak rychle, že vám to nezáleží, to, co se opravdu snažíte vidět, je 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, je to 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, máte SQL - a my jsme tak trochu 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, je to Transact-SQL, je to SQL-99, je to SQL / PSM - protože, myslím, je to procedura Stored Module. 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í 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, co můžete uložit do databáze jako kód - pokud dělám T-SQL, nebo PL / SQL - a já ukládám objekty do databáze, je to pravděpodobně uložená procedura nebo uložená funkce. Ale existují i spouštěče: spouště je něco jako uložená procedura, ale na nějakou událost se spustí. 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 postupy, 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. Do jedné skupiny seskupíte 50 nebo 100 uložených procedur, které se nazývají balíčky, takže je to něco jako knihovna. Takže tady 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, dobře, to je metoda ručního ladění.
A důvod, proč to uvádím, je, že pokud se to snažíte ručně, ve skutečnosti napíšete více ladicího kódu, který vložíte do všech těchto tiskových 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 protože, 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 podívat na nějaký stopový soubor, který pravděpodobně obsahuje všechny tyto tiskové výkazy v něm, a zkuste najít jehlu v kupka 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 v tomto souboru trasování jsem právě dostal spoustu tiskových příkazů a možná i nemusí být schopen sifonovat a najít to, co musím najít. Takže si opět nejsem tak jistý, že byste takto chtěli pracovat.
Nyní, interaktivní debuggery - a pokud jste použili něco jako Visual Studio k psaní programů, nebo Eclipse, měli jste debuggery a použili jste je ve svých dalších jazycích - prostě si nemysleli, že je použijete zde 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 zásadě jde jen o to, abych se podíval a uviděl, 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ě, v horní třetině, mám svůj zdrojový kód uprostřed, mám to, co se nazývá moje sledovací proměnné a moje zásobníky zásobníku volání, a poté dole Mám nějaké výstupní zprávy. 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ž 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 mě vypadat, co se stalo, krok další řádek, nech 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 jsem přistoupil a tam jsem na moment. Takže, když řeknu: „Krok znovu, “ půjdu na další řádek. Těsně pod ní uvidíte červenou tečku. No, to je bod zlomu, který říká: „Hej, 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 Run a bude to běžet odtud až do konce, nebo do bodu přerušení, pokud jsou nastaveny nějaké body přerušení, a pak se zastaví a dovolím 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 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 vidím hodnoty z mých proměnných, Vidím trasování zásobníku hovorů, víte, a tak se zde všechny tyto informace zobrazují, když 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 vlastně je pracuje v době provedení. 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. Pamatuješ, že jsem někdy řekl, že jsou oddělené a někdy mohou být spolu? V tomto případě a znovu jsem v Rapid SQL a vidím, že na levé straně je vedle čísel řádků okraj. A co to znamená, je to počet sekund nebo mikrosekund, které trvalo provedení každého řádku kódu, a já vidím, že celý můj čas je stráven v této jedné smyčce FOR, kde vybírám vše 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í to dividendy. Nebudu mít žádné vylepšení tím, že budu pracovat na těch linkách, které mají jako 0, 90 nebo 0, 86; není tam moc času. Nyní, v tomto případě a znovu, jsem v Rapid SQL, vidíte, jak mohu udělat profilování smíchané s mým ladením. Nyní je pěkné, že Rapid SQL vám to také umožňuje dělat opačně. 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 už nejsem v debuggeru a běží program a po dokončení provádění mi dává grafy, které mi mají co říci, takže vidím, že mám jedno prohlášení, které vypadá, že to zabírá většinu výsečového grafu a když se podívám, vidím na té mřížce směrem dolů, na řádku 23, opět je tu smyčka FOR: zabírá nejvíce času, ve skutečnosti je to tmavě červený žvýkání všech výsečových grafů. A tak je to další způsob 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 na světě a získat zvýšení mezd - 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 jsme si přečíst jejich mysl a udělat vše okamžitě. Jinými slovy, musí to být efektivní. A na to bychom použili profiler. Nyní, bez těchto nástrojů, opravdu věřím, že jste ten chlap v obleku s lukem a šípy a střílíte na cíl a jste se zavázanýma očima. 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, budu tady dělat opravdu rychlé demo. Není mým záměrem tlačit produkt, jen vám chci ukázat, jak vypadá debugger, protože mnohokrát lidé řeknou: „Nikdy jsem žádný z nich neviděl.“ A vypadá to docela slušně na snímcích obrazovky, ale jak to vypadá, když je v pohybu? Takže tady na obrazovce běží produkt DB Artisan; máme tam také debugger. DB Artisan je určen spíše pro DBA, Rapid SQL je spíše pro vývojáře, ale viděl jsem vývojáře, kteří používají DB Artisan, a viděl jsem DBA, kteří používají Rapid. Nenechte se tedy chytit produktu. A tady mám na výběr ladění, ale než spustím ladění, rozbalím tento kód, abyste viděli, jak tento kód vypadá, než jej spustím. 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.
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. Teď, když 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ž k bodu zlomu, takže jsem nyní v kontextu spuštění 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 na nulu. A teď můžu 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 udělá vybraný počet z mých výpůjček a můžu na něj najíst myší a podívat se, jsou dva, dva větší než jeden, takže pravděpodobně udělá další kousek tohoto kódu. Jinými slovy, něco našlo. Jen jdu do toho 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 nastavený bod přerušení, takže když jsem řekl, že běžel, prostě se vrátil k dalšímu bodu přerušení. Nechám to běžet až do konce, protože chci, abys viděl, že debugger nemění chování programu: když je hotovo, měl bych získat přesně stejné výsledky, kdybych to neprovedl 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: Ano, samozřejmě, to je samozřejmě fascinující. Pracoval jsem 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 je to jako, dívají se na - protože se domnívá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á v rámci svého jazyka nazývám Transact-SQL nebo PL / SQL. Dovolte mi provést PL / SQL, protože Oracle s nástroji Microsoft nehraje vždy dobře. 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é postup a řekněte: „Dobře, ze 100 výroků, které jsou zde, je zde 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 přestože může být kód vysoce účinný, můžete vypadat a říkat: „Ooh, toto volání na tento kus kódu provádíme 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 ve skutečnosti můžete najít, kde je účinný kód, který se právě nazývá příliš často a ve skutečnosti jde o 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 k problémům, které mě používaly k divokému šíření, k myšlence Rozdělil kód mezi databázi a program. Ale ano, udělejte vše - předpokládám, že odpověď bude ano, ale je to součást činnosti vývojového týmu, když se nějakým způsobem snažíte opravit něco, co je rozbité, nebo se možná pokusit přinést nový aplikace společně. 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 legrační, minulý týden jsem měl zákazníka, který vytvářel webovou aplikaci, a jejich databáze byla historicky malá, takže skutečnost, že nebyli moc dobrí programátoři, jim nikdy neublížila. Jejich databáze se v průběhu let rozrostla a nyní na webové stránce trvá 20 sekund, když řeknete: „Přihlaste se a dejte mi data, která chcete vidět“, a když se obrazovka skutečně objeví, a nyní je to 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í? A skutečně jsme zjistili, že se v jednom ze svých vybraných výroků připojili karteziánští, a nevěděli to.
Robin Bloor: Páni.
Bert Scalzo: Ale někdo mi jednou řekl: „No, jak by mohli mít karteziánské spojení a neví to?“ A to bude znít 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 zdatní, jak by snad měli být. 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 tak či onak v tomto ohledu jen jazykovou agnostikou, protože to vše se zaměřuje na stranu databáze. Mám v tom pravdu? Je to stejné, ať už používáte cokoli na straně kódování?
Bert Scalzo: Určitě to můžete udělat ve Fortranu 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 učíte, jak být programátorem, učíte se rekordně myslet. 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 mínus operátora. A někdy je pro člověka, který nikdy nemyslel na sady, velmi těžké přestat, pustit rekordní zpracování a pracovat se sadami.
Robin Bloor: Jo, jsem s tebou. Chci říct, teď už to je otázka vzdělání; Myslím, že se jedná o problém vzdělávání, myslím, že je přirozené, aby programátoři postupovali. A SQL není procedurální, je to deklarativní. Ve skutečnosti jen říkáte: „To je to, co chci, a je mi jedno, jak to děláte, “ víte? Zatímco u programovacích jazyků jste si často stáhli rukávy a jste dole v markantech dokonce i při správě počtů, zatímco děláte smyčku. Podám -
Bert Scalzo: Ne. OK, pokračujte.
Jo, chtěl jsem říci, že jsi uvedl další příklad, že by profiler mohl dobře chytit 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. Takže 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 tím, že se spojíte ručně, než necháte to udělat za vás databázovým serverem.
Robin Bloor: Jo, to by byla katastrofa. Chci říct, jen bys se házel kolem. Thrashing je vždy špatný.
Každopádně půjdu k Dezovi; Určitě 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. Chci říct, že jsem strávil příliš mnoho let svým životem tím, že jsem sám kodérem, na všech úrovních, víš, ať už je to, jak jsi řekl, seděl na příkazové řádce stroje Unix a v některých případech jsem se dokonce zapojil v několika různých portech Unixu z jedné hardwarové platformy na druhou. A dokážete si představit, jaké výzvy jsme tam měli. Skutečností je však to, že karta pro únik z 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 je Dennis Ritchie a Brian Kernahan, kteří pracují na nějakém kusu kódu samostatně a poté se obrátí na chat s recenzemi kódu nad kávou a zjistí, že napsali přesně stejný kus kódu, ve stejném programu, přesně stejným způsobem. A udělali to v C. Ale ta puristická úroveň programování existuje velmi zřídka.
Skutečnost je taková, že denně existuje jen 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 se vždy snažíme o co nejnižší náklady.
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ě si myslím, že jednou z otázek, které bych si opravdu ráda, abys nám dal ještě více vhledu, je to, co je šířka a dosah typu lidí, které v současné době vidíte a kteří používají tyto nástroje k profilování kód a hledat 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? Teď se nám dostává méně, jak řekl Robin, akademický přístup, a teď je to samouk, nebo kód pro vkládání a vkládání, nebo jen stavět věci? A odpovídá to typu lidí, kteří nyní berou tento produkt?
Bert Scalzo: Jo, přesně. A já vám ukážu velmi konkrétní příklad, chceme jen udělat práci, protože podnikatelé nechtějí dokonalost. Je to něco jako počítačová šachová hra: šachová hra nehledá dokonalou odpověď; hledá odpověď, která je dostatečně dobrá v rozumném čase, a tak naprogramujeme. Ale to, co teď zjišťuji, je, že většina lidí místo toho, aby řekla, že chce v rámci testování jednotek profiler - to je, jak bych to udělal, protože to nevidím jako ztrátu času - co se děje, je nyní, když se to dělá později, někdy během testování integrace nebo stresového testování, pokud máme štěstí. Ale ve většině případů je to součástí eskalace, kde se něco stalo ve výrobě, chvíli to běželo, možná dokonce běželo roky a teď to nefunguje dobře, a teď to budeme profilovat. A to se nyní zdá být běžnějším scénářem.
Dez Blanchfield: Jo, a myslím, že termín „technický dluh“ je pravděpodobně ten, se kterým jste víc než obeznámen; 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, máme vlastní projekty jako Media Lens a další, kde se každý den děje kódování, a různé věci napříč skupinou Bloor. A kdykoli něco budujeme, tak se na to díváme, dívám se na to a vždy se dívám na to, z čeho to bude stát, abych to opravil hned teď, versus mohu to jen dostat do a dostat to tam, a pak sledovat a zjistit, jestli se tato věc zlomí. A zdědím tento technický dluh, o kterém vím, že se budu muset později vrátit zpět a opravit.
A myslím, že jsem to udělal za posledních sedm dní: napsal jsem několik nástrojů a skriptů, napsal jsem několik kusů jazyka Python a nasadil jsem ho na zadní stranu Mongo, určitě je to hezké a čisté a bezpečné, ale dostane jen dotaz, který musím udělat, protože vím, že tuto funkci potřebuji, abych se dostal k většímu puzzle; tam 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. Tam vznikl 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 viděli, kde byly smyčky, dříve než byly takové nástroje k dispozici - a když jste vytvořili kód, který chcete zkontrolovat svůj vlastní kód, je velmi dobré, že nemusíte kontrolovat svůj vlastní kód. Ale to tak nyní není. 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, mám - budu pro vás kreslit analogii a ukážu vám, že to neprogramátoři dělají pořád. Protože když někdy učím ladicí 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?“ A nikdo nepostaví ruku, protože pro psaní dokumentů 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 text v IDE, jako je Visual Basic, nepoužíváte debugger? Je to totéž, je to jako kontrola pravopisu. “
Dez Blanchfield: Ano, ve skutečnosti je to skvělá analogie. Opravdu jsem o tom nepřemýšlel, musím přiznat, že vlastně 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ě vyříznout a vložit kód tam a jít hledat věci, které se jen zvýrazní okamžitě a uvědomím si, že jsem udělal překlep v nějakém hovoru třídy. A s nástrojem, jako je tento, je zajímavé, že to můžete 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 hezké chytit ho předem. Ale jo, to je skvělá analogie pouhého vložení textu do textového procesoru, protože je to zajímavé buzení, jen si uvědomte, že jste udělali překlepy nebo dokonce gramatickou chybu, že?
Bert Scalzo: Přesně.
Dez Blanchfield: Takže, vidíš teď víc upticku, myslím, myslím, poslední 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 implementujete to, jak se vyvíjíte, než se vyvíjíte? Nebo je to tak, že převážně stavíte, pohybujete se, stavíte něco, co přijde a profilujete to později? Mám podezření, že se jedná o případ brzy, a ujistěte se, že váš kód je čistý předem. 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ě, kde prostě musí udělat věci, nemají sklon to dělat, dokud nenarazí na problém s výkonem, který nedokážou vyřešit přidání více procesorů a paměti do virtuálního počítače.
Dez Blanchfield: 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ě 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 máme několik otázek, a chci, aby naši účastníci zůstali s námi, i když jsme prošli přes hodinu.
Eric Kavanagh: Ano, je tam pár lidí, jen stručně řeknu: Berti, myslím, že metafora, analogie, kterou dáváš použití kontroly pravopisu, je upřímně brilantní. To si zaslouží blog nebo dva, upřímně řečeno, protože je to dobrý způsob, jak zarámovat kontext toho, co děláte, jaké cenné to je a jak by skutečně mělo být používání debuggeru osvědčeným postupem. pravidelně, že? Vsadím se, že když hlavy vyhodíte, trochu přikývnete, že?
Bert Scalzo: Rozhodně, protože jim to ří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 hloupými chybami kódování!
Eric Kavanagh: Správně. 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 to přidáme do tohoto seznamu zde.
A s tím se ti rozloučíme, lidi. Ještě jednou skvělá práce, Berti, díky našim přátelům z IDERA. Budeme s tebou mluvit příště, budeme mluvit s tebou příští týden, ve skutečnosti. Opatruj se! Ahoj.
