A Techopedia munkatársai, 2017. március 15
Elvihető: Eric Kavanagh házigazda megbeszélte az adatbázis hibakeresését és profilozását Dr. Robin Bloorral, Dez Blanchfieldrel és az IDERA Bert Scalzo-val.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Eric Kavanagh: Oké, hölgyeim és uraim, szerdán 4:00 van keleti idő, és ez természetesen azt jelenti.
Robin Bloor: Nem hallom, Eric.
Eric Kavanagh: Néhány nappal ezelőtt itt voltam, tehát nem vagy egyedül. De tehát a mai téma nagyon érdekes. Ez az a fajta dolog, amelyet meg szeretne győződni arról, hogy a háttérben zajlik-e a vállalkozása, kivéve, ha Ön az, aki ezt csinálja, ebben az esetben meg szeretné győződni arról, hogy megfelelően csinálja-e. Mert a hibakeresésről beszélünk. Senki sem szereti a hibákat, senkinek sem tetszik, amikor a szoftver nem működik - az emberek felborulnak, a felhasználók barátságtalanok. Ez nem jó. Tehát a "Gyors válasz: Adatbázis hibakeresése és a mentés profilozása" témáról fogunk beszélni.
Van egy hely a tiédről, valószínűleg feltalál a Twitterre, természetesen a @eric_kavanagh.
Ez az év forró. És a hibakeresés forró lesz, nem számít. Ez valóban egy ilyen probléma, amely soha nem fog eltűnni, függetlenül attól, hogy mennyire jók meg ezt a dolgot, mindig problémák merülnek fel, tehát a legfontosabb az, hogy hogyan jutsz el oda, ahol gyorsan meg tudja oldani ezeket a kérdéseket? Ideális esetben nagyszerű programozóid vannak, nagyszerű környezetben vannak, ahol nem sok történik rosszul, de amint azt a régi mondás mondja: „A balesetek a család legjobban történnek.” Ugyanez igaz a szervezetekre is. Tehát, ez a cucc megtörténik, meg fog történni, a kérdés az, hogy mi lesz a megoldás a kezelésére és a problémák megoldására?
Dr. Robin Bloor-tól, majd alulról Dez Blanchfield-től, és természetesen jó barátnőmtől, Bert Scalzo-tól, az IDERA-tól, halljuk. És valójában le fogom adni a kulcsot Robin Bloornak, elviszem. A padló a tiéd.
Robin Bloor: Oké. Ez egy érdekes téma. Arra gondoltam, hogy mivel Dez valószínűleg folytatja a hibakeresés aktuális technikáit és háborús történeteit, azt gondoltam, hogy csak háttérbeszélgetést fogok folytatni, hogy teljes körű képet kapjunk arról, hogy mi folyik. Ezt már hosszú ideje csináltam, és egyelőre kódoló voltam, így van, és szinte a kísértésem volt ezzel a bemutatóval, hogy elkezdtem szövegezni a nyílt forráskód ötletét illetően, de azt hittem, hogy ezt valakinek másnak hagyom.
Itt található a híres hibák listája, és ezek többsége bárki legfelső listájára kerül, alapvetően mindegyik kivételével az utolsó kettő legalább 100 millió dollárba kerül. Az első a Mars Climate Orbiter volt, elveszett az űrben, és ez egy kódolási probléma miatt következett be, ahol az emberek összekeverték a metrikus egységeket lábakkal és hüvelykkel (nevet). Az Ariane Five Flight 501 esetében nem volt egyezés a feltett motor és a számítógépek között, amelyek állítólag a rakéta működtetésekor indultak el. Több számítógépes hiba, robbanó rakéta, hírek. Az 1982-es szovjet gázvezetékről azt mondták, hogy ez a legnagyobb robbanás a bolygó történetében; Nem tudom, valóban. Az oroszok ellopták néhány automatizált vezérlőszoftvert, és a CIA rájött, hogy ezt fogja csinálni, és hibákat tesz be, és a szovjetek tesztelés nélkül végrehajtották. Tehát felrobbant egy csővezetéket, azt gondolva, hogy szórakoztató.
A Morris féreg kódolási kísérlet volt, amely hirtelen mindenki körüli körmös féreggé vált - nyilvánvalóan 100 millió dolláros kárt okozott; ez természetesen egy becslés. Az Intel híres hibát követett el egy matematikai chippel - egy matematikai utasítás a Pentium chipen 1993-ban -, amelynek állítólag több mint 100 millió dollárba került. Az Apple Maps programja valószínűleg a legrosszabb és legpusztítóbb elindítása bármit is, amit az Apple valaha tett. Azok, akik megpróbálták használni, úgy értem, hogy valaki 101-es úton haladt, és rájöttek, hogy az Apple Map szerint a San Francisco-öböl közepén vannak. Tehát az emberek elkezdték hivatkozni az Apple Maps alkalmazásra iLost néven. Az 1990-es leghosszabb kiesésünk azért valami ilyesmi költsége szempontjából érdekes - az AT&T körülbelül kilenc órát állt ki, és mintegy 60 millió dollárba került a távolsági hívások során.
És egy brit biztosítótársaságnál voltam, és az adatbázis, új verziót vezettek be az adatbázisba, és elkezdték az adatok törlését. És ezt rendkívül jól emlékszem, mert utána behívtak, hogy valamilyen adatbázis-kiválasztásban vegyenek részt. És nagyon érdekes volt, hogy elvették az adatbázis új verzióját, és rengeteg teszttel rendelkeztek, amelyeket az adatbázis új verzióihoz tettek, hogy az minden tesztet letett. Nagyon homályos módszert talált az adatok törlésére.
Szóval, egyébként, ez az. Azt hittem, beszélek az impedancia eltérésről és az SQL kiadásáról. Érdekes, hogy a relációs adatbázisok táblázatokban tárolják az adatokat, és a kódolók általában olyan objektumszerkezetekben manipulálják az adatokat, amelyek valójában nem igazán mutatnak táblázatokat. És emiatt megkapja az úgynevezett impedancia-eltérést, és valakinek valamilyen módon kell foglalkoznia vele. De mi történik valójában, mert az egyik modell, a kódoló modellje és az adatbázis másik modellje, nincs különösebben összehangolva. Olyan hibákat kapsz, amelyek csak akkor nem fordulnak elő, ha az iparág olyan dolgokat épített fel, amelyek együtt működnek, ami szerintem vidám. Tehát alapvetően a kódolók oldalán, amikor hierarchiákat kapnak, lehetnek típusok, eredményhalmazokat eredményezhetnek, gyenge API képességek lehetnek, sok olyan dolog lehet, amelyek csak kihozzák a dolgokat az adatbázis-interakció szempontjából. De ez a számomra leginkább igazán érdekes; Mindig lenyűgözött, hogy megvan ez az SQL akadály, amely szintén egyfajta impedancia, oly módon, hogy a kódolók és az adatbázis működjenek egymással. Tehát az SQL rendelkezik az adatok felismerésével, ami rendben van, és rendelkezik DML-lel a kiválasztáshoz, a projekthez és a csatlakozáshoz, ami rendben van. Nagyon sok képességet élvezhet azzal, hogy ezzel az adatokat kihozza az adatbázisból. De nagyon kevés matematikai nyelv van a dolgok elvégzéséhez. Van egy kis ez és ez, és nagyon kevés az időalapú cucc. És ezért az SQL nem tökéletes eszköz az adatok megszerzésére, ha úgy tetszik. Tehát az adatbázis-srácok tárolt eljárásokat építettek, hogy az adatbázisban éljenek, és az ott élő tárolt eljárások oka az volt, hogy nem igazán akartad, hogy az adatokat oda-vissza dobják egy programra.
Egyes funkciók rendkívül adatspecifikusak voltak, tehát nem csupán a referenciális integritás és a lépcsőzetes törlés és más hasonló dolgok miatt az adatbázis gondoskodott arról, hogy hirtelen a funkcionalitást egy adatbázisba helyezi, ami természetesen azt jelentette, hogy az alkalmazás funkcionalitása megosztható a kódoló és az adatbázis között. És ez nagyon megnehezítette bizonyos típusú funkciók végrehajtását, és ennélfogva inkább hajlamosak a hibákra. Szóval, ez az adatbázis játék egyik oldala, mert ez azt jelenti, hogy sok megvalósításban részt vett, például hogy részt vettem a relációs adatbázisokban, valóban egy szörnyű sok kód található a tárolt eljárásokban, amelyet kezelnek külön az alkalmazásokban található kódtól. És nagyon furcsa dolognak tűnik, hogy elég okosnak kell lennie a különféle dolgok elvégzésében.
Arra gondoltam, hogy az adatbázis teljesítményéről is beszélek, mivel a teljesítmény hibákat gyakran hibának tekintik, de alapvetően szűk keresztmetszet lehet a CPU-n, a memórián, a lemezen, a hálózaton, és a zárolás miatt teljesítményproblémák merülhetnek fel. . Az ötlet az lenne, hogy a kódolónak nem kellett igazán aggódnia a teljesítmény miatt, és az adatbázis valójában elég jól teljesít. Úgy tervezték, hogy a kódolónak nem kell tudnia. Rossz az adatbázis-tervezés, rossz a programtervezés, a munkaterhelés-keverés párhuzamossága, ami teljesítményproblémákhoz is vezethet. Megkapja a terheléselosztást, megkapja a kapacitástervezést, az adatnövekedést - ami az adatbázis leállását vagy lelassítását okozhatja. Érdekes dolog, amikor az adatbázisok majdnem megtelnek, lelassulnak. És az adatrétegeket kiadhatja replikáció, replikációs igény, valamint biztonsági mentés és helyreállítás szempontjából. Különben is, ez egy általános áttekintés.
Az egyetlen dolog, amit szeretnék mondani, hogy az adatbázis hibakeresése csak annyira megterhelő és nem triviális - és ezt mondom, mert sokat csináltam -, és gyakran felfedezheti, hogy minden hibakeresési helyzethez hasonló, hogy valaha tapasztalt, az az első dolog, amit valaha lát, a rendetlenség. És meg kell próbálnia elmenni a rendetlenségből annak kidolgozásához, hogy a rendetlenség hogyan történt. És gyakran, amikor adatbázis-kérdéssel foglalkozik, csak sérült adatokra gondol, és arra gondol: "Hogyan a fenébe történt?"
Mindenesetre továbbadom Deznek, aki valószínűleg több bölcsességet fog mondani, mint amennyivel én kijöttem. Nem tudom, hogyan továbbítsam neked a labdát, Dez.
Eric Kavanagh: Átmegyek, állnék, tartsd.
Automatizált hang: a résztvevő vonalai némítva.
Eric Kavanagh: Rendben, lógj egy másodpercig, hadd adjam Deznek a labdát.
Dez Blanchfield: Köszönöm, Eric. Igen, Dr. Robin Bloor, valójában a legjobban igazad van: ez egy téma, egész életen át tartó hibás, ha megbocsátják a büntetést, sajnálom, hogy nem tudtam magam segíteni ebben. Remélhetőleg ott láthatja az első képernyőmet, a tetején elnézést a betűméret miatt. A hibák témája egy napos előadás, sok esetben tapasztalatom szerint. Ez egy olyan széles és tág téma, tehát két kulcsfontosságú területre összpontosítom a hangsúlyt, nevezetesen annak a koncepciónak a fogalmát, amelyet hibának tekintünk, de egy programozási kérdésnek. Úgy gondolom, hogy manapság egy hiba bevezetését általában magában foglalja az integrált fejlesztési környezet, bár lehet, hogy hosszú ideje fennálló hibák. De gyakran ez inkább a profil profilkódolása, és lehetséges, hogy olyan kódot írunk, amely működik, és ennek hibának kell lennie. Tehát, a címem itt csúszik, valójában volt egy példányom erről nagyon nagy felbontású A3-ban, de sajnos a ház költöztetésével elpusztult. De ez egy kézírásos jegyzet egy 1945 körül körülbelül egy programozási lapon, ahol állítólag néhány nép az USA-ban a Harvard Egyetemen, a második gyártmányuk egy Mark II nevû gép. Hibakerestek valamelyik kérdést, a közös nyelven, de megpróbáltak hibát találni, és kiderül, hogy valami, ami kissé különbözik a hardvertől és egy állítólag szoftveres problémától, jött.
Tehát a városi mítosz az, hogy 1945 szeptember 9- én körül a Harvard Egyetemen egy csapat széthúzta a gépet, találkoztak valamivel, amit „hetven relének” hívtak - akkoriban a programozás fizikai értelemben zajlott, te sebző kóddal egy tábla körül, és így programozhatta hatékonyan a gépet - és a hetvenes relé számukra találtak valamit, ami hibás volt, és kiderül, hogy a “hiba” kifejezés azért jött létre, mert szó szerint egy lepkék volt - állítólag ott egy lepke volt, amely az egyik helyről a másikra haladó rézhuzal egy darabja közé került. És a történet megragadja, hogy a legendás Grace Hopper, mint ez a felirat a címsoromhoz, „az első tényleges eset, amikor hibát találtak” idézettel idéz.
De amint Robin az első diajában korábban kiemelte, a hiba fogalma olyan messzire ment vissza, amennyire el tudjuk képzelni, hogy az emberek számítástechnikát végeznek, olyan fogalmak, mint egy javítás. A „javítás” kifejezés abból származott, hogy egy tényleges szalagdarabot ragasztottak egy lyukasztóra a lyukasztó kártyán. Ennek lényege azonban, hogy a „hibakeresés” kifejezés abból a fogalomból származik, amely egy hibát talál egy fizikai gépen. És azóta használtuk ezt a terminológiát a problémák megpróbálására, vagy akár annyira, mint a nem összeállított program kódolási kérdéseire, hanem olyan programra, amely nem működik jól. És kifejezetten nem volt profilozva, csak találhat olyan dolgokat, mint a soha véget nem érő hurkok, amelyek csak sehová sem kerülnek.
De van egy forgatókönyv is, és azt hittem, hogy beteszek egy pár vicces diát, mielőtt egy kissé részletesebben belemennék. Itt van a klasszikus rajzfilm, az XKCD néven az interneten, és a karikaturistának nagyon vicces nézete van a világról. És ez egy "Kis Bobby Táblázat" nevű gyerekről szól, és szülei állítólag ezt a fiatal fiút Robertnek nevezték el); DROP TÁBLÁZAT Diákok; - és ezt hívják, és az a fajta: "Helló, ez a fiad iskolája némi számítógépes problémával rendelkezik", és a szülő azt válaszolja: "Ó kedvesem, eltört valamit?", És a tanár azt mondja: "Nos, bizonyos értelemben ”, és a tanár azt kérdezi:„ Valóban nevezted a fiád, Robert ”); LEHETSÉGES TÁBLÁZATOK Diákok; -? ”És a szülő azt mondja:„ Ó, igen, kicsi Bobby Táblázatokat hívunk neki. ”Egyébként továbbra is azt mondják, hogy elveszítették az év hallgatói rekordjait, remélem boldogok vagytok. És a válasz: „Nos, meg kell tisztítania és fertőtlenítenie kell az adatbázis-bemeneteket.” És sokszor beszélek néhány olyan problémáról, amelyet a dolgok kódban történő megtalálása során tapasztalunk, hogy gyakran a kód nem nézi meg az adatokat is.
Egy másik vicces, nem tudom, valós-e ez vagy sem - gyanítom, hogy ez hamis -, de megint megérinti a vicces csontomat. Valaki megcseréli az autójának elülső rendszámát egy hasonló nyilatkozatra, amely miatt az adatbázisok csökkennek a sebességmérő kamerákban, és így tovább, amelyek elfogják az autó rendszámát. És mindig arra hivatkozom, hogy kétlem, hogy valamelyik programozó előrevetítette-e kódjának egy valódi gépjármű általi elérését és futtatását, de ezt soha nem szabad alábecsülni - egy dühös geek erejét.
(Nevetés)
Azt hiszem, ez vezeti a kulcsponthoz, azt hiszem, hogy egyszer csak hibaelhárító és profilkódot tudtunk képezni, mint pusztán halandók. De nagyon nagy az a véleményem, hogy ez az idő telt el, és anekdotikusan tapasztalataim szerint az első - és ez rettenetesen öregszik, biztos vagyok benne; Robin, örülök, hogy engem szórakoztat. - De történelmileg 14 éves korom hátteréből jöttem, amikor a város végén sétáltam, és kopogtattam egy új Data Center nevű adatközpont ajtaján. Zéland és arra kérdezve, hogy tudok-e pénzt keresni az iskolában azzal, hogy hazafelé haladok a busszal, kb. 25 km-es ingázással, papírt nyomtatókba és szalagokba, és csak egy általános adminisztrátorként. És kíváncsi, hogy munkát adtak nekem. De az idő múlásával sikerült bekerülnöm a személyzetbe és megtalálni a programozókat, és rájöttem, hogy szeretem a kódolást, és átmentem a szkriptek és a kötegelt feladatok futtatásának folyamatán, amely a nap végén még mindig kód. Írjon szkripteket és kötegelt feladatokat, amelyek úgy néznek ki, mint a mini programok, majd végigmennek az egész folyamaton, amikor kézzel ülnek a 3270 terminálon.
Valójában az első tapasztalatom egy teletip terminálon volt, amely valójában 132 oszlopos fizikai nyomtató volt. Alapvetően gondolj úgy, mint egy nagyon régi írógépre, amelyen papír gördült át, mert nem volt CRT-csőük. És a kód hibakeresése egy nagyon nem triviális kérdés volt, így hajlamos volt az összes kódot kézzel írni, majd gépelőként viselkedni, és mindent megtesz annak érdekében, hogy ne essen hibákat a becsapódáshoz, mert nagyon bosszantó, ha el kell mondanom az egyik sor szerkesztője, hogy elmenjen egy bizonyos sorra, majd kinyomtassa a sort, majd írja be újra. De egyszer volt, hogy így írtunk kódot, így hibáztuk meg, és nagyon-nagyon jól megkaptuk. És valójában arra kényszerített minket, hogy nagyon jó programozási technikákkal rendelkezzünk, mert valódi nehézség volt ezt kijavítani. De az utazás ezután ment - és mindannyian ismerjük ezt - a világomban lévő 3270 terminál élményéből a Digital Equipment VT220 készülékbe, ahol láthatott dolgokat a képernyőn, de megint csak ugyanazt csináltad a papírszalagon valamilyen nyomtatott formátumot tettél csak CRT-n, de könnyebben törölheted, és nem volt ilyen hangod.
És akkor tudod, hogy a Wyse terminálok - mint például a Wyse 150, valószínűleg a kedvenc interfészem a számítógéphez valaha -, majd a PC, majd a Mac, és manapság a modern webes felhasználói felületek és azonosítók. És ezen keresztül egy sor program, programozás egy és összeszerelőként, valamint PILOT és Logo, Lisp és és Fortran és Pascal, valamint olyan nyelvek, amelyek az embereket összecsaphatják. De ezek a nyelvek kényszerítették a jó kód írására; nem engedték meg, hogy elkerülje a rossz gyakorlatokat. C, C ++, Java, Ruby, Python - és tovább lépünk arra a programozási szakaszra, annál szkript-szerűbbek vagyunk, egyre közelebb kerülünk a strukturált lekérdezési nyelvhez és a PHP-hez hasonló nyelvekhez, mint például az SQL. A lényeg azt mondani, hogy hátteréből fakadóan sok szempontból öntanítottam őket, és azok, amelyek segítettek nekem megtanulni, nagyon jó programozási gyakorlatokat és nagyon jó gyakorlatokat tanítottak a tervezés és a folyamatok körül, hogy megbizonyosodjom arról, hogy nem bevezetni a hibás kódot.
Programozási módszerek manapság, például a strukturált lekérdezési nyelv, SQL, ez egy nagyon hatékony, egyszerű lekérdezési nyelv. De ezt programozási nyelvgé alakítottuk, és nem igazán hiszem, hogy az SQL-t valaha úgy tervezték, hogy modern programozási nyelvré váljon, de elcsúsztattuk, hogy így váljon. És ez egy egész csomó témát vezet be, „amikor két szempontból gondolkodunk: a kódolás és a DBA szempontjából. Nagyon könnyű megtalálni hibákat olyan dolgokon, mint a rossz programozási technikák, a kódírás lusta erőfeszítései, a tapasztalatok hiánya, a klasszikus kisállat-kutya, például az SQL-emberekkel, akik a Google-on ugrálnak, keresnek valamit, és megtalálnak egy weboldalt, kaptam egy példát, és készítsünk egy létező kód másolását és beillesztését. Aztán megismétli a rossz kódolást, a szabálytalanságot, és bevezette a termelésbe, mert csak akkor adja meg nekik a kívánt eredményt. Más kihívásokkal is szembesülsz, például manapság mindannyian rohanunk ehhez, amit nulla versenynek hívunk: mindent megpróbálunk oly olcsón és olyan gyorsan megcsinálni, hogy van egy forgatókönyv, ahol nem alkalmazunk alacsonyabb fizetett személyzet. És nem ezt félreértő módon értem, de nem foglalkoztatunk minden lehetséges munkához szakértőket. Egyszer régen bármi köze volt a számítógépekhez, a rakéta tudomány volt; részt vett olyan dolgokban, amelyek felrobbantottak és nagyon hangosak voltak, vagy űrbe mentek, vagy a mérnökök magasan képzett férfiak és nők voltak, akik diplomát végeztek és szigorú oktatással rendelkeztek, ami megakadályozta őket az őrült dolgok elkészítésében.
Manapság nagyon sok ember lép be a fejlesztésbe és a tervezésbe és az adatbázisba, akiknek nem volt hosszú éves tapasztalata, és akiknek nem feltétlenül volt ugyanaz a képzése vagy támogatása. És tehát csak a hagyományos amatőr versus szakértő forgatókönyvével ér véget. És van egy híres vonal, valójában nem emlékszem, ki készítette az árajánlatot, ez a sor megy: „Ha úgy gondolja, hogy drága egy szakértőt felvenni egy munka elvégzésére, várjon, amíg felhív egy pár amatőröt, akik problémát okoznak, és te meg kell tisztítani. ”És így az SQL-nek van ez a kérdése, és nagyon-nagyon könnyű megtanulni, nagyon könnyű használni. De véleményem szerint ez nem tökéletes programozási nyelv. Nagyon könnyű elvégezni a kiválasztott csillagot bárhonnan, és mindezt egy olyan programozási nyelvre húzni, amely jobban megfelel Önnek, mint például a PHP, a Ruby vagy a Python, és használni az eredetileg ismerős programozási nyelvet. az adatok manipulációja, és nem egy összetettebb lekérdezés végrehajtása az SQL-ben. És ezt sokat látjuk, majd az emberek azon gondolkodnak, miért fut az adatbázis lassan; azért van, mert egy millió ember próbál jegyet venni egy online jegyrendszerből, ahol bárhová kiválaszt egy csillagot.
Ez egy igazán szélsőséges példa, de mindezt megkapja. Tehát, hogy igazán lyukaszthassuk ezt a pontot otthon, itt van egy példa, amelyet sokat hordozok. Nagyon rajongok a matematikában, szeretem a káoszelméletet, a Mandelbrot készleteket. A jobb oldalon a Mandelbrot készlet ábrázolása található, amelyet biztosak vagyunk benne, hogy mindannyian ismerünk. És a bal oldalon van egy SQL darab, amely azt valójában megjeleníti. Most, minden alkalommal, amikor ezt valahol a képernyőre teszem, ezt hallom: „Istenem, valaki az SQL-rel készítette a Mandelbrot sorozatot, komolyan gondolod? Ez őrültség! ”Nos, ennek lényege annak bemutatása, amit éppen itt vázoltam, és ez igen, valójában most már szinte bármit be tud programozni az SQL-be; ez egy nagyon fejlett, erőteljes, modern programozási nyelv. Ha eredetileg ez egy lekérdezési nyelv volt, azt úgy tervezték, hogy csak az adatok felkeljen. Tehát most nagyon bonyolult konstrukciókkal és tárolt eljárásokkal rendelkezik, programozási módszertant alkalmazunk egy nyelvre, és így nagyon könnyű a rossz programozási gyakorlat, a tapasztalat hiánya, a cut-and-paste kód, alacsony fizetésű alkalmazottak, akik próbálnak magas fizetésű alkalmazottak lenni, az emberek úgy tesznek, mintha tudnának, de nekik munkát kell tanulniuk.
Sok olyan dolog, ahol a kód profilozása és a mi hibakeresésnek nevezzük, ami nem annyira hibákat talál, amelyek megállítják a programok működését, hanem olyan hibákat, amelyek csak megsértik a rendszert, és a rosszul strukturált kódot. Ha most megnézed ezt a képernyőt, és azt gondolod, hogy ez csak olyan aranyos, és azt gondolod: „Hű, milyen nagyszerű grafika, szeretném ezt futtatni.” De képzelje el, hogy fut valamilyen üzleti logikán. . Nagyon szépen néz ki, de egy matematikai, grafikusan megjelenített káoszelméletet beszél, de amikor gondolkodik azon, hogy mire szolgálhatna valamilyen üzleti logikában, akkor nagyon gyorsan megkapja a képet. És ezt valóban illusztrálva - és sajnálom, hogy a színek megfordultak, állítólag fekete háttérnek és zöld szövegnek kell lennie, mint egy zöld képernyő, de ezt még el tudja olvasni.
Elmentem, és gyorsan átpillantottam egy példát arra, mit tehetsz, ha valóban őrült vagy, és nincs bármilyen tapasztalata, és eltérő programozási háttérből származik, és a C ++ szeretetét alkalmaztam az SQL-re, hogy valóban szemléltessem az érveimet. Átadom az IDERA tanult vendégünknek. Ez egy olyan strukturált lekérdezés, amelyet úgy írnak, mint a C ++, de az SQL kódolja. És valóban végrehajt, de körülbelül három-öt perc alatt hajt végre. És látszólag egy adatsort húz vissza több adatbázisból, több kapcsolódásból.
Ismét a lényeg az, hogy ha nem rendelkeznek a megfelelő eszközökkel, ha nincs a megfelelő platformok és a környezet, hogy képesek legyenek ezeket a dolgokat elkapni, és elkezdik a termelést, akkor 100 000 ember ha naponta, órában vagy percben megüt egy rendszert, nagyon hamarosan csernobili élményre kerül, ahol a nagy vas olvadni kezd, és eltemetheti magát a bolygó magjába, mert az a kóddarab soha nem szabad termelésbe kerülni. Rendszereidet és eszközeit, bocsánat, kérjük, hogy ezt felvegyék, mielőtt bárhová is megyek - akár a tesztfolyamaton keresztül, akár az UAT és a rendszerintegráció révén is, ezt a kóddarabot fel kell venni és ki kell emelni, és valakit félre kell hozni, és mondván: „Nézd, ez tényleg nagyon szép kód, de szerezzünk be egy DBA-t, amely segít a strukturált lekérdezés megfelelő felépítésében, mert őszintén szólva, ez csak csúnya.” És ott van az URL, itt lehet megnézni, és megnézni - erre a a legbonyolultabb SQL lekérdezés, amit valaha írtál. Mert hidd el nekem, ez valójában fordít, fut. És ha ezt kivágja és beilleszti, és csak felsemmisíti az adatbázist, azt nagyon meg kell nézni; ha rendelkeznek az adatbázis figyelésére szolgáló eszközökkel, csak próbáljon megolvadni egy három-öt perces időszak alatt, hogy visszahívja, mi az a szövegsor.
Tehát összefoglalva, ennek fényében, a kódolás egész háttere megtanította nekem, hogy pisztolyt adhat az embereknek, és ha nem vigyáztak, lábukba lőnek; a trükk az, hogy megmutassák nekik, hol van a biztonsági mechanizmus. A megfelelő eszközökkel és a megfelelő szoftverrel, amely kéznél van, a kódolás elvégzése után átnézheti a kódot, problémákat találhat a kód profilozásával, hatékonyan találhat nem kívánt hibákat, amelyek teljesítményproblémák, és ahogy mondtam Korábban egyszer csak meg tudta csinálni egy zöld képernyőn. Nem tudod többé; több százezer sornyi kód van, több tízezer alkalmazás van telepítve, néhány esetben több millió adatbázis van, és még a szuper emberek sem tudják ezt kézzel megtenni. Szó szerint szó szerint szüksége van a megfelelő szoftverre és a megfelelő eszközökre kéznél, és szükség van a csapatra, aki ezeket az eszközöket használja, hogy megtalálja ezeket a kérdéseket, és nagyon-nagyon gyorsan meg tudja oldani őket, mielőtt a lényegre jutnának, míg Dr. Robin Bloor kiemelte, hogy a dolgok akár katasztrófá válnak, és a dolgok felrobbantanak, vagy általában: sok dollárba kerülnek, sok időt és erőfeszítést igényelnek, és elpusztítják az erkölcsöt és más dolgokat, amikor nem tudják megtudni, miért veszik a dolgok hosszú idő futni.
És ezt szem előtt tartva átadom a vendégünknek, és nagyon várom, hogy meghallgassam, hogyan oldották meg ezt a kérdést. És különösen azt a demót, amelyet szerintem meg fogunk kapni. Eric, visszamegyek.
Eric Kavanagh: Rendben, Bert, vedd el.
Bert Scalzo: Oké, köszönöm. Bert Scalzo vagyok itt, az IDERA-tól, az adatbázis-eszközöink termékmenedzsere vagyok. És a hibakeresésről fogok beszélni. Úgy gondolom, hogy az egyik legfontosabb dolog, amit Robin korábban mondta - és ez igaz, hogy a hibakeresés megterhelő és nem triviális, és amikor az adatbázis hibakeresésére megy, akkor még nagyobb terhet jelent és nem triviális nagyságrendű - tehát, hogy fontos idézet volt.
RENDBEN. A programozási történelemmel akartam kezdeni, mert sokszor látom az embereket, akik nem hibáznak, nem használnak hibakeresőt, csak programoznak bármilyen nyelven, amit használnak, és sokszor mondanak nekem, „Nos, ezek a hibakeresési dolgok új, és még nem kezdtük el ezeket használni.” És tehát az, hogy én megmutatom nekik ezt az ütemterv-diagramot, egyfajta előzményeket, az öregséget, a középkorot, ez kedves mondjuk, hol voltunk a programozási nyelvek szempontjából. És nagyon régi nyelveink 1951-től kezdődően kezdődtek, összeszerelési kóddal, Lisp, FACT és COBOL nyelvekkel. Aztán bejutunk a következő csoportba, Pascals és Cs, majd a következő csoportba, a C ++ -okba, és megnézzük, hol van ez a kérdőjel - ez a kérdőjel megközelítőleg jobb az 1978-as vagy talán 1980-as évek körül. Valahol ezen a tartományon volt rendelkezésre állnak a hibakeresők, és így mondhatjuk: "Hé, nem használom a hibakeresőt, " mert ez az egyik új dolog ", akkor el kellett kezdenie a programozást, tudod, már az 1950-es években, " mert ez az az egyetlen módja annak, hogy elkerülje ezt az állítást.
A másik dolog, ami furcsa ebben a diagramon, az, hogy Dez csak megjegyzést fűzött Grace Hopperhez, valójában ismertem Grace-t, tehát ez nagyon vicces. És akkor a másik dolog, amiben nevettem, az a, hogy a teleptípusokról beszélt, és ott ülök, hogy megyek: „Ember, ez volt a legnagyobb ugrás, ami valaha volt a termelékenységben, amikor kártyáktól teletipussá váltunk, ez volt a legnagyobb ugrás valaha. "Szóval, és az összes nyelven programoztam az itt felsorolt nyelveket, beleértve a SNOBOL-ot, amelyről még senki nem hallott, ez egy CDC, a Control Data Corporation, tehát azt hiszem, kicsit túl öreg vagyok ehhez az iparhoz .
Dez Blanchfield: Azt akarom mondani, hogy szörnyen öregítettél minket ott.
Bert Scalzo: Igen, azt mondom, hogy Simpson nagypapaként érzem magam. Tehát nézem a hibakeresést, és a hibakeresésnek különféle módjai vannak. Beszélhetne arról, hogy mi mindannyian gondolkodunk arról, hogy tradicionálisan bekerülünk a hibakeresőbe és lépünk át a kóddal. De az emberek megtanítják a kódot; ebbe az állításokba illesztheti a kódot, és talán előállít egy kimeneti fájlt, nyomkövetési fájlt vagy ilyesmit, és így beillesztheti a kódot. Úgy számolom, hogy a hibakeresés egy kicsit nehezebb, a módszer erre, de számít. Ugyanakkor megvan a híres nyomtatási nyilatkozat: Ön figyeli, és az emberek valójában nyomtatási nyilatkozatokat helyeznek el, és láttam egy olyan eszközt, ahol - és ez egy adatbázis eszköz - hol, ha nem tudod, hogyan kell használni a hibakeresőt, Ön megnyom egy gombot, és az az egész kódban kinyomtatja a kinyomtatott nyilatkozatokat, majd amikor elkészült, nyomja meg egy másik gombot, és kihúzza őket. Mert sok ember így hibakeres.
A hibakeresés oka kettős: mindenekelőtt olyan dolgokat kellett találnunk, amelyek hatástalanná teszik kódunkat. Más szavakkal, ez általában azt jelenti, hogy logikai hiba van, vagy elmulasztottunk egy üzleti követelményt, de ami az, hogy a kód nem hatékony; nem azt teszi, amit elvártunk. A másik alkalommal, amikor elmenünk és hibakeresést végezzünk, a hatékonyság érdekében, és ez logikai hiba lehet, de mi az, az az, hogy helyesen tettem, csak nem tér vissza elég gyorsan. Most arra gondolok, mert a profilozó valószínűleg jobb a második forgatókönyvhöz, és mind a hibakeresőkről, mind a profilolókról beszélni fogunk. Ezen felül létezik ez a távoli hibakeresés fogalma; ez azért fontos, mert sokszor, ha a személyi számítógépén ül, és egy hibakeresőt használ, amely olyan adatbázist talál meg, ahol a kód ténylegesen végrehajtódik az adatbázisban, akkor valójában a távoli hibakeresésnek nevezi. Lehet, hogy nem veszi észre, de éppen ez történik. És akkor nagyon gyakori, hogy ezekkel a hibakeresőkkel törési pontok vannak, figyelési pontok vannak, belépnek és lépnek át, és néhány más általános dolog, hogy egy pillanat alatt megmutatom azokat a képernyő pillanatképén.
Most, profilozás: a profilozást többféle módon is megteheti. Néhányan azt állítják, hogy a munkaterhelés rögzítése és visszajátszása, ahol mindent elfog, az pedig profilozásnak számít. A tapasztalataim szerint annál jobb, ha mintavételre kerül sor. Nincs ok minden egyes kijelentés elkapására, mert egyes állítások olyan gyorsan futhatnak, hogy nem érdekel, igazán megpróbálsz látni, nos, melyek azok, amelyek újra és újra megjelennek, mert túl sokáig futnak. Tehát néha a profilozás a mintavétel helyett azt jelenti, hogy az egészet futtatja. És általában kap egyfajta kimenetet, amelyet felhasználhat, most pedig vizuálisan megjelenhet egy IDE fejlesztői környezetben, ahol ez lehet, mint egy hisztogram a különböző kódsorok teljesítményéről, de mégis Legyen nyomkövető fájl.
A profilerek először 1979-ben jelentkeztek. Tehát ezek is már régóta léteznek. Nagyon jó az erőforrás-felhasználással vagy a teljesítménygel kapcsolatos problémák, más szóval a hatékonyság szempontjából. Általánosságban elmondható, hogy ez különálló és különbözik a hibakeresőtől, bár azokkal a hibakeresőkkel dolgoztam, amelyek mindkettő egyszerre történnek. És bár úgy gondolom, hogy a profilozók a két eszköz közül a legérdekesebbek, ha úgy érzem, hogy nincs elég ember hibakeresés, akkor minden bizonnyal nem elég az ember profilja, mert úgy tűnik, hogy a tíz hibakereső közül egy profilt fog profilozni. És ez szégyen, mert a profilozás valóban hatalmas különbséget jelent. Most, az adatbázis nyelveiben, amint arról korábban beszéltünk, megvan az SQL - és valamilyen módon kényszerítettük a kör alakú csapot a négyzet alakú lyukba, és arra kényszerítettük, hogy programozási nyelvgé váljon -, valamint az Oracle-t. Ez a PL / SQL - ez az eljárási nyelv SQL - és az SQL Server, ez a Transact-SQL, ez az SQL-99, ez az SQL / PSM - mert azt hiszem, hogy az eljárás tárolt modulja. A Postgres egy másik nevet, a DB2-nek még egy nevet, az Informix-et ad, de a lényeg az, hogy mindenki 3GL típusú konstrukciókat kényszerített; más szóval, a FOR hurkokhoz, a változó deklarációknál és az összes többi, az SQL-től idegen anyaghoz, az SQL része ezekben a nyelvekben. Tehát a PL / SQL-t vagy a Transact-SQL-t ugyanúgy kell hibáztatnia, mint a Visual Basic programhoz.
Most, adatbázis-objektumok, ez azért fontos, mert az emberek azt fogják mondani: „Nos, mit kell hibáznom egy adatbázisban?” És a válasz: nos, bármit is tárolhatok az adatbázisban kódként - ha T-SQL vagy PL / SQL - és objektumokat tárolok az adatbázisban, valószínűleg egy tárolt eljárás vagy tárolt funkció. De vannak triggerek is: a trigger olyan, mint egy tárolt eljárás, de valamilyen eseményre rúg. Most néhány ember az eseményindítóiban egy sor kódot helyez el, és tárolt eljárást hív fel, hogy megőrizze az összes tárolt kódját és eljárását, de ez ugyanaz a koncepció: továbbra is a trigger lehet az, ami az egészet kezdeményezi. És akkor, mint Oracle, van valami, úgynevezett csomag, amely valamiféle könyvtárhoz hasonló, ha akarod. 50 vagy 100 tárolt eljárást helyez el egy csoportba, úgynevezett csomagba, tehát olyan, mint egy könyvtár. Tehát itt van a régi hibakereső; ez valójában egy eszköz, amely valóban bekapcsol és rögzíti ezeket a hibakeresési utasításokat a kódban az Ön számára. Tehát mindenütt, ahol a hibakeresési blokk látható, ne távolítsa el, az automatikus hibakeresés indulása és nyomon követése, ezeket mind valami eszköz beragadta. És az azon kívüli sorok, amelyek a kód kisebbsége, nos, ez a nem manuális hibakeresési módszer.
És azért hozom fel ezt, ha kézzel próbálod ezt megtenni, akkor valójában több hibakeresési kódot ír be, hogy mindezeket a nyomtatott nyilatkozatokat betegye, mint a kóddal. Tehát, bár ez működhet, és bár jobb, mint semmi, ez egy nagyon nehéz módszer a hibakereséshez, főleg mivel az lenne, ha mi lenne, ha 10 óra eltelne, amíg ez a dolog fut, és ahol problémája van, a harmadik sorba kerül? Ha interaktív hibakeresési munkamenetet folytatnék, a harmadik sorban - öt perc múlva - tudtam volna, hogy hé, itt van egy probléma, tudok abbahagyni. De ezzel meg kell várnom, amíg fut, egészen a befejezésig, majd átnéznem egy nyomkövetési fájlt, amelyben valószínűleg megtalálhatók az összes nyomtatott nyilatkozat, és meg kell találnom a tűt a szénaboglya. Ez ismét jobb, mint semmi, de nem lenne a legjobb módszer a működésre. Most néz ki ez a fájl, ahogyan az az előző diaból származik; más szavakkal, futtam a programot, és csak egy csomó nyomtatott nyilatkozat van ebben a nyomkövetési fájlban, és valószínűleg nem tudok rajta átjutni, és megtalálni azt, amit meg kell találnom. Tehát ismét nem vagyok benne biztos, hogy ilyen módon szeretne dolgozni.
Most, interaktív hibakeresők - és ha valami hasonlót használtak a Visual Studio-hoz programok írásához, vagy az Eclipse-hez, akkor már vannak hibakeresők, és a többi nyelveddel is használták - egyszerűen nem gondolták, hogy itt használják őket az adatbázisukkal. És vannak olyan eszközök is, mint például a DB Artisan és a Rapid SQL, ez itt a Rapid SQL, amelyeknek van hibakeresője, és a bal oldalon láthatod, hogy van egy tárolt eljárásom, melynek neve: „Példányok ellenőrzése”. Alapvetően csak megy, és megnézem, van-e több sor a táblázatban ugyanazzal a filmcímmel. Tehát az adatbázis a filmekhez készült. És a jobb oldalon, a felső harmadon láthattad, a közepén van a forráskód, megvan az úgynevezett óraváltozóim és a hívásverem-tálcáim, majd az alján Van néhány kimeneti üzenet. És itt az a fontos, ha átnézzük az első piros nyíl fölött, ha az egérmutatót egy változó fölé mutatom, valójában látom, hogy az adott időpontban milyen érték van abban a változóban, ahogy átmentem a kódot. És ez nagyon hasznos, és akkor egy sorban léphetlek egyszerre a kódon keresztül, nem kell mondanom, hogy végre kell hajtanom, mondhattam egy sort vonalolni, hadd nézzem meg mi történt, lépjünk egy másik vonalra, hadd lássam mi történt, és ezt az adatbázisban csinálom. És annak ellenére, hogy a PC-n ülök a Rapid SQL-n, és az adatbázisom felhőben van, mégis megtehetem a távoli hibakeresést, láthatom és irányíthatom innen, és ugyanúgy végezhetek hibakeresést, mint bármely más nyelven.
Most, a következő nyíl - láthatja a kicsit olyan, mint a jobbra mutató nyilat a DBMS kimenete felé, ott van a kurzorom jelenleg - tehát más szavakkal, én léptem, és itt vagyok a pillanat. Tehát, ha azt mondom: „Lépjen újra”, megyek a következő sorra. Most alul látja a piros pontot. Nos, ez egy töréspont, amely azt mondja: „Hé, nem akarok ezen a vonalon átlépni.” Ha csak át akarok ugrani mindent és eljutok oda, ahol ez a piros pont van, megüthetem a Futtatás gombot, és elindul. innen akár a végéig, akár egy töréspontig, ha vannak beállítva töréspontok, akkor ez megáll, és hagyja, hogy ismét megtegyem a lépést. Mindez nagyon fontos és hatalmas oka az, hogy amikor mindezt megteszem, megváltozik a közepén és az alján - de ami a legfontosabb - középen zajló esemény történik, és látom az értékeket a változóimból, Látom a hívásverem nyomát, tudod, és így az összes információ ott megjelenik, ahogy átlépem a kódot, így valójában látom és érezhetem, és megértettem, mi folyik és hogyan működik a kód. a végrehajtás idején dolgozik. És általában megtalálhatom a problémát, ha van ilyen, vagy ha elég jó vagyok ahhoz, hogy felkapjam.
Oké, most egy profilőrről fogok beszélni, és ebben az esetben ez egy profilozó, amelyet egy hibakeresőn keresztül láthatok. Emlékszel, mondtam, hogy néha külön vannak, és néha együtt lehetnek? Ebben az esetben ismét a Rapid SQL-ben vagyok, és látom, hogy van egy margó a bal oldalon a sorszámok mellett. És mi az, az az, hogy hány másodpercet vagy mikrosekundumot igényelt az egyes kódsorok végrehajtása, és egyértelműen látom, hogy minden időmet ebben a FOR-hurokban töltöm, ahol mindent kiválasztom az asztalból . És tehát minden, ami ezen a FOR-hurkon belül történik, valószínűleg valami, amit meg kell vizsgálnom, és ha jobban tudom fejleszteni, akkor osztalékot fog fizetni. Nem fogok javulást elérni, ha azon vonalakon dolgozom, amelyek 0, 90 vagy 0, 86; nincs sok időt eltölteni ott. Most, ebben az esetben ismét a Rapid SQL-ben vagyok, látja, hogyan tudom profilozni a hibakeresést. Ami a jó, a Rapid SQL azt is lehetővé teszi, hogy másik módon csináld. A Rapid SQL lehetővé teszi, hogy azt mondja: „Tudod mit? Nem akarok a hibakeresésben lenni, csak futtatni akarom ezt, majd aztán grafikusan vagy vizuálisan szeretnék megnézni az azonos típusú információkat. ”
Láthatja, hogy már nem vagyok a hibakeresőben, és fut a program, és miután a végrehajtás megtörtént, grafikonokat ad nekem, hogy elmondjam a dolgokat, így láthatom, hogy van egy kijelentésem, amely úgy néz ki, mintha elkezdené A kördiagram nagy részét, és ha megnézem, látom, hogy ezen a rácson az alsó felé, a 23. sorban megint ott van a FOR-hurok: ő veszi a legtöbb időt, valójában sötétvörös rágja fel az összes kördiagramot. Tehát ez egy másik módszer a profilozáshoz. Véletlenszerűen ezt a „Code Analyst” -et hívjuk eszközünkben. De alapvetően ez csak egy profilkészítő, amely elválasztott egy hibakeresőtől. Vannak, akik elsőként szeretik csinálni, mások a második módon szeretik csinálni.
Miért csinálunk hibakeresést és profilozást? Nem azért, mert azt akarjuk, hogy a világ legnagyobb kódját megírjuk, és fizetésnövekedést szerezzünk - ez lehet mi oka, de valójában nem ez az oka, mert ezt megígérte - ígérte az üzletnek, hogy helyesen fog tenni valamit, hogy a programja eredményes lesz. Erre fogja használni a hibakeresőt. Ezen felül üzleti végfelhasználók; nem nagyon türelmesek: eredményt akarnak még a gomb megnyomása előtt. El kellene olvasnunk a gondolatukat, és mindent azonnal meg kell tennünk. Más szavakkal, hatékonynak kell lennie. Szóval erre használnánk a profilkészítőt. Most, ezen eszközök nélkül, azt hiszem, hogy ez a fickó vagy az öltönyben, íjjal és nyíllal, és a célra lő, és be van vakolva. Mert hogyan fogja megtudni, hogy egy program hogyan hajt végre egy statikus kód megnézésével, és hogyan fogja kitalálni, melyik vonal van, ahol valóban a legtöbb időt tölti a végrehajtás során, csak statikus kód megnézésével? A kód áttekintése előfordulhat, hogy nem feltétlenül jeleníti meg ezeket a dolgokat, de nem garantált, hogy a kód áttekintés mind megtalálni fogja azokat. A hibakereső és a profilkészítő segítségével meg kell találnia az összes ilyen hibát.
Oké, csak egy igazi gyors bemutatóm lesz itt. Nem az a szándékom, hogy a terméket toljam el, csak azt szeretném megmutatni, hogy néz ki egy hibakereső, mert sokszor az emberek azt mondják: „Még soha nem láttam ilyenet.” És a képernyő pillanatnyi diájai között is nagyon jól néz ki., de hogyan néz ki, amikor mozgásban van? Tehát itt, a képernyőn, futtatom a DB Artisan terméket; itt is van egy hibakereső. A DB Artisan-t inkább a DBA-knak, a Rapid SQL-t inkább a fejlesztőknek szánják, de láttam már a DB Artisan-t használó fejlesztõket, és láttam a DBA-kat, akik a Rapid-ot használják. Tehát ne érintse meg a terméket. És itt megválaszthatom a hibakeresést, de mielőtt elindítanám a hibakeresést, kibontom ezt a kódot, így láthatom, hogy néz ki a kód, mielőtt futtatnám. Tehát itt van pontosan ugyanaz a kód, mint a képernyő pillanatképében, ez az én ellenőrzés a másolatok ellenőrzésére. És ezt szeretném hibakeresni, ezért megnyomom a hibakeresést. És most eltart egy pillanatot, és azt mondod: „Nos, miért vesz egy pillanatra?” Emlékezz a távoli hibakeresésre: a hibakeresés valójában az én adatbázis-kiszolgálómon zajlik, nem a számítógépemen. Tehát át kellett mennie, hogy ott létrehozzon egy munkamenetet, hozzon létre egy távoli hibakeresési dolgot, bekapcsolja a munkamenetet arra a távoli hibakeresési munkamenetre, és beállítson egy kommunikációs csatornát.
Tehát most, itt van a nyíl, ott van a tetején, sor szerint, itt vagyok a kódban. És ha megnyomom a harmadik ikont, amely egy lépés, akkor látni fogja, hogy a nyíl éppen mozog, és ha továbbra is nyomom meg, látni fogja, hogy mozog. Most, ha végig akarok menni ehhez a FOR-hurokhoz, mert tudom, hogy a probléma itt van, beállíthatom egy töréspontot. Azt hittem, ezt beállítottam. Ó, lő, az egyik képernyőfogómom ugyanahhoz a kulcshoz lett ragasztva, mint a hibakereső, ez okozza a zavart. Rendben, tehát csak manuálisan állítottam be egy töréspontot ott, tehát most egy lépés, lépés, lépés, lépés elvégzése helyett csak azt tudom mondani: “Menj előre, futtasd ezt a dolgot”, és ez megáll. Észrevettem, hogy egészen arra a pontra helyeztem, ahol a töréspont van, tehát most a hurok futtatásának kontextusában vagyok, látom, hogy az összes változóm van beállítva, ami nem meglepő, mert én mindegyiket inicializáltam nullára. És most beléphetek ebbe a hurokba, és megnézhetem, mi folyik ezen a hurkon belül.
Tehát most kiválaszt egy számlálást a bérleti díjaimból, és rá tudom mutatni az a srácot, és megnézem, ő kettő, kettő nagyobb, mint egy, tehát valószínűleg meg fogja csinálni a kód következő részét. Más szavakkal, talált valamit. Én csak megyek, és hagyom, hogy fut. Nem akarok itt mindent átnézni; amit azt akarom mutatni, hogy amikor egy hibakeresõ elkészült, az úgy fejezõdik be, mint egy normál program. Megvan a töréspont, tehát amikor azt mondtam, hogy fut, csak visszatért a következő törésponthoz. Hagyom, hogy a végére futjon, mert azt szeretném, ha látnád, hogy a hibakereső nem változtatja meg a program viselkedését: amikor fut, befejezésekor pontosan ugyanazokat az eredményeket kell kapnom, ha nem futtattam volna. egy hibakeresőben.
És ezzel felfüggesztem a demonstrációt, és visszamegyek, mert meg akarjuk győződni arról, hogy van-e időnk kérdésekre és válaszokra. És így nyitva állom kérdéseket és válaszokat.
Eric Kavanagh: Rendben, Robin, talán kérdés tőled, majd egy pár Dez-ből?
Robin Bloor: Igen, persze, ezt természetesen lenyűgözőnek találom. Ilyen dolgokkal dolgoztam, de az adatbázisban soha nem dolgoztam ilyennel. Tudsz nekem képet adni arról, hogy mire használják az emberek a profilkészítőt? Mivel ez olyan, mint amilyenek - gondolom, hogy ők - a teljesítmény kérdéseit vizsgálják, segít-e megkülönböztetni az adatokat, amikor egy adatbázis időt vesz igénybe, és mikor egy kód időt vesz igénybe?
Bert Scalzo: Tudod, ez egy fantasztikus kérdés. Tegyük fel, hogy a Visual Basic-ben dolgozom, és a Visual Basic-ben belül Transact-SQL-nek vagy PL / SQL-nek hívom. Hadd csináljam a PL / SQL-t, mivel az Oracle nem mindig játszik jól a Microsoft eszközökkel. Profilálhatom a Visual Basic kódomat, és az ottani profil azt mondhatja: „Hé, meghívtam ezt a tárolt eljárást, és túl sokáig tartott.” De akkor bemehetek a tárolt eljárásba, és meg tudom készíteni egy adatbázis profilt a tárolt eljárást, és mondja: „Rendben, az itt található 100 állításból az alábbiakban az öt okozta a problémát.” És így el kell végeznie egy címkecsoportot, ahol több profilkészítőt kell használnia.
Az ötlet az, hogy ha valaha is értesülnek arról, hogy az adatbázisban található a teljesítményprobléma, az adatbázisprofil segíthet megtalálni a tűt a szénakazalban, amelyen az állítások valójában azok, ahol problémád van. Mondok neked egy másik dolgot, amely felbukkanott a profilozással: ha van egy olyan kóddarab, amelyet milliószor hívnak, de csak egy mikrosekundum szükséges egymilliószor, de milliószor hívják, amit a profilozó megmutatna, ez a dolog e sok időegységig futott. És így, bár a kód nagyon hatékony lehet, úgy nézhet ki és mondhatja: „Ó, túl gyakran hívjuk fel ezt a kódot. Talán csak ilyen gyakran kell hívnunk, ahelyett, hogy minden alkalommal feldolgozzunk egy lemezt, vagy valami. És így valóban megtalálhatja a hatékony kódot, amelyet gyakran túl gyakran hívnak, és ez valójában teljesítményprobléma.
Robin Bloor: Igen, ez csodálatos. Soha nem csináltam ezt. Természetesen láthatja, hogy amikor adatbázis-problémáim voltak, úgy éreztem, hogy valamilyen módon vagy adatbázissal, vagy kóddal foglalkoznék; Soha nem tudtam volna foglalkozni mindkettővel egyszerre. De itt ismét nem tettem a dolgot: Soha nem vettem részt olyan alkalmazások építésében, ahol eljárásokat tároltunk, tehát azt hiszem, hogy soha nem ütköztem olyan problémákba, amelyek régen vadul engedtek, az az ötlet, hogy te felosztaná a kódot egy adatbázis és egy program között. De igen, mindent megteszek - feltételezem, hogy a válasz igen lesz, de ez egy fejlesztői csapat tevékenységének része, amikor valamilyen módon próbálsz megjavítani valamit, ami megtört, vagy talán új alkalmazás együtt. De vajon ez megfelel-e az összes többi alkotóelemnek, amire számíthatok a környezetben? Arra számíthatok, hogy le tudom vágni ezt az összes tesztcsomaggal és az összes többi anyaggal, amit csinálok, és a projektmenedzsment cuccokkal, hogy ez az egész összekapcsolódik?
Bert Scalzo: Igen, bármilyen strukturált folyamat részévé válhat, ha elvégzi a programozási vagy fejlesztési erőfeszítéseit. És vicces, hogy a múlt héten volt egy ügyfelem, aki webes alkalmazást készített, és az adatbázisuk történelmileg kicsi volt, és az a tény, hogy nem voltak túl jó programozók, soha nem bántotta őket. Nos, az adatbázisuk az évek során nőtt, és most 20 másodpercig tart egy weboldalon, amikor azt mondod: „Jelentkezz be, és adj nekem némi adatot, hogy megnézhessem”, és amikor a képernyő ténylegesen felbukkan, és így van most teljesítményprobléma. És tudták, hogy a probléma nincs Java-jaikban, vagy azokban a helyeken. De több ezer tárolt eljárásuk volt, és így el kellett kezdeniük a tárolt eljárások profilozását, hogy megtudják, miért kell ennek a weboldalnak 20 másodpercig megjelenni? És valójában azt tapasztaltuk, hogy derékszögű csatlakoztak az egyik kiválasztott állításukhoz, és nem tudták.
Robin Bloor: Wow.
Bert Scalzo: De valaki egyszer azt mondta nekem: „Nos, lehet, hogy csatlakoztak volna egy derékszögû ember, és nem tudnák?” És ez igazán szörnyûnek hangzik; Időnként egy olyan programozó, aki nem igazán ért hozzá az SQL-hez, valami ilyesmit fog tenni, hogy hozzon nekem egy derékszögű csatlakozást, de csak az első rekordot adja vissza, tehát tudom, hogy van valami, és csak az elsőre van szükségem. És tehát nem is veszik észre, hogy csak milliárd lemezt hoztak vissza, vagy egymilliárd lemezt keresnek át, mert megkapta az érdeklődőket.
Robin Bloor: Hát, tudom, ezt hívják - nos, Dez-en állt erről szó, olyan emberekkel kapcsolatban, akik nem pontosan olyan képzettek, mint lehetnek, tudod. Ha programozó vagy, akkor tudnod kell, hogy mi a parancs kiadásának következményei. Úgy értem, valójában nincs mentség a hülyeségnek. Feltételezem azt is, hogy ebben az értelemben vagy úgy vagyok, hogy csak nyelvi agnosztikus, mert ez mind az adatbázis oldalára fókuszál. Igazam van ebben? Ugyanaz, bármit is használ a kódolási oldalon?
Bert Scalzo: Abszolút, megteheti ezt Fortran vagy C vagy C ++ formátumban. Valójában néhány Unixon meg is teheti azt a szkriptnyelvükkel; valójában ugyanazokat az eszközöket nyújtják. És aztán egy pillanatra vissza akarok térni azzal, amit mondott mentség nélkül. Egy szünetet fogok adni a programozóknak, mert nem szeretem a programozókat a busz alá dobni. De a probléma valójában az akadémiai környezet, mert amikor programozói képességeket tanul, megtanítják az időről-időre történő gondolkodást. Nem tanítják meg a set gondolkodást, és éppen ezért működik a strukturált lekérdezési nyelv, vagy az SQL a halmazokkal; ezért van az unió, a kereszteződés és a mínusz operátor. És néha nagyon nehéz azoknak a személyeknek, akik soha nem gondolkodtak a készletek szempontjából, kilépni, elengedni az egyszerre történő feldolgozást és dolgozni a készletekkel.
Robin Bloor: Igen, veled vagyok ezzel. Úgy értem, most megkapom, ez egy oktatási kérdés; Azt hiszem, hogy ez teljesen oktatási kérdés, azt hiszem, hogy a programozók számára természetes az, hogy eljárási szempontból gondolkodjanak. Az SQL nem eljárási, hanem deklaratív. Valójában csak azt mondod, hogy „ezt akarom, és nem érdekel, hogyan csinálod”, tudod? Míg a programozási nyelvekkel gyakran felcsavarod a hüvelyed, és még a számlálások kezelésének apró pontjaiba is belekerülsz, miközben hurkot csinálsz. Átadom …
Bert Scalzo: Nem. Rendben, folytassa.
Igen, azt szeretném mondani, hogy hozott fel egy másik példát, hogy egy profilozó jó lenne megkapni ezt a fajta folytatást ezzel a rekord-egyszeri feldolgozással. Időnként egy olyan programozó, aki jól ismeri az egyidejű logikát, nem tudja kitalálni, hogyan kell csinálni az SQL programot. Nos, tegyük fel, hogy két FOR hurkot készít és alapvetően csatlakozik, de az ügyfél oldalán teszi meg. Tehát ugyanazt a hatást látja el, mint a csatlakozás, de maga is csinálja, és egy profil ezt elkapja, mert valószínűleg több időt költene a csatlakozás manuális elvégzésére, mint hogy hagyja, hogy az adatbázis-kiszolgáló elvégzi az Ön számára.
Robin Bloor: Igen, ez katasztrófa lenne. Úgy értem, csak dobálsz. A dobás mindig rossz.
Különben is, átmegyek Dezbe; Biztos vagyok benne, hogy van néhány érdekes kérdése.
Dez Blanchfield: Köszönöm, igen. Csatlakozom a busz alatt nem dobó programozókhoz. Úgy értem, túl sok évet töltöttem az életemben, hogy magam kódoló vagyok, minden szinten, tudod, hogy az, amint mondtad, a Unix gép parancssorán ül, és bizonyos esetekben még részt vettem az Unix néhány különféle portjában, az egyik hardverplatformról a másikra. És el tudod képzelni azokat a kihívásokat, amelyekkel ott voltunk. De a valóság itt az, hogy a börtönből ki lehet jutni a világ minden kódolójához és forgatókönyvéhez. Ez egy rakéta tudomány, egészen szó szerint, hogy minden alkalommal nagyon szorosan írj, mindig rakéta tudomány. És olyan híres történetek az emberekről, mint Dennis Ritchie és Brian Kernahan, akik önállóan dolgoznak valamilyen kóddarabon, majd egy kávéfőzőn átváltanak egy kódértékelő csevegésre, és megtudják, hogy pontosan ugyanazt a kódot írták ugyanabban a programban, pontosan ugyanúgy. És megtették a C-ben. De a programozás purista szintje nagyon ritkán létezik.
A helyzet az, hogy napi szinten csak egy nap 24 órájában, egy hét hét napjában van, és csak meg kell tennünk a dolgok. És tehát, amikor nemcsak a hagyományos programozókra, a DBA-kra és a kódolókra, valamint a szkriptekre és a rendszergazdákra, valamint a hálózati adminisztrátorokra és a biztonsági személyzetre vonatkoznak, és mindezek mellett a polgárok adatainak oldalán is; halljuk, mindenki csak próbálja megtenni a munkáját. És úgy gondolom, hogy az egész dolgom az, hogy imádtam a demodat, és imádtam azt az elvihetőséget, amelyet egy pillanattal ezelőtt elhagytál velünk, és Robin-nal beszélgettem arról, hogy ennek van valami különleges - talán nem is annyira egy rést - de egy széles teret, amelyre vonatkozik, a kód, az SQL és az adatbázisok rögzítéséig. De nagyon izgatottan hallottam, hogy azt mondtad, hogy egy shell-szkripttel szúrhatod le és találhatsz néhány kérdést, mert tudod, hogy a mai korban mindig mindent megteszünk a legalacsonyabb költséggel.
Azért vásárolhat egy 6 dolláros inget valahova, mert valaki elég olcsón épített egy rendszert ahhoz, hogy ténylegesen elkészítse és szállítsa, logisztikailag szállítsa, eladja és kiskereskedelme legyen, valamint online fizetéseket vegyen igénybe, hogy megkapja ezt a 6 dolláros inget. És ez nem történik meg, ha az embereknek évente 400 000 dollárt fizetnek, hogy tökéletesen írják a kódot; ez csak a teljes fejlesztés. Tehát erre a pontra, azt hiszem, az egyik kérdés, amit nagyon szeretnék, ha még több betekintést nyújtana nekünk, az, hogy mekkora szélességet és elérhetőséget kínál azoknak az embereknek a típusa, akiket éppen látnak, akik ilyen típusú eszközöket telepítenek a profilba egy kódot, és keresse meg a teljesítménygel kapcsolatos problémákat? Kezdetben, történelmileg, honnan származnak? A nagy mérnöki házak voltak? És akkor haladva tovább, hogy van-e ez a helyzet, helyesen gondolom, hogy egyre több vállalat alkalmazza ezt az eszközt, vagy ezeket az eszközöket, hogy megkísérelje segíteni a kódolókat, akik tudják, akik éppen dolgoznak a munka befejezéséért és kihozza az ajtón? És néha szükségünk van egy börtönből kiszabható kártyára? Igazam van abban, hogy azt gondolom, hogy történelmileg inkább a mérnöki tevékenységek középpontjában álltunk és fejlesztettünk? Most már kevesebbet kapunk, amint azt Robin mondta, az akadémiai megközelítést, és most öntanuló, vagy kivágó-beillesztő kód, vagy csak építeni a dolgokat? És ez megegyezik-e azokkal a fajta emberekkel, akik most a terméket használják?
Bert Scalzo: Igen, pontosan. És hozok egy nagyon konkrét példát, mi csak azt akarjuk, hogy a munka megtörténjen, mert az üzletemberek nem akarnak tökéletességet. Olyan, mint egy számítógépes sakkjáték: a sakkjáték nem keresi a tökéletes választ; arra vár választ, amely ésszerű időn belül elég jó, tehát így programozzuk. Most azonban azt tapasztalom, hogy a legtöbb ember ahelyett, hogy azt mondaná, hogy profilmérnököt akar az egységtesztjük részeként - így csinálnám, mert nem látom, hogy időpocsékolás - mi történik most, hogy később történik, néha az integrációs tesztelés vagy a stresszteszt során, ha szerencsénk van. De leggyakrabban ez egy eszkaláció része, ahol valami gyártásra került, egy ideig futott, talán még évekig is futott, és most már nem működik jól, és most profiloljuk. És úgy tűnik, hogy ez most a leggyakoribb forgatókönyv.
Dez Blanchfield: Igen, és úgy gondolom, hogy a „technikai adósság” kifejezés valószínűleg olyan, amellyel többet ismersz; Ismerem Robint és biztosan vagyok. Úgy gondolom, hogy manapság, különösen a fejlesztés és a rendszerépítés agilis megközelítéseiben a technikai adósság fogalma nagyon valóságos dolog, és ezt valójában a projektekben számoljuk el. Tudom, úgy értem, megvan a saját projektünk, mint például a Media Lens és mások, ahol napi rendszerességgel történik kódolás, és különféle dolgok vannak a Bloor Csoportban. És amikor valamit építenek, nézzünk rá, nézek rá, és mindig arra a szempontból nézem, hogy mekkora költségekkel járok ennek a helynek a javítása érdekében, szemben azzal, hogy csak a tudsz odavenni oda, majd megnézem és megnézem, megszakad-e ez a dolog. És örökölöm ezt a műszaki adósságot, amelyet tudok, hogy később vissza kell térnem és javítanom kell.
És úgy értem, megtettem ezt az elmúlt hét napban: írtam néhány szerszámot és szkriptet, írtam néhány darab Python-nyelvet, és telepítettem a Mongo hátsó oldalára, így biztos, hogy kedves, tiszta és biztonságos, de csak elvégzi a szükséges lekérdezést, tudva, hogy szükségem van erre a funkcióra a működéshez, és a nagyobb puzzle eléréséhez; itt van az igazi fájdalmam. Tehát ez a technikai adósság felmerül, és azt hiszem, hogy ez nem csak alkalmi dolog, azt hiszem, ez része a fejlődésnek a DNS-ében. Az emberek - nem félreérthetetlenül - egyszerűen elfogadják a technikai adósságot. Ez egy normál működési mód, és csak ki kell viselniük. Itt merül fel a technikai adósság. És azt hiszem, hogy az a nagyszerű dolog, amit a bemutatón mutattál nekünk, az volt, hogy szó szerint profilozhat és megnézheti, hogy mennyi ideig tart futni valami. És ez valószínűleg az egyik kedvenc dolgom. Úgy értem, ténylegesen profilozó eszközöket építettem - a Sedben, a Lexben és az Orcban eszközöket építettünk, hogy futtassuk a kódunkat, és megnézhessük, hol vannak a hurkok, még mielőtt ilyen eszközök elérhetők voltak volna - és amikor építettél a kódot, áttekinti a saját kódját, nagyon jó lesz, hogy nem kell átnéznie a saját kódját. De most nem erről van szó. Ezt szem előtt tartva van-e egy adott piaci szegmens, amely jobban felveszi ezt, mint bármely más? Látni, mint egy mise
Bert Scalzo: Ó, igen, megvan… Analógiát fogok megrajzolni neked, és megmutatom, hogy a nem programozók ezt mindig végzik. Mert ha valaha is hibakeresőt és profilkészítő osztályokat vagy munkameneteket tanítok, megkérdezem az emberektől: „Rendben, hogy itt hány ember lép be a Microsoft Wordbe, és szándékosan soha nem használja a helyesírás-ellenőrzőt?” És senki sem teheti fel a kezét, mert a dokumentumok írásakor mindannyian tudjuk, hogy angol hibákat is elkövethetünk, és így mindenki a helyesírás-ellenőrzőt használja. Azt mondtam: „Nos, miért van az, ha szöveget ír az IDE-jén, mint például a Visual Basic, nem használja a hibakeresőt? Ez ugyanaz, olyan, mint egy helyesírás-ellenőrző. ”
Dez Blanchfield: Igen, valójában ez egy nagyszerű analógia. Nem igazán gondolkodtam, be kell vallanom, hogy valójában valami hasonlót csinálok néhány eszközzel. Valójában az egyik, az ODF, a kedvencem az Eclipse-nél, az egyszerűen kivág és beilleszt be a kódot oda, és olyan dolgokat keres, amelyek csak rögtön kiemelkednek, és rájönve, hogy elrontottam néhány osztályhívást. És most érdekes az ilyen eszköz segítségével valós időben megcsinálni, ellentétben azzal, hogy visszajöjjön, és később megnézze, ami nagyon kedves előzetesen elkapni. De igen, ez nagyszerű analógia a szöveg csak egy szövegszerkesztőbe helyezésével, mert ez egy érdekes ébresztési hívás, amely csak akkor veszi észre, hogy hibát követett el, vagy akár nyelvtani hibát is, igaz?
Bert Scalzo: Pontosan.
Dez Blanchfield: Tehát most már látsz egy uptick-et, azt hiszem, úgy értem, hogy az utolsó kérdés tőlem van, mielőtt talán a Q & A kérdéseimet felveszem a résztvevőink számára. Ha valamiféle ajánlást fogsz adni ehhez a megközelítéshez - feltételezem, hogy ez retorikus -, van-e ez az eset, ha korán beérkezel, és ezt végre hajtod, amikor fejlődsz, még mielőtt fejlődsz? Vagy az a helyzet, hogy túlnyomórészt építenek, elmozdulnak, építenek valamit, majd bejönnek és később profiloznak? Gyanítom, hogy ez az eset, ha korán belépünk, és ellenőrizzük, hogy a kód tiszta-e előre. Vagy olyan eset, hogy fontolóra kell venniük a telepítés utáni részét?
Bert Scalzo: Ideális esetben először csinálnák, de mivel mindenki a nyüzsgő világban van, ahol csak el kellett készíteni a dolgokat, hajlamosak nem ezt megtenni, amíg olyan teljesítményprobléma elé kerülnek, amelyet nem tudnak megoldani. további CPU-k és memória hozzáadása egy virtuális géphez.
Dez Blanchfield: Igen. Tehát valójában megemlített valami érdekeset, ha gyorsan tudok? Már említetted, hogy ez bárhonnan futtatható, és a hátsó oldalon adatbázisokkal tud beszélni. Tehát ez jól illeszkedik a fajta bimodális koncepcióhoz, amelyről most beszélünk, a helyszíni / helyiség nélküli felhőről, a dolgok megjelenése alapján is, a nap végén, ha képes beszélni a hátsó részre és látni a kód, nem igazán érdekel, igaz?
Bert Scalzo: Pontosan, igen, ezt futtathatja a felhőben.
Dez Blanchfield: Kiváló, mert szerintem ez az, ahová az új bátor világunk megy. Tehát, Eric. Most visszamegyek hozzád, és látom, hogy van néhány kérdésünk itt, és szeretném, ha a résztvevőink továbbra is velünk maradnak, annak ellenére, hogy már túlléptük az órát.
Eric Kavanagh: Igen, van néhány ember odakinn, csak egy rövid kommentárt teszek: Bert, azt hiszem, hogy a metafora, az analógia, amelyet a helyesírás-ellenőrzéshez adsz, őszintén briliáns. Ez méltó egy vagy két bloghoz, őszintén szólva, mert ez jó módja annak, hogy meghatározzuk a kontextust, hogy mit csinálsz, mennyire értékes, és hogy valóban hogyan kell a hibakereső bevált gyakorlata lenni. rendszeresen, ugye? Fogadok, hogy néhány fej bólint, amikor kidobja, ugye?
Bert Scalzo: Abszolút, mert azt mondom nekik: „Miért végezek helyesírás-ellenőrzést a dokumentumokon? Nem akarom, hogy zavarba ejtsenek a hülye helyesírási hibák. ”Nos, nem akarják, hogy zavarják a hülye kódolási hibák!
Eric Kavanagh: Igaz. Igen valóban. Nos, emberek, egy órát és öt percet égetünk itt, annyira nagy köszönet mindannyiótoknak az idejéért és a figyelemért. Archiváljuk ezeket a webes csevegéseket, bármikor visszatérhetünk és ellenőrizhetjük őket. A linkek megtalálásának legmegfelelőbb helye valószínűleg a techopedia.com, tehát ezt a listát itt egészítjük ki.
És ezzel búcsút fogunk adni neked, emberek. Ismét nagyszerű munkám, Bert, köszönhetően az IDERA barátainknak. Legközelebb beszélünk veled, valójában a jövő héten beszélünk veled. Vigyázz magadra! Viszlát.
