вынос: Ведущий Эрик Кавана обсуждал отладку и профилирование базы данных с доктором Робином Блором, Дезом Бланчфилдом и IDERAs Бертом Скальцо.
Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.
Эрик Кавана: Хорошо, дамы и господа, в среду 4:00 по восточному времени, и, конечно, это значит.
Робин Блур: Не могу тебя услышать, Эрик.
Эрик Кавана: Я был там несколько дней назад, так что ты не одинок. Но сегодня тема действительно интересная. Это то, что вы хотите, чтобы убедиться, что происходит в фоновом режиме в вашей компании, если только вы не человек, который делает это, и в этом случае вы хотите убедиться, что вы делаете это правильно. Потому что говорили об отладке. Никто не любит ошибки, никто не любит, когда программное обеспечение перестает работать - люди расстраиваются, пользователи недружелюбны. Это не хорошо. Итак, собирались поговорить о «Быстрых ответах: отладка базы данных и профилирование на помощь».
На самом деле есть место для твоего, нападай на меня, @eric_kavanagh, конечно.
В этом году жарко. И отладка будет горячей, несмотря ни на что. Это действительно будет одна из тех проблем, которые никогда не исчезнут, независимо от того, насколько мы хороши в этом, всегда будут проблемы, так что ключ в том, как добраться до места, где можно быстро решить эти проблемы? В идеале, у вас есть отличные программисты, отличные среды, в которых не так уж много и не получается, но, как гласит старая поговорка: «Аварии случаются в лучших семьях». То же самое относится и к организациям. Итак, это происходит, это должно произойти, вопрос в том, что станет вашим решением для решения этой проблемы и решения этих проблем?
Хорошо слышно от доктора Робина Блура, потом от нашей собственной Дез Бланчфилд из-под и, конечно же, от нашего хорошего друга, Берт Скальцо, из IDERA. И на самом деле, я собираюсь передать ключи от Робина Блура, забрать его. Вам слово.
Робин Блур: ХОРОШО. Это интересная тема. Я подумал, потому что Дез, вероятно, продолжит рассказывать о реальных методах и военных историях об отладке, я подумал, что я просто проведу предварительную дискуссию, чтобы мы могли получить полностью округленную картину происходящего. Я делал это долгое время, и раньше я был программистом, так что это похоже, и я почти соблазнился этой презентацией начать лирическую идею идеи открытого исходного кода, но я думал, что я оставлю это кому-то другому.
Вот список известных ошибок, и большинство из них попадают в топ-список anybodys, по сути, все, кроме двух последних, стоят как минимум 100 миллионов долларов. Первым был орбитальный аппарат Mars Climate Orbiter, затерявшийся в космосе из-за проблемы кодирования, когда люди путали метрические единицы с (смеется) футами и дюймами. В Ariane Five Flight 501 произошло несоответствие между установленным двигателем и компьютерами, которые должны были запускать ракету при запуске. Многочисленные сбои в работе компьютеров, взрывы ракет, заголовки новостей. Советский газопровод в 1982 году, считается самым крупным взрывом в истории планеты; Я не уверен, что это так. Русские украли какое-то программное обеспечение для автоматического управления, и ЦРУ осознало, что они собираются это сделать, и добавило в него ошибки, а Советы внедрили его без тестирования. Итак, взорвал трубопровод, подумал, что это забавно.
Червь Морриса был экспериментом по кодированию, который внезапно превратился в хищного червя, который обошел всех - очевидно, он нанес ущерб на 100 миллионов долларов; это оценка, конечно. Intel сделала известную ошибку с математическим чипом - математическая инструкция на чипе Pentium в 1993 году - она должна была стоить более 100 миллионов долларов. Программа «Карты яблок» - это, пожалуй, худший и самый катастрофический запуск всего, что когда-либо делала Apple. Люди, которые пытались его использовать, были, я имею в виду, кто-то ехал по 101 и обнаружил, что на карте Apple указано, что они находятся в середине залива Сан-Франциско. Итак, люди начали называть приложение Apple Maps iLost. Наш самый длительный перерыв в работе в 1990 году - это просто интересно с точки зрения стоимости чего-то подобного - AT & T отсутствовали около девяти часов и стоили около 60 миллионов долларов на междугородних звонках.
И я был в страховой компании Великобритании, и в базе данных они внедрили новую версию базы данных, и она начала стирать данные. И я это очень хорошо помню, потому что после этого меня вызвали, чтобы принять участие в выборе базы данных. И было очень интересно, что они взяли новую версию базы данных, и у них было множество тестов, которые они сделали для новых версий базы данных, которые она прошла все тесты. Он нашел действительно неясный способ стереть данные.
Так или иначе, вот так. Я думал, что я буду говорить о несоответствии импеданса и выданного SQL. Интересно, что реляционные базы данных хранят данные в таблицах и кодировщиках, как правило, манипулируют данными в структурах объектов, которые действительно не очень хорошо отображаются на таблицы. И из-за этого вы получаете то, что называется несоответствием импеданса, и кто-то должен так или иначе иметь дело с этим. Но что на самом деле происходит, потому что одна модель, модель кодировщиков и база данных, другая модель, не особенно согласованы. Вы получаете ошибки, которых просто не было бы, если бы индустрия создала вещи, которые работают вместе, что, я думаю, смешно. Так что, в основном, на стороне программистов, когда вы получаете иерархии, это могут быть типы, это может приводить к наборам, это может быть плохая возможность API, это может быть много вещей, которые просто выбрасывают вещи с точки зрения взаимодействия с базой данных. Но самое интересное для меня - это действительно интересно; Меня всегда удивляло то, что у вас был этот барьер SQL, который также является своего рода импедансом в том смысле, что кодеры и база данных работают друг с другом. Итак, в SQL есть распознавание данных, и это хорошо, и в нем есть DML для выбора, проецирования и объединения, что нормально. Вы можете использовать множество возможностей для получения данных из базы данных. Но у него очень мало математического языка для ведения дел. У этого есть кое-что из этого, и у этого есть очень мало основанного на времени материала. И из-за этого SQL является несовершенным, если хотите, средством получения данных. Итак, ребята из базы данных создали хранимые процедуры для жизни в базе данных, и причина существования хранимых процедур заключалась в том, что вы действительно не хотели передавать данные назад и вперед в программу.
Поскольку некоторые функции были исключительно специфичны для данных, так что это была не просто ссылочная целостность и каскадное удаление, и тому подобное, база данных позаботилась обо всех неожиданных действиях, которые вы вносите в базу данных, что, конечно, означало, что эта функция Приложение может быть разделено между кодером и самой базой данных. И это сделало работу по реализации некоторых видов функций действительно довольно сложной и, следовательно, более подверженной ошибкам. Таким образом, это одна из сторон игры с базой данных, потому что это означает, что вы получили множество реализаций, например, то, что я участвовал в реляционных базах данных, действительно очень много кода, который находится в хранимых процедурах и обрабатывается отдельно от кода, который сидит в приложениях. И это кажется очень странной вещью, которая должна быть достаточно умной в выполнении различных вещей.
Я подумал, что я также расскажу о производительности базы данных, потому что ошибки производительности часто рассматриваются как ошибки, но в основном вы можете столкнуться с узким местом в ЦП, в памяти, на диске, в сети, и у вас могут возникнуть проблемы с производительностью из-за блокировки. Идея будет заключаться в том, что кодировщику на самом деле не нужно беспокоиться о производительности, а база данных на самом деле будет работать достаточно хорошо. Предполагается, что он должен быть разработан так, чтобы кодер не знал об этом. Однако у вас плохой дизайн базы данных, у вас плохой дизайн программы, вы получаете параллелизм в смешивании рабочей нагрузки, что также может привести к проблемам с производительностью. Вы получаете балансировку нагрузки, планирование емкости, рост данных - это может привести к остановке или замедлению работы базы данных. Интересно, что когда базы данных почти заполнены, они замедляются. И у вас могут возникнуть проблемы с уровнями данных с точки зрения репликации, необходимости репликации и необходимости выполнять резервное копирование и восстановление. Во всяком случае, это общий обзор.
Единственное, что я хотел бы сказать, это то, что отладка базы данных может быть только такой обременительной и нетривиальной - и я говорю это, потому что я многое сделал - и вы часто обнаружите, что она похожа на все ситуации в отладке, которые я когда-либо испытывал это первое, что вы когда-либо видите, это беспорядок. И вы должны попытаться перейти от беспорядка к выяснению, как возник этот беспорядок. И часто, когда вы смотрите на проблему с базой данных, все, на что вы смотрите - это поврежденные данные и вы думаете: «Как, черт возьми, это произошло?»
Во всяком случае, я передам Дезу, который, вероятно, скажет больше слов мудрости, чем я придумал. Я не знаю, как передать тебе мяч, Дез.
Эрик Кавана: Я передам это, подожди, держись.
Автоматический голос: Линии участников приглушены.
Эрик Кавана: Хорошо, подожди секунду, позволь мне дать Дезу мяч.
Дез Бланчфилд: Спасибо, Эрик. Да, доктор Робин Блур, вы действительно правы: это тема, пожизненный багбир, если вы простите за каламбур, извините, я не смог с этим справиться. Надеюсь, вы можете увидеть мой первый экран там, мои извинения за проблему размера шрифта в верхней части. Тема ошибок - это лекция продолжительностью в один день, во многих случаях по моему опыту. Это такая широкая и широкая тема, поэтому я собираюсь сосредоточить внимание на двух ключевых областях, в частности на концепции того, что мы считаем ошибкой, но проблемой программирования. Я думаю, что в наши дни введение ошибки, как таковой, обычно воспринимается интегрированными средами разработки, хотя они могут быть долговременными ошибками. Но часто это в большей степени случай профилирования кода и возможность написания кода, который функционирует, что должно быть ошибкой. Итак, мой титульный слайд здесь, на самом деле у меня была его копия в очень высоком разрешении A3, но, к сожалению, она была разрушена при переезде. Но это рукописная заметка на листе программирования примерно с 1945 года, где предположительно некоторые люди из Гарвардского университета в США, их вторая сборка машины под названием Mark II. Они отлаживали какую-то проблему на общем языке, но пытались найти ошибку, и оказалось, что возникло что-то немного отличающееся от того, что было аппаратным и предположительно программным.
Итак, городской миф о том, что вокруг 9 сентябрягоВ 1945 году команда из Гарвардского университета разбирала машину, они столкнулись с тем, что они называли «реле семидесяти» - в те дни программирование осуществлялось в физическом смысле, вы наматывали код на доску, и именно так вы эффективно программировали машина - и они нашли это реле номер семьдесят, было что-то не так с ним, и оказалось, что фактический термин «ошибка» возник, потому что это было буквально мотылек - предположительно, был мотылек, зажатый между каким-то куском медного провода из одного места в другое. И история гласит, что легендарная Грейс Хоппер в качестве этого заголовка для моего титульного слайда «первый фактический случай обнаружения ошибки» цитирует цитату.
Но, как Робин подчеркивал ранее на своем первом слайде, концепция ошибки восходит к тем временам, когда мы можем представить себе, что люди делают вычисления, например, патч. Термин «патч» произошел от фактического куска ленты, наклеенного на отверстие в перфокарте. Но весь смысл этого в том, что термин «отладка» возник из этой концепции обнаружения ошибки в физической машине.И с тех пор мы использовали эту терминологию, пытаясь справиться с проблемами, либо не столько как проблемы с кодированием в программе, которая не компилируется, но и как программа, которая не работает хорошо. И, в частности, не было профилировано просто найти такие вещи, как бесконечные циклы, которые просто никуда не денутся.
Но у нас также есть сценарий, и я подумал, что я бы добавил пару забавных слайдов, прежде чем углубиться в детали. Вот классический мультфильм под названием XKCD в Интернете, и у мультипликатора есть довольно забавные взгляды на мир. А это про ребенка по имени «Маленькие столики Бобби» и, предположительно, его родители назвали этого мальчика Роберта); DROP TABLE Учащиеся; - и называется, и вроде «Привет, у твоей школы сыновей какие-то проблемы с компьютером», и родитель отвечает: «О, дорогой, он что-то сломал?» И учитель говорит: «Ну, в некотором смысле, - спрашивает учитель, - ты действительно назвал своего сына Роберта); DROP TABLE Студенты; -? »И родитель говорит:« О да, маленькие столики Бобби, которые мы ему называем ». В любом случае, они продолжают говорить, что потеряли студенческие записи за многие годы, надеюсь, вы счастливы. И ответ таков: «Ну, вы должны очистить и дезинфицировать входные данные своей базы данных». И я использую это много раз, чтобы говорить о некоторых проблемах, с которыми мы сталкиваемся при поиске вещей в коде, что часто код не смотрит и на данные. ,
Еще один забавный, я не знаю, реально это или нет - я подозреваю, что это обман - но опять же, это также касается моей забавной кости. Кто-то изменил номерной знак на передней части своего автомобиля, сделав аналогичное заявление, в результате которого в базах данных падали камеры контроля скорости и т. Д., Которые фиксируют номерные знаки автомобилей. И я всегда ссылаюсь на это как на то, что сомневаюсь, что любой программист предвосхитил бы их код на реальном автомобиле, но никогда не стоит недооценивать это - мощь злого гика.
(Смех)
Но это приводит меня к моей ключевой точке, я думаю, и это то, что когда-то мы могли отлаживать и профилировать код как простые смертные. Но я очень придерживаюсь того мнения, что это время прошло, и, судя по моему опыту, это мой первый опыт, и я ужасно постарел, я уверен; Робин, добро пожаловать, чтобы высмеять меня за это - но исторически я пришел из прошлого в возрасте 14 лет, бродя по концу города и стучась в дверь дата-центра Data Com в Новой Зеландии и спрашивая, Я мог бы заработать карманные деньги в школе, доставая опоздавший автобус домой, около 25 км поездок в день, кладя бумаги в кассеты и кассеты в ленточные накопители, и просто являясь обычным администратором. И как ни странно, они дали мне работу. Но со временем мне удалось найти себя в штате и найти программистов, и я понял, что люблю кодирование, и прошел через процесс запуска сценариев и пакетных заданий, которые в конце концов все еще остаются кодом. Вы должны написать сценарии и пакетные задания, которые выглядят как мини-программы, а затем пройти через весь процесс написания кода на терминале 3270 вручную.
Фактически, мой самый первый опыт был на терминале телетайпа, который был на самом деле физическим с 132 столбцами. По сути, представьте себе, как очень старую пишущую машинку с бумагой, которая пролистывала ее, потому что у них не было ЭЛТ-трубки. И отладка кода на этом была очень нетривиальной проблемой, поэтому вы, как правило, писали весь свой код вручную, а затем действовали как машинистка, стараясь не впустить ошибки, потому что было крайне неприятно рассказывать редактор одной строки, чтобы перейти к определенной строке, а затем к строке, а затем набрать ее обратно. Но однажды, именно так мы писали код и так мы отлаживали, и мы очень, очень хорошо справились с этим. И на самом деле, это вынудило нас использовать очень хорошие методы программирования, потому что это было очень сложно исправить. Но затем путешествие прошло - и все были знакомы с этим - оно прошло путь от терминала 3270 в моем мире до Digital Equipment VT220, где вы могли видеть вещи на экране, но опять же, вы просто делали то же, что и вы. на бумажной ленте, вроде формата ed, только на ЭЛТ, но вам было легче удалять, и у вас не было такого звука «dit dit dit dit».
И потом, вы знаете, терминалы Wyse - как Wyse 150, возможно, мой любимый интерфейс с компьютером - и затем ПК и затем Mac, а в наши дни современные GUI и идентификаторы, которые основаны на сети. И целый ряд программ: программирование на одном и на ассемблере, PILOT, Logo, Lisp, Fortran, Pascal и языки, которые могут заставить людей съежиться. Но это языки, которые заставили вас писать хороший код; они не позволили вам избежать неприятностей. C, C ++, Java, Ruby, Python - и мы продвигаемся дальше на этом этапе программирования, мы становимся все более похожими на сценарии, мы становимся все ближе и ближе к языку структурированных запросов и таким языкам, как PHP, которые фактически используются для вызова SQL. Смысл в том, чтобы сказать вам, что, исходя из моего прошлого, я был самоучкой во многих отношениях, и те, которые помогли мне учиться, научили меня очень хорошим практикам программирования и очень хорошим практикам в области дизайна и процессов, чтобы быть уверенным, что я не представляю ошибки код.
Методы программирования в наши дни, такие как, например, язык структурированных запросов, SQL, очень мощный и простой язык запросов. Но мы превратили его в язык программирования, и я действительно не верю, что SQL когда-либо разрабатывался как современный язык программирования, но мы исказили его, чтобы стать таким. И это порождает целый ряд проблем, возникающих, когда мы думаем о них с двух точек зрения: с точки зрения кодирования и с точки зрения администратора баз данных. Его очень легко найти и внести ошибки в такие вещи, как просто плохие методы программирования, ленивые усилия по написанию кода, нехватка опыта, классическая любимая мозоль, которую я имею, например, с людьми SQL, которые прыгают в Google и ищут что-то и находят веб-сайт, который получил пример и делает копию и вставку существующего кода. А затем тиражирование плохого кодирования, злоупотребление служебным положением и запуск его в производство, потому что это просто дает им желаемые результаты. Вы столкнулись с другими проблемами, например, в эти дни все спешат к этому, что мы называем гонкой к нулю: стараемся делать все так дешево и так быстро, что у нас есть сценарий, в котором не работают низкооплачиваемые сотрудники. И я не имею в виду это неискренне, но не нанимал экспертов для каждой возможной работы. Когда-то давно что-то связанное с компьютерами было ракетостроением; он занимался вещами, которые ударялись и были очень громкими, или уходили в космос, или инженеры были высококвалифицированными мужчинами и женщинами, которые получили ученые степени и имели строгое образование, которое мешало им делать сумасшедшие вещи.
В наши дни многие люди, занимающиеся разработкой, дизайном и базой данных, не имеют многолетнего опыта, не обязательно проходят такое же обучение или поддержку. И так вы заканчиваете сценарием просто традиционного любителя против эксперта. И есть знаменитая строка, я не могу вспомнить, кто создал цитату, строка гласит: «Если вы думаете, что нанять эксперта для выполнения работы дорого, подождите, пока вы не наймете пару любителей, которые создадут проблему, и вам придется очистите его ». Итак, SQL имеет эту проблему, и его очень, очень легко изучить, его очень легко использовать. Но это, на мой взгляд, не идеальный язык программирования. Очень легко сделать такие вещи, как выбрать звезду из любой точки мира и перенести все это на язык программирования, который вам удобнее, например, PHP и Ruby или Python, и использовать язык программирования, с которым вы изначально знакомы, для манипулирования данными, вместо того, чтобы делать более сложный запрос в SQL. И мы часто видим это, а потом люди задаются вопросом, почему база данных работает медленно; Это потому, что миллион людей пытаются купить билет через систему онлайн-продажи билетов, где он выбирает звезду откуда угодно.
Теперь это действительно экстремальный пример, но вы поймете смысл всего этого. Так что, чтобы действительно подчеркнуть этот момент, вот пример, который я часто беру с собой. Я большой поклонник математики, я люблю теорию хаоса, я люблю множества Мандельброта. На правой стороне есть исполнение набора Мандельброта, с которым, я уверен, все были знакомы. И слева есть кусок SQL, который на самом деле это отображает. Теперь, каждый раз, когда я помещаю это где-то на экран, я слышу: «О, боже, кто-то сделал серию Мандельброта с SQL, ты серьезно? Это безумие! »Ну, весь смысл в том, чтобы проиллюстрировать то, что я только что изложил там, и это да, на самом деле вы теперь можете программировать практически все на SQL; это очень хорошо разработанный, мощный, современный язык программирования. Изначально это был язык запросов, он был разработан, чтобы просто получать данные. Итак, теперь у нас есть очень сложные конструкции и у нас есть хранимые процедуры, у нас есть методология программирования, применяемая к языку, и поэтому это очень легко для плохой практики программирования, отсутствия опыта, вырезанного и вставленного кода, низкооплачиваемого персонала, пытающегося быть высокооплачиваемым персоналом, люди, притворяющиеся, что они знают, но они должны учиться на работе.
Целый ряд вещей, где профилирование кода и то, что мы называем отладкой, это не столько обнаружение ошибок, которые мешают работе программ, но и ошибок, которые только вредят системе и плохо структурированному коду. Когда вы смотрите на этот экран сейчас, и вы думаете, что это просто мило, и вы думаете: «Ух, какая замечательная графика, я бы хотел запустить это». Но представьте, что это работает на каком-то кусочке бизнес-логики. Это выглядит довольно аккуратно, но говорит о математической теории хаоса с графической визуализацией, но когда вы думаете о том, для чего она потенциально может быть использована в некоторой бизнес-логике, вы очень быстро получаете картину. И чтобы действительно проиллюстрировать это - и я сожалею, что цвета поменялись местами, он должен быть черным фоном, а зеленый - зеленым, но вы все равно можете это прочитать.
Я пошел и быстро взглянул на пример того, что вы могли бы потенциально сделать, если бы вы были по-настоящему сумасшедшими и не имели никакого опыта, пришли из другого опыта программирования и применили подобные C ++ к SQL, чтобы действительно проиллюстрировать мою точку зрения, прежде чем Я передаю наш образованный гость из IDERA. Это структурированный запрос, написанный как C ++, но закодированный в SQL. И он на самом деле выполняется, но выполняется в течение трех-пяти минут. И он забирает якобы одну строку данных из нескольких баз данных, из нескольких соединений.
Опять же, весь смысл этого в том, что если у вас нет правильных инструментов, если у вас нет правильных платформ и сред, чтобы можно было ловить эти вещи, и они попадают в производство, и тогда у вас есть 100 000 человек, поражающих систему каждый день, час или минута, очень скоро вы получите чернобыльский опыт, когда большое железо начинает плавиться и хоронить себя в ядре планеты, потому что этот кусок кода никогда не должен поступать в производство. Прошу прощения, ваши системы и ваши инструменты должны понять это, прежде чем они приблизятся - даже в процессе тестирования, даже благодаря UAT и системной интеграции, этот фрагмент кода должен быть выбран и выделен, а кого-то следует отвести в сторону и говоря: «Послушайте, это действительно красивый код, но давайте возьмем администратора баз данных, который поможет вам правильно построить этот структурированный запрос, потому что, откровенно говоря, это просто противно». А URL-адреса там можно посмотреть и посмотреть - его называют « самый сложный SQL-запрос, который вы когда-либо писали. Потому что поверьте мне, что на самом деле компилируется, он работает. И если вы вырезаете и вставляете это и просто копируете базу данных, на это вполне можно посмотреть; если у вас есть инструменты для наблюдения за базой данных, просто попытайтесь растаять в течение трех-пяти минут, чтобы перезвонить, что является одной линией.
Итак, подводя итог, имея в виду, весь мой опыт в программировании научил меня, что вы можете дать людям оружие, и если они не будут осторожны, они будут стрелять себе в ногу; хитрость заключается в том, чтобы показать им, где находится механизм безопасности. С правильными инструментами и подходящим программным обеспечением у вас под рукой, после того, как вы выполнили кодирование, вы можете просмотреть свой код, найти проблемы, профилировав код, найти эффективные непреднамеренные ошибки, которые являются проблемами производительности, и, как я уже говорил ранее, Давным-давно, вы могли бы сделать это, глядя на зеленый экран. Вы не можете больше; Есть сотни тысяч строк кода, развернуты десятки тысяч приложений, в некоторых случаях миллионы баз данных, и даже супер-люди не могут сделать это вручную. Вы буквально нуждаетесь в правильном программном обеспечении и правильных инструментах у вас под рукой, и вам нужна команда, чтобы использовать эти инструменты, чтобы вы могли найти эти проблемы и решить их очень, очень быстро, прежде чем вы дойдете до сути, тогда как доктор Робин Блур подчеркнул, что все или становится катастрофическим, и вещи взрываются, или, чаще, они просто начинают стоить вам много долларов и много времени и усилий и разрушают мораль и прочее, когда они не могут понять, почему вещи берутся долго бегать.
И с учетом этого я передам слово нашему гостю, и я с нетерпением ожидаю услышать, как они решили эту проблему. И, в частности, демо, которое я думаю получить. Эрик, я перейду обратно.
Эрик Кавана: Хорошо, Берт, убери это.
Берт Скальцо: Хорошо спасибо. Берт Скальцо (Bert Scalzo) из IDERA, я менеджер по продуктам для наших инструментов баз данных. И я собираюсь поговорить об отладке. Я думаю, что одна из самых важных вещей, которые Робин сказал ранее - и это очень верно, заключается в том, что отладка является обременительной и нетривиальной, а когда вы переходите к отладке базы данных, ее порядок еще более обременительный и нетривиальный - так что была важная цитата.
ХОРОШО. Я хотел начать с истории программирования, потому что часто я вижу людей, которые не отлаживают, они не используют отладчик, они просто программируют на любом языке, который они используют, и часто они мне говорят: «Ну, эти вещи отладчика являются новыми, и мы еще не начали использовать их ». И вот что я делаю, я показываю им эту временную диаграмму, вид предыстории, старости, средневековья, своего рода сказать, где мы были в термины языков программирования. И у нас были очень старые языки, начиная с 1951 года с ассемблерного кода, а также с Lisp, FACT и COBOL. Затем мы попадаем в следующую группу, Pascals и Cs, а затем в следующую группу, C ++, и смотрим, где находится этот вопросительный знак - этот вопросительный знак находится примерно в промежутке между 1978 и, возможно, 1980 годом. Где-то в этом диапазоне мы имели Доступные нам отладчики и, так сказать, «Эй, я не использую отладчик, потому что это одна из этих новых вещей», тогда вы, должно быть, начали программировать, знаете, еще в 1950-х, потому что это единственный способ, которым вы могли бы получить покончить с этим требованием.
Еще одна вещь, которая забавна в этом графике, это то, что Дез только что прокомментировал Грейс Хоппер, я на самом деле знал Грейс, так что это довольно забавно. А потом еще одна вещь, над которой я смеялся, это то, что он говорил о телетайпах, и я сижу там и говорю: «Чувак, это был самый большой скачок в нашей продуктивности, когда мы переходили от карточек к телетайпам, это был самый большой скачок за всю историю». и я программировал на всех языках здесь, включая SNOBOL, о котором раньше никто не слышал, это был CDC, Control Data Corporation, так что я думаю, я становлюсь слишком стар для этой отрасли.
Дез Бланчфилд: Я собирался сказать, что вы там ужасно постарели.
Берт Скальцо: Да, я говорю тебе, я чувствую себя дедушкой Симпсоном. Итак, я смотрю на отладку и есть разные способы отладки. Вы могли бы говорить о том, что мы все считаем традиционным входом в отладчик и пошаговое выполнение кода. Но также люди будут применять свой код; вот где вы вставляете операторы в ваш код и, возможно, вы создаете выходной файл, файл трассировки или что-то еще, и таким образом вы применяете свой код. Я бы посчитал это отладкой, это немного сложнее, способ сделать это, но это считается. Но также мы получили известное утверждение: вы смотрите, и люди фактически вводят заявления, и я действительно видел инструмент, где - и его инструмент базы данных - где, если вы не знаете, как использовать отладчик, вы нажимаете кнопку, и она будет придерживаться операторы в вашем коде для вас, а затем, когда вы закончите, вы нажимаете другую кнопку, и она удаляет их. Потому что так много людей отлаживают.
И причина отладки у нас двоякая: во-первых, нам нужно найти вещи, которые делают наш код неэффективным. Другими словами, обычно это означает, что есть логическая ошибка, или мы пропустили бизнес-требования, но в действительности код неэффективен; это не делает то, что мы ожидали. В другой раз, когда мы идем и делаем отладку, это делается для эффективности, и это может быть логической ошибкой, но что я сделал правильно, он просто не возвращается достаточно быстро. Теперь я подчеркиваю это, потому что профилировщики, вероятно, лучше для этого второго сценария и собирались поговорить об отладчиках и профилировщиках. Кроме того, существует эта концепция удаленной отладки; это важно, потому что много раз, если вы сидите на своем персональном компьютере и используете отладчик, который обращается к базе данных, где код фактически выполняется в базе данных, вы фактически делаете то, что называется удаленной отладкой. Вы можете не осознавать этого, но это то, что происходит. И потом, у этих отладчиков очень часто есть точки останова, точки наблюдения, шаг за шагом и некоторые другие общие вещи, которые я собираюсь показать на скриншоте через мгновение.
Теперь профилирование: вы можете выполнить профилирование несколькими способами. Некоторые люди скажут, что рабочая нагрузка захватывает и воспроизводит там, где она захватывает все, что считается профилированием. Мой опыт был бы лучше, если бы он сделал выборку. Нет никакой причины перехватывать каждое утверждение, потому что некоторые утверждения могут выполняться так быстро, что вам все равно, что вы на самом деле пытаетесь увидеть, ну, это те, которые продолжают появляться снова и снова, потому что они выполняются слишком долго , Таким образом, иногда профилирование может означать выборку, а не запускать все это. И, как правило, вы получите какой-то вывод, который вы можете использовать, теперь он может быть визуальным внутри среды разработки IDE, где он может дать вам гистограмму производительности различных строк кода, но он также может будь то, что он производит файл трассировки.
Профилировщики впервые появились в 1979 году. Так что они тоже существуют уже давно. Отлично подходит для поиска потребления ресурсов или проблем с производительностью, другими словами, это вопрос эффективности. Вообще говоря, это отдельный и отличный от отладчика, хотя я работал с отладчиками, которые делают оба одновременно. И хотя профилировщики, на мой взгляд, являются более интересными из этих двух инструментов, если я чувствую, что отладки недостаточно людей, то определенно недостаточно профилей людей, потому что, похоже, один из десяти отладчиков будет профилировать. И это позор, потому что профилирование действительно может иметь огромное значение. Итак, языки баз данных, о которых мы говорили ранее, у вас есть SQL - и мы в некотором роде заставили круглый колышек в квадратное отверстие и превратили его в язык программирования - и Oracle.Это PL / SQL - то есть процедурный язык SQL - и SQL Server, его Transact-SQL, его SQL-99, его SQL / PSM - для его процедурно-хранимого модуля. Postgres дает ему другое имя, DB2, еще одно имя, Informix, но дело в том, что все используют конструкции типа 3GL; другими словами, циклы FOR, объявления переменных и все остальное, что чуждо SQL, теперь являются частью SQL в этих языках. Итак, вы должны иметь возможность отлаживать PL / SQL или Transact-SQL так же, как и программу Visual Basic.
Теперь, объекты базы данных, это важно, потому что люди скажут: «Ну, что мне нужно отлаживать в базе данных?» И ответ, ну, в общем, то, что вы можете сохранить в базе данных как код - если я делаю T- SQL или PL / SQL - и я храню объекты в базе данных, это, вероятно, хранимая процедура или хранимая функция. Но есть и триггеры: триггер похож на хранимую процедуру, но он запускает какое-то событие. Теперь некоторые люди в своих триггерах будут помещать одну строку кода и вызывать хранимую процедуру, чтобы они сохранили весь свой хранимый код и процедуры, но это та же концепция: все равно триггер может быть тем, что инициирует все это. И затем, как Oracle, у них есть нечто, называемое пакетом, что-то вроде библиотеки, если хотите. Вы помещаете 50 или 100 хранимых процедур в одну группу, называемую пакетом, так что это похоже на библиотеку. Итак, вот отладчик по-старому; на самом деле это инструмент, который на самом деле вставит все эти отладочные операторы в ваш код для вас. Таким образом, везде, где вы видите блок отладки, не удаляйте его, запускайте и отслеживайте автоматический отладчик, все они были заблокированы каким-либо инструментом. И строки за пределами этого, который составляет меньшую часть кода, ну, это не ручной метод отладки.
И причина, по которой я это поднимаю, заключается в том, что если вы пытаетесь сделать это вручную, вы на самом деле собираетесь набрать больше кода отладки, чтобы вставить все эти операторы, чем вы с кодом. Таким образом, хотя это может сработать, и хотя это лучше, чем ничего, это очень трудный способ отладки, особенно с учетом того, что, если для запуска этой программы потребовалось 10 часов, и где у нее есть проблема, в третьей строке? Если бы я проводил интерактивную сессию отладки, я бы знал в строке три - пять минут спустя - эй, здесь есть проблема, я могу выйти. Но после этого мне пришлось ждать, пока он запустится, вплоть до завершения, а затем я взглянул на какой-нибудь файл трассировки, в котором, вероятно, есть все эти утверждения, и попытался найти иголку в стоге сена. Опять же, это лучше, чем ничего, но это не лучший способ работать. Вот как будет выглядеть этот файл с предыдущего слайда; Другими словами, я запустил программу, и она только что получила кучу утверждений в этом файле трассировки, и я могу или не могу пройти через это и найти то, что мне нужно найти. Итак, опять же, я не настолько уверен, что именно так вы бы хотели работать.
Теперь, интерактивные отладчики - и если вы использовали что-то вроде Visual Studio для написания программ или Eclipse, у вас были отладчики, и вы использовали их с другими языками - просто не думали использовать их здесь с вашей базой данных. И есть инструменты, такие как DB Artisan и Rapid SQL, здесь это Rapid SQL, у которых есть отладчик, и вы можете видеть слева, у меня есть хранимая процедура, называемая «проверка на наличие дубликатов». По сути, я просто пойду и посмотрю, есть ли у меня несколько строк в таблице с одинаковым названием фильма. Итак, база данных для фильмов. И вы могли видеть справа, в верхней трети, у меня есть мой исходный код посередине, у меня есть так называемые мои переменные наблюдения и мои стеки вызовов, а затем в нижней части у меня есть некоторые выходные данные. И здесь важно то, что, если вы посмотрите на эту первую красную стрелку, если я наведу курсор мыши на переменную, я на самом деле могу видеть, какое значение находится в этой переменной в данный момент времени, когда я перехожу через код. И это действительно полезно, и тогда я могу шаг за шагом пройти по коду, мне не нужно говорить «выполнить», я мог бы сказать «шаг за строкой», позвольте мне посмотреть, что произошло, перейти на другую строку, позвольте мне увидеть, что произошло, и Я делаю это в базе данных. И хотя я сижу на Rapid SQL на своем ПК, а моя база данных находится в облаке, я все еще могу выполнять эту удаленную отладку, видеть ее и управлять ею отсюда, и выполнять отладку так же, как и на любом другом языке.
Теперь следующая стрелка там - вы можете увидеть небольшую стрелку, направленную вправо, к выходу этой СУБД, где находится мой курсор в данный момент - другими словами, я ступил и вот где я в данный момент. Поэтому, если я скажу: «Шаг снова», я пойду на следующую строку. Теперь чуть ниже вы увидите красную точку. Ну, это точка останова, которая говорит: «Эй, я не хочу переступать через эти строки». Если я просто хочу перепрыгнуть через все и добраться до этой красной точки, я могу нажать кнопку запуска, и она будет бежать отсюда либо в конец или точка останова, если есть какие-либо установленные точки останова, и затем он остановится и позволит мне повторить шаг. И причина, по которой все это важно и мощно, заключается в том, что когда я делаю все это, то, что происходит в середине и даже внизу - но самое главное в середине - изменится, и я могу видеть значения из своих переменных, я могу вы видите мою трассировку стека вызовов, вы знаете, и поэтому вся эта информация отображается там, когда я перехожу через код, так что я на самом деле могу видеть, чувствовать и понимать, что происходит и как на самом деле работает код во время выполнения. , И обычно я могу найти проблему, если она есть, или если я достаточно хорош, чтобы ее решить.
Хорошо, теперь я собираюсь поговорить о профилировщике, и в данном случае это профилировщик, который я вижу через отладчик. Помните, я говорил, что иногда они раздельные, а иногда они могут быть вместе? В этом случае, опять же, я в Rapid SQL, и я вижу поле слева от номеров строк. И это то, что это количество секунд или микросекунд, которое потребовалось для выполнения каждой строки кода, и я ясно вижу, что все мое время тратится в этом цикле FOR, где я выбираю все из таблицы. И поэтому, что бы ни происходило внутри этого цикла FOR, вероятно, мне нужно взглянуть на него, и если я смогу сделать его лучше, это принесет дивиденды. Я не собираюсь добиваться каких-либо улучшений, работая с теми линиями, которые имеют 0,90 или 0,86; Theres не так много времени провел там. Теперь, в этом случае, и снова, я в Rapid SQL, вы видите, как я могу сделать профилирование смешанным с моей отладкой. Теперь приятно то, что Rapid SQL также позволяет делать это иным способом. Быстрый SQL позволяет вам сказать: «Знаете что? Я не хочу быть в отладчике, я просто хочу запустить это, а затем я хочу посмотреть графически или визуально информацию того же типа ».
И вы можете видеть, что я больше не в отладчике, и он запускает программу, и после того, как выполнение завершено, он дает мне графики, чтобы сказать мне вещи, так что я вижу, что у меня есть одно утверждение, которое выглядит так, как будто оно занимает большую часть пирога. Если посмотреть на график, то на этой сетке внизу, в строке 23, снова появится цикл FOR: он занимает больше всего времени, на самом деле он темно-красный, жуя всю круговую диаграмму. И так, это еще один способ для профилирования. Мы называем это «Code Analyst» в нашем инструменте. Но в основном это просто профилировщик, отделенный от отладчика. Некоторым нравится делать это первым способом, другим нравится делать это вторым способом.
Почему мы делаем отладку и профилирование? Это не потому, что мы хотим написать лучший в мире код и получить повышение заработной платы - это может быть нашей причиной, но на самом деле это не причина, по которой вы это делаете, - вы пообещали бизнесу, что вы сделаете что-то правильно, что ваша программа будет эффективной. Вот для чего вы будете использовать отладчик. Кроме того, бизнес конечных пользователей; они не очень терпеливы: они хотят результатов еще до того, как нажмут клавишу. Предполагалось читать их мысли и делать все мгновенно. Другими словами, это должно быть эффективно. И вот, для этого мы бы использовали профилировщик. Теперь, без этих инструментов, я действительно верю, что вы этот парень в деловом костюме с луком и стрелами, и вы стреляете по цели, и у вас завязаны глаза. Потому что как вы узнаете, как программа выполняется, просто взглянув на статический код, и как вы узнаете, в какой строке она действительно потратит больше всего времени, опять же, просто взглянув на статический код? Проверка кода может включать или не включать некоторые из этих вещей, но нет никакой гарантии, что проверка кода найдет их все. Используя отладчик и профилировщик, вы сможете найти все эти ошибки.
Хорошо, я собираюсь сделать очень быстрое демо здесь. Я не собираюсь продвигать продукт, я просто хочу показать вам, как выглядит отладчик, потому что много раз люди говорили: «Я никогда не видел ни одного из них раньше». И это выглядит симпатично на слайдах со снимками экрана, но что это выглядит, когда он в движении? Итак, здесь, на моем экране, я запускаю наш продукт DB Artisan; у нас также есть отладчик. DB Artisan больше предназначен для администраторов баз данных, Rapid SQL - больше для разработчиков, но я видел разработчиков, которые используют DB Artisan, и я видел администраторов баз данных, которые используют Rapid. Таким образом, не зацикливайтесь на продукте. И здесь у меня есть выбор сделать отладку, но перед тем, как запустить отладку, я собираюсь извлечь этот код, чтобы вы могли увидеть, как выглядит код, прежде чем я начну его запускать. Итак, вот тот же код, который был на снимке экрана, это моя проверка на дубликаты. И я хочу отладить это, поэтому я нажимаю отладку. И теперь, это занимает мгновение, и вы говорите: «Ну, почему это занимает мгновение?» Помните удаленную отладку: отладка фактически происходит на моем сервере базы данных, а не на моем ПК. Таким образом, он должен был перейти и создать там сеанс, создать удаленную отладочную вещь, подключить мой сеанс к этому сеансу удаленной отладки и настроить канал связи.
Итак, теперь, вот моя стрелка, вверху, вверху, в первой строке, где я нахожусь в коде. И если я нажму на третью иконку, которая является шагом вперед, вы увидите, что стрелка только что сдвинулась, и если я продолжу нажимать ее, вы увидите, что она продолжает двигаться. Теперь, если я хочу пройти весь цикл FOR, потому что я знаю, что в этом проблема, я могу установить точку останова. Я думал, что установил это. О, блин, у меня была одна из клавиш захвата экрана, сопоставленная с той же клавишей, что и отладчик, вот что и привело к путанице. Итак, я просто вручную установил там точку останова, так что теперь вместо того, чтобы делать шаг, шаг, шаг, шаг, пока я не достигну этого, на самом деле я могу просто сказать: «Иди и запусти эту штуку», и она остановится. Обратите внимание, что он полностью переместил меня туда, где находится точка останова, так что теперь я нахожусь в ловушке запуска этого цикла, я могу видеть, на что настроены все мои переменные, что неудивительно, потому что я инициализировал их все нуль. И теперь я могу войти в этот цикл и начать смотреть на то, что происходит внутри этого цикла.
Итак, теперь я собираюсь сделать выборочный подсчет из моих прокатов, и я могу навести курсор на этого парня и посмотреть, ему два, два больше, чем один, так что, вероятно, он собирается выполнить следующий фрагмент этого кода. Другими словами, он что-то нашел. Я просто собираюсь идти вперед и позволить этому бежать. Я не хочу проходить все здесь; Я хочу показать вам, что когда отладчик завершен, он завершает работу, как обычная программа. Я установил точку останова, поэтому, когда я сказал запустить, он просто вернулся к следующей точке останова. Я позволяю ему работать до конца, потому что я хочу, чтобы вы увидели, что отладчик не меняет поведение программы: когда она будет завершена, я должен получить точно такие же результаты, если бы я запустил ее не внутри отладчика.
И с этим я собираюсь приостановить демонстрацию и вернуться, потому что мы хотим убедиться, что у нас есть время для вопросов и ответов. И так, я открою это для вопросов и ответов.
Эрик Кавана: Ладно, Робин, может, у тебя вопрос, а потом пара из Деза?
Робин Блур: Да, конечно, я нахожу это захватывающим, конечно. Я работал с такими вещами, но я никогда не работал с такими в базе данных. Можете ли вы дать мне некоторое представление о том, для чего люди используют профилировщик? Потому что, похоже, они смотрят - потому что, как я полагаю, они - они смотрят на проблемы с производительностью, поможет ли вам отличить время, когда база данных занимает время, и когда код требует времени?
Берт Скальцо: Вы знаете, это фантастический вопрос. Допустим, я работаю в Visual Basic, и внутри своей Visual Basic я буду называть Transact-SQL или PL / SQL. Позвольте мне сделать PL / SQL, поскольку Oracle не всегда хорошо работает с инструментами Microsoft. Я мог бы профилировать свой код Visual Basic, и профиль там может сказать: «Эй, я вызвал эту хранимую процедуру, и это заняло слишком много времени». Но затем я могу перейти к хранимой процедуре и сделать профиль базы данных на сохраненной выполните процедуру и скажите: «Хорошо, из 100 приведенных здесь утверждений есть пять, которые вызвали проблему». Итак, вам, возможно, придется создать команду тегов, где вам придется использовать несколько профилировщиков.
Идея состоит в том, что если вам когда-нибудь сообщат, что проблема с производительностью находится в вашей базе данных, профиль базы данных может помочь вам найти иголку в стоге сена, на которой заявления действительно являются теми, где у вас есть проблема. Я расскажу вам еще одну вещь, которая возникла при профилировании: если у вас есть фрагмент кода, который вызывается миллион раз, но он занимает микросекунду каждый миллион раз, но вызывается миллион раз, то, что показал бы профилировщик Эта вещь побежала за это много единиц времени. И поэтому, хотя код может быть очень эффективным, вы можете посмотреть и сказать: «Ох, слишком часто делали этот вызов этому коду. Возможно, нам следует называть это только так часто, а не каждый раз, когда мы обрабатываем запись »или что-то в этом роде. Таким образом, вы можете найти эффективный код, который вызывается слишком часто, и на самом деле это проблема производительности.
Робин Блур: Да, это прекрасно. Я никогда не делал этого. Видите ли, конечно, когда у меня были проблемы с базой данных, это было так, как если бы я так или иначе имел дело с базой данных или с кодом; Я никогда не мог иметь дело с ними обоими одновременно. Но там, опять же, я не делал - я никогда не участвовал в создании приложений, где у нас были хранимые процедуры, поэтому я думаю, что я никогда не сталкивался с проблемами, которые приводили меня в бешенство, идея, что вы разделите код между база данных и программа. Но так, делайте все - я предполагаю, что ответы будут положительными, но это часть деятельности команды разработчиков, когда вы тем или иным образом пытаетесь исправить что-то сломанное или, возможно, пытаетесь собрать новое приложение. Но все ли это связано со всеми другими компонентами, которые я ожидал бы в окружающей среде? Могу ли я ожидать, что смогу связать это вместе со всеми моими тестовыми пакетами и всем остальным, что я буду делать, и со своими вещами по управлению проектами, вот как все это скрепляется?
Берт Скальцо: Да, это может стать частью любого структурированного процесса для ваших усилий по программированию или разработке. И что забавно, на прошлой неделе у меня был заказчик, который создавал веб-приложение, и его база данных была маленькой, исторически, и поэтому тот факт, что они не были очень хорошими программистами, никогда не причинял им вреда. Ну, их база данных выросла за эти годы, и теперь она занимает 20 секунд на веб-странице, между тем, когда вы говорите «Войдите в систему и дайте мне некоторые данные, чтобы увидеть», и когда на самом деле появляется экран, и теперь его проблема с производительностью. И они знали, что проблема не в какой-либо их Java или в любом другом месте. Но у них было тысячи хранимых процедур, и поэтому им пришлось начать профилирование хранимых процедур, чтобы выяснить, почему эта веб-страница занимает 20 секунд? И мы на самом деле обнаружили, что у них есть декартово объединение в одном из их избранных утверждений, и не знали об этом.
Робин Блур: Ух ты.
Берт Скальцо: Но кто-то однажды сказал мне: «Ну, как они могли присоединиться к Декарту и не знать об этом?» И это звучит действительно ужасно; иногда программист, которому не очень комфортно с SQL, может что-то сделать, например, дать мне декартово соединение, но затем вернуть мне только первую запись, так что я знаю, что получил что-то, а мне нужна только первая. И поэтому они не осознают, что просто вернули миллиард записей или просмотрели миллиард записей, потому что получили тот, который им был интересен.
Робин Блур: Ух ты, я знаю, это то, что называется - ну, это то, о чем говорил Дез, с точки зрения людей, не настолько опытных, как, возможно, они должны быть, вы знаете. Если вы программист, вы должны знать, каковы последствия использования любой команды. Я имею в виду, действительно, нет никакого оправдания этому уровню глупости. Я также предполагаю, что вы, так или иначе, просто независимы от языка в этом отношении, потому что все это сосредоточено на стороне базы данных. Я прав в этом? Это то же самое, что вы используете на стороне кодирования?
Берт Скальцо: Безусловно, вы можете сделать это в Fortran или C или C ++. Фактически, в некоторых Unixes вы можете сделать это даже для их языков сценариев; на самом деле они предоставляют одни и те же инструменты. А потом я хочу вернуться на секунду назад к тому, что вы сказали, без оправдания. Я собираюсь дать программистам один перерыв, потому что я не люблю бросать программистов под шину. Но проблема на самом деле в академической среде, потому что когда вы учитесь быть программистом, вас учат думать по-новому. Вас не учат мышлению множеств, и это то, что язык структурированных запросов или SQL работает с множествами; Вот почему у нас есть объединение, оператор пересечения и минус. И иногда человеку, который никогда не думал о множествах, очень трудно бросить, отпустить обработку записей и работать с множествами.
Робин Блур: Да, я с тобой об этом. Я имею в виду, я понимаю, это проблема образования; Я думаю, что это полностью вопрос образования, я думаю, что для программистов естественно думать процедурно. И SQL не процедурный, а декларативный. Вы на самом деле просто говорите: «Это то, что я хочу, и мне все равно, как вы это делаете», понимаете? Принимая во внимание, что с языками программирования вы часто закатываете рукава и погружаетесь в мелочи даже управления счетами, пока вы делаете цикл. Я подам руку на
Берт Скальцо: ОК, продолжай.
Да, я собирался сказать, что вы привели еще один пример того, что профилировщик был бы неплохо уловить, что-то вроде обработки этой записи за один раз. Иногда программист, хорошо разбирающийся в логике записи за один раз, не может понять, как сделать программу на SQL. Ну, допустим, он делает два цикла FOR и в основном выполняет соединение, но он делает это на стороне клиента. Таким образом, он выполняет тот же эффект, что и объединение, но делает это сам, и профиль поймет это, потому что вам, вероятно, придется тратить больше времени на объединение вручную, чем позволить серверу баз данных сделать это за вас.
Робин Блур: Да, это было бы катастрофой. Я имею в виду, вы бы просто бродили вокруг. Обманы всегда плохие.
В любом случае, я передам Дезу; Я уверен, что у него есть несколько интересных вопросов.
Дез Бланчфилд: Спасибо, да, я делаю. Я собираюсь присоединиться к вам в не бросать программистов под автобусом. Я имею в виду, что я провел слишком много лет в своей жизни, будучи самим кодером, на каждом уровне, знаете ли, как вы сказали, сидя в командной строке Unix-машины, а в некоторых случаях я даже участвовал в пара разных портов Unix с одной аппаратной платформы на другую. И вы можете себе представить проблемы, которые у нас были там. Но реальность такова, что вот эта карта выхода из тюрьмы для каждого программиста и сценариста в мире. Это в буквальном смысле ракетостроение, в буквальном смысле, писать очень плотно каждый раз, все время, это ракетостроение. И знаменитые истории таких людей, как Деннис Ритчи и Брайан Кернахан, которые работали над каким-то куском кода независимо, а затем обратились к чату обзора кода за чашкой кофе и выяснили, что они написали один и тот же кусок кода, в одной и той же программе, в точности так же. И они сделали это на C. Но этот пуристский уровень программирования существует очень редко.
Дело в том, что на ежедневной основе есть только 24 часа в день, семь дней в неделю, и нам просто нужно что-то сделать. И так, когда речь идет не только о традиционных программистах, администраторах баз данных, кодировщиках и сценариях, а также сисадминах, сетевых администраторах и сотрудниках службы безопасности, а также обо всем, вплоть до данных о гражданах в эти дни; мы слышим, все просто пытаются сделать свою работу. И поэтому я думаю, что большой вывод из всего этого - мне понравилась ваша демонстрация, и мне понравился вынос, с которым вы оставили нас там, всего минуту назад, разговаривая с Робином о том факте, что в этом есть что-то особенное - возможно, не так сильно ниша - но широкое пространство, к которому она применяется, в том, что касается исправления кода, SQL и баз данных. Но мне было очень приятно услышать, как вы говорите, что вы можете вставить его в сценарий оболочки и найти некоторые проблемы, потому что, как вы знаете, в наши дни день и возраст всегда работали с наименьшими затратами на все.
Причина, по которой вы можете купить где-то рубашку за 6 долларов, заключается в том, что кто-то создал систему достаточно дешево, чтобы фактически производить, отгружать, доставлять, продавать и продавать в розницу, а также принимать онлайн-платежи, чтобы получить эту рубашку за 6 долларов. И этого не произойдет, если у вас будут люди, которым платят 400 000 долларов в год, чтобы написать код идеальным способом; это всего лишь развитие. Итак, я полагаю, что один из вопросов, который мне действительно нравится, просто чтобы дать нам более глубокое понимание, заключается в том, какова широта и охват тех людей, которых вы видите в настоящее время, которые используют эти виды инструментов для профилирования кода и просмотра по вопросам производительности? Первоначально, исторически, откуда они берутся? Это были большие инженерные дома? И затем, продолжая, верно ли это, я прав, полагая, что все больше и больше компаний внедряют этот инструмент или эти инструменты, чтобы попытаться помочь кодировщикам, которые, как они знают, просто делают вещи, чтобы завершить работу и вытащить это за дверь? И иногда нам нужна карта для выхода из тюрьмы? Правильно ли я считаю, что исторически у нас было больше инженерного внимания и развития? Что теперь, как говорил Робин, получило меньше академического подхода, а теперь его самоучка, или код "вырезай и вставляй", или просто создавай вещи? И соответствует ли это типу людей, которые сейчас принимают продукт?
Берт Скальцо: Да, именно. И я приведу очень конкретный пример, мы просто хотим выполнить работу, потому что деловые люди не хотят совершенства. Это своего рода компьютерная игра в шахматы: шахматная игра не ищет идеального ответа; он ищет ответ, который достаточно хорош в разумные сроки, так мы программируем. Но сейчас я обнаружил, что большинство людей вместо того, чтобы сказать, что они хотят использовать профилировщик в рамках своего модульного тестирования - именно так я бы это сделал, потому что я не считаю это пустой тратой времени - сейчас происходит то, что происходит позже, иногда, во время интеграционного тестирования или стресс-тестирования, если повезло. Но в большинстве случаев это было частью эскалации, когда кое-что пошло в производство, оно работало какое-то время, может быть, даже работало годами, и теперь оно не работает хорошо, а теперь хорошо его описывает. И это, кажется, более распространенный сценарий сейчас.
Дез Бланчфилд: Да, и я думаю, что термин «технический долг», вероятно, знаком с вами; Я знаю Робина, и я, конечно, есть. Я думаю, что в наши дни, особенно в гибких подходах к разработке и системному построению, для меня концепция технического долга сейчас является очень реальной вещью, и мы фактически учитываем ее в проектах. Я знаю, я имею в виду, у нас есть свои собственные проекты, такие как Media Lens и другие, где у нас ежедневно происходит кодирование, и различные вещи в Bloor Group. И всякий раз, когда что-то строили, мы как бы смотрим, я смотрю на это и всегда смотрю с точки зрения того, что будет стоить мне исправить это прямо сейчас, вместо того, чтобы просто взять это в банку и получите это там, а затем посмотрите и посмотрите, не сломается ли это. И унаследовать этот технический долг, который, как я знаю, мне придется вернуться позже и исправить.
И я имею в виду, я сделал это за последние семь дней: я написал несколько инструментов и сценариев, я написал пару кусочков языка Python и развернул его на бэкэнде Mongo, убедившись, что он красивый, чистый и безопасный, но он просто получает запрос, который мне нужен, зная, что мне нужна эта функция для работы, чтобы добраться до большой загадки; вот где моя настоящая боль. Итак, вы несете этот технический долг, и я думаю, что это теперь не просто случайность, я думаю, что это часть ДНК развития сейчас. Люди просто - не лукаво - они просто принимают технический долг - это нормальный тип проблемы, и им просто приходится его брать на себя. Это где вы несете технический долг. И я думаю, что самое замечательное в том, что вы показали нам в демоверсии, это то, что вы можете буквально описать профиль и посмотреть, сколько времени потребуется для запуска. И это, наверное, одна из моих любимых вещей. Я имею в виду, что я на самом деле создавал инструменты профилирования - мы использовали инструменты для сборки в Sed, Lex и Orc, чтобы запускать наш код и видеть, где были циклы, до того, как стали доступны инструменты, подобные этой, - и когда вы создавали код для просмотра и проверки собственного кода. вы очень хорошо понимаете, что вам не нужно пересматривать свой собственный код. Но сейчас это не так. Имея это в виду, существует ли определенный сегмент рынка, который занимает это больше, чем любой другой? Видя, как масса
Берт Скальцо: О да, у меня есть ... Я собираюсь провести аналогию для вас и показать, что непрограммисты делают это все время. Потому что, если я когда-нибудь преподаю отладчик и профилирую класс или сеанс, я спрошу людей: «Хорошо, сколько людей здесь заходят в Microsoft Word и целенаправленно никогда не используют программу проверки орфографии?» И никто не поднимает руку, потому что для написания документов, мы все знаем, что можем делать ошибки на английском языке, и поэтому все используют программу проверки правописания. И я сказал: «Что ж, когда вы пишете в своей IDE, такой как Visual Basic, вы не используете отладчик? Это то же самое, что-то вроде проверки орфографии.
Дез Бланчфилд: Да, на самом деле, это отличная аналогия. Я действительно не задумывался, я должен признать, что на самом деле я делаю нечто подобное с парой инструментов, которые я использую. На самом деле, один из них, ODF, мой любимый в Eclipse - просто вырезать и вставлять туда код и искать вещи, которые сразу выделяются, и понимая, что я сделал опечатку в каком-то вызове класса. И, что интересно, теперь с помощью такого инструмента вы можете делать это в режиме реального времени, а не возвращаться и смотреть на него позже, что было бы неплохо, если бы он был уловим заранее. Но да, это отличная аналогия, заключающаяся в простом вводе в текстовый процессор, вызывающий интересный пробужденный сигнал: просто поймите, что вы допустили опечатки или даже грамматическую ошибку, верно?
Берт Скальцо: Именно так.
Дез Бланчфилд: Итак, вы видите больше всплеска, я думаю, я имею в виду последний вопрос от меня, прежде чем я, возможно, передам наши вопросы и ответы для наших посетителей. Если вы собирались дать какую-то рекомендацию относительно подхода, чтобы сделать это - я предполагаю, что это риторический вопрос - это тот случай, когда вы входите рано и реализуете это по мере своего развития, прежде чем приступить к разработке? Или это тот случай, когда вы в основном строите, двигаетесь, строите что-то, а затем заходите и профилируете это позже? Я подозреваю, что дело в том, чтобы войти рано и убедиться, что ваши коды чисты заранее. Или это тот случай, когда они должны рассмотреть эту часть своего пост-развертывания?
Берт Скальцо: В идеале, они должны делать это заранее, но поскольку все находятся в суетном мире, где им просто нужно что-то сделать, они не будут делать это, пока не столкнутся с проблемой производительности, которую не могут решить, добавив больше процессоров и памяти. виртуальной машине.
Дез Бланчфилд: Да уж. Итак, на самом деле вы упомянули что-то интересное, если я могу быстро? Вы упомянули ранее, что это может быть запущено из любого места и может общаться с базой данных на серверной части. Так что это устраивает своего рода бимодальную концепцию, о которой мы сейчас говорим, о локальном / внешнем облаке, а также о внешнем виде вещей, в конце концов, если он может поговорить с серверной частью и увидеть код, это действительно не волнует, не так ли?
Берт Скальцо: Точно, да, вы можете запустить это в облаке.
Дез Бланчфилд: Отлично, потому что я думаю, что именно в этом наш новый храбрый мир. Итак, Эрик. Сейчас я собираюсь отбросить вас назад и увидеть, что у нас здесь есть несколько вопросов, и я хочу, чтобы наши участники все еще оставались с нами, даже если мы прошли час.
Эрик Кавана: Да, есть несколько человек, я просто сделаю небольшой комментарий: Берт, я думаю, что метафора, аналогия, которую вы даете использованию проверки правописания, откровенно блестящая. Честно говоря, это достойно одного или двух блогов, потому что это хороший способ показать, что вы делаете, насколько это ценно, и как лучше всего использовать отладчик на регулярно, верно? Могу поспорить, что вы киваете головой, когда выбрасываете это, верно?
Берт Скальцо: Безусловно, потому что я говорю им: «Почему я проверяю орфографию в моих документах? Я не хочу смущаться из-за глупых орфографических ошибок ». Ну, они не хотят смущаться из-за глупых ошибок кодирования!
Эрик Кавана: Правильно. Да, в самом деле. Ну, ребята, мы прожгли здесь час и пять минут, так что большое спасибо всем вам за ваше время и внимание. Мы архивируем все эти веб-чаты, не стесняйтесь возвращаться в любое время и проверять их. Лучшее место для поиска этих ссылок, вероятно, techopedia.com, так что добавьте это в этот список прямо здесь.
И с этим, собирались попрощаться с вами, ребята. Еще раз, Берт, отличная работа, спасибо нашим друзьям из IDERA. Хорошо поговорим с тобой в следующий раз, хорошо поговорим с тобой на следующей неделе, на самом деле. Береги себя! Пока-пока.