Przez Techopedia Staff, 15 marca 2017 r
Na wynos: gospodarz Eric Kavanagh omówił debugowanie i profilowanie bazy danych z dr Robin Bloor, Dez Blanchfield i Bertem Scalzo z IDERA.
Obecnie nie jesteś zalogowany. Zaloguj się lub zarejestruj, aby zobaczyć wideo.
Eric Kavanagh: Dobra, panie i panowie, w środę jest godzina 4:00 czasu wschodniego i oczywiście to oznacza.
Robin Bloor: Nie słyszę cię, Eric.
Eric Kavanagh: Byłem tam kilka dni temu, więc nie jesteś sam. Ale dzisiejszy temat jest naprawdę interesujący. Jest to coś, co chcesz mieć pewność, że dzieje się w tle w Twojej firmie, chyba że jesteś osobą, która to robi, w takim przypadku chcesz upewnić się, że robisz to poprawnie. Ponieważ mówimy o debugowaniu. Nikt nie lubi błędów, nikt nie lubi, gdy oprogramowanie przestaje działać - ludzie się denerwują, użytkownicy stają się nieprzyjaźni. To nie jest dobrze. Porozmawiamy o „Rapid Response: Debugowanie bazy danych i profilowanie na ratunek”.
Naprawdę jest twoje miejsce, traf mnie na Twitterze, oczywiście @eric_kavanagh.
Ten rok jest gorący. Debugowanie będzie gorące, bez względu na wszystko. To naprawdę będzie jeden z tych problemów, który nigdy nie zniknie, bez względu na to, jak dobrze sobie z tym poradzimy, zawsze będą problemy, więc kluczem jest to, jak dotrzeć do miejsca, w którym można szybko rozwiązać te problemy? Idealnie jest, jeśli masz świetnych programistów, świetne środowiska, w których niewiele się dzieje, ale jak mówi stare powiedzenie: „Wypadki zdarzają się w najlepszych rodzinach”. To samo dotyczy organizacji. Tak więc, takie rzeczy się zdarzają, to się wydarzy, pytanie brzmi, jakie będzie twoje rozwiązanie, aby sobie z tym poradzić i rozwiązać te problemy?
Usłyszymy wiadomość od doktora Robina Bloora, a następnie naszego własnego Deza Blanchfielda z dołu i oczywiście naszego dobrego przyjaciela, Berta Scalzo, z firmy IDERA. I tak naprawdę oddam klucze Robin Bloor, zabierzę. Podłoga jest twoja.
Robin Bloor: OK. To ciekawy temat. Pomyślałem, ponieważ ponieważ Dez prawdopodobnie zamierza kontynuować aktualne techniki i historie wojenne dotyczące debugowania, pomyślałem, że po prostu przeprowadzę dyskusję w tle, aby uzyskać pełny obraz tego, co się dzieje. Robiłem to przez długi czas i kiedyś byłem programistą, więc to prawie tak, że niemal kusiło mnie to przedstawienie, by zacząć lirycznie wypowiadać się na temat open source, ale pomyślałem, że zostawię to komuś innemu.
Oto lista znanych błędów, a większość z nich trafia na najwyższą listę, w zasadzie wszystkie oprócz dwóch ostatnich kosztują co najmniej 100 milionów dolarów. Pierwszym z nich był Mars Climate Orbiter, zagubił się w przestrzeni kosmicznej i to z powodu problemu z kodowaniem, w którym ludzie mylili jednostki metryczne z (śmiech) stopami i calami. W Ariane Five Flight 501 wystąpiło niedopasowanie między uruchomionym silnikiem a komputerami, które miały uruchamiać rakietę po jej uruchomieniu. Wiele awarii komputera, wybuchająca rakieta, najważniejsze wiadomości. Radziecki gazociąg w 1982 roku, o którym mówi się, że jest największą eksplozją w historii planety; Nie jestem pewien, czy tak jest. Rosjanie ukradli oprogramowanie do automatycznej kontroli, a CIA zdało sobie sprawę, że zamierzają to zrobić i włożyło w to błędy, a Sowieci wdrożyli je bez testowania. Więc wysadziłem rurociąg, pomyślałem, że to zabawne.
Robak Morris był eksperymentem kodowania, który nagle stał się drapieżnym robakiem, który objął wszystkich - najwyraźniej spowodował szkody o wartości 100 milionów dolarów; to jest oczywiście szacunek. Intel popełnił słynny błąd z układem matematycznym - instrukcją matematyczną dotyczącą układu Pentium w 1993 roku - która miała kosztować ponad 100 milionów dolarów. Program Apple Maps to prawdopodobnie najgorsze i najbardziej katastrofalne uruchomienie wszystkiego, co Apple kiedykolwiek zrobił. Ludzie, którzy próbowali go użyć, to znaczy, że ktoś jechał wzdłuż 101, i odkryli, że Apple Map mówi, że są w środku Zatoki San Francisco. Ludzie zaczęli nazywać aplikację Apple Maps nazwą iLost. - Nasz najdłuższy przestój w 1990 roku - jest po prostu interesujący z punktu widzenia kosztu czegoś takiego - AT&T były dostępne przez około dziewięć godzin i kosztowały około 60 milionów dolarów za połączenia międzystrefowe.
Byłem w brytyjskiej firmie ubezpieczeniowej, a baza danych wdrożyła nową wersję bazy danych i zaczęła wymazywać dane. I pamiętam to bardzo dobrze, ponieważ zostałem później wezwany do wzięcia udziału w wyborze bazy danych z tego powodu. I to było bardzo interesujące, że wzięli nową wersję bazy danych i mieli szereg testów, które zrobili dla nowych wersji bazy danych, które przeszły wszystkie testy. Znalazł naprawdę niejasny sposób czyszczenia danych.
W każdym razie to tyle. Myślałem, że porozmawiam o niedopasowaniu impedancji i wydanym SQL. Interesujące jest to, że relacyjne bazy danych przechowują dane w tabelach, a kodery mają tendencję do manipulowania danymi w strukturach obiektowych, które tak naprawdę nie bardzo dobrze mapują na tabele. Z tego powodu dostajesz tak zwane niedopasowanie impedancji i ktoś musi sobie z tym poradzić w taki czy inny sposób. Ale to, co faktycznie się dzieje, ponieważ jeden model, model kodera i baza danych inny model, nie są specjalnie dostosowane. Dostajesz błędy, które po prostu by się nie zdarzyły, gdyby przemysł zbudował rzeczy, które działają razem, co moim zdaniem jest przezabawne. Zasadniczo, po stronie programistów, kiedy dostajesz hierarchie, mogą to być typy, zestawy wyników, może to być słaba zdolność API, może być wiele rzeczy, które po prostu wyrzucają rzeczy pod względem interakcji z bazą danych. Ale to, co dla mnie najbardziej, naprawdę interesujące; zawsze mnie dziwiło, że masz barierę SQL, która jest również impedancją w taki sposób, że kodery i baza danych współpracują ze sobą. Tak więc SQL ma rozpoznawanie danych, co jest w porządku i ma DML dla select, project i join, co jest w porządku. Dzięki temu możesz rzucić wiele możliwości w zakresie pobierania danych z bazy danych. Ale ma bardzo mało języka matematycznego do robienia rzeczy. Ma trochę tego i tamtego i ma bardzo mało rzeczy opartych na czasie. Z tego powodu SQL jest, jeśli chcesz, niedoskonałym sposobem na uzyskanie danych. Tak więc, faceci z bazy danych zbudowali procedury składowane, aby żyć w bazie danych, a powodem ich istnienia było to, że tak naprawdę nie chciałeś rzucać danymi tam iz powrotem do programu.
Ponieważ niektóre funkcje były wyjątkowo specyficzne dla danych, więc nie chodziło tylko o integralność referencyjną i usuwanie kaskadowe itp., Baza danych zajmowała się nagłym umieszczaniem funkcji w bazie danych, co oczywiście oznaczało, że funkcjonalność aplikacji można podzielić na koder i samą bazę danych. To sprawiło, że praca nad implementacją niektórych funkcji była naprawdę trudna, a zatem bardziej podatna na błędy. Tak, to jedna strona gry bazodanowej, ponieważ oznacza to, że masz wiele implementacji, na przykład, że byłem zaangażowany w relacyjne bazy danych, jest naprawdę okropnie dużo kodu, który jest obsługiwany w procedurach przechowywanych, które są obsługiwane niezależnie od kodu znajdującego się w aplikacjach. I wydaje się, że to bardzo dziwna rzecz. Musi być dość mądra w robieniu różnych rzeczy.
Pomyślałem, że porozmawiam również o wydajności bazy danych, ponieważ błędy wydajności są często uważane za błędy, ale w zasadzie możesz mieć wąskie gardło w procesorze, w pamięci, na dysku, w sieci i możesz mieć problemy z wydajnością z powodu blokowania . Pomysł polegałby na tym, że programista tak naprawdę nie musiał martwić się wydajnością, a baza danych faktycznie działała dość dobrze. Ma być zaprojektowany tak, aby programista nie musiał wiedzieć. Jednak dostajesz zły projekt bazy danych, dostajesz zły projekt programu, dostajesz współbieżność w mieszaniu obciążeń, co może również prowadzić do problemów z wydajnością. Dostajesz równoważenie obciążenia, dostajesz planowanie pojemności, wzrost danych - może to spowodować zatrzymanie lub spowolnienie bazy danych. To ciekawe, że kiedy bazy danych są prawie pełne, zwalniają. I możesz mieć problem z warstwami danych w zakresie replikacji i potrzeby replikacji oraz potrzeby tworzenia kopii zapasowych i odzyskiwania. W każdym razie to ogólny przegląd.
Jedyne, co chciałbym powiedzieć, to to, że debugowanie bazy danych może być tak samo uciążliwe i nietrywialne - i mówię to, ponieważ zrobiłem dużo tego - i często odkryjesz, że to jak wszystkie sytuacje podczas debugowania, które ja kiedykolwiek doświadczyłeś, to pierwsza rzecz, jaką zobaczysz, to bałagan. I musisz spróbować przejść od bałaganu do ustalenia, jak powstał bałagan. I często, gdy patrzysz na problem z bazą danych, patrzysz tylko na uszkodzone dane i myślisz: „Jak do cholery to się stało?”
W każdym razie przekażę Dezowi, który prawdopodobnie powie więcej mądrości niż się wydałem. Nie wiem, jak podać ci piłkę, Dez.
Eric Kavanagh: Przekażę, czekaj, poczekaj.
Zautomatyzowany głos: Wyciszone linie uczestników.
Eric Kavanagh: Dobra, poczekaj sekundę, pozwól mi dać piłkę Dezowi.
Dez Blanchfield: Dziękuję, Eric. Tak, doktorze Robin Bloor, naprawdę masz rację: to temat, dożywotni błąd, jeśli wybaczysz kalambura, przepraszam, że nie mogłem się powstrzymać. Mam nadzieję, że zobaczysz tam mój pierwszy ekran, przepraszam za problem z rozmiarem czcionki u góry. Tematem błędów jest wykład całodzienny, w wielu przypadkach z mojego doświadczenia. Jest to tak szeroki i szeroki temat, więc skupię się na dwóch kluczowych obszarach, a konkretnie na koncepcji tego, co uważamy za błąd, ale na problemie programistycznym. Myślę, że w dzisiejszych czasach wprowadzenie błędu jako takiego jest zazwyczaj wychwytywane przez zintegrowane środowiska programistyczne, chociaż mogą to być długotrwałe błędy. Ale często jest to bardziej przypadek profilowania kodu i można napisać kod, który działa, co powinno być błędem. Tak więc, mój slajd tytułowy, miałem kopię tego w bardzo wysokiej rozdzielczości A3, ale niestety został zniszczony w wyniku przeprowadzki. Ale jest to odręczna notatka na arkuszu programowania z około 1945 r., Gdzie podobno niektórzy ludzie z Harvard University w USA, ich druga wersja maszyny o nazwie Mark II. Debugowali jakiś problem we wspólnym języku, ale próbowali znaleźć usterkę i okazało się, że pojawiło się coś nieco innego niż sprzęt i rzekomo problem z oprogramowaniem.
Miejski mit głosi, że około 9 września 1945 r. Zespół z Uniwersytetu Harvarda rozbierał maszynę, natrafili na coś, co nazywali „przekaźnikiem siedemdziesiąt” - w tamtych czasach programowanie odbywało się w sensie fizycznym, zraniłeś kod wokół tablicy, i tak właśnie efektywnie zaprogramowałeś maszynę - i odkryli, że ten przekaźnik numer siedemdziesiąt był z nim coś nie tak, i okazuje się, że faktycznie pojawił się termin „błąd”, ponieważ dosłownie była ćma - podobno tam ćma była wciśnięta między kawałek drutu miedzianego przechodzącego z jednego miejsca do drugiego. I historia głosi, że legendarny Grace Hopper jako ten podpis, na slajd tytułowy, „pierwszy rzeczywisty przypadek znalezienia błędu” cytuje bez cytatu.
Ale jak Robin podkreślił wcześniej w swoim pierwszym slajdzie, koncepcja błędu sięga daleko wstecz, jak możemy sobie wyobrazić, że ludzie wykonują obliczenia, takie pojęcia jak łatka. Termin „łatka” pochodzi od faktycznego kawałka taśmy naklejonej na otwór na karcie dziurkacza. Ale w tym wszystkim chodzi o to, że termin „debugowanie” wywodzi się z koncepcji znalezienia błędu w maszynie fizycznej. I od tego czasu używamy tej terminologii, próbując rozwiązać problemy, albo nie tyle jak problemy z kodowaniem w programie, który się nie kompiluje, ale jako program, który nie działa dobrze. A konkretnie nie został profilowany, po prostu znajduj takie rzeczy, jak niekończące się pętle, które nigdzie nie idą.
Ale mamy też scenariusz i pomyślałem, że zamieściłem kilka zabawnych slajdów, zanim przedstawię nieco więcej szczegółów. Oto klasyczna kreskówka, zwana w sieci XKCD, a rysownik ma całkiem zabawne poglądy na świat. A ten opowiada o dziecku zwanym „Little Bobby Stoły” i podobno jego rodzice nazwali tego młodego chłopca Robertem ”); TABELA UPADKU Studenci; - i nazywa się: „Cześć, to szkoła twojego syna ma problemy z komputerem”, a rodzic odpowiada: „Och, kochanie, czy coś zepsuł?” A nauczyciel mówi: „Cóż, w pewnym sensie ”, a nauczyciel pyta:„ czy naprawdę nazywałeś swojego syna Roberta ”); DROP TABLE Studenci; -? ”A rodzic mówi:„ Och tak, nazywamy go małymi stolikami Bobby'ego ”. W każdym razie dalej mówią, że stracili zapisy uczniów z roku, mam nadzieję, że jesteś szczęśliwy. A odpowiedź brzmi: „Cóż, powinieneś wyczyścić i zdezynfekować dane wejściowe do bazy danych”. I używam tego wiele razy, aby porozmawiać o niektórych problemach ze znalezieniem rzeczy w kodzie, że często kod nie patrzy na dane także.
Kolejny zabawny, nie wiem, czy to prawda, czy nie - podejrzewam, że to podróbka - ale znów dotyka mojej śmiesznej kości. Ktoś zmienia tablicę rejestracyjną z przodu samochodu, na podobne stwierdzenie, które powoduje, że bazy danych upuszczają fotoradary i tak dalej, przechwytują tablice rejestracyjne samochodów. I zawsze nazywam to tym, że wątpię, aby jakikolwiek programista oczekiwał trafienia i uruchomienia ich kodu przez rzeczywisty pojazd silnikowy, ale nigdy nie lekceważy tego - moc gniewnego maniaka.
(Śmiech)
Ale to prowadzi mnie do mojego kluczowego punktu, i myślę, że dawno temu moglibyśmy debugować i profilować kod jako zwykli śmiertelnicy. Ale bardzo uważam, że ten czas minął, i z mojego doświadczenia, anegdotycznie, po raz pierwszy - i to mnie strasznie zestarzeje, jestem pewien; Robin, możesz naśmiewać się z tego za mnie - ale historycznie pochodzę z 14-latka, który wędruje na końcu miasta i puka do drzwi centrum danych o nazwie „Data Com” w Nowym Zelandia i pytanie, czy mógłbym zarobić kieszonkowe w szkole, jadąc do domu spóźnionym autobusem, około 25 km codziennych dojazdów, wkładając papier do drukarek i taśm do napędów taśmowych, i po prostu będąc ogólnym administratorem. I co ciekawe, dali mi pracę. Ale z czasem udało mi się dostać do personelu i znaleźć programistów i zdałem sobie sprawę, że uwielbiam kodować i przeszedłem proces uruchamiania skryptów i zadań wsadowych, które na koniec są kodami. Musisz pisać skrypty i zadania wsadowe, które wyglądają jak miniprogramy, a następnie przejść przez cały proces ręcznego pisania kodu na terminalu 3270.
W rzeczywistości moje pierwsze doświadczenie dotyczyło terminalu teletypowego, który w rzeczywistości był 132-kolumnową drukarką fizyczną. Zasadniczo pomyśl o bardzo starej maszynie do pisania z przewijanym przez nią papierem, ponieważ nie mieli rurki CRT. Debugowanie kodu na ten temat było bardzo nietrywialne, więc zwykle pisałeś cały swój kod ręcznie, a następnie działałeś jak maszynistka, starając się nie dopuścić do błędów, aby się do niego wślizgnąć, ponieważ bardzo frustrujące jest to, że musisz powiedzieć edytor jednowierszowy, który przechodzi do pewnej linii, a następnie drukuje linię, a następnie wpisuje ją z powrotem. Ale kiedyś tak pisaliśmy kod i tak debugowaliśmy i byliśmy w tym bardzo, bardzo dobrzy. W rzeczywistości zmusiło nas to do posiadania bardzo dobrych technik programowania, ponieważ naprawienie go było naprawdę trudne. Ale podróż przeszła - i wszyscy to znamy - przeszła od doświadczenia terminalu 3270 w moim świecie do Digital Equipment VT220, gdzie można było zobaczyć rzeczy na ekranie, ale znowu robiliście to samo zrobiłeś na papierze w formie drukowanego formatu tylko na CRT, ale byłeś w stanie usunąć go łatwiej i nie miałeś tego dźwięku „dit dit dit dit”.
A potem wiesz, terminale Wyse - jak Wyse 150, prawdopodobnie mój ulubiony interfejs do komputera - i potem PC, a potem Mac, a teraz nowoczesne GUI i identyfikatory oparte na sieci. Oraz szereg programów dzięki temu, programowanie w jednym i asemblerze oraz PILOT i Logo i Lisp i Fortran i Pascal oraz języki, które mogą wywoływać u ludzi dreszcze. Ale są to języki, które zmusiły cię do napisania dobrego kodu; nie pozwoliły ci uniknąć złych praktyk. C, C ++, Java, Ruby, Python - i przechodzimy dalej na tym etapie programowania, stajemy się bardziej podobni do skryptów, zbliżamy się coraz bardziej do Structured Query Language i języków takich jak PHP, które są faktycznie używane do wywoływania SQL. Chodzi mi o to, że pochodząc z mojego pochodzenia, byłem samoukiem na wiele sposobów, a te, które pomogły mi w nauce, nauczyły mnie bardzo dobrych praktyk programowania i bardzo dobrych praktyk w zakresie projektowania i procesów, aby upewnić się, że nie wprowadzić błędny kod.
Metody programowania w dzisiejszych czasach, takie jak na przykład Structured Query Language, SQL, to bardzo wydajny, prosty język zapytań. Ale przekształciliśmy go w język programowania i nie sądzę, aby SQL był kiedykolwiek zaprojektowany jako nowoczesny język programowania, ale zmieniliśmy go, aby tak się stało. I to wprowadza całą masę problemów, ponieważ kiedy myślimy o nich z dwóch punktów widzenia: z punktu widzenia kodowania i z punktu widzenia DBA. Bardzo łatwo jest wprowadzić i wprowadzić błędy dotyczące takich rzeczy, jak słabe techniki programowania, leniwe wysiłki w pisaniu kodu, brak doświadczenia, klasyczne wkurzanie, które mam na przykład, gdy ludzie SQL skaczą po Google i szukają czegoś i znajdują stronę, która dostałem przykład i robię kopię i wklejanie istniejącego kodu. A następnie powielanie złego kodowania, nadużyć i wprowadzanie go do produkcji, ponieważ po prostu daje im oczekiwane rezultaty. Masz inne wyzwania, na przykład w dzisiejszych czasach wszyscy spieszymy ku temu, co nazywamy wyścigem do zera: staramy się robić wszystko tak tanio i tak szybko, że mamy scenariusz, w którym nie zatrudniamy mniej opłacany personel. Nie mam na myśli tego w nieuczciwy sposób, ale nie zatrudniamy ekspertów do każdej możliwej pracy. Dawno, dawno temu coś związanego z komputerami było nauką o rakietach; był zaangażowany w rzeczy, które wybuchły i były bardzo głośne, lub w kosmos, albo inżynierowie byli wysoko wykwalifikowanymi mężczyznami i kobietami, którzy zdobyli stopnie naukowe i posiadali rygorystyczne wykształcenie, które powstrzymywało ich od robienia szalonych rzeczy.
W dzisiejszych czasach jest wielu ludzi zajmujących się programowaniem i projektowaniem oraz bazami danych, którzy nie mieli lat doświadczenia, niekoniecznie mieli takie samo szkolenie lub wsparcie. I tak kończysz się scenariuszem tradycyjnego amatora kontra eksperta. I jest taka słynna linia, nie pamiętam, kto stworzył wycenę, brzmi następująco: „Jeśli uważasz, że zatrudnienie eksperta do wykonania pracy jest drogie, poczekaj, aż zatrudnisz kilku amatorów, którzy tworzą problem, a ty trzeba to wyczyścić. ”Tak więc SQL ma ten problem i jest bardzo, bardzo łatwy do nauczenia, bardzo łatwy w użyciu. Moim zdaniem nie jest to jednak idealny język programowania. Bardzo łatwo jest robić rzeczy takie jak zrobić wybraną gwiazdę z dowolnego miejsca i wciągnąć to wszystko w język programowania, w którym czujesz się swobodniej, np. PHP, Ruby lub Python, i używać języka programowania, który znasz natywnie manipulowanie danymi zamiast wykonywania bardziej złożonych zapytań w SQL. I często to widzimy, a potem ludzie zastanawiają się, dlaczego baza danych działa wolno; dzieje się tak dlatego, że milion ludzi próbuje kupić bilet w internetowym systemie biletowym, w którym wybiera wybraną gwiazdę z dowolnego miejsca.
To naprawdę ekstremalny przykład, ale rozumiesz o tym wszystkim. Tak więc, aby naprawdę uderzyć ten punkt do domu, oto przykład, który dużo noszę. Jestem wielkim fanem matematyki, uwielbiam teorię chaosu, uwielbiam zestawy Mandelbrota. Po prawej stronie znajduje się wersja zestawu Mandelbrot, którą z pewnością wszyscy znamy. A po lewej stronie jest kawałek SQL, który to renderuje. Teraz, za każdym razem, gdy gdzieś umieszczam to na ekranie, słyszę: „O mój boże, ktoś wyrenderował serię Mandelbrot za pomocą SQL, mówisz poważnie? To szalone! ”Cóż, chodzi o to, aby zilustrować to, co właśnie tam nakreśliłem, i tak, w rzeczywistości możesz teraz programować prawie wszystko w SQL; jest to bardzo mocno rozwinięty, mocny, nowoczesny język programowania. Kiedyś był to język zapytań, był zaprojektowany tak, aby po prostu uzyskać dane. Więc teraz mamy bardzo złożone konstrukcje i procedury składowane, mamy metodologię programowania stosowaną do języka, więc jest to bardzo łatwe ze względu na słabą praktykę programowania, brak doświadczenia, wycinanie i wklejanie kodu, nisko opłacani pracownicy próbujący być wysoko opłacanymi pracownikami, ludzie udający, że wiedzą, ale muszą się uczyć w pracy.
Cały szereg rzeczy, w których profilowanie kodu i to, co nazywamy debugowaniem, to nie tyle znajdowanie błędów, które zatrzymują programy, ale błędy, które po prostu szkodzą systemowi i źle skonstruowanemu kodowi. Kiedy teraz patrzysz na ten ekran i myślisz, że to po prostu urocze i myślisz: „Wow, co za świetna grafika, chciałbym to uruchomić”. Ale wyobraź sobie, że działa na jakiejś logice biznesowej . Wygląda to całkiem schludnie, ale mówi matematyczną teorię chaosu, ale jeśli pomyślisz o tym, do czego może być potencjalnie wykorzystana w jakiejś logice biznesowej, możesz uzyskać obraz bardzo szybko. Aby naprawdę to zilustrować - przepraszam, że kolory są odwrócone, powinno to być czarne tło i zielony tekst, który ma być zielonym ekranem, ale nadal możesz to przeczytać.
Poszedłem i rzuciłem okiem na przykład tego, co możesz potencjalnie zrobić, jeśli byłbyś naprawdę szalony i nie miałeś żadnego doświadczenia, pochodziłem z innego środowiska programowania i zastosowałem C ++ do SQL, aby naprawdę zilustrować mój punkt widzenia, zanim Przekazuję naszemu uczonemu gościowi z IDERA. Jest to zapytanie strukturalne napisane jak C ++, ale zakodowane w SQL. I faktycznie działa, ale działa przez około trzy do pięciu minut. I wycofuje pozornie jedną linię danych z wielu baz danych, wiele połączeń.
Ponownie chodzi o to, że jeśli nie masz odpowiednich narzędzi, jeśli nie masz odpowiednich platform i środowisk, aby móc złapać te rzeczy, a one wchodzą do produkcji, a następnie masz 100 000 osób uderzając w system każdego dnia, godziny lub minuty, bardzo szybko kończy się doświadczenie w Czarnobylu, w którym wielkie żelazo zaczyna się topić i zakopywać w rdzeniu planety, ponieważ ten fragment kodu nigdy nie powinien zostać wprowadzony do produkcji. Wasze systemy i narzędzia, przepraszam, powinny to odebrać, zanim dotrze gdziekolwiek w pobliżu - nawet podczas procesu testowego, nawet przez UAT i integrację systemów, ten fragment kodu powinien zostać pobrany i wyróżniony, a ktoś powinien zostać odłożony na bok i mówiąc: „Spójrz, to naprawdę ładny kod, ale zdobądźmy DBA, które pomoże ci poprawnie zbudować to ustrukturyzowane zapytanie, bo szczerze mówiąc, to po prostu paskudne.” I tam jest adres URL, możesz przejść i rzucić okiem - to się nazywa najbardziej złożone zapytanie SQL, jakie kiedykolwiek napisałeś. Bo uwierz mi, to się kompiluje, działa. A jeśli wycinasz i wklejasz i po prostu próbujesz stworzyć bazę danych, jest to coś do oglądania; jeśli masz narzędzia do oglądania bazy danych, po prostu spróbuj stopić się w ciągu trzech do pięciu minut, aby oddzwonić, co jest jednym wierszem tekstu.
Podsumowując, mając to na uwadze, całe moje doświadczenie w kodowaniu nauczyło mnie, że możesz dawać ludziom broń, a jeśli nie będą ostrożni, strzelą sobie w stopę; sztuką jest pokazanie im, gdzie jest mechanizm bezpieczeństwa. Dzięki odpowiednim narzędziom i oprogramowaniu na wyciągnięcie ręki, po zakończeniu kodowania możesz przejrzeć swój kod, możesz znaleźć problemy poprzez profilowanie kodu, możesz znaleźć skutecznie niezamierzone błędy, które są problemami z wydajnością, i jak powiedziałem wcześniej, dawno temu, można było to zrobić, patrząc na zielony ekran. Nie możesz już więcej; istnieją setki tysięcy linii kodu, dziesiątki tysięcy aplikacji, w niektórych przypadkach istnieją miliony baz danych, a nawet super ludzie nie mogą tego robić ręcznie. Potrzebujesz dosłownie odpowiedniego oprogramowania i odpowiednich narzędzi na wyciągnięcie ręki, a zespół potrzebuje tych narzędzi, abyś mógł znaleźć te problemy i rozwiązać je bardzo szybko, zanim dojdziesz do sedna sprawy, podczas gdy Dr. Robin Bloor podkreślił, że rzeczy stają się katastrofalne, a rzeczy wysadzają się w powietrze, lub częściej, po prostu zaczynają cię kosztować dużo dolarów i dużo czasu i wysiłku oraz niszczą morale i inne rzeczy, gdy nie mogą zrozumieć, dlaczego rzeczy biorą długi czas na ucieczkę.
Mając to na uwadze, przekażę naszemu gościowi i czekam na wiadomość, jak rozwiązali ten problem. Zwłaszcza demo, które myślę, że niedługo otrzymamy. Eric, oddam ci z powrotem.
Eric Kavanagh: OK, Bert, zabierz to.
Bert Scalzo: OK, dziękuję. Bert Scalzo tutaj z IDERA, jestem menedżerem produktu dla naszych narzędzi baz danych. I zamierzam mówić o debugowaniu. Myślę, że jedną z najważniejszych rzeczy, które Robin powiedział wcześniej - i jest to bardzo prawdziwe, że debugowanie jest uciążliwe i nietrywialne, a kiedy przechodzisz do debugowania bazy danych, jest to rząd wielkości jeszcze bardziej uciążliwy i nietrywialny - więc że był ważnym cytatem.
DOBRZE. Chciałem zacząć od historii programowania, ponieważ wiele razy widzę ludzi, którzy nie debugują, nie używają debugera, po prostu programują w jakimkolwiek języku, którego używają i wiele razy mówią mi „Cóż, te debuggery są nowe i jeszcze nie zaczęliśmy ich używać”. I dlatego pokazuję im ten wykres na osi czasu, coś w rodzaju prehistorii, starości, średniowiecza, to miłe powiedzmy, gdzie byliśmy pod względem języków programowania. W 1951 roku mieliśmy bardzo stare języki z kodem asemblera oraz Lisp, FACT i COBOL. Następnie wchodzimy do następnej grupy, Pascals i Cs, a następnie do następnej grupy, C ++, i patrzymy, gdzie jest ten znak zapytania - ten znak zapytania jest w przybliżeniu około 1978 do może 1980 roku. Gdzieś w tym przedziale mieliśmy dostępne dla nas debuggery, i tak powiem: „Hej, nie używam debuggera, bo to jedna z tych nowych rzeczy”, to musiałeś zacząć programować, wiesz, w latach 50., bo to jest jedynym sposobem na uniknięcie tego roszczenia.
Kolejną zabawną rzeczą w tym wykresie jest to, że Dez skomentował Grace Hopper. Właściwie to znałem Grace, więc to trochę zabawne. A potem jeszcze jedna rzecz, z której się śmiałem, to to, że mówił o teletypach i siedzę tam, mówiąc: „Człowieku, to był największy skok, jaki kiedykolwiek mieliśmy pod względem produktywności, kiedy przechodziliśmy od kart do teletypów, był to największy skok w historii. „Tak więc, i programowałem we wszystkich językach tutaj, w tym w SNOBOL, o których nikt wcześniej nie słyszał, była to CDC, Control Data Corporation, więc chyba staję się trochę za stary dla tej branży .
Dez Blanchfield: Chciałem powiedzieć, że strasznie nas tam postarzeliście.
Bert Scalzo: Tak, mówię ci, czuję się jak dziadek Simpson. Więc patrzę na debugowanie i są różne sposoby debugowania. Możesz mówić o tym, co wszyscy uważamy za tradycyjne wchodzenie w debugger i przechodzenie przez kod. Ale także ludzie będą instrumentować swój kod; tam umieszczasz instrukcje w swoim kodzie, a może tworzysz plik wyjściowy, plik śledzenia lub coś takiego, więc instrumentujesz swój kod. Liczę to jako debugowanie, jest to trochę trudniejsze, sposób na zrobienie tego, ale to się liczy. Ale mamy też słynne polecenie drukowania: oglądasz, a ludzie faktycznie umieszczają instrukcje drukowania i faktycznie widziałem narzędzie, w którym - i jest to narzędzie bazy danych - gdzie, jeśli nie wiesz, jak korzystać z debuggera, naciskasz przycisk, a on umieszcza dla ciebie instrukcje drukowania w całym kodzie, a następnie, gdy skończysz, naciskasz inny przycisk i usuwa je. Ponieważ tak debuguje wiele osób.
Powód, dla którego debugujemy, jest dwojaki: po pierwsze musimy znaleźć rzeczy, które powodują, że nasz kod jest nieskuteczny. Innymi słowy, zazwyczaj oznacza to błąd logiczny lub nie spełniliśmy wymagań biznesowych, ale kod jest nieskuteczny; nie robi tego, czego się spodziewaliśmy. Innym razem, gdy idziemy i debugujemy, chodzi o wydajność i może to być logiczny błąd, ale to, co zrobiłem, to, że zrobiłem właściwą rzecz, po prostu nie wraca wystarczająco szybko. Teraz robię to, ponieważ profiler prawdopodobnie lepiej nadaje się do tego drugiego scenariusza, a my porozmawiamy zarówno o debuggerach, jak i profilerach. Ponadto istnieje koncepcja zdalnego debugowania; jest to ważne, ponieważ wiele razy, jeśli siedzisz na komputerze osobistym i używasz debugera, który trafia do bazy danych, w której kod jest faktycznie wykonywany w bazie danych, faktycznie robisz tak zwane zdalne debugowanie. Możesz nie zdawać sobie z tego sprawy, ale tak się dzieje. A potem bardzo często zdarza się, że te debuggery mają punkty przerwania, punkty obserwacyjne, wkraczają i przechodzą oraz kilka innych wspólnych rzeczy, które za chwilę pokażę na migawce ekranu.
Teraz profilowanie: możesz wykonywać profilowanie na kilka różnych sposobów. Niektórzy powiedzą, że przechwytywanie i odtwarzanie obciążenia odbywa się tam, gdzie przechwytuje wszystko, co liczy się jako profilowanie. Moje doświadczenie było tym większe, że lepiej, jeśli wykonano próbkowanie. Nie ma powodu, aby łapać każdą pojedynczą instrukcję, ponieważ niektóre instrukcje mogą po prostu działać tak szybko, że nie obchodzi cię to, co naprawdę chcesz zobaczyć, to są te, które ciągle się pojawiają, ponieważ biegną za długo. Tak więc czasami profilowanie może oznaczać próbkowanie, a nie uruchamianie całości. I zazwyczaj otrzymasz jakiś wynik, którego możesz użyć, teraz, który może być wizualny w środowisku programistycznym IDE, gdzie może dać ci histogram wydajności różnych linii kodu, ale może również nadal ponieważ tworzy plik śledzenia.
Profile pojawiły się po raz pierwszy w 1979 roku. Te też istnieją już od dawna. Idealne do znajdowania zużycia zasobów lub problemów z wydajnością, innymi słowy, że wydajność. Ogólnie rzecz biorąc, jest on odrębny i odmienny od debuggera, chociaż pracowałem z debuggerami, które robią oba jednocześnie. I chociaż uważam, że profilery są bardziej interesujące z tych dwóch narzędzi, jeśli uważam, że za mało ludzi debuguje, to zdecydowanie za mało ludzi profiluje, ponieważ jeden na dziesięciu debugerów będzie się profilował. A szkoda, bo profilowanie może naprawdę zrobić ogromną różnicę. Teraz języki baz danych, o których mówiliśmy wcześniej, masz SQL - i w pewnym sensie zmusiliśmy okrągły kołek do kwadratowej dziury tutaj i zmusiliśmy go, aby stał się językiem programowania - i Oracle. To PL / SQL - to język proceduralny SQL - i SQL Server, to Transact-SQL, to SQL-99, to SQL / PSM - dla, jak sądzę, to moduł przechowywany w procedurze. Postgres nadaje mu inną nazwę, DB2 jeszcze inną nazwę, Informix, ale chodzi o to, że wszyscy wymusili konstrukcje typu 3GL; innymi słowy, pętle FOR, deklaracje zmiennych i wszystkie inne elementy obce SQL są teraz częścią SQL w tych językach. Tak więc musisz mieć możliwość debugowania PL / SQL lub Transact-SQL, podobnie jak program Visual Basic.
Otóż, obiekty bazy danych, jest to ważne, ponieważ ludzie powiedzą: „Cóż, jakie rzeczy muszę debugować w bazie danych?”. A odpowiedź brzmi: cóż, cokolwiek możesz przechowywać w bazie danych jako kod - jeśli to robię T-SQL lub PL / SQL - i przechowuję obiekty w bazie danych, prawdopodobnie jest to procedura składowana lub funkcja składowana. Ale są też wyzwalacze: wyzwalacz jest czymś w rodzaju procedury składowanej, ale uruchamia się przy jakimś zdarzeniu. Teraz niektórzy ludzie w swoich wyzwalaczach wstawią jeden wiersz kodu i wywołają procedurę przechowywaną, aby zachować cały przechowywany kod i procedury, ale jest to ta sama koncepcja: to wciąż wyzwalacz może być tym, co inicjuje całość. A potem jako Oracle mają coś, co nazywa się pakietem, co jest jakby biblioteką, jeśli wolisz. Umieszczasz 50 lub 100 procedur przechowywanych w jednej grupie, zwanej pakietem, więc jest to trochę jak biblioteka. Oto debugger po staremu; w rzeczywistości jest to narzędzie, które faktycznie wklei wszystkie te instrukcje debugowania w kodzie. Tak więc, wszędzie tam, gdzie widzisz blok debugowania, nie usuwaj, uruchamianie i śledzenie automatycznego debuggera, wszystkie one utknęły w jakimś narzędziu. A poza tym wiersze, które stanowią mniejszość kodu, to nie jest ręczna metoda debugowania.
Powodem, dla którego to poruszam, jest to, że jeśli próbujesz to zrobić ręcznie, w rzeczywistości będziesz pisać więcej kodu debugującego, aby wstawić wszystkie te instrukcje print niż z kodem. Chociaż może to działać i jest lepsze niż nic, jest to bardzo trudny sposób na debugowanie, zwłaszcza, że jeśli zajmie to 10 godzin, aby uruchomić tę rzecz, a gdzie występuje problem, jest w trzeciej linii? Gdybym robił interaktywną sesję debugowania, wiedziałbym na linii trzeciej - pięć minut - hej, tu jest problem, mogę wyjść. Ale z tym muszę poczekać, aż się uruchomi, aż do zakończenia, a następnie muszę spojrzeć na jakiś plik śledzenia, który prawdopodobnie zawiera wszystkie te instrukcje drukowania, i spróbować znaleźć igłę w stóg siana. Znowu jest to lepsze niż nic, ale nie byłby to najlepszy sposób pracy. Tak właśnie wyglądałby ten plik, który pochodzi z poprzedniego slajdu; innymi słowy, uruchomiłem program, a on ma po prostu kilka instrukcji drukowania w tym pliku śledzenia i mogę, ale nie muszę, przesączyć przez to i znaleźć to, co muszę znaleźć. Ponownie nie jestem pewien, czy w taki sposób chciałbyś pracować.
Teraz interaktywne debugery - a jeśli używasz czegoś takiego jak Visual Studio do pisania programów lub Eclipse, masz debugery i korzystałeś z nich w innych językach - po prostu nie pomyślałem, aby użyć ich tutaj w bazie danych. Istnieją narzędzia, takie jak nasz DB Artisan i nasz Rapid SQL, tutaj jest Rapid SQL, które mają debugger, a po lewej stronie widać procedurę składowaną o nazwie „sprawdź duplikaty”. Zasadniczo, po prostu przejdę i zobaczę, czy mam wiele wierszy w tabeli o tym samym tytule filmowym. Baza danych dotyczy filmów. I widać po prawej stronie, w górnej trzeciej, mam kod źródłowy w środku, mam tak zwane moje zmienne zegarka i tacki stosu wywołań, a następnie u dołu: dostałem kilka komunikatów wyjściowych. I ważne jest to, że jeśli spojrzysz na pierwszą czerwoną strzałkę, jeśli przesuń kursor myszy nad zmienną, tak naprawdę widzę, jaka jest wartość tej zmiennej w danym momencie, gdy przeglądam kod. I to jest naprawdę przydatne, a następnie mogę krok po kroku przejść przez kod, nie muszę mówić o wykonaniu, mógłbym powiedzieć krok po kroku, pozwól mi spojrzeć, co się stało, krok po kroku, pozwól mi zobaczyć, co się stało i robię to w bazie danych. I mimo że siedzę na Rapid SQL na moim komputerze, a moja baza danych jest w chmurze, nadal mogę zdalnie debugować i widzieć go i kontrolować z tego miejsca, a także debugować tak, jak w innym języku.
Teraz następna strzałka tam - możesz zobaczyć małą strzałkę skierowaną w prawo, w stronę wyjścia DBMS, tam właśnie znajduje się mój kursor - innymi słowy, zrobiłem krok i tam jestem chwila. Więc jeśli powiem: „Zrób krok ponownie”, przejdę do następnej linii. Teraz tuż poniżej zobaczysz czerwoną kropkę. Cóż, to jest punkt przerwania, który mówi: „Hej, nie chcę przekraczać tych linii”. Jeśli chcę po prostu przeskoczyć wszystko i dojść do miejsca, w którym czerwona kropka, mogę nacisnąć przycisk biegu, a on uruchomi się od tego momentu do końca lub do punktu przerwania, jeśli są ustawione jakieś punkty przerwania, a następnie zatrzyma się i pozwoli mi powtórzyć krok. Powodem tego jest to, że wszystko to jest ważne i potężne, ponieważ kiedy to wszystko robię, to, co dzieje się na środku, a nawet na dole - ale co najważniejsze w środku - zmienia się i widzę wartości z moich zmiennych, Widzę, że mój stos wywołań jest śledzony, więc wszystkie te informacje są tam wyświetlane, gdy przechodzę przez kod, dzięki czemu naprawdę widzę, czuję i rozumiem, co się dzieje i jak właściwie jest kod praca w czasie wykonania. I zazwyczaj mogę znaleźć problem, jeśli taki istnieje, lub jeśli jestem wystarczająco dobry, aby go złapać.
OK, teraz zamierzam porozmawiać o profilerze, w tym przypadku jest to profiler, który widzę przez debugger. Pamiętasz, jak mówiłem, że czasami są oddzielni, a czasem mogą być razem? W tym przypadku i znowu jestem w Rapid SQL i widzę margines, po lewej stronie, obok numerów linii. A to oznacza, że jest to liczba sekund lub mikrosekund potrzebnych do wykonania każdej linii kodu, i widzę to wyraźnie, cały mój czas spędzam w tej jednej pętli FOR, w której wybieram wszystko z tabeli . A zatem to, co dzieje się wewnątrz tej pętli FOR, jest prawdopodobnie czymś, na co muszę spojrzeć, a jeśli uda mi się to poprawić, przyniesie to dywidendy. Nie zamierzam wprowadzać żadnych ulepszeń, pracując na liniach, które mają 0, 90 lub 0, 86; nie spędza się tam dużo czasu. Teraz, w tym przypadku, i znowu, jestem w Rapid SQL, widzisz, jak mogę profilować zmieszane z moim debugowaniem. Teraz fajne jest to, że Rapid SQL pozwala ci to zrobić w drugą stronę. Rapid SQL pozwala powiedzieć: „Wiesz co? Nie chcę być w debugerze, chcę to uruchomić, a następnie chcę spojrzeć na graficznie lub wizualnie ten sam typ informacji. ”
I widać, że nie jestem już w debuggerze i uruchamia on program, a po zakończeniu wykonywania daje mi wykresy, aby powiedzieć mi różne rzeczy, dzięki czemu mogę zobaczyć, że mam jedno zdanie, które wygląda na zajęcie większość wykresu kołowego, a jeśli spojrzę, widzę na tej siatce w dół, wiersz 23, znowu jest pętla FOR: zajmuje najwięcej czasu, w rzeczywistości jest ciemnoczerwony, żując wszystkie wykresy kołowe. To kolejny sposób na profilowanie. W naszym narzędziu nazywamy tego „Code Analyst”. Ale to po prostu profiler oddzielony od debuggera. Niektórzy ludzie lubią to robić w pierwszy sposób, inni lubią to w drugi sposób.
Dlaczego debugujemy i profilujemy? Nie dlatego, że chcemy napisać najlepszy kod na świecie i uzyskać podwyżkę - może to być nasz powód, ale to nie jest tak naprawdę powód, dla którego to robisz - obiecałeś firmie, że zrobisz coś poprawnie, że Twój program będzie skuteczny. Do tego użyjesz debugera. Ponadto biznesowi użytkownicy końcowi; nie są zbyt cierpliwi: chcą wyników nawet przed naciśnięciem klawisza. Mamy czytać w ich myślach i robić wszystko natychmiast. Innymi słowy, musi być wydajny. I do tego właśnie użylibyśmy profilera. Teraz bez tych narzędzi naprawdę wierzę, że jesteś tym facetem w garniturze z łukiem i strzałą, strzelasz do celu i masz zasłonięte oczy. Ponieważ jak dowiesz się, jak program działa, patrząc tylko na kod statyczny i jak dowiedzieć się, w którym wierszu tak naprawdę spędziłby najwięcej czasu, ponownie, patrząc tylko na kod statyczny? Recenzja kodu może ujawnić niektóre z tych rzeczy, ale nie ma gwarancji, że przegląd kodu znajdzie je wszystkie. Za pomocą debugera i profilera powinieneś być w stanie znaleźć wszystkie te błędy.
OK, zrobię tutaj naprawdę szybkie demo. Nie mam zamiaru pchać produktu, chcę tylko pokazać, jak wygląda debugger, ponieważ wiele razy ludzie mówią: „Nigdy wcześniej nie widziałem żadnego z nich”. I wygląda ładnie na zrzutach ekranowych, ale jak to wygląda, gdy jest w ruchu? Tak więc tutaj na moim ekranie korzystam z produktu DB Artisan; mamy tam również debugger. DB Artisan przeznaczony jest bardziej dla DBA, Rapid SQL jest bardziej dla programistów, ale widziałem programistów, którzy używają DB Artisan i widziałem DBA, którzy używają Rapid. Więc nie daj się złapać na produkcie. I tutaj mam wybór do przeprowadzenia debugowania, ale zanim uruchomię debugowanie, wyodrębnię ten kod, abyś mógł zobaczyć, jak wygląda kod, zanim zacznę go uruchamiać. Oto dokładnie ten sam kod, który znajdował się w migawce ekranu, oto moje sprawdzenie duplikatów. Chcę to debugować, więc naciskam debugowanie. A teraz zajmuje to chwilę i mówisz: „Cóż, dlaczego zajmuje to chwilę?”. Pamiętasz zdalne debugowanie: debugowanie odbywa się na moim serwerze bazy danych, a nie na komputerze. Musiał więc przejść i stworzyć tam sesję, stworzyć zdalne debugowanie, podłączyć moją sesję do tej zdalnej sesji debugowania i skonfigurować kanał komunikacyjny.
A więc, oto moja strzałka, jest tam na górze, w pierwszej linii, tam właśnie jestem w kodzie. A jeśli nacisnę tam trzecią ikonę, która jest krokiem do przodu, zobaczysz, że strzała właśnie się poruszyła, a jeśli będę ją nadal naciskać, zobaczysz, że się porusza. Teraz, gdybym chciał przejść do tej pętli FOR, ponieważ wiem, że na tym polega problem, mogę ustawić punkt przerwania. Myślałem, że to ustawiłem. Och, strzel, miałem jeden z moich klawiszy przechwytywania ekranu zmapowany na ten sam klucz co debugger, to powoduje zamieszanie. OK, więc po prostu ręcznie ustawiłem tam punkt przerwania, więc teraz zamiast robić krok, krok, krok, krok, aż do niego dojdę, właściwie mogę po prostu powiedzieć: „Idź naprzód i uruchom tę rzecz”, a ona się zatrzyma. Zauważ, że przesunęło mnie to do miejsca, w którym znajduje się punkt przerwania, więc jestem teraz w kontekście uruchamiania tej pętli, widzę, do czego są ustawione wszystkie moje zmienne, co nie jest zaskoczeniem, ponieważ zainicjowałem je wszystkie do zera. A teraz mogę wejść w tę pętlę i zacząć patrzeć na to, co dzieje się w tej pętli.
Tak więc teraz zrobi wybrane obliczenie z moich wypożyczeń i mogę najechać myszką na tego faceta i spojrzeć, on ma dwa, dwa to więcej niż jeden, więc prawdopodobnie zrobi następny fragment tego kodu. Innymi słowy, znalazł coś. Po prostu zamierzam iść naprzód i pozwolić temu biegać. Nie chcę tutaj wszystkiego przechodzić; to, co chcę ci pokazać, to kiedy debugger jest gotowy, kończy się tak jak normalny program. Mam ustawiony punkt przerwania, więc kiedy powiedziałem „bieg”, po prostu wróciłem do następnego punktu przerwania. Zezwalam, aby działał do końca, bo chcę, abyś zobaczył, że debuger nie zmienia zachowania programu: po zakończeniu pracy powinienem uzyskać dokładnie takie same wyniki, jeśli nie uruchomiłem wewnątrz debuggera.
I z tym zamierzam zawiesić wersję demo i wrócić, ponieważ chcemy się upewnić, że mamy czas na pytania i odpowiedzi. I tak otworzę go na pytania i odpowiedzi.
Eric Kavanagh: Dobra, Robin, może pytanie od ciebie, a potem kilka od Deza?
Robin Bloor: Tak, oczywiście, uważam to za fascynujące. Pracowałem z takimi rzeczami, ale nigdy nie pracowałem z czymś takim w bazie danych. Czy możesz mi powiedzieć, do czego ludzie używają profilera? Ponieważ wygląda na to, czy patrzą - bo zakładam, że tak - patrzą na problemy z wydajnością, czy pomoże ci to odróżnić, kiedy baza danych zajmuje czas, a kiedy kod zajmuje czas?
Bert Scalzo: Wiesz, to fantastyczne pytanie. Powiedzmy, że pracuję w języku Visual Basic, a ja, w swoim Visual Basic, wywołam Transact-SQL lub PL / SQL. Pozwól mi zrobić PL / SQL, ponieważ Oracle nie zawsze gra dobrze z narzędziami Microsoft. Być może profiluję swój kod Visual Basic, a profil może powiedzieć: „Hej, wywołałem tę procedurę przechowywaną i zajęło to zbyt długo”. Ale potem mogę przejść do procedury przechowywanej i mogę wykonać profil bazy danych na przechowywanym i powiedz: „OK, na 100 stwierdzeń, które tu są, oto pięć, które spowodowały problem”. Może być więc konieczne utworzenie zespołu tagów, w którym trzeba użyć wielu profilerów.
Chodzi o to, że jeśli kiedykolwiek dowiesz się, że problem z wydajnością znajduje się w bazie danych, profil bazy danych może pomóc Ci znaleźć igłę w stogu siana, na której stwierdzeniach faktycznie występują te, w których masz problem. Mówię wam o innej rzeczy, która pojawiła się przy profilowaniu: jeśli masz fragment kodu, który jest wywoływany milion razy, ale zajmuje to tylko mikrosekundę z każdego miliona razy, ale jest wywoływany milion razy, co pokaże profiler, to działało przez tak wiele jednostek czasu. I chociaż kod może być bardzo wydajny, możesz spojrzeć i powiedzieć: „Och, zbyt często wywołujemy ten fragment kodu. Może powinniśmy to nazywać tak często, a nie za każdym razem, gdy przetwarzamy nagranie ”czy coś takiego. W ten sposób można znaleźć miejsce, w którym znajduje się wydajny kod, który jest po prostu zbyt często wywoływany, a to w rzeczywistości problem z wydajnością.
Robin Bloor: Tak, to wspaniale. Nigdy tego nie zrobiłem. Widzisz, oczywiście, kiedy miałem problemy z bazą danych, to tak, jakbym w ten czy inny sposób zajmował się bazą danych lub kodem; Nigdy nie mogłem poradzić sobie z oboma jednocześnie. Ale znowu nie zrobiłem - nigdy nie brałem udziału w tworzeniu aplikacji, w których mieliśmy procedury składowane, więc chyba nigdy nie napotkałem problemów, które doprowadzały mnie do szaleństwa, pomysł, że ty podzieliłby kod na bazę danych i program. Ale tak, zrób wszystko - przypuszczam, że odpowiedź będzie twierdząca, ale jest to część działalności zespołu programistów, gdy w ten czy inny sposób próbujesz naprawić coś, co jest zepsute, lub może próbujesz przynieść nowy wspólna aplikacja. Ale czy to wszystko pasuje do wszystkich innych elementów, których oczekiwałbym w środowisku? Czy mogę się spodziewać, że mógłbym to zrobić razem ze wszystkimi moimi pakietami testowymi i wszystkimi innymi rzeczami, które bym robił oraz z rzeczami związanymi z zarządzaniem projektami, czy tak to wszystko razem łączy?
Bert Scalzo: Tak, może stać się częścią każdego ustrukturyzowanego procesu w celu programowania lub rozwoju. I to zabawne, w zeszłym tygodniu miałem klienta, który budował aplikację internetową, a ich baza danych była historycznie niewielka, więc fakt, że nie byli bardzo dobrymi programistami, nigdy ich nie skrzywdził. Cóż, ich baza danych rozrosła się przez lata, a teraz zajmuje 20 sekund na stronie internetowej, od kiedy powiesz: „Zaloguj mnie i daj mi trochę danych do zobaczenia”, a kiedy ekran faktycznie się pojawi, więc teraz jest problem z wydajnością. I wiedzieli, że problemu nie ma w żadnej Javie ani w żadnym innym miejscu. Ale mieli tysiące procedur przechowywanych i dlatego musieli rozpocząć profilowanie procedur przechowywanych, aby dowiedzieć się, dlaczego ta strona internetowa zajmuje 20 sekund? I faktycznie stwierdziliśmy, że mieli kartezjańskie przyłączenie w jednym z wybranych oświadczeń i nie wiedzieli o tym.
Robin Bloor: Wow.
Bert Scalzo: Ale ktoś powiedział mi kiedyś: „No cóż, jak mogliby dołączyć do kartezjańskiego króla i nie wiedzieć o tym?” A to zabrzmi naprawdę okropnie; czasami programista, który nie jest zbyt dobrze zaznajomiony z SQL, zrobi coś takiego, jak dać mi kartezjańskie dołączenie, ale potem zwróci mi tylko pierwszy rekord, więc wiem, że coś mam i potrzebuję tylko pierwszego. I tak, nie zdają sobie sprawy, że właśnie przywrócili miliard płyt lub przeglądają miliard płyt, bo dostali tę, którą byli zainteresowani.
Robin Bloor: Wow, wiem, tak to się nazywa - no cóż, o to właśnie chodziło Dez, jeśli chodzi o ludzi nie tak wykwalifikowanych, jak być może powinni być. Jeśli jesteś programistą, powinieneś wiedzieć, jakie są implikacje wydania dowolnego polecenia. To znaczy, naprawdę, nie ma usprawiedliwienia dla tego poziomu głupoty. Zakładam również, że jesteś, w ten czy inny sposób, obojętny na język w tym zakresie, ponieważ wszystko to koncentruje się na stronie bazy danych. Czy mam rację? Czy to jest to samo, cokolwiek używasz po stronie kodowania?
Bert Scalzo: Oczywiście, możesz to zrobić w Fortran, C lub C ++. W rzeczywistości, w niektórych Uniksach możesz to zrobić nawet dla ich języków skryptowych; faktycznie zapewniają te same narzędzia. A potem chcę cofnąć się o sekundę po to, co powiedziałeś bez żadnej wymówki. Dam programistom jedną przerwę, bo nie lubię rzucać programistów pod autobus. Ale problemem jest tak naprawdę środowisko akademickie, ponieważ kiedy idziesz uczyć się, jak być programistą, uczysz się rekordowego myślenia. Nie uczy się myślenia o ustawieniach, i to właśnie język zapytań strukturalnych lub SQL działa z zestawami; dlatego mamy związek, operator przecięcia i operator minus. Czasami bardzo trudno jest osobie, która nigdy nie zastanawiała się nad zestawami, odejść, puścić przetwarzanie nagrań i pracować z zestawami.
Robin Bloor: Tak, jestem z tobą w tej sprawie. Rozumiem, teraz to kwestia edukacji; Myślę, że to całkowicie kwestia edukacji, myślę, że programiści myślą proceduralnie. A SQL nie jest proceduralny, jest deklaratywny. Mówisz po prostu: „Tego właśnie chcę i nie obchodzi mnie, jak to robisz”, rozumiesz? Podczas gdy w językach programowania często masz podwinięte rękawy i jesteś w drobiazgach nawet zarządzania liczeniem, podczas wykonywania pętli. Przekażę …
Bert Scalzo: Nie. OK, kontynuuj.
Tak, chciałem powiedzieć, że przywołałeś jeszcze jeden przykład, że profiler byłby dobry w łapaniu tego, co dzieje się z tym przetwarzaniem nagrań na raz. Czasami programista, który jest dobry w logice zapisywania na raz, nie może zrozumieć, jak wykonać program SQL. Powiedzmy, że tworzy dwie pętle FOR i wykonuje sprzężenie, ale robi to po stronie klienta. Tak więc robi ten sam efekt co złączenie, ale robi to sam, a profil by to złapał, ponieważ prawdopodobnie skończyłbyś spędzać więcej czasu na ręcznym łączeniu, niż pozwalając, aby serwer bazy danych zrobił to za ciebie.
Robin Bloor: Tak, to byłaby katastrofa. Chodzi mi o to, że rzucasz się w kółko. Drżenie jest zawsze złe.
W każdym razie przekażę Dezowi; Jestem pewien, że ma kilka interesujących pytań.
Dez Blanchfield: Dziękuję, tak. Dołączę do was w nie rzucających programistów pod autobus. Mam na myśli, że spędziłem zbyt wiele lat w życiu jako programista, na każdym poziomie, wiesz, czy to tak, jak powiedziałeś, siedząc na linii poleceń maszyny uniksowej, aw niektórych przypadkach byłem nawet zaangażowany w kilku różnych portach Uniksa z jednej platformy sprzętowej na drugą. I możesz sobie wyobrazić wyzwania, które tam mieliśmy. Ale w rzeczywistości jest karta wychodząca z więzienia dla każdego kodera i skryptera na świecie. Jest to nauka o rakietach, dosłownie, pisanie naprawdę ciasno za każdym razem, przez cały czas, jest nauką o rakietach. I słynne historie ludzi takich jak Dennis Ritchie i Brian Kernahan, którzy pracują nad jakimś fragmentem kodu niezależnie, a następnie przychodzą na czat z recenzją kodu przy kawie i dowiadują się, że napisali dokładnie ten sam fragment kodu w dokładnie tym samym programie, dokładnie w ten sam sposób. I zrobili to w C. Ale ten purystyczny poziom programowania istnieje bardzo rzadko.
Faktem jest, że codziennie mamy tylko 24 godziny na dobę, siedem dni w tygodniu i po prostu musimy załatwić sprawę. I tak, jeśli chodzi o nie tylko tradycyjnych programistów, DBA, programistów, skrypterów, administratorów sieci, administratorów sieci i pracowników ochrony, a także wszystko, co w dzisiejszych czasach, aż po stronę danych obywateli; słyszymy, wszyscy po prostu starają się wykonywać swoją pracę. I dlatego uważam, że najlepsze na wynos z tego wszystkiego jest to, że uwielbiam twoje demo i uwielbiam to, co zostawiłeś nam przed chwilą, rozmawiając z Robin o tym, że ma to coś szczególnego - może nie tyle nisza - ale szeroka przestrzeń, której dotyczy, w zakresie poprawiania kodu oraz SQL i baz danych. Ale byłem bardzo podekscytowany słysząc, jak mówisz, że możesz wbić go w skrypt powłoki i znaleźć jakieś problemy, ponieważ wiesz, że w dzisiejszych czasach zawsze pracujemy na najniższy koszt.
Powodem, dla którego możesz gdzieś kupić koszulę za 6 USD, jest to, że ktoś zbudował system na tyle tanio, aby faktycznie produkować i wysyłać oraz logistycznie dostarczać, sprzedawać i sprzedawać detalicznie oraz przyjmować płatności online, aby otrzymać tę koszulę za 6 USD. I tak się nie stanie, jeśli ludzie będą zarabiać 400 000 $ rocznie za perfekcyjne pisanie kodu; to tylko cały rozwój. Myślę, że jednym z pytań, które naprawdę chciałbym, abyś dał nam trochę więcej wglądu, jest zasięg i zasięg ludzi, których obecnie widzisz, którzy wdrażają tego rodzaju narzędzia do profilowania kod i szukasz problemów z wydajnością? Początkowo, skąd pochodzą? Czy były to duże domy inżynieryjne? I dalej, czy tak jest w istocie, czy mam rację, myśląc, że coraz więcej firm wdraża to narzędzie lub te narzędzia, aby spróbować pomóc programistom, którzy wiedzą, którzy właśnie wykonują zadania, aby ukończyć pracę i wydostać się przez drzwi? A czasem potrzebujemy karty wychodzenia z więzienia? Czy mam rację, myśląc, że historycznie skupiliśmy się na inżynierii i rozwoju? Że teraz dostajemy mniej, jak powiedział Robin, podejście akademickie, a teraz jest to samouczek lub wycinanie i wklejanie kodu, czy po prostu tworzenie rzeczy? Czy to pasuje do ludzi, którzy biorą teraz ten produkt?
Bert Scalzo: Dokładnie tak. Dam ci bardzo konkretny przykład, chcemy po prostu wykonać zadanie, bo ludzie biznesu nie chcą perfekcji. To trochę jak komputerowa gra w szachy: gra w szachy nie szuka idealnej odpowiedzi; szuka odpowiedzi, która jest wystarczająco dobra w rozsądnym czasie, więc tak programujemy. Ale teraz znajduję, że większość ludzi zamiast mówić, że chce profilera w ramach ich testów jednostkowych - tak właśnie bym to zrobił, ponieważ nie widzę w tym straty czasu - to, co się dzieje teraz, gdy robi się to później, czasem podczas testów integracyjnych lub testów warunków skrajnych, jeśli mamy szczęście. Ale w większości przypadków jest to część eskalacji, w której coś trafiło do produkcji, działało przez jakiś czas, może nawet działało przez lata, a teraz nie działa dobrze, a teraz go profilujemy. I wydaje się, że jest to teraz bardziej powszechny scenariusz.
Dez Blanchfield: Tak, i myślę, że termin „dług techniczny” jest prawdopodobnie tym, który bardziej niż jesteś zaznajomiony; Wiem, że Robin i ja na pewno jesteśmy. Myślę, że w dzisiejszych czasach, szczególnie w zwinnym podejściu do programowania i budowania systemu, koncepcja długu technicznego jest teraz bardzo realna i faktycznie uwzględniamy to w projektach. Wiem, mam na myśli, mamy własne projekty, takie jak Media Lens i inne, w których codziennie kodujemy i różne rzeczy w całej Bloor Group. I ilekroć coś budujemy, patrzymy na to, patrzę na to i zawsze patrzę z punktu widzenia tego, co będzie mnie kosztować, aby naprawić to teraz, w porównaniu do tego, czy mogę to po prostu dostać w możesz to zrobić, a potem obserwuj i zobacz, czy coś się zepsuje. I odziedziczę ten dług techniczny, o którym wiem, że będę musiał później zawrócić i naprawić.
Mam na myśli, że zrobiłem to w ciągu ostatnich siedmiu dni: napisałem kilka narzędzi i skryptów, napisałem kilka fragmentów języka Python i wdrożyłem go na zapleczu Mongo, dzięki czemu pewnie, że jest ładna, czysta i bezpieczna, ale dostaje zapytanie, które muszę wykonać, wiedząc, że potrzebuję tej funkcji do pracy, aby dostać się do większej układanki; tam właśnie jest mój prawdziwy ból. Więc zaciągasz ten dług techniczny i myślę, że teraz nie jest to tylko okazjonalna sprawa, myślę, że jest to część DNA rozwoju. Ludzie po prostu - nie nieuczciwie - po prostu akceptują dług techniczny, który jest normalnym rodzajem problemu i muszą go ponieść. To tam zaciągasz dług techniczny. Myślę, że największą zaletą tego, co pokazałeś nam w wersji demo, było to, że możesz dosłownie profilować i obserwować, jak długo trwa uruchomienie. I to chyba jedna z moich ulubionych rzeczy. Mam na myśli, że właściwie zbudowałem narzędzia do profilowania - budowaliśmy narzędzia w Sed, Lex i Orc, aby uruchamiać nasz kod i sprawdzać, gdzie są pętle, zanim takie narzędzia były dostępne - i kiedy zbudowałeś kod do przejścia i przejrzyj swój własny kod, bardzo dobrze radzisz sobie z nie przeglądaniem własnego kodu. Ale teraz tak nie jest. Mając to na uwadze, czy istnieje jakiś segment rynku, który zajmuje się tym bardziej niż jakikolwiek inny? Widzieć jak masę-
Bert Scalzo: O tak, mam … Mam zamiar narysować dla ciebie analogię i pokazać, że nie-programiści robią to cały czas. Bo jeśli kiedykolwiek prowadzę zajęcia z debugowania i profilowania lub sesji, zapytam ludzi: „OK, ile osób tutaj wchodzi do Microsoft Word i celowo nigdy nie używa sprawdzania pisowni?” I nikt nie podnosi ręki, ponieważ do pisania dokumentów wszyscy wiemy, że możemy popełniać błędy w języku angielskim, dlatego wszyscy używają sprawdzania pisowni. A ja powiedziałem: „Dlaczego, kiedy piszesz tekst w swoim IDE, takim jak Visual Basic, nie używasz debugera? To to samo, przypomina sprawdzanie pisowni. ”
Dez Blanchfield: Tak, to świetna analogia. Tak naprawdę nie myślałem, muszę przyznać, że robię coś podobnego za pomocą kilku narzędzi, których używam. W rzeczywistości, jeden z ODF, mój ulubiony z Eclipse, to po prostu wytnij i wklej tam kod i idź szukać rzeczy, które po prostu wyróżniają się od razu i zdając sobie sprawę, że popełniłem literówkę podczas jakiegoś wywołania klasy. Ale teraz jest to interesujące dzięki takiemu narzędziu, które możesz zrobić w czasie rzeczywistym, zamiast wracać i patrzeć na to później, co jest miłe, aby złapać to z góry. Ale tak, to świetna analogia po prostu wstawiania tekstu do edytora tekstu, ponieważ jest to interesujące budzenie, po prostu uświadom sobie, że popełniłeś literówki lub nawet błąd gramatyczny, prawda?
Bert Scalzo: Dokładnie.
Dez Blanchfield: Czy widzisz teraz więcej pozytywnego wyniku od, chyba, ostatniego pytania ode mnie, zanim odpowiem na nasze pytania i pytania dla naszych uczestników. Jeśli miałbyś dać jakieś zalecenie dotyczące podejścia do tego - zakładam, że jest to retoryczne - czy to jest tak, że przychodzisz wcześnie i wdrażasz to w trakcie rozwoju, zanim zaczniesz się rozwijać? A może przeważnie budujesz, ruszasz się, budujesz coś, a potem wchodzisz i profilujesz to później? Podejrzewam, że należy wcześnie wejść i upewnić się, że kod jest czysty z góry. Czy jest to przypadek, że powinni rozważyć tę część swojego wdrożenia?
Bert Scalzo: Idealnie, zrobiliby to z góry, ale ponieważ wszyscy znajdują się w zgiełku, w którym muszą po prostu załatwić sprawy, zwykle nie robią tego, dopóki nie napotkają problemu z wydajnością, którego nie mogliby rozwiązać dodając więcej procesorów i pamięci do maszyny wirtualnej.
Dez Blanchfield: Tak. Więc właściwie wspomniałeś coś interesującego, jeśli mogę szybko? Wspomniałeś wcześniej, że można to uruchomić z dowolnego miejsca i można rozmawiać z bazą danych na zapleczu. Jest to więc wygodne z rodzajem bimodalnej koncepcji, o której teraz mówimy, z chmurą lokalną / pozamiejscową, również z wyglądu, pod koniec dnia, jeśli może porozmawiać z zapleczem i zobaczyć kod, to tak naprawdę nie obchodzi, prawda?
Bert Scalzo: Dokładnie tak, możesz uruchomić to w chmurze.
Dez Blanchfield: Doskonale, bo myślę, że właśnie w tym kierunku zmierza nasz nowy odważny świat. Więc, Eric. Wrócę teraz do ciebie i zobaczę, że mamy tutaj kilka pytań i chcę, aby nasi uczestnicy pozostali z nami, nawet jeśli minęła już godzina.
Eric Kavanagh: Tak, jest tam kilku ludzi, zrobię szybki komentarz: Bert, myślę, że ta metafora, analogia, którą podajesz przy użyciu sprawdzania pisowni, jest szczerze genialna. Jest to warte bloga lub dwóch, szczerze mówiąc, ponieważ jest to dobry sposób na określenie kontekstu tego, co robisz, i tego, jak cenny, i jak naprawdę powinna być najlepszą praktyką korzystania z debuggera regularnie, prawda? Założę się, że kilka głów przytakuje, kiedy wyrzucasz tę, prawda?
Bert Scalzo: Oczywiście, ponieważ mówię im: „Dlaczego sprawdzam pisownię na moich dokumentach? Nie chcę się wstydzić głupimi błędami w pisowni. ”Nie chcą się wstydzić głupimi błędami w kodzie!
Eric Kavanagh: Racja. W rzeczy samej. Cóż, ludzie, spaliliśmy tutaj godzinę i pięć minut, tak wielkie dzięki wam wszystkim za poświęcony czas i uwagę. Archiwizujemy wszystkie te czaty internetowe, w każdej chwili możesz wrócić i je sprawdzić. Najlepszym miejscem do znalezienia tych linków jest prawdopodobnie techopedia.com, dlatego dodamy to do tej listy tutaj.
I dzięki temu pożegnamy was, ludzie. Jeszcze raz świetna robota, Bert, dzięki naszym przyjaciołom z IDERA. Porozmawiamy z tobą następnym razem, rozmawiamy z tobą w przyszłym tygodniu. Dbać! PA pa.
