Винос: Ведучий Ерік Кавана обговорив налагодження та профілювання бази даних з докторами Робіном Блором, Дезом Бланчфілдом та IDERA Бертом Скальцо.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Гаразд, панове, це середа о 4:00 за східним часом, і це, звичайно, означає.
Робін Блор: Не чую тебе, Еріку.
Ерік Кавана: Я був там дні тому, тож ти не один. Але тому тема сьогодні - це справді цікаві речі. Це та річ, яку ви хочете переконатися, що відбувається у фоновому режимі у вашій компанії, якщо ви не людина, яка робить це, і в цьому випадку ви хочете переконатися, що ви робите це правильно. Тому що говорили про налагодження. Ніхто не любить помилок, нікому не подобається, коли програмне забезпечення перестає працювати - люди засмучуються, користувачі стають недоброзичливими. Це не добре. Отже, збиралися поговорити про "Швидке реагування: Налагодження бази даних та профілювання до порятунку".
Це місце про твою по-справжньому, вдарив мене, @eric_kavanagh звичайно.
Цей рік - гарячий. І налагодження буде гарячим, незважаючи ні на що. Це справді буде однією з цих проблем, яка ніколи не піде, незалежно від того, наскільки добре ми отримаємо цю справу, завжди будуть проблеми, тож ключовим є те, як дістатися до місця, де можна швидко вирішити ці питання? В ідеалі у вас є чудові програмісти, чудові умови, де не так вже й піде не так, але як свідчить стара приказка: «Аварії трапляються в кращих сім'ях». І те саме стосується організацій. Отже, ця штука буває, вона відбудеться, питання полягає у тому, що буде вашим рішенням для вирішення цього питання та вирішення цих проблем?
Добре чути від доктора Робіна Блура, потім нашого власного Дез Бланчфілда знизу, і, звичайно, нашого доброго друга, Берта Скальцо, з IDERA. Насправді я збираюся віддати ключі від Робіна Блора, забрати його. Підлога ваша.
Робін Блор: ГАРАЗД. Це цікава тема. Я думав, оскільки Дез, ймовірно, збирається продовжувати фактичні прийоми та історії війни про налагодження, я подумав, що я просто пройду фонову дискусію, щоб ми мали отримати повністю закруглену картину того, що відбувається. Я робив це давно, і я був кодером, тому подібне, і я майже спокусився цією презентацією почати воскову ліричну ідею з відкритим кодом, але я подумав, що Я залишаю це комусь іншому.
Ось список відомих помилок, і більшість із них потрапляють у топ-список будь-кого, в основному всі, крім двох останніх, коштують не менше 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 р. Команда Гарвардського університету розтягувала машину, вони натрапляли на щось, що вони називали "ретрансляція сімдесяти" - в ті дні програмування здійснювалося у фізичному сенсі, ви намотували код навколо дошки, і саме так ви ефективно програмували машина - і вони знайшли це реле номер сімдесят, там було щось не так, і виявляється, що власне термін «помилка» виник, тому що він буквально був молі - нібито там був моль, врізаний між частиною мідного дроту з одного місця в інше. І розповідь іде про те, що легендарна Грейс Хоппер, як цей підпис, для мого слайду заголовка "перший фактичний випадок виявлення помилки" цитує цитата.
Але як Робін підкреслював раніше у своєму першому слайді, поняття про помилку йде так далеко, як ми можемо уявити, як люди роблять обчислення, поняття на зразок виправлення. Термін "патч" походить від фактичного шматка стрічки, який проклеюється над отвором на перфокарті. Але вся справа в тому, що термін "налагодження" вийшов із цієї концепції пошуку помилки у фізичній машині. І з тих пір ми використовували цю термінологію, намагаючись вирішити проблеми, або не стільки як проблеми кодування в програмі, яка не компілюється, а як програма, яка не працює добре. І спеціально не було профільовано просто знайдіть такі речі, як нескінченні петлі, які просто нікуди не йдуть.
Але у нас також є сценарій, і я подумав, що Id поставив кілька кумедних слайдів, перш ніж я вступив у трохи детальніше. Ось класичний мультфільм, який називається XKCD в Інтернеті, і мультиплікатор має досить кумедні погляди на світ. А це про дитину, яку називали «Столиками маленького Бобі», і нібито його батьки назвали цього маленького хлопчика Робертом); СКЛАДУТЬ СТІЛЬКИ Учні; - і це називається, і начебто "Привіт, це школа ваших синів, яка має деякі проблеми з комп'ютером", і батько відповідає: "О, дорогий, чи щось він зламав?" певним чином, - і запитує вчитель, - чи справді ви назвали свого сина Робертом); СКЛАД СТІЛ Студенти; -? ”А батько каже:“ О так, маленький Боббі Столи, ми його називаємо. ”У будь-якому випадку, вони продовжують говорити, що тепер втратили записи студентів, я сподіваюся, що ви щасливі. І відповідь: "Ну, ви повинні очистити та очистити свої дані в базі даних". І я часто використовую це, щоб говорити про деякі проблеми, які ми маємо в пошуку речей у коді, що часто код також не переглядає дані. .
Ще один кумедний, я не знаю, справжній це чи ні - я підозрюю, що це підробка - але знову ж таки, це стосується і моєї смішної кістки. Хтось міняє номерні знаки на передній частині свого автомобіля, на аналогічну заяву, яка спричиняє падіння баз даних у камери швидкості тощо, що захоплює номерні знаки автомобілів. І я завжди посилаюсь на це так, що сумніваюся, що будь-який програміст передбачив потрапляння свого коду фактичним автотранспортом, але ніколи цього не варто недооцінювати - сила розлюченого вун.
(Сміх)
Але я думаю, це призводить до мого ключового моменту, і це те, що колись ми могли налагоджувати та кодувати профіль як просто смертні. Але я дуже переконаний, що цей час минув, і анекдотично, на моєму досвіді, моє перше - і це мені дуже страшно, я впевнений; Робін вітаєш мене з цього приковуватися, але історично я родом з фонового віку у віці 14 років блукає кінцем міста і стукає у двері дата-центру, який називається “Data Com” у Новій Зеландії, і запитує, чи Я міг би заробляти кишенькові гроші в школі, повертаючи пізній автобус додому, десь 25 км їзди на маршруті, щодня ставлячи папір у стрічки та стрічки в магнітофони і просто будучи генеральним адміністратором. І що цікаво, вони мені дали роботу. Але з часом мені вдалося ввійти в штатний розпис і знайти програмістів і зрозумів, що я люблю кодування, і пройшов процес запуску скриптів та пакетних завдань, який в кінці дня все ще є кодом. Ви повинні писати сценарії та пакетні завдання, схожі на міні-програми, а потім пройти весь процес сидіння в коді 3270 запису терміналу вручну.
Насправді, найперший мій досвід був на терміналі телетайпу, який насправді був 132-стовпним фізичним ер.По суті, подумайте, як про дуже стару машинку з папером, який прокручується по ній, тому що у них не було трубки CRT. І налагодження коду на цьому було дуже нетривіальною проблемою, тому ви прагнули написати весь код вручну, а потім діяти як машиністка, роблячи все можливе, щоб не помилитися, щоб прокрастись, тому що це надзвичайно засмучує. один редактор рядків, щоб перейти до певного рядка, а потім рядок, а потім ввести його знову. Але колись саме так ми писали код і ось як налагоджували, і ми отримали дуже, дуже добре в цьому. І насправді це змусило нас мати дуже хороші методи програмування, адже це було справжнім клопотом виправити це. Але тоді подорож пройшла - і всі були знайомі з цим - вона пройшла від терміналу 3270 в моєму світі, до цифрового обладнання VT220, де ви могли бачити речі на екрані, але знову ж таки, ви просто робили те саме, що ви робили на паперовій стрічці на зразок формату ed лише на CRT, але ви змогли простіше видалити, і у вас не було такого звуку "dit dit dit dit".
І тоді ви знаєте, термінали Wyse - як, наприклад, Wyse 150 - це, напевно, мій улюблений інтерфейс до комп’ютера коли-небудь - і тоді ПК, а потім Mac, а сьогодні ці сучасні графічні інтерфейси та ідентифікатори, які базуються на веб-сторінках. І цілий спектр програм, програмування в одному і асемблері, а також PILOT, Logo та Lisp, Fortran і Pascal та мови, які можуть змусити людей скупитися. Але це мови, які змусили вас написати хороший код; вони не дозволили вам піти від поганих практик. C, C ++, Java, Ruby, Python - і ми просуваємося далі на етапі програмування, ми отримуємо більше схожих на сценарій, ми наближаємось до ближче до структуризованої мови запитів та мов, таких як PHP, які фактично використовуються для виклику SQL. Сенс сказати тобі, що, виходячи зі свого походження, я багато в чому був самоучкою, і ті, що допомогли мені навчитися, навчили мене дуже хорошій програмістській практиці та дуже хорошій практиці дизайну та процесів, щоб переконатися, що я не представив баггі код.
Методи програмування в наші дні такі речі, як, наприклад, Structured Query Language, SQL, це дуже потужна, проста мова запитів. Але ми перетворили його на мову програмування, і я не вірю, що SQL коли-небудь був розроблений як сучасна мова програмування, але ми перекосили його, щоб стати таким. І це вводить цілу купу питань, тому що ми думаємо про це з двох точок зору: з точки зору кодування та з точки зору DBA. Дуже легко зібратися і ввести помилки для таких речей, як просто погані методи програмування, ледачі зусилля при написанні коду, відсутність досвіду, класичний підгляд для домашніх тварин у мене, наприклад, з SQL-людьми, що стрибають по Google і шукають щось і знаходять веб-сайт отримав приклад і зробив копію та вставлення існуючого коду. А потім тиражувати погане кодування, недосконалість та вводити його у виробництво, адже це просто відбувається, щоб дати їм бажані результати. У вас виникли інші виклики, наприклад, в ці дні всі кидалися назустріч цьому, що ми називаємо гонкою до нуля: намагаючись зробити все так дешево і так швидко, що у нас є сценарій, коли не було зайнято низькооплачуваних працівників. І я цього не маю на увазі, нехай не буде наймати експертів для кожної можливої роботи. Колись щось, що стосується комп'ютерів, було ракетною наукою; вона брала участь у речах, які чухалися і були дуже голосними, або виходили в космос, або інженери були висококваліфікованими чоловіками та жінками, які здобули ступінь і мали сувору освіту, яка не давала їм робити божевільні речі.
У наші дні дуже багато людей, що вступають у розробку та дизайн та базу даних, які не мали багаторічного досвіду роботи, не мали обов'язково однакової підготовки чи підтримки. І так ви закінчуєте сценарій просто традиційного аматора проти експерта. І ось відомий рядок, я не можу насправді пам’ятати, хто створив цитату, лінія іде: «Якщо ви думаєте, що дорогий наймає експерта для виконання роботи, зачекайте, поки ви наймете пару любителів, які створюють проблему, і вам доведеться Почистіть його ». І тому SQL має цю проблему, і її дуже, дуже просто вивчити, дуже просто у використанні. Але, на мій погляд, це не ідеальна мова програмування. Дуже легко робити такі речі, як зробити вибрану зірку звідки завгодно, і перетягнути все це на мову програмування, яка вам зручніша, як PHP та Ruby чи Python, і використовувати мову програмування, з якою ви споконвічно знайомі, щоб робити маніпуляції з даними, а не робити більш складний запит у SQL. І ми бачимо це багато, і тоді люди задаються питанням, чому база даних працює повільно; це тому, що мільйон людей намагаються придбати квиток у онлайн-системі квитків, де це вибрана зірка куди завгодно.
Зараз це справді екстремальний приклад, але ви розумієте це з усього цього. Отже, щоб просто побити цей пункт додому, ось приклад, який я багато переношу. Я великий фанат математики, я люблю теорію хаосу, я люблю набори Мандельброта. Праворуч представлено набір Мандельброта, з яким я впевнений, що всі були знайомі. А ліворуч - фрагмент SQL, який насправді робить це. Тепер, кожного разу, коли я десь кладу це на екран, я чую це "О боже мій, хтось видавав серію Мандельброта з SQL, ти серйозно? Це божевільно! ”Ну, вся суть у тому, щоб проілюструвати те, що я щойно там окреслював, і це так, адже ви тепер можете програмувати майже що завгодно в SQL; це дуже розвинена, потужна, сучасна мова програмування. Якщо спочатку це була мова запитів, вона була розроблена так, щоб просто отримати дані. Таким чином, зараз у нас є дуже складні конструкції, і у нас є збережені процедури, ми отримали методологію програмування, яка застосовується до мови, і це дуже легко для поганої практики програмування, відсутності досвіду, скорочення та вставки коду, низькооплачуваного персоналу, який намагається бути високооплачуваним персоналом, людям, що роблять вигляд, що знають, але вони повинні вчитися на роботі.
Цілий ряд речей, де кодування профілю та те, що ми називаємо налагодженням, це не стільки пошук помилок, які зупиняють роботу програм, але помилки, які просто шкодять системі та погано структурований код. Коли ви дивитесь на цей екран зараз, і ви думаєте, що це просто, його мило, і ви думаєте: "Ух, яка чудова графіка, я люблю це запускати". Але уявіть, що це працює на якійсь діловій логіці. Це виглядає досить акуратно, але говорить математично графічно викладеною теорією хаосу, але коли ви думаєте про те, для чого це потенційно може бути використане в певній бізнес-логіці, ви отримуєте картину дуже швидко. І щоб насправді проілюструвати це - і мені шкода, що кольори зворотні, його має бути чорний фон, а зелений - зелений екран, але ви все ще можете це прочитати.
Я пішов і переглянув приклад того, що ти потенційно можеш зробити, якщо ти справді божевільний і не мав жодного досвіду, і прийшов з іншого фону програмування і застосував подобається C ++ до SQL, щоб дійсно проілюструвати мою думку, перш ніж Я передаю нашого вченого гостя з ІДЕРИ. Це структурований запит, написаний як C ++, але його закодовано в SQL. І це насправді виконується, але виконується протягом приблизно трьох-п'ятихвилинного періоду. І він нібито відтягує назад один рядок даних із безлічі баз даних, декількох з'єднань.
Знову ж таки, вся справа в тому, що якщо у вас немає правильних інструментів, якщо у вас немає правильних платформ і середовищ, щоб ви могли зловити ці речі, і вони вступають у виробництво, і тоді у вас 100 000 людей, які б'ють кожну систему день, або година, або хвилина, дуже скоро ви закінчитеся чорнобильським досвідом, коли велике залізо починає плавитися і закопуватися до ядра планети, тому що цей фрагмент коду ніколи не повинен потрапляти у виробництво. Вибачте, ваші системи та ваші інструменти повинні це підібрати до того, як він пройде де-небудь поблизу - навіть через тестовий процес, навіть через UAT та інтеграцію систем, цей фрагмент коду має бути підібраний та виділений, а когось відвести в сторону та кажучи: "Подивіться, це дуже гарний код, але давайте зможете отримати DBA, щоб допомогти вам правильно побудувати цей структурований запит, бо, чесно кажучи, це просто неприємно". І URL-адреси там, ви можете зайти і подивитися - це називається найскладніший запит SQL, який ви коли-небудь писали. Тому що повірте мені, що насправді компілюється, він працює. І якщо ви вирізаєте це і вставте та просто знущаєтесь із бази даних, це буде щось, що слід спостерігати; якщо у вас є інструменти для перегляду бази даних, просто спробуйте переплавити протягом трьох - п'яти хвилин, щоб передзвонити, що є одним рядком.
Отже, підсумовуючи це, маючи на увазі, весь мій досвід кодування навчив мене, що ви можете дати людям пістолет, і якщо вони не будуть обережні, вони будуть стріляти собі в ногу; хитрість полягає в тому, щоб показати їм, де знаходиться механізм безпеки. З правильними інструментами та правильним програмним забезпеченням у вас під рукою, після того як ви зробите кодування, ви зможете переглянути свій код, ви зможете знайти проблеми шляхом профілювання коду, ви зможете знайти фактично ненавмисні помилки, які є проблемами продуктивності, і, як я вже говорив раніше , колись ви могли це робити, дивлячись на зелений екран. Ти вже не можеш; є сотні тисяч рядків коду, розгорнуті десятки тисяч додатків, у деяких випадках є мільйони баз даних, і навіть супер люди вже не можуть це робити вручну. Вам досить буквально потрібне правильне програмне забезпечення та потрібні інструменти у вас під рукою, і вам потрібна команда, яка використовує ці інструменти, щоб ви могли знайти ці проблеми та вирішити їх дуже швидко, перш ніж дійти до справи, тоді як Dr. Робін Блур підкреслив, що речі або стають згубними, і речі вибухають, або, звичайно, вони починають коштувати вам багато доларів і багато часу і зусиль, а також руйнують мораль і інше, коли вони не можуть розібратися, чому все береться довго бігати.
І маючи це на увазі, я збираюся передати нашого гостя, і я з нетерпінням чекаю почути, як вони вирішили це питання. І особливо демо, на яку я думаю, що збиралася отримати. Еріку, я пройду назад.
Ерік Кавана: Гаразд, Берт, забирай це.
Берт Скальцо: Добре, дякую. Берт Скальцо тут від IDERA, я менеджер продуктів для наших інструментів бази даних. І я збираюся поговорити про налагодження. Я думаю, що одна з найважливіших речей, про яку Робін говорив раніше, - і її дуже правда полягає в тому, що налагодження є обтяжливим і нетривіальним, а коли ви переходите до налагодження бази даних, її на порядок стає ще більш обтяжливим і нетривіальним - так, що була важливою цитатою.
ГАРАЗД. Мені хотілося почати з історії програмування, тому що я багато разів бачу людей, які не налагоджують, вони не використовують налагоджувач, вони просто програмують будь-якою мовою, якою вони користуються, і багато разів вони кажуть мені: "Ну, ці речі на налагодженні є новими, і ми ще не почали їх використовувати. "І тому, що я роблю, я показую їм цю графіку часової шкали, свого роду доісторії, старості, середніх віків, свого роду сказати, де ми були в умови мов програмування. І у нас були дуже старі мови, починаючи з 1951 року з асемблерним кодом, і Lisp, і FACT, і COBOL. Тоді ми переходимо до наступної групи, Pascals і Cs, а потім наступної групи, C ++ s, і дивимось, де цей знак питання - цей знак питання приблизно вільний від 1978 до, можливо, 1980-х років. Десь у цьому діапазоні ми мали доступні нам налагоджувачі, і так би мовити: "Ей, я не використовую налагоджувач, це викликає одне з цих нових речей", тоді ви, мабуть, почали програмувати, знаєте, ще в 50-х роках, це є єдиним способом, який ви отримаєте від цієї претензії.
Тепер інша річ, яка дивна в цій діаграмі - Дез щойно коментував Грейс Хоппер, я насправді знав Грейс, тому її різновид смішна. І тоді інша річ, над якою я сміявся - це він розповідав про телетипи, і я сидів там, ідучи: "Людина, це був найбільший стрибок у продуктивності, коли ми переходили від карт до телетипів, це був найбільший стрибок". І я програмував усіма мовами, включаючи 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; Іншими словами, цикли FOR для змінних оголошень та інших речей, які є іноземними для 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 отримали деякі вихідні дані. І що тут важливо, якщо ви перегляньте першу червону стрілку, якщо я наведіть курсор на змінну, я фактично можу побачити, яке значення знаходиться в цій змінній на той момент, як я перебираю код. І це дуже корисно, і тоді я можу переходити по черзі по одному рядку за допомогою коду, я не повинен сказати виконувати, я можу сказати, крок рядка, дозвольте мені подивитися, що сталося, перейдіть до іншого рядка, дозвольте мені побачити, що сталося, і Я роблю це в базі даних. І хоча я сиджу на Rapid SQL на своєму ПК, і моя база даних знаходиться в хмарі, я все одно можу зробити цю віддалену налагодження і побачити її та контролювати її звідси, і робити налагодження так само, як і з будь-якою іншою мовою.
Тепер, наступна стрілка там - ви можете бачити маленьку стрілку, що вказує праворуч, до цього виводу СУБД, ось де мій курсор знаходиться в даний момент - так, іншими словами, Ive ступив і ось де я є в даний момент. Отже, якщо я скажу: "Крок знову", я перейду до наступного рядка. Тепер трохи нижче цього ви побачите червону крапку. Ну, це точка розриву, яка говорить "Ей, я не хочу переступати ці лінії". Якщо я просто хочу перестрибнути все і дістатися туди, де ця червона крапка, я можу натиснути кнопку запуску і перебігти звідси або на до кінця або до точки розриву, якщо є якісь точки перерви, і тоді він зупиниться і дозволь мені зробити кроки ще раз. І причина, що це все важливо, і потужна в тому, що коли я роблю все це, те, що відбувається в середині і навіть внизу - але головне в середині - зміниться, і я можу побачити значення моїх змінних, я можу Ви бачите трасування стека викликів, знаєте, і тому вся ця інформація відображається там, як я переступаю через код, тож я насправді можу побачити і відчути і зрозуміти, що відбувається, і як код насправді працює під час виконання . І зазвичай я можу знайти проблему, якщо вона є, або якщо я досить хороший, щоб її усунути.
Гаразд, зараз я буду говорити про профілера, і в цьому випадку це профайлер, який я бачу через налагоджувач. Пам'ятаєш, я казав, що вони часом окремі, а іноді вони можуть бути разом? У цьому випадку, і знову, я в Rapid SQL, і я бачу їхній край, ліворуч, поруч з номерами рядків. І що це таке - це кількість секунд або мікросекунд, що знадобилося для виконання кожного рядка коду, і я це ясно бачу, весь свій час я проводжу в цьому циклі FOR, де я вибираю все з таблиці. Отже, що, мабуть, потрібно щось подивитися на те, що відбувається всередині цього циклу ЗА, і якщо я можу зробити це краще, він виплатить дивіденди. Я не збираюся вдосконалюватись, працюючи над тими рядками, які мають 0,90 або 0,86; там не так багато часу провели. Тепер, і в цьому випадку, я знову в Rapid SQL, ви бачите, як я можу робити профілювання, змішані з моєю налагодженням. Тепер, що приємно, що швидкий SQL також дозволяє зробити це іншим способом. Швидкий SQL дозволяє вам сказати: «Ви знаєте, що? Я не хочу знаходитись у відладчику, я просто хочу запустити це, а потім хочу переглянути графічно чи візуально один і той же тип інформації. "
І ви можете бачити, що я більше не в налагоджувальному пристрої, і він запускає програму, і після завершення виконання він дає мені графіки, щоб розповісти мені речі, щоб я міг бачити, що я отримав одне твердження, схоже на те, що він займає більшу частину пирога Діаграма, і якщо я дивлюсь, я бачу, що на цій сітці внизу, рядок 23, знову є петля FOR: він займає найбільше часу, він насправді той, що темно-червоний пережовує всю кругову діаграму. І так, це ще один спосіб робити профілювання. Ми випадково називаємо цього "Аналітика коду" у нашому інструменті. Але в основному це лише профілер, відокремлений від налагоджувача. Дехто любить робити це по-першому, деякі люблять робити це по-другому.
Чому ми робимо налагодження та профілювання? Це не тому, що ми хочемо написати найбільший у світі код і отримати підвищення заробітної плати - це може бути нашою причиною, але це насправді не причина, яку ви робите, - ви пообіцяли бізнесу, що ви зробите щось правильно, щоб ваша програма була ефективною. Ось для чого ви будете використовувати налагоджувач. Крім того, кінцеві споживачі бізнесу; вони не дуже терплячі: вони хочуть результатів ще до того, як натискають клавішу. Потрібно було прочитати їх думку і зробити все миттєво. Іншими словами, це повинно бути ефективним. І так, саме для цього ми б використали профайлер. Тепер без цих інструментів я справді вірю, що ти цей хлопець у діловому костюмі з луком і стрілою, і ти стріляєш у ціль, і ти зав'язуєш очі. Бо як ви збираєтеся знайти, як програма виконує, дивлячись на статичний код, і як ви збираєтеся розібратися, який рядок знаходиться там, де він би реально витратив найбільше часу на виконання, знову ж таки, просто переглянувши статичний код? Перегляд коду може чи не може відображати деякі з цих речей, але немає гарантії, що перевірка коду знайде їх усі. За допомогою налагоджувача та профілера ви зможете знайти всі ці помилки.
Гаразд, я просто збираюся зробити справжню швидку демонстрацію тут. Це не мій намір підштовхувати продукт, я просто хочу показати вам, як виглядає налагоджувач, що викликає багато разів, коли люди скажуть: "Я жодного разу раніше цього не бачив". це схоже на те, коли воно в русі? Отже, ось на моєму екрані я запускаю наш продукт DB Artisan; у нас також є налагоджувач. DB Artisan призначений більше для DBA, Rapid SQL - більше для розробників, але я бачив розробників, які використовують DB Artisan, і я бачив DBA, які використовують Rapid. Отже, не зациклюйтесь на продукті. І тут у мене є вибір робити налагодження, але перш ніж запустити налагодження, я збираюсь витягти цей код, щоб ви могли побачити, як виглядає код, перш ніж почати його запускати. Отже, ось такий самий код, який був на знімку екрана, це моя перевірка на дублікати. І я хочу це налагодити, тому натискаю налагодження. А тепер проходить мить, і ви кажете: «Ну, чому це займає хвилину?» Запам’ятайте віддалену налагодження: налагодження насправді відбувається на моєму сервері баз даних, а не на моєму ПК. Отже, треба було перейти і створити сеанс там, створити річ віддаленої налагодження, підключити мій сеанс до сеансу віддаленої налагодження та налаштувати канал зв’язку.
Отже, ось ось моя стрілка, її там вгорі, по першому рядку, ось де я в коді. І якщо я натисніть на третю піктограму, яка є кроком, ви побачите, що стрілка просто перемістилася, і якщо я продовжую її натискати, ви побачите, що вона продовжує рухатися. Тепер, якщо я хотів пройти весь шлях до цього циклу ЗА, оскільки я знаю, що там проблема, я можу встановити точку перерви. Я думав, що це встановив. О, знімайте, у мене один із клавіш зйомки екрана відображався на тій самій клавіші, що і налагоджувач, ось що викликає плутанину. Гаразд, тому я просто вручну встановив там точку розриву, тож тепер замість того, щоб робити крок, крок, крок, крок, поки я не дістанусь, насправді я можу просто сказати: «Вперед і запусти цю справу», і вона зупиниться. Зауважте, що це перемістило мене аж до місця перерви, тому я зараз перебуваю в кон'юнктурі цього циклу, я можу побачити, на що встановлені всі мої змінні, що не є несподіванкою, тому що я ініціалізував їх усіх нуль. І тепер я можу зайти в цю петлю і почати дивитися, що відбувається всередині цієї петлі.
Отже, тепер буде зроблено підрахунок від моєї оренди, і я можу навести курсор на цього хлопця і подивитися, два рази на два більше, ніж один, так що, ймовірно, буде зроблено наступний фрагмент цього коду. Іншими словами, воно щось знайшло. Я просто збираюся йти вперед і нехай це біжить. Я не хочу пройти все тут; те, що я хочу вам показати, це коли налагоджувач виконаний, він закінчується як звичайна програма. У мене встановлено точку розриву, тому, коли я сказав, біжи, він просто повернувся до наступної точки розриву. Я дозволяю йому запуститись до кінця, тому що я хочу, щоб ви бачили, що налагоджувач не змінює поведінку програми: коли це буде виконано, я повинен отримати такі самі результати, якби я запустив його не всередині налагоджувача.
І з цим я збираюся призупинити демонстрацію та повернутися назад, тому що ми хочемо переконатися, що в нас є час на запитання та відповіді. І так, я відкрию це для запитань та відповідей.
Ерік Кавана: Гаразд, Робін, може, питання до тебе, а потім пара від Деза?
Робін Блор: Так, звичайно, мені це здається захоплюючим. Я працював з подібними матеріалами, але ніколи не працював з подібним подібним чином у базі даних. Чи можете ви дати мені уявлення про те, для чого користуються профілери? Тому що це схоже на те, чи дивляться вони на них - тому що я припускаю, що вони є - вони дивляться на питання щодо продуктивності, чи це допоможе вам розрізнити, коли база даних потребує часу і коли код потребує часу?
Берт Скальцо: Ви знаєте, це фантастичне питання. Скажемо, що я працюю в 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 і в основному робить з'єднання, але він робить це на стороні клієнта. Так, він робить той самий ефект, що і приєднання, але він робить це сам, і профіль це захопить, тому що ви, ймовірно, витратите більше часу, роблячи приєднання вручну, ніж дозволяючи серверу баз даних зробити це за вас.
Робін Блор: Так, це було б лихом. Я маю на увазі, ти б просто лунав навколо. Збивання завжди погано.
У будь-якому випадку, я переходжу на Дез; Я впевнений, що у ХЕС з'явилися цікаві запитання.
Dez Blanchfield: Дякую, так, я. Я збираюся приєднатися до вас, що не кидають програмістів під автобус. Я маю на увазі, що я провів занадто багато років у своєму житті, будучи самим кодером, на кожному рівні, ви знаєте, чи це, як ви сказали, сидячи в командному рядку машини Unix, а в деяких випадках я навіть брав участь у пара різних портів Unix від однієї апаратної платформи до іншої. І ви можете уявити виклики, які ми мали там. Але реальність полягає в тому, що ця картка виходу з в'язниці для кожного кодера і сценариста у світі. Це ракетна наука, досить буквально, писати по-справжньому щільно кожен раз, весь час - це ракетна наука. І відомі історії таких людей, як Денніс Річі та Брайан Кернахан, які працюють над деяким кодом незалежно, а потім переходять до чату з переглядом коду за кавою і з'ясовують, що вони написали саме той самий фрагмент коду, точно в тій же програмі, точно так само. І вони зробили це в C. Але цей пуристичний рівень програмування існує дуже рідко.
Справа в тому, що щодня це лише 24 години на день, сім днів на тиждень, і нам просто потрібно робити справи. І так, якщо мова йде не лише про традиційних програмістів, DBA, і кодери, і скриптери, і sadadmin, і адміністраторів мережі, і службовців безпеки, і все, що стосується даних про громадянина в ці дні; ми чуємо, що всі намагаються виконувати свою роботу. І тому я думаю, що велике відплив від усієї цієї речі - я любив вашу демонстрацію, і я любив винос, який ви залишили нам там, лише мить назад, розмовляючи з Робіном про те, що це має особливе - можливо, не так багато ніша - але широкий простір, до якого вона застосовується, що стосується виправлення коду, 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. Добре поговоримо з вами наступного разу, добре поговоримо з вами на наступному тижні. Піклуватися! Бувай.