За вкъщи: Домакинът Ерик Кавана обсъди отстраняване на грешки в базата данни и профилиране с д-р Робин Блур, Дез Бланчфийлд и IDERAs Берт Скалцо.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре, дами и господа, в сряда е 4:00 източно време и разбира се това означава.
Robin Bloor: Не мога да те чуя, Ерик.
Ерик Кавана: Бях там преди дни, така че не сте сами. Но затова темата днес е наистина интересни неща. Това е нещото, за което искате да сте сигурни, че се случва на заден план във вашата компания, освен ако не сте човекът, който го прави, и в този случай искате да сте сигурни, че го правите правилно. Защото говореха за отстраняване на грешки. Никой не обича бъгове, никой не харесва, когато софтуерът престане да работи - хората се разстройват, потребителите стават неприветливи. Това не е добре. Така че, ще говорим за "Бързо реагиране: Отстраняване на грешки в базата данни и профилиране до спасяването."
Има място за твоето наистина, удари ме, @eric_kavanagh, разбира се.
Тази година е гореща. И отстраняването на грешки ще бъде горещо, независимо какво. Това наистина ще бъде един от тези проблеми, който никога няма да отмине, без значение колко добри ще постигнем тези неща, винаги има проблеми, така че ключовото е как да стигнете до мястото, където можете бързо да разрешите тези проблеми? В идеалния случай имате страхотни програмисти, страхотна среда, където не много се обърква, но както се казва в старата поговорка: „Авариите се случват в най-добрите семейства.“ И същото важи за организациите. И така, тези неща се случват, ще стане, въпросът е какво ще бъде вашето решение за справяне с него и решаване на тези проблеми?
Добре чуйте от д-р Робин Блур, след това от собствения ни Дез Бланчфийлд отдолу и, разбира се, от нашия добър приятел, Берт Скалцо, от IDERA. И всъщност, аз ще връча ключовете на Робин Блур и го отнемайте. Подът е ваш.
Robin Bloor: ДОБРЕ. Това е интересна тема. Мислех си, че понеже Дез вероятно ще продължи с действителните техники и военните истории за отстраняването на грешки, мислех, че аз просто правя обсъждане на фона, така че да получим напълно закръглена картина за това какво става. Направих това дълго време и бях кодиращ, така си приличах и почти бях изкушен с това представяне да започна да восъчно лирически за идеята за отворен код, но реших, че ще оставя това на някой друг.
Ето списък с известни бъгове и повечето от тях попадат в горния списък на anybodyys, като всички, с изключение на последните две, струват най-малко 100 милиона долара. Първият беше климатичният орбитър на Марс, изгуби се в космоса и се дължи на проблем с кодирането, при който хората объркаха метричните единици с (смее се) крака и инчове. В Ariane Five Flight 501 имаше несъответствие между двигател, който беше пуснат, и компютрите, които трябваше да управляват ракетата при изстрелването му. Множество компютърни повреди, взривяване на ракета, новини от заглавието. Съветският газопровод през 1982 г., за който се казва, че е най-голямата експлозия в историята на планетата; Не съм сигурен дали е така. Руснаците откраднаха някакъв автоматизиран софтуер за управление, а ЦРУ разбра, че ще го направят и сложи грешки в него, а Съветите го внедриха без тестване. И така, издух тръбопровод, мислех, че това е забавно.
Червеят Морис беше кодиращ експеримент, който внезапно се превърна в буен червей, който обиколи всички - очевидно причини щети на стойност 100 милиона долара; тази оценка е разбира се. Intel направи известна грешка с математически чип - инструкция по математика за чипа Pentium през 1993 г. - която трябваше да струва над 100 милиона долара. Програмата за ябълкови карти е може би най-лошото и най-катастрофално стартиране на всичко, което Apple е правил някога. Хората, които се опитаха да го използват, искам да кажа, някой шофираше по 101 и откриха, че Apple Map казва, че са в средата на залива Сан Франциско. Така че хората започнаха да наричат приложението на Apple Maps като iLost. Най-дългият прекъсване през 1990 г. - просто интересното от гледна точка на цената на нещо подобно - AT&T бяха за девет часа и струваше около 60 милиона долара при междуградски разговори.
И аз бях в американска застрахователна компания и базата данни, те въведоха нова версия на базата данни и тя започна да бърше данни. И това си спомням изключително добре, защото след това бях повикан да участвам в някакъв вид избор на база данни заради това. И беше много интересно, че бяха взели нова версия на базата данни и имаха батерия от тестове, които направиха за нови версии на базата данни, че тя премина всички тестове. Той намери наистина неясен начин за изтриване на данни.
Така че, така или иначе, това е. Мислех, че говоря за несъответствието на импеданса и издадения SQL. Интересното е, че релационните бази данни съхраняват данни в таблици и кодери са склонни да манипулират данни в структурите на обектите, които наистина не се представят много добре на таблиците. И поради това получавате това, което се нарича несъответствие на импеданса и някой трябва да се справи с него по някакъв или друг начин. Но какво всъщност се случва, защото един модел, моделът на кодерите и другият модел на базата данни не са особено подравнени. Получавате грешки, които просто няма да се случат, ако индустрията е изградила неща, които работят заедно, което според мен е смешно. Така че, по принцип, от страна на кодерите, когато получавате йерархии, това може да бъде типове, може да доведе до набори, може да е лоша API способност, може да бъде много неща, които просто изхвърлят нещата във връзка с взаимодействието с базата данни. Но нещото, което е най-много за мен, наистина интересно; винаги ме учудваше, че сте имали тази SQL бариера, която също е един вид импеданс по начин, който кодерите и базата данни работят един с друг. Така че, SQL има разпознаване на данни, което е добре и има DML за подбор, проектиране и присъединяване, което е добре. Можете да хвърлите много възможности по отношение на извличане на данни от базата данни с това. Но той има много малко математически език за правене на неща. Има малко от това и това, и има много малко неща, базирани на времето. И поради това SQL е несъвършено, ако искате, средство за получаване на данните. И така, момчетата от базата данни изградиха съхранени процедури, за да живеят в базата данни, а причината за съхраняваните процедури, живеещи там, беше, че наистина не искате да хвърляте данни напред и назад в програма.
За някои функционалността беше изключително специфична за данните, така че не беше просто референтен интегритет и каскадни изтривания и подобни неща, базата данни се грижеше за внезапното въвеждане на функционалност в база данни, което разбираше, че функционалността за приложението може да бъде разделено между кодера и самата база данни. И това направи работата по внедряването на някои видове функции наистина доста трудна и следователно по-предразположена към грешки. Това е едната страна на играта с база данни, тъй като това означава, че сте попаднали в много реализации, например, че Ive е участвал в релационни бази данни, наистина е много голям код, който се намира в съхранени процедури, който се обработва отделно от код, който седи в приложенията. И изглежда като много странно нещо, което трябва да се получи, трябва да е доста умно да прави различни неща.
Мислех, че Id говоря и за производителността на базата данни, тъй като грешките в производителността често се разглеждат като грешки, но по принцип можете да имате тясно място в процесора, в паметта, на диска, в мрежата и можете да имате проблеми с производителността поради заключване. Идеята е, че кодерът наистина не трябва да се тревожи за производителността и базата данни в действителност ще работи доста добре. Предполага се, че той е проектиран така, че кодерът не трябва да знае. Въпреки това получавате лош дизайн на база данни, получавате лош дизайн на програмата, получавате едновременност в смесването на натоварването, което също може да доведе до проблеми с производителността. Получавате балансиране на натоварването, получавате планиране на капацитета, нарастване на данните - това може да доведе до спиране на базата данни или забавяне. Интересното е, че когато базите данни се напълнят почти, те се забавят. И можете да имате проблем със слоевете данни по отношение на репликацията и необходимостта от репликация и необходимостта да направите архивиране и възстановяване. Както и да е, това е общ преглед.
Единственото нещо, което бих искал да кажа е, че отстраняването на грешки в базата данни може да бъде само толкова натоварващо и нетривиално - и това го казвам, защото съм направил много от него - и вие често ще откривате неговите подобни като всички ситуации при отстраняване на грешки, които някога съм преживявал е, първото нещо, което някога видите, е каша. И трябва да опитате и да преминете от кашата, за да разберете как е възникнала кашата. И често когато гледаш проблем с база данни, всичко, което гледаш, е покварени данни и си мислиш: „Как, по дяволите, се случи това?“
Както и да е, ще предам на Дез, който вероятно ще каже повече думи на мъдрост, отколкото съм излязъл. Не знам как да ти предам топката, Дез.
Ерик Кавана: Ще го предам, застанете, задръжте.
Автоматизиран глас: Линиите на участниците са заглушени.
Ерик Кавана: Добре, задръжте една секунда, нека да дам топката на Дез.
Dez Blanchfield: Благодаря ти, Ерик. Да, д-р Робин Блур, вие наистина сте най-коректни: това е тема, бъг за цял живот, ако извините за каламбура, съжалявам, че не можах да си помогна за това. Надявам се, че можете да видите първия ми екран там, моите извинения за проблема с размера на шрифта в горната част. Темата за бъговете е ежедневна лекция, в много случаи от моя опит. Това е толкова широка и широка тема, така че аз ще поставя фокуса върху две ключови области, по-специално върху концепцията за това, което считаме за много грешка, но проблем с програмирането. Мисля, че тези дни въвеждането на грешка сама по себе си по принцип се вдига от интегрираната среда за разработка, въпреки че може да са дългогодишни бъгове. Но често това е по-скоро случай на профилиране на код и възможно е да се напише код, който функционира, това трябва да е грешка. И така, слайдът ми заглавие тук, аз всъщност имах копие от това в много висока резолюция A3, но за съжаление той се разруши при ход на къща. Но това е ръкописна бележка на лист за програмиране от около 1945 г., където уж някои хора от Харвардския университет в САЩ, втората им конструкция на машина, наречена Марк II. Отстраняват грешката по някакъв проблем, на общ език, но се опитват да намерят грешка и се оказва, че се случи нещо малко по-различно от това, което беше хардуер и уж проблем със софтуера.
И така, градският мит е оня кръг около 9 септемвритата, 1945 г. екип от Харвардския университет разцепваше машина, те се натъкваха на нещо, което те наричаха „релейни седемдесет” - в онези дни програмирането се извършваше във физически смисъл, вие навивате код около дъска и така ефективно програмирате машина - и те откриха това реле номер седемдесет, че има нещо нередно в него и се оказва, че действителният термин „бъг” е възникнал, защото той буквално е бил молец - уж е имало молец, вклинен между някакво парче медна жица от едно място на друго. И историята отива, че легендарната Grace Hopper като тази надпис, за моя заглавие слайд, "първият действителен случай на грешка е намерена" цитирам цитат.
Но както Робин подчерта по-рано в първия си слайд, понятието за грешка върви толкова далеч назад, колкото можем да си представим, че хората правят изчисления, понятия като кръпка. Терминът "кръпка" идва от действително парче лента, залепена върху дупка на перфокарта. Но целият смисъл на това е, че терминът "отстраняване на грешки" излезе от тази концепция за намиране на грешка във физическа машина.И оттогава ние използваме тази терминология около опит да се справим с проблеми, или не толкова като проблеми с кодирането в програма, която не компилира, а като програма, която не работи добре. И конкретно не сте профилирани, просто намерете неща като безкрайни контури, които просто не отиват никъде.
Но ние също имаме сценарий и мислех, че Id пуснах няколко смешни слайда, преди да навляза малко по-подробно. Ето класическата карикатура, наречена XKCD в мрежата, а карикатуристът има някои доста смешни гледки към света. И това за дете, наречено „Малки боби маси“ и уж родителите му са кръстили това младо момче Робърт); ПУСКЕТЕ ТАБЛИЦА Ученици; - и се нарича, и нещо като „Здравей, това е, че училището на твоите синове има някакви компютърни проблеми“, а родителят отговаря: „О, скъпи, той ли е счупил нещо?“ И учителят казва: „Е, по някакъв начин - и учителят пита, - наистина ли си кръстил сина си Робърт); СМЪРТЕТЕ ТАБЛИЦА Ученици; -? ”А родителят казва:„ О, да, малки Боби Маси, ние го наричаме. И отговорът е: „Е, трябва да почистите и дезинфекцирате входовете на базата си данни.“ И аз използвам това много пъти, за да говоря за някои от проблемите, които имаме при намирането на неща в кода, че често кодът не разглежда данните и ,
Друг забавен, не знам дали това е истинско или не - подозирам, че е измама - но отново, той докосва и смешната ми кост. Някой, който сменя регистрационния номер на предната част на колата си, на подобно изявление, което води до спад на базите данни в камерите за скорост и така нататък, които заснемат регистрационните табели на автомобилите. И винаги го отнасям като това, че се съмнявам, че всеки програмист е очаквал хит и изпълнение на техния код от действително моторно превозно средство, но никога не е за подценяване - сила на гневен маниер.
(Смях)
Но това ме води до моя ключов момент, предполагам, и това е, че веднъж време бихме могли да отстраняваме грешки и да кодираме профила като простосмъртни. Но аз много възприемам мнението, че това време е минало и анекдотично в моя опит, първият ми - и това е възрастта ми ужасно, сигурен съм; Робин е добре дошъл да ми се забавлява за това - но в исторически план аз идвам от фона на 14-годишна възраст, скитайки по края на града и чукайки на вратата на център за данни, наречен „Data Com” в Нова Зеландия и пита дали Можех да печеля джобни пари в училището, като се прибирам в късния автобус до вкъщи, около 25 км пътуване всеки ден, като поставях хартия в ers и ленти в касети, и просто бях генерален администратор. И достатъчно любопитно са ми дали работа. Но с времето успях да вляза в персонала и да намеря програмистите и разбрах, че обичам кодирането и преминах през процеса на изпълнение на скриптове и пакетни задачи, който в края на деня все още е код. Трябва да напишете скриптове и партидни задачи, които приличат на мини програми и след това да преминете през целия процес на седене на 3270 код за писане на терминал на ръка.
Всъщност първото ми преживяване беше на терминал за телетипи, който всъщност беше физически ел. 132 колони. По същество, помислете за много стара пишеща машина с хартия, която се превърта през нея, защото те нямаха CRT тръба. И отстраняването на грешки в този код беше много нетривиален проблем, така че вие сте склонни да напишете целия си код на ръка и след това да се държите като машинописка, като правите всичко възможно да не получавате грешки, за да се промъкнете, тъй като е изключително неприятно да трябва да кажете редакторът на един ред да отиде до определен ред и след това реда и след това да го въведете отново. Но веднъж по този начин написахме код и ето как отстранихме грешки и получихме много, много добър в него. И всъщност ни принуди да имаме много добри техники за програмиране, защото беше истинска кавга да го поправим. Но след това пътуването премина - и всички бяха запознати с това - премина от опита на терминала 3270 в моя свят, до Digital Equipment VT220, където можете да видите нещата на екрана, но отново, просто правехте същото нещо, което направихте на хартиената лента, като формат ed само на CRT, но вие бяхте в състояние да изтриете по-лесно и нямахте този звук „dit dit dit dit“.
И тогава знаете, терминалите Wyse - като Wyse 150 - вероятно любимият ми интерфейс към компютър някога - и след това към компютъра, а след това към Mac, а в наши дни модерни GUI и ID, които са базирани в мрежата. И редица програми чрез това, програмиране в едно и асемблер и PILOT и лого, Lisp и, Fortran и Pascal и езици, които могат да накарат хората да се гърчат. Но това са езици, които ви принудиха да пишете добър код; не ви позволиха да се измъкнете с лоши практики. C, C ++, Java, Ruby, Python - и стигаме по-нататък до този етап на програмиране, получаваме повече подобни на скрипт, се приближаваме и се доближаваме до Structured Query Language и езици като PHP, които всъщност се използват за извикване на SQL. Смисълът да ви кажа, че идва от моя произход, аз бях самоук по много начини и тези, които ми помогнаха да се уча, научиха ме на много добри практики в програмирането и много добри практики около дизайна и процесите, за да съм сигурен, че не съм въвел бъги код.
Методи за програмиране в наши дни, неща като например Structured Query Language, SQL, е много мощен, прост език за заявки. Но ние го превърнахме в език за програмиране и аз наистина не вярвам, че SQL някога е бил създаден като модерен език за програмиране, но ние сме го изкривили, за да стане такъв. И това въвежда цял куп проблеми, защото, когато мислим за това от две гледни точки: от гледна точка на кодиране и от гледна точка на DBA. Много лесно е да се запознаем и да въведем грешки за неща като просто лоши техники за програмиране, мързеливи усилия при писане на код, липса на опит, класическият домашен любимец, например, със SQL хора, които скачат в Google и търсят нещо и намират този уебсайт имам пример и правим копие и паста на съществуващ код. И след това да репликирате лошо кодиране, злоупотреба и да го пуснете в производство, защото просто се случва да им дадете желаните от тях резултати. Имате и други предизвикателства, например, в наши дни всички бързаха към това, което наричаме надпреварата до нула: опитваме се да направим всичко толкова евтино и толкова бързо, че имаме сценарий, в който да не наемем нископлатен персонал. И не искам да кажа това по небрежен начин, но не наемах експерти за всяка възможна работа. Някога всичко, свързано с компютрите, беше ракетната наука; тя беше замесена във неща, които се втурнаха и бяха много силни, или влязоха в космоса, или инженерите бяха висококвалифицирани мъже и жени, които бяха завършили образователни степени и строги образования, които ги предпазваха да правят безумни неща.
В наши дни има много хора, които влизат в разработката и дизайна и базата данни, които не са имали дългогодишен опит, не са имали задължително същото обучение или подкрепа. И така завършвате със сценарий само на традиционния аматьор срещу експерт. И там е известна линия, всъщност не мога да си спомня кой е създал цитата, следният текст гласи: „Ако смятате, че скъпото му наемане на експерт да свърши работа, изчакайте, докато наемете няколко аматьори, които създават проблем и трябва да почистете го. ”И така SQL има този проблем и неговия, много лесен за научаване, неговият много лесен за използване. Но според мен това не е перфектен език за програмиране. Много лесно е да правите неща като правите избрана звезда от където и да е и да издърпате всичко това на език за програмиране, с който сте по-удобни като PHP и Ruby или Python, и да използвате езика за програмиране, с когото сте познати, за да извършвате манипулация на данните, вместо да правите по-сложна заявка в SQL. И ние виждаме това много и тогава хората се чудят защо базата данни работи бавно; това е, защото милион души се опитват да купят билет от онлайн система за билети, където прави избрана звезда отвсякъде.
Това е наистина екстремен пример, но вие разбирате всичко от всичко това. Така че, за да удрям истински тази точка у дома, ето пример, който много нося. Аз съм голям фен на математиката, обичам теорията на хаоса, обичам комплектите на Манделброт. От дясната страна има предаване на набора Mandelbrot, с което сигурно всички бяхме запознати. А от лявата страна има парче SQL, което всъщност прави това. Сега, всеки път, когато поставям това на екран някъде, чувам това „О, боже мой, някой е направил серията Mandelbrot със SQL, сериозен ли си? Това е безумно! ”Е, целият смисъл на това е да илюстрирам това, което току-що очертах там, и това е да, всъщност вече можете да програмирате почти всичко в SQL; това е много силно развит, мощен, модерен език за програмиране. Когато първоначално това е бил език за запитвания, той е създаден така, че просто да получи данни. И така, сега имаме много сложни конструкции и имаме съхранени процедури, използваме методология на програмиране, която се прилага към език и така е много лесно за лошата практика на програмиране, липсата на опит, кода за рязане и поставяне, нископлатения персонал, който се опитва да бъдете високоплатен персонал, хора се преструват, че знаят, но трябва да се учат на работата.
Цяла гама от неща, при които профилирането на кодове и това, което ние наричаме отстраняване на грешки, е не толкова намирането на грешки, които спират програмите да работят, а грешките, които просто нараняват системата и лошо структурирания код. Когато погледнете този екран сега и си мислите, че това е просто, неговият вид е сладък и си мислите: „Леле, каква страхотна графика, обичам да управлявам това.“ Но си представете, че работи по някаква част от бизнес логиката. Изглежда доста кокетно, но говори математически графично представена теория на хаоса, но когато се замислите за какво би могло да се използва в някаква бизнес логика, вие получавате картината много бързо. И наистина да илюстрирам това - и съжалявам, че цветовете са обърнати, трябва да е черен фон и зелен, за да бъде зелен екран, но все пак можете да прочетете това.
Отидох и разгледах набързо пример за това, което потенциално бихте могли да направите, ако сте наистина луд и нямате никакъв опит и идвах от различен фон на програмиране и прилагах харесванията на C ++ в SQL, за да илюстрирам моята точка, преди Предавам на нашия учен гост от IDERA. Това е структурирана заявка, написана като C ++, но кодирана в SQL. И всъщност се изпълнява, но се изпълнява за около три до пет минути. И тя дърпа назад сякаш един ред данни от множество бази данни, множество съединения.
Отново, целият смисъл на това е, че ако нямате правилните инструменти, ако нямате правилните платформи и среди, за да можете да уловите тези неща, и те да влязат в производство, и тогава имате 100 000 души, които удрят система всяка ден, час или минута, много скоро приключвате с преживяването в Чернобил, при което голямото желязо започва да се топи и да се заравя в сърцевината на планетата, защото това парче код никога не бива да влиза в производство. Вашите системи и вашите инструменти, извинете ме, трябва да го вземете, преди да стигне до никъде в близост - дори и през процеса на тестване, дори чрез UAT и интеграция на системи, това парче код трябва да се вземе и подчертае, а някой да бъде оставен настрана и казвайки: „Вижте, това наистина е доста добър код, но ви позволява да получите DBA, който да ви помогне да изградите правилно тази структурирана заявка, защото честно казано, това е просто гадно.“ И URL адресите там, можете да отидете и да погледнете - това се нарича като най-сложната SQL заявка, която някога сте писали. Защото повярвайте ми, че всъщност се компилира, той работи. И ако изрежете и поставите това и просто се подигравате с базата данни, е нещо, което трябва да гледате; ако имате инструментите за гледане на базата данни, просто опитайте да се стопите за период от три до пет минути, за да се обадите обратно какъв е един ред.
Така че, да обобщя, имайки предвид това, целият ми опит в кодирането ме научи, че можете да дадете на хората пистолет и ако не внимават, те ще се стрелят в крака; трикът е да им покажете къде е механизмът за безопасност. С правилните инструменти и подходящия софтуер на една ръка разстояние, след като извършите кодирането, можете да прегледате кода си, можете да намерите проблеми чрез профилиране на кода, можете да намерите ефективно непредвидени грешки, които са проблеми с производителността и както казах по-рано на , навремето можете да го направите, гледайки зелен екран. Не можеш повече; има стотици хиляди редове с код, има десетки хиляди приложения, внедрени са милиони бази данни в някои случаи и дори супер хора не могат да правят това на ръка вече. Вие буквално се нуждаете от правилния софтуер и правилните инструменти под ръка и се нуждаете от екипа, който да използва тези инструменти, така че да можете да намерите тези проблеми и да ги адресирате много, много бързо, преди да стигнете дотам, докато Dr. Робин Блур подчерта, че нещата стават катастрофални и нещата се взривяват, или по-често, те просто започват да ви струват много долари и много време и усилия и унищожават морала и други неща, когато не могат да разберат защо нещата отнемат дълго време да тичам.
И като се има предвид това, ще предам на нашия гост и с нетърпение очаквам да чуя как те решиха този въпрос. И по-специално демото, което мисля, че щеше да получи. Ерик, болестно минавам.
Ерик Кавана: Добре, Берт, отнеси го.
Берт Скалцо: Добре благодаря. Bert Scalzo тук от IDERA, Im мениджър на продукти за нашите инструменти за база данни. И ще говоря за отстраняване на грешки. Мисля, че едно от най-важните неща, което Робин каза по-рано - и истината му е, че отстраняването на грешки е натоварващо и нетривиално, а когато отидете в базата данни, отстраняването на грешки е подредбата му още по-трудна и нетривиална - така че, беше важен цитат.
ДОБРЕ. Исках да започна с историята на програмирането, защото много пъти виждам хора, които не отстраняват грешки, не използват грешка, те просто програмират с какъвто и език да се използват и много пъти ми казват: „Е, тези неща за отстраняване на грешки са нови и ние все още не сме започнали да ги използваме. ”И така, което правя, е да им покажа тази диаграма на времевата линия, нещо като предистория, старината, средните векове, каквото ми каже къде сме били условия на езици за програмиране. И имахме много стари езици, започващи през 1951 г. с код за сглобяване, и Lisp, и FACT и COBOL. След това влизаме в следващата група, Pascals и Cs и след това следващата група, C ++ s, и поглеждаме къде е въпросният знак - въпросният знак е приблизително точно около 1978 до може би 1980 г. Някъде в този диапазон имахме грешки, достъпни за нас, и така да се каже, „Ей, аз не използвам дебъгъра, това е едно от тези нови неща“, тогава трябва да сте започнали да програмирате, знаете, през 50-те години, защото това е единственият начин, по който ще получите далеч с това искане.
Сега другото, което е смешно в тази класация, е Дез току-що направи коментар за Грейс Хопър, всъщност познавах Грейс, така че е видът му смешен. И тогава другото, на което се засмях, е, че той говори за телетипи и аз седях там и вървях: „Човече, това беше най-големият скок, който някога сме имали в производителността, когато преминавахме от карти към телетипове, това беше най-големият скок досега.“ Така че , и Ive програмиран на всички езици тук, включително SNOBOL, за който никой досега не е чувал, това е CDC, Control Data Corporation, така че предполагам, че съм малко прекалено стар за тази индустрия.
Dez Blanchfield: Щях да кажа, остаряли сте ни ужасно.
Берт Скалцо: Да, казвам ви, чувствам се като дядо Симпсън. Така че разглеждам отстраняване на грешки и има различни начини за извършване на грешки. Бихте могли да говорите за това, което всички ние смятаме за традиционно влизане в отстраняване на грешки и преминаване през код. Но също така хората ще инструментират своя код; това е мястото, където залепвате изявления във вашия код и може би създавате изходен файл, файл със следи или нещо подобно и така инструментирате кода си. Бих считал, че като отстраняване на грешки, това е малко по-трудно, начин на правене, но се отчита. Но също така, ние имаме известното изявление: гледате и хората всъщност слагат изявления и всъщност видях инструмент, където - и неговия инструмент за база данни - където, ако не знаете как да използвате грешка, натискате бутон и той ще залепи извлечения в целия си код за вас и след това, когато сте готови, натиснете друг бутон и той ги изважда. Защото така се отстраняват много хора.
И причината за отстраняването на грешки е двойна: на първо място трябва да намерим неща, които правят кода ни неефективен. С други думи, обикновено това означава, че има логическа грешка или сме пропуснали бизнес изискване, но какво е, кодът не е ефективен; тя не прави това, което очаквахме. Другия път, когато отидем и правим отстраняване на грешки, неговата ефективност и това би могло да бъде логическа грешка, но какво е, направих ли правилното нещо, просто не се връща достатъчно бързо. Сега правя това, защото профилите вероятно са по-добри за втория сценарий и ще говорят както за отстраняване на грешки, така и за профили. В допълнение, има тази концепция за отдалечено отстраняване на грешки; това е важно, защото много пъти, ако седите на личния си компютър и използвате грешка, която удря база данни, където кодът всъщност се изпълнява в базата данни, всъщност правите това, наречено отдалечено отстраняване на грешки. Може да не го осъзнаете, но това се случва. И тогава е много често при тези грешки да има точки на почивка, точки за гледане, стъпка и пристъпване и някои други често срещани неща, които ще им покажа за момент снимка на екрана.
Сега, профилиране: можете да направите профилиране по няколко различни начина. Някои хора ще кажат, че заснемането и преиграването на работното натоварване там, където заснема всичко, това се счита за профилиране. Моят опит е по-добре, ако е направено вземане на проби. Няма причина да хващате всяко едно изявление, тъй като някои изявления могат просто да стартират толкова бързо, че не ви пука, това, което наистина се опитвате да видите, е, кои са тези, които продължават да се показват отново и отново, защото те стават твърде дълго , Така че понякога профилирането може да означава вземане на проби, а не изпълнение на цялата работа. И обикновено ще получите някакъв изход, който можете да използвате, сега това би могло да бъде визуално вътре в среда за разработка на IDE, където може да ви даде като хистограма на производителността на различните редове от код, но може и все още бъде, че произвежда файл със следи.
Профилите се появяват за първи път през 1979 г. И така, те също са отдавна. Чудесно за намиране на потребление на ресурси или проблеми с производителността, с други думи, че ефективността. Най-общо казано, отделно и различно от отстраняването на грешки, въпреки че съм работил с отстраняване на грешки, които правят и двете едновременно. И докато профилите мисля, че са по-интересните от двата инструмента, ако почувствам, че няма достатъчно проблеми за отстраняване на грешки, тогава определено няма достатъчно хора профили, защото един от десет дебъгъра ще профилира, изглежда. И това е жалко, защото профилирането наистина може да доведе до огромна промяна. Сега, езиците на базата данни, както говорихме по-рано, вие имате SQL - и ние някак си принудихме кръглото колче в квадратната дупка тук и го принудихме да се превърне в език за програмиране - и Oracle.Това е PL / SQL - този процедурен език SQL - и SQL Server, неговият Transact-SQL, SQL-99, SQL / PSM - за, според мен, неговият Процедурно запаметен модул. Postgres му дава друго име, DB2 още едно име, Informix, но въпросът е, че всеки е принудил 3GL тип конструкции; с други думи, за цикли, при декларации с променлива и всички други неща, които са чужди на SQL, вече са част от SQL на тези езици. И така, трябва да можете да отстранявате грешки в PL / SQL или Transact-SQL, точно както бихте направили Visual Basic програма.
Сега, обекти на базата данни, това е важно, защото хората ще кажат: „Е, какви неща трябва да отстранявам в грешка в база данни?“ И отговорът е, добре, каквото можеш да съхраняваш в базата данни като код - ако правя T- SQL или PL / SQL - и Im съхраняват обекти в базата данни, вероятно нейната запаметена процедура или съхранена функция. Но там също се задейства: тригерът е нещо като запаметена процедура, но се задейства на някакво събитие. Сега някои хора в своите задействания ще поставят един ред код и ще извикат запаметена процедура, така че да запазят всичките си съхранен код и процедури, но същата му концепция: неговият все още спусъкът може да бъде това, което инициира цялата работа. И тогава като Oracle, те имат нещо наречено пакет, което е нещо като библиотека, ако щете. Вие поставяте 50 или 100 съхранени процедури в едно групиране, наречено пакет, така че видът му е като библиотека. И така, ето отстраняването на грешки по стария начин; това всъщност е инструмент, който всъщност ще влезе и ще залепи всички тези изявления за отстраняване на грешки във вашия код за вас. Така че, навсякъде, където виждате блок за отстраняване на грешки, не премахвайте, стартирането и проследяването на автоматично отстраняване на грешки, всички те бяха заседнали от някакъв инструмент. И линиите извън това, което е малцинството на кода, добре, това е методът за отстраняване на грешки, който не е ръчен.
И причината да изложа това е, ако се опитвате да направите това на ръка, всъщност ще въвеждате повече код за отстраняване на грешки, който ще поставите във всички тези изявления, отколкото сте с кода. И така, макар че това може да работи и макар да е по-добре от нищо, това е много труден начин за отстраняване на грешки, още повече, че какво ще стане, ако са необходими 10 часа, за да се стартира това нещо, и когато има проблем, е в трета линия? Ако правех интерактивна сесия за отстраняване на грешки, щях да знам на линия три - пет минути в нея - ей, има ли проблем тук, мога да прекратя. Но с това, аз трябва да изчакам да стартира, чак до завършване и след това аз трябва да погледна някакъв файл със следи, който вероятно има всички тези изявления в него, и да опита и да намери иглата в сено. Отново това е по-добре от нищо, но това няма да е най-добрият начин за работа. Ето, този файл ще изглежда така, че идва от предишния слайд; с други думи, аз стартирах програмата и току-що получи куп изявления в този файл с проследяване и може или не мога да успея да пресичам това и да намеря това, което трябва да намеря. И така, отново не съм толкова сигурен, че това е начинът, по който бихте искали да работите.
Сега, интерактивни грешки - и ако сте използвали нещо като Visual Studio за писане на програми или Eclipse, вие сте имали отстраняване на грешки и сте ги използвали с другите си езици - просто не мислите да ги използвате тук с вашата база данни. И там има инструменти, като нашия DB Artisan и нашия Rapid SQL, тук е Rapid SQL, който има отстраняване на грешки и можете да видите отляво, имам запаметена процедура, наречена „провери за дубликати“. По принцип просто ще отида да погледна и видя дали имам няколко реда в таблицата със същото заглавие на филма. Така че, базата данни е за филми. И можете да видите от дясната страна, в горната трета, Ive получи моя изходен код в средата, Ive получи това, което се нарича променливите на часовника ми и таблиците за стек за повикване, а след това в долната част Ive получи някои изходни s. И това, което е важно тук, е ако погледнете тази първа червена стрелка, ако мишката върху дадена променлива, всъщност мога да видя каква стойност е в тази променлива в този момент във времето, когато аз преминавам през кода. И това е наистина полезно и тогава мога да стъпвам по един ред наведнъж през кода, не трябва да казвам изпълнявам, бих могъл да кажа стъпка ред, нека да видя какво се е случило, стъпка друг ред, нека да видя какво се е случило и Правя това в базата данни. И въпреки че аз седя на Rapid SQL на моя компютър и моята база данни е в облака, все още мога да направя това отдалечено отстраняване на грешки и да го видя и да го контролирам от тук, и да правя отстраняване на грешки точно както бих направил с всеки друг език.
Сега, следващата стрелка там - можете да видите малката като стрелка, сочеща вдясно, към този изход на СУБД, там е моят курсор в момента - така с други думи, Ive стъпи и това е мястото, където съм в момента. Така че, ако кажа: „Стъпка отново“, ще премина към следващия ред. Сега точно под това ще видите червената точка. Е, това е точка на прекъсване, която казва „Ей, не искам да премина през тези редове.“ Ако просто искам да прескоча всичко и да стигна до мястото, където е тази червена точка, мога да натисна бутона за стартиране и ще се пусна от тук или до края, или до точка на прекъсване, ако има зададени точки на прекъсване, и тогава тя ще спре и ме остави да направя стъпването отново. И причината, че всичко това е важно и е мощно, е, че когато правя всичко това, това, което се случва в средата и дори в долната част - но най-важното в средата - ще се промени и мога да видя стойностите от променливите си, мога вижте проследяването на стека ми на обаждания, знаете, и така цялата тази информация се показва там като аз преминавам през кода, така че всъщност мога да видя и усетя и да разбера какво се случва и как действително кодът работи по време на изпълнение , И обикновено мога да намеря проблем, ако има такъв или ако съм достатъчно добър, за да го преодолея.
Добре, сега ще говоря за профилер и в случая това е профилер, който мога да видя чрез грешка. Спомняте ли си, че казах, че понякога са разделени, а понякога могат да бъдат заедно? В този случай и отново, Im в Rapid SQL, и отляво до номерата на линията мога да видя там марж от лявата страна. И това, което е, е този брой секунди или микросекунди, необходими за изпълнение на всеки ред код, и мога да видя това ясно, че цялото си време прекарвам в този един цикъл FOR, където аз избирам всичко от таблицата. И така, Whatevers, случващ се в този цикъл FOR, вероятно е нещо, което трябва да разгледам, и ако мога да го подобря, ще изплати дивиденти. Няма да получавам подобрения, като работя върху тези линии, които имат 0,90 или 0,86; там не е прекарано много време. В този случай и отново, Im в Rapid SQL, виждате как мога да правя профилиране, смесено с моята грешка. Това, което е хубаво, Rapid SQL също ви позволява да го направите и по друг начин. Rapid SQL ви позволява да кажете: „Знаеш ли какво? Не искам да бъда в грешката, просто искам да стартирам това и тогава искам да разгледам графично или визуално един и същ тип информация. "
И можете да видите, че аз вече не е в отстраняването на грешки и той изпълнява програмата и след като изпълнението е завършено, ми дава диаграми да ми казва нещата, така че да видя, че имам едно изявление, което изглежда като заемането на по-голямата част от пая диаграма и ако погледна, виждам на тази решетка към дъното, линия 23, отново е веригата FOR: Хес поема най-много време, той всъщност е тъмночервен дъвчещ цялата диаграма на пай. И така, това е друг начин за правене на профили. Случва се да наричаме този „анализатор на код“ в нашия инструмент. Но всъщност това е просто профилер, отделен от грешки. Някои хора обичат да го правят по първия начин, някои хора обичат да го правят по втория начин.
Защо правим отстраняване на грешки и профилиране? Не е, защото искаме да напишем най-големия код в света и да получим повишение на заплащането - това може да е нашата причина, но всъщност това не е причината да го правите - обещахте на бизнеса, че ще направите нещо правилно, че вашата програма ще бъде ефективна. За това ще използвате дебъгъра. В допълнение, бизнес крайни потребители; не са много търпеливи: искат резултати, дори преди да натиснат клавиша. Трябваше да прочетат мнението им и да направят всичко моментално. С други думи, трябва да бъде ефективна. И така, за това бихме използвали профила. Сега, без тези инструменти, наистина вярвам, че сте този човек в бизнес костюма с лък и стрела и стреляте по целта и сте със завързани очи. Защото как ще откриете как дадена програма се изпълнява, само като погледнете статичния код и как ще разберете кой ред е къде наистина би прекарал най-много време в изпълнение, отново само като погледнете статичния код? Прегледът на код може или не може да доведе до някои от тези неща, но няма гаранция, че прегледът на кода ще ги намери всички. С помощта на грешка и профилер трябва да можете да намерите всички тези грешки.
Добре, аз просто ще направя истинска бърза демонстрация тук. Не ми е намерение да натискам продукт, просто искам да ви покажа как изглежда отстраняването на грешки, причинява много пъти хората да кажат: „Никога не съм виждал някое от тях преди.“ И изглежда доста на слайдовете на екрана, но какво изглежда ли, когато е в движение? И така, тук на екрана ми управлявам нашия DB Artisan продукт; там също имаме грешка. DB Artisan е предназначен повече за DBA, Rapid SQL е повече за разработчиците, но видях разработчици, които използват DB Artisan, и видях DBA, които използват Rapid. Така че, не се хващайте за продукта. И ето, имам избор да правя грешка, но преди да стартирам грешката, аз ще извлека този код, за да можете да видите как изглежда кодът, преди да започна да го изпълнявам. И така, ето точно същият код, който беше в снимката на екрана, това е моята проверка за дубликати. И искам да отстраня грешката в това, затова натискам грешка. И сега отнема момент и вие казвате: „Е, защо ви отнема момент?“ Запомнете отдалеченото отстраняване на грешки: отстраняването на грешки всъщност се случва на моя сървър на база данни, а не на моя компютър. И така, тя трябваше да премине и да създаде сесия там, да създаде дистанционно отстраняване на грешки, да закача сесията ми към тази сесия за отдалечено отстраняване на грешки и да настрои комуникационен канал.
И така, сега ето стрелата ми, нейната горе в горната част, от първа линия, там съм в кода. И ако натисна третата икона там, което е стъпка, ще видите, че стрелката просто се е преместила и ако продължавам да я натискам, ще видите да продължава да се движи. Сега, ако исках да стигна до този цикъл ЗА, защото знам, че там е проблемът, мога да поставя точка на прекъсване. Мислех, че го настроя. О, снимай, имах един от ключовете за заснемане на екрана ми, съпоставен със същия ключ като дебъгъра, онова, което причинява объркването. ОК, така че просто ръчно зададох точка на прекъсване там, така че сега вместо да правя стъпка, стъпка, стъпка, стъпка, докато стигна до там, всъщност мога просто да кажа: „Напред и пусни това нещо“ и тя ще спре. Забележете, че ме премести чак до мястото, където е точката на прекъсване, така че сега съм в противоречие с изпълнението на този цикъл, мога да видя на какво са зададени всичките ми променливи, което не е изненада, защото ги инициализирах всички нула. И сега мога да вляза в този цикъл и да започна да гледам какво се случва вътре в този цикъл.
И така, сега ще направя избран брой от моите наеми и мога да преместя курсора на този човек и да погледна, хес два, два е по-голям от един, така че вероятно ще направя следващото парче от този код. С други думи, тя намери нещо. Просто ще продължа напред и ще пусна това. Не искам да преживея всичко тук; това, което искам да ви покажа е, когато се извършва отстраняване на грешки, той завършва точно като нормална програма. Имам зададена точка на прекъсване, така че когато казах бягай, просто се върна към следващата точка на прекъсване. Позволявам му да работи до края, защото това, което искам да видите, е, че един грешки не променя поведението на програмата: когато свърши работа, трябва да получа същите резултати, ако го бях пуснал не в грешка.
И с това, аз ще спре демото и да се върна, защото искаме да сме сигурни, че имаме време за въпроси и отговори. И така, ще го отворя за въпроси и отговори.
Ерик Кавана: Добре, Робин, може би въпрос от теб и после двойка от Дез?
Robin Bloor: Да, разбира се, намирам това очарователно, разбира се. Работил съм с такива неща, но никога не съм работил с подобно нещо в базата данни. Можете ли да ми дадете някаква представа за какво хората използват профила? Тъй като това е, гледат ли те - защото предполагам, че са - те разглеждат проблеми с производителността, дали ще ви помогне да разграничите кога базата данни отнема време и кода отнема време?
Берт Скалцо: Знаеш ли, това е фантастичен въпрос. Да кажем, че работя във Visual Basic, а аз, вътре в моя Visual Basic, ще се обадя на Transact-SQL или PL / SQL. Нека да направя PL / SQL, тъй като Oracle не винаги играе добре с инструментите на Microsoft. Може да профилирам моя Visual Basic код и профилът там може да казва: „Ей, аз нарекох тази съхранена процедура и отне твърде много време.“ Но тогава мога да вляза в съхранената процедура и мога да направя профил на база данни на съхранения процедурата и кажете: „Добре, от 100-те изявления, които са тук, ето петте, които са причинили проблема.“ И така, може да се наложи да направите екип с тагове, където трябва да използвате множество профили.
Идеята е, че ако някога ви кажат, че проблемът с производителността е във вашата база данни, профилът в базата данни може да ви помогне да намерите иглата в сенокос, върху която всъщност са изявленията, където имате проблем. Казвам ви още нещо, което се оказа с профилирането: ако имате парче код, който се извиква милион пъти, но отнема само микросекунда всеки милион пъти, но се нарича милион пъти, какво ще покаже профила , това нещо вървеше за това много единици време. И така, въпреки че кодът може да е високоефективен, може да погледнете и да кажете: „О, прекалено често правеха този разговор към този код. Може би трябва да го наричаме само толкова често, а не всеки път, когато обработваме запис “или нещо подобно. И така всъщност можете да намерите къде има ефикасен код, който просто се нарича твърде често, и това всъщност е проблем с производителността.
Robin Bloor: Да, това е прекрасно. Никога не съм правил това. Разбирате, когато имах проблеми с базата данни, сякаш по един или друг начин се занимавах с база данни или се занимавам с код; Никога не бих могъл да се справя с двамата едновременно. Но там отново не съм направил - никога не съм участвал в създаването на приложения, където имахме съхранени процедури, така че предполагам, че всъщност никога не съм срещал проблеми, които ме разяждаха, идеята, че разделихте кода между база данни и програма. Но така, направете всичко - Предполагам, че отговорите ще са да, но това е част от дейността на екипа за развитие, когато по един или друг начин се опитвате да поправите нещо, което е счупено, или може би се опитвате да обедините ново приложение. Но всичко това ли е съобразено с всички останали компоненти, които бих очаквал в околната среда? Мога ли да очаквам, че бих могъл да го клипирам заедно с всичките си тестови пакети и всички онези други неща, които бих правил и с моите неща за управление на проекти, ето как всички тези клипове са заедно?
Берт Скалцо: Да, тя може да стане част от всеки структуриран процес, който да направи вашите усилия за програмиране или разработка. И смешното му беше, че миналата седмица имах клиент, който създаваше уеб приложение, а тяхната база данни в исторически план беше малка и затова фактът, че не бяха много добри програмисти, никога не ги нараняваше. Е, тяхната база данни се разраства с годините и сега отнема 20 секунди в уеб страница, между когато казвате: „Влезте ми и ми дайте малко данни, за да видя“ и кога екранът действително се появи, и сега проблем с производителността. И знаеха, че проблемът не е бил в никоя от тяхната Java или някое от онези други места. Но те имаха хиляди съхранени процедури и затова трябваше да започнат профилиране на съхранените процедури, за да разберат защо тази уеб страница отнема 20 секунди? И всъщност установихме, че имат декартово присъединяване в едно от избраните от тях изявления и не го знаехме.
Robin Bloor: Еха.
Берт Скалцо: Но някой ми каза веднъж: „Е, как биха могли да се присъединят декартово и да не го знаят?“ И това звучи наистина ужасно; понякога програмист, който не е много удобен за SQL, ще направи нещо като да ми присъедини декартово, но след това само ще ми върне първия запис, така че знам, че имам нещо и имам нужда само от първия. И така, те не осъзнават, че току-що са върнали милиард записи или преглеждат милиард записи, защото са получили този, от когото се интересуват.
Robin Bloor: Уау, знам, ето какво се нарича - е, това е, за което Дез ставаше по отношение на хора, които не са толкова квалифицирани, колкото може би трябва да бъдат, нали знаете. Ако сте програмист, трябва да знаете какви са последиците от издаването на която и да е команда. Искам да кажа, наистина, това не е оправдание за това ниво на глупост. Предполагам също, че по един или друг начин сте просто езиков агностик по отношение на това, защото всичко това е съсредоточено върху страната на базата данни. Прав ли съм в това? Дали е същото, каквото и да използвате от кодиращата страна?
Берт Скалцо: Абсолютно можете да направите това във Fortran или C или C ++. Всъщност, в някои Unixes дори можете да го направите за техните скриптови езици; те всъщност предоставят същите инструменти. И тогава искам да се върна секунда за това, което казахте без извинение. Ще направя една почивка на програмистите, защото не обичам да хвърлям програмисти под автобуса. Но проблемът е наистина академичната среда, защото когато отивате да научите как да бъдете програмист, вие сте научавали да мислите записващо по едно време. Не сте научени да задавате мислене и това е това, което Structured Query Language или SQL работи с набори; Ето защо ние имаме обединението, пресечната точка и оператора минус. И е много трудно понякога човек, който никога не е мислил по отношение на комплекти, да се откаже, да пусне обработка на записи по време и да работи с набори.
Robin Bloor: Да, аз съм с теб по въпроса. Искам да кажа, че сега разбирам, че това е проблем с образованието; Смятам, че това е напълно образователен проблем, мисля, че е естествено програмистите да мислят процедурно. И SQL не е процедурен, а декларативният му. Всъщност просто казвате: „Това искам и не ме интересува как го правите“, нали знаете? Като имате предвид, че с езиците за програмиране често запретвате ръкави и намалявате до минимум, дори да управлявате броя, докато правите цикъл. Болна ръка за ...
Берт Скалцо: Не. ОК, продължи.
Да, исках да кажа, че вие представихте още един пример, че един профилер би бил добър за хващане, като това продължава с тази запис в момента. Понякога програмист, който има добра логика на запис, не може да разбере как да прави SQL програма. Е, нека да кажем, че прави два цикъла FOR и по принцип прави съединение, но го прави от страна на клиента. Така че, той прави същия ефект като присъединяването, но той сам го прави, и профилът ще улови това, защото вероятно ще свършите повече време за свързване ръчно, отколкото да оставите сървъра на базата данни да го направи вместо вас.
Robin Bloor: Да, това би било катастрофа. Искам да кажа, че просто бихте мъркали. Хвърлянето винаги е лошо.
Както и да е, ще предам на Дез; Сигурен съм, че Хес има някои интересни въпроси.
Dez Blanchfield: Благодаря, да, да. Ще се присъединя към вас в не хвърлянето на програмисти под автобуса. Искам да кажа, че прекарах много години в живота си, като самият аз съм кодиращ, на всяко ниво, знаете дали е, както казахте, седящ в командния ред на Unix машината, а в някои случаи дори бях замесен в няколко различни порта на Unix от една хардуерна платформа до друга. И можете да си представите предизвикателствата, които имахме там. Но реалността е ере, че картата за излизане от затвора за всеки кодер и сценарист в света. Ракетна наука, съвсем буквално, всеки път да пишеш наистина здраво, през цялото време е ракетна наука. И известни истории на хора като Денис Ричи и Брайън Кернахан, които работят върху някакъв фрагмент код независимо и след това се обръщат към чат за преглед на кода по кафе и установяват, че са написали точно същия код в точно същата програма, в точно такава същия начин. И го направиха в C. Но това пуристично ниво на програмиране съществува много рядко.
Факт е, че ежедневно има само 24 часа на ден, седем дни в седмицата и просто трябва да свършим нещата. И така, що се отнася до не само традиционните програмисти, DBA, и кодери, и скриптове, и sysadmin, и мрежови администратори, и служители по сигурността, и всичко до края на данните за гражданите в наши дни; чуваме, всеки просто се опитва да си свърши работата. И така мисля, че голямото извличане от всичко това е, че обичах вашето демонстрация и обичах извеждането, което ни оставихте там, само преди малко, разговаряйки с Робин за факта, че това има определено - може би не толкова много ниша - но широко пространство, към което се прилага, що се отнася до коригиране на код и SQL и бази данни. Но бях много развълнуван, когато чух да казваш, че можеш да го прокараш със скрипт с черупки и да намериш някои проблеми, защото знаеш, че в днешния ден и възрастта винаги работеха с най-ниската цена за всичко.
Причината да купите някъде риза за 6 долара е, че някой е изградил система, достатъчно евтина, за да произвежда и доставя и логистично да доставя и продава и продава на дребно и да извършва онлайн плащания, за да получи тази риза от 6 долара. И това не се случва, ако на хората ви се плаща 400 000 долара годишно, за да напишат код по перфектен начин; просто цялото му развитие. Така че, този момент, предполагам, че един от въпросите, които наистина ви обичам, просто ни дайте още малко представа, каква е широчината и обхватът на типа хора, които виждате в момента, които разгръщат този вид инструменти за профилиране на код и търсене за проблеми с изпълнението? Първоначално, исторически, откъде идват те? Били ли са големите инженерни къщи? И тогава, продължавайки напред, вярно ли е, правилно ли съм, като мисля, че все повече и повече компании прилагат този инструмент или тези инструменти, за да се опитат да помогнат на кодери, които знаят, които просто правят нещата, за да свършат работата и да го изкараш през вратата? А понякога се нуждаем от карта за излизане от затвора? Прав ли съм да мисля, че в исторически план имахме по-инженерна насоченост и развитие? Това сега ставаше все по-малко, както каза Робин, академичен подход, а сега неговият самоук, или изрязване и поставяне на код, или просто изграждане на нещата? И съответства ли това на хората, които взимат продукта сега?
Берт Скалцо: Да точно. И Ви давам много конкретен пример, ние просто искаме да свършим работата, защото бизнесмените не искат съвършенство. Това е нещо като компютърна игра на шах: шахматната игра не търси идеалния отговор; търси отговор, който е достатъчно добър в разумен период от време, така че така програмираме. Но това, което намирам сега, е, че повечето хора вместо да казват, че искат профилер като част от тяхното тестване на единици - това е начинът, по който бих го направил, защото не го виждам като загуба на време - какво се случва е, че това се прави по-късно, понякога, по време на интеграционно тестване или стрес-тестове, ако имат късмет. Но повечето пъти частта му от ескалация, в която някои неща са тръгнали в производството, е продължила известно време, може би дори е въртяла години, а сега не работи добре и сега добре го профилира. И това изглежда е по-често срещаният сценарий сега.
Dez Blanchfield: Да, и мисля, че терминът "технически дълг" вероятно е повече от познат; Познавам Робин и със сигурност съм. Смятам, че в наши дни, особено при гъвкавите подходи към разработването и изграждането на системи, концепцията за технически дълг е много реално нещо и ние всъщност го отчитаме в проектите. Знам, искам да кажа, че имаме свои собствени проекти като Media Lens и други, където ежедневно се извършва кодиране и различни неща в Bloor Group. И винаги, когато строихме нещо, ние някак си гледаме, аз го гледам и винаги гледам от гледна точка на това, което ще ми струва да поправя това в момента, в сравнение с това просто мога ли да го вкарам в извадете го и след това гледайте и вижте дали тези неща ще се счупят. И наследявам този технически дълг, за който знам, че трябва да се върна по-късно и да се оправя.
И искам да кажа, че направих това през последните седем дни: написах няколко инструмента и скрипта, написах няколко парчета език Python и го разгърнах в задния край на Монго, като се уверих, че е приятен, чист и сигурен, но просто получава заявката, която трябва да свърша, като знам, че имам нужда от тази функция, за да работя, за да стигна до по-големия пъзел; там е моята истинска болка. И така вие поемате този технически дълг и мисля, че това вече не е просто случайно нещо, мисля, че това е част от ДНК на развитието в момента. Хората просто - не безпристрастно - просто приемат техническия дълг е нормален начин на издаване и те просто трябва да го понесат. Това е мястото, където поемате техническия дълг. И мисля, че страхотното нещо, което ни показахте в демонстрацията, беше, че можете буквално да профилирате и да гледате колко време отнема нещо. Това вероятно е едно от любимите ми неща. Искам да кажа, че всъщност създадох инструменти за профилиране - използвахме за изграждане на инструменти в Sed и Lex и Orc, за да стартираме кода си и да видим къде са бримките, преди да са налични инструменти като този - и когато създадете код, за да отидете и да прегледате собствения си код , получавате много добри резултати в това да не се налага да преглеждате собствения си код. Но това не е така сега. Имайки предвид това, има ли определен пазарен сегмент, който заема това повече от всеки друг? Виждам като маса -
Берт Скалцо: О да, аз имам ... Ще направя аналогия за вас и ще ви покажа, че непрограмистите го правят непрекъснато. Защото, ако някога преподавам клас за грешка или сесия за профилиране, аз питам хората: „Добре, колко хора тук влизат в Microsoft Word и целенасочено никога не използват проверката на правописа?“ И никой не вдига ръка, защото за писане на документи, всички знаем, че можем да правим английски грешки и затова всеки използва проверката на правописа. И аз казах: „Е, как така, когато пишете в IDE си като Visual Basic, не използвате дебъгъра? Това е същото нещо, прилича на проверка на правописа. "
Dez Blanchfield: Да, всъщност това е чудесна аналогия. Наистина не мислех, трябва да призная, че всъщност правя нещо подобно с няколко инструмента, които използвам. Всъщност, ODF, любимият ми с Eclipse, е просто изрязване и поставяне на код там и отивам да търся неща, които просто подчертават веднага и осъзнавам, че направих печатна грешка в някакъв клас разговор. И, но интересното му сега с този инструмент можете да го направите в реално време, за разлика от това да се върнете и да го разгледате по-късно, което е нещо приятно да го хванете напред. Но да, това е чудесна аналогия с просто въвеждането на текстов процесор, предизвика интересното му събуждане, просто осъзнай, че си направил грешки в грешка или дори граматична грешка, нали?
Берт Скалцо: Точно.
Dez Blanchfield: Така че, виждате ли повече от потърпевш сега от предполагам, искам да кажа, последния въпрос от мен, преди да се хвърля към нашите въпроси и отговори, може би за нашите участници. Ако щяхте да дадете някаква препоръка около подхода за това - предполагам, че това е риторично - случаят ли е, че започвате рано и го прилагате, докато се развивате, преди да се развивате? Или е случаят, че предимно се строиш, движиш се, изграждаш нещо, след което влизаш и го профилираш по-късно? Подозирам, че случаят е да влезе рано и се уверете, че вашите кодове са чисти предварително. Или случаят е, че те трябва да обмислят тази част от тяхното разгръщане?
Берт Скалцо: В идеалния случай те биха го направили предварително, но тъй като всички са в света на суматохата, където просто трябва да свършат нещата, те са склонни да не го правят, докато не изпаднат в проблем с производителността, който не могат да решат, като добавят още процесори и памет към виртуална машина.
Dez Blanchfield: Да. И така, всъщност споменахте нещо интересно, ако мога бързо? Споменахте преди, че това може да се стартира отвсякъде и може да говори с база данни в задната част. Така че това е удобно с бимодалната концепция, за която говорим сега, за облак в помещение / извън помещение, и от външния вид на нещата, в края на деня, ако може да говори с задния край и да видите кодът, това наистина не ви интересува, нали?
Берт Скалцо: Точно така, да, можете да пуснете това в облака.
Dez Blanchfield: Отлично, защото мисля, че точно там отива новият ни смел свят. И така, Ерик. Сега ще се върна при вас и ще видя, че тук имаме няколко въпроса и искам нашите участници да останат с нас, въпреки че изминахме часа.
Ерик Кавана: Да, има няколко хора там, аз просто да направя бърз коментар: Берт, мисля, че метафората, аналогията, която даваш на използването на проверка на правописа, е откровено блестяща. Това е достойно за блог или два, честно казано, защото това е добър начин да се определи какво е това, което правиш, и колко е ценно и как наистина трябва да е най-добрата практика да се използва дебъгер на редовно, нали? Обзалагам се, че получавате някои глави да кимате, когато го изхвърлите, нали?
Берт Скалцо: Абсолютно, защото това, което им казвам, е: „Защо провеждам проверка на правописа на документите си? Не искам да се смущавам от глупави правописни грешки. ”Е, те не искат да бъдат смутени от глупави грешки в кодирането!
Ерик Кавана: Точно така. Да, именно. Е, хора, изгаряхме тук час и пет минути, толкова много благодаря на всички от вас за отделеното време и внимание. Ние архивираме всички тези уеб чатове, не се колебайте да се върнете по всяко време и да ги проверите. Най-доброто място да намерите тези връзки вероятно е techopedia.com, така че добре добавете това към този списък тук.
И с това щяха да се сбогуват, хора. За пореден път страхотна работа, Берт, благодарение на нашите приятели от IDERA. Добре, ще говоря с вас следващия път, добре да говоря с вас следващата седмица. Пази се! Чао чао.