Elvitel: Eric Kavanagh házigazda megbeszélte az adatbázis hibakeresését és profilozását Dr. Robin Bloor, Dez Blanchfield és az IDERA Bert Scalzo.
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ás, kivéve, ha te vagy a személy, aki ezt csinálja. Ebben az esetben azt szeretné megbizonyosodni, hogy jól csinálja-e. Mert a hibakeresésről beszéltek. 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 fognak beszélni.
Van egy hely a sajátodról, igazán engem talál, @eric_kavanagh, természetesen.
Ez az év forró. És a hibakeresés forró lesz, nem számít. Valójában ezeknek a problémáknak az egyikét képezi, amelyek soha nem fognak eltűnni, nem számít, mennyire jók a dolgok, ezek mindig problémák lesznek, tehát a legfontosabb az, 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?
Jól hallgassa meg Dr. Robin Bloort, majd alulról saját Dez Blanchfield-t, és természetesen jó barátunkat, Bert Scalzo-t, az IDERA-tól. És valójában, én le fogom adni a kulcsot Robin Bloornak, és el kell vinni. A padló a tiéd.
Robin Bloor: RENDBEN. 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 folytatok, hogy teljes körű képet kapjunk a zajló eseményekről. Hosszú ideig ezt tettem, és régen kódoló voltam, azaz hasonló, és szinte a kísértésem elõtt a bemutatóval kezdtem el szövegezni a nyílt forráskód elképzelésérõl, de azt hittem, hogy ezt valakinek hagyom.
Itt vannak a híres hibák listája, és ezek többsége az anybodys top listájára kerül, alapvetően mindegyik kivételével, az utolsó két kivételével legalább 100 millió dollárba kerülnek. 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 vagyok biztos benne, hogy van-e ez. 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 egy kódolási kísérlet volt, amely hirtelen versenyképes féreggé vált, amely mindenütt körbekerült - nyilvánvalóan 100 millió dolláros kárt okozott; ez egy becslés természetesen. 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 program valószínűleg a legrosszabb és legveszélyesebb indí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 - ez valami hasonló költsége szempontjából csak é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 egyesült királyságbeli biztosítótársaságnál voltam, és az adatbázist, ú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, ez egyébként is. Azt hittem, beszélek az impedancia-eltérésről és a kiadott SQL-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óban nem igazán mutatnak táblázatokat. És emiatt megkapja az impedancia-eltérésnek nevezett eseményeket, és valakinek valamilyen módon kell foglalkoznia vele. De mi történik valójában, mert az egyik modell, a kódoló modell és az adatbázis másik modellje, nincs különösebben összehangolva. Olyan hibákat kap, amelyek csak nem fordulnak elő, ha az iparág dolgokat építenek, 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ípusúak, eredményhalmazokat eredményezhetnek, gyenge API-képességek is lehetnek, sok olyan dolog lehet, amelyek csak kihozzák a dolgokat az adatbázis-interakció szempontjából. De a legfontosabb dolog számomra, nagyon é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 nemcsak referenciális integritásra és lépcsőzetes törlésekre és hasonló dolgokra volt szükség, az adatbázis gondoskodott arról, hogy a funkciókat hirtelen egy adatbázisba helyezzék, ami természetesen azt jelentette, hogy egy az alkalmazást meg lehet osztani 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. Tehát ez az adatbázis-játék egyik oldala, mivel ez azt jelenti, hogy sok megvalósításban részesült, például hogy a relációs adatbázisokban részt vettem, valójában egy szörnyű sok olyan kód, amely a tárolt eljárásokban ül, és amelyet a kódtól külön kezelnek. ül az alkalmazásokban. És nagyon furcsa dolognak tűnik, amit meg kellett volna érkeznie, állítólag 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 problémák lehetnek a teljesítménygel. Az ötlet az lenne, hogy a kódolónak valóban nem kellett volna 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 én sokat tettem -, és gyakran felfedezi a hibakereséshez hasonló minden helyzetét, amelyet valaha tapasztaltam. az, hogy az első dolog, amit valaha látott, 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 egy adatbázis-kérdést vizsgál, 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ábbadjam a labdát, Dez.
Eric Kavanagh: Átadom, várom, tartsd fenn.
Automatizált hang: A résztvevő vonalai elnémultak.
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óban a legjobban igazad van: ez egy téma, egész életen át tartó hibás, ha megbocsátja a büntetést, sajnálom, hogy nem tudtam magam segíteni. 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. Ilyen széles és tág témája, ezért két kulcsfontosságú területre összpontosítom a hangsúlyt, nevezetesen annak a koncepciónak, amelyet sok hibának tartunk, 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 inkább profilkód esetén, és lehetséges, hogy olyan kódot írjon, 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 szeptember 9-én fordul előth, 1945, a Harvard Egyetem egy csapata széttépett egy gépet, találkoztak valamival, amit „hetven relének” hívtak - akkoriban a programozás fizikai értelemben zajlott, kódot tekercseltél egy tábla körül, és így hatékonyan programoztad a gép - és azt találták, hogy ez a relé száma hetven volt, valami nem volt benne, és kiderül, hogy a tényleges „hiba” kifejezés azért jött létre, mert szó szerint egy lepkék volt - állítólag ott volt egy lepke, amelybe valamelyik rézhuzal darabja bedugott egyik helyről a másikra. És a történet megragadja, hogy a legendás Grace Hopper, mint ez a felirat a címsoromra, „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, vagyis nem annyira, mint a kódolási kérdésekre egy olyan programban, amely nem fordul elő, hanem mint olyan program is, amely nem működik jól. És kifejezetten nem profiloztak, csak találnak 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 az a klasszikus rajzfilm, amelyet az interneten XKCD-nek hívnak, és a karikaturistának nagyon vicces nézete van a világról. És ezek egy „Kis Bobby Táblázatok” nevű gyerekről szólnak, és állítólag szülei ezt a fiatal fiút Robertnek nevezték el; DROP TÁBLÁZAT Diákok; - és az úgynevezett, és az a fajta: „Helló, ez a fiai iskolád valamilyen 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 fiad, Robertet; LEHETSÉGES TÁBLÁZATOK Diákok; -? ”És a szülő azt mondja:„ Ó, igen, kicsi Bobby Táblázatokat hívjuk. ”Egyébként továbbra is azt mondják, hogy elvesztették az évek 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 is nézi az adatokat .
Egy másik vicces, nem tudom, valós-e 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ók 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 az a véleményem, hogy ez az idő telt el, és tapasztalatom szerint anekdotikusan az első - és ez rettenetesen öregszik, biztos vagyok benne; Üdvözöljük, hogy Robin engem szórakoztat. - De történelmileg 14 éves korában jönnek a háttérbe, amikor a város végén vándorolnak, és az új-zélandi „Data Com” nevű adatközpont kopogtatnak, és azt kérdezik, hogy Zsebpénzt kereshetnék az iskolában, ha hazafelé haladnék a késő busszal, kb. 25 km-es ingázással, papírokkal, szalagokkal és szalagmeghajtókkal, és egyszerű 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 volt. Alapvetően gondoljon úgy, mint egy nagyon régi írógép papírjára, amelyen átgördült, mert nem volt CRT-csőjü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 megtettél annak érdekében, hogy ne essen hibákat a becsapódásba, mert rendkívül bosszantónak kell mondania az egysoros szerkesztővel egy bizonyos sorra lépni, majd a sorra, majd újra beírni. De régen írtuk a kódot, és mi történt a hibakeresés, é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 mindegyikük is ismerte 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, mint amit tettek. a papírszalagon, ed formátumban 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 megszabaduljon a rossz gyakorlattól. 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 az, hogy elmondjam neked, azaz 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 megbizonyosodjon arról, hogy nem mutattam be hibákat. kód.
Programozási módszerek manapság olyan dolgok, mint például a strukturált lekérdezési nyelv, SQL, ez egy nagyon hatékony, egyszerű lekérdezési nyelv. De mi programozási nyelvré változtattuk, és nem igazán hiszem, hogy az SQL-t valaha modern programozási nyelvként fejlesztették ki, de elcsúsztattuk, hogy ilyenvé váljon. És ez egy egész csomó kérdést vezet be, amelyek akkor merülnek fel, 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 tapasztalat hiánya, például a klasszikus kisállat-hámozás, amikor például az SQL-emberekkel ugráltam a Google-on, kerestem valamit, és megtalálom a 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ült, például ezekben a napokban mind rohantak ennek felé, 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 alkalmazzunk alacsonyabban fizetett alkalmazottakat. Nem értem ezt félreértő módon, de nem bocsátottam fel szakértőket minden lehetséges munkára. 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 a fejlesztésbe és a tervezésbe és az adatbázisba sok ember bekerül, akiknek már éves tapasztalata van, ugyanannak a képzésnek vagy támogatásnak nem volt szükségük. És tehát csak a hagyományos amatőr versus szakértő forgatókönyvével ér véget. És ha egy híres vonalra emlékszem, valójában nem emlékszem, ki készítette az árajánlatot, ez a sor így szól: „Ha úgy gondolja, hogy drága szakértő felvétele egy munka elvégzésére, várjon, amíg felhív egy pár amatőröt, akik problémát okoznak, és tisztítsa meg. ”És így az SQL-nek van ez a kérdése, és nagyon-nagyon könnyű megtanulni, nagyon könnyen használható. De véleményem szerint ez nem tökéletes programozási nyelv. Ez nagyon egyszerűen elvégezhető, mint például egy kiválasztott csillag bárhonnan, és mindezt olyan programozási nyelvre húzhatja, amelyben jobban megfelel, mint például a PHP, a Ruby vagy a Python, és az eredeti manipulációhoz használja a született programozási nyelvet, ahelyett, hogy bonyolultabb lekérdezést végez az SQL-ben. És ezt sokat látjuk, majd az emberek azon gondolkodnak, miért fut az adatbázis lassan; azért, 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 üthessem ezt a pontot haza, itt egy példa, amelyet sokat hordozok. Nagyon kedveltem a matematikát, szeretem a káoszelméletet, a Mandelbrot készleteket. A jobb oldalon ott van a Mandelbrot készlet ábrázolása, amelyet biztosan ismertek. És a bal oldalon ott 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; egy nagyon erősen 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 összetett konstrukciókat és tárolt eljárásokat kaptunk, programozási módszertant alkalmaztunk egy nyelvre, és így nagyon könnyű a rossz programozási gyakorlat, a tapasztalat hiánya, a kivágás és beillesztés kódja, az alacsony fizetésű alkalmazottak magas fizetésű alkalmazottak legyenek, az emberek úgy tesznek, mintha tudnának, de meg kell tanulniuk a munkát.
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 igazán kedves, és azt gondolod: „Hű, milyen nagyszerű grafika, szeretném ezt lefuttatni.” De képzeljétek 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öldnek lenni egy zöld képernyőnek lennie, 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 írtak, mint a C ++, de az SQL kódolású. É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 rendelkezel a megfelelő eszközökkel, ha nem rendelkezel a megfelelő platformokkal és a környezettel, hogy képesek legyenek ezeket a dolgokat elkapni, és elkezdik a termelést, akkor mindenki 100 000 ember üt egy rendszert Nap, óra, vagy perc, nagyon hamarosan olyan 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 igazán szép kód, de lehetővé teszi a DBA beszerzését, hogy segítsen ennek a strukturált lekérdezésnek a megfelelő felépítésében, mert őszintén szólva, ez csak csúnya.” És az ott található URL-ekkel megnézheti a nézetet - erre a a legbonyolultabb SQL lekérdezés, amit valaha írtál. Hidd el nekem, ez valójában lefordít, meg is fut. És ha ezt kivágja és beilleszti, és csak felsemmisíti az adatbázist, azt nagyon meg kell nézni; Ha rendelkezel az adatbázis figyelésére szolgáló eszközökkel, csak próbáljon megolvadni három-öt perc alatt, hogy visszahívja, hogy mi az egyik sor.
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 óvatosak, akkor a 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 korábban mondtam: egyszer csak meg tudta csinálni egy zöld képernyőn. Nem tudsz 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 a cuccokat, amikor nem tudják megtudni, miért kerülnek a dolgok hosszú idő futni.
És ezt szem előtt tartva átadom vendégünknek, és nagyon várom, hogy meghallgassam, hogyan oldják meg ezt a kérdést. És különösen azt a demót, amelyet szerintem megkaptak. Eric, átmegyek.
Eric Kavanagh: Oké, Bert, vedd el.
Bert Scalzo: Rendben köszönöm. Bert Scalzo itt, az IDERA-tól, az adatbázis-eszközöink termékmenedzsereként. És a hibakeresésről fogok beszélni. Úgy gondolom, hogy az egyik legfontosabb dolog, amit Robin korábban mondta - és nagyon igaz, hogy a hibakeresés megterhelő és nem triviális, és amikor az adatbázis hibakeresésére megy, még nagyobb terhet jelentő és nem triviális nagyságrenddel - tehát 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, amelyet használnak, és sokszor azt mondják nekem: „Nos, ezek a hibakeresési dolgok új, és ezeket még nem kezdtük el használni. ”És tehát az, hogy megteszem, megmutatom nekik ezt az ütemterv-diagramot, az előzetes történelem fajtáját, az öregkorot, a középkorot, annak mondását, hogy hol voltunk programozási nyelvek fogalma. É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 lehet azt mondani: "Hé, nem használom a hibakeresőt, mert ez az egyik új dolog". Akkor már el kellett kezdenie a programozást, tudod, még az 1950-es években, ez az egyetlen módja annak, hogy távol az állítástól.
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 az a fajta vicces. És akkor a másik dolog, amiben nevettem, az a teletípusokról beszélt és ott ülve ültem: „Ember, ez volt a legnagyobb ugrás, amit valaha a termelékenységben tettünk, amikor kártyáktól teletipussá váltunk, ez volt a legnagyobb ugrás valaha”. , és az Ive az összes nyelven beprogramozott, ideértve a SNOBOL-ot is, amelyről még soha nem hallottunk. Ez egy CDC, a Control Data Corporation volt, tehát azt hiszem, kicsit túl öregszem az ipar számára.
Dez Blanchfield: Azt akartam mondani, hogy borzasztóan öregedtél minket ott.
Bert Scalzo: Igen, mondom neked, úgy érzem magam, mint Simpson nagypapa. Tehát megvizsgálom a hibakeresést és a hibakeresés különféle módjait. 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; ezekben 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, ennek módja, de számít. Ugyanakkor megkaptuk a híres nyilatkozatot: Ön figyeli, és az emberek ténylegesen beillesztik az utasításokat, és láttam egy eszközt, ahol - és egy adatbázis eszközt - ahol ha nem tudod használni a hibakeresőt, akkor nyomd meg a gombot, és ez ragaszkodni fog. nyilatkozatokat az egész kódban az Ön számára, majd amikor elkészült, nyomjon meg egy másik gombot, és ez kiszabadítja őket. Mert az, hogy sok ember 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 logikai hibát jelent, vagy elmulasztottuk az üzleti követelményt, de ami az, hogy a kód nem hatékony; nem azt csinálja, amire számítottunk. 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 ami az, hogy helyesen csináltam, csak nem tér vissza elég gyorsan. Most arra gondolok, mert a profilozók valószínűleg jobbak a második forgatókönyvhöz, és mind a hibakeresőkről, mind a profilolókról beszélni fognak. Ezen felül a távoli hibakeresés ezen koncepcióját is; ez azért fontos, mert sokszor ha a számítógépen ül, és egy hibakeresőt használ, amely eltalálja az adatbázist, ahol a kód ténylegesen végrehajtódik az adatbázisban, akkor valójában távoli hibakeresésnek nevezik. Lehet, hogy nem veszi észre, de mi történik. És akkor nagyon gyakori ezekkel a hibakeresőkkel: törési pontok, megfigyelési pontok, belépés és átlépés, valamint néhány más általános dolog, amit egy pillanat alatt megmutatok a képernyő pillanatképein.
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 annál jobb, ha elvégzett mintavétel. Nincs ok arra, hogy minden egyes állítást elkapjunk, mert egyes állítások olyan gyorsan futhatnak, hogy nem törődsz vele. Amit valójában megpróbálsz látni, nos, ezek azok, amelyek újra és újra megjelennek, mert túl hosszúak. . 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-fogyasztá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 működnek. É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 nyelveiről, amint arról már korábban beszéltünk, megvan az SQL - és valamiféle kényszerítettük a kör alakú csapot a négyzet alakú lyukba, és kényszerítettük, hogy programozási nyelvgé váljon -, valamint az Oracle-t.A PL / SQL - az SQL eljárási nyelv és az SQL Server, a Transact-SQL, az SQL-99, az SQL / PSM - az, azt hiszem, az eljárással 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 SQL idegen dolgaihoz 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árolhat az adatbázisban kódként - ha csinálok T- SQL vagy PL / SQL - és objektumok tárolása az adatbázisban, valószínűleg egy tárolt eljárás vagy tárolt funkció. De az események szintén kiváltanak: egy eseményindító olyan, mint egy tárolt eljárás, de valamilyen eseményre lő. Most néhány ember a triggerekbe egy sor sorba helyezi a kódot, és elhívja a tárolt eljárást, hogy megőrizze az összes tárolt kódját és eljárását, de ugyanaz a koncepció: még mindig a trigger lehet az, ami az egészet iniciálja. É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, az örökös hibakereső a régi módon; 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, szintén a nem kézi hibakeresési módszer.
És azért hozom fel ezt, ha ha kézzel próbálod ezt megtenni, akkor valójában több hibakeresési kódot ír be, hogy mindezeket az állításokat beírja, mint ahogy a kóddal tetteted. 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 Ive-nek meg kellett várnia, amíg fut, egészen a befejezésig, majd Ive-nek meg kellett néznie egy nyomkövetési fájlt, amelyben valószínűleg megtalálhatók az összes ilyen állítás, és megpróbálnia megtalálni a tűt a szénakazalban. Ez ismét jobb, mint semmi, de nem lenne a legjobb módja annak, hogy működjön. Most néz ki ez a fájl, ahogyan az az előző diaból származik; Más szóval, futtam a programot, és csak egy csomó kijelentés van ebben a nyomkövetési fájlban, és valószínűleg nem vagyok képes arra, hogy átvizsgáljam és megtaláljam azt, amit kell. Tehát ismét nem vagyok benne biztos, hogy ilyen módon szeretne dolgozni.
Az interaktív hibakeresők - és ha valami hasonlót használtak a Visual Studio-hoz programok írására, vagy az Eclipse-t, akkor vannak hibakeresők, és más nyelveidet használtad - csak nem gondoltad, hogy itt használd őket az adatbázisoddal. É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 az, hogy megy, és megnézem, van-e több sorom 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 Ive középen helyezte a forráskódomat, a Ive az úgynevezett óraváltozókat és a hívásverem-tálcáimat, majd az alján Ive kapott néhány kimenetet. És ami itt fontos, az az, 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 ebben a változóban, miközben átmentem a kódot. És ez nagyon hasznos, és aztán egyszerre egy sort sorakozhatok a kódon keresztül, nem kell mondanom, hogy végre kell hajtanom, mondhattam egy sort egy lépésre, hadd nézzem meg, mi történt, lépjünk egy másik vonalra, hadd lássam, mi történt, és Ezt csinálom az adatbázisban. É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é mutatva, az a pont, ahol jelenleg a kurzorom van - tehát más szavakkal, Ive lépett, és ott van, ahol pillanatnyilag vagyok. Tehát, ha azt mondom: „Lépjen újra”, megyek a következő sorra. Most, közvetlenül alatta, látni fogja a piros pontot. Nos, ez egy töréspont, amely azt mondja: „Hé, nem akarok ezen vonalakon átmenni.” Ha csak át akarok ugrani mindent és eljutok oda, ahol ez a piros pont van, megüthetem a Futtatás gombot, és innen tovább futhatok a a végére, vagy egy töréspontra, ha vannak beállítva töréspontok, akkor az megáll, és hagyja, hogy újra elvégezzem a lépést. Mindez nagyon fontos és hatalmas oka az, hogy amikor mindezt megteszem, a középen és az alján - de ami a legfontosabb - középen - zajló események megváltoznak, és látom az értékeket a változóimból, Lásd a hívásverem nyomkövetését, tudod, és így az összes információ ott megjelenik, amikor léptem át a kódot, így valójában láthatom, megértem és megértem, mi folyik és hogyan működik a kód a végrehajtáskor . És általában olyan problémát találok, 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 az Im in Rapid SQL alkalmazásban látom, hogy egy margó látható a bal oldalon, a sorszám mellett. És ami ez, az az, hogy hány másodpercet vagy mikrosekundumot igényelt az egyes kódsorok végrehajtásához, é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 a FOR-hurok belsejében zajló vizeket valószínűleg valami olyasvalamit kell megvizsgálnom, és ha jobban tudom javítani, akkor osztalékot fog fizetni. Nem fogok javulni azáltal, hogy azokon a vonalakon dolgozom, amelyek 0,90 vagy 0,86; ott nem sok időt töltöttek. Most, ebben az esetben ismét a Rapid SQL-ben vagyok, látni fogod, hogy hogyan tudom profilozni a hibakeresést. Most, ami nagyon kedves, a Rapid SQL lehetővé teszi, hogy más módon is csináld. A Rapid SQL lehetővé teszi, hogy azt mondja: „Tudod mit? Nem akarok a hibakeresésben lenni, csak futtatni akarom ezt, és 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 futtatja a programot, és miután a végrehajtás megtörtént, grafikonokat ad nekem, hogy elmondjam a dolgokat, így láthatom, hogy Ive kapott egy kijelentést, amely úgy néz ki, mintha a pite nagy részét elfoglalná. ábrát, és ha megnézem, látom, hogy ezen a rácson az alsó felé, a 23. sorba kerül, újra a FOR-hurok: ő veszi fel a legtöbb időt, valójában az, hogy 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 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 nem igazán az az oka, amit csinálsz - ígérte az üzletnek, hogy helyesen fog tenni valamit, hogy a programja eredményes lesz. Amit használni fogja a hibakeresőt. Ezen felül üzleti végfelhasználók; nem nagyon türelmes: eredményt akarnak még a gomb megnyomása előtt. El kellett volna olvasniuk a gondolatukat, és mindent azonnal meg kell tenni. Más szavakkal, hatékonynak kell lennie. És tehát az, amit felhasználnánk a profilkészítőre. Most, ezen eszközök nélkül, azt hiszem, hogy ez a fickó az öltönyben van, íjjal és nyíllal, és a célra lő, és bekötött szemmel látja. 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 derül ki ezek közül a dolgok közül, de nem garantálja, hogy a kód áttekintés mindegyiket megtalálja. A hibakereső és a profilkészítő segítségével meg kell találnia az összes ilyen hibát.
Rendben, csak egy valódi 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 a hibakereső, mert sokszor azt mondják az emberek: „Soha nem láttam ilyenet korábban.” És a képernyő pillanatképei csúszik, de mi az, 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 ragadjon bele a termékbe. É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ílom, a tetején, az első sorban, ott, ahol vagyok a kódban. És ha ott megnyomom a harmadik ikont, amely egy lépés, akkor látni fogja, hogy a nyíl éppen mozogott, és ha tovább nyomom, akkor látni fogja, hogy mozog. Most, ha végig akarok menni ehhez a FOR-hurokhoz, mert tudom, hogy ott van a probléma, beállíthatom egy töréspontot. Azt hittem, ezt beállítottam. Ó, lő, az egyik képernyővételi kulcsom ugyanahhoz a kulcshoz lett ragasztva, mint a hibakereső, ami mi 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. Figyelje meg, hogy egészen addig ment, ahol a töréspont van, tehát most már folyamatban vagyok ennek a huroknak a futtatásában, látom, hogy az összes változóm van beállítva, ami nem meglepő, mert mindegyiket inicializáltam nulla. É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ót a bérleti díjaimból, és rá tudok mozgatni az a srácot, és megnézem: ketten 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. Csak megyek előre, é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. Megkaptam a töréspontot, tehát amikor azt mondtam, hogy fut, csak visszatért a következő törésponthoz. Ha hagyom, hogy a végére futjon, azt okozhatja, amit látni szeretnék, mert egy hibakereső nem változtatja meg a program viselkedését: amikor fut, akkor pontosan ugyanazt az eredményt kapom, ha nem a hibakeresőben futtam.
Ezzel felfüggesztem a demonstrációt, és visszamegyek, mert meg akarjuk győződni arról, hogy van időnk kérdéseire é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 pár pár Dezből?
Robin Bloor: Igen, persze, ezt természetesen lenyűgözőnek találom. Ive ilyesmivel dolgozott, de ilyesmivel sem dolgozott az adatbázisban. Tudsz nekem képet adni arról, hogy mire használják az emberek a profilkészítőt? Mivel hasonlók, néznek - mert feltételezem, hogy vannak - a teljesítmény kérdéseit vizsgálják, segít 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 én, a Visual Basic-ben dolgozom, 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ás közül itt olvashatók el az öt, amelyek a problémát okozták.” És így lehet, hogy tagcsapatot kell létrehoznia, 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ívták 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álja azokat a helyeket, ahol a hatékony kód, amit csak túl gyakran hívnak, és valójában teljesítményprobléma.
Robin Bloor: Igen, 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 megint nem tettem: - Ive soha nem vett részt olyan alkalmazások építésében, ahol eljárásokat tároltunk, tehát azt gondolom, hogy az Ive soha nem merült fel olyan problémákkal, amelyek régen vadul engem idéztek elő, az az ötlet, hogy a kódot felosztja egy adatbázis és egy program. De igen, mindent megteszek - feltételezem, hogy a válaszok igenek lesznek, de ez egy fejlesztői csapat tevékenységének része, amikor valamilyen módon próbálsz megjavítani valamit, ami összetört, vagy esetleg új alkalmazást próbálsz összehozni. 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 a programozási vagy fejlesztési erőfeszítések elvégzéséhez. És az a 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 nagyon jó programozókkal tettek szóba, 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ényleg felbukkan, és így most teljesítményprobléma. És tudták, hogy a probléma nincs Java-jaikban vagy bármelyik másik helyen. 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óban azt tapasztaltuk, hogy derékszögű csatlakoztak valamelyik kiválasztott kijelentésükhöz, és nem tudták.
Robin Bloor: Azta.
Bert Scalzo: De valaki egyszer azt mondta nekem: „Nos, hogyan csatlakozhattak volna egy derékszögűek, és nem tudták?” És ez nagyon borzalmasan hangzik; Időnként egy olyan programozó, akinek az SQL-ét nem igazán látja el, úgy fog tenni, mintha egy derékszögű csatlakozást adna nekem, de csak az első rekordot adja vissza, tehát tudom, hogy van valami, és csak az elsőre van szükségem. És így nem is tudják, hogy csak milliárd lemezt hoztak vissza, vagy egymilliárd lemezt keresnek át, mert megkapta az érdeklődésüket.
Robin Bloor: Hát, tudom, amit hívnak - nos, az az, amiben Dez zajlott, tudod, hogy nem az emberek olyan pontosan képesek, mint amilyennek valószínűleg lehetnek. Ha programozó vagy, akkor tudnod kell, hogy mi az a parancs kiadásának következménye. Valójában úgy gondolom, hogy nem szabad mentségülni a hülyeségnek. Feltételezem azt is, hogy egy vagy másik módon csak agnosztikus vagy a nyelv, mivel 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óként tanulsz, akkor egyszerre rekordot tanítasz. 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; ennélfogva miért van az unió, a kereszteződés és a mínusz operátor. És néha nagyon nehéz az a személy, aki soha nem gondolkodott 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 erről. Úgy értem, most kapok, ez egy oktatási kérdés; Úgy gondolom, hogy ez teljesen oktatási kérdés, azt hiszem, hogy természetes a programozók számára eljárási gondolkodásmód. És 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 felcsavarodott ujjaidat, és lekerültek a számlálások kezelésének apró részleteibe, miközben hurkot csinálsz. Beteg kezét ...
Bert Scalzo: Nem. OK, 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 egy időbeni logikát, nem tudja kitalálni, hogyan kell csinálni az SQL programot. Nos, mondjuk, 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 hajtja végre, 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, mintha hagyná, 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 szemetet 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, az Unix gép parancssorán ült, és bizonyos esetekben akár egy pár különböző Unix port az egyik hardverplatformról a másikra. És el tudod képzelni azokat a kihívásokat, amelyekkel ott voltunk. A valóság azonban az eretnekségek számára a börtönből való kivonás kártyája a világ minden kódolójának és forgatókönyvének. 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 egy 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óddarabot írták, pontosan ugyanabban a programban, pontosan azonos módon. És megtették a C-ben. De a programozás purista szintje nagyon ritkán létezik.
A helyzet az, hogy napi rendszerességgel csak egy nap 24 órájában, egy hét hét napján kell működni, és csak meg kell csinálni a dolgokat. É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, hogy mindenki csak próbálkozik a munkájával. É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 shell-szkripttel szúrhatod le és találhatsz néhány kérdést, mert tudod, hogy a mai nappali és korosztály mindig mindenképp a lehető legalacsonyabb költséggel dolgozott.
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 ember évente 400 000 dollárt fizet azért, hogy tökéletesen írja a kódot; csak teljes fejlesztése. Tehát erre a pontra, azt hiszem, az egyik olyan kérdés, amelyben nagyon szeretlek, hogy csak további betekintést nyújtson nekünk, mi az a szélessége és elérhetősége, amelyet jelenleg látnak azok az emberek, akik éppen ilyen típusú eszközöket használnak a kód profilozásához és megjelenítéséhez. a teljesítmény kérdéseire? 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égre összpontosítottuk és fejlesztettük? Mostantól kevesebb lett volna - amint azt Robin mondta - az akadémiai megközelítés, és most a saját tanítása, a kivágás és beillesztés kódja, vagy éppen a dolgok építése? És ez megegyezik-e azokkal a fajta emberekkel, akik most a terméket használják?
Bert Scalzo: Igen, pontosan. És nagyon konkrét példát mutatok neked, csak a munkát akarjuk elvégezni, mert az üzletemberek nem akarnak tökéletességet. Olyan, mint egy számítógépes sakkjáték: a sakk nem keresi a tökéletes választ; arra vár választ, hogy ésszerű idő alatt elég jó legyen, tehát a programozás módja is. De amit most találok, a legtöbb ember ahelyett, hogy azt mondaná, hogy profilmérőt akar az egységtesztük részeként - így csinálnám, mert ezt nem fogom időpocsékolásnak tekinteni - mi történik most, amit csinálnak később, néha az integrációs tesztelés vagy a stresszteszt során, ha szerencsések voltak. De a legtöbb esetben az eszkaláció része, ahol valami termelésbe került, egy ideig futott, talán még évekig is futott, és most már nem jól fut, és most jól profilolja. É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 több, mint amit ismeri; 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 projektjük, mint például a Media Lens és mások, ahol napi rendszerességgel történt a kódolás, és a Bloor Csoport különféle dolgaival. És amikor építenek valamit, nézzük meg, nézzük meg, és mindig arra a szempontból nézzünk, hogy mekkora költségekkel járok ennek a helynek a javítása érdekében, szemben azzal, hogy csak dobozba tehetem és vegye ki oda, majd nézze meg, hogy megtörténik-e ez a dolog. És örökölöm ezt a műszaki adósságot, amelyet tudom, hogy később vissza kell fordulnom és meg kell javítanom.
És úgy értem, az Ive ezt tette az elmúlt hét napban: Ive írt néhány eszközt és szkriptet, Ive írt néhány darab Python nyelvet, és az Ive telepítette a Mongo hátsó részébe, ügyelve arra, hogy szép, 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; az ott 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 adódik 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, hogy Ive ténylegesen profilozó eszközöket épített - szerszámok készítésére használtuk a Sed-ben, a Lex-ben és az Orc-ban, hogy futtassuk a kódunkat, és megnézhessük, hol vannak a hurkok, még mielőtt ilyen eszközök rendelkezésre álltak volna - és amikor építettél kódot, hogy áttekintsd a saját kódod , nagyon jó lesz, ha nem kell felülvizsgálnia a saját kódját. De most nem ez a helyzet. 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, Ive-nek… Analógiát fogok megrajzolni neked, és megmutatom, hogy a nem programozók mindig ezt teszik. Mert ha valaha is hibakeresőt és profilkészítő tanfolyamot vagy munkamenetet tanítok, arra kérdezem az embereket: „OK, itt hány ember lép be a Microsoft Wordbe, és célszerűen 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 követünk el, és így mindenki használja a helyesírás-ellenőrzőt. Azt mondtam: „Nos, miért van akkor, ha olyan IDE-ben írsz, mint a Visual Basic, de nem használod a hibakeresőt? Ugyanaz, olyan, mint egy helyesírás-ellenőrző.
Dez Blanchfield: Igen, valójában ez egy nagyszerű analógia. Nem igazán gondolkodtam rajta, be kell vallanom, hogy valójában valami hasonlót csinálok néhány eszközzel, amelyeket használok. 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 mivel érdekes most az ilyen eszköz segítségével, valós időben meg is csinálhatja, ellentétben azzal, hogy visszajöjjön, és később megnézze, ami nagyon kedves előzetesen elkapni. De igen, ez egy nagyszerű analógia a szövegszerkesztőbe való beillesztésével, és ez egy érdekes ébresztési hívást idéz elő, csak azt kell észrevenni, hogy hibákat tettél vagy akár nyelvtani hibát is igaz?
Bert Scalzo: Pontosan.
Dez Blanchfield: Tehát, most már lát valamit egy uptick-ból, azt hiszem, úgy értem, hogy az utolsó kérdés tőlem van, mielőtt talán a Q & A kérdéseinket felhívnánk a résztvevők számára. Ha valamiféle ajánlást fog adni ehhez a megközelítéshez - ha feltételezzük, hogy ez retorikus -, akkor van-e az a helyzet, hogy korán belépsz, és ezt megvalósítod, ahogy fejlődsz, még mielőtt fejlődsz? Vagy az a helyzet, hogy túlnyomórészt építenek, mozognak, építenek valamit, majd bejönnek és később profiloznak? Gyanítom, hogy ez az eset a korai bejelentkezés, és ellenőrizze, hogy a kódok előzetesen tiszta. Vagy olyan eset, hogy fontolóra kell venniük a telepítés utáni részét?
Bert Scalzo: Ideális esetben előzetesen 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ül, amelyet nem tudnak megoldani több CPU és memória hozzáadásával. egy virtuális gépre.
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, ez nem igazán érdekli, igaz?
Bert Scalzo: Pontosan, igen, futtathatja ezt a felhőben.
Dez Blanchfield: Kiváló, mert szerintem ez olyan, ahova megy az új bátor világunk. Tehát, Eric. Most vissza akarok térni hozzád, és látni fogom, hogy van néhány kérdésünk itt, és azt szeretném, ha a résztvevőink továbbra is velünk maradnak, annak ellenére, hogy már elmúltunk egy órával.
Eric Kavanagh: Igen, vannak 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ódszer annak megfogalmazására, hogy mit csinálsz, és mennyire értékes, és hogy valójában hogyan kell a hibakeresőt használni egy rendszeresen, igaz? Fogadok, hogy néhány fej bólint, amikor kidobja, ugye?
Bert Scalzo: Abszolút, mert azt mondom nekik, hogy „Miért végezek helyesírás-ellenőrzést a dokumentumaimon? Nem akarom, hogy zavarodjanak 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: Jobb. Igen valóban. Nos, a nép egy órán át öt perc alatt megégett itt, annyira nagy köszönet mindannyiótoknak idejével és figyelmével. 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, ezért tegye ide ezt a listát.
És ezzel búcsúzni fognak neked, emberek. Ismét nagyszerű munkám, Bert, köszönhetően az IDERA barátainknak. Nos, beszélj veled legközelebb, jól beszélj veled a jövő héten, valójában. Vigyázz magadra! Viszlát.